From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Aug 1 04:56:12 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01598 for ; Tue, 1 Aug 2000 04:56:12 -0400 (EDT) Received: from standards (47.234.32.16:2699) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83C3B@standards.nortelnetworks.com>; Tue, 1 Aug 2000 4:44:02 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1343 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Aug 2000 04:44:01 -0400 Received: from news.comp.lancs.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83C3A@standards.nortelnetworks.com>; Tue, 1 Aug 2000 4:44:01 -0400 Received: from SPOCK (egcsky000002.lancs.ac.uk [148.88.155.83]) by news.comp.lancs.ac.uk (8.10.2/8.10.2) with SMTP id e718tah15578; Tue, 1 Aug 2000 09:55:36 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Message-ID: Date: Tue, 1 Aug 2000 09:53:21 +0100 Reply-To: Stefan Schmid Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Stefan Schmid Subject: Re: [MOBILE-IP] Implementation Issues re MobileIP and IPSec X-To: Francis.Dupont@ENST-BRETAGNE.FR X-cc: Greg O'Shea To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200007311730.TAA79047@givry.rennes.enst-bretagne.fr> Content-Transfer-Encoding: 7bit Francis, please see my comments below. > => this point was signaled by me and others... The final document > is supposed to fix it. So, the care-of-address is used as the IP source address for the authentication calculations. Correct? > 2. According to the IPv6 RFC (2460) "extension headers must be > processed strictly in the order they appear in the packet". It > explicitly states that "a receiver MUST NOT, for example, scan through > a packet looking for a particular kind of extension header and process > that header prior to processing all preceding ones". > However, in contrast, the Mobile IPv6 specification declares that "the > Destination Options header in which the Binding Update option is > inserted MAY appear either before or after the AH or ESP header". > Since a Binding Update option cannot be processed before the packet > was properly authenticated (note that "any packet carrying a BU MUST > be protected by IPSEC [...]" (see 4.4), it should never occur before > the AH header in the packet. > > => I disagree because you put more in "Binding Update option processing" > than it should be. In fact when you decode the BU you don't know if there > is an AH after or (the argumebnt :-) a HA option. Now, I am confused ... Since we propose to put the BU in the 2nd Destination Options header, this problem wouldn't occur. By the time we get to the BU message, we have already processed the HA option (which MUST be in the 1st Destination Options header) and the AH (which MUST occur before the 2nd Destination Options header). > I execute the BU only > when I see the upper layer header, the processing itself is restricted > to length/alignement checks. So, what would you say are the advantages of putting the BU in the 1st Destination Options header? Or is it just convenience since only one of the Destination Options headers must be processed then? > 1. It should explicitly state which address, the mobile node's Home > Address or care-of-address, must be used as IPv6 source address for > the authentication calculation. > > => agree but I don't know what will be in the final document > (then I don't know if my code will interoperate because there are > two options :-). Could anybody working on the "final document" respond to this question? > 2. It should clarify which address, the mobile node's Home Address or > care-of-address, must be used for the SA/SP lookup. > > => this is clearly specified in the I-D (home address must be used). Could you please point out the respective section? Regards, - Stefan --- Stefan Schmid (Dipl.-Inf.) Distributed Multimedia Research Group Research Assistant Computing Department Phone: +44 (0)7989 400707 Lancaster University Fax: +44 (0)1524 593608 Lancaster LA1 4YR Email: mailto:sschmid@comp.lancs.ac.uk U.K. WWW: http://www.landmarc.net/people/stefan.htm From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Aug 1 15:16:47 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23234 for ; Tue, 1 Aug 2000 15:16:44 -0400 (EDT) Received: from standards (47.234.32.16:3187) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8402E@standards.nortelnetworks.com>; Tue, 1 Aug 2000 15:04:41 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2604 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Aug 2000 15:04:41 -0400 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8402D@standards.nortelnetworks.com>; Tue, 1 Aug 2000 15:04:40 -0400 Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e71JFl612712; Tue, 1 Aug 2000 21:15:48 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id VAA11550; Tue, 1 Aug 2000 21:15:47 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id VAA83137; Tue, 1 Aug 2000 21:16:56 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-ID: <200008011916.VAA83137@givry.rennes.enst-bretagne.fr> Date: Tue, 1 Aug 2000 21:16:56 +0200 Reply-To: Francis.Dupont@ENST-BRETAGNE.FR Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] Implementation Issues re MobileIP and IPSec X-To: Stefan Schmid X-cc: Greg O'Shea To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Tue, 01 Aug 2000 09:53:21 BST. In your previous mail you wrote: > => this point was signaled by me and others... The final document > is supposed to fix it. So, the care-of-address is used as the IP source address for the authentication calculations. Correct? => we need both the home and the care-of address, one will be in the source address field, the other in the home address option. But we have to wait for the final document to know the exact order (ie. swapped (me) or not (Microsoft)). > => I disagree because you put more in "Binding Update option processing" > than it should be. In fact when you decode the BU you don't know if there > is an AH after or (the argument :-) a HA option. Now, I am confused ... Since we propose to put the BU in the 2nd Destination Options header, this problem wouldn't occur. => you can put the BU in the first/only DO header before the HA: you have replaced "MUST include" by "MUST be before" which is far stronger... (*) The only constraint in the order is there MUST be a DO header with a HA option before the AH header, you can put the BU where you'd like (before or after, in the same header than the HA or in an other one. In my code I put it in the same header than the HA in the order which gives the smallest length). By the time we get to the BU message, we have already processed the HA option (which MUST be in the 1st Destination Options header) and the AH (which MUST occur before the 2nd Destination Options header). => the second MUST is yours and obviously is incorrect because I can implement this with only one DO header... > I execute the BU only > when I see the upper layer header, the processing itself is restricted > to length/alignement checks. So, what would you say are the advantages of putting the BU in the 1st Destination Options header? => simpler, smaller, ... Or is it just convenience since only one of the Destination Options headers must be processed then? => of course it is convenience. But if you have an ESP header too our firewall implementors want to have all DO headers in clear, ie before the ESP. Then they convince me to keep the way I built the DO header before IPsec introduction and just add some code which: - puts the AH after the DO header - supports DO headers (and DO themselves) in *any* order on input Could anybody working on the "final document" respond to this question? => I'll try to catch Dave Johnson who is here (IETF, mobileip 1st session). > 2. It should clarify which address, the mobile node's Home Address or > care-of-address, must be used for the SA/SP lookup. > > => this is clearly specified in the I-D (home address must be used). Could you please point out the respective section? => section 10.2 (inbound processing must be symmetrical). Beware that IKE rules are a bit hairy (but less than IKE itself :-). Regards Francis.Dupont@enst-bretagne.fr, PS *: to put the HA option after the BU option is a favorite in the UNH mobile IPv6 test suite... From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Aug 1 16:11:36 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00016 for ; Tue, 1 Aug 2000 16:11:35 -0400 (EDT) Received: from standards (47.234.32.16:1839) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84076@standards.nortelnetworks.com>; Tue, 1 Aug 2000 15:59:24 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2701 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Aug 2000 15:59:24 -0400 Received: from oulu.fi (ousrvr.oulu.fi) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84075@standards.nortelnetworks.com>; Tue, 1 Aug 2000 15:49:23 -0400 Received: from ee.oulu.fi (ees2.oulu.fi [130.231.61.23]) by oulu.fi (8.8.5/8.8.5) with ESMTP id XAA19194 for ; Tue, 1 Aug 2000 23:00:38 +0300 (EET DST) Received: from stekt56 (stekt56 [130.231.60.96]) by ee.oulu.fi (8.9.3/8.9.3) with ESMTP id XAA28693 for ; Tue, 1 Aug 2000 23:00:37 +0300 (EET DST) X-Sender: over@stekt56 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Tue, 1 Aug 2000 23:00:37 +0300 Reply-To: Mika Ylianttila Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Mika Ylianttila Subject: [MOBILE-IP] I-D ACTION: draft-ylianttila-isl-prot-req-00.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM FYI: as a part of Spatial Location activities within IETF, a draft http://search.ietf.org/internet-drafts/draft-ylianttila-isl-prot-req-00.txt has been presented to address how to possible use (geo)location information to enable MH to prepare for HO. As the main author of this draft I would like to make clear that this is a very early draft and that the work is in progress. Furthermore, I would like to be involved in any handoff related activities within Mobile IP (or CRAPS if that that will be realized) in the future. I look forward for any comments, and will try to adjust the possible second version of my draft for Mobile IP/CRAPS framework. INTERNET-DRAFT M. Ylianttila Internet Engineering Task Force Juha-Pekka Makela Issued: 11 April 2000 University of Oulu, Finland K. Pahlavan Worcester Polytechnic Institute, USA Considerations on IP Spatial Location Protocol Requirements Abstract This document addresses those requirements for IP spatial location protocol that emerges from the situation where mobile hosts (MH) use location information in the inter-domain mobility management. While IP spatial location protocol has many other usage cases, this document focuses on the requirements for mobile IP device that needs to know the whereabouts of IP subnetwork to be visited in order to prepare for handoff. Three inter-technology handoff (ITHO) scenarios and the related problems are presented, and the requirements for the system architecture, terminal and IP spatial location protocol are outlined. -- Mika Ylianttila M.Sc., Research Scientist Centre for Wireless Communications PL 4500, Tutkijantie 2 E, FIN-90014 University of Oulu, Finland From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Aug 1 17:09:09 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06781 for ; Tue, 1 Aug 2000 17:09:08 -0400 (EDT) Received: from standards (47.234.32.16:4414) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB840CB@standards.nortelnetworks.com>; Tue, 1 Aug 2000 16:57:24 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2811 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Aug 2000 16:57:24 -0400 Received: from news.comp.lancs.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB840CA@standards.nortelnetworks.com>; Tue, 1 Aug 2000 16:57:24 -0400 Received: from SPOCK (egcsky000002.lancs.ac.uk [148.88.155.83]) by news.comp.lancs.ac.uk (8.10.2/8.10.2) with SMTP id e71L94h23822; Tue, 1 Aug 2000 22:09:05 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Message-ID: Date: Tue, 1 Aug 2000 22:06:48 +0100 Reply-To: Stefan Schmid Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Stefan Schmid Subject: Re: [MOBILE-IP] Implementation Issues re MobileIP and IPSec X-To: Francis.Dupont@enst-bretagne.fr X-cc: Greg O'Shea To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200008011916.VAA83137@givry.rennes.enst-bretagne.fr> Content-Transfer-Encoding: 7bit Francis, > > => I disagree because you put more in "Binding Update option > processing" > > than it should be. In fact when you decode the BU you don't > know if there > > is an AH after or (the argument :-) a HA option. > > Now, I am confused ... Since we propose to put the BU in the 2nd > Destination Options header, this problem wouldn't occur. > > => you can put the BU in the first/only DO header before the HA: you have > replaced "MUST include" by "MUST be before" which is far stronger... (*) Sorry the confusion ... I just tried to point out that the specification is not entirely clear re AH processing. It states quite clear though, that the Home Address option must be in the 1st Destionation Options header (if included) and that the BU can be either in the 1st or 2nd Destination Options header. > By the time we get > to the BU message, we have already processed the HA option > (which MUST be in > the 1st Destination Options header) and the AH (which MUST > occur before the > 2nd Destination Options header). > > => the second MUST is yours and obviously is incorrect because I > can implement > this with only one DO header... Nope ... but I guess you got me wrong here. The second MUST is defined by the extension header order specified in RFC 2460 (IPv6 specification). It does not imply that a 2nd Destination Option header is required. It simply says that iff a 2nd DO header is present, it must occur after the Authentication Header. > > I execute the BU only > > when I see the upper layer header, the processing itself is > restricted > > to length/alignement checks. > > So, what would you say are the advantages of putting the BU > in the 1st > Destination Options header? > > => simpler, smaller, ... True. > => of course it is convenience. But if you have an ESP header too > our firewall implementors want to have all DO headers in clear, ie > before the ESP. Then they convince me to keep the way I built the DO Ei? Not sure if I understand you right here, because the 2nd DO header cleary must succeed the IPsec headers according to the IPv6 specification. I understand the benefits of clear (unencrypted) BU messages though. > > 2. It should clarify which address, the mobile node's > Home Address or > > care-of-address, must be used for the SA/SP lookup. > > > > => this is clearly specified in the I-D (home address must be used). > > Could you please point out the respective section? > > => section 10.2 (inbound processing must be symmetrical). Okay, I guess you refere to the following sentence ... "[...] it is assumed that IPsec is being used in transport mode [13] and that the mobile node is using its home address as the source for the packet[...]" Although it is quite clear, I still believe the specification could be improved by adding a clear statement (regarding which address to use for SA/SP lookup and where to use the HA/COA for the authentication calculation) to section 4.4 and/or 13, since both specifically discuss IPsec issues/requirements. Regards, - Stefan --- Stefan Schmid (Dipl.-Inf.) Distributed Multimedia Research Group Research Assistant Computing Department Phone: +44 (0)7989 400707 Lancaster University Fax: +44 (0)1524 593608 Lancaster LA1 4YR Email: mailto:sschmid@comp.lancs.ac.uk U.K. WWW: http://www.landmarc.net/people/stefan.htm From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Aug 2 05:43:18 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26139 for ; Wed, 2 Aug 2000 05:43:18 -0400 (EDT) Received: from standards (47.234.32.16:3943) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8428D@standards.nortelnetworks.com>; Wed, 2 Aug 2000 5:31:24 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3362 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Aug 2000 05:31:23 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84284@standards.nortelnetworks.com>; Wed, 2 Aug 2000 5:21:22 -0400 Received: from hy.hyn.co.kr ([210.92.243.76]) by hosaka.smallworks.com (8.9.1/8.9.1) with SMTP id EAA26617 for ; Wed, 2 Aug 2000 04:32:36 -0500 (CDT) Received: from zipp (unverified [209.206.56.19]) by hy.hyn.co.kr (EMWAC SMTPRS 0.83) with SMTP id ; Mon, 31 Jul 2000 11:50:23 +0900 Message-ID: Date: Mon, 31 Jul 2000 11:50:23 +0900 Reply-To: optin705@2BMAIL.CO.UK Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: optin705@2BMAIL.CO.UK Subject: [MOBILE-IP] How to make $100 - $500 per hour or two To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM From: Michelle Smith - publisher of the "Work From Home Opportunities" Newsletter Saturday, 8:15 p.m. Hello, If you're interested in earning $100 - $500 Per Hour or Two, Then I want to share something with you... Now you can make $100 - $500 Per Hour or Two! Imagine you come home from a hard day's work (exhausted..), You immediately go straight to bed. You get undressed, lay down, turn off the lights, and snuggle up face-down on the pillow. A few moments later, you feel uncomfortable and stressed out so you lie on your back. When you look up at the ceiling, it's as if the ceiling has been removed! You see exactly what you would see if outside stargazing! A stunning, accurate 3-dimensional re-creation of the starry night sky, including constellations such as the Big Dipper, Pegasus and the Milky Way galaxy, ...and even shooting stars! You can't see it during the day. The ceiling looks normal. But at night, when the lights are off, you see what looks like the sky outside! It's so relaxing and romantic. And educational! And talk about stress-relief! The moment you look at it, it'll melt your tension away faster than a great massage! Now how many people do you think would LOVE seeing this when they look up in their beds at night? "It's like you're sleeping under the stars!" Ok, I know you want to know How You Make Money. Here's how. You can put that awesome "convertible ceiling" in ANYONE'S bedroom with a product cost to you of.. Guess how much.. Only ONE to TWO Dollars! And you offer this masterpiece for $100 - $500! Talk about *nice* profits! And it only takes you an hour or two! Here's an important point: These profits are similar to the profits of selling Information: the material costs next to nothing, but the customer really VALUES the END RESULT. So you can charge more (a LOT more). "Who'd want this?" Anyone with a bedroom ceiling (or any ceiling), as well as homes, hotels, etc. Who do you know that has a bedroom ceiling? Whew! The official money-making opportunity of the Millenium! (Well... I think it should be!) |;-) Anyway, I know you want more information to make a decision, so ... To receive more FREE information on How To Make $100 - $500 Per Hour or Two, Simply Click On The Email Link Below and Send Back The Following: Mailto:starbiz152@newmail.net Name: E-Mail: Phone: Street: City: State: ZIP or Postal Code: Country (available INTERNATIONALLY): Mailto:starbiz152@newmail.net And you'll be sent the full details on how to make $100 - $500 per hour or two, as well as pictures of these murals so you can see for yourself how breathtaking they are! Best regards, Michelle Smith P.S. We'll also send you a free Opportunity E-zine with more interesting Money-Making Opportunities like this one, and important info. for the home-based entrepreneur! P.P.S. Also, even though 99% of people don't know about this opportunity, that won't be the case forever, so hurry up and reply to make sure you get to lock down YOUR city! To unsubscribe mailto:unsubscribe730@newmail.net From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Aug 2 10:50:54 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08310 for ; Wed, 2 Aug 2000 10:50:54 -0400 (EDT) Received: from standards (47.234.32.16:4159) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84418@standards.nortelnetworks.com>; Wed, 2 Aug 2000 10:38:58 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3886 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Aug 2000 10:38:58 -0400 Received: from oulu.fi (ousrvr.oulu.fi) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84417@standards.nortelnetworks.com>; Wed, 2 Aug 2000 10:38:57 -0400 Received: from ee.oulu.fi (ees2.oulu.fi [130.231.61.23]) by oulu.fi (8.8.5/8.8.5) with ESMTP id RAA09626 for ; Wed, 2 Aug 2000 17:50:13 +0300 (EET DST) Received: from stekt56 (stekt56 [130.231.60.96]) by ee.oulu.fi (8.9.3/8.9.3) with ESMTP id RAA24006 for ; Wed, 2 Aug 2000 17:50:12 +0300 (EET DST) X-Sender: over@stekt56 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Wed, 2 Aug 2000 17:50:12 +0300 Reply-To: Mika Ylianttila Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Mika Ylianttila Subject: [MOBILE-IP] Handoff triggering To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: First a kind note for the majordomo admin: please try to preclude spams, as well as out of office replys. It should be pretty easy to do, e.g. taboo_headers << END /$/i /"OUT OF OFFICE"/i END Then for the actual topic. As it is possible to use net in real-time during the WG sessions, I would assume that e.g. CRAPS and handoff issues would be relevant topics for immeadent discussions. While it is still unclear if there is enough work items (or specific enough) for a new WG, I am still very much interested in this kind of an effort within IETF. There are many aspect of handoff that are not yet currently addressed with the use of Mobile IP as inter-technology handoff protocol. One is the triggering part. It may be debatable if the handoff algorithm aspects for triggering is an IETF topic, but I would like to see discussion about it. I have presented some aspects for it in my draft http://search.ietf.org/internet-drafts/draft-ylianttila-isl-prot-req-00.txt. Because it was originally made to Spatial Location BOF it contains a number of irrelevant stuff for this WG, but you should find the relevant parts pretty easily. Waiting for the discussion (is there some other list, I have not seen much discussion on this list lately?) ;) -- Mika Ylianttila M.Sc., Research Scientist Centre for Wireless Communications PL 4500, Tutkijantie 2 E, FIN-90014 University of Oulu, Finland From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Aug 2 12:26:32 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13500 for ; Wed, 2 Aug 2000 12:26:31 -0400 (EDT) Received: from standards (47.234.32.16:4159) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB844F2@standards.nortelnetworks.com>; Wed, 2 Aug 2000 12:14:34 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4148 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Aug 2000 12:14:34 -0400 Received: from hotmail.com (f101.law3.hotmail.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB844D3@standards.nortelnetworks.com>; Wed, 2 Aug 2000 12:04:34 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 2 Aug 2000 09:15:51 -0700 Received: from 129.116.78.131 by lw3fd.law3.hotmail.msn.com with HTTP; Wed, 02 Aug 2000 GMT X-Originating-IP: [129.116.78.131] Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 02 Aug 2000 16:15:51.0075 (UTC) FILETIME=[ECFCC730:01BFFC9C] Message-ID: Date: Wed, 2 Aug 2000 11:15:51 CDT Reply-To: Seong-Kyu Song Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Seong-Kyu Song Subject: [MOBILE-IP] Q: dynamic home agent resolution To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello! Would you explain how a mobile node can find his home agent address if it doesn't know it? Let me first check if my understanding is correct. The MN broadcasts a Registration Request message to his own home network. Each HA in his home network will always reject that (broadcasted) request, but by the reject message the MN comes to know one of HA addresses. After the reject message, the MN tries again registration with the HA address. The reason each HA rejects and doesn't process the broadcasted request is that it could lead to duplicated bindings on some HAs on the home network. Is my understanding correct? Is there any other ways suggested for dynamic HA resolution? Thank you. Seong-Kyu Song ------------------------------------------ What is now proved was once only imagin'd. -- William Blake ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Aug 2 13:15:02 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29695 for ; Wed, 2 Aug 2000 13:15:02 -0400 (EDT) Received: from standards (47.234.32.16:1887) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84584@standards.nortelnetworks.com>; Wed, 2 Aug 2000 13:03:07 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4378 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Aug 2000 13:03:06 -0400 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84583@standards.nortelnetworks.com>; Wed, 2 Aug 2000 13:03:06 -0400 Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e72HEF655139; Wed, 2 Aug 2000 19:14:16 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA20682; Wed, 2 Aug 2000 19:14:15 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id TAA86556; Wed, 2 Aug 2000 19:15:29 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-ID: <200008021715.TAA86556@givry.rennes.enst-bretagne.fr> Date: Wed, 2 Aug 2000 19:15:29 +0200 Reply-To: Francis.Dupont@ENST-BRETAGNE.FR Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] Implementation Issues re MobileIP and IPSec X-To: Stefan Schmid X-cc: Greg O'Shea To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Tue, 01 Aug 2000 22:06:48 BST. In your previous mail you wrote: Nope ... but I guess you got me wrong here. The second MUST is defined by the extension header order specified in RFC 2460 (IPv6 specification). It does not imply that a 2nd Destination Option header is required. It simply says that iff a 2nd DO header is present, it must occur after the Authentication Header. => the word in RFC 2460 is "recommended" ie. a SHOULD and I think this recommendation is wrong because no already defined destination option is very useful when it is after an ESP header, ie. if/when the RFC 2460 will be revisited I'll ask to change the recommended order (put destination options before IPsec headers, AH, ESP and IPCOMP). My argument is the non-mobility destination option, tunnel encapsulation limit, must be in clear text... Regards Francis.Dupont@enst-bretagne.fr PS: I can't get an immediate answer from Dave Johnson about AH/HA issue but he recognized he had to fix it... From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Aug 3 02:30:16 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04162 for ; Thu, 3 Aug 2000 02:30:16 -0400 (EDT) Received: from standards (47.234.32.16:3759) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8484C@standards.nortelnetworks.com>; Thu, 3 Aug 2000 2:18:05 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5279 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Aug 2000 02:18:05 -0400 Received: from ns0.utdallas.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84848@standards.nortelnetworks.com>; Thu, 3 Aug 2000 2:08:05 -0400 Received: from apache.utdallas.edu (apache.utdallas.edu [129.110.16.9]) by ns0.utdallas.edu (Postfix) with ESMTP id 409471A0129 for ; Thu, 3 Aug 2000 01:18:46 -0500 (CDT) Received: (from jcobb@localhost) by apache.utdallas.edu (8.9.1/8.9.1) id BAA16500 for mobile-ip@standards.nortelnetworks.com; Thu, 3 Aug 2000 01:19:23 -0500 (CDT) Message-ID: <200008030619.BAA16500@apache.utdallas.edu> Date: Thu, 3 Aug 2000 01:19:23 -0500 Reply-To: jcobb@UTDALLAS.EDU Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: jcobb@UTDALLAS.EDU Subject: [MOBILE-IP] Deadline approaching, Autonomous Decentralized Systems Symposium CFP To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM * please forgive us if you receive multiple copies of this message * feel free to distribute to your colleagues. http://isads.utdallas.edu ISADS 2001 CALL FOR PAPERS The Fifth International Symposium on Autonomous Decentralized Systems with an emphasis on electronic commerce Monday March 26 - Wednesday March 28, 2001 Dallas, Texas, USA Paper deadline: August 15, 2000 Sponsored by: IEEE Computer Society Information Processing Society of Japan The Society of Instrument and Control Engineers of Japan The Institute of Electronics, Infor. and Communication Engineers, Japan In Cooperation with: International Federation for Information Processing International Federation of Automatic Control OMG TINA-C Manufacturing Science and Technology Center, Japan Scope: Driven by the continuous growth in the power, intelligence and openness of computer, communication and control technologies, possibilities and opportunities for realizing highly efficient and dependable business and control systems have been steadily increasing. Dynamically changing social and economic situations demand next-generation systems based on emerging technologies and applications. Such systems are expected to have the characteristics of living systems composed of largely autonomous and decentralized components. Such systems are called Autonomous Decentralized Systems (ADS). After the successful first, second, third, and fourth International Symposium on Autonomous Decentralized Systems (ISADS) held in 1993 in Japan, in 1995 in the USA , in 1997 in Germany, and in 1999 in Japan, the fifth ISADS will be held in Dallas, Texas, USA during March 26-28, 2001. While ISADS 2001 will primarily focus on advancements and innovation in ADS concept, technologies, and applications related to the increasingly important topic of *Electronic Commerce*, other themes such as telecommunications and heterogeneous system and application integration will also be included. The ISADS 2001 committee invites papers and panel proposals on the topics of the symposium that will foster interactions among researchers and practitioners in computer, communication, management, control as applied to electronic commerce and other related fields from academia, industry, and government. The scope of discussions on ADS shall include, but not be limited to: * Computer and communication architectures / intelligent network /Internet; * Heterogeneous distributed information / control systems; * Mobile agent /computer-supported cooperative works; * Distributed software development and maintenance; * Assurance, fault tolerance and on-line expansion; * Object management architecture /design pattern / application frameworks; * Emergent control and robotic systems; * Novel applications: electronic commerce, telecommunications, information service systems, manufacturing systems, real-time event management, office automation, traffic and transportation control, logistics systems. Plant tour is scheduled on March 29, 2001. Delegates are encour- aged to participate. Information for Authors Papers should describe original work (not submitted or published elsewhere) and be 20 double-spaced pages (5,000 words) or less in length. Papers should include: title, authors, affiliations, 150-word abstract and list of keywords. Identify the author responsible for correspondence, including the author's name, position, mailing address, telephone and fax numbers, and email address. One of the authors of each accepted paper must present the paper at ISADS 2001. Information for Panel Organizers Panel proposals should include: title, organizer's affiliations, position, mailing address, telephone and fax numbers, email address, and 150-word statement on the scope, proposed chair and panelists. Submission Address Authors and panel organizers are requested to submit their manuscripts electrically in the Microsoft WORD document file format, the PDF format, or the Postscript format, and also email the abstract and the full addresses of the author(s) to the following address: thura@mitre.org Note The program committee of ISADS2001 highly encourage electronic submissions. Otherwise, papers should be sent to the program chair: Dr. Bhavani Thuraisingham Mail Stop A270 The MITRE Corporation 202 Burlington Road Bedford, MA 01730 Phone: 781-271-8873 Fax: 781-271-8752 Email: thura@mitre.org General Information For general information, see our World-Wide Web Page at: http://isads.utdallas.edu The proceedings of the symposium will be published by IEEE Computer Society Press. Important Deadlines August 15, 2000: All papers and panel proposals are due November 15, 2000: Authors and panel organizers notified of acceptance. December 15, 2000: Camera-ready copies of accepted papers and panelists' position papers General Chair William Osborne, U. of Texas, Dallas, USA Program Committee Chair: Bhavani Thuraisingham, The MITRE Corp., USA Co-Chair: Makoto Imase, NTT Labs, Japan Co-Chair: Linda Strick, GMD Fokus, Berlin, Germany Co-Chair: Jeffrey Tsai, U. of Illinois, Chicago, USA Members G. Agha, U. of IL, Urbana, USA R. Arai, U. of Tokyo, Japan D. Bae, KAIST, Korea F. Bastani, U. of TX, Dallas, USA E. Bertino, U. of Milano, Italy M. Ceruti, SPAWAR, USA I. Chen, Virginia, Tech, USA Y. Chen, U. of the Witwatersrand, South Africa R. Chow, U. of FL, USA J. Chung, IBM T.J. Watson Research Center, USA P. Chuang, Tamkang U., Taiwan P. Ciancarini, U. of Bologna. B. Cukic, West Virginia U., USA K. Eckert, GMD FOKUS Germany S. Eisenbach, Imperial College, UK D. Ferrari, U. of Catoloca, Italy M. Fisher, Manchester Metropolitan U., UK M. Fujita, Sony, Japan A. Fukuda, Nara Inst. of Science and Technology, Japan V. Garg, Univ. of TX, Austin, USA S. Ghosh, Arizona State U., USA A. Ghafoor, Purdue U., USA A. Ghose, U. of Wollongong, Australia M. Gien, Sun, France V. Gobel, U. of Oslo, Norway T. Higashino Osaka U., Japan D. Hislop, ARO, USA I. Iida, Fujitsu, Japan Y. Ishiguro, NEC, Japan K. Ito, TITECH, Japan Y. Kakuda, Hiroshima City U., Japan K. Kim, U.C. Irvine, USA H. Kopetz, TU Wien, Austria J. Kramer, Imperial College, UK L. LeLann, INRIA, France C. Liu, Chung Yuan Christian U., Taiwan M. Lyu, The Chinese U. of Hong Kong, Hong Kong Y. Masunaga, Ochanomizu U., Japan W. Meng , State U. of New York at Binghamton, USA R. Montanari, U. of Bologna, Italy W. Ng, Nanyang Technological U., Singapore A. Prakash, U. of Michigan, USA J. Putman, MITRE, USA Q. Qingquan, Southwest Jiatong U., China N. Raynal, INRIA, France W. Ruh, Concept-V, USA D. Serpanos, Inst. of Comuter Science, Technology-Hellas, Greece S. Shekhar, U. of MN, Mpls, USA L. Simoncini, CNUCE-CNR, Italy R. Stroud, U. of New Castle, UK V. Subrahmanian, U. of MD, College Park, USA K. Tsuchiya, Kyoto Uv, Japan B. Wah, U. of IL, Urbana, USA Y. Wakahara, U. of Tokyo, Japan F. Wang, National Chao Tung U., Taiwan M. Wooldridge, U. of Liverpool, UK H. Yokota, TITECH, Japan M. Yano, Tohoku U., Japan S. Yongqiang, Shanghai Jiao Tong U, China P. Yu, IBM T.J. Watson Research Center S. Zubairy, Quaid-e-Azam U., Pakistan Steering Committee Chair: Stephen S. Yau, Arizona State U., USA Hiroshi Kuwahara, Hitachi, Japan Kinji Mori, Tokyo Inst. of Technology, Japan Radu Popescu-Zeletin, GMD, Germany Publicity Chair Jorge Cobb, U. of Texas, Dallas, USA From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Aug 3 02:51:53 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13387 for ; Thu, 3 Aug 2000 02:51:52 -0400 (EDT) Received: from standards (47.234.32.16:3759) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84892@standards.nortelnetworks.com>; Thu, 3 Aug 2000 2:40:01 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5376 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Aug 2000 02:40:01 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8488F@standards.nortelnetworks.com>; Thu, 3 Aug 2000 2:30:01 -0400 Received: from yolanda.byzantium.com ([195.92.107.66]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id BAA02508 for ; Thu, 3 Aug 2000 01:41:19 -0500 (CDT) Received: from george.byzantium.com (george.byzantium.com [62.232.11.90]) by yolanda.byzantium.com (8.9.3+Sun/8.9.3) with ESMTP id HAA14889; Thu, 3 Aug 2000 07:36:49 +0100 (BST) Received: from 789thn7896tb7 (1Cust83.tnt1.springfield.il.da.uu.net [63.27.174.83]) by george.byzantium.com (8.9.1b+Sun/8.9.3) with SMTP id HAA09140; Thu, 3 Aug 2000 07:34:18 +0100 (BST) Message-ID: <200008031140VAA30493@ftghyuji8l.byzantium.com> Date: Thu, 3 Aug 2000 07:34:18 +0100 Reply-To: Monica Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: Authenticated sender is From: Monica Subject: [MOBILE-IP] Know Your Rights! To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM INTERNATIONAL DRIVER'S LICENSE Need a new driver's license? Too many points or other trouble? Want a license that can never be suspended or revoked? Want ID for nightclubs or hotel check-in? Avoid tickets, fines, and mandatory driver's education. Protect your privacy, and hide your identity. The United Nations gave you the privilege to drive freely throughout the world! (Convention on International Road Traffic of September 19, 1949 & World Court Decision, The Hague, Netherlands, January 21, 1958) Take advantage of your rights. Order a valid International Driver's License that can never be suspended or revoked. Confidentiality assured. CALL NOW!!! 1-937-586-9313 rem-- techstar54_lop@inorbit.com 736289127542978276766 (û ni From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Aug 3 13:06:11 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24488 for ; Thu, 3 Aug 2000 13:06:10 -0400 (EDT) Received: from standards (47.234.32.16:2167) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84A80@standards.nortelnetworks.com>; Thu, 3 Aug 2000 12:54:10 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6009 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Aug 2000 12:54:09 -0400 Received: from httpprxy.aac.va.gov (63.160.3.2:45264) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84A7F@standards.nortelnetworks.com>; Thu, 3 Aug 2000 12:54:08 -0400 Received: from irm_aac_xchg_01.aac.va.gov (msexch-gw.aac.va.gov [152.125.188.21]) by httpprxy.aac.va.gov (8.8.8+Sun/8.8.8) with ESMTP id LAA03342 for ; Thu, 3 Aug 2000 11:56:06 -0500 (CDT) Received: by IRM_AAC_XCHG_01 with Internet Mail Service (5.5.2650.21) id <38RSC4R9>; Thu, 3 Aug 2000 12:05:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <2A5485D1C9C7D311816F0000F805ADB769700A@vhapugexc1.med.va.gov> Date: Thu, 3 Aug 2000 12:06:44 -0500 Reply-To: "Kay, Rodney" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Kay, Rodney" Subject: Re: [MOBILE-IP] Handoff triggering X-To: Mika Ylianttila To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Have been going through your draft document and find it very interesting, but have a general question: You talk of the MT scenario as being a combination of the MI/MO scenarios; but I wonder if it wouldn't properly be a separate entity unto itself. Your example of a MH in a moving vehicle seems to make the argument that when terminal velocity exceeds X (pre-defined by better minds than mine) then the ITHO should be negated in favor of remaining with the GPN as opposed to swapping around various LPN's. Regards, Rodney H. Kay Department of Veteran's Affairs Puget Sound Health Care System Systems Manager Seattle, Washington -----Original Message----- From: Mika Ylianttila [mailto:over@EES2.OULU.FI] Sent: Wednesday, August 02, 2000 7:50 AM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: [MOBILE-IP] Handoff triggering First a kind note for the majordomo admin: please try to preclude spams, as well as out of office replys. It should be pretty easy to do, e.g. taboo_headers << END /$/i /"OUT OF OFFICE"/i END Then for the actual topic. As it is possible to use net in real-time during the WG sessions, I would assume that e.g. CRAPS and handoff issues would be relevant topics for immeadent discussions. While it is still unclear if there is enough work items (or specific enough) for a new WG, I am still very much interested in this kind of an effort within IETF. There are many aspect of handoff that are not yet currently addressed with the use of Mobile IP as inter-technology handoff protocol. One is the triggering part. It may be debatable if the handoff algorithm aspects for triggering is an IETF topic, but I would like to see discussion about it. I have presented some aspects for it in my draft http://search.ietf.org/internet-drafts/draft-ylianttila-isl-prot-req-00.txt. Because it was originally made to Spatial Location BOF it contains a number of irrelevant stuff for this WG, but you should find the relevant parts pretty easily. Waiting for the discussion (is there some other list, I have not seen much discussion on this list lately?) ;) -- Mika Ylianttila M.Sc., Research Scientist Centre for Wireless Communications PL 4500, Tutkijantie 2 E, FIN-90014 University of Oulu, Finland From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Aug 3 15:05:43 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02027 for ; Thu, 3 Aug 2000 15:05:43 -0400 (EDT) Received: from standards (47.234.32.16:4885) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84B2E@standards.nortelnetworks.com>; Thu, 3 Aug 2000 14:53:14 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6221 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Aug 2000 14:53:14 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84B21@standards.nortelnetworks.com>; Thu, 3 Aug 2000 14:43:13 -0400 Received: from mail.ee.gatech.edu (mail.ee.gatech.edu [130.207.230.10]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id NAA05859 for ; Thu, 3 Aug 2000 13:54:28 -0500 (CDT) Received: from kesha (kesha.ece.gatech.edu [199.77.145.131]) by mail.ee.gatech.edu (8.11.0/8.11.0) with ESMTP id e73IsR209134 for ; Thu, 3 Aug 2000 14:54:27 -0400 (EDT) X-Sender: kesha@mail.ee.gatech.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_245877423==_" Message-ID: <4.2.0.58.20000803145414.00ca29d0@mail.ee.gatech.edu> Date: Thu, 3 Aug 2000 14:54:38 -0400 Reply-To: Kesha Jackson Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Kesha Jackson Subject: [MOBILE-IP] IEEE JSAC: Call for Papers X-To: mobile-ip@smallworks.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --=====================_245877423==_ Content-Type: text/plain; charset="us-ascii"; format=flowed --=====================_245877423==_ Content-Type: application/msword; name="JSAC call for papers.doc" Content-Disposition: attachment; filename="JSAC call for papers.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAMQAAAAAAAAAA EAAAMwAAAAEAAAD+////AAAAADAAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAcQAJBAAACBK/AAAAAAAAEAAAAAAABAAAhA8AAA4AYmpianQrdCsAAAAAAAAAAAAAAAAAAAAA AAAJBBYALR4AABZBAQAWQQEAhAsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAF0AAAAAAJQBAAAAAAAAlAEAAJQB AAAAAAAAlAEAAAAAAACUAQAAAAAAAJQBAAAAAAAAlAEAABQAAAAAAAAAAAAAAKgBAAAAAAAAqAEA AAAAAACoAQAAAAAAAKgBAAAAAAAAqAEAAAwAAAC0AQAAHAAAAKgBAAAAAAAAmQMAALYAAADcAQAA KAAAAAQCAAAAAAAABAIAAAAAAAAEAgAAAAAAAAQCAAAAAAAABAIAAAAAAAAEAgAAAAAAAAQCAAAA AAAAXgMAAAIAAABgAwAAAAAAAGADAAAAAAAAYAMAAAAAAABgAwAAAAAAAGADAAAAAAAAYAMAACQA AABPBAAA9AEAAEMGAAD8AAAAhAMAABUAAAAAAAAAAAAAAAAAAAAAAAAAlAEAAAAAAAAEAgAAAAAA AAAAAAAAAAAAAAAAAAAAAAAEAgAAAAAAAAQCAAAAAAAABAIAAAAAAAAEAgAAAAAAAIQDAAAAAAAA tAIAAAAAAACUAQAAAAAAAJQBAAAAAAAABAIAAAAAAAAAAAAAAAAAAAQCAAAAAAAA3AEAAAAAAAC0 AgAAAAAAALQCAAAAAAAAtAIAAAAAAAAEAgAAdgAAAJQBAAAAAAAABAIAAAAAAACUAQAAAAAAAAQC AAAAAAAAXgMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAqAEAAAAAAACoAQAAAAAAAJQBAAAAAAAAlAEA AAAAAACUAQAAAAAAAJQBAAAAAAAABAIAAAAAAABeAwAAAAAAALQCAACqAAAAtAIAAAAAAAAAAAAA AAAAAF4DAAAAAAAAlAEAAAAAAACUAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXgMAAAAAAAAEAgAAAAAAANABAAAMAAAAkMM2qXb9 vwGoAQAAAAAAAKgBAAAAAAAAegIAADoAAABeAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQXBv bG9naWVzIGZvciBtdWx0aXBsZSBjb3BpZXMuLi4uDQ0LQ2FsbCBmb3IgUGFwZXJzCQkJCQkJCQkJ CVBhZ2UgMSBvZiAyDQ0NDUNBTEwgRk9SIFBBUEVSUw1NT0JJTElUWSBBTkQgUkVTT1VSQ0UgTUFO QUdFTUVOVCBJTiBORVhUIEdFTkVSQVRJT04gV0lSRUxFU1MgU1lTVEVNUw0NSUVFRSBKb3VybmFs IG9uIFNlbGVjdGVkIEFyZWFzIGluIENvbW11bmljYXRpb25zDQ1UaGUgdGVjaG5vbG9neSBhbmQg YnVzaW5lc3Mgb2YgY2VsbHVsYXIgY29tbXVuaWNhdGlvbnMgc3lzdGVtcyBoYXZlIG1hZGUgc3Bl Y3RhY3VsYXIgcHJvZ3Jlc3Mgc2luY2UgdGhlIGZpcnN0IHN5c3RlbXMgd2VyZSBpbnRyb2R1Y2Vk IGZpZnRlZW4geWVhcnMgYWdvLiBHbG9iYWwgcm9hbWluZyBpcyBhIHJlYWxpdHkgaW4gDWN1cnJl bnQgY2VsbHVsYXIgc3lzdGVtcyB0aGF0IGRlbGl2ZXIgbG93IGJhbmR3aWR0aCBzZXJ2aWNlcywg c3VjaCBhcyB0ZWxlcGhvbmUgY2FsbHMgYW5kIHNob3J0IG1lc3NhZ2VzLiBIb3dldmVyLCBmdXR1 cmUgd2lyZWxlc3Mgc3lzdGVtcyBhcmUgZW52aXNpb25lZCB0byBwcm92aWRlIGhpZ2ggY2FwYWNp dHksIHViaXF1aXRvdXMgd2lyZWxlc3MgY29tbXVuaWNhdGlvbiBpbiBhIHZhcmlldHkgb2YgZW52 aXJvbm1lbnRzLCBpbmNsdWRpbmcgaW5kb29yIG9mZmljZSwgcGVkZXN0cmlhbiwgdmVoaWNsZSwg YW5kIHNhdGVsbGl0ZS4gRnV0dXJlIHN5c3RlbXMgd2lsbCBhbHNvIGluY2x1ZGUgYSB3aWRlIHZh cmlldHkgb2YgYXBwbGljYXRpb25zIHdoaWNoIHdpbGwgcmVzdWx0IGluIGRpdmVyc2UgdHJhZmZp YyBjbGFzc2VzIGJlaW5nIHN1cHBvcnRlZCBhbmQgY2FycmllZCBvdmVyIHdpcmVsZXNzIHN5c3Rl bXMuIFdpcmVsZXNzIG5ldHdvcmtzIG11c3QgYmUgbW9yZSByb2J1c3QgYW5kIGRpdmVyc2UgdGhh biB0b2RheSdzIHNlY29uZC1nZW5lcmF0aW9uIGNlbGx1bGFyIG5ldHdvcmtzIHRvIHN1cHBvcnQg dGhlIG5ldyByYW5nZSBvZiBzZXJ2aWNlcywgcmVzb3VyY2UgZGVtYW5kcywgYW5kIHJvYW1pbmcg Y2FwYWJpbGl0aWVzIG9mIHRoZSBmdXR1cmUgd2lyZWxlc3MgY3VzdG9tZXIuIFRoaXMgc3BlY2lh bCBpc3N1ZSBmb2N1c2VzIG9uIHRoZSBuZXcgcmVzZWFyY2ggY29udHJpYnV0aW9ucyBpbiB0aGUg YXJlYSBvZiBtb2JpbGl0eSBhbmQgcmVzb3VyY2UgbWFuYWdlbWVudCBmb3IgZnV0dXJlIHdpcmVs ZXNzIHN5c3RlbXMuIFdlIHNvbGljaXQgYSB2YXJpZXR5IG9mIHBhcGVycyB3aXRoIGlubm92YXRp dmUgc29sdXRpb25zIGZvciBtb2JpbGl0eSBhbmQgcmVzb3VyY2UgbWFuYWdlbWVudCBpc3N1ZXMg aW5jbHVkaW5nLCBidXQgbm90IGxpbWl0ZWQgdG86DQ0qIFBDUyBTeXN0ZW1zIA0qIE1vYmlsZSBJ UCANKiBXaXJlbGVzcyBMb2NhbCBBcmVhIE5ldHdvcmtzIA0qIEFkIEhvYyBOZXR3b3JrcyANKiBI eWJyaWQgTmV0d29ya3MgKFRlcnJlc3RyaWFsLVNhdGVsbGl0ZSkgDSogNEcgV2lyZWxlc3MgU3lz dGVtcyANKiBIaWVyYXJjaGljYWwgYW5kIE1hY3JvZGl2ZXJzaXR5IEFyY2hpdGVjdHVyZXMgDSog V2lyZWxlc3MgQVRNIA0qIFdpcmVsZXNzIExvY2FsIExvb3AgDSogU2F0ZWxsaXRlIE5ldHdvcmtz IA0qIDNHIChJTVQyMDAwLCBVTVRTKSBXaXJlbGVzcyBTeXN0ZW1zCw1NYW51c2NyaXB0IFN1Ym1p c3Npb24gRGF0ZTogRGVjZW1iZXIgMjAsIDIwMDAgDUFjY2VwdGFuY2UgTm90aWZpY2F0aW9uOglN YXkgMTUsIDIwMDEgDUZpbmFsIE1hbnVzY3JpcHQgRHVlOglKdWx5IDEsIDIwMDEgDVB1YmxpY2F0 aW9uIERhdGU6CQk0dGggUXVhcnRlciBvZiAyMDAxDQ1QbGVhc2Ugc3VibWl0IE9OTFkgT04tTElO RSBWRVJTSU9OIChQb3N0U2NyaXB0IG9yIFBERiBvciBET0MpIG9mIHRoZSBjb21wbGV0ZSBtYW51 c2NyaXB0LCBub3QgdG8gZXhjZWVkIDI1IHBhZ2VzLCB0byB0aGUgRklSU1QgZ3Vlc3QgZWRpdG9y IGJ5IERFQ0VNQkVSIDIwLCAyMDAwLg0NQ2FsbCBmb3IgUGFwZXJzCQkJCQkJCQkJCVBhZ2UgMiBv ZiAyDQ0NDVByb2YuIElhbiBGLiBBa3lpbGRpeiANQnJvYWRiYW5kIGFuZCBXaXJlbGVzcyBOZXR3 b3JraW5nIExhYm9yYXRvcnkgDVNjaG9vbCBvZiBFbGVjdHJpY2FsIGFuZCBDb21wdXRlciBFbmdp bmVlcmluZyANR2VvcmdpYSBJbnN0aXR1dGUgb2YgVGVjaG5vbG9neSANQXRsYW50YSwgR0EgMzAz MzItMDI4MCANVGVsOiA0MDQtODk0LTUxNDEgDUZheDogNDA0LTg5NC03ODgzIA1FX01haWw6IBMg SFlQRVJMSU5LIG1haWx0bzppYW5AZWNlLmdhdGVjaC5lZHUgARRpYW5AZWNlLmdhdGVjaC5lZHUV DQ1Qcm9mLiBEYXZpZCBHb29kbWFuIA1EZXBhcnRtZW50IG9mIEVsZWN0cmljYWwgRW5naW5lZXJp bmcgDTUgTWV0cm9UZWNoIENlbnRlciANUG9seXRlY2huaWMgVW5pdmVyc2l0eSANQnJvb2tseW4s IE5ldyBZb3JrLCAxMTIwMSANVGVsOiA3MTgtMjYwLTMyMjEgDUZheDogNzE4LTI2MC0zOTA2IA1F X21haWw6IGRnb29kbWFuQHBvbHkuZWR1IA0NUHJvZi4gTGVvbmFyZCBLbGVpbnJvY2sgDUNvbXB1 dGVyIFNjaWVuY2UgRGVwYXJ0bWVudCANVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhIGF0IExvcyBB bmdlbGVzIChVQ0xBKSANNDczMiBCb2VsdGVyIEhhbGwgDUxvcyBBbmdlbGVzLCBDYWxpZm9ybmlh IDkwMDk1LTE1OTYgDVRlbDogMzEwLTgyNS0zODg2IA1GYXg6IDMxMC04MjUtMjI3MyANRV9NYWls OiBsa0Bjcy51Y2xhLmVkdSANLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0LDUZvciBmb3JtYXR0ZWQgQ2ZQLCBw bGVhc2Ugc2VlDRNIWVBFUkxJTksgImh0dHA6Ly93d3cuYXJncmVlbmhvdXNlLmNvbS9zb2NpZXR5 L0otU0FDL0NhbGxzL21vYmlsaXR5Lmh0bWwiARRodHRwOi8vd3d3LmFyZ3JlZW5ob3VzZS5jb20v c29jaWV0eS9KLVNBQy9DYWxscy9tb2JpbGl0eS5odG1sFQsLDQ0AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAABMBAAAXAQA ANIEAADUBAAAfwYAAIEGAACECgAAlQoAAJcKAADiCgAAmQsAAKsLAABJDAAAagwAALAMAACxDAAA 1gwAANcMAADYDAAA6gwAAOsMAAD2DgAA9w4AAEAPAABBDwAAQg8AAH8PAACADwAAhA8AAP359wD9 8/35/QD9+f0A/ez94uzf7P3s/dXs0Oz9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAACDBKEABDShgAABMCCIEDas8AAAAGCAFDShgAVQgBBDBKEAAAEwIIgQNqAAAAAAYIAUNK GABVCAENA2oAAAAAQ0oYAFUIAQc6CIFDShgAAzUIgQc1CIFDShgABENKGAAdAAQAACIEAAAjBAAA SQQAAEoEAABLBAAATAQAAFwEAAChBAAAogQAANMEAADUBAAAjQUAAEEJAABCCQAAUQkAAF4JAAB+ CQAAkQkAALwJAADTCQAABAoAABQKAAArCgAAQQoAAGgKAACXCgAAvgoAAPoAAAAAAAAAAAAAAAD4 AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAA AAAAAAAAAPUAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPEAAAAAAAAAAAAA AAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAA AAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAA AAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA +AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAABAgAAAQEAAAERAAMAAAMkAQABAAAABAAAJmQGAQABABsABAAAIgQAACMEAABJ BAAASgQAAEsEAABMBAAAXAQAAKEEAACiBAAA0wQAANQEAACNBQAAQQkAAEIJAABRCQAAXgkAAH4J AACRCQAAvAkAANMJAAAECgAAFAoAACsKAABBCgAAaAoAAJcKAAC+CgAA4goAAAkLAAAKCwAArAsA AK0LAADSCwAA0wsAANQLAADVCwAA7AsAABoMAABJDAAAagwAAIIMAACVDAAAqAwAAOwMAADtDAAA Ag0AACgNAAA8DQAAVA0AAG8NAACCDQAAlQ0AALANAACxDQAAyg0AAOcNAAAXDgAAKg4AAE4OAABh DgAAdA4AAIwOAADYDgAA9g4AAIMPAACEDwAAAAAAAAAAAP39+gAAAAAAAAAAAAAAAAAAAAD39wAA AAAAAAAAAAAA9wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUCAgAFAQUCAQAFAAMCEQAAQr4KAADiCgAACQsAAAoL AACsCwAArQsAANILAADTCwAA1AsAANULAADsCwAAGgwAAEkMAABqDAAAggwAAJUMAACoDAAA7AwA AO0MAAACDQAAKA0AADwNAABUDQAAbw0AAIINAACVDQAAsA0AALENAADKDQAA5w0AAP0AAAAAAAAA AAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA +wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAA AAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAA AAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsA AAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAA AAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAA APsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAAAAAAAAAAAQAAAAECAAAd5w0AABcOAAAqDgAATg4A AGEOAAB0DgAAjA4AANgOAAD2DgAAgw8AAIQPAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAorABIwABxQAQAfsNAvILDg PSGwoAUisKAFI5CgBSSQoAUlsAAAF7CgBRiwoAUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAM8AAABEAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANDJ6nn5 us4RjIIAqgBLqQsCAAAAFwAAABMAAABpAGEAbgBAAGUAYwBlAC4AZwBhAHQAZQBjAGgALgBlAGQA dQAAAODJ6nn5us4RjIIAqgBLqQs0AAAAbQBhAGkAbAB0AG8AOgBpAGEAbgBAAGUAYwBlAC4AZwBh AHQAZQBjAGgALgBlAGQAdQAAAO0AAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANDJ6nn5us4RjIIAqgBLqQsCAAAAAwAAAODJ 6nn5us4RjIIAqgBLqQt8AAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGEAcgBnAHIAZQBlAG4AaABv AHUAcwBlAC4AYwBvAG0ALwBzAG8AYwBpAGUAdAB5AC8ASgAtAFMAQQBDAC8AQwBhAGwAbABzAC8A bQBvAGIAaQBsAGkAdAB5AC4AaAB0AG0AbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASABIACgABAFsADwACAAAAAAAAACQAAEDx /wIAJAAAAAYATgBvAHIAbQBhAGwAAAACAAAABABtSAkENAABYAEAAgA0AAAACQBIAGUAYQBkAGkA bgBnACAAMQAAAAsAAQADJAEGJAFAJgAABABDShgAMAACYAEAAgAwAAAACQBIAGUAYQBkAGkAbgBn ACAAMgAAAAgAAgAGJAFAJgEEAENKGAAAAAAAAAAAAAAAAAAAADwAQUDy/6EAPAAAABYARABlAGYA YQB1AGwAdAAgAFAAYQByAGEAZwByAGEAcABoACAARgBvAG4AdAAAAAAAAAAAAAAAAABCACVAAQDy AEIAAAAPAEUAbgB2AGUAbABvAHAAZQAgAFIAZQB0AHUAcgBuAAAAAgAPAA8AOgiBQ0oYAE9KAgBR SgIAACgAVUCiAAEBKAAAAAkASAB5AHAAZQByAGwAaQBuAGsAAAAGAD4qAUIqAi4AQmABABIBLgAA AAkAQgBvAGQAeQAgAFQAZQB4AHQAAAAFABEAAyQBAAQAQ0oYAAAAAACECwAABgAAHgAABQD///// AAQAAIQPAAAKAAAAAAQAAL4KAADnDQAAhA8AAAsAAAANAAAADgAAAAAEAACEDwAADAAAALAIAADX CAAA6ggAAPYKAABBCwAAfwsAAIQLAAATWBT/FYATWJT/lYQAAAAARAUAAEcFAADmBQAA9AUAAKgI AACuCAAAKgkAADMJAACVCQAAmwkAAL8JAADICQAAHAoAACMKAAB0CgAAegoAAOYKAADpCgAAhgsA AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAAAAAAI0BAACUAQAA8QIAAAMD AACwCQAAsQkAAHwKAACKCgAAhgsAAAcAGgAHABoABwAEAAcAGgAHAP//AgAAACYAQwBlAG4AdABl AHIAIABmAG8AcgAgAFMAaQBnAG4AYQBsACAAYQBuAGQAIABJAG0AYQBnAGUAIABQAHIAbwBjAGUA cwBzAGkAbgBnACoARAA6AFwAdQBzAGUAcgBzAFwAQQBrAHkAaQBsAGQAaQB6AFwASgBTAEEAQwAg AGMAYQBsAGwAIABmAG8AcgAgAHAAYQBwAGUAcgBzAC4AZABvAGMA/0ADgAEAsAkAALAJAABIvOEB AQABALAJAAAAAAAArwkAAAAAAAACEAAAAAAAAACECwAAYAAACABAAAADAAAARxaQAQAAAgIGAwUE BQIDBIcCAAAAAAAAAAAAAAAAAACfAAAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBu AAAANRaQAQIABQUBAgEHBgIFBwAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFMAeQBtAGIAbwBsAAAA MyaQAQAAAgsGBAICAgICBIcCAAAAAAAAAAAAAAAAAACfAAAAAAAAAEEAcgBpAGEAbAAAACIABABx CIgYAADQAgAAaAEAAAAAgBtIho4bSIYAAAAAAwAKAAAAqgEAAH4JAAABAAQAAAAEAAMQFAAAAAAA AAAAAAAAAQABAAAAAQAAAAAAAAAkAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAClBsAH tAC0AIAAMjAAAAAAAAAAAAAAAAAAAKgLAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAA//8SAAAAAAAAAB0AQQBwAG8A bABvAGcAaQBlAHMAIABmAG8AcgAgAG0AdQBsAHQAaQBwAGwAZQAgAGMAbwBwAGkAZQBzAAAAAAAA ACYAQwBlAG4AdABlAHIAIABmAG8AcgAgAFMAaQBnAG4AYQBsACAAYQBuAGQAIABJAG0AYQBnAGUA IABQAHIAbwBjAGUAcwBzAGkAbgBnACYAQwBlAG4AdABlAHIAIABmAG8AcgAgAFMAaQBnAG4AYQBs ACAAYQBuAGQAIABJAG0AYQBnAGUAIABQAHIAbwBjAGUAcwBzAGkAbgBnAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQAAgAAAAAAAAAAAAAAAAAAAAAAAQAAAOCFn/L5 T2gQq5EIACsns9kwAAAAwAEAABEAAAABAAAAkAAAAAIAAACYAAAAAwAAAMAAAAAEAAAAzAAAAAUA AAD8AAAABgAAAAgBAAAHAAAAFAEAAAgAAAAkAQAACQAAAFQBAAASAAAAYAEAAAoAAAB8AQAADAAA AIgBAAANAAAAlAEAAA4AAACgAQAADwAAAKgBAAAQAAAAsAEAABMAAAC4AQAAAgAAAOQEAAAeAAAA HgAAAEFwb2xvZ2llcyBmb3IgbXVsdGlwbGUgY29waWVzAE1pHgAAAAEAAAAAcG9sHgAAACcAAABD ZW50ZXIgZm9yIFNpZ25hbCBhbmQgSW1hZ2UgUHJvY2Vzc2luZwAgHgAAAAEAAAAAZW50HgAAAAEA AAAAZW50HgAAAAcAAABOb3JtYWwAZh4AAAAnAAAAQ2VudGVyIGZvciBTaWduYWwgYW5kIEltYWdl IFByb2Nlc3NpbmcAIB4AAAACAAAAMwBudB4AAAATAAAATWljcm9zb2Z0IFdvcmQgOC4wAG5AAAAA ALygZQEAAABAAAAAANAMpHT9vwFAAAAAAKS6mHb9vwEDAAAAAQAAAAMAAACqAQAAAwAAAH4JAAAD AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAP7/AAAEAAIAAAAAAAAAAAAAAAAAAAAAAAIAAAAC1c3VnC4bEJOXCAAr LPmuRAAAAAXVzdWcLhsQk5cIACss+a5kAQAAIAEAAAwAAAABAAAAaAAAAA8AAABwAAAABQAAAJgA AAAGAAAAoAAAABEAAACoAAAAFwAAALAAAAALAAAAuAAAABAAAADAAAAAEwAAAMgAAAAWAAAA0AAA AA0AAADYAAAADAAAAAIBAAACAAAA5AQAAB4AAAAdAAAAR2VvcmdpYSBUZWNoIC0gU2Nob29sIG9m IEVDRQAAYwADAAAAFAAAAAMAAAAEAAAAAwAAAKgLAAADAAAAMRUIAAsAAAAAAAAACwAAAAAAAAAL AAAAAAAAAAsAAAAAAAAAHhAAAAEAAAAeAAAAQXBvbG9naWVzIGZvciBtdWx0aXBsZSBjb3BpZXMA DBAAAAIAAAAeAAAABgAAAFRpdGxlAAMAAAABAAAA2AEAAAQAAAAAAAAAKAAAAAEAAABSAAAAAgAA AFoAAAADAAAAsgAAAAIAAAACAAAACgAAAF9QSURfR1VJRAADAAAADAAAAF9QSURfSExJTktTAAIA AADkBAAAQQAAAE4AAAB7AEYAQwA3AEMANgA3ADMAMQAtADYAOQA2ADcALQAxADEARAA0AC0AOQBC AEEAOAAtADAAMAA1ADAAMAA0ADYAOAA0ADEARAAyAH0AAAAAAEEAAAAcAQAADAAAAAMAAAAEAFsA AwAAAAMAAAADAAAAAAAAAAMAAAAFAAAAHwAAAD4AAABoAHQAdABwADoALwAvAHcAdwB3AC4AYQBy AGcAcgBlAGUAbgBoAG8AdQBzAGUALgBjAG8AbQAvAHMAbwBjAGkAZQB0AHkALwBKAC0AUwBBAEMA LwBDAGEAbABsAHMALwBtAG8AYgBpAGwAaQB0AHkALgBoAHQAbQBsAAAAHwAAAAEAAAAAAAAAAwAA AC8AXwADAAAAAAAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAGgAAAG0AYQBpAGwAdABvADoAaQBhAG4A QABlAGMAZQAuAGcAYQB0AGUAYwBoAC4AZQBkAHUAAAAfAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAAN AAAADgAAAA8AAAD+////EQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAAP7///8ZAAAAGgAAABsA AAAcAAAAHQAAAB4AAAAfAAAA/v///yEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAD+////KQAA ACoAAAArAAAALAAAAC0AAAAuAAAALwAAAP7////9////MgAAAP7////+/////v////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAAAADAAAAAAAAARgAAAACgQNgRdf2/ AXBXO6l2/b8BNAAAAIAAAAAAAAAARABhAHQAYQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAgH///////////////8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAABAAAAAAAAAxAFQAYQBiAGwAZQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgACAAEAAAD///////// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAAAAEAAAAAAAAFcAbwByAGQA RABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAa AAIBBgAAAAUAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0e AAAAAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAACgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAgAAAAABAAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBm AG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAQQAAAD//////////wAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAAAAEAAAAAAAAAEAQwBvAG0AcABPAGIAagAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIBAgAAAAcAAAD///// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGoAAAAAAAAATwBiAGoAZQBj AHQAUABvAG8AbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYA AQD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAHBXO6l2/b8BcFc7qXb9vwEAAAAAAAAA AAAAAAABAAAA/v////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////wEA/v8DCgAA/////wYJAgAAAAAAwAAAAAAAAEYYAAAATWljcm9zb2Z0IFdvcmQgRG9jdW1l bnQACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA --=====================_245877423==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="JSAC call for papers.txt" Apologies for multiple copies.... -------------------------------------------------------------------- CALL FOR PAPERS MOBILITY AND RESOURCE MANAGEMENT IN NEXT GENERATION WIRELESS SYSTEMS IEEE Journal on Selected Areas in Communications The technology and business of cellular communications systems have made spectacular progress since the first systems were introduced fifteen years ago. Global roaming is a reality in current cellular systems that deliver low bandwidth services, such as telephone calls and short messages. However, future wireless systems are envisioned to provide high capacity, ubiquitous wireless communication in a variety of environments, including indoor office, pedestrian, vehicle, and satellite. Future systems will also include a wide variety of applications which will result in diverse traffic classes being supported and carried over wireless systems. Wireless networks must be more robust and diverse than today's second-generation cellular networks to support the new range of services, resource demands, and roaming capabilities of the future wireless customer. This special issue focuses on the new research contributions in the area of mobility and resource management for future wireless systems. We solicit a variety of papers with innovative solutions for mobility and resource management issues including, but not limited to: * PCS Systems * Mobile IP * Wireless Local Area Networks * Ad Hoc Networks * Hybrid Networks (Terrestrial-Satellite) * 4G Wireless Systems * Hierarchical and Macrodiversity Architectures * Wireless ATM * Wireless Local Loop * Satellite Networks * 3G (IMT2000, UMTS) Wireless Systems Manuscript Submission Date: December 20, 2000 Acceptance Notification: May 15, 2001 Final Manuscript Due: July 1, 2001 Publication Date: 4th Quarter of 2001 Please submit ONLY ON-LINE VERSION (PostScript or PDF or DOC) of the complete manuscript, not to exceed 25 pages, to the FIRST guest editor by DECEMBER 20, 2000. Prof. Ian F. Akyildiz Broadband and Wireless Networking Laboratory School of Electrical and Computer Engineering Georgia Institute of Technology Atlanta, GA 30332-0280 Tel: 404-894-5141 Fax: 404-894-7883 E_Mail: ian@ece.gatech.edu Prof. David Goodman Department of Electrical Engineering 5 MetroTech Center Polytechnic University Brooklyn, New York, 11201 Tel: 718-260-3221 Fax: 718-260-3906 E_mail: dgoodman@poly.edu Prof. Leonard Kleinrock Computer Science Department University of California at Los Angeles (UCLA) 4732 Boelter Hall Los Angeles, California 90095-1596 Tel: 310-825-3886 Fax: 310-825-2273 E_Mail: lk@cs.ucla.edu -------------------------------------------------------------------------- For formatted CfP, please see http://www.argreenhouse.com/society/J-SAC/Calls/mobility.html --=====================_245877423==_-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Aug 3 16:12:21 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23838 for ; Thu, 3 Aug 2000 16:12:20 -0400 (EDT) Received: from standards (47.234.32.16:3075) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84B80@standards.nortelnetworks.com>; Thu, 3 Aug 2000 16:00:29 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6346 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Aug 2000 16:00:29 -0400 Received: from mail.arc.nasa.gov (pony1.arc.nasa.gov) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84B7E@standards.nortelnetworks.com>; Thu, 3 Aug 2000 15:50:28 -0400 Received: from cbyers (cbyers.arc.nasa.gov [128.102.132.83]) by mail.arc.nasa.gov (8.9.3/8.9.3) with ESMTP id NAA13280 for ; Thu, 3 Aug 2000 13:01:40 -0700 (PDT) X-Sender: cbyers@mail.arc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.2.0.58.20000804130059.00965610@mail.arc.nasa.gov> Date: Fri, 4 Aug 2000 13:04:29 -0700 Reply-To: Carol Byers Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Carol Byers Subject: [MOBILE-IP] Un-Subscribe To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <4.2.0.58.20000803145414.00ca29d0@mail.ee.gatech.edu> Please remove me from your server mailing list. unsubcribe, me please. Carol From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Aug 4 02:29:38 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12220 for ; Fri, 4 Aug 2000 02:29:38 -0400 (EDT) Received: from standards (47.234.32.16:4496) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84DD1@standards.nortelnetworks.com>; Fri, 4 Aug 2000 2:17:42 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7101 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Aug 2000 02:17:41 -0400 Received: from hotmail.com (f84.law3.hotmail.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84DCC@standards.nortelnetworks.com>; Fri, 4 Aug 2000 2:07:41 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 3 Aug 2000 23:19:03 -0700 Received: from 131.170.6.141 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 04 Aug 2000 GMT X-Originating-IP: [131.170.6.141] Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 04 Aug 2000 06:19:03.0734 (UTC) FILETIME=[E2F9A560:01BFFDDB] Message-ID: Date: Fri, 4 Aug 2000 16:19:03 EST Reply-To: opamps cybernetics Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: opamps cybernetics Subject: [MOBILE-IP] Some novice questions!!! To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi Gurus, Sorry for asking these stupid questions: 1) What is soft handoff, hard handoff and fast handoff? 2) Is the mobile-ip already implemented in present-day consumer networks or it is still a proposition? 3) Cellular-ip, HMIP and UMIP: Which one is better and why? Thank you very much in advance... Opamps ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Aug 4 03:16:03 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03776 for ; Fri, 4 Aug 2000 03:15:58 -0400 (EDT) Received: from standards (47.234.32.16:4496) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84E33@standards.nortelnetworks.com>; Fri, 4 Aug 2000 3:03:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7241 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Aug 2000 03:03:56 -0400 Received: from oulu.fi (ousrvr.oulu.fi) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84E32@standards.nortelnetworks.com>; Fri, 4 Aug 2000 3:03:56 -0400 Received: from ee.oulu.fi (ees2.oulu.fi [130.231.61.23]) by oulu.fi (8.8.5/8.8.5) with ESMTP id KAA03135 for ; Fri, 4 Aug 2000 10:15:17 +0300 (EET DST) Received: from stekt56 (stekt56 [130.231.60.96]) by ee.oulu.fi (8.9.3/8.9.3) with ESMTP id KAA01695 for ; Fri, 4 Aug 2000 10:15:17 +0300 (EET DST) X-Sender: over@stekt56 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Fri, 4 Aug 2000 10:15:17 +0300 Reply-To: Mika Ylianttila Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Mika Ylianttila Subject: Re: [MOBILE-IP] Handoff triggering To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <2A5485D1C9C7D311816F0000F805ADB769700A@vhapugexc1.med.va.gov> On Thu, 3 Aug 2000, Kay, Rodney wrote: >Have been going through your draft document and find it very interesting, >but have a general question: You talk of the MT scenario as being a >combination of the MI/MO scenarios; but I wonder if it wouldn't properly be >a separate entity unto itself. Hi Rodney, you are right that MT may not be explicitly a combination the first two, but merely in the conceptual level. This firts draft tries to bring up the problems and related requirements in a quite general level, and the contents of each scenario can be deepened, and some issues may need to be redefined. We have been studying the algorithm aspects around inter- tech mobility, and I was happy to see that there are now an increased interest within IETF to address these issues. >Your example of a MH in a moving vehicle >seems to make the argument that when terminal velocity exceeds X >(pre-defined by better minds than mine) then the ITHO should be negated in >favor of remaining with the GPN as opposed to swapping around various LPN's. That is a quite realistic assumption in my opinion. I think the coverage of LPN must be taken into consideration in respect to the terminal velocity (in an ideal system). -- Mika Ylianttila M.Sc., Research Scientist Centre for Wireless Communications PL 4500, Tutkijantie 2 E, FIN-90014 University of Oulu, Finland >Regards, > >Rodney H. Kay >Department of Veteran's Affairs >Puget Sound Health Care System >Systems Manager >Seattle, Washington > >-----Original Message----- >From: Mika Ylianttila [mailto:over@EES2.OULU.FI] >Sent: Wednesday, August 02, 2000 7:50 AM >To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM >Subject: [MOBILE-IP] Handoff triggering > > > First a kind note for the majordomo admin: please try to preclude spams, >as well as out of office replys. It should be pretty easy to do, e.g. > >taboo_headers << END >/$/i >/"OUT OF OFFICE"/i >END > > Then for the actual topic. As it is possible to use net in real-time >during the WG sessions, I would assume that e.g. CRAPS and handoff issues >would be relevant topics for immeadent discussions. While it is still >unclear if there is enough work items (or specific enough) for a new WG, I >am still very much interested in this kind of an effort within IETF. There >are many aspect of handoff that are not yet currently addressed with the >use of Mobile IP as inter-technology handoff protocol. One is the >triggering part. It may be debatable if the handoff algorithm aspects for >triggering is an IETF topic, but I would like to see discussion about it. I >have presented some aspects for it in my draft >http://search.ietf.org/internet-drafts/draft-ylianttila-isl-prot-req-00.txt. >Because it was originally made to Spatial Location BOF it contains a number >of irrelevant stuff for this WG, but you should find the relevant parts >pretty easily. > >Waiting for the discussion (is there some other list, I have not seen >much discussion on this list lately?) ;) > >-- >Mika Ylianttila >M.Sc., Research Scientist >Centre for Wireless Communications >PL 4500, Tutkijantie 2 E, FIN-90014 >University of Oulu, Finland > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Aug 4 08:02:54 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09146 for ; Fri, 4 Aug 2000 08:02:53 -0400 (EDT) Received: from standards (47.234.32.16:4312) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84F04@standards.nortelnetworks.com>; Fri, 4 Aug 2000 7:50:53 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7506 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Aug 2000 07:50:53 -0400 Received: from oulu.fi (ousrvr.oulu.fi) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB84F03@standards.nortelnetworks.com>; Fri, 4 Aug 2000 7:50:52 -0400 Received: from ee.oulu.fi (ees2.oulu.fi [130.231.61.23]) by oulu.fi (8.8.5/8.8.5) with ESMTP id PAA22910 for ; Fri, 4 Aug 2000 15:02:13 +0300 (EET DST) Received: from stekt34 (stekt34 [130.231.60.74]) by ee.oulu.fi (8.9.3/8.9.3) with ESMTP id PAA23907 for ; Fri, 4 Aug 2000 15:02:12 +0300 (EET DST) X-Sender: over@stekt34 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Fri, 4 Aug 2000 15:02:12 +0300 Reply-To: Mika Ylianttila Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Mika Ylianttila Subject: Re: [MOBILE-IP] Some novice questions!!! To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: On Fri, 4 Aug 2000, opamps cybernetics wrote: >1) What is soft handoff, hard handoff and fast handoff? Soft and hard handoff are concepts of connection oriented (cellular) networks. Hard handoff refers to brake-before-make type of procedure, typical in TDMA systems. In hard handoff there is a slight gap in the communication during handoff when the connection to old BS is closed and the connection to new BS is established. As on opposite, soft handoff is an make-before-brake type of procedure, typical in CDMA systems. In soft handoff MH establish connection to new BS before braking the previous connection. Seamless handoff is a concept of connectienless packet networks, such as Internet. While there can be handoffs between access points inside one network (=micro-mobility), seamless handoff is typically used as a concept of macro-mobility where MH moves between subnetworks. If the subnets use same technology, handoff is referred as intra-technology (horizontal) handoff, and when subnets have different technology, handoff is referred as inter-technology (vertical) handoff. Micro-mobility takes usually place in layer 2, whereas macro-mobility takes usually place in layer 3 or above. However, current trend has been to bring micro-mobility functions to layer 3 (e.g. micro-mobility with extended Mobile IP). Term "seamless" refers to the fact that handoff does not cause any noticeable gap to the packet based communications (especially to real-time communications such as Voice over IP). I guess term "fast handoff" is basicly the same thing, meaning that he handoff happens fast enough that the user does not notice any gap. I hope this clariefies these concepts to you and others. I noticed that there was a little bit confusion and mixing of concepts of soft and seamless handoff in the Mobile IP WG sessions in Pittsburgh. -- Mika Ylianttila M.Sc., Research Scientist Centre for Wireless Communications PL 4500, Tutkijantie 2 E, FIN-90014 University of Oulu, Finland From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Aug 4 10:27:42 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22632 for ; Fri, 4 Aug 2000 10:27:41 -0400 (EDT) Received: from standards (47.234.32.16:2708) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8503A@standards.nortelnetworks.com>; Fri, 4 Aug 2000 10:15:11 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7912 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Aug 2000 10:15:10 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85039@standards.nortelnetworks.com>; Fri, 4 Aug 2000 10:15:10 -0400 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA00036; Fri, 4 Aug 2000 08:26:28 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA18078; Fri, 4 Aug 2000 07:26:26 -0700 (PDT) Received: from nasnfs.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id HAA09022; Fri, 4 Aug 2000 07:26:15 -0700 (PDT) X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-ID: <200008041426.HAA09022@nasnfs.eng.sun.com> Date: Fri, 4 Aug 2000 10:27:25 -0600 Reply-To: Pat.Calhoun@Eng.Sun.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrice Calhoun Subject: Re: [MOBILE-IP] Some novice questions!!! X-To: opamps cybernetics To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit >Hi Gurus, > >Sorry for asking these stupid questions: > >1) What is soft handoff, hard handoff and fast handoff? Here's my take. soft vs. hard hand-off are terms that actually have very specific meanings in CDMA. I believe that the IETF should use fast handoff, which carries no baggage. Of course, this week we've heard of express handoff, so I am proposing changing my Internet Draft to hyper-speed handoff :) :) > >2) Is the mobile-ip already implemented in present-day consumer networks or >it is still a proposition? implemented, and available in Solaris 8 update 1. > >3) Cellular-ip, HMIP and UMIP: Which one is better and why? I believe that I will not touch this one with a 10 foot pole. PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Aug 4 11:10:12 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07379 for ; Fri, 4 Aug 2000 11:10:12 -0400 (EDT) Received: from standards (47.234.32.16:1357) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB850D4@standards.nortelnetworks.com>; Fri, 4 Aug 2000 10:57:57 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8074 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Aug 2000 10:57:57 -0400 Received: from ftpbox.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB850B4@standards.nortelnetworks.com>; Fri, 4 Aug 2000 10:47:56 -0400 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id HAB09502; Fri, 4 Aug 2000 07:59:15 -0700 (MST)] Received: [from il02dns1.comm.mot.com (il02dns1.comm.mot.com [145.1.3.2]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id HAA06266; Fri, 4 Aug 2000 07:59:10 -0700 (MST)] Received: from cje011.mot.com ([173.14.15.182]) by il02dns1.comm.mot.com (8.9.3/8.9.3) with ESMTP id JAA22649; Fri, 4 Aug 2000 09:59:15 -0500 (CDT) X-Sender: lmps_mstr_1/cje011@il02exm21.comm.mot.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.3.2.7.2.20000804095249.00b10e80@il02exm21.comm.mot.com> Date: Fri, 4 Aug 2000 09:59:09 -0500 Reply-To: John Emmert Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: John Emmert Subject: Re: [MOBILE-IP] Some novice questions!!! X-To: opamps cybernetics To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: At 04:19 PM 8/4/00, opamps cybernetics wrote: >2) Is the mobile-ip already implemented in present-day consumer networks or >it is still a proposition? Yes. Nextel offers it in the plus line of subscribers as their Nextel Online product. Some examples of consumer products already on the market that implement it can be found at: http://commerce.motorola.com/consumer/QWhtml/multi_cat.html From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Aug 4 11:28:49 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13810 for ; Fri, 4 Aug 2000 11:28:48 -0400 (EDT) Received: from standards (47.234.32.16:1161) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB850D9@standards.nortelnetworks.com>; Fri, 4 Aug 2000 11:14:49 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8183 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Aug 2000 11:11:31 -0400 Received: from prue.eim.surrey.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85108@standards.nortelnetworks.com>; Fri, 4 Aug 2000 11:01:30 -0400 Received: from carter-e0.ee.surrey.ac.uk ([131.227.86.16]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 13Kj9Z-0002m3-00 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 04 Aug 2000 16:12:53 +0100 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Fri, 4 Aug 2000 16:12:53 +0100 Reply-To: Karann Chew Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Karann Chew Subject: [MOBILE-IP] Another novice questions! To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200008041426.HAA09022@nasnfs.eng.sun.com> Dear All, I noticed that proposals such as Cellular IP, HAWAII etc. (which seem to be able to solve fast handoff or micro-mobility or intro-domain mobility problem) are not favoured by a lot of people in MIP WG. Well, at least not as popular as drafts such as Route Optimzation, Regional Registration etc. Could someone please explain why. What I can think of are that RO, RR is more conform to RFC2002; have a more well-defined security procedures... Thanks in advance. Cheers! Karann > >3) Cellular-ip, HMIP and UMIP: Which one is better and why? > > I believe that I will not touch this one with a 10 foot pole. > > PatC > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Aug 4 11:38:30 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17681 for ; Fri, 4 Aug 2000 11:38:29 -0400 (EDT) Received: from standards (47.234.32.16:1161) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85119@standards.nortelnetworks.com>; Fri, 4 Aug 2000 11:26:15 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8284 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Aug 2000 11:26:15 -0400 Received: from prserv.net (out1.prserv.net) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85118@standards.nortelnetworks.com>; Fri, 4 Aug 2000 11:26:14 -0400 Received: from [129.37.227.14] ([129.37.227.14]) by prserv.net (out1) with ESMTP id <20000804153646252033g82ce>; Fri, 4 Aug 2000 15:36:47 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: ahmrphd@pop3.attglobal.net Message-ID: Date: Fri, 4 Aug 2000 08:37:48 -0700 Reply-To: Arthur Ross Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Arthur Ross Subject: Re: [MOBILE-IP] Some novice questions!!! X-To: Pat.Calhoun@Eng.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200008041426.HAA09022@nasnfs.eng.sun.com> At 9:27 -0700 08/04/2000, Patrice Calhoun wrote: >>Hi Gurus, >> >>Sorry for asking these stupid questions: >> >>1) What is soft handoff, hard handoff and fast handoff? > >Here's my take. > >soft vs. hard hand-off are terms that actually have very specific meanings >in CDMA. I believe that the IETF should use fast handoff, which carries no >baggage. > Short description: "Soft" handoff in CDMA entails a make-before-break state during which diversity combining of signals from multiple stations is used to improve error performance. "Hard" handoff doesn't do that. Soft handoff is, in some loose sense, a state; hard handoff is a state transition. "Fast" seems to me to be a different coordinate axis of the problem :-) -- A Dr. Arthur H. M. Ross 2325 East Orangewood Avenue Phoenix, AZ 85020-4730 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Aug 4 11:50:39 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23058 for ; Fri, 4 Aug 2000 11:50:38 -0400 (EDT) Received: from standards (47.234.32.16:1161) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85150@standards.nortelnetworks.com>; Fri, 4 Aug 2000 11:38:35 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8358 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Aug 2000 11:38:35 -0400 Received: from ennovatenetworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8514F@standards.nortelnetworks.com>; Fri, 4 Aug 2000 11:38:34 -0400 Received: from broncos (broncos.tst.ennovatenetworks.com [10.1.1.208]) by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id LAA06548; Fri, 4 Aug 2000 11:49:15 -0400 (EDT) (envelope-from bkumar@ennovatenetworks.com) 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Message-ID: <009501bffe23$26fd2ce0$d001010a@tst.ennovatenetworks.com> Date: Fri, 4 Aug 2000 10:49:10 -0400 Reply-To: bkumar@ennovatenetworks.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Brijesh Kumar Subject: Re: [MOBILE-IP] Some novice questions!!! X-To: Mika Ylianttila To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Content-Transfer-Encoding: 7bit Hi, A little addition to Mika Ylianttila excellent explanation. Soft Hand off is a basic property of the CDMA systems as there is no channel to be acquired when a device moves from one cell area to another cell area. The actual algorithm is a lot more complex than this simple description as the device and base stations need to organize when it is appropriate to effect this hand over - remember you don't have definitive road signs saying "Welcome to area XX" in the wireless world. A device can hear from three cell controllers at the same time each saying "Welcome to area XX". And you get into all power computation and control algorithms in the system. In hard hand off the device needs to acquire the new RF channel (as in CDMA or GSM systems) and relinquish the current one. There are many techniques to do it efficiently in cellular systems. And Hard hand off doesn't mean that the user is going to notice it. Read any text book on wireless systems to know more on this. Fast handoff is a meaningless term like fast computer. What is fast? Such wonderful terms are coined by "Internet Experts" trying to be "Wireless specialists". Or is it other way - I don't know ;-). Cheers, --brijesh Ennovate Networks Inc. > -----Original Message----- > From: IP Routing for Wireless/Mobile Hosts (mobile-ip) > [mailto:MOBILE-IP@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Mika > Ylianttila > Sent: Friday, August 04, 2000 8:02 AM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Some novice questions!!! > > > On Fri, 4 Aug 2000, opamps cybernetics wrote: > > >1) What is soft handoff, hard handoff and fast handoff? > > Soft and hard handoff are concepts of connection oriented (cellular) > networks. Hard handoff refers to brake-before-make type of procedure, > typical in TDMA systems. In hard handoff there is a slight gap in the > communication during handoff when the connection to old BS is > closed and > the connection to new BS is established. As on opposite, soft > handoff is an > make-before-brake type of procedure, typical in CDMA systems. In soft > handoff MH establish connection to new BS before braking the previous > connection. > > Seamless handoff is a concept of connectienless packet > networks, such as > Internet. While there can be handoffs between access points inside one > network (=micro-mobility), seamless handoff is typically used > as a concept > of macro-mobility where MH moves between subnetworks. If the > subnets use > same technology, handoff is referred as intra-technology (horizontal) > handoff, and when subnets have different technology, handoff > is referred as > inter-technology (vertical) handoff. Micro-mobility takes > usually place in > layer 2, whereas macro-mobility takes usually place in layer > 3 or above. > However, current trend has been to bring micro-mobility > functions to layer > 3 (e.g. micro-mobility with extended Mobile IP). > > Term "seamless" refers to the fact that handoff does not cause any > noticeable gap to the packet based communications (especially > to real-time > communications such as Voice over IP). I guess term "fast handoff" is > basicly the same thing, meaning that he handoff happens fast > enough that > the user does not notice any gap. > > I hope this clariefies these concepts to you and others. I > noticed that > there was a little bit confusion and mixing of concepts of soft and > seamless handoff in the Mobile IP WG sessions in Pittsburgh. > > -- > Mika Ylianttila > M.Sc., Research Scientist > Centre for Wireless Communications > PL 4500, Tutkijantie 2 E, FIN-90014 > University of Oulu, Finland > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Aug 4 12:50:46 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14839 for ; Fri, 4 Aug 2000 12:50:46 -0400 (EDT) Received: from standards (47.234.32.16:1161) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB851DA@standards.nortelnetworks.com>; Fri, 4 Aug 2000 12:38:39 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8529 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Aug 2000 12:38:39 -0400 Received: from web1006.mail.yahoo.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB851D4@standards.nortelnetworks.com>; Fri, 4 Aug 2000 12:28:38 -0400 Received: (qmail 15447 invoked by uid 60001); 4 Aug 2000 16:40:01 -0000 Received: from [129.12.48.202] by web1006.mail.yahoo.com; Fri, 04 Aug 2000 17:40:01 BST MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <20000804164001.15446.qmail@web1006.mail.yahoo.com> Date: Fri, 4 Aug 2000 17:40:01 +0100 Reply-To: =?iso-8859-1?q?Mudar=20Barry?= Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: =?iso-8859-1?q?Mudar=20Barry?= Subject: Re: [MOBILE-IP] Some novice questions!!! To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit >Fast handoff is a meaningless term like fast computer. >What is fast? Hi, Can someone please correct me if I'm wrong. I thought Fast handover meant that for certain applications especially real-time applications, having, for example, partial HA functionality in a hierarchy of FAs means that location updates are handled regionally in the hierarchy for the duration allowed by the registration. Hence in this context, regional/local handovers can be performed faster than having to go all the way to a potentially distant HA. Thanks Mudar Barry ____________________________________________________________ Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Aug 4 13:05:30 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18394 for ; Fri, 4 Aug 2000 13:05:29 -0400 (EDT) Received: from standards (47.234.32.16:1161) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8520C@standards.nortelnetworks.com>; Fri, 4 Aug 2000 12:53:35 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8605 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Aug 2000 12:53:34 -0400 Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8520B@standards.nortelnetworks.com>; Fri, 4 Aug 2000 12:53:34 -0400 Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60]) by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e74H4us25546 for ; Fri, 4 Aug 2000 20:04:56 +0300 (EET DST) Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-i1.ntc.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e74H4sV20624 for ; Fri, 4 Aug 2000 20:04:55 +0300 (EET DST) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id ; Fri, 4 Aug 2000 12:02:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E168@daeis07nok> Date: Fri, 4 Aug 2000 12:02:10 -0500 Reply-To: Basavaraj.Patil@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: [MOBILE-IP] IETF48 - Note to people who presented To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi, If you presented an I-D at the Mobile IP WG sessions at IETF48 in Pitssburgh, please forward the presentations that you used to me or Phil for inclusion in the proceedings. -Basavaraj From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Aug 4 14:00:52 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06553 for ; Fri, 4 Aug 2000 14:00:52 -0400 (EDT) Received: from standards (47.234.32.16:1172) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85260@standards.nortelnetworks.com>; Fri, 4 Aug 2000 13:48:41 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8719 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Aug 2000 13:48:40 -0400 Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8525F@standards.nortelnetworks.com>; Fri, 4 Aug 2000 13:48:39 -0400 Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Fri Aug 4 13:58:44 EDT 2000 Received: from dnrc.bell-labs.com (IDENT:21257@ramjeepc [135.180.240.106]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id NAA14503; Fri, 4 Aug 2000 13:58:41 -0400 (EDT) X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.0.36 i686) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <398B0485.C9E94329@dnrc.bell-labs.com> Date: Fri, 4 Aug 2000 17:59:33 +0000 Reply-To: ramjee@DNRC.BELL-LABS.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Ramachandran Ramjee Subject: [MOBILE-IP] Handoff framework [Was Re: [MOBILE-IP] Another novice questions!] X-cc: Karann Chew To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello, Here is my take on fast handoffs. There has been a spate of drafts recently on handoff support and the working group is trying to unify them to one proposal. While the net outcome of this might indeed be one draft, that ONE DRAFT WILL END UP LISTING MULTIPLE HANDOFF SOLUTIONS FOR DIFFERENT LINK LAYER/WIRELESS NETWORK SCENARIOS (this is one of the reasons why we keep hearing objections from some quarters saying fast handoff should be left to the link layer folks themselves and not the mobileip wg!). I think what we need is a FRAMEWORK FOR HANDLING MOBILITY LOCALLY. Inside this framework, there must be freedom to tailor handoffs in any way, based on link layer or other characteristics. This framework will also allow registrations to be processed locally, reducing signaling load to the home agent. Also, such a framework will help support paging within the network agents (which is another local function) and ipv6 (which will initially be a local function as the transition from ipv4 takes place). Currently, there are two such broad frameworks available: 1) HAWAII/CIP - every local node is involved, no tunneling 2) HMIP/UMIP/RR - a few local nodes are involved, tunneling-based overlay I think both frameworks are/can be made to look like rfc2002 with similar security models. So, the real issue is do we want an overlay or not in the local wireless access network? Once the wg decides on this, we can then decide on ONE FRAMEWORK document that specifies how mobility is handled locally (for example, if the decision is to use the overlay network approach, we can then decide on merging the HMIP/UMIP/RR proposals). THEN, fast handoffs and everything else will have a structure to work with and we no longer need just one fast handoff standard. Comments please? Cheers, Ram P.S. Answering your question on the popularity of different micro-mobilty proposals, the ability to do all local functions such as paging/fast handoffs/regional registrations etc. in one framework in HAWAII/CIP is, I think, causing more resistance in the wg, while in the Hierarchial approach, there is multiple drafts each addressing one piece of the puzzle, making it easier to digest. Karann Chew wrote: > > Dear All, > > I noticed that proposals such as Cellular IP, HAWAII etc. (which seem to > be able to solve fast handoff or micro-mobility or intro-domain > mobility problem) are not favoured by a lot of people in MIP WG. Well, at > least not as popular as drafts such as Route Optimzation, Regional > Registration etc. Could someone please explain why. > > What I can think of are that RO, RR is more conform to RFC2002; have a > more well-defined security procedures... > > Thanks in advance. Cheers! > Karann > > > >3) Cellular-ip, HMIP and UMIP: Which one is better and why? > > > > I believe that I will not touch this one with a 10 foot pole. > > > > PatC > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Aug 4 17:04:29 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25271 for ; Fri, 4 Aug 2000 17:04:29 -0400 (EDT) Received: from standards (47.234.32.16:1691) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85318@standards.nortelnetworks.com>; Fri, 4 Aug 2000 16:52:31 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8959 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Aug 2000 16:52:31 -0400 Received: from smtpgw2.sprintspectrum.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85317@standards.nortelnetworks.com>; Fri, 4 Aug 2000 16:52:31 -0400 Received: from PKCEXV501.nmcc.sprintspectrum.com (pkcexb501.sprintspectrum.com [208.4.96.83]) by smtpgw2.sprintspectrum.com (8.9.3/8.9.3) with ESMTP id QAA10563; Fri, 4 Aug 2000 16:03:49 -0500 (CDT) Received: by pkcexv501.nmcc.sprintspectrum.com with Internet Mail Service (5.5.2650.21) id ; Fri, 4 Aug 2000 16:08:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Fri, 4 Aug 2000 16:08:14 -0500 Reply-To: "Castillo Jr., Al" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Castillo Jr., Al" Subject: Re: [MOBILE-IP] Some novice questions!!! X-To: "bkumar@ennovatenetworks.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Another way to look at "soft and "hard" handoff is: Soft: The Cell is within the same BTS, but it changes sector. A BTS usually has three sectors. When the cell gets to a different sector within the same BTS, the cell obtain a new PN control for the RF. Hard: A hard handoff occur when the cell moves to a new MSC. Al Castillo Jr. Sr. Engineer Sprint PCS Systems & Technology Integration Center Wireless Data Team Office: (913) 859-3609 PCS: (913) 226-9074 -----Original Message----- From: Brijesh Kumar [mailto:bkumar@ennovatenetworks.com] Sent: Friday, August 04, 2000 9:49 AM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] Some novice questions!!! Hi, A little addition to Mika Ylianttila excellent explanation. Soft Hand off is a basic property of the CDMA systems as there is no channel to be acquired when a device moves from one cell area to another cell area. The actual algorithm is a lot more complex than this simple description as the device and base stations need to organize when it is appropriate to effect this hand over - remember you don't have definitive road signs saying "Welcome to area XX" in the wireless world. A device can hear from three cell controllers at the same time each saying "Welcome to area XX". And you get into all power computation and control algorithms in the system. In hard hand off the device needs to acquire the new RF channel (as in CDMA or GSM systems) and relinquish the current one. There are many techniques to do it efficiently in cellular systems. And Hard hand off doesn't mean that the user is going to notice it. Read any text book on wireless systems to know more on this. Fast handoff is a meaningless term like fast computer. What is fast? Such wonderful terms are coined by "Internet Experts" trying to be "Wireless specialists". Or is it other way - I don't know ;-). Cheers, --brijesh Ennovate Networks Inc. > -----Original Message----- > From: IP Routing for Wireless/Mobile Hosts (mobile-ip) > [mailto:MOBILE-IP@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Mika > Ylianttila > Sent: Friday, August 04, 2000 8:02 AM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Some novice questions!!! > > > On Fri, 4 Aug 2000, opamps cybernetics wrote: > > >1) What is soft handoff, hard handoff and fast handoff? > > Soft and hard handoff are concepts of connection oriented (cellular) > networks. Hard handoff refers to brake-before-make type of procedure, > typical in TDMA systems. In hard handoff there is a slight gap in the > communication during handoff when the connection to old BS is > closed and > the connection to new BS is established. As on opposite, soft > handoff is an > make-before-brake type of procedure, typical in CDMA systems. In soft > handoff MH establish connection to new BS before braking the previous > connection. > > Seamless handoff is a concept of connectienless packet > networks, such as > Internet. While there can be handoffs between access points inside one > network (=micro-mobility), seamless handoff is typically used > as a concept > of macro-mobility where MH moves between subnetworks. If the > subnets use > same technology, handoff is referred as intra-technology (horizontal) > handoff, and when subnets have different technology, handoff > is referred as > inter-technology (vertical) handoff. Micro-mobility takes > usually place in > layer 2, whereas macro-mobility takes usually place in layer > 3 or above. > However, current trend has been to bring micro-mobility > functions to layer > 3 (e.g. micro-mobility with extended Mobile IP). > > Term "seamless" refers to the fact that handoff does not cause any > noticeable gap to the packet based communications (especially > to real-time > communications such as Voice over IP). I guess term "fast handoff" is > basicly the same thing, meaning that he handoff happens fast > enough that > the user does not notice any gap. > > I hope this clariefies these concepts to you and others. I > noticed that > there was a little bit confusion and mixing of concepts of soft and > seamless handoff in the Mobile IP WG sessions in Pittsburgh. > > -- > Mika Ylianttila > M.Sc., Research Scientist > Centre for Wireless Communications > PL 4500, Tutkijantie 2 E, FIN-90014 > University of Oulu, Finland > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Aug 5 13:28:08 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24489 for ; Sat, 5 Aug 2000 13:28:08 -0400 (EDT) Received: from standards (47.234.32.16:3650) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85508@standards.nortelnetworks.com>; Sat, 5 Aug 2000 13:15:48 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9538 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 5 Aug 2000 13:15:48 -0400 Received: from zircon.3com.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85501@standards.nortelnetworks.com>; Sat, 5 Aug 2000 13:05:48 -0400 Received: from agate.ops.3com.com (agate.3com.com [139.87.50.118]) by zircon.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e75HH6K16246; Sat, 5 Aug 2000 10:17:12 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by agate.ops.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id e75HH1415918; Sat, 5 Aug 2000 10:17:01 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256932.005EDCF7 ; Sat, 5 Aug 2000 10:16:09 -0700 X-Lotus-FromDomain: 3COM Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <88256932.005EDBE7.00@hqoutbound.ops.3com.com> Date: Sat, 5 Aug 2000 10:14:42 -0700 Reply-To: Barani_Subbiah@3COM.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Barani Subbiah Subject: Re: [MOBILE-IP] Some novice questions!!! X-To: Mudar Barry To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Fast hand off == soft hand off with constraints (if soft hand off does not do that already). Constraint could be specific to applications (eg. voice and video) and specify what is acceptable (delay or loss etc) to user and application. Barani. Mudar Barry on 08/04/2000 09:40:01 AM Please respond to Mudar Barry Sent by: Mudar Barry To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM cc: (Barani Subbiah/HQ/3Com) Subject: Re: [MOBILE-IP] Some novice questions!!! >Fast handoff is a meaningless term like fast computer. >What is fast? Hi, Can someone please correct me if I'm wrong. I thought Fast handover meant that for certain applications especially real-time applications, having, for example, partial HA functionality in a hierarchy of FAs means that location updates are handled regionally in the hierarchy for the duration allowed by the registration. Hence in this context, regional/local handovers can be performed faster than having to go all the way to a potentially distant HA. Thanks Mudar Barry ____________________________________________________________ Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Aug 6 01:40:14 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20606 for ; Sun, 6 Aug 2000 01:40:12 -0400 (EDT) Received: from standards (47.234.32.16:2544) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85640@standards.nortelnetworks.com>; 6 Aug 2000 1:28:04 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9929 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 6 Aug 2000 01:28:04 -0400 Received: from ns.kccedu.co.kr (router.kccedu.co.kr) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8563B@standards.nortelnetworks.com>; 6 Aug 2000 1:18:03 -0400 Received: from host (sdn-ar-001riprovP252.dialsprint.net [168.191.126.142]) by ns.kccedu.co.kr (8.9.3/8.8.7) with ESMTP id OAA12610; Sun, 6 Aug 2000 14:21:41 +0900 X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE VÐßD.1712.3 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0" Content-Transfer-Encoding: 7bit Message-ID: <200008060521.OAA12610@ns.kccedu.co.kr> Date: Sun, 6 Aug 2000 01:04:16 -0500 Reply-To: Frank Kardin Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Frank Kardin Subject: [MOBILE-IP] Out Of Debt... X-To: red93i@ns.kccedu.co.kr To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a MIME Message ------=_NextPart_000_007F_01BDF6C7.FABAC1B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0" ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ***** This is an HTML Message ! ***** ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

FREE!!
Debt Consolidation Help!

Our Organization = Provides
 FREE Professional Help and Relief From Too Much Debt=2E

Find out Why Our Debt-= Management Program is the
# 1 Way For Dealing With Too Much Debt=2E
We provide FREE Professional Help To Instantly Reduce
Your Interest Rates and Minimum Payments=2E
 "We Get Your Creditors Off Your= Back!"

With One = Phone Call,
We Can Get Your Creditors To Do the Following:=

Lower your monthly= payments
by 40-60%<= /em>=2E		 Save thousands of = dollars in
interest and late charges=2E
End Creditor Ha= rassment! Start improving yo= ur credit rating=2E
Cut your bills in = half=2E Consolidate your b= ills into
One Low monthly payment=2E
Eliminate interest= and late fee charges=2E Improve your credi= t rating=2E

From credit counseling= to debt consolidation we have the
FREE information and resources to provide you with fast relief
from credit card and other debts=2E

FREE award winning monthly Email Newsletter
containing powerful money saving credit and tax secrets=2E=

 

All applications = are confidential=2E=
There is absolutely NO obligation for filling out this form
and receiving a FREE debt analysis=2E

** The form must b= e filled out completely and you must be at least 18 years of age=2E **

Name:
Address:
City:
State:
Zip:
Day Phone:
(please be sure to inc= lude your area code)
Evening Phone:
(please be sure to inc= lude your area code)
Best Time of Day To Call:
(please be sure to include your time zone)		  
Email Address:
(i=2Ee=2E yourname@som= ewhere=2Ecom)
Subscribe me to your FREE<= /u> award winning
debt consolidation email newsletter		 Yes    =   No
Approximate total amount owed to creditors:
Is this business or personal debt?
(Either is acceptable)		 Personal      <= input name=3D"Business Debt" type=3D"checkbox" value=3D"ON"> Business    Both
Name of creditor or bank:
(do not= give account number)		 <= font color=3D"#000000">Creditor #1
Amount Owed to Creditor#1
Monthly Payment
<= br> Type of Debt

How Many Months Are You Behind?
*********
Creditor #2

Amount Owed to Creditor#2
Monthly Payment
=
Type of Debt

How Many Months Are You Behind?
*********
Creditor #3

Amount Owed to Creditor#3
Monthly Payment
=
Type of Debt

How Many Months Are You Behind?
*********
Creditor #4

Amount Owed to Creditor#4
Monthly Payment
=
Type of Debt

How Many Months Are You Behind?
*********
Creditor #5

Amount Owed to Creditor#5
Monthly Payment
=
Type of Debt

How Many Months Are You Behind?
*********
Creditor #6

Amount Owed to Creditor#6
Monthly Payment
=
Type of Debt

How Many Months Are You Behind?
*********
Please enter a short description of your debit/credit problem:

=

 


List Removal/OPT-OUT Option
Click Here ------=_NextPart_001_0080_01BDF6C7.FABAC1B0-- ------=_NextPart_000_007F_01BDF6C7.FABAC1B0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Aug 6 02:10:49 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07910 for ; Sun, 6 Aug 2000 02:10:48 -0400 (EDT) Received: from standards (47.234.32.16:4546) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85683@standards.nortelnetworks.com>; 6 Aug 2000 1:58:39 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10027 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 6 Aug 2000 01:58:39 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85682@standards.nortelnetworks.com>; 6 Aug 2000 1:48:38 -0400 Received: from tf-exchange.ajilontf.co.uk (mail.ajilontf.co.uk [212.89.84.3]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id BAA21856 for ; Sun, 6 Aug 2000 01:00:05 -0500 (CDT) Received: from 897hn9807 (cincinnati-ip-2-187.dynamic.ziplink.net [216.8.21.187]) by tf-exchange.ajilontf.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id PRKXLQA8; Sun, 6 Aug 2000 07:00:10 +0100 Message-ID: <200008062691FAA21534@qwsderfg6j.ajilontf.co.uk> Date: Sun, 6 Aug 2000 01:00:05 -0500 Reply-To: Kevin Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: Authenticated sender is From: Kevin Subject: [MOBILE-IP] Confidential To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM UNIVERSITY DIPLOMAS Obtain a prosperous future, money earning power, and the admiration of all. Diplomas from prestigious non-accredited universities based on your present knowledge and life experience. No required tests, classes, books, or interviews. Bachelors, masters, MBA, and doctorate (PhD) diplomas available in the field of your choice. No one is turned down. Confidentiality assured. CALL NOW to receive your diploma within days!!! 1-212-465-3248 Call 24 hours a day, 7 days a week, including Sundays and holidays. rem- sector_85b@adexec.com 571508119050275722851 ç From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Aug 7 03:33:34 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22875 for ; Mon, 7 Aug 2000 03:33:34 -0400 (EDT) Received: from standards (47.234.32.16:2216) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB858CB@standards.nortelnetworks.com>; Mon, 7 Aug 2000 3:20:51 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10739 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Aug 2000 03:20:51 -0400 Received: from hotmail.com (f62.law3.hotmail.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB858C8@standards.nortelnetworks.com>; Mon, 7 Aug 2000 3:10:50 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 7 Aug 2000 00:22:21 -0700 Received: from 131.170.6.141 by lw3fd.law3.hotmail.msn.com with HTTP; Mon, 07 Aug 2000 GMT X-Originating-IP: [131.170.6.141] Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 07 Aug 2000 07:22:21.0582 (UTC) FILETIME=[39E882E0:01C00040] Message-ID: Date: Mon, 7 Aug 2000 17:22:21 EST Reply-To: opamps cybernetics Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: opamps cybernetics Subject: [MOBILE-IP] UMIP questions To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Dear Gurus, Some questions: 1) When location chain is established between the HA and the mobile node, is every node in-between supposed to download from the Home Agent and keep a copy of informations such as user profile, AAA etc? 2) How does this help when the MN is idle and taken to a "new" foreign network far away from the "old" foreign network? The new location chain may have to be completely redrawn, right? Thank you very much in advance... Opamps ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Aug 7 08:09:16 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13765 for ; Mon, 7 Aug 2000 08:09:16 -0400 (EDT) Received: from standards (47.234.32.16:2138) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85943@standards.nortelnetworks.com>; Mon, 7 Aug 2000 7:16:57 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10886 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Aug 2000 07:16:56 -0400 Received: from ns.et.ntust.edu.tw by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85942@standards.nortelnetworks.com>; Mon, 7 Aug 2000 7:06:51 -0400 Received: from et.ntust.edu.tw (et.et.ntust.edu.tw [140.118.2.55]) by ns.et.ntust.edu.tw (8.9.3/8.9.3) with ESMTP id TAA05896; Mon, 7 Aug 2000 19:14:27 +0800 (CST) Received: from et.ntust.edu.tw (ppp-mac.et.ntust.edu.tw [140.118.122.5]) by et.ntust.edu.tw (8.8.8/8.8.8) with ESMTP id TAA14937; Mon, 7 Aug 2000 19:08:35 +0800 (CST) X-Mailer: Mozilla 4.7 (Macintosh; I; PPC) X-Accept-Language: zh-TW,pdf MIME-Version: 1.0 References: <200006082004.QAA27918@euler.cs.albany.edu> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Message-ID: <398E9A39.B487E337@et.ntust.edu.tw> Date: Mon, 7 Aug 2000 19:15:06 +0800 Reply-To: "Y.-C. Lin" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Y.-C. Lin" Organization: NTUST Subject: Re: [MOBILE-IP] [DMANET] DIAL M Workshop -- Call for Participation X-To: "S.S.Ravi" X-cc: im-net-digest@IWR.UNI-HEIDELBERG.DE, itc@ieee.org, manet@itd.nrl.navy.mil, mobility@media.mit.edu, opt-net@ZIB.DE, orcs-l@listserv.okstate.edu, podc-post@research.telcordia.com, tccc@ieee.org, theorynt@listserv.nodak.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit PRELIMINARY CALL FOR PAPERS The Second International Conference on Parallel and Distributed Computing, Applications, and Techniques (PDCAT 2001) July 9-11, 2001, Taipei, Taiwan Sponsors: IEEE Taipei Chapter, Institute of Information and Computing Machinery (Taiwan), and National Taiwan University of Science and Technology. More sponsors may be added. PURPOSE The International Conference on Parallel and Distributed Computing, Applications, and Techniques (PDCAT) is a major forum for scientists, engineers, and practitioners throughout the world to present the latest research, results, ideas, development, applications, and techniques in all areas of parallel and distributed computing. PDCAT 2001 will be held in Taipei, Taiwan, and will include keynote addresses, contributed papers, tutorials, and workshops. SCOPE The main focus for PDCAT 2001 will be parallel and distributed computing and networks viewed from the three perspectives of networks and architectures, software systems, and algorithms and applications. Topics include, but are not limited to, the following: Networks and Architectures -------------------------- * Interconnection networks * Computer networks * Internet computing * Parallel/distributed architectures * Communication and telecommunication * Heterogeneous and multimedia Systems * Wireless networks and mobile computing * ATM networks * Optical networks * Reliability and fault-tolerance * Security * Cluster computing Software Systems ---------------- * Operating systems * Programming languages * Parallel programming paradigms * Parallelizing compilers * Distributed data and knowledge based systems * Object-Oriented technology * Modelling and simulation * Performance evaluation and measurements * Distributed agent systems * Tools and environments for software development * Visualization Algorithms and Applications --------------------------- * Parallel/distributed algorithms * Resource allocation and management * Load sharing and balancing * Task mapping and job scheduling * Network routing and communication algorithms * Neural networks * Image processing and computer graphics * Database applications and data mining * High-performance scientific computing * Biological/molecular computing SUBMISSION OF PAPERS Papers reporting original and unpublished research results and experience are solicited. The cover page of each paper should include (1) title of the paper; (2) full name, affiliation, postal address, e-mail address, phone number, and fax number of each author; (3) name of the corresponding author; (4) an abstract; and (5) keywords, at least one of them from the list of topics. Papers must not exceed 20 double-spaced pages, including tables and figures. Please send your papers in the PostScript or PDF format as an attachment to your submission e-mail to the program chair at yclin@et.ntust.edu.tw or yclin@computer.org. Submission of a paper should be regarded as an undertaking that, should the paper be accepted, at least one of the authors will attend the conference to present the work. EVALUATION PROCESS Papers will be reviewed by at least two referees and selected based on their originality, significance, relevance, timeliness, and clarity of presentation. Accepted papers will be published in the conference proceedings. WORKSHOPS/SPECIAL SESSIONS/TUTORIALS/PANELS Workshops/special sessions and tutorials are planned for PDCAT 2001. Each workshop will focus on a particular topic, and consists of several presentations and open discussion. A one-page abstract of each workshop presentation will be published in the conference proceedings. The proposal for a workshop/special session should include the title, topics covered, proposed/invited speakers, and estimated length (hours) of the workshop. Each tutorial proposal should provide the title, topics, targeted audiences, and instructor's biography. Anyone wishing to organize a workshop, special session, panel, or tutorial should submit a proposal by January 1, 2001 to the general and program chairs, Hong Shen and Yen-Chun Lin. GENERAL CHAIR Hong Shen School of Computing and Information Technology Griffith University Nathan, QLD 4111 Australia E-mail: hong@cit.gu.edu.au PROGRAM CHAIR Yen-Chun Lin Department of Electronic Engineering National Taiwan Univ. of Sci. & Tech. P.O. Box 90-100, Taipei 106 Taiwan E-mail: yclin@computer.org or yclin@et.ntust.edu.tw Phone: 886-2-2737-6377 PROGRAM VICE-CHAIRS Susumu Horiguchi Japan Advanced Inst. of Sci. & Tech. (Japan) Feipei Lai National Taiwan University (Taiwan) Francis Lau University of Hong Kong (Hong Kong) IMPORTANT DATES Paper and Proposal Submissions Due: January 1, 2001 Notification of Acceptance/Rejection: March 1, 2001 Camera-ready Papers Due: April 15, 2001 For more information or to be placed on the mailing list, please contact the program chair. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Aug 7 09:31:18 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11909 for ; Mon, 7 Aug 2000 09:31:17 -0400 (EDT) Received: from standards (47.234.32.16:4517) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB859A2@standards.nortelnetworks.com>; Mon, 7 Aug 2000 9:19:01 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 11002 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Aug 2000 09:19:00 -0400 Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB859A1@standards.nortelnetworks.com>; Mon, 7 Aug 2000 9:18:59 -0400 Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e77DUTs16170; Mon, 7 Aug 2000 16:30:29 +0300 (EET DST) Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com [172.18.242.183]) by mgw-i2.ntc.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e77DUBu04845; Mon, 7 Aug 2000 16:30:21 +0300 (EET DST) Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id ; Mon, 7 Aug 2000 08:30:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E17D@daeis07nok> Date: Mon, 7 Aug 2000 08:27:18 -0500 Reply-To: Basavaraj.Patil@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: Re: [MOBILE-IP] Handoff framework [Was Re: [MOBILE-IP] Another no vice questions!] X-To: ramjee@DNRC.BELL-LABS.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Ram, >Hello, > >Here is my take on fast handoffs. There has been a spate of >drafts recently on handoff support and the working group is >trying to unify them to one proposal. While the net >outcome of this might indeed be one draft, that ONE DRAFT WILL >END UP LISTING MULTIPLE HANDOFF SOLUTIONS FOR DIFFERENT LINK >LAYER/WIRELESS NETWORK SCENARIOS (this is one of the reasons >why we keep hearing objections from some quarters saying fast >handoff should be left to the link layer folks themselves and >not the mobileip wg!). > It is not the first time nor the last that we will hear that handoffs should be left to the link layers. If handoffs can be done better and more efficiently at the link layer then people will opt to do that and I do not see why anyone should object to this WG developing a solution for handoffs at the network layer. I disagree that the outcome of the current effort will be specific solutions for different types of link layers. Based on the scope and the parameters that we are working on we will limit getting into link layer details. >I think what we need is a FRAMEWORK FOR HANDLING MOBILITY LOCALLY. >Inside this framework, there must be freedom to tailor handoffs >in any way, based on link layer or other characteristics. This >framework will also allow registrations to be processed locally, >reducing signaling load to the home agent. Also, >such a framework will help support paging within the network agents >(which is another local function) and ipv6 (which will initially be >a local function as the transition from ipv4 takes place). > The comment here (biased) seems to lay the groundwork for proposals such as HAWAII and Cellular IP. >Currently, there are two such broad frameworks available: > >1) HAWAII/CIP - every local node is involved, no tunneling >2) HMIP/UMIP/RR - a few local nodes are involved, tunneling-based >overlay > >I think both frameworks are/can be made to look like rfc2002 >with similar security models. > >So, the real issue is do we want an overlay or not in the local wireless >access network? Once the wg decides on this, we can then decide on ONE >FRAMEWORK document that specifies how mobility is handled locally >(for example, if the decision is to use the overlay network approach, >we can then decide on merging the HMIP/UMIP/RR proposals). >THEN, fast handoffs and everything else will have a structure to >work with and we no longer need just one fast handoff standard. > You really need to look at the scope of the handoffs in the current work to get a better perspective of the framework and the solution space. >Comments please? > >Cheers, >Ram -Basavaraj From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Aug 7 11:11:01 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09288 for ; Mon, 7 Aug 2000 11:11:01 -0400 (EDT) Received: from standards (47.234.32.16:2795) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85A04@standards.nortelnetworks.com>; Mon, 7 Aug 2000 10:58:33 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 11131 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Aug 2000 10:58:33 -0400 Received: from crufty.research.bell-labs.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85A03@standards.nortelnetworks.com>; Mon, 7 Aug 2000 10:58:32 -0400 Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Mon Aug 7 11:08:37 EDT 2000 Received: from dnrc.bell-labs.com (IDENT:21257@ramjeepc [135.180.240.106]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id LAA23230; Mon, 7 Aug 2000 11:08:33 -0400 (EDT) X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.0.36 i686) X-Accept-Language: en MIME-Version: 1.0 References: <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E17D@daeis07nok> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <398ED123.6B68A8F8@dnrc.bell-labs.com> Date: Mon, 7 Aug 2000 15:09:24 +0000 Reply-To: ramjee@DNRC.BELL-LABS.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Ramachandran Ramjee Subject: Re: [MOBILE-IP] Handoff framework [Was Re: [MOBILE-IP] Another novicequestions!] X-To: Basavaraj.Patil@nokia.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Raj, Basavaraj Patil wrote: > > I disagree that the outcome of the current effort will be specific > solutions for different types of link layers. Based on the scope and > the parameters that we are working on we will limit getting into link > layer details. From the last handoff only meeting that I attended, the conclusion seemed to be that different proposals had different link characteristics in mind (for example, one proposal assumed coverage was overlapping so that registrations to new FA can go through old base station; one assumed link layer authentication etc.) and so different solutions made sense in different settings. > >I think what we need is a FRAMEWORK FOR HANDLING MOBILITY LOCALLY. > >Inside this framework, there must be freedom to tailor handoffs > >in any way, based on link layer or other characteristics. This > >framework will also allow registrations to be processed locally, > >reducing signaling load to the home agent. Also, > >such a framework will help support paging within the network agents > >(which is another local function) and ipv6 (which will initially be > >a local function as the transition from ipv4 takes place). > > > > The comment here (biased) seems to lay the groundwork for proposals > such as HAWAII and Cellular IP. > > >Currently, there are two such broad frameworks available: > > > >1) HAWAII/CIP - every local node is involved, no tunneling > >2) HMIP/UMIP/RR - a few local nodes are involved, tunneling-based > >overlay > > > >I think both frameworks are/can be made to look like rfc2002 > >with similar security models. Just to avoid the bias, I specifically stated that I consider both Hierarchical as well as Hawaii/CIP models are fine as frameworks - the bias is more on my belief that the wg needs to standardize on the framework before doing the handoffs standardization. Cheers, Ram From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Aug 7 11:22:39 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16576 for ; Mon, 7 Aug 2000 11:22:38 -0400 (EDT) Received: from standards (47.234.32.16:2795) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85A3C@standards.nortelnetworks.com>; Mon, 7 Aug 2000 11:10:15 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 11206 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Aug 2000 11:10:15 -0400 Received: from mgw-x1.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85A3B@standards.nortelnetworks.com>; Mon, 7 Aug 2000 11:10:14 -0400 Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60]) by mgw-x1.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e77FLak16108; Mon, 7 Aug 2000 18:21:36 +0300 (EET DST) Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-i1.ntc.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e77FLXV07633; Mon, 7 Aug 2000 18:21:33 +0300 (EET DST) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id ; Mon, 7 Aug 2000 10:18:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E184@daeis07nok> Date: Mon, 7 Aug 2000 10:18:45 -0500 Reply-To: Basavaraj.Patil@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: Re: [MOBILE-IP] Handoff framework X-cc: ramjee@DNRC.BELL-LABS.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Ram, >Hello Raj, > >Basavaraj Patil wrote: >> >> I disagree that the outcome of the current effort will be specific >> solutions for different types of link layers. Based on the scope and >> the parameters that we are working on we will limit getting into link >> layer details. > >From the last handoff only meeting that I attended, the conclusion >seemed to be that different proposals had different link >characteristics in mind (for example, one proposal assumed >coverage was overlapping so that registrations to new FA can go >through old base station; one assumed link layer authentication etc.) >and so different solutions made sense in different settings. I think the best thing here would be to clearly specify the scope and objectives of the handoff work being done within the WG. That will clear the haze, but just to reiterate a point : We will not worry about specific link layers in the handoff solution being addressed now (to ensure people stop discussing soft handoffs and make before break etc.). >> >I think what we need is a FRAMEWORK FOR HANDLING MOBILITY LOCALLY. >> >Inside this framework, there must be freedom to tailor handoffs >> >in any way, based on link layer or other characteristics. This >> >framework will also allow registrations to be processed locally, >> >reducing signaling load to the home agent. Also, >> >such a framework will help support paging within the network agents >> >(which is another local function) and ipv6 (which will initially be >> >a local function as the transition from ipv4 takes place). >> > >> >> The comment here (biased) seems to lay the groundwork for proposals >> such as HAWAII and Cellular IP. >> >> >Currently, there are two such broad frameworks available: >> > >> >1) HAWAII/CIP - every local node is involved, no tunneling >> >2) HMIP/UMIP/RR - a few local nodes are involved, tunneling-based >> >overlay >> > >> >I think both frameworks are/can be made to look like rfc2002 >> >with similar security models. > >Just to avoid the bias, I specifically stated that I consider >both Hierarchical as well as Hawaii/CIP models are fine as frameworks - >the bias is more on my belief that the wg needs to standardize on the >framework before doing the handoffs standardization. > Maybe. Let's see if the people working on the handoff mechanisms arrive at a similar conclusion. > >Cheers, >Ram -Basavaraj From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Aug 7 11:41:12 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28476 for ; Mon, 7 Aug 2000 11:41:12 -0400 (EDT) Received: from standards (47.234.32.16:2795) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85A91@standards.nortelnetworks.com>; Mon, 7 Aug 2000 11:28:21 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 11287 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Aug 2000 11:28:21 -0400 Received: from postal.jnpr.net (natint.juniper.net) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85A7A@standards.nortelnetworks.com>; Mon, 7 Aug 2000 11:18:20 -0400 Received: by postal.jnpr.net with Internet Mail Service (5.5.2650.21) id ; Mon, 7 Aug 2000 08:29:45 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: Date: Mon, 7 Aug 2000 08:29:36 -0700 Reply-To: Richard Holben Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Richard Holben Subject: [MOBILE-IP] To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM unsubscribe Regards Richard Holben UK and Ireland System Engineer Juniper Networks Mobile: +44 787 981 2055 Email: rholben@juniper.net -----Original Message----- From: Ramachandran Ramjee [mailto:ramjee@DNRC.BELL-LABS.COM] Sent: Monday, August 07, 2000 4:09 PM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] Handoff framework [Was Re: [MOBILE-IP] Another novicequestions!] Hello Raj, Basavaraj Patil wrote: > > I disagree that the outcome of the current effort will be specific > solutions for different types of link layers. Based on the scope and > the parameters that we are working on we will limit getting into link > layer details. From the last handoff only meeting that I attended, the conclusion seemed to be that different proposals had different link characteristics in mind (for example, one proposal assumed coverage was overlapping so that registrations to new FA can go through old base station; one assumed link layer authentication etc.) and so different solutions made sense in different settings. > >I think what we need is a FRAMEWORK FOR HANDLING MOBILITY LOCALLY. > >Inside this framework, there must be freedom to tailor handoffs > >in any way, based on link layer or other characteristics. This > >framework will also allow registrations to be processed locally, > >reducing signaling load to the home agent. Also, > >such a framework will help support paging within the network agents > >(which is another local function) and ipv6 (which will initially be > >a local function as the transition from ipv4 takes place). > > > > The comment here (biased) seems to lay the groundwork for proposals > such as HAWAII and Cellular IP. > > >Currently, there are two such broad frameworks available: > > > >1) HAWAII/CIP - every local node is involved, no tunneling > >2) HMIP/UMIP/RR - a few local nodes are involved, tunneling-based > >overlay > > > >I think both frameworks are/can be made to look like rfc2002 > >with similar security models. Just to avoid the bias, I specifically stated that I consider both Hierarchical as well as Hawaii/CIP models are fine as frameworks - the bias is more on my belief that the wg needs to standardize on the framework before doing the handoffs standardization. Cheers, Ram From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Aug 7 12:14:55 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18781 for ; Mon, 7 Aug 2000 12:14:55 -0400 (EDT) Received: from standards (47.234.32.16:2795) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85AEF@standards.nortelnetworks.com>; Mon, 7 Aug 2000 12:02:30 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 11404 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Aug 2000 12:02:29 -0400 Received: from ftpbox.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85AD6@standards.nortelnetworks.com>; Mon, 7 Aug 2000 11:52:24 -0400 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id JAA25802 for ; Mon, 7 Aug 2000 09:03:56 -0700 (MST)] Received: [from il35exm01.cig.mot.com (IL35EXM01.cig.mot.com [160.19.16.101]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id JAA26721 for ; Mon, 7 Aug 2000 09:03:55 -0700 (MST)] Received: by IL35EXM01.cig.mot.com with Internet Mail Service (5.5.2650.21) id ; Mon, 7 Aug 2000 11:03:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: Date: Mon, 7 Aug 2000 11:03:54 -0500 Reply-To: Wang John-EZW001 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Wang John-EZW001 Subject: Re: [MOBILE-IP] UMIP questions To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Dear Opamps Please see embedded answers marked by >>A:. Best regards, John -----Original Message----- From: opamps cybernetics [mailto:opamps@HOTMAIL.COM] Sent: Monday, August 07, 2000 5:22 PM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: [MOBILE-IP] UMIP questions Dear Gurus, Some questions: 1) When location chain is established between the HA and the mobile node, is every node in-between supposed to download from the Home Agent and keep a copy of informations such as user profile, AAA etc? >> A: It doesn't have to but if the operator wants it is possible. To keep a copy of the information on these nodes will speed up the following registrations, call connections and handoff processes associated with the MN. 2) How does this help when the MN is idle and taken to a "new" foreign network far away from the "old" foreign network? The new location chain may have to be completely redrawn, right? >> A: When a MN is roaming between Foreign domains, the location chain will be updated, for example, from the Home root node LRn down to LR1 in the NEW Foreign domain. A system performance is measured by statistics rather than the worst case (e.g. ERLANG's model). Simulations and performance evaluations showed that the overall performances such as delay, system capacity etc., have been significantly improved over the traditional solution. Hopefully, these will help in clarifying your concerns. Thank you very much in advance... Opamps ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Aug 7 12:54:25 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09810 for ; Mon, 7 Aug 2000 12:54:25 -0400 (EDT) Received: from standards (47.234.32.16:2159) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85B32@standards.nortelnetworks.com>; Mon, 7 Aug 2000 12:42:08 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 11521 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Aug 2000 12:42:08 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85B31@standards.nortelnetworks.com>; Mon, 7 Aug 2000 12:42:08 -0400 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 JAA05263; Mon, 7 Aug 2000 09:53:36 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e77GrYN14680; Mon, 7 Aug 2000 09:53:34 -0700 X-Virus-Scanned: Mon, 7 Aug 2000 09:53:34 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from maxdialin22.iprg.nokia.com (205.226.20.252, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdGTLvwc; Mon, 07 Aug 2000 09:53:28 PDT X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <398B0485.C9E94329@dnrc.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <398EE8BE.49EC55D5@iprg.nokia.com> Date: Mon, 7 Aug 2000 09:50:06 -0700 Reply-To: "Charles E. Perkins" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Subject: Re: [MOBILE-IP] Handoff framework [Was Re: [MOBILE-IP] Another novicequestions!] X-To: Ramachandran Ramjee To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Ram, I agree with what Basavaraj has said, but it's also possible that the _general_ layer-3 handover documents could have specific sections that were relevant for a subset of link layers. In any case, there should be clear statements of applicability. I do not think that Cellular-IP and HAWAII represent general frameworks for fast handover. I think they represent integrated solutions with features for supporting localized registration and fast/smooth handovers. For the former, I would really like it (being biased and all) if you would be able to make comments about how the current Regional Registration draft might or might not be useful for supporting the needs for HAWAII. Regards, Charlie P. Ramachandran Ramjee wrote: > Hello, > > Here is my take on fast handoffs. There has been a spate of > drafts recently on handoff support and the working group is > trying to unify them to one proposal. While the net > outcome of this might indeed be one draft, that ONE DRAFT WILL > END UP LISTING MULTIPLE HANDOFF SOLUTIONS FOR DIFFERENT LINK > LAYER/WIRELESS NETWORK SCENARIOS (this is one of the reasons > why we keep hearing objections from some quarters saying fast > handoff should be left to the link layer folks themselves and > not the mobileip wg!). > > I think what we need is a FRAMEWORK FOR HANDLING MOBILITY LOCALLY. > Inside this framework, there must be freedom to tailor handoffs > in any way, based on link layer or other characteristics. This > framework will also allow registrations to be processed locally, > reducing signaling load to the home agent. Also, > such a framework will help support paging within the network agents > (which is another local function) and ipv6 (which will initially be > a local function as the transition from ipv4 takes place). > > Currently, there are two such broad frameworks available: > > 1) HAWAII/CIP - every local node is involved, no tunneling > 2) HMIP/UMIP/RR - a few local nodes are involved, tunneling-based > overlay > > I think both frameworks are/can be made to look like rfc2002 > with similar security models. > > So, the real issue is do we want an overlay or not in the local wireless > access network? Once the wg decides on this, we can then decide on ONE > FRAMEWORK document that specifies how mobility is handled locally > (for example, if the decision is to use the overlay network approach, > we can then decide on merging the HMIP/UMIP/RR proposals). > THEN, fast handoffs and everything else will have a structure to > work with and we no longer need just one fast handoff standard. > > Comments please? > > Cheers, > Ram > > P.S. Answering your question on the popularity of different > micro-mobilty proposals, the ability to do all local functions > such as paging/fast handoffs/regional registrations etc. in one > framework in HAWAII/CIP is, I think, causing more resistance in the wg, > while in the Hierarchial approach, there is multiple drafts each > addressing one piece of the puzzle, making it easier to digest. > > Karann Chew wrote: > > > > Dear All, > > > > I noticed that proposals such as Cellular IP, HAWAII etc. (which seem to > > be able to solve fast handoff or micro-mobility or intro-domain > > mobility problem) are not favoured by a lot of people in MIP WG. Well, at > > least not as popular as drafts such as Route Optimzation, Regional > > Registration etc. Could someone please explain why. > > > > What I can think of are that RO, RR is more conform to RFC2002; have a > > more well-defined security procedures... > > > > Thanks in advance. Cheers! > > Karann > > > > > >3) Cellular-ip, HMIP and UMIP: Which one is better and why? > > > > > > I believe that I will not touch this one with a 10 foot pole. > > > > > > PatC > > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Aug 7 13:57:27 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17846 for ; Mon, 7 Aug 2000 13:57:27 -0400 (EDT) Received: from standards (47.234.32.16:2148) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85BB9@standards.nortelnetworks.com>; Mon, 7 Aug 2000 13:44:58 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 11696 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Aug 2000 13:44:58 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85BB8@standards.nortelnetworks.com>; Mon, 7 Aug 2000 13:44:57 -0400 Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Mon Aug 7 13:54:55 EDT 2000 Received: from dnrc.bell-labs.com (IDENT:21257@ramjeepc [135.180.240.106]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id NAA02627; Mon, 7 Aug 2000 13:54:53 -0400 (EDT) X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.0.36 i686) X-Accept-Language: en MIME-Version: 1.0 References: <398B0485.C9E94329@dnrc.bell-labs.com> <398EE8BE.49EC55D5@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <398EF81E.ADE80797@dnrc.bell-labs.com> Date: Mon, 7 Aug 2000 17:55:42 +0000 Reply-To: ramjee@DNRC.BELL-LABS.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Ramachandran Ramjee Subject: Re: [MOBILE-IP] Handoff framework [Was Re: [MOBILE-IP] Anothernovicequestions!] X-To: "Charles E. Perkins" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Charlie, I am not sure what your definition of handoff framework is. I meant a framework as a structure around which different handoff schemes can work - for example, in HAWAII, the structure is the access network itself, with the ability to support multiple handoff schemes (termed path setup schemes in the draft). Similarly, I think Hierarchical FA has a structure made up of FA's - my main issue with this is that a dynamic configuration/ failover protocol for the various FAs is necessary in order to not introduce new single-points-of-failure elements. Regarding your question about RR and HAWAII, I think the ability to separate authentication between local and home (with the admissible authentication term you added in the rfc2002-bis) is needed for all drafts that allow regional registration. Regarding messages/extensions defined in the RR draft - the GFA extension and the HFA extension are specific to RR...we could potentially make HAWAII messages also look similar with Old BS, New BS extension etc. Cheers, Ram "Charles E. Perkins" wrote: > > Hello Ram, > > I agree with what Basavaraj has said, but it's also possible that the > _general_ layer-3 handover documents could have specific sections > that were relevant for a subset of link layers. In any case, there > should be clear statements of applicability. > > I do not think that Cellular-IP and HAWAII represent general > frameworks for fast handover. I think they represent integrated > solutions with features for supporting localized registration and > fast/smooth handovers. > > For the former, I would really like it (being biased and all) if you > would be able to make comments about how the current Regional > Registration draft might or might not be useful for supporting the > needs for HAWAII. > > Regards, > Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Aug 7 16:05:35 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04096 for ; Mon, 7 Aug 2000 16:05:34 -0400 (EDT) Received: from standards (47.234.32.16:1938) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85C31@standards.nortelnetworks.com>; Mon, 7 Aug 2000 15:53:04 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0065 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Aug 2000 15:53:04 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85C30@standards.nortelnetworks.com>; Mon, 7 Aug 2000 15:53:04 -0400 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA07103; Mon, 7 Aug 2000 14:04:36 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA20228; Mon, 7 Aug 2000 13:04:35 -0700 (PDT) Received: from suntana (suntana [129.146.122.88]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id NAA21675; Mon, 7 Aug 2000 13:04:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: zitguc79qRXd1jOTjMuIuw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Message-ID: <200008072004.NAA21675@nasnfs.eng.sun.com> Date: Mon, 7 Aug 2000 13:09:13 -0700 Reply-To: James Kempf Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: James Kempf Subject: Re: [MOBILE-IP] Handoff framework [Was Re: [MOBILE-IP] Another novicequestions!] X-To: ramjee@DNRC.BELL-LABS.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM >> I disagree that the outcome of the current effort will be specific >> solutions for different types of link layers. Based on the scope and >> the parameters that we are working on we will limit getting into link >> layer details. > >From the last handoff only meeting that I attended, the conclusion >seemed to be that different proposals had different link >characteristics in mind (for example, one proposal assumed >coverage was overlapping so that registrations to new FA can go >through old base station; one assumed link layer authentication etc.) >and so different solutions made sense in different settings. > Fundamentally, I don't think there is any way to escape using link layer support for fast handoff. If the link layer doesn't provide any support, you are left with RFC 2002. Conversely, if the link layer provides support but L3 doesn't use it, then the potential for optimizing handoff is lost. I think it should be possible to characterize the link layer support at an abstract level as a collection of events available to L3 from L2 at a particular time and place, and with particular parameters. This avoids getting into specifics of a particular link layer and instead allows L3 mechanisms to be matched to their (abstract) L2 support. It may even provide designers of new radio link layers with some guidance about what they need to do to enable fast handoff at L3. jak From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Aug 7 18:29:45 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15754 for ; Mon, 7 Aug 2000 18:29:44 -0400 (EDT) Received: from standards (47.234.32.16:3117) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85D45@standards.nortelnetworks.com>; Mon, 7 Aug 2000 18:17:37 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0378 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Aug 2000 18:17:37 -0400 Received: from motgate.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85D3D@standards.nortelnetworks.com>; Mon, 7 Aug 2000 18:07:04 -0400 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id PAA08052 for ; Mon, 7 Aug 2000 15:18:34 -0700 (MST)] Received: [from az33exi01.corp.mot.com ([199.2.84.10]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id PAA26399 for ; Mon, 7 Aug 2000 15:18:33 -0700 (MST)] Received: by AZ33EXI01 with Internet Mail Service (5.5.2650.21) id <36ZGA5FV>; Mon, 7 Aug 2000 15:18:32 -0700 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <876DB976C8DAD211B6C50008C70774942617F1@az10exm02.sat.mot.com> Date: Mon, 7 Aug 2000 15:18:26 -0700 Reply-To: Collins Will-P26257 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Collins Will-P26257 Subject: [MOBILE-IP] To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Will Collins From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Aug 8 08:14:08 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03697 for ; Tue, 8 Aug 2000 08:14:08 -0400 (EDT) Received: from standards (47.234.32.16:4943) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85E83@standards.nortelnetworks.com>; Tue, 8 Aug 2000 5:58:42 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0778 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 8 Aug 2000 05:58:42 -0400 Received: from prue.eim.surrey.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85E7F@standards.nortelnetworks.com>; Tue, 8 Aug 2000 5:48:41 -0400 Received: from carter-e0.ee.surrey.ac.uk ([131.227.86.16]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 13M6BE-0006Dq-00; Tue, 08 Aug 2000 11:00:16 +0100 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Tue, 8 Aug 2000 11:00:16 +0100 Reply-To: Karann Chew Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Karann Chew Subject: Re: [MOBILE-IP] UMIP questions X-cc: Wang John-EZW001 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Hi John, I have another question regarding UMIP. A MN in foreign network needs to setup a chain from home network to its current LR, possibly through the gateway routers/LRs of the foreign and home network. Supposingly, the foreign and home network is connected through Internet, then, how could the chain between them be setup? To make my question clear... Refering to Figure 2 in : the connection between the two LRs at L4 could be the Internet. How is the chain being setup between them? Thanks in advance. Cheers! Karann ++++++++++++++++++++++++++++++++++++++++++ Karann Chew Mobile Communications Research Group Centre for Communication Systems Research University of Surrey ++++++++++++++++++++++++++++++++++++++++++ On Mon, 7 Aug 2000, Wang John-EZW001 wrote: > Dear Opamps > > Please see embedded answers marked by >>A:. > > Best regards, > > John > > -----Original Message----- > From: opamps cybernetics [mailto:opamps@HOTMAIL.COM] > Sent: Monday, August 07, 2000 5:22 PM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: [MOBILE-IP] UMIP questions > > > Dear Gurus, > > Some questions: > > 1) When location chain is established between the HA and the mobile node, is > every node in-between supposed to download from the Home Agent and keep a > copy of informations such as user profile, AAA etc? > > >> A: It doesn't have to but if the operator wants it is possible. To keep a > copy of the information on these nodes will speed up the following > registrations, call connections and handoff processes associated with the > MN. > > 2) How does this help when the MN is idle and taken to a "new" foreign > network far away from the "old" foreign network? The new location chain may > have to be completely redrawn, right? > > >> A: When a MN is roaming between Foreign domains, the location chain will > be updated, for example, from the Home root node LRn down to LR1 in the NEW > Foreign domain. A system performance is measured by statistics rather than > the worst case (e.g. ERLANG's model). Simulations and performance > evaluations showed that the overall performances such as delay, system > capacity etc., have been significantly improved over the traditional > solution. Hopefully, these will help in clarifying your concerns. > > Thank you very much in advance... > > Opamps > > ________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Aug 8 08:34:33 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16653 for ; Tue, 8 Aug 2000 08:34:33 -0400 (EDT) Received: from standards (47.234.32.16:3474) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85ECB@standards.nortelnetworks.com>; Tue, 8 Aug 2000 8:22:10 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0872 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 8 Aug 2000 08:22:10 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85ECA@standards.nortelnetworks.com>; Tue, 8 Aug 2000 8:22:09 -0400 Received: from esealnt406.al.sw.ericsson.se (esealnt406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e78CXgw17979 for ; Tue, 8 Aug 2000 14:33:43 +0200 (MEST) Received: from SMTP ([153.88.251.29]) by esealnt406.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1); Tue, 8 Aug 2000 14:33:42 +0200 Received: from esealnt400.al.sw.ericsson.se ([153.88.251.21]) by 153.88.251.29 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 08 Aug 2000 12:33:42 0000 (GMT) Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id ; Tue, 8 Aug 2000 14:33:39 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 08 Aug 2000 12:33:42.0956 (UTC) FILETIME=[E349B6C0:01C00134] Message-ID: <5F05C89FB2F8D211B6430008C791912703EA811B@esealnt190> Date: Tue, 8 Aug 2000 14:33:30 +0200 Reply-To: "Karim El-Malki (ERA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Karim El-Malki (ERA)" Subject: Re: [MOBILE-IP] Doubts from X-To: Karann Chew To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello Karann The MIPv4 and MIPv6 parts from the draft you are referring to have been made into separate drafts: draft-elmalki-mobileip-fast-handoffs-02 draft-soliman-mobileip-hmipv6-00 > Section 3, paragraph 3: > "If the packets for the MN are tunnelled from the HA, then > the GFA should > change the source and destination IP address of the > encapsulating header to the "next" FA towards the MN." > > Do the authors mean changing source address to GFA's address, whereas > destination address is changed to the address of the next FA > towards the > MN? Yes, thanks for pointing out the bad wording. > > Another question (which is not the main issue in this draft): > > Section 2, Paragraph 1 and 2 read: > "a MN may be attached directly to any FA within the hierarchy and may > move between FAs from different levels in the hierarchy. The > following > figure describes the Hierarchical MIPv4 network. > ________ > | | > | GFA | > |________| > / | \ > ... ... ... > ____|___ > | | > | FA3 | > |________| > ______/_ _\______ > | | | | > | FA2 | | FA1 | > |________| |________| > ____|___ ____|___ > | | | | > |AP/RAN 2| |AP/RAN 1| > |________| |________| > | ____|___ > | | > CN | MN | > |________| > > Figure 1: Multi-level Hierarchical MIPv4 domain. > > In the above figure, Access Points (APs) or Radio Access Networks > (RANs) consisting of multiple access points, are used to > provide a MN with > L2 access." > > Am I right to say that: when one states that a MN may be > attached to and > moved freely among FAs at different levels of the hierarchy (such > statement appears not only in this draft, but others such as > HAWAII), it > is assumed that all of the FAs are connected to some kind of Access > Points or RAN? So, the FA1, FA2, FA3 in figure above should > be connected > to some radio access points/network? > > If so, how's the network practically look like? Any example? What > about: Each FA is connecting to a WaveLan ?? How about the > appliciable of > these hierarchical architecture in a cellular network?? The figure above was modified in draft-elmalki-mobileip-fast-handoffs-02 and should reflect this more clearly. Comments welcome. Regards, Karim From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Aug 8 11:31:48 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20911 for ; Tue, 8 Aug 2000 11:31:48 -0400 (EDT) Received: from standards (47.234.32.16:3255) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85FB0@standards.nortelnetworks.com>; Tue, 8 Aug 2000 11:19:08 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1155 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 8 Aug 2000 11:19:07 -0400 Received: from sonne.darmstadt.gmd.de by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB85FAF@standards.nortelnetworks.com>; Tue, 8 Aug 2000 11:19:07 -0400 Received: from darmstadt.gmd.de (rho [141.12.34.56]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id RAA27671; Tue, 8 Aug 2000 17:30:41 +0200 (MET DST) X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: de,en,it MIME-Version: 1.0 References: <398B0485.C9E94329@dnrc.bell-labs.com> <398EE8BE.49EC55D5@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3990273D.71620B94@darmstadt.gmd.de> Date: Tue, 8 Aug 2000 17:29:01 +0200 Reply-To: Wolfgang Schoenfeld Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Wolfgang Schoenfeld Organization: GMD IPSI Darmstadt Deutschland Subject: Re: [MOBILE-IP] Handoff framework [Was Re: [MOBILE-IP] Anothernovicequestions!] To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Dear Colleagues, for the ongoing -very interesting- discussion on fast handoff, the following notion might be useful which we developed to better understand (and teach) the proposed solutions. We started from usual mobile networks, i.e. networks with frequently changing topology where routing has to be adapted appropriately. Most mobile networks like GSM have a tree-like structure, and their diameter (=maximal distance) is about 10. (Updating routing tables is hard for non-tree topologies.) Now, a virtual mobile network (VMN) is a mobile network residing, as a new layer, above a stationary network (e.g. IP). A link in the VMN is just a path (or set of thereof) in the underlying stationary network (tunnel). What singles out a VMN (from e.g. virtual private networks) is that its points of attachment to the underlying stationary network ("binding") may change. (Maybe, this is what "overlay" expresses in Ramachandran's Email.) Mobile IP is a VMN of diameter 3 (if we count CN--HA as 1 hop). It is not a tree (instead, it is a "clique" with 1-hop appendices). HMIP is a tree with unbounded (?) diameter, RR is one with diameter slightly larger than 3. CIP is ... This concept of a VMN helps to separate concerns, e.g. binding from routing table updates, and fits into the standard method of structuring by layers. Please note that I chose "diameter" just as an example of a discriminating parameter. Others are life-time of binding/routing entries etc. Wolfgang ----------------------------------------------- Wolfgang Schoenfeld, GMD-IPSI, +49-6151-869-865 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Aug 8 13:20:23 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04148 for ; Tue, 8 Aug 2000 13:20:22 -0400 (EDT) Received: from standards (47.234.32.16:1647) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8602D@standards.nortelnetworks.com>; Tue, 8 Aug 2000 13:07:32 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1294 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 8 Aug 2000 13:07:32 -0400 Received: from motgate.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB86019@standards.nortelnetworks.com>; Tue, 8 Aug 2000 12:57:18 -0400 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id KAA20573 for ; Tue, 8 Aug 2000 10:08:50 -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 KAA21512 for ; Tue, 8 Aug 2000 10:08:50 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2650.21) id ; Tue, 8 Aug 2000 12:08:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: Date: Tue, 8 Aug 2000 12:08:47 -0500 Reply-To: Wang John-EZW001 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Wang John-EZW001 Subject: Re: [MOBILE-IP] UMIP questions To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Karann, Please reference the following. http://search.ietf.org/internet-drafts/draft-wang-manet-umip-routing-00.txt Regards, John -----Original Message----- From: Karann Chew [mailto:k.chew@EIM.SURREY.AC.UK] Sent: Tuesday, August 08, 2000 5:00 AM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] UMIP questions Hi John, I have another question regarding UMIP. A MN in foreign network needs to setup a chain from home network to its current LR, possibly through the gateway routers/LRs of the foreign and home network. Supposingly, the foreign and home network is connected through Internet, then, how could the chain between them be setup? To make my question clear... Refering to Figure 2 in : the connection between the two LRs at L4 could be the Internet. How is the chain being setup between them? Thanks in advance. Cheers! Karann ++++++++++++++++++++++++++++++++++++++++++ Karann Chew Mobile Communications Research Group Centre for Communication Systems Research University of Surrey ++++++++++++++++++++++++++++++++++++++++++ On Mon, 7 Aug 2000, Wang John-EZW001 wrote: > Dear Opamps > > Please see embedded answers marked by >>A:. > > Best regards, > > John > > -----Original Message----- > From: opamps cybernetics [mailto:opamps@HOTMAIL.COM] > Sent: Monday, August 07, 2000 5:22 PM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: [MOBILE-IP] UMIP questions > > > Dear Gurus, > > Some questions: > > 1) When location chain is established between the HA and the mobile node, is > every node in-between supposed to download from the Home Agent and keep a > copy of informations such as user profile, AAA etc? > > >> A: It doesn't have to but if the operator wants it is possible. To keep a > copy of the information on these nodes will speed up the following > registrations, call connections and handoff processes associated with the > MN. > > 2) How does this help when the MN is idle and taken to a "new" foreign > network far away from the "old" foreign network? The new location chain may > have to be completely redrawn, right? > > >> A: When a MN is roaming between Foreign domains, the location chain will > be updated, for example, from the Home root node LRn down to LR1 in the NEW > Foreign domain. A system performance is measured by statistics rather than > the worst case (e.g. ERLANG's model). Simulations and performance > evaluations showed that the overall performances such as delay, system > capacity etc., have been significantly improved over the traditional > solution. Hopefully, these will help in clarifying your concerns. > > Thank you very much in advance... > > Opamps > > ________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Aug 8 16:53:09 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09505 for ; Tue, 8 Aug 2000 16:53:08 -0400 (EDT) Received: from standards (47.234.32.16:2118) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB860F9@standards.nortelnetworks.com>; Tue, 8 Aug 2000 16:40:34 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1562 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 8 Aug 2000 16:40:34 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB860F8@standards.nortelnetworks.com>; Tue, 8 Aug 2000 16:30:33 -0400 Received: from mail.pjc.com.my ([202.185.215.69]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id PAA09600 for ; Tue, 8 Aug 2000 15:42:08 -0500 (CDT) Received: from tcp ([209.206.57.11]) by mail.pjc.com.my (Netscape Messaging Server 3.5) with SMTP id 378; Wed, 9 Aug 2000 04:37:42 +0800 Received: from be5 [218.25.7.15] by zuptsvr2.Comm6.com.br (router,SLMail V2.5); Tues, 08 Aug 2000 22: 07:19 -0600 Sun, 6 Aug 2000 20: 32:27 +0000 (213.27.19.2: :mail daemon; unverified,SLMail V2.5); Sat, 03 Aug 1996 22:07:18 -0600 Sun, 6 Aug 2000 17: 48:09 -0300 Sun, 6 Aug 2000 21: 56:11 +1000 id AAA18556; Sun, 6 Aug 2000 17: 52:18 -0200 Sun, 6 Aug 2000 22: 49:41 +3000 with SMTP id 2000071609070974: 4936 ; Sun, 6 Aug 2000 17: 51:38 -0100 (SMTPD32-4.06) id A9583A500EE; Sun, 06 Aug 2000 22: 59:36 EST Message-ID: <20000808203317228.ABA342.378@tcp> Date: Wed, 9 Aug 2000 04:37:42 +0800 Reply-To: debt_mgt8@AUSI.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: debt_mgt8@AUSI.COM Subject: [MOBILE-IP] How to lower your monthly credit card bills by $100+ To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM FREE DEBT CONSOLIDATION QUOTE Receive A Free Debt Consolidation Quote To Consolidate Your Debt And Reduce Your Bills. You do not need to own a home. You Can Consolidate Your Unsecured Debts Regardless Of Your Credit Status We do not even perform a credit check. Debt Consolidation is not a loan. Our debt consolidation specialists may be able to: 1. Lower your monthly payment by $100 or more... 2. Give you a cushion so you can catch up... 3. Reduce interest payments from an average of 20% down to an average of 6% to 8% Who Can Consolidate? Anyone with $5000 or more qualifying *unsecured debt, residing in the United States, and seeking to rid their life of financial burden. * Unsecured debts are loans/accounts with no tangible property attached such as Credit Cards, medical bills, personal loans and closed utility accounts. All of these are eligible debts. However, cars, mortgages, RV's, taxes, judgments, alimony, student loans, rent and current utilities are NOT eligible for debt consolidation. For a FREE Debt Consolidation Quote, Simply Email Your Name: Phone#: and Best times to call: To mailto:freequote17@newmail.net A Debt Consolidation Associate will contact you only to process your free quote. Your phone number will not be used for any purpose other than this. This will not be a sales call. If you have no interest mailto:nothanks12@newmail.net From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Aug 8 21:32:27 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27036 for ; Tue, 8 Aug 2000 21:32:27 -0400 (EDT) Received: from standards (47.234.32.16:2458) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8618D@standards.nortelnetworks.com>; Tue, 8 Aug 2000 21:20:10 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1750 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 8 Aug 2000 21:20:09 -0400 Received: from cosmos.lgic.co.kr (203.247.146.130:43902) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8618C@standards.nortelnetworks.com>; Tue, 8 Aug 2000 21:10:08 -0400 Received: from AIJ038W ([150.150.60.168]) by cosmos.lgic.co.kr (8.8.8/8.8.8) with SMTP id KAA29173 for ; Wed, 9 Aug 2000 10:19:32 +0900 (KST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C001EB.95445680" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: <000f01c001a0$2a4da2a0$a83c9696@AIJ038W> Date: Wed, 9 Aug 2000 10:21:29 +0900 Reply-To: "Taeyong,Kim" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Taeyong,Kim" Organization: =?ks_c_5601-1987?B?TEfBpLq4xeu9xQ==?= Subject: [MOBILE-IP] Short description and Two question To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C001EB.95445680 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGkuIHJlY2VudGx5LCBJIHNjaGVtZWQgb3V0IGEgbmV3IGlkZWEgYWJvdXQgSEEuDQpUaGVuIEkg d2FudCB0byBrbm93IG15IGlkZWEgaXMgd29ydGguDQoNCnBsZWFzZSwgcmVhZCB0aGUgZm9sbG93 aW5nIHNob3J0IGRlc2NyaXB0aW9uIGFuZCBhbnN3ZXIgIHRoZQ0KcXVlc3Rpb24uXl47DQoNCkkg dGhpbmsgc3ViamVjdCBvZiBteSBpZGVhIGlzICJkaXN0cmlidXRlZCBIQSIuDQoNCnNob3J0IGRl c2NyaXB0aW9uIDoNCg0KIF9fX19fX18gICAgICAgICAgIF9fX19fICAgICAgICAgICAgICAgICAg ICBfX19fX18NCiB8IFJBICB8IC0tLS0tLSB8RkEgfCAtLS0tLS0tLS0tLSB8IE1OIHwNCiB8X19f X198ICAgICAgICApICB8X19ffCAgICAgICkpKSkpKSkpKSkpIHxfX19ffA0KICAgIHwgICAgICAg ICAgICAgICkNCiAgICB8ICAgICAgICAgICAgICkNCiBfX19fX19fICAgICkgICAgICAgICAgX19f X19fDQogfCBUQSAgICB8ICApICAgICAgICAgICAgfCBDTiB8DQogfF9fX19ffCAgKSkpKSkpKSkp KSB8X19fX3wNCg0KVEEgOiB0dW5uZWxpbmcgQWdlbnQNClJBIDogUmVnaXN0cmF0aW9uIEFnZW50 DQpIQSA6IEhvbWUgQWdlbnQNCkNOIDogQ29ycmVzcG9uZGVudCBOb2RlDQopIDogdHVubmVsaW5n IHByb2NlZHVyZSBmcm9tIENOIHRvIE1ODQotIDogcmVnaXN0cmF0aW9uIHByb2NlZHVyZSBiZXR3 ZWVuIFJBIGFuZCBNTiB2aWEgRkENCnwgOiBzeW5jaHJvbml6YXRpb24gcHJvY2VkdXJlIGJldHdl ZW4gUkEgYW5kIFRBDQoNClRBIDogdHVubmVsaW5nIEFnZW50DQpSQSA6IFJlZ2lzdHJhdGlvbiBB Z2VudA0KSEEgOiBIb21lIEFnZW50DQpDTiA6IENvcnJlc3BvbmRlbnQgTm9kZQ0KDQpNeSBJZGVh IGlzIHRoYXQgc2VwYXJhdGVzIHRoZSBIQSB0byB0d28gZnVuY3Rpb25hbCB1bml0IChUQSwgUkEp Lg0KVEEgaXMgVHVubmVsaW5nIEFnZW50IHR1bm5lbHMgdGhlIHBhY2tldCB0byBNTiBmcm9tIENO Lg0KUkEgaXMgUmVnaXN0cmF0aW9uIEFnZW50IHRoYXQga2VlcHMgYmluZGluZyBlbnRyaWVzIGZv ciBlYWNoIE1OIGFuZA0KUHJvY2VzcyB0aGUgUmVnaXN0cmF0aW9uIG1lc3NhZ2VzLg0KTm90ZTog VEEgbXVzdCBjb21tdW5pY2F0ZSB3aXRoIFJBIHRvIGtub3cgd2hlcmUgTU4gaXMuDQoNClNjZW5h cmlvOg0KUmVnaXN0cmF0aW9uOg0KMSkgTU4gc2VuZHMgdGhlIFJlZ2lzdHJhdGlvbiBSZXF1ZXN0 IHRvIFJBKGluaXRpYWxseSwgbmV0d29yayBwcmVmaXggIG9mIFJBDQphbmQgSEEgYXJlIHNhbWUs IHRoYXQgbWVhbnMgSEEgaXMgYmVsb25nIHRvIFJBKQ0KMikgUkEgc2VuZHMgdGhlIFJlZ2lzdHJh dGlvbiBSZXBseSB3aXRoIHRoZSBhZGRyZXNzIG9mIHByb3BlciBUQQ0KMykgRkEgcmVjZWl2ZXMg dGhlIHBhY2tldCBhbmQgcmVsYXlpbmcgdGhlIHBhY2tldCB0byB0aGUgTU4NCk5vdGU6IGFsbW9z dCBwcm9jZWR1cmVzIGFyZSBzYW1lIHdpdGggb3JpZ2luYWwgTW9iaWxlIElQDQpidXQgUkEgc2Vu ZHMgbW9kaWZpZWQgUmVnaXN0cmF0aW9uIFJlcGx5ICB0byBNTiB0aGF0IGNvbnRhaW5zDQp0aGUg YWRkaXRpb25hbCBpbmZvcm1hdGlvbiwgYWRkcmVzcyBvZiBUQS4NCkFsc28gUkEgZG9lcyBub3Qg YWR2ZXJ0aXNlIHRoZSBhZGRyZXNzIG9mIHJlZ2lzdGVyZWQgTU4gYnV0IFRBIGRvZXMuDQoNClNl bmRpbmcgcGFja2V0IHRvIE1OOg0KMSkgQ04gc2VuZHMgdGhlIHBhY2tldCB0byBNTg0KMikgVEEg aW50ZXJjZXB0cyB0aGUgcGFja2V0DQozKSBUQSBzZW5kcyB0aGUgU3luY2hyb25pemF0aW9uIFJl cXVlc3QgbWVzc2FnZSB0byBSQSB0byBrbm93IHdoZXJlIE1OIGlzLg0KNCkgVEEgcmVjZWl2ZXMg dGhlIFN5bmNocm9uaXphdGlvbiBSZXBseSBmcm9tIFJBLg0KNSkgVEEgdHVubmVscyBpdCB0byBG QQ0KNikgRkEgcmVsYXlzIGl0IHRvIE1ODQpOb2RlOiBzdGVwIDMpLCA0KSBpcyBhbHdheXMgcGVy Zm9ybWVkIHBlcmlvZGljYWxseS4NCg0KTWFqb3JpdHk6DQoxKSBUaGlzIGlkZWEgY2FuIHJlZHVj ZSB0aGUgbmV0d29yayB0cmFmZmljcy4NCjIpIFRoaXMgaWRlYSBjYW4gcmVkdWNlIHRoZSBsb2Fk IG9mIEhBIHRvIHNlcGFyYXRlIGl0IChSQSwgVEEpDQozKSBUaGlzIGlkZWEgY2FuIGludHJvZHVj ZSB0aGUgbmV3IHJvdXRpbmcgYWxnb3JpdGhtIChleDogZHluYW1pYyBIQSkNCjQpIGV0Yw0KTXkg cXVlc3Rpb24gaXM6DQoxKSBEb2VzIHNhbWUgb3Igc2ltaWxhciBpZGVhIGV4aXN0Pw0KMikgSXMg dGhpcyBpZGVhIGlzIHN1ZmZpY2llbnQgZm9yIHdyaXRpbmcgdGhlIFJGQyBvciBjb250cmlidXRp b24/DQoNCg0K ------=_NextPart_000_000C_01C001EB.95445680 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjAwLjI2MTQuMzUwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhpLiByZWNl bnRseSwgSSBzY2hlbWVkIG91dCBhIG5ldyBpZGVhIGFib3V0IEhBLjwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgc2l6ZT0yPlRoZW4gSSB3YW50IHRvIGtub3cgbXkgaWRlYSBpcyB3b3J0aC48L0ZP TlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+cGxlYXNlLCBy ZWFkIHRoZSBmb2xsb3dpbmcgc2hvcnQgZGVzY3JpcHRpb24gYW5kIGFuc3dlciZuYnNwOyANCnRo ZTwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPnF1ZXN0aW9uLl5eOzwvRk9OVD48L0RJ Vj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5JIHRoaW5rIHN1YmplY3Qg b2YgbXkgaWRlYSBpcyAiZGlzdHJpYnV0ZWQgSEEiLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7 PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5zaG9ydCBkZXNjcmlwdGlvbiA6PC9GT05UPjwvRElW Pg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPiZuYnNwO19fX19fX18mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQombmJzcDsgDQpf X19fXyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyANCl9fX19fXzxCUj4mbmJzcDt8IFJBJm5ic3A7IHwgLS0tLS0tIHxGQSB8IC0tLS0tLS0t LS0tIHwgTU4gDQp8PEJSPiZuYnNwO3xfX19fX3wmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5i c3A7Jm5ic3A7ICkmbmJzcDsgDQp8X19ffCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAp KSkpKSkpKSkpKSB8X19fX3w8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KfCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAgIA0K KTxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgDQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICANCik8QlI+Jm5ic3A7X19fX19f XyZuYnNwOyZuYnNwOyAgKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBfX19fX188QlI+Jm5ic3A7fCBUQSZuYnNwOyZuYnNwOyAgfCZuYnNwOyANCikm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5i c3A7IHwgQ04gDQp8PEJSPiZuYnNwO3xfX19fX3wmbmJzcDsgKSkpKSkpKSkpKSB8X19fX3w8L0ZP TlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+VEEgOiB0dW5u ZWxpbmcgQWdlbnQ8QlI+UkEgOiBSZWdpc3RyYXRpb24gQWdlbnQ8QlI+SEEgOiBIb21lIA0KQWdl bnQ8QlI+Q04gOiBDb3JyZXNwb25kZW50IE5vZGU8QlI+KSA6IHR1bm5lbGluZyBwcm9jZWR1cmUg ZnJvbSBDTiB0byBNTjxCUj4tIDogDQpyZWdpc3RyYXRpb24gcHJvY2VkdXJlIGJldHdlZW4gUkEg YW5kIE1OIHZpYSBGQTxCUj58IDogc3luY2hyb25pemF0aW9uIHByb2NlZHVyZSANCmJldHdlZW4g UkEgYW5kIFRBPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6 ZT0yPlRBIDogdHVubmVsaW5nIEFnZW50PEJSPlJBIDogUmVnaXN0cmF0aW9uIEFnZW50PEJSPkhB IDogSG9tZSANCkFnZW50PEJSPkNOIDogQ29ycmVzcG9uZGVudCBOb2RlPC9GT05UPjwvRElWPg0K PERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPk15IElkZWEgaXMgdGhhdCBzZXBh cmF0ZXMgdGhlIEhBIHRvIHR3byBmdW5jdGlvbmFsIHVuaXQgKFRBLCANClJBKS48QlI+VEEgaXMg VHVubmVsaW5nIEFnZW50IHR1bm5lbHMgdGhlIHBhY2tldCB0byBNTiBmcm9tIENOLjxCUj5SQSBp cyANClJlZ2lzdHJhdGlvbiBBZ2VudCB0aGF0IGtlZXBzIGJpbmRpbmcgZW50cmllcyBmb3IgZWFj aCBNTiBhbmQ8QlI+UHJvY2VzcyB0aGUgDQpSZWdpc3RyYXRpb24gbWVzc2FnZXMuPEJSPk5vdGU6 IFRBIG11c3QgY29tbXVuaWNhdGUgd2l0aCBSQSB0byBrbm93IHdoZXJlIE1OIA0KaXMuPC9GT05U PjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPlNjZW5hcmlvOjxC Uj5SZWdpc3RyYXRpb246PEJSPjEpIE1OIHNlbmRzIHRoZSBSZWdpc3RyYXRpb24gDQpSZXF1ZXN0 IHRvIFJBKGluaXRpYWxseSwgbmV0d29yayBwcmVmaXgmbmJzcDsgb2YgUkE8QlI+YW5kIEhBIGFy ZSBzYW1lLCB0aGF0IA0KbWVhbnMgSEEgaXMgYmVsb25nIHRvIFJBKTxCUj4yKSBSQSBzZW5kcyB0 aGUgUmVnaXN0cmF0aW9uIFJlcGx5IHdpdGggdGhlIGFkZHJlc3MgDQpvZiBwcm9wZXIgVEE8QlI+ MykgRkEgcmVjZWl2ZXMgdGhlIHBhY2tldCBhbmQgcmVsYXlpbmcgdGhlIHBhY2tldCB0byB0aGUg DQpNTjxCUj5Ob3RlOiBhbG1vc3QgcHJvY2VkdXJlcyBhcmUgc2FtZSB3aXRoIG9yaWdpbmFsIE1v YmlsZSBJUDxCUj5idXQgUkEgc2VuZHMgDQptb2RpZmllZCBSZWdpc3RyYXRpb24gUmVwbHkmbmJz cDsgdG8gTU4gdGhhdCBjb250YWluczxCUj50aGUgYWRkaXRpb25hbCANCmluZm9ybWF0aW9uLCBh ZGRyZXNzIG9mIFRBLjxCUj5BbHNvIFJBIGRvZXMgbm90IGFkdmVydGlzZSB0aGUgYWRkcmVzcyBv ZiANCnJlZ2lzdGVyZWQgTU4gYnV0IFRBIGRvZXMuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8 L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPlNlbmRpbmcgcGFja2V0IHRvIE1OOjxCUj4xKSBDTiBz ZW5kcyB0aGUgcGFja2V0IHRvIE1OPEJSPjIpIFRBIA0KaW50ZXJjZXB0cyB0aGUgcGFja2V0PEJS PjMpIFRBIHNlbmRzIHRoZSBTeW5jaHJvbml6YXRpb24gUmVxdWVzdCBtZXNzYWdlIHRvIFJBIA0K dG8ga25vdyB3aGVyZSBNTiBpcy48QlI+NCkgVEEgcmVjZWl2ZXMgdGhlIFN5bmNocm9uaXphdGlv biBSZXBseSBmcm9tIFJBLjxCUj41KSANClRBIHR1bm5lbHMgaXQgdG8gRkE8QlI+NikgRkEgcmVs YXlzIGl0IHRvIE1OPEJSPk5vZGU6IHN0ZXAgMyksIDQpIGlzIGFsd2F5cyANCnBlcmZvcm1lZCBw ZXJpb2RpY2FsbHkuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQg c2l6ZT0yPk1ham9yaXR5OjxCUj4xKSBUaGlzIGlkZWEgY2FuIHJlZHVjZSB0aGUgbmV0d29yayAN CnRyYWZmaWNzLjxCUj4yKSBUaGlzIGlkZWEgY2FuIHJlZHVjZSB0aGUgbG9hZCBvZiBIQSB0byBz ZXBhcmF0ZSBpdCAoUkEsIA0KVEEpPEJSPjMpIFRoaXMgaWRlYSBjYW4gaW50cm9kdWNlIHRoZSBu ZXcgcm91dGluZyBhbGdvcml0aG0gKGV4OiBkeW5hbWljIA0KSEEpPEJSPjQpIGV0YzxCUj5NeSBx dWVzdGlvbiBpczo8QlI+MSkgRG9lcyBzYW1lIG9yIHNpbWlsYXIgaWRlYSBleGlzdD88QlI+Mikg SXMgDQp0aGlzIGlkZWEgaXMgc3VmZmljaWVudCBmb3Igd3JpdGluZyB0aGUgUkZDIG9yIGNvbnRy aWJ1dGlvbj88L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXpl PTI+PC9GT05UPiZuYnNwOzwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_000C_01C001EB.95445680-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Aug 9 10:37:40 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04088 for ; Wed, 9 Aug 2000 10:37:40 -0400 (EDT) Received: from standards (47.234.32.16:3190) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8638D@standards.nortelnetworks.com>; Wed, 9 Aug 2000 10:24:35 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2384 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Aug 2000 10:24:35 -0400 Received: from motgate.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8638C@standards.nortelnetworks.com>; Wed, 9 Aug 2000 10:24:35 -0400 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id HAA21389 for ; Wed, 9 Aug 2000 07:36:13 -0700 (MST)] Received: [from il35exm01.cig.mot.com (IL35EXM01.cig.mot.com [160.19.16.101]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id HAA22245 for ; Wed, 9 Aug 2000 07:36:13 -0700 (MST)] Received: by IL35EXM01.cig.mot.com with Internet Mail Service (5.5.2650.21) id ; Wed, 9 Aug 2000 09:36:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 9 Aug 2000 09:36:10 -0500 Reply-To: Roberts Phil-QA3445 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Roberts Phil-QA3445 Subject: [MOBILE-IP] charter review To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM The chairs would like to refocus the Mobile IP WG objectives to protocols and solutions that are based on Mobile IP v4 and v6. The current objective in the charter of enhancing the protocol to make it suitable for deployment can be achieved if we simply focus on what needs to be done from the perspective of just Mobile IP as specified for IPv4 and IPv6. We believe that alternatives to Mobile IP for IP mobility are outside the scope of this WG. To this end we are proposing that we remove the micromobility bullet item from our charter. Removing this means that we are not going to be considering protocols that are not based of Mobile IP v4/6. The two specific protocols that are WG items currently that will drop out of scope immediately are Cellular IP and HAWAII. We would like to hear from WG members their opinions on this proposal. You should be aware that going forward there MAY or MAY NOT necessarily be another WG in the IETF to pick up this work although we feel that it is a topic that needs separate coverage. Phil and Basavaraj From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Aug 9 11:00:23 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07448 for ; Wed, 9 Aug 2000 11:00:23 -0400 (EDT) Received: from standards (47.234.32.16:3190) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB863CD@standards.nortelnetworks.com>; Wed, 9 Aug 2000 10:47:54 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2459 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Aug 2000 10:47:54 -0400 Received: from ftpbox.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB863C3@standards.nortelnetworks.com>; Wed, 9 Aug 2000 10:37:53 -0400 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id HAA12764 for ; Wed, 9 Aug 2000 07:49:29 -0700 (MST)] Received: [from il02dns1.comm.mot.com (il02dns1.comm.mot.com [145.1.3.2]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id HAA26303 for ; Wed, 9 Aug 2000 07:49:16 -0700 (MST)] Received: from cje011.mot.com ([173.14.15.182]) by il02dns1.comm.mot.com (8.9.3/8.9.3) with ESMTP id JAA00605; Wed, 9 Aug 2000 09:49:21 -0500 (CDT) X-Sender: lmps_mstr_1/cje011@il02exm21.comm.mot.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.3.2.7.2.20000809094746.00b0e7a0@il02exm21.comm.mot.com> Date: Wed, 9 Aug 2000 09:49:15 -0500 Reply-To: John Emmert Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: John Emmert Subject: Re: [MOBILE-IP] charter review X-To: Roberts Phil-QA3445 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: At 09:36 AM 8/9/00, Roberts Phil-QA3445 wrote: >We would like to hear from WG members their opinions on this >proposal. You should be aware that going forward there MAY or >MAY NOT necessarily be another WG in the IETF to pick up this work >although we feel that it is a topic that needs separate coverage. I agree, although to a large extent, I think the current IP4 solution is workable. The fact that we have it deployed and working may have something to do with that! :-) From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Aug 9 11:17:08 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08397 for ; Wed, 9 Aug 2000 11:17:07 -0400 (EDT) Received: from standards (47.234.32.16:3190) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB86412@standards.nortelnetworks.com>; Wed, 9 Aug 2000 11:04:35 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2565 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Aug 2000 11:04:34 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB86411@standards.nortelnetworks.com>; Wed, 9 Aug 2000 11:04:34 -0400 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA12541; Wed, 9 Aug 2000 09:15:55 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA03522; Wed, 9 Aug 2000 08:14:55 -0700 (PDT) Received: from suntana (suntana [129.146.122.88]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id IAA02967; Wed, 9 Aug 2000 08:14:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: g9+TtX7y2gyTBQI/TBprdw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Message-ID: <200008091514.IAA02967@nasnfs.eng.sun.com> Date: Wed, 9 Aug 2000 08:19:34 -0700 Reply-To: James Kempf Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: James Kempf Subject: Re: [MOBILE-IP] charter review X-To: qa3445@EMAIL.MOT.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Phil and Raj, I support this proposal, as I believe it will help focus the discussion on mobile IP as it exists and what is needed to make it deployable. I also would like to see another working group take up the micromobility proposals, and hope that the IESG will see fit approve a charter including it. jak >MIME-Version: 1.0 >Date: Wed, 9 Aug 2000 09:36:10 -0500 >From: Roberts Phil-QA3445 >Subject: [MOBILE-IP] charter review >To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > >The chairs would like to refocus the Mobile IP WG objectives to >protocols and solutions that are based on Mobile IP v4 and v6. The >current objective in the charter of enhancing the protocol to make it >suitable for deployment can be achieved if we simply focus on what >needs to be done from the perspective of just Mobile IP as specified >for IPv4 and IPv6. >We believe that alternatives to Mobile IP for IP mobility are outside >the scope of this WG. To this end we are proposing that we remove the >micromobility bullet item from our charter. Removing this means that >we are not going to be considering protocols that are not based of >Mobile IP v4/6. The two specific protocols that are WG items currently >that will drop out of scope immediately are Cellular IP and HAWAII. > >We would like to hear from WG members their opinions on this >proposal. You should be aware that going forward there MAY or >MAY NOT necessarily be another WG in the IETF to pick up this work >although we feel that it is a topic that needs separate coverage. > >Phil and Basavaraj From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Aug 9 12:43:57 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13156 for ; Wed, 9 Aug 2000 12:43:56 -0400 (EDT) Received: from standards (47.234.32.16:2031) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB86485@standards.nortelnetworks.com>; Wed, 9 Aug 2000 12:31:23 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2721 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Aug 2000 12:31:22 -0400 Received: from netmail.alcatel.com (hoste47a.alcatel.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB86484@standards.nortelnetworks.com>; Wed, 9 Aug 2000 12:21:22 -0400 Received: from relay1.usa.alcatel.com (relay1.usa.alcatel.com [143.209.238.6]) by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id LAA04815 for ; Wed, 9 Aug 2000 11:32:13 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by relay1.usa.alcatel.com (8.9.3/8.9.3) with ESMTP id LAA28900 for ; Wed, 9 Aug 2000 11:33:29 -0500 (CDT) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: fr,en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3991832D.BD945E21@usa.alcatel.com> Date: Wed, 9 Aug 2000 11:13:33 -0500 Reply-To: Laurence Rose Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Laurence Rose Organization: ALCATEL USA Corporate Research Center Subject: [MOBILE-IP] new draft "Simple Multicast Mobility Protocol" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Regards all, I would like to present a new draft on micro and macro mobility issues, available here: http://search.ietf.org/internet-drafts/draft-rose-mobileip-smm-00.txt It seems that this draft was not announced on this mailing list, so I guess this is convenient to advertise it myself. Best Regards Laurence Rose From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Aug 9 14:17:15 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15331 for ; Wed, 9 Aug 2000 14:17:15 -0400 (EDT) Received: from standards (47.234.32.16:4244) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB86517@standards.nortelnetworks.com>; Wed, 9 Aug 2000 14:04:36 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2912 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Aug 2000 14:04:36 -0400 Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB86516@standards.nortelnetworks.com>; Wed, 9 Aug 2000 14:04:34 -0400 Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Wed Aug 9 14:15:08 EDT 2000 Received: from dnrc.bell-labs.com (IDENT:21257@ramjeepc [135.180.240.106]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id OAA04312; Wed, 9 Aug 2000 14:15:06 -0400 (EDT) X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.0.36 i686) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3991A2E7.24C1DAC0@dnrc.bell-labs.com> Date: Wed, 9 Aug 2000 18:28:55 +0000 Reply-To: ramjee@DNRC.BELL-LABS.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Ramachandran Ramjee Subject: Re: [MOBILE-IP] charter review X-To: Roberts Phil-QA3445 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi Raj and Phil, Two quick points: 1) I believe Hierachical Mobile IP/ UMIP/Regional registrations etc. also solve the issues of micro-mobility. 2) HAWAII conforms to Mobile IP (the mobile host will not even know if HAWAII or Regional Registrations is operating in the access network). The messages between HAWAII only nodes can also be easily translated into messages similar to the ones used in the RR draft (Mobile IP messages with extensions) as I recently mentioned to Charlie. Thus, the only key difference between HAWAII and Regional Registrations is whether tunneling is used or not (i.e. overlay or not) in the local access network. If any protocol that does not use tunneling is outside of the scope of the Mobile IP wg, then I agree with you. Cheers, Ram Roberts Phil-QA3445 wrote: > > The chairs would like to refocus the Mobile IP WG objectives to > protocols and solutions that are based on Mobile IP v4 and v6. The > current objective in the charter of enhancing the protocol to make it > suitable for deployment can be achieved if we simply focus on what > needs to be done from the perspective of just Mobile IP as specified > for IPv4 and IPv6. > We believe that alternatives to Mobile IP for IP mobility are outside > the scope of this WG. To this end we are proposing that we remove the > micromobility bullet item from our charter. Removing this means that > we are not going to be considering protocols that are not based of > Mobile IP v4/6. The two specific protocols that are WG items currently > that will drop out of scope immediately are Cellular IP and HAWAII. > > We would like to hear from WG members their opinions on this > proposal. You should be aware that going forward there MAY or > MAY NOT necessarily be another WG in the IETF to pick up this work > although we feel that it is a topic that needs separate coverage. > > Phil and Basavaraj From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Aug 9 14:48:54 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16073 for ; Wed, 9 Aug 2000 14:48:53 -0400 (EDT) Received: from standards (47.234.32.16:4244) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB86579@standards.nortelnetworks.com>; Wed, 9 Aug 2000 14:36:30 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3039 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Aug 2000 14:36:30 -0400 Received: from ftpbox.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB86578@standards.nortelnetworks.com>; Wed, 9 Aug 2000 14:36:30 -0400 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id LAA07988 for ; Wed, 9 Aug 2000 11:48:06 -0700 (MST)] Received: [from il75exm02.cig.mot.com (IL75EXM02.cig.mot.com [136.182.110.102]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id LAA26543 for ; Wed, 9 Aug 2000 11:46:36 -0700 (MST)] Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2650.21) id ; Wed, 9 Aug 2000 13:46:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 9 Aug 2000 13:46:33 -0500 Reply-To: Roberts Phil-QA3445 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Roberts Phil-QA3445 Subject: [MOBILE-IP] 3g wireless advancing To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM So the IESG wants to know what status we're asking for on the 3g wireless extension draft. I think we had agreed to send it up as an experimental RFC, but wanted to double check. Phil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Aug 10 04:06:35 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12287 for ; Thu, 10 Aug 2000 04:06:35 -0400 (EDT) Received: from standards (47.234.32.16:3114) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8679B@standards.nortelnetworks.com>; Thu, 10 Aug 2000 3:54:06 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3735 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Aug 2000 03:54:06 -0400 Received: from exchange.ctmotion.com (192.117.173.134:13277) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8679A@standards.nortelnetworks.com>; Thu, 10 Aug 2000 3:44:04 -0400 Received: by exchange with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Aug 2000 10:54:55 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C002A8.A761CE20" Message-ID: <53151A2826D8D3119E9000508B8B782F2302AA@exchange> Date: Thu, 10 Aug 2000 10:54:55 +0200 Reply-To: Sagiv Draznin Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Sagiv Draznin Subject: [MOBILE-IP] To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM 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_01C002A8.A761CE20 Content-Type: text/plain; charset="windows-1255" where I can find network layout for mobile-ip Sagiv Draznin. System Engineering Manager. CTmotion LTD. Fax:972-3-9031973 Phone:972-3-9005971 Mobile:972-54-368011 E-Mail:sagiv@ctmotion.com Web:www.ctmotion.com ------_=_NextPart_001_01C002A8.A761CE20 Content-Type: text/html; charset="windows-1255"
where I can find network layout for mobile-ip
Sagiv Draznin.
System Engineering Manager.
  CTmotion LTD.
Fax:972-3-9031973
Phone:972-3-9005971
Mobile:972-54-368011
Web:www.ctmotion.com

 

------_=_NextPart_001_01C002A8.A761CE20-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Aug 10 18:17:08 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15143 for ; Thu, 10 Aug 2000 18:17:07 -0400 (EDT) Received: from standards (47.234.32.16:2292) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB869A3@standards.nortelnetworks.com>; Thu, 10 Aug 2000 18:04:44 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4366 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Aug 2000 18:04:44 -0400 Received: from omega.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB869A2@standards.nortelnetworks.com>; Thu, 10 Aug 2000 18:04:44 -0400 Received: from gopal.cisco.com (dhcp-171-70-57-70.cisco.com [171.70.57.70]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA25469; Thu, 10 Aug 2000 15:16:26 -0700 (PDT) X-Sender: gdommety@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <4.3.2.7.2.20000810152358.00c81eb0@omega.cisco.com> Date: Thu, 10 Aug 2000 15:24:21 -0700 Reply-To: Gopal Dommety Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gopal Dommety Subject: Re: [MOBILE-IP] 3g wireless advancing X-To: Roberts Phil-QA3445 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: I think it should be standards track. Thanks Gopal At 01:46 PM 09/08/00 -0500, Roberts Phil-QA3445 wrote: >So the IESG wants to know what status we're asking for on the 3g wireless >extension draft. I think we had agreed to send it up as an experimental >RFC, but wanted to double check. > >Phil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Aug 11 12:40:24 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25025 for ; Fri, 11 Aug 2000 12:40:23 -0400 (EDT) Received: from standards (47.234.32.16:3477) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB86C15@standards.nortelnetworks.com>; Fri, 11 Aug 2000 12:27:18 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5119 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Aug 2000 12:27:17 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB86C0C@standards.nortelnetworks.com>; Fri, 11 Aug 2000 12:17:16 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24560; Fri, 11 Aug 2000 12:29:00 -0400 (EDT) Message-ID: <200008111629.MAA24560@ietf.org> Date: Fri, 11 Aug 2000 12:29:00 -0400 Reply-To: iesg@ietf.org Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: The IESG Subject: [MOBILE-IP] Last Call: Mobile IP Based Micro Mobility Management Protocol in The Third Generation Wireless Network to Experimental To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM The IESG has received a request from the IP Routing for Wireless/Mobile Hosts Working Group to consider Mobile IP Based Micro Mobility Management Protocol in The Third Generation Wireless Network as an Experimental Protocol. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by August 25, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mobileip-3gwireless-ext-04.txt From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Aug 11 22:12:37 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11068 for ; Fri, 11 Aug 2000 22:12:37 -0400 (EDT) Received: from standards (47.234.32.16:2591) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB86DB6@standards.nortelnetworks.com>; Fri, 11 Aug 2000 21:59:59 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5689 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Aug 2000 21:59:58 -0400 Received: from hotmail.com (oe29.law7.hotmail.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB86DB5@standards.nortelnetworks.com>; Fri, 11 Aug 2000 21:49:58 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 11 Aug 2000 19:01:43 -0700 X-Originating-IP: [202.188.207.22] References: <4.3.2.7.2.20000810152358.00c81eb0@omega.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-OriginalArrivalTime: 12 Aug 2000 02:01:43.0654 (UTC) FILETIME=[43466860:01C00401] Message-ID: Date: Sat, 12 Aug 2000 10:08:33 +0800 Reply-To: Kai Ping Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Kai Ping Subject: [MOBILE-IP] unsubscribe To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit would smeone help me to unsubscribe? ----- Original Message ----- From: Gopal Dommety To: Sent: Friday, August 11, 2000 6:24 AM Subject: Re: [MOBILE-IP] 3g wireless advancing > I think it should be standards track. > > Thanks > Gopal > > > At 01:46 PM 09/08/00 -0500, Roberts Phil-QA3445 wrote: > >So the IESG wants to know what status we're asking for on the 3g wireless > >extension draft. I think we had agreed to send it up as an experimental > >RFC, but wanted to double check. > > > >Phil > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Aug 12 01:54:00 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20791 for ; Sat, 12 Aug 2000 01:53:59 -0400 (EDT) Received: from standards (47.234.32.16:1813) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB86E0E@standards.nortelnetworks.com>; Sat, 12 Aug 2000 1:41:40 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5808 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 12 Aug 2000 01:41:39 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB86E0D@standards.nortelnetworks.com>; Sat, 12 Aug 2000 1:31:39 -0400 Received: from [206.87.85.26] (machine2.city.langley.bc.ca [206.87.85.26] (may be forged)) by hosaka.smallworks.com (8.9.1/8.9.1) with SMTP id AAA02792 for ; Sat, 12 Aug 2000 00:43:24 -0500 (CDT) Received: from application.city.langley.bc.ca by [206.87.85.26] via smtpd (for hosaka.SmallWorks.COM [192.207.126.1]) with SMTP; 12 Aug 2000 05:54:11 UT Received: from firewall.city.langley.bc.ca ([192.1.1.249]) by application.city.langley.bc.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id QXK6N25X; Fri, 11 Aug 2000 22:43:18 -0700 Received: from sdn-ar-001njacitP305.dialsprint.net ([158.252.39.43]) by firewall.city.langley.bc.ca via smtpd (for application.city.langley.bc.ca [192.1.1.202]) with SMTP; 12 Aug 2000 05:53:54 UT Message-ID: <200008123083VAA36133@hygbvfds2a.city.langley.bc.ca> Date: Sat, 12 Aug 2000 00:43:24 -0500 Reply-To: Noemi Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: Authenticated sender is From: Noemi Subject: [MOBILE-IP] The Ultimate Spy Software!!! To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Cyber Investigator "EASY WAY TO FIND OUT ANYTHING ABOUT ANYONE" Cyber Investigator TAKES YOU BEYOND WHAT SEARCH ENGINES CAN DO! Cyber Investigator is an amazing new tool that allows you to find EVERYTHING you ever wanted to know about your EMPLOYEES, FRIENDS, RELATIVES, SPOUSE, NEIGHBORS, even your BOSS! You can check out ANYONE, ANYTIME, ANYWHERE, right on the internet... Here's the best part: With our SECURE ORDER SYSTEM you can have this amazing tool in your hands right away and you can be doing your own on-line investigations IMMEDIATELY. To find out more about what Cyber Investigator can do for YOU! CLICK HERE http://3463729345/55280.html Rem send email to simon4065@excite.com 30815082102716943082118 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Aug 12 08:28:53 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00562 for ; Sat, 12 Aug 2000 08:28:53 -0400 (EDT) Received: from standards (47.234.32.16:1568) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB86E98@standards.nortelnetworks.com>; Sat, 12 Aug 2000 8:16:36 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6000 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 12 Aug 2000 08:16:36 -0400 Received: from eas.fsimail.com (207.138.153.197:1344) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB86E95@standards.nortelnetworks.com>; Sat, 12 Aug 2000 8:06:35 -0400 Received: from SERVER2 by eas.fsimail.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id QF8KGALV; Sat, 12 Aug 2000 06:55:53 -0400 Received: from [131.133.108.114] by _[126.182.231.173]_by with SMTP id A34C1E3 Sat, 12 Aug 2000 06:39:24 PDT Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Message-ID: Date: Sat, 12 Aug 2000 08:16:36 -0400 Reply-To: otd2@EMAIL.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: otd2@EMAIL.COM Subject: [MOBILE-IP] Your Cellular Phone Injuring You? To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Do you want to learn how you can make your mobile phone safer?

If you have seen the news lately you realize that with each cellular phone call your health may be at risk. GOOD NEWS!!! Now there is a new patented and tested product that has just been introduced called the Wave Buster.

Click Here to learn more!

The Wave Buster has been proven to stop up to 70% of all harmful EMF rays and up to 90% of HEAT to your head. Why is this important? It has been proven that Radiation & EMF (Electro Magnetic Frequency) are emitted to your Head and Brain with each cellular phone call?

Click Here to learn more!


Have you see the latest reports on CNN, MSN, Extra and many more TV & Radio shows discussing the harmful effects of cellular phone use?

Click Here to learn more!


The Wave Buster has been proven to stop up to 70% of all harmful EMF rays and up to 90% of HEAT to your head from one simple product!
Check the Wave Buster out NOW!

If you have family and friends using a mobile phone, be sure to tell them about the
Wave Buster!


Committed to making wireless phones safer!
Click Here to learn more!





You were sent this message because your address is in our subscriber database. If you wish to be removed, please CLICK HERE and we will remove you from our subscriber list. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Aug 13 14:26:44 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12048 for ; Sun, 13 Aug 2000 14:26:44 -0400 (EDT) Received: from standards (47.234.32.16:1981) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB871D1@standards.nortelnetworks.com>; 13 Aug 2000 14:14:06 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7132 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 13 Aug 2000 14:14:06 -0400 Received: from prserv.net (out2.prserv.net) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB871CA@standards.nortelnetworks.com>; 13 Aug 2000 14:04:05 -0400 Received: from attglobal.net ([32.101.120.168]) by prserv.net (out2) with SMTP id <200008131815022290194o0je>; Sun, 13 Aug 2000 18:15:03 +0000 X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 References: <200008072004.NAA21675@nasnfs.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3996E445.6F86A0B6@attglobal.net> Date: Sun, 13 Aug 2000 13:09:09 -0500 Reply-To: sebastn@attglobal.net Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Sebastian Thalanany Subject: Re: [MOBILE-IP] Handoff framework [Was Re: [MOBILE-IP] Anothernovicequestions!] X-To: James Kempf To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit The use of an abstraction of link layer characteristics(ie. optional triggers etc.) to assist L3 is fundamental to the realization of efficient wireless mobile handoffs. I agree with Jim. Regards, Sebastian Thalanany James Kempf wrote: > >> I disagree that the outcome of the current effort will be specific > >> solutions for different types of link layers. Based on the scope and > >> the parameters that we are working on we will limit getting into link > >> layer details. > > > >From the last handoff only meeting that I attended, the conclusion > >seemed to be that different proposals had different link > >characteristics in mind (for example, one proposal assumed > >coverage was overlapping so that registrations to new FA can go > >through old base station; one assumed link layer authentication etc.) > >and so different solutions made sense in different settings. > > > > Fundamentally, I don't think there is any way to escape using link > layer support for fast handoff. If the link layer doesn't provide > any support, you are left with RFC 2002. Conversely, if the link > layer provides support but L3 doesn't use it, then the potential > for optimizing handoff is lost. > > I think it should be possible to characterize the link layer support > at an abstract level as a collection of events available to L3 from > L2 at a particular time and place, and with particular parameters. > This avoids getting into specifics of a particular link layer and > instead allows L3 mechanisms to be matched to their (abstract) L2 > support. > > It may even provide designers of new radio link layers with some guidance > about what they need to do to enable fast handoff at L3. > > jak From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Aug 13 14:52:16 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12256 for ; Sun, 13 Aug 2000 14:52:16 -0400 (EDT) Received: from standards (47.234.32.16:3965) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87205@standards.nortelnetworks.com>; 13 Aug 2000 14:40:00 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7211 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 13 Aug 2000 14:39:59 -0400 Received: from prserv.net (out2.prserv.net) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87204@standards.nortelnetworks.com>; 13 Aug 2000 14:39:59 -0400 Received: from [32.101.170.75] ([32.101.170.75]) by prserv.net (out2) with ESMTP id <200008131850582290194o3je>; Sun, 13 Aug 2000 18:50:58 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: ahmrphd@pop3.attglobal.net References: <200008072004.NAA21675@nasnfs.eng.sun.com> Message-ID: Date: Sun, 13 Aug 2000 11:52:05 -0700 Reply-To: Arthur Ross Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Arthur Ross Subject: Re: [MOBILE-IP] Handoff framework [Was Re: [MOBILE-IP] Anothernovicequestions!] To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <3996E445.6F86A0B6@attglobal.net> At 11:09 -0700 08/13/2000, Sebastian Thalanany wrote: >The use of an abstraction of link layer characteristics(ie. optional >triggers etc.) to assist L3 is fundamental to the realization >of efficient wireless mobile handoffs. I agree with Jim. > I support this as well. The trick, of course, is going to be coming up with that OOP- or WIN-like abstraction. And, like Jim said, in the attempt may lie a VERY USEFUL large-scale gedanken experiment in helping to clarify what the physical layer designers' problem(s) is(are), and how the legacy stuff either a) fits in, or b) can be patched up. This is, IMHO, precisely the sort of enlightened collective discussion of this problem that has been needed for a long time. -- Arthur Dr. Arthur H. M. Ross 2325 East Orangewood Avenue Phoenix, AZ 85020-4730 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Aug 14 09:21:33 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07024 for ; Mon, 14 Aug 2000 09:21:32 -0400 (EDT) Received: from standards (47.234.32.16:1231) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB873E6@standards.nortelnetworks.com>; Mon, 14 Aug 2000 9:08:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7834 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 14 Aug 2000 09:08:52 -0400 Received: from smtpgw2.sprintspectrum.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB873E5@standards.nortelnetworks.com>; Mon, 14 Aug 2000 9:08:51 -0400 Received: from pkcex003.sprintspectrum.com (pkcex003.sprintspectrum.com [208.10.75.138]) by smtpgw2.sprintspectrum.com (8.9.3/8.9.3) with ESMTP id IAA21558; Mon, 14 Aug 2000 08:20:28 -0500 (CDT) Received: by pkcex003.sprintspectrum.com with Internet Mail Service (5.5.2650.21) id ; Mon, 14 Aug 2000 08:20:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <2D11BCC7FFD8D3118FD70000D1ECDC8802FAE313@pkcexv018.sprintspectrum.com> Date: Mon, 14 Aug 2000 08:20:10 -0500 Reply-To: "Lipford, Mark" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Lipford, Mark" Subject: Re: [MOBILE-IP] 3g wireless advancing X-To: Roberts Phil-QA3445 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM As Gopal indicated Standards track would be great, but if that will slow it down let's go experimental and then we can move it to Standards Track once we have a few more implementations. Thanks Mark A. Lipford -----Original Message----- From: Roberts Phil-QA3445 [mailto:qa3445@EMAIL.MOT.COM] Sent: Wednesday, August 09, 2000 1:47 PM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: [MOBILE-IP] 3g wireless advancing So the IESG wants to know what status we're asking for on the 3g wireless extension draft. I think we had agreed to send it up as an experimental RFC, but wanted to double check. Phil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Aug 14 09:57:58 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08671 for ; Mon, 14 Aug 2000 09:57:57 -0400 (EDT) Received: from standards (47.234.32.16:1231) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87428@standards.nortelnetworks.com>; Mon, 14 Aug 2000 9:45:29 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7925 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 14 Aug 2000 09:45:29 -0400 Received: from gandalf.axion.bt.co.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87427@standards.nortelnetworks.com>; Mon, 14 Aug 2000 9:45:28 -0400 Received: from cbtlipnt01.btlabs.bt.co.uk by gandalf (local) with ESMTP; Mon, 14 Aug 2000 14:56:46 +0100 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2651.88) id <3GLRGC1T>; Mon, 14 Aug 2000 14:56:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.88) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C005F7.13EFFD90" Message-ID: <5104D4DBC598D211B5FE0000F8FE7EB2078A5A60@mbtlipnt02.btlabs.bt.co.uk> Date: Mon, 14 Aug 2000 14:53:51 +0100 Reply-To: george.tsirtsis@BT.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: George Tsirtsis Subject: [MOBILE-IP] FW: I-D ACTION:draft-oneill-handoff-state-00.txt X-To: craps@diameter.org, obast-list@cig.mot.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM ------_=_NextPart_000_01C005F7.13EFFD90 Content-type: text/plain; charset="us-ascii" All, You might want to check out a draft that appeared on the directory. This is an attempt to document what people might mean when they talk about "state transfers" between Access Routers during handoffs. We hope this is going to help discussion in CRAPS and other related groups. Enjoy George > -----Original Message----- > From: Internet-Drafts@ietf.org [SMTP:Internet-Drafts@ietf.org] > Sent: Monday, August 14, 2000 12:02 PM > To: IETF-Announce > Subject: I-D ACTION:draft-oneill-handoff-state-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : State transfer between Access Routes during > Handoff > Author(s) : A. O'Neill, G. Tsirtsis, S. Corson > Filename : draft-oneill-handoff-state-00.txt > Pages : 5 > Date : 11-Aug-00 > > This draft aims to document an issue raised in the Mobile IP working > group related to fast handoff between Access Routers. The fast > handoff work aims to rapidly enable IP service at the new access > router. In Mobile IP this implies that Binding Updates at the > network layer enable forwarding of packets to the new access router. > However, it may also imply other network layer activities because > the IP service given to the MN may depend on state which is > presently located in the old access router. This draft aims to > document the issue through examples so that the IETF can resolve how > to approach this issue. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-oneill-handoff-state-00.txt > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-oneill-handoff-state-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-oneill-handoff-state-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. <> ------_=_NextPart_000_01C005F7.13EFFD90 Content-type: message/rfc822 Content-Description: Untitled Attachment Date: Mon, 14 Aug 2000 13:56:57 +0000 To: Subject: Date: Mon, 14 Aug 2000 14:56:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.88) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C005F7.13EFFD90" ------_=_NextPart_002_01C005F7.13EFFD90 Content-type: text/plain; charset="us-ascii" ------_=_NextPart_002_01C005F7.13EFFD90 Content-type: application/octet-stream; name="ATT62183" Content-Disposition: attachment; filename="ATT62183" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000811101923.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-oneill-handoff-state-00.txt ------_=_NextPart_002_01C005F7.13EFFD90 Content-type: message/external-body; site="internet-drafts"; dir="draft-oneill-handoff-state-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C005F7.13EFFD90-- ------_=_NextPart_000_01C005F7.13EFFD90-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Aug 14 14:46:41 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16993 for ; Mon, 14 Aug 2000 14:46:40 -0400 (EDT) Received: from standards (47.234.32.16:1810) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8755B@standards.nortelnetworks.com>; Mon, 14 Aug 2000 14:33:48 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8322 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 14 Aug 2000 14:33:48 -0400 Received: from topaz.3com.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87554@standards.nortelnetworks.com>; Mon, 14 Aug 2000 14:23:47 -0400 Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e7EIZaH22610; Mon, 14 Aug 2000 11:35:36 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id e7EIZex03042; Mon, 14 Aug 2000 11:35:40 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 8825693B.006621D3 ; Mon, 14 Aug 2000 11:35:33 -0700 X-Lotus-FromDomain: 3COM Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <8825693B.00661DC2.00@hqoutbound.ops.3com.com> Date: Mon, 14 Aug 2000 13:37:54 -0500 Reply-To: Yingchun_Xu@3COM.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Yingchun_Xu@3COM.COM Subject: Re: [MOBILE-IP] Handoff framework [Was Re: [MOBILE-IP] Anothernovicequestions!] X-To: Arthur Ross To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM I agreed with Jim. In fact, the approach has been used to some extent in 3G cdma2000 wireless network. In general, there are two approachs to abstract an Access Network: 1. Abstract Link Layer Protocol: Defining an common link layer protocol to extend various Access Network to FA. By doing this, an FA will only need to understand the Abstract link layer protocol (or Abstract Access Network). Each Access Network will be responsible for translating (or mapping) its specific link layer to the Abstract link layer. In 3G cdma2000, the RP interface protocol (to some extent) is an extension of cdma2000 link layer. 2. Link Layer Specific FA: This will make every Access Network has its own specific FA. The FA will be fully knowledgable of a specific link layer (or Access Network). This method tries to abstract Access Network at network layer so that from HA point of view, all Access Network are same. Unfortunately, it makes Mobile IP depending on specific link layer. Method 1 is prefered since it makes Mobile IP independent of any specific link layer protocol (but still dependent of the common Abstract link layer). ---Yingchun. Arthur Ross on 08/13/2000 01:52:05 PM Please respond to Arthur Ross Sent by: Arthur Ross To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM cc: (Yingchun Xu/MW/US/3Com) Subject: Re: [MOBILE-IP] Handoff framework [Was Re: [MOBILE-IP] Anothernovicequestions!] At 11:09 -0700 08/13/2000, Sebastian Thalanany wrote: >The use of an abstraction of link layer characteristics(ie. optional >triggers etc.) to assist L3 is fundamental to the realization >of efficient wireless mobile handoffs. I agree with Jim. > I support this as well. The trick, of course, is going to be coming up with that OOP- or WIN-like abstraction. And, like Jim said, in the attempt may lie a VERY USEFUL large-scale gedanken experiment in helping to clarify what the physical layer designers' problem(s) is(are), and how the legacy stuff either a) fits in, or b) can be patched up. This is, IMHO, precisely the sort of enlightened collective discussion of this problem that has been needed for a long time. -- Arthur Dr. Arthur H. M. Ross 2325 East Orangewood Avenue Phoenix, AZ 85020-4730 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Aug 14 15:04:36 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17272 for ; Mon, 14 Aug 2000 15:04:35 -0400 (EDT) Received: from standards (47.234.32.16:1810) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB875A5@standards.nortelnetworks.com>; Mon, 14 Aug 2000 14:51:43 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8419 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 14 Aug 2000 14:51:43 -0400 Received: from eagle.aud.alcatel.com (host60d9.alcatel.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8759C@standards.nortelnetworks.com>; Mon, 14 Aug 2000 14:41:43 -0400 Received: from usa.alcatel.com by eagle.aud.alcatel.com (8.8.8+Sun/SMI-SVR4) id NAA08806; Mon, 14 Aug 2000 13:53:24 -0500 (CDT) X-Mailer: Mozilla 4.72 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 References: <8825693B.00661DC2.00@hqoutbound.ops.3com.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3998402F.497B4CEA@usa.alcatel.com> Date: Mon, 14 Aug 2000 13:53:35 -0500 Reply-To: Vincent Magret Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Vincent Magret Subject: Re: [MOBILE-IP] Handoff framework [Was Re: [MOBILE-IP]Anothernovicequestions!] To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit I will be in favor of the first solution. Vincent. Yingchun_Xu@3COM.COM wrote: > I agreed with Jim. In fact, the approach has been used to some extent in 3G > cdma2000 wireless network. > > In general, there are two approachs to abstract an Access Network: > 1. Abstract Link Layer Protocol: Defining an common link layer protocol to > extend various Access Network to FA. > By doing this, an FA will only need to understand the Abstract link layer > protocol (or Abstract Access Network). > Each Access Network will be > responsible for translating (or mapping) its specific link layer to the Abstract > link layer. > > In 3G cdma2000, the RP interface protocol (to some extent) is an extension of > cdma2000 link layer. > > 2. Link Layer Specific FA: This will make every Access Network has its own > specific FA. The FA will be fully > knowledgable of a specific link layer (or Access Network). This method tries to > abstract Access Network > at network layer so that from HA point of view, all Access Network are same. > Unfortunately, it makes Mobile IP > depending on specific link layer. > > Method 1 is prefered since it makes Mobile IP independent of any specific link > layer protocol (but still dependent of > the common Abstract link layer). > > ---Yingchun. > > Arthur Ross on 08/13/2000 01:52:05 PM > > Please respond to Arthur Ross > > Sent by: Arthur Ross > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > cc: (Yingchun Xu/MW/US/3Com) > Subject: Re: [MOBILE-IP] Handoff framework [Was Re: [MOBILE-IP] > Anothernovicequestions!] > > At 11:09 -0700 08/13/2000, Sebastian Thalanany wrote: > >The use of an abstraction of link layer characteristics(ie. optional > >triggers etc.) to assist L3 is fundamental to the realization > >of efficient wireless mobile handoffs. I agree with Jim. > > > I support this as well. The trick, of course, is going to be coming up with > that OOP- or WIN-like abstraction. And, like Jim said, in the attempt may > lie a VERY USEFUL large-scale gedanken experiment in helping to clarify > what the physical layer designers' problem(s) is(are), and how the legacy > stuff either a) fits in, or b) can be patched up. This is, IMHO, precisely > the sort of enlightened collective discussion of this problem that has been > needed for a long time. > > -- Arthur > > Dr. Arthur H. M. Ross > 2325 East Orangewood Avenue > Phoenix, AZ 85020-4730 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Aug 14 15:46:22 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17831 for ; Mon, 14 Aug 2000 15:46:22 -0400 (EDT) Received: from standards (47.234.32.16:3277) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB875E7@standards.nortelnetworks.com>; Mon, 14 Aug 2000 15:33:48 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8518 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 14 Aug 2000 15:33:48 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB875E6@standards.nortelnetworks.com>; Mon, 14 Aug 2000 15:33:47 -0400 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA09800; Mon, 14 Aug 2000 13:45:41 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA26227; Mon, 14 Aug 2000 12:45:40 -0700 (PDT) Received: from suntana (suntana [129.146.122.88]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id MAA25732; Mon, 14 Aug 2000 12:45:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 3mHONPXq6XICRX5/E8oDzA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Message-ID: <200008141945.MAA25732@nasnfs.eng.sun.com> Date: Mon, 14 Aug 2000 12:50:26 -0700 Reply-To: James Kempf Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: James Kempf Subject: Re: [MOBILE-IP] Handoff framework [Was Re: [MOBILE-IP] Anothernovicequestions!] X-To: Yingchun_Xu@3COM.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Yingchun, >In general, there are two approachs to abstract an Access Network: >1. Abstract Link Layer Protocol: Defining an common link layer protocol to >extend various Access Network to FA. > By doing this, an FA will only need to understand the Abstract link layer >protocol (or Abstract Access Network). >Each Access Network will be >responsible for translating (or mapping) its specific link layer to the Abstract >link layer. > >In 3G cdma2000, the RP interface protocol (to some extent) is an extension of >cdma2000 link layer. > >2. Link Layer Specific FA: This will make every Access Network has its own >specific FA. The FA will be fully >knowledgable of a specific link layer (or Access Network). This method tries to >abstract Access Network >at network layer so that from HA point of view, all Access Network are same. >Unfortunately, it makes Mobile IP >depending on specific link layer. > >Method 1 is prefered since it makes Mobile IP independent of any specific link >layer protocol (but still dependent of >the common Abstract link layer). These are implementation stratagies that can be useful, but I think they are somewhat independent of the specification. If the specification is developed in terms of an abstract description of the link layer, then implementors can choose one or the other of these implementation stratagies, or potentially another one. jak From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Aug 14 16:28:43 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18338 for ; Mon, 14 Aug 2000 16:28:42 -0400 (EDT) Received: from standards (47.234.32.16:1272) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8764F@standards.nortelnetworks.com>; Mon, 14 Aug 2000 16:15:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8606 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 14 Aug 2000 16:15:56 -0400 Received: from eagle.aud.alcatel.com (host60d9.alcatel.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87628@standards.nortelnetworks.com>; Mon, 14 Aug 2000 16:05:56 -0400 Received: from usa.alcatel.com by eagle.aud.alcatel.com (8.8.8+Sun/SMI-SVR4) id PAA09462; Mon, 14 Aug 2000 15:17:31 -0500 (CDT) X-Mailer: Mozilla 4.72 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <399853E5.AA7D3B81@usa.alcatel.com> Date: Mon, 14 Aug 2000 15:17:41 -0500 Reply-To: Vincent Magret Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Vincent Magret Subject: [MOBILE-IP] Draft for micro mobility X-cc: Vinod Choyi To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Greetings, We like to advertise the availability of a draft proposing a solution for micro mobility support. The proposal was presented during the last IETF meeting. The draft is retrievable at the following URL: http://search.ietf.org/internet-drafts/draft-magret-mobileip-mmm-00.txt Comments are welcomed. Vincent. PS: I know that there is a discussion about the micro mobility issue, but at this time I don't know another WG handling this debate, so I send it to the Mobile IP WG. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Aug 14 16:42:55 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18567 for ; Mon, 14 Aug 2000 16:42:55 -0400 (EDT) Received: from standards (47.234.32.16:1272) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8769A@standards.nortelnetworks.com>; Mon, 14 Aug 2000 16:30:17 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8763 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 14 Aug 2000 16:30:17 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87699@standards.nortelnetworks.com>; Mon, 14 Aug 2000 16:30:17 -0400 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA25475; Mon, 14 Aug 2000 14:42:09 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA04473; Mon, 14 Aug 2000 13:42:08 -0700 (PDT) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id NAA27367; Mon, 14 Aug 2000 13:42:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Mon, 14 Aug 2000 13:40:44 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: Re: [MOBILE-IP] Handoff framework [Was Re: [MOBILE-IP] Anothernovicequestions!] X-To: Yingchun_Xu@3COM.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <8825693B.00661DC2.00@hqoutbound.ops.3com.com> > I agreed with Jim. In fact, the approach has been used to some extent in 3G > cdma2000 wireless network. > > In general, there are two approachs to abstract an Access Network: > 1. Abstract Link Layer Protocol: Defining an common link layer protocol to > extend various Access Network to FA. > By doing this, an FA will only need to understand the Abstract link layer > protocol (or Abstract Access Network). > Each Access Network will be > responsible for translating (or mapping) its specific link layer to the > Abstract link layer. > > In 3G cdma2000, the RP interface protocol (to some extent) is an extension of > cdma2000 link layer. > > 2. Link Layer Specific FA: This will make every Access Network has its own > specific FA. The FA will be fully > knowledgable of a specific link layer (or Access Network). This method > tries to abstract Access Network > at network layer so that from HA point of view, all Access Network are same. > Unfortunately, it makes Mobile IP > depending on specific link layer. > > Method 1 is prefered since it makes Mobile IP independent of any specific > link layer protocol (but still dependent of > the common Abstract link layer). > So, let's see if I get this correct. You propose that each wireless standard try to figure out how to get Mobile IP working correctly, as opposed to Mobile IP providing a set of tools for the wireless standards people to use. Do you not believe that the IETF is where any Mobile IP work should be done? Do people really want to see solutions like the 3G ext, where PPP is carried in GRE, and god knows what other standard body comes up with, as opposed to a *single* nice clean solution? I much prefer #2 above, but I do not like the way you've put it. How about: "2. The Mobile IP WG will develop a single fast handoff strategy, that takes advantage of certain wireless technology capabilities. The document will include support for complex air interfaces (e.g. ones that provide air interface measurements), and simpler ones (e.g. ones that do not provide such measurements)." PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Aug 14 17:27:32 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18966 for ; Mon, 14 Aug 2000 17:27:32 -0400 (EDT) Received: from standards (47.234.32.16:2658) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB876EA@standards.nortelnetworks.com>; Mon, 14 Aug 2000 17:15:04 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8860 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 14 Aug 2000 17:15:03 -0400 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB876E1@standards.nortelnetworks.com>; Mon, 14 Aug 2000 17:05:02 -0400 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA16634; Mon, 14 Aug 2000 14:16:47 -0700 (PDT) Received: from atlantic.East.Sun.COM (atlantic.East.Sun.COM [129.148.174.27]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA03088; Mon, 14 Aug 2000 17:16:46 -0400 (EDT) Received: from onion.east.sun.com (onion [129.148.174.110]) by atlantic.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id RAA10590; Mon, 14 Aug 2000 17:16:45 -0400 (EDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Mon, 14 Aug 2000 17:16:39 -0400 Reply-To: Steven Glass - Solaris Software Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Steven Glass - Solaris Software Subject: Re: [MOBILE-IP] charter review X-To: Roberts Phil-QA3445 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" I support this 100%, and applaud this decision. This has been a problem for a long time now. The IETF solution for those who are upset is to hold a WG BOF, and try to figure out what that non-mobileip puzzle piece is shapped like. Cheers, Steve > The chairs would like to refocus the Mobile IP WG objectives to > protocols and solutions that are based on Mobile IP v4 and v6. The > current objective in the charter of enhancing the protocol to make it > suitable for deployment can be achieved if we simply focus on what > needs to be done from the perspective of just Mobile IP as specified > for IPv4 and IPv6. > > We believe that alternatives to Mobile IP for IP mobility are outside > the scope of this WG. To this end we are proposing that we remove the > micromobility bullet item from our charter. Removing this means that > we are not going to be considering protocols that are not based of > Mobile IP v4/6. The two specific protocols that are WG items currently > that will drop out of scope immediately are Cellular IP and HAWAII. > > We would like to hear from WG members their opinions on this > proposal. You should be aware that going forward there MAY or > MAY NOT necessarily be another WG in the IETF to pick up this work > although we feel that it is a topic that needs separate coverage. > > Phil and Basavaraj From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Aug 15 01:35:16 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00075 for ; Tue, 15 Aug 2000 01:35:15 -0400 (EDT) Received: from standards (47.234.32.16:4279) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8780F@standards.nortelnetworks.com>; Tue, 15 Aug 2000 1:22:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9214 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 15 Aug 2000 01:22:52 -0400 Received: from topaz.3com.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB877FF@standards.nortelnetworks.com>; Tue, 15 Aug 2000 1:12:51 -0400 Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e7F5OgH23274; Mon, 14 Aug 2000 22:24:42 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id e7F5Ok916301; Mon, 14 Aug 2000 22:24:46 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 8825693C.001DB92C ; Mon, 14 Aug 2000 22:24:39 -0700 X-Lotus-FromDomain: 3COM Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <8825693C.001DB719.00@hqoutbound.ops.3com.com> Date: Tue, 15 Aug 2000 00:27:07 -0500 Reply-To: Yingchun_Xu@3COM.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Yingchun_Xu@3COM.COM Subject: Re: [MOBILE-IP] Handoff framework [Was Re: [MOBILE-IP] Anothernovicequestions!] X-To: "pcalhoun@eng.sun.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Pat, I was not proposing each wireless standard body making Mobile IP work. On the contrary, I am proposing that each wireless standard body should map its Access Network specific link layer into a common Abstract link layer defined by Mobile IP WG. This will free Mobile IP from specific Link Layer dependent. This can be achieved by implementing a common link layer protocol extension. Without this common Link Layer protocol, each FA implementation will be dependent on each specific Link Layer. That's all I am trying to say. Hope I am not mislead you. God know how you come up so much conclusion. ---Yingchun. "pcalhoun/@eng.sun.com" Sent by: "pcalhoun@eng.sun.com" I agreed with Jim. In fact, the approach has been used to some extent in 3G > cdma2000 wireless network. > > In general, there are two approachs to abstract an Access Network: > 1. Abstract Link Layer Protocol: Defining an common link layer protocol to > extend various Access Network to FA. > By doing this, an FA will only need to understand the Abstract link layer > protocol (or Abstract Access Network). > Each Access Network will be > responsible for translating (or mapping) its specific link layer to the > Abstract link layer. > > In 3G cdma2000, the RP interface protocol (to some extent) is an extension of > cdma2000 link layer. > > 2. Link Layer Specific FA: This will make every Access Network has its own > specific FA. The FA will be fully > knowledgable of a specific link layer (or Access Network). This method > tries to abstract Access Network > at network layer so that from HA point of view, all Access Network are same. > Unfortunately, it makes Mobile IP > depending on specific link layer. > > Method 1 is prefered since it makes Mobile IP independent of any specific > link layer protocol (but still dependent of > the common Abstract link layer). > So, let's see if I get this correct. You propose that each wireless standard try to figure out how to get Mobile IP working correctly, as opposed to Mobile IP providing a set of tools for the wireless standards people to use. Do you not believe that the IETF is where any Mobile IP work should be done? Do people really want to see solutions like the 3G ext, where PPP is carried in GRE, and god knows what other standard body comes up with, as opposed to a *single* nice clean solution? I much prefer #2 above, but I do not like the way you've put it. How about: "2. The Mobile IP WG will develop a single fast handoff strategy, that takes advantage of certain wireless technology capabilities. The document will include support for complex air interfaces (e.g. ones that provide air interface measurements), and simpler ones (e.g. ones that do not provide such measurements)." PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Aug 15 02:06:17 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08531 for ; Tue, 15 Aug 2000 02:06:17 -0400 (EDT) Received: from standards (47.234.32.16:3464) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8784B@standards.nortelnetworks.com>; Tue, 15 Aug 2000 1:53:55 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9313 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 15 Aug 2000 01:53:55 -0400 Received: from hotmail.com (f29.law3.hotmail.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8784A@standards.nortelnetworks.com>; Tue, 15 Aug 2000 1:43:53 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 14 Aug 2000 22:55:49 -0700 Received: from 131.170.6.142 by lw3fd.law3.hotmail.msn.com with HTTP; Tue, 15 Aug 2000 GMT X-Originating-IP: [131.170.6.142] Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 15 Aug 2000 05:55:49.0175 (UTC) FILETIME=[764C1470:01C0067D] Message-ID: Date: Tue, 15 Aug 2000 15:55:49 EST Reply-To: opamps cybernetics Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: opamps cybernetics Subject: [MOBILE-IP] Mobile IP v4/6 and Micro-mobility schemes To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi, As far as I know, Mobile IP v4/6 require HA, FA and the tunneling concepts. How come this will make Cellular-IP and HAWAII out of spec? If I got it correct, both Cellular and HAWAII have HA, FA and tunneling concepts. They keep the same IP address for the MN and do not require global broadcast of their "new" address (scalibility problems). Can any body enlighten me why they are considered off-track? Thank you in advance. Opamps ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Aug 15 02:45:29 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08811 for ; Tue, 15 Aug 2000 02:45:29 -0400 (EDT) Received: from standards (47.234.32.16:1580) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87881@standards.nortelnetworks.com>; Tue, 15 Aug 2000 2:33:10 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9388 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 15 Aug 2000 02:33:09 -0400 Received: from cwcsun41.cwc.nus.edu.sg by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87880@standards.nortelnetworks.com>; Tue, 15 Aug 2000 2:23:08 -0400 Received: from tanhl ([172.16.2.68]) by cwcsun41.cwc.nus.edu.sg (8.9.3/8.9.3) with SMTP id OAA23157; Tue, 15 Aug 2000 14:34:12 +0800 (SGT) Received: by localhost with Microsoft MAPI; Tue, 15 Aug 2000 14:40:00 +0800 X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <01C006C6.B091A480.tanpaul@cwc.nus.edu.sg> Date: Tue, 15 Aug 2000 14:39:59 +0800 Reply-To: "tanpaul@cwc.nus.edu.sg" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Tan Hock Lai Paul Organization: CWC Subject: Re: [MOBILE-IP] Mobile IP v4/6 and Micro-mobility schemes X-To: opamps cybernetics To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi, Both Cellular IP and HAWAII are Micro-Mobility Management Protocol From my understanding, IPv4 requires a FA to be located at the foreign network. IPv6 doesn't require FA, thus the functionality of the FA is in mobile node (Thus, the end point of the tunnel is the mobile node itself). Mobile IP is designed to solve macro-mobility problem. Mobile IP faced a problem when a user move frequently (from one network to another), this action requires the mobile node to notify its HA of its new location even for small movement. To solve this problem, Cellular IP (similar concept to the Cellular System ) is developed. To the HA, the movement of the mobile node inside the Cellular network is transparent. Inside a Cellular IP network, no tunnelling is required. If a host sends a messages addressed to a mobile node, it will arrive at the HA, HA then tunnel the message to the Cellular Gateway (care-of-address for the mobile node) where it will de-tunnel and route it to the mobile node's Base Station and finally to the Mobile node. I hope this will help you. Regards Paul Tan -----Original Message----- From: opamps cybernetics [SMTP:opamps@HOTMAIL.COM] Sent: Wednesday, August 16, 2000 4:56 AM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: [MOBILE-IP] Mobile IP v4/6 and Micro-mobility schemes Hi, As far as I know, Mobile IP v4/6 require HA, FA and the tunneling concepts. How come this will make Cellular-IP and HAWAII out of spec? If I got it correct, both Cellular and HAWAII have HA, FA and tunneling concepts. They keep the same IP address for the MN and do not require global broadcast of their "new" address (scalibility problems). Can any body enlighten me why they are considered off-track? Thank you in advance. Opamps ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Aug 15 03:22:01 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09089 for ; Tue, 15 Aug 2000 03:22:00 -0400 (EDT) Received: from standards (47.234.32.16:3648) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB878C3@standards.nortelnetworks.com>; Tue, 15 Aug 2000 3:09:44 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9477 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 15 Aug 2000 03:09:44 -0400 Received: from sirius.ctr.columbia.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB878C2@standards.nortelnetworks.com>; Tue, 15 Aug 2000 2:59:44 -0400 Received: from cvn3 (cvn3.comet.columbia.edu [128.59.68.102]) by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with SMTP id DAA08672; Tue, 15 Aug 2000 03:11:38 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Message-ID: <003f01c00688$61a29de0$66443b80@cvn3.comet.columbia.edu> Date: Tue, 15 Aug 2000 03:13:57 -0400 Reply-To: Michael Kounavis Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Michael Kounavis Subject: Re: [MOBILE-IP] Handoff framework [Was Re: [MOBILE-IP] Anothernovicequestions!] X-To: Yingchun_Xu@3COM.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Dear colleagues: As a side note, modern software engineering can be used for implementing extensible and modular access network architectures, that incorporate many different levels of abstractions, including those that have been mentioned: For example, one can completely separate the handoff detection process -which implementation can be specific to the link layer used- from the handoff execution process which can be generic, independent of the layer two, and implement them as collection of software components that create bindings at run-time. We have done some work on these concepts at CoIlumbia as part of our reserach on programmable mobile networks. --Michael >I agreed with Jim. In fact, the approach has been used to some extent in 3G >cdma2000 wireless network. > >In general, there are two approachs to abstract an Access Network: >1. Abstract Link Layer Protocol: Defining an common link layer protocol to >extend various Access Network to FA. > By doing this, an FA will only need to understand the Abstract link layer >protocol (or Abstract Access Network). >Each Access Network will be >responsible for translating (or mapping) its specific link layer to the Abstract >link layer. > >In 3G cdma2000, the RP interface protocol (to some extent) is an extension of >cdma2000 link layer. > >2. Link Layer Specific FA: This will make every Access Network has its own >specific FA. The FA will be fully >knowledgable of a specific link layer (or Access Network). This method tries to >abstract Access Network >at network layer so that from HA point of view, all Access Network are same. >Unfortunately, it makes Mobile IP >depending on specific link layer. > >Method 1 is prefered since it makes Mobile IP independent of any specific link >layer protocol (but still dependent of >the common Abstract link layer). > >---Yingchun. > > > > > > >Arthur Ross on 08/13/2000 01:52:05 PM > >Please respond to Arthur Ross > >Sent by: Arthur Ross > > >To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM >cc: (Yingchun Xu/MW/US/3Com) >Subject: Re: [MOBILE-IP] Handoff framework [Was Re: [MOBILE-IP] > Anothernovicequestions!] > > > >At 11:09 -0700 08/13/2000, Sebastian Thalanany wrote: >>The use of an abstraction of link layer characteristics(ie. optional >>triggers etc.) to assist L3 is fundamental to the realization >>of efficient wireless mobile handoffs. I agree with Jim. >> >I support this as well. The trick, of course, is going to be coming up with >that OOP- or WIN-like abstraction. And, like Jim said, in the attempt may >lie a VERY USEFUL large-scale gedanken experiment in helping to clarify >what the physical layer designers' problem(s) is(are), and how the legacy >stuff either a) fits in, or b) can be patched up. This is, IMHO, precisely >the sort of enlightened collective discussion of this problem that has been >needed for a long time. > > -- Arthur > > Dr. Arthur H. M. Ross > 2325 East Orangewood Avenue > Phoenix, AZ 85020-4730 > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Aug 15 07:03:11 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10677 for ; Tue, 15 Aug 2000 07:03:11 -0400 (EDT) Received: from standards (47.234.32.16:1804) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB879B9@standards.nortelnetworks.com>; Tue, 15 Aug 2000 6:50:39 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9786 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 15 Aug 2000 06:50:38 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB879B2@standards.nortelnetworks.com>; Tue, 15 Aug 2000 6:40:38 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10544; Tue, 15 Aug 2000 06:52:33 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200008151052.GAA10544@ietf.org> Date: Tue, 15 Aug 2000 06:52:33 -0400 Reply-To: Internet-Drafts@ietf.org Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: [MOBILE-IP] I-D ACTION:draft-mccann-mobileip-limiph-00.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Low Interruption Mobile IP Handoff Author(s) : P. McCann, T. Hiller Filename : draft-mccann-mobileip-limiph-00.txt Pages : 12 Date : 14-Aug-00 There are currently a number of proposals for different mechanisms intended to reduce the overhead of IP mobility management. Generally speaking, the goal of these proposals is twofold: first, to reduce the latency or interruption due to handoffs; and second, to reduce the signaling load on the Mobile IP Home Agent (and Correspondent Nodes, for the case of Mobile IPv6). These techniques are meant to improve the performance of real-time applications like voice or video over IP over wireless networks. By minimizing the period of interruption during a handoff from one point of attachment to another, the proposals attempt to minimize packet loss when these events occur. This draft argues that the best solution to this problem is a 'transparent' one that requires no changes to the Mobile IP clients in mobile nodes and that gives control over routing functionality to the operator of a wireless network. We review some of the existing proposals and describe in detail a new proposal that can provide for low interruption handoffs in a more transparent manner. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mccann-mobileip-limiph-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-mccann-mobileip-limiph-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-mccann-mobileip-limiph-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000814134848.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mccann-mobileip-limiph-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-mccann-mobileip-limiph-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000814134848.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Aug 15 10:22:21 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15720 for ; Tue, 15 Aug 2000 10:22:21 -0400 (EDT) Received: from standards (47.234.32.16:1891) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87A62@standards.nortelnetworks.com>; Tue, 15 Aug 2000 10:09:49 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10011 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 15 Aug 2000 10:09:49 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87A61@standards.nortelnetworks.com>; Tue, 15 Aug 2000 10:09:49 -0400 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA11219; Tue, 15 Aug 2000 08:21:41 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA03736; Tue, 15 Aug 2000 07:21:02 -0700 (PDT) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA28315; Tue, 15 Aug 2000 07:20:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Tue, 15 Aug 2000 07:19:35 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: Re: [MOBILE-IP] Handoff framework [Was Re: [MOBILE-IP] Anothernovicequestions!] X-To: Michael Kounavis To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <003f01c00688$61a29de0$66443b80@cvn3.comet.columbia.edu> > Dear colleagues: > > As a side note, modern software engineering can be > used for implementing extensible and modular > access network architectures, that incorporate many > different levels of abstractions, including those that > have been mentioned: > > For example, one can completely separate the handoff detection > process -which implementation can be specific to the link layer used- > from the handoff execution process which can be generic, > independent of the layer two, and implement them as > collection of software components that create bindings at run-time. This appears to be what we had been proposing the WG should do. The basic idea is to come up with some basic capabilities that link layers have, which could be used to perform the handoff execution process. Since some link layers are more complex than others, some may provide better handoff performance. PatC > > We have done some work on these concepts at CoIlumbia as > part of our reserach on programmable mobile networks. > > --Michael > > > >I agreed with Jim. In fact, the approach has been used to some extent in 3G > >cdma2000 wireless network. > > > >In general, there are two approachs to abstract an Access Network: > >1. Abstract Link Layer Protocol: Defining an common link layer protocol to > >extend various Access Network to FA. > > By doing this, an FA will only need to understand the Abstract link layer > >protocol (or Abstract Access Network). > >Each Access Network will be > >responsible for translating (or mapping) its specific link layer to the > Abstract > >link layer. > > > >In 3G cdma2000, the RP interface protocol (to some extent) is an extension > of > >cdma2000 link layer. > > > >2. Link Layer Specific FA: This will make every Access Network has its own > >specific FA. The FA will be fully > >knowledgable of a specific link layer (or Access Network). This method > tries to > >abstract Access Network > >at network layer so that from HA point of view, all Access Network are > same. > >Unfortunately, it makes Mobile IP > >depending on specific link layer. > > > >Method 1 is prefered since it makes Mobile IP independent of any specific > link > >layer protocol (but still dependent of > >the common Abstract link layer). > > > >---Yingchun. > > > > > > > > > > > > > >Arthur Ross on 08/13/2000 01:52:05 PM > > > >Please respond to Arthur Ross > > > >Sent by: Arthur Ross > > > > > >To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > >cc: (Yingchun Xu/MW/US/3Com) > >Subject: Re: [MOBILE-IP] Handoff framework [Was Re: [MOBILE-IP] > > Anothernovicequestions!] > > > > > > > >At 11:09 -0700 08/13/2000, Sebastian Thalanany wrote: > >>The use of an abstraction of link layer characteristics(ie. optional > >>triggers etc.) to assist L3 is fundamental to the realization > >>of efficient wireless mobile handoffs. I agree with Jim. > >> > >I support this as well. The trick, of course, is going to be coming up with > >that OOP- or WIN-like abstraction. And, like Jim said, in the attempt may > >lie a VERY USEFUL large-scale gedanken experiment in helping to clarify > >what the physical layer designers' problem(s) is(are), and how the legacy > >stuff either a) fits in, or b) can be patched up. This is, IMHO, precisely > >the sort of enlightened collective discussion of this problem that has been > >needed for a long time. > > > > -- Arthur > > > > Dr. Arthur H. M. Ross > > 2325 East Orangewood Avenue > > Phoenix, AZ 85020-4730 > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Aug 15 11:13:08 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16662 for ; Tue, 15 Aug 2000 11:13:08 -0400 (EDT) Received: from standards (47.234.32.16:1284) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87AC9@standards.nortelnetworks.com>; Tue, 15 Aug 2000 11:00:38 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10147 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 15 Aug 2000 11:00:38 -0400 Received: from fw7.usa.alcatel.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87AC8@standards.nortelnetworks.com>; Tue, 15 Aug 2000 11:00:37 -0400 Received: (from uucp@localhost) by fw7.usa.alcatel.com (8.8.8+Sun/8.8.8) id KAA03079; Tue, 15 Aug 2000 10:09:41 -0500 (CDT) Received: from (relay2-alt.usa.alcatel.com [143.209.167.22]) by fw7 via smap (V2.1) id xma003008; Tue, 15 Aug 00 10:09:00 -0500 Received: from usa.alcatel.com (localhost [127.0.0.1]) by relay2.usa.alcatel.com (8.9.3/8.9.3) with ESMTP id KAA01225; Tue, 15 Aug 2000 10:13:40 -0500 (CDT) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: fr,en MIME-Version: 1.0 References: Content-Type: multipart/mixed; boundary="------------A9AFAEA391D661240CC88375" Message-ID: <39995914.48B2890E@usa.alcatel.com> Date: Tue, 15 Aug 2000 09:52:04 -0500 Reply-To: Laurence Rose Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Laurence Rose Organization: ALCATEL USA Corporate Research Center Subject: Re: [MOBILE-IP] charter review X-To: Steven Glass - Solaris Software To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------A9AFAEA391D661240CC88375 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Regarding our proposal which is aiming to support micro mobility as well as being based on Mobile IP v4 where it is supposed to be ... ? http://www.ietf.org/internet-drafts/draft-rose-mobileip-smm-00.txt Regard Laurence Rose REgar Steven Glass - Solaris Software wrote: > I support this 100%, and applaud this decision. This has been a problem > for a long time now. The IETF solution for those who are upset is to hold a > WG BOF, and try to figure out what that non-mobileip puzzle piece is shapped > like. > > Cheers, > Steve > > > The chairs would like to refocus the Mobile IP WG objectives to > > protocols and solutions that are based on Mobile IP v4 and v6. The > > current objective in the charter of enhancing the protocol to make it > > suitable for deployment can be achieved if we simply focus on what > > needs to be done from the perspective of just Mobile IP as specified > > for IPv4 and IPv6. > > > > We believe that alternatives to Mobile IP for IP mobility are outside > > the scope of this WG. To this end we are proposing that we remove the > > micromobility bullet item from our charter. Removing this means that > > we are not going to be considering protocols that are not based of > > Mobile IP v4/6. The two specific protocols that are WG items currently > > that will drop out of scope immediately are Cellular IP and HAWAII. > > > > We would like to hear from WG members their opinions on this > > proposal. You should be aware that going forward there MAY or > > MAY NOT necessarily be another WG in the IETF to pick up this work > > although we feel that it is a topic that needs separate coverage. > > > > Phil and Basavaraj --------------A9AFAEA391D661240CC88375 Content-Type: text/x-vcard; charset=us-ascii; name="Laurence.Rose.vcf" Content-Description: Card for Laurence Rose Content-Disposition: attachment; filename="Laurence.Rose.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rose;Laurence tel;work:972 996 3567 x-mozilla-html:FALSE url:www.alcatel.com org:ALCATEL USA Corporate Research Center adr:;;ALCATEL USA CRC - 1201 East Campbell Road - M/S 446-310;DALLAS;TEXAS;75081-1936;USA version:2.1 email;internet:Laurence.Rose@aud.alcatel.com title:Research Scientist fn:Laurence ROSE end:vcard --------------A9AFAEA391D661240CC88375-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Aug 15 11:59:19 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17737 for ; Tue, 15 Aug 2000 11:59:18 -0400 (EDT) Received: from standards (47.234.32.16:1574) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87B38@standards.nortelnetworks.com>; Tue, 15 Aug 2000 11:46:45 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10289 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 15 Aug 2000 11:46:45 -0400 Received: from thalia.fm.intel.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87B36@standards.nortelnetworks.com>; Tue, 15 Aug 2000 11:36:45 -0400 Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.30 2000/06/08 18:25:35 dmccart Exp $) with SMTP id PAA02276 for ; Tue, 15 Aug 2000 15:49:39 GMT Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.204 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 15 Aug 2000 15:48:41 0000 (GMT) Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2650.21) id <3X9R765L>; Tue, 15 Aug 2000 08:48:24 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4148FEAAD879D311AC5700A0C969E8901CC69F@orsmsx35.jf.intel.com> Date: Tue, 15 Aug 2000 08:48:16 -0700 Reply-To: "Iyer, Prakash" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Iyer, Prakash" Subject: [MOBILE-IP] Mobile IP through NAT and firewalls To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Can someone point me to previous / current work on enabling mobile IP through NAT gateways and firewalls (could be drafts, research work). Thanks in advance. -Prakash From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Aug 15 12:03:12 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17973 for ; Tue, 15 Aug 2000 12:03:12 -0400 (EDT) Received: from standards (47.234.32.16:1574) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87B47@standards.nortelnetworks.com>; Tue, 15 Aug 2000 11:48:07 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10290 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 15 Aug 2000 11:48:07 -0400 Received: from ganymede.or.intel.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87B37@standards.nortelnetworks.com>; Tue, 15 Aug 2000 11:38:07 -0400 Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.30 2000/06/08 18:25:35 dmccart Exp $) with SMTP id IAA03415 for ; Tue, 15 Aug 2000 08:50:02 -0700 (PDT) Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 15 Aug 2000 15:50:02 0000 (GMT) Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 15 Aug 2000 08:50:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4148FEAAD879D311AC5700A0C969E8901CC69B@orsmsx35.jf.intel.com> Date: Tue, 15 Aug 2000 08:43:35 -0700 Reply-To: "Iyer, Prakash" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Iyer, Prakash" Subject: [MOBILE-IP] Mobile IP and NAT/firewall traversal To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Has some work been done on getting mobile IP to work through NAT and firewalls. If so, pointers to drafts or research work would be appreciated. Please respond to prakash.iyer@intel.com Thanks in advance. -Prakash Iyer From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Aug 15 12:33:44 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18538 for ; Tue, 15 Aug 2000 12:33:43 -0400 (EDT) Received: from standards (47.234.32.16:1574) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87BCD@standards.nortelnetworks.com>; Tue, 15 Aug 2000 12:21:01 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10455 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 15 Aug 2000 12:21:01 -0400 Received: from motgate.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87BB0@standards.nortelnetworks.com>; Tue, 15 Aug 2000 12:11:00 -0400 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id JAA01100 for ; Tue, 15 Aug 2000 09:22:57 -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 JAA00541 for ; Tue, 15 Aug 2000 09:22:57 -0700 (MST)] Received: from ripcord756 (d50-6e57.cig.mot.com [160.44.110.87]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id QRJPVV83; Tue, 15 Aug 2000 11:22:57 -0500 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Message-ID: Date: Tue, 15 Aug 2000 11:28:29 -0500 Reply-To: Ajoy Singh Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Ajoy Singh Subject: Re: [MOBILE-IP] Handoff framework [Was Re: [MOBILE-IP] Anothernovicequestions!] X-To: Yingchun_Xu@3COM.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <8825693C.001DB719.00@hqoutbound.ops.3com.com> Content-Transfer-Encoding: 7bit Hi All, I also agree with the idea of link layer trigger being used to trigger mobile/IP handover. I also think it is possible to define a common link layer extension to make FA implementation independent of link layer details. I guess it might be enough to define a link layer primitive which will be sent from link layer to network layer whenever handover event is detected. The handover draft can define what it expects in the link layer handover primitive. It will be job of the respective link layers to provide the information required by handover primitive to layer 3. This way the foreign agent implementation will be independent of link layer. I am not in favor of proposing complete new RP like protocol between radio access network and foreign agent as generic protocol might not be suitable to different access technologies and moreover Mobile/IP may not be right place to define such link layer protocol extension. In case of CDMA 2000, RP may be extended to accommodate information required by handover primitive. Any suggestions ? regards, ajoy -----Original Message----- From: IP Routing for Wireless/Mobile Hosts (mobile-ip) [mailto:MOBILE-IP@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Yingchun_Xu@3COM.COM Sent: Tuesday, August 15, 2000 12:27 AM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] Handoff framework [Was Re: [MOBILE-IP] Anothernovicequestions!] Pat, I was not proposing each wireless standard body making Mobile IP work. On the contrary, I am proposing that each wireless standard body should map its Access Network specific link layer into a common Abstract link layer defined by Mobile IP WG. This will free Mobile IP from specific Link Layer dependent. This can be achieved by implementing a common link layer protocol extension. Without this common Link Layer protocol, each FA implementation will be dependent on each specific Link Layer. That's all I am trying to say. Hope I am not mislead you. God know how you come up so much conclusion. ---Yingchun. "pcalhoun/@eng.sun.com" Sent by: "pcalhoun@eng.sun.com" I agreed with Jim. In fact, the approach has been used to some extent in 3G > cdma2000 wireless network. > > In general, there are two approachs to abstract an Access Network: > 1. Abstract Link Layer Protocol: Defining an common link layer protocol to > extend various Access Network to FA. > By doing this, an FA will only need to understand the Abstract link layer > protocol (or Abstract Access Network). > Each Access Network will be > responsible for translating (or mapping) its specific link layer to the > Abstract link layer. > > In 3G cdma2000, the RP interface protocol (to some extent) is an extension of > cdma2000 link layer. > > 2. Link Layer Specific FA: This will make every Access Network has its own > specific FA. The FA will be fully > knowledgable of a specific link layer (or Access Network). This method > tries to abstract Access Network > at network layer so that from HA point of view, all Access Network are same. > Unfortunately, it makes Mobile IP > depending on specific link layer. > > Method 1 is prefered since it makes Mobile IP independent of any specific > link layer protocol (but still dependent of > the common Abstract link layer). > So, let's see if I get this correct. You propose that each wireless standard try to figure out how to get Mobile IP working correctly, as opposed to Mobile IP providing a set of tools for the wireless standards people to use. Do you not believe that the IETF is where any Mobile IP work should be done? Do people really want to see solutions like the 3G ext, where PPP is carried in GRE, and god knows what other standard body comes up with, as opposed to a *single* nice clean solution? I much prefer #2 above, but I do not like the way you've put it. How about: "2. The Mobile IP WG will develop a single fast handoff strategy, that takes advantage of certain wireless technology capabilities. The document will include support for complex air interfaces (e.g. ones that provide air interface measurements), and simpler ones (e.g. ones that do not provide such measurements)." PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Aug 15 13:59:01 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20630 for ; Tue, 15 Aug 2000 13:59:01 -0400 (EDT) Received: from standards (47.234.32.16:4804) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87C38@standards.nortelnetworks.com>; Tue, 15 Aug 2000 13:46:21 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10634 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 15 Aug 2000 13:46:21 -0400 Received: from motgate.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87C37@standards.nortelnetworks.com>; Tue, 15 Aug 2000 13:46:21 -0400 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id KAA17205 for ; Tue, 15 Aug 2000 10:58:18 -0700 (MST)] Received: [from il75exm02.cig.mot.com (IL75EXM02.cig.mot.com [136.182.110.102]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id KAA18569 for ; Tue, 15 Aug 2000 10:58:17 -0700 (MST)] Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2650.21) id ; Tue, 15 Aug 2000 12:58:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Tue, 15 Aug 2000 12:58:16 -0500 Reply-To: Roberts Phil-QA3445 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Roberts Phil-QA3445 Subject: Re: [MOBILE-IP] Handoff framework [Was Re: [MOBILE-IP] Anothernovicequestions!] To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > You propose that each wireless standard try to figure out how > to get Mobile IP > working correctly, as opposed to Mobile IP providing a set of > tools for the > wireless standards people to use. > > Do you not believe that the IETF is where any Mobile IP work > should be done? > Do people really want to see solutions like the 3G ext, where > PPP is carried > in GRE, and god knows what other standard body comes up with, > as opposed to a > *single* nice clean solution? No doubt we're doing work to support speeding up handovers in systems that use MIP for IP layer mobility. The extent of our success will probably be seen in what other standards bodies choose to do with what we complete. So we need to do a good job in a timely manner. > > I much prefer #2 above, but I do not like the way you've put > it. How about: > > "2. The Mobile IP WG will develop a single fast handoff > strategy, that takes > advantage of certain wireless technology capabilities. The > document will > include support for complex air interfaces (e.g. ones that provide air > interface measurements), and simpler ones (e.g. ones that do > not provide such > measurements)." > This is my understanding of what we're trying to do, although I still get nervous when you start talking about air interface measurements. I'm hoping we can keep the abstraction such that cellular topology considerations are minimized. Phil > PatC > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Aug 15 14:18:56 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21120 for ; Tue, 15 Aug 2000 14:18:56 -0400 (EDT) Received: from standards (47.234.32.16:4804) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87C89@standards.nortelnetworks.com>; Tue, 15 Aug 2000 14:06:29 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10738 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 15 Aug 2000 14:06:29 -0400 Received: from sirius.ctr.columbia.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87C88@standards.nortelnetworks.com>; Tue, 15 Aug 2000 14:06:28 -0400 Received: from cvn3 (cvn3.comet.columbia.edu [128.59.68.102]) by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with SMTP id OAA21925; Tue, 15 Aug 2000 14:18:22 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Message-ID: <00d401c006e5$865838e0$66443b80@cvn3.comet.columbia.edu> Date: Tue, 15 Aug 2000 14:20:43 -0400 Reply-To: Michael Kounavis Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Michael Kounavis Subject: Re: [MOBILE-IP] Handoff framework [Was Re: [MOBILE-IP] Anothernovicequestions!] X-To: "pcalhoun@eng.sun.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit >This appears to be what we had been proposing the WG should do. The basic idea >is to come up with some basic capabilities that link layers have, which could >be used to perform the handoff execution process. Since some link layers are >more complex than others, some may provide better handoff performance. > >PatC Pat, In addition to link layer abstractions, however one could think of many other types of 'open' interfaces between access network components. This goes beyond the definition of an abstract link layer interface. This calls for new technologies to extend the capabilities software radfios offer to the signaling plane of mobile and wireless networks. For example, if you have a generic 'handoff execution interface' that separates the handoff detection algorithms from the handoff execution algorithms you can deploy multiple styles of handoff control (e.g., MAHO, MCHO) on the same wireless network; Different handoff styles would seamlessly share the underlying mobility management system (e.g., HAWAII, CIP) etc. The same generic interface can be used for 'plugging' different signaling systems into mobile devices allowing to roam accross heterogeneous access networks. In this way, you address the inter-system handoff problem. So my point is that there are technologies, which are being investigated in the academia, that can be leveraged by the Mobile IP WG where and when needed -as in the case of the abstract link layer. --Michael From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Aug 15 16:05:02 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23380 for ; Tue, 15 Aug 2000 16:05:02 -0400 (EDT) Received: from standards (47.234.32.16:2534) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87D18@standards.nortelnetworks.com>; Tue, 15 Aug 2000 15:52:15 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10925 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 15 Aug 2000 15:52:15 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87D17@standards.nortelnetworks.com>; Tue, 15 Aug 2000 15:52:15 -0400 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA03528; Tue, 15 Aug 2000 14:04:09 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA23565; Tue, 15 Aug 2000 13:04:08 -0700 (PDT) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id NAA06562; Tue, 15 Aug 2000 13:04:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Tue, 15 Aug 2000 13:02:46 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: Re: [MOBILE-IP] Handoff framework [Was Re: [MOBILE-IP] Anothernovicequestions!] X-To: Roberts Phil-QA3445 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" > > No doubt we're doing work to support speeding up handovers in systems that > use MIP for IP layer mobility. The extent of our success will probably be > seen in what other standards bodies choose to do with what we complete. So > we need to do a good job in a timely manner. Agreed. > > > This is my understanding of what we're trying to do, although I still get > nervous when you start talking about air interface measurements. I'm hoping > we can keep the abstraction such that cellular topology considerations are > minimized. > It was provided for illustrative purposes only. I was in no way proposing that we get into link layer characteristics and/or design. PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Aug 15 17:30:36 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27444 for ; Tue, 15 Aug 2000 17:30:35 -0400 (EDT) Received: from standards (47.234.32.16:2229) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87D94@standards.nortelnetworks.com>; Tue, 15 Aug 2000 17:18:06 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 11090 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 15 Aug 2000 17:18:05 -0400 Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87D93@standards.nortelnetworks.com>; Tue, 15 Aug 2000 17:18:05 -0400 Received: from grubby.research.bell-labs.com ([135.104.2.9]) by crufty; Tue Aug 15 17:28:33 EDT 2000 Received: from king.research.bell-labs.com ([135.1.152.1]) by grubby; Tue Aug 15 17:28:33 EDT 2000 Received: from notmafia.research.bell-labs.com.research.bell-labs.com (notmafia [135.1.152.230]) by king.research.bell-labs.com (Postfix) with SMTP id A66585701F for ; Tue, 15 Aug 2000 16:28:32 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <200008151052.GAA10544@ietf.org> X-Mailer: VM 6.33 under Emacs 19.34.2 Message-ID: <20000815212832.A66585701F@king.research.bell-labs.com> Date: Tue, 15 Aug 2000 16:28:32 -0500 Reply-To: Pete McCann Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Pete McCann Subject: [MOBILE-IP] I-D ACTION:draft-mccann-mobileip-limiph-00.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200008151052.GAA10544@ietf.org> Content-Transfer-Encoding: 7bit Hi, I hope everyone saw this announcement. Sorry about posting Yet Another Fast Handoff Draft, but we feel there are some important points that have been missed in the discussion so far. This draft proposes a more "transparent" kind of fast handoff, and can be seen as a synthesis of both the Anchor Chaining kind of ideas and Pat's Proactive FA ideas, although it takes a much more hardline approach to the "network controlled" aspect of handoff than either of these two drafts, going so far as to not require any mobile node re-registration at the new point of attachment if link-layer authentication is used. This draft should be useful for both inter- and intra-domain fast handoff, which I think is an important consideration. Finally, the framework outlined in the document could also be used to alleviate the latency incurred by link-layer (read: PPP) re-establishment at the new FA by providing for temporary layer-2 tunnels back to the previous FA. This would be an alternative to moving such link layer state around in the network. Please read it; comments are welcome. -Pete From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Aug 15 17:34:11 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27712 for ; Tue, 15 Aug 2000 17:34:09 -0400 (EDT) Received: from standards (47.234.32.16:2229) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87D9C@standards.nortelnetworks.com>; Tue, 15 Aug 2000 17:19:00 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 11086 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 15 Aug 2000 17:18:59 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87D90@standards.nortelnetworks.com>; Tue, 15 Aug 2000 17:08:58 -0400 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA09663; Tue, 15 Aug 2000 15:20:53 -0600 (MDT) Received: from atlantic.East.Sun.COM (atlantic.East.Sun.COM [129.148.174.27]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA02880; Tue, 15 Aug 2000 17:20:53 -0400 (EDT) Received: from onion.east.sun.com (onion [129.148.174.110]) by atlantic.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id RAA07470; Tue, 15 Aug 2000 17:20:51 -0400 (EDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Tue, 15 Aug 2000 17:20:46 -0400 Reply-To: Steven Glass - Solaris Software Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Steven Glass - Solaris Software Subject: Re: [MOBILE-IP] charter review X-To: Laurence Rose To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <39995914.48B2890E@usa.alcatel.com> > > Regarding our proposal which is aiming to support micro mobility as well as > being based on > Mobile IP v4 where it is supposed to be ... ? > http://www.ietf.org/internet-drafts/draft-rose-mobileip-smm-00.txt > > Regard > Laurence, I'm not exactly sure the official policy, but my educated guess is if this is already an individual submission to the mobile ip working group, it can stay where it is until the BOF I mentioned becomes a working group, and forms a charter. If that charter encompases your draft, then it becomes draft-rose--smm-00.txt. If not, your draft doesn't need to be a working group submission to become an RFC, though it's certainly harder to get feedback. Cheers, Steve > REgar > > Steven Glass - Solaris Software wrote: > > > I support this 100%, and applaud this decision. This has been a problem > > for a long time now. The IETF solution for those who are upset is to hold a > > WG BOF, and try to figure out what that non-mobileip puzzle piece is shapped > > like. > > > > Cheers, > > Steve > > > > > The chairs would like to refocus the Mobile IP WG objectives to > > > protocols and solutions that are based on Mobile IP v4 and v6. The > > > current objective in the charter of enhancing the protocol to make it > > > suitable for deployment can be achieved if we simply focus on what > > > needs to be done from the perspective of just Mobile IP as specified > > > for IPv4 and IPv6. > > > > > > We believe that alternatives to Mobile IP for IP mobility are outside > > > the scope of this WG. To this end we are proposing that we remove the > > > micromobility bullet item from our charter. Removing this means that > > > we are not going to be considering protocols that are not based of > > > Mobile IP v4/6. The two specific protocols that are WG items currently > > > that will drop out of scope immediately are Cellular IP and HAWAII. > > > > > > We would like to hear from WG members their opinions on this > > > proposal. You should be aware that going forward there MAY or > > > MAY NOT necessarily be another WG in the IETF to pick up this work > > > although we feel that it is a topic that needs separate coverage. > > > > > > Phil and Basavaraj From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Aug 16 05:34:27 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20669 for ; Wed, 16 Aug 2000 05:34:27 -0400 (EDT) Received: from standards (47.234.32.16:4826) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87FE5@standards.nortelnetworks.com>; Wed, 16 Aug 2000 5:21:53 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 11872 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Aug 2000 05:21:53 -0400 Received: from finch-post-10.mail.demon.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB87FE4@standards.nortelnetworks.com>; Wed, 16 Aug 2000 5:21:53 -0400 Received: from panasonic-pmdc.demon.co.uk ([194.222.202.84] helo=panasonic-pmdc) by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1) id 13Oza3-000DIT-0A for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Aug 2000 09:33:51 +0000 Received: from 100.100.101.233 by panasonic-pmdc ([100.100.101.232] running VPOP3) with SMTP for ; Wed, 16 Aug 2000 10:24:59 +0100 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal X-Server: VPOP3 V1.4.0b - Registered to: Panasonic PMDC Message-ID: <000b01c00762$ca484fe0$e9656464@pc1233> Date: Wed, 16 Aug 2000 10:17:23 +0100 Reply-To: gavin.button@panasonic-pmdc.co.uk Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gavin Button Subject: [MOBILE-IP] RFC2002 - Registration Request To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi, I am currently reading RFC 2002 IP Mobility Support (October 1996) and have a couple of questions with regards to the FA forwarding Registration Requests to the HA (section 3.7.2.2). - How does the FA know what to set the Destination MAC Address to when forwarding to the HA, as all it receives in the Registration Request is the HA IP address? - Should it leave the Source MAC Address as the MHs, or set it to its own MAC Address? Thanks in Advance, Gavin Button From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Aug 16 09:33:53 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24455 for ; Wed, 16 Aug 2000 09:33:53 -0400 (EDT) Received: from standards (47.234.32.16:1466) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB880D7@standards.nortelnetworks.com>; Wed, 16 Aug 2000 9:21:05 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12196 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Aug 2000 09:21:05 -0400 Received: from ms.hansol.co.kr (203.235.136.4:4114) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB880D6@standards.nortelnetworks.com>; Wed, 16 Aug 2000 9:21:03 -0400 Received: from ns ([210.112.7.7]) by ms.hansol.co.kr (8.9.3/8.9.3) with SMTP id WAA24540 for ; Wed, 16 Aug 2000 22:31:48 +0900 References: <000f01c001a0$2a4da2a0$a83c9696@AIJ038W> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0017_01C007D1.E1FBAAA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: <002001c00786$84d5f380$d012060a@hansol.co.kr> Date: Wed, 16 Aug 2000 22:32:38 +0900 Reply-To: "Lee, Jiwoong" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Lee, Jiwoong" Subject: Re: [MOBILE-IP] Short description and Two question To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_0017_01C007D1.E1FBAAA0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 RGVhciBUYWV5b25nLA0KDQpJIGhhZCBhIGxvb2sgb24geW91ciBuZXcgaWRlYSBhbmQgaXQgc2Vl bXMgbmFzY2VudC4NClJhdGhlciBJIGRvbid0IHNlZSB0aGUgYmV0dGVyIHF1YWxpZmljYXRpb24g dGhhbiB0aGUgY3VycmVudCB2ZXJzaW9uIG9mIElFVEYNCk1vYmlsZSBJUC4NCg0KQmFzZWQgb24g bXkgdW5kZXJzdGFuZGluZywgeW91ciBpZGVhIG9idGFpbnMgcGVyZm9ybWFuY2UgZWxldmF0aW9u IG9ubHkgaW4NCnRoZQ0KY2FzZSB0aGF0IFRBIGlzIGxvY2F0ZWQgY2xvc2VseSB0byBDTi4gIE15 IG5vdGVzIGFyZSBmb2xsb3dpbmcuDQoNCjEpIEhvdyBjYW4gVEEgaW50ZXJjZXB0IHRoZSBwYWNr ZXQgb2YgQ04gaGVhZGluZyBmb3IgTU4gPw0KIC0gVGhlIG9ubHkgcG9zc2libHkgcmVsaWFibGUg Y2FzZSBpcyB3aGVuIFRBIGlzIHRoZSBlZGdlIHJvdXRlciBvZiBDTi4NCiAgICBUaGlzIGlzIHRo ZSBkZXBsb3ltZW50IHByb2JsZW0uIEFsbCBlZGdlIHJvdXRlcnMgaW5jbHVkaW5nIENOcyB3aG8g d2FudA0KICAgIHRvIHRhbGsgdG8gTU4gU0hPVUxEIGJlIGltcGxlbWVudGVkIHdpdGggeW91ciBp ZGVhLiAgVGhlIGN1cnJlbnQgTW9ibGllDQpJUA0KICAgIGRvZXMgbm90IGhhdmUgdG8uDQoNCjIp IFNlY3VyaXR5IEFzc29jaWF0aW9uDQogLSBSQSBhbmQgVEEgc2hvdWxkIGhhdmUgc2VjdXJpdHkg YXNzb2NpYXRpb24uIE1hbnkgVEFzIGJlbG9uZyB0byBvbmUgUkEuDQogICAgT25lIFRBIHN1cHBv cnRzIG1hbnkgUkFzLiBUaGVyZWZvcmUsIGEgbmV3IHNlY3VyaXR5IHByb2JsZW0gc2hvdWxkIGJl DQogICAgc29sdmVkIG91dCBhbmQgbmV0d29yayBvcGVyYXRvcnMgd2lsbCBoYXZlIHRvdWdoIHRp bWUgdG8gbWFuYWdlIGl0Lg0KDQpJIGhvcGUgbXkgcmVtYXJrIG1pZ2h0IGhlbHAgeW91IHRvIGJ1 aWxkIGEgbmV3IGdvb2Qgc2NoZW1lLg0KDQpKaXdvb25nIExlZQ0KDQoNCiAgLS0tLS0gT3JpZ2lu YWwgTWVzc2FnZSAtLS0tLSANCiAgRnJvbTogVGFleW9uZyxLaW0gDQogIFRvOiBNT0JJTEUtSVBA U1RBTkRBUkRTLk5PUlRFTE5FVFdPUktTLkNPTSANCiAgU2VudDogV2VkbmVzZGF5LCBBdWd1c3Qg MDksIDIwMDAgMTA6MjEgQU0NCiAgU3ViamVjdDogW01PQklMRS1JUF0gU2hvcnQgZGVzY3JpcHRp b24gYW5kIFR3byBxdWVzdGlvbg0KDQoNCiAgSGkuIHJlY2VudGx5LCBJIHNjaGVtZWQgb3V0IGEg bmV3IGlkZWEgYWJvdXQgSEEuDQogIFRoZW4gSSB3YW50IHRvIGtub3cgbXkgaWRlYSBpcyB3b3J0 aC4NCg0KICBwbGVhc2UsIHJlYWQgdGhlIGZvbGxvd2luZyBzaG9ydCBkZXNjcmlwdGlvbiBhbmQg YW5zd2VyICB0aGUNCiAgcXVlc3Rpb24uXl47DQoNCiAgSSB0aGluayBzdWJqZWN0IG9mIG15IGlk ZWEgaXMgImRpc3RyaWJ1dGVkIEhBIi4NCg0KICBzaG9ydCBkZXNjcmlwdGlvbiA6DQoNCiAgIF9f X19fX18gICAgICAgICAgIF9fX19fICAgICAgICAgICAgICAgICAgICBfX19fX18NCiAgIHwgUkEg IHwgLS0tLS0tIHxGQSB8IC0tLS0tLS0tLS0tIHwgTU4gfA0KICAgfF9fX19ffCAgICAgICAgKSAg fF9fX3wgICAgICApKSkpKSkpKSkpKSB8X19fX3wNCiAgICAgIHwgICAgICAgICAgICApDQogICAg ICB8ICAgICAgICAgICAgKQ0KICAgX19fX19fXyAgICkgICAgICAgICAgX19fX19fDQogICB8IFRB ICAgfCAgKSAgICAgICAgICAgIHwgQ04gfA0KICAgfF9fX19ffCAgKSkpKSkpKSkpKSB8X19fX3wN Cg0KICBUQSA6IHR1bm5lbGluZyBBZ2VudA0KICBSQSA6IFJlZ2lzdHJhdGlvbiBBZ2VudA0KICBI QSA6IEhvbWUgQWdlbnQNCiAgQ04gOiBDb3JyZXNwb25kZW50IE5vZGUNCiAgKSA6IHR1bm5lbGlu ZyBwcm9jZWR1cmUgZnJvbSBDTiB0byBNTg0KICAtIDogcmVnaXN0cmF0aW9uIHByb2NlZHVyZSBi ZXR3ZWVuIFJBIGFuZCBNTiB2aWEgRkENCiAgfCA6IHN5bmNocm9uaXphdGlvbiBwcm9jZWR1cmUg YmV0d2VlbiBSQSBhbmQgVEENCg0KICBUQSA6IHR1bm5lbGluZyBBZ2VudA0KICBSQSA6IFJlZ2lz dHJhdGlvbiBBZ2VudA0KICBIQSA6IEhvbWUgQWdlbnQNCiAgQ04gOiBDb3JyZXNwb25kZW50IE5v ZGUNCg0KICBNeSBJZGVhIGlzIHRoYXQgc2VwYXJhdGVzIHRoZSBIQSB0byB0d28gZnVuY3Rpb25h bCB1bml0IChUQSwgUkEpLg0KICBUQSBpcyBUdW5uZWxpbmcgQWdlbnQgdHVubmVscyB0aGUgcGFj a2V0IHRvIE1OIGZyb20gQ04uDQogIFJBIGlzIFJlZ2lzdHJhdGlvbiBBZ2VudCB0aGF0IGtlZXBz IGJpbmRpbmcgZW50cmllcyBmb3IgZWFjaCBNTiBhbmQNCiAgUHJvY2VzcyB0aGUgUmVnaXN0cmF0 aW9uIG1lc3NhZ2VzLg0KICBOb3RlOiBUQSBtdXN0IGNvbW11bmljYXRlIHdpdGggUkEgdG8ga25v dyB3aGVyZSBNTiBpcy4NCg0KICBTY2VuYXJpbzoNCiAgUmVnaXN0cmF0aW9uOg0KICAxKSBNTiBz ZW5kcyB0aGUgUmVnaXN0cmF0aW9uIFJlcXVlc3QgdG8gUkEoaW5pdGlhbGx5LCBuZXR3b3JrIHBy ZWZpeCAgb2YgUkENCiAgYW5kIEhBIGFyZSBzYW1lLCB0aGF0IG1lYW5zIEhBIGlzIGJlbG9uZyB0 byBSQSkNCiAgMikgUkEgc2VuZHMgdGhlIFJlZ2lzdHJhdGlvbiBSZXBseSB3aXRoIHRoZSBhZGRy ZXNzIG9mIHByb3BlciBUQQ0KICAzKSBGQSByZWNlaXZlcyB0aGUgcGFja2V0IGFuZCByZWxheWlu ZyB0aGUgcGFja2V0IHRvIHRoZSBNTg0KICBOb3RlOiBhbG1vc3QgcHJvY2VkdXJlcyBhcmUgc2Ft ZSB3aXRoIG9yaWdpbmFsIE1vYmlsZSBJUA0KICBidXQgUkEgc2VuZHMgbW9kaWZpZWQgUmVnaXN0 cmF0aW9uIFJlcGx5ICB0byBNTiB0aGF0IGNvbnRhaW5zDQogIHRoZSBhZGRpdGlvbmFsIGluZm9y bWF0aW9uLCBhZGRyZXNzIG9mIFRBLg0KICBBbHNvIFJBIGRvZXMgbm90IGFkdmVydGlzZSB0aGUg YWRkcmVzcyBvZiByZWdpc3RlcmVkIE1OIGJ1dCBUQSBkb2VzLg0KDQogIFNlbmRpbmcgcGFja2V0 IHRvIE1OOg0KICAxKSBDTiBzZW5kcyB0aGUgcGFja2V0IHRvIE1ODQogIDIpIFRBIGludGVyY2Vw dHMgdGhlIHBhY2tldA0KICAzKSBUQSBzZW5kcyB0aGUgU3luY2hyb25pemF0aW9uIFJlcXVlc3Qg bWVzc2FnZSB0byBSQSB0byBrbm93IHdoZXJlIE1OIGlzLg0KICA0KSBUQSByZWNlaXZlcyB0aGUg U3luY2hyb25pemF0aW9uIFJlcGx5IGZyb20gUkEuDQogIDUpIFRBIHR1bm5lbHMgaXQgdG8gRkEN CiAgNikgRkEgcmVsYXlzIGl0IHRvIE1ODQogIE5vZGU6IHN0ZXAgMyksIDQpIGlzIGFsd2F5cyBw ZXJmb3JtZWQgcGVyaW9kaWNhbGx5Lg0KDQogIE1ham9yaXR5Og0KICAxKSBUaGlzIGlkZWEgY2Fu IHJlZHVjZSB0aGUgbmV0d29yayB0cmFmZmljcy4NCiAgMikgVGhpcyBpZGVhIGNhbiByZWR1Y2Ug dGhlIGxvYWQgb2YgSEEgdG8gc2VwYXJhdGUgaXQgKFJBLCBUQSkNCiAgMykgVGhpcyBpZGVhIGNh biBpbnRyb2R1Y2UgdGhlIG5ldyByb3V0aW5nIGFsZ29yaXRobSAoZXg6IGR5bmFtaWMgSEEpDQog IDQpIGV0Yw0KICBNeSBxdWVzdGlvbiBpczoNCiAgMSkgRG9lcyBzYW1lIG9yIHNpbWlsYXIgaWRl YSBleGlzdD8NCiAgMikgSXMgdGhpcyBpZGVhIGlzIHN1ZmZpY2llbnQgZm9yIHdyaXRpbmcgdGhl IFJGQyBvciBjb250cmlidXRpb24/DQoNCg0K ------=_NextPart_000_0017_01C007D1.E1FBAAA0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjUwLjQxMzQuNjAwIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9I RUFEPg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBmYWNlPbG8uLLDvD5EZWFy IFRhZXlvbmcsPEJSPjxCUj5JIGhhZCBhIGxvb2sgb24geW91ciBuZXcgaWRlYSBhbmQgaXQgDQpz ZWVtcyBuYXNjZW50LjxCUj5SYXRoZXIgSSBkb24ndCBzZWUgdGhlIGJldHRlciBxdWFsaWZpY2F0 aW9uIHRoYW4gdGhlIGN1cnJlbnQgDQp2ZXJzaW9uIG9mIElFVEY8QlI+TW9iaWxlIElQLjxCUj48 QlI+QmFzZWQgb24gbXkgdW5kZXJzdGFuZGluZywgeW91ciBpZGVhIA0Kb2J0YWlucyBwZXJmb3Jt YW5jZSBlbGV2YXRpb24gb25seSBpbjxCUj50aGU8QlI+Y2FzZSB0aGF0IFRBIGlzIGxvY2F0ZWQg Y2xvc2VseSANCnRvIENOLiZuYnNwOyBNeSBub3RlcyBhcmUgZm9sbG93aW5nLjxCUj48QlI+MSkg SG93IGNhbiBUQSBpbnRlcmNlcHQgdGhlIHBhY2tldCANCm9mIENOIGhlYWRpbmcgZm9yIE1OID88 QlI+Jm5ic3A7LSBUaGUgb25seSBwb3NzaWJseSByZWxpYWJsZSBjYXNlIGlzIHdoZW4gVEEgaXMg DQp0aGUgZWRnZSByb3V0ZXIgb2YgQ04uPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyBUaGlzIGlzIHRo ZSBkZXBsb3ltZW50IHByb2JsZW0uIEFsbCANCmVkZ2Ugcm91dGVycyBpbmNsdWRpbmcgQ05zIHdo byB3YW50PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyB0byB0YWxrIHRvIE1OIFNIT1VMRCANCmJlIGlt cGxlbWVudGVkIHdpdGggeW91ciBpZGVhLiZuYnNwOyBUaGUgY3VycmVudCANCk1vYmxpZTxCUj5J UDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgZG9lcyBub3QgaGF2ZSB0by48QlI+PEJSPjIpIFNlY3Vy aXR5IA0KQXNzb2NpYXRpb248QlI+Jm5ic3A7LSBSQSBhbmQgVEEgc2hvdWxkIGhhdmUgc2VjdXJp dHkgYXNzb2NpYXRpb24uIE1hbnkgVEFzIA0KYmVsb25nIHRvIG9uZSBSQS48QlI+Jm5ic3A7Jm5i c3A7Jm5ic3A7IE9uZSBUQSBzdXBwb3J0cyBtYW55IFJBcy4gVGhlcmVmb3JlLCBhIA0KbmV3IHNl Y3VyaXR5IHByb2JsZW0gc2hvdWxkIGJlPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyBzb2x2ZWQgb3V0 IGFuZCBuZXR3b3JrIA0Kb3BlcmF0b3JzIHdpbGwgaGF2ZSB0b3VnaCB0aW1lIHRvIG1hbmFnZSBp dC48QlI+PEJSPkkgaG9wZSBteSByZW1hcmsgbWlnaHQgaGVscCANCnlvdSB0byBidWlsZCBhIG5l dyBnb29kIHNjaGVtZS48QlI+PEJSPkppd29vbmcgTGVlPEJSPjxCUj48L0ZPTlQ+PC9ESVY+DQo8 QkxPQ0tRVU9URSBkaXI9bHRyIA0Kc3R5bGU9IlBBRERJTkctUklHSFQ6IDBweDsgUEFERElORy1M RUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1MRUZUOiAjMDAwMDAwIDJweCBzb2xp ZDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0KICA8RElWIHN0eWxlPSJGT05UOiAxMHB0IGFyaWFsIj4t LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvRElWPg0KICA8RElWIA0KICBzdHlsZT0iQkFD S0dST1VORDogI2U0ZTRlNDsgRk9OVDogMTBwdCBhcmlhbDsgZm9udC1jb2xvcjogYmxhY2siPjxC PkZyb206PC9CPiANCiAgPEEgdGl0bGU9amVhaW1ldHVATEdJQy5DTy5LUiBocmVmPSJtYWlsdG86 amVhaW1ldHVATEdJQy5DTy5LUiI+VGFleW9uZyxLaW08L0E+IA0KICA8L0RJVj4NCiAgPERJViBz dHlsZT0iRk9OVDogMTBwdCBhcmlhbCI+PEI+VG86PC9CPiA8QSANCiAgdGl0bGU9TU9CSUxFLUlQ QFNUQU5EQVJEUy5OT1JURUxORVRXT1JLUy5DT00gDQogIGhyZWY9Im1haWx0bzpNT0JJTEUtSVBA U1RBTkRBUkRTLk5PUlRFTE5FVFdPUktTLkNPTSI+TU9CSUxFLUlQQFNUQU5EQVJEUy5OT1JURUxO RVRXT1JLUy5DT008L0E+IA0KICA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogMTBwdCBhcmlh bCI+PEI+U2VudDo8L0I+IFdlZG5lc2RheSwgQXVndXN0IDA5LCAyMDAwIDEwOjIxIA0KICBBTTwv RElWPg0KICA8RElWIHN0eWxlPSJGT05UOiAxMHB0IGFyaWFsIj48Qj5TdWJqZWN0OjwvQj4gW01P QklMRS1JUF0gU2hvcnQgZGVzY3JpcHRpb24gDQogIGFuZCBUd28gcXVlc3Rpb248L0RJVj4NCiAg PERJVj48QlI+PC9ESVY+DQogIDxESVY+PEZPTlQgc2l6ZT0yPkhpLiByZWNlbnRseSwgSSBzY2hl bWVkIG91dCBhIG5ldyBpZGVhIGFib3V0IA0KSEEuPC9GT05UPjwvRElWPg0KICA8RElWPjxGT05U IHNpemU9Mj5UaGVuIEkgd2FudCB0byBrbm93IG15IGlkZWEgaXMgd29ydGguPC9GT05UPjwvRElW Pg0KICA8RElWPiZuYnNwOzwvRElWPg0KICA8RElWPjxGT05UIHNpemU9Mj5wbGVhc2UsIHJlYWQg dGhlIGZvbGxvd2luZyBzaG9ydCBkZXNjcmlwdGlvbiBhbmQgDQogIGFuc3dlciZuYnNwOyB0aGU8 L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgc2l6ZT0yPnF1ZXN0aW9uLl5eOzwvRk9OVD48L0RJ Vj4NCiAgPERJVj4mbmJzcDs8L0RJVj4NCiAgPERJVj48Rk9OVCBzaXplPTI+SSB0aGluayBzdWJq ZWN0IG9mIG15IGlkZWEgaXMgImRpc3RyaWJ1dGVkIEhBIi48L0ZPTlQ+PC9ESVY+DQogIDxESVY+ Jm5ic3A7PC9ESVY+DQogIDxESVY+PEZPTlQgc2l6ZT0yPnNob3J0IGRlc2NyaXB0aW9uIDo8L0ZP TlQ+PC9ESVY+DQogIDxESVY+Jm5ic3A7PC9ESVY+DQogIDxESVY+PEZPTlQgDQogIHNpemU9Mj4m bmJzcDtfX19fX19fJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZuYnNwOyANCiAgX19fX18mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIF9fX19fXzxCUj4mbmJzcDt8IFJBJm5ic3A7IHwgLS0t LS0tIHxGQSB8IC0tLS0tLS0tLS0tIHwgTU4gDQogIHw8QlI+Jm5ic3A7fF9fX19ffCZuYnNwOyZu YnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgKSZuYnNwOyANCiAgfF9fX3wmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgKSkpKSkpKSkpKSkgfF9fX198PEJSPiZuYnNwOyZuYnNwOyZu YnNwOyANCiAgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgKTxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgDQogIHwmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgDQogICk8QlI+Jm5ic3A7X19fX19fXyZuYnNwOyZuYnNwOyApJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IA0KICAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgX19fX19fPEJSPiZuYnNwO3wg VEEmbmJzcDsmbmJzcDsgfCZuYnNwOyANCiAgKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgfCBDTiANCiAgfDxCUj4mbmJzcDt8X19f X198Jm5ic3A7ICkpKSkpKSkpKSkgfF9fX198PC9GT05UPjwvRElWPg0KICA8RElWPiZuYnNwOzwv RElWPg0KICA8RElWPjxGT05UIHNpemU9Mj5UQSA6IHR1bm5lbGluZyBBZ2VudDxCUj5SQSA6IFJl Z2lzdHJhdGlvbiBBZ2VudDxCUj5IQSA6IEhvbWUgDQogIEFnZW50PEJSPkNOIDogQ29ycmVzcG9u ZGVudCBOb2RlPEJSPikgOiB0dW5uZWxpbmcgcHJvY2VkdXJlIGZyb20gQ04gdG8gTU48QlI+LSAN CiAgOiByZWdpc3RyYXRpb24gcHJvY2VkdXJlIGJldHdlZW4gUkEgYW5kIE1OIHZpYSBGQTxCUj58 IDogc3luY2hyb25pemF0aW9uIA0KICBwcm9jZWR1cmUgYmV0d2VlbiBSQSBhbmQgVEE8L0ZPTlQ+ PC9ESVY+DQogIDxESVY+Jm5ic3A7PC9ESVY+DQogIDxESVY+PEZPTlQgc2l6ZT0yPlRBIDogdHVu bmVsaW5nIEFnZW50PEJSPlJBIDogUmVnaXN0cmF0aW9uIEFnZW50PEJSPkhBIDogSG9tZSANCiAg QWdlbnQ8QlI+Q04gOiBDb3JyZXNwb25kZW50IE5vZGU8L0ZPTlQ+PC9ESVY+DQogIDxESVY+Jm5i c3A7PC9ESVY+DQogIDxESVY+PEZPTlQgc2l6ZT0yPk15IElkZWEgaXMgdGhhdCBzZXBhcmF0ZXMg dGhlIEhBIHRvIHR3byBmdW5jdGlvbmFsIHVuaXQgKFRBLCANCiAgUkEpLjxCUj5UQSBpcyBUdW5u ZWxpbmcgQWdlbnQgdHVubmVscyB0aGUgcGFja2V0IHRvIE1OIGZyb20gQ04uPEJSPlJBIGlzIA0K ICBSZWdpc3RyYXRpb24gQWdlbnQgdGhhdCBrZWVwcyBiaW5kaW5nIGVudHJpZXMgZm9yIGVhY2gg TU4gYW5kPEJSPlByb2Nlc3MgdGhlIA0KICBSZWdpc3RyYXRpb24gbWVzc2FnZXMuPEJSPk5vdGU6 IFRBIG11c3QgY29tbXVuaWNhdGUgd2l0aCBSQSB0byBrbm93IHdoZXJlIE1OIA0KICBpcy48L0ZP TlQ+PC9ESVY+DQogIDxESVY+Jm5ic3A7PC9ESVY+DQogIDxESVY+PEZPTlQgc2l6ZT0yPlNjZW5h cmlvOjxCUj5SZWdpc3RyYXRpb246PEJSPjEpIE1OIHNlbmRzIHRoZSBSZWdpc3RyYXRpb24gDQog IFJlcXVlc3QgdG8gUkEoaW5pdGlhbGx5LCBuZXR3b3JrIHByZWZpeCZuYnNwOyBvZiBSQTxCUj5h bmQgSEEgYXJlIHNhbWUsIHRoYXQgDQogIG1lYW5zIEhBIGlzIGJlbG9uZyB0byBSQSk8QlI+Mikg UkEgc2VuZHMgdGhlIFJlZ2lzdHJhdGlvbiBSZXBseSB3aXRoIHRoZSANCiAgYWRkcmVzcyBvZiBw cm9wZXIgVEE8QlI+MykgRkEgcmVjZWl2ZXMgdGhlIHBhY2tldCBhbmQgcmVsYXlpbmcgdGhlIHBh Y2tldCB0byANCiAgdGhlIE1OPEJSPk5vdGU6IGFsbW9zdCBwcm9jZWR1cmVzIGFyZSBzYW1lIHdp dGggb3JpZ2luYWwgTW9iaWxlIElQPEJSPmJ1dCBSQSANCiAgc2VuZHMgbW9kaWZpZWQgUmVnaXN0 cmF0aW9uIFJlcGx5Jm5ic3A7IHRvIE1OIHRoYXQgY29udGFpbnM8QlI+dGhlIGFkZGl0aW9uYWwg DQogIGluZm9ybWF0aW9uLCBhZGRyZXNzIG9mIFRBLjxCUj5BbHNvIFJBIGRvZXMgbm90IGFkdmVy dGlzZSB0aGUgYWRkcmVzcyBvZiANCiAgcmVnaXN0ZXJlZCBNTiBidXQgVEEgZG9lcy48L0ZPTlQ+ PC9ESVY+DQogIDxESVY+Jm5ic3A7PC9ESVY+DQogIDxESVY+PEZPTlQgc2l6ZT0yPlNlbmRpbmcg cGFja2V0IHRvIE1OOjxCUj4xKSBDTiBzZW5kcyB0aGUgcGFja2V0IHRvIE1OPEJSPjIpIA0KICBU QSBpbnRlcmNlcHRzIHRoZSBwYWNrZXQ8QlI+MykgVEEgc2VuZHMgdGhlIFN5bmNocm9uaXphdGlv biBSZXF1ZXN0IG1lc3NhZ2UgdG8gDQogIFJBIHRvIGtub3cgd2hlcmUgTU4gaXMuPEJSPjQpIFRB IHJlY2VpdmVzIHRoZSBTeW5jaHJvbml6YXRpb24gUmVwbHkgZnJvbSANCiAgUkEuPEJSPjUpIFRB IHR1bm5lbHMgaXQgdG8gRkE8QlI+NikgRkEgcmVsYXlzIGl0IHRvIE1OPEJSPk5vZGU6IHN0ZXAg MyksIDQpIGlzIA0KICBhbHdheXMgcGVyZm9ybWVkIHBlcmlvZGljYWxseS48L0ZPTlQ+PC9ESVY+ DQogIDxESVY+Jm5ic3A7PC9ESVY+DQogIDxESVY+PEZPTlQgc2l6ZT0yPk1ham9yaXR5OjxCUj4x KSBUaGlzIGlkZWEgY2FuIHJlZHVjZSB0aGUgbmV0d29yayANCiAgdHJhZmZpY3MuPEJSPjIpIFRo aXMgaWRlYSBjYW4gcmVkdWNlIHRoZSBsb2FkIG9mIEhBIHRvIHNlcGFyYXRlIGl0IChSQSwgDQog IFRBKTxCUj4zKSBUaGlzIGlkZWEgY2FuIGludHJvZHVjZSB0aGUgbmV3IHJvdXRpbmcgYWxnb3Jp dGhtIChleDogZHluYW1pYyANCiAgSEEpPEJSPjQpIGV0YzxCUj5NeSBxdWVzdGlvbiBpczo8QlI+ MSkgRG9lcyBzYW1lIG9yIHNpbWlsYXIgaWRlYSBleGlzdD88QlI+MikgDQogIElzIHRoaXMgaWRl YSBpcyBzdWZmaWNpZW50IGZvciB3cml0aW5nIHRoZSBSRkMgb3IgY29udHJpYnV0aW9uPzwvRk9O VD48L0RJVj4NCiAgPERJVj4mbmJzcDs8L0RJVj4NCiAgPERJVj48Rk9OVCBzaXplPTI+PC9GT05U PiZuYnNwOzwvRElWPjwvQkxPQ0tRVU9URT48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0017_01C007D1.E1FBAAA0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Aug 16 10:09:49 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25456 for ; Wed, 16 Aug 2000 10:09:48 -0400 (EDT) Received: from standards (47.234.32.16:1466) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB881C9@standards.nortelnetworks.com>; Wed, 16 Aug 2000 9:56:46 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12521 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Aug 2000 09:56:46 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB881C8@standards.nortelnetworks.com>; Wed, 16 Aug 2000 9:56:46 -0400 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 HAA12955; Wed, 16 Aug 2000 07:08:45 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e7GE8hs02853; Wed, 16 Aug 2000 07:08:43 -0700 X-Virus-Scanned: Wed, 16 Aug 2000 07:08:43 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdynbCBO; Wed, 16 Aug 2000 07:08:39 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <000b01c00762$ca484fe0$e9656464@pc1233> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <399AA069.551A4D30@iprg.nokia.com> Date: Wed, 16 Aug 2000 07:08:41 -0700 Reply-To: charliep@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: Re: [MOBILE-IP] RFC2002 - Registration Request X-To: gavin.button@panasonic-pmdc.co.uk To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Gavin, As a general rule, a Registration Request sent by the foreign agent to the home agent follows the same MAC addressing rules as would any other packet sent by the foreign agent to the home agent. Thus: > - How does the FA know what to set the Destination MAC Address to when > forwarding to the HA, as all it receives in the Registration Request is the > HA IP address? By using either its default router or by using ARP if the HA is on the same subnet as one of the FA's network interfaces. > - Should it leave the Source MAC Address as the MHs, or set it to its own > MAC Address? The foreign agent should set its own MAC address as the source MAC address. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Aug 16 10:37:00 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26203 for ; Wed, 16 Aug 2000 10:36:59 -0400 (EDT) Received: from standards (47.234.32.16:3960) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8821B@standards.nortelnetworks.com>; Wed, 16 Aug 2000 10:24:13 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12634 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Aug 2000 10:24:13 -0400 Received: from marvin.axion.bt.co.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8821A@standards.nortelnetworks.com>; Wed, 16 Aug 2000 10:24:12 -0400 Received: from cbtlipnt01.btlabs.bt.co.uk by marvin (local) with ESMTP; Wed, 16 Aug 2000 15:36:08 +0100 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2651.88) id <3GLRH0M6>; Wed, 16 Aug 2000 15:36:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.88) Content-Type: text/plain Message-ID: Date: Wed, 16 Aug 2000 15:34:55 +0100 Reply-To: alan.w.oneill@BT.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Alan O'Neill" Subject: Re: [MOBILE-IP] charter review X-To: qa3445@EMAIL.MOT.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi Phil / Basavaraj, The EMA team definitely agree that the re-focussing needs to be done and I certainly plan to refresh a proposal to the AD's to enable a BOF at the next IETF to address intra-domain mobile routing. Routing should not be in MIP... BT however is specifically seeking a large-scale mobile routing solution for input into the 3G bodies for Release 2000+ which includes support for fast restoration at the IP layer. This solution should co-exist with MIP based mechanisms to support evolutionary and incremental deployment. Interactions with GTP mechanisms will likely be covered by 3G activity. Whilst BT is not specifically interested at this time in small scale (micro-mobility) solutions, they are clearly within the scope of this BOF, share a common need for standardisation with well-defined applicability statements and hopefully a common interface to both hosts, edge routers and the related MIP interfaces / features for IP hand-over, temporary forwarding and inter-domain movement. I think it is important that the above requirements for MIP are kept in scope of the MIP working group so that we avoid evolutionary disconnects. We will certainly continue to contribute to both the handoff plane of MIP and the mobile routing work to assist in this. Alan O'Neill, Scott Corson, George Tsirtsis. > -----Original Message----- > From: Roberts Phil-QA3445 [SMTP:qa3445@EMAIL.MOT.COM] > Sent: Thursday, August 10, 2000 12:06 AM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: [MOBILE-IP] charter review > > The chairs would like to refocus the Mobile IP WG objectives to > protocols and solutions that are based on Mobile IP v4 and v6. The > current objective in the charter of enhancing the protocol to make it > suitable for deployment can be achieved if we simply focus on what > needs to be done from the perspective of just Mobile IP as specified > for IPv4 and IPv6. > We believe that alternatives to Mobile IP for IP mobility are outside > the scope of this WG. To this end we are proposing that we remove the > micromobility bullet item from our charter. Removing this means that > we are not going to be considering protocols that are not based of > Mobile IP v4/6. The two specific protocols that are WG items currently > that will drop out of scope immediately are Cellular IP and HAWAII. > > We would like to hear from WG members their opinions on this > proposal. You should be aware that going forward there MAY or > MAY NOT necessarily be another WG in the IETF to pick up this work > although we feel that it is a topic that needs separate coverage. > > Phil and Basavaraj From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Aug 16 11:07:39 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27276 for ; Wed, 16 Aug 2000 11:07:39 -0400 (EDT) Received: from standards (47.234.32.16:3960) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8829B@standards.nortelnetworks.com>; Wed, 16 Aug 2000 10:54:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12802 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Aug 2000 10:54:55 -0400 Received: from motgate2.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8829A@standards.nortelnetworks.com>; Wed, 16 Aug 2000 10:54:55 -0400 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id IAA08294 for ; Wed, 16 Aug 2000 08:06:55 -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 IAA12455 for ; Wed, 16 Aug 2000 08:06:54 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2650.21) id ; Wed, 16 Aug 2000 10:06:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 16 Aug 2000 10:06:49 -0500 Reply-To: Roberts Phil-QA3445 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Roberts Phil-QA3445 Subject: Re: [MOBILE-IP] charter review X-To: "alan.w.oneill@BT.COM" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Let me make sure I understand what you're saying. You think it fine to trim the charter to remove non mobile ip based micromobility solutions, but you don't want us to get out of the fast handover business or, in other words, improving the performance of mobile ip mobility? Thanks, Phil > -----Original Message----- > From: Alan O'Neill [mailto:alan.w.oneill@BT.COM] > Sent: Wednesday, August 16, 2000 9:35 AM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] charter review > > > Hi Phil / Basavaraj, > > The EMA team definitely agree that the re-focussing needs to > be done and I > certainly plan > to refresh a proposal to the AD's to enable a BOF at the next IETF to > address intra-domain mobile routing. Routing should not be in MIP... > > BT however is specifically seeking a large-scale mobile > routing solution for > input > into the 3G bodies for Release 2000+ which includes support for fast > restoration at the IP layer. This solution should co-exist > with MIP based > mechanisms to support evolutionary and incremental > deployment. Interactions > with GTP mechanisms will likely be covered by 3G activity. > > Whilst BT is not specifically interested at this time in small scale > (micro-mobility) > solutions, they are clearly within the scope of this BOF, > share a common > need for > standardisation with well-defined applicability statements > and hopefully a > common interface to both hosts, edge routers and the related > MIP interfaces > / features for IP hand-over, temporary forwarding and > inter-domain movement. > > I think it is important that the above requirements for MIP > are kept in > scope of the > MIP working group so that we avoid evolutionary disconnects. We will > certainly > continue to contribute to both the handoff plane of MIP and the mobile > routing work to > assist in this. > > Alan O'Neill, Scott Corson, George Tsirtsis. > > > -----Original Message----- > > From: Roberts Phil-QA3445 [SMTP:qa3445@EMAIL.MOT.COM] > > Sent: Thursday, August 10, 2000 12:06 AM > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > Subject: [MOBILE-IP] charter review > > > > The chairs would like to refocus the Mobile IP WG objectives to > > protocols and solutions that are based on Mobile IP v4 and v6. The > > current objective in the charter of enhancing the protocol > to make it > > suitable for deployment can be achieved if we simply focus on what > > needs to be done from the perspective of just Mobile IP as specified > > for IPv4 and IPv6. > > We believe that alternatives to Mobile IP for IP mobility > are outside > > the scope of this WG. To this end we are proposing that we > remove the > > micromobility bullet item from our charter. Removing this means that > > we are not going to be considering protocols that are not based of > > Mobile IP v4/6. The two specific protocols that are WG > items currently > > that will drop out of scope immediately are Cellular IP and HAWAII. > > > > We would like to hear from WG members their opinions on this > > proposal. You should be aware that going forward there MAY or > > MAY NOT necessarily be another WG in the IETF to pick up this work > > although we feel that it is a topic that needs separate coverage. > > > > Phil and Basavaraj > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Aug 16 11:27:39 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27898 for ; Wed, 16 Aug 2000 11:27:38 -0400 (EDT) Received: from standards (47.234.32.16:3960) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB882F3@standards.nortelnetworks.com>; Wed, 16 Aug 2000 11:14:50 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12920 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Aug 2000 11:14:50 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB882F2@standards.nortelnetworks.com>; Wed, 16 Aug 2000 11:14:44 -0400 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 IAA21338; Wed, 16 Aug 2000 08:26:44 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e7GFQeA19471; Wed, 16 Aug 2000 08:26:40 -0700 X-Virus-Scanned: Wed, 16 Aug 2000 08:26:40 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdm7cu8m; Wed, 16 Aug 2000 08:26:35 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <399AB2AD.238E25D5@iprg.nokia.com> Date: Wed, 16 Aug 2000 08:26:37 -0700 Reply-To: charliep@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: Re: [MOBILE-IP] charter review X-To: alan.w.oneill@BT.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Alan, Since IPv4 Regional Registration is in Last Call (I think!) and it purports to be a Mobile IP mechanism for doing intra-domain mobility, I would like to see that it remain a mobile-ip working group item for at least as long as it takes to make it out of the current process. I thought that there was a distinction being made based on whether an intra-domain mechanism used Mobile IP or not. Mechanisms that use Mobile IP are worth discussion in the mobile-ip working group. Mechanisms that use some other protocol might be beneficially discussed in some outgrowth of CRAPS or OBAST or something along those lines. Layer-2 mechanisms might not even belong in the IETF. Handover mechanisms that involve Mobile IP also should be discussed in the mobile-ip working group. My understanding of the problem leads me to believe that some handover mechanisms involve Mobile IP, and others do not. It is the task of the recently designated design teams to figure this out for IPv4 and for IPv6. To your points: > The EMA team definitely agree that the re-focussing needs to be done and I > certainly plan > to refresh a proposal to the AD's to enable a BOF at the next IETF to > address intra-domain mobile routing. Routing should not be in MIP... Mobile IP is in the routing area. So, I am not at all clear on what you mean by this statement. If you mean that OSPF or RIP-based solutions for intra-domain mobility should be discussed elsewhere, I agree. If you mean that tunneling solutions should be discussed elsewhere, then it seems to me that would depend on whether the tunneling is controlled as part of the Mobile IPv4 registration process or else the Mobile IPv6 Binding Update delivery. > BT however is specifically seeking a large-scale mobile routing solution for > input > into the 3G bodies for Release 2000+ which includes support for fast > restoration at the IP layer. This solution should co-exist with MIP based > mechanisms to support evolutionary and incremental deployment. Interactions > with GTP mechanisms will likely be covered by 3G activity. The working group should open some discussion on whether GTP tunneling is a useful work item. Alessio Casati authored a small draft on GTP which was intended to open this discussion, but not much interest has been shown for a long time. What does "fast restoration" mean? What does Release 2000+ mean? Is it different than the rumored Release 01? > Whilst BT is not specifically interested at this time in small scale > (micro-mobility) > solutions, they are clearly within the scope of this BOF, share a common > need for > standardisation with well-defined applicability statements and hopefully a > common interface to both hosts, edge routers and the related MIP interfaces > / features for IP hand-over, temporary forwarding and inter-domain movement. Can you make a clear distinction between your proposed BOF, and the selection of topics that were raised at the recent CRAPS BOF? > I think it is important that the above requirements for MIP are kept in > scope of the > MIP working group so that we avoid evolutionary disconnects. We will > certainly > continue to contribute to both the handoff plane of MIP and the mobile > routing work to > assist in this. Would you formulate the proposed requirements on Mobile IP as follows? - Mobile IP interfaces to intra-domain mobility mechanisms - Evolutionary paths from GTP - IP handover interface - Tunneling from the previous access router (foreign agent) - Inter-domain mobility I assume that this last point would include some AAA interface requirement. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Aug 16 11:31:51 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28087 for ; Wed, 16 Aug 2000 11:31:51 -0400 (EDT) Received: from standards (47.234.32.16:3960) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88310@standards.nortelnetworks.com>; Wed, 16 Aug 2000 11:17:07 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12959 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Aug 2000 11:17:07 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8830F@standards.nortelnetworks.com>; Wed, 16 Aug 2000 11:17:07 -0400 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA07422; Wed, 16 Aug 2000 09:28:27 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA02883; Wed, 16 Aug 2000 08:25:39 -0700 (PDT) Received: from suntana (suntana [129.146.122.88]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id IAA29009; Wed, 16 Aug 2000 08:25:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Y7ekmhOWZhPSLiiM6D2Png== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Message-ID: <200008161525.IAA29009@nasnfs.eng.sun.com> Date: Wed, 16 Aug 2000 08:30:27 -0700 Reply-To: James Kempf Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: James Kempf Subject: Re: [MOBILE-IP] charter review X-To: alan.w.oneill@BT.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM >BT however is specifically seeking a large-scale mobile routing solution for >input >into the 3G bodies for Release 2000+ which includes support for fast >restoration at the IP layer. This solution should co-exist with MIP based >mechanisms to support evolutionary and incremental deployment. Interactions >with GTP mechanisms will likely be covered by 3G activity. > It would be very interesting to hear why mobile IP does not meet BT's requirements in this area, since one of the primary goals of the current work is to make mobile IP able to perform this kind of function. jak From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Aug 16 11:31:52 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28093 for ; Wed, 16 Aug 2000 11:31:52 -0400 (EDT) Received: from standards (47.234.32.16:3960) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8832E@standards.nortelnetworks.com>; Wed, 16 Aug 2000 11:18:17 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12886 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Aug 2000 11:18:16 -0400 Received: from topaz.3com.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB882D8@standards.nortelnetworks.com>; Wed, 16 Aug 2000 11:08:16 -0400 Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e7GFK6H12112; Wed, 16 Aug 2000 08:20:06 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id e7GFK7906068; Wed, 16 Aug 2000 08:20:07 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 8825693D.0054374A ; Wed, 16 Aug 2000 08:19:51 -0700 X-Lotus-FromDomain: 3COM Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <8825693D.0054165F.00@hqoutbound.ops.3com.com> Date: Wed, 16 Aug 2000 10:19:32 -0500 Reply-To: Yingchun_Xu@3COM.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Yingchun_Xu@3COM.COM Subject: Re: [MOBILE-IP] Handoff framework [Was Re: [MOBILE-IP] Anothernovicequestions!] X-To: Ajoy Singh To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM I agree that the Abstract link layer requirements or primitives should be part of Mobile IP WG. As far as how to implement the primitives, it is beyond the WG. Agreed that RP like extension to cdma2000 network is just an example of the implementation. ---Yingchun. "Ajoy Singh" on 08/15/2000 11:28:29 AM Sent by: "Ajoy Singh" To: Yingchun Xu/MW/US/3Com, MOBILE-IP@STANDARDS.NORTELNETWORKS.COM cc: Subject: RE: [MOBILE-IP] Handoff framework [Was Re: [MOBILE-IP] Anothernovicequestions!] Hi All, I also agree with the idea of link layer trigger being used to trigger mobile/IP handover. I also think it is possible to define a common link layer extension to make FA implementation independent of link layer details. I guess it might be enough to define a link layer primitive which will be sent from link layer to network layer whenever handover event is detected. The handover draft can define what it expects in the link layer handover primitive. It will be job of the respective link layers to provide the information required by handover primitive to layer 3. This way the foreign agent implementation will be independent of link layer. I am not in favor of proposing complete new RP like protocol between radio access network and foreign agent as generic protocol might not be suitable to different access technologies and moreover Mobile/IP may not be right place to define such link layer protocol extension. In case of CDMA 2000, RP may be extended to accommodate information required by handover primitive. Any suggestions ? regards, ajoy -----Original Message----- From: IP Routing for Wireless/Mobile Hosts (mobile-ip) [mailto:MOBILE-IP@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Yingchun_Xu@3COM.COM Sent: Tuesday, August 15, 2000 12:27 AM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] Handoff framework [Was Re: [MOBILE-IP] Anothernovicequestions!] Pat, I was not proposing each wireless standard body making Mobile IP work. On the contrary, I am proposing that each wireless standard body should map its Access Network specific link layer into a common Abstract link layer defined by Mobile IP WG. This will free Mobile IP from specific Link Layer dependent. This can be achieved by implementing a common link layer protocol extension. Without this common Link Layer protocol, each FA implementation will be dependent on each specific Link Layer. That's all I am trying to say. Hope I am not mislead you. God know how you come up so much conclusion. ---Yingchun. "pcalhoun/@eng.sun.com" Sent by: "pcalhoun@eng.sun.com" I agreed with Jim. In fact, the approach has been used to some extent in 3G > cdma2000 wireless network. > > In general, there are two approachs to abstract an Access Network: > 1. Abstract Link Layer Protocol: Defining an common link layer protocol to > extend various Access Network to FA. > By doing this, an FA will only need to understand the Abstract link layer > protocol (or Abstract Access Network). > Each Access Network will be > responsible for translating (or mapping) its specific link layer to the > Abstract link layer. > > In 3G cdma2000, the RP interface protocol (to some extent) is an extension of > cdma2000 link layer. > > 2. Link Layer Specific FA: This will make every Access Network has its own > specific FA. The FA will be fully > knowledgable of a specific link layer (or Access Network). This method > tries to abstract Access Network > at network layer so that from HA point of view, all Access Network are same. > Unfortunately, it makes Mobile IP > depending on specific link layer. > > Method 1 is prefered since it makes Mobile IP independent of any specific > link layer protocol (but still dependent of > the common Abstract link layer). > So, let's see if I get this correct. You propose that each wireless standard try to figure out how to get Mobile IP working correctly, as opposed to Mobile IP providing a set of tools for the wireless standards people to use. Do you not believe that the IETF is where any Mobile IP work should be done? Do people really want to see solutions like the 3G ext, where PPP is carried in GRE, and god knows what other standard body comes up with, as opposed to a *single* nice clean solution? I much prefer #2 above, but I do not like the way you've put it. How about: "2. The Mobile IP WG will develop a single fast handoff strategy, that takes advantage of certain wireless technology capabilities. The document will include support for complex air interfaces (e.g. ones that provide air interface measurements), and simpler ones (e.g. ones that do not provide such measurements)." PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Aug 16 11:42:00 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28379 for ; Wed, 16 Aug 2000 11:41:59 -0400 (EDT) Received: from standards (47.234.32.16:3960) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB883AC@standards.nortelnetworks.com>; Wed, 16 Aug 2000 11:28:54 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13168 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Aug 2000 11:28:54 -0400 Received: from gollum.axion.bt.co.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB883AB@standards.nortelnetworks.com>; Wed, 16 Aug 2000 11:28:53 -0400 Received: from cbtlipnt01.btlabs.bt.co.uk by gollum (local) with ESMTP; Wed, 16 Aug 2000 16:41:04 +0100 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2651.88) id <3GLR2FSH>; Wed, 16 Aug 2000 16:39:45 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.88) Content-Type: text/plain Message-ID: Date: Wed, 16 Aug 2000 16:38:36 +0100 Reply-To: alan.w.oneill@BT.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Alan O'Neill" Subject: Re: [MOBILE-IP] charter review X-To: qa3445@EMAIL.MOT.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Absolutely. In general, as an operator we would wish to have a set of standardised, optimised yet complementary deployment tools from which to select at each Release stage. > -----Original Message----- > From: Roberts Phil-QA3445 [SMTP:qa3445@EMAIL.MOT.COM] > Sent: Thursday, August 17, 2000 12:37 AM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] charter review > > Let me make sure I understand what you're saying. You think it fine to > trim > the charter to remove non mobile ip based micromobility solutions, but you > don't want us to get out of the fast handover business or, in other words, > improving the performance of mobile ip mobility? > > Thanks, > Phil > > > > -----Original Message----- > > From: Alan O'Neill [mailto:alan.w.oneill@BT.COM] > > Sent: Wednesday, August 16, 2000 9:35 AM > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: [MOBILE-IP] charter review > > > > > > Hi Phil / Basavaraj, > > > > The EMA team definitely agree that the re-focussing needs to > > be done and I > > certainly plan > > to refresh a proposal to the AD's to enable a BOF at the next IETF to > > address intra-domain mobile routing. Routing should not be in MIP... > > > > BT however is specifically seeking a large-scale mobile > > routing solution for > > input > > into the 3G bodies for Release 2000+ which includes support for fast > > restoration at the IP layer. This solution should co-exist > > with MIP based > > mechanisms to support evolutionary and incremental > > deployment. Interactions > > with GTP mechanisms will likely be covered by 3G activity. > > > > Whilst BT is not specifically interested at this time in small scale > > (micro-mobility) > > solutions, they are clearly within the scope of this BOF, > > share a common > > need for > > standardisation with well-defined applicability statements > > and hopefully a > > common interface to both hosts, edge routers and the related > > MIP interfaces > > / features for IP hand-over, temporary forwarding and > > inter-domain movement. > > > > I think it is important that the above requirements for MIP > > are kept in > > scope of the > > MIP working group so that we avoid evolutionary disconnects. We will > > certainly > > continue to contribute to both the handoff plane of MIP and the mobile > > routing work to > > assist in this. > > > > Alan O'Neill, Scott Corson, George Tsirtsis. > > > > > -----Original Message----- > > > From: Roberts Phil-QA3445 [SMTP:qa3445@EMAIL.MOT.COM] > > > Sent: Thursday, August 10, 2000 12:06 AM > > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > > Subject: [MOBILE-IP] charter review > > > > > > The chairs would like to refocus the Mobile IP WG objectives to > > > protocols and solutions that are based on Mobile IP v4 and v6. The > > > current objective in the charter of enhancing the protocol > > to make it > > > suitable for deployment can be achieved if we simply focus on what > > > needs to be done from the perspective of just Mobile IP as specified > > > for IPv4 and IPv6. > > > We believe that alternatives to Mobile IP for IP mobility > > are outside > > > the scope of this WG. To this end we are proposing that we > > remove the > > > micromobility bullet item from our charter. Removing this means that > > > we are not going to be considering protocols that are not based of > > > Mobile IP v4/6. The two specific protocols that are WG > > items currently > > > that will drop out of scope immediately are Cellular IP and HAWAII. > > > > > > We would like to hear from WG members their opinions on this > > > proposal. You should be aware that going forward there MAY or > > > MAY NOT necessarily be another WG in the IETF to pick up this work > > > although we feel that it is a topic that needs separate coverage. > > > > > > Phil and Basavaraj > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Aug 16 12:10:27 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29059 for ; Wed, 16 Aug 2000 12:10:26 -0400 (EDT) Received: from standards (47.234.32.16:3960) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88403@standards.nortelnetworks.com>; Wed, 16 Aug 2000 11:57:46 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13286 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Aug 2000 11:57:45 -0400 Received: from ish7.ericsson.com.au (203.61.155.111:48143) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88402@standards.nortelnetworks.com>; Wed, 16 Aug 2000 11:57:44 -0400 Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id CAA06000; Thu, 17 Aug 2000 02:07:48 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id CAA28849; Thu, 17 Aug 2000 02:09:23 +1000 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Thu, 17 Aug 2000 02:09:21 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0079C.55D81110" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A5089EB167@eaubrnt018.epa.ericsson.se> Date: Thu, 17 Aug 2000 02:09:20 +1000 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] charter review X-To: James Kempf To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM 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_01C0079C.55D81110 Content-Type: text/plain; charset="iso-8859-1" Good question ! Hesham >BT however is specifically seeking a large-scale mobile routing solution for >input >into the 3G bodies for Release 2000+ which includes support for fast >restoration at the IP layer. This solution should co-exist with MIP based >mechanisms to support evolutionary and incremental deployment. Interactions >with GTP mechanisms will likely be covered by 3G activity. > It would be very interesting to hear why mobile IP does not meet BT's requirements in this area, since one of the primary goals of the current work is to make mobile IP able to perform this kind of function. jak ------_=_NextPart_001_01C0079C.55D81110 Content-Type: text/html; charset="iso-8859-1" RE: [MOBILE-IP] charter review

Good question !

Hesham



>BT however is specifically seeking a large-scale mobile routing solution for
>input
>into the 3G bodies for Release 2000+ which includes support for fast
>restoration at the IP layer. This solution should co-exist with MIP based
>mechanisms to support evolutionary and incremental deployment. Interactions
>with GTP mechanisms will likely be covered by 3G activity.
>

It would be very interesting to hear why mobile IP does not meet BT's
requirements in this area, since one of the primary goals of the
current work is to make mobile IP able to perform this kind of function.

                jak

------_=_NextPart_001_01C0079C.55D81110-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Aug 16 12:22:47 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29415 for ; Wed, 16 Aug 2000 12:22:47 -0400 (EDT) Received: from standards (47.234.32.16:3960) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88457@standards.nortelnetworks.com>; Wed, 16 Aug 2000 12:10:10 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13400 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Aug 2000 12:10:10 -0400 Received: from gandalf.axion.bt.co.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88456@standards.nortelnetworks.com>; Wed, 16 Aug 2000 12:10:09 -0400 Received: from cbtlipnt01.btlabs.bt.co.uk by gandalf (local) with ESMTP; Wed, 16 Aug 2000 17:21:30 +0100 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2651.88) id <3GLR2G06>; Wed, 16 Aug 2000 17:21:30 +0100 X-Mailer: Internet Mail Service (5.5.2651.88) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 16 Aug 2000 17:20:21 +0100 Reply-To: alan.w.oneill@BT.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Alan O'Neill" Subject: Re: [MOBILE-IP] charter review X-To: charliep@iprg.nokia.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi Charlie, Responses below. Thanks for helping to clarify > -----Original Message----- > From: Charles E. Perkins [SMTP:charliep@iprg.nokia.com] > Sent: Thursday, August 17, 2000 12:57 AM > To: alan.w.oneill@BT.COM > Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] charter review > > > Hello Alan, > > Since IPv4 Regional Registration is in Last Call (I think!) and > it purports to be a Mobile IP mechanism for doing intra-domain > mobility, I would like to see that it remain a mobile-ip working > group item for at least as long as it takes to make it out of > the current process. [AWO] Of course > I thought that there was a distinction being made based on whether > an intra-domain mechanism used Mobile IP or not. Mechanisms that > use Mobile IP are worth discussion in the mobile-ip working group. > Mechanisms that use some other protocol might be beneficially > discussed in some outgrowth of CRAPS or OBAST or something along > those lines. Layer-2 mechanisms might not even belong in the IETF. > [AWO] Absolutely > Handover mechanisms that involve Mobile IP also should be discussed > in the mobile-ip working group. My understanding of the problem > leads me to believe that some handover mechanisms involve Mobile IP, > and others do not. It is the task of the recently designated > design teams to figure this out for IPv4 and for IPv6. > [AWO] Agreed. The specific hooks I am therefore asking to be left in MIP work are those necessary for kicking off intra-domain mobile routing (and preserving the utility of the CoA) as opposed to either regional registrations or repeated MIP BU's to CN's/HA's. These hooks are very simple and clean as illustrated in EMA:MIP draft. The alternative is that the intra-domain routing folks re-invent an alternative to MIP (which looks very similar to MIP) and will no doubt lead to all sorts of host and access router transition and interoperability problems. The intra-domain routing folks should view this as simply submitting new 'in-scope' MIP requirements to the wg for consideration. > To your points: > > > The EMA team definitely agree that the re-focussing needs to be done and > I > > certainly plan > > to refresh a proposal to the AD's to enable a BOF at the next IETF to > > address intra-domain mobile routing. Routing should not be in MIP... > > Mobile IP is in the routing area. So, I am not at all clear on what > you mean by this statement. If you mean that OSPF or RIP-based solutions > for intra-domain mobility should be discussed elsewhere, I agree. [AWO] That is what I meant..but the scope needs to cover other routing protocols which hopefully do not have the OSPF like and RIP like limitations (ie modified MANET routing) > > BT however is specifically seeking a large-scale mobile routing solution > for > > input > > into the 3G bodies for Release 2000+ which includes support for fast > > restoration at the IP layer. This solution should co-exist with MIP > based > > mechanisms to support evolutionary and incremental deployment. > Interactions > > with GTP mechanisms will likely be covered by 3G activity. > > The working group should open some discussion on whether GTP tunneling > is a useful work item. Alessio Casati authored a small draft on GTP > which was intended to open this discussion, but not much interest has > been shown for a long time. [AWO] Well personally speaking I think that GTP is not a subject for IETF work, but aiming to produce a viable alternative to it, in the shape of MIP etc is. > What does "fast restoration" mean? [AWO] Being able to rapidly react to the failure of nodes to maintain IP sessions...ie for real-time services etc OSPF convergence times are problematic and new routing technology should aim to address this. In the meantime we have to rely on other layers... > What does Release 2000+ mean? Is it different than the rumored > Release 01? [AWO] Beyond Release 00 :-) > > > Whilst BT is not specifically interested at this time in small scale > > (micro-mobility) > > solutions, they are clearly within the scope of this BOF, share a common > > need for > > standardisation with well-defined applicability statements and hopefully > a > > common interface to both hosts, edge routers and the related MIP > interfaces > > / features for IP hand-over, temporary forwarding and inter-domain > movement. > > Can you make a clear distinction between your proposed BOF, and the > selection of topics that were raised at the recent CRAPS BOF? [AWO] CRAPS covered a wide range of issues. We will be seeking a very focussed BOF on new intra-domain routing technology for the support of existing routing performance requirements, plus mobility with fast restoration capabilities. OSPF / IS-IS have problems in both areas...lets discuss the issues, present the detailed work to date on this (we know of at least two approaches and I am sure others are developing), and see if there is sufficient interest / progress to warrant an IRTF or IETF wg > > I think it is important that the above requirements for MIP are kept in > > scope of the > > MIP working group so that we avoid evolutionary disconnects. We will > > certainly > > continue to contribute to both the handoff plane of MIP and the mobile > > routing work to > > assist in this. > > Would you formulate the proposed requirements on Mobile IP as follows? > - Mobile IP interfaces to intra-domain mobility mechanisms [AWO] yes > - Evolutionary paths from GTP [AWO] needs set of MIP requirements from 3G as a precurser though as GTP is a 3G thing > - IP handover interface [AWO] yes > - Tunneling from the previous access router (foreign agent) [AWO] yes > - Inter-domain mobility assuming heterogeneous intra-domain solutions... [AWO] yes > > I assume that this last point would include some AAA interface > requirement. [AWO] as always > Regards, > Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Aug 16 12:32:10 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29638 for ; Wed, 16 Aug 2000 12:32:10 -0400 (EDT) Received: from standards (47.234.32.16:3960) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8848F@standards.nortelnetworks.com>; Wed, 16 Aug 2000 12:19:29 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13477 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Aug 2000 12:19:29 -0400 Received: from marvin.axion.bt.co.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8848E@standards.nortelnetworks.com>; Wed, 16 Aug 2000 12:19:28 -0400 Received: from cbtlipnt02.btlabs.bt.co.uk by marvin (local) with ESMTP; Wed, 16 Aug 2000 17:31:18 +0100 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2651.88) id ; Wed, 16 Aug 2000 17:31:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.88) Content-Type: text/plain Message-ID: Date: Wed, 16 Aug 2000 17:30:05 +0100 Reply-To: alan.w.oneill@BT.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Alan O'Neill" Subject: Re: [MOBILE-IP] charter review X-To: James.Kempf@Eng.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi James, That is not the issue. The issue is more whether a routed solution would result in a less stateful, more resilient, easier to manage and less costly solution than Mobile IP. We won't know that until we do the detailed work but at the moment we believe it would. If it turns out that this is the case then having a migration path seems sensible provided it doesn't We are as keen as you to make MIP as good as it can be. Alan. > -----Original Message----- > From: James Kempf [SMTP:James.Kempf@ENG.SUN.COM] > Sent: Thursday, August 17, 2000 1:00 AM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] charter review > > >BT however is specifically seeking a large-scale mobile routing solution > for > >input > >into the 3G bodies for Release 2000+ which includes support for fast > >restoration at the IP layer. This solution should co-exist with MIP based > >mechanisms to support evolutionary and incremental deployment. > Interactions > >with GTP mechanisms will likely be covered by 3G activity. > > > > It would be very interesting to hear why mobile IP does not meet BT's > requirements in this area, since one of the primary goals of the > current work is to make mobile IP able to perform this kind of function. > > jak From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Aug 16 12:38:56 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29736 for ; Wed, 16 Aug 2000 12:38:56 -0400 (EDT) Received: from standards (47.234.32.16:3960) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB884BE@standards.nortelnetworks.com>; Wed, 16 Aug 2000 12:26:09 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13540 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Aug 2000 12:26:09 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB884BD@standards.nortelnetworks.com>; Wed, 16 Aug 2000 12:26:04 -0400 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 JAA27412; Wed, 16 Aug 2000 09:38:03 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e7GGc0m23699; Wed, 16 Aug 2000 09:38:00 -0700 X-Virus-Scanned: Wed, 16 Aug 2000 09:38:00 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdah4y3d; Wed, 16 Aug 2000 09:37:53 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <399AC363.972BED9@iprg.nokia.com> Date: Wed, 16 Aug 2000 09:37:55 -0700 Reply-To: charliep@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: [MOBILE-IP] IPv6 handover document X-To: "Hesham Soliman (EPA)" , "Karim El-Malki (ERA)" , Gopal Dommety , "Jari T. Malinen" , Rajeev Koodli , "M. Scott Corson" , George Tsirtsis , Alan O'Neill X-cc: "Basavaraj Patil (NTC/Dallas)" , Phil Roberts To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello folks, I have a primitive version of a writeup for the IPv6 handover document that was authorized during the Pittsburgh IETF 48. I am not sure whether this is supposed to be an edited document, or a co-authored document, or in general whose names are supposed to appear on the document. My plan is as follows: 1. Distribute the primitive and rough document I have now to see if it is a useful starting point. 2. Get additional production collaboration from the interested participants 3. Submit an Internet Draft by end of August 4. Get discussion by the working group 5. Submit revised Internet Draft by end of October Anyone who is interested in participation in (1) and (2) please let me know and I will send you what I have. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Aug 16 13:07:01 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00295 for ; Wed, 16 Aug 2000 13:07:00 -0400 (EDT) Received: from standards (47.234.32.16:3960) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88531@standards.nortelnetworks.com>; Wed, 16 Aug 2000 12:54:19 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13697 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Aug 2000 12:54:19 -0400 Received: from ish7.ericsson.com.au (203.61.155.111:48469) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88530@standards.nortelnetworks.com>; Wed, 16 Aug 2000 12:54:18 -0400 Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id DAA06950; Thu, 17 Aug 2000 03:04:12 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id DAA01354; Thu, 17 Aug 2000 03:05:47 +1000 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Thu, 17 Aug 2000 03:05:43 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C007A4.35697AB0" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A5089EB169@eaubrnt018.epa.ericsson.se> Date: Thu, 17 Aug 2000 03:05:41 +1000 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] IPv6 handover document X-To: "charliep@IPRG.NOKIA.COM" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM 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_01C007A4.35697AB0 Content-Type: text/plain; charset="iso-8859-1" Hello Charlie, First, let me answer by saying I'm clearly interested in this work (steps 1 and 2). I have a question though, is this new document going to be based on an existing proposal for fast handoffs in v6 (I'm only aware of our draft) or is it a new approach ? Regards, Hesham -----Original Message----- From: Charles E. Perkins [mailto:charliep@IPRG.NOKIA.COM] Sent: den 16 augusti 2000 18:38 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: [MOBILE-IP] IPv6 handover document Hello folks, I have a primitive version of a writeup for the IPv6 handover document that was authorized during the Pittsburgh IETF 48. I am not sure whether this is supposed to be an edited document, or a co-authored document, or in general whose names are supposed to appear on the document. My plan is as follows: 1. Distribute the primitive and rough document I have now to see if it is a useful starting point. 2. Get additional production collaboration from the interested participants 3. Submit an Internet Draft by end of August 4. Get discussion by the working group 5. Submit revised Internet Draft by end of October Anyone who is interested in participation in (1) and (2) please let me know and I will send you what I have. Regards, Charlie P. ------_=_NextPart_001_01C007A4.35697AB0 Content-Type: text/html; charset="iso-8859-1" RE: [MOBILE-IP] IPv6 handover document

Hello Charlie,

First, let me answer by saying I'm clearly interested in this
work (steps 1 and 2).

I have a question though, is this new document going to be based on an
existing proposal for fast handoffs in v6 (I'm only aware of our draft) or
is it a new approach ?


Regards,
Hesham



-----Original Message-----
From: Charles E. Perkins [mailto:charliep@IPRG.NOKIA.COM]
Sent: den 16 augusti 2000 18:38
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: [MOBILE-IP] IPv6 handover document


Hello folks,

I have a primitive version of a writeup for the IPv6 handover
document that was authorized during the Pittsburgh IETF 48.
I am not sure whether this is supposed to be an edited document,
or a co-authored document, or in general whose names are supposed
to appear on the document.  My plan is as follows:

1. Distribute the primitive and rough document I have now to see
   if it is a useful starting point.
2. Get additional production collaboration from the interested participants
3. Submit an Internet Draft by end of August
4. Get discussion by the working group
5. Submit revised Internet Draft by end of October

Anyone who is interested in participation in (1) and (2) please
let me know and I will send you what I have.

Regards,
Charlie P.

------_=_NextPart_001_01C007A4.35697AB0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Aug 16 13:34:11 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00752 for ; Wed, 16 Aug 2000 13:34:11 -0400 (EDT) Received: from standards (47.234.32.16:3960) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8858C@standards.nortelnetworks.com>; Wed, 16 Aug 2000 13:21:34 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13823 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Aug 2000 13:21:34 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8858B@standards.nortelnetworks.com>; Wed, 16 Aug 2000 13:21:34 -0400 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 KAA03316; Wed, 16 Aug 2000 10:33:33 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e7GHXVd17855; Wed, 16 Aug 2000 10:33:31 -0700 X-Virus-Scanned: Wed, 16 Aug 2000 10:33:31 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdWf6sSb; Wed, 16 Aug 2000 10:33:24 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <4B6BC00CD15FD2119E5F0008C7A419A5089EB169@eaubrnt018.epa.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <399AD065.B82AF717@iprg.nokia.com> Date: Wed, 16 Aug 2000 10:33:25 -0700 Reply-To: charliep@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: Re: [MOBILE-IP] IPv6 handover document X-To: "Hesham Soliman (EPA)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Hesham, Welcome aboard. I will send you the rough draft by day's end. > I have a question though, is this new document going to be based on an > existing proposal for fast handoffs in v6 (I'm only aware of our draft) or > is it a new approach ? The document is first and foremost a delineation of the issues and relationships to Mobile IP. I believe that recent Internet Drafts for IPv6 smooth handovers from our group here at Nokia will also be relevant. We propose a SHIN (Smooth Handover Initiation) destination option, as well as SHREQ and SHREP, for IPv6. However, it may be the case that no protocol at all will be specified in the document under discussion. I hope at least to get some consensus from the working group about what should be under consideration. If we get a protocol too, then so much the better! The rough draft so far does not contain any protocol specification. I also hope to get a clear picture about how to separate fast, smooth, seamless handovers from regional registration. The main idea could be that handovers are purely edge phenomena, whereas binding updates (e.g., registrations) are mostly not edge phenomena. I wonder whether "fast restoration" is a handover thing or not (see Alan's recent note). Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Aug 16 14:13:26 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01406 for ; Wed, 16 Aug 2000 14:13:25 -0400 (EDT) Received: from standards (47.234.32.16:3960) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88635@standards.nortelnetworks.com>; Wed, 16 Aug 2000 14:00:38 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 14040 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Aug 2000 14:00:38 -0400 Received: from ish7.ericsson.com.au (203.61.155.111:48750) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88632@standards.nortelnetworks.com>; Wed, 16 Aug 2000 14:00:37 -0400 Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id EAA07718; Thu, 17 Aug 2000 04:10:40 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id EAA04051; Thu, 17 Aug 2000 04:12:16 +1000 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Thu, 17 Aug 2000 04:12:14 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C007AD.80B0A210" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A5089EB16B@eaubrnt018.epa.ericsson.se> Date: Thu, 17 Aug 2000 04:12:13 +1000 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] IPv6 handover document X-To: "charliep@IPRG.NOKIA.COM" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM 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_01C007AD.80B0A210 Content-Type: text/plain; charset="iso-8859-1" Hi Charlie, Welcome aboard. I will send you the rough draft by day's end. =>Thanks, I'll look forward to it. > I have a question though, is this new document going to be based on an > existing proposal for fast handoffs in v6 (I'm only aware of our draft) or > is it a new approach ? The document is first and foremost a delineation of the issues and relationships to Mobile IP. I believe that recent Internet Drafts for IPv6 smooth handovers from our group here at Nokia will also be relevant. We propose a SHIN (Smooth Handover Initiation) destination option, as well as SHREQ and SHREP, for IPv6. However, it may be the case that no protocol at all will be specified in the document under discussion. I hope at least to get some consensus from the working group about what should be under consideration. If we get a protocol too, then so much the better! The rough draft so far does not contain any protocol specification. =>My understanding is that the task that was decided on by the WG in the "smaller" handoff meeting was to devise a method for Fast Handoffs that is independant of the access technology. As far as I understand, the SHIN and SHREQ messages above are triggers for context transfer. While we decided that this work is important, it was also seen as something that is not part of the MIP WG charter and that yourself, Alan and James? would consult with the IESG to find out where it should be done. So based on this evidence (or at least my side of the story) I'm not sure how this proposal would fit with the task allocated by the WG. The main problem that I understood we're addressing here is the routing problem. I also hope to get a clear picture about how to separate fast, smooth, seamless handovers from regional registration. The main idea could be that handovers are purely edge phenomena, whereas binding updates (e.g., registrations) are mostly not edge phenomena. =>Yes I think that is important, but also just as important is to separate fast, smooth and seamless handoffs from each other. I believe the basic MIPv6 already provides smooth handoffs (as far as routing goes). I wonder whether "fast restoration" is a handover thing or not (see Alan's recent note). I'm sure it is related but I think we need to precisely define what it means. ------_=_NextPart_001_01C007AD.80B0A210 Content-Type: text/html; charset="iso-8859-1" RE: [MOBILE-IP] IPv6 handover document

Hi Charlie,


Welcome aboard.  I will send you the rough draft by day's end.

=>Thanks, I'll look forward to it.

> I have a question though, is this new document going to be based on an
> existing proposal for fast handoffs in v6 (I'm only aware of our draft) or
> is it a new approach ?

The document is first and foremost a delineation of the issues
and relationships to Mobile IP.

I believe that recent Internet Drafts for IPv6 smooth handovers from
our group here at Nokia will also be relevant.  We propose a SHIN
(Smooth Handover Initiation) destination option, as well as SHREQ and
SHREP, for IPv6.  However, it may be the case that no protocol at all
will be specified in the document under discussion.  I hope at least
to get some consensus from the working group about what should be
under consideration.  If we get a protocol too, then so much the better!
The rough draft so far does not contain any protocol specification.

=>My understanding is that the task that was decided on by the WG in the
"smaller" handoff meeting was to devise a method for Fast Handoffs
that is independant of the access technology.
As far as I understand, the SHIN and SHREQ messages above are triggers
for context transfer. While we decided that this work is important,
it was also seen as something that is not part of the MIP WG charter
and that yourself, Alan and James? would consult with the IESG to find
out where it should be done. So based on this evidence (or at least my
side of the story) I'm not sure how this proposal would fit with the
task allocated by the WG.
The main problem that I understood we're addressing here is the routing
problem.
 


I also hope to get a clear picture about how to separate fast,
smooth, seamless handovers from regional registration.  The main
idea could be that handovers are purely edge phenomena, whereas
binding updates (e.g., registrations) are mostly not edge phenomena.

=>Yes I think that is important, but also just as important is to
separate fast, smooth and seamless handoffs from each other. I believe
the basic MIPv6 already provides smooth handoffs (as far as routing goes).


I wonder whether "fast restoration" is a handover thing or not (see
Alan's recent note).

I'm sure it is related but I think we need to precisely define what
it means.

------_=_NextPart_001_01C007AD.80B0A210-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Aug 16 15:03:40 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02319 for ; Wed, 16 Aug 2000 15:03:39 -0400 (EDT) Received: from standards (47.234.32.16:3960) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB886E6@standards.nortelnetworks.com>; Wed, 16 Aug 2000 14:51:08 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 14241 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Aug 2000 14:51:08 -0400 Received: from gunpowder.stanford.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB886CB@standards.nortelnetworks.com>; Wed, 16 Aug 2000 14:41:07 -0400 Received: (qmail 22421 invoked by alias); 16 Aug 2000 18:53:05 -0000 Received: (qmail 22415 invoked from network); 16 Aug 2000 18:53:05 -0000 Received: from thermite.stanford.edu (171.64.67.72) by gunpowder.stanford.edu with SMTP; 16 Aug 2000 18:53:05 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20000816185305.22420.qmail@gunpowder.stanford.edu> Date: Wed, 16 Aug 2000 11:57:13 -0700 Reply-To: Xinhua Zhao Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Xinhua Zhao Subject: Re: [MOBILE-IP] charter review To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Message from James Kempf of "Wed, 16 Aug 2000 08:30:27 PDT." <200008161525.IAA29009@nasnfs.eng.sun.com> Could someone please explain what "BT" stands for here? Thanks, Xinhua -- MosquitoNet Project on Mobile and Wireless Computing Stanford University http://MosquitoNet.Stanford.EDU > >BT however is specifically seeking a large-scale mobile routing solution for > >input > >into the 3G bodies for Release 2000+ which includes support for fast > >restoration at the IP layer. This solution should co-exist with MIP based > >mechanisms to support evolutionary and incremental deployment. Interactions > >with GTP mechanisms will likely be covered by 3G activity. > > > > It would be very interesting to hear why mobile IP does not meet BT's > requirements in this area, since one of the primary goals of the > current work is to make mobile IP able to perform this kind of function. > > jak From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Aug 16 16:33:41 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03609 for ; Wed, 16 Aug 2000 16:33:40 -0400 (EDT) Received: from standards (47.234.32.16:3960) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8880A@standards.nortelnetworks.com>; Wed, 16 Aug 2000 16:20:50 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 14654 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Aug 2000 16:20:50 -0400 Received: from ftpbox.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88809@standards.nortelnetworks.com>; Wed, 16 Aug 2000 16:20:50 -0400 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id NAA08541 for ; Wed, 16 Aug 2000 13:32:44 -0700 (MST)] Received: [from il75exm02.cig.mot.com (IL75EXM02.cig.mot.com [136.182.110.102]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id NAA01375 for ; Wed, 16 Aug 2000 13:32:32 -0700 (MST)] Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2650.21) id ; Wed, 16 Aug 2000 15:32:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 16 Aug 2000 15:32:23 -0500 Reply-To: Roberts Phil-QA3445 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Roberts Phil-QA3445 Subject: Re: [MOBILE-IP] IPv6 handover document X-To: "Charles E. Perkins" , "Hesham Soliman (EPA)" , "Karim El-Malki (ERA)" , Gopal Dommety , "Jari T. Malinen" , Rajeev Koodli , "M. Scott Corson" , George Tsirtsis , Alan O'Neill X-cc: "Basavaraj Patil (NTC/Dallas)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a good plan. I'd like to participate. > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: Wednesday, August 16, 2000 11:38 AM > To: Hesham Soliman (EPA); Karim El-Malki (ERA); Gopal Dommety; Jari T. > Malinen; Rajeev Koodli; M. Scott Corson; George Tsirtsis; Alan O'Neill > Cc: Basavaraj Patil (NTC/Dallas); Phil Roberts; Mobile IP Mailing List > Subject: IPv6 handover document > > > > Hello folks, > > I have a primitive version of a writeup for the IPv6 handover > document that was authorized during the Pittsburgh IETF 48. > I am not sure whether this is supposed to be an edited document, > or a co-authored document, or in general whose names are supposed > to appear on the document. My plan is as follows: > > 1. Distribute the primitive and rough document I have now to see > if it is a useful starting point. > 2. Get additional production collaboration from the > interested participants > 3. Submit an Internet Draft by end of August > 4. Get discussion by the working group > 5. Submit revised Internet Draft by end of October > > Anyone who is interested in participation in (1) and (2) please > let me know and I will send you what I have. > > Regards, > Charlie P. > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Aug 17 06:18:13 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22981 for ; Thu, 17 Aug 2000 06:18:12 -0400 (EDT) Received: from standards (47.234.32.16:3030) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88B1B@standards.nortelnetworks.com>; Thu, 17 Aug 2000 6:05:29 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 15650 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 17 Aug 2000 06:05:29 -0400 Received: from tml-gw.tml.hut.fi (tml.hut.fi) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88B07@standards.nortelnetworks.com>; Thu, 17 Aug 2000 5:55:29 -0400 Received: (from smap@localhost) by tml-gw.tml.hut.fi (8.8.7/8.8.7) id NAA11481 for ; Thu, 17 Aug 2000 13:07:30 +0300 Received: from caffeine.tml.hut.fi(130.233.45.27) by tml-gw.tml.hut.fi via smap (V2.0) id xma011477; Thu, 17 Aug 00 13:07:13 +0300 Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7]) by caffeine.tml.hut.fi (8.10.2/8.10.2) with ESMTP id e7HA7Ou23056 for ; Thu, 17 Aug 2000 13:07:24 +0300 (EET DST) Received: from localhost (lyang@localhost) by morphine.tml.hut.fi (8.9.2/8.7.1) with ESMTP id NAA00437 for ; Thu, 17 Aug 2000 13:06:59 +0300 (EET DST) X-Authentication-Warning: morphine.tml.hut.fi: lyang owned process doing -bs X-Sender: lyang@morphine.tml.hut.fi MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Thu, 17 Aug 2000 13:06:58 +0300 Reply-To: Linfeng Yang Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Linfeng Yang Subject: Re: [MOBILE-IP] IPv6 handover document To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <4B6BC00CD15FD2119E5F0008C7A419A5089EB16B@eaubrnt018.epa.ericsson.se> > =>Yes I think that is important, but also just as important is to > separate fast, smooth and seamless handoffs from each other. I believe > the basic MIPv6 already provides smooth handoffs (as far as routing goes). Here is my understanding about the different between fast, smooth and seamless handoff. Please correct me if I am wrong. I feel smooth handoff and seamless handoff are the same, they describe the handoff in the way what we want it achieve, i.e., minimized packet loss. In basic MIPv6 smooth or seamless handoff is achieved through establishing forwarding from a previous care-of address. Fast handoff on the other hand describe how we can achieve it. Fast is compared with basic MIPv6 in the sense that it will overcome the router advertisement interval limit. Here I schemed one way of Fast handoff, I call it Link Layer Assisted Fast Handoff. When MN is on idle movement, there is no need to perform fast handoff, since there is no packet loss issue. So MN will start fast handoff process when it is in active movement. MN will constantly measure signal strength of message received from current router, if it is lower than some threshold value (t1), MN will then send a router solicitation message in hope of receiving a router advertisement. In this way, MN can overcome the Router Advertisement interval limit, thus speed up handoff process. MN may then receive more than one Solicited Router Advertisement from neighboring routers. After compare the signal strength of current router (sc) with the one received earliest from new router (sn), MN can then decide to perform a Handoff or not. If (sn + t2) >= sc, MN will perform handoff, otherwise MN will send another Router Solicitation. t2 is used to prevent unnecessary handoff in the "ping pong" like movement within the overlap of two router domain. After handoff new router becomes current default router or MN, MN will then measure its signal strength from this router. We can see this is only local handoff, if accompanied with establishing forwarding from a previous care-of address, it can achieve even better smoothness. Regards, Linfeng Yang Helsinki University of Technology Telecommunications Software and Multimedia Laboratory P.O.Box 9700, 02015 HUT, Finland Phone: +358 9 451 5250 Fax: +358 9 451 5351 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Aug 17 06:44:52 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23166 for ; Thu, 17 Aug 2000 06:44:52 -0400 (EDT) Received: from standards (47.234.32.16:3030) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88B76@standards.nortelnetworks.com>; Thu, 17 Aug 2000 6:32:21 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 15793 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 17 Aug 2000 06:32:21 -0400 Received: from finch-post-11.mail.demon.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88B75@standards.nortelnetworks.com>; Thu, 17 Aug 2000 6:32:20 -0400 Received: from panasonic-pmdc.demon.co.uk ([194.222.202.84] helo=panasonic-pmdc) by finch-post-11.mail.demon.net with esmtp (Exim 2.12 #1) id 13PN9n-000798-0B; Thu, 17 Aug 2000 10:44:22 +0000 Received: from 100.100.101.233 by panasonic-pmdc ([100.100.101.232] running VPOP3) with SMTP; Thu, 17 Aug 2000 11:51:08 +0100 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 CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal X-Server: VPOP3 V1.4.0b - Registered to: Panasonic PMDC Message-ID: <000d01c00837$f8e9f6c0$e9656464@pc1233> Date: Thu, 17 Aug 2000 11:43:24 +0100 Reply-To: gavin.button@panasonic-pmdc.co.uk Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gavin Button Subject: Re: [MOBILE-IP] RFC2002 - Registration Request X-cc: charliep@IPRG.NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <399AA069.551A4D30@iprg.nokia.com> Content-Transfer-Encoding: 7bit Thanks again for the reply. Am I right in assuming that if the default router is used by a FA for forwarding a Registration request, that ARP will still be required for getting the MAC address as this will not be in the routing table? Thanks Gavin -----Original Message----- From: IP Routing for Wireless/Mobile Hosts (mobile-ip) [mailto:MOBILE-IP@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Charles E. Perkins Sent: 16 August 2000 15:09 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] RFC2002 - Registration Request Hello Gavin, As a general rule, a Registration Request sent by the foreign agent to the home agent follows the same MAC addressing rules as would any other packet sent by the foreign agent to the home agent. Thus: > - How does the FA know what to set the Destination MAC Address to when > forwarding to the HA, as all it receives in the Registration Request is the > HA IP address? By using either its default router or by using ARP if the HA is on the same subnet as one of the FA's network interfaces. > - Should it leave the Source MAC Address as the MHs, or set it to its own > MAC Address? The foreign agent should set its own MAC address as the source MAC address. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Aug 17 10:56:22 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27861 for ; Thu, 17 Aug 2000 10:56:21 -0400 (EDT) Received: from standards (47.234.32.16:1158) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88CDC@standards.nortelnetworks.com>; Thu, 17 Aug 2000 10:43:15 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 16256 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 17 Aug 2000 10:43:15 -0400 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88CDB@standards.nortelnetworks.com>; Thu, 17 Aug 2000 10:43:14 -0400 Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e7HEt8631813; Thu, 17 Aug 2000 16:55:10 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id QAA16016; Thu, 17 Aug 2000 16:55:05 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id QAA57909; Thu, 17 Aug 2000 16:57:43 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-ID: <200008171457.QAA57909@givry.rennes.enst-bretagne.fr> Date: Thu, 17 Aug 2000 16:57:43 +0200 Reply-To: Francis.Dupont@ENST-BRETAGNE.FR Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] IPv6 handover document X-To: Linfeng Yang To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Thu, 17 Aug 2000 13:06:58 +0300. In your previous mail you wrote: > =>Yes I think that is important, but also just as important is to > separate fast, smooth and seamless handoffs from each other. I believe > the basic MIPv6 already provides smooth handoffs (as far as routing goes). Here is my understanding about the different between fast, smooth and seamless handoff. Please correct me if I am wrong. => you have forgotten smart handoff (:-)! I feel smooth handoff and seamless handoff are the same, they describe the handoff in the way what we want it achieve, i.e., minimized packet loss. In basic MIPv6 smooth or seamless handoff is achieved through establishing forwarding from a previous care-of address. => this is seamless handoff, smooth is based on bicasting. The mechanism is not exactly the same. Fast handoff on the other hand describe how we can achieve it. Fast is compared with basic MIPv6 in the sense that it will overcome the router advertisement interval limit. => to use router advertisements as a beacon is stupid (from a IPv6 person point of view). Here I schemed one way of Fast handoff, I call it Link Layer Assisted Fast Handoff. When MN is on idle movement, there is no need to perform fast handoff, since there is no packet loss issue. => idle movement is "not moving", isn't it? And active is "moving"? So MN will start fast handoff process when it is in active movement. MN will constantly measure signal strength of message received from current router, if it is lower than some threshold value (t1), MN will then send a router solicitation message in hope of receiving a router advertisement. => I disagree, if you want to poll a router you should use a neighbor solicitation: - router solicitations are multicasted then they are more expensive than unicasted neighbor solicitations - router advertisements are expensive to build, transmit and decode - routers should wait a bit before sending a solicited router advertisement (in order to avoid synchronization of replies) In this way, MN can overcome the Router Advertisement interval limit, thus speed up handoff process. => the less-reachability detection of routers should not rely on router advertisements, I agree. MN may then receive more than one Solicited Router Advertisement from neighboring routers. => I prefer to use router advertisement in order to get the set of available routers first and to have a regular measure of the signal strength in second and in a *passive* way. After compare the signal strength of current router (sc) with the one received earliest from new router (sn), MN can then decide to perform a Handoff or not. If (sn + t2) >= sc, MN will perform handoff, otherwise MN will send another Router Solicitation. t2 is used to prevent unnecessary handoff in the "ping pong" like movement within the overlap of two router domain. => I prefer to have a second threshold: if (sn + t2) >= sc then the new candidate router should be polled in order to get a fresh sn, then if (sn + t3) >= sc MN will perform handoff. This is cheaper and faster than using router solicitation as a hammer and more powerful than a decay mechanism on signal strength. It can support multiple candidates too if movement is both active and fast. An interesting case is if there are real beacons associated to routers then signal strengths are available directly. After handoff new router becomes current default router or MN, MN will then measure its signal strength from this router. => MN should keep a list of candidate default routers (RFC 2461) then it is not so expensive to keep signal strengths too. We can see this is only local handoff, if accompanied with establishing forwarding from a previous care-of address, it can achieve even better smoothness. => "forwarding from a previous care-of address" is I-D 12 10.9, isn't it? This supposes there are enough available home agents (ie. lost of benefits of the disappearance of foreign agents). Thanks Francis.Dupont@enst-bretagne.fr PS: fast/smooth/seamless/smart handoffs are fine but mobile IPv6 code should support other more traditional usage of mobility, for instance it should be able to change an interface for another, for instance a GSM/GPRS/UMTS/... cellular device for a 100Mbits/s Ethernet. This is what makes mobile IPv* more powerful than any layer 2 solution and we should not drop this in order to fight with better weapons against layer 2 solutions. I am afraid this was forgotten by some of us... From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Aug 17 11:01:11 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27992 for ; Thu, 17 Aug 2000 11:01:11 -0400 (EDT) Received: from standards (47.234.32.16:1158) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88CEE@standards.nortelnetworks.com>; Thu, 17 Aug 2000 10:44:53 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 16248 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 17 Aug 2000 10:44:52 -0400 Received: from motgate2.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88CD5@standards.nortelnetworks.com>; Thu, 17 Aug 2000 10:34:51 -0400 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id HAA18584 for ; Thu, 17 Aug 2000 07:46:54 -0700 (MST)] Received: [from il02dns1.comm.mot.com (il02dns1.comm.mot.com [145.1.3.2]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id HAA29468 for ; Thu, 17 Aug 2000 07:46:53 -0700 (MST)] Received: from cje011.mot.com ([173.14.15.182]) by il02dns1.comm.mot.com (8.9.3/8.9.3) with ESMTP id JAA21023 for ; Thu, 17 Aug 2000 09:46:46 -0500 (CDT) X-Sender: lmps_mstr_1/cje011@il02exm21.comm.mot.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 References: <4B6BC00CD15FD2119E5F0008C7A419A5089EB16B@eaubrnt018.epa.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.3.2.7.2.20000817093510.00b0f150@il02exm21.comm.mot.com> Date: Thu, 17 Aug 2000 09:45:43 -0500 Reply-To: John Emmert Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: John Emmert Subject: Re: [MOBILE-IP] IPv6 handover document To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: At 05:06 AM 8/17/00, Linfeng Yang wrote: >So MN will start fast handoff process when it is in active movement. >MN will constantly measure signal strength of message received from >current router, if it is lower than some threshold value (t1), MN will >then send a router solicitation message in hope of receiving a router >advertisement. In this way, MN can overcome the Router Advertisement >interval limit, thus speed up handoff process. MN may then receive >more than one Solicited Router Advertisement from neighboring routers. >After compare the signal strength of current router (sc) with the one >received earliest from new router (sn), MN can then decide to perform a >Handoff or not. If (sn + t2) >= sc, MN will perform handoff, otherwise >MN will send another Router Solicitation. t2 is used to prevent >unnecessary handoff in the "ping pong" like movement within the overlap >of two router domain. After handoff new router becomes current default >router or MN, MN will then measure its signal strength from this router. > >We can see this is only local handoff, if accompanied with establishing >forwarding from a previous care-of address, it can achieve even better >smoothness. I've seen two solutions to this. Have a FA cover a large geographic area, thus minimizing the need for changing FAs, and have the FA assigned by a lower link layer when boundaries are crossed. I think short term forwarding from a previous FA would be worth investigating. Perhaps a defined interval that if not renewed is automatically flushed? Ping-ponging problems are already handled at the lower layers (or they better be). Due to the inherent unreliability of RF in delivering data without errors, and well known problems with the error handling routines of IP, the lower layers better do some error detection and correction as well. I'm not sure, and in fact am of the opinion, that the lower layers are not the topic of this group. Really they should be handled by other groups. This group should give a mobility solution that the other groups can use to integrate a complete mobility solution, including RF protocol layers. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Aug 17 11:19:14 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28433 for ; Thu, 17 Aug 2000 11:19:14 -0400 (EDT) Received: from standards (47.234.32.16:1158) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88D7B@standards.nortelnetworks.com>; Thu, 17 Aug 2000 11:06:23 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 16465 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 17 Aug 2000 11:06:23 -0400 Received: from ish7.ericsson.com.au (203.61.155.111:34853) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88D7A@standards.nortelnetworks.com>; Thu, 17 Aug 2000 11:06:22 -0400 Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id BAA04743; Fri, 18 Aug 2000 01:16:20 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id BAA19111; Fri, 18 Aug 2000 01:17:57 +1000 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Fri, 18 Aug 2000 01:17:55 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0085E.50B9DD40" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A5089EB178@eaubrnt018.epa.ericsson.se> Date: Fri, 18 Aug 2000 01:17:54 +1000 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] IPv6 handover document X-To: Linfeng Yang To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM 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_01C0085E.50B9DD40 Content-Type: text/plain; charset="iso-8859-1" Here is my understanding about the different between fast, smooth and seamless handoff. Please correct me if I am wrong. I feel smooth handoff and seamless handoff are the same, they describe the handoff in the way what we want it achieve, i.e., minimized packet loss. In basic MIPv6 smooth or seamless handoff is achieved through establishing forwarding from a previous care-of address. Fast handoff on the other hand describe how we can achieve it. Fast is compared with basic MIPv6 in the sense that it will overcome the router advertisement interval limit. Here I schemed one way of Fast handoff, I call it Link Layer Assisted Fast Handoff. => Fast Handoff (as far as I am aware) was designed to reduce packet loss AND reduce latencies in packet delivery due to handoffs by anticipating MN's movement early, before it arrives at the next AR. I'm referring here to the definition in : draft-elmalki-mobileip-fast-handoffs-02.tx I guess some L2 help is always needed to make a realistic handoff. (ie. avoid these RA beacons). >So MN will start fast handoff process when it is in active movement. >MN will constantly measure signal strength of message received from >current router, if it is lower than some threshold value (t1), MN will >then send a router solicitation message in hope of receiving a router >advertisement. In this way, MN can overcome the Router Advertisement >interval limit, thus speed up handoff process. MN may then receive >more than one Solicited Router Advertisement from neighboring routers. >After compare the signal strength of current router (sc) with the one >received earliest from new router (sn), MN can then decide to perform a >Handoff or not. If (sn + t2) >= sc, MN will perform handoff, otherwise >MN will send another Router Solicitation. t2 is used to prevent >unnecessary handoff in the "ping pong" like movement within the overlap >of two router domain. After handoff new router becomes current default >router or MN, MN will then measure its signal strength from this router. => What you say above is very interesting and we've been looking into similar algorithms that reuse L2 knowledge. One general comment though, Sending a Neighbour solicitation (or even worse router solicitation) only due to signal measurements makes the assummption that whenever you change Base station, you also change subnets. That coupling is not required by MIP and hence may also be inefficient in terms of radio resource usage. Also are you making the assumption that you can talk to two routers in two subnets at the same time ? Do you have a specific Layer 2 in mind ? Hesham ------_=_NextPart_001_01C0085E.50B9DD40 Content-Type: text/html; charset="iso-8859-1" RE: [MOBILE-IP] IPv6 handover document

Here is my understanding about the different between fast, smooth and
seamless handoff. Please correct me if I am wrong.

I feel smooth handoff and seamless handoff are the same, they describe the
handoff in the way what we want it achieve, i.e., minimized packet loss.
In basic MIPv6 smooth or seamless handoff is achieved through establishing
forwarding from a previous care-of address.

Fast handoff on the other hand describe how we can achieve it. Fast is
compared with basic MIPv6 in the sense that it will overcome the router
advertisement interval limit. Here I schemed one way of Fast handoff, I
call it Link Layer Assisted Fast Handoff.

=> Fast Handoff (as far as I am aware) was designed to reduce packet
loss AND reduce latencies in packet delivery due to handoffs by
anticipating MN's movement early, before it arrives at the next AR.
I'm referring here to the definition in :
draft-elmalki-mobileip-fast-handoffs-02.tx

I guess some L2 help is always needed to make a realistic handoff.
(ie. avoid these RA beacons).



>So MN will start fast handoff process when it is in active movement.
>MN will constantly measure signal strength of message received from
>current router, if it is lower than some threshold value (t1), MN will
>then send a router solicitation message in hope of receiving a router
>advertisement. In this way, MN can overcome the Router Advertisement
>interval limit, thus speed up handoff process. MN may then receive
>more than one Solicited Router Advertisement from neighboring routers.
>After compare the signal strength of current router (sc) with the one
>received earliest from new router (sn), MN can then decide to perform a
>Handoff or not. If (sn + t2) >= sc, MN will perform handoff, otherwise
>MN will send another Router Solicitation.  t2 is used to prevent
>unnecessary handoff in the "ping pong" like movement within the overlap
>of two router domain. After handoff new router becomes current default
>router or MN, MN will then measure its signal strength from this router.

=> What you say above is very interesting and we've been looking into
similar algorithms that reuse L2 knowledge. One general comment though,
Sending a Neighbour solicitation (or even worse router solicitation) only
due to signal measurements makes the assummption that whenever you change
Base station, you also change subnets. That coupling is not required by
MIP and hence may also be inefficient in terms of radio resource usage.

Also are you making the assumption that you can talk to two routers
in two subnets at the same time ?
Do you have a specific Layer 2 in mind ?

Hesham

------_=_NextPart_001_01C0085E.50B9DD40-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Aug 17 11:26:44 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28554 for ; Thu, 17 Aug 2000 11:26:43 -0400 (EDT) Received: from standards (47.234.32.16:1158) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88DD9@standards.nortelnetworks.com>; Thu, 17 Aug 2000 11:13:54 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 16588 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 17 Aug 2000 11:13:54 -0400 Received: from ish7.ericsson.com.au (203.61.155.111:34907) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88DD8@standards.nortelnetworks.com>; Thu, 17 Aug 2000 11:13:53 -0400 Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id BAA04883; Fri, 18 Aug 2000 01:23:59 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id BAA19468; Fri, 18 Aug 2000 01:25:36 +1000 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Fri, 18 Aug 2000 01:25:34 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0085F.627A9550" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A5089EB179@eaubrnt018.epa.ericsson.se> Date: Fri, 18 Aug 2000 01:25:33 +1000 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] IPv6 handover document X-To: "Francis.Dupont@ENST-BRETAGNE.FR" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM 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_01C0085F.627A9550 Content-Type: text/plain; charset="iso-8859-1" PS: fast/smooth/seamless/smart handoffs are fine but mobile IPv6 code should support other more traditional usage of mobility, for instance it should be able to change an interface for another, for instance a GSM/GPRS/UMTS/... cellular device for a 100Mbits/s Ethernet. This is what makes mobile IPv* more powerful than any layer 2 solution and we should not drop this in order to fight with better weapons against layer 2 solutions. I am afraid this was forgotten by some of us... => Yes you're right. But the main reason is that the problem of eliminating packet delays / losses while performing handoff is harder to fix when doing a handoff within the same access technology (at least when you consider the routing problem alone). This is due to the nature of most radio links, as they don't allow you to be data-connected to two different coverage areas. On the other hand when doing an inter-access technology handoff (ie. two different interfaces on your device) you can actually make it lossles using standard MIPv6. ------_=_NextPart_001_01C0085F.627A9550 Content-Type: text/html; charset="iso-8859-1" RE: [MOBILE-IP] IPv6 handover document

PS: fast/smooth/seamless/smart handoffs are fine but mobile IPv6 code should
support other more traditional usage of mobility, for instance it should
be able to change an interface for another, for instance a GSM/GPRS/UMTS/...
cellular device for a 100Mbits/s Ethernet. This is what makes mobile IPv*
more powerful than any layer 2 solution and we should not drop this in order
to fight with better weapons against layer 2 solutions.
I am afraid this was forgotten by some of us...

=> Yes you're right. But the main reason is that the problem of eliminating
packet delays / losses while performing handoff is harder to fix
when doing a handoff within the same access technology (at least when
you consider the routing problem alone). This is due to the nature of
most radio links, as they don't allow you to be data-connected to two
different coverage areas.
On the other hand when doing an inter-access technology handoff
(ie. two different interfaces on your device) you can actually
make it lossles using standard MIPv6.



------_=_NextPart_001_01C0085F.627A9550-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Aug 17 12:15:45 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29457 for ; Thu, 17 Aug 2000 12:15:44 -0400 (EDT) Received: from standards (47.234.32.16:1158) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88E81@standards.nortelnetworks.com>; Thu, 17 Aug 2000 12:02:55 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 16810 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 17 Aug 2000 12:02:54 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88E80@standards.nortelnetworks.com>; Thu, 17 Aug 2000 12:02:54 -0400 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 JAA05869; Thu, 17 Aug 2000 09:14:56 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e7HGErG26389; Thu, 17 Aug 2000 09:14:53 -0700 X-Virus-Scanned: Thu, 17 Aug 2000 09:14:53 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdjB2Q0B; Thu, 17 Aug 2000 09:14:49 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <4B6BC00CD15FD2119E5F0008C7A419A5089EB178@eaubrnt018.epa.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <399C0F7C.784E47DD@iprg.nokia.com> Date: Thu, 17 Aug 2000 09:14:52 -0700 Reply-To: charliep@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: Re: [MOBILE-IP] IPv6 handover document X-To: "Hesham Soliman (EPA)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello, > I feel smooth handoff and seamless handoff are the same, they describe the > handoff in the way what we want it achieve, i.e., minimized packet loss. > In basic MIPv6 smooth or seamless handoff is achieved through establishing > forwarding from a previous care-of address. It is useful to distinguish between lossless handover and low-delay handover. For instance, one can achieve zero loss, but not zero delay, by merely buffering packets for future delivery to the new access router. Achieving low delay probabilistically automatically _reduces_ loss, since it reduces the time during which losses can occur, but sometimes one might get a burst during the exact time when the mobile was disconnected. Thus, low delay does not _necessarily_ mean low loss. I'm willing to concede that _zero_ delay "probably" means zero loss. Since we are lately in the business of defining terminology, why don't we define seamless to be low-loss _and_ low-delay? > I guess some L2 help is always needed to make a realistic handoff. > (ie. avoid these RA beacons). L2 help makes for better handovers -- assuming that layer 3 has a way to make use of the information. However, I am sure that we can make "realistic" handovers even with minimal L2 assistance. What seems "realistic" depends on the application, as always. A seamless handover for telnet or http may not appear seamless for voice. A seamless handover for voice may not appear seamless for video. > >After compare the signal strength of current router (sc) with the one > >received earliest from new router (sn), MN can then decide to perform a > >Handoff or not. If (sn + t2) >= sc, MN will perform handoff, otherwise > >MN will send another Router Solicitation. t2 is used to prevent > >unnecessary handoff in the "ping pong" like movement within the overlap > >of two router domain. After handoff new router becomes current default > >router or MN, MN will then measure its signal strength from this router. In the usual case, this can be done more simply by just letting the mobile node switch to the newest beacon, if beacons overlap and if they come fast enough. As you point out, some provision has to be made to avoid ping-pong behavior, but it does not have to be parameterized by a time constant. There are other simpler and more reliable solutions. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Aug 17 12:43:28 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29984 for ; Thu, 17 Aug 2000 12:43:28 -0400 (EDT) Received: from standards (47.234.32.16:1158) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88EDB@standards.nortelnetworks.com>; Thu, 17 Aug 2000 12:30:41 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 16931 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 17 Aug 2000 12:30:41 -0400 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88EDA@standards.nortelnetworks.com>; Thu, 17 Aug 2000 12:30:40 -0400 Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e7HGgX627834; Thu, 17 Aug 2000 18:42:33 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA17098; Thu, 17 Aug 2000 18:42:24 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id SAA58508; Thu, 17 Aug 2000 18:44:50 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-ID: <200008171644.SAA58508@givry.rennes.enst-bretagne.fr> Date: Thu, 17 Aug 2000 18:44:50 +0200 Reply-To: Francis.Dupont@ENST-BRETAGNE.FR Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] IPv6 handover document X-To: "Hesham Soliman (EPA)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Fri, 18 Aug 2000 01:17:54 +1000. <4B6BC00CD15FD2119E5F0008C7A419A5089EB178@eaubrnt018.epa.ericsson.se> In your previous mail you wrote: I guess some L2 help is always needed to make a realistic handoff. (ie. avoid these RA beacons). => I agree! => What you say above is very interesting and we've been looking into similar algorithms that reuse L2 knowledge. One general comment though, Sending a Neighbour solicitation (or even worse router solicitation) only => I agree about a NS is better than a RS. due to signal measurements makes the assummption that whenever you change Base station, you also change subnets. => we need to know the layer 2 property before in order to say if this assumption was made. In a IEEE 802.11 network in an ad-hoc mode ("an" because a well-known vendor has its own ad-hoc mode :-) you can do real good things with signal strength (no base station => no assumption). Same if base stations and routers are always in the same box. That coupling is not required by MIP and hence may also be inefficient in terms of radio resource usage. Also are you making the assumption that you can talk to two routers in two subnets at the same time ? => obviously there is something like overlapping cells here. Do you have a specific Layer 2 in mind ? => ah! This should be the next point after "Link Layer Assisted ...". I am afraid it is a bit hard to rely efficiently on a generic layer 2. Unfortunately not a scoop! Thanks Francis.Dupont@enst-bretagne.fr PS: is there a specialized mailing list for this topic? From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Aug 17 13:20:43 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00794 for ; Thu, 17 Aug 2000 13:20:42 -0400 (EDT) Received: from standards (47.234.32.16:1158) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88F65@standards.nortelnetworks.com>; Thu, 17 Aug 2000 13:07:59 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17104 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 17 Aug 2000 13:07:59 -0400 Received: from ish7.ericsson.com.au (203.61.155.111:35620) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88F64@standards.nortelnetworks.com>; Thu, 17 Aug 2000 13:07:58 -0400 Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id DAA06578; Fri, 18 Aug 2000 03:18:04 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id DAA24147; Fri, 18 Aug 2000 03:19:40 +1000 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Fri, 18 Aug 2000 03:19:38 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0086F.51A4C9C0" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A5089EB17E@eaubrnt018.epa.ericsson.se> Date: Fri, 18 Aug 2000 03:19:37 +1000 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] IPv6 handover document X-To: "Francis.Dupont@ENST-BRETAGNE.FR" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM 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_01C0086F.51A4C9C0 Content-Type: text/plain; charset="iso-8859-1" => obviously there is something like overlapping cells here. Sure but that doesn't necessarily mean you can receive two separate traffic streams. PS: is there a specialized mailing list for this topic? => Don't know ! ------_=_NextPart_001_01C0086F.51A4C9C0 Content-Type: text/html; charset="iso-8859-1" RE: [MOBILE-IP] IPv6 handover document

=> obviously there is something like overlapping cells here.

Sure but that doesn't necessarily mean you can receive two
separate traffic streams.


PS: is there a specialized mailing list for this topic?

=> Don't know !

------_=_NextPart_001_01C0086F.51A4C9C0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Aug 17 13:25:12 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00873 for ; Thu, 17 Aug 2000 13:25:11 -0400 (EDT) Received: from standards (47.234.32.16:1158) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88F72@standards.nortelnetworks.com>; Thu, 17 Aug 2000 13:08:59 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17120 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 17 Aug 2000 13:08:59 -0400 Received: from qhars002.nortel.com (47.101.112.102:53861) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88F71@standards.nortelnetworks.com>; Thu, 17 Aug 2000 13:08:54 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Thu, 17 Aug 2000 18:20:13 +0100 Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch1.nortel.com; Thu, 17 Aug 2000 12:14:18 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 17 Aug 2000 12:13:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0086E.78E433A0" Message-ID: <9A9367D1556AD21182C40000F80930AB025E5445@crchy28b.us.nortel.com> Date: Thu, 17 Aug 2000 12:13:33 -0500 Reply-To: Mohamed Khalil Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Mohamed Khalil Subject: Re: [MOBILE-IP] IPv6 handover document To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM 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_01C0086E.78E433A0 Content-Type: text/plain; charset="iso-8859-1" Hi Charlie , > * If we want to handle the case of fast handoff, we should get > some type of assistant from L2. If we want to go through this path , we > should specify the following types of handoff: > > 1- Mobile Node assisted handoff. > > The MN by some means will detect that it has moved to a new > foreign environment, and it will send a router solicitation > to acquire a router advertisement from the router(s) in the new > foreign sub-network. Their are two cases of sending > router solicitation to the routers resides at the new foreign > sub-network. > > a- The MN may have connections to the new and old foreign > sub-network. > In this case the MN can send the router solicitation > directly to the new foreign sub-network and receive the router > advertisement. > > b- The MN is not allowed to have multiple connections and it only > have a connection to the current sub-network. In this case > we could send a tunneled router solicitation to the new > foreign sub-network using the current established link. > The router advertisement should be tunneled back to the > mobile node. > > > 2- Network or System assisted handoff. > > Once the network detected the existence of the MN it will send a > router advertisment to the MN. > > * buffering of information in the old router and forwarding this > information later may be useful to minimize data loss. > > * Regarding your question if the draft is informational draft? If we > are defining in this draft the requirements for the smooth and fast > handoff, so this draft will be informational. If we are going to define > new signals so this draft should be standard track. > > > Mohamed & Haseeb > > > > > > -----Original Message----- > From: Linfeng Yang [mailto:lyang@TML.HUT.FI] > Sent: Thursday, August 17, 2000 5:07 AM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] IPv6 handover document > > > > =>Yes I think that is important, but also just as important is to > > separate fast, smooth and seamless handoffs from each other. I > believe > > the basic MIPv6 already provides smooth handoffs (as far as > routing goes). > > Here is my understanding about the different between fast, smooth > and > seamless handoff. Please correct me if I am wrong. > > I feel smooth handoff and seamless handoff are the same, they > describe the > handoff in the way what we want it achieve, i.e., minimized packet > loss. > In basic MIPv6 smooth or seamless handoff is achieved through > establishing > forwarding from a previous care-of address. > > Fast handoff on the other hand describe how we can achieve it. Fast > is > compared with basic MIPv6 in the sense that it will overcome the > router > advertisement interval limit. Here I schemed one way of Fast > handoff, I > call it Link Layer Assisted Fast Handoff. > > When MN is on idle movement, there is no need to perform fast > handoff, > since there is no packet loss issue. > > So MN will start fast handoff process when it is in active movement. > MN will constantly measure signal strength of message received from > current router, if it is lower than some threshold value (t1), MN > will > then send a router solicitation message in hope of receiving a > router > advertisement. In this way, MN can overcome the Router Advertisement > interval limit, thus speed up handoff process. MN may then receive > more than one Solicited Router Advertisement from neighboring > routers. > After compare the signal strength of current router (sc) with the > one > received earliest from new router (sn), MN can then decide to > perform a > Handoff or not. If (sn + t2) >= sc, MN will perform handoff, > otherwise > MN will send another Router Solicitation. t2 is used to prevent > unnecessary handoff in the "ping pong" like movement within the > overlap > of two router domain. After handoff new router becomes current > default > router or MN, MN will then measure its signal strength from this > router. > > We can see this is only local handoff, if accompanied with > establishing > forwarding from a previous care-of address, it can achieve even > better > smoothness. > > Regards, > > Linfeng Yang > Helsinki University of Technology > Telecommunications Software and Multimedia > Laboratory > P.O.Box 9700, 02015 HUT, Finland > Phone: +358 9 451 5250 Fax: +358 9 451 > 5351 > ------_=_NextPart_001_01C0086E.78E433A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] IPv6 handover document


       Hi   Charlie ,


      * If we want to handle the case of fast handoff, = we  should  get some type of assistant from L2. If we = want to go through this path ,  we should = specify the following types of handoff:

      1- Mobile Node assisted = handoff.

         The MN by some means will = detect that it has moved to a new foreign environment, and it will send = a router solicitation

         to acquire a router = advertisement from the router(s) in the new foreign sub-network. Their = are two cases of sending
         router solicitation to = the routers resides at the new foreign sub-network.

         a- The MN may have connections to the new and = old   foreign = sub-network.
             = In this case the MN can send the router solicitation  = directly to the new foreign = sub-network  and receive the router advertisement.  

           =20
       
         b- The MN is not allowed to have multiple connections = and it only have a connection to the current sub-network. In this = case

             = we could send a tunneled router solicitation to the new foreign = sub-network using the current established link.
             The router = advertisement should be tunneled back to the mobile node.
             
        
      2- Network or System assisted = handoff.

         Once the network detected = the existence of the MN it will send a router advertisment to the = MN.

      * buffering of information in the old = router and forwarding this information later may be useful to minimize = data loss.

      * Regarding your question if the draft is informational = draft? If we are defining in this draft the requirements for the smooth = and fast handoff, so this draft will be informational. If we are going = to define new signals so this draft should be standard = track.


      Mohamed & Haseeb





      -----Original Message-----
      From: Linfeng Yang = [mailto:lyang@TML.HUT.FI<= FONT SIZE=3D2 FACE=3D"Arial">]
      Sent: Thursday, August 17, 2000 5:07 = AM
      To: = MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
      Subject: Re: [MOBILE-IP] IPv6 = handover document


      > =3D>Yes I think that is = important, but also just as important is to
      > separate fast, smooth and = seamless handoffs from each other. I believe
      > the basic MIPv6 already provides = smooth handoffs (as far as routing goes).

      Here is my understanding about the = different between fast, smooth and
      seamless handoff. Please correct me = if I am wrong.

      I feel smooth handoff and seamless = handoff are the same, they describe the
      handoff in the way what we want it = achieve, i.e., minimized packet loss.
      In basic MIPv6 smooth or seamless = handoff is achieved through establishing
      forwarding from a previous care-of = address.

      Fast handoff on the other hand = describe how we can achieve it. Fast is
      compared with basic MIPv6 in the = sense that it will overcome the router
      advertisement interval limit. Here I = schemed one way of Fast handoff, I
      call it Link Layer Assisted Fast = Handoff.

      When MN is on idle movement, there is = no need to perform fast handoff,
      since there is no packet loss = issue.

      So MN will start fast handoff process = when it is in active movement.
      MN will constantly measure signal = strength of message received from
      current router, if it is lower than = some threshold value (t1), MN will
      then send a router solicitation = message in hope of receiving a router
      advertisement. In this way, MN can = overcome the Router Advertisement
      interval limit, thus speed up handoff = process. MN may then receive
      more than one Solicited Router = Advertisement from neighboring routers.
      After compare the signal strength of = current router (sc) with the one
      received earliest from new router = (sn), MN can then decide to perform a
      Handoff or not. If (sn + t2) >=3D = sc, MN will perform handoff, otherwise
      MN will send another Router = Solicitation.  t2 is used to prevent
      unnecessary handoff in the "ping = pong" like movement within the overlap
      of two router domain. After handoff = new router becomes current default
      router or MN, MN will then measure = its signal strength from this router.

      We can see this is only local handoff, = if accompanied with establishing
      forwarding from a previous care-of = address, it can achieve even better
      smoothness.

      Regards,

      Linfeng Yang
               &nb= sp;      Helsinki University of = Technology
               &nb= sp;      Telecommunications Software and = Multimedia Laboratory
               &nb= sp;      P.O.Box 9700, 02015 HUT, = Finland
               &nb= sp;      Phone: +358 9 451 = 5250           Fax: = +358 9 451 5351

------_=_NextPart_001_01C0086E.78E433A0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Aug 17 13:30:19 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01000 for ; Thu, 17 Aug 2000 13:30:18 -0400 (EDT) Received: from standards (47.234.32.16:1158) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88FEE@standards.nortelnetworks.com>; Thu, 17 Aug 2000 13:17:25 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17288 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 17 Aug 2000 13:17:25 -0400 Received: from ish7.ericsson.com.au (203.61.155.111:35674) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB88FED@standards.nortelnetworks.com>; Thu, 17 Aug 2000 13:17:24 -0400 Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id DAA06722; Fri, 18 Aug 2000 03:27:30 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id DAA24542; Fri, 18 Aug 2000 03:29:07 +1000 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Fri, 18 Aug 2000 03:29:05 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C00870.A41D31F0" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A5089EB180@eaubrnt018.epa.ericsson.se> Date: Fri, 18 Aug 2000 03:29:04 +1000 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] IPv6 handover document X-To: Mohamed Khalil To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM 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_01C00870.A41D31F0 Content-Type: text/plain; charset="iso-8859-1" Hi Mohamed, * If we want to handle the case of fast handoff, we should get some type of assistant from L2. If we want to go through this path , we should specify the following types of handoff: 1- Mobile Node assisted handoff. The MN by some means will detect that it has moved to a new foreign environment, and it will send a router solicitation to acquire a router advertisement from the router(s) in the new foreign sub-network. Their are two cases of sending router solicitation to the routers resides at the new foreign sub-network. a- The MN may have connections to the new and old foreign sub-network. In this case the MN can send the router solicitation directly to the new foreign sub-network and receive the router advertisement. b- The MN is not allowed to have multiple connections and it only have a connection to the current sub-network. In this case we could send a tunneled router solicitation to the new foreign sub-network using the current established link. The router advertisement should be tunneled back to the mobile node. => Agree 100 % -----Original Message----- From: Linfeng Yang [ mailto:lyang@TML.HUT.FI ] Sent: Thursday, August 17, 2000 5:07 AM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] IPv6 handover document > =>Yes I think that is important, but also just as important is to > separate fast, smooth and seamless handoffs from each other. I believe > the basic MIPv6 already provides smooth handoffs (as far as routing goes). Here is my understanding about the different between fast, smooth and seamless handoff. Please correct me if I am wrong. I feel smooth handoff and seamless handoff are the same, they describe the handoff in the way what we want it achieve, i.e., minimized packet loss. In basic MIPv6 smooth or seamless handoff is achieved through establishing forwarding from a previous care-of address. Fast handoff on the other hand describe how we can achieve it. Fast is compared with basic MIPv6 in the sense that it will overcome the router advertisement interval limit. Here I schemed one way of Fast handoff, I call it Link Layer Assisted Fast Handoff. When MN is on idle movement, there is no need to perform fast handoff, since there is no packet loss issue. So MN will start fast handoff process when it is in active movement. MN will constantly measure signal strength of message received from current router, if it is lower than some threshold value (t1), MN will then send a router solicitation message in hope of receiving a router advertisement. In this way, MN can overcome the Router Advertisement interval limit, thus speed up handoff process. MN may then receive more than one Solicited Router Advertisement from neighboring routers. After compare the signal strength of current router (sc) with the one received earliest from new router (sn), MN can then decide to perform a Handoff or not. If (sn + t2) >= sc, MN will perform handoff, otherwise MN will send another Router Solicitation. t2 is used to prevent unnecessary handoff in the "ping pong" like movement within the overlap of two router domain. After handoff new router becomes current default router or MN, MN will then measure its signal strength from this router. We can see this is only local handoff, if accompanied with establishing forwarding from a previous care-of address, it can achieve even better smoothness. Regards, Linfeng Yang Helsinki University of Technology Telecommunications Software and Multimedia Laboratory P.O.Box 9700, 02015 HUT, Finland Phone: +358 9 451 5250 Fax: +358 9 451 5351 ------_=_NextPart_001_01C00870.A41D31F0 Content-Type: text/html; charset="iso-8859-1" RE: [MOBILE-IP] IPv6 handover document
Hi Mohamed,

      * If we want to handle the case of fast handoff, we  should  get some type of assistant from L2. If we want to go through this path ,  we should specify the following types of handoff:

      1- Mobile Node assisted handoff.

         The MN by some means will detect that it has moved to a new foreign environment, and it will send a router solicitation

         to acquire a router advertisement from the router(s) in the new foreign sub-network. Their are two cases of sending
         router solicitation to the routers resides at the new foreign sub-network.

         a- The MN may have connections to the new and old   foreign sub-network.
             In this case the MN can send the router solicitation  directly to the new foreign sub-network  and receive the router advertisement.  

           
       
         b- The MN is not allowed to have multiple connections and it only have a connection to the current sub-network. In this case

             we could send a tunneled router solicitation to the new foreign sub-network using the current established link.
             The router advertisement should be tunneled back to the mobile node.
             
       

      => Agree 100 %

         





      -----Original Message-----
      From: Linfeng Yang [mailto:lyang@TML.HUT.FI]
      Sent: Thursday, August 17, 2000 5:07 AM
      To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
      Subject: Re: [MOBILE-IP] IPv6 handover document


      > =>Yes I think that is important, but also just as important is to
      > separate fast, smooth and seamless handoffs from each other. I believe
      > the basic MIPv6 already provides smooth handoffs (as far as routing goes).

      Here is my understanding about the different between fast, smooth and
      seamless handoff. Please correct me if I am wrong.

      I feel smooth handoff and seamless handoff are the same, they describe the
      handoff in the way what we want it achieve, i.e., minimized packet loss.
      In basic MIPv6 smooth or seamless handoff is achieved through establishing
      forwarding from a previous care-of address.

      Fast handoff on the other hand describe how we can achieve it. Fast is
      compared with basic MIPv6 in the sense that it will overcome the router
      advertisement interval limit. Here I schemed one way of Fast handoff, I
      call it Link Layer Assisted Fast Handoff.

      When MN is on idle movement, there is no need to perform fast handoff,
      since there is no packet loss issue.

      So MN will start fast handoff process when it is in active movement.
      MN will constantly measure signal strength of message received from
      current router, if it is lower than some threshold value (t1), MN will
      then send a router solicitation message in hope of receiving a router
      advertisement. In this way, MN can overcome the Router Advertisement
      interval limit, thus speed up handoff process. MN may then receive
      more than one Solicited Router Advertisement from neighboring routers.
      After compare the signal strength of current router (sc) with the one
      received earliest from new router (sn), MN can then decide to perform a
      Handoff or not. If (sn + t2) >= sc, MN will perform handoff, otherwise
      MN will send another Router Solicitation.  t2 is used to prevent
      unnecessary handoff in the "ping pong" like movement within the overlap
      of two router domain. After handoff new router becomes current default
      router or MN, MN will then measure its signal strength from this router.

      We can see this is only local handoff, if accompanied with establishing
      forwarding from a previous care-of address, it can achieve even better
      smoothness.

      Regards,

      Linfeng Yang
                      Helsinki University of Technology
                      Telecommunications Software and Multimedia Laboratory
                      P.O.Box 9700, 02015 HUT, Finland
                      Phone: +358 9 451 5250           Fax: +358 9 451 5351

------_=_NextPart_001_01C00870.A41D31F0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Aug 17 13:45:12 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01301 for ; Thu, 17 Aug 2000 13:45:12 -0400 (EDT) Received: from standards (47.234.32.16:1158) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB89040@standards.nortelnetworks.com>; Thu, 17 Aug 2000 13:32:31 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17396 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 17 Aug 2000 13:32:31 -0400 Received: from oulu.fi (ousrvr.oulu.fi) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8903F@standards.nortelnetworks.com>; Thu, 17 Aug 2000 13:32:21 -0400 Received: from ee.oulu.fi (ees2.oulu.fi [130.231.61.23]) by oulu.fi (8.8.5/8.8.5) with ESMTP id UAA16275 for ; Thu, 17 Aug 2000 20:44:16 +0300 (EET DST) Received: from stekt34 (stekt34 [130.231.60.74]) by ee.oulu.fi (8.9.3/8.9.3) with ESMTP id UAA02495 for ; Thu, 17 Aug 2000 20:44:12 +0300 (EET DST) X-Sender: over@stekt34 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Thu, 17 Aug 2000 20:44:12 +0300 Reply-To: Mika Ylianttila Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Mika Ylianttila Subject: Re: [MOBILE-IP] IPv6 handover document To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <4B6BC00CD15FD2119E5F0008C7A419A5089EB178@eaubrnt018.epa.ericsson.se> On Fri, 18 Aug 2000, Hesham Soliman (EPA) wrote: >I guess some L2 help is always needed to make a realistic handoff. >(ie. avoid these RA beacons). I agree. To get this discussion further, let me ask two concrete questions: - Which L2s are we talking about? - Which parameters are we talking about? As we know there are several L2s we can think about (GSM, IS-95, UMTS, IEEE 802.11 WLAN, Bluetooth, cdma2000, etc.). I would suggest thinking about common parameters in these and how they be could used in L3 with Mobile IP. I have some parameters in my mind. RSS is of course the most popular L2 parameter. Then there are BER, SNR, CIR, etc. In addition to these, there can be thinked of some other parameters, such as location and velocity. When thinking about the handoff mechanism, I would like to illustrate it as a "black box", which has a number of inputs and a number of outputs. Selected L2 parameters with potentially some additional parameters such as location and velocity are the inputs, and the output would be handoff signal, and potentially some other, such as "alert" signal for MH to prepare for handoff. For example, in an inter-technology mobility scenario between a cellular and WLAN, MH can have two pcmcia cards in a laptop. While working at cellular, WLAN card can be powered down. Network could inform e.g. based on location info, that MH is approaching on overlay-WLAN, and thus "alert" signal would mean: "power up your wlan card, you need to use it as soon as you hear the WLAN beacon". I think this is a very realistic scenario where location information could be used as an input for the handoff mechanism. The actual handoff mechanism or algorith could be left (if mobile controlled handoff is used) to be implemented by the manufacturers. I would imagine that the IETF handoff drafts could define a framework for the mechanism that ALLOWS measuring those L2-parameters-to-be-selected. Looking forward to hear some concrete suggestions what "some L2 help" would mean in practice. I think the challenge is to make the handoff mechanism simultaneously generic enough and yet "optimized" even in a rough sense. ;) -- Mika Ylianttila M.Sc., Research Scientist Centre for Wireless Communications PL 4500, Tutkijantie 2 E, FIN-90014 University of Oulu, Finland From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Aug 17 14:00:04 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01498 for ; Thu, 17 Aug 2000 14:00:04 -0400 (EDT) Received: from standards (47.234.32.16:1158) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB89084@standards.nortelnetworks.com>; Thu, 17 Aug 2000 13:47:18 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17477 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 17 Aug 2000 13:47:17 -0400 Received: from tml-gw.tml.hut.fi (tml.hut.fi) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8907B@standards.nortelnetworks.com>; Thu, 17 Aug 2000 13:37:16 -0400 Received: (from smap@localhost) by tml-gw.tml.hut.fi (8.8.7/8.8.7) id UAA14837 for ; Thu, 17 Aug 2000 20:49:18 +0300 Received: from caffeine.tml.hut.fi(130.233.45.27) by tml-gw.tml.hut.fi via smap (V2.0) id xma014835; Thu, 17 Aug 00 20:48:49 +0300 Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7]) by caffeine.tml.hut.fi (8.10.2/8.10.2) with ESMTP id e7HHn0u25124 for ; Thu, 17 Aug 2000 20:49:01 +0300 (EET DST) Received: from localhost (lyang@localhost) by morphine.tml.hut.fi (8.9.2/8.7.1) with ESMTP id UAA02304 for ; Thu, 17 Aug 2000 20:48:35 +0300 (EET DST) X-Authentication-Warning: morphine.tml.hut.fi: lyang owned process doing -bs MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Thu, 17 Aug 2000 20:48:34 +0300 Reply-To: Linfeng Yang Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Linfeng Yang Subject: Re: [MOBILE-IP] IPv6 handover document To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <4B6BC00CD15FD2119E5F0008C7A419A5089EB180@eaubrnt018.epa.ericsson.se> Hi all, I have to back to "work", even it is about 8:45 pm local time :-) On Fri, 18 Aug 2000, Hesham Soliman (EPA) wrote: (Sorry, I deleted most of the lines to keep the mail short.) > Hi Mohamed, > => Agree 100 % I agree too. Still I feel, if we want fine tune handoff performance, we need L2's assist. We should not isolate ourselves inside L3. We needn't go deep to L2, but we need the interface from L2. Linfeng Yang Helsinki University of Technology Telecommunications Software and Multimedia Laboratory P.O.Box 9700, 02015 HUT, Finland Phone: +358 9 451 5250 Fax: +358 9 451 5351 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Aug 17 14:15:58 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01857 for ; Thu, 17 Aug 2000 14:15:57 -0400 (EDT) Received: from standards (47.234.32.16:1158) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB890CB@standards.nortelnetworks.com>; Thu, 17 Aug 2000 14:03:16 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17577 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 17 Aug 2000 14:03:16 -0400 Received: from tml-gw.tml.hut.fi (tml.hut.fi) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB890C5@standards.nortelnetworks.com>; Thu, 17 Aug 2000 13:53:15 -0400 Received: (from smap@localhost) by tml-gw.tml.hut.fi (8.8.7/8.8.7) id VAA14928 for ; Thu, 17 Aug 2000 21:05:18 +0300 Received: from caffeine.tml.hut.fi(130.233.45.27) by tml-gw.tml.hut.fi via smap (V2.0) id xma014926; Thu, 17 Aug 00 21:04:55 +0300 Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7]) by caffeine.tml.hut.fi (8.10.2/8.10.2) with ESMTP id e7HI56u25196 for ; Thu, 17 Aug 2000 21:05:06 +0300 (EET DST) Received: from localhost (lyang@localhost) by morphine.tml.hut.fi (8.9.2/8.7.1) with ESMTP id VAA02342 for ; Thu, 17 Aug 2000 21:04:40 +0300 (EET DST) X-Authentication-Warning: morphine.tml.hut.fi: lyang owned process doing -bs MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Thu, 17 Aug 2000 21:04:40 +0300 Reply-To: Linfeng Yang Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Linfeng Yang Subject: Re: [MOBILE-IP] IPv6 handover document To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <4B6BC00CD15FD2119E5F0008C7A419A5089EB17E@eaubrnt018.epa.ericsson.se> > => obviously there is something like overlapping cells here. > > Sure but that doesn't necessarily mean you can receive two > separate traffic streams. Yes my assumption is, there must be some form of overlapping, otherwise you cannot achieve zero-delay. -Linfeng From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Aug 17 14:42:22 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02455 for ; Thu, 17 Aug 2000 14:42:21 -0400 (EDT) Received: from standards (47.234.32.16:3985) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB89125@standards.nortelnetworks.com>; Thu, 17 Aug 2000 14:29:45 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17686 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 17 Aug 2000 14:29:45 -0400 Received: from tml-gw.tml.hut.fi (tml.hut.fi) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB89118@standards.nortelnetworks.com>; Thu, 17 Aug 2000 14:19:45 -0400 Received: (from smap@localhost) by tml-gw.tml.hut.fi (8.8.7/8.8.7) id VAA15092 for ; Thu, 17 Aug 2000 21:31:48 +0300 Received: from caffeine.tml.hut.fi(130.233.45.27) by tml-gw.tml.hut.fi via smap (V2.0) id xma015090; Thu, 17 Aug 00 21:31:40 +0300 Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7]) by caffeine.tml.hut.fi (8.10.2/8.10.2) with ESMTP id e7HIVqu25305 for ; Thu, 17 Aug 2000 21:31:52 +0300 (EET DST) Received: from localhost (lyang@localhost) by morphine.tml.hut.fi (8.9.2/8.7.1) with ESMTP id VAA02382 for ; Thu, 17 Aug 2000 21:31:25 +0300 (EET DST) X-Authentication-Warning: morphine.tml.hut.fi: lyang owned process doing -bs MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Thu, 17 Aug 2000 21:31:25 +0300 Reply-To: Linfeng Yang Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Linfeng Yang Subject: Re: [MOBILE-IP] IPv6 handover document To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <399C0F7C.784E47DD@iprg.nokia.com> Hi, > Since we are lately in the business of defining terminology, why > don't we define seamless to be low-loss _and_ low-delay? I agree. If we cannot eliminate the use of seamless, smooth, and fast, we should at least define them in terms of low-delay, low-loss, zero-delay, and zero-loss before using them. Regards, Linfeng Yang Helsinki University of Technology Telecommunications Software and Multimedia Laboratory P.O.Box 9700, 02015 HUT, Finland Phone: +358 9 451 5250 Fax: +358 9 451 5351 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Aug 17 15:12:56 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02938 for ; Thu, 17 Aug 2000 15:12:55 -0400 (EDT) Received: from standards (47.234.32.16:2064) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB891A9@standards.nortelnetworks.com>; Thu, 17 Aug 2000 15:00:16 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17861 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 17 Aug 2000 15:00:16 -0400 Received: from tml-gw.tml.hut.fi (tml.hut.fi) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8919E@standards.nortelnetworks.com>; Thu, 17 Aug 2000 14:50:15 -0400 Received: (from smap@localhost) by tml-gw.tml.hut.fi (8.8.7/8.8.7) id WAA15335 for ; Thu, 17 Aug 2000 22:02:18 +0300 Received: from caffeine.tml.hut.fi(130.233.45.27) by tml-gw.tml.hut.fi via smap (V2.0) id xma015331; Thu, 17 Aug 00 22:02:15 +0300 Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7]) by caffeine.tml.hut.fi (8.10.2/8.10.2) with ESMTP id e7HJ2Qu25463 for ; Thu, 17 Aug 2000 22:02:26 +0300 (EET DST) Received: from localhost (lyang@localhost) by morphine.tml.hut.fi (8.9.2/8.7.1) with ESMTP id WAA02491 for ; Thu, 17 Aug 2000 22:02:00 +0300 (EET DST) X-Authentication-Warning: morphine.tml.hut.fi: lyang owned process doing -bs MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Thu, 17 Aug 2000 22:01:59 +0300 Reply-To: Linfeng Yang Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Linfeng Yang Subject: Re: [MOBILE-IP] IPv6 handover document To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200008171457.QAA57909@givry.rennes.enst-bretagne.fr> Hi, On Thu, 17 Aug 2000, Francis Dupont wrote: > When MN is on idle movement, there is no need to perform fast handoff, > since there is no packet loss issue. > > => idle movement is "not moving", isn't it? And active is "moving"? Sorry, they are Cellular IP like concept, I expressed them in a too simplified form. Linfeng Yang Helsinki University of Technology Telecommunications Software and Multimedia Laboratory P.O.Box 9700, 02015 HUT, Finland Phone: +358 9 451 5250 Fax: +358 9 451 5351 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Aug 17 15:28:39 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03236 for ; Thu, 17 Aug 2000 15:28:39 -0400 (EDT) Received: from standards (47.234.32.16:2064) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB891F1@standards.nortelnetworks.com>; Thu, 17 Aug 2000 15:16:02 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17968 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 17 Aug 2000 15:16:02 -0400 Received: from sirius.ctr.columbia.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB891F0@standards.nortelnetworks.com>; Thu, 17 Aug 2000 15:16:02 -0400 Received: from will (dialup-cc5-13.cc.columbia.edu [128.59.4.15]) by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with SMTP id PAA24921; Thu, 17 Aug 2000 15:27:59 -0400 (EDT) References: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: <000201c00868$9ae08400$0f043b80@comet.columbia.edu> Date: Thu, 17 Aug 2000 11:36:51 -0400 Reply-To: Andrew Campbell Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Andrew Campbell Subject: Re: [MOBILE-IP] charter review X-cc: campbell@ee.columbia.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit I am happy with this change. Our intention with introducing Cellular IP was never to drive for any form of standardization with the protocol. We wanted to inform and push an agenda that Mobile IP needs a number of important enhancements to be more commercial useful to carriers/wireless ISPs; these are: 1) fast and low loss handoff control 2) IP paging 3) a link level API that exposes link state information (e.g., SNR) for fast handoff A number of people see CIP at odds with Mobile IP. That is not the case. CIP and Mobile IP run in unison to support 1-3. (A CIP terminal runs CIP and Mobile IP to achieve micro and macro mobility, respectively). The challenge is to provide 1-3 with minimal state, signaling and complexity. I'm convinced that Mobile IP needs to provide 1-3. Looks like the charter embraces 1 but not 2 and 3 at the moment. Andrew > > > > The chairs would like to refocus the Mobile IP WG objectives to > > protocols and solutions that are based on Mobile IP v4 and v6. The > > current objective in the charter of enhancing the protocol to make it > > suitable for deployment can be achieved if we simply focus on what > > needs to be done from the perspective of just Mobile IP as specified > > for IPv4 and IPv6. > > > > We believe that alternatives to Mobile IP for IP mobility are outside > > the scope of this WG. To this end we are proposing that we remove the > > micromobility bullet item from our charter. Removing this means that > > we are not going to be considering protocols that are not based of > > Mobile IP v4/6. The two specific protocols that are WG items currently > > that will drop out of scope immediately are Cellular IP and HAWAII. > > > > We would like to hear from WG members their opinions on this > > proposal. You should be aware that going forward there MAY or > > MAY NOT necessarily be another WG in the IETF to pick up this work > > although we feel that it is a topic that needs separate coverage. > > > > Phil and Basavaraj > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Aug 17 15:39:17 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03462 for ; Thu, 17 Aug 2000 15:39:17 -0400 (EDT) Received: from standards (47.234.32.16:2064) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB89234@standards.nortelnetworks.com>; Thu, 17 Aug 2000 15:26:40 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17978 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 17 Aug 2000 15:26:40 -0400 Received: from motgate2.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB891F9@standards.nortelnetworks.com>; Thu, 17 Aug 2000 15:16:40 -0400 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id MAA13264 for ; Thu, 17 Aug 2000 12:28:43 -0700 (MST)] Received: [from relay1.cig.mot.com (relay1.cig.mot.com [136.182.15.23]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id MAA01660 for ; Thu, 17 Aug 2000 12:28:43 -0700 (MST)] Received: from Motorola.Com ([199.1.50.110]) by relay1.cig.mot.com (8.8.8+Sun/SCERG-RELAY-1.11b) with ESMTP id OAA00004; Thu, 17 Aug 2000 14:28:17 -0500 (CDT) X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <399C3AF4.A53FA148@Motorola.Com> Date: Thu, 17 Aug 2000 14:20:20 -0500 Reply-To: Phil Neumiller Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Phil Neumiller Organization: Personal Area Networking (PAN) Subject: Re: [MOBILE-IP] IPv6 handover document X-To: Mika Ylianttila To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Are we being too specific here? Wouldn't a generic hinting mechanism work better? In ye olde layered models of days gone by, there was something called a SAP and an SPP. The SAP is a service access port, and the SPP is a service provision point. Something like the following could be done. Verticle Hinting Framework ========================== ------------------------ | Any transport | ------------------------- | SAP | | ------------------------ | IP routing / Mobile-IP | ------------------------ | SPP | | ------------------------- | Any Link Layer | ------------------------ No a generic packet for hinting up and down can be added and of course easily extened. This can cary bad/good news about the link lauyer, and even propogate it up to the transport. Thanks, Phil Neumiller Mika Ylianttila wrote: > > On Fri, 18 Aug 2000, Hesham Soliman (EPA) wrote: > > >I guess some L2 help is always needed to make a realistic handoff. > >(ie. avoid these RA beacons). > > I agree. To get this discussion further, let me ask two concrete > questions: > > - Which L2s are we talking about? > - Which parameters are we talking about? > > As we know there are several L2s we can think about (GSM, IS-95, UMTS, IEEE > 802.11 WLAN, Bluetooth, cdma2000, etc.). I would suggest thinking about > common parameters in these and how they be could used in L3 with Mobile IP. > I have some parameters in my mind. RSS is of course the most popular L2 > parameter. Then there are BER, SNR, CIR, etc. In addition to these, there > can be thinked of some other parameters, such as location and velocity. > > When thinking about the handoff mechanism, I would like to illustrate it as > a "black box", which has a number of inputs and a number of outputs. > Selected L2 parameters with potentially some additional parameters such as > location and velocity are the inputs, and the output would be handoff > signal, and potentially some other, such as "alert" signal for MH to > prepare for handoff. > > For example, in an inter-technology mobility scenario between a cellular > and WLAN, MH can have two pcmcia cards in a laptop. While working at > cellular, WLAN card can be powered down. Network could inform e.g. based on > location info, that MH is approaching on overlay-WLAN, and thus "alert" > signal would mean: "power up your wlan card, you need to use it as soon as > you hear the WLAN beacon". I think this is a very realistic scenario where > location information could be used as an input for the handoff mechanism. > > The actual handoff mechanism or algorith could be left (if mobile > controlled handoff is used) to be implemented by the manufacturers. I would > imagine that the IETF handoff drafts could define a framework for the > mechanism that ALLOWS measuring those L2-parameters-to-be-selected. > > Looking forward to hear some concrete suggestions what "some L2 help" would > mean in practice. I think the challenge is to make the handoff mechanism > simultaneously generic enough and yet "optimized" even in a rough sense. ;) > > -- > Mika Ylianttila > M.Sc., Research Scientist > Centre for Wireless Communications > PL 4500, Tutkijantie 2 E, FIN-90014 > University of Oulu, Finland From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Aug 17 15:50:50 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03649 for ; Thu, 17 Aug 2000 15:50:49 -0400 (EDT) Received: from standards (47.234.32.16:2064) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB89278@standards.nortelnetworks.com>; Thu, 17 Aug 2000 15:36:00 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18059 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 17 Aug 2000 15:36:00 -0400 Received: from mail.yourdomain.com (m319-mp1-cvx1a.man.ntl.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB89233@standards.nortelnetworks.com>; Thu, 17 Aug 2000 15:25:59 -0400 Message-ID: Date: Thu, 17 Aug 2000 15:36:00 -0400 Reply-To: announce@LEISUREWEBCAMS.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: announce@LEISUREWEBCAMS.COM Subject: [MOBILE-IP] LeisureWebcams.com - See the World To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM LeisureWebcams.com is a recently launched website specialising in providing free LIVE access to over 1,500 webcams and 2,000 Tourist Offices world wide. Check it out:- http://www.leisurewebcams.com/ This offers you the chance to check out live and frequently updated images of your chosen location through the webcams and get detailed local knowledge through the Tourist Offices. Along with booking holidays direct through our travel partner, there is the opportunity to sell your unwanted clothes and equipment through our free Swap Shop. There is a lot to see, so if you have enjoyed your trip through our site, do tell your friends and let us know through 'Your Views'. If you have any suggestions for the site, or queries, please feel free to contact me at cy@LeisureWebcams.com. I look forward to hearing from you. Kind regards, Charlie Yates MARKETING DIRECTOR LeisureWebcams.com From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Aug 17 23:30:34 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10459 for ; Thu, 17 Aug 2000 23:30:33 -0400 (EDT) Received: from standards (47.234.32.16:2113) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB893CB@standards.nortelnetworks.com>; Thu, 17 Aug 2000 23:17:49 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18593 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 17 Aug 2000 23:17:49 -0400 Received: from sj-msg-core-1.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB893CA@standards.nortelnetworks.com>; Thu, 17 Aug 2000 23:17:49 -0400 Received: from shako.cisco.com (shako.cisco.com [161.44.3.76]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id UAA00012; Thu, 17 Aug 2000 20:29:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Thu, 17 Aug 2000 23:29:42 -0400 Reply-To: Madhavi W Subbarao Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Madhavi W Subbarao Subject: Re: [MOBILE-IP] IPv6 handover document X-To: "Charles E. Perkins" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <399AC363.972BED9@iprg.nokia.com> Charlie, Please make your writeup available. Thanks, Madhavi On Wed, 16 Aug 2000, Charles E. Perkins wrote: > Hello folks, > > I have a primitive version of a writeup for the IPv6 handover > document that was authorized during the Pittsburgh IETF 48. > I am not sure whether this is supposed to be an edited document, > or a co-authored document, or in general whose names are supposed > to appear on the document. My plan is as follows: > > 1. Distribute the primitive and rough document I have now to see > if it is a useful starting point. > 2. Get additional production collaboration from the interested participants > 3. Submit an Internet Draft by end of August > 4. Get discussion by the working group > 5. Submit revised Internet Draft by end of October > > Anyone who is interested in participation in (1) and (2) please > let me know and I will send you what I have. > > Regards, > Charlie P. > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Aug 18 04:23:16 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25115 for ; Fri, 18 Aug 2000 04:23:15 -0400 (EDT) Received: from standards (47.234.32.16:2104) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB894CB@standards.nortelnetworks.com>; Fri, 18 Aug 2000 4:10:43 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18922 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 18 Aug 2000 04:10:42 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB894C5@standards.nortelnetworks.com>; Fri, 18 Aug 2000 4:00:41 -0400 Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id e7I8Cjp09941 for ; Fri, 18 Aug 2000 10:12:45 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id KAA12711; Fri, 18 Aug 2000 10:12:44 +0200 X-Mailer: Mozilla 4.74 [en] (Win95; U) X-Accept-Language: en, sv MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <399CEF1E.763D1800@era.ericsson.se> Date: Fri, 18 Aug 2000 10:09:02 +0200 Reply-To: Mattias Pettersson Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Mattias Pettersson Organization: Ericsson Radio Systems AB Subject: Re: [MOBILE-IP] IPv6 handover document To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Linfeng Yang wrote: > > => obviously there is something like overlapping cells here. > > > > Sure but that doesn't necessarily mean you can receive two > > separate traffic streams. > > Yes my assumption is, there must be some form of overlapping, otherwise you > cannot achieve zero-delay. Hi, Yes, overlapping is of course necessary, but that's not what Hesham is pointing at. The nature of radio link layers is not exactly like an Ethernet, where everyone can hear everyone else. Since bandwidth is limited and transceivers are interfering, different transceivers will use different physical and/or logical channels. If the link medium is using different physical channels (different frequencies, not CDMA technology, for instance), then a receiver can usually only lock onto one single of these channels, since (due to cost) it is only equipped with one transceiver. If access point A is on subnet Na and using channel Ca, a mobile node locked onto channel Ca won't be able to hear or measure anything of a possible access point B on subnet Nb on channel Cb. The only way for the mobile node to detect the presence of B would be to start a scan over all channels (and do so occasionally) or to be informed of its existence by the network over channel Ca. The few radio technologies I've fought with do this and if anyone else have better news I would be very happy to hear of it. The point is: we must understand these limitations inherited from radio links and take them into consideration when designing a handoff scheme. Otherwise, if we assume the opposite with the ability to hear routers regardless of radio channels and have good enough overlap plus add some heuristics in reachability detection of routers and maybe crank up the RA rate a bit, good old Mobile IPv6 will do the work perfectly without our help! /Mattias Pettersson From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Aug 18 05:04:44 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25442 for ; Fri, 18 Aug 2000 05:04:44 -0400 (EDT) Received: from standards (47.234.32.16:1595) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB89512@standards.nortelnetworks.com>; Fri, 18 Aug 2000 4:52:10 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19020 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 18 Aug 2000 04:52:10 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8950F@standards.nortelnetworks.com>; Fri, 18 Aug 2000 4:42:10 -0400 Received: from kl-media.de ([195.185.251.80]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id DAA13712; Fri, 18 Aug 2000 03:54:12 -0500 (CDT) Received: from 209.178.164.57 [209.178.164.57] by kl-media.de (SMTPD32-6.00) id A86F42601A0; Fri, 18 Aug 2000 10:57:03 +0100 X-Priority: 3 X-MSMail-Priority: Normal Message-ID: <00004c8d0200$00003f7f$00007291@209.178.164.57> Date: Fri, 18 Aug 2000 01:54:05 -0700 Reply-To: acctcard2@HOTMAIL.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: acctcard2@HOTMAIL.COM Subject: [MOBILE-IP] Merchant Account - Limited Time - No Setup Fee 29329 X-To: Undisclosed.Recipients@hosaka.smallworks.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM HOW TO SUBSTANTIALLY INCREASE SALES: Easily accept major credit cards right away! Act now and all Setup & App. fees waived Merchant Status will help you increase sales by an incredible 50% to 400%. Stop losing valuable sales! With one phone call you can be: Accepting all major credit cards! Accepting checks over the net or by Fax! Accepting real time processing for member sites! Gaining costumer loyalty and trust! Close the sale now. No more wondering if "The check is in the mail" We specialize in helping those entrepreneurs who are just starting out: no credit, poor credit, or even if you have great credit. Almost everyone is approved! For the next 5 days we will waive all Setup & App. fees! (other companies charge $200 to $500 to set up) In Business since 1992 *************************************************************** For Free Setup DOUBLE CLICK ON: mailto:credit22@altavista.com?subject=credit Include your name, phone number and best time to call. *Subject must contain the word "credit" for us to receive your request. Or you can call 1(888) 242-8260 now! Our courteous customer care reps are anxious to help you get your merchant account today. *************************************************************** If you feel that this has reached you in error please DOUBLE CLICK ON: mailto:remonow15@china.com?subject=remove We will insure that your email address is removed from our database immediately. *Subject must contain the word "remove" for us to remove you. HOW TO SUBSTANTIALLY INCREASE SALES: From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Aug 18 05:25:29 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25621 for ; Fri, 18 Aug 2000 05:25:29 -0400 (EDT) Received: from standards (47.234.32.16:1595) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8956B@standards.nortelnetworks.com>; Fri, 18 Aug 2000 5:12:50 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19125 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 18 Aug 2000 05:12:50 -0400 Received: from prue.eim.surrey.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8955E@standards.nortelnetworks.com>; Fri, 18 Aug 2000 5:02:50 -0400 Received: from carter-e0.ee.surrey.ac.uk ([131.227.86.16]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 13PiEm-0003xG-00; Fri, 18 Aug 2000 10:14:52 +0100 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Fri, 18 Aug 2000 10:14:52 +0100 Reply-To: Karann Chew Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Karann Chew Subject: Re: [MOBILE-IP] BT = British Telecom X-To: Xinhua Zhao To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <20000816185305.22420.qmail@gunpowder.stanford.edu> Xinhua, BT = British Telecom An operator in UK. ++++++++++++++++++++++++++++++++++++++++++ Karann Chew Mobile Communications Research Group Centre for Communication Systems Research University of Surrey ++++++++++++++++++++++++++++++++++++++++++ On Wed, 16 Aug 2000, Xinhua Zhao wrote: > Could someone please explain what "BT" stands for here? > > Thanks, > > Xinhua > -- > MosquitoNet Project on Mobile and Wireless Computing > Stanford University > http://MosquitoNet.Stanford.EDU > > > > >BT however is specifically seeking a large-scale mobile routing solution for > > >input > > >into the 3G bodies for Release 2000+ which includes support for fast > > >restoration at the IP layer. This solution should co-exist with MIP based > > >mechanisms to support evolutionary and incremental deployment. Interactions > > >with GTP mechanisms will likely be covered by 3G activity. > > > > > > > It would be very interesting to hear why mobile IP does not meet BT's > > requirements in this area, since one of the primary goals of the > > current work is to make mobile IP able to perform this kind of function. > > > > jak > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Aug 18 09:40:49 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28077 for ; Fri, 18 Aug 2000 09:40:48 -0400 (EDT) Received: from standards (47.234.32.16:3613) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8965A@standards.nortelnetworks.com>; Fri, 18 Aug 2000 9:27:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19435 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 18 Aug 2000 09:27:52 -0400 Received: from dumburken.it.kth.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB89659@standards.nortelnetworks.com>; Fri, 18 Aug 2000 9:27:51 -0400 Received: (from maguire@localhost) by dumburken.it.kth.se (8.9.3/8.9.3) id PAA09816; Fri, 18 Aug 2000 15:39:55 +0200 (MET DST) X-Authentication-Warning: dumburken.it.kth.se: maguire set sender to maguire@dumburken.it.kth.se using -f References: <399CEF1E.763D1800@era.ericsson.se> Message-ID: <200008181339.PAA09816@dumburken.it.kth.se> Date: Fri, 18 Aug 2000 15:39:55 +0200 Reply-To: Gerald Maguire Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gerald Maguire Subject: Re: [MOBILE-IP] IPv6 handover document X-To: mattias.pettersson@ERA.ERICSSON.SE To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <399CEF1E.763D1800@era.ericsson.se> (message from Mattias Pettersson on Fri, 18 Aug 2000 10:09:02 +0200) You stated: If the link medium is using different physical channels (different frequencies, not CDMA technology, for instance), then a receiver can usually only lock onto one single of these channels, since (due to cost) it is only equipped with one transceiver. If access point A is on subnet Na and using channel Ca, a mobile node locked onto channel Ca won't be able to hear or measure anything of a possible access point B on subnet Nb on channel Cb. The only way for the mobile node to detect the presence of B would be to start a scan over all channels (and do so occasionally) or to be informed of its existence by the network over channel Ca. This is not quite true, as it is possible for the receiver to have only enough circuitry to determine the power level in a band - and thus detect activity in other frequency bands -- even though it is not listening to the actual data in these bands (for example DECT receivers do this). In addition, it is also possible to use wideband front ends to the receiver and do the decoding of multiple narrow bands within (for example using software radio techniques). Again, a useful aspect is that you might not need to actually decode all the narrowband contents, but just look for some feaure -- such as a pilot tone or the freq. spectrum or perhaps only decode it once in a while. All of the above means that you don't necessary have to have a second full receiver nor do you have to necessary time multiplex this receiver (and hence lose the current communication channel) by having it scan the other channels. However, I think we are rapidly reaching the point where it will be the case that we have multiple receivers in many devices and it will be nature to use one for the current communication and the others either for additional communication channels or to (occasionally) look for better communication channels. This is certainly the case with cellular handsets which have multiple distinct radio receivers (such as GSM and DECT or the long awaited GSM and Bluetooth). Further, it does not cost that much to listen to multiple channels -- vs. the cost to both listen and transmit on multiple channels. I've often thought of having CDMA beacons that annouce what resources are available -- in analogy with the signs you see on many highways which tell you want are the local radio stations (for traffic/public safety information). Such a beacon could be design to have a very low data rate (and very long spread code) - so that it could be very readily detected, but minimize its interference. Chip From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Aug 18 10:17:08 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28842 for ; Fri, 18 Aug 2000 10:17:08 -0400 (EDT) Received: from standards (47.234.32.16:1875) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB896D8@standards.nortelnetworks.com>; Fri, 18 Aug 2000 10:04:14 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19596 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 18 Aug 2000 10:04:14 -0400 Received: from techtransfer.swift.shef.ac.uk (sms.swift.shef.ac.uk) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB896D7@standards.nortelnetworks.com>; Fri, 18 Aug 2000 10:04:13 -0400 X-Mailer: Lotus Notes Release 5.0.1a (Intl) 17 August 1999 X-MIMETrack: Serialize by Router on TechTransfer/Swift(Release 5.0.4a |July 24, 2000) at 08/18/2000 03:17:03 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Message-ID: Date: Fri, 18 Aug 2000 15:17:01 +0100 Reply-To: Matthias.Kraner@SWIFT.SHEF.AC.UK Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Matthias Kraner Subject: Re: [MOBILE-IP] charter review X-To: Andrew Campbell To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Since we have faced a similar statement, when we were applying for a timeslot for IIP in Pittsburgh ... MIP working group has started to address one of the major problems for wireless mobile phone environments that is hand-offs (Fast Handoff discussion). However, it seems that there is only little research available on MIP perfomance especially in those areas mentioned in the charter: GPRS, UMTS, CDMA2000. Given that after Pittsburgh, I have been told, there are still severe issues with the handoff problem, that there are security issues (unfortunately others overspent the time guidelines sufficiently that a colleague of mine couldn't present her contribution) and that MIP in both versions is heavily contributing towards transport overhead on expensive spectrum, I believe it is premature to assume MIP is really the suitable solution and thus to exclude other protocols proposals. (It is still a pain to make MIP interworking on different platforms) There is no need to adopt another protocol from scratch but at least some thoughts might be worthwhile considering for future MIP versions ;-). How about taking the advantage and to review the whole process of MIP standardization. It might be not to late to review the research in this area. Is it time for a CFP to support this? Matthias Andrew Campbell To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Sent by: "IP Routing for cc: Wireless/Mobile Hosts Subject: Re: [MOBILE-IP] charter review (mobile-ip)" 17/08/2000 16:36 Please respond to Andrew Campbell I am happy with this change. Our intention with introducing Cellular IP was never to drive for any form of standardization with the protocol. We wanted to inform and push an agenda that Mobile IP needs a number of important enhancements to be more commercial useful to carriers/wireless ISPs; these are: 1) fast and low loss handoff control 2) IP paging 3) a link level API that exposes link state information (e.g., SNR) for fast handoff A number of people see CIP at odds with Mobile IP. That is not the case. CIP and Mobile IP run in unison to support 1-3. (A CIP terminal runs CIP and Mobile IP to achieve micro and macro mobility, respectively). The challenge is to provide 1-3 with minimal state, signaling and complexity. I'm convinced that Mobile IP needs to provide 1-3. Looks like the charter embraces 1 but not 2 and 3 at the moment. Andrew > > > > The chairs would like to refocus the Mobile IP WG objectives to > > protocols and solutions that are based on Mobile IP v4 and v6. The > > current objective in the charter of enhancing the protocol to make it > > suitable for deployment can be achieved if we simply focus on what > > needs to be done from the perspective of just Mobile IP as specified > > for IPv4 and IPv6. > > > > We believe that alternatives to Mobile IP for IP mobility are outside > > the scope of this WG. To this end we are proposing that we remove the > > micromobility bullet item from our charter. Removing this means that > > we are not going to be considering protocols that are not based of > > Mobile IP v4/6. The two specific protocols that are WG items currently > > that will drop out of scope immediately are Cellular IP and HAWAII. > > > > We would like to hear from WG members their opinions on this > > proposal. You should be aware that going forward there MAY or > > MAY NOT necessarily be another WG in the IETF to pick up this work > > although we feel that it is a topic that needs separate coverage. > > > > Phil and Basavaraj > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Aug 18 10:51:23 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29578 for ; Fri, 18 Aug 2000 10:51:21 -0400 (EDT) Received: from standards (47.234.32.16:1875) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB89751@standards.nortelnetworks.com>; Fri, 18 Aug 2000 10:38:09 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19751 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 18 Aug 2000 10:38:09 -0400 Received: from motgate2.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB89750@standards.nortelnetworks.com>; Fri, 18 Aug 2000 10:38:09 -0400 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id HAA06590 for ; Fri, 18 Aug 2000 07:50:15 -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 HAA03201 for ; Fri, 18 Aug 2000 07:50:14 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2650.21) id ; Fri, 18 Aug 2000 09:50:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C00923.9D821FF0" Message-ID: Date: Fri, 18 Aug 2000 09:50:13 -0500 Reply-To: Roberts Phil-QA3445 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Roberts Phil-QA3445 Subject: [MOBILE-IP] pittsburgh minutes To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM 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_000_01C00923.9D821FF0 Content-Type: text/plain; charset="iso-8859-1" Please comment on this draft of the meeting minutes. Thanks very much to Tom Hiller for recording in Pittsburgh. <> ------_=_NextPart_000_01C00923.9D821FF0 Content-Type: application/octet-stream; name="pittsminutes.pdf" Content-Disposition: attachment; filename="pittsminutes.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjIgDSXi48/TDQogDTEyIDAgb2JqDTw8DS9MZW5ndGggMTMgMCBSDS9GaWx0ZXIgL0xa V0RlY29kZSANPj4Nc3RyZWFtDQqAEIqA0YjUbCCDDYXDgcCAQFQiA0YCCJxM5GcQA0XkaJjEYC4Y Q2HmYGi2PjAYjQaQ4qGMQSaQDMcSuHncQCgjGUxHI6mE5HkQDIYUOHlIaDUXDYXlQpkcWlAQE0ym U6Gk3RgpGU4G85HQUw81RKXjEYi4ajKWESKSAYDUZyyXSeUDmWTYUFMwm4QEQ0mUzm8WCAhkGvlS wxMWjQbi4ZSKICCNjEQR6QY6STAYDeDXC1yHG3Wbk03mI0mwyiAk1Am1Y6nQynPC4ex2Wz2mXyfa w+4yAajm0TXQm83GQw0CpVSrGfY2IWjIZi4bweH2qN2jKSGWZekDIbjjJbqKaAUFwZDYb8saWaDx Pp5COZOT5axeC5DfflS7CDljiFw32MeuTNvo8QnjgMo3OS5aPhyg4WhiGTGJox7qvgyrspK7buu+ lqbvI8z0PU8L2o2jr4wu/7dqG+zxP0sCCOelURQAtgaw3FIYBlDa7OOqqrhAMIzwO4gQL+14QDMr g7p8MkfjmEA0jmFzlwchsHQgGUJOoIzrRMkcMMZDTOP+u0PPPFz0s2/8tRLC0vRQzrMvu/LlhjGC VzU26Yhmt7wMwzIavEJrUjsg47DKOQ5jS4TJrRIsnDoN4QDoNDTiSIqmyOrkfjgOA5DeOwwjYwNJ wOEDhSUOUmUhSVKBAKQjCGEAyjINNIDkEA4jqMtdSmGMqwe20KOu+QWwy70xPFMsQTTYL32HE8xL ZFbgBRFrDReF0YzwzDGulDjMBqGk5JuIwg1iMg5DCMw6JeFoQDaNI5VnJ69CSIInCCF9LUxTrRtM NsoofVoqikJknycNw33YMauXkMd2VWOY3ja043DKmw3DqNoxUOF2BDLBTZrM+61Mwj0bThCS7DC1 o0K5Jw5joMLXVYMqgDJSOE3YNeEptlybVWO45Vq09SBAOYy4fRQ3Y8Kg0SgEF0XVdmoDZmdD6jKA xjqOekSZmeatQIoqCM5YqBVPIYBnlE/Byxy7Dg0w3J8POm1bfYj0kMo2DZJwhjQnzTSdOlxIXGS1 Te+rxChQ41qtR/AXYMOjuS02jwO1w3DHiqpjJedV45H4yc8MmPb/wMjOW8r+OxbaThmzNkWpxg5c cNzYRcxLKIZkTcxmlFfM5PwaW9lYz3lI1J7AOY6jGNEf8uN3M83o/Ab4EHQjD0dZyl3PgytCNmy5 NoqO1MFjwHallTPEM8RJCrsTdaMVXHas6Ttw+0hk+8Uhk3x4mnGnCskJTQRQ8OZUSotqS6wQOAcg acOYYWKGoXuEEEC/QxL/V6r9K6WT3Pjfi+VL53H0IcTGh08qZlrpoPWs1NkISSOJWk/VaxYU6rZT ubZkwOC6J9PiDB4pN4AggCOgdQ6oQ0h6XnAaBDS0nQLaowgN7QA0KeDqGd54V28tWZiCAMaoQ2Qb LGySD78FiLGZRCc8cKVlwtRGs5LsIoZP0RY/eHD+VuI5eEScjwNzxFZUMohoodQ3MWDYckoIMyVG kScVYEEXGFxgBAz2MT4EsPijMhdYr540rJjY+xZkb4XnyjmnGOqLobrah0SdHKgIfEgBiDlPh+Cb gziLAdqK6YGQOgup6DIZWAAgDurV568gzKHQO5tJxeUmBta4HRUalJjFcDKYF0K8g4BhXirOSqD3 wxvhBGeTjspaRrQ/KCNyE44Pkhi/OUy1IarYlUe1kxBY9ywBw/UKQbzWmnDeHAqq8A9MzaWj84YI F5BnaWqGhBfkoB0XSVU4TAYAryYO9BWgcw4T9mEpRUit6E0LDZQ2hTMaIxOouVxkKDjaRkZMDeP0 rzMlkPE1BnVDXtFASQreSEXowPdWuC0GaECVnNOe75LU4ZNRonImST8K32wuky/I+kM5TrXlTDk9 pcgZw9hMWxPcf1YFCRxIwEAXAUOnDk4IEDtHbBzC4ClKZz0GzekvOCqcIpNwkk6+qp5YYWP5fes+ qlX46TwjtPMx5mAaI4fmnVHRNwrBKBAEgMr2msBDYmp018CS9NQb2GleDczXJMDMp4NrYYoTdg7J iwleqmPpnK+uqEoZ1SjWhVWw85Z41ZjxKwGa3iXWMlmjsJwLQkQWZYqR6QaYv0SL1Tdoxwg2FAuW pS5tz2lmBVrF6fgbEmOhaME244QbzI/Za5i51BFF1oDu095zB6VlkZHKsmJ5n5g0q6eJuIYXNqqU i5Nl0E7zQWaQHKQNcbWWuji+avlTYUTntrOlNdeZ226nfbyxNWrFuvlncN16Apy3kovGCKbn1Ihs DeG8NaP12MxZm1y7znlJKRc8a4OVozThpDM2EM02g2B1os1C07E2wrlVMrdo1ybWTfnVUpL1e0w2 yqdhKwFUZRYWPnYbDKc5UP4ddLBBk90cLAWpEPEgc2XB1vA9g07zsVtIx8vGLoQwnwWkc0aQ8XQ3 49e0uizqRs8qte1IEqrSGKPSdxUF79doPLCwbCPKcJpPZWAbYF9064YZbRutPDWX475hJQDar2IC QHOq8XaJiB7PSTY0xxRCP6LMMduG+Q5xLSr0egzKX6mVb2Xzln2nDnlEZNrvk/LWUoSlx0rCrK9t sK2vwvlzT2XqsZgvtmXD7aS2tvJuFMKoTio3OU8HMPLMZgTLDmGtJ1O6DAgDqHDXDRVItGmcGwqo LYvxdaQ0o4QO2a5Dik0dAwY8eXOXpRsrz3oOYMnZpLZaMsq7O0vli2+WpS7VJvb3bE9CTmKQlqYz 0rpyxDihRdeVOdfAgi1I8MMXYvt8rnUQl5zjoLeqTsm2OlK/aW0xVLaWnE4caftqCxTJePg2jSby sK1FBBQUIq6hxwqGUhpNewvVaAlE+DSVGJDFg3YKdzXSMeTuc9B2VX22df+K7QPdbiwunYaYbt+T FGuZKaZnVbiq7Si947zouv2ZTXtdNGDslBoiTGcBtm0G7gG9jRmlNP1bHEy0jhpDwvPO1ymIKtUg HBUwZr50t2yc5/j+sxrUaM0+I4cnnFArRzE0yqlWhHCaEHsWjOG147RzvZnPeKc/yz0HjPc+jYc6 RWCmK30A2RLu0nIStSgJQeYaeYak7VS6DoCdJy/StwRDYDpj7R0lKckRsLP68mupG5e2GbIYw1lU Xep95MVZ+RYZr6O+tWy2T2pkBsM+Wo9YXS9cDQKAJ2su3YVkoOVWSEcua2aGDoZuV0xqx8v886bA CCCQXoDGyCc8gezk/S0CSi2M0eS250nGyowi+C4s2i0i+Kquhs46w6lgBs5If6Bm+WLsn2n61iY4 xUioNO9suUos5eeYYowAgaDCUMbCgigmCm+hAiKACCa6De4M6waO3qUoKAi+L08oawOE/0qQf1By zIq7B0JuY4esx62E8gNINMbs+sOKVYbAaMzUJ8XmCmzwSc1oDMDSDOyEXmKsVXAGJ89eoQn48qoM 9oNODa8icEbMbQW4By1KM7By+cmci6dCo0aS4Oe4BACeYsaOiuSCZioKageUXYwKew5eXm/iZuoe aGDENaoKYYzYSYX68OxocmYkyCugBAwKqALCSojG4c027SwgnNBY7csHBenc6I441C2yJk+Wf7Eo PECCZ0mkYO+q/EiGqGewu68W8aSec8ubD8awYsVmUeUidCDOxUDEjAKAkIDSVyDLG8aekamWL0e0 tHFioIUNDEpclYLdGSgwX/GEJK0ata940jGQPBGUjasE00lJGe+M2vGk/4KGBzBu9QgAVadOzoaO ZkZpFSbCuuZeXemedE0Aa6ZqzlHtFMonISqE5oqM5vGMnEwfBVIinRIm7gjlItBink+QbSqHI6de BzDQBQCSCcCkXssq6e6iCgU8++oYrQCGasDqxoCG5eNcb4ebCu9zGG7IStJyqXBS547W59Ba7e4x KEsQ+O7qbUBsuEM6v028BQ5M+0aiDLD8Ys8tEdDe+kkmKoDuK4xa/acm74oYYsDpMOdrDoiixcZk ecxQegisxxAWKrAlMku8ek8a0WLCbGAaDiIyV8P4JWeCv0I+M2d2oaga5YkmIyIEIIIYWyMmByKS McIiW4OisebcPEU0ahCNCsDSauSY+ueeLyoMzgDkBakO/jM3MIUSXgasyUwCsqCDDi/nMHM7MdMg xal5OZOLCutKOXNICiIyICANZW5kc3RyZWFtDWVuZG9iag0xMyAwIG9iag0zMDc1DWVuZG9iag00 IDAgb2JqDTw8DS9UeXBlIC9QYWdlDS9QYXJlbnQgNSAwIFINL1Jlc291cmNlcyA8PA0vRm9udCA8 PA0vRjAgNiAwIFIgDS9GMSA4IDAgUiANL0YyIDEwIDAgUiANPj4NL1Byb2NTZXQgMiAwIFINPj4N L0NvbnRlbnRzIDEyIDAgUg0+Pg1lbmRvYmoNMTUgMCBvYmoNPDwNL0xlbmd0aCAxNiAwIFINL0Zp bHRlciAvTFpXRGVjb2RlIA0+Pg1zdHJlYW0NCoAQioDRiNRsIIMNhcOBwIBAVCIDRgIInEzkZxAD ReRomMRgLhhDYeZgaLY+MBiNBpDioYxBJpAMxxK4edxAKCMZTEcjqYTkeRAMhhQ4eUhoNRcNheVC mRxaUBATTKZToaTdGCkZTgbzkdBTDzVEpeMRiLhqMpYRIpIBgNRnLJdJ5QOZZNhQUzCbhARDSZTO bxYICGQa+VLDKRdKxaMqRaIfao3aI9IJEVJILcaNxwMbhFLrNy4MhsN8LYRpZoPE8eII3HZPlZJq pba6GN8cVLsINLBBniZXsrVMJQM4PD5dwrblbsVDQZaiThAbqmZDmIDobxAZDSc6rVzr2zQIDYbz GYTZgid1Tscxd6OqbzqdDmaTJzjpzRAbTeYjSbDSOigOkOg7q4NbrOwNY3Demw7uavTruy7D7jK3 aJhasizNu4KThkHIbs65Aapo3CbjmMoxjeNwyBAOo4DIMI6DK9rmRgEDtsDCb8v2/rnRSNigRbF8 Yuq8byvPBT6uqO7/vDHIhieIIQDeMzrPwJsdv9AAQCmMo5DtLrAwUrywAaKgVJek4Yhst7jTQmIc uLEgUSdKEpSpHIkCC9opsBKrnDMMIxjpKsawmOTnJ8+0CBANarOpOwQDCMgyUOOcTOqLgUDSF0ZS k6UlSYq0/PE8jzQqsayhkysNpAgsRritgbTiu0BQIOUDLzFb7jfE0pPi+b6i4r40jaOD/DK6tDOd Ag6jZFYxOcMY0LyM9kQPUYmiSKA7IOMdjjcOkZvwML4jQrjqjCM9Dxk3YWhmGTEpeGTehvOLICMy TXpYy7Ms2zrZLs0LRt206DM81bWhAyaQ32sU2rk2zPhQ3UyBi3qVYOiE3BgGk4uOk4ZhoziapuEA kL6OSfWkNMjKjbVuUjFQQUA7gQWnFUpjNTAUCRZFpjbLY3v8Nq85jFYlp9YgQCK84mvNRthXa3qD wveAZRHe98sphrMBcGTNZG2eANA0TSTJgrUrS1iOYVfSR4dsS2YjkmJt3izfYzVgYBtq9/4lSgwj MOgWjKNmiDZRoWv0/g2DKNI4BbmnB5uMmcjmk14DoPExsMkoYobquvaxtetYZt+u6/f02hRgWzc7 tG87W12t7e2VYNq27c7ti7f7U5Ab7D26UzZOTmOcOA5DerY5vMEA5xarauuryWbVzywQWhAapr1Q Ix2Q6vkvjLr2IfcYx+9SwQfDGI5Oqqw7aFL8VyW+9I1PC9U1Xjevtv2+9thLs5RnJ+QwlAWgpFSx 5A0owDK/NJikEcvMDafYPIcEepUe6986JVFbBrMCVwED9DwnaDMGZLoZVwHWgqtZKakXzvffuhgs 7vkOMeNoSk5RN1aoFfI8YEDyHlK8eaHQMIa1rKSDsXmIi1VIBoZQyqJzLV0woPke0IJeoqH/KAkZ xqukrJYi0CCK60iuG7TMxsGoOH+m0BoDB3JNwoBvKsoOIAdj6RHe4Gx9gbkYBpS+YJOqEE8JRhAE M9K4jtlRCCVBohQAyh4O2oNGpeSgONS+eeFoYWbRPDktIPILozJnOEUIyrH1Wg0eIXaK8CHnrFKq ilGyyVpySPEGWS5QUbIqZZH2WESmWOPgYuh6rOIStGedER6So4gPofICAKqLpgqRUPKFjaalXv7Y w3Roh9Vro5CbIswIc0JSzSrImIDy3mqHDIHV9BUUsHOW084NIZ4+H+Kur4+Ud1RxOS7FAPJgVNrs TJGc4QMQbofTbKNgzdJ1TsWsfOeh5irEYkEfhPJ7XynOCadBIM0ZvSLU8j95x2Dxz3DC+5QZ+kvv uQefifjKZOhoDzNSUYNC6MPVaQxiTzw4PRRis8oCOQ4E+KqGNZpPpFBQXFRqjk0EhqRDYeeQy6GZ SDhDA9OkhE7pWkXTRDgOXiFxYlFlAEoEyIXdADFqzozIttdoZYkq/XgtkYG2c1DsWEsLNg3B/zc0 5MUc63djBwH9g5Bqv8mJo2JBUOwoGfkfzxk2jml0ngcJXl6gFCUOaOKuFQnWsaXdT6hhjiMfJa4I nkS2DSfAOYIpjAiOkHe10U1wUshi/mGirQbzXlGyFiSOaXz+qWdllLgofxytrPhQig5bQoSqfAM6 TVFwZfS+t8b6kTuOj/Z8/x5UYggRQHAvtm0/W3Qzbk5Nh6ElyBhTdOVG4CFAR8UBQ73o/I9OlD9Q NpUbVbOdJZwsuJ7IGfe/GBqEVrJiqhZG8CKTpKCj9GFCAYg3v1uoHOahcoZsPYldZ9tZnO1oLHWt tVba9NcrkZ11jZWCV3sJXlt1cHbG0BhX53TFXeOxOEyKuZyAZwAJvD5wFxpzq8Wth5SIZEvldO2G WCdyUIBlhKidQcIjsh5j4G1llSTsnbRRkuT9GcuR3XBGE7d5sNsaoKSlEBJ6bXuLtOddMDEVx2k1 cCTknpuvmmY+o+D7D2Ltc/iN0WJV8VudNXB1DYG/N0dbi1g2L22YndrYh3DErAGHxzYQ4QMyUZtJ jQexZ+MhqDW80kM141R2TZThCWGVgg6xB1mLWKUQ6MpDcHOEz7VRuLR485E4dQ5RhiMHlZM4znWx zQhqathtQRuYsxLC+fnxByhCg7Xs70dUr0FWnZmJsYr8a9ozDmjsWV20joZ2eiTY6WxrG9uuOG8a cTTTbSwMgZZABQEMNmqC+xeeOrw+YYnGzDcrMUOb3o+bDV5MZBtzj+HlO5ROWN2A4nfnVt3QjfWE aH0porFO5U5aP3Q2nju6694zYhvDTJvN53ovbDZNINocgoW0FI6OFWWHOO5nTEBYV3LwMUvMFy9d DOlr3ot1TYmJckdfi7dWiOU7uxsyV3fLzV47xrs8GnSy7BMVK02MCWggrVuSqJl5B1MhHeU80Igb w0ZaQAYEJqew6hiDET4MKfQpGBChH0NjUaztTxH0fqWKNx9LrFuauvT908n8PpWnGl26ctsE73rJ J6D3q6Y3TUoLXKhtgmgBxU73HgtcMGEFrj1uEmI+5pznQNBuh44xrcFb9xOprnivxppuoeQ4/u3y e79MdXsHegxka00luYl2yoZ55WtE2GHpayOVD0nRS9OEG/UYhuDGUBUSV3GTwKhZlnWs3jK9USYF aodDukYaKpJSj3wWbLvQR6hDcSUA3zgTeCwOQMwrjLSe67i0JRBSZSo6o+pGLVwNycKFA7Se6jpI YwJZCIjgg8DihEyozYZLTKyTRPLjT2itjjzcKuLxKuZsb3h1z3zx72zScEzlRuTlj4zzDNRkDNj4 YHBWbII5pQ6aRRRCSFY95KjXxLIoC2g+QwKTQJgIYFoJib4EBTLAbBoNzB6n5HRxiMMJJYSY0EEJ 8KJTJBT+zzIkAo7/KUw2rfUKhFEKzKjCJLUI0LbswOhYS4YJAFoJEKKRI+bLTfrayio5wI6BgO6A oEAIwrhxyeiMUOkEStTwz4ME73TRrkbc7xzk0F7lBhsGTyiv8GrHTmbZ4GIHLfSH0Ix45LsAIOQN pZJRY/iXUCSpxZAwLVJ9pQcQJk0MBKJXJPylpGov6FgN0QoORXTZA9Dn4sR/C88Mo4cNB/cHJ4pK yjhS5Ub+UBKCA/EJsXRmaEEV8CIjECY+0Y0PEKBPTMSQwF5PLYBFRZK4rVIMarwtgGkZygrfK38c cbcXhPEbZCaLD7wMIOB577j6sYwJkXURzEjjrpDxESbkRgMS0FsTBe8TTyT/T4jysT7egtjQb4b/ oFAJoOpmqA4MLgkcUdZZ5RzikcKWSScH6FA8sgKo8LCERUQvLCsHy/S0gqkhDQshTyLkEFESkh73 oBp2DSUijGTqkGjeT441YuUR74cHgFAJ0RQNDCjaw7ThIN7MAECR77o+b7KH55J5bA5CDOQM6BhU cckKMax75ZBqToReQ3rNJrMn73LcjzsSsokozqMSMTki8T0pkGxvQGY4jZ4GYHLeAIpzcCDihbJb Yg5CCninxSMLLX6HZW5qQpLjcEkhZ07kMvMocFkor38TMuyvjGjqreKwLTa9AmUFJv64pwZLrXJw cU7071pAQMqDr1wFz2Enj2susSLpT3bp0iKvEGD3E1Dlb4swUUCU6UqNBiRKMU6DZAZAriqTU6rJ BY0kMar9yxzA5JEt6s72cqEF8z0oEhs0Kuk0cvj4EGMpU5s1jrEG4kBea3kp5EYuz8Q/qMMVTnJJ Kq4+5URHM6szDAhdA+IN5oioqcKIip4IgMKP4JTuDXJFIwIMQ+JmxRBcpc6Y6BkMk+wlEecw7rwm 4+5QsHxREH7LRSzii8S7LDBMgIogYOIjKgwj4lbQZ2BeCnUH48IK46IjIgQggG9HStxVYjUEs5U4 koU9o3dGoBoKIjNG9Iw05OBhQhry5hQF0xK7BmwEFIQvQBtIqg1LAg4ydJUv81TltKVKgBtKxz4H BeLQZDsuYyVLwtFIFMVIdMogdOdOoj9JUeq90NJebzguwKbhRpIN7Wa+BGCIhaUgkys7bP5LqYxQ 4M6SK68D4vUENGggdOAgIA1lbmRzdHJlYW0NZW5kb2JqDTE2IDAgb2JqDTMzNTENZW5kb2JqDTE0 IDAgb2JqDTw8DS9UeXBlIC9QYWdlDS9QYXJlbnQgNSAwIFINL1Jlc291cmNlcyA8PA0vRm9udCA8 PA0vRjAgNiAwIFIgDS9GMiAxMCAwIFIgDT4+DS9Qcm9jU2V0IDIgMCBSDT4+DS9Db250ZW50cyAx NSAwIFINPj4NZW5kb2JqDTE4IDAgb2JqDTw8DS9MZW5ndGggMTkgMCBSDS9GaWx0ZXIgL0xaV0Rl Y29kZSANPj4Nc3RyZWFtDQqAEIqA0YjUbCCDDYXDgcCAQFQiA0YCCJxM5GcQA0XkaJjEYC4YQ2Hm YGi2PjAYjQaQ4qGMQSaQDMcSuHncQCgjGUxHI6mE5HkQDIYUOHlIaDUXDYXlQpkcWlAQE0ymU6Gk 3RgpGU4G85HQUw81RKXjEYi4ajKWESKSAYDUZyyXSeUDmWTYUFMwm4QEQ0mUzm8WCAhkGvlSwykX SsWjKkWiH2qN2iPSCRFSSC3GjccDG4RS6zcuDIbDfC2EaWaDxPHiCNx2T5WSaqW2uhjfHFS7CDSw QZ4mV7K1XIaQeH3G2aLPiglmWgGkyGUwnMdbsWjGG9Xb5AjZLXyzL5nN53ZXbQ6Pd6eDZ7V60QZO Q96xcXaDDbcndWDeb71RCXycZhi26XJgoYcuI3CbiCvQwjIMg5DKOY5hANowjgOAyjkEDojmN4xj SMI6QeEAkigOyVryMkRRIg4hieIIQC4FEThAOw0jGMsZwuOYyi4FLqOssYZBcGSaP4yL2u6kaSvA zj5PG0DRNI/D0NStLWI5I7KPg2TjNq27ct2GLepU/a1QGGDkPlAYbzO5KsjINMHDGOioxHCUHjmM IzxCqyoicEA4DkN46Q4N42BAOY6DCMY1x868ASFIjtO5LMksxITNSY2cnBQ8sosMBspzJKzXUoyz 400tj6pqm770/ML9OA/qQI8G7OzMhjkiQN6bDIN8QjoNEbjaN4xDSNkbjMq0UWBG8FwbO4QDeMwQ WZCUKQsOQfofYNDjGOQ0jFG47ujag8jgqyMRlN8UDdQQQTirkULy3aJuqsqzyqk6VMquLkryOY7w u6gZyCxQZN7fD1u3LD30rJbO05KDztRUT2Pc2FTy4+kvVZMExN/KsBqFTMuBkG631WFAmjeNwyDC oA3DSM40TmNET2lac3jmMY6wgNOWOm/AWt6g7sUhKsjYu+FLZM8MmuTTuJvTWOLSRU0tvnVUDhRV rD4/UUBhiG2UNnAaj0yuwjjeMNDDTCNB3eMoyDrG1qW4Nw6jbcMMWlP9Aq3PA2DnRsgaPhVJ4bU2 mUw8WoYlKWKapK+lSTrC5a1L78VfMdY5FMc0pOGQY1rlIqWDBwQDvY1DXDDNojdG9e54NoyjdOYz K5GcTZbGaDugMY0B2EHfjQECrDGNg6ufCO2UM6MLTlCOAwyM8HRvuENjYOwy8Jo0h6RhfKcVh+n5 TqPIan8FScS2LxVTjmuY9WGQ9DskBdCHLKrt00Lxvtzrg6LfDOnpDAZlAhtbsuJOAZVjoQBAr1Ca fFgIfUOokrqEWVrFWOilDKcmfhucG0JH52HwOIYw4tpymnHHmfQlRhT62MOWfefZ+TnH6EgKEgFW RKE0NbCsT5n7PVuu1iAG9CIbWes1DC9sEC7U/oXRsGl7aKCrIgDkTwOBVWgPdUe99w7DITvkhU+Z x6n1QuShglp9yXYaOaa+504TpGyr6hSXYKa6INuqQdA1t4ZXgLtDYG8M5QHcIYY8UhADYHQkFjWD IHEci7RVDkGEFqGXeHnkQWiOBMS6Pla3FVC8EAwlWR8/lo73lIpWhM0uMRLmIwsjM5F9UYI1JNhm ylrp+YbGrZEfRWx/nRHJCaHUNhVQ4R5gXHxakfg0SAkFIR3KYAaFlJnIqHEjJbJnkecmSUlJLIoP OadXEmyUA3ZIfuSLtpQhvgiG46hQjTn1hJF98R31Lwplc+eWL6YXy0crGtjcbVXRvhuDA4cnVUJn mmcl/gIArhHdS6sEAY52RIZiGND8ClgQSW4EkIoVAjLUDfA8qiFw2lWRuGhXaEm6PFDnSqYiKHWq 9dg8YvQTU6lcXoWNe52YdzTjkyUGlCC7QMR0Hd07/i9LVo9SAFwIAjO5DKHgMIbZjhlMCht2lNpC oTi0XqJCiAQOtgCv8MyF0HBki4kGLyRXwtWns02c6m59GmllP2erGWsvwly5tkEvHQtjl+SCaYNT khDoq7UOgOgQBsKsGuxrL0LoSWIsYNIdCgITKA61a9jm5TfgSiKj9IVeohXanN2Fn24LOQdA6jaE VALEWOG1gbBSXgySCZU7RnK8thLbGt0ckCbhXbk7AObLrMlTKqVenZi5UtJrgkqe9c4VqertPyt0 aZ/zZoDLiGtfz+NhBpUE2joqiE3CEg4MIaw3h1TmiCqta4Sz+fHdNxsZJYXXhddm+j7buOYY7G5+ dgCYgzQM/ckANwcvwCQzcMy03aFUXRA+SYZg6IRDEUAKZWkQN6YFCJR1bLn1vVLXFxknjyRlv0xV yd0YZRsu9gKXd4T/T4NoUdshdqcIqgqh9nqYMQuGrdKth19sUJPvyqCu9/K84vu61uvtBMCUGX4f 05IU1Eh0Z7YylVW7HBusgoAMqyQ8IhBbJWic7FisxKvSyYoaart+zGGnMqEU+ILe2V1twZXaO2eY 7xZlSw6hudhl8M9zSyFmp9L2c7Io6k3bgtVYcGqlWhkKGVmRenYB0DuVwNdT3TP/dUGxQy7SbOtD mHVCpXEQBkqeFANCxpcgzoMC5gioi5WGu5bhNqxEL4XbiHEOqD9gBEiW9xoWtDT63Xtoqgro37U/ oWykJQb5mobqXSO061g1rCDCGp3LwC8p6eY29bjsm82KeNnZBQbFh1iWuoGKdYygUeKbfKel0YUX UvxdbJV2DtXaavQDAD8cZXgTKf4o9gyhgzxyTdXVWwmWPBAFBB2ZEH5cpWr11KNwzxSeutwJqfgw 5phA25EDtkZl9Js31auXUb6b06HLMPF86IPB+wMpLha2qSv7dKuV92t113/fvgPP8ncFyjgPGmBc qthvOCgK7Nk5hhDFe1OdFA3LJDOHVb+beYIZQZa2EKnwWnDIXzzEeRL69ByPK/f0Z5Z5N4JXy781 qDFkjWDQHHDwUFZopnnCYYcLWT5Kt46IaOdNFkTvnEvQMTxj6HirouLOBX+oTk9zNA+mcJVmDO8i AwZg5bRcPqjxlphIRd4il6IQTWNiMiHkYJ0Is8ivurNabyr85PwvWLva+f776FinJPcq8Yu7rQJr 3nYdn/4YSh/RN/ABvzyUCilMVohj9s6+JtU05rYZ+m8lwQgq1ryFz63srZ0ZI7jkvo/dL/924P3h g8Oj/UGOT1OCnVusKHDK2Edqbqbww8DkDmW0BAV0JsbgQcKssuQ8scD0DK947MhG9+vm/SyM8k+I /a4AVG6Q+Sxi84xm88TOa0S4Bmc+a2sQ+w44suge68wmN2M21s6Mh2Bs10oSNsfgRGw2Jc2I6ssc pez6DoMCDEvcgeDSweRqmIK8hEdHBoSBAu30/Uro8o+MyY+Q/i+Ul04Q2krmhwOG/y9O/5COQc4+ UQQuwmdUWAdcTewef65U9UQy8KQw5GomkmpfAmLC98xFCk8e+E7e6JCu/fCy8y6U7unIOs9CJOBq 2ma2CeDYRRDkf+UQokOerOZawmWqtYTuOoBqI+MVAs8cfY8gxtCq+K/dA8/hEM/lBFC6OFBwY0ZM VynYWa7GWgDeiyg+b8Q4TvBic075FSOESJFk+iBQDsQiCCCQR9GCPSnmyG+DCouqalBqaq8e6TFa +XBGh2+goA6i4stkz4sZGUUOphEirGRuDEOis+ZYBA7DE4QgqfAQRdFyq/HKvbHOdatiRsQgs+XC 0uBBGU/M56lVGjAyX637Go8tA/C1BDG1FesIqG4Y9AuEBQNwpG1SgG2Ig+Qi1MaCVcyDIIuhD/Gl IShbIXFWY1EPGAMS1wLZIk1278CmXGDhARFrIDFugdHrF3DWeKCmvaDkbqCDJy7KLCOqBwBcQK7V D9FJEBA0/ZIUjRIZFZC2MRC6TM1udAVmJSOSOWK0dcK2lAQwtWQqb+W+oyUPKAbrHgzsWmtSOeRQ RgCaCmgeV83MbcR4neIUbFCjFGjDIO/W7hKi7nELJVGyIINPKuJOTC2ibM0eBRBXHObYQ2bimOUU 5CRuRGDsIPJ+69KFKIdeDYDyUbKS8ZD7L8lZMBFPA5GqxbGvBAygmlJanIMYoQwQTOBg78f4R0Qy mKQuDcQ+5AQitbCYptCRDeQc5UDgUU266yZY5S2AkLICCRF5H4DmXRNJKUlRKZL+7dKfMFJPKlJS r3KrMS7w9G2iLlBuoYWDN4J8RuRoDKYCXk9qDYiAWSowq+wwKAWqCGZsTgMCpUYCzyMCWqCaRqUC Q2wsKisqg3M0BsOoVC2aYS6bBKwONobE78DSqstmsVODHa1GUMZsiYbgda3EKubkqyZeQi2MiY2q 2uZYMCRkteomZtRQ3WgS4uK42QU+o+AaDiIyYPKQIaR+QABuP0VCdQeKCuiaIyIEAbSE7Sr8LSJK X1NtG4JkOSWGdQgmL0DUiSdceRPuRrQ+DcBcN3R8CiIyICANZW5kc3RyZWFtDWVuZG9iag0xOSAw IG9iag0zMjY3DWVuZG9iag0xNyAwIG9iag08PA0vVHlwZSAvUGFnZQ0vUGFyZW50IDUgMCBSDS9S ZXNvdXJjZXMgPDwNL0ZvbnQgPDwNL0YwIDYgMCBSIA0vRjEgOCAwIFIgDS9GMiAxMCAwIFIgDT4+ DS9Qcm9jU2V0IDIgMCBSDT4+DS9Db250ZW50cyAxOCAwIFINPj4NZW5kb2JqDTIxIDAgb2JqDTw8 DS9MZW5ndGggMjIgMCBSDS9GaWx0ZXIgL0xaV0RlY29kZSANPj4Nc3RyZWFtDQqAEIqA0YjUbCCD DYXDgcCAQFQiA0YCCJxM5GcQA0XkaJjEYC4YQ2HmYGi2PjAYjQaQ4qGMQSaQDMcSuHncQCgjGUxH I6mE5HkQDIYUOHlIaDUXDYXlQpkcWlAQE0ymU6Gk3RgpGU4G85HQUw81RKXjEYi4ajKWESKSAYDU ZyyXSeUDmWTYUFMwm4QEQ0mUzm8WCAhkGvlSwykXSsWjKkWiH2qN2iPSCRFSSC3GjccDG4RS6zcu DIbDfC2EaWaDxPHiCNx2T5WSaqW2uhjfHFS7CDSwQZ4mV7K1TAYUIb53hDQb5yazcgiA1mWgGkyG UwiA0nMQHQ0GE6dk0GU5mUQHAwmerRgwmQ7GWu9cym0ym46difeLw/IQdzxz6qmM6jYnzsjS+DsC 4FA4PYNI3jINIxi4r68jI7zxDaN4xDSNgyt2FreoOFqyLM27gpOgqDoelzhBm2zPhQN43DYoA2Ou Oj4vo7rtPA8SqwIF0NsQxQYxE1gjMk16WMuzLNs62S7NC0bdtOgzPNW1oQMmkMjrFE7aBhFblhQ3 SwN430pogl6TtFEzZxSGjKrsIY3ja+D5DmHQQDnOLxDuNI5DLDI5uxGgxjQNw3jYN7zPAEAyDeEF Cu67b1vyvTpQzO46O4Modu867rOwMc4jhGQx0zCUIusNwyjMM0Gr6+UNw6sayrOtMzpjFUlrYmjc JuO4wqANQ6jnG9G0jHTvhBCsL0tXznhAOo4OzRs+jGMo00k6sADy9gQLe8gxuer0xMWHCFpeGTeh vNTISJK0jJGkskuU2cmNA0TSTFKLU1rKsrthLV6LZL1eTA3YYt6lUyxGkCC1y4YZNuuwpiSJoQDE MLw1MOrtK4NI9O5BS9QMJAXTCwyCNEFwc321bhBuGt5riyl0RYJAwvWOSrPiwIlZK3YbLKGyGuBW y2hqyq4xYJowxlVI3QfHwchkFwZSBqeq35dt/SyzGqM1mN7SffLUYVIbXMpLLZZk2uIpvkzD4Q39 auPh0grpL4qvCEA3jMEAxz66b5DTpjsRc/IQCOKeK4nitSDlCQ6UaOA5DeOzpT1X9pUXBNJCaJwW iQIPROc6EfIbD8hMjd20XhroZa/JcWSdfGT31st+3ey2AbXLu24LMWDzJojhBiG274C4YaXmuwqW Rz2/T7TL6L1z3QdE5ow427/BVIqvDDKPEaDcOeQ4tjAywlwztU6Obt8B0jor1HAQCkKQo5L5r41g pNZRDuaaGaJbOEDBNqLH5uhb8XlZ7eoFPXVQGYOTGA6E8DGHQOqfTvH6DWoUO6gVkHPDyYEMoLgz slcSxWBxVoIQSgpBZPqPjTtWaortdiRXWO6dc7BLa9QUOzSg2RojuIbmxYc71Fjb0xsJeGScGYNE 1O8ZeiwJ6qW/JxTmd1Tp2j9PrOwnsNgbFHBvO6Hcrga1UITUWT2MD2UcPcZA4YOYeVhnvb230GYR woBQBkrBqZil0AuXU1mGyWHWrydil+HzY0pRBI46uQjum1JcYGblgzcWyvEVpDskDEFdvMgi+NVy Nw6huVS00jCBi8BuDIUBgzEDEtlLkDN47SUvvNP+GVqC40goeSDIKRy/4cpKS3D1e8P5FtZbPI+I kmm2RHkq8J/7DAaG3RREyTpzAyBkT6oBRRPJSHnL2EgIZUIIJxcOn1CqNFkoWQwno78GAiTiKgp0 q0aA0J5UcVSMgcg1umLG1eGiQ5BzAkNDt2UxZFMsTNEKZTu5JO+iQ8GJU0S5q7bWkEGqLH8zrWWe JCymCrH0MEE97EqkJl6o+GGkLhwxoAUAR4/M2ZtnYnKG2NECGMH7K7HUECfTzLDgi94NyPVxqxQ+ rNITxDknGiYDU4stVkLKnbT0MocQ6ngPnVRnDeoLSkT8eeGEr3UQzl81uQrXphL0oO2J2sQJkS/b TEWSbbpn0TZaXJhsAiTkqqewSjdUlLRtUWG9RR1Z4zjUWddUDOHNPznufCfIdJ9hrMCsKcD86WsY OxTA9M2jwH0pEniC61X9y8qRRRg5b5mFCoyl+ztMzAuVW4dVPtW0dSjlLWFq1ZXcpIrQ2CHkia2z HSpI2s0kK5UQrq3I1deIntFI9NcFFG7DlQPCHKxlgpRoNglSKbZW3xo6Ua/OwEIyHhoU7d9FzelQ HypU+Nw6qSbWvs+Cy0r/ZMpmOEUKajRQZJuJuqmyUZVksYsoCAqgY38XoPoHByYbwwqDPyHYN50o PHiuqnc9ljKasWcoelUiw7LhocoHUM4aKbp5N2ROo7/rmlseLUxhgNnfBBDOfEOjJQph1wkTvCAZ MQxjDef9CSpFhHiweGJDIbaaFcb2jgOVHJ2xdnuCBXx8n0Yex/kEOdRGTofhjP+slxaBtcoLWqRF CLh0KXZMlf8kS5Vzd+yeiVzEzFyORjI4YObW1+qjOxSypH5PbqoC2nyM1uWWKvGi+VMbPKAPydgN NWbHnivooAwOUCdFAT6hljGI0NVFf5i2/Jas8X9liiyzOkKYaV0dTO3U/7eRDXjb+Q7BLhGmrdcX N1cZmRGS/RGS0S2GA3r7NUkANAZpqLsc1UAbTyM5TxShvsEy8vkxwdm3FX9Fp7O1ggNoYn0HTVNj c/Cp8Hh4KAeXbKncHuW3JgtHUn9sKv1FabF1+k0EMz0wlL9XZSzgO2di9GJ1uIAfEGMoCBkKwYxL SaCYaQ4BzQexZjbfkAIDUCsVm54lDh3W5s9UT4NJvxpuEHLxYcwViSDmOhbWre61dfWmWmuM1a6u Jy/Xq8M4MCuU8DYdFL/59ovnK6gSQghNCKFQIoUlFwRDNVlvgZj2ZZOq+Qq6luHuQZytEM2TtXaX tA+QM4bormBDFxdPB8L76kqSiSKNeiYpdRYGHByo433wDa5lVOWX52d0myFpkDyud7qEpNCSeDs7 0lDtqr0pvEThsQp3u2D3JuDRohu/65jFrpXXQKuFZ+Z3ArW7TnGbGzehuRr/OWwpoV32TjHuQMM+ O+wzPUJugDxBJKhKhGikgj0u4oClgxH3Ty9zJ6q33o9bpN5uA120jOd+reRsBgnrq7b6YFap5BKc +l2bysc8VOKRYZ3SHmf1Y2sfJuP8uHWaObVs9O7e43MeezN2DcuS6aJpxFzyqg/GOaPuDI/KsUtk yiVOWoWsPWemQkCeVWPY0y0I72Oeu8qqquWGZKCSO6yOwuBACcCCCSjORw7aRA1KaKicueJOLcwA BQfqCi0ijQpa8aCSLUnqfmwyL4DmsWPY1i/UoCdU/a5k/e5q+c/k+g1250+Uoczi5+zo6C9gLaLa YcXQ++JuimRgPzAggrA8dCMCUeBACMOaycc8/S+Q5ezK9FCITLCM9NCQ5yzbCW/u+sko6A9e+0Ye 6IaKia+4eYwYPywcw+wkU6K4Y4L+Dc8GciKi94MC0msGUVDAWMUm04OojACa94b2yi9uywgigqZD DMoA1moamC9IzTCO+irfCFDm9a/02IJQicz0xoeOLsCTA8CGRk2zBqBAQAIuPEPiyGxOBA6+yifn BACSB+BACyPAZKCGgUgOOaxuO6DaP+Kq5G1es+UUw7BI3uvw7eLYBrD0OEBqukwyuuZwZLGUy6BA CQDeJsiyWQ08b0T6vkfRGQvPADEeg8OuZKCuO2iw2qWQgQb+YwO+DnGQMITExZBNG8KGaQS4LIRY 8sDeDm8GiyUaaY4+jQeeT6qsqw8kusw3AiTvIu42b2DEpA0GwwnlGu0wwKDmwOQiN2CoBVBQZWYc BmJQRYRk6oR2vMCS0GU6xCDLAlHxIGfaysQwjA3EnWjFB85a/XDRCXFI+abDDdFQ15DkuSmdDs+y YWgI2WbqJkRYx2TkJ8DyTsUZEgjEqoqsT4PEtqPYq422lM7Q4uDDC2qzGfGYyGDYQk3EVSVYO6w6 DeDgqEaZBKtPCiYPIcTQeWJuBEwyfAfEfIvWBFKQfWeo945SJK2UaoXON7BPCC5jKmoNFNKtCTDj FVK0/zK4ztK8mm+42QKGBrFmJuCaKsQG8GCgPKnA9w90BBEwQMD0O2260mxQjEnepocopsTgDYDq 3CcGBACqMCCMDqDU0mDmDq8iCEw+yATilyzo+MzFKghrKkzPCLKqmM9QoYzfNW+vFa6EByotDYNA BQCgBbEuChPA5UBi+PFC/ZNHPPPSoS/o+mmW+rFZNa/2JiYgz0iaukCgcoyUjoDmW+PFHeP0QqWG p4fnJ6nXQ2b5KQ06s+c2csWqPogwUq1CZO6WAaDiIzP6NOIbP6BAdsRAkCgwxQCuUcIyIEIIJmXM BiByKSMqIjNE1pNI/hDaN3RbBhRdRgBxSHLBRozqdWIbRyBBR2L0AbR9P7SkIPSFSILTCY59K3RY IHSdReAav5SCIalkBuZUhtSuPFR1R5S4IHTZRnSGaFTGRSBtNjD2BtCsunD+QGVEL6i6PE76cgWm fQx4PsDS7KaZN7MyKhEUwivQDKUlIoQAWW5KZKBBN2PM0Ww6Wqi+P+J9SZTQIyICDWVuZHN0cmVh bQ1lbmRvYmoNMjIgMCBvYmoNMzM2NA1lbmRvYmoNMjAgMCBvYmoNPDwNL1R5cGUgL1BhZ2UNL1Bh cmVudCA1IDAgUg0vUmVzb3VyY2VzIDw8DS9Gb250IDw8DS9GMCA2IDAgUiANL0YyIDEwIDAgUiAN Pj4NL1Byb2NTZXQgMiAwIFINPj4NL0NvbnRlbnRzIDIxIDAgUg0+Pg1lbmRvYmoNMjQgMCBvYmoN PDwNL0xlbmd0aCAyNSAwIFINL0ZpbHRlciAvTFpXRGVjb2RlIA0+Pg1zdHJlYW0NCoAQioDRiNRs IIMNhcOBwIBAVCIDRgIInEzkZxADReRomMRgLhhDYeZgaLY+MBiNBpDioYxBJpAMxxK4edxAKCMZ TEcjqYTkeRAMhhQ4eUhoNRcNheVCmRxaUBATTKZToaTdGCkZTgbzkdBTDzVEpeMRiLhqMpYRIpIB gNRnLJdJ5QOZZNhQUzCbhARDSZTObxYICGQa+VLCMhxC5eMqRaIfao3aI9IJEVJILcaNxwMbhFLr Ny4MhsN8LYRpZoPE8eII3HZPlZJqpba6GN8cVLsINLBBmLpVntXMBgNJRnZNnxQVDQZRAZTwYTGd BAZKoYTSbDmIDeZhAdOWIDgYTPVowbTKYzReTSczaIJ9zKt3e+ZDkYTNXrBJRpCoaLRmpDhrS1gj Mk16WMuzLNs62S7NC0bdtOgzgIhAbXMpA6xIeuK2Ns5DdPyGLet+2S1OEs4buMj6POKmqbiaOo2K qMYwjm6Q2jSMY5DeNo3jE640jooAuBQKyrDeMgQCWOo2p8LgUt2yb+hiGQXBkmkKMiEDJpDDDMSq zTOQ1CcGtE0j8wi1MBNbLUDJHDLZrlDsWhRD7DN43yVxIl6ThoGUwtm4UrIPOYmjeqo7DCqo3jcH TujCNbmDCMlEDcOjxOY7YQDYMo7DKNigvcN0kLeqw6DK+rojTRYdu6+o3Dm8I5DLSrujeEEeR9TY QDdI4y1ZS1IN2/ykrGsqzwE4U+xRMS5Biuk50lSlLDPTDuDbGA6RnGoQR0OqqquwIwjgOA2KAOlb CSKA7IOvMkXSOwaMCMUaDLJFF1vR7mDEMozK5fVZUeEEajzXT01E7YzWElLfLHKkrTVAk2QvN0vB lMEFuRB0zTtNEJsgjmJS5NzZQ22rbtzKERTzZCTo9K6XOEGYZ2e3CbiFegQCnS1FUY7o71tGb0DK 7IWhaEEfVE8gQaC5bAjhHV5jFculug5YXocObyV1a8YxxGjpUk+mhuyOFT1vHrrjLYTeoOFqyLM2 8S5aG2aZgk4ZZm5FeOowOsqvXQhieILwbMJonBch7vjDbw0K4ED16W9I2U2q961q6d+KtSOj5xGt E1UN3EOVSI5PRIDzjoOtZN2ie3LKxGWJiHFB0BOIauQMMeDrSrs3O93HjcMz6xqnjo9VfVPDemzv OZTdO0/TPmBAIzCPztzTpXt2HSvj8C4myySwTP644zMsINRj0K5C2E35KGE5ZrOmUzx9LhWdFKQB ohjkdHzg5tDZ26Bx52QwtSOY74NQbz4hhVuthry2wzrdDg6I74aA0hnOWHJTSnFPLcDet5szkICq 6d8rNGYcA5owUS2p6zbFitwdiUMGztG7EgBiDhk5N12sCVmkgOwaYGNcRk19y70l5v/YFAFRYc4K L6c7EpV58lZuYhPCkNkK4mv+OY55ngc3WQvWOcEk4NwYN1NoxdOcCT4tPDedBQ6ng8guYU9hhqVX uIDe8yJ8DFY0JwfKg9M76E9JrS2+xkhtH3w5fkiBlT9WWg5jMiYGTNC7BRDrAB0CjQkPKOmG9ocU oGtdW0dIqy/Q5JMZ40c5gZD1h0DkGkMUIEkO+ekoiV8HzsrdVMHI7IcQ6o4DWuVtaxHXQwNWXIGx t3yJzVnB+DAP1hA0N6Wg/yAI7pZkKl18RnQUMafOhKQbIJssjQWhyRSdSwohfonpQJR38EhBwW9O YSAwh3OsGkECQwpO5BBPsNoaippOSgR9KT22IR5fZHxBSzI/sbNNIJiCFo9GxnKyZDz80RwxKEy9 PZbGHpzn8twMsvoAO9PSdIOaOzmBjR20hz8SztHcCQE1dIL56T2DSGkF4Q10yqPA6qFK9WFUFjtQ d9c2kv0Lj8nOb0gZwURqPORZk5qLyMnXRoxk7wag3dunN/rT2hqzihAM7qp0bhuhWkgMS5jvhDPS GmXh05LuXiuGMNdMTuhpPNNE/hLz/v5qNOOPc26GVMfNU5NJq5CJtfBIdOM56MMrjESCZUiJFG4V soaDLj1TBtOyvd6Sl1RQMPertQx4FZP/Uq5YMlc3fV1ru9GvQZYsh0Z+e5alo7OBls8e5WQIAdJQ SksZuKAy32CMunwysy34hvN3YlLE4rGUUqnRZOc6CCFonZGMlM7yUJXLsoVXJzKew7CaFAJgU58g yNEVFxAV1ZBuqHGC4pG7j3TJLcpjCc7nH5ugx+iUhqKyJqqnZKcjn8n/oqDV95yLxNpBAFYKATjs mhvaEVxBeA3NCD1fOYsYbo33e/cl/Ny0xk3v6na/76rkPtkQ/BlCILtQxKPV12pIMGSKCCXpUp9Q WhkR2dYvWDw2JAKAkytC1DzK0jYuelin8LEHCC4gJp6z6m7CKQMgIA1lbmRzdHJlYW0NZW5kb2Jq DTI1IDAgb2JqDTE3NTgNZW5kb2JqDTIzIDAgb2JqDTw8DS9UeXBlIC9QYWdlDS9QYXJlbnQgNSAw IFINL1Jlc291cmNlcyA8PA0vRm9udCA8PA0vRjAgNiAwIFIgDS9GMiAxMCAwIFIgDS9GMyAyNiAw IFIgDT4+DS9Qcm9jU2V0IDIgMCBSDT4+DS9Db250ZW50cyAyNCAwIFINPj4NZW5kb2JqDTYgMCBv YmoNPDwNL1R5cGUgL0ZvbnQNL1N1YnR5cGUgL1RydWVUeXBlDS9OYW1lIC9GMA0vQmFzZUZvbnQg L0FyaWFsDS9GaXJzdENoYXIgMzINL0xhc3RDaGFyIDI1NQ0vV2lkdGhzIFsgMjg1IDMzMyAzNTcg NTQ3IDU0NyA4ODAgNjY2IDE5MCAzMzMgMzMzIDM4MCA1OTUgMjg1IDMzMyAyODUgMjg1IA01NDcg NTQ3IDU0NyA1NDcgNTQ3IDU0NyA1NDcgNTQ3IDU0NyA1NDcgMjg1IDI4NSA1OTUgNTk1IDU5NSA1 NDcgDTEwMjMgNjY2IDY2NiA3MTQgNzE0IDY2NiA2MTkgNzg1IDcxNCAyODUgNTAwIDY2NiA1NDcg ODMzIDcxNCA3ODUgDTY2NiA3ODUgNzE0IDY2NiA2MTkgNzE0IDY2NiAxMDAwIDY0MiA2NjYgNjE5 IDI4NSAyODUgMjg1IDQ1MiA1NDcgDTMzMyA1NDcgNTQ3IDUwMCA1NDcgNTQ3IDMwOSA1NDcgNTQ3 IDIzOCAyMzggNTAwIDIzOCA4NTcgNTQ3IDU0NyANNTQ3IDU0NyAzMzMgNDc2IDI4NSA1NDcgNTQ3 IDY5MCA1MjMgNTAwIDUwMCAzMzMgMjYxIDMzMyA1OTUgNzYxIA01OTUgNzYxIDU5NSA1OTUgNTk1 IDU5NSA1OTUgNTk1IDU5NSA1OTUgNTk1IDU5NSA1OTUgNzYxIDU5NSA3NjEgDTc2MSA1OTUgNTk1 IDU5NSA1OTUgNTk1IDU5NSA1OTUgNTk1IDU5NSA1OTUgNTk1IDU5NSA3NjEgNTk1IDU5NSANMjg1 IDMzMyA1NDcgNTQ3IDU0NyA1NDcgMjYxIDU0NyAzMzMgNzM4IDM4MCA1NDcgNTk1IDMzMyA3Mzgg NTQ3IA00MDQgNTQ3IDMzMyAzMzMgMzMzIDU3MSA1NDcgMjg1IDMzMyAzMzMgMzU3IDU0NyA4MzMg ODMzIDgzMyA2MTkgDTY2NiA2NjYgNjY2IDY2NiA2NjYgNjY2IDEwMDAgNzE0IDY2NiA2NjYgNjY2 IDY2NiAyODUgMjg1IDI4NSAyODUgDTcxNCA3MTQgNzg1IDc4NSA3ODUgNzg1IDc4NSA1OTUgNzg1 IDcxNCA3MTQgNzE0IDcxNCA2NjYgNjY2IDYxOSANNTQ3IDU0NyA1NDcgNTQ3IDU0NyA1NDcgODgw IDUwMCA1NDcgNTQ3IDU0NyA1NDcgMjg1IDI4NSAyODUgMjg1IA01NDcgNTQ3IDU0NyA1NDcgNTQ3 IDU0NyA1NDcgNTQ3IDYxOSA1NDcgNTQ3IDU0NyA1NDcgNTAwIDU0NyA1MDAgDV0NL0VuY29kaW5n IC9XaW5BbnNpRW5jb2RpbmcNL0ZvbnREZXNjcmlwdG9yIDcgMCBSDT4+DWVuZG9iag03IDAgb2Jq DTw8DS9UeXBlIC9Gb250RGVzY3JpcHRvcg0vRm9udE5hbWUgL0FyaWFsDS9GbGFncyAzMg0vRm9u dEJCb3ggWyAtMjUwIC0yMTIgMTIyOSAxMDU1IF0NL01pc3NpbmdXaWR0aCAyODYNL1N0ZW1WIDgw DS9TdGVtSCA4MA0vSXRhbGljQW5nbGUgMA0vQ2FwSGVpZ2h0IDkwNQ0vWEhlaWdodCA0NTMNL0Fz Y2VudCA5MDUNL0Rlc2NlbnQgLTIxMg0vTGVhZGluZyAxNTANL01heFdpZHRoIDEwMjQNL0F2Z1dp ZHRoIDQ0MQ0+Pg1lbmRvYmoNOCAwIG9iag08PA0vVHlwZSAvRm9udA0vU3VidHlwZSAvVHJ1ZVR5 cGUNL05hbWUgL0YxDS9CYXNlRm9udCAvQXJpYWwsQm9sZA0vRmlyc3RDaGFyIDMyDS9MYXN0Q2hh ciAyNTUNL1dpZHRocyBbIDI4NSAzMzMgNDc2IDU0NyA1NDcgODMzIDcxNCAyMzggMzMzIDMzMyAz ODAgNTk1IDI4NSAzMzMgMjg1IDI4NSANNTQ3IDU0NyA1NDcgNTQ3IDU0NyA1NDcgNTQ3IDU0NyA1 NDcgNTQ3IDMzMyAzMzMgNTk1IDU5NSA1OTUgNjE5IA05NzYgNjkwIDcxNCA3MTQgNzE0IDY2NiA2 MTkgNzg1IDcxNCAyODUgNTQ3IDcxNCA2MTkgODMzIDcxNCA3ODUgDTY2NiA3ODUgNzE0IDY2NiA2 NDIgNzE0IDY2NiA5MjggNjY2IDY2NiA2MTkgMzMzIDI4NSAzMzMgNTk1IDU0NyANMzMzIDU0NyA2 MTkgNTQ3IDYxOSA1NDcgMzMzIDYxOSA2MTkgMjg1IDI4NSA1NDcgMjg1IDg4MCA2MTkgNjE5IA02 MTkgNjE5IDM4MCA1NDcgMzMzIDYxOSA1NDcgNzg1IDU0NyA1NDcgNTAwIDM4MCAyODUgMzgwIDU5 NSA3NjEgDTU5NSA3NjEgNTk1IDU5NSA1OTUgNTk1IDU5NSA1OTUgNTk1IDU5NSA1OTUgNTk1IDU5 NSA3NjEgNTk1IDc2MSANNzYxIDU5NSA1OTUgNTk1IDU5NSA1OTUgNTk1IDU5NSA1OTUgNTk1IDU5 NSA1OTUgNTk1IDc2MSA1OTUgNTk1IA0yODUgMzMzIDU0NyA1NDcgNTQ3IDU0NyAyODUgNTQ3IDMz MyA3MzggMzgwIDU0NyA1OTUgMzMzIDczOCA1NDcgDTQwNCA1NDcgMzMzIDMzMyAzMzMgNTcxIDU0 NyAyODUgMzMzIDMzMyAzNTcgNTQ3IDgzMyA4MzMgODMzIDYxOSANNjkwIDY5MCA2OTAgNjkwIDY5 MCA2OTAgMTAwMCA3MTQgNjY2IDY2NiA2NjYgNjY2IDI4NSAyODUgMjg1IDI4NSANNzE0IDcxNCA3 ODUgNzg1IDc4NSA3ODUgNzg1IDU5NSA3ODUgNzE0IDcxNCA3MTQgNzE0IDY2NiA2NjYgNjE5IA01 NDcgNTQ3IDU0NyA1NDcgNTQ3IDU0NyA4ODAgNTQ3IDU0NyA1NDcgNTQ3IDU0NyAyODUgMjg1IDI4 NSAyODUgDTYxOSA2MTkgNjE5IDYxOSA2MTkgNjE5IDYxOSA1NDcgNjE5IDYxOSA2MTkgNjE5IDYx OSA1NDcgNjE5IDU0NyANXQ0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZw0vRm9udERlc2NyaXB0 b3IgOSAwIFINPj4NZW5kb2JqDTkgMCBvYmoNPDwNL1R5cGUgL0ZvbnREZXNjcmlwdG9yDS9Gb250 TmFtZSAvQXJpYWwsQm9sZA0vRmxhZ3MgMTY0MTYNL0ZvbnRCQm94IFsgLTI1MCAtMjEyIDEyMDAg MTA1NSBdDS9NaXNzaW5nV2lkdGggMzMzDS9TdGVtViAxNTMNL1N0ZW1IIDE1Mw0vSXRhbGljQW5n bGUgMA0vQ2FwSGVpZ2h0IDkwNQ0vWEhlaWdodCA0NTMNL0FzY2VudCA5MDUNL0Rlc2NlbnQgLTIx Mg0vTGVhZGluZyAxNTANL01heFdpZHRoIDEwMDANL0F2Z1dpZHRoIDQ3OQ0+Pg1lbmRvYmoNMTAg MCBvYmoNPDwNL1R5cGUgL0ZvbnQNL1N1YnR5cGUgL1RydWVUeXBlDS9OYW1lIC9GMg0vQmFzZUZv bnQgL1N5bWJvbA0vRmlyc3RDaGFyIDMwDS9MYXN0Q2hhciAyNTUNL1dpZHRocyBbIDU5NSAyNjEg MzMzIDY5MCA0NzYgNTQ3IDgzMyA3ODUgNDUyIDMzMyAzMzMgNTAwIDU0NyAyMzggNTQ3IDI2MSAN Mjg1IDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCAyODUgMjM4IDU0NyA1 NDcgNTQ3IA00NTIgNTcxIDcxNCA2NjYgNzM4IDYxOSA2MTkgODA5IDU5NSA3MzggMzMzIDU5NSA3 MzggNjkwIDkwNCA3MTQgDTcxNCA3ODUgNzM4IDU3MSA2MTkgNTk1IDY2NiA0MjggNzg1IDY5MCA4 MDkgNjE5IDMzMyA4NTcgMjYxIDY2NiANNTAwIDQ3NiA2MTkgNTk1IDU5NSA1OTUgOTc2IDUwMCA3 NjEgMTA0NyA1OTUgNjkwIDU3MSA3NjEgNzg1IDU5NSANNTk1IDU5NSA3NjEgNTk1IDU5NSA3MTQg NTAwIDU0NyA1NDcgNTk1IDU0NyAzODAgMjYxIDU5NSA3ODUgMTAwMCANNDA0IDU5NSA1NDcgNTQ3 IDU0NyA1NDcgNTQ3IDU0NyA1NDcgNTQ3IDU0NyA1NDcgNTQ3IDU0NyA1NDcgNzM4IA01NDcgNTk1 IDU5NSA1NDcgNTQ3IDU0NyA1NDcgNTQ3IDU0NyA1NDcgNTQ3IDU0NyA1NDcgNTQ3IDU0NyA3NjEg DTU0NyA1NDcgNjkwIDIzOCA5NzYgNzYxIDgwOSA1OTUgNTcxIDUyMyA1OTUgNDc2IDcxNCA0Mjgg NzYxIDcxNCANNjkwIDcxNCA3MTQgNzM4IDM4MCA0NzYgNzE0IDY5MCA3NjEgOTc2IDQwNCA1MDAg NTk1IDkwNCA3ODUgNzg1IA01OTUgMzgwIDM4MCA1OTUgNTk1IDMzMyA1NDcgNTcxIDU0NyA1MjMg NTk1IDU0NyA1MjMgNTIzIDUyMyA1OTUgDTU3MSA0MjggNzE0IDY0MiAzODAgNDUyIDQ3NiA2OTAg NTAwIDUwMCAxOTAgNDUyIDYxOSA1OTUgNTQ3IDU5NSANNTk1IDM4MCA1MDAgNTcxIDU0NyA1NDcg NTQ3IDU0NyA1NDcgNTQ3IDU0NyA1NDcgNTQ3IDU0NyA1NDcgNTQ3IA01NDcgNTQ3IDU0NyA1NDcg NTQ3IDU0NyA1NDcgNTQ3IDU0NyA1NDcgNTQ3IDU0NyA1NDcgNTQ3IDU0NyA1NDcgDTU0NyA1NDcg XQ0vRm9udERlc2NyaXB0b3IgMTEgMCBSDT4+DWVuZG9iag0xMSAwIG9iag08PA0vVHlwZSAvRm9u dERlc2NyaXB0b3INL0ZvbnROYW1lIC9TeW1ib2wNL0ZsYWdzIDYNL0ZvbnRCQm94IFsgLTI1MCAt MjIwIDEyNTggMTIzMCBdDS9NaXNzaW5nV2lkdGggODU3DS9TdGVtViAxMDkNL1N0ZW1IIDEwOQ0v SXRhbGljQW5nbGUgMA0vQ2FwSGVpZ2h0IDEwMDUNL1hIZWlnaHQgNTAzDS9Bc2NlbnQgMTAwNQ0v RGVzY2VudCAtMjIwDS9MZWFkaW5nIDIyNQ0vTWF4V2lkdGggMTA0OA0vQXZnV2lkdGggNjAwDT4+ DWVuZG9iag0yNiAwIG9iag08PA0vVHlwZSAvRm9udA0vU3VidHlwZSAvVHJ1ZVR5cGUNL05hbWUg L0YzDS9CYXNlRm9udCAvQ291cmllck5ldw0vRmlyc3RDaGFyIDMyDS9MYXN0Q2hhciAyNTUNL1dp ZHRocyBbIDU5NSA1OTUgNTk1IDU5NSA1OTUgNTk1IDU5NSA1OTUgNTk1IDU5NSA1OTUgNTk1IDU5 NSA1OTUgNTk1IDU5NSANNTk1IDU5NSA1OTUgNTk1IDU5NSA1OTUgNTk1IDU5NSA1OTUgNTk1IDU5 NSA1OTUgNTk1IDU5NSA1OTUgNTk1IA01OTUgNTk1IDU5NSA1OTUgNTk1IDU5NSA1OTUgNTk1IDU5 NSA1OTUgNTk1IDU5NSA1OTUgNTk1IDU5NSA1OTUgDTU5NSA1OTUgNTk1IDU5NSA1OTUgNTk1IDU5 NSA1OTUgNTk1IDU5NSA1OTUgNTk1IDU5NSA1OTUgNTk1IDU5NSANNTk1IDU5NSA1OTUgNTk1IDU5 NSA1OTUgNTk1IDU5NSA1OTUgNTk1IDU5NSA1OTUgNTk1IDU5NSA1OTUgNTk1IA01OTUgNTk1IDU5 NSA1OTUgNTk1IDU5NSA1OTUgNTk1IDU5NSA1OTUgNTk1IDU5NSA1OTUgNTk1IDU5NSA1OTUgDTU5 NSA1OTUgNTk1IDU5NSA1OTUgNTk1IDU5NSA1OTUgNTk1IDU5NSA1OTUgNTk1IDU5NSA1OTUgNTk1 IDU5NSANNTk1IDU5NSA1OTUgNTk1IDU5NSA1OTUgNTk1IDU5NSA1OTUgNTk1IDU5NSA1OTUgNTk1 IDU5NSA1OTUgNTk1IA01OTUgNTk1IDU5NSA1OTUgNTk1IDU5NSA1OTUgNTk1IDU5NSA1OTUgNTk1 IDU5NSA1OTUgNTk1IDU5NSA1OTUgDTU5NSA1OTUgNTk1IDU5NSA1OTUgNTk1IDU5NSA1OTUgNTk1 IDU5NSA1OTUgNTk1IDU5NSA1OTUgNTk1IDU5NSANNTk1IDU5NSA1OTUgNTk1IDU5NSA1OTUgNTk1 IDU5NSA1OTUgNTk1IDU5NSA1OTUgNTk1IDU5NSA1OTUgNTk1IA01OTUgNTk1IDU5NSA1OTUgNTk1 IDU5NSA1OTUgNTk1IDU5NSA1OTUgNTk1IDU5NSA1OTUgNTk1IDU5NSA1OTUgDTU5NSA1OTUgNTk1 IDU5NSA1OTUgNTk1IDU5NSA1OTUgNTk1IDU5NSA1OTUgNTk1IDU5NSA1OTUgNTk1IDU5NSANNTk1 IDU5NSA1OTUgNTk1IDU5NSA1OTUgNTk1IDU5NSA1OTUgNTk1IDU5NSA1OTUgNTk1IDU5NSA1OTUg NTk1IA1dDS9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nDS9Gb250RGVzY3JpcHRvciAyNyAwIFIN Pj4NZW5kb2JqDTI3IDAgb2JqDTw8DS9UeXBlIC9Gb250RGVzY3JpcHRvcg0vRm9udE5hbWUgL0Nv dXJpZXJOZXcNL0ZsYWdzIDM0DS9Gb250QkJveCBbIC0yNTAgLTMwMCA3MTQgMTAwMCBdDS9NaXNz aW5nV2lkdGggNTk1DS9TdGVtViAxMDkNL1N0ZW1IIDEwOQ0vSXRhbGljQW5nbGUgMA0vQ2FwSGVp Z2h0IDgzMw0vWEhlaWdodCA0MTcNL0FzY2VudCA4MzMNL0Rlc2NlbnQgLTMwMA0vTGVhZGluZyAx MzMNL01heFdpZHRoIDU5NQ0vQXZnV2lkdGggNjAwDT4+DWVuZG9iag0yIDAgb2JqDVsgL1BERiAv VGV4dCAgXQ1lbmRvYmoNNSAwIG9iag08PA0vS2lkcyBbNCAwIFIgMTQgMCBSIDE3IDAgUiAyMCAw IFIgMjMgMCBSIF0NL0NvdW50IDUNL1R5cGUgL1BhZ2VzDS9NZWRpYUJveCBbIDAgMCA3OTIgNjEy IF0NPj4NZW5kb2JqDTEgMCBvYmoNPDwNL0NyZWF0b3IgKCkNL0NyZWF0aW9uRGF0ZSAoRDoyMDAw MDgxODA5NDc1MykNL1RpdGxlIChNSVAgbWludXRlcy5QREYpDS9BdXRob3IgKHJvYmVydHMpDS9Q cm9kdWNlciAoQWNyb2JhdCBQREZXcml0ZXIgMy4wMiBmb3IgV2luZG93cyBOVCkNL0tleXdvcmRz ICgpDS9TdWJqZWN0ICgpDT4+DWVuZG9iag0zIDAgb2JqDTw8DS9QYWdlcyA1IDAgUg0vVHlwZSAv Q2F0YWxvZw0+Pg1lbmRvYmoNeHJlZg0wIDI4DTAwMDAwMDAwMDAgNjU1MzUgZiANMDAwMDAyMTUw MiAwMDAwMCBuIA0wMDAwMDIxMzU5IDAwMDAwIG4gDTAwMDAwMjE2ODYgMDAwMDAgbiANMDAwMDAw MzE5MSAwMDAwMCBuIA0wMDAwMDIxMzkwIDAwMDAwIG4gDTAwMDAwMTYwMTIgMDAwMDAgbiANMDAw MDAxNzA5MyAwMDAwMCBuIA0wMDAwMDE3MzQ2IDAwMDAwIG4gDTAwMDAwMTg0MzAgMDAwMDAgbiAN MDAwMDAxODY5MyAwMDAwMCBuIA0wMDAwMDE5NzU3IDAwMDAwIG4gDTAwMDAwMDAwMTkgMDAwMDAg biANMDAwMDAwMzE3MCAwMDAwMCBuIA0wMDAwMDA2NzgxIDAwMDAwIG4gDTAwMDAwMDMzMzMgMDAw MDAgbiANMDAwMDAwNjc2MCAwMDAwMCBuIA0wMDAwMDEwMjc3IDAwMDAwIG4gDTAwMDAwMDY5MTMg MDAwMDAgbiANMDAwMDAxMDI1NiAwMDAwMCBuIA0wMDAwMDEzODgxIDAwMDAwIG4gDTAwMDAwMTA0 MjAgMDAwMDAgbiANMDAwMDAxMzg2MCAwMDAwMCBuIA0wMDAwMDE1ODY4IDAwMDAwIG4gDTAwMDAw MTQwMTMgMDAwMDAgbiANMDAwMDAxNTg0NyAwMDAwMCBuIA0wMDAwMDIwMDE1IDAwMDAwIG4gDTAw MDAwMjExMDAgMDAwMDAgbiANdHJhaWxlcg08PA0vU2l6ZSAyOA0vUm9vdCAzIDAgUg0vSW5mbyAx IDAgUg0vSUQgWzxhZGVlYWY5M2ZkZjQ1NWU3M2I4NzMxNjI3NzQ1MDU1Nj48YWRlZWFmOTNmZGY0 NTVlNzNiODczMTYyNzc0NTA1NTY+XQ0+Pg1zdGFydHhyZWYNMjE3MzUNJSVFT0YN ------_=_NextPart_000_01C00923.9D821FF0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Aug 18 10:57:30 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29713 for ; Fri, 18 Aug 2000 10:57:30 -0400 (EDT) Received: from standards (47.234.32.16:1875) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB89799@standards.nortelnetworks.com>; Fri, 18 Aug 2000 10:44:51 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19845 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 18 Aug 2000 10:44:51 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB89798@standards.nortelnetworks.com>; Fri, 18 Aug 2000 10:44:50 -0400 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 HAA05040; Fri, 18 Aug 2000 07:56:56 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e7IEurt04516; Fri, 18 Aug 2000 07:56:53 -0700 X-Virus-Scanned: Fri, 18 Aug 2000 07:56:53 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdtibAse; Fri, 18 Aug 2000 07:56:45 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <399D4EAF.FE90300D@iprg.nokia.com> Date: Fri, 18 Aug 2000 07:56:47 -0700 Reply-To: charliep@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: Re: [MOBILE-IP] charter review X-To: Matthias.Kraner@SWIFT.SHEF.AC.UK To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Matthias, > However, it seems that there is only little research available on MIP > perfomance especially in those areas mentioned in the charter: GPRS, UMTS, > CDMA2000. These would be interesting numbers to get. > Given that after Pittsburgh, I have been told, there are still severe > issues with the handoff problem, that there are security issues > (unfortunately others overspent the time guidelines sufficiently that a > colleague of mine couldn't present her contribution) Could you describe the security issues? > and that MIP in both > versions is heavily contributing towards transport overhead on expensive > spectrum, How does Mobile IP contribute in any significant way, compared to (say) IP header overhead on data packets? > I believe it is premature to assume MIP is really the suitable > solution and thus to exclude other protocols proposals. (It is still a pain > to make MIP interworking on different platforms) Let's assume that Mobile IP does not solve all problems associated with mobility. In fact, it really just makes IP packet redirection invisible to higher level protocols (and applications). Thus, for other mobility problems (e.g., service discovery) Mobile IP is not "the suitable solution". Do you claim that Mobile IP is not the suitable solution for managing IP routing to mobile nodes? If so, can you suggest a better approach? Or, instead, do you claim that there are application requirements that are not solved by Mobile IP? In that case, I reckon you would get widespread agreement. On the other hand, I don't know whether the mobile-ip working group is prepared to take on application issues. Of course I am only speaking for myself; if others wanted to take up the problem area, that could lead to many possible improvements. > There is no need to adopt another protocol from scratch but at least some > thoughts might be worthwhile considering for future MIP versions ;-). > > How about taking the advantage and to review the whole process of MIP > standardization. It might be not to late to review the research in this > area. Is it time for a CFP to support this? What does CFP mean in the context of an IETF working group? Do you mean to propose a design team? Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Aug 18 11:02:39 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29860 for ; Fri, 18 Aug 2000 11:02:39 -0400 (EDT) Received: from standards (47.234.32.16:1875) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB897E5@standards.nortelnetworks.com>; Fri, 18 Aug 2000 10:49:40 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19943 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 18 Aug 2000 10:49:39 -0400 Received: from ish7.ericsson.com.au (203.61.155.111:55105) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB897E4@standards.nortelnetworks.com>; Fri, 18 Aug 2000 10:49:38 -0400 Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id AAA01824; Sat, 19 Aug 2000 00:59:47 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id BAA06091; Sat, 19 Aug 2000 01:01:25 +1000 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Sat, 19 Aug 2000 01:01:23 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C00925.2C585400" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A5089EB188@eaubrnt018.epa.ericsson.se> Date: Sat, 19 Aug 2000 01:01:22 +1000 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] pittsburgh minutes X-To: Roberts Phil-QA3445 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM 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_01C00925.2C585400 Content-Type: text/plain; charset="iso-8859-1" Hello Phil, The HMIPv6 draft name is incorrect, it should be draft-soliman-hmipv6-00.txt Thanks, Hesham -----Original Message----- From: Roberts Phil-QA3445 [mailto:qa3445@EMAIL.MOT.COM] Sent: den 18 augusti 2000 16:50 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: [MOBILE-IP] pittsburgh minutes Please comment on this draft of the meeting minutes. Thanks very much to Tom Hiller for recording in Pittsburgh. <> ------_=_NextPart_001_01C00925.2C585400 Content-Type: text/html; charset="iso-8859-1" RE: [MOBILE-IP] pittsburgh minutes

Hello Phil,

The HMIPv6 draft name is incorrect, it should be

draft-soliman-hmipv6-00.txt

Thanks,
Hesham

-----Original Message-----
From: Roberts Phil-QA3445 [mailto:qa3445@EMAIL.MOT.COM]
Sent: den 18 augusti 2000 16:50
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: [MOBILE-IP] pittsburgh minutes



Please comment on this draft of the meeting minutes.  Thanks very much to
Tom Hiller for recording in Pittsburgh.

 <<pittsminutes.pdf>>

------_=_NextPart_001_01C00925.2C585400-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Aug 18 11:17:07 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00155 for ; Fri, 18 Aug 2000 11:17:06 -0400 (EDT) Received: from standards (47.234.32.16:1875) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8985F@standards.nortelnetworks.com>; Fri, 18 Aug 2000 11:03:42 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20104 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 18 Aug 2000 11:03:42 -0400 Received: from ish7.ericsson.com.au (203.61.155.111:55187) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8985A@standards.nortelnetworks.com>; Fri, 18 Aug 2000 11:03:41 -0400 Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id BAA02024; Sat, 19 Aug 2000 01:13:48 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id BAA07324; Sat, 19 Aug 2000 01:15:25 +1000 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Sat, 19 Aug 2000 01:15:23 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C00927.2116F0E0" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A5089EB18B@eaubrnt018.epa.ericsson.se> Date: Sat, 19 Aug 2000 01:15:22 +1000 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] IPv6 handover document X-To: Gerald Maguire To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM 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_01C00927.2116F0E0 Content-Type: text/plain; charset="iso-8859-1" Chip, You stated: If the link medium is using different physical channels (different frequencies, not CDMA technology, for instance), then a receiver can usually only lock onto one single of these channels, since (due to cost) it is only equipped with one transceiver. If access point A is on subnet Na and using channel Ca, a mobile node locked onto channel Ca won't be able to hear or measure anything of a possible access point B on subnet Nb on channel Cb. The only way for the mobile node to detect the presence of B would be to start a scan over all channels (and do so occasionally) or to be informed of its existence by the network over channel Ca. This is not quite true, as it is possible for the receiver to have only enough circuitry to determine the power level in a band - and thus detect activity in other frequency bands -- even though it is not listening to the actual data in these bands (for example DECT receivers do this). In addition, it is also possible to use wideband front ends to the receiver and do the decoding of multiple narrow bands within (for example using software radio techniques). Again, a useful aspect is that you might not need to actually decode all the narrowband contents, but just look for some feaure -- such as a pilot tone or the freq. spectrum or perhaps only decode it once in a while. All of the above means that you don't necessary have to have a second full receiver nor do you have to necessary time multiplex this receiver (and hence lose the current communication channel) by having it scan the other channels. However, I think we are rapidly reaching the point where it will be the case that we have multiple receivers in many devices and it will be nature to use one for the current communication and the others either for additional communication channels or to (occasionally) look for better communication channels. This is certainly the case with cellular handsets which have multiple distinct radio receivers (such as GSM and DECT or the long awaited GSM and Bluetooth). Further, it does not cost that much to listen to multiple channels -- vs. the cost to both listen and transmit on multiple channels. I've often thought of having CDMA beacons that annouce what resources are available -- in analogy with the signs you see on many highways which tell you want are the local radio stations (for traffic/public safety information). Such a beacon could be design to have a very low data rate (and very long spread code) - so that it could be very readily detected, but minimize its interference. => That's an interesting analysis. Are there any products that you know of and can do this (ie. WLAN, CDMA terminals). I'm talking about receiving more than one traffic stream simultaneously on the same receiver. ------_=_NextPart_001_01C00927.2116F0E0 Content-Type: text/html; charset="iso-8859-1" RE: [MOBILE-IP] IPv6 handover document

Chip,

You stated:
    If the link medium is using different physical channels (different frequencies,
    not CDMA technology, for instance), then a receiver can usually only lock onto
    one single of these channels, since (due to cost) it is only equipped with one
    transceiver. If access point A is on subnet Na and using channel Ca, a mobile
    node locked onto channel Ca won't be able to hear or measure anything of a
    possible access point B on subnet Nb on channel Cb. The only way for the mobile
    node to detect the presence of B would be to start a scan over all channels
    (and do so occasionally) or to be informed of its existence by the network over
    channel Ca.

This is not quite true, as it is possible for the receiver to have
only enough circuitry to determine the power level in a band - and
thus detect activity in other frequency bands -- even though it is not
listening to the actual data in these bands (for example DECT
receivers do this).

In addition, it is also possible to use wideband front ends to the
receiver and do the decoding of multiple narrow bands within (for
example using software radio techniques). Again, a useful aspect is
that you might not need to actually decode all the narrowband
contents, but just look for some feaure -- such as a pilot tone or the
freq. spectrum or perhaps only decode it once in a while.

All of the above means that you don't necessary have to have a second
full receiver nor do you have to necessary time multiplex this
receiver (and hence lose the current communication channel) by having
it scan the other channels.

However, I think we are rapidly reaching the point where it will be
the case that we have multiple receivers in many devices and it will
be nature to use one for the current communication and the others
either for additional communication channels or to (occasionally) look
for better communication channels. This is certainly the case with
cellular handsets which have multiple distinct radio receivers (such
as GSM and DECT or the long awaited GSM and Bluetooth).

Further, it does not cost that much to listen to multiple channels --
vs. the cost to both listen and transmit on multiple channels.

I've often thought of having CDMA beacons that annouce what resources
are available -- in analogy with the signs you see on many highways
which tell you want are the local radio stations (for traffic/public
safety information). Such a beacon could be design to have a very low
data rate (and very long spread code) - so that it could be very
readily detected, but minimize its interference.

=> That's an interesting analysis. Are there any products that
you know of and can do this (ie. WLAN, CDMA terminals).
I'm talking about receiving more than one traffic stream
simultaneously on the same receiver.

------_=_NextPart_001_01C00927.2116F0E0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Aug 18 12:08:46 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01343 for ; Fri, 18 Aug 2000 12:08:46 -0400 (EDT) Received: from standards (47.234.32.16:1118) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB898CE@standards.nortelnetworks.com>; Fri, 18 Aug 2000 11:55:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20253 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 18 Aug 2000 11:55:56 -0400 Received: from dumburken.it.kth.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB898CD@standards.nortelnetworks.com>; Fri, 18 Aug 2000 11:55:54 -0400 Received: (from maguire@localhost) by dumburken.it.kth.se (8.9.3/8.9.3) id SAA10066; Fri, 18 Aug 2000 18:07:47 +0200 (MET DST) X-Authentication-Warning: dumburken.it.kth.se: maguire set sender to maguire@dumburken.it.kth.se using -f References: <4B6BC00CD15FD2119E5F0008C7A419A5089EB18B@eaubrnt018.epa.ericsson.se> Message-ID: <200008181607.SAA10066@dumburken.it.kth.se> Date: Fri, 18 Aug 2000 18:07:47 +0200 Reply-To: Gerald Maguire Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gerald Maguire Subject: Re: [MOBILE-IP] IPv6 handover document X-To: Hesham.Soliman@ericsson.com.au To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <4B6BC00CD15FD2119E5F0008C7A419A5089EB18B@eaubrnt018.epa.ericsson.se> (Hesham.Soliman@ericsson.com.au) "Hesham Soliman (EPA)" said: => That's an interesting analysis. Are there any products that you know of and can do this (ie. WLAN, CDMA terminals). I'm talking about receiving more than one traffic stream simultaneously on the same receiver. I don't know of hand of any products (for mobiles) which do this, however, Daniel Kerek had an experimental Direct Sequence Spread Spectrum receiver here (in ~1992) where all you had to do was replicate the correlators to receive multiple streams (since then you can load different spreading codes in the different correlators and hence have multiple receivers). This should be perfectly feasible with existing direct sequence receivers -- if they have enough resources. Note that the amount of resources necessary to do this correlation is pretty small (especially when you put it all on one chip as Intersil can easily do). {In fact his and many other RAKE receivers already use 3 sets of correlators - early, late, and in sync -- so as to easily track the signal.} There are at least two papers about his design (and I think it is also covered in his licentiate thesis): D. Kerek, H. Tenhunen, G. Maguire, F. Reichert, Direct Sequence CDMA Technology and its Application to Future Portable Multimedia Communication Systems, IEEE ISSSTA'94 - Third International Symposium on Spread Spectrum Techniques & Applications, July 4-6, 1994, University of Oulu, Finland. D. Kerek, H. Tenhunen, G. Maguire, F. Reichert, The Walkstation Transceiver Design, Proceedings of the 44th IEEE Vehicular Technology Conference `94, Volume 1, pages 462-466, Stockholm, Sweden, June 1994. There are some chipsets such as the Harris Semiconductor HSP50214 which is designed (~1997) to "to permit a single digital radio to support a variety of air-interface standards. The HSP50214 is aimed at multimode DSP-based software receivers that used in basestations and test sets. ..." {The price in 1997 in 10K quantities as US$15.} In fact there are quite a lot of multichannel receivers for commercial cellular basestations. One of the changes which needs to occur is that WLAN manufacturers have to start designing their systems to support mobile clients, rather than the current model of simply eliminating the wire. If you really want to support mobility, you gain an enormous amount by having this second receive channel -- since then you can look for new access points. We also pointed out in an early paper that this means that you can also use a dedicated spreading code to send from an access point to a particular mobile (or group) or mobiles - while still using the first channel for two way communication. As the access point alone controls this 2nd channel you can have very highly efficient use of the channel and thus burst large amounts of data. The nice things is that Mobile IP readily supports this - since the different interfaces can have their temporary IP addresses, but the mobile has its fixed IP address. Hence the access point can send different traffic via the different interfaces (and channels) but the traffic can all be combined at the mobile when it detunnels the packets and then sends them all to the single mobile IP address. Regards, Chip From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Aug 18 12:30:28 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01673 for ; Fri, 18 Aug 2000 12:30:27 -0400 (EDT) Received: from standards (47.234.32.16:1118) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8992A@standards.nortelnetworks.com>; Fri, 18 Aug 2000 12:17:28 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20376 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 18 Aug 2000 12:17:28 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB89929@standards.nortelnetworks.com>; Fri, 18 Aug 2000 12:17:28 -0400 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA04626 for ; Fri, 18 Aug 2000 10:29:19 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA28890; Fri, 18 Aug 2000 09:28:43 -0700 (PDT) Received: from suntana (suntana [129.146.122.88]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id JAA14600; Fri, 18 Aug 2000 09:28:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 6kRKRVEMRoyJfu8qqDZimQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Message-ID: <200008181628.JAA14600@nasnfs.eng.sun.com> Date: Fri, 18 Aug 2000 09:33:34 -0700 Reply-To: James Kempf Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: James Kempf Subject: Re: [MOBILE-IP] IPv6 handover document X-To: maguire@IT.KTH.SE To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi Chip, >One of the changes which needs to occur is that WLAN manufacturers >have to start designing their systems to support mobile clients, >rather than the current model of simply eliminating the wire. If you >really want to support mobility, you gain an enormous amount by having >this second receive channel -- since then you can look for new access >points. We also pointed out in an early paper that this means that you >can also use a dedicated spreading code to send from an access point >to a particular mobile (or group) or mobiles - while still using the >first channel for two way communication. As the access point alone >controls this 2nd channel you can have very highly efficient use of >the channel and thus burst large amounts of data. > The problem is that wideband spectrum is *extremely* expensive. The auctions that just completed in Germany resulted in licenses that costed more that $9 billion per license. At that cost, the operators are highly motivated to squeeze as much revenue as possible out of each MHz. Perhaps if the radio protocol were designed correctly the amount of actual housekeeping traffic on the second channel could be limited, but, still, any use of spectrum for any housekeeping rather than revenue bearing traffic is likely to meet with strong resistence. I think that radio protocols which maximize the amount of revenue producing data per MHz of spectrum used are more likely to interest operators. jak From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Aug 18 13:00:12 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02338 for ; Fri, 18 Aug 2000 13:00:12 -0400 (EDT) Received: from standards (47.234.32.16:1118) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8999D@standards.nortelnetworks.com>; Fri, 18 Aug 2000 12:47:31 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20520 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 18 Aug 2000 12:47:30 -0400 Received: from dumburken.it.kth.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8999C@standards.nortelnetworks.com>; Fri, 18 Aug 2000 12:47:30 -0400 Received: (from maguire@localhost) by dumburken.it.kth.se (8.9.3/8.9.3) id SAA10172; Fri, 18 Aug 2000 18:59:33 +0200 (MET DST) X-Authentication-Warning: dumburken.it.kth.se: maguire set sender to maguire@dumburken.it.kth.se using -f References: <200008181628.JAA14600@nasnfs.eng.sun.com> Message-ID: <200008181659.SAA10172@dumburken.it.kth.se> Date: Fri, 18 Aug 2000 18:59:33 +0200 Reply-To: Gerald Maguire Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gerald Maguire Subject: Re: [MOBILE-IP] IPv6 handover document X-To: James.Kempf@Eng.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200008181628.JAA14600@nasnfs.eng.sun.com> (message from James Kempf on Fri, 18 Aug 2000 09:33:34 -0700 (PDT)) "Hesham Soliman (EPA)" ask about WLAN and CDMA terminals. Thus my response was largely directed to the WLAN and CDMA markets, in the WLAN case these systems primarily use licensed equipment rather than license spectrum -- so it is manufacturing costs which is the major issue not the license fee for allocated spectrum. Many existing CDMA cellular systems do in fact use spectrum for "house keeping" - witness the pilot channel used by Qualcomm's systems. As I noted, if you just wanted to indicate the presence of an access point (i.e., offer service) -- you need very very little bandwidth for this channel, so in the case of CDMA you can use long codes and therefore you present little interference to the revenue producing use of your spectrum. In defense of this other traffic, it should be noted that even in GSM systems each operator uses a control channel which has in most cases very little traffic going over it {this is why it is possible to carry some amount of SMS messages on this channel}. Of course it is possible to have too much traffic for this channel and thus prevent the full utilization of the other channels which an operator has licensed, but I think this illustrates the problems of having fixed assignments of traffic types to specific channels and the resulting limited ability to multiple (which is not a problem which IP based systems should have). It should also be noted that for many cellular operators there is an advantage of having mobiles able to find a more local means of getting serivce as this removes traffic which has to contend for the larger cell. Of course there are some practical difficulties as some operators have these more local systems under one part of the organization and the cellular group under another. This results in some cases in suboptimal service to the customer. But in general the customer always wins when they can get more local coverage as this in general requires less power for a given amount of data transfer. I think that we are starting to see operators who are recognizing that even when they have licensed spectrum, that providing the service(s) which are necessary to get and keep a large number of customers is a much better business metric than simply maximizing $/MHz/year. I think that one of the very important contributions of mobile IP is to help operators and others to maximize service to customers/users across whatever physical and link layer infrastructures are available. Chip From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Aug 18 13:30:53 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03045 for ; Fri, 18 Aug 2000 13:30:52 -0400 (EDT) Received: from standards (47.234.32.16:4491) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB899E1@standards.nortelnetworks.com>; Fri, 18 Aug 2000 13:18:07 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20610 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 18 Aug 2000 13:18:06 -0400 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB899E0@standards.nortelnetworks.com>; Fri, 18 Aug 2000 13:18:06 -0400 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA04064 for ; Fri, 18 Aug 2000 10:30:09 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.85.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id KAA21790 for ; Fri, 18 Aug 2000 10:30:09 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.0+Sun/8.11.0) with SMTP id e7IHU7K507249 for ; Fri, 18 Aug 2000 10:30:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: kWx+uzOBXPuhDgPK51FoaA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Message-ID: <200008181730.e7IHU7K507249@jurassic.eng.sun.com> Date: Fri, 18 Aug 2000 10:26:46 -0700 Reply-To: Alper Yegin Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Alper Yegin Subject: Re: [MOBILE-IP] IPv6 handover document To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM I was wondering how big is a cell? I'm sure it depends on the technology, vendor, but can I get a range... Thanks. alper Sun Microsystems, Inc. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Aug 18 15:31:42 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06060 for ; Fri, 18 Aug 2000 15:31:41 -0400 (EDT) Received: from standards (47.234.32.16:4491) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB89B28@standards.nortelnetworks.com>; Fri, 18 Aug 2000 15:17:55 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21046 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 18 Aug 2000 15:17:55 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB89B27@standards.nortelnetworks.com>; Fri, 18 Aug 2000 15:17:55 -0400 Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Fri Aug 18 15:28:05 EDT 2000 Received: from king.research.bell-labs.com ([135.1.152.1]) by grubby; Fri Aug 18 15:28:04 EDT 2000 Received: from notmafia.research.bell-labs.com.research.bell-labs.com (notmafia [135.1.152.230]) by king.research.bell-labs.com (Postfix) with SMTP id 2F5BD5701F; Fri, 18 Aug 2000 14:28:03 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <4B6BC00CD15FD2119E5F0008C7A419A5089EB16B@eaubrnt018.epa.ericsson.se> <4.3.2.7.2.20000817093510.00b0f150@il02exm21.comm.mot.com> X-Mailer: VM 6.33 under Emacs 19.34.2 Message-ID: <20000818192803.2F5BD5701F@king.research.bell-labs.com> Date: Fri, 18 Aug 2000 14:28:03 -0500 Reply-To: Pete McCann Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Pete McCann Subject: Re: [MOBILE-IP] IPv6 handover document X-To: John Emmert To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <4.3.2.7.2.20000817093510.00b0f150@il02exm21.comm.mot.com> Content-Transfer-Encoding: 7bit John Emmert (JE) writes: JE> At 05:06 AM 8/17/00, Linfeng Yang wrote: >> We can see this is only local handoff, if accompanied with establishing >> forwarding from a previous care-of address, it can achieve even better >> smoothness. JE> I've seen two solutions to this. Have a FA cover a large geographic area, JE> thus minimizing the need for changing FAs, This is the approach taken by the 3gwireless-ext draft. JE> and have the FA assigned by a JE> lower link layer when boundaries are crossed. I think short term forwarding JE> from a previous FA would be worth investigating. Perhaps a defined interval JE> that if not renewed is automatically flushed? Yes! This is exactly what is proposed in draft-mccann-mobileip-limiph-00.txt. I hope everyone reads it! We take a "transparent" approach where we assume that the link-layer can often help us find the previous FA, and the tunnel is established by the network on behalf of the user. JE> Ping-ponging problems are JE> already handled at the lower layers (or they better be). Unfortunately, the link-layer may provide quite a bit of ping-ponging. We propose to deal with this through appropriate use of the 'S' bit. -Pete From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Aug 18 16:29:02 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06978 for ; Fri, 18 Aug 2000 16:29:01 -0400 (EDT) Received: from standards (47.234.32.16:4491) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB89BBE@standards.nortelnetworks.com>; Fri, 18 Aug 2000 16:16:07 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21250 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 18 Aug 2000 16:16:07 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB89BBD@standards.nortelnetworks.com>; Fri, 18 Aug 2000 16:16:06 -0400 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 NAA07903 for ; Fri, 18 Aug 2000 13:28:13 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e7IKS8m14431 for ; Fri, 18 Aug 2000 13:28:08 -0700 X-Virus-Scanned: Fri, 18 Aug 2000 13:28:08 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdzNCcVj; Fri, 18 Aug 2000 13:27:08 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <399D9C1D.B0FD55F1@iprg.nokia.com> Date: Fri, 18 Aug 2000 13:27:09 -0700 Reply-To: charliep@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: [MOBILE-IP] [Fwd: draft-ietf-mobileip-3gwireless-ext-04.txt] To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello folks, I have sent the following message earlier this afternoon, in an attempt to reopen discussion about the abovementioned Internet Draft which is currently under consideration for Experimental status. Yingchun has informed me that the 3gwireless approach has been implemented as part of the IOS 4.1 standard within CDMA2000. I do not know whether that should affect the discussion at this point in time. Regards, Charlie P. -------- Original Message -------- Subject: draft-ietf-mobileip-3gwireless-ext-04.txt Date: Fri, 18 Aug 2000 13:08:28 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center To: Yingchun_Xu@3com.com, rajesh_bhalla@3com.com,karl_freter@3com.com, ed_campbell@3com.com,mcgrath.hadwen@worldnet.att.net,Gopal Dommety , kjoshi@cisco.com,p.yeqani@ericsson.com, matumura@mcs.ts.fujitsu.co.jp,atsushi_teshima@cm.tcd.hitachi.co.jp, jihs@hei.co.kr,nao-itoh@ido.co.jp, ki-ohki@kdd.co.jp, bklim@lgic.co.kr,mccap@lucent.com, ttowle@lucent.com, jayapal@cig.mot.com,wenzel@nortelnetworks.com, becker@nortelnetworks.com,jjiang@nortelnetworks.com, shikano471@oki.co.jp,keg@telecom.samsung.co.kr, yong@telecom.samsung.co.kr,bsemper@telecom.samsung.com, jmkoo@sktelecom.com,"Lipford, Mark" ,FLerou01@sprintspectrum.com, jgately@uswest.com CC: Tom Hiller ,Phil Roberts ,"Basavaraj Patil (NTC/Dallas)" ,David Oran , Rob Coltun BCC: Pat Calhoun ,James Kempf Hello draft co-authors, >From the discussion below, and after a careful re-reading of the draft, I hope to show that this protocol specification does not at all fit well within the mainstream of work within the mobile-ip working group. I believe that it is actively harmful, because any core network implementing their protocol would find it correspondingly much more difficult to implement "actual" Mobile IP specifications. I say "actual" in quotes because the specifications in question are not yet Proposed Standard, and also because I do not think that the 3gwireless specification fits well in its current formulation nor has it received sufficient working-group review. The first basic problem with the 3G wireless draft is the specification of the Registration Update and the Registration Acknowledgement message types. Neither of them is clearly specified, and to the extent that I understand their purpose, neither one is necessary. The intended results of those messages are done better by use of the Binding Update and Binding Acknowledgement messages which are already specified in the Route Optimization draft. The respecification of the Registration Request draft is also faulty, and exhibits the well-known fallacy of doing the same thing in two different ways. In this particular instance, we see that the alt-Registration Request message has failed to keep up with recent developments regarding the 'V' bit. We can expect this to continue, especially given the strong likelihood that some new Mobile IP developments will involve interactions between the Registration Request message and AAA services. Figuring out when to send an alt-Registration Request will be additionally complicated by the standardization of the upcoming Regional Registration protocol specification, which is currently in Last Call. Another element of confusion is represented by the lack of IP addressability for mobile nodes subordinate to the protocol operations described in the 3gwireless draft. In fact, nowhere in the draft is there any indication that mobile nodes in their system will have IP addresses. Furthermore, mobile nodes in this draft are basically identified by a MN ID field, which is expected to be the same as the mobile node's IMSI. Recent work within the mobile-ip working group has gone in the direction of using the NAI for analogous purposes of allowing a Registration Request to emanate from a mobile node that does not yet have a home address assigned. I would suggest that the 3gwireless draft use the NAI extension instead of their current MN ID. The IMSI is widely expected to show up as data within NAI extensions to Mobile IP registration requests, so this should not cause any problems to the 3gwireless authors. As an example to support my contention that this draft is actively harmful to current work items within the mobile-ip working group, say that a PDSN implements Regional Registrations. This is very likely, given recent discussion. How then would such a PDSN manage its route tables if it ever received a message on port 697? It might be very difficult to figure this out. It would be possible to get messages that required incompatible operations. Similarly, if a mobile node implements smooth handover messages using IPv4 Binding Updates, then there would be a conflict between actions required by the Binding Update message and the port 697 messages. I have numerous other syntactic and editorial comments that I think would need attention before the draft should be considered at all. If need be, I will supply these additional comments. However, before going to that trouble, I think that it is more important to consider the viability of the draft. I hope that the authors of the draft will follow through on their previous agreement to find a better integration strategy with other existing mobile-ip working group drafts, specifically including Route Optimization and Regional Registration. If it is the contention of the 3gwireless authors that the previous drafts are too complicated for their implementation purposes, then we should have the discussion. I have offered to do so, more than once. One possible outcome would be to get simpler drafts for specific protocol features needed by the 3gwireless authors. I note that Nortel Networks had brought some similar concerns to light a couple of years ago, and we reached a beneficial improvement to the Route Optimization draft which allowed the inclusion of multiple correspondent node addresses in the Binding Warning message. I fully expect that we can make similar improvements as needed to the IPv4 Binding Update message for use in the role needed by the authors of the 3gwireless draft. I also note that the name of the draft is misleading. As far as I know, there is no consensus behind this protocol specification within 3GPP or within MWIF. I also do not think there is any consensus behind this protocol within 3GPP2, but I note that several of the listed authors are indeed active within 3GPP2. My guess is that this draft has limited support even there. But either way, it seems very clear to me that the draft should NOT be named in any way to imply that it represents _the_ 3G solution for wireless mobility management. Far from it. Lastly, I note that this draft has attracted almost no discussion within the mobile-ip working group. When I asked several others about it, they said it was because most people generally don't care. But I care. I care because I think it is damaging to the progress of other longstanding mobile-ip working group items. In order to best meet the needs of all parties, I offer my best effort to work with the authors of the 3gwireless draft to make the other drafts meet their needs. I hope this will be sufficient to resolve what could otherwise be a situation causing problems for the future. Sincerely, Charles E. Perkins PS. I regret that I have only now been able to make time for this set of comments. It would have been much better to raise the discussion during working-group last call, but that slipped right by me and was over before I knew it. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Aug 18 16:32:55 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07167 for ; Fri, 18 Aug 2000 16:32:55 -0400 (EDT) Received: from standards (47.234.32.16:4491) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB89BE0@standards.nortelnetworks.com>; Fri, 18 Aug 2000 16:18:40 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21296 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 18 Aug 2000 16:18:40 -0400 Received: from smtpgw1.sprintspectrum.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB89BDE@standards.nortelnetworks.com>; Fri, 18 Aug 2000 16:18:39 -0400 Received: from pkcex003.sprintspectrum.com (pkcex003.sprintspectrum.com [208.10.75.138]) by smtpgw1.sprintspectrum.com (8.9.3/8.9.3) with ESMTP id PAA25951; Fri, 18 Aug 2000 15:30:35 -0500 (CDT) Received: by pkcex003.sprintspectrum.com with Internet Mail Service (5.5.2650.21) id ; Fri, 18 Aug 2000 15:30:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <2D11BCC7FFD8D3118FD70000D1ECDC8802FAE3E6@pkcexv018.sprintspectrum.com> Date: Fri, 18 Aug 2000 15:30:33 -0500 Reply-To: "Lipford, Mark" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Lipford, Mark" Subject: Re: [MOBILE-IP] [Fwd: draft-ietf-mobileip-3gwireless-ext-04.txt] X-To: "charliep@IPRG.NOKIA.COM" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM If has actually been published in IS-2001 and is being developed to (I hope). Mark A. Lipford -----Original Message----- From: Charles E. Perkins [mailto:charliep@IPRG.NOKIA.COM] Sent: Friday, August 18, 2000 3:27 PM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: [MOBILE-IP] [Fwd: draft-ietf-mobileip-3gwireless-ext-04.txt] Hello folks, I have sent the following message earlier this afternoon, in an attempt to reopen discussion about the abovementioned Internet Draft which is currently under consideration for Experimental status. Yingchun has informed me that the 3gwireless approach has been implemented as part of the IOS 4.1 standard within CDMA2000. I do not know whether that should affect the discussion at this point in time. Regards, Charlie P. -------- Original Message -------- Subject: draft-ietf-mobileip-3gwireless-ext-04.txt Date: Fri, 18 Aug 2000 13:08:28 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center To: Yingchun_Xu@3com.com, rajesh_bhalla@3com.com,karl_freter@3com.com, ed_campbell@3com.com,mcgrath.hadwen@worldnet.att.net,Gopal Dommety , kjoshi@cisco.com,p.yeqani@ericsson.com, matumura@mcs.ts.fujitsu.co.jp,atsushi_teshima@cm.tcd.hitachi.co.jp, jihs@hei.co.kr,nao-itoh@ido.co.jp, ki-ohki@kdd.co.jp, bklim@lgic.co.kr,mccap@lucent.com, ttowle@lucent.com, jayapal@cig.mot.com,wenzel@nortelnetworks.com, becker@nortelnetworks.com,jjiang@nortelnetworks.com, shikano471@oki.co.jp,keg@telecom.samsung.co.kr, yong@telecom.samsung.co.kr,bsemper@telecom.samsung.com, jmkoo@sktelecom.com,"Lipford, Mark" ,FLerou01@sprintspectrum.com, jgately@uswest.com CC: Tom Hiller ,Phil Roberts ,"Basavaraj Patil (NTC/Dallas)" ,David Oran , Rob Coltun BCC: Pat Calhoun ,James Kempf Hello draft co-authors, >From the discussion below, and after a careful re-reading of the draft, I hope to show that this protocol specification does not at all fit well within the mainstream of work within the mobile-ip working group. I believe that it is actively harmful, because any core network implementing their protocol would find it correspondingly much more difficult to implement "actual" Mobile IP specifications. I say "actual" in quotes because the specifications in question are not yet Proposed Standard, and also because I do not think that the 3gwireless specification fits well in its current formulation nor has it received sufficient working-group review. The first basic problem with the 3G wireless draft is the specification of the Registration Update and the Registration Acknowledgement message types. Neither of them is clearly specified, and to the extent that I understand their purpose, neither one is necessary. The intended results of those messages are done better by use of the Binding Update and Binding Acknowledgement messages which are already specified in the Route Optimization draft. The respecification of the Registration Request draft is also faulty, and exhibits the well-known fallacy of doing the same thing in two different ways. In this particular instance, we see that the alt-Registration Request message has failed to keep up with recent developments regarding the 'V' bit. We can expect this to continue, especially given the strong likelihood that some new Mobile IP developments will involve interactions between the Registration Request message and AAA services. Figuring out when to send an alt-Registration Request will be additionally complicated by the standardization of the upcoming Regional Registration protocol specification, which is currently in Last Call. Another element of confusion is represented by the lack of IP addressability for mobile nodes subordinate to the protocol operations described in the 3gwireless draft. In fact, nowhere in the draft is there any indication that mobile nodes in their system will have IP addresses. Furthermore, mobile nodes in this draft are basically identified by a MN ID field, which is expected to be the same as the mobile node's IMSI. Recent work within the mobile-ip working group has gone in the direction of using the NAI for analogous purposes of allowing a Registration Request to emanate from a mobile node that does not yet have a home address assigned. I would suggest that the 3gwireless draft use the NAI extension instead of their current MN ID. The IMSI is widely expected to show up as data within NAI extensions to Mobile IP registration requests, so this should not cause any problems to the 3gwireless authors. As an example to support my contention that this draft is actively harmful to current work items within the mobile-ip working group, say that a PDSN implements Regional Registrations. This is very likely, given recent discussion. How then would such a PDSN manage its route tables if it ever received a message on port 697? It might be very difficult to figure this out. It would be possible to get messages that required incompatible operations. Similarly, if a mobile node implements smooth handover messages using IPv4 Binding Updates, then there would be a conflict between actions required by the Binding Update message and the port 697 messages. I have numerous other syntactic and editorial comments that I think would need attention before the draft should be considered at all. If need be, I will supply these additional comments. However, before going to that trouble, I think that it is more important to consider the viability of the draft. I hope that the authors of the draft will follow through on their previous agreement to find a better integration strategy with other existing mobile-ip working group drafts, specifically including Route Optimization and Regional Registration. If it is the contention of the 3gwireless authors that the previous drafts are too complicated for their implementation purposes, then we should have the discussion. I have offered to do so, more than once. One possible outcome would be to get simpler drafts for specific protocol features needed by the 3gwireless authors. I note that Nortel Networks had brought some similar concerns to light a couple of years ago, and we reached a beneficial improvement to the Route Optimization draft which allowed the inclusion of multiple correspondent node addresses in the Binding Warning message. I fully expect that we can make similar improvements as needed to the IPv4 Binding Update message for use in the role needed by the authors of the 3gwireless draft. I also note that the name of the draft is misleading. As far as I know, there is no consensus behind this protocol specification within 3GPP or within MWIF. I also do not think there is any consensus behind this protocol within 3GPP2, but I note that several of the listed authors are indeed active within 3GPP2. My guess is that this draft has limited support even there. But either way, it seems very clear to me that the draft should NOT be named in any way to imply that it represents _the_ 3G solution for wireless mobility management. Far from it. Lastly, I note that this draft has attracted almost no discussion within the mobile-ip working group. When I asked several others about it, they said it was because most people generally don't care. But I care. I care because I think it is damaging to the progress of other longstanding mobile-ip working group items. In order to best meet the needs of all parties, I offer my best effort to work with the authors of the 3gwireless draft to make the other drafts meet their needs. I hope this will be sufficient to resolve what could otherwise be a situation causing problems for the future. Sincerely, Charles E. Perkins PS. I regret that I have only now been able to make time for this set of comments. It would have been much better to raise the discussion during working-group last call, but that slipped right by me and was over before I knew it. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Aug 18 16:43:36 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07356 for ; Fri, 18 Aug 2000 16:43:35 -0400 (EDT) Received: from standards (47.234.32.16:4491) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB89C44@standards.nortelnetworks.com>; Fri, 18 Aug 2000 16:30:49 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21432 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 18 Aug 2000 16:30:49 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB89C43@standards.nortelnetworks.com>; Fri, 18 Aug 2000 16:30:49 -0400 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA26315; Fri, 18 Aug 2000 14:42:52 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA04279; Fri, 18 Aug 2000 13:42:47 -0700 (PDT) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id NAA20967; Fri, 18 Aug 2000 13:42:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Fri, 18 Aug 2000 13:41:15 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: Re: [MOBILE-IP] [Fwd: draft-ietf-mobileip-3gwireless-ext-04.txt] X-To: "Lipford, Mark" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <2D11BCC7FFD8D3118FD70000D1ECDC8802FAE3E6@pkcexv018.sprintspectrum.com> > If has actually been published in IS-2001 and is being developed to (I > hope). How could it have been published, without an RFC number, given that the document would surely be a normative reference? PatC > > Mark A. Lipford > > > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@IPRG.NOKIA.COM] > Sent: Friday, August 18, 2000 3:27 PM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: [MOBILE-IP] [Fwd: > draft-ietf-mobileip-3gwireless-ext-04.txt] > > Hello folks, > > I have sent the following message earlier this afternoon, in > an > attempt to reopen discussion about the abovementioned > Internet > Draft which is currently under consideration for > Experimental status. > > Yingchun has informed me that the 3gwireless approach has > been > implemented as part of the IOS 4.1 standard within CDMA2000. > I do not know whether that should affect the discussion at > this > point in time. > > Regards, > Charlie P. > > > -------- Original Message -------- > Subject: draft-ietf-mobileip-3gwireless-ext-04.txt > Date: Fri, 18 Aug 2000 13:08:28 -0700 > From: "Charles E. Perkins" > Organization: Nokia Research Center > To: Yingchun_Xu@3com.com, > rajesh_bhalla@3com.com,karl_freter@3com.com, > ed_campbell@3com.com,mcgrath.hadwen@worldnet.att.net,Gopal > Dommety > , > kjoshi@cisco.com,p.yeqani@ericsson.com, > > matumura@mcs.ts.fujitsu.co.jp,atsushi_teshima@cm.tcd.hitachi.co.jp, > jihs@hei.co.kr,nao-itoh@ido.co.jp, ki-ohki@kdd.co.jp, > bklim@lgic.co.kr,mccap@lucent.com, ttowle@lucent.com, > jayapal@cig.mot.com,wenzel@nortelnetworks.com, > becker@nortelnetworks.com,jjiang@nortelnetworks.com, > shikano471@oki.co.jp,keg@telecom.samsung.co.kr, > yong@telecom.samsung.co.kr,bsemper@telecom.samsung.com, > jmkoo@sktelecom.com,"Lipford, Mark" > ,FLerou01@sprintspectrum.com, > jgately@uswest.com > CC: Tom Hiller ,Phil Roberts > ,"Basavaraj Patil (NTC/Dallas)" > ,David Oran , Rob > Coltun > > BCC: Pat Calhoun ,James Kempf > > > > Hello draft co-authors, > > >From the discussion below, and after a careful re-reading > of the draft, > I hope to show that this protocol specification does not at > all fit > well within the mainstream of work within the mobile-ip > working group. > I believe that it is actively harmful, because any core > network > implementing their protocol would find it correspondingly > much more > difficult to implement "actual" Mobile IP specifications. I > say > "actual" in quotes because the specifications in question > are not > yet Proposed Standard, and also because I do not think that > the > 3gwireless specification fits well in its current > formulation nor > has it received sufficient working-group review. > > The first basic problem with the 3G wireless draft is the > specification > of the Registration Update and the Registration > Acknowledgement > message types. Neither of them is clearly specified, and to > the > extent that I understand their purpose, neither one is > necessary. > The intended results of those messages are done better by > use of > the Binding Update and Binding Acknowledgement messages > which are > already specified in the Route Optimization draft. > > The respecification of the Registration Request draft is > also > faulty, and exhibits the well-known fallacy of doing the > same > thing in two different ways. In this particular instance, > we > see that the alt-Registration Request message has failed to > keep > up with recent developments regarding the 'V' bit. We can > expect > this to continue, especially given the strong likelihood > that > some new Mobile IP developments will involve interactions > between > the Registration Request message and AAA services. > > Figuring out when to send an alt-Registration Request will > be > additionally complicated by the standardization of the > upcoming > Regional Registration protocol specification, which is > currently > in Last Call. > > Another element of confusion is represented by the lack of > IP addressability for mobile nodes subordinate to the > protocol > operations described in the 3gwireless draft. In fact, > nowhere > in the draft is there any indication that mobile nodes in > their > system will have IP addresses. Furthermore, mobile nodes in > this draft are basically identified by a MN ID field, which > is > expected to be the same as the mobile node's IMSI. Recent > work > within the mobile-ip working group has gone in the direction > of > using the NAI for analogous purposes of allowing a > Registration > Request to emanate from a mobile node that does not yet have > a home address assigned. I would suggest that the > 3gwireless > draft use the NAI extension instead of their current MN ID. > The IMSI is widely expected to show up as data within NAI > extensions to Mobile IP registration requests, so this > should > not cause any problems to the 3gwireless authors. > > As an example to support my contention that this draft is > actively > harmful to current work items within the mobile-ip working > group, > say that a PDSN implements Regional Registrations. This is > very > likely, given recent discussion. How then would such a PDSN > manage > its route tables if it ever received a message on port 697? > It might be very difficult to figure this out. It would be > possible to get messages that required incompatible > operations. > > Similarly, if a mobile node implements smooth handover > messages > using IPv4 Binding Updates, then there would be a conflict > between > actions required by the Binding Update message and the port > 697 > messages. > > I have numerous other syntactic and editorial comments that > I > think would need attention before the draft should be > considered > at all. If need be, I will supply these additional > comments. > However, before going to that trouble, I think that it is > more > important to consider the viability of the draft. I hope > that the > authors of the draft will follow through on their previous > agreement > to find a better integration strategy with other existing > mobile-ip > working group drafts, specifically including Route > Optimization and > Regional Registration. If it is the contention of the > 3gwireless > authors that the previous drafts are too complicated for > their > implementation purposes, then we should have the discussion. > I have offered to do so, more than once. One possible > outcome > would be to get simpler drafts for specific protocol > features > needed by the 3gwireless authors. > > I note that Nortel Networks had brought some similar > concerns to > light a couple of years ago, and we reached a beneficial > improvement > to the Route Optimization draft which allowed the inclusion > of > multiple correspondent node addresses in the Binding Warning > message. I fully expect that we can make similar > improvements > as needed to the IPv4 Binding Update message for use in the > role needed by the authors of the 3gwireless draft. > > I also note that the name of the draft is misleading. As > far as > I know, there is no consensus behind this protocol > specification > within 3GPP or within MWIF. I also do not think there is > any > consensus behind this protocol within 3GPP2, but I note that > several of the listed authors are indeed active within > 3GPP2. > My guess is that this draft has limited support even there. > But > either way, it seems very clear to me that the draft should > NOT > be named in any way to imply that it represents _the_ 3G > solution > for wireless mobility management. Far from it. > > Lastly, I note that this draft has attracted almost no > discussion > within the mobile-ip working group. When I asked several > others > about it, they said it was because most people generally > don't care. > But I care. I care because I think it is damaging to the > progress of > other longstanding mobile-ip working group items. In order > to best > meet the needs of all parties, I offer my best effort to > work with > the authors of the 3gwireless draft to make the other drafts > meet > their needs. I hope this will be sufficient to resolve what > could > otherwise be a situation causing problems for the future. > > Sincerely, > Charles E. Perkins > > PS. I regret that I have only now been able to make time for > this > set of comments. It would have been much better to > raise the > discussion during working-group last call, but that > slipped > right by me and was over before I knew it. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Aug 18 16:55:31 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07615 for ; Fri, 18 Aug 2000 16:55:30 -0400 (EDT) Received: from standards (47.234.32.16:4491) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB89C90@standards.nortelnetworks.com>; Fri, 18 Aug 2000 16:42:37 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21538 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 18 Aug 2000 16:42:37 -0400 Received: from smtpgw1.sprintspectrum.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB89C8F@standards.nortelnetworks.com>; Fri, 18 Aug 2000 16:42:36 -0400 Received: from pkcex003.sprintspectrum.com (pkcex003.sprintspectrum.com [208.10.75.138]) by smtpgw1.sprintspectrum.com (8.9.3/8.9.3) with ESMTP id PAA04770 for ; Fri, 18 Aug 2000 15:54:43 -0500 (CDT) Received: by pkcex003.sprintspectrum.com with Internet Mail Service (5.5.2650.21) id ; Fri, 18 Aug 2000 15:54:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <2D11BCC7FFD8D3118FD70000D1ECDC8802FAE3E8@pkcexv018.sprintspectrum.com> Date: Fri, 18 Aug 2000 15:54:39 -0500 Reply-To: "Lipford, Mark" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Lipford, Mark" Subject: Re: [MOBILE-IP] [Fwd: draft-ietf-mobileip-3gwireless-ext-04.txt] To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM The specific procedures were put into IS-2001. The I-D was to "standardize" these procedures in the IETF. This is similar to work that another TR45 group considered doing with another protocol, but decided against. Mark A. Lipford -----Original Message----- From: pcalhoun@eng.sun.com [mailto:Pat.Calhoun@Eng.Sun.COM] Sent: Friday, August 18, 2000 3:41 PM To: Lipford, Mark Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] [Fwd: draft-ietf-mobileip-3gwireless-ext-04.txt] > If has actually been published in IS-2001 and is being developed to (I > hope). How could it have been published, without an RFC number, given that the document would surely be a normative reference? PatC > > Mark A. Lipford > > > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@IPRG.NOKIA.COM] > Sent: Friday, August 18, 2000 3:27 PM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: [MOBILE-IP] [Fwd: > draft-ietf-mobileip-3gwireless-ext-04.txt] > > Hello folks, > > I have sent the following message earlier this afternoon, in > an > attempt to reopen discussion about the abovementioned > Internet > Draft which is currently under consideration for > Experimental status. > > Yingchun has informed me that the 3gwireless approach has > been > implemented as part of the IOS 4.1 standard within CDMA2000. > I do not know whether that should affect the discussion at > this > point in time. > > Regards, > Charlie P. > > > -------- Original Message -------- > Subject: draft-ietf-mobileip-3gwireless-ext-04.txt > Date: Fri, 18 Aug 2000 13:08:28 -0700 > From: "Charles E. Perkins" > Organization: Nokia Research Center > To: Yingchun_Xu@3com.com, > rajesh_bhalla@3com.com,karl_freter@3com.com, > ed_campbell@3com.com,mcgrath.hadwen@worldnet.att.net,Gopal > Dommety > , > kjoshi@cisco.com,p.yeqani@ericsson.com, > > matumura@mcs.ts.fujitsu.co.jp,atsushi_teshima@cm.tcd.hitachi.co.jp, > jihs@hei.co.kr,nao-itoh@ido.co.jp, ki-ohki@kdd.co.jp, > bklim@lgic.co.kr,mccap@lucent.com, ttowle@lucent.com, > jayapal@cig.mot.com,wenzel@nortelnetworks.com, > becker@nortelnetworks.com,jjiang@nortelnetworks.com, > shikano471@oki.co.jp,keg@telecom.samsung.co.kr, > yong@telecom.samsung.co.kr,bsemper@telecom.samsung.com, > jmkoo@sktelecom.com,"Lipford, Mark" > ,FLerou01@sprintspectrum.com, > jgately@uswest.com > CC: Tom Hiller ,Phil Roberts > ,"Basavaraj Patil (NTC/Dallas)" > ,David Oran , Rob > Coltun > > BCC: Pat Calhoun ,James Kempf > > > > Hello draft co-authors, > > >From the discussion below, and after a careful re-reading > of the draft, > I hope to show that this protocol specification does not at > all fit > well within the mainstream of work within the mobile-ip > working group. > I believe that it is actively harmful, because any core > network > implementing their protocol would find it correspondingly > much more > difficult to implement "actual" Mobile IP specifications. I > say > "actual" in quotes because the specifications in question > are not > yet Proposed Standard, and also because I do not think that > the > 3gwireless specification fits well in its current > formulation nor > has it received sufficient working-group review. > > The first basic problem with the 3G wireless draft is the > specification > of the Registration Update and the Registration > Acknowledgement > message types. Neither of them is clearly specified, and to > the > extent that I understand their purpose, neither one is > necessary. > The intended results of those messages are done better by > use of > the Binding Update and Binding Acknowledgement messages > which are > already specified in the Route Optimization draft. > > The respecification of the Registration Request draft is > also > faulty, and exhibits the well-known fallacy of doing the > same > thing in two different ways. In this particular instance, > we > see that the alt-Registration Request message has failed to > keep > up with recent developments regarding the 'V' bit. We can > expect > this to continue, especially given the strong likelihood > that > some new Mobile IP developments will involve interactions > between > the Registration Request message and AAA services. > > Figuring out when to send an alt-Registration Request will > be > additionally complicated by the standardization of the > upcoming > Regional Registration protocol specification, which is > currently > in Last Call. > > Another element of confusion is represented by the lack of > IP addressability for mobile nodes subordinate to the > protocol > operations described in the 3gwireless draft. In fact, > nowhere > in the draft is there any indication that mobile nodes in > their > system will have IP addresses. Furthermore, mobile nodes in > this draft are basically identified by a MN ID field, which > is > expected to be the same as the mobile node's IMSI. Recent > work > within the mobile-ip working group has gone in the direction > of > using the NAI for analogous purposes of allowing a > Registration > Request to emanate from a mobile node that does not yet have > a home address assigned. I would suggest that the > 3gwireless > draft use the NAI extension instead of their current MN ID. > The IMSI is widely expected to show up as data within NAI > extensions to Mobile IP registration requests, so this > should > not cause any problems to the 3gwireless authors. > > As an example to support my contention that this draft is > actively > harmful to current work items within the mobile-ip working > group, > say that a PDSN implements Regional Registrations. This is > very > likely, given recent discussion. How then would such a PDSN > manage > its route tables if it ever received a message on port 697? > It might be very difficult to figure this out. It would be > possible to get messages that required incompatible > operations. > > Similarly, if a mobile node implements smooth handover > messages > using IPv4 Binding Updates, then there would be a conflict > between > actions required by the Binding Update message and the port > 697 > messages. > > I have numerous other syntactic and editorial comments that > I > think would need attention before the draft should be > considered > at all. If need be, I will supply these additional > comments. > However, before going to that trouble, I think that it is > more > important to consider the viability of the draft. I hope > that the > authors of the draft will follow through on their previous > agreement > to find a better integration strategy with other existing > mobile-ip > working group drafts, specifically including Route > Optimization and > Regional Registration. If it is the contention of the > 3gwireless > authors that the previous drafts are too complicated for > their > implementation purposes, then we should have the discussion. > I have offered to do so, more than once. One possible > outcome > would be to get simpler drafts for specific protocol > features > needed by the 3gwireless authors. > > I note that Nortel Networks had brought some similar > concerns to > light a couple of years ago, and we reached a beneficial > improvement > to the Route Optimization draft which allowed the inclusion > of > multiple correspondent node addresses in the Binding Warning > message. I fully expect that we can make similar > improvements > as needed to the IPv4 Binding Update message for use in the > role needed by the authors of the 3gwireless draft. > > I also note that the name of the draft is misleading. As > far as > I know, there is no consensus behind this protocol > specification > within 3GPP or within MWIF. I also do not think there is > any > consensus behind this protocol within 3GPP2, but I note that > several of the listed authors are indeed active within > 3GPP2. > My guess is that this draft has limited support even there. > But > either way, it seems very clear to me that the draft should > NOT > be named in any way to imply that it represents _the_ 3G > solution > for wireless mobility management. Far from it. > > Lastly, I note that this draft has attracted almost no > discussion > within the mobile-ip working group. When I asked several > others > about it, they said it was because most people generally > don't care. > But I care. I care because I think it is damaging to the > progress of > other longstanding mobile-ip working group items. In order > to best > meet the needs of all parties, I offer my best effort to > work with > the authors of the 3gwireless draft to make the other drafts > meet > their needs. I hope this will be sufficient to resolve what > could > otherwise be a situation causing problems for the future. > > Sincerely, > Charles E. Perkins > > PS. I regret that I have only now been able to make time for > this > set of comments. It would have been much better to > raise the > discussion during working-group last call, but that > slipped > right by me and was over before I knew it. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Aug 18 18:37:24 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09705 for ; Fri, 18 Aug 2000 18:37:23 -0400 (EDT) Received: from standards (47.234.32.16:3086) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB89D47@standards.nortelnetworks.com>; Fri, 18 Aug 2000 18:24:18 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21777 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 18 Aug 2000 18:24:18 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB89D46@standards.nortelnetworks.com>; Fri, 18 Aug 2000 18:24:17 -0400 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA24999; Fri, 18 Aug 2000 16:36:22 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA03917; Fri, 18 Aug 2000 15:36:09 -0700 (PDT) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id PAA23953; Fri, 18 Aug 2000 15:36:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Fri, 18 Aug 2000 15:34:37 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: Re: [MOBILE-IP] [Fwd: draft-ietf-mobileip-3gwireless-ext-04.txt] X-To: Yingchun_Xu@3com.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <8825693F.007BC419.00@hqoutbound.ops.3com.com> Ah, then why waste IETF resources? You can easily go to IANA and request the numbers that you need. PatC > > > Pat, > Well, the experience from TIA TR45.6 working group has tought us a lesson. > Intead of referenceing the draft, we have copied the whole content of the > draft into the IOS4.1 standard. > > --Yingchun > > > > > "pcalhoun/@eng.sun.com" > Please respond to "pcalhoun@eng.sun.com" > > Sent by: "pcalhoun@eng.sun.com" > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > cc: (Yingchun Xu/MW/US/3Com) > Subject: Re: [MOBILE-IP] [Fwd: draft-ietf-mobileip-3gwireless-ext-04.txt] > > > > > If has actually been published in IS-2001 and is being developed to (I > > hope). > > How could it have been published, without an RFC number, given that the > document would surely be a normative reference? > > PatC > > > > Mark A. Lipford > > > > > > -----Original Message----- > > From: Charles E. Perkins [mailto:charliep@IPRG.NOKIA.COM] > > Sent: Friday, August 18, 2000 3:27 PM > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > Subject: [MOBILE-IP] [Fwd: > > draft-ietf-mobileip-3gwireless-ext-04.txt] > > > > Hello folks, > > > > I have sent the following message earlier this afternoon, in > > an > > attempt to reopen discussion about the abovementioned > > Internet > > Draft which is currently under consideration for > > Experimental status. > > > > Yingchun has informed me that the 3gwireless approach has > > been > > implemented as part of the IOS 4.1 standard within CDMA2000. > > I do not know whether that should affect the discussion at > > this > > point in time. > > > > Regards, > > Charlie P. > > > > > > -------- Original Message -------- > > Subject: draft-ietf-mobileip-3gwireless-ext-04.txt > > Date: Fri, 18 Aug 2000 13:08:28 -0700 > > From: "Charles E. Perkins" > > Organization: Nokia Research Center > > To: Yingchun_Xu@3com.com, > > rajesh_bhalla@3com.com,karl_freter@3com.com, > > ed_campbell@3com.com,mcgrath.hadwen@worldnet.att.net,Gopal > > Dommety > > , > > kjoshi@cisco.com,p.yeqani@ericsson.com, > > > > matumura@mcs.ts.fujitsu.co.jp,atsushi_teshima@cm.tcd.hitachi.co.jp, > > jihs@hei.co.kr,nao-itoh@ido.co.jp, ki-ohki@kdd.co.jp, > > bklim@lgic.co.kr,mccap@lucent.com, ttowle@lucent.com, > > jayapal@cig.mot.com,wenzel@nortelnetworks.com, > > becker@nortelnetworks.com,jjiang@nortelnetworks.com, > > shikano471@oki.co.jp,keg@telecom.samsung.co.kr, > > yong@telecom.samsung.co.kr,bsemper@telecom.samsung.com, > > jmkoo@sktelecom.com,"Lipford, Mark" > > ,FLerou01@sprintspectrum.com, > > jgately@uswest.com > > CC: Tom Hiller ,Phil Roberts > > ,"Basavaraj Patil (NTC/Dallas)" > > ,David Oran , Rob > > Coltun > > > > BCC: Pat Calhoun ,James Kempf > > > > > > > > Hello draft co-authors, > > > > >From the discussion below, and after a careful re-reading > > of the draft, > > I hope to show that this protocol specification does not at > > all fit > > well within the mainstream of work within the mobile-ip > > working group. > > I believe that it is actively harmful, because any core > > network > > implementing their protocol would find it correspondingly > > much more > > difficult to implement "actual" Mobile IP specifications. I > > say > > "actual" in quotes because the specifications in question > > are not > > yet Proposed Standard, and also because I do not think that > > the > > 3gwireless specification fits well in its current > > formulation nor > > has it received sufficient working-group review. > > > > The first basic problem with the 3G wireless draft is the > > specification > > of the Registration Update and the Registration > > Acknowledgement > > message types. Neither of them is clearly specified, and to > > the > > extent that I understand their purpose, neither one is > > necessary. > > The intended results of those messages are done better by > > use of > > the Binding Update and Binding Acknowledgement messages > > which are > > already specified in the Route Optimization draft. > > > > The respecification of the Registration Request draft is > > also > > faulty, and exhibits the well-known fallacy of doing the > > same > > thing in two different ways. In this particular instance, > > we > > see that the alt-Registration Request message has failed to > > keep > > up with recent developments regarding the 'V' bit. We can > > expect > > this to continue, especially given the strong likelihood > > that > > some new Mobile IP developments will involve interactions > > between > > the Registration Request message and AAA services. > > > > Figuring out when to send an alt-Registration Request will > > be > > additionally complicated by the standardization of the > > upcoming > > Regional Registration protocol specification, which is > > currently > > in Last Call. > > > > Another element of confusion is represented by the lack of > > IP addressability for mobile nodes subordinate to the > > protocol > > operations described in the 3gwireless draft. In fact, > > nowhere > > in the draft is there any indication that mobile nodes in > > their > > system will have IP addresses. Furthermore, mobile nodes in > > this draft are basically identified by a MN ID field, which > > is > > expected to be the same as the mobile node's IMSI. Recent > > work > > within the mobile-ip working group has gone in the direction > > of > > using the NAI for analogous purposes of allowing a > > Registration > > Request to emanate from a mobile node that does not yet have > > a home address assigned. I would suggest that the > > 3gwireless > > draft use the NAI extension instead of their current MN ID. > > The IMSI is widely expected to show up as data within NAI > > extensions to Mobile IP registration requests, so this > > should > > not cause any problems to the 3gwireless authors. > > > > As an example to support my contention that this draft is > > actively > > harmful to current work items within the mobile-ip working > > group, > > say that a PDSN implements Regional Registrations. This is > > very > > likely, given recent discussion. How then would such a PDSN > > manage > > its route tables if it ever received a message on port 697? > > It might be very difficult to figure this out. It would be > > possible to get messages that required incompatible > > operations. > > > > Similarly, if a mobile node implements smooth handover > > messages > > using IPv4 Binding Updates, then there would be a conflict > > between > > actions required by the Binding Update message and the port > > 697 > > messages. > > > > I have numerous other syntactic and editorial comments that > > I > > think would need attention before the draft should be > > considered > > at all. If need be, I will supply these additional > > comments. > > However, before going to that trouble, I think that it is > > more > > important to consider the viability of the draft. I hope > > that the > > authors of the draft will follow through on their previous > > agreement > > to find a better integration strategy with other existing > > mobile-ip > > working group drafts, specifically including Route > > Optimization and > > Regional Registration. If it is the contention of the > > 3gwireless > > authors that the previous drafts are too complicated for > > their > > implementation purposes, then we should have the discussion. > > I have offered to do so, more than once. One possible > > outcome > > would be to get simpler drafts for specific protocol > > features > > needed by the 3gwireless authors. > > > > I note that Nortel Networks had brought some similar > > concerns to > > light a couple of years ago, and we reached a beneficial > > improvement > > to the Route Optimization draft which allowed the inclusion > > of > > multiple correspondent node addresses in the Binding Warning > > message. I fully expect that we can make similar > > improvements > > as needed to the IPv4 Binding Update message for use in the > > role needed by the authors of the 3gwireless draft. > > > > I also note that the name of the draft is misleading. As > > far as > > I know, there is no consensus behind this protocol > > specification > > within 3GPP or within MWIF. I also do not think there is > > any > > consensus behind this protocol within 3GPP2, but I note that > > several of the listed authors are indeed active within > > 3GPP2. > > My guess is that this draft has limited support even there. > > But > > either way, it seems very clear to me that the draft should > > NOT > > be named in any way to imply that it represents _the_ 3G > > solution > > for wireless mobility management. Far from it. > > > > Lastly, I note that this draft has attracted almost no > > discussion > > within the mobile-ip working group. When I asked several > > others > > about it, they said it was because most people generally > > don't care. > > But I care. I care because I think it is damaging to the > > progress of > > other longstanding mobile-ip working group items. In order > > to best > > meet the needs of all parties, I offer my best effort to > > work with > > the authors of the 3gwireless draft to make the other drafts > > meet > > their needs. I hope this will be sufficient to resolve what > > could > > otherwise be a situation causing problems for the future. > > > > Sincerely, > > Charles E. Perkins > > > > PS. I regret that I have only now been able to make time for > > this > > set of comments. It would have been much better to > > raise the > > discussion during working-group last call, but that > > slipped > > right by me and was over before I knew it. > > > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Aug 18 18:37:25 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09708 for ; Fri, 18 Aug 2000 18:37:24 -0400 (EDT) Received: from standards (47.234.32.16:3086) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB89D51@standards.nortelnetworks.com>; Fri, 18 Aug 2000 18:24:37 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21775 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 18 Aug 2000 18:24:37 -0400 Received: from topaz.3com.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB89D44@standards.nortelnetworks.com>; Fri, 18 Aug 2000 18:14:36 -0400 Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e7IMQbs06012; Fri, 18 Aug 2000 15:26:37 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id e7IMQg908602; Fri, 18 Aug 2000 15:26:42 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 8825693F.007B43A4 ; Fri, 18 Aug 2000 15:26:22 -0700 X-Lotus-FromDomain: 3COM Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <8825693F.007B4092.00@hqoutbound.ops.3com.com> Date: Fri, 18 Aug 2000 17:28:42 -0500 Reply-To: Yingchun_Xu@3COM.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Yingchun_Xu@3COM.COM Subject: Re: [MOBILE-IP] draft-ietf-mobileip-3gwireless-ext-04.txt X-To: charliep@IPRG.NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Charles, I wish we could have received your comments ealier. The proposed Mobile IP extension has been implemented in cdma2000 standard and it is very hard to change. I agreed with Pete that we should stick to the current format. The points you have made in your email are mostly not hold because of your misunderstanding of the draft (see Pete's response below). The method proposed in the draft is mainly used for the mobility management between RNN and PDSN and it is transparent to the upper layer Mobile IP. As the matter of fact, the proposed method was approved by 3GPP2 and it represents 3GPP2. ---Yingchun. Pete McCann on 08/18/2000 04:28:51 PM Sent by: Pete McCann To: "Charles E. Perkins" cc: See Below Subject: draft-ietf-mobileip-3gwireless-ext-04.txt Charles, I was quite disheartened to see your message below. While the comments come rather late in the process, they also reflect a pretty serious misunderstanding of both the intent and some of the technical details of the draft. While you raise some points that are valid, I think you have missed the role this draft is intending to play in the network and its potential interactions with other emerging Mobile IP standards. Let me try to address your concerns one at a time. "Charles E. Perkins" (CEP) writes: CEP> Hello draft co-authors, CEP> From the discussion below, and after a careful re-reading of the draft, CEP> I hope to show that this protocol specification does not at all fit CEP> well within the mainstream of work within the mobile-ip working group. CEP> I believe that it is actively harmful, because any core network CEP> implementing their protocol would find it correspondingly much more CEP> difficult to implement "actual" Mobile IP specifications. I say CEP> "actual" in quotes because the specifications in question are not CEP> yet Proposed Standard, and also because I do not think that the CEP> 3gwireless specification fits well in its current formulation nor CEP> has it received sufficient working-group review. Implementations of 3gwireless should have no trouble co-existing with any current or proposed Mobile IP extensions. I hope the further discussion below will clarify this. CEP> The first basic problem with the 3G wireless draft is the specification CEP> of the Registration Update and the Registration Acknowledgement CEP> message types. Neither of them is clearly specified, and to the CEP> extent that I understand their purpose, neither one is necessary. CEP> The intended results of those messages are done better by use of CEP> the Binding Update and Binding Acknowledgement messages which are CEP> already specified in the Route Optimization draft. Whether to use the Binding Update messages was discussed several times, and a number of us went back and forth on this issue. If this were your only problem with the draft, I'm sure it could be changed to use Binding Updates, as long as they carry the Session-Specific Extension. However, this would disrupt some ongoing implementation efforts and I do not see that the change is really warranted. CEP> The respecification of the Registration Request draft is also CEP> faulty, and exhibits the well-known fallacy of doing the same CEP> thing in two different ways. In this particular instance, we CEP> see that the alt-Registration Request message has failed to keep CEP> up with recent developments regarding the 'V' bit. We can expect CEP> this to continue, especially given the strong likelihood that CEP> some new Mobile IP developments will involve interactions between CEP> the Registration Request message and AAA services. The draft was not intended as a re-specification of the Mobile IP Registration Request message. It was designed to be used intact from RFC 2002, and I believe the format was only included here for reference. I'm sure Yingchun would be happy to remove the 'V' bit so as to conform with 2002-bis, but this is a really minor point. The basic Registration Request message format should eventually stabilize in an RFC (we were working with 2002 at the time) and any changes will then be accommodated with the Mobile IP extension mechanism. Do you foresee any other changes to the Registration Request message? CEP> Figuring out when to send an alt-Registration Request will be CEP> additionally complicated by the standardization of the upcoming CEP> Regional Registration protocol specification, which is currently CEP> in Last Call. This is the point at which I think you have misunderstood the purpose of the draft. The 3gwireless protocol is designed to be used between an RNN and a PDSN, for establishing a tunnel over which the MN's data will be sent. It is established in response to a link-layer connection event and NOT in response to any IP-layer message sent by the MN. This is very important, because it was decided a long time ago in 3GPP2 that we cannot afford to bring up a traffic channel for sending IP packets every time the MN changes its RNN - that should be done only when changing PDSNs. This has the effect of making the PDSN the first-hop IP point of attachment: the whole R-P interface is just one logical link according to the IP stack on the MN. This degree of transparency is important for two reasons: one, to reduce the burden on the traffic channels, as above, but also two, to provide some "limited mobility support" to MNs that do not even possess Mobile IP client code. For this very reason, the draft will never interact with any new features proposed for Mobile IP - they are always a matter of the MIP client interacting with its first-hop router. CEP> Another element of confusion is represented by the lack of CEP> IP addressability for mobile nodes subordinate to the protocol CEP> operations described in the 3gwireless draft. In fact, nowhere CEP> in the draft is there any indication that mobile nodes in their CEP> system will have IP addresses. The draft defines an interface between RNNs and PDSNs - that is all. It does not specify what the MN is allowed to do once it is connected to the PDSN; that is properly the subject of other work in the Mobile IP WG. Even though the draft does not standardize any aspect of MN behavior, we felt it was important to specify this interface in the IETF because the RNN and PDSN will share an IP network and the IETF is the best possible place to get feedback, exposure, and consensus for this interface. This is a perfectly proper role for an Experimental RFC to play. CEP> Furthermore, mobile nodes in CEP> this draft are basically identified by a MN ID field, which is CEP> expected to be the same as the mobile node's IMSI. Recent work CEP> within the mobile-ip working group has gone in the direction of CEP> using the NAI for analogous purposes of allowing a Registration CEP> Request to emanate from a mobile node that does not yet have CEP> a home address assigned. I would suggest that the 3gwireless CEP> draft use the NAI extension instead of their current MN ID. CEP> The IMSI is widely expected to show up as data within NAI CEP> extensions to Mobile IP registration requests, so this should CEP> not cause any problems to the 3gwireless authors. As I said, the R-P interface runs as a side-effect of link establishment, before *any* IP packets are received from the MN. As such we do not know the NAI that the client may later use when sending an actual Mobile IP Registration Request, but we do have a link-layer identifier (which in our case has been properly authenticated by means outside the scope of Mobile IP). This identifier is included in an extension to allow the PDSN to perform handoff without receiving any IP packets from the MN. CEP> As an example to support my contention that this draft is actively CEP> harmful to current work items within the mobile-ip working group, CEP> say that a PDSN implements Regional Registrations. This is very CEP> likely, given recent discussion. How then would such a PDSN manage CEP> its route tables if it ever received a message on port 697? CEP> It might be very difficult to figure this out. It would be CEP> possible to get messages that required incompatible operations. Not true. Messages received on port 697 would only come from RNNs. Other messages that may be defined in the future, such as regional handoff messages, would come from MNs or from neighboring PDSNs (FAs). Think of the R-P connection as a logical interface. CEP> Similarly, if a mobile node implements smooth handover messages CEP> using IPv4 Binding Updates, then there would be a conflict between CEP> actions required by the Binding Update message and the port 697 CEP> messages. Also not true. A Binding Update from anywhere else in the network should be treated by the PDSN in its normal role as Mobile IP Foreign Agent. It would then redirect traffic to another PDSN and stop sending packets down the R-P tunnel (assuming the BU was properly authenticated, of course, the key distribution/PKI for which has not yet been solved). CEP> I have numerous other syntactic and editorial comments that I CEP> think would need attention before the draft should be considered CEP> at all. If need be, I will supply these additional comments. CEP> However, before going to that trouble, I think that it is more CEP> important to consider the viability of the draft. I hope that the CEP> authors of the draft will follow through on their previous agreement CEP> to find a better integration strategy with other existing mobile-ip CEP> working group drafts, specifically including Route Optimization and CEP> Regional Registration. If it is the contention of the 3gwireless CEP> authors that the previous drafts are too complicated for their CEP> implementation purposes, then we should have the discussion. CEP> I have offered to do so, more than once. One possible outcome CEP> would be to get simpler drafts for specific protocol features CEP> needed by the 3gwireless authors. A "better integration strategy" than complete transparency to any existing and future Mobile IP standards is not to be found. At this late date I would prefer to stick with the messages as they have been defined. The draft has been available for comment for quite some time. However, I have no objection in principle to changing from Registration Update to Binding Update and I certainly agree that the "V" bit should be dropped. If you have any other comments waiting could you please share them soon? CEP> I note that Nortel Networks had brought some similar concerns to CEP> light a couple of years ago, and we reached a beneficial improvement CEP> to the Route Optimization draft which allowed the inclusion of CEP> multiple correspondent node addresses in the Binding Warning CEP> message. I fully expect that we can make similar improvements CEP> as needed to the IPv4 Binding Update message for use in the CEP> role needed by the authors of the 3gwireless draft. That's fine but I do not think the IPv4 Route Optimization draft could ever subsume the functionality described here. This draft is needed to define the Session-Specific Extension and to describe the behavior of RNNs and PDSNs as they establish and tear-down R-P connections. CEP> I also note that the name of the draft is misleading. As far as CEP> I know, there is no consensus behind this protocol specification CEP> within 3GPP or within MWIF. I also do not think there is any CEP> consensus behind this protocol within 3GPP2, but I note that CEP> several of the listed authors are indeed active within 3GPP2. CEP> My guess is that this draft has limited support even there. But CEP> either way, it seems very clear to me that the draft should NOT CEP> be named in any way to imply that it represents _the_ 3G solution CEP> for wireless mobility management. Far from it. This draft has rock-solid support in 3GPP2. It has been codified into IOSv4 and is being implemented by several vendors. MWIF, as far as I know, is not a standards-setting body. I agree that this draft has come from the 3GPP2 community rather than 3GPP, but nothing in the draft is specific to 3GPP2 or cdma2000. The IMSI is an international identifier recognized by both bodies. 3GPP has shown very limited IETF participation so far, choosing to go its own way with GPRS. Would you be satisfied if we changed the name to "in A 3rd Generation Wireless Network?" CEP> Lastly, I note that this draft has attracted almost no discussion CEP> within the mobile-ip working group. When I asked several others CEP> about it, they said it was because most people generally don't care. CEP> But I care. I care because I think it is damaging to the progress of CEP> other longstanding mobile-ip working group items. In order to best CEP> meet the needs of all parties, I offer my best effort to work with CEP> the authors of the 3gwireless draft to make the other drafts meet CEP> their needs. I hope this will be sufficient to resolve what could CEP> otherwise be a situation causing problems for the future. None of the other drafts are capable of satisfying the transparency requirements that are met by 3gwireless. I think your impression of "damage" is due to a misunderstanding of this draft's proposed role in the network. Nothing in the draft precludes Regional Registrations from being deployed and used, but we need a solution that handles some amount of mobility in a transparent manner that does not require IP-layer messages from MNs, and in a timeframe that will meet the deployment requirements of cdma2000 (next year). The uncertainty about the availability of MIPv4 clients, let alone even more elaborate solutions like Regional Registrations, strongly argues that something like 3gwireless is needed. I don't see what harm is done by allowing it to proceed to Experimental status, and I don't see why we need to choose between this draft and the other drafts currently out there. -Pete CEP> Sincerely, CEP> Charles E. Perkins CEP> PS. I regret that I have only now been able to make time for this CEP> set of comments. It would have been much better to raise the CEP> discussion during working-group last call, but that slipped CEP> right by me and was over before I knew it. cc: Yingchun Xu/Mw/Us/3Com @3Com Wenzel @Nortelnetworks.Com Rajesh_Bhalla @3Com.Com Becker @Nortelnetworks.Com Karl_Freter @3Com.Com Jjiang @Nortelnetworks.Com Ed Campbell/Mw/Us/3Com @3Com Shikano471 @Oki.Co.Jp Mcgrath.Hadwen @Worldnet.Att.Net Keg @Telecom.Samsung.Co.Kr Gopal Dommety Yong @Telecom.Samsung.Co.Kr Kjoshi @Cisco.Com Bsemper @Telecom.Samsung.Com P.Yeqani @Ericsson.Com Jmkoo @Sktelecom.Com Matumura @Mcs.Ts.Fujitsu.Co.Jp "Lipford, Mark" Atsushi_Teshima @Cm.Tcd.Hitachi.Co.Jp Flerou01 @Sprintspectrum.Com Jihs @Hei.Co.Kr Jgately @Uswest.Com Nao-Itoh @Ido.Co.Jp Tom Hiller Ki-Ohki @Kdd.Co.Jp Phil Roberts Bklim @Lgic.Co.Kr "Basavaraj Patil Mccap @Lucent.Com David Oran Ttowle @Lucent.Com Rob Coltun Jayapal @Cig.Mot.Com From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Aug 18 18:42:51 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09763 for ; Fri, 18 Aug 2000 18:42:50 -0400 (EDT) Received: from standards (47.234.32.16:3086) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB89DF1@standards.nortelnetworks.com>; Fri, 18 Aug 2000 18:29:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21776 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 18 Aug 2000 18:29:52 -0400 Received: from topaz.3com.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB89D45@standards.nortelnetworks.com>; Fri, 18 Aug 2000 18:19:51 -0400 Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e7IMVqs06565; Fri, 18 Aug 2000 15:31:52 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id e7IMVw909042; Fri, 18 Aug 2000 15:31:58 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 8825693F.007BC51C ; Fri, 18 Aug 2000 15:31:53 -0700 X-Lotus-FromDomain: 3COM Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <8825693F.007BC419.00@hqoutbound.ops.3com.com> Date: Fri, 18 Aug 2000 17:34:24 -0500 Reply-To: Yingchun_Xu@3COM.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Yingchun_Xu@3COM.COM Subject: Re: [MOBILE-IP] [Fwd: draft-ietf-mobileip-3gwireless-ext-04.txt] X-To: "pcalhoun@eng.sun.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Pat, Well, the experience from TIA TR45.6 working group has tought us a lesson. Intead of referenceing the draft, we have copied the whole content of the draft into the IOS4.1 standard. --Yingchun "pcalhoun/@eng.sun.com" Sent by: "pcalhoun@eng.sun.com" If has actually been published in IS-2001 and is being developed to (I > hope). How could it have been published, without an RFC number, given that the document would surely be a normative reference? PatC > > Mark A. Lipford > > > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@IPRG.NOKIA.COM] > Sent: Friday, August 18, 2000 3:27 PM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: [MOBILE-IP] [Fwd: > draft-ietf-mobileip-3gwireless-ext-04.txt] > > Hello folks, > > I have sent the following message earlier this afternoon, in > an > attempt to reopen discussion about the abovementioned > Internet > Draft which is currently under consideration for > Experimental status. > > Yingchun has informed me that the 3gwireless approach has > been > implemented as part of the IOS 4.1 standard within CDMA2000. > I do not know whether that should affect the discussion at > this > point in time. > > Regards, > Charlie P. > > > -------- Original Message -------- > Subject: draft-ietf-mobileip-3gwireless-ext-04.txt > Date: Fri, 18 Aug 2000 13:08:28 -0700 > From: "Charles E. Perkins" > Organization: Nokia Research Center > To: Yingchun_Xu@3com.com, > rajesh_bhalla@3com.com,karl_freter@3com.com, > ed_campbell@3com.com,mcgrath.hadwen@worldnet.att.net,Gopal > Dommety > , > kjoshi@cisco.com,p.yeqani@ericsson.com, > > matumura@mcs.ts.fujitsu.co.jp,atsushi_teshima@cm.tcd.hitachi.co.jp, > jihs@hei.co.kr,nao-itoh@ido.co.jp, ki-ohki@kdd.co.jp, > bklim@lgic.co.kr,mccap@lucent.com, ttowle@lucent.com, > jayapal@cig.mot.com,wenzel@nortelnetworks.com, > becker@nortelnetworks.com,jjiang@nortelnetworks.com, > shikano471@oki.co.jp,keg@telecom.samsung.co.kr, > yong@telecom.samsung.co.kr,bsemper@telecom.samsung.com, > jmkoo@sktelecom.com,"Lipford, Mark" > ,FLerou01@sprintspectrum.com, > jgately@uswest.com > CC: Tom Hiller ,Phil Roberts > ,"Basavaraj Patil (NTC/Dallas)" > ,David Oran , Rob > Coltun > > BCC: Pat Calhoun ,James Kempf > > > > Hello draft co-authors, > > >From the discussion below, and after a careful re-reading > of the draft, > I hope to show that this protocol specification does not at > all fit > well within the mainstream of work within the mobile-ip > working group. > I believe that it is actively harmful, because any core > network > implementing their protocol would find it correspondingly > much more > difficult to implement "actual" Mobile IP specifications. I > say > "actual" in quotes because the specifications in question > are not > yet Proposed Standard, and also because I do not think that > the > 3gwireless specification fits well in its current > formulation nor > has it received sufficient working-group review. > > The first basic problem with the 3G wireless draft is the > specification > of the Registration Update and the Registration > Acknowledgement > message types. Neither of them is clearly specified, and to > the > extent that I understand their purpose, neither one is > necessary. > The intended results of those messages are done better by > use of > the Binding Update and Binding Acknowledgement messages > which are > already specified in the Route Optimization draft. > > The respecification of the Registration Request draft is > also > faulty, and exhibits the well-known fallacy of doing the > same > thing in two different ways. In this particular instance, > we > see that the alt-Registration Request message has failed to > keep > up with recent developments regarding the 'V' bit. We can > expect > this to continue, especially given the strong likelihood > that > some new Mobile IP developments will involve interactions > between > the Registration Request message and AAA services. > > Figuring out when to send an alt-Registration Request will > be > additionally complicated by the standardization of the > upcoming > Regional Registration protocol specification, which is > currently > in Last Call. > > Another element of confusion is represented by the lack of > IP addressability for mobile nodes subordinate to the > protocol > operations described in the 3gwireless draft. In fact, > nowhere > in the draft is there any indication that mobile nodes in > their > system will have IP addresses. Furthermore, mobile nodes in > this draft are basically identified by a MN ID field, which > is > expected to be the same as the mobile node's IMSI. Recent > work > within the mobile-ip working group has gone in the direction > of > using the NAI for analogous purposes of allowing a > Registration > Request to emanate from a mobile node that does not yet have > a home address assigned. I would suggest that the > 3gwireless > draft use the NAI extension instead of their current MN ID. > The IMSI is widely expected to show up as data within NAI > extensions to Mobile IP registration requests, so this > should > not cause any problems to the 3gwireless authors. > > As an example to support my contention that this draft is > actively > harmful to current work items within the mobile-ip working > group, > say that a PDSN implements Regional Registrations. This is > very > likely, given recent discussion. How then would such a PDSN > manage > its route tables if it ever received a message on port 697? > It might be very difficult to figure this out. It would be > possible to get messages that required incompatible > operations. > > Similarly, if a mobile node implements smooth handover > messages > using IPv4 Binding Updates, then there would be a conflict > between > actions required by the Binding Update message and the port > 697 > messages. > > I have numerous other syntactic and editorial comments that > I > think would need attention before the draft should be > considered > at all. If need be, I will supply these additional > comments. > However, before going to that trouble, I think that it is > more > important to consider the viability of the draft. I hope > that the > authors of the draft will follow through on their previous > agreement > to find a better integration strategy with other existing > mobile-ip > working group drafts, specifically including Route > Optimization and > Regional Registration. If it is the contention of the > 3gwireless > authors that the previous drafts are too complicated for > their > implementation purposes, then we should have the discussion. > I have offered to do so, more than once. One possible > outcome > would be to get simpler drafts for specific protocol > features > needed by the 3gwireless authors. > > I note that Nortel Networks had brought some similar > concerns to > light a couple of years ago, and we reached a beneficial > improvement > to the Route Optimization draft which allowed the inclusion > of > multiple correspondent node addresses in the Binding Warning > message. I fully expect that we can make similar > improvements > as needed to the IPv4 Binding Update message for use in the > role needed by the authors of the 3gwireless draft. > > I also note that the name of the draft is misleading. As > far as > I know, there is no consensus behind this protocol > specification > within 3GPP or within MWIF. I also do not think there is > any > consensus behind this protocol within 3GPP2, but I note that > several of the listed authors are indeed active within > 3GPP2. > My guess is that this draft has limited support even there. > But > either way, it seems very clear to me that the draft should > NOT > be named in any way to imply that it represents _the_ 3G > solution > for wireless mobility management. Far from it. > > Lastly, I note that this draft has attracted almost no > discussion > within the mobile-ip working group. When I asked several > others > about it, they said it was because most people generally > don't care. > But I care. I care because I think it is damaging to the > progress of > other longstanding mobile-ip working group items. In order > to best > meet the needs of all parties, I offer my best effort to > work with > the authors of the 3gwireless draft to make the other drafts > meet > their needs. I hope this will be sufficient to resolve what > could > otherwise be a situation causing problems for the future. > > Sincerely, > Charles E. Perkins > > PS. I regret that I have only now been able to make time for > this > set of comments. It would have been much better to > raise the > discussion during working-group last call, but that > slipped > right by me and was over before I knew it. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Aug 18 19:00:16 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10004 for ; Fri, 18 Aug 2000 19:00:15 -0400 (EDT) Received: from standards (47.234.32.16:3086) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB89E6E@standards.nortelnetworks.com>; Fri, 18 Aug 2000 18:47:33 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 22147 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 18 Aug 2000 18:47:33 -0400 Received: from topaz.3com.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB89E54@standards.nortelnetworks.com>; Fri, 18 Aug 2000 18:37:33 -0400 Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e7IMnYs08632; Fri, 18 Aug 2000 15:49:34 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id e7IMnd910889; Fri, 18 Aug 2000 15:49:39 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 8825693F.007D63AC ; Fri, 18 Aug 2000 15:49:35 -0700 X-Lotus-FromDomain: 3COM Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <8825693F.007D617E.00@hqoutbound.ops.3com.com> Date: Fri, 18 Aug 2000 17:52:06 -0500 Reply-To: Yingchun_Xu@3COM.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Yingchun_Xu@3COM.COM Subject: Re: [MOBILE-IP] [Fwd: draft-ietf-mobileip-3gwireless-ext-04.txt] X-To: "pcalhoun@eng.sun.com" X-cc: "pcalhoun@eng.sun.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Pat, I don't think we are wasting the IETF resources. We made the draft first and not sure how long it will take to be a RFC status (you properly know better). But we do have the time limit w.r.t to our standard. ---Yingchun. "pcalhoun/@eng.sun.com" Sent by: "pcalhoun@eng.sun.com" , MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] [Fwd: draft-ietf-mobileip-3gwireless-ext-04.txt] Ah, then why waste IETF resources? You can easily go to IANA and request the numbers that you need. PatC > > > Pat, > Well, the experience from TIA TR45.6 working group has tought us a lesson. > Intead of referenceing the draft, we have copied the whole content of the > draft into the IOS4.1 standard. > > --Yingchun > > > > > "pcalhoun/@eng.sun.com" > Please respond to "pcalhoun@eng.sun.com" > > Sent by: "pcalhoun@eng.sun.com" > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > cc: (Yingchun Xu/MW/US/3Com) > Subject: Re: [MOBILE-IP] [Fwd: draft-ietf-mobileip-3gwireless-ext-04.txt] > > > > > If has actually been published in IS-2001 and is being developed to (I > > hope). > > How could it have been published, without an RFC number, given that the > document would surely be a normative reference? > > PatC > > > > Mark A. Lipford > > > > > > -----Original Message----- > > From: Charles E. Perkins [mailto:charliep@IPRG.NOKIA.COM] > > Sent: Friday, August 18, 2000 3:27 PM > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > Subject: [MOBILE-IP] [Fwd: > > draft-ietf-mobileip-3gwireless-ext-04.txt] > > > > Hello folks, > > > > I have sent the following message earlier this afternoon, in > > an > > attempt to reopen discussion about the abovementioned > > Internet > > Draft which is currently under consideration for > > Experimental status. > > > > Yingchun has informed me that the 3gwireless approach has > > been > > implemented as part of the IOS 4.1 standard within CDMA2000. > > I do not know whether that should affect the discussion at > > this > > point in time. > > > > Regards, > > Charlie P. > > > > > > -------- Original Message -------- > > Subject: draft-ietf-mobileip-3gwireless-ext-04.txt > > Date: Fri, 18 Aug 2000 13:08:28 -0700 > > From: "Charles E. Perkins" > > Organization: Nokia Research Center > > To: Yingchun_Xu@3com.com, > > rajesh_bhalla@3com.com,karl_freter@3com.com, > > ed_campbell@3com.com,mcgrath.hadwen@worldnet.att.net,Gopal > > Dommety > > , > > kjoshi@cisco.com,p.yeqani@ericsson.com, > > > > matumura@mcs.ts.fujitsu.co.jp,atsushi_teshima@cm.tcd.hitachi.co.jp, > > jihs@hei.co.kr,nao-itoh@ido.co.jp, ki-ohki@kdd.co.jp, > > bklim@lgic.co.kr,mccap@lucent.com, ttowle@lucent.com, > > jayapal@cig.mot.com,wenzel@nortelnetworks.com, > > becker@nortelnetworks.com,jjiang@nortelnetworks.com, > > shikano471@oki.co.jp,keg@telecom.samsung.co.kr, > > yong@telecom.samsung.co.kr,bsemper@telecom.samsung.com, > > jmkoo@sktelecom.com,"Lipford, Mark" > > ,FLerou01@sprintspectrum.com, > > jgately@uswest.com > > CC: Tom Hiller ,Phil Roberts > > ,"Basavaraj Patil (NTC/Dallas)" > > ,David Oran , Rob > > Coltun > > > > BCC: Pat Calhoun ,James Kempf > > > > > > > > Hello draft co-authors, > > > > >From the discussion below, and after a careful re-reading > > of the draft, > > I hope to show that this protocol specification does not at > > all fit > > well within the mainstream of work within the mobile-ip > > working group. > > I believe that it is actively harmful, because any core > > network > > implementing their protocol would find it correspondingly > > much more > > difficult to implement "actual" Mobile IP specifications. I > > say > > "actual" in quotes because the specifications in question > > are not > > yet Proposed Standard, and also because I do not think that > > the > > 3gwireless specification fits well in its current > > formulation nor > > has it received sufficient working-group review. > > > > The first basic problem with the 3G wireless draft is the > > specification > > of the Registration Update and the Registration > > Acknowledgement > > message types. Neither of them is clearly specified, and to > > the > > extent that I understand their purpose, neither one is > > necessary. > > The intended results of those messages are done better by > > use of > > the Binding Update and Binding Acknowledgement messages > > which are > > already specified in the Route Optimization draft. > > > > The respecification of the Registration Request draft is > > also > > faulty, and exhibits the well-known fallacy of doing the > > same > > thing in two different ways. In this particular instance, > > we > > see that the alt-Registration Request message has failed to > > keep > > up with recent developments regarding the 'V' bit. We can > > expect > > this to continue, especially given the strong likelihood > > that > > some new Mobile IP developments will involve interactions > > between > > the Registration Request message and AAA services. > > > > Figuring out when to send an alt-Registration Request will > > be > > additionally complicated by the standardization of the > > upcoming > > Regional Registration protocol specification, which is > > currently > > in Last Call. > > > > Another element of confusion is represented by the lack of > > IP addressability for mobile nodes subordinate to the > > protocol > > operations described in the 3gwireless draft. In fact, > > nowhere > > in the draft is there any indication that mobile nodes in > > their > > system will have IP addresses. Furthermore, mobile nodes in > > this draft are basically identified by a MN ID field, which > > is > > expected to be the same as the mobile node's IMSI. Recent > > work > > within the mobile-ip working group has gone in the direction > > of > > using the NAI for analogous purposes of allowing a > > Registration > > Request to emanate from a mobile node that does not yet have > > a home address assigned. I would suggest that the > > 3gwireless > > draft use the NAI extension instead of their current MN ID. > > The IMSI is widely expected to show up as data within NAI > > extensions to Mobile IP registration requests, so this > > should > > not cause any problems to the 3gwireless authors. > > > > As an example to support my contention that this draft is > > actively > > harmful to current work items within the mobile-ip working > > group, > > say that a PDSN implements Regional Registrations. This is > > very > > likely, given recent discussion. How then would such a PDSN > > manage > > its route tables if it ever received a message on port 697? > > It might be very difficult to figure this out. It would be > > possible to get messages that required incompatible > > operations. > > > > Similarly, if a mobile node implements smooth handover > > messages > > using IPv4 Binding Updates, then there would be a conflict > > between > > actions required by the Binding Update message and the port > > 697 > > messages. > > > > I have numerous other syntactic and editorial comments that > > I > > think would need attention before the draft should be > > considered > > at all. If need be, I will supply these additional > > comments. > > However, before going to that trouble, I think that it is > > more > > important to consider the viability of the draft. I hope > > that the > > authors of the draft will follow through on their previous > > agreement > > to find a better integration strategy with other existing > > mobile-ip > > working group drafts, specifically including Route > > Optimization and > > Regional Registration. If it is the contention of the > > 3gwireless > > authors that the previous drafts are too complicated for > > their > > implementation purposes, then we should have the discussion. > > I have offered to do so, more than once. One possible > > outcome > > would be to get simpler drafts for specific protocol > > features > > needed by the 3gwireless authors. > > > > I note that Nortel Networks had brought some similar > > concerns to > > light a couple of years ago, and we reached a beneficial > > improvement > > to the Route Optimization draft which allowed the inclusion > > of > > multiple correspondent node addresses in the Binding Warning > > message. I fully expect that we can make similar > > improvements > > as needed to the IPv4 Binding Update message for use in the > > role needed by the authors of the 3gwireless draft. > > > > I also note that the name of the draft is misleading. As > > far as > > I know, there is no consensus behind this protocol > > specification > > within 3GPP or within MWIF. I also do not think there is > > any > > consensus behind this protocol within 3GPP2, but I note that > > several of the listed authors are indeed active within > > 3GPP2. > > My guess is that this draft has limited support even there. > > But > > either way, it seems very clear to me that the draft should > > NOT > > be named in any way to imply that it represents _the_ 3G > > solution > > for wireless mobility management. Far from it. > > > > Lastly, I note that this draft has attracted almost no > > discussion > > within the mobile-ip working group. When I asked several > > others > > about it, they said it was because most people generally > > don't care. > > But I care. I care because I think it is damaging to the > > progress of > > other longstanding mobile-ip working group items. In order > > to best > > meet the needs of all parties, I offer my best effort to > > work with > > the authors of the 3gwireless draft to make the other drafts > > meet > > their needs. I hope this will be sufficient to resolve what > > could > > otherwise be a situation causing problems for the future. > > > > Sincerely, > > Charles E. Perkins > > > > PS. I regret that I have only now been able to make time for > > this > > set of comments. It would have been much better to > > raise the > > discussion during working-group last call, but that > > slipped > > right by me and was over before I knew it. > > > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Aug 18 19:00:16 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10007 for ; Fri, 18 Aug 2000 19:00:16 -0400 (EDT) Received: from standards (47.234.32.16:3086) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB89E7A@standards.nortelnetworks.com>; Fri, 18 Aug 2000 18:47:53 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 22192 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 18 Aug 2000 18:47:52 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB89E78@standards.nortelnetworks.com>; Fri, 18 Aug 2000 18:47:52 -0400 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA10353; Fri, 18 Aug 2000 16:59:58 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA21197; Fri, 18 Aug 2000 15:59:57 -0700 (PDT) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id PAA24513; Fri, 18 Aug 2000 15:59:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Fri, 18 Aug 2000 15:58:30 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: Re: [MOBILE-IP] [Fwd: draft-ietf-mobileip-3gwireless-ext-04.txt] X-To: Yingchun_Xu@3com.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <8825693F.007D617E.00@hqoutbound.ops.3com.com> Let me be more explicit (and this is just honesty here, I am not trying to p*ss anyone off). You write a draft, submit it. Meanwhile you document it, and publish a document prior to knowing whether the IETF will accept it as is. The IESG does a last call, and comments come in. You state it is too late because your document has been published. The fact is that IETF procedures, be them as it may, are set, and we have to live by them. If significant comments come back during the last call process, the authors have to address them, if they want the draft to be published as a WG work item. Your options, are I see it are the following (either way you get an RFC number): 1. Publish as Informational (as a non WG document), as is. 2. Go for either experimental or Proposed Standard, and address the comments. If you wish to have #2 and not address the comments, because it is published in IS-2001, then I believe this is wasting the WG's time because our review (or lack thereof :), is being ignored anyways. That was my point. PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Aug 18 23:09:26 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14857 for ; Fri, 18 Aug 2000 23:09:24 -0400 (EDT) Received: from standards (47.234.32.16:1371) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB89F9F@standards.nortelnetworks.com>; Fri, 18 Aug 2000 22:56:50 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 22585 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 18 Aug 2000 22:56:50 -0400 Received: from topaz.3com.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB89F92@standards.nortelnetworks.com>; Fri, 18 Aug 2000 22:46:49 -0400 Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e7J2wos24806; Fri, 18 Aug 2000 19:58:50 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id e7J2wt927486; Fri, 18 Aug 2000 19:58:55 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256940.00105EE7 ; Fri, 18 Aug 2000 19:58:48 -0700 X-Lotus-FromDomain: 3COM Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <88256940.00105DF3.00@hqoutbound.ops.3com.com> Date: Fri, 18 Aug 2000 22:01:20 -0500 Reply-To: Yingchun_Xu@3COM.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Yingchun_Xu@3COM.COM Subject: Re: [MOBILE-IP] draft-ietf-mobileip-3gwireless-ext-04.txt X-To: "pcalhoun@eng.sun.com" X-cc: charliep@IPRG.NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Pat, Charlie, I may have missed the comment. Regardless, if the comments make sense, it's still not too late to put them in now. W.r.t to Charlie's message types comment, one of the big reason for not using the Binding Update is that we feel some of the extension we added to the Registration Update message has nothing to do with "route optimization" and it does not make sense to twist Binding Update for the purpose. Otherwise, the "route optimization" draft will soon become a dumping ground. If Charlie is willing to make the change, we have no problem to update our draft. --Yingchun. "pcalhoun/@eng.sun.com" Sent by: "pcalhoun@eng.sun.com" ; Sat, 19 Aug 2000 10:34:24 -0400 (EDT) Received: from standards (47.234.32.16:2714) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8A198@standards.nortelnetworks.com>; Sat, 19 Aug 2000 10:21:26 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 23288 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 19 Aug 2000 10:21:25 -0400 Received: from cedar.dcs.shef.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8A197@standards.nortelnetworks.com>; Sat, 19 Aug 2000 10:21:20 -0400 Received: from borg (borg.dcs.shef.ac.uk [143.167.11.44]) by cedar.dcs.shef.ac.uk (8.9.3+Sun/8.9.3) with SMTP id PAA05044; Sat, 19 Aug 2000 15:33:28 +0100 (BST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D7_01C009F2.F4F66D20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: <00da01c009ea$935cbea0$2c0ba78f@dcs.shef.ac.uk> Date: Sat, 19 Aug 2000 15:34:26 +0100 Reply-To: Chern Nam Yap Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Chern Nam Yap Subject: [MOBILE-IP] Re charter review To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_00D7_01C009F2.F4F66D20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all There has not been not much discussion about about agent discovery = recently. That is something i am quite puzzle when people are mentioning all sorts = of fast handoff. How could one discuss fast handoff without discussing how much delay = does agent discovery takes in place all sorts of environments. Moreover, there is still an issues of how much overheads that agent = discovery will take up in the expensive air link. Please give some real figures. Hopefully someone would clear up these fundamental issues. Cheers -------------------------------------------------------------------------= ------ Chern Nam Yap Research Associate Center for Mobile Communication Research Department of Electronic and Electrical Engineering University of Sheffield Regent Court 211 Portobello Street Sheffield S1 4DP United Kingdom Tel:+44 (0) 114-222-3308 Fax:+44 (0) 114-222-8299 Web: www.mobile1.net E-mail: cny@dcs.shef.ac.uk E-mail: cny@ieee.org ------=_NextPart_000_00D7_01C009F2.F4F66D20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all
 
There has not been not = much discussion about=20 about agent discovery recently.
That is something i am quite puzzle = when people are=20 mentioning all sorts of fast handoff.
 
How could one discuss fast = handoff without=20 discussing how much delay does
agent discovery takes in place all = sorts of=20 environments.
 
Moreover, there is still an issues of = how much=20 overheads that agent discovery
will take up in the expensive air=20 link.
 
Please give some real = figures.
Hopefully someone would clear up these = fundamental=20 issues.
 
Cheers
----------------------------------------------------------------= ---------------
Chern=20 Nam Yap
Research Associate
Center for Mobile Communication=20 Research
Department of Electronic and Electrical = Engineering
University of=20 Sheffield
Regent Court
211 Portobello Street
Sheffield S1 = 4DP
United=20 Kingdom
Tel:+44 (0) 114-222-3308
Fax:+44 (0) 114-222-8299
Web: = www.mobile1.net
E-mail: cny@dcs.shef.ac.uk
E-mail: cny@ieee.org
 
 
 
 
------=_NextPart_000_00D7_01C009F2.F4F66D20-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Aug 20 07:18:55 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07306 for ; Sun, 20 Aug 2000 07:18:55 -0400 (EDT) Received: from standards (47.234.32.16:1655) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8A41A@standards.nortelnetworks.com>; 20 Aug 2000 7:06:00 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 24182 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 20 Aug 2000 07:06:00 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8A411@standards.nortelnetworks.com>; 20 Aug 2000 6:56:00 -0400 Received: from eshop.eshop.com.my ([203.106.85.201]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id GAA27646 for ; Sun, 20 Aug 2000 06:08:09 -0500 (CDT) Received: from 209.179.247.91 - 209.179.247.91 by eshop.eshop.com.my with Microsoft SMTPSVC(5.5.1774.114.11); Sun, 20 Aug 2000 18:25:41 +0800 X-Priority: 3 X-MSMail-Priority: Normal Message-ID: <00005cdc53aa$00006889$00004a26@> Date: Sun, 20 Aug 2000 03:11:32 -0700 Reply-To: futurenow26@HOTMAIL.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: futurenow26@HOTMAIL.COM Subject: [MOBILE-IP] Need a Merchant Account? 18982 X-To: Undisclosed.Recipients@hosaka.smallworks.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Are you looking to have your own web presence? Are you losing business because you are unable to process credit cards & checks over the internet? Sign up and get a FREE shopping cart! Start Your Internet e-Commerce Store today! * Custom Web-Site for Life * Unlimited pages and images * Free Electronic Shopping Cart * 24 hour customer service * 99% approval rate! Studies have shown you can increase your sales up to 1500% by accepting Credit Cards on-line! Accept Visa, Mastercard, Discover/Novus and American Express! Also Debit Card, Direct Check, and countless more! $79.95 Gets You Started! Internet Business ~ New Startups ~ Home Office Mail/Phone Order ~ Retail Stores 99% approval! ~ No set-up fees! ~ Low monthly fees REPLY NOW! & Learn How to Receive this Custom Web-Site e-Commerce solution! STARTING A BUSINESS ONLINE OF ANY KIND? NEED A WEBSITE & MERCHANT ACCOUNT for your business? So what are you waiting for? If you REPLY within 24 hours We will waive all application and setup fees! A savings of $295.00! We will also throw in a shopping cart to complete your e-Commerce store! THERE IS NO OBLIGATION IN RESPONDING TO THIS EMAIL EXCEPT TO RECEIVE MORE INFORMATION. FOR YOUR FREE INFORMATION DOUBLE CLICK ON: mailto:ezcardz4@altavista.com?subject=merchant MAKE SURE TO INCLUDE ALL THE FOLLOWING DETAILS! -NAME -DAY AND EVENING PHONE # -FAX # -EMAIL ADDRESS If you feel that this has reached you in error please DOUBLE CLICK ON: mailto:remonow15@china.com?subject=remove We will insure that your email address is removed from our database immediately. *Subject must contain the word "remove" for us to remove you. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Aug 20 13:22:12 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08957 for ; Sun, 20 Aug 2000 13:22:12 -0400 (EDT) Received: from standards (47.234.32.16:1333) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8A540@standards.nortelnetworks.com>; 20 Aug 2000 13:09:09 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 24587 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 20 Aug 2000 13:09:09 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8A53C@standards.nortelnetworks.com>; 20 Aug 2000 12:59:07 -0400 Received: from ns0.utdallas.edu (ns0.utdallas.edu [129.110.10.1]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id MAA29297 for ; Sun, 20 Aug 2000 12:11:19 -0500 (CDT) Received: from pitcher.utdallas.edu (pitcher.utdallas.edu [129.110.34.20]) by ns0.utdallas.edu (Postfix) with ESMTP id 097A51A040A for ; Sun, 20 Aug 2000 12:10:12 -0500 (CDT) Received: (from jcobb@localhost) by pitcher.utdallas.edu (8.9.1/8.9.1) id MAA10363 for mobile-ip@SMALLWORKS.COM; Sun, 20 Aug 2000 12:11:06 -0500 (CDT) Message-ID: <200008201711.MAA10363@pitcher.utdallas.edu> Date: Sun, 20 Aug 2000 12:11:06 -0500 Reply-To: jcobb@UTDALLAS.EDU Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: jcobb@UTDALLAS.EDU Subject: [MOBILE-IP] ISADS 2001 deadline extended X-To: mobile-ip@SMALLWORKS.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Dear Colleagues: The submission deadline for the International Symposium on Autonomous Decentralized Systems (ISADS) 2001 has been extended to August 31st, 2000, to accommodate some late paper requests. For information on how to submit papers, please go to: http://isads.utdallas.edu Please feel free to pass this information to your colleagues. Thank you very much Jorge Cobb The University of Texas at Dallas publicity chair, ISADS 2001 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Aug 20 19:11:47 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10968 for ; Sun, 20 Aug 2000 19:11:47 -0400 (EDT) Received: from standards (47.234.32.16:4933) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8A66D@standards.nortelnetworks.com>; 20 Aug 2000 18:58:59 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 24957 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 20 Aug 2000 18:58:59 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8A66C@standards.nortelnetworks.com>; 20 Aug 2000 18:58:59 -0400 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA05493; Sun, 20 Aug 2000 17:11:10 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA16469; Sun, 20 Aug 2000 16:11:08 -0700 (PDT) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id QAA05540; Sun, 20 Aug 2000 16:11:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Sun, 20 Aug 2000 16:09:40 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: Re: [MOBILE-IP] draft-ietf-mobileip-3gwireless-ext-04.txt X-To: Yingchun_Xu@3COM.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <88256940.00105DF3.00@hqoutbound.ops.3com.com> Yingchun, As an FYI. It is typically unethical to post someone's private e-mail to the mailing list without the author's consent. PatC > Pat, Charlie, > I may have missed the comment. Regardless, if the comments make sense, it's > still not too late to put them in now. > > W.r.t to Charlie's message types comment, one of the big reason for not using > the Binding Update is that we feel some of the extension we added to the > Registration Update message has nothing to do with "route optimization" and > it does not make sense to twist Binding Update for the purpose. Otherwise, > the "route optimization" draft will soon become a dumping ground. > > If Charlie is willing to make the change, we have no problem to update our > draft. > > --Yingchun. > > > > > "pcalhoun/@eng.sun.com" > Please respond to "pcalhoun@eng.sun.com" > > Sent by: "pcalhoun@eng.sun.com" > > To: Yingchun Xu/MW/US/3Com > cc: charliep@IPRG.NOKIA.COM > Subject: Re: [MOBILE-IP] draft-ietf-mobileip-3gwireless-ext-04.txt > > > > Again, not that I am trying to take one side or another, but I do recall > Charlie sending his objections to the list regarding the message types. The > fact that his comments were ignored was not terribly wise, and his objections > to the IETF should not come as a surprise. > > PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Aug 20 23:07:04 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14288 for ; Sun, 20 Aug 2000 23:07:04 -0400 (EDT) Received: from standards (47.234.32.16:3948) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8A6DD@standards.nortelnetworks.com>; 20 Aug 2000 22:54:01 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 25105 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 20 Aug 2000 22:54:01 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8A6DC@standards.nortelnetworks.com>; 20 Aug 2000 22:54:00 -0400 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA15194 for ; Sun, 20 Aug 2000 21:06:13 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA11674; Sun, 20 Aug 2000 20:06:12 -0700 (PDT) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id UAA08671; Sun, 20 Aug 2000 20:06:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Sun, 20 Aug 2000 20:04:40 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: Re: [MOBILE-IP] Re charter review X-To: Chern Nam Yap To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <00da01c009ea$935cbea0$2c0ba78f@dcs.shef.ac.uk> > Hi all > > There has not been not much discussion about about agent discovery recently. > That is something i am quite puzzle when people are mentioning all sorts of > fast handoff. > > How could one discuss fast handoff without discussing how much delay does > agent discovery takes in place all sorts of environments. Bingo! That is the point that Jim and I have been making all this time, and the reason why we designed the pro-active FA I-D. It takes time for a mobile to detect that it has moved (using traditional Agent Advertisements), not to mention the latency added by the registration process (regardless of how far the registration request has to be sent). PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Aug 21 08:15:47 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29806 for ; Mon, 21 Aug 2000 08:15:46 -0400 (EDT) Received: from standards (47.234.32.16:1667) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8A87B@standards.nortelnetworks.com>; Mon, 21 Aug 2000 8:02:25 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 25605 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 21 Aug 2000 08:02:25 -0400 Received: from ish7.ericsson.com.au (203.61.155.111:50316) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8A87A@standards.nortelnetworks.com>; Mon, 21 Aug 2000 8:02:23 -0400 Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id WAA17885; Mon, 21 Aug 2000 22:12:37 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id WAA06824; Mon, 21 Aug 2000 22:14:17 +1000 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Mon, 21 Aug 2000 22:13:23 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C00B69.33174AD0" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A5089EB193@eaubrnt018.epa.ericsson.se> Date: Mon, 21 Aug 2000 22:13:22 +1000 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] IPv6 handover document X-To: Alper Yegin To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM 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_01C00B69.33174AD0 Content-Type: text/plain; charset="iso-8859-1" I was wondering how big is a cell? I'm sure it depends on the technology, vendor, but can I get a range... =>It depends on various factors but I believe the max cell size in GSM is 35 Km (from the tower). Pico cells (in GSM) can be around 100 m. In CDMA the actual cell size can be dynamic and can vary depending on the number of users per cell and the power budgets per user. ------_=_NextPart_001_01C00B69.33174AD0 Content-Type: text/html; charset="iso-8859-1" RE: [MOBILE-IP] IPv6 handover document


I was wondering how big is a cell? I'm sure it depends on the technology,
vendor, but can I get a range...


=>It depends on various factors but I believe the max cell size in GSM
is 35 Km (from the tower). Pico cells (in GSM) can be around 100 m.
In CDMA the actual cell size can be dynamic and can vary depending
on the number of users per cell and the power budgets per user.

------_=_NextPart_001_01C00B69.33174AD0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Aug 21 10:15:28 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01223 for ; Mon, 21 Aug 2000 10:15:27 -0400 (EDT) Received: from standards (47.234.32.16:4741) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8A91F@standards.nortelnetworks.com>; Mon, 21 Aug 2000 10:02:29 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 25818 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 21 Aug 2000 10:02:29 -0400 Received: from smtpgw2.sprintspectrum.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8A91E@standards.nortelnetworks.com>; Mon, 21 Aug 2000 10:02:29 -0400 Received: from pkcex004.sprintspectrum.com (pkcex004.sprintspectrum.com [208.10.75.139]) by smtpgw2.sprintspectrum.com (8.9.3/8.9.3) with ESMTP id JAA11987 for ; Mon, 21 Aug 2000 09:14:43 -0500 (CDT) Received: by PKCEX004 with Internet Mail Service (5.5.2650.21) id ; Mon, 21 Aug 2000 09:15:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <2D11BCC7FFD8D3118FD70000D1ECDC88033CBC79@pkcexv018.sprintspectrum.com> Date: Mon, 21 Aug 2000 09:14:56 -0500 Reply-To: "Lipford, Mark" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Lipford, Mark" Subject: Re: [MOBILE-IP] [Fwd: draft-ietf-mobileip-3gwireless-ext-04.txt] To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Pat, I can remember if I have responded to this or not, so I will now. You bring up very good questions and I personally thought of this when TSG-A/TR45.4 was doing this and brought it up. Our goal is to be IETF "compliant" on the infamous 3GPP2 TSG-P R-P Interface. To do this and not slip the schedule that we were up against we developed the I-D and put it into version 4.0 of the standard KNOWING that as the I-D went through the IETF process of last call. We decided we would address the necessary comments and move the I-D into RFC status (we are OK with experimental, but not really informational). Once we have an RFC we will then go back in a future version of our standard and "enhance" the R-P interface to be fully compliant. This way we were able to meet our dates and still become IETF compliant as soon as possible. Mark A. Lipford -----Original Message----- From: pcalhoun@eng.sun.com [mailto:Pat.Calhoun@eng.sun.com] Sent: Friday, August 18, 2000 5:59 PM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] [Fwd: draft-ietf-mobileip-3gwireless-ext-04.txt] Let me be more explicit (and this is just honesty here, I am not trying to p*ss anyone off). You write a draft, submit it. Meanwhile you document it, and publish a document prior to knowing whether the IETF will accept it as is. The IESG does a last call, and comments come in. You state it is too late because your document has been published. The fact is that IETF procedures, be them as it may, are set, and we have to live by them. If significant comments come back during the last call process, the authors have to address them, if they want the draft to be published as a WG work item. Your options, are I see it are the following (either way you get an RFC number): 1. Publish as Informational (as a non WG document), as is. 2. Go for either experimental or Proposed Standard, and address the comments. If you wish to have #2 and not address the comments, because it is published in IS-2001, then I believe this is wasting the WG's time because our review (or lack thereof :), is being ignored anyways. That was my point. PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Aug 21 10:23:00 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01371 for ; Mon, 21 Aug 2000 10:22:59 -0400 (EDT) Received: from standards (47.234.32.16:4741) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8A965@standards.nortelnetworks.com>; Mon, 21 Aug 2000 10:10:08 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 25915 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 21 Aug 2000 10:10:08 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8A964@standards.nortelnetworks.com>; Mon, 21 Aug 2000 10:10:07 -0400 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA16081; Mon, 21 Aug 2000 08:21:29 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA12576; Mon, 21 Aug 2000 07:21:28 -0700 (PDT) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA18903; Mon, 21 Aug 2000 07:21:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Mon, 21 Aug 2000 07:19:53 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: Re: [MOBILE-IP] [Fwd: draft-ietf-mobileip-3gwireless-ext-04.txt] X-To: "Lipford, Mark" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <2D11BCC7FFD8D3118FD70000D1ECDC88033CBC79@pkcexv018.sprintspectrum.com> Good, then it sounds as if you are willing to modify the document to address comments brought up on the list. That makes is much simpler. Thanks for the clarification, PatC > Pat, > > I can remember if I have responded to this or not, so I will now. > > You bring up very good questions and I personally thought of this when > TSG-A/TR45.4 was doing this and brought it up. Our goal is to be IETF > "compliant" on the infamous 3GPP2 TSG-P R-P Interface. To do this and not > slip the schedule that we were up against we developed the I-D and put it > into version 4.0 of the standard KNOWING that as the I-D went through the > IETF process of last call. We decided we would address the necessary > comments and move the I-D into RFC status (we are OK with experimental, but > not really informational). Once we have an RFC we will then go back in a > future version of our standard and "enhance" the R-P interface to be fully > compliant. This way we were able to meet our dates and still become IETF > compliant as soon as possible. > Mark A. Lipford > > > -----Original Message----- > From: pcalhoun@eng.sun.com > [mailto:Pat.Calhoun@eng.sun.com] > Sent: Friday, August 18, 2000 5:59 PM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] [Fwd: > draft-ietf-mobileip-3gwireless-ext-04.txt] > > Let me be more explicit (and this is just honesty here, I am > not trying to > p*ss anyone off). > > You write a draft, submit it. Meanwhile you document it, and > publish a > document prior to knowing whether the IETF will accept it as > is. The IESG does > a last call, and comments come in. You state it is too late > because your > document has been published. > > The fact is that IETF procedures, be them as it may, are > set, and we have to > live by them. If significant comments come back during the > last call process, > the authors have to address them, if they want the draft to > be published as a > WG work item. > > Your options, are I see it are the following (either way you > get an RFC > number): 1. Publish as Informational (as a non WG document), > as is. > 2. Go for either experimental or Proposed Standard, and > address the comments. > > If you wish to have #2 and not address the comments, because > it is published > in IS-2001, then I believe this is wasting the WG's time > because our review > (or lack thereof :), is being ignored anyways. That was my > point. > > PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Aug 21 10:42:14 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01705 for ; Mon, 21 Aug 2000 10:42:13 -0400 (EDT) Received: from standards (47.234.32.16:4741) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8A9DB@standards.nortelnetworks.com>; Mon, 21 Aug 2000 10:29:18 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 26063 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 21 Aug 2000 10:29:18 -0400 Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8A9DA@standards.nortelnetworks.com>; Mon, 21 Aug 2000 10:29:17 -0400 Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e7LEfKs19484 for ; Mon, 21 Aug 2000 17:41:26 +0300 (EET DST) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id ; Mon, 21 Aug 2000 09:38:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E1DC@daeis07nok> Date: Mon, 21 Aug 2000 09:38:06 -0500 Reply-To: Basavaraj.Patil@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: [MOBILE-IP] 3Gwireless-ext-04 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM From the current debate on the list regarding the I-D draft-ietf-mobileip-3gwireless-ext-04.txt, it seems that the authors are unwilling to respond to concerns raised a this point in time because of it being already approved and implemented in 3GPP2. The I-D is currently in IETF last call and as such any concerns raised have to be addressed. The fact that the I-D passed WG last call does not guarantee that the IESG will approve it. And issues can be raised during any last call. It's not too late in the process to raise concerns about the I-D. In order to make any progress on this I-D now, I would recommend that the issues be addressed and solved. Regards, -Basavaraj From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Aug 21 10:53:34 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01934 for ; Mon, 21 Aug 2000 10:53:28 -0400 (EDT) Received: from standards (47.234.32.16:4741) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8AA32@standards.nortelnetworks.com>; Mon, 21 Aug 2000 10:40:28 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 26183 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 21 Aug 2000 10:40:28 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8AA31@standards.nortelnetworks.com>; Mon, 21 Aug 2000 10:40:27 -0400 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA04738; Mon, 21 Aug 2000 08:52:35 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA17202; Mon, 21 Aug 2000 07:52:34 -0700 (PDT) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA19569; Mon, 21 Aug 2000 07:52:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Mon, 21 Aug 2000 07:51:01 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: Re: [MOBILE-IP] 3Gwireless-ext-04 X-To: Basavaraj.Patil@NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E1DC@daeis07nok> I believe that one of the co-authors has stated that they are willing to update the document to address the objections that were raised. The co-author also has a very valid point, IMHO. One of Charlie's objections is that the draft should rely on the techniques described in the Route Optimization I-D. One of the problems, of course, is that the Route Optimization I-D hasn't really been going anywhere for some time, so imposing that the 3G draft (and possibly all future handoff work) depend upon the R.O. draft, may not be wise. Perhaps the R.O draft could be split into two. Some basic non-controversial functionality could perhaps be moved into a separate draft, and this is the draft the 3G draft would rely upon. The more controversial portions of the R.O. draft would be separated, and would not hold any future handoff work up in the WG. Comments? PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Aug 21 11:10:10 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02256 for ; Mon, 21 Aug 2000 11:10:09 -0400 (EDT) Received: from standards (47.234.32.16:4741) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8AA96@standards.nortelnetworks.com>; Mon, 21 Aug 2000 10:55:42 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 26315 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 21 Aug 2000 10:55:42 -0400 Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8AA94@standards.nortelnetworks.com>; Mon, 21 Aug 2000 10:55:41 -0400 Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e7LF7js11847; Mon, 21 Aug 2000 18:07:49 +0300 (EET DST) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id ; Mon, 21 Aug 2000 10:04:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E1DE@daeis07nok> Date: Mon, 21 Aug 2000 10:04:44 -0500 Reply-To: Basavaraj.Patil@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: Re: [MOBILE-IP] 3Gwireless-ext-04 X-cc: Pat.Calhoun@Eng.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Pat, If the concern is that the RO draft has not been making progress and hence having a dependency on that will deter the progress of the 3G wireless I-D, then my response woule be that we are in the process of getting the RO draft to WG last call and on to the IESG. So I do not think that would impede the progress of any work. I am not sure if splitting the RO draft into two will help. I am not sure what you consider as the controversial aspects of the draft? -Basavaraj > -----Original Message----- > From: EXT pcalhoun@eng.sun.com [mailto:Pat.Calhoun@Eng.Sun.COM] > Sent: Monday, August 21, 2000 9:51 AM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] 3Gwireless-ext-04 > > > I believe that one of the co-authors has stated that they are > willing to > update the document to address the objections that were > raised. The co-author > also has a very valid point, IMHO. > > One of Charlie's objections is that the draft should rely on > the techniques > described in the Route Optimization I-D. One of the problems, > of course, is > that the Route Optimization I-D hasn't really been going > anywhere for some > time, so imposing that the 3G draft (and possibly all future > handoff work) > depend upon the R.O. draft, may not be wise. > > Perhaps the R.O draft could be split into two. Some basic > non-controversial > functionality could perhaps be moved into a separate draft, > and this is the > draft the 3G draft would rely upon. The more controversial > portions of the > R.O. draft would be separated, and would not hold any future > handoff work up > in the WG. > > Comments? > > PatC > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Aug 21 11:10:10 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02260 for ; Mon, 21 Aug 2000 11:10:10 -0400 (EDT) Received: from standards (47.234.32.16:4741) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8AABD@standards.nortelnetworks.com>; Mon, 21 Aug 2000 10:57:48 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 26364 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 21 Aug 2000 10:57:47 -0400 Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8AABC@standards.nortelnetworks.com>; Mon, 21 Aug 2000 10:57:47 -0400 Received: from grubby.research.bell-labs.com ([135.104.2.9]) by crufty; Mon Aug 21 11:08:28 EDT 2000 Received: from king.research.bell-labs.com ([135.1.152.1]) by grubby; Mon Aug 21 11:08:27 EDT 2000 Received: from notmafia.research.bell-labs.com.research.bell-labs.com (notmafia [135.1.152.230]) by king.research.bell-labs.com (Postfix) with SMTP id 136A55701F; Mon, 21 Aug 2000 10:08:26 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <88256940.00105DF3.00@hqoutbound.ops.3com.com> X-Mailer: VM 6.33 under Emacs 19.34.2 Message-ID: <20000821150826.136A55701F@king.research.bell-labs.com> Date: Mon, 21 Aug 2000 10:08:26 -0500 Reply-To: Pete McCann Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Pete McCann Subject: Re: [MOBILE-IP] draft-ietf-mobileip-3gwireless-ext-04.txt X-To: "pcalhoun@eng.sun.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Content-Transfer-Encoding: 7bit Pat, While Yingchun didn't explicitly ask my permission, I'm glad that my points were made here and I still stand by them. I did intend to post something here after seeing Charles' comments also posted here. -Pete "pcalhoun@eng.sun.com" (psc) writes: psc> Yingchun, psc> As an FYI. It is typically unethical to post someone's private psc> e-mail to the mailing list without the author's consent. psc> PatC >> Pat, Charlie, >> I may have missed the comment. Regardless, if the comments make sense, it's >> still not too late to put them in now. >> >> W.r.t to Charlie's message types comment, one of the big reason for not using >> the Binding Update is that we feel some of the extension we added to the >> Registration Update message has nothing to do with "route optimization" and >> it does not make sense to twist Binding Update for the purpose. Otherwise, >> the "route optimization" draft will soon become a dumping ground. >> >> If Charlie is willing to make the change, we have no problem to update our >> draft. >> >> --Yingchun. >> >> >> >> >> "pcalhoun/@eng.sun.com" > >> Please respond to "pcalhoun@eng.sun.com" >> >> Sent by: "pcalhoun@eng.sun.com" > >> >> To: Yingchun Xu/MW/US/3Com >> cc: charliep@IPRG.NOKIA.COM >> Subject: Re: [MOBILE-IP] draft-ietf-mobileip-3gwireless-ext-04.txt >> >> >> >> Again, not that I am trying to take one side or another, but I do recall >> Charlie sending his objections to the list regarding the message types. The >> fact that his comments were ignored was not terribly wise, and his objections >> to the IETF should not come as a surprise. >> >> PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Aug 21 11:10:11 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02270 for ; Mon, 21 Aug 2000 11:10:10 -0400 (EDT) Received: from standards (47.234.32.16:4741) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8AAC0@standards.nortelnetworks.com>; Mon, 21 Aug 2000 10:57:53 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 26367 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 21 Aug 2000 10:57:52 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8AABF@standards.nortelnetworks.com>; Mon, 21 Aug 2000 10:57:52 -0400 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA14935; Mon, 21 Aug 2000 09:09:56 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA20453; Mon, 21 Aug 2000 08:09:55 -0700 (PDT) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id IAA20064; Mon, 21 Aug 2000 08:09:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Mon, 21 Aug 2000 08:08:27 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: Re: [MOBILE-IP] 3Gwireless-ext-04 X-To: Basavaraj.Patil@nokia.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E1DE@daeis07nok> There are some interesting security requirements in the RO draft, but that is another matter. I was unaware of the fact that the RO draft was in last call.... too many drafts to keep track of, I suppose. If it is, then please ignore my previous comment. PatC > > Pat, > > If the concern is that the RO draft has not been making progress and > hence having a dependency on that will deter the progress of the 3G > wireless I-D, then my response woule be that we are in the process > of getting the RO draft to WG last call and on to the IESG. So I do > not think that would impede the progress of any work. > > I am not sure if splitting the RO draft into two will help. I am not sure > what > you consider as the controversial aspects of the draft? > > > -Basavaraj > > > -----Original Message----- > > From: EXT pcalhoun@eng.sun.com [mailto:Pat.Calhoun@Eng.Sun.COM] > > Sent: Monday, August 21, 2000 9:51 AM > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: [MOBILE-IP] 3Gwireless-ext-04 > > > > > > I believe that one of the co-authors has stated that they are > > willing to > > update the document to address the objections that were > > raised. The co-author > > also has a very valid point, IMHO. > > > > One of Charlie's objections is that the draft should rely on > > the techniques > > described in the Route Optimization I-D. One of the problems, > > of course, is > > that the Route Optimization I-D hasn't really been going > > anywhere for some > > time, so imposing that the 3G draft (and possibly all future > > handoff work) > > depend upon the R.O. draft, may not be wise. > > > > Perhaps the R.O draft could be split into two. Some basic > > non-controversial > > functionality could perhaps be moved into a separate draft, > > and this is the > > draft the 3G draft would rely upon. The more controversial > > portions of the > > R.O. draft would be separated, and would not hold any future > > handoff work up > > in the WG. > > > > Comments? > > > > PatC > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Aug 21 11:20:50 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02579 for ; Mon, 21 Aug 2000 11:20:49 -0400 (EDT) Received: from standards (47.234.32.16:4741) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8AB7C@standards.nortelnetworks.com>; Mon, 21 Aug 2000 11:07:47 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 26618 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 21 Aug 2000 11:07:47 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8AB7B@standards.nortelnetworks.com>; Mon, 21 Aug 2000 11:07:46 -0400 Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Mon Aug 21 11:19:19 EDT 2000 Received: from king.research.bell-labs.com ([135.1.152.1]) by grubby; Mon Aug 21 11:19:19 EDT 2000 Received: from notmafia.research.bell-labs.com.research.bell-labs.com (notmafia [135.1.152.230]) by king.research.bell-labs.com (Postfix) with SMTP id 31BA35701F; Mon, 21 Aug 2000 10:19:18 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E1DC@daeis07nok> X-Mailer: VM 6.33 under Emacs 19.34.2 Message-ID: <20000821151918.31BA35701F@king.research.bell-labs.com> Date: Mon, 21 Aug 2000 10:19:18 -0500 Reply-To: Pete McCann Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Pete McCann Subject: [MOBILE-IP] 3Gwireless-ext-04 X-To: Basavaraj.Patil@NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E1DC@daeis07nok> Content-Transfer-Encoding: 7bit Raj, We are perfectly willing to make reasonable changes; I certainly do not think that 3GPP2's process trumps the IETF process. What was worrisome to me was that Charles' comments seemed to indicate a desire to kill the draft entirely, by including a few minor "tweaks" to the existing Route Optimization draft. I want to state in the strongest possible terms that the basic architectural decisions made in the 3gwireless draft, most importantly the transparency requirement, the use of GRE tunneling, and the inclusion of link-layer identification information in the tunnel establishment messages are at the core of what the draft is trying to accomplish. Because 3GPP2 has made these decisions, they will be implementing something like the 3gwireless draft as an interface between RNNs and PDSNs. While this does not mean the current draft as written is set in stone, it does mean that to document something completely different here in the IETF would be pointless. I think Pat's comments are a good place to start the discussion on whether to use the Binding Update message. I still would argue against this (yes, partly based on a desire to get the draft finished as quickly as possible) but I am willing to accept the consensus of the working group. -Pete Basavaraj Patil (BP) writes: >> From the current debate on the list regarding the I-D BP> draft-ietf-mobileip-3gwireless-ext-04.txt, it seems that BP> the authors are unwilling to respond to concerns raised BP> a this point in time because of it being already approved BP> and implemented in 3GPP2. The I-D is currently in IETF BP> last call and as such any concerns raised have to be BP> addressed. The fact that the I-D passed WG last call does BP> not guarantee that the IESG will approve it. And issues can BP> be raised during any last call. It's not too late in the process BP> to raise concerns about the I-D. BP> In order to make any progress on this I-D now, I would recommend BP> that the issues be addressed and solved. BP> Regards, BP> -Basavaraj From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Aug 21 11:28:38 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02807 for ; Mon, 21 Aug 2000 11:28:37 -0400 (EDT) Received: from standards (47.234.32.16:4741) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8ABDD@standards.nortelnetworks.com>; Mon, 21 Aug 2000 11:15:31 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 26743 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 21 Aug 2000 11:15:30 -0400 Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8ABDC@standards.nortelnetworks.com>; Mon, 21 Aug 2000 11:15:30 -0400 Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com [172.18.242.183]) by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e7LFRZs28060 for ; Mon, 21 Aug 2000 18:27:42 +0300 (EET DST) Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id ; Mon, 21 Aug 2000 10:27:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E1E0@daeis07nok> Date: Mon, 21 Aug 2000 10:24:16 -0500 Reply-To: Basavaraj.Patil@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: Re: [MOBILE-IP] 3Gwireless-ext-04 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Pat, The RO I-D is not in last call. At IETF48 I mentioned that the RO I-D would be sent to IETF last call and wanted to see if people had any concerns with that. Except Dave J, who has a new proposal for RO I heard none. As a result, you will see a WG last call for RO soon. -Basavaraj > -----Original Message----- > From: EXT pcalhoun@eng.sun.com [mailto:Pat.Calhoun@Eng.Sun.COM] > Sent: Monday, August 21, 2000 10:08 AM > To: Basavaraj.Patil@nokia.com > Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: RE: [MOBILE-IP] 3Gwireless-ext-04 > > > There are some interesting security requirements in the RO > draft, but that is > another matter. I was unaware of the fact that the RO draft > was in last > call.... too many drafts to keep track of, I suppose. If it > is, then please > ignore my previous comment. > > PatC > > > > Pat, > > > > If the concern is that the RO draft has not been making progress and > > hence having a dependency on that will deter the progress of the 3G > > wireless I-D, then my response woule be that we are in the process > > of getting the RO draft to WG last call and on to the IESG. So I do > > not think that would impede the progress of any work. > > > > I am not sure if splitting the RO draft into two will help. > I am not sure > > what > > you consider as the controversial aspects of the draft? > > > > > > -Basavaraj > > > > > -----Original Message----- > > > From: EXT pcalhoun@eng.sun.com [mailto:Pat.Calhoun@Eng.Sun.COM] > > > Sent: Monday, August 21, 2000 9:51 AM > > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: [MOBILE-IP] 3Gwireless-ext-04 > > > > > > > > > I believe that one of the co-authors has stated that they are > > > willing to > > > update the document to address the objections that were > > > raised. The co-author > > > also has a very valid point, IMHO. > > > > > > One of Charlie's objections is that the draft should rely on > > > the techniques > > > described in the Route Optimization I-D. One of the problems, > > > of course, is > > > that the Route Optimization I-D hasn't really been going > > > anywhere for some > > > time, so imposing that the 3G draft (and possibly all future > > > handoff work) > > > depend upon the R.O. draft, may not be wise. > > > > > > Perhaps the R.O draft could be split into two. Some basic > > > non-controversial > > > functionality could perhaps be moved into a separate draft, > > > and this is the > > > draft the 3G draft would rely upon. The more controversial > > > portions of the > > > R.O. draft would be separated, and would not hold any future > > > handoff work up > > > in the WG. > > > > > > Comments? > > > > > > PatC > > > > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Aug 21 11:33:24 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03020 for ; Mon, 21 Aug 2000 11:33:23 -0400 (EDT) Received: from standards (47.234.32.16:4741) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8AC04@standards.nortelnetworks.com>; Mon, 21 Aug 2000 11:17:48 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 26796 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 21 Aug 2000 11:17:48 -0400 Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8AC02@standards.nortelnetworks.com>; Mon, 21 Aug 2000 11:17:47 -0400 Received: from scummy.research.bell-labs.com ([135.104.2.10]) by crufty; Mon Aug 21 11:29:11 EDT 2000 Received: from king.research.bell-labs.com ([135.1.152.1]) by scummy; Mon Aug 21 11:29:11 EDT 2000 Received: from notmafia.research.bell-labs.com.research.bell-labs.com (notmafia [135.1.152.230]) by king.research.bell-labs.com (Postfix) with SMTP id 62D4557045; Mon, 21 Aug 2000 10:29:10 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <20000821150826.136A55701F@king.research.bell-labs.com> X-Mailer: VM 6.33 under Emacs 19.34.2 Message-ID: <20000821152910.62D4557045@king.research.bell-labs.com> Date: Mon, 21 Aug 2000 10:29:10 -0500 Reply-To: Pete McCann Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Pete McCann Subject: Re: [MOBILE-IP] draft-ietf-mobileip-3gwireless-ext-04.txt X-To: "pcalhoun@eng.sun.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Content-Transfer-Encoding: 7bit Pat, Sorry, I didn't realize Yingchun had posted a private message of yours. I was referring to the off-list message of mine that he re-posted to the list. I guess he's picked up a bad habit. :) -Pete "pcalhoun@eng.sun.com" (psc) writes: >> Pat, >> >> While Yingchun didn't explicitly ask my permission, I'm glad that my >> points were made here and I still stand by them. I did intend to post >> something here after seeing Charles' comments also posted here. psc> ???? psc> The e-mail that Yingchun sent to the list was a *private* e-mail psc> between Yingchun, Charlie and I. It was not intended to the psc> list. Are you stating that it is now OK to send private e-mail to psc> the world? What, exactly, is your point? I have no problems psc> discussing this problem on the list, and in fact, I was actively psc> discussing the problem, but private e-mails *are* private. psc> PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Aug 21 11:34:57 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03058 for ; Mon, 21 Aug 2000 11:34:56 -0400 (EDT) Received: from standards (47.234.32.16:4741) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8AC54@standards.nortelnetworks.com>; Mon, 21 Aug 2000 11:21:26 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 26903 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 21 Aug 2000 11:21:26 -0400 Received: from mgw-x1.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8AC52@standards.nortelnetworks.com>; Mon, 21 Aug 2000 11:21:25 -0400 Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-x1.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e7LFXTk26857; Mon, 21 Aug 2000 18:33:33 +0300 (EET DST) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id ; Mon, 21 Aug 2000 10:30:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E1E1@daeis07nok> Date: Mon, 21 Aug 2000 10:30:31 -0500 Reply-To: Basavaraj.Patil@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: Re: [MOBILE-IP] 3Gwireless-ext-04 X-To: mccap@research.bell-labs.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Pete, I am glad to hear that the authors are willing to address the issues. I believe the discussion that is already ongoing will clarify the intent of the I-D and also aleviate some of Charlie's worries. I do not think Charlie intended to kill the I-D. Hopefully your e-mail clarifying the issues will go a long way in addressing these concerns. -Basavaraj > -----Original Message----- > From: EXT Pete McCann [mailto:mccap@research.bell-labs.com] > Sent: Monday, August 21, 2000 10:19 AM > To: Basavaraj.Patil@NOKIA.COM > Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: [MOBILE-IP] 3Gwireless-ext-04 > > > > Raj, > > We are perfectly willing to make reasonable changes; I certainly do > not think that 3GPP2's process trumps the IETF process. > > What was worrisome to me was that Charles' comments seemed to indicate > a desire to kill the draft entirely, by including a few minor "tweaks" > to the existing Route Optimization draft. I want to state in the > strongest possible terms that the basic architectural decisions made > in the 3gwireless draft, most importantly the transparency > requirement, the use of GRE tunneling, and the inclusion of link-layer > identification information in the tunnel establishment messages are at > the core of what the draft is trying to accomplish. Because 3GPP2 has > made these decisions, they will be implementing something like the > 3gwireless draft as an interface between RNNs and PDSNs. While this > does not mean the current draft as written is set in stone, it does > mean that to document something completely different here in the IETF > would be pointless. > > I think Pat's comments are a good place to start the discussion on > whether to use the Binding Update message. I still would argue > against this (yes, partly based on a desire to get the draft finished > as quickly as possible) but I am willing to accept the consensus of > the working group. > > -Pete > > Basavaraj Patil (BP) writes: > > >> From the current debate on the list regarding the I-D > BP> draft-ietf-mobileip-3gwireless-ext-04.txt, it seems that > BP> the authors are unwilling to respond to concerns raised > BP> a this point in time because of it being already approved > BP> and implemented in 3GPP2. The I-D is currently in IETF > BP> last call and as such any concerns raised have to be > BP> addressed. The fact that the I-D passed WG last call does > BP> not guarantee that the IESG will approve it. And issues can > BP> be raised during any last call. It's not too late in the process > BP> to raise concerns about the I-D. > > BP> In order to make any progress on this I-D now, I would recommend > BP> that the issues be addressed and solved. > > BP> Regards, > BP> -Basavaraj > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Aug 21 12:25:53 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04107 for ; Mon, 21 Aug 2000 12:25:52 -0400 (EDT) Received: from standards (47.234.32.16:1229) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8ACE3@standards.nortelnetworks.com>; Mon, 21 Aug 2000 12:12:51 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 27100 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 21 Aug 2000 12:12:51 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8ACE2@standards.nortelnetworks.com>; Mon, 21 Aug 2000 12:12:50 -0400 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA16552; Mon, 21 Aug 2000 09:12:36 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA04052; Mon, 21 Aug 2000 08:12:35 -0700 (PDT) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id IAA20124; Mon, 21 Aug 2000 08:12:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Mon, 21 Aug 2000 08:11:08 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: Re: [MOBILE-IP] draft-ietf-mobileip-3gwireless-ext-04.txt X-To: Pete McCann To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <20000821150826.136A55701F@king.research.bell-labs.com> > > Pat, > > While Yingchun didn't explicitly ask my permission, I'm glad that my > points were made here and I still stand by them. I did intend to post > something here after seeing Charles' comments also posted here. ???? The e-mail that Yingchun sent to the list was a *private* e-mail between Yingchun, Charlie and I. It was not intended to the list. Are you stating that it is now OK to send private e-mail to the world? What, exactly, is your point? I have no problems discussing this problem on the list, and in fact, I was actively discussing the problem, but private e-mails *are* private. PatC > > -Pete > > "pcalhoun@eng.sun.com" (psc) writes: > > psc> Yingchun, > > psc> As an FYI. It is typically unethical to post someone's private > psc> e-mail to the mailing list without the author's consent. > > psc> PatC > >> Pat, Charlie, > >> I may have missed the comment. Regardless, if the comments make sense, > it's >> still not too late to put them in now. > >> > >> W.r.t to Charlie's message types comment, one of the big reason for not > using >> the Binding Update is that we feel some of the extension we added > to the >> Registration Update message has nothing to do with "route > optimization" and >> it does not make sense to twist Binding Update for the > purpose. Otherwise, >> the "route optimization" draft will soon become a > dumping ground. >> > >> If Charlie is willing to make the change, we have no problem to update our > >> draft. >> > >> --Yingchun. > >> > >> > >> > >> > >> "pcalhoun/@eng.sun.com" >> > >> Please respond to "pcalhoun@eng.sun.com" > >> > >> Sent by: "pcalhoun@eng.sun.com" >> > >> > >> To: Yingchun Xu/MW/US/3Com > >> cc: charliep@IPRG.NOKIA.COM > >> Subject: Re: [MOBILE-IP] draft-ietf-mobileip-3gwireless-ext-04.txt > >> > >> > >> > >> Again, not that I am trying to take one side or another, but I do recall > >> Charlie sending his objections to the list regarding the message types. > The >> fact that his comments were ignored was not terribly wise, and his > objections >> to the IETF should not come as a surprise. > >> > >> PatC > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Aug 21 13:38:45 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05339 for ; Mon, 21 Aug 2000 13:38:45 -0400 (EDT) Received: from standards (47.234.32.16:3550) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8AD4D@standards.nortelnetworks.com>; Mon, 21 Aug 2000 13:25:32 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 27246 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 21 Aug 2000 13:25:32 -0400 Received: from topaz.3com.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8AD4C@standards.nortelnetworks.com>; Mon, 21 Aug 2000 13:25:31 -0400 Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e7LHbds01930; Mon, 21 Aug 2000 10:37:40 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id e7LHbk909613; Mon, 21 Aug 2000 10:37:46 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256942.0060D449 ; Mon, 21 Aug 2000 10:37:38 -0700 X-Lotus-FromDomain: 3COM Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <88256942.0060D0F4.00@hqoutbound.ops.3com.com> Date: Mon, 21 Aug 2000 10:35:28 -0700 Reply-To: Barani_Subbiah@3COM.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Barani Subbiah Subject: Re: [MOBILE-IP] Re charter review X-To: "pcalhoun@eng.sun.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM I thought that the recent discussions on fast handoff and L2 assisted hand off with L2 abstraction will address this problem. If L2 informs the L3 about the SNR and other parameters then L3 can pro-actively initiate to agent rather than wait for advertisement. Few issues on the recent fast hand off discussion.. 1. We need a single hand off mechanism that is fast, smooth, seamless and reliable at the IP layer. It can use L2 for what ever reasons, however it should be L2 agnostic. 2. We ought to be clear on what information we need from L2. I saw some one mentioned about SNR . Other than that I have not seen any new parameters. 3. What does L3 accomplishes with L2 information and how decision made on L3 relates to L2 or vice versa. Are the decisions made on L3 and L2 independent of each other or have some consequences on each other. It will be useful if we are clear about what information L3 needs from L2 and what does it accomplishes with it.. Barani. "pcalhoun/@eng.sun.com" Sent by: "pcalhoun@eng.sun.com" Hi all > > There has not been not much discussion about about agent discovery recently. > That is something i am quite puzzle when people are mentioning all sorts of > fast handoff. > > How could one discuss fast handoff without discussing how much delay does > agent discovery takes in place all sorts of environments. Bingo! That is the point that Jim and I have been making all this time, and the reason why we designed the pro-active FA I-D. It takes time for a mobile to detect that it has moved (using traditional Agent Advertisements), not to mention the latency added by the registration process (regardless of how far the registration request has to be sent). PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Aug 21 14:29:41 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06401 for ; Mon, 21 Aug 2000 14:29:40 -0400 (EDT) Received: from standards (47.234.32.16:3550) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8ADB3@standards.nortelnetworks.com>; Mon, 21 Aug 2000 14:16:44 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 27384 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 21 Aug 2000 14:16:43 -0400 Received: from dumburken.it.kth.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8ADB2@standards.nortelnetworks.com>; Mon, 21 Aug 2000 14:16:43 -0400 Received: (from maguire@localhost) by dumburken.it.kth.se (8.9.3/8.9.3) id UAA02144; Mon, 21 Aug 2000 20:28:56 +0200 (MET DST) X-Authentication-Warning: dumburken.it.kth.se: maguire set sender to maguire@dumburken.it.kth.se using -f References: <88256942.0060D0F4.00@hqoutbound.ops.3com.com> Message-ID: <200008211828.UAA02144@dumburken.it.kth.se> Date: Mon, 21 Aug 2000 20:28:56 +0200 Reply-To: Gerald Maguire Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gerald Maguire Subject: Re: [MOBILE-IP] Re charter review X-To: Barani_Subbiah@3COM.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <88256942.0060D0F4.00@hqoutbound.ops.3com.com> (message from Barani Subbiah on Mon, 21 Aug 2000 10:35:28 -0700) With respect to your three questions: 1. Well if you want to look for paramters from L2 with respect to "fast, smooth, seamless and reliable", you also many want to have information such as power in the channel (both for the channel you are using and the channels you might want to use) - since SNR may not be sufficient information to tell you if it is in use, detection of pilot/access point, past/current/projected future power consumption, past/current/project future data rate, past/current/project future corrected and uncorrected error rates, ... . 2. While the method can be L2 agnostic, the data dictionary of the attributes which have to be passed across this API should be extensible -- since we really don't have a good idea of the complete range of information that we would like to get. {Since in fact there is very little experience with providing this information outside of a specific wireless system.} 3. The decisions made on L2 and L3 shouldn't be independent or we would not care about passing information back and forth! One of our problems currently is that they are largely independent and sometimes at cross purposes. A clear example is that a specific L2 may not even be aware of another specific L2, both of which are available to L3 -- thus the first L2 might increase power or decrease data rate -- while if the L3 knew that this L2 were having problems, then as it knows that it has another L2 available it might try to use that instead (but only if it can know that it is worth using - which requires information). Chip From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Aug 21 21:37:44 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12917 for ; Mon, 21 Aug 2000 21:37:43 -0400 (EDT) Received: from standards (47.234.32.16:1681) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8AEF6@standards.nortelnetworks.com>; Mon, 21 Aug 2000 21:25:00 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 27809 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 21 Aug 2000 21:24:59 -0400 Received: from web3903.mail.yahoo.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8AEF5@standards.nortelnetworks.com>; Mon, 21 Aug 2000 21:14:59 -0400 Received: from [207.253.63.225] by web3903.mail.yahoo.com; Mon, 21 Aug 2000 18:27:15 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20000822012715.14865.qmail@web3903.mail.yahoo.com> Date: Mon, 21 Aug 2000 18:27:15 -0700 Reply-To: Didem Sarikaya Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Didem Sarikaya Subject: Re: [MOBILE-IP] 3Gwireless-ext-04 X-To: "pcalhoun@eng.sun.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM It seems to me that the biggest problem with this draft which contains a record number of authors is its standardization of the ppp access to what Andrew once called ATM like link layer. --behcet __________________________________________________ Do You Yahoo!? Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Aug 22 00:43:05 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15762 for ; Tue, 22 Aug 2000 00:43:05 -0400 (EDT) Received: from standards (47.234.32.16:4347) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8AF88@standards.nortelnetworks.com>; Tue, 22 Aug 2000 0:30:13 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 28005 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 22 Aug 2000 00:30:12 -0400 Received: from topaz.3com.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8AF87@standards.nortelnetworks.com>; Tue, 22 Aug 2000 0:20:12 -0400 Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e7M4WLs05457; Mon, 21 Aug 2000 21:32:21 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id e7M4WSa09435; Mon, 21 Aug 2000 21:32:28 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256943.0018EDCB ; Mon, 21 Aug 2000 21:32:17 -0700 X-Lotus-FromDomain: 3COM Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <88256943.0018ED54.00@hqoutbound.ops.3com.com> Date: Mon, 21 Aug 2000 23:34:49 -0500 Reply-To: Yingchun_Xu@3COM.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Yingchun_Xu@3COM.COM Subject: Re: [MOBILE-IP] 3Gwireless-ext-04 X-To: Basavaraj.Patil@NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM First, in order to address the issues, changes to RO draft are necessary. But if you look at the changes required to RO, it seems make no sense. Can we update RO draft to let Binding Update message carry link specific extension? --Yingchun. Basavaraj Patil on 08/21/2000 10:30:31 AM Please respond to Basavaraj.Patil@NOKIA.COM Sent by: Basavaraj Patil To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM cc: (Yingchun Xu/MW/US/3Com) Subject: Re: [MOBILE-IP] 3Gwireless-ext-04 Pete, I am glad to hear that the authors are willing to address the issues. I believe the discussion that is already ongoing will clarify the intent of the I-D and also aleviate some of Charlie's worries. I do not think Charlie intended to kill the I-D. Hopefully your e-mail clarifying the issues will go a long way in addressing these concerns. -Basavaraj > -----Original Message----- > From: EXT Pete McCann [mailto:mccap@research.bell-labs.com] > Sent: Monday, August 21, 2000 10:19 AM > To: Basavaraj.Patil@NOKIA.COM > Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: [MOBILE-IP] 3Gwireless-ext-04 > > > > Raj, > > We are perfectly willing to make reasonable changes; I certainly do > not think that 3GPP2's process trumps the IETF process. > > What was worrisome to me was that Charles' comments seemed to indicate > a desire to kill the draft entirely, by including a few minor "tweaks" > to the existing Route Optimization draft. I want to state in the > strongest possible terms that the basic architectural decisions made > in the 3gwireless draft, most importantly the transparency > requirement, the use of GRE tunneling, and the inclusion of link-layer > identification information in the tunnel establishment messages are at > the core of what the draft is trying to accomplish. Because 3GPP2 has > made these decisions, they will be implementing something like the > 3gwireless draft as an interface between RNNs and PDSNs. While this > does not mean the current draft as written is set in stone, it does > mean that to document something completely different here in the IETF > would be pointless. > > I think Pat's comments are a good place to start the discussion on > whether to use the Binding Update message. I still would argue > against this (yes, partly based on a desire to get the draft finished > as quickly as possible) but I am willing to accept the consensus of > the working group. > > -Pete > > Basavaraj Patil (BP) writes: > > >> From the current debate on the list regarding the I-D > BP> draft-ietf-mobileip-3gwireless-ext-04.txt, it seems that > BP> the authors are unwilling to respond to concerns raised > BP> a this point in time because of it being already approved > BP> and implemented in 3GPP2. The I-D is currently in IETF > BP> last call and as such any concerns raised have to be > BP> addressed. The fact that the I-D passed WG last call does > BP> not guarantee that the IESG will approve it. And issues can > BP> be raised during any last call. It's not too late in the process > BP> to raise concerns about the I-D. > > BP> In order to make any progress on this I-D now, I would recommend > BP> that the issues be addressed and solved. > > BP> Regards, > BP> -Basavaraj > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Aug 22 00:57:15 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15814 for ; Tue, 22 Aug 2000 00:57:14 -0400 (EDT) Received: from standards (47.234.32.16:4347) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8AFCC@standards.nortelnetworks.com>; Tue, 22 Aug 2000 0:44:18 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 28097 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 22 Aug 2000 00:44:18 -0400 Received: from smtpgw2.sprintspectrum.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8AFCB@standards.nortelnetworks.com>; Tue, 22 Aug 2000 0:44:18 -0400 Received: from pkcex004.sprintspectrum.com (pkcex004.sprintspectrum.com [208.10.75.139]) by smtpgw2.sprintspectrum.com (8.9.3/8.9.3) with ESMTP id XAA16161 for ; Mon, 21 Aug 2000 23:56:35 -0500 (CDT) Received: by PKCEX004 with Internet Mail Service (5.5.2650.21) id ; Mon, 21 Aug 2000 23:56:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <2D11BCC7FFD8D3118FD70000D1ECDC88033CBF6B@pkcexv018.sprintspectrum.com> Date: Mon, 21 Aug 2000 23:56:33 -0500 Reply-To: "Lipford, Mark" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Lipford, Mark" Subject: Re: [MOBILE-IP] 3Gwireless-ext-04 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM I don't think your comments are accurate. We are willing to take comments and improve the I-D. There is some concern in halting the work on this I-D due to Route Optimization. When we submitted this I-D in DC last November a concern was raised and we indicated a willingness to work with the "Route" authors to try and utilize their I-D, but we thought the I-D was "dead" since it had expired and no new revision was posted to the list. (This was at the Nov99 IETF in DC, I see that since then there was an update last February - Which is now expired). The authors indicated a willingness to revive it, but we have not seen a new revision. Again in Adelaide we indicated a willingness to work with the "Route" authors but nothing has happened. This is what we are confused about and as someone that is wanting to deploy this solution we find frustrating. To be fair to the "Route" authors we are working off-line with them to try and find a compromise, but wanted to avoid forcing the mail list the pain of this discussion. So we are addressing this issue even though I personally don't see why it should be an issue. Regards Mark A. Lipford -----Original Message----- From: Basavaraj Patil [mailto:Basavaraj.Patil@NOKIA.COM] Sent: Monday, August 21, 2000 9:38 AM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: [MOBILE-IP] 3Gwireless-ext-04 From the current debate on the list regarding the I-D draft-ietf-mobileip-3gwireless-ext-04.txt, it seems that the authors are unwilling to respond to concerns raised a this point in time because of it being already approved and implemented in 3GPP2. The I-D is currently in IETF last call and as such any concerns raised have to be addressed. The fact that the I-D passed WG last call does not guarantee that the IESG will approve it. And issues can be raised during any last call. It's not too late in the process to raise concerns about the I-D. In order to make any progress on this I-D now, I would recommend that the issues be addressed and solved. Regards, -Basavaraj From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Aug 22 00:57:15 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15818 for ; Tue, 22 Aug 2000 00:57:15 -0400 (EDT) Received: from standards (47.234.32.16:4347) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8AFD1@standards.nortelnetworks.com>; Tue, 22 Aug 2000 0:44:22 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 28103 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 22 Aug 2000 00:44:21 -0400 Received: from smtpgw2.sprintspectrum.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8AFCF@standards.nortelnetworks.com>; Tue, 22 Aug 2000 0:44:21 -0400 Received: from pkcex004.sprintspectrum.com (pkcex004.sprintspectrum.com [208.10.75.139]) by smtpgw2.sprintspectrum.com (8.9.3/8.9.3) with ESMTP id XAA16173 for ; Mon, 21 Aug 2000 23:56:38 -0500 (CDT) Received: by PKCEX004 with Internet Mail Service (5.5.2650.21) id ; Mon, 21 Aug 2000 23:56:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <2D11BCC7FFD8D3118FD70000D1ECDC88033CBF6C@pkcexv018.sprintspectrum.com> Date: Mon, 21 Aug 2000 23:56:35 -0500 Reply-To: "Lipford, Mark" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Lipford, Mark" Subject: Re: [MOBILE-IP] 3Gwireless-ext-04 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Fully concur Mark A. Lipford -----Original Message----- From: pcalhoun@eng.sun.com [mailto:Pat.Calhoun@Eng.Sun.COM] Sent: Monday, August 21, 2000 9:51 AM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] 3Gwireless-ext-04 I believe that one of the co-authors has stated that they are willing to update the document to address the objections that were raised. The co-author also has a very valid point, IMHO. One of Charlie's objections is that the draft should rely on the techniques described in the Route Optimization I-D. One of the problems, of course, is that the Route Optimization I-D hasn't really been going anywhere for some time, so imposing that the 3G draft (and possibly all future handoff work) depend upon the R.O. draft, may not be wise. Perhaps the R.O draft could be split into two. Some basic non-controversial functionality could perhaps be moved into a separate draft, and this is the draft the 3G draft would rely upon. The more controversial portions of the R.O. draft would be separated, and would not hold any future handoff work up in the WG. Comments? PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Aug 22 04:34:48 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29427 for ; Tue, 22 Aug 2000 04:34:47 -0400 (EDT) Received: from standards (47.234.32.16:1086) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8B06A@standards.nortelnetworks.com>; Tue, 22 Aug 2000 4:21:54 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 28302 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 22 Aug 2000 04:21:54 -0400 Received: from finch-post-11.mail.demon.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8B069@standards.nortelnetworks.com>; Tue, 22 Aug 2000 4:21:53 -0400 Received: from panasonic-pmdc.demon.co.uk ([194.222.202.84] helo=panasonic-pmdc) by finch-post-11.mail.demon.net with esmtp (Exim 2.12 #1) id 13R9Va-000ALm-0B for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 22 Aug 2000 08:34:10 +0000 Received: from 100.100.101.233 by panasonic-pmdc ([100.100.101.232] running VPOP3) with SMTP for ; Tue, 22 Aug 2000 09:38:57 +0100 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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Server: VPOP3 V1.4.0b - Registered to: Panasonic PMDC Message-ID: <000601c00c13$614eccc0$e9656464@pc1233> Date: Tue, 22 Aug 2000 09:31:33 +0100 Reply-To: gavin.button@panasonic-pmdc.co.uk Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gavin Button Subject: [MOBILE-IP] Move Detection. To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi, As the questions on this list are predominantly concerned with defining new Mobile IP protocols, is it the right place for me to ask MobileIPv4 (RFC2002) implementation questions? If not, could you please point me in the right direction. If so, heres my question......... From my undesrtanding, both of the Move Detection algorithms within RFC2000 IP Mobility Support rely on having to wait for the Lifetime of a previous Registration to expire before an Agent Advertisement from another FA could overide it. This could potentially leave a long gap before a change of network was detected. Or am I missing something? Thanks Gavin Button From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Aug 22 07:34:57 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01535 for ; Tue, 22 Aug 2000 07:34:57 -0400 (EDT) Received: from standards (47.234.32.16:2043) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8B156@standards.nortelnetworks.com>; Tue, 22 Aug 2000 7:22:00 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 28533 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 22 Aug 2000 07:22:00 -0400 Received: from tml-gw.tml.hut.fi (tml.hut.fi) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8B119@standards.nortelnetworks.com>; Tue, 22 Aug 2000 7:11:59 -0400 Received: (from smap@localhost) by tml-gw.tml.hut.fi (8.8.7/8.8.7) id OAA17316 for ; Tue, 22 Aug 2000 14:24:16 +0300 Received: from caffeine.tml.hut.fi(130.233.45.27) by tml-gw.tml.hut.fi via smap (V2.0) id xma017312; Tue, 22 Aug 00 14:24:15 +0300 Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7]) by caffeine.tml.hut.fi (8.10.2/8.10.2) with ESMTP id e7MBOSu24607 for ; Tue, 22 Aug 2000 14:24:28 +0300 (EET DST) Received: from localhost (lyang@localhost) by morphine.tml.hut.fi (8.9.2/8.7.1) with ESMTP id OAA08156 for ; Tue, 22 Aug 2000 14:23:58 +0300 (EET DST) X-Authentication-Warning: morphine.tml.hut.fi: lyang owned process doing -bs MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Tue, 22 Aug 2000 14:23:58 +0300 Reply-To: Linfeng Yang Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Linfeng Yang Subject: Re: [MOBILE-IP] Move Detection. To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <000601c00c13$614eccc0$e9656464@pc1233> Hi, On Tue, 22 Aug 2000, Gavin Button wrote: > From my understanding, both of the Move Detection algorithms within RFC2000 > IP Mobility Support rely on having to wait for the Lifetime of a previous > Registration to expire before an Agent Advertisement from another FA could > overide it. This could potentially leave a long gap before a change of > network was detected. Or am I missing something? Even though the Lifetime field here for ICMP has no relation to the "Registration Lifetime" field within the Mobility Agent Advertisement Extension, I checked the ICMP Router Discovery Messages (RFC 1256) and it says: The default advertising rate is once every 7 to 10 minutes, and the default lifetime is 30 minutes. Can this be used as beacon? If not, can anyone point out what can be used as beacon? Thanks, Linfeng Yang Helsinki University of Technology Telecommunications Software and Multimedia Laboratory P.O.Box 9700, 02015 HUT, Finland Phone: +358 9 451 5250 Fax: +358 9 451 5351 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Aug 22 07:47:04 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01879 for ; Tue, 22 Aug 2000 07:47:03 -0400 (EDT) Received: from standards (47.234.32.16:2043) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8B196@standards.nortelnetworks.com>; Tue, 22 Aug 2000 7:34:18 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 28657 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 22 Aug 2000 07:34:17 -0400 Received: from telecom.samsung.co.kr (165.213.221.4:1666) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8B17F@standards.nortelnetworks.com>; Tue, 22 Aug 2000 7:24:15 -0400 Received: from keg ( [165.213.178.136] (may be forged)) by telecom.samsung.co.kr (8.9.3/8.9.3) with SMTP id UAA09466 for ; Tue, 22 Aug 2000 20:37:13 +0900 (KST) MIME-Version: 1.0 Content-Type: text/plain; charset="euc-kr" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Message-ID: <001601c00c2b$b1175fc0$88b2d5a5@keg.telecom.samsung.co.kr> Date: Tue, 22 Aug 2000 20:25:33 +0900 Reply-To: Woo-June Kim Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Woo-June Kim Subject: Re: [MOBILE-IP] Move Detection. To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id HAA01879 Hi, I've wondered about the same problem myself. At least I'm not alone. :-) As I understand it, the current wording in rfc2002 seems to result from the fact that the Mobile IP protocol was defined for systems where it would be possible to get Agent Advertisements from multiple FAs at the same time. For such a case there would be no reason to get rid of a previous registration just because a Agent Advertisement was received from a new FA. Waiting for the lifetime to expire would be wise. This runs into problems for cases such as when the mobile is connected to a network such as the currently proposed 3GPP2 cdma2000 networks. During handoff to another PDSN (the terminating point of the PPP connection between the mobile and the edge of the IP network), the link connection (most likely PPP) will be reset, and the PDSN will send out an Agent Advertisement. (This is all spelled out in the IS-835 specs and the IOS v4.0.1 specs, by the way.) Once this happens the mobile runs into the problem you just described. Should the mobile remove the old registration. because it received a Agent Advertisement from a new FA ? My feeling is that since the link layer has been changed (i.e. the PPP has been reset) the mobile should react to the new Agent Advertisement immediately. The wording in rfc2002 does contain some musing on link layer notification. I guess this sort of falls into that category. (Probably the authors were considering this sor t of problem ?) Actually, during the current (or is it finished ?) last call of rfc2002-bis, I was wondering if anyone bring this up. As there is currently a lot of discussions going on about the 3G- etc. using Mobile IP, I think it would have been useful to clarify the language a bit. cheers Woojune Kim, Senior Engineer Samsung Electronics Ltd. tel : +82-342-779-8526 hp : +82-11-368-7480 e-mail : keg@telecom.samsung.co.kr >Hi, > >As the questions on this list are predominantly concerned with defining new >Mobile IP protocols, is it the right place for me to ask MobileIPv4 >(RFC2002) implementation questions? > >If not, could you please point me in the right direction. If so, heres my >question......... > >>From my undesrtanding, both of the Move Detection algorithms within RFC2000 >IP Mobility Support rely on having to wait for the Lifetime of a previous >Registration to expire before an Agent Advertisement from another FA could >overide it. This could potentially leave a long gap before a change of >network was detected. Or am I missing something? > >Thanks > >Gavin Button > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Aug 22 13:57:39 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12040 for ; Tue, 22 Aug 2000 13:57:38 -0400 (EDT) Received: from standards (47.234.32.16:2437) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8B38C@standards.nortelnetworks.com>; Tue, 22 Aug 2000 13:44:07 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29334 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 22 Aug 2000 13:44:07 -0400 Received: from mgw-x1.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8B38B@standards.nortelnetworks.com>; Tue, 22 Aug 2000 13:44:06 -0400 Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-x1.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e7MHuH008440; Tue, 22 Aug 2000 20:56:18 +0300 (EET DST) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id ; Tue, 22 Aug 2000 12:53:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E1F9@daeis07nok> Date: Tue, 22 Aug 2000 12:53:17 -0500 Reply-To: Basavaraj.Patil@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: Re: [MOBILE-IP] 3Gwireless-ext-04 X-cc: Yingchun_Xu@3com.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Yingchun, I do not believe that you need to include session speciic extension as part of the RO I-D. This is specific to the interface that this I-D addresses. Any updates to the RO I-D as a result of the 3G wireless ext I-D should be minimal. As you have stated before RO is really not the issue that is dealt with in the 3G Wireless extensions I-D, and I agree. -Basavaraj > -----Original Message----- > From: EXT Yingchun_Xu@3com.com [mailto:Yingchun_Xu@3com.com] > Sent: Monday, August 21, 2000 11:35 PM > To: Basavaraj.Patil@NOKIA.COM > Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] 3Gwireless-ext-04 > > > > > First, in order to address the issues, changes to RO draft > are necessary. But if > you look at the changes required to RO, it seems make no > sense. Can we update RO > draft to let Binding Update message carry link specific extension? > > --Yingchun. > > > > > Basavaraj Patil on 08/21/2000 10:30:31 AM > > Please respond to Basavaraj.Patil@NOKIA.COM > > Sent by: Basavaraj Patil > > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > cc: (Yingchun Xu/MW/US/3Com) > Subject: Re: [MOBILE-IP] 3Gwireless-ext-04 > > > > Pete, > > I am glad to hear that the authors are willing to address the issues. > I believe the discussion that is already ongoing will clarify > the intent > of the I-D and also aleviate some of Charlie's worries. > I do not think Charlie intended to kill the I-D. Hopefully your e-mail > clarifying the issues will go a long way in addressing these concerns. > > -Basavaraj > > > -----Original Message----- > > From: EXT Pete McCann [mailto:mccap@research.bell-labs.com] > > Sent: Monday, August 21, 2000 10:19 AM > > To: Basavaraj.Patil@NOKIA.COM > > Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > Subject: [MOBILE-IP] 3Gwireless-ext-04 > > > > > > > > Raj, > > > > We are perfectly willing to make reasonable changes; I certainly do > > not think that 3GPP2's process trumps the IETF process. > > > > What was worrisome to me was that Charles' comments seemed > to indicate > > a desire to kill the draft entirely, by including a few > minor "tweaks" > > to the existing Route Optimization draft. I want to state in the > > strongest possible terms that the basic architectural decisions made > > in the 3gwireless draft, most importantly the transparency > > requirement, the use of GRE tunneling, and the inclusion of > link-layer > > identification information in the tunnel establishment > messages are at > > the core of what the draft is trying to accomplish. > Because 3GPP2 has > > made these decisions, they will be implementing something like the > > 3gwireless draft as an interface between RNNs and PDSNs. While this > > does not mean the current draft as written is set in stone, it does > > mean that to document something completely different here > in the IETF > > would be pointless. > > > > I think Pat's comments are a good place to start the discussion on > > whether to use the Binding Update message. I still would argue > > against this (yes, partly based on a desire to get the > draft finished > > as quickly as possible) but I am willing to accept the consensus of > > the working group. > > > > -Pete > > > > Basavaraj Patil (BP) writes: > > > > >> From the current debate on the list regarding the I-D > > BP> draft-ietf-mobileip-3gwireless-ext-04.txt, it seems that > > BP> the authors are unwilling to respond to concerns raised > > BP> a this point in time because of it being already approved > > BP> and implemented in 3GPP2. The I-D is currently in IETF > > BP> last call and as such any concerns raised have to be > > BP> addressed. The fact that the I-D passed WG last call does > > BP> not guarantee that the IESG will approve it. And issues can > > BP> be raised during any last call. It's not too late in the process > > BP> to raise concerns about the I-D. > > > > BP> In order to make any progress on this I-D now, I would recommend > > BP> that the issues be addressed and solved. > > > > BP> Regards, > > BP> -Basavaraj > > > > > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Aug 22 14:08:54 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12290 for ; Tue, 22 Aug 2000 14:08:53 -0400 (EDT) Received: from standards (47.234.32.16:2437) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8B3D4@standards.nortelnetworks.com>; Tue, 22 Aug 2000 13:55:50 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29429 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 22 Aug 2000 13:55:50 -0400 Received: from mgw-x1.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8B3D3@standards.nortelnetworks.com>; Tue, 22 Aug 2000 13:55:44 -0400 Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com [172.18.242.183]) by mgw-x1.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e7MI7x014309; Tue, 22 Aug 2000 21:07:59 +0300 (EET DST) Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id ; Tue, 22 Aug 2000 13:07:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E1FA@daeis07nok> Date: Tue, 22 Aug 2000 13:04:56 -0500 Reply-To: Basavaraj.Patil@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: Re: [MOBILE-IP] 3Gwireless-ext-04 X-cc: MLipfo01@SPRINTSPECTRUM.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Mark, So the authors are working on addressing the comments and making any changes to the I-D to improve it. So from that perspective, my comments may be inaccurate. I do not expect that the work on this I-D will be halted because of the RO I-D. I do realize your frustrations im making headway. Let's try and work it out. I guess the RO authors and the authors of the 3G wireless I-D are already off-line to resolve the issues. If you need my help in this process, I will be glad to do what I can. -Basavaraj > -----Original Message----- > From: EXT Lipford, Mark [mailto:MLipfo01@SPRINTSPECTRUM.COM] > Sent: Monday, August 21, 2000 11:57 PM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] 3Gwireless-ext-04 > > > I don't think your comments are accurate. We are willing to > take comments > and improve the I-D. There is some concern in halting the > work on this I-D > due to Route Optimization. When we submitted this I-D in DC > last November a > concern was raised and we indicated a willingness to work > with the "Route" > authors to try and utilize their I-D, but we thought the I-D > was "dead" > since it had expired and no new revision was posted to the > list. (This was > at the Nov99 IETF in DC, I see that since then there was an > update last > February - Which is now expired). The authors indicated a > willingness to > revive it, but we have not seen a new revision. Again in Adelaide we > indicated a willingness to work with the "Route" authors but > nothing has > happened. This is what we are confused about and as someone > that is wanting > to deploy this solution we find frustrating. > > To be fair to the "Route" authors we are working off-line > with them to try > and find a compromise, but wanted to avoid forcing the mail > list the pain of > this discussion. So we are addressing this issue even though > I personally > don't see why it should be an issue. > > Regards > Mark A. Lipford > > > -----Original Message----- > From: Basavaraj Patil [mailto:Basavaraj.Patil@NOKIA.COM] Sent: Monday, August 21, 2000 9:38 AM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: [MOBILE-IP] 3Gwireless-ext-04 From the current debate on the list regarding the I-D draft-ietf-mobileip-3gwireless-ext-04.txt, it seems that the authors are unwilling to respond to concerns raised a this point in time because of it being already approved and implemented in 3GPP2. The I-D is currently in IETF last call and as such any concerns raised have to be addressed. The fact that the I-D passed WG last call does not guarantee that the IESG will approve it. And issues can be raised during any last call. It's not too late in the process to raise concerns about the I-D. In order to make any progress on this I-D now, I would recommend that the issues be addressed and solved. Regards, -Basavaraj From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Aug 23 12:36:48 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17995 for ; Wed, 23 Aug 2000 12:36:48 -0400 (EDT) Received: from standards (47.234.32.16:4275) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8B75A@standards.nortelnetworks.com>; Wed, 23 Aug 2000 12:23:41 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30524 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 23 Aug 2000 12:23:41 -0400 Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8B74E@standards.nortelnetworks.com>; Wed, 23 Aug 2000 12:13:40 -0400 Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Wed Aug 23 12:24:02 EDT 2000 Received: from blhothuelpc (thuelpc [135.180.240.114]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id MAA17938; Wed, 23 Aug 2000 12:24:01 -0400 (EDT) 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 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Message-ID: <000c01c00d1e$61be8630$72f0b487@dnrc.belllabs.com> Date: Wed, 23 Aug 2000 12:22:50 -0400 Reply-To: Sandy Thuel Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Sandy Thuel Subject: Re: [MOBILE-IP] charter review X-To: Roberts Phil-QA3445 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Content-Transfer-Encoding: 7bit > > The chairs would like to refocus the Mobile IP WG objectives to > protocols and solutions that are based on Mobile IP v4 and v6. Can someone please explain CLEARLY how you determine whether or not "protocols and solutions" are based on Mobile IP and are therefore, within the scope of the mobileip WG charter? (e.g. do they have to be rfc2002 compliant?) Thanks, Sandy From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Aug 23 17:05:07 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23038 for ; Wed, 23 Aug 2000 17:05:06 -0400 (EDT) Received: from standards (47.234.32.16:1692) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8B90C@standards.nortelnetworks.com>; Wed, 23 Aug 2000 16:49:34 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31069 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 23 Aug 2000 16:49:34 -0400 Received: from win (64.64.25.133:1379) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8B904@standards.nortelnetworks.com>; Wed, 23 Aug 2000 16:39:34 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 23 Aug 2000 16:49:34 -0400 Reply-To: intelco Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: intelco Subject: [MOBILE-IP] MobileHomeTrader.com Acquired by Penny Stock To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM BW0522 AUG 22,2000 12:11 PACIFIC 15:11 EASTERN ------------------------------------------------------------------------------------ ------------------------- This mail is never sent unsolicited. This is an intelco RoboSpyder mailing! You have subscribed to receive this information at one of 125 intelco managed News, Business or Corporate web sites.To unsubscribe forward this message to: otcremove@netscape.net If you have received this mailing by mistake, we apologize and we assure you that we will remove you from our mailing lists immediately. intelco adheres to Anti Spamming Rules & Regulations You may also be removed by visiting http://www.mobilehometrader.com/mailbox.htm ------------------------------------------------------------------------------------ ---------------------------- - BW)(FL-TIDALWAVE-HOLDINGS)(TDWV) Tidalwave Holdings Inc. Announces Mortgage Web Site Acquisition!!! Interest in MobileHomeTrader.com Acquired By Public Company! FORT LAUDERDALE, Fla.--(BUSINESS WIRE)--Aug. 22, 2000--Tidalwave Holdings Inc. (OTCBB: TDWV) Tuesday announced that they have acquired 10% of MobileHomeTrader.com for $300,000. First American Mortgage Securities Inc. (FAMS) provided financing for the transaction by purchasing restricted treasury shares from the company. Tidalwave Holdings also signed a letter of intent to acquire the additional 90% of MobileHomeTrader.com for $2.7 million subject to financing. In exchange for helping to arrange financing, FAMS is currently negotiating with Tidalwave to manage MobileHomeTrader.com, including providing warehouse credit lines of up to $5 million that can be utilized to fund loans originated via the site. Visit Mobile Home Tradser at http://www.mobilehometrader.com FAMS is a privately held, Florida based, full service Investment Mortgage Bank that operates a Manufactured Housing Finance Conduit. The FAMS Conduit is one of the only firms in the United States that provides financing for all types of manufactured homes, including subprime and singlewide units. FAMS has had a similar agreement with the current management of MobileHomeTrader.com, since 1998 when the Web site was conceived. Under the new agreement Tidalwave and FAMS will work together to expand the services offered and to add new content, including offering a National Manufactured Housing Dealer Directory, a National Mortgage Broker Directory of MobileHomeTrader.com Approved Mortgage Originators, an ONLINE Appraisal service, an ONLINE Sales Center, where used homes are offered directly to consumers and a REPO Center where lenders can list repossessed homes for sale. About Tidalwave Holdings Presently, Tidalwave Holdings is beginning to implement its new business plan of aggressively seeking acquisitions. The company has allocated a significant amount of treasury stock for these acquisitions and is prepared to continue acquiring profitable companies. For additional information, including current price, quotes and Message Boards, visit http://www.otc.bb/tdwv.htm Safe Harbor for Forward-Looking Statements: Except for historical information contained herein, the statements in this news release are forward-looking statements that are made pursuant to the safe harbor provisions of the Private Securities Reform Act of 1995. Forward-looking statements involve known and unknown risks and uncertainties, including but not limited to digital camera competition and Web site traffic, which may cause the company's actual results in the future periods to differ materially from forecasted results. --30--KM/np* JP/np CONTACT: Tidalwave Holdings Inc. Leon Kline, Investor Relations 954/255-6753 KEYWORD: FLORIDA INDUSTRY KEYWORD: COMPUTERS/ELECTRONICS INTERNET MERGERS/ACQ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Aug 25 03:54:41 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13905 for ; Fri, 25 Aug 2000 03:54:40 -0400 (EDT) Received: from standards (47.234.32.16:2784) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8BED0@standards.nortelnetworks.com>; Fri, 25 Aug 2000 3:41:22 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32859 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 25 Aug 2000 03:41:22 -0400 Received: from hermes.iaccess.com.au (203.5.74.7:3788) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8BEC5@standards.nortelnetworks.com>; Fri, 25 Aug 2000 3:31:21 -0400 Received: from llama (as1-86.mel.au.asiaonline.net [210.215.17.86]) by hermes.iaccess.com.au (8.9.1a/8.9.1) with SMTP id RAA01837 for ; Fri, 25 Aug 2000 17:45:10 +1000 (EST) References: <000c01c00d1e$61be8630$72f0b487@dnrc.belllabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 7bit Message-ID: <000001c00e67$f61eae00$0300a8c0@llama> Date: Thu, 24 Aug 2000 18:37:55 +1000 Reply-To: Craig Cameron Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Craig Cameron Subject: [MOBILE-IP] Optimisation Question To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit From the Route Optimization in Mobile IP Draft, >cut--------------------------------------- Similarly, when any node (e.g., a foreign agent) receives a tunneled datagram, if it has a binding cache entry for the destination mobile node (and thus has no visitor list entry for this mobile node), the node receiving this tunneled datagram may deduce that the tunneling node has an out-of-date binding cache entry for this mobile node. In this case, the receiving node SHOULD send a Binding Warning message to the mobile node's home agent, advising it to send a Binding Update message to the node that tunneled this datagram. The mobile node's home agent can be determined from the binding cache entry, because the home agent address is learned from the Binding Update that established this cache entry. >-------------------------------------------------------------- How does the old FA have a cache entry for the mobile? If it is only detunnelling packets then why does it have to maintain a binding cache entry for the mobile? I seem to be missing the crucial detail: how does the old FA know the home address of the mobile (that just moved)? Is it set up when the first packet sent goes through the home agent via a triangular route -> original tunnelled packet's destination is the home address? Thanks Craig 4th year Elec Eng, University of Melbourne From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Aug 25 04:23:56 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14227 for ; Fri, 25 Aug 2000 04:23:55 -0400 (EDT) Received: from standards (47.234.32.16:2090) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8BF15@standards.nortelnetworks.com>; Fri, 25 Aug 2000 4:10:58 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32960 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 25 Aug 2000 04:10:58 -0400 Received: from es40f (hi2000.hitel.net) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8BF14@standards.nortelnetworks.com>; Fri, 25 Aug 2000 4:00:57 -0400 Received: by es40f id RAA0000003088; Fri, 25 Aug 2000 17:07:47 +0900 (KST) Received: from [140.118.188.184] by _[82.181.198.49]_by with SMTP id A38C49E9 Fri, 25 Aug 2000 04:00:34 PDT Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Message-ID: <200008250807.RAA0000003088@es40f> Date: Fri, 25 Aug 2000 04:10:58 -0400 Reply-To: a695webhost@CROSSWINDS.NET Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: a695webhost@CROSSWINDS.NET Subject: [MOBILE-IP] Dirt Cheap Web Hosting for $6.95!! No Gimmicks! To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Web Hosting $6.95 per month!! No Gimmicks!
The first month is free - Follow the link for more information
Paying More Is Too Much!!
http://696.i1internet.net

$6.95 per month for a full service user friendly Web Host.
No Banner Ads - Plenty of disk space.

http://696.i1internet.net

You get:
30Mb Disk Space
2000Mb transfer per month
5 E-mail addresses with unlimited forwarding including a Catch All mailbox
Free Auto Responder for E-Mail
FrontPage Enabled if you want it -
FTP access 24 X 7
Free Graphical Statistics Server with real time "Who's On"
Your own CGI-bin - Password protected Control Panel - Forms to E-Mail - Page
Counters
Free Qualified Technical Support
99.9% up time
SQL 7 packages available
Additional drive space and mailboxes available
Plus many other extras

i1Internet $aver is a no hassle quality Web Host that believes that if you
pay more than $6.95 per month, you are paying TOO MUCH!! We offer you the
same EXTRAS as other sites charging three times more.

http://696.i1internet.net

To be removed from this mailing list; Click Here

From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Aug 25 18:54:47 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01364 for ; Fri, 25 Aug 2000 18:54:46 -0400 (EDT) Received: from standards (47.234.32.16:2985) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C0E9@standards.nortelnetworks.com>; Fri, 25 Aug 2000 18:41:44 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 33485 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 25 Aug 2000 18:41:44 -0400 Received: from fridge.docomo-usa.com (216.69.72.10:51731) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C0B5@standards.nortelnetworks.com>; Fri, 25 Aug 2000 18:31:41 -0400 Received: from mobilebeatles (dhcp87.docomo-usa.com [216.69.72.87]) by fridge.docomo-usa.com (Postfix) with SMTP id 33F6A1C03 for ; Fri, 25 Aug 2000 15:44:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C00EAA.E59A55A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: <000f01c00ee5$92131e40$574845d8@docomousa.com> Date: Fri, 25 Aug 2000 15:41:12 -0700 Reply-To: Youngjune Lee Gwon Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Youngjune Lee Gwon Subject: [MOBILE-IP] Mobile IP Simulation To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C00EAA.E59A55A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable What network simulator is suitable for Mobile IP simulation, both v4 and = v6? Is OPNET a good candidate?=20 Is ns-2 by BSD a good candidate? I heard there is a model created by Charles Perkins using ns-2 = simulator, but cannot locate the source yet. Any comment is welcomed. Thank you and let me know, ------=_NextPart_000_000C_01C00EAA.E59A55A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
What network simulator is suitable for = Mobile IP=20 simulation, both v4 and v6?
Is OPNET a good candidate? =
Is ns-2 by BSD a good = candidate?
 
I heard there is a model created by = Charles Perkins=20 using ns-2 simulator, but cannot locate the source yet.
Any comment is welcomed.
 
Thank you and let me=20 know,
------=_NextPart_000_000C_01C00EAA.E59A55A0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Aug 26 01:48:21 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12755 for ; Sat, 26 Aug 2000 01:48:21 -0400 (EDT) Received: from standards (47.234.32.16:3117) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C1AE@standards.nortelnetworks.com>; Sat, 26 Aug 2000 1:35:19 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 33793 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 26 Aug 2000 01:35:19 -0400 Received: from bacardi.torrentnet.com (198.78.51.104:4602) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C1AB@standards.nortelnetworks.com>; Sat, 26 Aug 2000 1:25:19 -0400 Received: (from gopal@localhost) by bacardi.torrentnet.com (8.10.2/8.10.2) id e7Q5bma03253; Sat, 26 Aug 2000 01:37:48 -0400 (EDT) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID: <200008260537.e7Q5bma03253@bacardi.torrentnet.com> Date: Sat, 26 Aug 2000 01:37:47 -0400 Reply-To: Gopal Kailad Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gopal Kailad Subject: [MOBILE-IP] draft-ietf-mobileip-3gwireless-ext-04 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit What is the rationale for choosing GRE instead of L2TP to tunnel PPP? It will be useful to add it to the draft. Since L2TP has call setup support, there would have been no need to overload the mobile IP registration mechanism to setup GRE tunnels. Also, L2TP has support for in order delivery using sequence numbers, and there would have been no need for adding sequence number support to GRE after it was deprecated. One possible advantage with GRE is future support for tunneling IP instead of PPP, if the PDSN talks IP with the MN. Is there any other benefit? This has probably been discussed in the mailing list, but I have been following this list only recently, and I could not get the rationale from the mailing list archives (may be I did not go back far enough!) Anyways I think this information is useful to have in the draft. Also, if GRE is going to be used to tunnel PPP, will escape characters, framing, and FCS be carried all the way to the PDSN? Cheers, Gopal From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Aug 26 11:16:17 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22379 for ; Sat, 26 Aug 2000 11:16:16 -0400 (EDT) Received: from standards (47.234.32.16:1596) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C2F5@standards.nortelnetworks.com>; Sat, 26 Aug 2000 11:03:03 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 34203 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 26 Aug 2000 11:03:03 -0400 Received: from web3903.mail.yahoo.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C2E8@standards.nortelnetworks.com>; Sat, 26 Aug 2000 10:53:02 -0400 Received: from [216.113.45.91] by web3903.mail.yahoo.com; Sat, 26 Aug 2000 08:05:32 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20000826150532.9059.qmail@web3903.mail.yahoo.com> Date: Sat, 26 Aug 2000 08:05:32 -0700 Reply-To: sarikaya@u-aizu.ac.jp Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Behcet Sarikaya Subject: Re: [MOBILE-IP] Mobile IP Simulation X-To: Youngjune Lee Gwon To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM For mip v4, ns has some good support provided by Dave Johnson"s group at CMU. ns works on almost all platforms. I have no idea on OPTNET. --behcet --- Youngjune Lee Gwon wrote: > What network simulator is suitable for Mobile IP > simulation, both v4 and v6? > Is OPNET a good candidate? > Is ns-2 by BSD a good candidate? > > I heard there is a model created by Charles Perkins > using ns-2 simulator, but cannot locate the source > yet. > Any comment is welcomed. > > Thank you and let me know, > ===== Behcet Sarikaya Univ. of Aizu Aizu, Japan __________________________________________________ Do You Yahoo!? Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Aug 27 23:32:52 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16671 for ; Sun, 27 Aug 2000 23:32:51 -0400 (EDT) Received: from standards (47.234.32.16:1521) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C4E8@standards.nortelnetworks.com>; 27 Aug 2000 23:18:04 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 34885 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 27 Aug 2000 23:18:04 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C4E7@standards.nortelnetworks.com>; 27 Aug 2000 23:08:04 -0400 Received: from mail.copartner.com.tw ([210.65.207.14]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id WAA18939 for ; Sun, 27 Aug 2000 22:20:36 -0500 (CDT) Received: from host [168.191.126.227] by mail.copartner.com.tw with ESMTP (SMTPD32-5.05) id AAB06B2E0236; Mon, 28 Aug 2000 11:08:48 +0800 X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE VÐßD.1712.3 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0" Content-Transfer-Encoding: 7bit Message-ID: <200008281108777.SM00324@host> Date: Sun, 27 Aug 2000 20:37:21 -0500 Reply-To: Mel Kinis Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Mel Kinis Subject: [MOBILE-IP] Your Net X-To: list28js@hosaka.smallworks.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a MIME Message ------=_NextPart_000_007F_01BDF6C7.FABAC1B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0" ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ***** This is an HTML Message ! ***** ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Executive Guild Membership ApplicationResponse-O-Matic Form Dear Candidate,

You were recently selected by The Office of the Managing
Director for a free listing on The International Executive
Who's Who=2E

Our Researchers gather information from many recognized
sources, including professional associations and societies,
trade organizations, newspaper and magazine articles,
professional reference publications, web presence, and
referrals from existing members=2E

As a highly respected professional in your field of
expertise, we believe your contributions merit very
serious consideration for inclusion on The International
Executive Who's Who=2E  To maintain the highest
level of accuracy, we ask you fill out the brief bit of
information below required for inclusion=2E

There is no cost or obligation to be listed on The
International Executive Who's Who=2E
 

My Sincere Thanks,

Lorraine A=2E Michaels
Office Of Managing Director


The International Executive Who's Who is not affiliated or associated with Marquis Who's Who=2E

If you wish to be removed from our list, please submit your request
at the bottom of this email=2E
International Executive Who's Who
Registration Form
(US and Canada Only)
Please fill out this form if you would like to be included on The International Executive Who's Who=2E For accuracy and publication purposes, please complete and send this form at the earliest opportunity=2E There is no charge or obligation to be listed on The International Executive Who's Who=2E
Your Name
Your Company
Title
Address
City
State or Province
Country
ZIP/Postal Code
Day Time Telephone
Home Phone
 (Not To Be Published)
Email

TO HELP US IN CONSIDERING YOUR APPLICATION, PLEASE TELL US A LITTLE ABOUT YOURSELF=2E=2E=2E
Your Business
(Financial Svcs, Banking, Computer Hardware, Software, Professional Svcs, Chemicals, Apparel, Aerospace, Food, Government, Utility, etc=2E)
Type of Organization
(M= fg, Dist/Wholesaler, Retailer, Law Firm,
Investment Bank, Commercial Bank, University,
Financial Consultants, Ad Agency, Contractor, Broker, etc=2E)
Your Business Expertise
(Corp=2EMgmt, Marketing, Civil Engineering,
Tax Law, Nuclear Physics, Database Development, Operations, Pathologist, Mortgage Banking, etc=2E)
Major Product Line
(Integrated Circuits, Commercial Aircraft, Adhesives, Cosmetics, Plastic Components, Snack Foods, etc=2E)


Note: Submitting this form= will be made by email, not by use of www=2E  Confirmation of its delivery= is made by browsing your outgoing mail=2E

Thank you for filling in this form, we will contact you with more information=2E

The International Executive is not affiliated or associated with Marquis Who's Who=2E

List Removal
Click Here
------=_NextPart_001_0080_01BDF6C7.FABAC1B0-- ------=_NextPart_000_007F_01BDF6C7.FABAC1B0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Aug 28 07:21:10 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03438 for ; Mon, 28 Aug 2000 07:21:09 -0400 (EDT) Received: from standards (47.234.32.16:3082) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C666@standards.nortelnetworks.com>; Mon, 28 Aug 2000 7:08:01 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 35364 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 28 Aug 2000 07:08:01 -0400 Received: from smtp1.cluster.oleane.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C665@standards.nortelnetworks.com>; Mon, 28 Aug 2000 7:08:00 -0400 Received: from oleane (dyn-1-1-234.Vin.dialup.oleane.fr [195.25.4.234]) by smtp1.cluster.oleane.net with SMTP id NAA60440; Mon, 28 Aug 2000 13:20:02 +0200 (CEST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01EC_01C010F2.109F9DC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: <01ff01c010e1$de0db460$0401a8c0@oleane.com> Date: Mon, 28 Aug 2000 13:15:41 +0200 Reply-To: Peter Lewis Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Peter Lewis Subject: [MOBILE-IP] MPLS World To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_01EC_01C010F2.109F9DC0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MPLS World, third edition, Paris 6-9 February. The most important conference, with more than 700 delegates. Speakers may still submit papers untill september 15th. =20 MPLS World is also the largest exhibition in this area. =20 Please take a look on: http://www.upperside.fr/congress/conf.htm =20 ------=_NextPart_000_01EC_01C010F2.109F9DC0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
MPLS World, third edition, Paris 6-9 = February.
The most = important=20 conference, with more than 700 delegates.
Speakers may = still submit=20 papers untill september 15th.
 
MPLS World is also the largest exhibition in this=20 area.
 
Please take a look on:
 
http://www.upperside.f= r/congress/conf.htm
 
------=_NextPart_000_01EC_01C010F2.109F9DC0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Aug 28 08:20:54 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05382 for ; Mon, 28 Aug 2000 08:20:54 -0400 (EDT) Received: from standards (47.234.32.16:1390) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C6AB@standards.nortelnetworks.com>; Mon, 28 Aug 2000 8:07:33 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 35452 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 28 Aug 2000 08:07:33 -0400 Received: from agni.wipinfo.soft.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C6AA@standards.nortelnetworks.com>; Mon, 28 Aug 2000 7:57:27 -0400 Received: from vayu.wipinfo.soft.net (vayu [192.168.200.170]) by agni.wipinfo.soft.net (8.9.3/8.9.3) with ESMTP id RAA00871 for ; Mon, 28 Aug 2000 17:35:10 +0500 (GMT) Received: from sarovar.mail.wipro.com ([192.168.2.18]) by vayu.wipinfo.soft.net (8.9.3/8.9.3) with ESMTP id RAA06664 for ; Mon, 28 Aug 2000 17:37:58 +0500 (GMT) Received: from yaksha.wipinfo.soft.net ([192.168.2.78]) by sarovar.mail.wipro.com (Netscape Messaging Server 3.6) with ESMTP id AAA3211 for ; Mon, 28 Aug 2000 17:38:45 +0530 X-Sender: sharadj@yaksha.wipinfo.soft.net MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Mon, 28 Aug 2000 17:40:51 +0530 Reply-To: Sharad Joshi Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Sharad Joshi Subject: [MOBILE-IP] Hardware address Question To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi, This may be a trivial question, but important for me. So here i go.. How does the mobile node finds out the hardware address of a newly found FA, to which it has to send registration requests? I mean if the link layer does not provide for storing of the address of the received packet, and if the MN uses ARP to find out the hardware address of the FA, it can not send the ARP request since it can not broadcast it over the net (acc to rfc 2002, Page 64). So how does it send the registration request over the link. TIA, Sharad. P.S. Kindly Cc the responses to me, I am not subscribed to the list. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Aug 28 09:36:00 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08223 for ; Mon, 28 Aug 2000 09:35:59 -0400 (EDT) Received: from standards (47.234.32.16:3583) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C717@standards.nortelnetworks.com>; Mon, 28 Aug 2000 9:22:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 35585 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 28 Aug 2000 09:22:55 -0400 Received: from smtpgw2.sprintspectrum.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C716@standards.nortelnetworks.com>; Mon, 28 Aug 2000 9:22:55 -0400 Received: from pkcex004.sprintspectrum.com (pkcex004.sprintspectrum.com [208.10.75.139]) by smtpgw2.sprintspectrum.com (8.9.3/8.9.3) with ESMTP id IAA18625; Mon, 28 Aug 2000 08:35:27 -0500 (CDT) Received: by PKCEX004 with Internet Mail Service (5.5.2650.21) id ; Mon, 28 Aug 2000 08:35:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <2D11BCC7FFD8D3118FD70000D1ECDC8802FAE407@pkcexv018.sprintspectrum.com> Date: Mon, 28 Aug 2000 08:35:16 -0500 Reply-To: "Lipford, Mark" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Lipford, Mark" Subject: Re: [MOBILE-IP] draft-ietf-mobileip-3gwireless-ext-04 X-To: Gopal Kailad To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Your rationale is correct. This is to look beyond PPP as the framing, but was developed to be more generic. The first implementation of this will be with PPP in a cdma2000 network for connection from the radio access network to the PDSN. I am sure there could be other implementations, but this is all that we are aware of at this time. Mark A. Lipford -----Original Message----- From: Gopal Kailad [mailto:gopal@TORRENTNET.COM] Sent: Saturday, August 26, 2000 12:38 AM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: [MOBILE-IP] draft-ietf-mobileip-3gwireless-ext-04 What is the rationale for choosing GRE instead of L2TP to tunnel PPP? It will be useful to add it to the draft. Since L2TP has call setup support, there would have been no need to overload the mobile IP registration mechanism to setup GRE tunnels. Also, L2TP has support for in order delivery using sequence numbers, and there would have been no need for adding sequence number support to GRE after it was deprecated. One possible advantage with GRE is future support for tunneling IP instead of PPP, if the PDSN talks IP with the MN. Is there any other benefit? This has probably been discussed in the mailing list, but I have been following this list only recently, and I could not get the rationale from the mailing list archives (may be I did not go back far enough!) Anyways I think this information is useful to have in the draft. Also, if GRE is going to be used to tunnel PPP, will escape characters, framing, and FCS be carried all the way to the PDSN? Cheers, Gopal From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Aug 28 22:50:11 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25757 for ; Mon, 28 Aug 2000 22:50:10 -0400 (EDT) Received: from standards (47.234.32.16:1921) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C927@standards.nortelnetworks.com>; Mon, 28 Aug 2000 22:36:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 36256 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 28 Aug 2000 22:36:51 -0400 Received: from hansolm (210.112.10.141:25058) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8C924@standards.nortelnetworks.com>; Mon, 28 Aug 2000 22:26:50 -0400 Received: from ns ([210.112.7.7]) by hansolm with Microsoft SMTPSVC(5.5.1877.197.19); Tue, 29 Aug 2000 11:37:00 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: <001301c01162$66c30d20$d012060a@hansol.co.kr> Date: Tue, 29 Aug 2000 11:39:49 +0900 Reply-To: "Lee, Jiwoong" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Lee, Jiwoong" Subject: [MOBILE-IP] [Q] Multicast preference for Mobile IP To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit In the past, there was an ID for multicast preference for mobile ip. What was the main reason it was expired ? Where can I get a copy of it ? TIA, Jiwoong Lee From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 10:35:02 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19458 for ; Tue, 29 Aug 2000 10:35:02 -0400 (EDT) Received: from standards (47.234.32.16:4966) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8CC7E@standards.nortelnetworks.com>; Tue, 29 Aug 2000 10:19:07 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37346 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 10:19:06 -0400 Received: from motgate2.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8CC7D@standards.nortelnetworks.com>; Tue, 29 Aug 2000 10:19:01 -0400 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id HAA08382 for ; Tue, 29 Aug 2000 07:31:40 -0700 (MST)] Received: [from il75exm02.cig.mot.com (IL75EXM02.cig.mot.com [136.182.110.102]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id HAA12798 for ; Tue, 29 Aug 2000 07:31:40 -0700 (MST)] Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2650.21) id ; Tue, 29 Aug 2000 09:31:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Tue, 29 Aug 2000 09:31:28 -0500 Reply-To: Roberts Phil-QA3445 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Roberts Phil-QA3445 Subject: Re: [MOBILE-IP] charter review X-To: Sandy Thuel To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi Sandy, I'm sorry it has taken so long to respond to this email. What we have in mind I believe are protocol extensions to mobile-ip that are based on existing mobile-ip entities such as foreign agents and home agents, extend messages that are already used, and rely on some kind of encapsulation or tunneling in a way that is similar to what is being done today. Developing protocols that rely on some form of host routing or application level address management for example would be beyond the scope of the group. That's not to say some might find such an approach useful in certain settings but that the mobile ip working group has its hands full and won't be considering these kinds of approaches. Is that clear enough? Phil > -----Original Message----- > From: Sandy Thuel [mailto:thuel@LUCENT.COM] > Sent: Wednesday, August 23, 2000 11:23 AM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] charter review > > > > > > The chairs would like to refocus the Mobile IP WG objectives to > > protocols and solutions that are based on Mobile IP v4 and v6. > > Can someone please explain CLEARLY how you determine whether or not > "protocols and solutions" are based on > Mobile IP and are therefore, within the scope of the > mobileip WG charter? (e.g. do they have to be rfc2002 > compliant?) > > Thanks, > Sandy > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Aug 29 10:35:03 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19461 for ; Tue, 29 Aug 2000 10:35:02 -0400 (EDT) Received: from standards (47.234.32.16:4966) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8CCA7@standards.nortelnetworks.com>; Tue, 29 Aug 2000 10:21:38 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37321 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Aug 2000 10:21:37 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8CC6C@standards.nortelnetworks.com>; Tue, 29 Aug 2000 10:11:37 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19021; Tue, 29 Aug 2000 10:24:10 -0400 (EDT) Message-ID: <200008291424.KAA19021@ietf.org> Date: Tue, 29 Aug 2000 10:24:09 -0400 Reply-To: The IESG Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: RFC822 error: CC field duplicated. Last occurrence was retained. Comments: RFC822 error: CC field duplicated. Last occurrence was retained. Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: The IESG Subject: [MOBILE-IP] Document Action: Mobile IP Authentication, Authorization, and Accounting Requirements to Informational To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM The IESG has approved the Internet-Draft 'Mobile IP Authentication, Authorization, and Accounting Requirements' as an Informational RFC. This document is the product of the IP Routing for Wireless/Mobile Hosts Working Group. The IESG contact persons are David Oran and Rob Coltun. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Aug 30 01:37:55 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12209 for ; Wed, 30 Aug 2000 01:37:55 -0400 (EDT) Received: from standards (47.234.32.16:3159) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D7C5@standards.nortelnetworks.com>; Wed, 30 Aug 2000 1:24:33 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3061 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 30 Aug 2000 01:24:33 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D7C4@standards.nortelnetworks.com>; Wed, 30 Aug 2000 1:14:32 -0400 Received: from oemcomputer (ACA178F9.ipt.aol.com [172.161.120.249]) by hosaka.smallworks.com (8.9.1/8.9.1) with SMTP id AAA03444 for ; Wed, 30 Aug 2000 00:27:11 -0500 (CDT) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <200008300527.AAA03444@hosaka.smallworks.com> Date: Wed, 30 Aug 2000 01:24:33 -0400 Reply-To: ClubHunter Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: ClubHunter Subject: [MOBILE-IP] ClubHunter - Golf Club Protection System X-To: mobile-ip@smallworks.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a one time email transmission. Under Bill S1618 Title III passed by the 105th Congress, this email cannot be considered spam if contact and removal information is provided. ************************************************************************************************* AS SEEN IN - 'Golf For Women' Magazine ************************************************************************************************* ClubHunter has the only Golf Club Protection System in the Industry. Have you ever returned from a round of golf and realized..."where is my 8 iron?" I have; and so have many others. Golf courses around the world have 'lost-club' barrels that are overflowing with countless clubs from years of collections. But they are never returned to their rightful owner. Many times they end up in the hands of the foursome three holes back that found it, and decided to keep it. NOT ANY MORE Register with ClubHunter and let us help you locate your lost or stolen iron or wood. If we can't locate it, we will ship you a replacement club at NO COST TO YOU. That's right, with ClubHunter your complete set is registered in our network. If your club is lost or stolen, our contact information allows the finder to contact us and we arrange to have the club returned to you. If after three weeks the club never surfaces, we will ship you an identical replacement at NO COST. Individual plans for only $49.00 annually; family plans for only $99.00 annually. See our web site for complete registration details: http://www.ntl-fb.com ************************************************************************************************* to be removed; reply with remove in the subject headline From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Aug 30 02:50:57 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21461 for ; Wed, 30 Aug 2000 02:50:56 -0400 (EDT) Received: from standards (47.234.32.16:2332) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D83C@standards.nortelnetworks.com>; Wed, 30 Aug 2000 2:36:23 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3217 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 30 Aug 2000 02:36:23 -0400 Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D83B@standards.nortelnetworks.com>; Wed, 30 Aug 2000 2:36:22 -0400 Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com [172.18.242.183]) by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e7U6leY09969 for ; Wed, 30 Aug 2000 09:47:40 +0300 (EET DST) Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id ; Wed, 30 Aug 2000 01:47:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B0207F174@daeis07nok> Date: Wed, 30 Aug 2000 01:44:37 -0500 Reply-To: Basavaraj.Patil@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: [MOBILE-IP] Charter Update (Micromobility) To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi folks. Since we didn't get much pushback on dropping micromobility from the charter we've decided to do so. That means the following bullet will be removed from the charter: Additional IP-based solutions for micro mobility (movement within a subnet). And the drafts that follow will no longer be working group items and should be resubmitted to the draft directory as individual contributions: draft-ietf-mobileip-cellularip-00.txt draft-ietf-mobileip-hawaii-01.txt draft-ietf-mobileip-paging-hawaii-01.txt Phil and Raj From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Aug 30 08:22:42 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25983 for ; Wed, 30 Aug 2000 08:22:42 -0400 (EDT) Received: from standards (47.234.32.16:4661) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D9E0@standards.nortelnetworks.com>; Wed, 30 Aug 2000 8:09:26 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3772 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 30 Aug 2000 08:09:25 -0400 Received: from prue.eim.surrey.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8D9DF@standards.nortelnetworks.com>; Wed, 30 Aug 2000 7:59:25 -0400 Received: from carter-e0.ee.surrey.ac.uk ([131.227.86.16] helo=ee.surrey.ac.uk) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 13U6it-0003VG-00 for mobile-ip@standards.nortelnetworks.com; Wed, 30 Aug 2000 13:12:07 +0100 X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------1C859B184790AD42A906A00A" Message-ID: <39ACFA17.3ADC4595@ee.surrey.ac.uk> Date: Wed, 30 Aug 2000 13:12:07 +0100 Reply-To: m.gkizeli@EIM.SURREY.AC.UK Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Maria Gkizeli Organization: University of Surrey, Guildford, England Subject: [MOBILE-IP] your_last_name To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --------------1C859B184790AD42A906A00A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit subscribe mobile-ip first_name last_name subscribe mobile-ip Maria Gkizeli -- *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=* MARIA GKIZELI Mobile Comms Research Group, CCSR, University of Surrey, Guildford, GU2 7XH, Surrey, U.K Tel: +44-1483-873036, Fax: +44-1483-876011 Email:M.Gkizeli@eim.surrey.ac.uk *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=**=*=*=*=*=*=*=*=*=*=*=* --------------1C859B184790AD42A906A00A Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit subscribe mobile-ip first_name last_name

subscribe mobile-ip     Maria Gkizeli 

-- 
 *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
                           MARIA GKIZELI
                    Mobile Comms Research Group,
                    CCSR, University of Surrey,
                   Guildford, GU2 7XH, Surrey, U.K

                Tel: +44-1483-873036, Fax: +44-1483-876011
                      Email:M.Gkizeli@eim.surrey.ac.uk
 *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=**=*=*=*=*=*=*=*=*=*=*=*
  --------------1C859B184790AD42A906A00A-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Aug 30 09:16:37 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28336 for ; Wed, 30 Aug 2000 09:16:36 -0400 (EDT) Received: from standards (47.234.32.16:4661) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8DB1B@standards.nortelnetworks.com>; Wed, 30 Aug 2000 9:03:20 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4132 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 30 Aug 2000 09:03:20 -0400 Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8DAFA@standards.nortelnetworks.com>; Wed, 30 Aug 2000 8:53:20 -0400 Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Wed Aug 30 09:05:02 EDT 2000 Received: from valjean.dnrc.bell-labs.com (IDENT:root@valjean [135.180.240.120]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id JAA04993 for ; Wed, 30 Aug 2000 09:05:02 -0400 (EDT) Received: (from salga@localhost) by valjean.dnrc.bell-labs.com (8.9.3/8.8.7) id JAA05692 for MOBILE-IP@standards.nortelnetworks.com; Wed, 30 Aug 2000 09:05:02 -0400 Mail-Followup-To: MOBILE-IP@standards.nortelnetworks.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i X-Organization: Bell Laboratories X-To: Roberts Phil-QA3445 Message-ID: <20000830090502.E5411@bell-labs.com> Date: Wed, 30 Aug 2000 09:05:02 -0400 Reply-To: Luca Salgarelli Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Luca Salgarelli Subject: Re: [MOBILE-IP] charter review To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: ; from qa3445@EMAIL.MOT.COM on Tue, Aug 29, 2000 at 09:31:28AM -0500 Hi Phil. I apologize if this will be a naive question, but I guess I am not an expert on IETF procedures. I think it is now clear what were the technological criteria for deciding the new charter (no host-based routing or non-tunneling-based approaches will be handled by the Mobile-IP WG), but I do not understand how the WG arrived to the selection of such criteria. I do not remember any major discussion on these criteria being held on the mailing list. I think there are some undeniable technological benefits in avoiding tunnels in some parts of a wireless network (I am thinking at access-networks in particular), such as better efficiency in the usage of the air interface. In my opinion, ruling out such approaches without having a proper technical discussion within the WG could hurt the WG output in the long run. Just my 2 cents about re-chartering. Thanks Luca On Tue, Aug 29, 2000 at 09:31:28AM -0500, Roberts Phil-QA3445 wrote: > Hi Sandy, > > I'm sorry it has taken so long to respond to this email. > > What we have in mind I believe are protocol extensions to mobile-ip > that are based on existing mobile-ip entities such as foreign agents and > home agents, extend messages that are already used, and rely on some kind of > encapsulation or tunneling in a way that is similar to what is being done > today. Developing protocols that rely on some form of host routing or > application level address management for example would be beyond the scope > of the group. That's not to say some might find such an approach useful in > certain settings but that the mobile ip working group has its hands full and > won't be considering these kinds of approaches. Is that clear enough? > > Phil > > > > -----Original Message----- > > From: Sandy Thuel [mailto:thuel@LUCENT.COM] > > Sent: Wednesday, August 23, 2000 11:23 AM > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: [MOBILE-IP] charter review > > > > > > > > > > The chairs would like to refocus the Mobile IP WG objectives to > > > protocols and solutions that are based on Mobile IP v4 and v6. > > > > Can someone please explain CLEARLY how you determine whether or not > > "protocols and solutions" are based on > > Mobile IP and are therefore, within the scope of the > > mobileip WG charter? (e.g. do they have to be rfc2002 > > compliant?) > > > > Thanks, > > Sandy > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Aug 30 10:49:34 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00899 for ; Wed, 30 Aug 2000 10:49:34 -0400 (EDT) Received: from standards (47.234.32.16:1371) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8DC32@standards.nortelnetworks.com>; Wed, 30 Aug 2000 10:36:06 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4531 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 30 Aug 2000 10:36:06 -0400 Received: from alemail1.firewall.lucent.com (alemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8DC31@standards.nortelnetworks.com>; Wed, 30 Aug 2000 10:36:04 -0400 Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA08725 for ; Wed, 30 Aug 2000 10:48:46 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA08714 for ; Wed, 30 Aug 2000 10:48:46 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Wed, 30 Aug 2000 15:48:45 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: <976F7C55E3B2D111A0720008C728549C048770ED@en0060exch001u.uk.lucent.com> Date: Wed, 30 Aug 2000 15:48:44 +0100 Reply-To: "Casati, Alessio (Alessio)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Casati, Alessio (Alessio)" Subject: Re: [MOBILE-IP] charter review X-To: Luca Salgarelli To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM I believe the WG want to get focused on the revised charter to finalize outstanding urgent matters. If the need for further work in the area you are describing is felt necessary then a BOF and a new WG should be the way to go at this stage. I believe there's no value judgement on the "demoted" drafts in the WG decision to get more focused. In the end, the mobile IP WG deserves to retire, as any other WG. alessio > ---------- > From: Luca Salgarelli[SMTP:lsalgarelli@BELL-LABS.COM] > Reply To: Luca Salgarelli > Sent: 30 August 2000 14:05 > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] charter review > > Hi Phil. > > I apologize if this will be a naive question, but I guess I am not an > expert on IETF procedures. > > I think it is now clear what were the technological criteria for deciding > the new charter (no host-based routing or non-tunneling-based approaches > will be handled by the Mobile-IP WG), but I do not understand how the WG > arrived to the selection of such criteria. I do not remember any major > discussion on these criteria being held on the mailing list. > > I think there are some undeniable technological benefits in avoiding > tunnels > in some parts of a wireless network (I am thinking at access-networks in > particular), such as better efficiency in the usage of the air interface. > In my opinion, ruling out such approaches without having a proper > technical > discussion within the WG could hurt the WG output in the long run. > > Just my 2 cents about re-chartering. > > Thanks > Luca > > On Tue, Aug 29, 2000 at 09:31:28AM -0500, Roberts Phil-QA3445 wrote: > > Hi Sandy, > > > > I'm sorry it has taken so long to respond to this email. > > > > What we have in mind I believe are protocol extensions to > mobile-ip > > that are based on existing mobile-ip entities such as foreign agents and > > home agents, extend messages that are already used, and rely on some > kind of > > encapsulation or tunneling in a way that is similar to what is being > done > > today. Developing protocols that rely on some form of host routing or > > application level address management for example would be beyond the > scope > > of the group. That's not to say some might find such an approach useful > in > > certain settings but that the mobile ip working group has its hands full > and > > won't be considering these kinds of approaches. Is that clear enough? > > > > Phil > > > > > > > -----Original Message----- > > > From: Sandy Thuel [mailto:thuel@LUCENT.COM] > > > Sent: Wednesday, August 23, 2000 11:23 AM > > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: [MOBILE-IP] charter review > > > > > > > > > > > > > > The chairs would like to refocus the Mobile IP WG objectives to > > > > protocols and solutions that are based on Mobile IP v4 and v6. > > > > > > Can someone please explain CLEARLY how you determine whether or not > > > "protocols and solutions" are based on > > > Mobile IP and are therefore, within the scope of the > > > mobileip WG charter? (e.g. do they have to be rfc2002 > > > compliant?) > > > > > > Thanks, > > > Sandy > > > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Aug 30 10:53:47 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01033 for ; Wed, 30 Aug 2000 10:53:47 -0400 (EDT) Received: from standards (47.234.32.16:1371) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8DC70@standards.nortelnetworks.com>; Wed, 30 Aug 2000 10:40:22 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4613 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 30 Aug 2000 10:40:22 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8DC6F@standards.nortelnetworks.com>; Wed, 30 Aug 2000 10:40:22 -0400 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA03022; Wed, 30 Aug 2000 08:53:01 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA09451; Wed, 30 Aug 2000 07:52:58 -0700 (PDT) Received: from darius (darius [129.146.122.100]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA10328; Wed, 30 Aug 2000 07:52:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Wed, 30 Aug 2000 07:52:58 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: Re: [MOBILE-IP] charter review X-To: "Casati, Alessio (Alessio)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <976F7C55E3B2D111A0720008C728549C048770ED@en0060exch001u.uk.lucent.com> Some of us are working on such a BOF. PatC > I believe the WG want to get focused on the revised charter > to finalize outstanding urgent matters. > If the need for further work in the area you are > describing is felt necessary then a BOF and a new WG > should be the way to go at this stage. > I believe there's no > value judgement on the "demoted" drafts in the WG decision > to get more focused. In the end, the mobile IP WG > deserves to retire, as any other WG. > > alessio > > > > ---------- > > From: Luca Salgarelli[SMTP:lsalgarelli@BELL-LABS.COM] > > Reply To: Luca Salgarelli > > Sent: 30 August 2000 14:05 > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: [MOBILE-IP] charter review > > > > Hi Phil. > > > > I apologize if this will be a naive question, but I guess I am not an > > expert on IETF procedures. > > > > I think it is now clear what were the technological criteria for deciding > > the new charter (no host-based routing or non-tunneling-based approaches > > will be handled by the Mobile-IP WG), but I do not understand how the WG > > arrived to the selection of such criteria. I do not remember any major > > discussion on these criteria being held on the mailing list. > > > > I think there are some undeniable technological benefits in avoiding > > tunnels > > in some parts of a wireless network (I am thinking at access-networks in > > particular), such as better efficiency in the usage of the air interface. > > In my opinion, ruling out such approaches without having a proper > > technical > > discussion within the WG could hurt the WG output in the long run. > > > > Just my 2 cents about re-chartering. > > > > Thanks > > Luca > > > > On Tue, Aug 29, 2000 at 09:31:28AM -0500, Roberts Phil-QA3445 wrote: > > > Hi Sandy, > > > > > > I'm sorry it has taken so long to respond to this email. > > > > > > What we have in mind I believe are protocol extensions to > > mobile-ip > > > that are based on existing mobile-ip entities such as foreign agents and > > > home agents, extend messages that are already used, and rely on some > > kind of > > > encapsulation or tunneling in a way that is similar to what is being > > done > > > today. Developing protocols that rely on some form of host routing or > > > application level address management for example would be beyond the > > scope > > > of the group. That's not to say some might find such an approach useful > > in > > > certain settings but that the mobile ip working group has its hands full > > and > > > won't be considering these kinds of approaches. Is that clear enough? > > > > > > Phil > > > > > > > > > > -----Original Message----- > > > > From: Sandy Thuel [mailto:thuel@LUCENT.COM] > > > > Sent: Wednesday, August 23, 2000 11:23 AM > > > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > > > Subject: Re: [MOBILE-IP] charter review > > > > > > > > > > > > > > > > > > The chairs would like to refocus the Mobile IP WG objectives to > > > > > protocols and solutions that are based on Mobile IP v4 and v6. > > > > > > > > Can someone please explain CLEARLY how you determine whether or not > > > > "protocols and solutions" are based on > > > > Mobile IP and are therefore, within the scope of the > > > > mobileip WG charter? (e.g. do they have to be rfc2002 > > > > compliant?) > > > > > > > > Thanks, > > > > Sandy > > > > > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Aug 30 10:57:18 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01130 for ; Wed, 30 Aug 2000 10:57:17 -0400 (EDT) Received: from standards (47.234.32.16:1371) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8DCAE@standards.nortelnetworks.com>; Wed, 30 Aug 2000 10:43:59 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4697 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 30 Aug 2000 10:43:59 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8DCAD@standards.nortelnetworks.com>; Wed, 30 Aug 2000 10:43:59 -0400 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 HAA28354; Wed, 30 Aug 2000 07:56:41 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e7UEucg08317; Wed, 30 Aug 2000 07:56:38 -0700 X-Virus-Scanned: Wed, 30 Aug 2000 07:56:38 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdLUtRbq; Wed, 30 Aug 2000 07:56:28 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <976F7C55E3B2D111A0720008C728549C048770ED@en0060exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39AD209E.9727F955@iprg.nokia.com> Date: Wed, 30 Aug 2000 07:56:30 -0700 Reply-To: charliep@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: Re: [MOBILE-IP] charter review X-To: "Casati, Alessio (Alessio)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Alessio, Judging from the distance between need and deployment for Mobile IP, it seems we have a very long way to go before retirement. I'm also not very comfortable about disallowing host-route based approaches for Mobile IP. I am comfortable with focussing the effort on specifications that use Mobile IP messages possibly with new extensions. However, it seems to me that some new extension might specify some behavior related to host routing. Regards, Charlie P. "Casati, Alessio (Alessio)" wrote: > > I believe the WG want to get focused on the revised charter > to finalize outstanding urgent matters. > If the need for further work in the area you are > describing is felt necessary then a BOF and a new WG > should be the way to go at this stage. > I believe there's no > value judgement on the "demoted" drafts in the WG decision > to get more focused. In the end, the mobile IP WG > deserves to retire, as any other WG. > > alessio > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Aug 30 13:31:04 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05361 for ; Wed, 30 Aug 2000 13:31:04 -0400 (EDT) Received: from standards (47.234.32.16:4864) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E01F@standards.nortelnetworks.com>; Wed, 30 Aug 2000 13:17:48 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5964 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 30 Aug 2000 13:17:47 -0400 Received: from chntva1-smrly1.gtei.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E01E@standards.nortelnetworks.com>; Wed, 30 Aug 2000 13:17:47 -0400 Received: from deptvass2-cp.va.gov (deptvass2-cp.va.gov [205.128.215.121]) by chntva1-smrly1.gtei.net (Postfix) with SMTP id C9D3741E1 for ; Wed, 30 Aug 2000 17:30:22 +0000 (GMT) Received: from 152.129.1.69 by vhaishmul3.med.va.gov (InterScan E-Mail VirusWall NT); Wed, 30 Aug 2000 12:32:35 -0500 (Central Daylight Time) Received: by vhaishhbexc3.med.va.gov with Internet Mail Service (5.5.2448.0) id ; Wed, 30 Aug 2000 12:30:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C012A7.EDEBF078" Message-ID: <2A5485D1C9C7D311816F0000F805ADB7697047@vhapugexc1.med.va.gov> Date: Wed, 30 Aug 2000 12:32:17 -0500 Reply-To: "Kay, Rodney" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Kay, Rodney" Subject: Re: [MOBILE-IP] Local Mobility Agents in IPv6 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM 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_000_01C012A7.EDEBF078 Content-Type: text/plain; charset="iso-8859-1" The concept of a Local Mobility Agent (LMA) which acts as a reference point for the MN to the HA/CN seems to be fulfilling the same function as the FA in IPv4, but I am unclear how latency is improved by "The MN registers back with the HA using the LMA CoA, and anchors with the LMA as it moves in foreign domains." It would seem that the possibility would exist for the MN to switch LMA anchors prior to the HA/CN effecting the CoA change. Would it be possible that the LMA could also be satellite based? Rodney H. Kay Department of Veterans Affairs Puget Sound Health Care System Systems Manager Seattle, Washington 98108 <> ------_=_NextPart_000_01C012A7.EDEBF078 Content-Type: application/octet-stream; name="Kay, Rodney.vcf" Content-Disposition: attachment; filename="Kay, Rodney.vcf" BEGIN:VCARD VERSION:2.1 N:Kay;Rodney FN:Kay, Rodney ORG:Department of Veterans Affairs;VHA TITLE:VistA Systems Manager TEL;WORK;VOICE:(206)768-5482 ADR;WORK;ENCODING=QUOTED-PRINTABLE:;Seattle VAMC;Puget Sound HC System=0D=0A1660 S. Columbian Way;Seattle;WA;98= 108-1597;USA LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Seattle VAMC=0D=0APuget Sound HC System=0D=0A1660 S. Columbian Way=0D=0ASeat= tle, WA 98108-1597=0D=0AUSA EMAIL;PREF;INTERNET:Rodney.Kay@med.va.gov REV:20000803T182959Z END:VCARD ------_=_NextPart_000_01C012A7.EDEBF078-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Aug 30 14:06:42 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06153 for ; Wed, 30 Aug 2000 14:06:41 -0400 (EDT) Received: from standards (47.234.32.16:4864) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E097@standards.nortelnetworks.com>; Wed, 30 Aug 2000 13:53:19 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6114 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 30 Aug 2000 13:53:19 -0400 Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E091@standards.nortelnetworks.com>; Wed, 30 Aug 2000 13:43:19 -0400 Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Wed Aug 30 13:55:27 EDT 2000 Received: from blhothuelpc (thuelpc [135.180.240.114]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id NAA19612; Wed, 30 Aug 2000 13:55:26 -0400 (EDT) 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 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Message-ID: <000901c012ab$4f1556c0$72f0b487@dnrc.belllabs.com> Date: Wed, 30 Aug 2000 13:54:14 -0400 Reply-To: Sandy Thuel Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Sandy Thuel Subject: Re: [MOBILE-IP] charter review X-To: charliep@IPRG.NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <39AD209E.9727F955@iprg.nokia.com> Content-Transfer-Encoding: 7bit Hi Charlie, > I'm also not very comfortable about disallowing host-route > based approaches for Mobile IP. I am comfortable with > focussing the effort on specifications that use Mobile IP > messages possibly with new extensions. However, it seems > to me that some new extension might specify some behavior > related to host routing. This is precisely the issue that is unclear. It makes absolute sense to focus the WG efforts on specifications that solely use Mobile IP messages (whether extended or not). But outruling the use of host routing methods may be a costly and unnecessary restriction. Sandy From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Aug 31 05:58:10 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02512 for ; Thu, 31 Aug 2000 05:58:10 -0400 (EDT) Received: from standards (47.234.32.16:2075) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E579@standards.nortelnetworks.com>; Thu, 31 Aug 2000 5:44:40 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7744 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 31 Aug 2000 05:44:40 -0400 Received: from explore.kwangwoon.ac.kr (128.134.70.30:39023) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E578@standards.nortelnetworks.com>; Thu, 31 Aug 2000 5:34:39 -0400 Received: from eos (eos.kwangwoon.ac.kr [128.134.56.162]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id SAA29745 for ; Thu, 31 Aug 2000 18:44:43 +0900 (KST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C0137C.0C04FDA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: <000f01c01330$9cb2dee0$a2388680@kwangwoon.ac.kr> Date: Thu, 31 Aug 2000 18:48:26 +0900 Reply-To: SungJin Lee Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: SungJin Lee Subject: [MOBILE-IP] questions for cellular IP and 3G network To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C0137C.0C04FDA0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 US4xICAgSW4gdGhlIGNlbGx1bGFyIElQIGFyY2hpdGVjdHVyZSwgQlNzIGFyZSBjb25uZWN0ZWQg ZWFjaCBvdGhlciBoaWVyYXJjaGljYWxseQ0KICAgICAgICBhbmQgcGFja2V0IGlzIHJvdXRlZCB1 c2luZyB0aGUgY2FjaGUgb2YgQlNzLiBIb3dldmVyIGkgY291bGRuJ3QgZmluZCB0aGF0DQogICAg ICAgIGtpbmQgb2YgdG9wb2xvZ3kgaW4gdGhlIHJhZGlvIG5ldHdvcmsgYXJjaGl0ZWN0dXJlLiBJ dCB1c3VhbGx5IGhhcyBkZWRpY2F0ZWQgDQogICAgICAgIGNvbm5lY3Rpb24gYmV0d2VlbiBNU0Mg YW5kIEJTLiBXaGF0IGFtIGkgd3Jvbmcgd2l0aCB0aGF0IGlkZWEgPyBJIHRoaW5rIA0KICAgICAg ICBtaWdodCBtaXN1bmRlcnN0YW5kIHRoZSByYWRpbyBuZXR3b3JrIGlmIHRoZSBjZWxsdWxhciBJ UCBpcyByaWdodC4NCg0KUS4yICBJbiB0aGUgM0cgbmV0d29yaywgTUlQIGlzIHN1cHBvcnRlZCB3 aXRoIEdHU04uIFRoZW4gR0dTTiBtYXRjaGVzIEZBIG9mIE1JUCBuZXR3b3JrLg0KICAgICAgICB0 aGVuLCBob3cgbWFueSBtb2JpbGUgbm9kZXMgY291bGQgdGhlIEZBIG1hbmFnZXMgPyBpbiBtb3N0 IHBpY3R1cmVzIG9mIDNnIHJhZGlvIG5ldHdvcmsNCiAgICAgICAgYSBHR1NOIGNvbm5lY3RlZCB0 byBGQS4gSSB0aGluayB0aGUgR0dTTiwgRkEsIGhhcyB0b28gbWFueSBtb2JpbGUgbm9kZXMgaW4g dGhpcyBjb25jZXB0Lg0KICAgICAgICBob3cgbWFueSBtb2JpbGUgbm9kZXMgYXJlIGFwcHJvcHJp YXRlIHVuZGVyIG9uZSBGQSBpbiBNb2JpbGUgSVAgbmV0d29yayA/IG9yIHJhZGlvIG5ldHdyb2su DQoNCg0KDQpyZWdhcmRzLA0KDQpFZGRpZSBMZWUNCg== ------=_NextPart_000_000C_01C0137C.0C04FDA0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjUwLjQxMzQuNjAwIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9I RUFEPg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBzaXplPTI+US4xJm5ic3A7 Jm5ic3A7IEluIHRoZSBjZWxsdWxhciBJUCBhcmNoaXRlY3R1cmUsIEJTcyBhcmUgDQpjb25uZWN0 ZWQgZWFjaCBvdGhlciBoaWVyYXJjaGljYWxseTwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6 ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhbmQgcGFja2V0 IGlzIA0Kcm91dGVkIHVzaW5nIHRoZSBjYWNoZSBvZiBCU3MuIEhvd2V2ZXIgaSBjb3VsZG4ndCBm aW5kIHRoYXQ8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsga2luZCBvZiB0b3BvbG9neSBpbiANCnRoZSByYWRp byBuZXR3b3JrIGFyY2hpdGVjdHVyZS4gSXQgdXN1YWxseSBoYXMgZGVkaWNhdGVkIDwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBjb25uZWN0aW9uIGJldHdlZW4gDQpNU0MmbmJzcDthbmQgQlMuIFdoYXQgYW0g aSB3cm9uZyB3aXRoIHRoYXQgaWRlYSA/IEkgdGhpbmsgPC9GT05UPjwvRElWPg0KPERJVj48Rk9O VCBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1pZ2h0 IG1pc3VuZGVyc3RhbmQgDQp0aGUgcmFkaW8gbmV0d29yayBpZiB0aGUgY2VsbHVsYXIgSVAgaXMg cmlnaHQuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElW Pg0KPERJVj48Rk9OVCBzaXplPTI+US4yJm5ic3A7Jm5ic3A7SW4gdGhlIDNHIG5ldHdvcmssJm5i c3A7TUlQIGlzIHN1cHBvcnRlZCB3aXRoIA0KR0dTTi4gVGhlbiBHR1NOIG1hdGNoZXMgRkEmbmJz cDs8L0ZPTlQ+PEZPTlQgc2l6ZT0yPm9mIE1JUCBuZXR3b3JrLjwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0 aGVuLCBob3cgbWFueSANCm1vYmlsZSBub2RlcyZuYnNwO2NvdWxkIHRoZSBGQSZuYnNwO21hbmFn ZXMgPyBpbiBtb3N0IHBpY3R1cmVzIG9mIDNnIHJhZGlvIA0KbmV0d29yazwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwO2EgDQpHR1NOJm5ic3A7Y29ubmVjdGVkIHRvIEZBLiBJIHRoaW5rIHRoZSBHR1NO LCBGQSwgaGFzIHRvbyBtYW55IG1vYmlsZSBub2RlcyBpbiANCnRoaXMmbmJzcDtjb25jZXB0Ljwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBob3cgbWFueSBtb2JpbGUgDQpub2RlcyBhcmUgYXBwcm9wcmlhdGUm bmJzcDt1bmRlciBvbmUgRkEgaW4gTW9iaWxlIElQIG5ldHdvcmsgPyBvciByYWRpbyANCm5ldHdy b2suPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0K PERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4N CjxESVY+PEZPTlQgc2l6ZT0yPnJlZ2FyZHMsPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXpl PTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+RWRkaWUmbmJzcDtMZWU8 L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_000C_01C0137C.0C04FDA0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Aug 31 10:51:11 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06971 for ; Thu, 31 Aug 2000 10:51:11 -0400 (EDT) Received: from standards (47.234.32.16:1774) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E6B5@standards.nortelnetworks.com>; Thu, 31 Aug 2000 10:37:31 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8125 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 31 Aug 2000 10:37:31 -0400 Received: from alemail1.firewall.lucent.com (alemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E6B4@standards.nortelnetworks.com>; Thu, 31 Aug 2000 10:37:31 -0400 Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA20309 for ; Thu, 31 Aug 2000 10:50:16 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA20300 for ; Thu, 31 Aug 2000 10:50:16 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Thu, 31 Aug 2000 15:50:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: <976F7C55E3B2D111A0720008C728549C048770EF@en0060exch001u.uk.lucent.com> Date: Thu, 31 Aug 2000 15:50:14 +0100 Reply-To: "Casati, Alessio (Alessio)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Casati, Alessio (Alessio)" Subject: Re: [MOBILE-IP] charter review X-To: "Charles E. Perkins" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > ---------- > From: Charles E. Perkins[SMTP:charliep@iprg.nokia.com] > Sent: 30 August 2000 15:56 > To: Casati, Alessio (Alessio) > Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] charter review > > > Hello Alessio, > > Judging from the distance between need and deployment for > Mobile IP, it seems we have a very long way to go before > retirement. > The more this WG does not get focused, the greater the distance becomes. I believe that's the point, right? alessio From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Aug 31 11:19:20 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07682 for ; Thu, 31 Aug 2000 11:19:19 -0400 (EDT) Received: from standards (47.234.32.16:1774) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E70B@standards.nortelnetworks.com>; Thu, 31 Aug 2000 11:05:58 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8227 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 31 Aug 2000 11:05:58 -0400 Received: from web3902.mail.yahoo.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E700@standards.nortelnetworks.com>; Thu, 31 Aug 2000 10:55:58 -0400 Received: from [216.113.45.133] by web3902.mail.yahoo.com; Thu, 31 Aug 2000 08:08:39 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20000831150839.22241.qmail@web3902.mail.yahoo.com> Date: Thu, 31 Aug 2000 08:08:39 -0700 Reply-To: sarikaya@u-aizu.ac.jp Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Behcet Sarikaya Subject: Re: [MOBILE-IP] charter review X-To: Sandy Thuel To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --- Sandy Thuel wrote: > But outruling the use of > host routing methods may be a costly and unnecessary > restriction. > > Sandy I do not really think so. There is no restriction on someone/some organization building (implementing) a domain be it a HAWAII domain in which host routing is used but Mobile IPv4 with some non standard extensions is supported. At any rate mipv4 is going to go away. --behcet ===== Behcet Sarikaya Univ. of Aizu Aizu, Japan __________________________________________________ Do You Yahoo!? Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Aug 31 11:27:50 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07841 for ; Thu, 31 Aug 2000 11:27:49 -0400 (EDT) Received: from standards (47.234.32.16:1774) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E757@standards.nortelnetworks.com>; Thu, 31 Aug 2000 11:14:28 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8235 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 31 Aug 2000 11:14:28 -0400 Received: from prue.eim.surrey.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E706@standards.nortelnetworks.com>; Thu, 31 Aug 2000 11:04:28 -0400 Received: from carter-e0.ee.surrey.ac.uk ([131.227.86.16]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 13UVyK-0007Qa-00; Thu, 31 Aug 2000 16:09:44 +0100 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Thu, 31 Aug 2000 16:09:44 +0100 Reply-To: Karann Chew Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Karann Chew Subject: Re: [MOBILE-IP] questions for cellular IP and 3G network X-To: SungJin Lee To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <000f01c01330$9cb2dee0$a2388680@kwangwoon.ac.kr> Eddie, I'm not sure if we should still discuss Cellular IP-related stuffs here, due to the ongoing charter review. Anyway... > Q.1 In the cellular IP architecture, BSs are connected each other hierarchically > and packet is routed using the cache of BSs. However i couldn't find that > kind of topology in the radio network architecture. It usually has dedicated > connection between MSC and BS. What am i wrong with that idea ? I think > might misunderstand the radio network if the cellular IP is right. ...you are right, cellular system has a strict hierarchy like GMSC-MSC-BSS, and they are in TREE form. Cellular IP assumes the network elements, especially BSs, enjoys more flexibility, though they are in hierarchical form too (but not necesary in tree). In other works, CIP's architecture/topology/network elements do not completely conform to the CURRENT cellular system. > Q.2 In the 3G network, MIP is supported with GGSN. Then GGSN matches FA of MIP network. > then, how many mobile nodes could the FA manages ? in most pictures of 3g radio network > a GGSN connected to FA. I think the GGSN, FA, has too many mobile nodes in this concept. I think both GGSN and SGSNs match to the FA of MIP, depending on the scenario. GGSN could be thought of as a HA, whereas SGSNs could be considered as FAs which perform update to GGSN (i.e. HA). So, the mobilily management of mobile host is not deal solely by the GGSN. > how many mobile nodes are appropriate under one FA in Mobile IP network ? or radio netwrok. I've no idea. Perhaps people with GPRS implementation/testing experience could answer this. Cheers, Karann ++++++++++++++++++++++++++++++++++++++++++ Karann Chew Mobile Communications Research Group Centre for Communication Systems Research University of Surrey ++++++++++++++++++++++++++++++++++++++++++ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Aug 31 11:34:38 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08053 for ; Thu, 31 Aug 2000 11:34:38 -0400 (EDT) Received: from standards (47.234.32.16:1774) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E7A0@standards.nortelnetworks.com>; Thu, 31 Aug 2000 11:21:17 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8331 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 31 Aug 2000 11:21:17 -0400 Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E74D@standards.nortelnetworks.com>; Thu, 31 Aug 2000 11:11:17 -0400 Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Thu Aug 31 11:22:12 EDT 2000 Received: from blhothuelpc (thuelpc [135.180.240.114]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id LAA25937; Thu, 31 Aug 2000 11:22:11 -0400 (EDT) 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 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Message-ID: <000c01c0135f$10da3290$72f0b487@dnrc.belllabs.com> Date: Thu, 31 Aug 2000 11:20:59 -0400 Reply-To: Sandy Thuel Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Sandy Thuel Subject: Re: [MOBILE-IP] charter review X-To: sarikaya@u-aizu.ac.jp To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <20000831150839.22241.qmail@web3902.mail.yahoo.com> Content-Transfer-Encoding: 7bit The question is NOT whether or not a protocol like HAWAII can or should be implemented in some provider's network. The question is much more fundamental than that: should host based routing be allowed to play a role in mobile IP-based solutions considered by the WG? Sandy > -----Original Message----- > From: Behcet Sarikaya [mailto:bsarikaya_1999@yahoo.com] > Sent: Thursday, August 31, 2000 11:09 AM > To: Sandy Thuel; MOBILE-IP@standards.nortelnetworks.com > Subject: Re: [MOBILE-IP] charter review > > > > --- Sandy Thuel wrote: > > But outruling the use of > > host routing methods may be a costly and unnecessary > > restriction. > > > > Sandy > I do not really think so. > There is no restriction on someone/some organization > building (implementing) a domain be it a HAWAII domain > in which host routing is used but Mobile IPv4 with > some non standard extensions is supported. > > At any rate mipv4 is going to go away. > > --behcet > > ===== > Behcet Sarikaya > Univ. of Aizu > Aizu, Japan > > __________________________________________________ > Do You Yahoo!? > Yahoo! Mail - Free email you can access from anywhere! > http://mail.yahoo.com/ > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Aug 31 11:55:38 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08464 for ; Thu, 31 Aug 2000 11:55:38 -0400 (EDT) Received: from standards (47.234.32.16:1774) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E803@standards.nortelnetworks.com>; Thu, 31 Aug 2000 11:42:19 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8563 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 31 Aug 2000 11:42:19 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E802@standards.nortelnetworks.com>; Thu, 31 Aug 2000 11:42:19 -0400 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA26435 for ; Thu, 31 Aug 2000 09:55:03 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA02768; Thu, 31 Aug 2000 08:55:02 -0700 (PDT) Received: from darius.eng.sun.com (darius [129.146.122.100]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id IAA08629; Thu, 31 Aug 2000 08:54:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Thu, 31 Aug 2000 08:54:56 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: Re: [MOBILE-IP] questions for cellular IP and 3G network X-To: Karann Chew To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" > I'm not sure if we should still discuss Cellular IP-related stuffs here, > due to the ongoing charter review. Anyway... cellular@cdma-2000.org was setup for these types of discussions. See www.cdma-2000.org for more info on the mailing list. PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Aug 31 12:15:49 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08847 for ; Thu, 31 Aug 2000 12:15:49 -0400 (EDT) Received: from standards (47.234.32.16:4374) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E851@standards.nortelnetworks.com>; Thu, 31 Aug 2000 12:02:32 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8666 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 31 Aug 2000 12:02:31 -0400 Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E850@standards.nortelnetworks.com>; Thu, 31 Aug 2000 11:52:31 -0400 Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA19001 for ; Thu, 31 Aug 2000 12:05:16 -0400 (EDT) Received: from marconi.ih.lucent.com (h135-1-120-108.lucent.com [135.1.120.108]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA18989 for ; Thu, 31 Aug 2000 12:05:15 -0400 (EDT) Received: by marconi.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA10907; Thu, 31 Aug 2000 11:05:14 -0500 (CDT) Received: from rjmarkspc by marconi.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA10903; Thu, 31 Aug 2000 11:05:14 -0500 (CDT) Original-To: 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 8.5, Build 4.71.2232.26 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Message-ID: <001e01c01365$3dcf6300$32868318@ce.mediaone.net> Date: Thu, 31 Aug 2000 11:05:09 -0500 Reply-To: rjmarks@lucent.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "R. J. Marks" Subject: Re: [MOBILE-IP] questions for cellular IP and 3G network To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Content-Transfer-Encoding: 7bit Perhaps a more appropriate site to discuss architectures that involve SGSNs and GGSNs would be one related to GPRS and UMTS. The cdma2000 architecture does not include these network elements, but instead uses an element called the PDSN, in which the FA resides. Bob > -----Original Message----- > From: IP Routing for Wireless/Mobile Hosts (mobile-ip) > [mailto:MOBILE-IP@standards.nortelnetworks.com]On Behalf Of > pcalhoun@eng.sun.com > Sent: Thursday, August 31, 2000 10:55 AM > To: MOBILE-IP@standards.nortelnetworks.com > Subject: Re: [MOBILE-IP] questions for cellular IP and 3G network > > > > I'm not sure if we should still discuss Cellular IP-related > stuffs here, > > due to the ongoing charter review. Anyway... > > cellular@cdma-2000.org was setup for these types of discussions. > > See www.cdma-2000.org for more info on the mailing list. > > PatC > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Aug 31 14:34:06 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11354 for ; Thu, 31 Aug 2000 14:34:06 -0400 (EDT) Received: from standards (47.234.32.16:3538) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E911@standards.nortelnetworks.com>; Thu, 31 Aug 2000 14:20:45 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8910 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 31 Aug 2000 14:20:44 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8E910@standards.nortelnetworks.com>; Thu, 31 Aug 2000 14:10:44 -0400 Received: from acsysindia.com ([202.54.63.216]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id NAA13764; Thu, 31 Aug 2000 13:23:25 -0500 (CDT) Received: from sdn-ar-001tnknoxP262.dialsprint.net_[168.191.249.152] [168.191.249.152] by acsysindia.com (SMTPD32-6.00) id A9FF1D700E0; Wed, 30 Aug 2000 21:06:31 +0530 Received: from by sdn-ar-001tnknoxP262.dialsprint.net with ESMTP; Wed, 30 Aug 2000 11:36:39 -0400 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Message-ID: <00002a746871$00003067$00005030@> Date: Wed, 30 Aug 2000 11:36:32 -0400 Reply-To: chow4now31@EARTHLINK.NET Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: chow4now31@EARTHLINK.NET Subject: [MOBILE-IP] The #1 Home Based Business In AMERICA!! 20528 X-To: Undisclosed.Recipients@hosaka.smallworks.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: quoted-printable

FOLLOW ME TO FINANCIAL FREEDOM!!



I Am looking for people with good work ethic and extrordinary desire
to earn at least $10,000 per month working from home!



NO SPECIAL SKILLS OR EXPERIENCE REQUIRED We will give you all the

training and personal support you will need to ensure your success!


This LEGITIMATE HOME-BASED INCOME OPPORTUNITY can put you back in

control of your time,your finances,and your life!



If you've tried other opportunities in the past that have failed to
live up their promises,



THIS IS DIFFERENT THEN ANYTHING ELSE YOU'VE SEEN!



THIS IS NOT A GET RICH QUICK SCHEME!



YOUR FINANCIAL PAST DOES NOT HAVE TO BE YOUR FINANCIAL FUTURE!



CALL ONLY IF YOU ARE SERIOUS!



1-800-345-9708



DONT GO TO SLEEP WITHOUT LISTENING TO THIS!



"ALL our dreams can come true- if we have the courage to persue them"
<= BR> -Walt Disney



Please Leave Your Name And Number And Best Time To Call



DO NOT RESPOND BY EMAIL



------------------------------------------------------------------------
This message is sent in compliance of the new email bill section
301.PerSection

301, Paragraph (a)(2)(C) of S. 1618. We will comply with all removal
=
requests.Just Put Remove
mailto:bagboy@= burmesses.net
------------------------------------------------------------------------=

From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Aug 31 18:02:24 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13595 for ; Thu, 31 Aug 2000 18:02:23 -0400 (EDT) Received: from standards (47.234.32.16:3638) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8EBA0@standards.nortelnetworks.com>; Thu, 31 Aug 2000 17:49:05 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9678 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 31 Aug 2000 17:49:05 -0400 Received: from motgate3.mot.com (144.189.100.103:42141) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8EB7B@standards.nortelnetworks.com>; Thu, 31 Aug 2000 17:39:04 -0400 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (motgate3 2.1) with ESMTP id OAA02090 for ; Thu, 31 Aug 2000 14:49:51 -0700 (MST)] Received: [from il75exm02.cig.mot.com (IL75EXM02.cig.mot.com [136.182.110.102]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id OAA15307 for ; Thu, 31 Aug 2000 14:50:47 -0700 (MST)] Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2650.21) id ; Thu, 31 Aug 2000 16:50:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C01395.845212C0" Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A0367073B@il27exm02.cig.mot.com> Date: Thu, 31 Aug 2000 16:50:45 -0500 Reply-To: Nakhjiri Madjid-MNAKHJI1 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Nakhjiri Madjid-MNAKHJI1 Subject: Re: [MOBILE-IP] The #1 Home Based Business In AMERICA!! 20528 X-To: "chow4now31@EARTHLINK.NET" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM 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_01C01395.845212C0 Content-Type: text/plain; charset="iso-8859-1" I am sorry, I just joined the Mobile IP mailing list a week ago. Can somebody tell me why I am getting so much junkmail on this reflector? -----Original Message----- From: chow4now31@EARTHLINK.NET [mailto:chow4now31@EARTHLINK.NET] Sent: Wednesday, August 30, 2000 10:37 AM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: [MOBILE-IP] The #1 Home Based Business In AMERICA!! 20528 FOLLOW ME TO FINANCIAL FREEDOM!! I Am looking for people with good work ethic and extrordinary desire to earn at least $10,000 per month working from home! NO SPECIAL SKILLS OR EXPERIENCE REQUIRED We will give you all the training and personal support you will need to ensure your success! This LEGITIMATE HOME-BASED INCOME OPPORTUNITY can put you back in control of your time,your finances,and your life! If you've tried other opportunities in the past that have failed to live up their promises, THIS IS DIFFERENT THEN ANYTHING ELSE YOU'VE SEEN! THIS IS NOT A GET RICH QUICK SCHEME! YOUR FINANCIAL PAST DOES NOT HAVE TO BE YOUR FINANCIAL FUTURE! CALL ONLY IF YOU ARE SERIOUS! 1-800-345-9708 DONT GO TO SLEEP WITHOUT LISTENING TO THIS! "ALL our dreams can come true- if we have the courage to persue them" -Walt Disney Please Leave Your Name And Number And Best Time To Call DO NOT RESPOND BY EMAIL ------------------------------------------------------------------------ This message is sent in compliance of the new email bill section 301.PerSection 301, Paragraph (a)(2)(C) of S. 1618. We will comply with all removal requests.Just Put Remove mailto:bagboy@burmesses.net ------------------------------------------------------------------------ ------_=_NextPart_001_01C01395.845212C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I am=20 sorry, I just joined the Mobile IP mailing list a week ago. Can = somebody tell me=20 why I am getting so much junkmail on this = reflector?
-----Original Message-----
From: = chow4now31@EARTHLINK.NET=20 [mailto:chow4now31@EARTHLINK.NET]
Sent: Wednesday, August = 30, 2000=20 10:37 AM
To:=20 MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: [MOBILE-IP] = The #1=20 Home Based Business In AMERICA!! 20528



FOLLOW ME TO FINANCIAL=20 FREEDOM!!



I Am looking for people with good work ethic = and=20 extrordinary desire

to earn at least $10,000 per month working = from=20 home!



NO SPECIAL SKILLS OR EXPERIENCE REQUIRED We will = give you=20 all the

training and personal support you will need to ensure = your=20 success!



This LEGITIMATE HOME-BASED INCOME OPPORTUNITY = can put=20 you back in

control of your time,your finances,and your=20 life!



If you've tried other opportunities in the past = that have=20 failed to

live up their promises,



THIS IS = DIFFERENT=20 THEN ANYTHING ELSE YOU'VE SEEN!



THIS IS NOT A GET RICH = QUICK=20 SCHEME!



YOUR FINANCIAL PAST DOES NOT HAVE TO BE YOUR = FINANCIAL=20 FUTURE!



CALL ONLY IF YOU ARE=20 SERIOUS!



1-800-345-9708



DONT GO TO = SLEEP=20 WITHOUT LISTENING TO THIS!



"ALL our dreams can come = true- if we=20 have the courage to persue them"

-Walt = Disney



Please=20 Leave Your Name And Number And Best Time To Call



DO = NOT RESPOND=20 BY=20 = EMAIL



---------------------------------------------------= ---------------------

This=20 message is sent in compliance of the new email bill=20 section

301.PerSection

301, Paragraph (a)(2)(C) of S. = 1618. We=20 will comply with all removal

requests.Just Put=20 = Remove
mailto:bagboy@burmesses.net
-------------------------------= -----------------------------------------

------_=_NextPart_001_01C01395.845212C0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Aug 31 21:38:49 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16522 for ; Thu, 31 Aug 2000 21:38:48 -0400 (EDT) Received: from standards (47.234.32.16:4081) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8EC84@standards.nortelnetworks.com>; Thu, 31 Aug 2000 21:25:33 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10023 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 31 Aug 2000 21:25:33 -0400 Received: from mail.eecis.udel.edu (louie.udel.edu) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8EC7F@standards.nortelnetworks.com>; Thu, 31 Aug 2000 21:15:32 -0400 Received: from ren.eecis.udel.edu by mail.eecis.udel.edu id aa21969; 31 Aug 2000 21:27 EDT MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Thu, 31 Aug 2000 21:27:29 -0400 Reply-To: Xinming He Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Xinming He Subject: [MOBILE-IP] about unsubscription To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM ----------------- Sorry to bother everyone. But I really do not know how to unsubscribe from this email list. I suggest there should be information on how to unsubscribe besides the information on how to subscribe in the web page of the mobile IP working group. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Aug 31 23:02:15 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19298 for ; Thu, 31 Aug 2000 23:02:15 -0400 (EDT) Received: from standards (47.234.32.16:2390) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8ECE8@standards.nortelnetworks.com>; Thu, 31 Aug 2000 22:48:50 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10167 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 31 Aug 2000 22:48:50 -0400 Received: from hkueee2.eee.hku.hk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8ECE5@standards.nortelnetworks.com>; Thu, 31 Aug 2000 22:38:49 -0400 Received: from hkueee1 (lzhuge@hkueee1.eee.hku.hk [147.8.180.2]) by hkueee2.eee.hku.hk (8.11.0/8.11.0) with ESMTP id e812pLV27682; Fri, 1 Sep 2000 10:51:21 +0800 (HKT) X-Sender: lzhuge@hkueee1 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Fri, 1 Sep 2000 10:51:24 +0800 Reply-To: ZhuGe Lei Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: ZhuGe Lei Subject: Re: [MOBILE-IP] about unsubscription X-To: Xinming He To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "You may leave the list at any time by sending a "SIGNOFF MOBILE-IP" or "UNSUBSCRIBE MOBILE-IP" command to LISTSERV@STANDARDS.NORTELNETWORKS.COM." (in the email confirming subscription from the list server :-) On Thu, 31 Aug 2000, Xinming He wrote: > ----------------- > Sorry to bother everyone. But I really do not know how to unsubscribe from > this email list. I suggest there should be information on how to > unsubscribe besides the information on how to subscribe in the web page of > the mobile IP working group. >