From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 1 05:30:35 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22760 for ; Mon, 1 May 2000 05:30:35 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5DA1FAA0@standards.nortelnetworks.com>; Mon, 1 May 2000 5:23:21 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 27222 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 1 May 2000 05:22:03 -0400 Received: from newman.cs.purdue.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C95F87F0@standards.nortelnetworks.com>; Mon, 1 May 2000 5:12:03 -0400 Received: from ector.cs.purdue.edu (0@ector.cs.purdue.edu [128.10.2.10]) by newman.cs.purdue.edu (8.8.7/8.8.7/PURDUE_CS-2.0) with ESMTP id EAA00635 for ; Mon, 1 May 2000 04:18:34 -0500 (EST) Received: from ector.cs.purdue.edu (782@ector.cs.purdue.edu [128.10.27.10]) by ector.cs.purdue.edu (8.8.7/8.8.7/PURDUE_CS-2.0) with ESMTP id EAA00181 for ; Mon, 1 May 2000 04:18:30 -0500 (EST) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Mon, 1 May 2000 04:18:27 -0500 Reply-To: Manish Tiwari Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Manish Tiwari Subject: [MOBILE-IP] Returning home To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi all! I am doing an implementation of mobile-ipv4 (bis) for an operating system xinu. I am facing a small problem. When the mobile node returns to the home network, it sends a deregistration request to the home agent. Now, the home agent will send the registration reply after deleting its mobility bindings to the care-of address mentioned in the request, and in the case of the foreign agent care-of address, this reply will go to the foreign agent. Now, I don't see the purpose of forwarding this reply from the foreign agent to the mobile node, since the mobile node has already left the foreign network, and it will not be able to receive this reply. Secondly, how does the mobile node come to know that it has been able to successfully deregister with the home agent. Am I missing something? Thank you Manish Tiwari {\o/}__________________________________________________________________{\o/} )|( )|( ~|~ Manish Tiwari Office: CS G072 ~|~ | Graduate Student Phone : 494-9569 | | Department of Computer Science __ | | Purdue University ,,-~ ~-. Residence: | | West Lafayette, IN 47907-1398. // . -.. ~. | | ____ . \ // ' _ } 702, Dodge Street | | { }__ :. __\ //,'.,._ _ ,' Apt# 1 | | _/ ____ \ \ `:: \\~-:-: : : : :\ West Lafayette | | // { __ \ }.} ::: { @|,;: : : : : >- IN 47906. | | /{,/ /_ \ \ \ }:::: `Y'/=|_\: : : :/ Phone: 746-4072 | | { / // \_\ }//.:::' / | \-===-~ | | ( {_/{(@)} }.) }:<____A___/_A_|___\,_______A_______A_______A_____| | \ \\ \\/ / / };::-------v------V------v-------V-------v-------V-| | \/\\_\_/\/_/ }`:` | | { { ~ } \ /,::' URL: http://www.cs.purdue.edu/homes/tiwari | | \_ \__/ /~,::' | | {____}~ ,::' | | ~ | {\o/}____________________________________________________________________0 )|( /V\ ~"~ H ^ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 1 06:45:37 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23277 for ; Mon, 1 May 2000 06:45:36 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DAE09DF0@standards.nortelnetworks.com>; Mon, 1 May 2000 6:38:26 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 27287 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 1 May 2000 06:36:45 -0400 Received: from ietf.org (132.151.1.176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.38DF56F0@standards.nortelnetworks.com>; Mon, 1 May 2000 6:26:45 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23106; Mon, 1 May 2000 06:33:16 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200005011033.GAA23106@ietf.org> Date: Mon, 1 May 2000 06:33:15 -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-ietf-mobileip-ipv6-12.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : Mobility Support in IPv6 Author(s) : D. Johnson, C. Perkins Filename : draft-ietf-mobileip-ipv6-12.txt Pages : 109 Date : 28-Apr-00 This document specifies the operation of mobile computers using IPv6. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines four new IPv6 destination options, including one that MUST be supported in packets received by any node, whether mobile or stationary. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-12.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-ietf-mobileip-ipv6-12.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-ietf-mobileip-ipv6-12.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: <20000428081314.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-ipv6-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-ipv6-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000428081314.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 1 07:32:43 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24335 for ; Mon, 1 May 2000 07:32:43 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.705DE850@standards.nortelnetworks.com>; Mon, 1 May 2000 7:25:34 -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, 1 May 2000 07:24:19 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.43BA72A0@standards.nortelnetworks.com>; Mon, 1 May 2000 7:24: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 FAA02979; Mon, 1 May 2000 05:30:49 -0600 (MDT) Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM [129.146.105.34]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id EAA15902; Mon, 1 May 2000 04:30:49 -0700 (PDT) Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA15904; Mon, 1 May 2000 04:30:35 -0700 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Mon, 1 May 2000 04:30: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] handover: proactive versus reactive X-To: Phil Neumiller To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <005101bfb1d8$056c5020$6d01acc0@default> > > > > Network access such as 802.11 is a good model, and that should be our > ultimate > > target. > > No Pat, I am (sort of, albeit a malcontent), a cellular insider, having > worked in that > industry for over 12 years. My feeling is that PPP must be disposed of > ASAP. > This is not a very popular opinion among those that do set the standards for > cellular > in those groups like 3G.IP, 3GPP, 3GPP2, etc. I believe we can still rescue > Bluetooth > from this "circuit" mind set, by recommending an L2CAP link adaptation for > IPv4 and > IPv6 that works precisely like that of 802.11 in the Pittsburgh BOF. > Phil, I am a little confused by your response. You open by disagreeing with me, then you agree with my (that PPP must go). So, are you of the opinion, as I am, that a circuit switched model for wireless networks is Really Bad Design (TM). PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 1 08:02:01 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24956 for ; Mon, 1 May 2000 08:02:01 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.801386C0@standards.nortelnetworks.com>; Mon, 1 May 2000 7:54:38 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 27443 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 1 May 2000 07:52:59 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.447D9EC0@standards.nortelnetworks.com>; Mon, 1 May 2000 7:52:58 -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 FAA09239 for ; Mon, 1 May 2000 05:59:30 -0600 (MDT) Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM [129.146.61.34]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id EAA17497; Mon, 1 May 2000 04:59:23 -0700 (PDT) Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA02887; Mon, 1 May 2000 04:59:10 -0700 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Mon, 1 May 2000 04:59:09 -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] handover: proactive versus reactive X-To: cnyap X-cc: Sunny , Ben van Noort , "C.C.Tsang" , Dave , "E.Piperakis" , Emlyn Bolton , Iwan Adhicandra , Nasser Abouzakhar , Siu Fai Cheng , "X.Chen" , Stephen E Larkin , Srba Cvetkovic , Robert Edwards , Matthias Kraner , Kitty Hung , Harry Ladas , E.Sanchez@dcs.shef.ac.uk, Maysoon To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <003601bfb149$4e891980$2c0ba78f@dcs.shef.ac.uk> > > Below are some of my doubts. > Why use a "connection oriented" MIP layer that as well require > 10 round trips in order to get IP packet delivered? > Why develop alternatives where PPP is already doing the job? > First, off, let me state that my position is not that PPP is utterly useless. In fact, it is a very useful protocol that has made connectivity MUCH simpler than what we had before. However, sometimes we need to evaluate whether the use of a protocol, just because it exists, is appropriate in a specific problem space. Now, let's use the 3GPP2 architecture model, and see how useful PPP really is. In their architecture, when Mobile IP is used, home address negotiation and user authentication is done through the Mobile IP registration sequence, so: LCP: - Authentication negotiation (disabled, not needed) - MTU negotiation (this one *could* be useful) Auth: - Not needed since it is handled by MIP IPCP: - Address Negotiation (not done since it is handled by MIP) Framing: - yes, this is needed So, as you can see above, some of the networks make use of PPP simply to negotiation framing, when in fact framing could be done without the need for all of the negotiations. We could use the same HDLC framing that PPP uses, if need be, and that still reduces the initial connection setup time. So, since we are looking to move away from the circuit switched model in wireless networks, we should strive for a link layer that is stateless. PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 1 09:31:58 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26209 for ; Mon, 1 May 2000 09:31:58 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1C8B1B10@standards.nortelnetworks.com>; Mon, 1 May 2000 9:24:55 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 27653 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 1 May 2000 09:23:18 -0400 Received: from sirius.ctr.columbia.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E2D6C450@standards.nortelnetworks.com>; Mon, 1 May 2000 9:23:18 -0400 Received: from comet.columbia.edu (sweetpea.comet.columbia.edu [128.59.68.61]) by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with ESMTP id JAA20217; Mon, 1 May 2000 09:29:45 -0400 (EDT) X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <390DB469.25FCB50E@comet.columbia.edu> Date: Mon, 1 May 2000 09:44:25 -0700 Reply-To: campbell@comet.columbia.edu Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Andrew T. Campbell" Organization: Center for Telecommunications Research Subject: Re: [MOBILE-IP] handover: proactive versus reactive X-To: "pcalhoun@eng.sun.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Pat: > So, are you of the opinion, as I am, that a circuit switched model for > wireless networks is Really Bad Design (TM). The last bastion of "circuit" in wireless networks in the air-interface. Packets to the BTS is (while still controversial in some quarters) a given. May be it will fade over the air soon al la WLANs - but that will take sometime and more smarts. The difficulty is control. If "cicuit==control" then there is no doubt that some level of "control" is required in wireless networks above and beyond wireline. Control is here to stay. Control can equal state and mechanisms. A good research question is what is the minimum amount of state and level of control needed to allow IP to scale in wireless networks. That is an open questions and the answer lies between cellular and packet readio.... Andrew From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 1 09:44:11 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26375 for ; Mon, 1 May 2000 09:44:11 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CEE4CD00@standards.nortelnetworks.com>; Mon, 1 May 2000 9:37:03 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 27665 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 1 May 2000 09:35:54 -0400 Received: from ftpbox.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3F83BE10@standards.nortelnetworks.com>; Mon, 1 May 2000 9:25:53 -0400 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id GAA23343 for ; Mon, 1 May 2000 06:32:22 -0700 (MST)] Received: [from il33exm01.wes.mot.com (il33exm01.wes.mot.com [154.56.3.118]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id GAA06964 for ; Mon, 1 May 2000 06:32:21 -0700 (MST)] Received: by il33exm01.wes.mot.com with Internet Mail Service (5.5.2650.21) id <28T0BVR1>; Mon, 1 May 2000 08:32: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: <7195C03599D9D311BE580008C75697EB443241@il33exm01.wes.mot.com> Date: Mon, 1 May 2000 08:32:20 -0500 Reply-To: Roberts Phil-QA3445 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Roberts Phil-QA3445 Subject: Re: [MOBILE-IP] peripheral concern X-To: "t.pagtzis@CS.UCL.AC.UK" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi, I think it's time to reign in this discussion. We're pretty far off topic of mobile ip. Perhaps someone would like to create a cellular interest list, but designing cellular systems in general and the wide range of topics associated with it are out of scope. Phil -----Original Message----- From: Theo PAGTZIS [mailto:T.Pagtzis@CS.UCL.AC.UK] Sent: Friday, April 28, 2000 5:26 PM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: [MOBILE-IP] peripheral concern I do not know how much has concerned you but, does anyone have any arguments about health and safety issues in deploying such BSs ? Are there any issues involved with range extension antennas that we would like to be aware of? I am trying to convince people here about their safety but dunno where I stand... (I know about inverse square.....) Theo From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 1 09:55:14 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26516 for ; Mon, 1 May 2000 09:55:14 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5B18DEF0@standards.nortelnetworks.com>; Mon, 1 May 2000 9:48:08 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 27820 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 1 May 2000 09:47:00 -0400 Received: from smtpgw2.sprintspectrum.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.323AFCC0@standards.nortelnetworks.com>; Mon, 1 May 2000 9:47:00 -0400 Received: from PKCEXV501.nmcc.sprintspectrum.com (pkcexa501.sprintspectrum.com [208.4.96.82]) by smtpgw2.sprintspectrum.com (8.9.3/8.9.3) with ESMTP id IAA15649; Mon, 1 May 2000 08:53:20 -0500 (CDT) Received: by pkcexv501.nmcc.sprintspectrum.com with Internet Mail Service (5.5.2448.0) id ; Mon, 1 May 2000 08:53:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Mon, 1 May 2000 08:53:29 -0500 Reply-To: "Castillo Jr., Al" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Castillo Jr., Al" Subject: Re: [MOBILE-IP] peripheral concern X-To: Arthur Ross To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Motorola conducted a study about the effect of Radio Frequency in users. You can find it at the Motorola.com site. 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: Arthur Ross [mailto:a.ross@IEEE.ORG] Sent: Friday, April 28, 2000 6:12 PM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] peripheral concern At 15:25 -0700 04/28/2000, Theo PAGTZIS wrote: >I do not know how much has concerned you but, > >does anyone have any arguments about health and safety issues in >deploying such BSs ? Are there any issues involved with range extension >antennas that we would like to be aware of? > >I am trying to convince people here about their safety but dunno where I >stand... (I know about inverse square.....) > > >Theo A place to start might be the United States FCC Office of Engineering and Technology Bulletin 65: "Evaluating Compliance with FCC Guidelines for Human Exposure to Radiofrequency Electromagnetic Fields" You can find it as PDF somewhere on the FCC website (www.fcc.gov). OET 65 appears to be aimed primarily at "big wireless" installations, e.g. the antenna farms that you will often find on prime site rooftops, rather than small LAN/WAN things, but it is a place to start. It is based on exposure recommendations by something called the National Council on Radiation Protection and Measurements, by the IEEE, and by ANSI. It gives references to those underlying recommendations. This is one of those public health & safety policy issues where you will find people firmly dug in on both sides, regardless of the facts. And there will be perennial disagreement about the facts. Like so many of these things, to make it totally go away would require proving a negative, generally impossible. You might also check with the US CTIA (Cellular Telecommunications Industry Association). They initiated a real, scientific study several years ago, stimulated by a personal injury tort that claimed handheld cell phones cause cancer (woman had died of some sort of tumor in her head). They enlisted some well respected medical research folks to do the study. As I recall, the conclusion was generally favorable, but with a hint of ambiguity about some obscure low-level effect. You should contact the CTIA. -- Best -- Arthur From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 1 10:20:30 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26905 for ; Mon, 1 May 2000 10:20:30 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DEF58E50@standards.nortelnetworks.com>; Mon, 1 May 2000 10:13:18 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 27941 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 1 May 2000 10:12:15 -0400 Received: from prserv.net (32.97.166.32) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B96AF5D0@standards.nortelnetworks.com>; Mon, 1 May 2000 10:12:15 -0400 Received: from [32.100.146.59] ([32.100.146.59]) by prserv.net (out2) with ESMTP id <2000050114182622900m4qkee>; Mon, 1 May 2000 14:18:27 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: ahmrphd@pop3.attglobal.net References: Message-ID: Date: Mon, 1 May 2000 07:19:20 -0700 Reply-To: Arthur Ross Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Arthur Ross Subject: Re: [MOBILE-IP] handover: proactive versus reactive X-To: campbell@comet.columbia.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <390DB469.25FCB50E@comet.columbia.edu> Once again, RIGHT ON Andrew! My vote is for some form of SSMA-based packet radio, with power control. It obviously needs some sort of congestion control at the physical level, but I think that is quite doable. How do you define "allow IP to scale"? Complexity? Thermodynamics? Seems to me that the difficulty lies in the relationship between the two. A major conceptual leap in the SSMA air interfaces was the notion of tight closed-loop transmitter power control, including the ability to turn the power WAY down (CDMA handsets, can and do sometimes transmit less power than they are receiving). This has a lot to do with scaling at the physical level. A well-executed CDMA cellular/PCS system, for example, has pretty much CONSTANT capacity (ckt style) per sector, more or less independent of coverage, or even degree of sectorization (not rigorously true, but a fair approximation in most circumstances). The original Bell Labs notion of increasing capacity by cell splitting continues to work for SSMA, at least in the sortof "thermodynamic" sense of mutual interference. I look forward to the continuation of this debate ... Maybe even to a conclusion or two! -- Arthur At 9:44 -0700 05/01/2000, Andrew T. Campbell wrote: >Pat: > >> So, are you of the opinion, as I am, that a circuit switched model for >> wireless networks is Really Bad Design (TM). > >The last bastion of "circuit" in wireless networks in the air-interface. >Packets to the BTS is (while still controversial in some quarters) a >given. May be it will fade over the air soon al la WLANs - but >that will take sometime and more smarts. > >The difficulty is control. > >If "cicuit==control" then there is no doubt that some level of >"control" is required in wireless networks above and beyond >wireline. > >Control is here to stay. > >Control can equal state and mechanisms. > >A good research question is what is the >minimum amount of state and level of control needed to >allow IP to scale in wireless networks. > >That is an open questions and the answer >lies between cellular and packet readio.... > >Andrew From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 1 10:57:39 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27571 for ; Mon, 1 May 2000 10:57:38 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A4A8AED0@standards.nortelnetworks.com>; Mon, 1 May 2000 10:47:28 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 28013 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 1 May 2000 10:46:42 -0400 Received: from eagle.aud.alcatel.com (128.251.96.217) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.23B99790@standards.nortelnetworks.com>; Mon, 1 May 2000 10:36:42 -0400 Received: from usa.alcatel.com by eagle.aud.alcatel.com (8.8.8+Sun/SMI-SVR4) id JAA28314; Mon, 1 May 2000 09:43:02 -0500 (CDT) X-Mailer: Mozilla 4.72 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 References: <4B6BC00CD15FD2119E5F0008C7A419A5089EAFCC@eaubrnt018.epa.ericsson.se> Content-Type: multipart/alternative; boundary="------------09F275711A7B522CE53E4583" Message-ID: <390D9780.684BC19F@usa.alcatel.com> Date: Mon, 1 May 2000 09:41:04 -0500 Reply-To: Vincent Magret Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Vincent Magret Subject: Re: [MOBILE-IP] handover To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --------------09F275711A7B522CE53E4583 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I fully agree with the proposal. Vincent "Hesham Soliman (EPA)" wrote: > > > Hi, > > Now I am not proposing that Mobile IP support movement detection > using signal > strength, or any other method. What I am proposing is that the > existing link > layers do this, and trigger events in Mobile IP when they do. > This way, we can > keep Mobile IP layer-2 unaware. Perhaps the API mentioned earlier > would state > what events Mobile IP expects to receive, and would be a good > start. > > PatC > > I fully agree with you here. We can keep MIP generic and > independant of the underlying link layer and it will always work > as long as the link layer is aware that MIP is running above it > and can assist its operation by (for example) carrying some of > the L3 messages or providing some information about the link > status. > > Having said that, I believe this WG should continue to try to > improve the "IP layer" handoff performance, and while doing that > we can put some requirements on lower layers that will choose MIP > for their mobility management. > > Cheers, > Hesham > --------------09F275711A7B522CE53E4583 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I fully agree with the proposal.

Vincent

"Hesham Soliman (EPA)" wrote:

 
    Hi,

    Now I am not proposing that Mobile IP support movement detection using signal
    strength, or any other method. What I am proposing is that the existing link
    layers do this, and trigger events in Mobile IP when they do. This way, we can
    keep Mobile IP layer-2 unaware. Perhaps the API mentioned earlier would state
    what events Mobile IP expects to receive, and would be a good start.

    PatC

    I fully agree with you here. We can keep MIP generic and independant of the underlying link layer and it will always work as long as the link layer is aware that MIP is running above it and can assist its operation by (for example) carrying some of the L3 messages or providing some information about the link status.

    Having said that, I believe this WG should continue to try to improve the "IP layer" handoff performance, and while doing that we can put some requirements on lower layers that will choose MIP for their mobility management.

    Cheers,
    Hesham

--------------09F275711A7B522CE53E4583-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 1 11:33:55 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28456 for ; Mon, 1 May 2000 11:33:55 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1EF135E0@standards.nortelnetworks.com>; Mon, 1 May 2000 11:26:40 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 28207 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 1 May 2000 11:25:22 -0400 Received: from clea.qualcomm.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F01B28C0@standards.nortelnetworks.com>; Mon, 1 May 2000 11:25:22 -0400 Received: from jwillkie1 (jwillkie1.qualcomm.com [129.46.219.171]) by clea.qualcomm.com (8.9.3/8.9.3/1.0) with SMTP id IAA17076; Mon, 1 May 2000 08:31:52 -0700 (PDT) X-Sender: jwillkie@mail1.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 References: <"Your message with ID" <003601bfb149$4e891980$2c0ba78f@dcs.shef.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <4.1.20000501082055.00d8e760@mail1.qualcomm.com> Date: Mon, 1 May 2000 08:31:44 -0700 Reply-To: Jim Willkie Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Jim Willkie Subject: Re: [MOBILE-IP] handover: proactive versus reactive X-To: "pcalhoun@eng.sun.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: At 04:59 AM 5/1/00 -0700, pcalhoun@eng.sun.com wrote: >> >> Below are some of my doubts. >> Why use a "connection oriented" MIP layer that as well require >> 10 round trips in order to get IP packet delivered? >> Why develop alternatives where PPP is already doing the job? >> >First, off, let me state that my position is not that PPP is utterly useless. >In fact, it is a very useful protocol that has made connectivity MUCH simpler >than what we had before. > >However, sometimes we need to evaluate whether the use of a protocol, just >because it exists, is appropriate in a specific problem space. Now, let's use >the 3GPP2 architecture model, and see how useful PPP really is. In their >architecture, when Mobile IP is used, home address negotiation and user >authentication is done through the Mobile IP registration sequence, so: > >LCP: > - Authentication negotiation (disabled, not needed) > - MTU negotiation (this one *could* be useful) >Auth: > - Not needed since it is handled by MIP >IPCP: > - Address Negotiation (not done since it is handled by MIP) >Framing: > - yes, this is needed > >So, as you can see above, some of the networks make use of PPP simply to >negotiation framing, when in fact framing could be done without the need for >all of the negotiations. We could use the same HDLC framing that PPP uses, if >need be, and that still reduces the initial connection setup time. > >So, since we are looking to move away from the circuit switched model in >wireless networks, we should strive for a link layer that is stateless. Folks: Here's a couple of counter points to the above well focused thoughts: If MobileIP was a required piece of the wireless packet network then the above arguments hold and a state-less link layer is viable. But the current (at least CDMA) wireless network does not have MobileIP and uses PPP to negotiate IP addresses. This capability will have to continue to exist when a mobileIP solution is rolled out. Many deployed cellular packet network use PAP or CHAP to authenticate the packet user. One would think that this capability will continue to be desired by operators. So it would seem that for at least the CDMA packet network both MobileIP-capable and the the so-called simple IP capabilities will continue to co-exist. This reality would seem to make the on-going need for PPP to remain. Comments please.... Jim Willkie From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 1 11:50:58 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28758 for ; Mon, 1 May 2000 11:50:57 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.816303A0@standards.nortelnetworks.com>; Mon, 1 May 2000 11:43:44 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 28262 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 1 May 2000 11:41:45 -0400 Received: from mail.hrn.ascend.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3A005350@standards.nortelnetworks.com>; Mon, 1 May 2000 11:41:45 -0400 Received: from awalker2 (lease-93.eng.hrn.ascend.com [149.52.12.93]) by mail.hrn.ascend.com (8.9.3/8.9.3) with ESMTP id LAA00030 for ; Mon, 1 May 2000 11:48:17 -0400 (EDT) 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Message-ID: Date: Mon, 1 May 2000 11:47:57 -0400 Reply-To: Amanda Walker Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Amanda Walker Subject: [MOBILE-IP] PPP (was Re: handover: proactive versus reactive) To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Content-Transfer-Encoding: 7bit [This is a small diversion from the technical aspects of Mobile-IP, but it seems relevant.] First off, I should note that as an engineer I think of PPP over Ethernet, wireless, DSL, etc. as a kludge, at least from a purely technical standpoint. However, there are more than just technical factors at work. PPP is popular for a variety of reasons, but the major reason it is being deployed over wireless, DSL, and other media is that it makes access look like a phone call. Existing systems (billing, support, usage monitoring, etc.) know how to deal with phone calls, and existing operators will always ask vendors for new products by framing their requests in terms of what they already have rather than the problem they are trying to solve. This is unavoidable, I think, and it's a particular challenge for vendors. The same effect also applies to end users, although the individual amounts of money are a lot smaller :-). When an operator asks for "faster wireless data calls", an ISP asks for a "wireless dialup POP", or a telco asks for a "layer 2 gateway", it can be very difficult not to sell them what they are asking for. This is how, as an industry, we've ended up with PPP over Ethernet for DSL, huge L2TP networks for access wholesaling, and so on, with analogous wireless products recently making their debut from several big vendors (and more in the pipeline). From a technical standpoint, these are kludges if you view the problem as providing ubquitous IP with the lowest possible overhead. If the only challenges were technical, none of this would be around. However, PPP and L2TP work (for various values of "work"), today, with off the shelf hardware and software. This is particularly true for the unlicensed/low-power arena, since for all that cellular providers often disregard technology like IEEE 802.11b because it's unlicensed and low range, those very facts are strengths as well. A budding provider can deploy a wireless access infastructure serving tens of thousands of simultaneous users with 100x the on-air data rate of cellular data without any licenses, approvals, or whatever--just money and the rights to stick little grey boxes every few hundred feet. And they can do it today--with shipping, field-proven products. Airports, hotels, high-rises, convention centers, ... backhaul it with DSL and you can even use the existing wireplant. Very lower barriers to entry, very fast product cycles, more efficient reuse of spectrum, and lots of leverage from existing products and infastructure, particularly the billing and provisioning infastructure [disclaimer: we make all of these products, so I am probably a bit biased :-), though you can also do it with products from most of the other big vendors at this point, now that router vendors are buying up WLAN vendors...]. It'll happen, and it may well be speaking PPP & L2TP if nothing better (from a business case point of view) comes by--people will build their networks with whatever technology is ready and solves their business needs. And this, I think, is the biggest danger in thinking of Mobile-IP as a "cellular" technology, with 5-7 year product cycles, slow adoption of new technology (often with good reason, to be sure--essential services have different operating constraints than discretionary ones), and high barriers to entry. The ISP/datacom market is a very different place than the telco market. Amanda Walker Lucent Technologies InterNetworking Systems From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 1 12:08:54 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29255 for ; Mon, 1 May 2000 12:08:54 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C12FA590@standards.nortelnetworks.com>; Mon, 1 May 2000 11:59:50 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 28334 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 1 May 2000 11:58:10 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.855BA320@standards.nortelnetworks.com>; Mon, 1 May 2000 11:58:10 -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 KAA28329; Mon, 1 May 2000 10:04:41 -0600 (MDT) Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM [129.146.91.34]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id JAA26275; Mon, 1 May 2000 09:04:40 -0700 (PDT) Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA19491; Mon, 1 May 2000 09:04:38 -0700 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Mon, 1 May 2000 09:04: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] handover: proactive versus reactive X-To: Jim Willkie To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <4.1.20000501082055.00d8e760@mail1.qualcomm.com> > At 04:59 AM 5/1/00 -0700, pcalhoun@eng.sun.com wrote: > >> > >> Below are some of my doubts. > >> Why use a "connection oriented" MIP layer that as well require > >> 10 round trips in order to get IP packet delivered? > >> Why develop alternatives where PPP is already doing the job? > >> > >First, off, let me state that my position is not that PPP is utterly > useless. >In fact, it is a very useful protocol that has made connectivity > MUCH simpler >than what we had before. > > > >However, sometimes we need to evaluate whether the use of a protocol, just > >because it exists, is appropriate in a specific problem space. Now, let's > use >the 3GPP2 architecture model, and see how useful PPP really is. In their > >architecture, when Mobile IP is used, home address negotiation and user > >authentication is done through the Mobile IP registration sequence, so: > > >LCP: > > - Authentication negotiation (disabled, not needed) > > - MTU negotiation (this one *could* be useful) > >Auth: > > - Not needed since it is handled by MIP > >IPCP: > > - Address Negotiation (not done since it is handled by MIP) > >Framing: > > - yes, this is needed > > > >So, as you can see above, some of the networks make use of PPP simply to > >negotiation framing, when in fact framing could be done without the need for > >all of the negotiations. We could use the same HDLC framing that PPP uses, > if >need be, and that still reduces the initial connection setup time. > > > >So, since we are looking to move away from the circuit switched model in > >wireless networks, we should strive for a link layer that is stateless. > > Folks: > Here's a couple of counter points to the above well focused thoughts: > > If MobileIP was a required piece of the wireless packet network then the > above arguments hold and a state-less link layer is viable. But the current > (at least CDMA) wireless network does not have MobileIP and uses PPP to > negotiate IP addresses. This capability will have to continue to exist when > a mobileIP solution is rolled out. > > Many deployed cellular packet network use PAP or CHAP to authenticate the > packet user. One would think that this capability will continue to be > desired by operators. > > So it would seem that for at least the CDMA packet network both > MobileIP-capable and the the so-called simple IP capabilities will continue > to co-exist. This reality would seem to make the on-going need for PPP to > remain. > > Comments please.... Jim, you are correct. Even 3G supports simple IP, which is essentially dial-up PPP over a wireless link. So, PPP is still in the architecture for legacy devices, and I agree that this service will remain to be provided as long as there are some legacy devices around. However, there is an opportunity to redesign the network, and it seems like the best time to move away from PPP. This new design would be similar to the thoughts that I've been discussing in various threads. So, while I agree with your comments, let's see if we can move forward and do it right. I don't think that creating next generation networks that rely on antiquated technology that does nothing but add overhead seems pointless. PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 1 12:39:18 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29827 for ; Mon, 1 May 2000 12:39:18 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.40E0DE40@standards.nortelnetworks.com>; Mon, 1 May 2000 12:32:03 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 28488 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 1 May 2000 12:31:25 -0400 Received: from cedar.dcs.shef.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2A906F70@standards.nortelnetworks.com>; Mon, 1 May 2000 12:31:25 -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 RAA14166; Mon, 1 May 2000 17:37:51 +0100 (BST) 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.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Message-ID: <005901bfb37a$d913d1c0$2c0ba78f@dcs.shef.ac.uk> Date: Mon, 1 May 2000 15:37:59 +0100 Reply-To: cnyap Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: cnyap Subject: Re: [MOBILE-IP] handover: proactive versus reactive X-To: "pcalhoun@eng.sun.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit > Jim, you are correct. Even 3G supports simple IP, which is essentially dial-up > PPP over a wireless link. So, PPP is still in the architecture for legacy > devices, and I agree that this service will remain to be provided as long as > there are some legacy devices around. > > However, there is an opportunity to redesign the network, and it seems like > the best time to move away from PPP. This new design would be similar to the > thoughts that I've been discussing in various threads. > > So, while I agree with your comments, let's see if we can move forward and do > it right. I don't think that creating next generation networks that rely on > antiquated technology that does nothing but add overhead seems pointless. > > PatC Hi From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 1 13:19:27 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00651 for ; Mon, 1 May 2000 13:19:26 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DD2531C0@standards.nortelnetworks.com>; Mon, 1 May 2000 13:12:12 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 28617 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 1 May 2000 13:12:03 -0400 Received: from bells.cs.ucl.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D7B4D470@standards.nortelnetworks.com>; Mon, 1 May 2000 13:12:03 -0400 Received: from ginger.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 1 May 2000 18:17:57 +0100 X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: el, en MIME-Version: 1.0 References: <7195C03599D9D311BE580008C75697EB443241@il33exm01.wes.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <390DBC3F.F2CE6EDF@cs.ucl.ac.uk> Date: Mon, 1 May 2000 18:17:51 +0100 Reply-To: t.pagtzis@cs.ucl.ac.uk Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Theo PAGTZIS Organization: UCL Subject: Re: [MOBILE-IP] peripheral concern... To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Roberts Phil-QA3445 wrote: > Hi, > > I think it's time to reign in this discussion. We're pretty far off > topic of mobile ip. Perhaps someone would like to create a cellular > interest list, but designing cellular systems in general and the wide range > of topics associated with it are out of scope. > > Not really that far.... Considering the small range of the WLAN base stations and the need for dense population of Base stations for wireless (which is really the major card in the game called mobility), I think that one needs to consider the effects that the deployment of such population of base stations will have to humans. Besides the latter are consumers of the technology (effected by mobile ip) which if not accepted, won't get far Mobile-IP either.... Positioning of the BS has a direct effect on the BS population per square mile...but this is directly controlled by the effect it has on humans....(If you feel threatened by the technology you may always avoid using it....so practicing of mobile-IP gets another good delay which we could all do _without_ ...) The density of the BS population affects directly the amount of cell handoffs (which is what mobile-IP _is_ currently concerned with) ....which leads me to believe that the health and safety effects on humans by the deployment of BSs controls implicitly cell radius and thus handoff rates.... Since at the moment Mobile-IP cannot overprovision for handoff rates...I think it would be wise to consider all influencing (albeit peripheral ) factors...before ignoring the issue... Theo From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 1 13:35:38 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00960 for ; Mon, 1 May 2000 13:35:37 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1D836550@standards.nortelnetworks.com>; Mon, 1 May 2000 13:28:19 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 28709 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 1 May 2000 13:26:33 -0400 Received: from cedar.dcs.shef.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DDE9CF60@standards.nortelnetworks.com>; Mon, 1 May 2000 13:26:33 -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 SAA15762; Mon, 1 May 2000 18:33:04 +0100 (BST) 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.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Message-ID: <007501bfb382$8fcf2160$2c0ba78f@dcs.shef.ac.uk> Date: Mon, 1 May 2000 16:33:12 +0100 Reply-To: cnyap Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: cnyap Subject: Re: [MOBILE-IP] handover: proactive versus reactive X-To: "pcalhoun@eng.sun.com" X-cc: Sunny , Ben van Noort , "C.C.Tsang" , Dave , "E.Piperakis" , Emlyn Bolton , Iwan Adhicandra , Nasser Abouzakhar , Siu Fai Cheng , "X.Chen" , Stephen E Larkin , Srba Cvetkovic , Robert Edwards , Matthias Kraner , Kitty Hung , Harry Ladas , E.Sanchez@dcs.shef.ac.uk, Maysoon To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi PatC 1) What would you suggest of a link layer hint to IP layer? 2) Isn't air link essential as a perquisite for link layer hint? 3) Why would not be nice to use the confirmation of IP address negotiation as a link layer hint? Cheers ------------------------------------------------------------------- Chern Nam Yap Mobile Communication System Researcher University of Sheffield Department of Electronic and Electrical Engineering Regent Court 211 Portobello Street Sheffield S1 4DP, England Tel: +44 114 222 3308 Web: http://www.mobile1.net E-mail: cny@dcs.shef.ac.uk From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 1 13:39:36 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01032 for ; Mon, 1 May 2000 13:39:36 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6547E4B0@standards.nortelnetworks.com>; Mon, 1 May 2000 13:30:20 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 28715 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 1 May 2000 13:28:49 -0400 Received: from mail.hrn.ascend.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2F295EE0@standards.nortelnetworks.com>; Mon, 1 May 2000 13:28:49 -0400 Received: from awalker2 (lease-93.eng.hrn.ascend.com [149.52.12.93]) by mail.hrn.ascend.com (8.9.3/8.9.3) with ESMTP id NAA00981 for ; Mon, 1 May 2000 13:35:21 -0400 (EDT) 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Message-ID: Date: Mon, 1 May 2000 13:35:02 -0400 Reply-To: Amanda Walker Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Amanda Walker Subject: Re: [MOBILE-IP] peripheral concern... To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <390DBC3F.F2CE6EDF@cs.ucl.ac.uk> Content-Transfer-Encoding: 7bit > Considering the small range of the WLAN base stations and the > need for dense > population of Base stations for wireless (which is really the > major card in the > game called mobility), I think that one needs to consider the > effects that the > deployment of such population of base stations will have to > humans. On the other hand, WLAN base stations tend to be less dense and *much* lower power than, say, a room full of people with cell phone handsets (thanks to operating in unlicensed bands)--we're talking only tens of mW even if you're sitting directly on the antenna :-). The average microwave oven, even with all of its shielding, will swamp out a WLAN operating on the same frequency. I agree that RF safety issues are not directly relevant to MIP, though they might be a practical consideration to people constructing networks using RF physical media, WLAN-based or not. Amanda Walker Lucent Technologies InterNetworking Systems From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 1 13:42:46 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01137 for ; Mon, 1 May 2000 13:42:45 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1BF35A00@standards.nortelnetworks.com>; Mon, 1 May 2000 13:35:26 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 28705 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 1 May 2000 13:34:17 -0400 Received: from motgate2.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8CF66410@standards.nortelnetworks.com>; Mon, 1 May 2000 13:24:17 -0400 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id KAA27438 for ; Mon, 1 May 2000 10:30:49 -0700 (MST)] Received: [from il33exm01.wes.mot.com (il33exm01.wes.mot.com [154.56.3.118]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id KAA24291 for ; Mon, 1 May 2000 10:30:47 -0700 (MST)] Received: by il33exm01.wes.mot.com with Internet Mail Service (5.5.2650.21) id <28T0BV5F>; Mon, 1 May 2000 12:30: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: <7195C03599D9D311BE580008C75697EB44324B@il33exm01.wes.mot.com> Date: Mon, 1 May 2000 12:30:31 -0500 Reply-To: Roberts Phil-QA3445 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Roberts Phil-QA3445 Subject: Re: [MOBILE-IP] peripheral concern... X-To: "t.pagtzis@CS.UCL.AC.UK" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM No, it's too far off topic. -----Original Message----- From: Theo PAGTZIS [mailto:T.Pagtzis@CS.UCL.AC.UK] Sent: Monday, May 01, 2000 12:18 PM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] peripheral concern... Roberts Phil-QA3445 wrote: > Hi, > > I think it's time to reign in this discussion. We're pretty far off > topic of mobile ip. Perhaps someone would like to create a cellular > interest list, but designing cellular systems in general and the wide range > of topics associated with it are out of scope. > > Not really that far.... Considering the small range of the WLAN base stations and the need for dense population of Base stations for wireless (which is really the major card in the game called mobility), I think that one needs to consider the effects that the deployment of such population of base stations will have to humans. Besides the latter are consumers of the technology (effected by mobile ip) which if not accepted, won't get far Mobile-IP either.... Positioning of the BS has a direct effect on the BS population per square mile...but this is directly controlled by the effect it has on humans....(If you feel threatened by the technology you may always avoid using it....so practicing of mobile-IP gets another good delay which we could all do _without_ ...) The density of the BS population affects directly the amount of cell handoffs (which is what mobile-IP _is_ currently concerned with) ....which leads me to believe that the health and safety effects on humans by the deployment of BSs controls implicitly cell radius and thus handoff rates.... Since at the moment Mobile-IP cannot overprovision for handoff rates...I think it would be wise to consider all influencing (albeit peripheral ) factors...before ignoring the issue... Theo From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 1 13:46:11 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01183 for ; Mon, 1 May 2000 13:46:10 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.64A3E710@standards.nortelnetworks.com>; Mon, 1 May 2000 13:37:28 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 28712 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 1 May 2000 13:37:02 -0400 Received: from u-mail.rd.francetelecom.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EF1D5810@standards.nortelnetworks.com>; Mon, 1 May 2000 13:27:01 -0400 Received: by u-mail.rd.francetelecom.com with Internet Mail Service (5.5.2448.0) id <29KAMQB2>; Mon, 1 May 2000 10:31:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFB393.2104479A" Message-ID: <337055FBC675D311A85D00508B5A9C4F2DDCC2@u-mail.rd.francetelecom.com> Date: Mon, 1 May 2000 10:31:48 -0700 Reply-To: "LALLIER, Olivier FTR&D" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "LALLIER, Olivier FTR&D" Subject: [MOBILE-IP] Mobile IP WLAN Standard organization ? 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_01BFB393.2104479A Content-Type: text/plain; charset="iso-8859-1" Hi, I am project manager in France Telecom R&D. We are actually working on Mobile IP IPv4 / IPv6 implementation on new wireless LAN standards (HiperLAN2 / 802.11/Bluetooth). Is there a standard organization dedicated to Mobile IP over WLAN ? Thanks for you answer ! Olivier Lallier France Telecom R&D 1000 Marina Bd, Suite 300 Brisbane, CA 94005 Tel : 650 875 1559 Fax : 650 875 1505 ------_=_NextPart_001_01BFB393.2104479A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mobile IP WLAN Standard organization ?

Hi,

I am project manager in France Telecom = R&D. We are actually working on Mobile IP IPv4 / IPv6 = implementation on new wireless LAN standards (HiperLAN2 / = 802.11/Bluetooth).

Is there a standard organization = dedicated to Mobile IP over WLAN ?

Thanks for you answer !

Olivier Lallier
France Telecom R&D
1000 Marina Bd, Suite 300
Brisbane, CA 94005
Tel : 650 875 1559
Fax : 650 875 1505

------_=_NextPart_001_01BFB393.2104479A-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 1 13:56:41 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01307 for ; Mon, 1 May 2000 13:56:41 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.17F0AB90@standards.nortelnetworks.com>; Mon, 1 May 2000 13:49:38 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 28946 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 1 May 2000 13:47:50 -0400 Received: from dumburken.it.kth.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D71A01C0@standards.nortelnetworks.com>; Mon, 1 May 2000 13:47:50 -0400 Received: (from maguire@localhost) by dumburken.it.kth.se (8.9.3/8.9.3) id TAA01994; Mon, 1 May 2000 19:54:20 +0200 (MET DST) X-Authentication-Warning: dumburken.it.kth.se: maguire set sender to maguire@dumburken.it.kth.se using -f References: <7195C03599D9D311BE580008C75697EB443241@il33exm01.wes.mot.com> <390DBC3F.F2CE6EDF@cs.ucl.ac.uk> Message-ID: <200005011754.TAA01994@dumburken.it.kth.se> Date: Mon, 1 May 2000 19:54:20 +0200 Reply-To: Gerald Maguire Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gerald Maguire Subject: Re: [MOBILE-IP] peripheral concern... X-To: t.pagtzis@cs.ucl.ac.uk To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <390DBC3F.F2CE6EDF@cs.ucl.ac.uk> (message from Theo PAGTZIS on Mon, 1 May 2000 18:17:51 +0100) Actually if what you are concerned about is the power level which an individual is exposed to, then the smaller the cells the better (atleast down to a single user per cell). In the case of only one user per cell, there only needs to be a signal in this cell if _this_ user wants to communicate. In addition all the signalling is _only_ that which the user wants, so if they don't want something there is no reason to transmit to them, hence the exposure can be as low as practical to carry out this user's communication needs. A side effect of this approach is that non-users have very little exposure. Note that as cells may not have infinitely sharp fall-off, there is energy radiated outside of the cell. However, it benefits the system designers to minimize this -- since it decreases costs, limits interference, increases capacity, ... . In a similar fashion mobile devices will want to radiate as little power as possible to accomplish their communication task, since this will reduce their power requirements and hence reduce battery weight or increase battery life. You have stated that "Since at the moment Mobile-IP cannot overprovision for handoff rates..." but this is not true, in fact the solutions proposed by Vatn and Wu both demonstrate that you can think of a user moving through space as creating a bow wave and a trailing wake. The bow wave corresponds to simulcasting additional copies of packets to the cells that the user is most likely to enter next, while the trailing wake consists of the copies being sent to where the user used to be. Depending on the speed of the user in comparison to the time delays involved in establishing and terminating routing of packets these waves will be larger or smaller. As the user's velocity vector decreases in magnitude the effects (both fore and aft) become smaller. At high acceleration the effects of the user's movement are most widespread and the total system emergy used is high, but at zero acceleration (but constant velocity) the energy used will be directly related to the delays in control signaling {assuming a homogeneous cell structure}. In heterogeneous systems with different sized cells there will probably be "critical" velocities and accelerations which trigger vertical handoffs. Chip From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 1 14:03:49 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01508 for ; Mon, 1 May 2000 14:03:49 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.14B11B80@standards.nortelnetworks.com>; Mon, 1 May 2000 13:56:42 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 28906 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 1 May 2000 13:54:54 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6DD32BB0@standards.nortelnetworks.com>; Mon, 1 May 2000 13:44:53 -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 LAA12643 for ; Mon, 1 May 2000 11:51:25 -0600 (MDT) Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM [129.146.51.34]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id KAA23868; Mon, 1 May 2000 10:51:24 -0700 (PDT) Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA10253; Mon, 1 May 2000 10:51:23 -0700 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Mon, 1 May 2000 10:51:22 -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] handover: proactive versus reactive X-To: cnyap To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <007501bfb382$8fcf2160$2c0ba78f@dcs.shef.ac.uk> > Hi PatC > > 1) What would you suggest of a link layer hint to IP layer? Well, first off, PPP doesn't provide any mobility "hints" per say. PPP is a method of negotiating configuration, and framing. We can keep the framing, but the actual air interface is the one that provides the "hints" we need. > 2) Isn't air link essential as a perquisite for link layer hint? absolutely! And it has nothing to do with PPP > 3) Why would not be nice to use the confirmation of IP address negotiation > as a link layer hint? Because Mobile IP always does it, and it does so in a single round trip. Why add more latency and packets at the problem than necessary? PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 1 14:06:56 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01578 for ; Mon, 1 May 2000 14:06:55 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5E8E1AA0@standards.nortelnetworks.com>; Mon, 1 May 2000 13:58:46 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 28952 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 1 May 2000 13:58:16 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E68637F0@standards.nortelnetworks.com>; Mon, 1 May 2000 13:48: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 LAA15045 for ; Mon, 1 May 2000 11:54:47 -0600 (MDT) Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM [129.146.51.34]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id KAA24744 for ; Mon, 1 May 2000 10:54:45 -0700 (PDT) Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA11597; Mon, 1 May 2000 10:54:44 -0700 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Mon, 1 May 2000 10:54: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] peripheral concern... To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <7195C03599D9D311BE580008C75697EB44324B@il33exm01.wes.mot.com> > No, it's too far off topic. All, I am in the process of setting up a new mailing list, that can be used to discuss cellular related issues, that are off-topic for this mailing list. The mailing list will be cellular@cdma-2000.org. I am having some difficulty with sendmail at the moment, and will send a notice to the mailing list when it is up and running. Thanks, PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 1 14:39:21 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02206 for ; Mon, 1 May 2000 14:39:20 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FEA5D9C0@standards.nortelnetworks.com>; Mon, 1 May 2000 14:31:53 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29124 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 1 May 2000 14:30:41 -0400 Received: from bells.cs.ucl.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D3C2B1B0@standards.nortelnetworks.com>; Mon, 1 May 2000 14:30:41 -0400 Received: from ginger.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 1 May 2000 19:36:35 +0100 X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: el, en MIME-Version: 1.0 References: <7195C03599D9D311BE580008C75697EB443241@il33exm01.wes.mot.com> <390DBC3F.F2CE6EDF@cs.ucl.ac.uk> <200005011754.TAA01994@dumburken.it.kth.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <390DCEAC.5548C4C1@cs.ucl.ac.uk> Date: Mon, 1 May 2000 19:36:28 +0100 Reply-To: t.pagtzis@cs.ucl.ac.uk Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Theo PAGTZIS Organization: UCL Subject: Re: [MOBILE-IP] peripheral concern... To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit > > Actually if what you are concerned about is the power level which an > individual is exposed to, then the smaller the cells the better > (atleast down to a single user per cell). In the case of only one user > per cell, there only needs to be a signal in this cell if _this_ user > wants to communicate. In addition all the signalling is _only_ that > which the user wants, so if they don't want something there is no > reason to transmit to them, hence the exposure can be as low as > practical to carry out this user's communication needs. > I think that a cell with a single user is rather a scenario that would not meet real world practice. And for the sake of completeness I do not refer to PANs but WLANs.... > > A side effect of this approach is that non-users have very little > exposure. > > Note that as cells may not have infinitely sharp fall-off, there is > energy radiated outside of the cell. However, it benefits the system > designers to minimize this -- since it decreases costs, limits > interference, increases capacity, ... . > > In a similar fashion mobile devices will want to radiate as little > power as possible to accomplish their communication task, since this > will reduce their power requirements and hence reduce battery weight > or increase battery life. > > You have stated that "Since at the moment Mobile-IP cannot > overprovision for handoff rates..." but this is not true, Perhaps I was unclear, what I mean is that fast handoffs at the moment are an issue for Mobile-IP.. to require fast handoffs you either need to have too many small cells (constant velocity) or keep cell size the same and increase velocity, or both. I was refering to the first case only... So going back to original question: "What are the link layer hints that MIP _may_ want to be aware of, to effect handoffs successfully in terms of performance or other"? Should or shouldn't MIP keep independent of link layer considerations. Would the spec like to encourage awareness but enforce it? What is the precedence that PPP has established (if any) - on link layer hints? Theo From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 1 14:43:18 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02434 for ; Mon, 1 May 2000 14:43:18 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8FA090F0@standards.nortelnetworks.com>; Mon, 1 May 2000 14:35:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29159 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 1 May 2000 14:35:34 -0400 Received: from cedar.dcs.shef.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8277BB10@standards.nortelnetworks.com>; Mon, 1 May 2000 14:35:34 -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 TAA17142; Mon, 1 May 2000 19:41:57 +0100 (BST) 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.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Message-ID: <00f101bfb38c$2ee4c080$2c0ba78f@dcs.shef.ac.uk> Date: Mon, 1 May 2000 17:42:04 +0100 Reply-To: cnyap Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: cnyap Subject: Re: [MOBILE-IP] handover: proactive versus reactive X-To: "pcalhoun@eng.sun.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi PatC > > 1) What would you suggest of a link layer hint to IP layer? > > Well, first off, PPP doesn't provide any mobility "hints" per say. PPP is a > method of negotiating configuration, and framing. We can keep the framing, but > the actual air interface is the one that provides the "hints" we need. > 1a) "hints" can be in any form. It is really depend on how view it. > > 2) Isn't air link essential as a perquisite for link layer hint? > absolutely! And it has nothing to do with PPP 2a) PPP confirmed air link follow directly, providing mobile node an IP addess which is used as a link layer hint for IIP. That is essentially, the type of "hints" you mentioned above. > > 3) Why would not be nice to use the confirmation of IP address negotiation > > as a link layer hint? > Because Mobile IP always does it, and it does so in a single round trip. Why > add more latency and packets at the problem than necessary? 3a) This need to based on an assumption there is always a link below IP, which is not necessary always true. Even so, Mobile IP always have to do it, even there is no occurance of handoffs. In Itinerant IP (IIP) model of mobility. PPP does it ONCE in a SINGLE trip with much higher confident during handoffs ONLY. In comparsion to wasteful, undetermistic Mobile IP advertisments model. Cheers ------------------------------------------------------------------- Chern Nam Yap Mobile Communication System Researcher University of Sheffield Department of Electronic and Electrical Engineering Regent Court 211 Portobello Street Sheffield S1 4DP, England Tel: +44 114 222 3308 Web: http://www.mobile1.net E-mail: cny@dcs.shef.ac.uk From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 1 15:17:30 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03548 for ; Mon, 1 May 2000 15:17:29 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.55A4B7A0@standards.nortelnetworks.com>; Mon, 1 May 2000 15:10:06 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29294 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 1 May 2000 15:08:36 -0400 Received: from dumburken.it.kth.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1FA79C80@standards.nortelnetworks.com>; Mon, 1 May 2000 15:08:36 -0400 Received: (from maguire@localhost) by dumburken.it.kth.se (8.9.3/8.9.3) id VAA02176; Mon, 1 May 2000 21:15:03 +0200 (MET DST) X-Authentication-Warning: dumburken.it.kth.se: maguire set sender to maguire@dumburken.it.kth.se using -f References: <7195C03599D9D311BE580008C75697EB443241@il33exm01.wes.mot.com> <390DBC3F.F2CE6EDF@cs.ucl.ac.uk> <200005011754.TAA01994@dumburken.it.kth.se> <390DCEAC.5548C4C1@cs.ucl.ac.uk> Message-ID: <200005011915.VAA02176@dumburken.it.kth.se> Date: Mon, 1 May 2000 21:15:03 +0200 Reply-To: Gerald Maguire Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gerald Maguire Subject: Re: [MOBILE-IP] peripheral concern... X-To: t.pagtzis@cs.ucl.ac.uk To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <390DCEAC.5548C4C1@cs.ucl.ac.uk> (message from Theo PAGTZIS on Mon, 1 May 2000 19:36:28 +0100) I think that a cell with a single user is rather a scenario that would not meet real world practice. And for the sake of completeness I do not refer to PANs but WLANs.... I disagree with respect to the definition of PAN -- I would think that the PAN is the network which moves with me when I move, while a femtocell of a WLAN is a cell that just encompasses me and perhaps a few things very near to me. As I can move through a considerable number of such very small cells over the course of a day, I will want Mobile IP support for many of the devices which move with me. I seem Mobile IP as providing the mechanims, but that an external agent should provide the policy of when to do handoffs and to whom. The question then becomes how the agent is going to tell Mobile IP its decisions and how Mobile IP can indicate that it needs a decision and provide some of its current observations. With respect to observations, it would see that via (SNMP) access to the Mobile IP and interface MIBs that we should be able to access all the externally observable behavior/information. This enables the agent to be local or remote (however, if the agent is remote it must be able to act only when there is connectivity to the mobile and the mobile will need some fall back behavior -- much as space probes have). What I'm unclear on is how the agent should tell Mobile IP its decisions. Should this be via manipulating the Mobile IP MIB or via an API (much as configuring routers can be done via SNMP or a command line interface). Chip From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 1 15:37:22 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04033 for ; Mon, 1 May 2000 15:37:21 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.243BC340@standards.nortelnetworks.com>; Mon, 1 May 2000 15:30:12 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29366 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 1 May 2000 15:28:55 -0400 Received: from bells.cs.ucl.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F61AD550@standards.nortelnetworks.com>; Mon, 1 May 2000 15:28:55 -0400 Received: from ginger.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 1 May 2000 20:34:41 +0100 X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: el, en MIME-Version: 1.0 References: <7195C03599D9D311BE580008C75697EB443241@il33exm01.wes.mot.com> <390DBC3F.F2CE6EDF@cs.ucl.ac.uk> <200005011754.TAA01994@dumburken.it.kth.se> <390DCEAC.5548C4C1@cs.ucl.ac.uk> <200005011915.VAA02176@dumburken.it.kth.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <390DDC4A.CBBE19F4@cs.ucl.ac.uk> Date: Mon, 1 May 2000 20:34:34 +0100 Reply-To: t.pagtzis@cs.ucl.ac.uk Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Theo PAGTZIS Organization: UCL Subject: Re: [MOBILE-IP] peripheral concern... To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Chip, I tried to keep silent after Rob's call for adherence to MIP only issues... > > > I disagree with respect to the definition of PAN -- I would think that > the PAN is the network which moves with me when I move, If the network moves with you....it smells like Adhoc nets....unless you refer to devs that move but only in the same cell ... Do you feel that it should be pure MIP that should cater for these small nets ...sort of Bluetooth PANs with an attitude nets...I think it may want something more lightweight... > while a > femtocell of a WLAN is a cell that just encompasses me and perhaps a > few things very near to me. As I can move through a considerable > number of such very small cells over the course of a day, I will want > Mobile IP support for many of the devices which move with me. > > I seem Mobile IP as providing the mechanims, but that an external > agent should provide the policy of when to do handoffs and to whom. > The question then becomes how the agent is going to tell Mobile IP its > decisions and how Mobile IP can indicate that it needs a decision and > provide some of its current observations. > smells like admission control....in that case you may want to set a policy enforcment point talking with BSs....or better the FAs that would control entry through the BS.. > > With respect to observations, it would see that via (SNMP) access to > the Mobile IP and interface MIBs that we should be able to access all > the externally observable behavior/information. This enables the > agent to be local or remote (however, if the agent is remote it must > be able to act only when there is connectivity to the mobile and the > mobile will need some fall back behavior -- much as space probes have). > > What I'm unclear on is how the agent should tell Mobile IP its > decisions. Should this be via manipulating the Mobile IP MIB or via an > API (much as configuring routers can be done via SNMP or a command > line interface). Theo From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 1 15:46:29 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04243 for ; Mon, 1 May 2000 15:46:28 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.68F2BF10@standards.nortelnetworks.com>; Mon, 1 May 2000 15:39:17 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29365 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 1 May 2000 15:37:52 -0400 Received: from ftpbox.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D0CE3030@standards.nortelnetworks.com>; Mon, 1 May 2000 15:27:52 -0400 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id MAA18681; Mon, 1 May 2000 12:34:23 -0700 (MST)] Received: [from relay1.cig.mot.com (relay1.cig.mot.com [136.182.15.23]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id MAA26323; Mon, 1 May 2000 12:34:21 -0700 (MST)] Received: from Motorola.Com (dr05_239.il33.wes.mot.com [154.56.5.239]) by relay1.cig.mot.com (8.8.8+Sun/SCERG-RELAY-1.11b) with ESMTP id OAA19733; Mon, 1 May 2000 14:34:13 -0500 (CDT) X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: <337055FBC675D311A85D00508B5A9C4F2DDCC2@u-mail.rd.francetelecom.com> Content-Type: multipart/mixed; boundary="------------CAA5FA05664187ACB395E0ED" Message-ID: <390DD95A.236E54F2@Motorola.Com> Date: Mon, 1 May 2000 14:22:02 -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] Mobile IP WLAN Standard organization ? X-To: "LALLIER, Olivier FTR&D" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------CAA5FA05664187ACB395E0ED Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Yes the Mobile-IP working group in the IETF! The last thing we need is yet another standards body. Phil Roberts has recently suggest that Mobile-IP expand its scope to faster handovers across diverse radio access networks. In my mind in many others this includes WLAN/WPAN (802.11/Bluetooth), etc. Phil Neumiller > "LALLIER, Olivier FTR&D" wrote: > > Hi, > > I am project manager in France Telecom R&D. We are actually working on Mobile IP IPv4 / IPv6 implementation on new > wireless LAN standards (HiperLAN2 / 802.11/Bluetooth). > > Is there a standard organization dedicated to Mobile IP over WLAN ? > > Thanks for you answer ! > > Olivier Lallier > France Telecom R&D > 1000 Marina Bd, Suite 300 > Brisbane, CA 94005 > Tel : 650 875 1559 > Fax : 650 875 1505 --------------CAA5FA05664187ACB395E0ED Content-Type: text/x-vcard; charset=us-ascii; name="Phillip.Neumiller.vcf" Content-Description: Card for Phil Neumiller Content-Disposition: attachment; filename="Phillip.Neumiller.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Neumiller;Phillip tel;pager:1258338@skytel.com tel;cell:iDen 847-9804238 / CDMA 847-370-3899 tel;home:847-516-2009 tel;work:847-576-9624 x-mozilla-html:TRUE url:www.mot.com/bluetooth org:Motorola, Inc.;Personal Area Networking (PAN) adr:;;50 E Commerce Drive;Schaumburg;IL;60195;USA version:2.1 email;internet:Phillip.Neumiller@Motorola.com title:Advanced Standards and Architecture fn:Phil Neumiller end:vcard --------------CAA5FA05664187ACB395E0ED-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 1 16:06:32 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04863 for ; Mon, 1 May 2000 16:06:32 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.389BD6F0@standards.nortelnetworks.com>; Mon, 1 May 2000 15:59:24 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29475 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 1 May 2000 15:57:40 -0400 Received: from motgate.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9499DDF0@standards.nortelnetworks.com>; Mon, 1 May 2000 15:47:39 -0400 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id MAA12021 for ; Mon, 1 May 2000 12:54:12 -0700 (MST)] Received: [from il33exm01.wes.mot.com (il33exm01.wes.mot.com [154.56.3.118]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id MAA05150 for ; Mon, 1 May 2000 12:54:10 -0700 (MST)] Received: by il33exm01.wes.mot.com with Internet Mail Service (5.5.2650.21) id <28T0BWAF>; Mon, 1 May 2000 14:54:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <7195C03599D9D311BE580008C75697EB443254@il33exm01.wes.mot.com> Date: Mon, 1 May 2000 14:54:02 -0500 Reply-To: Roberts Phil-QA3445 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Roberts Phil-QA3445 Subject: Re: [MOBILE-IP] Mobile IP WLAN Standard organization ? X-To: NEUMILLER PHILLIP-QA2757 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Well, be careful here. If someone is looking for a group that does specific interfaces to lower layer technologies, it's not us. If one is looking for a method that's "access technology independent," we're open. -----Original Message----- From: NEUMILLER PHILLIP-QA2757 Sent: Monday, May 01, 2000 2:22 PM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] Mobile IP WLAN Standard organization ? Yes the Mobile-IP working group in the IETF! The last thing we need is yet another standards body. Phil Roberts has recently suggest that Mobile-IP expand its scope to faster handovers across diverse radio access networks. In my mind in many others this includes WLAN/WPAN (802.11/Bluetooth), etc. Phil Neumiller > "LALLIER, Olivier FTR&D" wrote: > > Hi, > > I am project manager in France Telecom R&D. We are actually working on Mobile IP IPv4 / IPv6 implementation on new > wireless LAN standards (HiperLAN2 / 802.11/Bluetooth). > > Is there a standard organization dedicated to Mobile IP over WLAN ? > > Thanks for you answer ! > > Olivier Lallier > France Telecom R&D > 1000 Marina Bd, Suite 300 > Brisbane, CA 94005 > Tel : 650 875 1559 > Fax : 650 875 1505 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 2 07:59:55 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28115 for ; Tue, 2 May 2000 07:59:55 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.55F1C090@standards.nortelnetworks.com>; Tue, 2 May 2000 7:52:16 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30993 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 2 May 2000 07:50:17 -0400 Received: from tech.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0E6B3490@standards.nortelnetworks.com>; Tue, 2 May 2000 7:50:16 -0400 Received: from ORANLT ([171.69.210.4]) by tech.cisco.com (Netscape Messaging Server 3.61) with SMTP id AAC194A; Tue, 2 May 2000 07:56:32 -0400 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Message-ID: Date: Tue, 2 May 2000 07:56:29 -0400 Reply-To: Dave Oran Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Dave Oran Subject: Re: [MOBILE-IP] handover X-To: Roberts Phil-QA3445 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <7195C03599D9D311BE580008C75697EB44323D@il33exm01.wes.mot.com> Content-Transfer-Encoding: 7bit Some words from your friendly, neighborhood area director. I'd like to emphasize what Phil has said in the message below - that the scope is confined to the general charter of Mobile IP itself: network layer handoff mechanisms. I'd like to offer the following suggestions for the scope of the work (the working group is of course free to agree to a different set of constraints if that is the consensus): a) methods of micromobility or cell-to-cell handoff accomplished entirely at layer 2 are out of scope, since they are essentally invisible to mobile IP anyway b) methods of handoff that depend sensitively on mobility features of particular layer 2 protocols are also out of scope, but layer 2 information can (and should) be used to optimize handoff latency, routing optimality, administrative afinity, etc. as appropriate. c) handoff methods which - do not involve any layer 2 mobility mechanisms, - make the acutal handoff decision at layer 3 based on layer 2 information, and - which do a handoff autnonmously at layer 2 and inform layer 3 of the new configuration are all in scope. Ideally, all three would be supported by the resulting specification. The idea of defining an abstract layer2/layer 3 interface to express both the informaiton exchange and the handoff invocation seems an essental part of the charter, since the alternative are likely to be out of scope. Hope this contributes to the dleiberations. Dave. > -----Original Message----- > From: IP Routing for Wireless/Mobile Hosts (mobile-ip) > [mailto:MOBILE-IP@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Roberts > Phil-QA3445 > Sent: Friday, April 28, 2000 3:56 PM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: [MOBILE-IP] handover > > > Hi folks, > > Monday we reinitiated the discussion of fast handover support for > Mobile IP. We proposed adding the following line to the charter: 'Develop > an access technology independent method for supporting low > latency handover > between access points within a system or across systems.' > > The intent of providing a smooth handoff solution at the network layer > is for obvious reasons : achieve seamless handoff between networks > (internetworks). Having a solution at the network layer does not > necessarily mean that it must be used when there is a more efficient > or optimal mechanism at a lower layer. Also the objective is to > provide a technology or air interface independent solution (reason for > doing at the network layer). > So depending on whether a smooth handoff mechanism defined at the > network layer is applied in the micro-mobility environment or at a > more macro level, within the same technology or across different > technologies, inter/intra domains etc. may vary to a certain degree. > > We've let the conversation run somewhat open loop in order to hear > what people have to say. There hasn't been anything that sounds like > an objection to adding this to the charter so we're going to go ahead > and forward it to the ADs for approval. We'll put a Dec 2000 date on > it. > > We believe it's important to put some constraints for discussion and > submissions. Although the context of developing fast handover for > cellular applications in particular may be all IP cellular networks or may > be > from the setting of some specific link layer technologies, the > group is not > chartered to design all IP cellular networks or to specify interfaces to > specific link layers. This is not to say that such work is not > necessarily > needed, but that it is outside the scope of this working group. > > > Phil and Raj > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 2 10:26:51 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01871 for ; Tue, 2 May 2000 10:26:51 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E6B39D60@standards.nortelnetworks.com>; Tue, 2 May 2000 10:19:29 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31147 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 2 May 2000 10:18:07 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B52C7A00@standards.nortelnetworks.com>; Tue, 2 May 2000 10:18:06 -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 IAA17595 for ; Tue, 2 May 2000 08:24:34 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA13312 for ; Tue, 2 May 2000 07:24:33 -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 HAA24772 for ; Tue, 2 May 2000 07:24:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: SL1EkZTUYVjxFait7k+SvQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Message-ID: <200005021424.HAA24772@nasnfs.eng.sun.com> Date: Tue, 2 May 2000 07:27:15 -0700 Reply-To: James Kempf Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: James Kempf Subject: [MOBILE-IP] IPv6 Mobility Last Call Question To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Some of the options for fast handover we've been discussing recently may call for an FA-like entity in IPv6. I've heard this variously referred to as an "attendent". Is the IPv6 mobility draft last call the right time to bring up this issue, or should it perhaps wait for a separate discussion and a separate draft? jak From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 2 10:46:52 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02307 for ; Tue, 2 May 2000 10:46:51 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B551ADE0@standards.nortelnetworks.com>; Tue, 2 May 2000 10:39:35 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31209 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 2 May 2000 10:39:14 -0400 Received: from clea.qualcomm.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A85AE480@standards.nortelnetworks.com>; Tue, 2 May 2000 10:39:13 -0400 Received: from jwillkie1 (jwillkie1.qualcomm.com [129.46.219.171]) by clea.qualcomm.com (8.9.3/8.9.3/1.0) with SMTP id HAA03171; Tue, 2 May 2000 07:45:47 -0700 (PDT) X-Sender: jwillkie@mail1.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 References: <"Your message with ID" <4.1.20000501082055.00d8e760@mail1.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <4.1.20000502072308.00d97c70@mail1.qualcomm.com> Date: Tue, 2 May 2000 07:45:37 -0700 Reply-To: Jim Willkie Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Jim Willkie Subject: Re: [MOBILE-IP] handover: proactive versus reactive X-To: "pcalhoun@eng.sun.com" X-cc: "pcalhoun@eng.sun.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: At 09:04 AM 5/1/00 -0700, pcalhoun@eng.sun.com wrote: --cut-- >> Folks: >> Here's a couple of counter points to the above well focused thoughts: >> >> If MobileIP was a required piece of the wireless packet network then the >> above arguments hold and a state-less link layer is viable. But the current >> (at least CDMA) wireless network does not have MobileIP and uses PPP to >> negotiate IP addresses. This capability will have to continue to exist when >> a mobileIP solution is rolled out. >> >> Many deployed cellular packet network use PAP or CHAP to authenticate the >> packet user. One would think that this capability will continue to be >> desired by operators. >> >> So it would seem that for at least the CDMA packet network both >> MobileIP-capable and the the so-called simple IP capabilities will continue >> to co-exist. This reality would seem to make the on-going need for PPP to >> remain. >> >> Comments please.... > >Jim, you are correct. Even 3G supports simple IP, which is essentially dial-up >PPP over a wireless link. So, PPP is still in the architecture for legacy >devices, and I agree that this service will remain to be provided as long as >there are some legacy devices around. > >However, there is an opportunity to redesign the network, and it seems like >the best time to move away from PPP. This new design would be similar to the >thoughts that I've been discussing in various threads. > >So, while I agree with your comments, let's see if we can move forward and do >it right. I don't think that creating next generation networks that rely on >antiquated technology that does nothing but add overhead seems pointless. Pat: I can see the need to specify a more optimized and focused link layer for mobileIP. If it is done correctly and fills a valid need then perhaps the next wave of info devices could utilize it. But the reasons stated so far are 1) the only piece of PPP used is encapsulation and 2) the dialup aspect of PPP should be removed. I may be missing something (in fact I probably am) but the threshold to toss away PPP should be a little higher, given all the flexibility it has. However it seems very prudent to pursue this optimized-for-mobileIP link layer. But be very careful not to invent another PPP. For example if this new layer needs a negotiation mechanism then one would question the effort. Thank you for the forum... please let me know what list this topic will be moving to... Jim Willkie On the other hand if this link layer needs to put a negotiation mechanism in then there would need to be a very valid reason to From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 2 10:51:13 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02379 for ; Tue, 2 May 2000 10:51:12 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FD5B73A0@standards.nortelnetworks.com>; Tue, 2 May 2000 10:41:36 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31221 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 2 May 2000 10:40:18 -0400 Received: from ish7.ericsson.com.au (203.61.155.111) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CC27C770@standards.nortelnetworks.com>; Tue, 2 May 2000 10:40:13 -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 AAA21750; Wed, 3 May 2000 00:46:33 +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 AAA19910; Wed, 3 May 2000 00:46:53 +1000 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2448.0) id ; Wed, 3 May 2000 00:46:31 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFB445.340A8130" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A5089EAFDC@eaubrnt018.epa.ericsson.se> Date: Wed, 3 May 2000 00:46:30 +1000 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question 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_01BFB445.340A8130 Content-Type: text/plain The term "attendant" is used in the AAA draft for IPv6. You might be thinking of the "MAP" in the HMIPv6 draft. Anyway, I don't think this is the right time to discuss extensions to MIPv6. They should be assessed when the drafts you're referring to are due for last call. The MIPv6 draft is independent of other proposals for fast handoff and there is no need to associate it with them at this time. > Some of the options for fast handover we've been discussing recently may > call for an FA-like entity in IPv6. I've heard this variously referred > to as an "attendent". Is the IPv6 mobility draft last call the right > time to bring up this issue, or should it perhaps wait for a separate > discussion > and a separate draft? > > ------_=_NextPart_001_01BFB445.340A8130 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] IPv6 Mobility Last Call Question

    The term = "attendant" is used in the AAA draft for IPv6. You might be = thinking of the "MAP" in the HMIPv6 draft.
    Anyway, I don't = think this is the right time to discuss extensions to MIPv6. They = should be assessed when the drafts you're referring to are due for last = call. The MIPv6 draft is independent of other proposals for fast = handoff and there is no need to associate it with them at this = time.


    Some of the options for fast handover = we've been discussing recently may
    call for an FA-like entity in IPv6. = I've heard this variously referred
    to as an "attendent". Is = the IPv6 mobility draft last call the right
    time to bring up this issue, or = should it perhaps wait for a separate discussion
    and a separate draft?

             &nb= sp;  

------_=_NextPart_001_01BFB445.340A8130-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 2 10:56:02 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02473 for ; Tue, 2 May 2000 10:56:01 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FA7FFC90@standards.nortelnetworks.com>; Tue, 2 May 2000 10:48:40 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31279 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 2 May 2000 10:47:00 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BEBC9BF0@standards.nortelnetworks.com>; Tue, 2 May 2000 10:47:00 -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 HAA02333; Tue, 2 May 2000 07:53:34 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id HAA02836; Tue, 2 May 2000 07:43:08 -0700 X-Virus-Scanned: Tue, 2 May 2000 07:43:08 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from (charliep.iprg.nokia.com [205.226.2.89]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma002557; Tue, 2 May 00 07:43:02 -0700 X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <200005021424.HAA24772@nasnfs.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <390EEBE7.7E768582@iprg.nokia.com> Date: Tue, 2 May 2000 07:53:27 -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 Mobility Last Call Question X-To: James Kempf To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Jim, Bottom line: I do NOT think this should be discussed in the Mobile IPv6 draft. In fact, I think we should do everything possible to expedite the progress of that draft. Adding new functionality would be a mistake at this point. The "attendant" function is as described in the AAA requirements draft for Mobile IP. A foreign agent was created to hand out care-of addresses. If something does not hand out care-of addresses, I don't think it resembles a foreign agent. What is being proposed is not at all a foreign agent, but an authorization agent. While it is not coincidental that the foreign agent in IPv4 makes a good locus for the authorization agent ("attendant") function, it isn't logically necessary. I think it is a matter of good engineering, efficiency, and convenience, more than an absolute given, that causes us to consider co-locating these functions. In v6, the authorization functions need a new locus, since the old one isn't available. Furthermore, I don't believe that the attendant functionality is purely a Mobile IP thing, although Mobile IP certainly brings into clear focus the need for such a thing. Regards, Charlie P. PS. Do you have comments about our recent AAAv6 draft where some of these issues are discussed? We will have a new revision soon, but it doesn't negate the discussion in our existing draft. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 2 11:18:01 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03093 for ; Tue, 2 May 2000 11:18:00 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0FE39300@standards.nortelnetworks.com>; Tue, 2 May 2000 11:10:45 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31324 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 2 May 2000 11:10:19 -0400 Received: from motgate2.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9AA94F40@standards.nortelnetworks.com>; Tue, 2 May 2000 11:00:19 -0400 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id IAA23311 for ; Tue, 2 May 2000 08:06:54 -0700 (MST)] Received: [from il33exm01.wes.mot.com (il33exm01.wes.mot.com [154.56.3.118]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id IAA01595 for ; Tue, 2 May 2000 08:06:53 -0700 (MST)] Received: by il33exm01.wes.mot.com with Internet Mail Service (5.5.2650.21) id <28T0BWTJ>; Tue, 2 May 2000 09:50: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: <7195C03599D9D311BE580008C75697EB44325F@il33exm01.wes.mot.com> Date: Tue, 2 May 2000 09:50:17 -0500 Reply-To: Roberts Phil-QA3445 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Roberts Phil-QA3445 Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question X-To: James Kempf To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM We want to send this draft to the printers so last call is too late for this. Subsequent work that's needed should go to separate supplemental drafts. -----Original Message----- From: James Kempf [mailto:James.Kempf@ENG.SUN.COM] Sent: Tuesday, May 02, 2000 9:27 AM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: [MOBILE-IP] IPv6 Mobility Last Call Question Some of the options for fast handover we've been discussing recently may call for an FA-like entity in IPv6. I've heard this variously referred to as an "attendent". Is the IPv6 mobility draft last call the right time to bring up this issue, or should it perhaps wait for a separate discussion and a separate draft? jak From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 2 11:30:14 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03341 for ; Tue, 2 May 2000 11:30:13 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BEB7EEC0@standards.nortelnetworks.com>; Tue, 2 May 2000 11:22:48 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31364 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 2 May 2000 11:20:58 -0400 Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7D607C30@standards.nortelnetworks.com>; Tue, 2 May 2000 11:20:58 -0400 Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id SAA07090; Tue, 2 May 2000 18:27:27 +0300 (EETDST) Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id SAA12507; Tue, 2 May 2000 18:27:25 +0300 (EETDST) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id ; Tue, 2 May 2000 10:26:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2BCD4F97@daeis07nok> Date: Tue, 2 May 2000 10:25:46 -0500 Reply-To: Basavaraj.Patil@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question X-To: James.Kempf@Eng.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM James, The IPV6 Mobility draft is not the place for this concept. I would defer this to a separate discussion. Right now the key objective is to get the IPv6 mobility draft through to the IESG and on standards track. -Basavaraj > -----Original Message----- > From: EXT James Kempf [mailto:James.Kempf@Eng.Sun.COM] > Sent: Tuesday, May 02, 2000 9:27 AM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: [MOBILE-IP] IPv6 Mobility Last Call Question > > > Some of the options for fast handover we've been discussing > recently may > call for an FA-like entity in IPv6. I've heard this variously referred > to as an "attendent". Is the IPv6 mobility draft last call the right > time to bring up this issue, or should it perhaps wait for a > separate discussion > and a separate draft? > > jak > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 2 12:24:18 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04392 for ; Tue, 2 May 2000 12:24:17 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.503936E0@standards.nortelnetworks.com>; Tue, 2 May 2000 12:16:58 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31496 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 2 May 2000 12:16:14 -0400 Received: from p-biset.issy.cnet.fr (139.100.0.33) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.357C4630@standards.nortelnetworks.com>; Tue, 2 May 2000 12:16:13 -0400 Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2448.0) id <2K2JQBGS>; Tue, 2 May 2000 18:12:08 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <7D59335FDAE0D011A3350060974B1C7202863454@l-mhs3.lannion.cnet.fr> Date: Tue, 2 May 2000 18:11:33 +0200 Reply-To: LARREUR Elodie FTRD/DAC/LAN Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: LARREUR Elodie FTRD/DAC/LAN Subject: [MOBILE-IP] tunnels To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA04392 Hello, I'm using 2 Cisco 2500 routers as HA and FA. I 'd like to change some tunnel parameters such as bandwidth inside HA configuration because I noticed that it was quite low as described below: HA#sh interfaces tunnel 0 Tunnel0 is up, line protocol is up Hardware is Tunnel Interface is unnumbered. Using address of Ethernet0 (10.10.0.49) MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec, reliability 255/255, txload 255/255, rxload 1/255 Encapsulation TUNNEL, loopback not set Keepalive set (10 sec) Tunnel source 10.10.0.49, destination 10.10.0.2 Tunnel protocol/transport IP/IP, key disabled, sequencing disabled Checksumming of packets disabled, fast tunneling enabled Last input never, output 00:07:28, output hang never Last clearing of "show interface" counters never Queueing strategy: fifo Output queue 0/0, 0 drops; input queue 9/75, 0 drops 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 54000 bits/sec, 4 packets/sec 0 packets input, 0 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 4503 packets output, 6413031 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out HA#sh ip mobile tun Mobile Tunnels: Tunnel0: src 10.10.0.49, dest 10.10.0.2 encap IP/IP, mode reverse-allowed, tunnel-users 1 IP MTU 1480 bytes outbound interface Serial0 HA created, fast switching enabled, ICMP unreachable enabled 0 packets input, 0 bytes, 0 drops 4611 packets output, 6566967 bytes HA# Is there someone who would know how to increase the tunnel bandwidth value ? Thanks Elodie Larreur France Télécom R&D Phone: + 33 2 96 05 20 50 Fax: + 33 2 96 05 18 52 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 2 12:33:25 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04625 for ; Tue, 2 May 2000 12:33:24 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.947DC1D0@standards.nortelnetworks.com>; Tue, 2 May 2000 12:26:02 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31490 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 2 May 2000 12:25:25 -0400 Received: from gandalf.axion.bt.co.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.12F13210@standards.nortelnetworks.com>; Tue, 2 May 2000 12:15:15 -0400 Received: from cbtlipnt02.btlabs.bt.co.uk by gandalf (local) with ESMTP; Tue, 2 May 2000 15:24:51 +0100 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2651.88) id ; Tue, 2 May 2000 15:24:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.88) Content-Type: text/plain Message-ID: Date: Tue, 2 May 2000 15:24:41 +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] Hand-over resend To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Folks, The following message was sent to the list last week and whilst it is on the Nortel archive, it appears it did not hit the main list ? Date: Fri, 28 Apr 2000 08:15:51 -0400 Reply-To: Alan O'Neill Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Alan O'Neill Subject: Re: handover All, For those who do not know me I work in BT on all IP architecture with primary focus on UMTS Rel2001 but also including mobility across a range of access technologies. I am also co-author of which attempts to provide a generic IP hand-over architecture which will support UMTS:GTP, MobileIP, but mainly routed mobility. Co-authors are Scott Corson the MANET wg co-chair and George Tsirtsis also of BT. We would like to to see hand-over control and interactions with the radio systems to be defined in a generalised way so that an operator can migrate from existing GTP through possibly MobileIP to the holy grail of a scalable mobile enhanced routing protocol (we use modified MANET:TORA for this at the moment), with co-existence where commercial models dictate for the data-path options (tunnelled / routed etc) . The aim is to facilitate a common IP hand-over interface so that the operator can have all options co-exist, and support evolution between them. We can also see big dangers and interoperability problems if each affected working group designs it's own, non-interworking fast IP hand-over solutions and associated interfaces into the access technologies and systems. The Edge mobility Architecture draft avoids many of the details but hopefully the reader can see the clear need to enable tunnelled and native routed solutions to co-exist, re-using the same AAA, access signalling and policy elements, plus the interfaces into many different access technologies and systems. Our view at this stage is that the solution for the signalling plane requires a combination of extended MobileIP signalling to embrace GTP and routed mobility requirements, plus DHCP extensions. We are presently preparing drafts which detail the mapping of EMA to UMTS, and the detailed signalling pieces. It seems to make sense that a separate short working group be first formed to define the scope and architecture for the IP hand-over work so that common pieces can be identified along with the full set of new protocol requirements. We can then let each existing or resulting working group deal with those protocol requirements which clearly will include MobileIP. Possibly a BOF could be specifically scheduled at the next IETF or even some sort of interim meeting given the all-IP timescales we are all experiencing in this space. Comments appreciated. Regards Alan O'Neill, Scott Corson, George Tsirtsis.... From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 2 13:08:21 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05509 for ; Tue, 2 May 2000 13:08:21 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7B943F50@standards.nortelnetworks.com>; Tue, 2 May 2000 13:01:08 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31611 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 2 May 2000 12:59:54 -0400 Received: from iti-idsc.gov.eg (163.121.12.2) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E8477740@standards.nortelnetworks.com>; Tue, 2 May 2000 12:49:51 -0400 Received: from iti-idsc.gov.eg (seg28.iti.idsc.gov.eg [163.121.28.7] (may be forged)) by iti-idsc.gov.eg (8.9.1b+Sun/8.9.1) with ESMTP id TAA08722 for ; Tue, 2 May 2000 19:57:36 +0300 (EET DST) X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <35436760.6AE45CAC@iti-idsc.gov.eg> Date: Sun, 26 Apr 1998 18:57:04 +0200 Reply-To: ",kj" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: ",kj" Subject: [MOBILE-IP] Mobile-IP To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit We make a new project in Mobile-IP so, we need to know problems needed to be solved in Mobile-IP From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 2 13:29:20 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05826 for ; Tue, 2 May 2000 13:29:19 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6C0CD8A0@standards.nortelnetworks.com>; Tue, 2 May 2000 13:22:10 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31655 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 2 May 2000 13:20:46 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.399C1890@standards.nortelnetworks.com>; Tue, 2 May 2000 13:20:46 -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 LAA12775; Tue, 2 May 2000 11:27:15 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA13157; Tue, 2 May 2000 10:27:14 -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 KAA09365; Tue, 2 May 2000 10:26:45 -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: <200005021726.KAA09365@nasnfs.eng.sun.com> Date: Tue, 2 May 2000 10:29:38 -0700 Reply-To: James.Kempf@eng.sun.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: James Kempf Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question X-To: "Charles E. Perkins" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi Charlie, >The "attendant" function is as described in the AAA requirements >draft for Mobile IP. > >A foreign agent was created to hand out care-of addresses. >If something does not hand out care-of addresses, I don't >think it resembles a foreign agent. > I was thinking particularly of Pat and my proposal for FA assisted handoff. This proposal is motivated by a desire to reduce the requirements on mobile nodes (among other things). Since minimal terminal involvement in handoff is of interest to the cellular community, and IPv6 is being recommended as an early deployment target for telephony, the question came up. The fast handoff discussion has just started, and therefore it is probably better to postpone the discussion on support until it is concluded. But I hope that the fast handoff discusion will keep IPv6 in mind. jak From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 2 14:03:28 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06318 for ; Tue, 2 May 2000 14:03:27 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2E9C7200@standards.nortelnetworks.com>; Tue, 2 May 2000 13:56:15 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31698 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 2 May 2000 13:54:47 -0400 Received: from motgate.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9442DAB0@standards.nortelnetworks.com>; Tue, 2 May 2000 13:44:46 -0400 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id KAA09112 for ; Tue, 2 May 2000 10:51:21 -0700 (MST)] Received: [from il33exm01.wes.mot.com (il33exm01.wes.mot.com [154.56.3.118]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id KAA19253 for ; Tue, 2 May 2000 10:51:21 -0700 (MST)] Received: by il33exm01.wes.mot.com with Internet Mail Service (5.5.2650.21) id <28T0BW57>; Tue, 2 May 2000 12:51: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: <7195C03599D9D311BE580008C75697EB44326E@il33exm01.wes.mot.com> Date: Tue, 2 May 2000 12:51:10 -0500 Reply-To: Roberts Phil-QA3445 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Roberts Phil-QA3445 Subject: Re: [MOBILE-IP] Hand-over resend X-To: "alan.w.oneill@bt.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Alan, this was on the mail list. We were letting people say pretty much whatever they wanted on this issue last week so I didn't respond. I now have a couple of comments. Although a sizeable constituency of the group has the same goal of an all IP mobile enabled network for cellular, the group is not chartered to come up with a transition plan for something like UMTS. That's not to say such isn't needed, it's just beyond the scope of this group. If there are particular aspects of that kind of work that fall into our charter (such as supporting fast handovers) we're certainly willing to take contributions. As far as forming something like a BOF to investigate the appraoch you've outlined, there may be members of this list who are interested in participating, but we're not really the right audience to ask for such an agenda item. Hope this helps, Phil -----Original Message----- From: Alan O'Neill [mailto:alan.w.oneill@bt.com] Sent: Tuesday, May 02, 2000 9:25 AM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] Hand-over resend Folks, The following message was sent to the list last week and whilst it is on the Nortel archive, it appears it did not hit the main list ? Date: Fri, 28 Apr 2000 08:15:51 -0400 Reply-To: Alan O'Neill Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Alan O'Neill Subject: Re: handover All, For those who do not know me I work in BT on all IP architecture with primary focus on UMTS Rel2001 but also including mobility across a range of access technologies. I am also co-author of which attempts to provide a generic IP hand-over architecture which will support UMTS:GTP, MobileIP, but mainly routed mobility. Co-authors are Scott Corson the MANET wg co-chair and George Tsirtsis also of BT. We would like to to see hand-over control and interactions with the radio systems to be defined in a generalised way so that an operator can migrate from existing GTP through possibly MobileIP to the holy grail of a scalable mobile enhanced routing protocol (we use modified MANET:TORA for this at the moment), with co-existence where commercial models dictate for the data-path options (tunnelled / routed etc) . The aim is to facilitate a common IP hand-over interface so that the operator can have all options co-exist, and support evolution between them. We can also see big dangers and interoperability problems if each affected working group designs it's own, non-interworking fast IP hand-over solutions and associated interfaces into the access technologies and systems. The Edge mobility Architecture draft avoids many of the details but hopefully the reader can see the clear need to enable tunnelled and native routed solutions to co-exist, re-using the same AAA, access signalling and policy elements, plus the interfaces into many different access technologies and systems. Our view at this stage is that the solution for the signalling plane requires a combination of extended MobileIP signalling to embrace GTP and routed mobility requirements, plus DHCP extensions. We are presently preparing drafts which detail the mapping of EMA to UMTS, and the detailed signalling pieces. It seems to make sense that a separate short working group be first formed to define the scope and architecture for the IP hand-over work so that common pieces can be identified along with the full set of new protocol requirements. We can then let each existing or resulting working group deal with those protocol requirements which clearly will include MobileIP. Possibly a BOF could be specifically scheduled at the next IETF or even some sort of interim meeting given the all-IP timescales we are all experiencing in this space. Comments appreciated. Regards Alan O'Neill, Scott Corson, George Tsirtsis.... From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 2 14:27:33 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06699 for ; Tue, 2 May 2000 14:27:32 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8FE72F70@standards.nortelnetworks.com>; Tue, 2 May 2000 14:20:26 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31849 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 2 May 2000 14:19:11 -0400 Received: from sirius.ctr.columbia.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.62F9DF80@standards.nortelnetworks.com>; Tue, 2 May 2000 14:19:11 -0400 Received: from comet.columbia.edu (sweetpea.comet.columbia.edu [128.59.68.61]) by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with ESMTP id OAA25209; Tue, 2 May 2000 14:25:45 -0400 (EDT) X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <7195C03599D9D311BE580008C75697EB44326E@il33exm01.wes.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <390F4B44.3D1F3CBB@comet.columbia.edu> Date: Tue, 2 May 2000 14:40:20 -0700 Reply-To: campbell@comet.columbia.edu Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Andrew T. Campbell" Organization: Center for Telecommunications Research Subject: Re: [MOBILE-IP] Hand-over resend X-To: Roberts Phil-QA3445 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Phil: Following up on your note: I think it would be a mistake to have the Mobile IP Working Group do a 3GIP kind of thing or be a vehicle for 2/3G transition to wireless Internet. The Mobile IP WG should charter 4GIP: pure unadulterated IP packet networks based on Mobile IP and packets to and from the mobile host using best effort service. I think too much 3G influence in the group may be a distraction from that. Andrew Roberts Phil-QA3445 wrote: > > Alan, > > this was on the mail list. We were letting people say pretty much > whatever they wanted on this issue last week so I didn't respond. > > I now have a couple of comments. > > Although a sizeable constituency of the group has the same goal of > an all IP mobile enabled network for cellular, the group is not chartered to > come up with a transition plan for something like UMTS. That's not to say > such isn't needed, it's just beyond the scope of this group. If there are > particular aspects of that kind of work that fall into our charter (such as > supporting fast handovers) we're certainly willing to take contributions. > > As far as forming something like a BOF to investigate the appraoch > you've outlined, there may be members of this list who are interested in > participating, but we're not really the right audience to ask for such an > agenda item. > > Hope this helps, > Phil > > -----Original Message----- > From: Alan O'Neill [mailto:alan.w.oneill@bt.com] > Sent: Tuesday, May 02, 2000 9:25 AM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Hand-over resend > > Folks, > > The following message was sent to the list last week and whilst it is on the > Nortel archive, it appears it did not hit the main list ? > > Date: Fri, 28 Apr 2000 08:15:51 -0400 > Reply-To: Alan O'Neill > Sender: "IP Routing for Wireless/Mobile Hosts > (mobile-ip)" > > From: Alan O'Neill > Subject: Re: handover > > All, > > For those who do not know me I work in BT on all IP > architecture with primary focus on UMTS Rel2001 but also including mobility > across a range of access technologies. I am also > co-author of which attempts to provide a generic > IP > hand-over architecture which will support UMTS:GTP, > MobileIP, but mainly routed mobility. Co-authors are Scott Corson the > MANET wg co-chair and George Tsirtsis also of BT. > > We would like to to see hand-over control and > interactions with the radio systems to be defined in a > generalised way so that an operator can migrate from > existing GTP through possibly MobileIP to the holy grail of a scalable > mobile enhanced routing protocol (we use modified > MANET:TORA for this at the moment), with co-existence where commercial > models dictate for the data-path options (tunnelled / > routed etc) . The aim is to facilitate a common IP hand-over interface so > that > the operator can have all options co-exist, and support > evolution between them. We can also see big dangers and interoperability > problems if each affected working group designs it's > own, non-interworking fast IP hand-over solutions and associated interfaces > into the access technologies and systems. > > The Edge mobility Architecture draft > avoids many of the details but hopefully the > reader can see the > clear need to enable tunnelled and native routed > solutions to co-exist, re-using the same AAA, access signalling and policy > elements, plus the interfaces into many different access > technologies and systems. Our view at this stage is that the solution for > the signalling plane requires a combination of extended > MobileIP signalling to embrace GTP and routed mobility requirements, > plus DHCP extensions. We are presently preparing drafts > which detail the mapping of EMA to UMTS, and the detailed signalling > pieces. > > It seems to make sense that a separate short working > group be first formed to define the scope and > architecture for the IP hand-over work so that common > pieces can be identified along with the full set of new protocol > requirements. We can then let each existing or resulting > working group deal with those protocol requirements which clearly will > include MobileIP. Possibly a BOF could be specifically > scheduled at the next IETF or even some sort of interim meeting given > the all-IP timescales we are all experiencing in this > space. > > Comments appreciated. > > Regards > Alan O'Neill, Scott Corson, George Tsirtsis.... From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 2 14:57:42 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07243 for ; Tue, 2 May 2000 14:57:41 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C6D98330@standards.nortelnetworks.com>; Tue, 2 May 2000 14:50:37 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31974 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 2 May 2000 14:49:52 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.ABEF40F0@standards.nortelnetworks.com>; Tue, 2 May 2000 14:49:51 -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 LAA29879; Tue, 2 May 2000 11:55:55 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id LAA22897; Tue, 2 May 2000 11:44:47 -0700 X-Virus-Scanned: Tue, 2 May 2000 11:44:47 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from (maxdialin14.iprg.nokia.com [205.226.20.244]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma012459; Tue, 2 May 00 11:41:00 -0700 X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <7195C03599D9D311BE580008C75697EB44326E@il33exm01.wes.mot.com> <390F4B44.3D1F3CBB@comet.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <390F22EA.5EDEFFAB@iprg.nokia.com> Date: Tue, 2 May 2000 11:48:10 -0700 Reply-To: charliep@iprg.nokia.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "C. Perkins/D. Reese" Subject: Re: [MOBILE-IP] Hand-over resend X-To: campbell@comet.columbia.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Andrew, I think it would be a mistake to limit the involvement of 3G proponents. Instead, I would hope that we would identify the correct charter items, and solicit input from all interested parties along the way towards fulfilling the charter work items. Just as an example -- if, for instance, some 3G folks need to have certain Route Optimization features that are independent of the access medium, that is a discussion which belongs here. Part of the reason I am reacting to this is that I have spent a lot of time encouraging 3G engineers to get more involved with the mobile-ip working group. They should be welcomed, and we should all make sure that we understand clearly the goals of the working group. One notable difference is that the mobile-ip working group is mostly chartered to do protocols, whereas 3G standardization groups also have to put together system architectures. Thus, they are likely to notice when a protocol component is missing. That is good information for us to know. Regards, Charlie P. "Andrew T. Campbell" wrote: > Phil: > > Following up on your note: > > I think it would be a mistake to have the Mobile IP Working > Group do a 3GIP kind of thing or be a vehicle for 2/3G > transition to wireless Internet. > > The Mobile IP WG should charter 4GIP: pure unadulterated > IP packet networks based on Mobile IP and packets to > and from the mobile host using best effort service. > > I think too much 3G influence in the group may > be a distraction from that. > > Andrew From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 2 15:04:51 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07380 for ; Tue, 2 May 2000 15:04:50 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C440E180@standards.nortelnetworks.com>; Tue, 2 May 2000 14:57:42 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32034 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 2 May 2000 14:56:14 -0400 Received: from prserv.net (32.97.166.35) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9016FFC0@standards.nortelnetworks.com>; Tue, 2 May 2000 14:56:14 -0400 Received: from [32.101.171.146] ([32.101.171.146]) by prserv.net (out5) with ESMTP id <2000050219022424301o9iaoe>; Tue, 2 May 2000 19:02:24 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: ahmrphd@pop3.attglobal.net (Unverified) References: <7195C03599D9D311BE580008C75697EB44326E@il33exm01.wes.mot.com> Message-ID: Date: Tue, 2 May 2000 12:01:57 -0700 Reply-To: Arthur Ross Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Arthur Ross Subject: Re: [MOBILE-IP] Hand-over resend X-To: campbell@comet.columbia.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <390F4B44.3D1F3CBB@comet.columbia.edu> At 14:40 -0700 05/02/2000, Andrew T. Campbell wrote: > >The Mobile IP WG should charter 4GIP: pure unadulterated >IP packet networks based on Mobile IP and packets to >and from the mobile host using best effort service. > >I think too much 3G influence in the group may >be a distraction from that. > I agree. Trying to graft MIP onto 3G would be a quagmire & distraction. Pure MIP packet radio should be the goal. I would include in that the "Minimalist" physical layer, although some may consider that controvertial or out of scope. -- A From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 2 15:09:06 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07418 for ; Tue, 2 May 2000 15:09:06 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.569C6130@standards.nortelnetworks.com>; Tue, 2 May 2000 15:01:47 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32110 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 2 May 2000 15:01:23 -0400 Received: from sirius.ctr.columbia.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.47BF2490@standards.nortelnetworks.com>; Tue, 2 May 2000 15:01:22 -0400 Received: from comet.columbia.edu (sweetpea.comet.columbia.edu [128.59.68.61]) by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with ESMTP id PAA26920; Tue, 2 May 2000 15:07:54 -0400 (EDT) X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <7195C03599D9D311BE580008C75697EB44326E@il33exm01.wes.mot.com> <390F4B44.3D1F3CBB@comet.columbia.edu> <390F22EA.5EDEFFAB@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <390F5526.357F0F63@comet.columbia.edu> Date: Tue, 2 May 2000 15:22:30 -0700 Reply-To: campbell@comet.columbia.edu Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Andrew T. Campbell" Organization: Center for Telecommunications Research Subject: Re: [MOBILE-IP] Hand-over resend X-To: charliep@iprg.nokia.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Charlie: I fully agree we need to be open and inclusive. But my gut feel is that overlaying 3G on to IP is a little like the ATM circuit model on to IP. Andrew "C. Perkins/D. Reese" wrote: > > Hello Andrew, > > I think it would be a mistake to limit the involvement of > 3G proponents. Instead, I would hope that we would > identify the correct charter items, and solicit input from > all interested parties along the way towards fulfilling > the charter work items. Just as an example -- if, for > instance, some 3G folks need to have certain Route > Optimization features that are independent of the access > medium, that is a discussion which belongs here. > > Part of the reason I am reacting to this is that I have > spent a lot of time encouraging 3G engineers to get > more involved with the mobile-ip working group. > They should be welcomed, and we should all make > sure that we understand clearly the goals of the working > group. > > One notable difference is that the mobile-ip working > group is mostly chartered to do protocols, whereas > 3G standardization groups also have to put together > system architectures. Thus, they are likely to notice > when a protocol component is missing. That is good > information for us to know. > > Regards, > Charlie P. > > "Andrew T. Campbell" wrote: > > > Phil: > > > > Following up on your note: > > > > I think it would be a mistake to have the Mobile IP Working > > Group do a 3GIP kind of thing or be a vehicle for 2/3G > > transition to wireless Internet. > > > > The Mobile IP WG should charter 4GIP: pure unadulterated > > IP packet networks based on Mobile IP and packets to > > and from the mobile host using best effort service. > > > > I think too much 3G influence in the group may > > be a distraction from that. > > > > Andrew From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 2 15:17:59 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07496 for ; Tue, 2 May 2000 15:17:58 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9B477620@standards.nortelnetworks.com>; Tue, 2 May 2000 15:10:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32168 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 2 May 2000 15:10:22 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.891716E0@standards.nortelnetworks.com>; Tue, 2 May 2000 15:10:22 -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 NAA12840; Tue, 2 May 2000 13:16:49 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA00782; Tue, 2 May 2000 12:16:45 -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 MAA13226; Tue, 2 May 2000 12:16:16 -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: <200005021916.MAA13226@nasnfs.eng.sun.com> Date: Tue, 2 May 2000 12:18:31 -0700 Reply-To: pcalhoun@Eng.Sun.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrice Calhoun Subject: Re: [MOBILE-IP] Hand-over resend X-To: campbell@comet.columbia.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Amen! PatC >Phil: > >Following up on your note: > >I think it would be a mistake to have the Mobile IP Working >Group do a 3GIP kind of thing or be a vehicle for 2/3G >transition to wireless Internet. > >The Mobile IP WG should charter 4GIP: pure unadulterated >IP packet networks based on Mobile IP and packets to >and from the mobile host using best effort service. > >I think too much 3G influence in the group may >be a distraction from that. > >Andrew > >Roberts Phil-QA3445 wrote: >> >> Alan, >> >> this was on the mail list. We were letting people say pretty much >> whatever they wanted on this issue last week so I didn't respond. >> >> I now have a couple of comments. >> >> Although a sizeable constituency of the group has the same goal of >> an all IP mobile enabled network for cellular, the group is not chartered to >> come up with a transition plan for something like UMTS. That's not to say >> such isn't needed, it's just beyond the scope of this group. If there are >> particular aspects of that kind of work that fall into our charter (such as >> supporting fast handovers) we're certainly willing to take contributions. >> >> As far as forming something like a BOF to investigate the appraoch >> you've outlined, there may be members of this list who are interested in >> participating, but we're not really the right audience to ask for such an >> agenda item. >> >> Hope this helps, >> Phil >> >> -----Original Message----- >> From: Alan O'Neill [mailto:alan.w.oneill@bt.com] >> Sent: Tuesday, May 02, 2000 9:25 AM >> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM >> Subject: Re: [MOBILE-IP] Hand-over resend >> >> Folks, >> >> The following message was sent to the list last week and whilst it is on the >> Nortel archive, it appears it did not hit the main list ? >> >> Date: Fri, 28 Apr 2000 08:15:51 -0400 >> Reply-To: Alan O'Neill >> Sender: "IP Routing for Wireless/Mobile Hosts >> (mobile-ip)" >> >> From: Alan O'Neill >> Subject: Re: handover >> >> All, >> >> For those who do not know me I work in BT on all IP >> architecture with primary focus on UMTS Rel2001 but also including mobility >> across a range of access technologies. I am also >> co-author of which attempts to provide a generic >> IP >> hand-over architecture which will support UMTS:GTP, >> MobileIP, but mainly routed mobility. Co-authors are Scott Corson the >> MANET wg co-chair and George Tsirtsis also of BT. >> >> We would like to to see hand-over control and >> interactions with the radio systems to be defined in a >> generalised way so that an operator can migrate from >> existing GTP through possibly MobileIP to the holy grail of a scalable >> mobile enhanced routing protocol (we use modified >> MANET:TORA for this at the moment), with co-existence where commercial >> models dictate for the data-path options (tunnelled / >> routed etc) . The aim is to facilitate a common IP hand-over interface so >> that >> the operator can have all options co-exist, and support >> evolution between them. We can also see big dangers and interoperability >> problems if each affected working group designs it's >> own, non-interworking fast IP hand-over solutions and associated interfaces >> into the access technologies and systems. >> >> The Edge mobility Architecture draft >> avoids many of the details but hopefully the >> reader can see the >> clear need to enable tunnelled and native routed >> solutions to co-exist, re-using the same AAA, access signalling and policy >> elements, plus the interfaces into many different access >> technologies and systems. Our view at this stage is that the solution for >> the signalling plane requires a combination of extended >> MobileIP signalling to embrace GTP and routed mobility requirements, >> plus DHCP extensions. We are presently preparing drafts >> which detail the mapping of EMA to UMTS, and the detailed signalling >> pieces. >> >> It seems to make sense that a separate short working >> group be first formed to define the scope and >> architecture for the IP hand-over work so that common >> pieces can be identified along with the full set of new protocol >> requirements. We can then let each existing or resulting >> working group deal with those protocol requirements which clearly will >> include MobileIP. Possibly a BOF could be specifically >> scheduled at the next IETF or even some sort of interim meeting given >> the all-IP timescales we are all experiencing in this >> space. >> >> Comments appreciated. >> >> Regards >> Alan O'Neill, Scott Corson, George Tsirtsis.... From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 2 15:22:04 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07530 for ; Tue, 2 May 2000 15:22:04 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2BDDED40@standards.nortelnetworks.com>; Tue, 2 May 2000 15:14:55 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32204 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 2 May 2000 15:13:26 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F67968A0@standards.nortelnetworks.com>; Tue, 2 May 2000 15:13:25 -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 NAA15102; Tue, 2 May 2000 13:19:54 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA01432; Tue, 2 May 2000 12:19:53 -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 MAA13334; Tue, 2 May 2000 12:19:30 -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: <200005021919.MAA13334@nasnfs.eng.sun.com> Date: Tue, 2 May 2000 12:21:40 -0700 Reply-To: pcalhoun@Eng.Sun.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrice Calhoun Subject: Re: [MOBILE-IP] Hand-over resend X-To: Arthur Ross To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit >At 14:40 -0700 05/02/2000, Andrew T. Campbell wrote: >> >>The Mobile IP WG should charter 4GIP: pure unadulterated >>IP packet networks based on Mobile IP and packets to >>and from the mobile host using best effort service. >> >>I think too much 3G influence in the group may >>be a distraction from that. >> >I agree. Trying to graft MIP onto 3G would be a quagmire & distraction. >Pure MIP packet radio should be the goal. I would include in that the >"Minimalist" physical layer, although some may consider that controvertial >or out of scope. Here I respectfully disagree. We need to pay attention to 3G networks, since Mobile IP will be deployed in some 3G networks, and this is a GREAT opportunity for Mobile IP to get extensive operational experience. However, I agree with Andrew that we should not limit our work to existing 3G architectures, and try to work towards a 4G network. PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 2 15:31:06 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07665 for ; Tue, 2 May 2000 15:31:06 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.71E780C0@standards.nortelnetworks.com>; Tue, 2 May 2000 15:24:02 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32195 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 2 May 2000 15:22:33 -0400 Received: from motgate.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D6C59060@standards.nortelnetworks.com>; Tue, 2 May 2000 15:12:32 -0400 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id MAA27520 for ; Tue, 2 May 2000 12:19:07 -0700 (MST)] Received: [from il33exm01.wes.mot.com (il33exm01.wes.mot.com [154.56.3.118]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id MAA10790 for ; Tue, 2 May 2000 12:19:06 -0700 (MST)] Received: by il33exm01.wes.mot.com with Internet Mail Service (5.5.2650.21) id <28T0BW0K>; Tue, 2 May 2000 14:19:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <7195C03599D9D311BE580008C75697EB443278@il33exm01.wes.mot.com> Date: Tue, 2 May 2000 14:18:59 -0500 Reply-To: Roberts Phil-QA3445 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Roberts Phil-QA3445 Subject: Re: [MOBILE-IP] Hand-over resend X-To: "campbell@comet.columbia.edu" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi, I agree that we don't have the scope of organizations that are not only interested in developing protocols but also developing system architectures. I find it difficult to agree with your perspective on 3G network support, and actually what constitutes 3G networks for that matter. All constituencies with an interest in Mobile IP are welcome here. We're not going to design 3G cellular networks, but if the folks who are would like something added to mobile ip in order to use it in their networks they are more than welcome to contribute, and have been doing so in fact. Phil -----Original Message----- From: Andrew T. Campbell [mailto:campbell@comet.columbia.edu] Sent: Tuesday, May 02, 2000 4:40 PM To: Roberts Phil-QA3445 Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] Hand-over resend Phil: Following up on your note: I think it would be a mistake to have the Mobile IP Working Group do a 3GIP kind of thing or be a vehicle for 2/3G transition to wireless Internet. The Mobile IP WG should charter 4GIP: pure unadulterated IP packet networks based on Mobile IP and packets to and from the mobile host using best effort service. I think too much 3G influence in the group may be a distraction from that. Andrew Roberts Phil-QA3445 wrote: > > Alan, > > this was on the mail list. We were letting people say pretty much > whatever they wanted on this issue last week so I didn't respond. > > I now have a couple of comments. > > Although a sizeable constituency of the group has the same goal of > an all IP mobile enabled network for cellular, the group is not chartered to > come up with a transition plan for something like UMTS. That's not to say > such isn't needed, it's just beyond the scope of this group. If there are > particular aspects of that kind of work that fall into our charter (such as > supporting fast handovers) we're certainly willing to take contributions. > > As far as forming something like a BOF to investigate the appraoch > you've outlined, there may be members of this list who are interested in > participating, but we're not really the right audience to ask for such an > agenda item. > > Hope this helps, > Phil > > -----Original Message----- > From: Alan O'Neill [mailto:alan.w.oneill@bt.com] > Sent: Tuesday, May 02, 2000 9:25 AM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Hand-over resend > > Folks, > > The following message was sent to the list last week and whilst it is on the > Nortel archive, it appears it did not hit the main list ? > > Date: Fri, 28 Apr 2000 08:15:51 -0400 > Reply-To: Alan O'Neill > Sender: "IP Routing for Wireless/Mobile Hosts > (mobile-ip)" > > From: Alan O'Neill > Subject: Re: handover > > All, > > For those who do not know me I work in BT on all IP > architecture with primary focus on UMTS Rel2001 but also including mobility > across a range of access technologies. I am also > co-author of which attempts to provide a generic > IP > hand-over architecture which will support UMTS:GTP, > MobileIP, but mainly routed mobility. Co-authors are Scott Corson the > MANET wg co-chair and George Tsirtsis also of BT. > > We would like to to see hand-over control and > interactions with the radio systems to be defined in a > generalised way so that an operator can migrate from > existing GTP through possibly MobileIP to the holy grail of a scalable > mobile enhanced routing protocol (we use modified > MANET:TORA for this at the moment), with co-existence where commercial > models dictate for the data-path options (tunnelled / > routed etc) . The aim is to facilitate a common IP hand-over interface so > that > the operator can have all options co-exist, and support > evolution between them. We can also see big dangers and interoperability > problems if each affected working group designs it's > own, non-interworking fast IP hand-over solutions and associated interfaces > into the access technologies and systems. > > The Edge mobility Architecture draft > avoids many of the details but hopefully the > reader can see the > clear need to enable tunnelled and native routed > solutions to co-exist, re-using the same AAA, access signalling and policy > elements, plus the interfaces into many different access > technologies and systems. Our view at this stage is that the solution for > the signalling plane requires a combination of extended > MobileIP signalling to embrace GTP and routed mobility requirements, > plus DHCP extensions. We are presently preparing drafts > which detail the mapping of EMA to UMTS, and the detailed signalling > pieces. > > It seems to make sense that a separate short working > group be first formed to define the scope and > architecture for the IP hand-over work so that common > pieces can be identified along with the full set of new protocol > requirements. We can then let each existing or resulting > working group deal with those protocol requirements which clearly will > include MobileIP. Possibly a BOF could be specifically > scheduled at the next IETF or even some sort of interim meeting given > the all-IP timescales we are all experiencing in this > space. > > Comments appreciated. > > Regards > Alan O'Neill, Scott Corson, George Tsirtsis.... From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 2 17:25:28 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09080 for ; Tue, 2 May 2000 17:25:27 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6D581A50@standards.nortelnetworks.com>; Tue, 2 May 2000 17:18:26 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32584 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 2 May 2000 17:16:55 -0400 Received: from caip.rutgers.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.30E1E470@standards.nortelnetworks.com>; Tue, 2 May 2000 17:16:44 -0400 Received: from boccaccio (boccaccio.rutgers.edu [128.6.37.33]) by caip.rutgers.edu (8.9.3/8.9.3) with SMTP id RAA11233 for ; Tue, 2 May 2000 17:23:09 -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.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Message-ID: <001101bfb47c$5b6fa110$21250680@rutgers.edu> Date: Tue, 2 May 2000 17:21:15 -0400 Reply-To: Ajay Wanchoo Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Ajay Wanchoo Subject: [MOBILE-IP] Multiple Associations & Soft Handoffs To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Quite sometime back there was a discussion regarding association (registration) of an MH to more than one FA. Since it was brought up that there seemed to be no real advantage, and even though currently Mobile IP does not disallow multiple registration, maybe at a later date, multiple associations may be disallowed. I am curious about what the current thought is in this regard. I am particularly concerned since I am currently working on handoff approaches involving multiple associations. Will appreciate any advice. Regards, Ajay Wanchoo From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 2 18:06:36 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09600 for ; Tue, 2 May 2000 18:06:36 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2C4199A0@standards.nortelnetworks.com>; Tue, 2 May 2000 17:59:34 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32682 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 2 May 2000 17:58:20 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.007263E0@standards.nortelnetworks.com>; Tue, 2 May 2000 17:58:20 -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 QAA15763; Tue, 2 May 2000 16:04:51 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA11200; Tue, 2 May 2000 15:04:51 -0700 (PDT) Received: from nasnfs.Eng.Sun.COM (pacrimapp2.Singapore.Sun.COM [129.158.124.41]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id PAA17713; Tue, 2 May 2000 15:04:26 -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: <200005022204.PAA17713@nasnfs.eng.sun.com> Date: Tue, 2 May 2000 15:07:13 -0700 Reply-To: James.Kempf@Eng.Sun.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: James Kempf Subject: Re: [MOBILE-IP] Multiple Associations & Soft Handoffs X-To: Ajay Wanchoo To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit I think replacing soft handoff should be outside the domain of discussion. There's a draft currently in preparation between myself and a couple co-authors, hopefully (as soon as the one co-author gets back to me) I'll be able to post it soon. jak >Quite sometime back there was a discussion regarding >association (registration) of an MH to more than one FA. >Since it was brought up that there seemed to be no real >advantage, and even though currently Mobile IP does not >disallow multiple registration, maybe at a later date, >multiple associations may be disallowed. > >I am curious about what the current thought is in this regard. >I am particularly concerned since I am currently working >on handoff approaches involving multiple associations. > >Will appreciate any advice. > >Regards, >Ajay Wanchoo From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 2 19:43:56 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10450 for ; Tue, 2 May 2000 19:43:56 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BFF14BC0@standards.nortelnetworks.com>; Tue, 2 May 2000 19:36:45 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32828 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 2 May 2000 19:34:49 -0400 Received: from sj-msg-core-1.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7A9D7E40@standards.nortelnetworks.com>; Tue, 2 May 2000 19:34:49 -0400 Received: from rhino (rhino.cisco.com [172.20.9.57]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id QAA12785; Tue, 2 May 2000 16:41:29 -0700 (PDT) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by rhino (SMI-8.6/CISCO.WS.1.1) with ESMTP id QAA08924; Tue, 2 May 2000 16:46:09 -0700 X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.3.1.2.20000502160009.00cd1960@flipper.cisco.com> Date: Tue, 2 May 2000 16:14:59 -0700 Reply-To: Fred Baker Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Fred Baker Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question X-To: James Kempf To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200005021424.HAA24772@nasnfs.eng.sun.com> At 07:27 AM 5/2/00 -0700, James Kempf wrote: >Some of the options for fast handover we've been discussing recently may >call for an FA-like entity in IPv6. I've heard this variously referred >to as an "attendent". Is the IPv6 mobility draft last call the right >time to bring up this issue, or should it perhaps wait for a separate >discussion >and a separate draft? that's up to you. If you want the draft as it stands to be reviewed by the IESG, pulling it back for additional features is probably not the best way to do it. One thing to consider is - no, I haven't written up the Internet draft yet - IP6 mobility may have uses that you haven't thought about which do not require this. Consider something happening in various networks around the world, including at elast a cable network in the US, a DSL network in the UK, a proposed fiber plant in Sweden, and a proposal being developed in Taiwan. The idea is that you have a number of homes and SOHO facilities connected to a common infrastructure which could be perceived as giving one ISP an advantage. So legislation comes into play that says "all ISPs must be able to offer their services over this common infrastructure, and individuals in the homes must be able to use different ISPs". There are several ways to do this. Traditional ones include Frame Relay, ISDN, and ATM. What is being proposed are IP networks where the individual gets his/her IP Address from their ISP, magic happens in the middle, and the ISP offers its services. There are many ways to do this in IP: We could use the IP Source Address as a route discriminator and build a separate route table per ISP, with neighborhood subnets from each ISP scattered throughout. We could say "forget it" and use a link layer network. Or we could use MPLS and drag labeled paths from the ISP to the home (the reverse is unnecessary, as normal routing would get traffic in the other direction). We could do the same with other tunnel technologies. We wind up with a phenomenal number of tunnels, and rerouting issues related to circuit switching. More manageably, we could use some variation on a BGP community to identify folks belonging to the same ISP and set up MPLS labelled paths within communities. This means a route table per community (ISP) at the edge, plus an interchange/backbone community, and an MPLS core. Each of these has scaling and single point of failure issues. If we use IP4 mobility, that is really just another "tunnel from the ISP to the home" with a scaling and single point of failure problem at the home agent. But if we could use IP6 mobility and treat the device in the home/SOHO as the special case of a mobile device which happens to move infrequently or not at all, the solution does all the requirements, is manageable, and scales fairly nicely. The "care-of router" even serves as a one-way tunnel for us. Adding a mandatory foreign agent could screw this up for us... Just a thought. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed May 3 04:45:53 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27625 for ; Wed, 3 May 2000 04:45:53 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6CCD8160@standards.nortelnetworks.com>; Wed, 3 May 2000 4:38:27 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 33353 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 3 May 2000 04:37:24 -0400 Received: from ebene.inrialpes.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.416E4B80@standards.nortelnetworks.com>; Wed, 3 May 2000 4:37:14 -0400 Received: from iseran.inrialpes.fr (iseran.inrialpes.fr [194.199.24.100]) by ebene.inrialpes.fr (8.9.3/8.8.5) with ESMTP id KAA19317; Wed, 3 May 2000 10:36:54 +0200 (MET DST) Received: from iseran (localhost [127.0.0.1]) by iseran.inrialpes.fr (8.8.7/8.8.5) with SMTP id KAA08343; Wed, 3 May 2000 10:43:28 +0200 (MET DST) X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.6 sun4u) MIME-Version: 1.0 References: <200005021919.MAA13334@nasnfs.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <390FE6B0.6F6A@inrialpes.fr> Date: Wed, 3 May 2000 10:43:28 +0200 Reply-To: Claude.Castelluccia@INRIALPES.FR Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Claude Castelluccia Subject: Re: [MOBILE-IP] Hand-over resend X-To: pcalhoun@Eng.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello, What do you exactly mean by "4G networks"? Is that an official terminology? Where can I get more information about the design constraints/goals of such networks? thanks a lot. Claude. Patrice Calhoun wrote: > > Here I respectfully disagree. We need to pay attention to 3G networks, since > Mobile IP will be deployed in some 3G networks, and this is a GREAT opportunity > for Mobile IP to get extensive operational experience. However, I agree with > Andrew that we should not limit our work to existing 3G architectures, and try > to work towards a 4G network. -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed May 3 06:03:54 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28007 for ; Wed, 3 May 2000 06:03:54 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.58797DD0@standards.nortelnetworks.com>; Wed, 3 May 2000 5:56:38 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 33481 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 3 May 2000 05:55:03 -0400 Received: from extmx.itri.org.tw by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C2C79210@standards.nortelnetworks.com>; Wed, 3 May 2000 5:38:07 -0400 Received: from nti.itri.org.tw (nti.itri.org.tw [140.96.157.2]) by extmx.itri.org.tw (8.8.8/8.8.8) with ESMTP id RAA13413 for ; Wed, 3 May 2000 17:46:58 +0800 (CST) Received: from cclmail.ccl.itri.org.tw (cclmail.ccl.itri.org.tw [140.96.90.193]) by nti.itri.org.tw (8.8.8/8.8.8) with ESMTP id RAA02935 for ; Wed, 3 May 2000 17:45:15 +0800 (CST) Received: from CCLiu ([140.96.104.51]) by cclmail.ccl.itri.org.tw (Lotus Domino Release 5.0.2a (Intl)) with SMTP id 2000050317471067:608 ; Wed, 3 May 2000 17:47:10 +0800 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-MIMETrack: Itemize by SMTP Server on CCLMAIL/ITRI(Release 5.0.2a (Intl)|23 November 1999) at 2000/05/03 05:47:10 PM, Serialize by Router on CCLMAIL/ITRI(Release 5.0.2a (Intl)|23 November 1999) at 2000/05/03 05:47:11 PM, Serialize complete at 2000/05/03 05:47:11 PM Content-Type: multipart/alternative; boundary="----=_NextPart_000_0084_01BFB527.19A41940" Message-ID: <008701bfb4e4$0b91a220$3368608c@cclk400.ccl.itri.org.tw> Date: Wed, 3 May 2000 17:43:32 +0800 Reply-To: ccliu Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: ccliu Subject: [MOBILE-IP] about interworking between MIPv6 and MIPv4 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_0084_01BFB527.19A41940 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Now we are going a project about interworking between MIPv6 and MIPv4. Where has the related reference or any idea?? Thanks a lot!! Lewis ------=_NextPart_000_0084_01BFB527.19A41940 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
Now we are going a project about interworking = between MIPv6=20 and MIPv4.
Where has the related reference or any = idea??
Thanks a lot!!
Lewis
------=_NextPart_000_0084_01BFB527.19A41940-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed May 3 06:41:00 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28329 for ; Wed, 3 May 2000 06:40:59 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.868E92A0@standards.nortelnetworks.com>; Wed, 3 May 2000 6:33:42 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 33550 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 3 May 2000 06:32:44 -0400 Received: from alpha.netvision.net.il (194.90.1.13) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.63390290@standards.nortelnetworks.com>; Wed, 3 May 2000 6:32:43 -0400 Received: from sendout.icomverse.com (Efrat-FR3.ser.netvision.net.il [199.203.174.65]) by alpha.netvision.net.il (8.9.3/8.8.6) with ESMTP id NAA22683 for ; Wed, 3 May 2000 13:38:08 +0300 (IDT) Received: from ismail1.icomverse.com (ismail1.icomverse.com [190.190.110.2]) by sendout.icomverse.com (8.9.3/8.8.7) with ESMTP id MAA28050 for ; Wed, 3 May 2000 12:39:58 +0300 Received: by ismail1.icomverse.com with Internet Mail Service (5.5.2650.21) id ; Wed, 3 May 2000 13:38:54 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="big5" Message-ID: Date: Wed, 3 May 2000 13:38:48 +0300 Reply-To: "Klein, Eric" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Klein, Eric" Subject: Re: [MOBILE-IP] about interworking between MIPv6 and MIPv4 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Try this information from the NGTRANS group: New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Generation Transition Working Group of the IETF. Title : Overview of Transition Techniques for IPv6 only to Talk to IPv4-only Communication Author(s) : K. Yamamoto, M. Sumikawa Filename : draft-ietf-ngtrans-translator-03.txt Pages : 8 Date : 09-Mar-00 This memo discusses translators to enable direct communication between IPv4 hosts and IPv6 hosts. Three translation mechanisms are described. From the address mapping point of view, the translators are categorized into four types and each feasibility is considered. This memo is based on a paper appeared in Proceedings of INET98[INET]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-translator-03.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-ietf-ngtrans-translator-03.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-ietf-ngtrans-translator-03.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. -----Original Message--- Try -- From: ccliu [mailto:jcliu@ITRI.ORG.TW] Sent: Wednesday, May 03, 2000 12:44 PM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: [MOBILE-IP] about interworking between MIPv6 and MIPv4 Now we are going a project about interworking between MIPv6 and MIPv4. Where has the related reference or any idea?? Thanks a lot!! Lewis From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed May 3 08:01:29 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00185 for ; Wed, 3 May 2000 08:01:29 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B9AE2F50@standards.nortelnetworks.com>; Wed, 3 May 2000 7:53:53 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 33681 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 3 May 2000 07:52:37 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8C63CB40@standards.nortelnetworks.com>; Wed, 3 May 2000 7:52:37 -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 FAA03776 for ; Wed, 3 May 2000 05:59:14 -0600 (MDT) Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM [129.146.93.34]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id EAA13021; Wed, 3 May 2000 04:59:13 -0700 (PDT) Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA16642; Wed, 3 May 2000 04:59:12 -0700 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Wed, 3 May 2000 04:59:11 -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] Hand-over resend X-To: Claude Castelluccia X-cc: pcalhoun@eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <390FE6B0.6F6A@inrialpes.fr> > Hello, > > What do you exactly mean by "4G networks"? > Is that an official terminology? no it isn't. I was borrowing from the term that was used in the e-mail I was responding to (which I can't seem to find at the moment :( The way 4G was described was simply the routing of packets, and treating the air interface as nothing but a link layer (well, I am paraphrasing here). Currently, as you know, the 3G networks are quite complex, and include many additional devices in order to make use of the legacy equipment that already exists in the networks. Perhaps the next revision will make the cellular networks look more like an IP network. > Where can I get more information about the > design constraints/goals of such networks? My head, I suppose :) Seriously, there isn't any information that is publically available. Some people in the All-IP space have this view, but it doesn't seem to be all that popular since it requires a drastic change to the network. PatC > > thanks a lot. > > Claude. > > > > > Patrice Calhoun wrote: > > > > Here I respectfully disagree. We need to pay attention to 3G networks, since > > Mobile IP will be deployed in some 3G networks, and this is a GREAT opportunity > > for Mobile IP to get extensive operational experience. However, I agree with > > Andrew that we should not limit our work to existing 3G architectures, and try > > to work towards a 4G network. > > > -- > > ---------------------------------------- > Claude CASTELLUCCIA, INRIA Rhone-Alpes > ph: +33 4.76.61.52.15 (fax: 52.52) > http://www.inrialpes.fr/planete/ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed May 3 09:28:39 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01762 for ; Wed, 3 May 2000 09:28:39 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E73C5CB0@standards.nortelnetworks.com>; Wed, 3 May 2000 9:21:03 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 33810 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 3 May 2000 09:19:40 -0400 Received: from auemlsrv.firewall.lucent.com (192.11.223.161) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B5E4FBE0@standards.nortelnetworks.com>; Wed, 3 May 2000 9:19:40 -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 JAA02976 for ; Wed, 3 May 2000 09:26:18 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA02940 for ; Wed, 3 May 2000 09:26:17 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2448.0) id <2PATYT0D>; Wed, 3 May 2000 14:26:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Message-ID: <976F7C55E3B2D111A0720008C728549C04876BA8@en0060exch001u.uk.lucent.com> Date: Wed, 3 May 2000 14:26:14 +0100 Reply-To: "Casati, Alessio (Alessio)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Casati, Alessio (Alessio)" Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question X-To: Fred Baker To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > If we use IP4 mobility, that is really just another "tunnel from the ISP > to > the home" with a scaling and single point of failure problem at the home > agent. But if we could use IP6 mobility and treat the device in the > home/SOHO as the special case of a mobile device which happens to move > infrequently or not at all, the solution does all the requirements, is > manageable, and scales fairly nicely. The "care-of router" even serves as > a > one-way tunnel for us. > > Fred, I miss the point you are making. Why would a v6 mobility scale better than a v4? OK, you don't have tunnels most of the time but I'm sure you need to store some info at home and in the correspondent nodes. I'm pretty sure I'm missing something, so please enlighten me. alessio From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed May 3 10:01:45 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02523 for ; Wed, 3 May 2000 10:01:45 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.86D10920@standards.nortelnetworks.com>; Wed, 3 May 2000 9:54:09 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 33876 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 3 May 2000 09:52:42 -0400 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.535086C0@standards.nortelnetworks.com>; Wed, 3 May 2000 9:52:42 -0400 Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch1.nortel.com; Wed, 3 May 2000 08:58:55 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 3 May 2000 08:58:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFB507.B757091A" Message-ID: <9A9367D1556AD21182C40000F80930AB0272B7A1@crchy28b.us.nortel.com> Date: Wed, 3 May 2000 08:58:52 -0500 Reply-To: Raja Narayanan Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Raja Narayanan Subject: Re: [MOBILE-IP] Hand-over resend 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_01BFB507.B757091A Content-Type: text/plain; charset="iso-8859-1" I agree with this viewpoint....especially the last paragraph. --Raja -----Original Message----- From: C. Perkins/D. Reese [mailto:charliep@IPRG.NOKIA.COM] Sent: Tuesday, May 02, 2000 1:48 PM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] Hand-over resend Hello Andrew, I think it would be a mistake to limit the involvement of 3G proponents. Instead, I would hope that we would identify the correct charter items, and solicit input from all interested parties along the way towards fulfilling the charter work items. Just as an example -- if, for instance, some 3G folks need to have certain Route Optimization features that are independent of the access medium, that is a discussion which belongs here. Part of the reason I am reacting to this is that I have spent a lot of time encouraging 3G engineers to get more involved with the mobile-ip working group. They should be welcomed, and we should all make sure that we understand clearly the goals of the working group. One notable difference is that the mobile-ip working group is mostly chartered to do protocols, whereas 3G standardization groups also have to put together system architectures. Thus, they are likely to notice when a protocol component is missing. That is good information for us to know. Regards, Charlie P. "Andrew T. Campbell" wrote: > Phil: > > Following up on your note: > > I think it would be a mistake to have the Mobile IP Working > Group do a 3GIP kind of thing or be a vehicle for 2/3G > transition to wireless Internet. > > The Mobile IP WG should charter 4GIP: pure unadulterated > IP packet networks based on Mobile IP and packets to > and from the mobile host using best effort service. > > I think too much 3G influence in the group may > be a distraction from that. > > Andrew ------_=_NextPart_001_01BFB507.B757091A Content-Type: text/html; charset="iso-8859-1" Re: [MOBILE-IP] Hand-over resend

I agree with this viewpoint....especially the last paragraph.

--Raja


-----Original Message-----
From: C. Perkins/D. Reese [mailto:charliep@IPRG.NOKIA.COM]
Sent: Tuesday, May 02, 2000 1:48 PM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: Re: [MOBILE-IP] Hand-over resend


Hello Andrew,

I think it would be a mistake to limit the involvement of
3G proponents.  Instead, I would hope that we would
identify the correct charter items, and solicit input from
all interested parties along the way towards fulfilling
the charter work items.  Just as an example -- if, for
instance, some 3G folks need to have certain Route
Optimization features that are independent of the access
medium, that is a discussion which belongs here.

Part of the reason I am reacting to this is that I have
spent a lot of time encouraging 3G engineers to get
more involved with the mobile-ip working group.
They should be welcomed, and we should all make
sure that we understand clearly the goals of the working
group.

One notable difference is that the mobile-ip working
group is mostly chartered to do protocols, whereas
3G standardization groups also have to put together
system architectures.  Thus, they are likely to notice
when a protocol component is missing.  That is good
information for us to know.

Regards,
Charlie P.



"Andrew T. Campbell" wrote:

> Phil:
>
> Following up on your note:
>
> I think it would be a mistake to have the Mobile IP Working
> Group do a 3GIP kind of thing or be a vehicle for 2/3G
> transition to wireless Internet.
>
> The Mobile IP WG should charter 4GIP: pure unadulterated
> IP packet networks based on Mobile IP and packets to
> and from the mobile host using best effort service.
>
> I think too much 3G influence in the group may
> be a distraction from that.
>
> Andrew

------_=_NextPart_001_01BFB507.B757091A-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed May 3 10:07:19 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02657 for ; Wed, 3 May 2000 10:07:19 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CEF9A180@standards.nortelnetworks.com>; Wed, 3 May 2000 9:56:10 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 33887 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 3 May 2000 09:55:40 -0400 Received: from cedar.dcs.shef.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BCF449E0@standards.nortelnetworks.com>; Wed, 3 May 2000 9:55:40 -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 PAA05808; Wed, 3 May 2000 15:02:07 +0100 (BST) 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.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Message-ID: <004d01bfb508$94719220$2c0ba78f@dcs.shef.ac.uk> Date: Wed, 3 May 2000 15:05:03 +0100 Reply-To: cnyap Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: cnyap Subject: Re: [MOBILE-IP] Hand-over resend X-To: "pcalhoun@eng.sun.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit A website with so call 4G network. http://www.s3.kth.se/radio/4GW/ Cheers ------------------------------------------------------------------- Chern Nam Yap Mobile Communication System Researcher University of Sheffield Department of Electronic and Electrical Engineering Regent Court 211 Portobello Street Sheffield S1 4DP, England Tel: +44 114 222 3308 Web: http://www.mobile1.net E-mail: cny@dcs.shef.ac.uk ----- Original Message ----- From: "pcalhoun@eng.sun.com" To: Sent: Wednesday, May 03, 2000 12:59 PM Subject: Re: [MOBILE-IP] Hand-over resend > > Hello, > > > > What do you exactly mean by "4G networks"? > > Is that an official terminology? > no it isn't. I was borrowing from the term that was used in the e-mail I was > responding to (which I can't seem to find at the moment :( > > The way 4G was described was simply the routing of packets, and treating the > air interface as nothing but a link layer (well, I am paraphrasing here). > Currently, as you know, the 3G networks are quite complex, and include many > additional devices in order to make use of the legacy equipment that already > exists in the networks. Perhaps the next revision will make the cellular > networks look more like an IP network. > > > Where can I get more information about the > > design constraints/goals of such networks? > > > My head, I suppose :) > > Seriously, there isn't any information that is publically available. Some > people in the All-IP space have this view, but it doesn't seem to be all that > popular since it requires a drastic change to the network. > > PatC > > > > > thanks a lot. > > > > Claude. > > > > > > > > > > Patrice Calhoun wrote: > > > > > > Here I respectfully disagree. We need to pay attention to 3G networks, since > > > Mobile IP will be deployed in some 3G networks, and this is a GREAT opportunity > > > for Mobile IP to get extensive operational experience. However, I agree with > > > Andrew that we should not limit our work to existing 3G architectures, and try > > > to work towards a 4G network. > > > > > > -- > > > > ---------------------------------------- > > Claude CASTELLUCCIA, INRIA Rhone-Alpes > > ph: +33 4.76.61.52.15 (fax: 52.52) > > http://www.inrialpes.fr/planete/ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed May 3 10:10:08 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02659 for ; Wed, 3 May 2000 10:07:19 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.17678040@standards.nortelnetworks.com>; Wed, 3 May 2000 9:58:11 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 33869 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 3 May 2000 09:56:47 -0400 Received: from motgate.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7F5FA120@standards.nortelnetworks.com>; Wed, 3 May 2000 9:46:47 -0400 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id GAA25294 for ; Wed, 3 May 2000 06:53:25 -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 GAA29007 for ; Wed, 3 May 2000 06:53:25 -0700 (MST)] Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2650.21) id ; Wed, 3 May 2000 08:53:24 -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, 3 May 2000 08:53:24 -0500 Reply-To: Varma Dileep-DVARMA1 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Varma Dileep-DVARMA1 Subject: [MOBILE-IP] Routing Optimization Question To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Is there any reference documents on the ongoing research in the field of Route Optimization for MobileIP. Ay pointers to the same would be appreciated. Thanks, Dileep. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed May 3 11:18:22 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04105 for ; Wed, 3 May 2000 11:18:22 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.32E5E0A0@standards.nortelnetworks.com>; Wed, 3 May 2000 11:10:32 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 34176 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 3 May 2000 11:10:16 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2891D5A0@standards.nortelnetworks.com>; Wed, 3 May 2000 11:10: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 JAA24671; Wed, 3 May 2000 09:16:52 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA05940; Wed, 3 May 2000 08:16:50 -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 IAA06215; Wed, 3 May 2000 08:16:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: MULTIPART/mixed; BOUNDARY=Sounder_of_Swine_044_000 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Message-ID: <200005031516.IAA06215@nasnfs.eng.sun.com> Date: Wed, 3 May 2000 08:19:33 -0700 Reply-To: James Kempf Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: James Kempf Subject: [MOBILE-IP] Applicability of IP Mobility to CDMA Soft Handoff X-To: sip@lists.bell-labs.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --Sounder_of_Swine_044_000 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ctfkkmfiDsXoPrUMStI7WQ== There has been some discussion on the mobile IP and SIP lists about replacing CDMA soft handoff with IP mobility mechanisms. The attached draft, authored by Pete McCann, Phil Roberts, and myself, attempts to explain how a CDMA RAN works and why soft handoff is not a promising candidate for replacing with IP mobility mechanisms in the near term. In contrast, the analysis is not applicable to hard handoff, which is a potential candidate for replacing with IP mobility. We have submitted this to the drafts alias as an individual contribution Comments are welcome. jak --Sounder_of_Swine_044_000 Content-Type: TEXT/plain; name="draft-kempf-cdma-appl-00.txt"; charset=us-ascii; x-unix-mode=0664 Content-Description: draft-kempf-cdma-appl-00.txt Content-MD5: QLFWjD/x2rxby7zjR/HDMQ== INTERNET DRAFT James Kempf Category: Informational Sun Microsystems, Inc. Title: draft-kempf-cdma-appl-00.txt Peter McCann Date: April 2000 Lucent Technologies Philip Roberts Motorola, Inc. IP Mobility and the CDMA Radio Access Network: Applicability Statement for Soft Handoff Status of this Memo This document is an individual contribution for consideration by the Mobile IP Working Group of the Internet Engineering Task Force. Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Copyright (C) The Internet Society 2000. All Rights Reserved. Kempf, McCann, Roberts expires October 2000 [Page 1] INTERNET DRAFT April 2000 Abstract Recently, there have been a variety of proposals submitted to the Mobile IP Working Group and to other IETF working groups for IP mobility solutions that seek to enhance or replace mobile IP. These proposals, often characterized as micromobility or fast handoff, are addressed primarily at the perceived need of multimedia sessions such as video or voice over IP for faster handoff between radio base stations, and are primarily directed at real time multimedia traffic in 3rd generation cellular access networks. In this paper, we discuss the design of CDMA radio access networks (RANs) and the applicability of IP mobility to soft handoff in a CDMA RAN. We attempt to show that given current IP routing algorithms and the constraints on a CDMA RAN, IP mobility solutions have little, if any, role to play in handoff within the RAN. In contrast, an IP mobility solution is likely to play a big role in fast handoff between RANs, also called hard handoff. While future developments in IP networking may change this situation, IP mobility in CDMA networks currently seems to apply only when the mobile node roams between RANs rather than between base stations within a RAN. Table of Contents 1.0 Introduction 2.0 Terminology 3.0 RAN Architecture and Characteristics 4.0 Applicability of IP Mobility to Soft Handoff 5.0 Applicability of IP Mobility to Hard Handoff 6.0 Future Prospects for IP Mobility in the CDMA RAN 7.0 Summary 8.0 References 9.0 Authors' Addresses 10.0 Full Copyright Statement 1.0 Introduction Mobile IP [1] allows IP hosts that change their point of attachment to the network to keep their IP address as they change from their home subnet to other subnets. Recently, there have been a variety of proposals advanced for augmenting or replacing mobile IP in access networks for cellular telephony systems. These proposals are often characterized as supporting micromobility or fast handoff, and are directed towards real time multimedia streams in 3rd generation cellular networks (see [2] [3] [4] [5] and [7]). While these proposals may have some applicability if handoff between RANs is very frequent, their utility is lessened in the presence of Kempf, McCann, Roberts expires October 2000 [Page 2] INTERNET DRAFT April 2000 link-layer mobility like that offered by today's TDMA and CDMA systems. In fact if the link-layer offers transparent mobility throughout a given domain these proposals do not contribute anything since they are essentially intra-domain mobility management protocols. As cellular networks evolve towards more pervasive IP technologies, mobility for traffic within those networks must accommodate some level of movement of IP traffic. In this paper, we discuss CDMA radio access networks and why IP mobility solutions (including mobile IP) are not applicable to soft handoff in a CDMA radio access network. In effect, the CDMA RAN network with soft handoff is an application layer transport and mobility mechanism, and therefore not an appropriate candidate for moving into the network layer. In contrast, IP mobility solutions that are directed at improving handoff performance within the core network, often called hard handoff, are likely to play an important role in enhancing the performance of IP networking for CDMA (see [6] for an example). 2.0 Terminology mobile terminal A mobile IP host. In mobile IP terminology, this is called the mobile node. base station A fixed, land-based radio transmitter and receiver, used to provide cellular telephony radio coverage in a limited geographic area. A mobile terminal may be in contact with one or more base stations at a time in CDMA networks. Also called the Base Transceiver Station (BTS) or Node B. RAN The radio access network. This is a wired network that sits between a collection of base stations and the core, wired telephone network. The RAN in CDMA systems is involved in real-time distribution and collection of physical layer radio frames to and from base stations, a topic that is discussed in the next section. soft handoff The process by which a moving CDMA mobile terminal is transferred between one base station or set of base stations to another within the radio access network. Soft handoff is typically very fast (on the order of 20 ms) and has a low probability of dropping ongoing real time connections. hard handoff The process by which a moving mobile terminal is transferred Kempf, McCann, Roberts expires October 2000 [Page 3] INTERNET DRAFT April 2000 between one cellular service provider's network and another or between two RANs that do not share a direct connection within a provider's network. Hard handoffs have a higher probability of connection droppage, and are slower (usually 100 ms or more). macrodiversity A term used to describe the fact that within the CDMA RAN, there is no single octet stream corresponding to the data that arrives at or is sent by the mobile terminal. Macrodiversity results because the mobile terminal can be in contact with more than one base station at a time. frame selector A combination software/hardware unit at the gateway to the RAN that combines the multiple octet streams from multiple base stations in contact with a single mobile terminal into a single octet stream. A similar process happens at the mobile terminal. Also called the macrodiversity combiner or Selection and Distribution Unit (SDU). RAN gateway A functional unit positioned between the RAN and the core network. The RAN gateway includes the frame selector, in addition to functional units that perform soft handoff and radio frame processing. Also called the Base Station Controller (BSC) or Radio Network Controller (RNC). radio frame A short (usually 20 millisecond) unit of transmission at the physical radio layer used to transmit data over the air to and from the mobile terminal. The frames do not contain complete IP packets, but rather contain small sections of octet stream data that must be framed by a higher layer protocol (such as PPP) to form IP packets. On a basic fundamental data rate channel one radio frame contains about 20 octets. Radio frames may be retransmitted a small number of times to increase the reliability of the octet stream transport. This is performed by a negative- acknowledgement protocol known as the Radio Link Protocol (RLP). 3.0 RAN Architecture and Characteristics A RAN consists of a RAN gateway connected to one or more base stations. In the network to mobile terminal (forward) direction, the RAN gateway performs the following functions: 1) Receive packets from the core network destined to the mobile terminal, Kempf, McCann, Roberts expires October 2000 [Page 4] INTERNET DRAFT April 2000 2) Process those packets into radio frames, 3) Replicate the radio frames and transmit copies to base stations that are currently in contact with the mobile terminal in a way such that the frames arrive at each base station in a timely fashion, 4) Manage the retransmission of individual radio frames when negative acknowledgements are received. In the mobile terminal to network (reverse) direction, the RAN gateway performs the following functions: 1) Collect copies of the radio frames fowarded by base stations that are currently in contact with the mobile terminal, 2) Combine these (possibly errorful) copies into one (hopefully error-free) radio frame, 3) From the resulting radio frame stream, synthesize an outgoing octet stream of packets for the core network. In both directions, the RAN gateway performs the following function: 1) Manage the power with which mobile nodes and base stations are transmitting, so as to maintain a low error rate while at the same time minimizing the transmitted power and therefore interference among different transmitters (and drain on the mobile terminal's battery). 2) In concert with the mobile terminal, manage the set of base stations with which a mobile terminal is in contact such that the quality of the radio signal is maintained as the mobile terminal moves. The use of multiple base stations to transmit and receive the same radio frames to and from the mobile node at the same time is known as "macrodiversity" and can help to improve the reliability of the wireless link. Note that some of the base stations may be owned by a neighboring RAN and this necessitates a RAN-to-RAN interface to carry the radio frames. The following figure illustrates the architecture and how the CDMA Kempf, McCann, Roberts expires October 2000 [Page 5] INTERNET DRAFT April 2000 RAN network works: Core Network ^ | incoming/outgoing octet stream | from/to corresponding node (129.142.68.79) | V +-----------------------------------------------------+ | RAN Gateway | | | | +-------------+ +-----------+ +----------+ | | | | | | | | | | | Frame | | Frame | | Soft | |----------- | | Selection | | Splitting | | Handoff | | to another | | | | | | Control | | RAN Gateway | +-------------+ +-----------+ +----------+ | | | | +---------------+ | | | | | | | Radio Frame | | | | Processing | | | | | | | +---------------+ | | | +-----------------------------------------------------+ | | | | * | | | | * | | ... | | * radio | | | | * frames | | | | * | | | | * +---------+ +---------+ +---------+ +---------+ | Base | | Base | | Base | | Base | | Station | | Station | | Station | | Station | | B1 | | B2 | | B42 | | B43 | +---------+ +---------+ +---------+ +---------+ \ | \ V \---------> | ----- / \ ----- ----- 162.42.42.42 | mobile terminal|( ---> ------------------ ( ) ( ) Kempf, McCann, Roberts expires October 2000 [Page 6] INTERNET DRAFT April 2000 The links between the RAN gateway and the base stations are typically point to point links today, though provisions exist in the 3rd generation standards for switched networks. In the above figure, a mobile terminal with IP address 162.42.42.42 is corresponding with a host having the IP address 129.142.68.79, through a CDMA cellular network. The mobile terminal is in contact with two base stations, B1 and B2. The RAN gateway takes incoming packets from 129.142.68.79 and splits them into two streams that it sends to base stations B1 and B2. A mobile terminal can be in communication with up to 3 and, in some CDMA systems, up to 6 base stations at a time. When the multiple octet streams are received at the mobile terminal, the mobile terminal performs a sophisticated combination of the multiple packet streams at L1 to deliver the end packet to the application. Packets flowing in the other direction, from 162.42.42.42 to 129.142.68.79, are put into an octet stream which is then divided into radio frames. Each radio frame is received by B1 and B2 and delivered to the frame selector in the RAN gateway. The frame selector performs signal processing on the incoming radio frames and produces a single frame that is then sent to the re-sequencing buffer where the octet stream is re-created. The IP packets are formed from the octet stream and transmitted into the core IP network. An important point to note about the RAN is that, even if the RAN itself is running IP, routing in the RAN does not use the mobile's IP address. In fact, the IP packets sent by the mobile terminal are not tunneled through the RAN nor do they necessarily appear in a form that would be recognizable using a packet sniffer. The packets in the RAN contain radio frames that have been highly processed into a form that is extremely efficient for the base stations to handle and that efficiently uses radio spectrum, including compensations for the inherently lossy nature of the radio medium. On the forward leg to the mobile terminal, because the delay and jitter constraints between multiple base stations transmitting to the same mobile terminal are so tight (5ms to 80ms), the RAN gateway essentially puts out streams of radio frames that the base station can quickly pull off the wire and transmit over the air. On the reverse leg from the mobile terminal, the base station simply pulls the radio frames off the air and puts them on the wire without any further processing. The RAN gateway's radio frame processor is responsible for making sure that the jitter and delay constraints are met, and for processing packets from the core network into radio frames. Kempf, McCann, Roberts expires October 2000 [Page 7] INTERNET DRAFT April 2000 When the mobile terminal begins to move out of range of stations B1 and B2, the RAN gateway adds and deletes base stations from the set currently serving the mobile node. This process is called soft handoff. Note that new base stations may belong to a neighboring RAN which requires closely-coupled RAN-to-RAN interaction. The real time constraints on soft handoff are extremely tight. All base stations involved in soft handoff must transmit the command for the mobile to move at the same time. North American cellular networks use the Global Positioning System as a time source to assure that these timing constraints are met. As shown in the figure, two RAN gateways can be connected together through a direct link. This link allows radio frames containing data and RAN control protocol to flow between two RANs. As a result, two RANs can perform soft handoff between them, increasing the quality and reliability of the connection when a user moves between coverage areas. A RAN gateway and its collection of base stations can only cover a limited geographic area, so RAN interconnection is very important in cellular networks for maintaining good connection quality over large geographic areas. 4.0 Applicability of IP Mobility to Soft Handoff Most of the proposals for IP mobility in the RAN assume the following: 1) An end-to-end IP routing model for routing through the RAN. 2) A one-to-one mapping between the mobile terminal and the base station with which it is in contact. 3) The IP packets coming from the mobile terminal are transported directly on L2 in the RAN. As the above discussion has attempted to show, the extremely tight real time constraints on traffic in the RAN require that RAN traffic be highly processed as radio frames for efficient delivery into and from the radio medium by the base stations. This precludes routing IP packets from the mobile directly over the RAN. Furthermore, because there are multiple octet streams flowing over the RAN that correspond to one logical octet stream going to and from the mobile terminal, there is no one-to-one mapping between the mobile terminal and a base station. Taking mobile IP as an example, using mobile IP in the RAN would require that a mobile IP foreign agent (FA) be present at each base Kempf, McCann, Roberts expires October 2000 [Page 8] INTERNET DRAFT April 2000 station. However, because the mobile terminal can be in contact with up to 6 base stations at once, there is no unique care-of address for the mobile (unless the mobile uses a co-located care-of address). Therefore, the home agent (HA) would need to forward packets to multiple FAs. Furthermore, on the reverse leg, a frame selector is still necessary to generate a single packet for the corresponding node. In effect, the RAN controller is an application level transport and mobility mechanism specialized to the CDMA radio medium. It is therefore not a good candidate for replacing with network level mobility mechanisms. Because of the hard real time constraints involved in soft handoff, the RAN controller's soft handoff function is also not a good candidate for replacing with more general application level mechanisms, such as SIP [4]. 5.0 Applicability of IP Mobility to Hard Handoff Note that the above considerations do not apply to hard handoff, which occurs outside of the RAN. When a mobile terminal moves between two RANs that are not interconnected, the RAN controller defers handoff to the core network. Some mechanism is necessary in the core network to move the mobile terminal's point of attachement at the network level. IP mobility solutions for fast handoff are applicable here. Proposals such as [6] that apply after frame selection do not involve soft handoff and therefore are appropriate for implementing fast, hard handoff. 6.0 Future Prospects for IP Mobility in the CDMA RAN What would it take to enable IP mobility in the RAN? The question is worth examining because the end-to-end model of networking which would be required to make IP mobility work in the RAN has attractions from the point of view of simplicity of network management and transparency. Certainly, routing the mobile's packets directly in the RAN would be a major contributor. For that to happen, IP over the air interface would be necessary. The major impediment to IP over the air is currently header size, but new work in header compression may eliminate this objection. Given that a spectrally efficient representation of IP on the radio medium is possible, IP packets can be sent out over the air by the mobile terminal, and the base stations can handle the packets precisely as they currently do with the specialized radio frames. The result would be that IP packets from the radio would appear directly on L2 in the RAN. Kempf, McCann, Roberts expires October 2000 [Page 9] INTERNET DRAFT April 2000 However, there is still a problem with macrodiversity. On the forward leg, the routing from a single source at the RAN gateway to multiple base stations looks like multicast, but the real time constraints are extremely tight. A multicast routing algorithm with routing tree modifications that converge in real time might contribute to solving the problem. On the other hand, the reverse leg traffic would still need to be combined in the wired network behind the base stations. While the prospects for moving IP into the RAN are good, it seems unlikely that IP mobility will play any role in replacing CDMA soft handoff in the immediate future. CDMA soft handoff appears to be a very specialized form of transport-level or link layer mobility, and therefore not a good candidate for replacement by more general network or application level mechanisms. In addition, even if IP is used for transport in the RAN, if voice over IP is to completely replace the current radio voice protocols, voice packets may need to be processed at the RAN gateway for maximum efficiency and robustness over the radio medium. 7.0 Summary Most proposals for IP mobility require a one-to-one mapping between the mobile terminal and a base station with which it is in contact, and assume end-to-end connectivity and consequently routing in the radio access network based on the mobile's IP address. In CDMA networks, macrodiversity and the need for extremely low delay and jitter invalidate these assumptions. Consequently, IP mobility solutions are not applicable to CDMA soft handoff. These considerations do not, however, apply to hard handoff which occurs in the core network after frame selection. 8.0 References [1] Perkins, C. (ed.), IP Mobility Support for IPv4, revised, draft- ietf-mobileip-rfc2002-bis.txt (work in progress), January, 2000. [2] Vakil, Faramak, et. al., Host Mobility Management Protocol: Extending SIP to 3G-IP Networks, draft-itsumo-hmmp-00.txt (work in progress), October, 1999. [3] E. Wedlund and H. Schulzrinne. Mobility Support Using SIP. Second ACM/IEEE International Conference on Wireless and Mobile Multimedia (WoWMoM'99). Seattle, Washington. Aug. 1999. [4] O'Neill, A. and Corson, S., Edge Mobility Architecture, draft- oneill-ema-00.txt (work in progress), October, 1999. [5] Campbell, A., et. al., Cellular IP, draft-ietf-mobileip- Kempf, McCann, Roberts expires October 2000 [Page 10] INTERNET DRAFT April 2000 cellularip-00.txt, January, 2000. [6] Kempf, J. and Calhoun, P., Foreign Agent Assisted Hand-off, draft-calhoun-mobileip-proactive-fa-00.txt (work in progress), January, 2000. [7] Ramjee, R., et. al., IP micro-mobility support using HAWAII, Internet Draft (work in progress), June 1999. 9.0 Authors' Addresses Questions about this memo can be directed to: James Kempf Network and Security Research Center, Sun Labs Sun Microsystems, Inc. 901 San Antonio Rd., UMPK15-214 Palo Alto, CA, 94303 USA Phone: +1 650 786 5890 Fax: +1 650 786 6445 E-Mail: james.kempf@sun.com Peter McCann Bell Laboratories 263 Shuman Boulevard Room 2Z-305 P.O. Box 3050 Naperville, IL, 60566 USA Phone: +1 630 713 9359 Fax: +1 630 713 4982 E-Mail: mccap@research.bell-labs.com Philip Roberts Motorola, Inc. 1501 W. Shure Dr. Arlington Heights, IL, 60015 Phone: +1 847 632 3148 E-Mail: qa3445@email.mot.com 9.0 Full Copyright Statement Kempf, McCann, Roberts expires October 2000 [Page 11] INTERNET DRAFT April 2000 Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this docu- ment itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Inter- net organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permis- sions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WAR- RANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Kempf, McCann, Roberts expires October 2000 [Page 12] --Sounder_of_Swine_044_000-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed May 3 11:33:57 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04464 for ; Wed, 3 May 2000 11:33:57 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.736557D0@standards.nortelnetworks.com>; Wed, 3 May 2000 11:26:40 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 34234 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 3 May 2000 11:26:15 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FF0FF5D0@standards.nortelnetworks.com>; Wed, 3 May 2000 11:16:15 -0400 Received: from marjan.fesb.hr (root@marjan.fesb.hr [161.53.166.3]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id KAA17879 for ; Wed, 3 May 2000 10:22:38 -0500 (CDT) Received: from jurica (jurica.fesb.hr [161.53.166.43]) by marjan.fesb.hr (8.9.3/8.9.3) with SMTP id QAA28524; Wed, 3 May 2000 16:17:37 +0200 (MET DST) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit 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: <062801bfb50a$e567aaa0$2ba635a1@fesb.hr> Date: Wed, 3 May 2000 16:18:39 +0200 Reply-To: SoftCOM Secretary Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: SoftCOM Secretary Organization: FESB, University of Split Subject: [MOBILE-IP] Second Call for Papers To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Dear All A Gentle Reminder * Kindly ignore this email if you have received this before. Please give * this remainder to your coleagues that might be interested. Thank you for your kind attention and cooperation. *********************************************************** The 8th IEEE International Conference on Software, Telecommunications and Computer networks (SoftCOM 2000) will be held from October 11-14, 2000 aboard the luxury ship Marko Polo travelling on the route Split (Croatia) - Rijeka (Croatia) - Trieste (Italy) - Venice (Italy) - Dubrovnik (Croatia). The aim of the conference is to provide an international forum for experts to promote, share and discuss various issues and developments in the broad field of telecommunication and computer networks. We thus seek and solicit your contributions in the form of original/unpublished papers, tutorials, and topics for special sessions/panel discussions. More information on the scope of the conference and the guidelines for the submission of contributions can be obtained at this web site: http://www.fesb.hr/SoftCOM We look forward to your participation. Thank you. SoftCOM 2000 Organizing Committee From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed May 3 14:05:36 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07755 for ; Wed, 3 May 2000 14:05:36 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A0F0FE10@standards.nortelnetworks.com>; Wed, 3 May 2000 13:58:15 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 34655 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 3 May 2000 13:56:33 -0400 Received: from dnsmx1rrc.telcordia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FE1B5010@standards.nortelnetworks.com>; Wed, 3 May 2000 13:46:33 -0400 Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8]) by dnsmx1rrc.telcordia.com (8.9.3/8.9.2) with SMTP id NAA26327; Wed, 3 May 2000 13:52:57 -0400 (EDT) Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 852568D4.006237F7 ; Wed, 3 May 2000 13:52:48 -0400 X-Lotus-FromDomain: TELCORDIA Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <852568D4.00623794.00@notes949.cc.telcordia.com> Date: Wed, 3 May 2000 13:52:15 -0400 Reply-To: Ashutosh Dutta Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Ashutosh Dutta Subject: Re: [MOBILE-IP] [SIP] Applicability of IP Mobility to CDMA Soft Handoff X-To: James Kempf X-cc: sip@lists.bell-labs.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM HI James & co, I have few questions after my first reading of the draft Page 7: When you talk about RAN-RAN interconnection (closley coupled way), what is your assumption? Does each neighboring RAN (RAN-GW) belong to a different IP subnet? or these RAN-GWs belong to the same subnet but are just distributed along. Page 6: Client listening to multiple base stations (3 or 6) at the same time: Do you assume multiple interfaces on the client or just one? In cases where the neighboring BSs for a mobile client are part of RANs belonging to different subnets ( and controlled by different RAN-GW), how does the RAN-GWs interact with each other to take care of soft-handoff, probably some sort of IP-mobility solution like IP multicast can be helpful here. Thanks Ashutosh From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed May 3 19:59:26 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13056 for ; Wed, 3 May 2000 19:59:26 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.154B4140@standards.nortelnetworks.com>; Wed, 3 May 2000 19:52:16 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 35712 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 3 May 2000 19:50:37 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.74893100@standards.nortelnetworks.com>; Wed, 3 May 2000 19:40:37 -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 RAA08165; Wed, 3 May 2000 17:47:13 -0600 (MDT) Received: from locked.eng.sun.com (locked.Eng.Sun.COM [129.146.85.189]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA25436; Wed, 3 May 2000 16:47:10 -0700 (PDT) Received: (from mohanp@localhost) by locked.eng.sun.com (8.10.1+Sun/8.10.1) id e43NkM009445; Wed, 3 May 2000 16:46:22 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID: <200005032346.e43NkM009445@locked.eng.sun.com> Date: Wed, 3 May 2000 16:46:21 -0700 Reply-To: Mohan Parthasarathy Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Mohan Parthasarathy Subject: Re: [MOBILE-IP] New version of "Mobility Support in IPv6" draft X-To: Dave Johnson To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <26784.956861838@maredsous.monarch.cs.cmu.edu> from Dave Johnson at "Apr 27, 2000 02:57:18 pm" Content-Transfer-Encoding: 7bit Dave, The IPsec processing section is not very clear on what exact bits pass through AH i.e at least what does the source address and the Home address option contain ? Without this, there might be potential inter-operability problems. In section 10.2, it describes that HOME address option is inserted, *replacing* the source address in the packet's IP header with a COA, then AH ICV is computed. What does the HOME address option contain ? I understand that it contains the original ip6_src which is the HOME address. *replacing* is really *swap* then. In section 5.4 and other places, on inbound if a packet contains HOME address option, it states that it should be processed first which implies that the source address will be replaced with the HOME address. Again, this is before the computation of the AH ICV. ICV computed this way will not match with what was done on outbound as ip6_src contains the COA while ICV was computed. Is it possible to clarify this so that everybody computes the ICV with the same set of bits.. thanks -mohan > I just submitted a revised version of the Internet-Draft "Mobility > Support in IPv6", which corrects a number of minor problems and adds > several clarifications over the previous version of the draft. Here > is a list of some of the changes since the previous version: > > - Moved the definition of IPsec requirements for Binding Updates > and Binding Acknowledgements to Section 4.4), giving this > important information its own specific section with a section > title (IPsec Requirements for Mobile IPv6 Destination Options) > that will be identifiable in the table of contents for this > document. This makes these requirements harder to miss than > where they were defined in Sections 5.1 and 5.2, mixed in with > the definition of the format of these destination options. > > - In Section 4.6, added a precise definition of Sequence Number > value comparison modulo 2**16. Also added a reference to this > definition in each other place where Sequence Number comparison > is discussed. > > - Added a statement in Section 9.5 to clarify the sending of a > Neighbor Advertisement message by the home agent on behalf of the > mobile node in order to intercept packets addressed to the mobile > node. Except for the specific fields defined there, all fields > in each such Neighbor Advertisement SHOULD be set in the same > way they would be set by the mobile node itself if sending this > Neighbor Advertisement while at home [17]. > > - In Section 10.6, specified that the Lifetime in the Binding > Update sent by a mobile node to its home agent SHOULD be less > than or equal to the remaining lifetime of the home address and > the care-of address specified for the binding. > > - In Section 10.8, modified the specification that was there > about the correct setting of the Lifetime in the Binding > Update sent by a mobile node to a correspondent node. The > original specification stated that the Lifetime value MUST be no > greater than the remaining lifetime of the mobile node's home > registration of its primary care-of address at its home agent. > However, there should be no necessary relationship between the > remaining lifetime of a home registration and the lifetime of > a binding at a correspondent node. Instead, as with the home > registration Binding Update, the Lifetime in the Binding Update > sent by a mobile node to a correspondent node SHOULD be less than > or equal to the remaining lifetime of the home address and the > care-of address specified for the binding. > > - In Section 5.4, added a statement that a packet MUST NOT contain > more than one Home Address option, except that an encapsulated > packet [4] MAY contain a separate Home Address option associated > with each encapsulating IP header. > > - In Section 4.6, added a new field in the Binding Update List > entry format to record the initial value of the Lifetime field > sent in that Binding Update. > > - In Section 10.12, defined a new step in processing a received > Binding Acknowledgement: if the value specified in the Lifetime > field in the Binding Acknowledgement is less than the Lifetime > value sent in the Binding Update being acknowledged, then the > mobile node MUST subtract the difference between these two > Lifetime values from the remaining lifetime for the binding > as maintained in the corresponding Binding Update List entry. > The effect of this step is to correctly manage the mobile > node's view of the binding's remaining lifetime (as maintained > in the corresponding Binding Update List entry) so that it > correctly counts down from the Lifetime value given in the > Binding Acknowledgement, but with the timer countdown beginning > at the time that the Binding Update was sent. This change also > affected Section 10.8 in sending Binding Updates, to record both > the original lifetime and the remaining lifetime in the Binding > Update List. > > - In Sections 5.1 and 9.3, clarified that the Duplicate Address > Detection performed by the home agent if the Duplicate Address > Detection (D) bit is set in the Binding Update, is performed > before returning the Binding Acknowledgement for that Binding > Update. > > - In Section 5.1, clarified that the mobile node SHOULD set the > Duplicate Address Detection (D) bit in its home registration > Binding Updates based on any requirements for Duplicate Address > Detection that would apply to the mobile node if it were at > home [17, 27]. > > - In Section 9.3, specified that a home agent, when performing > Duplicate Address Detection for a mobile node when the > Duplicate Address Detection (D) bit is set in a received > Binding Update, SHOULD NOT delay sending the initial Neighbor > Solicitation message of Duplicate Address Detection by the random > delay specified for normal processing of Duplicate Address > Detection [17, 27]. > > - In Section 10.5, defined special considerations for a mobile > node's use of Duplicate Address Detection upon forming a new > care-of address. In particular, the mobile node MAY begin > using the new care-of address without performing Duplicate > Address Detection, and MAY optionally bypass Duplicate Address > Detection or begin Duplicate Address Detection asynchronously > when it begins use of the address, allowing the Duplicate > Address Detection procedure to complete in parallel with > normal communication using the address. In addition, the > mobile node SHOULD NOT delay sending the initial Neighbor > Solicitation message of Duplicate Address Detection by the random > delay specified for normal processing of Duplicate Address > Detection [17, 27], unless the mobile node is initializing after > rebooting. > > - In Section 4.6, added a clarification to the definition of the > Binding Update List, that for multiple Binding Updates sent to > the same destination address, the Binding Update List contains > only the most recent Binding Update (i.e., with the greatest > Sequence Number value) sent to that destination. This was > already noted in previous versions of the draft in the sending of > Binding Updates, as defined in Section update-corresp, but was > not previously stated explicitly in the definition of the Binding > Update List conceptual data structure. > > - In Section 9.3, added a specification that the lifetime for the > Binding Cache entry (and thus the Lifetime value returned in the > Binding Acknowledgement) MUST NOT be greater than the Lifetime > value specified in the Binding Update. Also added a similar > specification (and clarification) in Section 8.3 for the Binding > Cache entry in a correspondent node. > > - In Section 10.6, added a clarification that, when sending a > Binding Update to its home agent, the mobile node MUST also > create or update the corresponding Binding Update List entry, as > specified in Section 10.8. > > The official announcement of the draft should appear on the mailing > lists shortly, but you can get a copy of the new draft now from > > http://www.monarch.cs.cmu.edu/internet-drafts/draft-ietf-mobileip-ipv6-12.txt > > We expect to go to Last Call on this version of the draft shortly. > Please send any comments on the draft to the Mobile IP mailing list at > mobile-ip@standards.nortelnetworks.com. > > Thanks. > > Dave > > -- > David B. Johnson dbj@cs.cmu.edu > Associate Professor http://www.cs.cmu.edu/~dbj/ > Computer Science Department http://www.monarch.cs.cmu.edu/ > Carnegie Mellon University Phone: (412) 268-7399 > 5000 Forbes Avenue Fax: (412) 268-5576 > Pittsburgh, PA 15213-3891 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 4 01:46:57 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23198 for ; Thu, 4 May 2000 01:46:57 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9ECDBC60@standards.nortelnetworks.com>; Thu, 4 May 2000 1:39:43 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 36061 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 4 May 2000 01:37:55 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F91057C0@standards.nortelnetworks.com>; Thu, 4 May 2000 1:27:55 -0400 Received: from uci.agh.edu.pl (root@galaxy.uci.agh.edu.pl [149.156.96.9]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id AAA22540 for ; Thu, 4 May 2000 00:34:29 -0500 (CDT) Received: from saturn.kt.agh.edu.pl (proms@saturn.kt.agh.edu.pl [149.156.114.3]) by uci.agh.edu.pl (8.9.3/8.8.7/rchk1.20) with SMTP id HAA19818 for ; Thu, 4 May 2000 07:34:27 +0200 (MET DST) Received: by saturn.kt.agh.edu.pl (AIX 3.2/UCB 5.64/5.1) for mobile-ip@smallworks.com id AA26030; Thu, 4 May 2000 07:33:29 +0200 Address: Mickiewicza 30, 30-059 Krakow, POLAND Message-ID: <10005040533.AA26030@saturn.kt.agh.edu.pl> Date: Thu, 4 May 2000 07:33:29 +0200 Reply-To: Piotr Pacyna Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Piotr Pacyna Organization: University of Mining and Metallurgy Subject: [MOBILE-IP] PROMS2000 Call for Papers X-To: mobile-ip@smallworks.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Dear Sir, Dear Madam, Please find enclosed the Protocols for Multimedia Systems conference CfP. We do apologise if you receive multiple copies of this. Thank you for your attention. With best regards, Piotr Pacyna ++++++++++++++++++++++++++++++++++++++++++++++++++++++ (Please apologize, if you receive multiple copies of this CfP) Announcement and Call for Papers PROTOCOLS FOR MULTIMEDIA SYSTEMS - PROMS2000 Cracow, Poland, October 22-25, 2000 Sponsored by IEEE Poland Sect. and Cracow Communications Soc. Chap. Lucent Technologies, ZWUT a Siemens Company, http://PROMS2000.kt.agh.edu.pl/ After past successful PROMS conferences held in Berlin, Salzburg, Madrid, and Santiago de Chile now we cordially invite you to Cracow/Poland, a lovely university city, with a 1000 year history, today one of cultural capitals of Europe. Emerging broadband interactive applications along with a development of different networking technologies should draw telecom operators' and service providers' attention to protocols supporting multimedia systems as an interface between these two environments that has to be still investigated and modified. The PROMS2000 conference is intended to contribute to a scientific, strategical and practical cooperation between research institutes and industrial companies in the area of distributed multimedia applications, protocols, and intelligent management tools, with emphasis on their provision over broadband networks. PROMS2000 will cover papers and demonstrations on research and achievements related to the following topics: TOPICS * design and implementation of multimedia protocols for public switched telephony networks, mobile networks, data networks, and satellite networks using IP, ATM or other connectivity techniques; * application, media, and protocol integration: synchronization of media streams; * multiparty and group communication protocols; * mobile networking and routing: multimedia communication architectures for mobile networks; * multimedia applications: video-on-demand, digital video libraries, video games, virtual community, teleworking, teleteaching, e-commerce, telemeeting, virtual reality simulations; * content based searching and querying; * techniques for the specification of communication services required by multimedia applications; * methods for real-time testing and analysis of service implementations; * integration of media storage and communication mechanisms, operating system and high-performance issues; * experiences with service provisioning using distributed multimedia applications, eg. voice over IP; * performance of protocols, such as TCP, and applications: modeling, simulation and optimization in different networks; * definition, provisioning, and supervision of QoS parameters for networked applications and services, eg. in IntServ/DiffServ networks; * multimedia traffic engineering; * applications and platforms for service management and provisioning; * intelligent management tools pertaining to costs and quality of service, network access, accounting, security, and system resilience; * service access - security, authentication, privacy; * accounting and tariff policing for multimedia teleservices. IMPORTANT DATES * Full papers due June 26, 2000 * Authors notified July 24, 2000 * Full paper camera ready due September 25, 2000 CONFERENCE TIMETABLE * 1st day October 22 full-day sightseeing tour (optional) * 2nd day October 23 tutorials, welcome reception * 3rd day October 24 invited talks, sessions, panel, banquet * 4th day October 25 invited talks, sessions VENUE Its history rooted deep in the Middle Ages, Cracow, is the most celebrated city in Poland. UNESCO has added its architectural complex to the World Heritage List. Cracow's appeal today, however, is no longer attributable solely to the beauty of its medieval architecture, but to its strong scientific potential for applied research and development. The PROMS2000 Conference will be held on the modern premises of the Department of Telecommunications within walking distance of both the downtown area and hotels. Direct flights to Cracow are available to and from Chicago, Copenhagen, New York, Toronto, Frankfurt, London, Paris, Rome, Tel Aviv, Vienna and Zurich. SUBMISSION Submit a full manuscript to the PROMS chair in an electronic form (MSWord, Postscript or pdf file); editorial requirements can be found at http://PROMS2000.kt.agh.edu.pl/. PROCEEDINGS 1. Each participant will receive Proceedings from the conference. 2. Two best papers will be considered for publication in the IEEE Communications Magazine (March 2001 issue) in a feature topic "Protocols for Multimedia Systems". CONFERENCE CHAIR Zdzislaw PAPIR Department of Telecommunications University of Mining and Metallurgy Al. Mickiewicza 30 30-059 Cracow, Poland E-mail: papir@kt.agh.edu.pl Phone: +48 12 634 55 82 Fax: +48 12 634 23 72 PROGRAM COMMITTEE Koichi Asatani, Univ. Kogakuin, asatani@sin.cc.kogakuin.ac.jp William Atwood, Univ. Concordia, Bill@cs.Concordia.ca Arturo Azcorra, Univ. Carlos III de Madrid, azcorra@it.uc3m.es Stanislaw Budkowski, INT-Evry, stan@int-evry.fr Andrew Campbell, Univ. Columbia, campbell@ctr.columbia.edu Michel Diaz, LAAS-CNRS, diaz@laas.fr Wolfgang Effelsberg, Univ. Mannheim, effelsberg@informatik.uni-mannheim.de Paolo Fasano, CSELT, Paolo.Fasano@cselt.it Francisco Fontes, Portugal Telecom, fontes@ptinovacao.pt Nicolas D. Georganas, Univ. Ottawa, georgana@mcrlab.uottawa.ca Per Gunningberg, Univ. Uppsala, Per.Gunningberg@docs.uu.se Ulrich Hofmann, Univ. Salzburg, ulrich.hofmann@fh-sbg.ac.at David Hutchison, Univ. Lancaster, dh@comp.lancs.ac.uk Yuji Inoue, NTT, yuji@rd.nttdata.co.jp Andrzej Jajszczyk, Univ. Mining and Metallurgy, jajszcz@kt.agh.edu.pl Pedro Lizcano, Telefonica Labs, lizcano@tid.es John C. S. Lui, Chinese Univ. Hong Kong, cslui@cse.cuhk.edu.hk Andrzej R. Pach, Univ. Mining & Metallurgy, pach@kt.agh.edu.pl Sergio Palazzo, Univ. Catania, palazzo@iit.unict.it Thomas Plagemann, Center for Technology, plageman@unik.no Radia Perlman, SUN, radia.perlman@sun.com Radu Popescu-Zeletin, GMD, zeletin@fokus.gmd.de Marten J. van Sinderen, Univ. Twente, sinderen@cs.utwente.nl Kazem Sohraby, Lucent, sohraby@lucent.com Joan I. Solana, Nokia Telecom R & D, juan.solana@nokia.com Eduardo Vera, Univ. of Chile, evera@accessnova.cl Johan Zuidweg, Tecsidel, johan.zuidweg@ieee.org ORGANISING COMMITTEE Chair: Piotr PACYNA, proms@kt.agh.edu.pl K. Juszkiewicz, juszkiew@kt.agh.edu.pl J. Gozdecki, gozdecki@kt.agh.edu.pl J. Roman, roman@kt.agh.edu.pl From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 4 03:04:08 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00365 for ; Thu, 4 May 2000 03:04:07 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.633AE0A0@standards.nortelnetworks.com>; Thu, 4 May 2000 2:56:47 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 36127 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 4 May 2000 02:54:57 -0400 Received: from mail0.u-aizu.ac.jp by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.21678750@standards.nortelnetworks.com>; Thu, 4 May 2000 2:54:57 -0400 Received: from pross114.u-aizu.ac.jp (pross114 [163.143.180.102]) by mail0.u-aizu.ac.jp (8.9.3+3.1W/3.7Winternet-gw) with ESMTP id QAA08100; Thu, 4 May 2000 16:01:22 +0900 (JST) Received: from u-aizu.ac.jp (localhost [127.0.0.1]) by pross114.u-aizu.ac.jp (8.9.3+3.1W/3.7Wistcmx+kanji) with ESMTP id QAA14947; Thu, 4 May 2000 16:01:21 +0900 (JST) X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Message-ID: <39112041.34D22542@u-aizu.ac.jp> Date: Thu, 4 May 2000 16:01:21 +0900 Reply-To: sarikaya@U-AIZU.AC.JP Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Behcet Sarikaya Organization: University of Aizu Subject: Re: [MOBILE-IP] Hand-over resend X-cc: alan.w.oneill@BT.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Could anybody understand the ema draft? It depends on another draft from adhoc networking wg called TORA, i.e. the draft is not self contained. -- Behcet From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 4 06:48:43 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02039 for ; Thu, 4 May 2000 06:48:43 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B9CD1B30@standards.nortelnetworks.com>; Thu, 4 May 2000 6:41:07 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 36347 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 4 May 2000 06:39:27 -0400 Received: from ietf.org (132.151.1.176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.18C3A1B0@standards.nortelnetworks.com>; Thu, 4 May 2000 6:29:27 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01907; Thu, 4 May 2000 06:36:07 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200005041036.GAA01907@ietf.org> Date: Thu, 4 May 2000 06:36:07 -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-kempf-cdma-appl-00.txt X-cc: sip@lists.bell-labs.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IP Mobility and the CDMA Radio Access Network: Applicability Statement for Soft Handoff Author(s) : J. Kempf, P. McCann, P. Roberts Filename : draft-kempf-cdma-appl-00.txt Pages : 12 Date : 03-May-00 Recently, there have been a variety of proposals submitted to the Mobile IP Working Group and to other IETF working groups for IP mobility solutions that seek to enhance or replace mobile IP. These proposals, often characterized as micromobility or fast handoff, are addressed primarily at the perceived need of multimedia sessions such as video or voice over IP for faster handoff between radio base stations, and are primarily directed at real time multimedia traffic in 3rd generation cellular access networks. In this paper, we discuss the design of CDMA radio access networks (RANs) and the applicability of IP mobility to soft handoff in a CDMA RAN. We attempt to show that given current IP routing algorithms and the constraints on a CDMA RAN, IP mobility solutions have little, if any, role to play in handoff within the RAN. In contrast, an IP mobility solution is likely to play a big role in fast handoff between RANs, also called hard handoff. While future developments in IP networking may change this situation, IP mobility in CDMA networks currently seems to apply only when the mobile node roams between RANs rather than between base stations within a RAN. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kempf-cdma-appl-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-kempf-cdma-appl-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-kempf-cdma-appl-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: <20000503111149.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kempf-cdma-appl-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-kempf-cdma-appl-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000503111149.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 4 10:18:10 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06468 for ; Thu, 4 May 2000 10:18:09 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F8AF41D0@standards.nortelnetworks.com>; Thu, 4 May 2000 10:10:28 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 36602 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 4 May 2000 10:08:41 -0400 Received: from clea.qualcomm.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B8DEBD60@standards.nortelnetworks.com>; Thu, 4 May 2000 10:08:41 -0400 Received: from jwillkie1 (jwillkie1.qualcomm.com [129.46.219.171]) by clea.qualcomm.com (8.9.3/8.9.3/1.0) with SMTP id HAA29314; Thu, 4 May 2000 07:15:18 -0700 (PDT) X-Sender: jwillkie@mail1.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <4.1.20000504070937.00dba320@mail1.qualcomm.com> Date: Thu, 4 May 2000 07:15:07 -0700 Reply-To: Jim Willkie Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Jim Willkie Subject: Re: [MOBILE-IP] I-D ACTION:draft-kempf-cdma-appl-00.txt X-To: Internet-Drafts@ietf.org To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200005041036.GAA01907@ietf.org> At 06:36 AM 5/4/00 -0400, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : IP Mobility and the CDMA Radio Access Network: > Applicability Statement for Soft Handoff > Author(s) : J. Kempf, P. McCann, P. Roberts > Filename : draft-kempf-cdma-appl-00.txt > Pages : 12 > Date : 03-May-00 > >Recently, there have been a variety of proposals submitted to the >Mobile IP Working Group and to other IETF working groups for IP >mobility solutions that seek to enhance or replace mobile IP. These >proposals, often characterized as micromobility or fast handoff, are >addressed primarily at the perceived need of multimedia sessions such >as video or voice over IP for faster handoff between radio base >stations, and are primarily directed at real time multimedia traffic >in 3rd generation cellular access networks. In this paper, we discuss >the design of CDMA radio access networks (RANs) and the applicability >of IP mobility to soft handoff in a CDMA RAN. We attempt to show that >given current IP routing algorithms and the constraints on a CDMA >RAN, IP mobility solutions have little, if any, role to play in >handoff within the RAN. In contrast, an IP mobility solution is >likely to play a big role in fast handoff between RANs, also called >hard handoff. While future developments in IP networking may change >this situation, IP mobility in CDMA networks currently seems to apply >only when the mobile node roams between RANs rather than between base >stations within a RAN. Well great cheers to the authors!! Hopefully this paper and any potential enusing discussions will quell any effort to use mobileIP for soft handoff on CDMA networks.... Jim Willkie From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 4 10:59:20 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07386 for ; Thu, 4 May 2000 10:59:20 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B96284A0@standards.nortelnetworks.com>; Thu, 4 May 2000 10:51:38 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 36732 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 4 May 2000 10:50:36 -0400 Received: from dumburken.it.kth.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.94243760@standards.nortelnetworks.com>; Thu, 4 May 2000 10:50:36 -0400 Received: (from maguire@localhost) by dumburken.it.kth.se (8.9.3/8.9.3) id QAA08179; Thu, 4 May 2000 16:57:06 +0200 (MET DST) X-Authentication-Warning: dumburken.it.kth.se: maguire set sender to maguire@dumburken.it.kth.se using -f References: <200005031516.IAA06215@nasnfs.eng.sun.com> Message-ID: <200005041457.QAA08179@dumburken.it.kth.se> Date: Thu, 4 May 2000 16:57:06 +0200 Reply-To: Gerald Maguire Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gerald Maguire Subject: Re: [MOBILE-IP] Applicability of IP Mobility to CDMA Soft Handoff X-To: James.Kempf@Eng.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200005031516.IAA06215@nasnfs.eng.sun.com> (message from James Kempf on Wed, 3 May 2000 08:19:33 -0700) In draft-kempf-cdma-appl-00.txt, you state that "the reverse leg traffic would still need to be combined in the wired network behind the base stations." Why is this necessary? If the corresponding host receives multiple copies of the packet, it can decide to accept the first one to arrive which is correct and throw away the other copies. You also state: " ... In addition, even if IP is used for transport in the RAN, if voice over IP is to completely replace the current radio voice protocols, voice packets may need to be processed at the RAN gateway for maximum efficiency and robustness over the radio medium." Why add this processing (and hence additional delay) in the RAN gateway, when the voice encoding/decoding can simply be done at the mobile? Any necessary robustness can be provided by end points and thus you avoid any possible need to transcode in the RAN. Although the draft very thoughtfully describes the current CDMA systems and the requirements, it does not provide a proof that end-to-end IP can't be done. So I don't think Jim Willkie's statement "Hopefully this paper and any potential enusing discussions will quell any effort to use mobileIP for soft handoff on CDMA networks...." has any basis. What is missing is some real measurements on the delays involved in controlling a device which can replicate packets for transmission over tunnels to several base stations and implementation and measurement of a base station which does IP directly over RLP. Christian Olrog showed in April 1999, in his M.S. thesis "Direct Radio Link Protocol Interface", that GSM's RLP processing could be done on a PC running Linux -- rather than requiring a real-time OS. Prior to his implementation and measurements everyone thought this couldn't be done. What is the chance that we will see the same thing happen with regard to end-to-end IP? Regards, Chip From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 4 11:24:21 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08206 for ; Thu, 4 May 2000 11:24:21 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3BB38AF0@standards.nortelnetworks.com>; Thu, 4 May 2000 11:16:45 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 36831 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 4 May 2000 11:16:03 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.21E036F0@standards.nortelnetworks.com>; Thu, 4 May 2000 11:16:02 -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 JAA28565; Thu, 4 May 2000 09:22:34 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA04284; Thu, 4 May 2000 08:19:24 -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 IAA06402; Thu, 4 May 2000 08:19:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Pm1qnwKqLkBHUQeLL2QIqA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Message-ID: <200005041519.IAA06402@nasnfs.eng.sun.com> Date: Thu, 4 May 2000 08:22:07 -0700 Reply-To: James Kempf Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: James Kempf Subject: Re: [MOBILE-IP] [SIP] Applicability of IP Mobility to CDMA Soft Handoff X-To: adutta@telcordia.com X-cc: sip@lists.bell-labs.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM >HI James & co, I have few questions after my first reading of the draft >Page 7: > When you talk about RAN-RAN interconnection (closley coupled way), >what is your assumption? Does each neighboring RAN (RAN-GW) belong to a >different IP subnet? or these RAN-GWs belong to the same subnet but are just >distributed along. > Whether or not they belong to a different subnet is not important from the point of view of a moving terminal, since the terminal's IP packets are not routed through the RAN based on the terminal's IP address. The termimal's packets are processed into radio frames, in which the IP packets are encoded. If the RAN is IP based (it may not be and, in fact, in current 2G and 3G designs is not), then the links are typically point to point or at most one hop, due to the stringent timing constraints. The radio frames in an IP-based RAN would run on top of IP (maybe UDP) directly, and the terminal's IP packets would not be identifiable in the RAN as such, except by performing the same processing the terminal's CDMA hardware performs to decode the radio frames. >Page 6: > > Client listening to multiple base stations (3 or 6) at the same >time: Do you assume multiple interfaces on the client or just one? >In cases where the neighboring BSs for a mobile client are part of RANs >belonging to different subnets ( and controlled by different RAN-GW), how does >the RAN-GWs interact with each other to take care of soft-handoff, probably some >sort of IP-mobility solution like IP multicast can be helpful here. > The client has only one "interface" in the IP sense. A mobile CDMA phone uses a signal processing technique to combine the incoming signals to produce a single packet. This process proceeds at the physical layer, i.e. L1, and therefore the upper layers never see more than a single packet as was incoming to the frame selector/ distributor from the corresponding node. So the phone can have only a single IP address for the CDMA connection, even though at the physical layer there are multiple signals coming in with the same (modulo errors) octet stream. This characteristic is the single largest deterrent to using IP mobility in CDMA RANs. jak From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 4 11:50:27 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09032 for ; Thu, 4 May 2000 11:50:26 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E26EC5A0@standards.nortelnetworks.com>; Thu, 4 May 2000 11:42:54 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 36932 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 4 May 2000 11:41:28 -0400 Received: from dirty.research.bell-labs.com (204.178.16.6) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AF6A2A00@standards.nortelnetworks.com>; Thu, 4 May 2000 11:41:28 -0400 Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Thu May 4 11:47:08 EDT 2000 Received: from king.research.bell-labs.com ([135.1.152.1]) by grubby; Thu May 4 11:47:07 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 011CA57042; Thu, 4 May 2000 10:47:01 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <200005031516.IAA06215@nasnfs.eng.sun.com> <200005041457.QAA08179@dumburken.it.kth.se> X-Mailer: VM 6.33 under Emacs 19.34.2 Message-ID: <20000504154702.011CA57042@king.research.bell-labs.com> Date: Thu, 4 May 2000 10:47:02 -0500 Reply-To: Pete McCann Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Pete McCann Subject: Re: [MOBILE-IP] Applicability of IP Mobility to CDMA Soft Handoff X-To: Gerald Maguire To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200005041457.QAA08179@dumburken.it.kth.se> Content-Transfer-Encoding: 7bit Hi, Gerald, Gerald Maguire (GM) writes: GM> In draft-kempf-cdma-appl-00.txt, you state that "the reverse leg GM> traffic would still need to be combined in the wired network behind GM> the base stations." Why is this necessary? If the corresponding host GM> receives multiple copies of the packet, it can decide to accept the GM> first one to arrive which is correct and throw away the other copies. This is necessary to support the macrodiversity features of a CDMA RAN. The radio frame received by any given base station is likely to contain errors, and in any case will be just one chunk of an IP packet. The frame selector combines the frames from multiple base stations, hopefully correcting any errors and producing a single frame that contains data for the octet stream that carries IP traffic. So an individual radio frame received by a base station is *not* an IP packet and cannot be routed directly to a correspondent host without being processed by a frame selector. If you don't believe that macrodiversity is important, then you would eliminate the centralized frame selector and try to reconstruct the packets from only one stream of radio frames. However, this would degrade performance from current CDMA systems. GM> You also state: GM> " ... In addition, even if IP is GM> used for transport in the RAN, if voice over IP is to completely GM> replace the current radio voice protocols, voice packets may need to GM> be processed at the RAN gateway for maximum efficiency and robustness GM> over the radio medium." GM> Why add this processing (and hence additional delay) in the RAN GM> gateway, when the voice encoding/decoding can simply be done at the GM> mobile? Any necessary robustness can be provided by end points and GM> thus you avoid any possible need to transcode in the RAN. The point is just that vocoders specifically designed for wireless should be used over the wireless link. If the CH has such a vocoder that's great, but it's not clear that all wired hosts would support a wireless-specific vocoder. So transcoding has to take place somewhere (although admittedly not necessarily in the RAN gateway itself). GM> Although the draft very thoughtfully describes the current CDMA GM> systems and the requirements, it does not provide a proof that GM> end-to-end IP can't be done. So I don't think Jim Willkie's statement GM> "Hopefully this paper and any potential enusing discussions will quell GM> any effort to use mobileIP for soft handoff on CDMA networks...." has GM> any basis. What is missing is some real measurements on the delays GM> involved in controlling a device which can replicate packets for GM> transmission over tunnels to several base stations and implementation GM> and measurement of a base station which does IP directly over RLP. The draft points out that "replication" is done at the level of radio frames, not IP packets. The draft does not argue for or against end-to-end voice-over-IP, but it does point out that BTSs are not the individual, IP-addressable entities visible from MNs that some people have assumed them to be. Even if the RAN network is IP-based and the BTSs have IP addresses, the MNs do not see them as their IP point of attachment. That point is farther back in the network, at the RAN gateway. If you want to combine such a gateway with a BTS it will have negative performance implications because you will lose macrodiversity. GM> Christian Olrog showed in April 1999, in his M.S. thesis "Direct Radio GM> Link Protocol Interface", that GSM's RLP processing could be done on a GM> PC running Linux -- rather than requiring a real-time OS. Prior to his GM> implementation and measurements everyone thought this couldn't be done. GM> What is the chance that we will see the same thing happen with regard GM> to end-to-end IP? What you are saying is that a RAN gateway could be implemented on a Linux box. (I would question whether such a gateway would have nice scaling properties as you increased the system load, btw). That's great but doesn't really say anything about where architecturally the RAN gateway (frame selector) should be placed. All we are saying is that you can't see the MN's IP packets before that point. -Pete From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 4 12:03:59 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09604 for ; Thu, 4 May 2000 12:03:57 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B6E5AEB0@standards.nortelnetworks.com>; Thu, 4 May 2000 11:56:00 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37005 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 4 May 2000 11:55:21 -0400 Received: from crufty.research.bell-labs.com (204.178.16.49) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9FCA75D0@standards.nortelnetworks.com>; Thu, 4 May 2000 11:55:21 -0400 Received: from grubby.research.bell-labs.com ([135.104.2.9]) by crufty; Thu May 4 12:00:07 EDT 2000 Received: from king.research.bell-labs.com ([135.1.152.1]) by grubby; Thu May 4 12:00:07 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 98CF857042; Thu, 4 May 2000 11:00:06 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <200005021424.HAA24772@nasnfs.eng.sun.com> X-Mailer: VM 6.33 under Emacs 19.34.2 Message-ID: <20000504160006.98CF857042@king.research.bell-labs.com> Date: Thu, 4 May 2000 11:00:06 -0500 Reply-To: Pete McCann Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Pete McCann Subject: [MOBILE-IP] IPv6 Mobility Last Call Question X-To: James Kempf To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200005021424.HAA24772@nasnfs.eng.sun.com> Content-Transfer-Encoding: 7bit James, I've been thinking about this issue for some time. I think there are good reasons for creating an IPv6 FA, although I'm not sure the current IPv6 draft is the right place to do it. I am not saying that an IPv6 FA would serve as a tunnel endpoint, but there is definitely a need for some sort of "attendant" function and I think integrating that attendant with Mobile IP has advantages. Note that the existing IPv6 already requires some sort of entity sitting on the visited network to serve as a recipient of Binding Updates when handoff takes place. There is a need to develop a security association with that entity at the time the MN first registers. Even if you believe that a PKI will exist I think there are good reasons to involve a AAA infrastructure in the development of such an association. Such an entity would actually facilitate the kind of "ISP open access" that Fred described, rather than hindering it. It could make sure that all traffic from a given user was tunneled back to a home network, by integrating the Mobile IP registration process with some kind of firewall features. Mobile IP then would become the universal "dial-tone" for Internet access. This scenario requires that registration requests be sent to an FA rather than directly to an HA, which is in conflict with the current definition of MIPv6. Remember, in MIPv4, we can set the "R" bit to require FA-routed registration even when using a co-located COA. Maybe some kind of registration forwarding can be added to MIPv6. -Pete James Kempf (JK) writes: JK> Some of the options for fast handover we've been discussing JK> recently may call for an FA-like entity in IPv6. I've heard this JK> variously referred to as an "attendent". Is the IPv6 mobility JK> draft last call the right time to bring up this issue, or should JK> it perhaps wait for a separate discussion and a separate draft? JK> jak From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 4 12:04:01 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09614 for ; Thu, 4 May 2000 12:03:59 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B7096350@standards.nortelnetworks.com>; Thu, 4 May 2000 11:56:00 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37008 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 4 May 2000 11:55:33 -0400 Received: from clea.qualcomm.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A6C1E850@standards.nortelnetworks.com>; Thu, 4 May 2000 11:55:33 -0400 Received: from jwillkie1 (jwillkie1.qualcomm.com [129.46.219.171]) by clea.qualcomm.com (8.9.3/8.9.3/1.0) with SMTP id JAA23494; Thu, 4 May 2000 09:02:10 -0700 (PDT) X-Sender: jwillkie@mail1.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 References: <200005031516.IAA06215@nasnfs.eng.sun.com> <200005031516.IAA06215@nasnfs.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <4.1.20000504083713.00d6f670@mail1.qualcomm.com> Date: Thu, 4 May 2000 09:01:59 -0700 Reply-To: Jim Willkie Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Jim Willkie Subject: Re: [MOBILE-IP] Applicability of IP Mobility to CDMA Soft Handoff X-To: Gerald Maguire To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200005041457.QAA08179@dumburken.it.kth.se> At 04:57 PM 5/4/00 +0200, Gerald Maguire wrote: --cut-- >You also state: > " ... In addition, even if IP is > used for transport in the RAN, if voice over IP is to completely > replace the current radio voice protocols, voice packets may need to > be processed at the RAN gateway for maximum efficiency and robustness > over the radio medium." > >Why add this processing (and hence additional delay) in the RAN >gateway, when the voice encoding/decoding can simply be done at the >mobile? Any necessary robustness can be provided by end points and >thus you avoid any possible need to transcode in the RAN. The catch here is the 'necessary robustness'. One can accurately claim that the current CDMA air-interface has done all this 'necessary robustness' and has done it best. So the premise of Gerald's claim holds but the work is already done and optimal. >Although the draft very thoughtfully describes the current CDMA >systems and the requirements, it does not provide a proof that >end-to-end IP can't be done. So I don't think Jim Willkie's statement >"Hopefully this paper and any potential enusing discussions will quell >any effort to use mobileIP for soft handoff on CDMA networks...." has >any basis. What is missing is some real measurements on the delays >involved in controlling a device which can replicate packets for >transmission over tunnels to several base stations and implementation >and measurement of a base station which does IP directly over RLP. I suppose the actual proof is missing. One could derive the proof. I think the key factors would be 1) some reasonably accurate CPU-load processing factors for a typical mobile phone/data device, 2) model the more extensive IP layer processing needed, including the 'price' paid for IP header overhead. I would guess that we are 3 or 4 Moore's Law generations away, perhaps more. >Christian Olrog showed in April 1999, in his M.S. thesis "Direct Radio >Link Protocol Interface", that GSM's RLP processing could be done on a >PC running Linux -- rather than requiring a real-time OS. Prior to his >implementation and measurements everyone thought this couldn't be done. >What is the chance that we will see the same thing happen with regard >to end-to-end IP? Please note that a PC running Linux is still running with a CPU clock rate of 300 to 400 Mhz. Typical mobile phone/device CPU clock rates are 10 to 20 Mhz. The cost of the CPU and the accompanying memory are orders of magnitude different. At some point processing power will grow to the point where some of the arguments against mobileIP-for-softhandoff will disappear. There will still be the issue of "why do something that is already in place?". There would have to be a compelling reason at that point in time. For the near future it is a solution looking for a problem. Jim Willkie From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 4 12:29:45 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10251 for ; Thu, 4 May 2000 12:29:44 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5F8009A0@standards.nortelnetworks.com>; Thu, 4 May 2000 12:22:11 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37144 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 4 May 2000 12:20:54 -0400 Received: from eagle.aud.alcatel.com (128.251.96.217) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CBFA0920@standards.nortelnetworks.com>; Thu, 4 May 2000 12:10:54 -0400 Received: from usa.alcatel.com by eagle.aud.alcatel.com (8.8.8+Sun/SMI-SVR4) id LAA05450; Thu, 4 May 2000 11:17:21 -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: <3911A21E.38AC95CA@usa.alcatel.com> Date: Thu, 4 May 2000 11:15:27 -0500 Reply-To: Vincent Magret Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Vincent Magret Subject: [MOBILE-IP] Some comments on draft-kempf-cdma-appl-00.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello, In the section 4 you state: "Taking mobile IP as an example, using mobile IP in the RAN would require that a mobile IP foreign agent (FA) be present at each base station", I think this argument is little bit too extreme, in the sense that the closet you locate the FA to the mobile node, the less efficient will be the protocol. Further more with the macro diversity scheme defined in CDMA the concept can not be applied. At least it would gave a better impact if the draft used the case of locating the FA in the RNC would be discussed. My feeling is the argumentation tend to take the case that makes the use of Mobile IP obviously not suitable. My understanding of macro diversity (and I'm not a radio expert) is that the splitting realized at the RNC is made so that the information conveyed via a base station is slightly different to the one sent to another base station. As you said the mobile node needs to compute some sophisticated mathematics to get the original information sent. Best regards, Vincent. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 4 12:45:51 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10860 for ; Thu, 4 May 2000 12:45:51 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A0281770@standards.nortelnetworks.com>; Thu, 4 May 2000 12:38:18 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37251 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 4 May 2000 12:37:26 -0400 Received: from ish7.ericsson.com.au (203.61.155.111) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8019C320@standards.nortelnetworks.com>; Thu, 4 May 2000 12:37:25 -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 CAA24328 for ; Fri, 5 May 2000 02:43:33 +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 CAA18619 for ; Fri, 5 May 2000 02:43:55 +1000 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2448.0) id ; Fri, 5 May 2000 02:43:33 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFB5E7.E295167C" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A5089EAFF2@eaubrnt018.epa.ericsson.se> Date: Fri, 5 May 2000 02:43: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 Mobility Last Call Question 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_01BFB5E7.E295167C Content-Type: text/plain Pete > I've been thinking about this issue for some time. I think there > are good reasons for creating an IPv6 FA, although I'm not sure > the current IPv6 draft is the right place to do it. > I think something is needed but I don't agree with calling it "FA", simply because we don't need to have the same functions that FA's do in MIPv4 transferred to MIPv6. > I am not saying that an IPv6 FA would serve as a tunnel endpoint, > but there is definitely a need for some sort of "attendant" function > and I think integrating that attendant with Mobile IP has advantages. > Note that the existing IPv6 already requires some sort of entity > sitting on the visited network to serve as a recipient of Binding > Updates when handoff takes place. There is a need to develop a > security association with that entity at the time the MN first > registers. Even if you believe that a PKI will exist I think > there are good reasons to involve a AAA infrastructure in the > development of such an association. > Yes I agree in part. AAA is obviously required by operators to have access control and billing. The interworking between AAA and mobility is useful and necessary in a handoff situation. However, that doesn't mean AAA as a function should be part of the mobility management. I think the direction access control has taken in IPv6 is excellent as it addresses access control as a separate function. Not to say that it doesn't need to interwork with mobility, but that doesn't make them one function. > Such an entity would actually facilitate the kind of "ISP open access" > that Fred described, rather than hindering it. Yes > It could make sure that all traffic from a given user was tunneled back to > a home > network, by integrating the Mobile IP registration process with some > kind of firewall features. Why would you want your traffic to be tunnelled back ? > Mobile IP then would become the universal > "dial-tone" for Internet access. This scenario requires that > registration requests be sent to an FA rather than directly to an HA, > which is in conflict with the current definition of MIPv6. Again, even if you have an FA-like function in your network why does that stop you from having two separate registrations, one for your HA and one for your "new function". > Remember, in MIPv4, we can set the "R" bit to require FA-routed > registration even when using a co-located COA. Maybe some kind > of registration forwarding can be added to MIPv6. I don't see why that would be needed in IPv6 Hesham > James Kempf (JK) writes: > > JK> Some of the options for fast handover we've been discussing > JK> recently may call for an FA-like entity in IPv6. I've heard this > JK> variously referred to as an "attendent". Is the IPv6 mobility > JK> draft last call the right time to bring up this issue, or should > JK> it perhaps wait for a separate discussion and a separate draft? > > JK> jak ------_=_NextPart_001_01BFB5E7.E295167C Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] IPv6 Mobility Last Call Question

Pete


    I've been thinking about this issue = for some time.  I think there
    are good reasons for creating an IPv6 = FA, although I'm not sure
    the current IPv6 draft is the right = place to do it.

    I think something is = needed but I don't agree with calling it "FA", simply because = we don't need to have the same functions that FA's do in MIPv4 = transferred to MIPv6.

    I am not saying that an IPv6 FA would = serve as a tunnel endpoint,
    but there is definitely a need for = some sort of "attendant" function
    and I think integrating that = attendant with Mobile IP has advantages.
    Note that the existing IPv6 already = requires some sort of entity
    sitting on the visited network to = serve as a recipient of Binding
    Updates when handoff takes = place.  There is a need to develop a
    security association with that entity = at the time the MN first
    registers.  Even if you believe = that a PKI will exist I think
    there are good reasons to involve a = AAA infrastructure in the
    development of such an = association.

    Yes I agree in part. = AAA is obviously required by operators to have access control and = billing.
    The interworking = between AAA and mobility is useful and necessary in a handoff = situation.
    However, that = doesn't mean AAA as a function should be part of the mobility = management.
    I think the = direction access control has taken in IPv6 is excellent as it addresses = access control as a separate function. Not to say that it doesn't need = to interwork with mobility, but that doesn't make them one = function.

    Such an entity would actually = facilitate the kind of "ISP open access"
    that Fred described, rather than = hindering it. =20
    Yes

    It could make sure that all traffic from a given user was tunneled back to = a home
    network, by integrating the Mobile IP = registration process with some
    kind of firewall = features. =20
    Why would you want = your traffic to be tunnelled back ?


    Mobile IP then would become the = universal
    "dial-tone" for Internet = access.  This scenario requires that
    registration requests be sent to an = FA rather than directly to an HA,
    which is in conflict with the current = definition of MIPv6.
    Again, even if you = have an FA-like function in your network why does that stop you from = having two separate registrations, one for your HA and one for your = "new function".

    Remember, in MIPv4, we can set the = "R" bit to require FA-routed
    registration even when using a = co-located COA.  Maybe some kind
    of registration forwarding can be = added to MIPv6.
    I don't see why = that would be needed in IPv6


    Hesham


    James Kempf = <James.Kempf@ENG.SUN.COM> (JK) writes:

    JK> Some of the options for fast = handover we've been discussing
    JK> recently may call for an = FA-like entity in IPv6. I've heard this
    JK> variously referred to as an = "attendent". Is the IPv6 mobility
    JK> draft last call the right time = to bring up this issue, or should
    JK> it perhaps wait for a separate = discussion and a separate draft?

    JK>        &nb= sp;        jak

------_=_NextPart_001_01BFB5E7.E295167C-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 4 12:59:40 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11159 for ; Thu, 4 May 2000 12:59:39 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.97194BC0@standards.nortelnetworks.com>; Thu, 4 May 2000 12:52:22 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37306 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 4 May 2000 12:51:21 -0400 Received: from crufty.research.bell-labs.com (204.178.16.49) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.726EB300@standards.nortelnetworks.com>; Thu, 4 May 2000 12:51:21 -0400 Received: from grubby.research.bell-labs.com ([135.104.2.9]) by crufty; Thu May 4 12:56:28 EDT 2000 Received: from king.research.bell-labs.com ([135.1.152.1]) by grubby; Thu May 4 12:56: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 0C19157042; Thu, 4 May 2000 11:56:26 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <3911A21E.38AC95CA@usa.alcatel.com> X-Mailer: VM 6.33 under Emacs 19.34.2 Message-ID: <20000504165627.0C19157042@king.research.bell-labs.com> Date: Thu, 4 May 2000 11:56:27 -0500 Reply-To: Pete McCann Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Pete McCann Subject: [MOBILE-IP] Some comments on draft-kempf-cdma-appl-00.txt X-To: Vincent Magret To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <3911A21E.38AC95CA@usa.alcatel.com> Content-Transfer-Encoding: 7bit Vincent Magret (VM) writes: VM> Hello, VM> In the section 4 you state: "Taking mobile IP as an example, using VM> mobile IP in the RAN would require that a mobile IP foreign agent (FA) VM> be present at each base station", I think this argument is little bit VM> too extreme, in the sense that the closet you locate the FA to the VM> mobile node, the less efficient will be the protocol. Further more with VM> the macro diversity scheme defined in CDMA the concept can not be VM> applied. At least it would gave a better impact if the draft used the VM> case of locating the FA in the RNC would be discussed. My feeling is the VM> argumentation tend to take the case that makes the use of Mobile IP VM> obviously not suitable. You are correct - the proper location for a Mobile IP FA is at the RNC or behind it, NOT at every BTS. That is what the draft tries to argue. VM> My understanding of macro diversity (and I'm not a radio expert) is that VM> the splitting realized at the RNC is made so that the information VM> conveyed via a base station is slightly different to the one sent to VM> another base station. As you said the mobile node needs to compute some VM> sophisticated mathematics to get the original information sent. I think the frames sent to each BTS are identical, and this is necessary to achieve the proper effect when the multiple signals are received by the MN. However, they are sent with unequal power which is an aspect not covered by the draft - RNCs typically perform very tight-loop power control on the signals sent by each BTS. This is another aspect that would be difficult to recapture with end-to-end IP signaling. -Pete From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 4 13:15:46 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11882 for ; Thu, 4 May 2000 13:15:46 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D6D54BE0@standards.nortelnetworks.com>; Thu, 4 May 2000 13:08:28 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37348 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 4 May 2000 13:06:29 -0400 Received: from sirius.ctr.columbia.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.29D69A80@standards.nortelnetworks.com>; Thu, 4 May 2000 12:56:28 -0400 Received: from comet.columbia.edu (locke.comet.columbia.edu [128.59.68.81]) by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with ESMTP id NAA04092 for ; Thu, 4 May 2000 13:03:10 -0400 (EDT) X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 References: <200005031516.IAA06215@nasnfs.eng.sun.com> <200005041457.QAA08179@dumburken.it.kth.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3911BC15.A5530649@comet.columbia.edu> Date: Thu, 4 May 2000 13:06:13 -0500 Reply-To: Andras Veres Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Andras Veres Subject: Re: [MOBILE-IP] Applicability of IP Mobility to CDMA Soft Handoff To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit All, I think that draft-kempf-cdma-appl-00.txt assumes a scenario where all components of a WCMDA network remain the same, only the networking layer would be replaced by IP. If this is the case, I am not surprised at all that we run into serious problems. The reason is that WCDMA was designed based on the circuit switched model and it follows the principle of ** total control for maximum efficiency (TM) **. I think that one thing we can learn from IP is that by eliminating total control, of course we loose in performance, but we gain a lot in simplicity and scalability. (And who knows, this loss may be negligible - just think of the great performance of IEEE 802.11) I know that radio channels call for more control than usual IP networks (e.g., Ethernet), but I do beleive that the current WCDMA and 3G concepts are fundamentally problematic and not scalable -- requiring terrible protocol stacks (IP over ATM over UDP over IP over Whatever over AAL2 over ..... :-), leading to such monsters like RNC. James: Do you think that IP is still a non-feasible solution, if we consider that even the curcuit switched model may be redesigned based on IP principles? Regards, Andras -- Andras Veres http://comet.ctr.columbia.edu/~veres Columbia University Dept. of Electrical Engineering mc 4712 500 West 120th Street, H1 New York, NY 10027 Office phone: (212) 854-3117 Office fax: (212) 932-9421 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 4 13:20:02 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11985 for ; Thu, 4 May 2000 13:20:02 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.67CFDC00@standards.nortelnetworks.com>; Thu, 4 May 2000 13:12:31 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37421 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 4 May 2000 13:11:11 -0400 Received: from prserv.net (32.97.166.35) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.37969560@standards.nortelnetworks.com>; Thu, 4 May 2000 13:11:11 -0400 Received: from [32.101.171.202] ([32.101.171.202]) by prserv.net (out5) with ESMTP id <2000050417172524302fb4rfe>; Thu, 4 May 2000 17:17:26 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: ahmrphd@pop3.attglobal.net References: <200005031516.IAA06215@nasnfs.eng.sun.com> <200005041457.QAA08179@dumburken.it.kth.se> Message-ID: Date: Thu, 4 May 2000 10:18:30 -0700 Reply-To: Arthur Ross Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Arthur Ross Subject: Re: [MOBILE-IP] Applicability of IP Mobility to CDMA Soft Handoff X-To: Andras Veres To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <3911BC15.A5530649@comet.columbia.edu> At 11:06 -0700 05/04/2000, Andras Veres wrote: >I know that radio channels call for more control than usual IP >networks (e.g., Ethernet), but I do beleive that the current >WCDMA and 3G concepts are fundamentally problematic and not >scalable -- requiring terrible protocol stacks (IP over ATM >over UDP over IP over Whatever over AAL2 over ..... :-), >leading to such monsters like RNC. > AMEN! -- A From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 4 13:23:32 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12068 for ; Thu, 4 May 2000 13:23:32 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D47CE780@standards.nortelnetworks.com>; Thu, 4 May 2000 13:15:34 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37451 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 4 May 2000 13:14:33 -0400 Received: from sirius.ctr.columbia.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B0048250@standards.nortelnetworks.com>; Thu, 4 May 2000 13:14:33 -0400 Received: from comet.columbia.edu (locke.comet.columbia.edu [128.59.68.81]) by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with ESMTP id NAA04766; Thu, 4 May 2000 13:21:12 -0400 (EDT) X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 References: <3911A21E.38AC95CA@usa.alcatel.com> <20000504165627.0C19157042@king.research.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3911C04F.775DA3EA@comet.columbia.edu> Date: Thu, 4 May 2000 13:24:15 -0500 Reply-To: Andras Veres Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Andras Veres Subject: Re: [MOBILE-IP] Some comments on draft-kempf-cdma-appl-00.txt X-To: Pete McCann To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Pete, > I think the frames sent to each BTS are identical, and this is > necessary to achieve the proper effect when the multiple signals are > received by the MN. However, they are sent with unequal power which > is an aspect not covered by the draft - RNCs typically perform very > tight-loop power control on the signals sent by each BTS. This is > another aspect that would be difficult to recapture with end-to-end > IP signaling. What do you mean by 'end-to-end'? It is a message between the control unit (typically in the RNC) and the BTS or MH. In this respect it IS e2e, as it involves two (possibly IP layer) nodes. Andras -- Andras Veres http://comet.ctr.columbia.edu/~veres Columbia University Dept. of Electrical Engineering mc 4712 500 West 120th Street, H1 New York, NY 10027 Office phone: (212) 854-3117 Office fax: (212) 932-9421 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 4 13:27:08 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12192 for ; Thu, 4 May 2000 13:27:08 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1D28B9A0@standards.nortelnetworks.com>; Thu, 4 May 2000 13:17:36 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37480 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 4 May 2000 13:16:04 -0400 Received: from dumburken.it.kth.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E66F5360@standards.nortelnetworks.com>; Thu, 4 May 2000 13:16:04 -0400 Received: (from maguire@localhost) by dumburken.it.kth.se (8.9.3/8.9.3) id TAA08456; Thu, 4 May 2000 19:22:42 +0200 (MET DST) X-Authentication-Warning: dumburken.it.kth.se: maguire set sender to maguire@dumburken.it.kth.se using -f References: <3911A21E.38AC95CA@usa.alcatel.com> <20000504165627.0C19157042@king.research.bell-labs.com> Message-ID: <200005041722.TAA08456@dumburken.it.kth.se> Date: Thu, 4 May 2000 19:22:42 +0200 Reply-To: Gerald Maguire Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gerald Maguire Subject: Re: [MOBILE-IP] Some comments on draft-kempf-cdma-appl-00.txt X-To: mccap@RESEARCH.BELL-LABS.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <20000504165627.0C19157042@king.research.bell-labs.com> (message from Pete McCann on Thu, 4 May 2000 11:56:27 -0500) VM> My understanding of macro diversity (and I'm not a radio expert) is that VM> the splitting realized at the RNC is made so that the information VM> conveyed via a base station is slightly different to the one sent to VM> another base station. As you said the mobile node needs to compute some VM> sophisticated mathematics to get the original information sent. I think the frames sent to each BTS are identical, and this is necessary to achieve the proper effect when the multiple signals are received by the MN. However, they are sent with unequal power which is an aspect not covered by the draft - RNCs typically perform very tight-loop power control on the signals sent by each BTS. This is another aspect that would be difficult to recapture with end-to-end IP signaling. Power control is a link layer issue -- not an IP layer issue. Although at one point some students here looked at doing the power control via SNMP packets running over IP. I believe that there was a doctoral dissertation under Prof. Jens Zander which showed what the bandwidth necessary for doing the power control is -- however, I don't recall the details exactly. Note that the combining does not have to happen at any particular stage in the radio (i.e., you can do it at many different points -- ranging from the very front where it gets called "smart antennas" to longer after the chips have been converted into bits, but before the packet is passed up to the transport layer). Note that since you can't tell the difference between a reflection and a copy sent by another base station unless the copies set by basestations were different. But if they were different, then you would have to do the combining later in the processing. Hence they are idential to allow the combining at a very early stage. Chip From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 4 14:09:12 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13088 for ; Thu, 4 May 2000 14:09:12 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4BCAFDD0@standards.nortelnetworks.com>; Thu, 4 May 2000 14:01:51 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37671 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 4 May 2000 14:00:53 -0400 Received: from bells.cs.ucl.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.29177A20@standards.nortelnetworks.com>; Thu, 4 May 2000 14:00:53 -0400 Received: from ginger.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 4 May 2000 19:07:31 +0100 X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: el, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3911BC62.FC1CC433@cs.ucl.ac.uk> Date: Thu, 4 May 2000 19:07:30 +0100 Reply-To: t.pagtzis@cs.ucl.ac.uk Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Theo PAGTZIS Organization: UCL Subject: [MOBILE-IP] intra-RAN diversity with dynamic anycasting... To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit It strikes me that we should not be talking about macrodiversity but microdiversity since the terms really refers to intra-RAN movement, not inter-RAN one. I cannot see how you intend to effect power control on the MN since you have no control over the mobility pattern of the MN. For instance lower power on the MN may be effected if the MN is relatively close to the BS and the air interface is relatively quiet. I would probably opt for the word 'compliance' to power transmission requirements based on (distance,velocity,height,direction) vector. The degree of compliance to power control on the BS should be affected in some non-linear way by that vector. When you try to eliminate cell dragging (inter or intra-RAN) isn't there a limit to how many cells a CDMA node can be in contact with? How do you decide which BS will participate on the simulcasting of the radio frames and thus will receive the attention of the RAN gateway. Is the participation dynamic per-RAN or is it fixed (you mentioned point to point links). If it is fixed don't you introduce a point of failure for the BS in case the RAN gateway gets down...? There may not be a one to one mapping but I gather that you would like the one (MN) to many (BS) down to a minimum....otherwise you flood your link towards the RAN gateway... Theo From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 4 14:15:11 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13230 for ; Thu, 4 May 2000 14:15:10 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.24096BA0@standards.nortelnetworks.com>; Thu, 4 May 2000 14:07:54 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37706 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 4 May 2000 14:06:51 -0400 Received: from mail.hrn.ascend.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FE72C530@standards.nortelnetworks.com>; Thu, 4 May 2000 14:06:51 -0400 Received: from awalker2 (amanda-pad.eng.hrn.ascend.com [149.52.12.188]) by mail.hrn.ascend.com (8.9.3/8.9.3) with ESMTP id OAA27194 for ; Thu, 4 May 2000 14:13:28 -0400 (EDT) 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.2919.6700 Importance: Normal Message-ID: Date: Thu, 4 May 2000 14:13:28 -0400 Reply-To: Amanda Walker Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Amanda Walker Subject: Re: [MOBILE-IP] Applicability of IP Mobility to CDMA Soft Handoff To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <3911BC15.A5530649@comet.columbia.edu> Content-Transfer-Encoding: 7bit > James: Do you think that IP is still a non-feasible solution, > if we consider that even the curcuit switched model may be > redesigned based on IP principles? I think that there are two separate threads of discussion here, and that they are sometimes hard to tell apart: 1) Can we build networks that support mobile IP services from the "ground up"? I think this answer is "certainly." CIP and HAWAII are great examples, various people have built proof-of-concept demos of things like VOIP over 802.11, and so on. However, at least so far, these are all experimental--in some cases very robust, but they run in labs, not in airports and cars. Nonetheless, they do show that it is both possible and often advantageous to have as lightweight a link layer as possible and have a single place for mobility decisions and policy to be implemented. 2) Can we overlay mobile IP services on top of existing networks? I think that this answer is also "certainly," but it's very much a different problem. Many networks support their own mobility features specifically because at the time they were designed and deployed, there was no other choice. Even 802.11, for example, jumps through hoops (smaller hoops than CDMA, to be sure, but hoops nonetheless) to give the illusion of an Ethernet-like link, so that existing IP implementations can gain at least limited mobility. draft-kempf-cdma-appl-00 addresses question (2). The same argument can be applied to any existing network where discarding it and building a new one from scratch is not an option. Where the existing network handles mobility, the most useful place to pick things up with MIP (e.g., a non-colocated FA) is where that existing mechanism stops. draft-kempf-cdma-appl-00 does not address question (1) at all. Now, there's a third, often implicit, third question which is: 3) Which approach is better? This is unanswerable in any absolute sense. Operators and suppliers for existing networks will tend to ask question (2), while innovators entering the market will ask question (1). It's a lot easier to build from scratch if you don't already have a working network to have to throw away or write off (and existing customers to lose while you do so). On the other hand, not keeping up with innovation will eventually render older systems irrelevant anyway. It's a classic dilemma. Speaking personally, I don't think we're going to solve it here. MIP needs to be usable as both a building block *and* an overlay. There's a lot of useful experience represented here on both sides of this issue (and some additional perspectives as well). I'm much more interested in what everyone has done and how it succeeds and fails, than in speculating about how things should have been done differently in existing systems. Amanda Walker Lucent Technologies InterNetworking Systems From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 4 14:24:16 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13389 for ; Thu, 4 May 2000 14:24:16 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.67B31620@standards.nortelnetworks.com>; Thu, 4 May 2000 14:16:57 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37743 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 4 May 2000 14:15:21 -0400 Received: from crufty.research.bell-labs.com (204.178.16.49) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2E9273E0@standards.nortelnetworks.com>; Thu, 4 May 2000 14:15:21 -0400 Received: from grubby.research.bell-labs.com ([135.104.2.9]) by crufty; Thu May 4 14:20:30 EDT 2000 Received: from king.research.bell-labs.com ([135.1.152.1]) by grubby; Thu May 4 14:20:30 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 43DDD57042; Thu, 4 May 2000 13:20:29 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <3911A21E.38AC95CA@usa.alcatel.com> <20000504165627.0C19157042@king.research.bell-labs.com> <3911C04F.775DA3EA@comet.columbia.edu> X-Mailer: VM 6.33 under Emacs 19.34.2 Message-ID: <20000504182029.43DDD57042@king.research.bell-labs.com> Date: Thu, 4 May 2000 13:20:29 -0500 Reply-To: Pete McCann Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Pete McCann Subject: Re: [MOBILE-IP] Some comments on draft-kempf-cdma-appl-00.txt X-To: Andras Veres To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <3911C04F.775DA3EA@comet.columbia.edu> Content-Transfer-Encoding: 7bit Andras Veres (AV) writes: AV> Pete, >> I think the frames sent to each BTS are identical, and this is >> necessary to achieve the proper effect when the multiple signals are >> received by the MN. However, they are sent with unequal power which >> is an aspect not covered by the draft - RNCs typically perform very >> tight-loop power control on the signals sent by each BTS. This is >> another aspect that would be difficult to recapture with end-to-end >> IP signaling. AV> What do you mean by 'end-to-end'? It is a message between the AV> control unit (typically in the RNC) and the BTS or MH. In this AV> respect it IS e2e, as it involves two (possibly IP layer) nodes. What I meant by "end-to-end" was an IP stack on an MT communicating with another IP stack somewhere in the network to convey power control information. As Chip correctly pointed out, power control is a link layer issue, not an IP layer issue. We should not use end-to-end IP packets to do power control. -Pete From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 4 14:35:25 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13576 for ; Thu, 4 May 2000 14:35:24 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F44D8B00@standards.nortelnetworks.com>; Thu, 4 May 2000 14:28:02 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37810 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 4 May 2000 14:26:36 -0400 Received: from sirius.ctr.columbia.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C0EE7350@standards.nortelnetworks.com>; Thu, 4 May 2000 14:26:36 -0400 Received: from comet.columbia.edu (sweetpea.comet.columbia.edu [128.59.68.61]) by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with ESMTP id OAA08029; Thu, 4 May 2000 14:33:15 -0400 (EDT) X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3911F000.AB7BBD08@comet.columbia.edu> Date: Thu, 4 May 2000 14:47:44 -0700 Reply-To: campbell@comet.columbia.edu Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Andrew T. Campbell" Organization: Center for Telecommunications Research Subject: Re: [MOBILE-IP] Applicability of IP Mobility to CDMA Soft Handoff X-To: Amanda Walker To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit That is an excellent summary. Amanda Walker wrote: > > > James: Do you think that IP is still a non-feasible solution, > > if we consider that even the curcuit switched model may be > > redesigned based on IP principles? > > I think that there are two separate threads of discussion here, and that > they are sometimes hard to tell apart: > > 1) Can we build networks that support mobile IP services from the "ground > up"? I think this answer is "certainly." CIP and HAWAII are great > examples, various people have built proof-of-concept demos of things like > VOIP over 802.11, and so on. However, at least so far, these are all > experimental--in some cases very robust, but they run in labs, not in > airports and cars. Nonetheless, they do show that it is both possible and > often advantageous to have as lightweight a link layer as possible and have > a single place for mobility decisions and policy to be implemented. > > 2) Can we overlay mobile IP services on top of existing networks? I think > that this answer is also "certainly," but it's very much a different > problem. Many networks support their own mobility features specifically > because at the time they were designed and deployed, there was no other > choice. Even 802.11, for example, jumps through hoops (smaller hoops than > CDMA, to be sure, but hoops nonetheless) to give the illusion of an > Ethernet-like link, so that existing IP implementations can gain at least > limited mobility. > > draft-kempf-cdma-appl-00 addresses question (2). The same argument can be > applied to any existing network where discarding it and building a new one > from scratch is not an option. Where the existing network handles mobility, > the most useful place to pick things up with MIP (e.g., a non-colocated FA) > is where that existing mechanism stops. > > draft-kempf-cdma-appl-00 does not address question (1) at all. > > Now, there's a third, often implicit, third question which is: > > 3) Which approach is better? > > This is unanswerable in any absolute sense. Operators and suppliers for > existing networks will tend to ask question (2), while innovators entering > the market will ask question (1). It's a lot easier to build from scratch > if you don't already have a working network to have to throw away or write > off (and existing customers to lose while you do so). On the other hand, > not keeping up with innovation will eventually render older systems > irrelevant anyway. > > It's a classic dilemma. > > Speaking personally, I don't think we're going to solve it here. MIP needs > to be usable as both a building block *and* an overlay. There's a lot of > useful experience represented here on both sides of this issue (and some > additional perspectives as well). I'm much more interested in what everyone > has done and how it succeeds and fails, than in speculating about how things > should have been done differently in existing systems. > > Amanda Walker > Lucent Technologies InterNetworking Systems From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 4 15:01:29 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14182 for ; Thu, 4 May 2000 15:01:28 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9D2ABB50@standards.nortelnetworks.com>; Thu, 4 May 2000 14:54:14 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37908 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 4 May 2000 14:52:39 -0400 Received: from locke (128.59.68.81) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FE9DDA90@standards.nortelnetworks.com>; Thu, 4 May 2000 14:42:38 -0400 Received: from comet.columbia.edu (IDENT:root@localhost.localdomain [127.0.0.1]) by locke (8.9.3/8.9.3) with ESMTP id OAA01284; Thu, 4 May 2000 14:52:23 +0200 X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 References: <3911A21E.38AC95CA@usa.alcatel.com> <20000504165627.0C19157042@king.research.bell-labs.com> <3911C04F.775DA3EA@comet.columbia.edu> <20000504182029.43DDD57042@king.research.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39117286.65CCA12B@comet.columbia.edu> Date: Thu, 4 May 2000 14:52:22 +0200 Reply-To: veres Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: veres Subject: Re: [MOBILE-IP] Some comments on draft-kempf-cdma-appl-00.txt X-To: Pete McCann To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Pete, > AV> What do you mean by 'end-to-end'? It is a message between the > AV> control unit (typically in the RNC) and the BTS or MH. In this > AV> respect it IS e2e, as it involves two (possibly IP layer) nodes. > > What I meant by "end-to-end" was an IP stack on an MT communicating > with another IP stack somewhere in the network to convey power control > information. As Chip correctly pointed out, power control is a link > layer issue, not an IP layer issue. We should not use end-to-end > IP packets to do power control. > > -Pete If you consider the RAN to be L2, then it is a L2 issue. If, on the other hand, RAN is a L3 network, which means that there are several L3 routers between the BTS and the RNC, then signaling between the two nodes is to be done on L3. In my view the major problem with current RAN is that it tries to reinvent a networking layer on - what it calls - L2, i.e., L2/L1 radio frames are routed in the RAN network (consisting of hundreds of nodes!) - which requires fundamentally L3 funcions e.g., routing protocols. And do not forget, that on top of this we still need IP with its own solution for routing etc., even in the current WCDMA solutions, for all data and management traffic. Now, IF on top of this pile, we want to place MIP to interwork with all of this, well, where do we end up? Who will be able to manage it? I am not sure operators would be happy... Andras From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 4 15:07:29 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14307 for ; Thu, 4 May 2000 15:07:29 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.76638EB0@standards.nortelnetworks.com>; Thu, 4 May 2000 15:00:18 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 38009 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 4 May 2000 14:59:21 -0400 Received: from crufty.research.bell-labs.com (204.178.16.49) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.53BBF1E0@standards.nortelnetworks.com>; Thu, 4 May 2000 14:59:20 -0400 Received: from grubby.research.bell-labs.com ([135.104.2.9]) by crufty; Thu May 4 15:05:11 EDT 2000 Received: from king.research.bell-labs.com ([135.1.152.1]) by grubby; Thu May 4 15:05:10 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 DCD4957042; Thu, 4 May 2000 14:05:09 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <3911BC62.FC1CC433@cs.ucl.ac.uk> X-Mailer: VM 6.33 under Emacs 19.34.2 Message-ID: <20000504190509.DCD4957042@king.research.bell-labs.com> Date: Thu, 4 May 2000 14:05:09 -0500 Reply-To: Pete McCann Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Pete McCann Subject: [MOBILE-IP] intra-RAN diversity with dynamic anycasting... X-To: t.pagtzis@cs.ucl.ac.uk To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <3911BC62.FC1CC433@cs.ucl.ac.uk> Content-Transfer-Encoding: 7bit Hi, Theo, Theo PAGTZIS (TP) writes: TP> It strikes me that we should not be talking about macrodiversity but TP> microdiversity since the terms really refers to intra-RAN movement, not TP> inter-RAN one. I am not sure where the term "macrodiversity" comes from - I think it is a 3GPP term. Frame selection (what I usually call it) can occur both within and between RANs - sometimes BTSs from a neighboring RAN are "borrowed" and added to the active set of BTSs. TP> I cannot see how you intend to effect power control on the MN since you TP> have no control over the mobility pattern of the MN. For instance lower TP> power on the MN may be effected if the MN is relatively close to the BS TP> and the air interface is relatively quiet. I would probably opt for the TP> word 'compliance' to power transmission requirements based on TP> (distance,velocity,height,direction) vector. The degree of compliance to TP> power control on the BS should be affected in some non-linear way by TP> that vector. The RNC does not have direct knowledge of the position, velocity, and acceleration of the MN. What happens in existing systems are that the MN sends a signal to the RNC whenever the detected pilot level of some BTS in its candidate set exceeds a given threshold. Then the RNC has the option of adding that BTS to the active set. Power control is maintained by watching the error rates and adjusting the transmission power of each BTS to keep it within a predefined threshhold. The IP stack on the MN is unaware of any of this activity (and should remain so). TP> When you try to eliminate cell dragging (inter or intra-RAN) isn't there TP> a limit to how many cells a CDMA node can be in contact with? Yes, there is a limit, and it varies from system to system. TP> How do you decide which BS will participate on the simulcasting of the TP> radio frames and thus will receive the attention of the RAN gateway. Is TP> the participation dynamic per-RAN or is it fixed (you mentioned point to TP> point links). Participation of BTSs is done according to an algorithm like that given above. BTSs in an active set can sometimes belong to two different RANs. TP> If it is fixed don't you introduce a point of failure for TP> the BS in case the RAN gateway gets down...? The RAN gateway is in fact a single point of failure because it is the attachment point to the rest of the network. This is true of any of the equipment in an IP network between you and your first-hop gateway router, such as your modem, your telephone line, and the NAS box you are connecting to. TP> There may not be a one to one mapping but I gather that you would like TP> the one (MN) to many (BS) down to a minimum....otherwise you flood your TP> link towards the RAN gateway... Not quite sure what you mean here - you should add BTSs to the active set to achieve the desired level of reliability on the link. Adding too many would of course add to network utilization. -Pete From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 4 15:30:41 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14764 for ; Thu, 4 May 2000 15:30:41 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B1AEAAB0@standards.nortelnetworks.com>; Thu, 4 May 2000 15:23:26 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 38112 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 4 May 2000 15:21:47 -0400 Received: from sirius.ctr.columbia.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.76309070@standards.nortelnetworks.com>; Thu, 4 May 2000 15:21:46 -0400 Received: from comet.columbia.edu (locke.comet.columbia.edu [128.59.68.81]) by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with ESMTP id PAA10490; Thu, 4 May 2000 15:28:24 -0400 (EDT) X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3911DDFE.7916CE21@comet.columbia.edu> Date: Thu, 4 May 2000 15:30:54 -0500 Reply-To: Andras Veres Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Andras Veres Subject: Re: [MOBILE-IP] Applicability of IP Mobility to CDMA Soft Handoff X-To: Amanda Walker To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Amanda, Fully agree! I did not intend to bring WCDMA standardization to this forum :-) My message is that there is are fundamental limitations in TCP/IP which would inhibit its use in WCDMA networks. And maybe we'll have it once - thanks to those "innovators" you mentioned. (Hey, aren;t we supposed to be the innovators here?) :-) Andras > Speaking personally, I don't think we're going to solve it here. MIP needs > to be usable as both a building block *and* an overlay. There's a lot of > useful experience represented here on both sides of this issue (and some > additional perspectives as well). I'm much more interested in what everyone > has done and how it succeeds and fails, than in speculating about how things > should have been done differently in existing systems. > > Amanda Walker > Lucent Technologies InterNetworking Systems -- Andras Veres http://comet.ctr.columbia.edu/~veres Columbia University Dept. of Electrical Engineering mc 4712 500 West 120th Street, H1 New York, NY 10027 Office phone: (212) 854-3117 Office fax: (212) 932-9421 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 4 15:34:36 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14915 for ; Thu, 4 May 2000 15:34:36 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.428A6830@standards.nortelnetworks.com>; Thu, 4 May 2000 15:27:29 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 38149 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 4 May 2000 15:27:21 -0400 Received: from sirius.ctr.columbia.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3D31D8A0@standards.nortelnetworks.com>; Thu, 4 May 2000 15:27:20 -0400 Received: from comet.columbia.edu (locke.comet.columbia.edu [128.59.68.81]) by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with ESMTP id PAA10826 for ; Thu, 4 May 2000 15:34:02 -0400 (EDT) X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 References: <3911DDFE.7916CE21@comet.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3911DF50.54A1E50D@comet.columbia.edu> Date: Thu, 4 May 2000 15:36:32 -0500 Reply-To: Andras Veres Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Andras Veres Subject: Re: [MOBILE-IP] Applicability of IP Mobility to CDMA Soft Handoff To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Oppps! I mean there are NO fundamental limitations! Andras > Amanda, > > Fully agree! I did not intend to bring WCDMA standardization to this > forum :-) > My message is that there is are fundamental limitations in TCP/IP which > would > inhibit its use in WCDMA networks. And maybe we'll have it once - thanks > to those "innovators" you mentioned. > (Hey, aren;t we supposed to be the innovators here?) > > :-) > Andras > > > Speaking personally, I don't think we're going to solve it here. MIP needs > > to be usable as both a building block *and* an overlay. There's a lot of > > useful experience represented here on both sides of this issue (and some > > additional perspectives as well). I'm much more interested in what everyone > > has done and how it succeeds and fails, than in speculating about how things > > should have been done differently in existing systems. > > > > Amanda Walker > > Lucent Technologies InterNetworking Systems > > -- > Andras Veres > > http://comet.ctr.columbia.edu/~veres > Columbia University > Dept. of Electrical Engineering mc 4712 > 500 West 120th Street, H1 > New York, NY 10027 > > Office phone: (212) 854-3117 > Office fax: (212) 932-9421 -- Andras Veres http://comet.ctr.columbia.edu/~veres Columbia University Dept. of Electrical Engineering mc 4712 500 West 120th Street, H1 New York, NY 10027 Office phone: (212) 854-3117 Office fax: (212) 932-9421 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 4 15:39:48 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15055 for ; Thu, 4 May 2000 15:39:47 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F71FA7B0@standards.nortelnetworks.com>; Thu, 4 May 2000 15:32:32 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 38190 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 4 May 2000 15:31:12 -0400 Received: from bells.cs.ucl.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C6F4B8F0@standards.nortelnetworks.com>; Thu, 4 May 2000 15:31:11 -0400 Received: from ginger.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 4 May 2000 20:37:51 +0100 X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: el, en MIME-Version: 1.0 References: <3911BC62.FC1CC433@cs.ucl.ac.uk> <20000504190509.DCD4957042@king.research.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3911D18F.CEB0F384@cs.ucl.ac.uk> Date: Thu, 4 May 2000 20:37:51 +0100 Reply-To: t.pagtzis@cs.ucl.ac.uk Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Theo PAGTZIS Organization: UCL Subject: Re: [MOBILE-IP] intra-RAN diversity with dynamic anycasting... To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Pete McCann wrote: > Hi, Theo, > > Theo PAGTZIS (TP) writes: > > TP> It strikes me that we should not be talking about macrodiversity but > TP> microdiversity since the terms really refers to intra-RAN movement, not > TP> inter-RAN one. > > I am not sure where the term "macrodiversity" comes from - I think it > is a 3GPP term. Frame selection (what I usually call it) can occur > both within and between RANs - sometimes BTSs from a neighboring RAN > are "borrowed" and added to the active set of BTSs. > Fine but I thought that the draft argues on the case of intra-RAN movements and subsequent effect of handoff smoothening...If you start borrowing (hello CBQ) BTSs from neighbouring RANs (really recruit other RANs services) then you are making the distinction between intra and inter-RAN movement a bit obscure. For instance how do you actually decide that you should borrow a BTSs for the neighbour RAN and not initiate a hard handoff? The picture becomes a bit like expanding/contracting (living) RANs.... > TP> I cannot see how you intend to effect power control on the MN since you > TP> have no control over the mobility pattern of the MN. For instance lower > TP> power on the MN may be effected if the MN is relatively close to the BS > TP> and the air interface is relatively quiet. I would probably opt for the > TP> word 'compliance' to power transmission requirements based on > TP> (distance,velocity,height,direction) vector. The degree of compliance to > TP> power control on the BS should be affected in some non-linear way by > TP> that vector. > > The RNC does not have direct knowledge of the position, velocity, and > acceleration of the MN. What happens in existing systems are that the > MN sends a signal to the RNC whenever the detected pilot level of some > BTS in its candidate set exceeds a given threshold. Then the RNC has > the option of adding that BTS to the active set. Power control is > maintained by watching the error rates and adjusting the transmission > power of each BTS to keep it within a predefined threshhold. The IP > stack on the MN is unaware of any of this activity (and should remain > so). Fine ! that mean that by manipulating your power thresholds per MN you may be able to pass MNs to neighbouring cells and really be in control (as RAN gateway) of the handoff situation....So it looks like the MN kicks the handoff but really it is the RAN gateway that triggers it. This has some nice angles in terms managing hotspots and really resources...but isn't that getting the handoff really as network initiated...??? > > > TP> When you try to eliminate cell dragging (inter or intra-RAN) isn't there > TP> a limit to how many cells a CDMA node can be in contact with? > > Yes, there is a limit, and it varies from system to system. > > TP> How do you decide which BS will participate on the simulcasting of the > TP> radio frames and thus will receive the attention of the RAN gateway. Is > TP> the participation dynamic per-RAN or is it fixed (you mentioned point to > TP> point links). > > Participation of BTSs is done according to an algorithm like that given > above. BTSs in an active set can sometimes belong to two different RANs. > > TP> If it is fixed don't you introduce a point of failure for > TP> the BS in case the RAN gateway gets down...? > > The RAN gateway is in fact a single point of failure because it is the > attachment point to the rest of the network. This is true of any of > the equipment in an IP network between you and your first-hop gateway > router, such as your modem, your telephone line, and the NAS box you > are connecting to. I thought that if the BTSs participates to more than one RAN gateways it could potentially re-elect a new RAN-gateway master and thus avoid such PoF. That of course requires that one such BSs maintains more than one PtP connections with diff RAN-gateways; could that have negative implications for the RNCs ? > > > TP> There may not be a one to one mapping but I gather that you would like > TP> the one (MN) to many (BS) down to a minimum....otherwise you flood your > TP> link towards the RAN gateway... > > Not quite sure what you mean here - you should add BTSs to the active > set to achieve the desired level of reliability on the link. Adding too > many would of course add to network utilization. > I may have not understood things correctly here...How long is the 1-M rel/ship between MN and BTSs, effected for ? Theo From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 4 15:48:05 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15259 for ; Thu, 4 May 2000 15:48:05 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.17204AF0@standards.nortelnetworks.com>; Thu, 4 May 2000 15:40:36 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 38176 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 4 May 2000 15:39:34 -0400 Received: from exconnect.levels.unisa.edu.au by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8C3A15C0@standards.nortelnetworks.com>; Thu, 4 May 2000 15:29:33 -0400 Received: by exconnect.levels.unisa.edu.au with Internet Mail Service (5.5.2232.9) id ; Fri, 5 May 2000 05:06:10 +0930 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="windows-1252" Message-ID: <5DA42F8A3C18D111979400AA00DD609D026244B3@exstaff3.levels.unisa.edu.au> Date: Fri, 5 May 2000 05:06:09 +0930 Reply-To: Arek Dadej Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Arek Dadej Subject: Re: [MOBILE-IP] Applicability of IP Mobility to CDMA Soft Handoff X-To: Andras Veres To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Andreas, Please let us not forget that the mobile radio environment is slightly different from what you are used to in a fixed IP world - a cable from point to point, with virtually unlimited bandwidth (if one cable is not enough, you can always add some...). I think in the discussion thus far, the only real voice of reason has come from Pete. Mobile radio is a very complex beast and, for efficiency, involves such tricks as the diversity discussed here (and there is more to come - time/space diversity, smart antennas etc...), most of them involving coordinated activities of multiple base stations. This clearly touches the network level, and therefore the mobile radio access cannot be seen as L1/L2 only. It is, in fact, an infrastructure involving at least layers 1 - 3, ALL of them radio access specific. Why should it be replaced by radio-ignorant standard Internet protocols? See more below --> -----Original Message----- From: Andras Veres To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Sent: 5/5/00 3:36 AM Subject: Re: [MOBILE-IP] Applicability of IP Mobility to CDMA Soft Handoff All, I think that draft-kempf-cdma-appl-00.txt assumes a scenario where all components of a WCMDA network remain the same, only the networking layer would be replaced by IP. If this is the case, I am not surprised at all that we run into serious problems. The reason is that WCDMA was designed based on the circuit switched model and it follows the principle of ** total control for maximum efficiency (TM) **. ******* What else would you expect? The operators pay billions of dollars for a chunk of scarce radio bandwidth. A very small change in efficiency of using that bandwidth may mean a swing in the balance between cost of operation and revenue. Simplicity of equipment and system architecture becomes much less relevant here - no equipment is as expensive as the chunk of radio spectrum the operator needs to buy. Besides, with the progress in technology, the cost of equipment goes down, unlike the cost of radio spectrum which continues to grow. ******* I think that one thing we can learn from IP is that by eliminating total control, of course we loose in performance, but we gain a lot in simplicity and scalability. (And who knows, this loss may be negligible - just think of the great performance of IEEE 802.11) ******* Is this really a lesson to learn from IP? Maybe one could agree long years ago, when the Internet was no more than enjoyable toy for a few computer scientisis, but not now, when we expect it to grow to the level of IP-centric solution to all communications needs of general public. If you were right, the IETF repository would not contain such a huge volume of RFCs and Internet Drafts as it does now. Clearly, the new role of Internet calls for new solutions, and these new solutions somehow refuse to be simple. As to the 802.11, it was designed for a different purpose and different "geographical" scope than cellular networks. Not much of a lesson from 802.11 applies to cellular environment. ******** I know that radio channels call for more control than usual IP networks (e.g., Ethernet), but I do beleive that the current WCDMA and 3G concepts are fundamentally problematic and not scalable -- requiring terrible protocol stacks (IP over ATM over UDP over IP over Whatever over AAL2 over ..... :-), leading to such monsters like RNC. ***** Terrible protocol stacks? Why? If the specifics of mobile radio environment call for solutions that span across layers 1-3 (or higher), because diversity schemes neccesary for efficiency reasons involve co-ordinated activities of a number of geographically distributed entities, what's wrong with that? Would you rather replace these radio-specific solutions with standard Internet? In that case, why not use the same L1 transmission scheme over the mobile radio channel as, say, in a cable-based 802.3 network? Clearly, the Radio Access Network is a very specific infrastructure upon which IP-centric network can be build. And, there is nothing terrible in the way the protocols are stacked upon each other, if you only have a right "mental tool", or template, to deal with that. Have you ever heard of STRATIFIED protocol stacks? You must have heard of looking at the protocol stacks in terms of three planes (user, control and management). That was the first step to aid visualisation of protocol stacks that involve multiple protocols at the same layer level. Te concept of planes simply categorises protocols in the same stack by their purpose/function. The next step is to recognise that a stack of protocols spanning across layers 1-3 can be (from above) treated in the same way as you treat Physical Layer (an infrastructure that can be used to transmit data from point to point), upon which you can use L2 and L3 protocols of your choice. You can iterate that trick a number of times. Each time, what ends at L3 is treated as an infrastructure layer from the layer above. This process of STRATIFICATION is described in the ITU-T Recommendation I.322. It is a very slick and useful way of interpreting complex systems, where protocols do not fall nicely into a typical 7-layer stack. Whenever you see the same level protocol in more places than one when traversing the stack upwards, you may need to stratify the stack. Try the stratification concept on your example above, and it will look VERY SIMPLE. The RAN is a stratum (often made of multiple strata itself). ****** Cheers --Arek James: Do you think that IP is still a non-feasible solution, if we consider that even the curcuit switched model may be redesigned based on IP principles? Regards, Andras -- Andras Veres http://comet.ctr.columbia.edu/~veres Columbia University Dept. of Electrical Engineering mc 4712 500 West 120th Street, H1 New York, NY 10027 Office phone: (212) 854-3117 Office fax: (212) 932-9421 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 4 16:18:09 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15949 for ; Thu, 4 May 2000 16:18:09 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5159DA70@standards.nortelnetworks.com>; Thu, 4 May 2000 16:10:51 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 38440 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 4 May 2000 16:10:09 -0400 Received: from sirius.ctr.columbia.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.37C934C0@standards.nortelnetworks.com>; Thu, 4 May 2000 16:10:08 -0400 Received: from comet.columbia.edu (locke.comet.columbia.edu [128.59.68.81]) by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with ESMTP id QAA12601; Thu, 4 May 2000 16:16:40 -0400 (EDT) X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 References: <5DA42F8A3C18D111979400AA00DD609D026244B3@exstaff3.levels.unisa.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3911E94F.117CF0E2@comet.columbia.edu> Date: Thu, 4 May 2000 16:19:11 -0500 Reply-To: Andras Veres Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Andras Veres Subject: Re: [MOBILE-IP] Applicability of IP Mobility to CDMA Soft Handoff X-To: Arek Dadej To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Arek, I think there is a slight misunderstanding here. When I claim that RAN should be built on IP, I do not mean that radio specific optimizations should be forgotten. These two can coexist easily. I am targeting the terrestrial access network (RAN). I have seen reports claiming that only ATM can support the QoS requirements of WCDMA. Is it true? I am sure it is not. ATM does not contain any fundamental differences compared IP regarding QoS. The current UMTS standard is based on an IP/AAL2/ATM stack, each implementing its own QoS architecture - and the QoS definitions defined in these layers are highly incompatible. The end-result? - large overhead - mapping between service classes lead to unnecessary underutilization - complexity To reply to the isses of the radio channel, it is for sure that it is the focus: by using smart antennas, soft handoff, and don't forget softer handoff (which has higher gain than soft handoff) the efficiency of the scarce radio can be significantly improved. In many countries the radio network is redesigned every few weeks (by adjusting antennas etc.) to squeeze the most out of the radio. On the terrestrial side this means that it has to be reconfigured much more often than in a fixed IP network, it has to be managed more frequently, which can only be solved by a simple RAN architecture. Regards, Andras PS: I think we are getting more and more off-topic, so I should stop now. Arek Dadej wrote: > > Andreas, > > Please let us not forget that the mobile radio environment is slightly > different from what you are used to in a fixed IP world - a cable from point to > point, with virtually unlimited bandwidth (if one cable is not enough, you can > always add some...). I think in the discussion thus far, the only real voice of > reason has come from Pete. Mobile radio is a very complex beast and, for > efficiency, involves such tricks as the diversity discussed here (and there is > more to come - time/space diversity, smart antennas etc...), most of them > involving coordinated activities of multiple base stations. This clearly > touches the network level, and therefore the mobile radio access cannot be seen > as L1/L2 only. It is, in fact, an infrastructure involving at least layers 1 - > 3, ALL of them radio access specific. Why should it be replaced by > radio-ignorant standard Internet protocols? See more below --> > > -----Original Message----- > From: Andras Veres > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Sent: 5/5/00 3:36 AM > Subject: Re: [MOBILE-IP] Applicability of IP Mobility to CDMA Soft Handoff > > All, > > I think that draft-kempf-cdma-appl-00.txt assumes a scenario where > all components of a WCMDA network remain the same, only the networking > layer would be replaced by IP. > > If this is the case, I am not surprised at all that we run into > serious problems. The reason is that WCDMA was designed based on the > circuit switched model and it follows the principle of > ** total control for maximum efficiency (TM) **. > > ******* What else would you expect? The operators pay billions of dollars for a > chunk of scarce radio bandwidth. A very small change in efficiency of using > that bandwidth may mean a swing in the balance between cost of operation and > revenue. Simplicity of equipment and system architecture becomes much less > relevant here - no equipment is as expensive as the chunk of radio spectrum the > operator needs to buy. Besides, with the progress in technology, the cost of > equipment goes down, unlike the cost of radio spectrum which continues to grow. > ******* > > I think that one thing we can learn from IP is that by eliminating > total control, of course we loose in performance, but we gain a lot > in simplicity and scalability. (And who knows, this loss may > be negligible - just think of the great performance of IEEE 802.11) > > ******* Is this really a lesson to learn from IP? Maybe one could agree long > years ago, when the Internet was no more than enjoyable toy for a few computer > scientisis, but not now, when we expect it to grow to the level of IP-centric > solution to all communications needs of general public. If you were right, the > IETF repository would not contain such a huge volume of RFCs and Internet > Drafts as it does now. Clearly, the new role of Internet calls for new > solutions, and these new solutions somehow refuse to be simple. As to the > 802.11, it was designed for a different purpose and different "geographical" > scope than cellular networks. Not much of a lesson from 802.11 applies to > cellular environment. ******** > > I know that radio channels call for more control than usual IP > networks (e.g., Ethernet), but I do beleive that the current > WCDMA and 3G concepts are fundamentally problematic and not > scalable -- requiring terrible protocol stacks (IP over ATM > over UDP over IP over Whatever over AAL2 over ..... :-), > leading to such monsters like RNC. > > ***** Terrible protocol stacks? Why? If the specifics of mobile radio > environment call for solutions that span across layers 1-3 (or higher), because > diversity schemes neccesary for efficiency reasons involve co-ordinated > activities of a number of geographically distributed entities, what's wrong > with that? Would you rather replace these radio-specific solutions with > standard Internet? In that case, why not use the same L1 transmission scheme > over the mobile radio channel as, say, in a cable-based 802.3 network? Clearly, > the Radio Access Network is a very specific infrastructure upon which > IP-centric network can be build. And, there is nothing terrible in the way the > protocols are stacked upon each other, if you only have a right "mental tool", > or template, to deal with that. Have you ever heard of STRATIFIED protocol > stacks? You must have heard of looking at the protocol stacks in terms of three > planes (user, control and management). That was the first step to aid > visualisation of protocol stacks that involve multiple protocols at the same > layer level. Te concept of planes simply categorises protocols in the same > stack by their purpose/function. The next step is to recognise that a stack of > protocols spanning across layers 1-3 can be (from above) treated in the same > way as you treat Physical Layer (an infrastructure that can be used to transmit > data from point to point), upon which you can use L2 and L3 protocols of your > choice. You can iterate that trick a number of times. Each time, what ends at > L3 is treated as an infrastructure layer from the layer above. This process of > STRATIFICATION is described in the ITU-T Recommendation I.322. It is a very > slick and useful way of interpreting complex systems, where protocols do not > fall nicely into a typical 7-layer stack. Whenever you see the same level > protocol in more places than one when traversing the stack upwards, you may > need to stratify the stack. Try the stratification concept on your example > above, and it will look VERY SIMPLE. The RAN is a stratum (often made of > multiple strata itself). ****** > > Cheers > --Arek > > James: Do you think that IP is still a non-feasible solution, > if we consider that even the curcuit switched model may be > redesigned based on IP principles? > > Regards, > Andras > > -- > Andras Veres > > http://comet.ctr.columbia.edu/~veres > Columbia University > Dept. of Electrical Engineering mc 4712 > 500 West 120th Street, H1 > New York, NY 10027 > > Office phone: (212) 854-3117 > Office fax: (212) 932-9421 -- Andras Veres http://comet.ctr.columbia.edu/~veres Columbia University Dept. of Electrical Engineering mc 4712 500 West 120th Street, H1 New York, NY 10027 Office phone: (212) 854-3117 Office fax: (212) 932-9421 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 4 16:28:08 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16172 for ; Thu, 4 May 2000 16:28:08 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B9CA7F50@standards.nortelnetworks.com>; Thu, 4 May 2000 16:20:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 38504 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 4 May 2000 16:19:45 -0400 Received: from ihemlsrv.firewall.lucent.com (192.11.222.161) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8F8BD4A0@standards.nortelnetworks.com>; Thu, 4 May 2000 16:19:45 -0400 Received: from ihemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id QAA29666 for ; Thu, 4 May 2000 16:26:27 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id QAA29649 for ; Thu, 4 May 2000 16:26:26 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2448.0) id ; Thu, 4 May 2000 21:26:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Message-ID: <976F7C55E3B2D111A0720008C728549C04876BBE@en0060exch001u.uk.lucent.com> Date: Thu, 4 May 2000 21:26:25 +0100 Reply-To: "Casati, Alessio (Alessio)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Casati, Alessio (Alessio)" Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question X-To: "Hesham Soliman (EPA)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > It could make sure that all traffic from a given user was tunneled > back to a home > network, by integrating the Mobile IP registration process with some > kind of firewall features. > Why would you want your traffic to be tunnelled back ? > Could attempt an answer: say you own a corporation and have a lot of employees. It's nice to provide them with corporate net access when they are on the road, but you don't like 'em to mess too much with company data and want to enforce the same policies you usally enforce when they are at home via firewalls. Well, I would claim all the traffic from the road warrior should be controlled and if it is not tunneled back, say it's forced to take a route back home before (possibly) going out the internet. How does MIPv6 support this? That is, does it have this essential service capability? thanks alessio From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 4 16:33:21 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16311 for ; Thu, 4 May 2000 16:33:20 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6F6AED40@standards.nortelnetworks.com>; Thu, 4 May 2000 16:26:01 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 38568 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 4 May 2000 16:25:29 -0400 Received: from exconnect.levels.unisa.edu.au by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5C2ACBB0@standards.nortelnetworks.com>; Thu, 4 May 2000 16:25:28 -0400 Received: by exconnect.levels.unisa.edu.au with Internet Mail Service (5.5.2232.9) id ; Fri, 5 May 2000 06:02:07 +0930 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="windows-1252" Message-ID: <5DA42F8A3C18D111979400AA00DD609D026244B4@exstaff3.levels.unisa.edu.au> Date: Fri, 5 May 2000 06:02:07 +0930 Reply-To: Arek Dadej Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Arek Dadej Subject: Re: [MOBILE-IP] Some comments on draft-kempf-cdma-appl-00.txt X-To: veres To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Andras, The "horror" stack you describe below is nothing really horrofic, and nothing new. Telecom networks have seen this many times already, and the operators were not only happy, but also knew how to manage all this. The answer is, as I already pointed out, in the stratified view of stacks. If you want examples, here are a few: 1) a very basic and old one: IP-level interconnection between a number of geographically distributed LANs using switched PSTN or ISDN connections. You have the PSTN or ISDN stratum first (with its own L1 transmission, L2 link control and L3 routing), and this is used by the IP stack (with "null" L2 in most cases)without the IP really knowing what's underneath. The same goes for old X.25 networks that were often run in a similar way. 2) TCP/IP over ATM over satellite network - first you have the satellite stratum (complete with layer 3 if we are talking network of satellites), ten there goes the ATM infrastructure, and finally the TCP/IP network. 3) Most of the "IP switching" schemes - you have the complete ATM (up to the ATM layer) underneath the TCP/IP network with IP-based routing decisions, then you have to see ATM stratum first, and the IP on top of it. Note that ATM, since it involves switching of cells between multiple points, is in fact a complete NETWORK infrastructure. It should not be too difficult to find a few more tricky, more complex existing systems that resemble your horror stack, yet are happily used by te operators. Regards --Arek -----Original Message----- From: veres To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Sent: 5/4/00 10:22 PM Subject: Re: [MOBILE-IP] Some comments on draft-kempf-cdma-appl-00.txt Pete, > AV> What do you mean by 'end-to-end'? It is a message between the > AV> control unit (typically in the RNC) and the BTS or MH. In this > AV> respect it IS e2e, as it involves two (possibly IP layer) nodes. > > What I meant by "end-to-end" was an IP stack on an MT communicating > with another IP stack somewhere in the network to convey power control > information. As Chip correctly pointed out, power control is a link > layer issue, not an IP layer issue. We should not use end-to-end > IP packets to do power control. > > -Pete If you consider the RAN to be L2, then it is a L2 issue. If, on the other hand, RAN is a L3 network, which means that there are several L3 routers between the BTS and the RNC, then signaling between the two nodes is to be done on L3. In my view the major problem with current RAN is that it tries to reinvent a networking layer on - what it calls - L2, i.e., L2/L1 radio frames are routed in the RAN network (consisting of hundreds of nodes!) - which requires fundamentally L3 funcions e.g., routing protocols. And do not forget, that on top of this we still need IP with its own solution for routing etc., even in the current WCDMA solutions, for all data and management traffic. Now, IF on top of this pile, we want to place MIP to interwork with all of this, well, where do we end up? Who will be able to manage it? I am not sure operators would be happy... Andras From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 4 18:14:06 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19538 for ; Thu, 4 May 2000 18:14:06 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8714F040@standards.nortelnetworks.com>; Thu, 4 May 2000 18:06:53 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 39277 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 4 May 2000 18:04:55 -0400 Received: from clea.qualcomm.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.409266C0@standards.nortelnetworks.com>; Thu, 4 May 2000 18:04:55 -0400 Received: from jwillkie1 (jwillkie1.qualcomm.com [129.46.219.171]) by clea.qualcomm.com (8.9.3/8.9.3/1.0) with SMTP id PAA28391; Thu, 4 May 2000 15:11:30 -0700 (PDT) X-Sender: jwillkie@mail1.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_890248781==_" Message-ID: <4.1.20000504150518.00bbbb20@mail1.qualcomm.com> Date: Thu, 4 May 2000 15:11:18 -0700 Reply-To: Jim Willkie Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Jim Willkie Subject: Re: [MOBILE-IP] Applicability of IP Mobility to CDMA Soft Handoff X-To: Andras Veres To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <3911DDFE.7916CE21@comet.columbia.edu> --=====================_890248781==_ Content-Type: text/plain; charset="us-ascii" At 03:30 PM 5/4/00 -0500, Andras Veres wrote: >Amanda, > >Fully agree! I did not intend to bring WCDMA standardization to this >forum :-) >My message is that there is are fundamental limitations in TCP/IP which >would >inhibit its use in WCDMA networks. And maybe we'll have it once - thanks >to those "innovators" you mentioned. >(Hey, aren;t we supposed to be the innovators here?) Isn't this statement exactly backwards? That is, there are fundamental limitations to WCDMA (the data protocols at least) that inhibit running TCP/IP over it? There are at least some of us out here that are convinced this is the case. In fact I would further state that it appears that TCP/IP will run over WCDMA rather nicely if the WCDMA GPRS-like protocols (and the associated XXGNs) were stripped away. Jim Willkie >> Speaking personally, I don't think we're going to solve it here. MIP needs >> to be usable as both a building block *and* an overlay. There's a lot of >> useful experience represented here on both sides of this issue (and some >> additional perspectives as well). I'm much more interested in what everyone >> has done and how it succeeds and fails, than in speculating about how things >> should have been done differently in existing systems. >> >> Amanda Walker >> Lucent Technologies InterNetworking Systems > >-- >Andras Veres > >http://comet.ctr.columbia.edu/~veres >Columbia University >Dept. of Electrical Engineering mc 4712 >500 West 120th Street, H1 >New York, NY 10027 > >Office phone: (212) 854-3117 >Office fax: (212) 932-9421 --=====================_890248781==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="map.bat" net use l: /delete net use l: \\watercooler\aswdata /persistent:yes net use t: /delete net use t: \\watercooler\aswproj /persistent:yes net use v: /delete net use v: \\watercooler\aswusr /persistent:yes net use o: /delete net use o: \\watercooler\aswdata /persistent:yes --=====================_890248781==_-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 4 18:35:14 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19962 for ; Thu, 4 May 2000 18:35:14 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7B1550C0@standards.nortelnetworks.com>; Thu, 4 May 2000 18:28:02 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 39386 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 4 May 2000 18:26:09 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.378664C0@standards.nortelnetworks.com>; Thu, 4 May 2000 18:26:08 -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 QAA07936 for ; Thu, 4 May 2000 16:32:49 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA15131; Thu, 4 May 2000 15:32:45 -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 PAA19989; Thu, 4 May 2000 15:32:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: GNLzm1dRsOyQPsOSf5WyeQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Message-ID: <200005042232.PAA19989@nasnfs.eng.sun.com> Date: Thu, 4 May 2000 15:35:29 -0700 Reply-To: James Kempf Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: James Kempf Subject: Re: [MOBILE-IP] intra-RAN diversity with dynamic anycasting... X-To: t.pagtzis@cs.ucl.ac.uk To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Theo, >I cannot see how you intend to effect power control on the MN since you >have no control over the mobility pattern of the MN. For instance lower >power on the MN may be effected if the MN is relatively close to the BS >and the air interface is relatively quiet. I would probably opt for the >word 'compliance' to power transmission requirements based on >(distance,velocity,height,direction) vector. The degree of compliance to >power control on the BS should be affected in some non-linear way by >that vector. > I'm not entirely sure what your message was referring to, but it is my understanding that current and future CDMA protocols have a very tight coupling between the mobile terminal and the RAN in terms of power control. The RAN gateway (to use the terminology from our draft) basically adjusts the power incrementally in order to balance the signal strength to the base stations to which the MN is transmitting. So it is not a question of whether the RAN can or can not affect the power on the MN, it, in fact, currently does. jak From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 4 18:57:36 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20384 for ; Thu, 4 May 2000 18:57:35 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9ADD9400@standards.nortelnetworks.com>; Thu, 4 May 2000 18:50:23 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 39668 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 4 May 2000 18:50:21 -0400 Received: from bells.cs.ucl.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.995434E0@standards.nortelnetworks.com>; Thu, 4 May 2000 18:50:21 -0400 Received: from ginger.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 4 May 2000 23:56:55 +0100 X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: el, en MIME-Version: 1.0 References: <200005042232.PAA19989@nasnfs.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39120036.FB7D2414@cs.ucl.ac.uk> Date: Thu, 4 May 2000 23:56:54 +0100 Reply-To: t.pagtzis@cs.ucl.ac.uk Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Theo PAGTZIS Organization: UCL Subject: Re: [MOBILE-IP] intra-RAN diversity with dynamic anycasting... To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit > Jak, > I'm not entirely sure what your message was referring to, but it is > my understanding that current and future CDMA protocols have a > very tight coupling between the mobile terminal and the RAN in > terms of power control. The RAN gateway (to use the terminology from our draft) > basically adjusts the power incrementally in order to balance the signal > strength to the base stations to which the MN is transmitting. So it is not a > question of whether the RAN can or can not affect the power on the MN, it, in > fact, currently does. > > jak My initial understanding from the draft was that power control was attempted to be exerted on the MN by the BTS in terms of power savings rather than balancing of signal strength from the MN to each individual BTS to which the MN is Tx-ing... Given some random mobility pattern I was finding difficult to see how you manage to yield power savings on the MN in terms of some control protocol (since the function was not stipulated by the BTS but by the RAN gateway.... ) It is now clear to me that we are talking about signal strength manipulation on the BTS effected by the RAN gateway, which reflects on the power levels of transmission on the part of the MN... How does the RAN gateway exert such control over the BTS(s). What protocol does it employ..? Theo From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 4 19:02:35 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20490 for ; Thu, 4 May 2000 19:02:35 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4FA50710@standards.nortelnetworks.com>; Thu, 4 May 2000 18:55:27 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 39709 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 4 May 2000 18:55:09 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.451097B0@standards.nortelnetworks.com>; Thu, 4 May 2000 18:55:09 -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 RAA25229 for ; Thu, 4 May 2000 17:01:50 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA21771; Thu, 4 May 2000 16:01:05 -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 QAA20839; Thu, 4 May 2000 16:01:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 5TZZ/O+GFxC61xKDu5xp4g== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Message-ID: <200005042301.QAA20839@nasnfs.eng.sun.com> Date: Thu, 4 May 2000 16:03:50 -0700 Reply-To: James Kempf Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: James Kempf Subject: Re: [MOBILE-IP] Applicability of IP Mobility to CDMA Soft Handoff X-To: Arek.Dadej@UNISA.EDU.AU To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Andras, Thanx for the long email. >James: Do you think that IP is still a non-feasible solution, >if we consider that even the curcuit switched model may be >redesigned based on IP principles? > > These are my own opinions, my co-authors may have others. The design of the CDMA RAN has little or nothing to do with circuit switched/non-circuit switched. I don't claim to be a radio engineer, but those I've talked to claim it is primarily governed by the physics of radio propagation to a mobile terminal over a larger area, and how best to maintain signal quality given that. Therefore, I think moving to an overall packet-switched solution will have little effect. In fact, if you look at the 3GPP UTRAN network architecture, the design calls for ATM w. AAL5 for signalling and AAL2 for voice in the RAN. ATM is already packet (well, cell) switched. There is a potential opportunity for replacing ATM with IP, provided the stringent timing and jitter constraints can be met, but I don't think that existing IP mobility solutions will have a role to play in CDMA RAN networks for soft handoff purposes. There is a remote possibility that new routing algorithms could change this situation, though none of the proposals I've seen so far are look very convincing. That said, I agree with Amanda's comments that other solutions are possible, though they have some significant competition in CDMA, based, as it is, on the physics of radio propagation. jak From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 4 19:11:49 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20683 for ; Thu, 4 May 2000 19:11:48 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.96427620@standards.nortelnetworks.com>; Thu, 4 May 2000 19:04:35 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 39810 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 4 May 2000 19:04:29 -0400 Received: from prserv.net (32.97.166.34) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.92996B50@standards.nortelnetworks.com>; Thu, 4 May 2000 19:04:29 -0400 Received: from [32.101.171.137] ([32.101.171.137]) by prserv.net (out4) with ESMTP id <20000504231109239039sao5e>; Thu, 4 May 2000 23:11:10 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: ahmrphd@pop3.attglobal.net Message-ID: Date: Thu, 4 May 2000 16:11:50 -0700 Reply-To: Arthur Ross Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Arthur Ross Subject: Re: [MOBILE-IP] intra-RAN diversity with dynamic anycasting... X-To: James Kempf To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200005042232.PAA19989@nasnfs.eng.sun.com> At 15:35 -0700 05/04/2000, James Kempf wrote: > >I'm not entirely sure what your message was referring to, but it is >my understanding that current and future CDMA protocols have a >very tight coupling between the mobile terminal and the RAN in >terms of power control. The RAN gateway (to use the terminology from our >draft) >basically adjusts the power incrementally in order to balance the signal >strength to the base stations to which the MN is transmitting. So it is not a >question of whether the RAN can or can not affect the power on the MN, it, in >fact, currently does. > Correct. The power is adjusted very rapidly (800 updates per second in the original ANSI-95 standard) by a closed loop mechanism in rather small steps (1 dB or less). Last I heard actual field measurements had found the rms error between received power and the loop setpoint to be roughly +/- 2 dB ... pretty good when you consider the enormous dynamic range of path loss that can be experienced in these systems. And that control mechanism does take into account the soft HO. Only if ALL participating base stations in the SHO say "UP" does the MS increase power. The intent is to keep the power at the level needed for adequate QoS and NO HIGHER. This tight power control is one of the keys to the high spectral efficiency/capacity of CDMA. 'Course this is all predicated on continuous transmission in both directions that permits the closure of the loop. -- A From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 4 19:21:00 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20807 for ; Thu, 4 May 2000 19:21:00 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DC19FD20@standards.nortelnetworks.com>; Thu, 4 May 2000 19:13:41 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 39898 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 4 May 2000 19:11:55 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9C8E9800@standards.nortelnetworks.com>; Thu, 4 May 2000 19:11:55 -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 RAA05821 for ; Thu, 4 May 2000 17:18:35 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA25752; Thu, 4 May 2000 16:18:30 -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 QAA21416; Thu, 4 May 2000 16:18:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 3wqWnaukkXC6X6Gg0/kqTQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Message-ID: <200005042318.QAA21416@nasnfs.eng.sun.com> Date: Thu, 4 May 2000 16:21:15 -0700 Reply-To: James Kempf Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: James Kempf Subject: Re: [MOBILE-IP] intra-RAN diversity with dynamic anycasting... X-To: t.pagtzis@cs.ucl.ac.uk To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Theo, > How does the RAN gateway exert such control >over the BTS(s). What protocol does it employ..? > In 3GPP Release 1999 (wcdma), I think the protocols are NBAP and RNSAP. NBAP is the protocol involved in soft handoff, RNSAP is involved in RAN-RAN signalling. NBAP is specified in TSG 3GPP TS 25.433 v3.1.0 (March 2000) and RNSAP is specified in TSG 3GPP TS 25.423 v3.1.0 (March 2000). These are available from the URL ftp://ftp.3gpp.org/Specs/March 00/25 series/. In 3GPP2, the protocols are specified in IS-95, the existing 2G CDMA standard, and IS-2000, the cdma-2000 standard. IS-634 may also be involved in RAN-RAN signalling. Unfortunately, I don't have a reference for the 3GPP2 protocols. jak From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 4 19:30:59 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20961 for ; Thu, 4 May 2000 19:30:59 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.45850790@standards.nortelnetworks.com>; Thu, 4 May 2000 19:23:48 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 39976 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 4 May 2000 19:22:38 -0400 Received: from prserv.net (32.97.166.32) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1BFDED10@standards.nortelnetworks.com>; Thu, 4 May 2000 19:22:38 -0400 Received: from [32.101.171.137] ([32.101.171.38]) by prserv.net (out2) with ESMTP id <200005042328582290184ctte>; Thu, 4 May 2000 23:28:59 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: ahmrphd@pop3.attglobal.net Message-ID: Date: Thu, 4 May 2000 16:28:33 -0700 Reply-To: Arthur Ross Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Arthur Ross Subject: Re: [MOBILE-IP] Applicability of IP Mobility to CDMA Soft Handoff X-To: James Kempf To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200005042301.QAA20839@nasnfs.eng.sun.com> At 16:03 -0700 05/04/2000, James Kempf wrote: > >That said, I agree with Amanda's comments that other solutions are >possible, though they have some significant competition in CDMA, based, as >it is, on the physics of radio propagation. > Indeed, the solutions are very much dependent on that ugly mobile radio propagation environment - "multipath" propagation, which may or may not be characterizable as "fading" depending on the physical circumstances and bandwidth of the signal, and many tens of dB variation in path loss. But, that said, I think there ARE alternative solutions. Whether they are "optimal" in any sense will depend very much on the nature, distribution, mobility, and intensity of the traffic ... to say nothing of the business/service model. IP packets for non-speech applications may have VERY different statistics and QoS requirements than speech. The existing standards, which are nicely fine-tuned for speech, may not be so optimal if the traffic is bursty, intermittent, and very asymmetric. -- A Dr. Arthur H. M. Ross 2325 East Orangewood Avenue Phoenix, AZ 85020-4730 Tel: 602-371-9708 Fax: 602-336-7074 Portable (CDMA, of course!): 602-677-1021 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 4 22:26:46 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24867 for ; Thu, 4 May 2000 22:26:46 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C948A420@standards.nortelnetworks.com>; Thu, 4 May 2000 22:19:17 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 40375 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 4 May 2000 22:19:00 -0400 Received: from mail0.u-aizu.ac.jp by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BEE3D040@standards.nortelnetworks.com>; Thu, 4 May 2000 22:18:59 -0400 Received: from pross114.u-aizu.ac.jp (pross114 [163.143.180.102]) by mail0.u-aizu.ac.jp (8.9.3+3.1W/3.7Winternet-gw) with ESMTP id LAA24431; Fri, 5 May 2000 11:25:41 +0900 (JST) Received: from u-aizu.ac.jp (localhost [127.0.0.1]) by pross114.u-aizu.ac.jp (8.9.3+3.1W/3.7Wistcmx+kanji) with ESMTP id LAA15688; Fri, 5 May 2000 11:25:40 +0900 (JST) X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Message-ID: <39123124.DFCCF915@u-aizu.ac.jp> Date: Fri, 5 May 2000 11:25:40 +0900 Reply-To: sarikaya@U-AIZU.AC.JP Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Behcet Sarikaya Organization: University of Aizu Subject: Re: [MOBILE-IP] Applicability of IP Mobility to CDMA Soft Handoff X-To: Amanda Walker To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit This mail is really great, thanks Amanda! I think that the researchers in this field should work hard in the direction of the second approach (rather than singling out 3G as ATM-like) and at the same time we should keep an eye on the first one. I think that the approach 1 should set the stage for 4G together with innovations at the physical layer. -- Behcet From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri May 5 03:06:42 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11552 for ; Fri, 5 May 2000 03:06:42 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E90FCB90@standards.nortelnetworks.com>; Fri, 5 May 2000 2:59:20 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 41234 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 5 May 2000 02:57:45 -0400 Received: from ish7.ericsson.com.au (203.61.155.111) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AF8FCB40@standards.nortelnetworks.com>; Fri, 5 May 2000 2: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 RAA03749; Fri, 5 May 2000 17:03:50 +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 RAA06976; Fri, 5 May 2000 17:04:12 +1000 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2448.0) id ; Fri, 5 May 2000 17:03:50 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFB660.10899652" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A5089EAFF7@eaubrnt018.epa.ericsson.se> Date: Fri, 5 May 2000 17:03:49 +1000 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question X-To: "Casati, Alessio (Alessio)" 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_01BFB660.10899652 Content-Type: text/plain > Could attempt an answer: say you own a corporation and have a lot > of employees. It's nice to provide them with corporate net access > when they are on the road, but you don't like 'em to mess too > much with company data and want to enforce the same policies > you usally enforce when they are at home via firewalls. > > Well, I would claim all the traffic from the road warrior > should be controlled and if it is not tunneled back, say it's > forced to take a route back home before (possibly) going > out the internet. > > How does MIPv6 support this? That is, does it have this > essential service capability? > Well that is of course a reasonable example. If I understand you correctly you're basically talking about being able to do reverse tunnelling. I don't see why an FA is required for that purpose. MIPv6 doesn't stop a MN from reverse tunnelling through the home network. So given that the right policies are configured in the MN, nothing I know of in the specs would stop that from happening. If I missed something please let me know Hesham ------_=_NextPart_001_01BFB660.10899652 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] IPv6 Mobility Last Call Question

    Could attempt an answer: say you own a = corporation and have a lot
    of employees. It's nice to provide = them with corporate net access
    when they are on the road, but you = don't like 'em to mess too
    much with company data and want to = enforce the same policies
    you usally enforce when they are at = home via firewalls.

    Well, I would claim all the = traffic  from the road warrior
    should be controlled and if it is not = tunneled back, say it's
    forced to take a route back home = before (possibly) going
    out the internet.

    How does MIPv6 support this? That is, = does it have this
    essential service capability?

    Well that is of = course a reasonable example.
    If I understand you = correctly you're basically talking about being able to do reverse = tunnelling. I don't see why an FA is required for that purpose. MIPv6 = doesn't stop a MN from reverse tunnelling through the home network. So = given that the right policies are configured in the MN, nothing I know = of in the specs would stop that from happening. If I missed something = please let me know

    Hesham


------_=_NextPart_001_01BFB660.10899652-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri May 5 04:38:54 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12289 for ; Fri, 5 May 2000 04:38:54 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C83F9AF0@standards.nortelnetworks.com>; Fri, 5 May 2000 4:31:29 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 41341 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 5 May 2000 04:30:22 -0400 Received: from ihemlsrv.firewall.lucent.com (192.11.222.161) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A06F3120@standards.nortelnetworks.com>; Fri, 5 May 2000 4:30:22 -0400 Received: from ihemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id EAA16704 for ; Fri, 5 May 2000 04:37:05 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id EAA16696 for ; Fri, 5 May 2000 04:37:05 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2448.0) id ; Fri, 5 May 2000 09:37:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Message-ID: <976F7C55E3B2D111A0720008C728549C04876BC2@en0060exch001u.uk.lucent.com> Date: Fri, 5 May 2000 09:37:03 +0100 Reply-To: "Casati, Alessio (Alessio)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Casati, Alessio (Alessio)" Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question X-To: "Hesham Soliman (EPA)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Well that is of course a reasonable example. > If I understand you correctly you're basically talking about being able to > do reverse tunnelling. I don't see why an FA is required for that purpose. > MIPv6 doesn't stop a MN from reverse tunnelling through the home network. > So given that the right policies are configured in the MN, nothing I know > of in the specs would stop that from happening. If I missed something > please let me know > > This may be a solution, but is that part of the MIPv6 spec? are those policies dependent on the NAI? If so there may be quite a lot of configuration required on the MN. Also it would be nice it not to be hardwired. I would suggest that a FA-like (or, not to appear a v4 bigot, let's call it "care of router", but this is a political name for foreign agent;)) approach would be better in that policies are configured dynamically by interaction with AAA. That is to say that we may do workaraounds, but the V6 equivalent of a FA would make the thing better. IMHO. alessio From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri May 5 04:55:16 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12413 for ; Fri, 5 May 2000 04:55:16 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.074DA7D0@standards.nortelnetworks.com>; Fri, 5 May 2000 4:47:34 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 41393 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 5 May 2000 04:46:47 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EBABAE50@standards.nortelnetworks.com>; Fri, 5 May 2000 4:46: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 CAA08145; Fri, 5 May 2000 02:53:29 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA01715; Fri, 5 May 2000 01:53:27 -0700 (PDT) Received: from nasnfs.Eng.Sun.COM (centralapp.Central.Sun.COM [129.147.34.61]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id BAA03260; Fri, 5 May 2000 01:53:21 -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: <200005050853.BAA03260@nasnfs.eng.sun.com> Date: Fri, 5 May 2000 08:55:33 -0000 Reply-To: gab@sun.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gabriel Montenegro Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question X-To: "Casati, Alessio (Alessio)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit >This may be a solution, but is that part of the MIPv6 spec? >are those policies dependent on the NAI? If so there may be quite >a lot of configuration required on the MN. Also it would be nice it not >to be hardwired. I would suggest that a FA-like (or, not to appear >a v4 bigot, let's call it "care of router", but this is a political name >for foreign agent;)) approach would be better in that policies >are configured dynamically by interaction with AAA. > >That is to say that we may do workaraounds, but the V6 equivalent of a >FA would make the thing better. IMHO. i disagree here. to solve this scenario, you'll also require ip layer protection from the mn all the way to its corporation (and perhaps extending into it all the way to the CN). what we found in rfc2356 was that the only viable way to do this was precisely to *NOT* use an FA. perhaps what you want is mipv6+ipsra? -gabriel From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri May 5 10:42:11 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20263 for ; Fri, 5 May 2000 10:42:11 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7B518310@standards.nortelnetworks.com>; Fri, 5 May 2000 10:34:24 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 42054 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 5 May 2000 10:32:35 -0400 Received: from sirius.ctr.columbia.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3A2E8E00@standards.nortelnetworks.com>; Fri, 5 May 2000 10:32:35 -0400 Received: from comet.columbia.edu (locke.comet.columbia.edu [128.59.68.81]) by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with ESMTP id KAA18091; Fri, 5 May 2000 10:39:17 -0400 (EDT) X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 References: <200005042301.QAA20839@nasnfs.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3912EBBF.D6E1EBB9@comet.columbia.edu> Date: Fri, 5 May 2000 10:41:51 -0500 Reply-To: Andras Veres Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Andras Veres Subject: Re: [MOBILE-IP] Applicability of IP Mobility to CDMA Soft Handoff X-To: James Kempf To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit James, > ATM is already packet (well, cell) switched. There is a potential opportunity > for replacing ATM with IP, provided the stringent timing and jitter > constraints can be met, but I don't think that existing IP mobility solutions > will have a role to play in CDMA RAN networks for soft handoff purposes. You claim that IP is not able to guarantee delay and jitter requirements, while ATM is able to do it. This is not proven. If this is the central point of the draft, you will have to back it with data, otherwise we are not on solid ground. Personally I would be very interested in arguments in favor of ATM regarding QoS guarantees, and for a complete and satifying draft, you should probably consider extending the draft in this direction. If it is not QoS which differentiates an ATM based RAN and an IP based RAN, then it the mobility protocol which is used. I think THIS FITS the charter of this WG, and we should focus on whether MIP and the micomobility proposals (CIP, RMIP, HAWAII) are able to support the needs of ANY radio technology. The MIP in its current form is not able to "penetrate" the WCDMA RAN, it has to stop at the edges. Regards, Andras -- Andras Veres http://comet.ctr.columbia.edu/~veres Columbia University Dept. of Electrical Engineering mc 4712 500 West 120th Street, H1 New York, NY 10027 Office phone: (212) 854-3117 Office fax: (212) 932-9421 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri May 5 10:53:58 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20467 for ; Fri, 5 May 2000 10:53:57 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2B99E130@standards.nortelnetworks.com>; Fri, 5 May 2000 10:46:29 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 42118 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 5 May 2000 10:44:37 -0400 Received: from ish7.ericsson.com.au (203.61.155.111) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E822C2F0@standards.nortelnetworks.com>; Fri, 5 May 2000 10:44:36 -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 AAA17045; Sat, 6 May 2000 00:51:13 +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 AAA06838; Sat, 6 May 2000 00:51:36 +1000 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2448.0) id ; Sat, 6 May 2000 00:51:13 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFB6A1.5A633D0A" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A5089EAFF8@eaubrnt018.epa.ericsson.se> Date: Sat, 6 May 2000 00:51:10 +1000 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question X-To: "Casati, Alessio (Alessio)" 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_01BFB6A1.5A633D0A Content-Type: text/plain > > Well that is of course a reasonable example. > > If I understand you correctly you're basically talking about being able > to > > do reverse tunnelling. I don't see why an FA is required for that > purpose. > > MIPv6 doesn't stop a MN from reverse tunnelling through the home > network. > > So given that the right policies are configured in the MN, nothing I > know > > of in the specs would stop that from happening. If I missed something > > please let me know > > > > > This may be a solution, but is that part of the MIPv6 spec? Sure, nothing in the spec stops that scenario as far as I know. > are those policies dependent on the NAI? If so there may be quite > a lot of configuration required on the MN. > Policies or user profiles will be necessary to configure anyway. Just look at how much configuration goes on today. I'm not an advocate for configuration but I think some sort of a "user profile" is essential. > Also it would be nice it not > to be hardwired. I would suggest that a FA-like (or, not to appear > a v4 bigot, let's call it "care of router", but this is a political name > for foreign agent;)) approach would be better in that policies > are configured dynamically by interaction with AAA. That is to say that we may do workaraounds, but the V6 equivalent of a FA would make the thing better. IMHO. I'm all for a "care of router", in fact we presented a draft in Adelaide on a very similar concept (hmipv4/v6). I just believe it is needed for a different reason, and that is fast handoffs. I also agree with you that an interaction with AAA is an absolute necessity (also mentioned in our draft) but I wouldn't like to see the two functions getting mixed so that you would end up needing MIP to exercise access control. An interaction is great but let's keep them as separate functions. Also by keeping "some" policies in the MN we can relief the network node from the extra processing load => more scalability. Again I'm not suggesting letting the MN do everything but some policy enforcement in the MN might be a good thing. Cheers, Hesham ------_=_NextPart_001_01BFB6A1.5A633D0A Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] IPv6 Mobility Last Call Question

    >       = Well that is of course a reasonable example.
    > If I understand you correctly = you're basically talking about being able to
    > do reverse tunnelling. I don't = see why an FA is required for that purpose.
    > MIPv6 doesn't stop a MN from = reverse tunnelling through the home network.
    > So given that the right policies = are configured in the MN, nothing I know
    > of in the specs would stop that = from happening. If I missed something
    > please let me know
    >
    >
    This may be a solution, but is that = part of the MIPv6 spec?
    Sure, nothing in = the spec stops that scenario as far as I know.

    are those policies dependent on the = NAI? If so there may be quite
    a lot of configuration required on = the MN.

    Policies or user = profiles will be necessary to configure anyway. Just look at how much = configuration goes on today. I'm not an advocate for configuration but = I think some sort of a "user profile" is = essential.


     Also it would be nice it = not
    to be hardwired. I would suggest that = a FA-like (or, not to appear
    a v4 bigot, let's call it "care = of router", but this is a political name
    for foreign agent;)) approach would = be better in that policies
    are configured dynamically by = interaction with AAA.
    That is to say that we may do = workaraounds, but the V6 equivalent of a
    FA would make the thing better. = IMHO.

    I'm all for a = "care of router", in fact we presented a draft in Adelaide on = a very similar concept (hmipv4/v6). I just believe it is needed for a = different reason, and that is fast handoffs. I also agree with you that = an interaction with AAA is an absolute necessity (also mentioned in our = draft) but I wouldn't like to see the two functions getting mixed so = that you would end up needing MIP to exercise access control. An = interaction is great but let's keep them as separate = functions.

    Also by keeping = "some" policies in the MN we can relief the network node from = the extra processing load =3D> more scalability.  Again I'm not = suggesting letting the MN do everything but some policy enforcement in = the MN might be a good thing.

    Cheers,
    Hesham




------_=_NextPart_001_01BFB6A1.5A633D0A-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri May 5 11:03:08 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20794 for ; Fri, 5 May 2000 11:03:08 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7298F840@standards.nortelnetworks.com>; Fri, 5 May 2000 10:55:38 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 42224 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 5 May 2000 10:54:48 -0400 Received: from exconnect.levels.unisa.edu.au by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5432FCC0@standards.nortelnetworks.com>; Fri, 5 May 2000 10:54:47 -0400 Received: by exconnect.levels.unisa.edu.au with Internet Mail Service (5.5.2232.9) id ; Sat, 6 May 2000 00:31:29 +0930 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="windows-1252" Message-ID: <5DA42F8A3C18D111979400AA00DD609D026244B5@exstaff3.levels.unisa.edu.au> Date: Sat, 6 May 2000 00:31:28 +0930 Reply-To: Arek Dadej Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Arek Dadej Subject: Re: [MOBILE-IP] Applicability of IP Mobility to CDMA Soft Handoff X-To: Andras Veres To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Andras, I agree that it is good to have data to prove our statements. However, as far as ATM vs IP goes, it is not too hard to guess tha with the current technology ATM has a better chance to guarantee QoS, especially when delay and jitter are concerned. Apart from the obvious differences in the approach to QoS, the important one is that ATM is FAST PACKET (CELL) SWITCHING, while IP can only be a conventional packet switching technology. The subtle difference is in the degree to which you have to examine the header in order to effect the forwarding. Also, the constant (small) cell size makes it easier to control delay and jitter. So, for high volume (high speed) applications, ATM has a better chance to be as fast as we want it to be. However, ATM vs IP within the RAN may be a totally different issue. The major differences between ATM and IP are not so important here, and thus one could imagine both performing well enough. Cheers --Arek -----Original Message----- From: Andras Veres To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Sent: 5/6/00 1:11 AM Subject: Re: [MOBILE-IP] Applicability of IP Mobility to CDMA Soft Handoff James, > ATM is already packet (well, cell) switched. There is a potential opportunity > for replacing ATM with IP, provided the stringent timing and jitter > constraints can be met, but I don't think that existing IP mobility solutions > will have a role to play in CDMA RAN networks for soft handoff purposes. You claim that IP is not able to guarantee delay and jitter requirements, while ATM is able to do it. This is not proven. If this is the central point of the draft, you will have to back it with data, otherwise we are not on solid ground. Personally I would be very interested in arguments in favor of ATM regarding QoS guarantees, and for a complete and satifying draft, you should probably consider extending the draft in this direction. If it is not QoS which differentiates an ATM based RAN and an IP based RAN, then it the mobility protocol which is used. I think THIS FITS the charter of this WG, and we should focus on whether MIP and the micomobility proposals (CIP, RMIP, HAWAII) are able to support the needs of ANY radio technology. The MIP in its current form is not able to "penetrate" the WCDMA RAN, it has to stop at the edges. Regards, Andras -- Andras Veres http://comet.ctr.columbia.edu/~veres Columbia University Dept. of Electrical Engineering mc 4712 500 West 120th Street, H1 New York, NY 10027 Office phone: (212) 854-3117 Office fax: (212) 932-9421 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri May 5 11:15:04 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21046 for ; Fri, 5 May 2000 11:15:03 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.23BF0C30@standards.nortelnetworks.com>; Fri, 5 May 2000 11:07:45 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 42307 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 5 May 2000 11:05:48 -0400 Received: from sirius.ctr.columbia.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DE405E20@standards.nortelnetworks.com>; Fri, 5 May 2000 11:05:48 -0400 Received: from comet.columbia.edu (sweetpea.comet.columbia.edu [128.59.68.61]) by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with ESMTP id LAA19368; Fri, 5 May 2000 11:12:25 -0400 (EDT) X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <5DA42F8A3C18D111979400AA00DD609D026244B5@exstaff3.levels.unisa.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3913126B.A2F911EA@comet.columbia.edu> Date: Fri, 5 May 2000 11:26:51 -0700 Reply-To: campbell@comet.columbia.edu Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Andrew T. Campbell" Organization: Center for Telecommunications Research Subject: Re: [MOBILE-IP] Applicability of IP Mobility to CDMA Soft Handoff X-To: Arek Dadej To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit My personal view is ATM and virtual cicuits complicate the design of the access network and are not needed. Packet based link layers will win - ATM is dead. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri May 5 11:33:14 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21638 for ; Fri, 5 May 2000 11:33:13 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AAB54D10@standards.nortelnetworks.com>; Fri, 5 May 2000 11:25:50 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 42375 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 5 May 2000 11:25:33 -0400 Received: from exconnect.levels.unisa.edu.au by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A02A7AA0@standards.nortelnetworks.com>; Fri, 5 May 2000 11:25:32 -0400 Received: by exconnect.levels.unisa.edu.au with Internet Mail Service (5.5.2232.9) id ; Sat, 6 May 2000 01:02:14 +0930 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="windows-1252" Message-ID: <5DA42F8A3C18D111979400AA00DD609D026244B6@exstaff3.levels.unisa.edu.au> Date: Sat, 6 May 2000 01:02:12 +0930 Reply-To: Arek Dadej Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Arek Dadej Subject: Re: [MOBILE-IP] Applicability of IP Mobility to CDMA Soft Handoff X-To: "Andrew T. Campbell" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Andrew, I tend to agree with the first statement (even if it applies to fixed access networks). However, your second statement is rather far going, if you consider switching of high volume, aggregated traffic. Why is it that truly high capacity, gigabit IP routers somehow cannot do without underlying ATM switching? --Arek -----Original Message----- From: Andrew T. Campbell To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Sent: 5/6/00 3:56 AM Subject: Re: [MOBILE-IP] Applicability of IP Mobility to CDMA Soft Handoff My personal view is ATM and virtual cicuits complicate the design of the access network and are not needed. Packet based link layers will win - ATM is dead. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri May 5 12:50:30 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23858 for ; Fri, 5 May 2000 12:50:29 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.74788FE0@standards.nortelnetworks.com>; Fri, 5 May 2000 12:43:04 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 42548 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 5 May 2000 12:41:17 -0400 Received: from dirty.research.bell-labs.com (204.178.16.6) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3492AEB0@standards.nortelnetworks.com>; Fri, 5 May 2000 12:41:16 -0400 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Fri May 5 12:46:21 EDT 2000 Received: from dnrc.bell-labs.com (ex-vpn69.pa.bell-labs.com [135.250.1.69]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id MAA20278; Fri, 5 May 2000 12:46:16 -0400 (EDT) X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: <5DA42F8A3C18D111979400AA00DD609D026244B5@exstaff3.levels.unisa.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3912FBAC.9BB9FD7@dnrc.bell-labs.com> Date: Fri, 5 May 2000 09:49:48 -0700 Reply-To: Grenville Armitage Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies Subject: Re: [MOBILE-IP] Applicability of IP Mobility to CDMA Soft Handoff X-To: Arek Dadej To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Arek Dadej wrote: [..] > Apart from the obvious differences in the approach to QoS, the > important one is that ATM is FAST PACKET (CELL) SWITCHING, while IP can only be > a conventional packet switching technology. The subtle difference is in the > degree to which you have to examine the header in order to effect the > forwarding. In practice nowdays this is no longer relevant - many new core routers are being designed nowdays with packet switching/forwarding rates at OC-48c and higher. > Also, the constant (small) cell size makes it easier to control > delay and jitter. This point is valid, and the only remaining possible justification for ATM underneath IP at any point in a network - viz. that sometimes you need a 'link' mechanism that can segment and interleave IP packets having different priorities (e.g. using the VC concept to isolate different priority levels, and mux/schedule at the cell level) > So, for high volume (high speed) applications, ATM has a > better chance to be as fast as we want it to be. > > However, ATM vs IP within the RAN may be a totally different issue. The major > differences between ATM and IP are not so important here, and thus one could > imagine both performing well enough. Interestingly, over low speed links (e.g. < couple hundred Kbit/sec) there may be interleaving benefits to having something like ATM under IP (on a per hop basis), although if the link layer itself provides this in other ways that would make ATM arguably redundant. cheers, gja ________________________________________________________________________ Grenville Armitage http://members.home.net/garmitage/ Bell Labs Research Silicon Valley From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri May 5 12:56:43 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24023 for ; Fri, 5 May 2000 12:56:43 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4D520530@standards.nortelnetworks.com>; Fri, 5 May 2000 12:49:07 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 42598 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 5 May 2000 12:47:17 -0400 Received: from crufty.research.bell-labs.com (204.178.16.49) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0B7758E0@standards.nortelnetworks.com>; Fri, 5 May 2000 12:47:17 -0400 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Fri May 5 12:52:37 EDT 2000 Received: from dnrc.bell-labs.com (ex-vpn69.pa.bell-labs.com [135.250.1.69]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id MAA20567; Fri, 5 May 2000 12:52:32 -0400 (EDT) X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: <5DA42F8A3C18D111979400AA00DD609D026244B6@exstaff3.levels.unisa.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3912FD24.BBFF44FD@dnrc.bell-labs.com> Date: Fri, 5 May 2000 09:56:04 -0700 Reply-To: Grenville Armitage Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies Subject: Re: [MOBILE-IP] Applicability of IP Mobility to CDMA Soft Handoff X-To: Arek Dadej To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit [..] > Why is it that truly high > capacity, gigabit IP routers somehow cannot do without underlying ATM > switching? > --Arek Actually, gigabit routers no longer need underlying ATM switching. Consider the use of IP/PPP/SONET interfaces on such routers, running at OC-48c and recently OC-192c. These speeds exceed what commercial IP/ATM ports run at (although ATM switching at OC-48c exists, SAR is problematic at such speeds). As an interesting wrinkle, operators concerned about traffic engineering are deploying such routers with packet-based MPLS in order to support non-shortest path forwarding. cheers, gja ________________________________________________________________________ Grenville Armitage http://members.home.net/garmitage/ Bell Labs Research Silicon Valley From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri May 5 13:45:44 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24908 for ; Fri, 5 May 2000 13:45:44 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2B35DB50@standards.nortelnetworks.com>; Fri, 5 May 2000 13:38:17 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 42708 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 5 May 2000 13:37:16 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.07133740@standards.nortelnetworks.com>; Fri, 5 May 2000 13:37:16 -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 LAA27381; Fri, 5 May 2000 11:43:57 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA02987; Fri, 5 May 2000 10:43:52 -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 KAA14758; Fri, 5 May 2000 10:43:20 -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: <200005051743.KAA14758@nasnfs.eng.sun.com> Date: Fri, 5 May 2000 10:46:05 -0700 Reply-To: James.Kempf@Eng.Sun.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: James Kempf Subject: Re: [MOBILE-IP] Applicability of IP Mobility to CDMA Soft Handoff X-To: Andras Veres To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit >James, > >> ATM is already packet (well, cell) switched. There is a potential opportunity >> for replacing ATM with IP, provided the stringent timing and jitter >> constraints can be met, but I don't think that existing IP mobility solutions >> will have a role to play in CDMA RAN networks for soft handoff purposes. > >You claim that IP is not able to guarantee delay and jitter >requirements, while ATM is able to do it. This is not proven. If this >is the central point of the draft, you will have to back it with data, >otherwise we are not on solid ground. Personally I would be very >interested in arguments in favor of ATM regarding QoS guarantees, and >for a complete and satifying draft, you should probably consider >extending the draft in this direction. > No, what I said was that IP *MAY* have a role to play in the RAN, but it has not been proven yet. Personally, I think it does have a big role to play, but, as an engineer, I'm not willing to say "yes" until I see the numbers. >If it is not QoS which differentiates an ATM based RAN and an IP based >RAN, then it the mobility protocol which is used. I think THIS FITS >the charter of this WG, and we should focus on whether MIP and >the micomobility proposals (CIP, RMIP, HAWAII) are able to support >the needs of ANY radio technology. The MIP in its current form >is not able to "penetrate" the WCDMA RAN, it has to stop at the >edges. > As we tried to point out in the paper, given current understanding of IP routing protocols and RAN designs, our belief is that soft handoff is not a candidate for replacement with current IP mobility, but hard handoff is. A hierarchical model of mobility management, with soft handoff being highest performance and mobile IP for hard handoff, seems like the most logical model to me. Personally, I'd like to see the fast handoff discussion in this group confined to replacing hard handoff, and confined to the context of current mobile IP and IP routing protocols. If there is interest in looking at new routing protocols and mobility management for networks that operate like CDMA RANs, I think it should be taken up in a separate working group. The model here is MANET, which discusses a mobility model which is orthogonal to the model presented by mobile IP. I am skeptical that a mobility model will cover all wireless networks, simply because, given the MANET work, we already know that there will be some that don't fall under the mobile IP model. On the other hand, mobile IP has proved its usefulness in the 3GPP2 packet data service. It seems likely that any replacement to current soft handoff that uses IP mobility would require a separate protocol because the CDMA network is very different. jak From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri May 5 14:16:51 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25955 for ; Fri, 5 May 2000 14:16:51 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8356E780@standards.nortelnetworks.com>; Fri, 5 May 2000 14:09:22 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 42767 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 5 May 2000 14:08:02 -0400 Received: from angelo.kcl.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EDAEF160@standards.nortelnetworks.com>; Fri, 5 May 2000 13:58:02 -0400 Received: from nhhg62-02.paws.umds.ac.uk (nhhg62-02.paws.umds.ac.uk [159.92.100.62]) by angelo.kcl.ac.uk with SMTP id TAA20137 for ; Fri, 5 May 2000 19:04:46 +0100 (BST) Priority: NORMAL X-Mailer: Simeon for Win32 Version 4.1.5 Build (43) X-Authentication: IMSP MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Fri, 5 May 2000 19:04:46 +0100 Reply-To: sylvain.gille@kcl.ac.uk Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Sylvain Gille Subject: [MOBILE-IP] Tcl scripts to study routing in Mip To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <3912FBAC.9BB9FD7@dnrc.bell-labs.com> hi, does anybody know where I could find a script in Tcl (running with NS2) which purpose is to study routing in mip i.e. to make test on delays at MH, optimization etc... Sylvain. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat May 6 09:18:04 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21164 for ; Sat, 6 May 2000 09:18:03 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E9B6A2F0@standards.nortelnetworks.com>; Sat, 6 May 2000 9:10:24 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 44337 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 6 May 2000 09:09:22 -0400 Received: from auemail2.firewall.lucent.com (192.11.223.163) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C4A58030@standards.nortelnetworks.com>; Sat, 6 May 2000 9:09:22 -0400 Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA00420 for ; Sat, 6 May 2000 09:16:03 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA00402 for ; Sat, 6 May 2000 09:15:58 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2448.0) id ; Sat, 6 May 2000 14:15:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Message-ID: <976F7C55E3B2D111A0720008C728549C04876BC9@en0060exch001u.uk.lucent.com> Date: Sat, 6 May 2000 14:15:55 +0100 Reply-To: "Casati, Alessio (Alessio)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Casati, Alessio (Alessio)" Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question X-To: "gab@sun.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > perhaps what you want is mipv6+ipsra? > This is certainly a solution. But sometimes the visited operator is trusted. Sometimes IPSEC is not supported all the way to light weight terminals and still having a FA (v4) or CoR (V6) may be useful, of course provided that the serving operator can be trusted (a lot of businesses, almost every business, rely on trust at a certain stage). But, most important, if we go down the IPSRA way, the MIP model is due to change quite a lot: the home agent will be most likely always provided by the visited network, which provides internet access, and a VPN client must be used to access the corporate net. So, not allowing for a FA (sorry, CoR) implies changes in the Mobile IP model when IPv6 is used. Food for thought. alessio From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat May 6 10:12:51 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21630 for ; Sat, 6 May 2000 10:12:51 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9CE4FB40@standards.nortelnetworks.com>; Sat, 6 May 2000 10:05:31 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 44438 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 6 May 2000 10:03:50 -0400 Received: from ihemlsrv.firewall.lucent.com (192.11.222.161) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6048C6D0@standards.nortelnetworks.com>; Sat, 6 May 2000 10:03:50 -0400 Received: from ihemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA27695 for ; Sat, 6 May 2000 10:10:37 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA27689 for ; Sat, 6 May 2000 10:10:36 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2448.0) id ; Sat, 6 May 2000 15:10:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Message-ID: <976F7C55E3B2D111A0720008C728549C04876BCC@en0060exch001u.uk.lucent.com> Date: Sat, 6 May 2000 15:10:35 +0100 Reply-To: "Casati, Alessio (Alessio)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Casati, Alessio (Alessio)" Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question X-To: "Hesham Soliman (EPA)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > Well that is of course a reasonable example. > > If I understand you correctly you're basically talking about being able > to > > do reverse tunnelling. I don't see why an FA is required for that > purpose. > > MIPv6 doesn't stop a MN from reverse tunnelling through the home > network. > > So given that the right policies are configured in the MN, nothing I > know > > of in the specs would stop that from happening. If I missed something > > please let me know > > > > > This may be a solution, but is that part of the MIPv6 spec? > > > Sure, nothing in the spec stops that scenario as far as I know. > I would add to that, that according to MIPv6 the correspondent node would not send traffic to the corporation after it has received the binding update, but to the visited network, and as such we have problems. We need to add to the spec the option to have CN's always send traffic to the HA, I would think. > I'm not an advocate for configuration but I think some sort of a "user > profile" is essential. > Yes, but maybe not stored on the mobile node :). I also agree with you that an interaction with AAA is an absolute necessity (also mentioned in our draft) but I wouldn't like to see the two functions getting mixed so that you would end up needing MIP to exercise access control. An interaction is great but let's keep them as separate functions. AAA does provide useful services and MIP had already happened to benefit from them in V4, why not in V6? > Also by keeping "some" policies in the MN we can relief the network > node from the extra processing load => more scalability. Again I'm not > suggesting letting the MN do everything but some policy enforcement in the > MN might be a good thing. > Well, what you may keep in the mobile are a NAI and credentials/authentication material. Policies are enforced by the network. alessio > > > > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat May 6 13:41:28 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22797 for ; Sat, 6 May 2000 13:41:27 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BCEEDC90@standards.nortelnetworks.com>; Sat, 6 May 2000 13:34:00 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 44831 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 6 May 2000 13:32:20 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.80C762F0@standards.nortelnetworks.com>; Sat, 6 May 2000 13:32:19 -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 KAA06701; Sat, 6 May 2000 10:39:06 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id KAA05876; Sat, 6 May 2000 10:33:07 -0700 X-Virus-Scanned: Sat, 6 May 2000 10:33:07 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from (maxdialin6.iprg.nokia.com [205.226.20.236]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma005646; Sat, 6 May 00 10:33:02 -0700 X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <976F7C55E3B2D111A0720008C728549C04876BCC@en0060exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <391457B8.F021AFF4@iprg.nokia.com> Date: Sat, 6 May 2000 10:34:48 -0700 Reply-To: charliep@iprg.nokia.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "C. Perkins/D. Reese" Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question X-To: "Casati, Alessio (Alessio)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Alessio, > I would add to that, that according to MIPv6 the > correspondent node would not send traffic to > the corporation after it has received the binding > update, but to the visited network, and > as such we have problems. We need to add to the > spec the option to have CN's always > send traffic to the HA, I would > think. The mobile node is not required to send Binding Updates to any correspondent node. If it does not, the mobile node will get all its traffic from the HA. The existing text doesn't need to be changed in the regard. > AAA does provide useful services and MIP had already > happened to benefit from them in V4, why not in V6? What do you think about the AAAv6 draft? Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat May 6 15:06:55 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23357 for ; Sat, 6 May 2000 15:06:55 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A82B58E0@standards.nortelnetworks.com>; Sat, 6 May 2000 14:59:20 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 45086 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 6 May 2000 14:57:31 -0400 Received: from sj-msg-core-1.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.677F8FA0@standards.nortelnetworks.com>; Sat, 6 May 2000 14:57:31 -0400 Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA07085; Sat, 6 May 2000 12:04:24 -0700 (PDT) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id OAA16391; Sat, 6 May 2000 14:04:17 -0500 (CDT) X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.3.1.2.20000506114738.029066f0@flipper.cisco.com> Date: Sat, 6 May 2000 11:50:40 -0700 Reply-To: Fred Baker Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Fred Baker Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question X-To: "Casati, Alessio (Alessio)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Apologies if this is a duplicate. I seem to have a stuck mail server in San Jose, and I'm resending some stuff I think may be in it. At 02:26 PM 5/3/00 +0100, Casati, Alessio (Alessio) wrote: >Why would a v6 mobility scale better than a v4? Tell me if I misunderstand. It is my understanding that in IP4 mobility, every packet goes through the home agent, while in IP6 mobility, the call is set up through the home agent but after that packets go directly to the care-of router. In IP4, the home agent is a single point of failure for every packet going to the mobile device. In IP6, it is a single point of failure only for sessions being set up to the mobile device, and presumably if I have multiple sessions to that device in parallel I could maintain some form of super-state that knows the care-of router for all of them together. We're talking at least one order of magnitude (mean session being on the order of ten packets each direction), probably two (accounting for aggregated sessions and larger files). >I'm sure you need to store some info at home and in the correspondent nodes. Yes, of course - a key aspect of mobility is that it has to know where the mobile device is *right now*. But how often do you have to use it? By the way, for the other solutions you also need some form of routing state. You need to know the addresses you have positioned at the far end of MPLS tunnels or whatever, and keep that correlation. And like V4 mobility (if I understand it) the link into the ISP must be as large as all the traffic that its users need to send at any given time with the routing solutions. The nice thing I see about IP6 mobility (if I understand it) is that we use the distributed characteristics of the Internet architecture to make that link and processing bottleneck not exist. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat May 6 15:06:55 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23359 for ; Sat, 6 May 2000 15:06:55 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A84F0D80@standards.nortelnetworks.com>; Sat, 6 May 2000 14:59:20 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 45089 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 6 May 2000 14:57:45 -0400 Received: from sj-msg-core-1.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6FCBE3C0@standards.nortelnetworks.com>; Sat, 6 May 2000 14:57:45 -0400 Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA07126; Sat, 6 May 2000 12:04:38 -0700 (PDT) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id OAA16424; Sat, 6 May 2000 14:04:31 -0500 (CDT) X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.3.1.2.20000506114710.0289ae90@flipper.cisco.com> Date: Sat, 6 May 2000 11:52:57 -0700 Reply-To: Fred Baker Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Fred Baker Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question X-To: Pete McCann To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Apologies if this is a duplicate. I seem to have a stuck mail server in San Jose, and I'm resending some stuff I think may be in it. At 11:00 AM 5/4/00 -0500, Pete McCann wrote: >Such an entity would actually facilitate the kind of "ISP open access" >that Fred described, rather than hindering it. It could make sure >that all traffic from a given user was tunneled back to a home >network, by integrating the Mobile IP registration process with some >kind of firewall features. Would that be an objective? I think the user would generally like to be able to get his address from the ISP and access the services (which he pays for) that the ISP offers, but in generally he has no desire that his traffic go through the ISP. If they can go straight to the peer through the intervening network, and avoid having a single point of failure or congestion, he's happiest. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat May 6 15:06:56 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23368 for ; Sat, 6 May 2000 15:06:56 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A8B0DC90@standards.nortelnetworks.com>; Sat, 6 May 2000 14:59:20 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 45096 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 6 May 2000 14:58:02 -0400 Received: from sj-msg-core-1.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.79D13280@standards.nortelnetworks.com>; Sat, 6 May 2000 14:58:02 -0400 Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA07193; Sat, 6 May 2000 12:04:55 -0700 (PDT) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id OAA16442; Sat, 6 May 2000 14:04:48 -0500 (CDT) X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.3.1.2.20000506114706.02883c40@flipper.cisco.com> Date: Sat, 6 May 2000 11:53:36 -0700 Reply-To: Fred Baker Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Fred Baker Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question X-To: "Casati, Alessio (Alessio)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Apologies if this is a duplicate. I seem to have a stuck mail server in San Jose, and I'm resending some stuff I think may be in it. At 09:26 PM 5/4/00 +0100, Casati, Alessio (Alessio) wrote: >Could attempt an answer: say you own a corporation and have a lot >of employees. It's nice to provide them with corporate net access >when they are on the road, but you don't like 'em to mess too >much with company data and want to enforce the same policies >you usally enforce when they are at home via firewalls. > >Well, I would claim all the traffic from the road warrior >should be controlled and if it is not tunneled back, say it's >forced to take a route back home before (possibly) going >out the internet. I can imagine some benighted corporation making that rule for its employees. Are you telling me that because some company might someday be that obnoxious to its own employees, then that should be fundamental to the protocol and hobble its scalability for more normal purposes? I hope you don't quite mean that. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun May 7 00:49:31 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28611 for ; Sun, 7 May 2000 00:49:31 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0C899B70@standards.nortelnetworks.com>; 7 May 2000 0:41:57 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 45566 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 7 May 2000 00:40:27 -0400 Received: from ish7.ericsson.com.au (203.61.155.111) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D62F6C30@standards.nortelnetworks.com>; 7 May 2000 0:40:26 -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 OAA01007 for ; Sun, 7 May 2000 14:46:35 +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 OAA20017 for ; Sun, 7 May 2000 14:46:58 +1000 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2448.0) id ; Sun, 7 May 2000 14:46:36 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFB7DF.39D1C202" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A5089EAFF9@eaubrnt018.epa.ericsson.se> Date: Sun, 7 May 2000 14:46:36 +1000 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question 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_01BFB7DF.39D1C202 Content-Type: text/plain Hi Alessio, > > I would add to that, that according to MIPv6 the > correspondent node would not send traffic to > the corporation after it has received the binding > update, but to the visited network, and > as such we have problems. We need to add to the > spec the option to have CN's always > send traffic to the HA, I would > think. >The mobile node is not required to send Binding Updates >to any correspondent node. If it does not, the mobile node >will get all its traffic from the HA. The existing text >doesn't need to be changed in the regard. I think Charlie's answered this above. Just remember that the MIPv6 SW _will_need_ to be configured. There is no way around that. So this is just another configuration parameter. This is basically the option you're referring to. It's a configuration option not a protocol option. > > I'm not an advocate for configuration but I think some sort of a "user > > profile" is essential. > > > Yes, but maybe not stored on the mobile node :). > > > I also agree with you that an interaction with AAA is an absolute > necessity (also mentioned in our draft) but I wouldn't like to see the two > functions getting mixed so that you would end up needing MIP to exercise > access control. An interaction is great but let's keep them as separate > functions. > > AAA does provide useful services and MIP had already > happened to benefit from them in V4, why not in V6? > I never said there are no benefits for V6. There were two AAAv6 drafts presented in Adelaide, and I'm sure MIPv6 will benefits from them. But the great thing about both drafts (in my opinion ) is that they we re aimed at providing a generic access control mechanism for IPv6. MIPv6 can certainly interwork with the AAA function and benefit from it, but they should remain two separate functions. Just like MIPv6 benefits and interacts with IPsec but they are two separate functions. > > Also by keeping "some" policies in the MN we can relief the network > > node from the extra processing load => more scalability. Again I'm not > > suggesting letting the MN do everything but some policy enforcement in > the > > MN might be a good thing. > > > Well, what you may keep in the mobile are a NAI and > credentials/authentication material. > > Policies are enforced by the network. Well I slightly disagree ;) I think in future with the existence of various overlapping access technologies, a user profile might be necessary and that might be a much more sophisticated one than a simple configuration command for MIP (which is the case here with reverse tunnelling). Hesham ------_=_NextPart_001_01BFB7DF.39D1C202 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] IPv6 Mobility Last Call Question

Hi Alessio,

     
    I would add to that, that according = to MIPv6 the
    correspondent node would not send = traffic to
    the corporation after it has received = the binding
    update, but to the visited network, = and
    as such we have problems. We need to = add to the
    spec the option to have CN's = always
    send traffic to the HA, I = would
    think.

     
      = >The mobile node is not required to send Binding Updates
      >to = any correspondent node.  If it does not, the mobile node
      = >will get all its traffic from the HA.  The existing = text
      = >doesn't need to be changed in the regard.

 I think Charlie's answered this = above. Just remember that the MIPv6 SW _will_need_ to be configured. = There is no way around that. So this is just another configuration = parameter. This is basically the option you're referring to. It's a = configuration option not a protocol option.

    >  I'm not an advocate for = configuration but I think some sort of a "user
    > profile" is = essential.
    >
    Yes, but maybe not stored on the = mobile node :).=20


               I also agree with you that an interaction = with AAA is an absolute
    necessity (also mentioned in our = draft) but I wouldn't like to see the two
    functions getting mixed so that you = would end up needing MIP to exercise
    access control. An interaction is = great but let's keep them as separate
    functions.

    AAA does provide useful services and = MIP had already
    happened to benefit from them in V4, = why not in V6?=20

    I never said there = are no benefits for V6. There were two  AAAv6 drafts presented in = Adelaide, and I'm sure MIPv6 will benefits from them. But the great = thing about both drafts (in my opinion ) is that they we re aimed at = providing a generic access control mechanism for IPv6. MIPv6 can = certainly interwork with the AAA function and benefit from it, but they = should remain two separate functions. Just like MIPv6 benefits and = interacts with IPsec but they are two separate functions.

    >       = Also by keeping "some" policies in the MN we can relief the = network
    > node from the extra processing = load =3D> more scalability.  Again I'm not
    > suggesting letting the MN do = everything but some policy enforcement in the
    > MN might be a good thing. =
    >
    Well, what you may keep in the mobile = are a NAI and
    credentials/authentication material. =

    Policies are enforced by the = network.
    Well I slightly = disagree ;) I think in future with the existence of various overlapping = access technologies, a user profile might be necessary and that might = be a much more sophisticated one than a simple configuration command = for MIP (which is the case here with reverse tunnelling).

    Hesham

------_=_NextPart_001_01BFB7DF.39D1C202-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun May 7 13:06:18 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10040 for ; Sun, 7 May 2000 13:06:17 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FF2DA1D0@standards.nortelnetworks.com>; 7 May 2000 12:58:53 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 47043 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 7 May 2000 12:58:03 -0400 Received: from mercury.ukc.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E1569FE0@standards.nortelnetworks.com>; 7 May 2000 12:58:03 -0400 Received: from pelican.ukc.ac.uk ([129.12.200.26]) by mercury.ukc.ac.uk with esmtp (Exim 2.12 #1) id 12oUU8-0002Af-00 for MOBILE-IP@standards.nortelnetworks.com; Sun, 7 May 2000 18:04:53 +0100 Received: from pcecad4.ukc.ac.uk ([129.12.51.227] helo=pcecad4) by pelican.ukc.ac.uk with smtp (Exim 1.92 #1) for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM id 12oUU9-0004XB-00; Sun, 7 May 2000 18:04:53 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002F_01BFB84E.BEC14400" 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: <003201bfb846$5d555c40$e3330c81@ukc.ac.uk> Date: Sun, 7 May 2000 18:04:53 +0100 Reply-To: Kumarendra Sivarajah Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Kumarendra Sivarajah Subject: [MOBILE-IP] Mobile IP with Ad Hoc Network To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_002F_01BFB84E.BEC14400 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If anyone has any related papers on the subject Mobile IP with Ad Hoc = Network, I would appreciate if you could reply to my mail. Currently I = only have two papers as below: -Ad Hoc Networking with Mobile IP by Hui Lei and Charles E Perkins -Mobile IP, Ad Hoc Networking and Nomadicity by Charles E Perkins=20 Also has anyone done any simulation on combination of both mobile IP = with Ad Hoc network, could you also please reply to me. Thank you Indran ------=_NextPart_000_002F_01BFB84E.BEC14400 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
If anyone has any related papers on the = subject=20 Mobile IP with Ad Hoc Network, I would appreciate if you could reply to = my mail.=20 Currently I only have two papers as below:
-Ad Hoc Networking with Mobile IP = by Hui Lei=20 and Charles E Perkins
-Mobile IP, Ad Hoc Networking and = Nomadicity by=20 Charles E Perkins 
Also has anyone done any simulation on = combination=20 of both mobile IP with Ad Hoc network, could you also please reply to = me. Thank=20 you
 
Indran
------=_NextPart_000_002F_01BFB84E.BEC14400-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun May 7 15:12:42 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11522 for ; Sun, 7 May 2000 15:12:41 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A0EAC0A0@standards.nortelnetworks.com>; 7 May 2000 15:05:06 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 47217 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 7 May 2000 15:04:04 -0400 Received: from alemail1.firewall.lucent.com (192.11.221.161) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7C023480@standards.nortelnetworks.com>; 7 May 2000 15:04: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 PAA22638 for ; Sun, 7 May 2000 15:10:55 -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 PAA22623 for ; Sun, 7 May 2000 15:10:51 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2448.0) id ; Sun, 7 May 2000 20:10:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Message-ID: <976F7C55E3B2D111A0720008C728549C04876BCF@en0060exch001u.uk.lucent.com> Date: Sun, 7 May 2000 20:10:47 +0100 Reply-To: "Casati, Alessio (Alessio)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Casati, Alessio (Alessio)" Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question X-To: "charliep@iprg.nokia.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi Charlie > ---------- > From: C. Perkins/D. Reese[SMTP:charliep@iprg.nokia.com] > Reply To: charliep@iprg.nokia.com > Sent: 06 May 2000 18:34 > To: Casati, Alessio (Alessio) > Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question > > > Hello Alessio, > > > I would add to that, that according to MIPv6 the > > correspondent node would not send traffic to > > the corporation after it has received the binding > > update, but to the visited network, and > > as such we have problems. We need to add to the > > spec the option to have CN's always > > send traffic to the HA, I would > > think. > > The mobile node is not required to send Binding Updates > to any correspondent node. If it does not, the mobile node > will get all its traffic from the HA. The existing text > doesn't need to be changed in the regard. > Yes, the spec says the MN MAY send a BU. I would like, at the protocol level, to force the traffic to be tunneled back to the corporation, concurrently with disabling sending BUs to CNs. In addition, would the WG like to add the option to let the CoR do reverse tunneling, just to save radio resources? That is good for V4, I think that would be even better for V6, as the header size is quite bigger. Another item for discussion is: How much is acceptable for a corporation that a mobile node uses an IP address topologically not belonging to the corporate net when sending packets as it is away from home but still logically part of the corporate network? Does it make corporate security policies enforcement more complex? do we have any V6 firewall expert to provide help? > > AAA does provide useful services and MIP had already > > happened to benefit from them in V4, why not in V6? > > What do you think about the AAAv6 draft? > I think it's good to start defining AAA for V6 network access. I think there are problems with reply protection that need to be addressed (as already discussed in Adelaide). I also think that mobile IP could require its own special things, since I'm not sure that granting network access would automatically be associated to granting mobility support services. The allocation of HA may be subject to authorization? Opinions? alessio From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun May 7 15:12:42 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11524 for ; Sun, 7 May 2000 15:12:42 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A12FDFF0@standards.nortelnetworks.com>; 7 May 2000 15:05:06 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 47222 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 7 May 2000 15:05:05 -0400 Received: from ihemail2.firewall.lucent.com (192.11.222.163) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A01FF690@standards.nortelnetworks.com>; 7 May 2000 15:05:04 -0400 Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA03080 for ; Sun, 7 May 2000 15:11:52 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA03072 for ; Sun, 7 May 2000 15:11:51 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2448.0) id ; Sun, 7 May 2000 20:11:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Message-ID: <976F7C55E3B2D111A0720008C728549C04876BD0@en0060exch001u.uk.lucent.com> Date: Sun, 7 May 2000 20:11:44 +0100 Reply-To: "Casati, Alessio (Alessio)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Casati, Alessio (Alessio)" Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question X-To: "Hesham Soliman (EPA)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > >The mobile node is not required to send Binding Updates > >to any correspondent node. If it does not, the mobile node > >will get all its traffic from the HA. The existing text > >doesn't need to be changed in the regard. > > I think Charlie's answered this above. Just remember that the MIPv6 SW > _will_need_ to be configured. There is no way around that. So this is just > another configuration parameter. This is basically the option you're > referring to. It's a configuration option not a protocol option. > I would prefer avoiding host configuration if we could have some flag set in a message back from the HA telling the MIPv6 SW to -Turn off sending BUs -Reverse tunnel to the corporate HA It would avoid much pain with misconfigured hosts in the future. alessio From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun May 7 15:16:35 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11561 for ; Sun, 7 May 2000 15:16:35 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.33FDD080@standards.nortelnetworks.com>; 7 May 2000 15:09:12 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 47300 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 7 May 2000 15:08:20 -0400 Received: from ihemail2.firewall.lucent.com (192.11.222.163) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.14E01DC0@standards.nortelnetworks.com>; 7 May 2000 15:08:20 -0400 Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA03593 for ; Sun, 7 May 2000 15:15:11 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA03588 for ; Sun, 7 May 2000 15:15:11 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2448.0) id ; Sun, 7 May 2000 20:15:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Message-ID: <976F7C55E3B2D111A0720008C728549C04876BD1@en0060exch001u.uk.lucent.com> Date: Sun, 7 May 2000 20:15:08 +0100 Reply-To: "Casati, Alessio (Alessio)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Casati, Alessio (Alessio)" Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question X-To: Fred Baker To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > ---------- > From: Fred Baker[SMTP:fred@cisco.com] > > Apologies if this is a duplicate. I seem to have a stuck mail server in > San > Jose, and I'm resending some stuff I think may be in it. > > > At 02:26 PM 5/3/00 +0100, Casati, Alessio (Alessio) wrote: > >Why would a v6 mobility scale better than a v4? > > Tell me if I misunderstand. > > It is my understanding that in IP4 mobility, every packet goes through the > > home agent, while in IP6 mobility, the call is set up through the home > agent but after that packets go directly to the care-of router. > Yes, but not always. The binding cache for most of websites will be quite busy if we would have millions of mobile nodes hitting them, so the information stored in web sites binding caches will inevitably be quite volatile. I would say that MIPv6 implies websites processing thousands of BUs per second and I see a lot of scalability problems (and low efficiency in sending BUs to CNs such as websites). I could guess that web sites may be in the business of managing millions of SAs too, for MIPv6 purposes. Let me say that V6 appears to have its own peculiar scalability problems. > In IP4, the home agent is a single point of failure for every packet going > > to the mobile device. In IP6, it is a single point of failure only for > sessions being set up to the mobile device, and presumably if I have > multiple sessions to that device in parallel I could maintain some form of > > super-state that knows the care-of router for all of them together. > I would claim that V6 home agents should be quite reliable anyway, and actually need to be up, if you want to use MIPv6. Recovering from a HA failure will be quite like today recovering from a NAS failure. The industry of NASes seems not to be suffering a lot. Let me also say this is not certainly telling me V6 scales better. > We're talking at least one order of magnitude (mean session being on the > order of ten packets each direction), probably two (accounting for > aggregated sessions and larger files). > I would say I'm lost on this statement. I don't quite get what you mean. You don't keep state per (traffic)session, but per mobile node MIPv6 session. This is like in MIPv4. > >I'm sure you need to store some info at home and in the correspondent > nodes. > > Yes, of course - a key aspect of mobility is that it has to know where the > > mobile device is *right now*. But how often do you have to use it? > As often as you want to send packets to a mobile node. > By the way, for the other solutions you also need some form of routing > state. You need to know the addresses you have positioned at the far end > of > MPLS tunnels or whatever, and keep that correlation. And like V4 mobility > (if I understand it) the link into the ISP must be as large as all the > traffic that its users need to send at any given time with the routing > solutions. > I really had to give up on this since I was not able to recall/understand what are "the other solutions". Please clarify. Generally, I could buy scalability arguments If you showed that V4 is O(n^2) and V6 O(n) or V4 O(n)and V6 O(log n) where n is the number of users a HA (and FA for V4, CoR for V6, of course) handles. alessio From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun May 7 15:21:34 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11599 for ; Sun, 7 May 2000 15:21:34 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EA025770@standards.nortelnetworks.com>; 7 May 2000 15:14:18 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 47377 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 7 May 2000 15:13:31 -0400 Received: from ihemail2.firewall.lucent.com (192.11.222.163) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CDAFF9B0@standards.nortelnetworks.com>; 7 May 2000 15:13:30 -0400 Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA04185 for ; Sun, 7 May 2000 15:20:21 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA04180 for ; Sun, 7 May 2000 15:20:21 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2448.0) id ; Sun, 7 May 2000 20:20:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Message-ID: <976F7C55E3B2D111A0720008C728549C04876BD2@en0060exch001u.uk.lucent.com> Date: Sun, 7 May 2000 20:20:18 +0100 Reply-To: "Casati, Alessio (Alessio)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Casati, Alessio (Alessio)" Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > ---------- > From: Fred Baker[SMTP:fred@CISCO.COM] > Reply To: Fred Baker > Sent: 06 May 2000 19:53 > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question > > Apologies if this is a duplicate. I seem to have a stuck mail server in > San > Jose, and I'm resending some stuff I think may be in it. > > > At 09:26 PM 5/4/00 +0100, Casati, Alessio (Alessio) wrote: > >Could attempt an answer: say you own a corporation and have a lot > >of employees. It's nice to provide them with corporate net access > >when they are on the road, but you don't like 'em to mess too > >much with company data and want to enforce the same policies > >you usally enforce when they are at home via firewalls. > > > >Well, I would claim all the traffic from the road warrior > >should be controlled and if it is not tunneled back, say it's > >forced to take a route back home before (possibly) going > >out the internet. > > I can imagine some benighted corporation making that rule for its > employees. Are you telling me that because some company might someday be > that obnoxious to its own employees, then that should be fundamental to > the > protocol and hobble its scalability for more normal purposes? > > I hope you don't quite mean that. > > I mean that when a roadwarrior is accessing the corporate net, all traffic to and from the Internet must traverse the corporate firewalls and use corporate proxies to make enforcement of corporate (security) policies possible. Seems to be quite a common practice not to want employees access inappropriate internet resources when on the workplace. I would think also when they are on the road, if they access the corporate net. Of course the road warrior may well use other mobile services than corporate net access to access the Net without having the traffic take the corporate net route :). This is to say, we need a protocol option allowing traffic to be tunneled back to the corporation. This does not mean the protocol in its entirety is affected, I think. alessio From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun May 7 18:54:51 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13696 for ; Sun, 7 May 2000 18:54:51 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B4488B40@standards.nortelnetworks.com>; 7 May 2000 18:47:33 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 47586 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 7 May 2000 18:46:05 -0400 Received: from sj-msg-core-1.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8017A4A0@standards.nortelnetworks.com>; 7 May 2000 18:46:05 -0400 Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id PAA00427; Sun, 7 May 2000 15:53:01 -0700 (PDT) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id RAA16966; Sun, 7 May 2000 17:52:53 -0500 (CDT) X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.3.1.2.20000507150752.00ea2100@flipper.cisco.com> Date: Sun, 7 May 2000 15:11:26 -0700 Reply-To: Fred Baker Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Fred Baker Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question X-To: "Casati, Alessio (Alessio)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <976F7C55E3B2D111A0720008C728549C04876BD2@en0060exch001u.uk .lucent.com> At 08:20 PM 5/7/00 +0100, Casati, Alessio (Alessio) wrote: >I mean that when a roadwarrior is accessing the corporate net, >all traffic to and from the Internet must traverse the corporate >firewalls and use corporate proxies to make >enforcement of corporate (security) policies possible. seems quite a special case. Could be configured that way for those cases where (a) it's a road warrior and (b) there is a policy that requires this handling. Why impose packet-handling of the special case in the general case where distributed processing would get better packet handling characteristics? In short, I understand that sometimes there is a corporation that figures its employees cannot be trusted outside of its four walls, but I don't understand why that should be a limit on the case I mentioned, or a limit on a corporation that doesn't see its employees in that light. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun May 7 20:14:10 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14247 for ; Sun, 7 May 2000 20:14:10 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C4DD13D0@standards.nortelnetworks.com>; 7 May 2000 20:06:45 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 47758 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 7 May 2000 20:04:49 -0400 Received: from ish7.ericsson.com.au (203.61.155.111) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7ED67110@standards.nortelnetworks.com>; 7 May 2000 20:04:47 -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 KAA18636 for ; Mon, 8 May 2000 10:10:58 +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 KAA07369 for ; Mon, 8 May 2000 10:11:22 +1000 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2448.0) id ; Mon, 8 May 2000 10:11:01 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFB881.E37CF072" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A5089EAFFA@eaubrnt018.epa.ericsson.se> Date: Mon, 8 May 2000 10:10:58 +1000 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question 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_01BFB881.E37CF072 Content-Type: text/plain > > > > >The mobile node is not required to send Binding Updates > > >to any correspondent node. If it does not, the mobile node > > >will get all its traffic from the HA. The existing text > > >doesn't need to be changed in the regard. > > > > I think Charlie's answered this above. Just remember that the MIPv6 SW > > _will_need_ to be configured. There is no way around that. So this is > just > > another configuration parameter. This is basically the option you're > > referring to. It's a configuration option not a protocol option. > > > I would prefer avoiding host configuration if we could have some > flag set in a message back from the HA telling the MIPv6 SW to > > -Turn off sending BUs > -Reverse tunnel to the corporate HA > > It would avoid much pain with misconfigured hosts > in the future. > Is there any significant SW module that gets installed without configuration, no matter how little it may be ? If you avoid configuring this particular option, I can name another half a dozen options that might need configuration to allow for other special cases like the one you mentioned. In fact when we implemented MIPv6 we had about 10 options to configure and I'm sure if we look again we'll find more. I don't think everyone of those options should go in the specs. So IMO you can't avoid host configuration because different users have different needs. ------_=_NextPart_001_01BFB881.E37CF072 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] IPv6 Mobility Last Call Question

    >      
    >       >The mobile = node is not required to send Binding Updates
    >       >to any = correspondent node.  If it does not, the mobile node
    >       >will get = all its traffic from the HA.  The existing text
    >       >doesn't = need to be changed in the regard.
    >
    >  I think Charlie's answered = this above. Just remember that the MIPv6 SW
    > _will_need_ to be configured. = There is no way around that. So this is just
    > another configuration parameter. = This is basically the option you're
    > referring to. It's a = configuration option not a protocol option.
    >
    I would prefer avoiding host = configuration if we could have some
    flag set in a message back from the = HA telling the MIPv6 SW to

    -Turn off sending BUs
    -Reverse tunnel to the corporate = HA

    It would avoid much pain with = misconfigured hosts
    in the future.

    Is there any = significant SW module that gets installed without configuration, no = matter how little it may be ? If you avoid configuring this particular = option, I can name another half a dozen options that might need = configuration to allow for other special cases like the one you = mentioned. In fact when we implemented MIPv6 we had about 10 options to = configure and I'm sure if we look again we'll find more.

    I don't think = everyone of those options should go in the specs. So IMO you can't = avoid host configuration because different users have different needs. =


------_=_NextPart_001_01BFB881.E37CF072-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun May 7 22:14:27 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16131 for ; Sun, 7 May 2000 22:14:27 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8DB74770@standards.nortelnetworks.com>; 7 May 2000 22:06:54 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 47855 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 7 May 2000 22:05:40 -0400 Received: from shsrv.shaked.co.il (192.115.231.130) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FBA79340@standards.nortelnetworks.com>; 7 May 2000 21:55:39 -0400 Received: from kllklk (01-059.044.popsite.net [216.126.163.59]) by shsrv.shaked.co.il (8.8.7/8.8.7) with ESMTP id DAA11793; Mon, 8 May 2000 03:45:56 +0300 X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <200005080045.DAA11793@shsrv.shaked.co.il> Date: Sun, 7 May 2000 21:01:57 -0500 Reply-To: Jason Mills Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Jason Mills Subject: [MOBILE-IP] For Job Seekers and Employers! X-To: seek290d@shsrv.shaked.co.il To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA16131 Dear Potential Job Seeker and Employers, http://www.nationwideconsultants.com is an absolutely free service for job seekers, employers and 3rd party firms. In the future, please use this site as another resource for your employment needs. Sincerely, The NationwideConsultants.com Team PLEASE NOTE: Further transmissions to you by the sender of this email may be stopped at no cost to you by sending a reply to: mailto:sppt8@angelfire.com?subject=remove You have received this offer because your email address is part of our "in House" list. You or someone you know has sent your email address to us in the past. Our team promotes professional and responsible use of email marketing. If this message is in error we apologize. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 8 00:56:45 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18314 for ; Mon, 8 May 2000 00:56:45 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3A71DE60@standards.nortelnetworks.com>; Mon, 8 May 2000 0:49:13 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 48086 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 8 May 2000 00:47:38 -0400 Received: from mail0.u-aizu.ac.jp by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.00548CA0@standards.nortelnetworks.com>; Mon, 8 May 2000 0:47:35 -0400 Received: from pross114.u-aizu.ac.jp (pross114 [163.143.180.102]) by mail0.u-aizu.ac.jp (8.9.3+3.1W/3.7Winternet-gw) with ESMTP id NAA23803 for ; Mon, 8 May 2000 13:54:14 +0900 (JST) Received: from u-aizu.ac.jp (localhost [127.0.0.1]) by pross114.u-aizu.ac.jp (8.9.3+3.1W/3.7Wistcmx+kanji) with ESMTP id NAA19359 for ; Mon, 8 May 2000 13:54:14 +0900 (JST) X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: <3911A21E.38AC95CA@usa.alcatel.com> <20000504165627.0C19157042@king.research.bell-labs.com> <3911C04F.775DA3EA@comet.columbia.edu> <20000504182029.43DDD57042@king.research.bell-labs.com> <39117286.65CCA12B@comet.columbia.edu> Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Message-ID: <39164876.D53EACE0@u-aizu.ac.jp> Date: Mon, 8 May 2000 13:54:14 +0900 Reply-To: sarikaya@U-AIZU.AC.JP Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Behcet Sarikaya Organization: University of Aizu Subject: Re: [MOBILE-IP] Some comments on draft-kempf-cdma-appl-00.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit IMHO this draft has several serious (typing) mistakes and when corrected it is easy to understand and appreciate its conclusion, in short this draft is not a bombshell trying to invalidate Mobile IP in cellular networks. The typos are: 1. base station should be replaced by base transceiver station or BTS everywhere. 2. RAN should probably be replaced by base station controller or BSC in most places. 3. that soft handoff is an application layer mechanism should be replaced by L2 mechanism in at least two places. Basically BTS is a link layer entity and Jak has a nice picture of it in Fig.3 of SC-AllIP-20000217-015. With the above corrections this draft is a nice contribution and makes its point quite well. I think the largest impact is with host route based approaches, it is in those drafts that there is a claim on soft handoff. --behcet From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 8 02:10:52 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00323 for ; Mon, 8 May 2000 02:10:52 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9595BB90@standards.nortelnetworks.com>; Mon, 8 May 2000 2:03:20 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 48188 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 8 May 2000 02:01:38 -0400 Received: from sirius.ctr.columbia.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5892FD20@standards.nortelnetworks.com>; Mon, 8 May 2000 2:01:38 -0400 Received: from comet.columbia.edu (coltrane.ocs.columbia.edu [128.59.240.174]) by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with ESMTP id CAA15657; Mon, 8 May 2000 02:08:21 -0400 (EDT) X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <3911A21E.38AC95CA@usa.alcatel.com> <20000504165627.0C19157042@king.research.bell-labs.com> <3911C04F.775DA3EA@comet.columbia.edu> <20000504182029.43DDD57042@king.research.bell-labs.com> <39117286.65CCA12B@comet.columbia.edu> <39164876.D53EACE0@u-aizu.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <391663D1.E0C7A6E9@comet.columbia.edu> Date: Mon, 8 May 2000 02:50:57 -0400 Reply-To: campbell@comet.columbia.edu Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: campbell Organization: Center for Telecommunications Research, Columbia University Subject: Re: [MOBILE-IP] Some comments on draft-kempf-cdma-appl-00.txt X-To: sarikaya@U-AIZU.AC.JP To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Behcet Sarikaya wrote: > > With the above corrections this draft is a nice contribution and makes > its point quite well. I think the largest impact > is with host route based approaches, it is in those drafts that there is > a claim on soft handoff. Cellular IP supports, what we call, semisoft handoff. > > --behcet From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 8 04:45:24 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01361 for ; Mon, 8 May 2000 04:45:24 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.23FA7910@standards.nortelnetworks.com>; Mon, 8 May 2000 4:37:39 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 48420 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 8 May 2000 04:36:02 -0400 Received: from auemlsrv.firewall.lucent.com (192.11.223.161) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EA3A3B70@standards.nortelnetworks.com>; Mon, 8 May 2000 4:36:02 -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 EAA07247 for ; Mon, 8 May 2000 04:42:54 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id EAA07242 for ; Mon, 8 May 2000 04:42:53 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2448.0) id ; Mon, 8 May 2000 09:42:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Message-ID: <976F7C55E3B2D111A0720008C728549C04876BD3@en0060exch001u.uk.lucent.com> Date: Mon, 8 May 2000 09:42:47 +0100 Reply-To: "Casati, Alessio (Alessio)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Casati, Alessio (Alessio)" Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question X-To: "Hesham Soliman (EPA)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Is there any significant SW module that gets installed without > configuration, no matter how little it may be ? If you avoid configuring > this particular option, I can name another half a dozen options that might > need configuration to allow for other special cases like the one you > mentioned. In fact when we implemented MIPv6 we had about 10 options to > configure and I'm sure if we look again we'll find more. > > Well, saying you have to configure something does not mean you are happy to configure even more. Sounds like a strange statement to me. alessio From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 8 04:51:46 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01422 for ; Mon, 8 May 2000 04:51:45 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FC3B57E0@standards.nortelnetworks.com>; Mon, 8 May 2000 4:43:42 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 48458 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 8 May 2000 04:41:58 -0400 Received: from hoemail2.firewall.lucent.com (192.11.226.163) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BE9FDBE0@standards.nortelnetworks.com>; Mon, 8 May 2000 4:41:58 -0400 Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id EAA04927 for ; Mon, 8 May 2000 04:48:51 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id EAA04912 for ; Mon, 8 May 2000 04:48:50 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2448.0) id ; Mon, 8 May 2000 09:48:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Message-ID: <976F7C55E3B2D111A0720008C728549C04876BD4@en0060exch001u.uk.lucent.com> Date: Mon, 8 May 2000 09:48:41 +0100 Reply-To: "Casati, Alessio (Alessio)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Casati, Alessio (Alessio)" Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question X-To: Fred Baker To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Why impose packet-handling of the special case in the general > case where distributed processing would get better packet handling > characteristics? > Fred, seems like you are assuming I said that to make me appear on the wrong side. In the non particular case the appropriate scenario will apply. In the particular case, the particular scenario holds. We could design quite easily the MIPv6 protocol to help enforce some policies, versus configuring MN SW. Anyway, I gave my input, up to the authors making use of it (if it's worth). cheers alessio From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 8 04:59:29 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01444 for ; Mon, 8 May 2000 04:59:28 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1D507860@standards.nortelnetworks.com>; Mon, 8 May 2000 4:51:47 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 48437 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 8 May 2000 04:49:48 -0400 Received: from monza.broadswitch.com (195.178.164.73) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.70DE4F90@standards.nortelnetworks.com>; Mon, 8 May 2000 4:39:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <45AFD48D077ED211BB4700A0C9DCE8FD28A4DA@monza.broadswitch.com> Date: Mon, 8 May 2000 10:46:35 +0200 Reply-To: Thomas Eklund Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Thomas Eklund Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question X-To: "Casati, Alessio (Alessio)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi Allessio, > > > > > >The mobile node is not required to send Binding Updates > > >to any correspondent node. If it does not, the mobile node > > >will get all its traffic from the HA. The existing text > > >doesn't need to be changed in the regard. > > > > I think Charlie's answered this above. Just remember that > the MIPv6 SW > > _will_need_ to be configured. There is no way around that. > So this is just > > another configuration parameter. This is basically the option you're > > referring to. It's a configuration option not a protocol option. > > > I would prefer avoiding host configuration if we could have some > flag set in a message back from the HA telling the MIPv6 SW to Why? The only thing that happens if the host dont support local bindings of the CN is that the traffic will go trough the HA... In other words it works but the traffic will not take the optimal way , e.g no route optimazation... > > -Turn off sending BUs This option is like saying turn off toute optimazation, but why do you want to do that when you have support for it? Even a tiny thin client have enough memory for its CN's.... > -Reverse tunnel to the corporate HA Why is that needed??? In ipv6 all the ip addresses are always topologically correct and there is no need to do reverse tunneling to the corporate HA... > > It would avoid much pain with misconfigured hosts > in the future. dont see the need for it... But that my opinion... Regards Thomas From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 8 05:24:25 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01644 for ; Mon, 8 May 2000 05:24:24 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9D24E5F0@standards.nortelnetworks.com>; Mon, 8 May 2000 5:16:50 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 48554 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 8 May 2000 05:14:58 -0400 Received: from monza.broadswitch.com (195.178.164.73) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F47606B0@standards.nortelnetworks.com>; Mon, 8 May 2000 5:04:57 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <45AFD48D077ED211BB4700A0C9DCE8FD28A4DB@monza.broadswitch.com> Date: Mon, 8 May 2000 11:11:44 +0200 Reply-To: Thomas Eklund Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Thomas Eklund Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question X-To: "Casati, Alessio (Alessio)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi Allessio, > > Of course the road warrior may well use other mobile services than > corporate net access to access the Net without having the traffic take > the corporate net route :). > > This is to say, we need a protocol option allowing traffic to > be tunneled > back to the corporation. This does not mean the protocol in > its entirety > is affected, I think. > We already have that option in default today in IPv6 if we use ipsec in tunneling mode... You can set up a tunnel from your mobile node to your firewall/router in your home network... And you have a IPv6 based VPN.... Regards Thomas From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 8 05:35:17 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01737 for ; Mon, 8 May 2000 05:35:16 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.28503A70@standards.nortelnetworks.com>; Mon, 8 May 2000 5:27:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 48559 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 8 May 2000 05:26:08 -0400 Received: from monza.broadswitch.com (195.178.164.73) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.84104E10@standards.nortelnetworks.com>; Mon, 8 May 2000 5:16:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <45AFD48D077ED211BB4700A0C9DCE8FD28A4DD@monza.broadswitch.com> Date: Mon, 8 May 2000 11:22:53 +0200 Reply-To: Thomas Eklund Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Thomas Eklund Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question X-To: Fred Baker To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi Fred, Besides route optimazation that you pointed out - mobile ipv6 can get scaling benefits out of the hiearchical address architecture that ipv6 have. And those scaling benefits can be HUGE if you use ipv6 in large networks like inside a GPRS operator or CDMA2000 operator.... It is also much easier to enforce ingress filtering in the routers in the vistited subnetworks... Regards Thomas > At 02:26 PM 5/3/00 +0100, Casati, Alessio (Alessio) wrote: > >Why would a v6 mobility scale better than a v4? > > Tell me if I misunderstand. > > It is my understanding that in IP4 mobility, every packet > goes through the > home agent, while in IP6 mobility, the call is set up through the home > agent but after that packets go directly to the care-of router. > > In IP4, the home agent is a single point of failure for every > packet going > to the mobile device. In IP6, it is a single point of failure only for > sessions being set up to the mobile device, and presumably if I have > multiple sessions to that device in parallel I could maintain > some form of > super-state that knows the care-of router for all of them together. > > We're talking at least one order of magnitude (mean session > being on the > order of ten packets each direction), probably two (accounting for > aggregated sessions and larger files). > > >I'm sure you need to store some info at home and in the > correspondent nodes. > > Yes, of course - a key aspect of mobility is that it has to > know where the > mobile device is *right now*. But how often do you have to use it? > > By the way, for the other solutions you also need some form of routing > state. You need to know the addresses you have positioned at > the far end of > MPLS tunnels or whatever, and keep that correlation. And like > V4 mobility > (if I understand it) the link into the ISP must be as large as all the > traffic that its users need to send at any given time with the routing > solutions. The nice thing I see about IP6 mobility (if I > understand it) is > that we use the distributed characteristics of the Internet > architecture to > make that link and processing bottleneck not exist. > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 8 06:21:33 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02317 for ; Mon, 8 May 2000 06:21:33 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9C5BCFF0@standards.nortelnetworks.com>; Mon, 8 May 2000 6:14:04 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 48750 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 8 May 2000 06:12:26 -0400 Received: from mgw-x1.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6141CEB0@standards.nortelnetworks.com>; Mon, 8 May 2000 6:12:25 -0400 Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60]) by mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id NAA11683; Mon, 8 May 2000 13:19:17 +0300 (EETDST) Received: from esebh01nok.ntc.nokia.com (esebh01nok.ntc.nokia.com [131.228.118.150]) by mgw-i1.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id NAA15189; Mon, 8 May 2000 13:19:15 +0300 (EETDST) Received: by esebh01nok with Internet Mail Service (5.5.2650.10) id ; Mon, 8 May 2000 13:19:10 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: Date: Mon, 8 May 2000 13:18:38 +0300 Reply-To: patrik.flykt@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrik Flykt Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question X-To: acasati@LUCENT.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello, > I would like, at the protocol level, to > force the traffic to be tunneled back to the > corporation, concurrently with disabling sending BUs > to CNs. Actually, since there has been a lot of interest in adding optimized routing to MIPv4, why would you try to remove it from MIPv6 ?? > In addition, would the WG like to add the > option to let the CoR do reverse tunneling, just > to save radio resources? That is good for V4, > I think that would be even better for V6, as the header > size is quite bigger. The radio resource saving is a general concern, not a MIP specific thing. Therefore it should be attacked by using header compression. The FA in MIPv4 is there mainly as an care-of address distributor, which is not needed in MIPv6 anymore since we have address autoconfiguration. > Another item for discussion is: > How much is acceptable for a corporation > that a mobile node uses an IP address topologically > not belonging to the corporate net when sending packets as it is > away from home but still logically part of the corporate > network? Does it make corporate security policies enforcement > more complex? do we have any V6 firewall expert to provide help? I'm neither a firewall nor a security gateway expert, but IMHO I think this is solved by having the Mobile Node apply the corporate security policies for every sent and received datagram. I also thing this is an IPsec issue irrelevant if MIP is used or not. I agree that MNs tend to move somewhat more than hosts leasing addresses with DHCP, which is why this issue pops up when MIP is discussed. > I also think that mobile IP could require its own special > things, since I'm not sure that granting network access > would automatically be associated to granting mobility support Why not? There is nothing in the visited network that needs to be involved in MIPv6. Besides, the MN could be protecting its Binding Updates to the HA also with ESP, meaning that there is no way for the visited network to know what the MN is sending anyway. I think most of your concerns could be addressed by proper configuration of Binding Update sending, VPN, header compression, etc. after/prior to the MIPv6 stack has been activated. > services. The allocation of HA may be subject to > authorization? Opinions? It's true that HA leasing needs authorization. Perhaps there is some input to both of the IPv6+AAA drafts here ? Regards, Patrik From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 8 06:32:33 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02445 for ; Mon, 8 May 2000 06:32:33 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.282957E0@standards.nortelnetworks.com>; Mon, 8 May 2000 6:25:08 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 48806 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 8 May 2000 06:23:19 -0400 Received: from alemail1.firewall.lucent.com (192.11.221.161) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E722EB80@standards.nortelnetworks.com>; Mon, 8 May 2000 6:23:19 -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 GAA20803 for ; Mon, 8 May 2000 06:30:12 -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 GAA20794 for ; Mon, 8 May 2000 06:30:11 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2448.0) id ; Mon, 8 May 2000 11:30:11 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Message-ID: <976F7C55E3B2D111A0720008C728549C04876BD7@en0060exch001u.uk.lucent.com> Date: Mon, 8 May 2000 11:30:03 +0100 Reply-To: "Casati, Alessio (Alessio)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Casati, Alessio (Alessio)" Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question X-To: Thomas Eklund To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > We already have that option in default today in IPv6 if we use ipsec in > tunneling mode... > > You can set up a tunnel from your mobile node to your firewall/router in > your home network... > And you have a IPv6 based VPN.... > > Perfect, but that is not the Mobile IP model. that is IPSRA, which gabriel already mentioned. alessio From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 8 06:36:49 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02495 for ; Mon, 8 May 2000 06:36:48 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B8CBB5E0@standards.nortelnetworks.com>; Mon, 8 May 2000 6:29:11 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 48838 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 8 May 2000 06:29:05 -0400 Received: from hoemlsrv.firewall.lucent.com (192.11.226.161) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B52EB900@standards.nortelnetworks.com>; Mon, 8 May 2000 6:29:05 -0400 Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id GAA25412 for ; Mon, 8 May 2000 06:35:57 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id GAA25403 for ; Mon, 8 May 2000 06:35:57 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2448.0) id ; Mon, 8 May 2000 11:35:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Message-ID: <976F7C55E3B2D111A0720008C728549C04876BD8@en0060exch001u.uk.lucent.com> Date: Mon, 8 May 2000 11:35:52 +0100 Reply-To: "Casati, Alessio (Alessio)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Casati, Alessio (Alessio)" Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question X-To: Thomas Eklund To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Thom, could you stick to the discussion topics and avoid megastatements on the virtues of IPv6 (which we are not discussing here). It seems to me that we have a bunch of people that feel very hurt when one expresses comments on *V6. We are here to work on *V6 to make it ready for deployment. alessio > ---------- > From: Thomas Eklund[SMTP:thomas.eklund@SWITCHCORE.COM] > Reply To: Thomas Eklund > Sent: 08 May 2000 10:22 > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question > > Hi Fred, > Besides route optimazation that you pointed out - mobile ipv6 can get > scaling benefits out of the hiearchical address architecture that ipv6 > have. > And those scaling benefits can be HUGE if you use ipv6 in large networks > like inside a GPRS operator or CDMA2000 operator.... > It is also much easier to enforce ingress filtering in the routers in the > vistited subnetworks... > Regards Thomas > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 8 06:45:40 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02729 for ; Mon, 8 May 2000 06:45:40 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FCB80EB0@standards.nortelnetworks.com>; Mon, 8 May 2000 6:38:14 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 48890 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 8 May 2000 06:36:52 -0400 Received: from ihemlsrv.firewall.lucent.com (192.11.222.161) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CB60ADE0@standards.nortelnetworks.com>; Mon, 8 May 2000 6:36:52 -0400 Received: from ihemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id GAA28505 for ; Mon, 8 May 2000 06:43:44 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id GAA28497 for ; Mon, 8 May 2000 06:43:44 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2448.0) id ; Mon, 8 May 2000 11:43:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Message-ID: <976F7C55E3B2D111A0720008C728549C04876BD9@en0060exch001u.uk.lucent.com> Date: Mon, 8 May 2000 11:43:38 +0100 Reply-To: "Casati, Alessio (Alessio)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Casati, Alessio (Alessio)" Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question X-To: "patrik.flykt@nokia.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > ---------- > From: patrik.flykt@nokia.com[SMTP:patrik.flykt@nokia.com] > Sent: 08 May 2000 11:18 > To: acasati@LUCENT.COM; MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: RE: [MOBILE-IP] IPv6 Mobility Last Call Question > > > Hello, > > > I would like, at the protocol level, to > > force the traffic to be tunneled back to the > > corporation, concurrently with disabling sending BUs > > to CNs. > > Actually, since there has been a lot of interest in adding optimized > routing > to MIPv4, why would you try to remove it from MIPv6 ?? > did you read my messages? I would be surprised if you asked to me this question if you read them. > > In addition, would the WG like to add the > > option to let the CoR do reverse tunneling, just > > to save radio resources? That is good for V4, > > I think that would be even better for V6, as the header > > size is quite bigger. > > The radio resource saving is a general concern, not a MIP specific thing. > Therefore it should be attacked by using header compression. The FA in > MIPv4 > is there mainly as an care-of address distributor, which is not needed in > MIPv6 anymore since we have address autoconfiguration. > Good, so tell ROHC to compress IP/IP headers. (I was not ruling out compression of the user IP packet, after it was stripped off from the encapsulating header). I'm not sure that we can compress IPsec stuff, though. Try to check that. > > Another item for discussion is: > > How much is acceptable for a corporation > > that a mobile node uses an IP address topologically > > not belonging to the corporate net when sending packets as it is > > away from home but still logically part of the corporate > > network? Does it make corporate security policies enforcement > > more complex? do we have any V6 firewall expert to provide help? > > I'm neither a firewall nor a security gateway expert, but IMHO I think > this > is solved by having the Mobile Node apply the corporate security policies > for every sent and received datagram. > Well, I already hear network administrators having some doubt on this. > > I also think that mobile IP could require its own special > > things, since I'm not sure that granting network access > > would automatically be associated to granting mobility support > > Why not? There is nothing in the visited network that needs to be involved > in MIPv6. Besides, the MN could be protecting its Binding Updates to the > HA > also with ESP, meaning that there is no way for the visited network to > know > what the MN is sending anyway. > How does this relate to authorization? I miss that. > I think most of your concerns could be addressed by proper configuration > of > Binding Update sending, VPN, header compression, etc. after/prior to the > MIPv6 stack has been activated. > I get suspicious of protocols/systems requiring too much configuration for them to work properly. But this is only my taste. alessio From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 8 07:55:04 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04902 for ; Mon, 8 May 2000 07:55:03 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AB8E1E80@standards.nortelnetworks.com>; Mon, 8 May 2000 7:47:33 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 49126 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 8 May 2000 07:46:50 -0400 Received: from monza.broadswitch.com (195.178.164.73) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2BA2E2B0@standards.nortelnetworks.com>; Mon, 8 May 2000 7:36:49 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <45AFD48D077ED211BB4700A0C9DCE8FD28A4DF@monza.broadswitch.com> Date: Mon, 8 May 2000 13:43:35 +0200 Reply-To: Thomas Eklund Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Thomas Eklund Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question X-To: "Casati, Alessio (Alessio)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi, > > > In addition, would the WG like to add the > > > option to let the CoR do reverse tunneling, just > > > to save radio resources? That is good for V4, > > > I think that would be even better for V6, as the header > > > size is quite bigger. > > > > The radio resource saving is a general concern, not a MIP > specific thing. > > Therefore it should be attacked by using header > compression. The FA in > > MIPv4 > > is there mainly as an care-of address distributor, which is > not needed in > > MIPv6 anymore since we have address autoconfiguration. > > > Good, so tell ROHC to compress IP/IP headers. (I was not ruling > out compression of the user IP packet, after it was stripped off > from the encapsulating header). I'm not sure that we can compress > IPsec stuff, though. Try to check that. You cant compress an encrypted header or payload... Because when you do compression you want to compress patterns in your data that is predictable and in the header of field that are not changing or fields that change in a controlled manner... If you have an encrypted packet these pattern dont exist and it is practically impossible to compress... > > > > Another item for discussion is: > > > How much is acceptable for a corporation > > > that a mobile node uses an IP address topologically > > > not belonging to the corporate net when sending packets as it is > > > away from home but still logically part of the corporate > > > network? Does it make corporate security policies enforcement > > > more complex? do we have any V6 firewall expert to provide help? > > > > I'm neither a firewall nor a security gateway expert, but > IMHO I think > > this > > is solved by having the Mobile Node apply the corporate > security policies > > for every sent and received datagram. > > > Well, I already hear network administrators > having some doubt on this. This is described in the updated AAAv6 draft - i.e how you dynamically update your packet and service filters of the authenticated user and the authorized services.... (it will be re-submitted within a week or so..) Regards Thomas From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 8 08:02:07 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05131 for ; Mon, 8 May 2000 08:02:07 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A7B386F0@standards.nortelnetworks.com>; Mon, 8 May 2000 7:54:36 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 49133 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 8 May 2000 07:53:29 -0400 Received: from monza.broadswitch.com (195.178.164.73) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.19BF4E70@standards.nortelnetworks.com>; Mon, 8 May 2000 7:43:28 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <45AFD48D077ED211BB4700A0C9DCE8FD28A4E0@monza.broadswitch.com> Date: Mon, 8 May 2000 13:50:14 +0200 Reply-To: Thomas Eklund Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Thomas Eklund Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question X-To: "Casati, Alessio (Alessio)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Well I think that the scalable address architechture IS a major difference compared to v4 which you can take advantage of if you run mobile ipv6... But to be honest you could achieve the same thing with ipv4 if you re-assign the whole IPv4 based Internet (and we know that that will never happen) and handed out the addresses in a hierarchical way and made CIDR and route agregation mandatory... Regards Thomas > > Thom, could you stick to the discussion topics and avoid > megastatements > on the virtues of IPv6 (which we are not discussing here). > > It seems to me that we have a bunch of people that feel very hurt > when one expresses comments on *V6. > > We are here to work on *V6 to make it ready for deployment. > > > alessio > > > ---------- > > From: Thomas Eklund[SMTP:thomas.eklund@SWITCHCORE.COM] > > Reply To: Thomas Eklund > > Sent: 08 May 2000 10:22 > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question > > > > Hi Fred, > > Besides route optimazation that you pointed out - mobile > ipv6 can get > > scaling benefits out of the hiearchical address > architecture that ipv6 > > have. > > And those scaling benefits can be HUGE if you use ipv6 in > large networks > > like inside a GPRS operator or CDMA2000 operator.... > > It is also much easier to enforce ingress filtering in the > routers in the > > vistited subnetworks... > > Regards Thomas > > > > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 8 08:21:22 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05686 for ; Mon, 8 May 2000 08:21:22 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.534879B0@standards.nortelnetworks.com>; Mon, 8 May 2000 8:13:43 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 49264 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 8 May 2000 08:12:22 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.22BBBBE0@standards.nortelnetworks.com>; Mon, 8 May 2000 8:12:22 -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 GAA14619; Mon, 8 May 2000 06:18:43 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA12155; Mon, 8 May 2000 05:18: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 FAA22616; Mon, 8 May 2000 05:18:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Mon, 8 May 2000 05:18:33 -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] IPv6 Mobility Last Call Question X-To: Thomas Eklund To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <45AFD48D077ED211BB4700A0C9DCE8FD28A4DA@monza.broadswitch.com> > > > > > -Turn off sending BUs > This option is like saying turn off toute optimazation, but why do you want > to do that when you have support for it? > Even a tiny thin client have enough memory for its CN's.... Security and Privacy. First off, I may know want everyone that I communicate with what my current geographic position is, and chances are they can get a pretty good idea given my IP address. So, BU MUST be able to be turned off. Second, Short of having all of the v6 nodes in the network share some secret, or having the promised great unified PKI in the sky, route optimization will not be used by most clients due to lack of secure communication. So, until we can all trust each other, BU MUST be able to be turned off. My 2 cents, PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 8 08:32:36 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05983 for ; Mon, 8 May 2000 08:32:35 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.737B0260@standards.nortelnetworks.com>; Mon, 8 May 2000 8:21:47 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 49307 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 8 May 2000 08:20:20 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3FB7D1B0@standards.nortelnetworks.com>; Mon, 8 May 2000 8:20:20 -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 GAA19417; Mon, 8 May 2000 06:27:04 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA16960; Mon, 8 May 2000 05:26:51 -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 FAA22758; Mon, 8 May 2000 05:26:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Mon, 8 May 2000 05:26:48 -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] IPv6 Mobility Last Call Question X-To: patrik.flykt@NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" > > > Another item for discussion is: > > How much is acceptable for a corporation > > that a mobile node uses an IP address topologically > > not belonging to the corporate net when sending packets as it is > > away from home but still logically part of the corporate > > network? Does it make corporate security policies enforcement > > more complex? do we have any V6 firewall expert to provide help? > > I'm neither a firewall nor a security gateway expert, but IMHO I think this > is solved by having the Mobile Node apply the corporate security policies > for every sent and received datagram. I also thing this is an IPsec issue > irrelevant if MIP is used or not. I agree that MNs tend to move somewhat > more than hosts leasing addresses with DHCP, which is why this issue pops up > when MIP is discussed. > I would argue that it is impossible for a corporate network for remotely enforce their policies on a mobile node. This is especially true if I own the mobile node :). Seriously corporate networks will expect that their "road warrior" are subjected to the same policies as their fixed terminals. This is sad, but true, and has nothing to do with IPsec, per say, unless you are stating that they could simply tunnel to the corporate network. However, I would like to add that there are MANY corporate networks that would prefer NOT to let the Mobile decide that it must initiate a tunnel in order to be subjected to policies. I could easily envision someone, myself as an example, simply ignoring the IPsec portion, and start using the 'net. Of course, getting access to internal resources may be very difficult :) So, I guess what I am saying is that network/IS managers will expect to have *some* over the Mobile Nodes that THEY authorize access for. This is REALLY sad, and certainly is against everything I believe in, but unfortunately true. PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 8 09:22:34 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07041 for ; Mon, 8 May 2000 09:22:34 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E13B7580@standards.nortelnetworks.com>; Mon, 8 May 2000 9:14:57 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 49453 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 8 May 2000 09:13:03 -0400 Received: from ish7.ericsson.com.au (203.61.155.111) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9513EA20@standards.nortelnetworks.com>; Mon, 8 May 2000 9:12:49 -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 XAA28254 for ; Mon, 8 May 2000 23:19:15 +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 XAA18505 for ; Mon, 8 May 2000 23:19:39 +1000 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2448.0) id ; Mon, 8 May 2000 23:19:17 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFB8F0.02D3C7DE" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A5089EAFFB@eaubrnt018.epa.ericsson.se> Date: Mon, 8 May 2000 23:19:17 +1000 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question 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_01BFB8F0.02D3C7DE Content-Type: text/plain > Security and Privacy. > > First off, I may know want everyone that I communicate with what my > current > geographic position is, and chances are they can get a pretty good idea > given > my IP address. So, BU MUST be able to be turned off. > Which is already possible today as the spec is written. ------_=_NextPart_001_01BFB8F0.02D3C7DE Content-Type: text/html RE: [MOBILE-IP] IPv6 Mobility Last Call Question

    Security and Privacy.

    First off, I may know want everyone that I communicate with what my current
    geographic position is, and chances are they can get a pretty good idea given
    my IP address. So, BU MUST be able to be turned off.

    Which is already possible today as the spec is written.


------_=_NextPart_001_01BFB8F0.02D3C7DE-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 8 09:30:39 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07175 for ; Mon, 8 May 2000 09:30:38 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.00ACF820@standards.nortelnetworks.com>; Mon, 8 May 2000 9:22:59 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 49448 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 8 May 2000 09:22:10 -0400 Received: from monza.broadswitch.com (195.178.164.73) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7D13F690@standards.nortelnetworks.com>; Mon, 8 May 2000 9:12:09 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <45AFD48D077ED211BB4700A0C9DCE8FD28A4E2@monza.broadswitch.com> Date: Mon, 8 May 2000 15:18:58 +0200 Reply-To: Thomas Eklund Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Thomas Eklund Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question X-To: "pcalhoun@eng.sun.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi Pat, > > > > > -Turn off sending BUs > > This option is like saying turn off toute optimazation, but > why do you want > > to do that when you have support for it? > > Even a tiny thin client have enough memory for its CN's.... > Security and Privacy. > > First off, I may know want everyone that I communicate with > what my current > geographic position is, and chances are they can get a pretty > good idea given > my IP address. So, BU MUST be able to be turned off. I dont agree. In ipv6 you have the address diveded into two parts and it is only of interest to a "spoofer" what your lower 64 bits are (i.e. your interface id or EUI-64).. And there is a draft how you add privacy to the interface part (http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addrconf-privacy-01.t xt*) That means that you cant be tracked... Eventhough a spoofer sees where the packets comes from he cant reveil from who it is originated... In other words there are already a solution to the privacy issue... So the privacy issue is not an valid for having the BU turned off... > > Second, Short of having all of the v6 nodes in the network > share some secret, Well my guess is that when you roll out all the SIM card you will have your shared secret already there and your fixed IPv6 address from your home ISP... > or having the promised great unified PKI in the sky, route > optimization will > not be used by most clients due to lack of secure > communication. So, until we > can all trust each other, BU MUST be able to be turned off. If you are communicating with a IPv6 CN you know that it has support for IPsec.. This might be the case in GPRS... People are discussing to add IPv6 in release 2000 of GPRS and my guess is that it will be part of that. Then the operators can use IPv6 inside their private networks today and have a future proof solution... They can start giving out ipv6 address that are globaly unique and get all the scaling benefits and get rid of the NAT related problems with using private IPv4 address... It should also be noted that Windows_2000 will support IPv6 in the next release... > > My 2 cents, > > PatC My 3 cents ...:-) Regards Thomas From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 8 10:29:35 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08537 for ; Mon, 8 May 2000 10:29:35 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2B5AE5C0@standards.nortelnetworks.com>; Mon, 8 May 2000 10:21:27 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 49836 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 8 May 2000 10:21:22 -0400 Received: from sj-msg-core-1.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.284CE270@standards.nortelnetworks.com>; Mon, 8 May 2000 10:21:22 -0400 Received: from rhino (rhino.cisco.com [172.20.9.57]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA11984; Mon, 8 May 2000 07:28:21 -0700 (PDT) Received: from p7020-img-nt.cisco.com ([171.69.128.116]) by rhino (SMI-8.6/CISCO.WS.1.1) with ESMTP id OAA09870; Thu, 4 May 2000 14:18:13 -0700 X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.3.1.2.20000504135526.00ccc2c0@flipper.cisco.com> Date: Thu, 4 May 2000 13:57:35 -0700 Reply-To: Fred Baker Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Fred Baker Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question X-To: "Casati, Alessio (Alessio)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <976F7C55E3B2D111A0720008C728549C04876BBE@en0060exch001u.uk .lucent.com> At 09:26 PM 5/4/00 +0100, Casati, Alessio (Alessio) wrote: >Could attempt an answer: say you own a corporation and have a lot >of employees. It's nice to provide them with corporate net access >when they are on the road, but you don't like 'em to mess too >much with company data and want to enforce the same policies >you usally enforce when they are at home via firewalls. > >Well, I would claim all the traffic from the road warrior >should be controlled and if it is not tunneled back, say it's >forced to take a route back home before (possibly) going >out the internet. I can imagine some benighted corporation making that rule for its employees. Are you telling me that because some company might someday be that obnoxious to its own employees, then that should be fundamental to the protocol and hobble its scalability for more normal purposes? I hope you don't quite mean that. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 8 10:34:58 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08680 for ; Mon, 8 May 2000 10:34:57 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7347FBC0@standards.nortelnetworks.com>; Mon, 8 May 2000 10:23:28 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 49848 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 8 May 2000 10:22:15 -0400 Received: from sj-msg-core-1.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.47B6B960@standards.nortelnetworks.com>; Mon, 8 May 2000 10:22:15 -0400 Received: from rhino (rhino.cisco.com [172.20.9.57]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA12422; Mon, 8 May 2000 07:29:13 -0700 (PDT) Received: from p7020-img-nt.cisco.com ([171.69.128.116]) by rhino (SMI-8.6/CISCO.WS.1.1) with ESMTP id QAA09391; Wed, 3 May 2000 16:15:39 -0700 X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.3.1.2.20000503155727.0282d200@flipper.cisco.com> Date: Wed, 3 May 2000 16:07:58 -0700 Reply-To: Fred Baker Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Fred Baker Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question X-To: "Casati, Alessio (Alessio)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <976F7C55E3B2D111A0720008C728549C04876BA8@en0060exch001u.uk .lucent.com> At 02:26 PM 5/3/00 +0100, Casati, Alessio (Alessio) wrote: >Why would a v6 mobility scale better than a v4? Tell me if I misunderstand. It is my understanding that in IP4 mobility, every packet goes through the home agent, while in IP6 mobility, the call is set up through the home agent but after that packets go directly to the care-of router. In IP4, the home agent is a single point of failure for every packet going to the mobile device. In IP6, it is a single point of failure only for sessions being set up to the mobile device, and presumably if I have multiple sessions to that device in parallel I could maintain some form of super-state that knows the care-of router for all of them together. We're talking at least one order of magnitude (mean session being on the order of ten packets each direction), probably two (accounting for aggregated sessions and larger files). >I'm sure you need to store some info at home and in the correspondent nodes. Yes, of course - a key aspect of mobility is that it has to know where the mobile device is *right now*. But how often do you have to use it? By the way, for the other solutions you also need some form of routing state. You need to know the addresses you have positioned at the far end of MPLS tunnels or whatever, and keep that correlation. And like V4 mobility (if I understand it) the link into the ISP must be as large as all the traffic that its users need to send at any given time with the routing solutions. The nice thing I see about IP6 mobility (if I understand it) is that we use the distributed characteristics of the Internet architecture to make that link and processing bottleneck not exist. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 8 10:52:59 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08539 for ; Mon, 8 May 2000 10:29:35 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2B837C60@standards.nortelnetworks.com>; Mon, 8 May 2000 10:21:27 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 49839 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 8 May 2000 10:21:25 -0400 Received: from sj-msg-core-1.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.29C32EC0@standards.nortelnetworks.com>; Mon, 8 May 2000 10:21:24 -0400 Received: from rhino (rhino.cisco.com [172.20.9.57]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA12035; Mon, 8 May 2000 07:28:23 -0700 (PDT) Received: from p7020-img-nt.cisco.com ([171.69.128.116]) by rhino (SMI-8.6/CISCO.WS.1.1) with ESMTP id MAA09825; Thu, 4 May 2000 12:15:38 -0700 X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 References: <200005021424.HAA24772@nasnfs.eng.sun.com> <200005021424.HAA24772@nasnfs.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.3.1.2.20000504110718.03614cb0@flipper.cisco.com> Date: Thu, 4 May 2000 11:10:37 -0700 Reply-To: Fred Baker Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Fred Baker Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question X-To: Pete McCann To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <20000504160006.98CF857042@king.research.bell-labs.com> At 11:00 AM 5/4/00 -0500, Pete McCann wrote: >Such an entity would actually facilitate the kind of "ISP open access" >that Fred described, rather than hindering it. It could make sure >that all traffic from a given user was tunneled back to a home >network, by integrating the Mobile IP registration process with some >kind of firewall features. Would that be an objective? I think the user would generally like to be able to get his address from the ISP and access the services (which he pays for) that the ISP offers, but in generally he has no desire that his traffic go through the ISP. If they can go straight to the peer through the intervening network, and avoid having a single point of failure or congestion, he's happiest. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 8 11:07:24 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09286 for ; Mon, 8 May 2000 11:07:23 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.60949790@standards.nortelnetworks.com>; Mon, 8 May 2000 10:58:44 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 50054 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 8 May 2000 10:56:44 -0400 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.190224B0@standards.nortelnetworks.com>; Mon, 8 May 2000 10:56:44 -0400 Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch1.nortel.com; Mon, 8 May 2000 09:57:38 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 8 May 2000 09:57:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFB8FD.BA2D6B9E" Message-ID: <40DC7CF03BDDD3118F3D0000F806EEEC4F2F6E@zrchb199.us.nortel.com> Date: Mon, 8 May 2000 09:57:21 -0500 Reply-To: Haseeb Akhtar Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Haseeb Akhtar Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question 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_01BFB8FD.BA2D6B9E Content-Type: text/plain > It is my understanding that in IP4 mobility, every packet goes through the > home agent, while in IP6 mobility, the call is set up through the home > agent but after that packets go directly to the care-of router. > This can be avoided with route optimization added to the IPv4 solution. That is, after the first packet, the rest of the packets from the CN will directly go to the MN's COA. Haseeb ------_=_NextPart_001_01BFB8FD.BA2D6B9E Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] IPv6 Mobility Last Call Question

    It is my understanding that in IP4 = mobility, every packet goes through the
    home agent, while in IP6 mobility, = the call is set up through the home
    agent but after that packets go = directly to the care-of router.

    This can be avoided = with route optimization added to the IPv4 solution. That is, after the = first
    packet, the rest of = the packets from the CN will directly go to the MN's COA.=20

    Haseeb

------_=_NextPart_001_01BFB8FD.BA2D6B9E-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 8 11:37:30 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09885 for ; Mon, 8 May 2000 11:37:30 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BC65DA80@standards.nortelnetworks.com>; Mon, 8 May 2000 11:29:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 50205 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 8 May 2000 11:28:28 -0400 Received: from smtprch2.nortel.com (192.135.215.15) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.881AB520@standards.nortelnetworks.com>; Mon, 8 May 2000 11:28:28 -0400 Received: from smtprich.nortel.com (actually zrchs148) by smtprch2.nortel.com; Mon, 8 May 2000 10:28:31 -0500 Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprich.nortel.com; Tue, 2 May 2000 14:44:48 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 2 May 2000 14:53:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFB470.14B02C10" X-Orig: X-Orig: Message-ID: <9A9367D1556AD21182C40000F80930AB0272B5F2@crchy28b.us.nortel.com> Date: Tue, 2 May 2000 14:53:21 -0500 Reply-To: Raja Narayanan Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Raja Narayanan Subject: Re: [MOBILE-IP] Hand-over resend 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_01BFB470.14B02C10 Content-Type: text/plain; charset="iso-8859-1" I agree with this viewpoint....especially the last paragraph. --Raja -----Original Message----- From: C. Perkins/D. Reese [mailto:charliep@IPRG.NOKIA.COM] Sent: Tuesday, May 02, 2000 1:48 PM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] Hand-over resend Hello Andrew, I think it would be a mistake to limit the involvement of 3G proponents. Instead, I would hope that we would identify the correct charter items, and solicit input from all interested parties along the way towards fulfilling the charter work items. Just as an example -- if, for instance, some 3G folks need to have certain Route Optimization features that are independent of the access medium, that is a discussion which belongs here. Part of the reason I am reacting to this is that I have spent a lot of time encouraging 3G engineers to get more involved with the mobile-ip working group. They should be welcomed, and we should all make sure that we understand clearly the goals of the working group. One notable difference is that the mobile-ip working group is mostly chartered to do protocols, whereas 3G standardization groups also have to put together system architectures. Thus, they are likely to notice when a protocol component is missing. That is good information for us to know. Regards, Charlie P. "Andrew T. Campbell" wrote: > Phil: > > Following up on your note: > > I think it would be a mistake to have the Mobile IP Working > Group do a 3GIP kind of thing or be a vehicle for 2/3G > transition to wireless Internet. > > The Mobile IP WG should charter 4GIP: pure unadulterated > IP packet networks based on Mobile IP and packets to > and from the mobile host using best effort service. > > I think too much 3G influence in the group may > be a distraction from that. > > Andrew ------_=_NextPart_001_01BFB470.14B02C10 Content-Type: text/html; charset="iso-8859-1" RE: [MOBILE-IP] Hand-over resend

I agree with this viewpoint....especially the last paragraph.

--Raja


-----Original Message-----
From: C. Perkins/D. Reese [mailto:charliep@IPRG.NOKIA.COM]
Sent: Tuesday, May 02, 2000 1:48 PM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: Re: [MOBILE-IP] Hand-over resend


Hello Andrew,

I think it would be a mistake to limit the involvement of
3G proponents.  Instead, I would hope that we would
identify the correct charter items, and solicit input from
all interested parties along the way towards fulfilling
the charter work items.  Just as an example -- if, for
instance, some 3G folks need to have certain Route
Optimization features that are independent of the access
medium, that is a discussion which belongs here.

Part of the reason I am reacting to this is that I have
spent a lot of time encouraging 3G engineers to get
more involved with the mobile-ip working group.
They should be welcomed, and we should all make
sure that we understand clearly the goals of the working
group.

One notable difference is that the mobile-ip working
group is mostly chartered to do protocols, whereas
3G standardization groups also have to put together
system architectures.  Thus, they are likely to notice
when a protocol component is missing.  That is good
information for us to know.

Regards,
Charlie P.



"Andrew T. Campbell" wrote:

> Phil:
>
> Following up on your note:
>
> I think it would be a mistake to have the Mobile IP Working
> Group do a 3GIP kind of thing or be a vehicle for 2/3G
> transition to wireless Internet.
>
> The Mobile IP WG should charter 4GIP: pure unadulterated
> IP packet networks based on Mobile IP and packets to
> and from the mobile host using best effort service.
>
> I think too much 3G influence in the group may
> be a distraction from that.
>
> Andrew

------_=_NextPart_001_01BFB470.14B02C10-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 8 11:44:17 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10031 for ; Mon, 8 May 2000 11:44:17 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4D202D50@standards.nortelnetworks.com>; Mon, 8 May 2000 11:33:59 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 50179 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 8 May 2000 11:32:21 -0400 Received: from ftpbox.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AD1D0040@standards.nortelnetworks.com>; Mon, 8 May 2000 11:22:21 -0400 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id IAA29943 for ; Mon, 8 May 2000 08:29:12 -0700 (MST)] Received: [from il33exm01.wes.mot.com (il33exm01.wes.mot.com [154.56.3.118]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id IAA11759 for ; Mon, 8 May 2000 08:29:10 -0700 (MST)] Received: by il33exm01.wes.mot.com with Internet Mail Service (5.5.2650.21) id <28T0CDG0>; Mon, 8 May 2000 10:29:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <7195C03599D9D311BE580008C75697EB443299@il33exm01.wes.mot.com> Date: Mon, 8 May 2000 10:29:11 -0500 Reply-To: Roberts Phil-QA3445 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Roberts Phil-QA3445 Subject: Re: [MOBILE-IP] Applicability of IP Mobility to CDMA Soft Handoff To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM OK. ATM v. IP is definitely off topic on this list. Take it offline. -----Original Message----- From: Arek Dadej [mailto:Arek.Dadej@UNISA.EDU.AU] Sent: Friday, May 05, 2000 10:32 AM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] Applicability of IP Mobility to CDMA Soft Handoff Andrew, I tend to agree with the first statement (even if it applies to fixed access networks). However, your second statement is rather far going, if you consider switching of high volume, aggregated traffic. Why is it that truly high capacity, gigabit IP routers somehow cannot do without underlying ATM switching? --Arek -----Original Message----- From: Andrew T. Campbell To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Sent: 5/6/00 3:56 AM Subject: Re: [MOBILE-IP] Applicability of IP Mobility to CDMA Soft Handoff My personal view is ATM and virtual cicuits complicate the design of the access network and are not needed. Packet based link layers will win - ATM is dead. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 8 12:20:59 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11044 for ; Mon, 8 May 2000 12:20:59 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CB034040@standards.nortelnetworks.com>; Mon, 8 May 2000 12:13:17 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 50486 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 8 May 2000 12:11:25 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.87A687D0@standards.nortelnetworks.com>; Mon, 8 May 2000 12:11:24 -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 JAA25351; Mon, 8 May 2000 09:18:16 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id JAA26182; Mon, 8 May 2000 09:16:21 -0700 X-Virus-Scanned: Mon, 8 May 2000 09:16:21 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from (charliep.iprg.nokia.com [205.226.2.89]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma026011; Mon, 8 May 00 09:16:17 -0700 X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3916E8C3.53F5B465@iprg.nokia.com> Date: Mon, 8 May 2000 09:18:11 -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 Mobility Last Call Question X-To: "pcalhoun@eng.sun.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Pat, > Second, Short of having all of the v6 nodes in the network share some secret, > or having the promised great unified PKI in the sky, route optimization will > not be used by most clients due to lack of secure communication. So, until we > can all trust each other, BU MUST be able to be turned off. This does not require turning off Binding Updates. It only requires that binding updates should not be sent if they cannot be accompanied by unforgeable credentials. Furthermore, I strongly suggest that privacy decisions should be made depending on the correspondent node. Some communications partners are people we are willing to trust with our location information, and some are not. And, finally, some mobile users may be instructed not to trust anyone. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 8 12:24:54 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11141 for ; Mon, 8 May 2000 12:24:54 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5C837B20@standards.nortelnetworks.com>; Mon, 8 May 2000 12:17:21 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 50473 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 8 May 2000 12:16:25 -0400 Received: from imr1.ericy.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D4F79480@standards.nortelnetworks.com>; Mon, 8 May 2000 12:06:24 -0400 Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id LAA11348; Mon, 8 May 2000 11:13:17 -0500 (CDT) Received: from SMTP (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with SMTP id LAA08017; Mon, 8 May 2000 11:13:16 -0500 (CDT) Received: from eamrcnt740.exu.ericsson.se ([138.85.133.41]) by 138.85.133.38 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 08 May 2000 16:13:16 0000 (GMT) Received: by eamrcnt740.exu.ericsson.se with Internet Mail Service (5.5.2448.0) id ; Mon, 8 May 2000 11:13:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Message-ID: <125911DC0503D4119E2400508B0CCD2F0102D820@eamrcnt718.exu.ericsson.se> Date: Mon, 8 May 2000 11:13:09 -0500 Reply-To: "Kevin Purser (EUS)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Kevin Purser (EUS)" Subject: Re: [MOBILE-IP] Mobile IP with Ad Hoc Network X-To: Kumarendra Sivarajah To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello, During the second half of 1999, 2 Masters Thesis projects were carried out within Ericsson Research on the topic. My thesis consisted of a preliminary implementation study with AODV integrated with Mobile IP. The other thesis was able to achieve a more detailed account of AODV/Mobile IP interworking with varying methods through a thorough set of simulations. My report should be available soon on the internet at which time I can let you know, but if you prefer I can email it to you now. Unfortunately, I am unaware of the availability of the other thesis publication. Kevin Purser Software Engineer III ERICSSON, INC. 2100 Shattuck Avenue (Enter on Addison Street) Berkeley, CA 94704-1209 Phone: (510) 305-6100 Fax: (510) 981-4016 > -----Original Message----- > From: Kumarendra Sivarajah [SMTP:ks23@UKC.AC.UK] > Sent: Sunday, May 07, 2000 10:05 AM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: [MOBILE-IP] Mobile IP with Ad Hoc Network > > If anyone has any related papers on the subject Mobile IP with Ad Hoc > Network, I would appreciate if you could reply to my mail. Currently I > only have two papers as below: > -Ad Hoc Networking with Mobile IP by Hui Lei and Charles E Perkins > -Mobile IP, Ad Hoc Networking and Nomadicity by Charles E Perkins > Also has anyone done any simulation on combination of both mobile IP with > Ad Hoc network, could you also please reply to me. Thank you > > Indran From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 8 12:57:16 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11942 for ; Mon, 8 May 2000 12:57:16 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DE1B0000@standards.nortelnetworks.com>; Mon, 8 May 2000 12:49:37 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 50745 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 8 May 2000 12:48:12 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AB62AFA0@standards.nortelnetworks.com>; Mon, 8 May 2000 12:48:12 -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 KAA25259 for ; Mon, 8 May 2000 10:55:04 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA06759; Mon, 8 May 2000 09:54: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 JAA29568; Mon, 8 May 2000 09:54:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 8mJy6ez8hck+8frhFxLlgw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Message-ID: <200005081654.JAA29568@nasnfs.eng.sun.com> Date: Mon, 8 May 2000 09:57:43 -0700 Reply-To: James Kempf Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: James Kempf Subject: Re: [MOBILE-IP] Some comments on draft-kempf-cdma-appl-00.txt X-To: sarikaya@U-AIZU.AC.JP To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM >it is easy to understand and appreciate its conclusion, in short this >draft is not a bombshell >trying to invalidate Mobile IP in cellular networks. > That wasn't the intention. The intention was to question the applicability of Mobile IP in radio *access* networks. There are other places in cellular networks where mobile IP has a very big role to play (namely hard handoff). The draft says something to that effect, but maybe it should be more strongly worded. >The typos are: >1. base station should be replaced by base transceiver station or BTS >everywhere. BTS is 3GPP2 terminology. The equivalent 3GPP terminology is Node B. We were trying to be agnostic, hence, we used terminology that was different from both. >2. RAN should probably be replaced by base station controller or BSC in >most places. Again, BSC is 3GPP2 terminiology. And RAN implies the entire radio access network, including (in 3GPP2 terminology) the BSC, BTS, the wires or optical fiber connecting them, and the connection between one BSC and another, not simply the BSC. >3. that soft handoff is an application layer mechanism should be >replaced by L2 mechanism in at least two places. > This is debatable. If you look at the current 3GPP design (for example), the protocol that does soft handoff (NBAP) runs on top of SCCS-UNI/SCCOP which is (I presume) the transport layer and network layer, and that runs on top of AAL5, which is L2. So in the current networks, soft handoff is being done above L2. I suppose to be technically congruent with the OSI model, we should have said "session layer" instead of "application layer". The 3GPP protocol stack actually has a couple places in the control plane where SCTP over IP over ATM is a supported option for L4/L3/L2. We should probably include this example to support our claim about soft handoff. jak From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 8 13:19:18 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12410 for ; Mon, 8 May 2000 13:19:17 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F4C06540@standards.nortelnetworks.com>; Mon, 8 May 2000 13:11:43 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 50828 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 8 May 2000 13:11:39 -0400 Received: from hoemail2.firewall.lucent.com (192.11.226.163) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F1F2C650@standards.nortelnetworks.com>; Mon, 8 May 2000 13:11:39 -0400 Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA19858 for ; Mon, 8 May 2000 13:18:32 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA19839 for ; Mon, 8 May 2000 13:18:31 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2448.0) id ; Mon, 8 May 2000 18:18:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Message-ID: <976F7C55E3B2D111A0720008C728549C04876BE9@en0060exch001u.uk.lucent.com> Date: Mon, 8 May 2000 18:18:19 +0100 Reply-To: "Casati, Alessio (Alessio)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Casati, Alessio (Alessio)" Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Furthermore, I strongly suggest that privacy decisions should > be made depending on the correspondent node. Some communications > partners are people we are willing to trust with our location > information, and some are not. And, finally, some mobile users > may be instructed not to trust anyone. > > Charlie, About location privacy: even if we don't send binding updates, and even if we don't trust the CN, the CN ill kno enough info from the link prefix included in the COA. So, correlating application layer info with the prefix the CN can know the link we are at. This even if we have the non prefix info randomly change as we move from link to link. Alessio From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 8 14:34:33 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14674 for ; Mon, 8 May 2000 14:34:33 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.76BCB7B0@standards.nortelnetworks.com>; Mon, 8 May 2000 14:26:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 51005 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 8 May 2000 14:25:10 -0400 Received: from dirty.research.bell-labs.com (204.178.16.6) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.36EEA440@standards.nortelnetworks.com>; Mon, 8 May 2000 14:25:09 -0400 Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Mon May 8 14:31:02 EDT 2000 Received: from king.research.bell-labs.com ([135.1.152.1]) by grubby; Mon May 8 14:31:02 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 5356057042; Mon, 8 May 2000 13:31:01 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <200005021424.HAA24772@nasnfs.eng.sun.com> <20000504160006.98CF857042@king.research.bell-labs.com> <4.3.1.2.20000504110718.03614cb0@flipper.cisco.com> X-Mailer: VM 6.33 under Emacs 19.34.2 Message-ID: <20000508183101.5356057042@king.research.bell-labs.com> Date: Mon, 8 May 2000 13:31:01 -0500 Reply-To: Pete McCann Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Pete McCann Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question X-To: Fred Baker To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <4.3.1.2.20000504110718.03614cb0@flipper.cisco.com> Content-Transfer-Encoding: 7bit Hi, Fred, Fred Baker (FB) writes: FB> At 11:00 AM 5/4/00 -0500, Pete McCann wrote: >> Such an entity would actually facilitate the kind of "ISP open access" >> that Fred described, rather than hindering it. It could make sure >> that all traffic from a given user was tunneled back to a home >> network, by integrating the Mobile IP registration process with some >> kind of firewall features. FB> Would that be an objective? I think the user would generally like to be FB> able to get his address from the ISP and access the services (which he pays FB> for) that the ISP offers, but in generally he has no desire that his FB> traffic go through the ISP. If they can go straight to the peer through the FB> intervening network, and avoid having a single point of failure or FB> congestion, he's happiest. It sounds really strange that I would be paying an ISP who doesn't transit my traffic. If you look at what ISPs are doing today with the wired telephony plant (DSL), they are tunneling at link layer (through ethernet bridging or PPP relay) from a CO to their point of Internet connectivity. Often this is done over an ATM network or some other network, in a way that is completely transparent to the end customer. Such tunnels have to be provisioned manually in cooperation with the company that owns the co-located termination equipment at the CO. Applying Mobile IP to this scenario, we *could* (and this is just speculation) begin to use Mobile IP as a way to dynamically establish these bindings, and as a uniform way to present credentials on any kind of network (it's link layer independent). Then we could simultaneously tell the CO who we are, where our home network is, and how to establish a tunnel to that home network with one round-trip of messages. In this case the equipment at the CO might be prohibited (by law) from routing my packets directly on the Internet, or from providing me any kind of Internet-like service (including DHCP). -Pete From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 8 15:03:34 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15622 for ; Mon, 8 May 2000 15:03:34 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8949B910@standards.nortelnetworks.com>; Mon, 8 May 2000 14:56:05 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 51110 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 8 May 2000 14:55:03 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.63FF5DE0@standards.nortelnetworks.com>; Mon, 8 May 2000 14:55:03 -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 MAA13971; Mon, 8 May 2000 12:00:10 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id LAA14899; Mon, 8 May 2000 11:57:46 -0700 X-Virus-Scanned: Mon, 8 May 2000 11:57:46 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from (charliep.iprg.nokia.com [205.226.2.89]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma014416; Mon, 8 May 00 11:57:36 -0700 X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <200005021424.HAA24772@nasnfs.eng.sun.com> <20000504160006.98CF857042@king.research.bell-labs.com> <4.3.1.2.20000504110718.03614cb0@flipper.cisco.com> <20000508183101.5356057042@king.research.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39170EAF.365DA774@iprg.nokia.com> Date: Mon, 8 May 2000 11:59:59 -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 Mobility Last Call Question X-To: Pete McCann To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Pete, > It sounds really strange that I would be paying an ISP who doesn't > transit my traffic. It sounds even stranger to reroute traffic just to make busywork for some router in a galaxy far, far away. > Applying Mobile IP to this scenario, we *could* (and this is just > speculation) begin to use Mobile IP as a way to dynamically establish > these bindings, and as a uniform way to present credentials on any > kind of network (it's link layer independent). Then we could > simultaneously tell the CO who we are, where our home network is, and > how to establish a tunnel to that home network with one round-trip of > messages. In this case the equipment at the CO might be prohibited > (by law) from routing my packets directly on the Internet, or from > providing me any kind of Internet-like service (including DHCP). This could be done just as you say without requiring all traffic to go down the tunnel to the home network. So what is illegal about doing it one way or another? Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 8 15:35:26 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16667 for ; Mon, 8 May 2000 15:35:26 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BE770440@standards.nortelnetworks.com>; Mon, 8 May 2000 15:26:13 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 51197 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 8 May 2000 15:25:17 -0400 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9BBC54A0@standards.nortelnetworks.com>; Mon, 8 May 2000 15:25:14 -0400 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA21718 for ; Mon, 8 May 2000 12:32:07 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.89.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id MAA05599 for ; Mon, 8 May 2000 12:32:07 -0700 (PDT) Received: (from samita@localhost) by jurassic.eng.sun.com (8.10.1+Sun/8.10.1) id e48JW6T786396; Mon, 8 May 2000 12:32:06 -0700 (PDT) X-Sun-Charset: US-ASCII Message-ID: <200005081932.e48JW6T786396@jurassic.eng.sun.com> Date: Mon, 8 May 2000 12:32:06 -0700 Reply-To: Samita Chakrabarti Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Samita Chakrabarti Subject: [MOBILE-IP] Encapsulating delivery style in reverse tunnel draft X-cc: samita@jurassic.Eng.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello folks: Currently rfc2344-bis requires foreign agent to support EDS (encapsulating delivery style) and DDS (direct delivery style) when 'T' bit is turned on in the agent advertisement. " A foreign agent that sets the 'T' bit MUST support the two delivery styles currently supported: Direct and Encapsulating Delivery Style (section 5)." Since we are revisiting the draft, I wonder if it makes sense to relax the 'MUST' to 'SHOULD' for simplicity in FA. I understand that, it may introduce some delay in MN side, if a MN wants to use EDS and the FA is a DDS only agent. Also I know that there are not enough bits left in the agent advertisement to distinguish between two reverse tunnel modes. On the other hand, if most MNs use DDS only then perhaps, EDS support may be an optional choice for FA's implementation. I have discussed this question internally with some folks and would like to know if the working group has any strong opinion in changing the requirement from 'MUST' to 'SHOULD'. Attached is excerpt of Gabriel's response on this discussion. -Samita ----- Begin Included Message ----- Date: Thu, 4 May 2000 13:55:31 -0700 (PDT) From: Gabriel Montenegro Subject: Re: Encapsulating delivery style in reverse tunnel draft To: Samita Chakrabarti MIME-Version: 1.0 about EDS (encapsulating delivery style) vs DDS (direct delivery style): the consensus was that it was simpler (at least from one point of view) to require EDS and DDS as a unified 'reverse tunneling' bundle instead of then having the additional problem of resolving which flavor of it was supported. so yes, you'd need additional error codes, at least. perhaps you'd need additional info in the advertisement if you want the mobile node to not attempt registration with a DDS-only FA, if what it needs is EDS. We even joked once that this could be accomplished by overloading the 'T' bit thus: capital 'T': EDS (and DDS) supported small 't': DDS only the alternative was to use more than one bit in the advertisement, but that's probably out of the question. i had at one time defined an extension to the advertisement with which the FA explicitly announced support for EDS (in addition to DDS). the 'T' bit by itself would then only imply DDS support. we'd need new error codes as well. not a major thing, though. as always, it's a tradeoff, perhaps it's worth revisiting. i'd suggest you bring this up in the mailing list, and if there's strong sentiment that we should allow DDS-only FA's then we could do that now that we're revising rfc2344. feel free to forward some or part of this email if you wish. -gabriel ----- End Included Message ----- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 8 15:39:39 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16783 for ; Mon, 8 May 2000 15:39:38 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.97801510@standards.nortelnetworks.com>; Mon, 8 May 2000 15:32:17 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 51251 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 8 May 2000 15:31:08 -0400 Received: from dirty.research.bell-labs.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6E61CE80@standards.nortelnetworks.com>; Mon, 8 May 2000 15:31:08 -0400 Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Mon May 8 15:36:57 EDT 2000 Received: from king.research.bell-labs.com ([135.1.152.1]) by grubby; Mon May 8 15:36:57 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 6F85957042; Mon, 8 May 2000 14:36:56 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <200005021424.HAA24772@nasnfs.eng.sun.com> <20000504160006.98CF857042@king.research.bell-labs.com> <4.3.1.2.20000504110718.03614cb0@flipper.cisco.com> <20000508183101.5356057042@king.research.bell-labs.com> <39170EAF.365DA774@iprg.nokia.com> X-Mailer: VM 6.33 under Emacs 19.34.2 Message-ID: <20000508193656.6F85957042@king.research.bell-labs.com> Date: Mon, 8 May 2000 14:36:56 -0500 Reply-To: Pete McCann Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Pete McCann Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question X-To: charliep@IPRG.NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <39170EAF.365DA774@iprg.nokia.com> Content-Transfer-Encoding: 7bit Hi, Charles, "Charles E. Perkins" (CEP) writes: CEP> Hello Pete, >> It sounds really strange that I would be paying an ISP who doesn't >> transit my traffic. CEP> It sounds even stranger to reroute traffic just to make busywork CEP> for some router in a galaxy far, far away. The most straightforward approach is of course to get Internet service directly from my point of connectivity at the CO - but then there is no such thing as "open access." I'm not sure this list is the place for a public policy debate, but I was just trying to point out some (silly) scenarios where I would be forced to pay a third party service provider for providing essentially no service - if I could get some services directly, why not just get them all? Also, I was trying to make a comparison to what is done today with transparent, layer-2 tunnels between a CO and an ISP. Maybe these tunnels should all just go away, since they are inefficient and legacies of the old circuit world anyway? :) >> Applying Mobile IP to this scenario, we *could* (and this is just >> speculation) begin to use Mobile IP as a way to dynamically establish >> these bindings, and as a uniform way to present credentials on any >> kind of network (it's link layer independent). Then we could >> simultaneously tell the CO who we are, where our home network is, and >> how to establish a tunnel to that home network with one round-trip of >> messages. In this case the equipment at the CO might be prohibited >> (by law) from routing my packets directly on the Internet, or from >> providing me any kind of Internet-like service (including DHCP). CEP> This could be done just as you say without requiring all traffic CEP> to go down the tunnel to the home network. So what is illegal CEP> about doing it one way or another? Nothing specifically - laws can be pretty arbitrary. I was just positing one state of the world where the law was written that way. This state of the world is somewhat similar to what we have today with distinct ISPs and telcos, but it could always change. Note that there might be other more technical reasons (security policies, as Alessio has been pointing out) for wanting to see all the traffic that you, as a home network or ISP, are paying the visited network to transit. We can argue about whether such requirements are "good" or "bad" from the end user's or network utilization point of view, but as Pat points out those requirements still exist. -Pete From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 8 18:10:15 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21112 for ; Mon, 8 May 2000 18:10:15 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9BD81800@standards.nortelnetworks.com>; Mon, 8 May 2000 18:02:43 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 51561 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 8 May 2000 18:00:49 -0400 Received: from mail.hrn.ascend.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.57A6F890@standards.nortelnetworks.com>; Mon, 8 May 2000 18:00:49 -0400 Received: from awalker2 (amanda-pad.eng.hrn.ascend.com [149.52.12.188]) by mail.hrn.ascend.com (8.9.3/8.9.3) with ESMTP id SAA26014 for ; Mon, 8 May 2000 18:07:43 -0400 (EDT) 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.2919.6700 Importance: Normal Message-ID: Date: Mon, 8 May 2000 18:07:45 -0400 Reply-To: Amanda Walker Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Amanda Walker Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <20000508193656.6F85957042@king.research.bell-labs.com> Content-Transfer-Encoding: 7bit > We can argue about whether such requirements are > "good" or "bad" from the end user's or network utilization point of > view, but as Pat points out those requirements still exist. Indeed. Many of the problems at hand are not technical. They are policy problems (both public and private) relating to things like liability, billing, the responsibilities of common carriers vs. private carriers, branding, and so on. From a purely technical point of view, tunneling traffic around (at layer 2, layer 3, or however else) is inefficient. However, it is often the simplest way to solve administrative problems, especially when raw bandwidth is not the tightest constraint (which, often, it is not). It's like wholesale vs. retail of phsyical goods. It's more efficient, in some sense, for me to buy food from the farms at which it is produced. However, the farmer is equipped for production--not packaging, freshness control, and accounting for taxes on individual sales. Similarly, a carrier may be quite well equipped to maintain a high performance network, but not at all equipped to handle front-line consumer tech support, individual billing and accounting, promotional deals, etc. An ISP may want to concentrate on supporting and maintaining a loyal customer base rather than on whether they need to lease more fiber between Atlanta and New York. So they make a deal where each concentrates on what they do best. To take a real-world example (one of many): When John Q. Public dials up AOL, his traffic gets tunneled from a UUNET POP, over UUNET's network to AOL, and then probably back out onto UUNET's network to get to a web site he wants to visit: yes, this is in a network traffic sense inefficient. But that's OK with both UUNET and AOL. It solves business problems at the price of a little extra bandwidth. UUNET doesn't want consumer customers, and AOL doesn't want to have to maintain POPs all over the world. The consumer wins, because from an administrative point of view, AOL does have POPs all over the world that he can dial up to and be connected to his service. The fact that the traffic is being tunneled for part of its journey is irrelevant. The same argument can be made about IP mobility reverse tunneling: yes, it seems inefficient to people who are used to bandwidth being the scarce resource. However, that is often not the case. Even with non-mobile IPv4, a lot of network traffic is tunneled in various ways for purely administrative and business purposes these days. It is no longer at all the case that physical connectivity and administrative connectivity are isomorphic. Amanda Walker Lucent Technologies InterNetworking Systems From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 8 18:50:06 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21883 for ; Mon, 8 May 2000 18:50:06 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.352FD2E0@standards.nortelnetworks.com>; Mon, 8 May 2000 18:42:48 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 51620 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 8 May 2000 18:41:12 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FB59EA60@standards.nortelnetworks.com>; Mon, 8 May 2000 18:41:11 -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 QAA28191 for ; Mon, 8 May 2000 16:48:05 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA01821 for ; Mon, 8 May 2000 15:48:03 -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 PAA09905 for ; Mon, 8 May 2000 15:48:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Mon, 8 May 2000 15:48:03 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: [MOBILE-IP] More thoughts on Regional Registrations To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" Some time back I sent my comments on the above draft, and Charlie answered. Well, further implementation experience has left a few concerns in my mind: 1. Advertisement of GFA. The Internet Drafts states: "If the 'I' bit is set, and there are multiple care-of addresses, the first care-of address is the local FA, and the last care-of address is the GFA." In my initial e-mail I asked why it wasn't possible to simply have a new extension that contained the GFA's address, and the response (as I recall) was to minimize packet bloat. Although I believe that this is a reasonable goal, I would ask what occurs with a RFC2002 Mobile Node that receives an advertisement, and decides, for some reason to use the LAST care-of address in the advertisement? It seems to me like this could cause some problems (because of #2 below). 2. new MN-GFA Extension The Internet drafts introduces a new authentication extension, which is the MN-GFA. First, I have concerns with this one primarily because (to me) the whole idea behind the Regional draft is to try to hide alot of the internals of the network, but this new authentication extension forces the Mobile Node to KNOW that a GFA is being used. Certainly, the draft does state that the local FA doesn't have to advertise it's care-of address, and could include only the GFA, but HOW would the MN know that it should use the MN-GFA as opposed to the MN-FA? Furthermore, what occurs with RFC2002 mobile nodes? This extension does allow a mobile to share a secret with both the local FA and the GFA, but I question how often this would EVER be used. It really is too complex, IMHO. 3. Hierarchical FA extension I question the use of this extension. Certainly all socket (and variant) implementations that I know of allow an application to know the source of the packet. If this wasn't the case, how would the FA know the source port? The problem here is that this extension breaks network address translation. The draft states that this extension contains the IP address of the Foreign Agent, and this COULD be an address that eventually gets translated. In my case, I have to write an ALG that handles this specific extension. Is there anyway that we could simply require that the GFA know that IP address of the sender through an API mechanism? PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 8 19:00:12 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22069 for ; Mon, 8 May 2000 19:00:11 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.55C42AA0@standards.nortelnetworks.com>; Mon, 8 May 2000 18:50:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 51670 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 8 May 2000 18:50:27 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4695E7D0@standards.nortelnetworks.com>; Mon, 8 May 2000 18:50:27 -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 QAA03491 for ; Mon, 8 May 2000 16:57:21 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA03884 for ; Mon, 8 May 2000 15:57:19 -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 PAA10198 for ; Mon, 8 May 2000 15:57:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Mon, 8 May 2000 15:57:19 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: [MOBILE-IP] Cellular Interest List To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" All, Last week I sent an e-mail stating that I was setting up a mailing list for the discussion of cellular related technologies, specifically those that don't really belong in the Mobile IP WG's mailing list. Unfortunately, I still cannot use cdma-2000.org domain (thanks for those bozos at... ok, I'll leave that one open). However, for now I set it up at: cellular@diameter.org. In order to register, simply send an e-mail to: cellular-request@diameter.org with "subscribe cellular [e-mail]" in the body of the message. This list is completely open, and can be used to discuss ANYTHING that has to do with IP in cellular environments (and even other wireless technologies). Enjoy, PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 8 22:18:22 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26373 for ; Mon, 8 May 2000 22:18:21 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3DF102B0@standards.nortelnetworks.com>; Mon, 8 May 2000 22:10:38 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 52252 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 8 May 2000 22:09:13 -0400 Received: from ms.hansol.co.kr (203.235.136.4) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0A860420@standards.nortelnetworks.com>; Mon, 8 May 2000 22:09:12 -0400 Received: from ns ([210.112.7.7]) by ms.hansol.co.kr (8.9.3/8.9.3) with SMTP id LAA04558 for ; Tue, 9 May 2000 11:15:52 +0900 References: 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.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: <000c01bfb95c$99bb9340$d012060a@hansol.co.kr> Date: Tue, 9 May 2000 11:16:04 +0900 Reply-To: "Lee, Jiwoong" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Lee, Jiwoong" Subject: [MOBILE-IP] Advantage of Mobile IP Testbeds To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi all, My team is considering the launch of Mobile IP Testbed, under any OS flatform. (We are a cell phone industry, preparing IMT-2000.) Our concern is not the cost of testbeds (cost means not only the money), but the purpose of the testbeds - "What we can get from it" Thereby I hope some of the experienced experts give any kind of hint about that. I thank all in advance. Regards, Jiwoong Lee Hansol M.com, Korea From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 9 07:44:05 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15564 for ; Tue, 9 May 2000 07:44:05 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.253AC590@standards.nortelnetworks.com>; Tue, 9 May 2000 7:35:27 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 52849 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 9 May 2000 07:34:59 -0400 Received: from monza.broadswitch.com (195.178.164.73) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AED40FC0@standards.nortelnetworks.com>; Tue, 9 May 2000 7:24:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <45AFD48D077ED211BB4700A0C9DCE8FD28A4EA@monza.broadswitch.com> Date: Tue, 9 May 2000 13:31:32 +0200 Reply-To: Thomas Eklund Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Thomas Eklund Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question X-To: "Casati, Alessio (Alessio)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi Alessio, The problem I see with that is that it is difficult to set up packet filters (ingress filters, ACL or something similar) if the source address prefix is not topologically correct... /Thomas > About location privacy: even if we don't send binding updates, > and even if we don't trust the CN, the CN ill kno enough info > from the link prefix included in the COA. > > So, correlating application layer info with the prefix the CN can know > the link we are at. > > This even if we have the non prefix info randomly change as > we move from > link to link. > > Alessio > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 9 10:25:40 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21066 for ; Tue, 9 May 2000 10:25:40 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D4E8FA00@standards.nortelnetworks.com>; Tue, 9 May 2000 10:17:51 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 53140 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 9 May 2000 10:17:07 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BA86AC70@standards.nortelnetworks.com>; Tue, 9 May 2000 10:17:06 -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 IAA16780; Tue, 9 May 2000 08:23:53 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA05516; Tue, 9 May 2000 07:23:52 -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 HAA03452; Tue, 9 May 2000 07:23:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Tue, 9 May 2000 07:23:51 -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] IPv6 Mobility Last Call Question X-To: Thomas Eklund To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <45AFD48D077ED211BB4700A0C9DCE8FD28A4EA@monza.broadswitch.com> That really depends upon where the filters are implemented. In a dial-up network, it makes more sense to distribute the processing, and implement the filters on the Network Access Server (read: PPP server), and leave the egress routers handle routing instead. The above still conforms to the recommendation to filter on source addresses, and does not break Mobile IP. PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 9 11:03:38 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22087 for ; Tue, 9 May 2000 11:03:37 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.28117B80@standards.nortelnetworks.com>; Tue, 9 May 2000 10:55:58 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 53228 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 9 May 2000 10:55:43 -0400 Received: from mail.hrn.ascend.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1F4940A0@standards.nortelnetworks.com>; Tue, 9 May 2000 10:55:43 -0400 Received: from awalker2 (amanda-pad.eng.hrn.ascend.com [149.52.12.188]) by mail.hrn.ascend.com (8.9.3/8.9.3) with ESMTP id LAA01251 for ; Tue, 9 May 2000 11:02:39 -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 IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Message-ID: Date: Tue, 9 May 2000 11:02:42 -0400 Reply-To: Amanda Walker Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Amanda Walker Subject: [MOBILE-IP] Looking for MIP implementation(s) for Windows 2000 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit I'm looking for a Windows 2000 MIP implementation (mobile node/colocated FA) to do some experimentation with. The Bucharest driver hasn't been updated in a while, so I was wondering if anyone knew of a publically available driver that is known to work under Windows 2000. If not, I'll do a full backup of my ThinkPad and give the Bucharest driver a spin :-). Amanda Walker Lucent Technologies InterNetworking Systems From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 9 13:07:00 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25520 for ; Tue, 9 May 2000 13:06:59 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.64B3E1C0@standards.nortelnetworks.com>; Tue, 9 May 2000 12:59:21 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 53526 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 9 May 2000 12:58:01 -0400 Received: from gandalf.axion.bt.co.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.35264470@standards.nortelnetworks.com>; Tue, 9 May 2000 12:58:01 -0400 Received: from cbtlipnt02.btlabs.bt.co.uk by gandalf (local) with ESMTP; Tue, 9 May 2000 17:03:34 +0100 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2651.88) id ; Tue, 9 May 2000 17:03:24 +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: Tue, 9 May 2000 17:03:26 +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] Hand-over resend X-cc: qa3445@EMAIL1.WES.MOT.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Phil (folks), > >Hi, > > I agree that we don't have the scope of organizations that are >not only interested in developing protocols but also developing system >architectures. > > I find it difficult to agree with your perspective on 3G network >support, and actually what constitutes 3G networks for that matter. All >constituencies with an interest in Mobile IP are welcome here. We're not >going to design 3G cellular networks, but if the folks who are would like >something added to mobile ip in order to use it in their networks they >are >more than welcome to contribute, and have been doing so in fact. > >Phil Roberts I just wanted to allay some fears that we were suggesting that MIP should undertake UMTS evolution work which is most definitely not what we want, and yes Phil we are more than keen to contribute to the MIP work but I think it important for us to explain a little more what we are worried about and why GTP/MIP/TORA are involved in this space. Draft-oneill-ema-01.txt is targeted at controlling IP hand-over between Access Routers (ie the first IP aware boxes) in the same routed domain. [For those struggling with the draft see http://www.isr.umd.edu/TechReports/ISR/2000/TR_2000-5/TR_2000-5.phtml] Between the AR and the MH could be a range of radio or fixed technologies, some of which have there own imbedded mobility mechanisms. The AR for UMTS in our work is assumed to be the SGSN in the early days but migrating out to the RNC as it becomes more IP enabled/compliant. Inter-domain hand-over (which we believe will be very rare but potentially useful) requires MobileIP. Inter-SGSN and (in the future) inter-RNC hand-overs in the UMTS specs use an IP tunnel technique called GTP (also see draft-casati-gtp-00.txt), which exists between a core anchor point called the GGSN, and the present SGSN. SGSN hand-over involves building a temporary tunnel between the two SGSNs (old and new) to forward received data at the OLD SGSN, whilst a new GTP tunnel is constructed between the new SGSN and the same GGSN anchor point. The GGSN looks a little like the MIP HA, whilst the two SGSN's look like two Fas in the 3GPP2 model. The significant difference though is two-fold. Firstly, the existence of the temporary hand-over tunnel between FAs, and secondly, the fact that GTP tunnel management is closely bound to, and controlled by, the cellular signalling. EMA is a fusion of "planned" hand-over (routed at the OLD AR/SGSN/RNC etc), where the hand-over is controlled using cellular signalling/measurements etc, and "unplanned" hand-over (routed at the new AR etc), where hand-over to/from/ between access technologies is not supported by cellular signalling. Note that unplanned includes the case where cellular hand-over fails due to unplanned loss of connectivity to the old AR/SGSN/RNC. For planned hand-over, a temporary tunnel MAY be used between the two AR's, in a similar manner to that effected by GTP today because the system knows in advance where the MH is being handed over to. With unplanned hand-over, the old AR does not know where to hand-over to (so cannot build a temporary tunnel), until the MH arrives at the new AR and signals back. Note that the EMA hand-over model is similar to MIP if the HA is the old AR and the FA is the new AR (although this does stretch things a little bit). What is clear though is the following, which I think should be considered, and which we would like to both support and contribute to; 1) MIP has an existing and developing signalling plane which is to be evolved to embrace the GTP type requirement in 3GPP2. If it can fully support the 3GPP GTP requirement then we can evolve to a single common solution to the anchor scenario, and hence provide better support for 3G.PP / 3G.PP2 inter-working.....I believe that the inter-working and GTP requirements and interfaces for MIP should of course be done in 3GPPx. 2) EMA is likely to first use GTP temporary tunnels between old and new AR's (as it exists), but we would wish to migrate to MIP both because of (1), and the fact that the AR's will need MIP later on anyway for inter-domain EMA support. Clearly if we can get MIP in before EMA then EMA can avoid GTP in the first phase. 3) EMA itself would like to be able to re-use the MIP signalling plane only. MIPsig deals well with the AAA requirements, this approach would provide co-existence of both tunnelled and native options (which is commercially important), provides a simple migration path to EMA from MIP (from tunnelled to native forwarding) in the future, and again provides us with the fully integrated inter-domain MIP piece. 4) Failure to address this here and now (same/very similar technical requirement for slightly different scenario) could lead to multiple, distinct, non-interworking IP hand-over signalling planes in cellular (note we already have GTP v MIP out of the bag). I hope we can avoid this when it seems to us we are trying to do such similar things ! 5) There is in addition to the above a range of mobility related signalling issues which I think affect MIPs evolution in this space, and it's relationship to other working groups activities...Maybe this is the BOF issue... So I guess I have to ask the chairs and you list folks if what I am asking is unreasonable, and what if any of the above areas are, and are not, going to be welcome as technical input into this wg ?? Regards, Alan. ------------------------------ __________________________________________________________________________ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 9 13:26:59 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25834 for ; Tue, 9 May 2000 13:26:59 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3508CA00@standards.nortelnetworks.com>; Tue, 9 May 2000 13:19:29 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 53634 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 9 May 2000 13:17:57 -0400 Received: from marvin.axion.bt.co.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FD7FDEC0@standards.nortelnetworks.com>; Tue, 9 May 2000 13:17:56 -0400 Received: from cbtlipnt02.btlabs.bt.co.uk by marvin (local) with ESMTP; Tue, 9 May 2000 17:13:32 +0100 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2651.88) id ; Tue, 9 May 2000 17:13:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.88) Content-Type: text/plain Message-ID: Date: Tue, 9 May 2000 17:13:23 +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] Applicability of IP Mobility to CDMA Soft Handoff X-To: James.Kempf@Eng.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM James said in > -----Original Message----- > From: James Kempf [SMTP:James.Kempf@ENG.SUN.COM] > Sent: Saturday, May 06, 2000 3:16 AM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Applicability of IP Mobility to CDMA Soft > Handoff > >As we tried to point out in the paper, given current understanding of >IP routing protocols and RAN designs, our belief is that soft handoff >is not a candidate for replacement with current IP mobility, but >hard handoff is. James, the authors of absolutely agree with you (and for the same reasons). We rewrote the .00 draft after similar comments from our UMTS people end of last year, and converted the edge nodes from basestations (BS) to access routers (AR) so that situations in which the radio interface were both local and remote to the AR could be encompassed. Your draft has made this issue clear to everyone which is good. >A hierarchical model of mobility management, with >soft handoff being highest performance and mobile IP for hard >handoff, seems like the most logical model to me. But the above does not necessarily follow from the first para...Why not native (routed) instead of tunnelled forwarding in hard hand-over? >Personally, I'd like to see the fast handoff discussion in this group >confined to >replacing hard handoff, and confined to the context of current mobile IP >and IP routing protocols. If there is interest in looking at new >routing protocols and mobility management for networks that operate >like CDMA RANs, I think it should be taken up in a separate working >group. The model here is MANET, which discusses a mobility model >which is orthogonal to the model presented by mobile IP. Clearly, the routing piece can sit in MANET if those chairs are happy, but the signalling hand-over for EMA in support of the routing has no home if not here..... And that leads to the risk that we develop (at least) two non-interworking signalling solutions to the same (or similar) problem, where the only difference in the solution should be the mode of data -forwarding (native v tunnelled) which can be selected through policy, AAA, and/or cellular signalling. In addition, because all the routed solutions require Mobile IP inter-domain, not including them at all in the work effectively blocks them to some extent. Hope you can see the problem... >I am skeptical that a mobility model will cover all wireless networks, >simply because, given the MANET work, we already know that there >will be some that don't fall under the mobile IP model. On the other >hand, mobile IP has proved its usefulness in the 3GPP2 packet data >service. It seems likely that any replacement to current soft handoff >that uses IP mobility would require a separate protocol because the >CDMA network is very different. You are right to be sceptical but that doesn't mean we should not try, especially when others believe from their work that a generic (or at least broader) model is both possible and useful. Regards, Alan. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 9 14:46:29 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27803 for ; Tue, 9 May 2000 14:46:23 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.47BCFE40@standards.nortelnetworks.com>; Tue, 9 May 2000 14:38:45 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 53806 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 9 May 2000 14:36:58 -0400 Received: from smtp.pandora.be (195.130.132.33) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A1DBBDF0@standards.nortelnetworks.com>; Tue, 9 May 2000 14:26:57 -0400 Received: (qmail 13314 invoked from network); 9 May 2000 18:33:53 -0000 Received: from unknown (HELO GERONIMO) ([213.224.62.136]) (envelope-sender ) by hercules.telenet-ops.be (qmail-ldap-1.03) with SMTP for ; 9 May 2000 18:33:53 -0000 X-Sender: Candyman@mail.antwerpen.be 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.20000509202146.009728e0@mail.antwerpen.be> Date: Tue, 9 May 2000 20:31:18 +0200 Reply-To: Jeroen Van Beirendonck Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Jeroen Van Beirendonck Subject: [MOBILE-IP] Changing networks - Learning new prefixes ? To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello, I'm having a bit of trouble understanding the Mobile IPv6 protocol as stated in the current draft. Is there anyone that could help me with these questions ? : The draft clearly states that it isn't a fault that routers on the same network may advertise different prefixes. But if a mobile node that starts on it's home link, can NEVER be sure that it has gotten ALL prefixes from all available routers that it should consider on-link, how can it detect then the fact that it has moved to a different link ? Because it it is allowed (for e.g. wireless links) to be in transmission range of different routers serving on different links, she can get RA's from both routers, but the fact that the prefixes are different can't make her decide that they are on different links ... Is the mobile node supposed to keep a seperate prefix-list of all valable home subnet prefixes ? That is if it is able to get a 100% complete & certain list of that ? thanx, Jeroen Van Beirendonck Computer Science Student UIA University, Antwerp Belgium email : Geronimo@thepentagon.com From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 9 15:05:14 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28279 for ; Tue, 9 May 2000 15:05:14 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F13BBB30@standards.nortelnetworks.com>; Tue, 9 May 2000 14:57:49 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 53878 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 9 May 2000 14:56:32 -0400 Received: from motgate.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5E1518C0@standards.nortelnetworks.com>; Tue, 9 May 2000 14:46:32 -0400 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id LAA25517 for ; Tue, 9 May 2000 11:53:29 -0700 (MST)] Received: [from il33exm01.wes.mot.com (il33exm01.wes.mot.com [154.56.3.118]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id LAA27903 for ; Tue, 9 May 2000 11:53:29 -0700 (MST)] Received: by il33exm01.wes.mot.com with Internet Mail Service (5.5.2650.21) id <28T0CHTG>; Tue, 9 May 2000 13:53:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <7195C03599D9D311BE580008C75697EB4432B2@il33exm01.wes.mot.com> Date: Tue, 9 May 2000 13:53:29 -0500 Reply-To: Roberts Phil-QA3445 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Roberts Phil-QA3445 Subject: Re: [MOBILE-IP] Cellular Interest List X-To: "pcalhoun@eng.sun.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi folks, thanks, Pat, for setting this up. I'd appreciate it if we migrated discussions that are more broadly about cellular off the mobile-ip list and onto the cellular interest list. Thanks, Phil -----Original Message----- From: pcalhoun@eng.sun.com [mailto:Pat.Calhoun@eng.sun.com] Sent: Monday, May 08, 2000 5:57 PM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: [MOBILE-IP] Cellular Interest List All, Last week I sent an e-mail stating that I was setting up a mailing list for the discussion of cellular related technologies, specifically those that don't really belong in the Mobile IP WG's mailing list. Unfortunately, I still cannot use cdma-2000.org domain (thanks for those bozos at... ok, I'll leave that one open). However, for now I set it up at: cellular@diameter.org. In order to register, simply send an e-mail to: cellular-request@diameter.org with "subscribe cellular [e-mail]" in the body of the message. This list is completely open, and can be used to discuss ANYTHING that has to do with IP in cellular environments (and even other wireless technologies). Enjoy, PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 9 15:29:23 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28954 for ; Tue, 9 May 2000 15:29:23 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4FE14940@standards.nortelnetworks.com>; Tue, 9 May 2000 15:21:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 53974 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 9 May 2000 15:20:43 -0400 Received: from atlrel2.hp.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BEA11A10@standards.nortelnetworks.com>; Tue, 9 May 2000 15:10:43 -0400 Received: from l3107mxr.atl.hp.com (l3107mxr.atl.hp.com [15.19.254.19]) by atlrel2.hp.com (Postfix) with ESMTP id 3E1E440D; Tue, 9 May 2000 15:17:36 -0400 (EDT) Received: from hpinrput.cup.hp.com (hpinrput.cup.hp.com [15.13.108.67]) by l3107mxr.atl.hp.com (Postfix) with ESMTP id 70E164FDE1; Tue, 9 May 2000 15:17:35 -0400 (EDT) Received: from cup.hp.com (junmei@hpncdjb.cup.hp.com [15.13.106.147]) by hpinrput.cup.hp.com with ESMTP (8.7.5/8.7.3 TIS 5.0.1) id MAA06735; Tue, 9 May 2000 12:13:18 -0700 (PDT) X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.10.20 9000/778) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39186BE8.E4185A33@cup.hp.com> Date: Tue, 9 May 2000 12:50:00 -0700 Reply-To: junmei@CUP.HP.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Junmei Yan Subject: [MOBILE-IP] Please add my name in your mailing list X-To: listserv@standards.nortelnetworks.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi, Would you please add my name in the mobile-ip mailing list. mobile-ip junmei yan My e-mail address is junmei@cup.hp.com Thanks, Junmei From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 9 17:25:56 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01143 for ; Tue, 9 May 2000 17:25:56 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.91D70460@standards.nortelnetworks.com>; Tue, 9 May 2000 17:18:19 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 54265 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 9 May 2000 17:16:59 -0400 Received: from zmamail05.zma.compaq.com (161.114.64.105) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.623D5920@standards.nortelnetworks.com>; Tue, 9 May 2000 17:16:59 -0400 Received: by zmamail05.zma.compaq.com (Postfix, from userid 12345) id B8688181E; Tue, 9 May 2000 17:23:50 -0400 (EDT) Received: from exctay-gh01.tay.cpqcorp.net (exctay-gh01.tay.cpqcorp.net [16.103.129.42]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 98F821A91; Tue, 9 May 2000 17:23:50 -0400 (EDT) Received: by exctay-gh01.tay.cpqcorp.net with Internet Mail Service (5.5.2650.21) id ; Tue, 9 May 2000 17:23:50 -0400 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, 9 May 2000 17:23:43 -0400 Reply-To: "Powell, Ken" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Powell, Ken" Subject: Re: [MOBILE-IP] Mobile IPv6 questions X-To: Francis Dupont To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Sorry for the slow turn-around on this, I was sidetracked by vacation and other priorities at work. > > RFC 2461 section 6.2.7 states: > > "Note that it is not an error for different routers to > advertise different sets of prefixes" > > => for me "no error" is requirement level below/weaker than a > "MUST NOT". I read it to mean different routers "MAY" advertise different sets of prefixes. > > Section 9.7 of the Mobile IPv6 draft indicates that it was > intended to support routers advertising different prefixes: > > "The home agent determines these conditions based on its > own configuration as a router and based on the Router > Advertisements that it receives on the home link." > > => and section 9.7 indicates the home agent should send changes > for any prefixes of the link, the list is built by the union > of configured prefixes on the home agent and prefixes listen > on the link in router advertisements. Things are more simpler > if both lists in the union are the same. I agree that things are simpler if both lists are the same, but I don't think we can just assume they are without stating that clearly in the Mobile IPv6 spec. > I think some of your other responses were based on the > assumption that routers will advertise a consistent set > of prefixes. I guess before we can resolve the details, > we need to know if the Mobile IPv6 spec should or should > not impose this restriction on the home subnet configuration. > > => mobile IPv6 spec imposes this restriction for router advertisements > sent to the mobile node in case of an "important" change. I think you may have misinterpreted my statement. I meant to ask should Mobile IPv6 impose a restriction that all routers on the home subnet advertise a consistent set of prefixes? If not, then the Mobile IPv6 spec needs to provide more details about how to relay prefix information from all routers on the home subnet to the mobile node. Perhaps there could be an alternative restriction that a Mobile Agent's interface needs to be configured with all possible prefixes advertised on the home link. Other routers don't. I wonder if there are any other ways to solve this problem. > => There is > nothing about other router advertisements... My term "other router advertisements" was intended to mean "router advertisements that the mobile agent receives on the home link". > > > I think more details are needed on how the home agent should > > maintain its list of prefixes > > > > => I think it should use standard management and router > renumbering > > as other routers. > > Yes, if routers on the home subnet advertise the same set > of prefixes. > Otherwise, we need additional mechanisms to keep the set > of home subnet > prefixes available to the mobile node consistent. > > => if router management tools are not enough then the home > agent should > look at prefixes announced by router advertisements from other routers > (cf section 9.7). Agreed, but which way should it be? > > > Sections 4.3, 5.1, 9.3, and 9.5 describe how the mobile node > > sends a Router bit to the home agent which the home agent must > > in turn use for the IsRouter bit on proxy neighbor > advertisements > > for the mobile node. Why is this done? The mobile node can't > > continue to function as a normal router to other nodes on the > > home subnet can it? > > > > => the mobile node can be either a host or a router then the home > > agent needs to know if it is a host or a router when it sends > > proxy NAs (because of the IsRouter bit). The router bit > in binding > > updates provides this information. > > I asked this question because of the role the IsRouter bit plays > in Neighbor Discovery. Specifically, the sole function of the > IsRouter bit is to signal to hosts on the home link that a node > which was previously acting as an on-link router is no longer > capable of accepting messages on the link for forwarding. RFC > 2461 section 7.3.3 states: > > "When a node detects that a neighbor has changed from being a > router to being a host, the node MUST remove that router from > the Default Router List and update the Destination Cache as > described in Section 6.3.5. Note that a router may not be > listed in the Default Router List, even though a Destination > Cache entry is using it (e.g., a host was redirected to it). > In such cases, all Destination Cache entries that reference > the (former) router must perform next-hop determination > again before using the entry." > > I don't believe RFC 2461 accounted for mobile routers. It seems > to me that the above host processing makes just as much sense > when a neighboring mobile router goes off-link as when a > neighboring router switches from being a router to a host. > > => there is two independent parts in "being a router": > - being an on-link router (this function uses the link-local address > then will stop when the router goes off-link. Some implementations > impose the gateway field of a route to be a link-local address, > this is not stupid because an off-link router can't receive then > forward packets on the link) > - being involved in a protocol as a router (in general such > a protocol > is a routing protocol but there are other examples). In this case > an address with a scope larger than the link is used and if the > protocol looks at the neighbor discovery stuff then the IsRouter > flag must be preserved (ie. there is no good reason than a router > which goes off-link MUST become a host then the IsRouter flag > MUST be transmitted in binding updates). Thanks, I didn't think of this second possible use of IsRouter. > Note: the IsRouter should be reset in proxy neighbor advertisements > for the link-local address, for instance in duplicate address > detection. > Perhaps a SHOULD for a proxy router advertisement with a zero lifetime > should be added too? > > However, I think this I-D should be able to cover how > to initialize its state on the home agent and the mobile node > from a limited amount of information that is relatively easy > to configure. For example, start with the assumption that the > mobile node can always get the Home Agent's Anycast Address. > > => I agree this is useful but I think this is out of the > scope of the I-D. Perhaps it would help if I backed up a little. The Mobile IPv6 draft explains how to handle many parts of stateless address autoconfiguration between a mobile node and the home network. This led me to believe that Mobile IPv6 aught to work with a home subnet that runs stateless address autoconfiguration only. I tried to understand how a Mobile IPv6 node would initialize its addresses on power-up using stateless address auto- configuration when away from home. The steps I came up with were: 1) Get the home network mobile agent anycast address. (Method for this is beyond the scope of this spec) 2) Send Home Agent Address Discovery Request message to home network. 3) Receive Home Agent Address Discovery Reply message. Now I'm stuck. I still need to: 4) Autoconfigure the mobile node's home network global addresses from router advertisements sent by the home agent. This cannot be done without the primary care-of address binding due to the way router advertisements are tunneled. 5) Create the primary care-of address binding. This cannot be done without the mobile node having a global address on the home network. What information can I expect the mobile node have to break this deadlock? Is my reading of how this should work way off? > > > Comments on Specific Sections: > > > > Page 14: > > > > Should section 4.3 (Conceptual Data Structures) > define a place > > where the home agent would store the state of all prefixes > > advertised by other routers on the home subnet? > > > > => the home agent should act as a standard router for this. > > Yes, but only if all routers on the home subnet advertise the > same set of prefixes. > > => it is simpler to add the unknown prefixes to the home > agent prefix list > (hosts will not see the difference) but a clarification is needed. I'm not sure exactly what you mean. Would the home agent dynamically add the prefix from another router on the link to its own list and automatically start advertising that prefix? > > > Page 42 penultimate paragraph: > > "In a solicited Router Advertisement, a router MUST > > include at least one Prefix Information option with > > the router Address (R) bit set." > > > > This looks like a requirement on all IPv6 routers. I > > understand why this is a MUST for mobile agents, but > > I don't get the reasoning for routers that are not acting > > as mobile agents. > > > > => the rationate at the beginning of 6.2 is only about > home agents > > then I agree: R bit must be defined for routers but the > MUST is only > > for home agents. But I know some situations where router > addresses > > are very useful then I'd like to have a SHOULD for > routers which are > > not home agents. > > I don't understand why "SHOULD" as opposed to "MAY". > > => I think you don't understand because of this next statement: > > I don't see why a router implementation that has no mobile agent > support should do this. > > => because this gives a nice way to know a global address of a router: > router advertisements carry only the link-local address and to take > a prefix and the interface ID from the link-local address is *not* > a reliable way to get one. > There are some situations where it is useful: > - management (it solves the topology discovery issue described by > Jean-Luc Richier, you know routers the link, you send SNMP queries > to know further routers and you get only unusable link-local > addresses, > with global or site-local addresses you can queries second > then higher > layer routers). > - point-to-point links: some OSs want to get both addresses when you > add a new prefix. > - just ask in the IPng list for many other examples... This is plenty, I'm convinced. "SHOULD" sounds good. > > I would like to distinguish between the subnet prefix associated > with the home address on the mobile node's Binding Update, and > the other subnet prefixes on the home network. > > => the problem is this distinction doesn't work for connections which > are not initiated my the mobile node, for instance when the DNS has > the whole set of home addresses. The latest draft went a long way to clear up my concerns here. If I read the changes right, the lifetime of bindings with correspondent nodes is no longer limited to be less than the lifetime of the binding with the home agent. I was worried that a mobile node would have to drop all bindings to all nodes at the end of a renumbering process on the home network. That won't happen now. > > I agree that when the former times-out, the binding cache entry > for the mobile node should be flushed. I don't think the binding > between the mobile node and the home agent should be purged when > other subnet prefixes on the home network timeout. They > are not needed > to maintain communication between the home agent and the mobile > node, and the mobile node has individual timers on the other > home addresses which will expire on their own. > > => you forget the home agent is a correspondent too then the binding > cache entry must be flushed as soon as an address in the set timeouts > (correspondents are simpler because they have one home > address by entry, > the prefix length stuff gives one entry for the whole set but this has > a cost). Good point. > > > When a mobile agent receives a router advertisement from > > another router on the home subnet, does it treat > the received > > Valid Lifetime and Preferred Lifetime as fixed or > decrementing? > > I would think given the lack of other information, > it should be > > treated as decrementing. > > > > => RFC 2461 6.2.7 provides the answer (use the local > fix/decrement mode). > > This gets back to the router prefix assumption. > > => this is an argument in favor of it because to look at router > advertisments don't give all infos (thank for the proof :-). Yes, but this can be reasonably handled. It just has to be defined somewhere so everyone does it the same way if its done at all. > > > What should the mobile agent set the following > fields to when > > sending a router advertisement to a mobile node? > > > > M (managed address configuration flag) > > O (other stateful address configuration flag) > > H (home agent flag) > > Router Lifetime > > Reachable Time > > Retrans Timer > > Prefix Information > > L (on-link flag) > > A (autonomous address configuration flag) > > R (router address flag) > > Valid Lifetime > > Preferred Lifetime > > Prefix > > > > => I don't see a reason to send something different than on > > the home link? > > I guess the possible issues I can think of are: > > Retrans Timer: I don't know how address timers are to be > handled on mobile nodes. For now, I assume > the mobile node continues to time-out home > addresses as if they were on-link. Given that, > the router advertisement must be retransmitted > periodically by the home agent. I understand > the time between retransmissions would be > much greater than on-link. What should this > time period be? Should this field in the > advertisement be adjusted accordingly? > > => the retrans timer is for NUD and address resolution, the > mobile node > can't do something useful with it... > > L (on-link flag): The mobile node is no longer on-link. > As far as I can tell, all communication > to nodes on the home subnet will work > exactly like communication to any other > off-link node. > > => idem, it doesn't matter but there is an interesting case: > - there is only one prefix announced on the link (what you call > the home subnet?) > - this prefix is off-link, ie. there are nodes in the prefix > on other links > - the mobile node is connected to one of these links. > IMHO the mobile node is still at home and routing between nodes in the > prefix must be done with host routes: this is like > paging/micro mobility > and needs draft-nordmark-ipv6-aaa-hooks-00.txt registration to work... Looking at it again, I agree. These fields don't need any special handling. > > I think the spec should explicitly state the remaining fields > are transmitted exactly as if the message were sent on-link. > > => SHOULD or MUST? The I-D says "no other options"... Good question, I can see arguments for either. A SHOULD would allow home agent developers to put in value-added features they may think of later. Would the home agent seriously break neighbor discovery or stateless address autoconfiguration by sending different values of these fields to the mobile node? > > > Page 80 Section 10.7: > > > > Should a mobile node get its home network anycast > address from > > DNS as opposed to constructing it from the > previously known home > > network prefix? This would allow a mobile node to > more easily > > recover from renumbering events on the home network > if it happens > > to be disconnected while the renumbering event occurs. > > > > => "previously" is only a way to know the home network prefix > > (and the way to know it is not specified by the I-D) then you MAY > > do what you'd like... > > By "previously", I intended to convey that the mobile node > remembers > the numeric form of the home network prefix last used in > non-volatile > memory. I don't think this would be a good thing to do. > The prefix may > change. > > => we agree, DNS is a superior way but again this is out of the scope. OK. > > Is there a recommended way to avoid this duplicate coverage? > > => none... Worse, if the mobile node reboots and sends a fresh home > registration then the home agent can be confused and rejects > it because > of a bad sequence number (this point is supposed to be solved by the > security stuff which resets SAs before but this is in old minutes, > not in the spec). > > If not, should the home agent recognize this as a > duplicate entry and > purge the old one? > > => same answer, and the issue is open when there is more than > one home agent. Thanks for the history on this. New Question: Looking at draft-ietf-mobileip-ipv6-12 section 9.7 page 70, should the conditions for sending a router advertisement to a mobile node include some sort of unconditional periodic retransmission? My concern is the home agent could define a prefix with a fixed lifetime that the mobile node will treat as decrementing in realtime. The prefix on the mobile node could expire without any updates from the home agent. The retransmission could occur on an hourly or even daily basis, depending on the Preferred and Valid Lifetimes of the prefixes. Ken Powell Compaq Computer Corporation From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 9 18:20:56 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01979 for ; Tue, 9 May 2000 18:20:55 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.489428C0@standards.nortelnetworks.com>; Tue, 9 May 2000 18:13:32 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 54425 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 9 May 2000 18:12:08 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.168EADA0@standards.nortelnetworks.com>; Tue, 9 May 2000 18:12:08 -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 QAA06456; Tue, 9 May 2000 16:19:02 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA12280; Tue, 9 May 2000 15:18:58 -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 PAA16345; Tue, 9 May 2000 15:18:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: wHd/NrU7emutMi/K1h661w== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Message-ID: <200005092218.PAA16345@nasnfs.eng.sun.com> Date: Tue, 9 May 2000 15:21:48 -0700 Reply-To: James Kempf Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: James Kempf Subject: Re: [MOBILE-IP] Applicability of IP Mobility to CDMA Soft Handoff X-To: alan.w.oneill@bt.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM >>A hierarchical model of mobility management, with >>soft handoff being highest performance and mobile IP for hard >>handoff, seems like the most logical model to me. > >But the above does not necessarily follow from the first para...Why not >native (routed) instead of tunnelled forwarding in hard hand-over? > My understanding from talking with people who have worked on routers (I'm not a router expert myself) is that the convergence of routing tables is too slow for handoff of realtime applications. Now, it's possible that a new routing algorithm that converges faster could be invented, but interdomain handover is likely to involve different carriers or ISPs, which means that they will probably want to use standard Internet routing algorithms between them. As far as tunneling goes, if IPv6 is used, tunneling may be avoided in certain cases. >>Personally, I'd like to see the fast handoff discussion in this group >>confined to >>replacing hard handoff, and confined to the context of current mobile IP >>and IP routing protocols. If there is interest in looking at new >>routing protocols and mobility management for networks that operate >>like CDMA RANs, I think it should be taken up in a separate working >>group. The model here is MANET, which discusses a mobility model >>which is orthogonal to the model presented by mobile IP. > >Clearly, the routing piece can sit in MANET if those chairs >are happy, but the signalling hand-over for EMA in support of the routing >has no home if not here..... I'm confused. If the singalling is in support of the routing, then shouldn't the two activites be co-located? >And that leads to the risk that we develop (at least) two non-interworking >signalling solutions to the same (or similar) problem, where the only >difference in the solution should be the mode of data -forwarding (native v >tunnelled) which can be selected through policy, AAA, and/or cellular >signalling. In addition, because all the routed solutions require Mobile IP >inter-domain, not including them at all in the work effectively blocks them >to some extent. Hope you can see the problem... > I guess I don't. If you are talking about MANET and mobile IP, clearly there is a need to look at their interaction, and there would be the same need for a new protocol for CDMA RAN networks. But why is this any different than the current IS-95 based network, where soft handoff runs in the IS-634 based RAN and hard handoff runs over IS-41? Not to say that this situation is ideal, just that it indicates a data point of where such work was necessary. And the interaction between Internet and intradomain routing protocols in wired networks is the same case. >>I am skeptical that a mobility model will cover all wireless networks, >>simply because, given the MANET work, we already know that there >>will be some that don't fall under the mobile IP model. On the other >>hand, mobile IP has proved its usefulness in the 3GPP2 packet data >>service. It seems likely that any replacement to current soft handoff >>that uses IP mobility would require a separate protocol because the >>CDMA network is very different. > >You are right to be sceptical but that doesn't mean we should not try, >especially when others believe from their work that a generic (or at least >broader) model is both possible and useful. > Sure, it's always possible that somebody will come up with a generic solution. My skepticism is, however, based on experience. Different routing protocols are used for inter- v.s. intradomain routing for current fixed, wired networks (BGP v.s. RIP), so I see no reason why the same shouldn't be the case for wireless networks and their wired access networks. jak From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 9 20:15:21 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03152 for ; Tue, 9 May 2000 20:15:21 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.43997D60@standards.nortelnetworks.com>; Tue, 9 May 2000 20:07:55 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 54739 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 9 May 2000 20:06:04 -0400 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.013BBE60@standards.nortelnetworks.com>; Tue, 9 May 2000 20:06:04 -0400 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA07185; Tue, 9 May 2000 17:13:00 -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 RAA18144; Tue, 9 May 2000 17:13:00 -0700 (PDT) Received: from lillen (lillen.Eng.Sun.COM [129.146.86.161]) by jurassic.eng.sun.com (8.10.1+Sun/8.10.1) with SMTP id e4A0Cxh107152; Tue, 9 May 2000 17:12:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Tue, 9 May 2000 17:04:50 -0700 Reply-To: Erik Nordmark Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Erik Nordmark Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question X-To: Fred Baker To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <4.3.1.2.20000507150752.00ea2100@flipper.cisco.com> > In short, I understand that sometimes there is a corporation that figures > its employees cannot be trusted outside of its four walls, but I don't > understand why that should be a limit on the case I mentioned, or a limit > on a corporation that doesn't see its employees in that light. Also, if the employees can't be trusted to this extent we can't solve that with technology - it is a social problem that requires social solutions. (Many companies make statements about the possible effects of violating company security policies like connecting an externally accessible modem to the desktop allowing people to break in etc) Erik From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 9 20:53:24 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03407 for ; Tue, 9 May 2000 20:53:24 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.96DE8790@standards.nortelnetworks.com>; Tue, 9 May 2000 20:46:02 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 54836 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 9 May 2000 20:44:57 -0400 Received: from ish7.ericsson.com.au (203.61.155.111) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6F6B31E0@standards.nortelnetworks.com>; Tue, 9 May 2000 20:44:56 -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 KAA19013; Wed, 10 May 2000 10:51:28 +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 KAA28521; Wed, 10 May 2000 10:51:38 +1000 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2448.0) id ; Wed, 10 May 2000 10:51:17 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFBA19.D944869E" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A5089EB005@eaubrnt018.epa.ericsson.se> Date: Wed, 10 May 2000 10:51:15 +1000 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] Changing networks - Learning new prefixes ? X-To: Jeroen Van Beirendonck 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_01BFBA19.D944869E Content-Type: text/plain > Hello, > > I'm having a bit of trouble understanding the Mobile IPv6 protocol as > stated in the current > draft. Is there anyone that could help me with these questions ? : > > The draft clearly states that it isn't a fault that routers on the same > network may advertise different prefixes. > But if a mobile node that starts on it's home link, can NEVER be sure that > it has gotten ALL prefixes > from all available routers that it should consider on-link, how can it > detect then the fact that it has moved > to a different link ? Because it it is allowed (for e.g. wireless links) > to > be in transmission range > of different routers serving on different links, she can get RA's from > both > routers, but the > fact that the prefixes are different can't make her decide that they are > on > different links ... > Receiving RAs with new prefixes should not be an indication of movement. However receiving new prefixes combined with the fact that your default router has disappeared IS in fact an indication of movement. Of course you can easily find out if your default router disappeared or not by probing its link local address. ------_=_NextPart_001_01BFBA19.D944869E Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] Changing networks - Learning new prefixes = ?

    Hello,

    I'm having a bit of trouble = understanding the Mobile IPv6 protocol as
    stated in the current
    draft. Is there anyone that could = help me with these questions ? :

    The draft clearly states that it isn't = a fault that routers on the same
    network may advertise different = prefixes.
    But if a mobile node that starts on = it's home link, can NEVER be sure that
    it has gotten ALL prefixes
    from all available routers that it = should consider on-link, how can it
    detect then the fact that it has = moved
    to a different link ? Because it it = is allowed (for e.g. wireless links) to
    be in transmission range
    of different routers serving on = different links, she can get RA's from both
    routers, but the
    fact that the prefixes are different = can't make her decide that they are on
    different links ...

    Receiving RAs with = new prefixes should not be an indication of movement. However receiving = new prefixes combined with the fact that your default router has = disappeared IS in fact an indication of movement. Of course you can = easily find out if your default router disappeared or not by probing = its link local address.


------_=_NextPart_001_01BFBA19.D944869E-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed May 10 04:54:30 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20651 for ; Wed, 10 May 2000 04:54:30 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BE999930@standards.nortelnetworks.com>; Wed, 10 May 2000 4:46:45 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 55369 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 10 May 2000 04:46:22 -0400 Received: from hoemail2.firewall.lucent.com (192.11.226.163) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B0897090@standards.nortelnetworks.com>; Wed, 10 May 2000 4:46:22 -0400 Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id EAA22153 for ; Wed, 10 May 2000 04:53:20 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id EAA22144 for ; Wed, 10 May 2000 04:53:19 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2448.0) id ; Wed, 10 May 2000 09:53:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Message-ID: <976F7C55E3B2D111A0720008C728549C04876C08@en0060exch001u.uk.lucent.com> Date: Wed, 10 May 2000 09:53:18 +0100 Reply-To: "Casati, Alessio (Alessio)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Casati, Alessio (Alessio)" Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question X-To: Erik Nordmark To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Also, if the employees can't be trusted to this extent we can't solve > that with technology - it is a social problem that requires social > solutions. > (Many companies make statements about the possible effects of violating > company security policies like connecting an externally accessible modem > to the desktop allowing people to break in etc) > > This statement is kind of strange, and would really mean that Mobile IPv6 has not the service capabilities Mobile IPv4 has with reverse tunneling. Just add to the biding update ACK from the Home Agent a flag to turn off sending binding updates to CNs and forcing reverse tunneling, and we have solved the problem. Thanks. alessio From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed May 10 05:47:27 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21138 for ; Wed, 10 May 2000 05:47:26 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2C8E62C0@standards.nortelnetworks.com>; Wed, 10 May 2000 5:39:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 55504 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 10 May 2000 05:38:14 -0400 Received: from marvin.axion.bt.co.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EF5997D0@standards.nortelnetworks.com>; Wed, 10 May 2000 5:38:14 -0400 Received: from cbtlipnt01.btlabs.bt.co.uk by marvin (local) with ESMTP; Wed, 10 May 2000 10:17:50 +0100 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2651.88) id ; Wed, 10 May 2000 10:17:40 +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, 10 May 2000 10:17:39 +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] Applicability of IP Mobility to CDMA Soft Handoff X-To: James.Kempf@eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM James, To clarify.... > ---------- > From: James Kempf > Reply To: James Kempf > Sent: Tuesday, May 9, 2000 11:21 pm > To: James.Kempf@eng.sun.com; MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; > alan.w.oneill@bt.com > Subject: RE: [MOBILE-IP] Applicability of IP Mobility to CDMA Soft > Handoff > > > >>A hierarchical model of mobility management, with > >>soft handoff being highest performance and mobile IP for hard > >>handoff, seems like the most logical model to me. > > > >But the above does not necessarily follow from the first para...Why not > >native (routed) instead of tunnelled forwarding in hard hand-over? > > > > My understanding from talking with people who have worked on routers > (I'm not a router expert myself) is that the convergence of routing > tables is too slow for handoff of realtime applications. > Yes - deployed algorithms are way to slow. > Now, it's > possible that a new routing algorithm that converges faster could > be invented, > That is what MANET has been working on for a while now, and at least one of these, TORA, looks like it can scale to be commercially important. That is neither to say that others can't be made to scale, nor does it suggest that the work is complete. Our hand-over times in simulation are more than sufficient for real-time apps...one of our primary drivers in doing this is support of such apps. We have been working on this problem for two years and are presently coding the algorithm into FreeBSD3.2 for testing and release, and may also release the OPNET sim code. None of us are in anyway underestimating the timescales required for the community to understand, evolve, standardise and deploy a new routing algorithm though, so MIP in the short-medium term is also important (ie I am therefore really keen that MIP does this work as well). > but interdomain handover is likely to involve different > carriers or ISPs, which means that they will probably want to use > standard Internet routing algorithms between them. > Inter-domain requires mobileIP in our work which is clearly stated in our drafts. We are not trying to change the Internet routing architecture. However, with a scalable mobile enabled routing algorithm, inter-domain hand-over = inter-operator hand-over IN-SESSION which we think will be rare due to obvious commercial barriers. Roaming is in contrast pretty important. > As far as tunneling goes, if IPv6 is used, tunneling may be avoided > in certain cases. > But not all cases, and nowhere close to majority of cases. But be aware that tunnelling is also required in our model to support remote access, so co-existence of native and tunelled forwarding is critical for us. > >>Personally, I'd like to see the fast handoff discussion in this group > >>confined to > >>replacing hard handoff, and confined to the context of current mobile IP > >>and IP routing protocols. If there is interest in looking at new > >>routing protocols and mobility management for networks that operate > >>like CDMA RANs, I think it should be taken up in a separate working > >>group. The model here is MANET, which discusses a mobility model > >>which is orthogonal to the model presented by mobile IP. > > > >Clearly, the routing piece can sit in MANET if those chairs > >are happy, but the signalling hand-over for EMA in support of the routing > >has no home if not here..... > > I'm confused. If the singalling is in support of the routing, then > shouldn't the two activites be co-located? > The signalling is not in support of routing, it is in support of hand-over and associated AAA. Hand-over causes injection of messages into the routing protocol to enable it to track the mobile (mech is routing protocol specific triggered through the EMA<->routing API). The signalling is common to a range of possible routing algorithms, and also common in many ways to MIP. > >And that leads to the risk that we develop (at least) two > non-interworking > >signalling solutions to the same (or similar) problem, where the only > >difference in the solution should be the mode of data -forwarding (native > v > >tunnelled) which can be selected through policy, AAA, and/or cellular > >signalling. In addition, because all the routed solutions require Mobile > IP > >inter-domain, not including them at all in the work effectively blocks > them > >to some extent. Hope you can see the problem... > > > > I guess I don't. If you are talking about MANET and mobile IP, clearly > there is a need to look at their interaction, and there would be the > same need for a new protocol for CDMA RAN networks. But why is this > any different than the current IS-95 based network, where soft handoff > runs in the IS-634 based RAN and hard handoff runs over IS-41? Not > to say that this situation is ideal, just that it indicates a data > point of where such work was necessary. And the interaction between > Internet and intradomain routing protocols in wired networks is the > same case. > This seems orthogonal to me - as I agree with it :-) > >>I am skeptical that a mobility model will cover all wireless networks, > >>simply because, given the MANET work, we already know that there > >>will be some that don't fall under the mobile IP model. On the other > >>hand, mobile IP has proved its usefulness in the 3GPP2 packet data > >>service. It seems likely that any replacement to current soft handoff > >>that uses IP mobility would require a separate protocol because the > >>CDMA network is very different. > > > >You are right to be sceptical but that doesn't mean we should not try, > >especially when others believe from their work that a generic (or at > least > >broader) model is both possible and useful. > > > > Sure, it's always possible that somebody will come up with a generic > solution. My skepticism is, however, based on experience. Different > routing protocols are used for inter- v.s. intradomain routing for > current fixed, wired networks (BGP v.s. RIP), so I see no reason why the > same > shouldn't be the case for wireless networks and their wired access > networks. > Not trying to change the routing architecture in anyway...TORA (or whatever) intra-domain. BGP inter-domain with MIP supporting inter-domain hand-over (which we all agree technically if not commercially) > jak > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed May 10 07:12:48 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22359 for ; Wed, 10 May 2000 07:12:48 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.15A42E80@standards.nortelnetworks.com>; Wed, 10 May 2000 7:05:12 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 55689 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 10 May 2000 07:04:05 -0400 Received: from goliath.siemens.de (194.138.37.131) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.881FF5E0@standards.nortelnetworks.com>; Wed, 10 May 2000 6:54:05 -0400 X-Envelope-Sender-Is: jochen.grimminger@mchp.siemens.de (at relayer goliath.siemens.de) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.10.1/8.10.1) with ESMTP id e4AB10P11183; Wed, 10 May 2000 13:01:00 +0200 (MET DST) Received: from mail-y.mchp.siemens.de (mail-y.mchp.siemens.de [139.23.202.157]) by mail1.siemens.de (8.10.1/8.10.1) with ESMTP id e4AB0xk12913; Wed, 10 May 2000 13:00:59 +0200 (MET DST) Received: from mchp.siemens.de (mhpa2s1c.mchp.siemens.de [139.23.200.185]) by mail-y.mchp.siemens.de (8.9.3/8.9.3) with ESMTP id NAA20584; Wed, 10 May 2000 13:00:58 +0200 (MET DST) X-Mailer: Mozilla 4.7 [de] (WinNT; I) X-Accept-Language: de MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------E68B567142714126042E43B0" Message-ID: <3919416F.F92AC19C@mchp.siemens.de> Date: Wed, 10 May 2000 13:01:03 +0200 Reply-To: Jochen Grimminger Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Jochen Grimminger Subject: [MOBILE-IP] Presentation slides LA '96 / Adelaide X-To: dbj@cs.cmu.edu X-cc: Hans-Peter Huth To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --------------E68B567142714126042E43B0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hallo Dave, hello everybody on the MIP mailing list in Adelaide Gopal Dommety made his presentation (draft) in MIP about "Fast Handover" described in the draft "draft-dommety-mobileip-anchor-handoff-00.txt" ... the topic was quite interesting ... and Dave Johnson made quite clear that in LA he has presented something similar (draft-whatwasitsname). I was searching for your presentation and the according draft, but all i found on your homepage was .... * The 35th Internet Engineering Task Force meeting, Los Angeles, CA, March 4-8, 1996: "Design Questions in Route Optimization", Mobile IP Working Group Meeting, March 7, 1996. "Location Areas in Mobile IP", Mobile IP Working Group meeting, David B. Johnson, March 7, 1996 I'm working in the MIP / MIP IPv6/MicroMobility enviroment. Could you or somebody on the list please send the documents directly to me or just make them available on any public homepage or via the MIP mailinglist. Best regards and many thanks in advance Jochen Grimminger PS: I'm pretty sure i'm not the only one who was interested ;-) with respect to the fast handover discussions on the list. By the way what about the state of all the micro mobility drafts, most of them are and cellularIP is about to expire . --------------E68B567142714126042E43B0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  

Hallo Dave, hello everybody on the MIP mailing list

in Adelaide Gopal Dommety made his presentation (draft) in MIP about "Fast Handover" described in the draft "draft-dommety-mobileip-anchor-handoff-00.txt" ... the topic was quite interesting ... and Dave Johnson made quite clear that in LA he has presented something similar (draft-whatwasitsname). I was searching for your presentation and the according draft, but all i found on your homepage was ....
 

  • The 35th Internet Engineering Task Force meeting, Los Angeles, CA, March 4-8, 1996:
          "Design Questions in Route Optimization", Mobile IP Working Group Meeting, March 7, 1996.
          "Location Areas in Mobile IP", Mobile IP Working Group meeting, David B. Johnson, March 7, 1996
 

I'm working in the MIP / MIP IPv6/MicroMobility enviroment. Could you or somebody on the list please send the documents directly to me or just make them available on any public homepage or via the MIP mailinglist.

Best regards and many thanks in advance

Jochen Grimminger

PS: I'm pretty sure i'm not the only one who was interested ;-) with respect to the fast handover discussions
on the list. By the way what about the state of all the micro mobility drafts, most of them are and cellularIP is about to expire .

  --------------E68B567142714126042E43B0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed May 10 12:00:52 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28864 for ; Wed, 10 May 2000 12:00:52 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.423EEA70@standards.nortelnetworks.com>; Wed, 10 May 2000 11:52:46 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 56811 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 10 May 2000 11:52:05 -0400 Received: from omega.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.296F71E0@standards.nortelnetworks.com>; Wed, 10 May 2000 11:52:05 -0400 Received: from gopal (gdommety-dsl3.cisco.com [10.19.17.140]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id IAA04535; Wed, 10 May 2000 08:59:00 -0700 (PDT) X-Sender: gdommety@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <4.1.20000510090125.009fac40@omega.cisco.com> Date: Wed, 10 May 2000 09:05:27 -0700 Reply-To: Gopal Dommety Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gopal Dommety Subject: Re: [MOBILE-IP] question about draft "anchor handoff" X-To: ccliu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <009001bfba63$cc2700a0$3368608c@cclk400.ccl.itri.org.tw> At 05:40 PM 10/05/00 +0800, you wrote: > > Mr. Dommety, > > I have studied your draft " draft-dommety-mobileip-anchor-handoff-00.txt" > You provide Global registration, Local registration, and Global indirect > registration flow. > My question is this flow is only for registration procedure?? > The data also has to be transffer through the path which follow the > registration path?? > Thanks a lot!! > Lewis Hello Lewis: You understanding is correct. The data follows the same path. However you can optimize the path immediatey (essentially getting a smooth handoff ). thanks Gopal ------------------------------------------------------------------------------------------------------------- Gopal Dommety 408 525 1404 gdommety@cisco.com Cisco Systems, San Jose, CA, 95051 It is preoccupation with possessions, more than anything else, that prevents us from living freely and nobly. -Bertrand Russell From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed May 10 12:05:26 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28983 for ; Wed, 10 May 2000 12:05:26 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8B2FDBE0@standards.nortelnetworks.com>; Wed, 10 May 2000 11:54:49 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 56840 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 10 May 2000 11:54:46 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.891E8810@standards.nortelnetworks.com>; Wed, 10 May 2000 11:54:45 -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 JAA17042; Wed, 10 May 2000 09:01:42 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id IAA23605; Wed, 10 May 2000 08:51:25 -0700 X-Virus-Scanned: Wed, 10 May 2000 08:51:25 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from (charliep.iprg.nokia.com [205.226.2.89]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma023302; Wed, 10 May 00 08:51:16 -0700 X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <3919416F.F92AC19C@mchp.siemens.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <391987DD.3ADA5EF6@iprg.nokia.com> Date: Wed, 10 May 2000 09:01:33 -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] Presentation slides LA '96 / Adelaide X-To: Jochen Grimminger To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Jochen, I believe that the functionality described by Gopal is a subset of the functionality in our Regional Registration draft, where basically our GFA entity is allowed to be selected dynamically and associated with the mobile node at the time of the regional registration. If there is some way in which we unintentionally have failed to include that functionality, we would like to correct that, and welcome comments about where the failure may have arisen. Since we have had this draft available for quite a long while now, I also do not believe that there can be any new intellectual property assigned to Cisco for this approach. But, I am not a lawyer, am not authoritative on patent law, and I do not wish to be held liable for my legally-untrained opinions. Regards, Charlie P. Jochen Grimminger wrote: > > > > Hallo Dave, hello everybody on the MIP mailing list > > in Adelaide Gopal Dommety made his presentation (draft) in MIP about "Fast > Handover" described in the draft > "draft-dommety-mobileip-anchor-handoff-00.txt" ... the topic was quite > interesting ... and Dave Johnson made quite clear that in LA he has presented > something similar (draft-whatwasitsname). I was searching for your > presentation and the according draft, but all i found on your homepage was > .... > > > * The 35th Internet Engineering Task Force meeting, Los Angeles, CA, March > 4-8, 1996: > > "Design Questions in Route Optimization", Mobile IP Working Group > Meeting, March 7, 1996. > "Location Areas in Mobile IP", Mobile IP Working Group meeting, > David B. Johnson, March 7, 1996 > > > I'm working in the MIP / MIP IPv6/MicroMobility enviroment. Could you or > somebody on the list please send the documents directly to me or just make > them available on any public homepage or via the MIP mailinglist. > > Best regards and many thanks in advance > > Jochen Grimminger > > PS: I'm pretty sure i'm not the only one who was interested ;-) with respect > to the fast handover discussions > on the list. By the way what about the state of all the micro mobility drafts, > most of them are and cellularIP is about to expire . > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed May 10 13:34:42 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00517 for ; Wed, 10 May 2000 13:34:42 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.710AD280@standards.nortelnetworks.com>; Wed, 10 May 2000 13:27:08 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 57096 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 10 May 2000 13:25:14 -0400 Received: from omega.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2C9493C0@standards.nortelnetworks.com>; Wed, 10 May 2000 13:25:14 -0400 Received: from gopal (gdommety-dsl3.cisco.com [10.19.17.140]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id KAA18430; Wed, 10 May 2000 10:31:34 -0700 (PDT) X-Sender: gdommety@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 References: <3919416F.F92AC19C@mchp.siemens.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <4.1.20000510102549.00997730@omega.cisco.com> Date: Wed, 10 May 2000 10:37:54 -0700 Reply-To: Gopal Dommety Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gopal Dommety Subject: Re: [MOBILE-IP] Presentation slides LA '96 / Adelaide X-To: charliep@IPRG.NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <391987DD.3ADA5EF6@iprg.nokia.com> Charlie: >I believe that the functionality described by Gopal is a >subset of the functionality in our Regional Registration >draft, where basically our GFA entity is allowed to be >selected dynamically and associated with the mobile node >at the time of the regional registration. If there is Could you elobrate a bit more on how the Regional Registration covers this draft? The basic difference is that the Regionalized Tunnels is based on a centralized approach and the local anchoring is a distributed approach. >Since we have had this draft available for quite a long >while now, I also do not believe that there can be any >new intellectual property assigned to Cisco for this approach. >But, I am not a lawyer, am not authoritative on patent law, >and I do not wish to be held liable for my legally-untrained >opinions. Standard Disclaimer: I am not a lawyer, so my opinions are legally-untrained. Dave Johnson's LA presentation is the same as the local anchoring. Will work with Dave on that. So, most of the IPR claim may be moot. Moreover the licencing, if there is any, is apprently provided free of cost. thanks Gopal > >Regards, >Charlie P. > > >Jochen Grimminger wrote: >> >> >> >> Hallo Dave, hello everybody on the MIP mailing list >> >> in Adelaide Gopal Dommety made his presentation (draft) in MIP about "Fast >> Handover" described in the draft >> "draft-dommety-mobileip-anchor-handoff-00.txt" ... the topic was quite >> interesting ... and Dave Johnson made quite clear that in LA he has presented >> something similar (draft-whatwasitsname). I was searching for your >> presentation and the according draft, but all i found on your homepage was >> .... >> >> >> * The 35th Internet Engineering Task Force meeting, Los Angeles, CA, March >> 4-8, 1996: >> >> "Design Questions in Route Optimization", Mobile IP Working Group >> Meeting, March 7, 1996. >> "Location Areas in Mobile IP", Mobile IP Working Group meeting, >> David B. Johnson, March 7, 1996 >> >> >> I'm working in the MIP / MIP IPv6/MicroMobility enviroment. Could you or >> somebody on the list please send the documents directly to me or just make >> them available on any public homepage or via the MIP mailinglist. >> >> Best regards and many thanks in advance >> >> Jochen Grimminger >> >> PS: I'm pretty sure i'm not the only one who was interested ;-) with respect >> to the fast handover discussions >> on the list. By the way what about the state of all the micro mobility >drafts, >> most of them are and cellularIP is about to expire . >> >> > ------------------------------------------------------------------------------------------------------------- Gopal Dommety 408 525 1404 gdommety@cisco.com Cisco Systems, San Jose, CA, 95051 It is preoccupation with possessions, more than anything else, that prevents us from living freely and nobly. -Bertrand Russell From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed May 10 16:40:57 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03566 for ; Wed, 10 May 2000 16:40:57 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7826E530@standards.nortelnetworks.com>; Wed, 10 May 2000 16:33:27 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 57344 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 10 May 2000 16:32:09 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4944F130@standards.nortelnetworks.com>; Wed, 10 May 2000 16:32:09 -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 OAA24792 for ; Wed, 10 May 2000 14:39:04 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA16582; Wed, 10 May 2000 13:38:56 -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 NAA15475; Wed, 10 May 2000 13:38:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Wed, 10 May 2000 13:38:55 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: [MOBILE-IP] Regional Registration Questions X-cc: pcalhoun@eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM I have a couple of last questions, and assumptions regarding the above draft. First, I am assuming that the *dynamic* security associations that get created as a result of AAA are as follows (communication path is shown by single line, while SAs are shown by double lines): +=========================+ || || MN =========+ || | || || | || || | || || FA---------GFA ========== HA | | | | | | AAAF-----------AAAH This means that the Mobile Node gets keying information that it would use to authenticate MN-GFA messages, and the GFA would auth with the MN and the HA. Of course, the MN would also create the MN-HA auth ext. So, the FA should NEVER have a security association with the HA, right? And furthermore, the MN should NEVER have a security association with the FA, right? If not, please let me know why. The idea of the MN share an SA with both the FA and the GFA seems odd. First, they are owned by the same administrative domain, so they trust themselves, and it reduces the overhead and complexity of the protocol. Am I wrong? PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed May 10 16:54:59 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03662 for ; Wed, 10 May 2000 16:54:59 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.70AD5F80@standards.nortelnetworks.com>; Wed, 10 May 2000 16:47:34 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 57421 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 10 May 2000 16:46:11 -0400 Received: from imr1.ericy.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3F7E9550@standards.nortelnetworks.com>; Wed, 10 May 2000 16:46:11 -0400 Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id PAA01735 for ; Wed, 10 May 2000 15:53:09 -0500 (CDT) Received: from SMTP (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with SMTP id PAA29432 for ; Wed, 10 May 2000 15:53:07 -0500 (CDT) Received: from eamrcnt740.exu.ericsson.se ([138.85.133.41]) by 138.85.133.38 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 10 May 2000 20:53:06 0000 (GMT) Received: by eamrcnt740.exu.ericsson.se with Internet Mail Service (5.5.2448.0) id ; Wed, 10 May 2000 15:53: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: <125911DC0503D4119E2400508B0CCD2F012227CB@eamrcnt718.exu.ericsson.se> Date: Wed, 10 May 2000 15:52:57 -0500 Reply-To: "Kevin Purser (EUS)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Kevin Purser (EUS)" Subject: [MOBILE-IP] Reverse Tunneling (encapsulated delivery) To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello all, A couple of questions regarding the draft on reverse tunneling (draft-ietf-mobileip-rfc2344-bis-01.txt), encapsulated delivery method: 1) As described in Sec 3.3, the encapsulated delivery style extension must be included after the MN-HA Auth extension and before the MN-FA Auth extension. Additionally, the FA must consume the extension. The problem that arises is that the authentication value calculated by the MN includes this extension (by virtue of it's placement among the extensions) and this authentication value can only be verified by the HA/AAA, not the FA. So after the FA removes the encapsulated delivery extension, it invalidates the authentication value, and is incapable of calculating a new value. How could this be remedied? It is imperative that the FA remove this extension? 2) I have not seen any mention of the protocol behavior from the FA-->MN for regular data packets. Shouldn't these packets be encapsulated as well to allow the MN to receive multi-/broadcast packets from it's home network? Kevin Purser Software Engineer III ERICSSON, INC. 2100 Shattuck Avenue (Enter on Addison Street) Berkeley, CA 94704-1209 Phone: (510) 305-6100 Fax: (510) 981-4016 > -----Original Message----- > From: Gopal Dommety [SMTP:gdommety@CISCO.COM] > Sent: Wednesday, May 10, 2000 10:38 AM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Presentation slides LA '96 / Adelaide > > Charlie: > > >I believe that the functionality described by Gopal is a > >subset of the functionality in our Regional Registration > >draft, where basically our GFA entity is allowed to be > >selected dynamically and associated with the mobile node > >at the time of the regional registration. If there is > > Could you elobrate a bit more on how the Regional > Registration covers this draft? > > The basic difference is that the Regionalized Tunnels is based on a > centralized approach and the local anchoring > is a distributed approach. > > > >Since we have had this draft available for quite a long > >while now, I also do not believe that there can be any > >new intellectual property assigned to Cisco for this approach. > >But, I am not a lawyer, am not authoritative on patent law, > >and I do not wish to be held liable for my legally-untrained > >opinions. > > Standard Disclaimer: I am not a lawyer, so my opinions are > legally-untrained. > > Dave Johnson's LA presentation is the same as the local anchoring. > Will work with Dave on that. So, most of the IPR claim may be moot. > > Moreover the licencing, if there is any, is apprently provided free of > cost. > > thanks > Gopal > > > > > >Regards, > >Charlie P. > > > > > >Jochen Grimminger wrote: > >> > >> > >> > >> Hallo Dave, hello everybody on the MIP mailing list > >> > >> in Adelaide Gopal Dommety made his presentation (draft) in MIP about > "Fast > >> Handover" described in the draft > >> "draft-dommety-mobileip-anchor-handoff-00.txt" ... the topic was quite > >> interesting ... and Dave Johnson made quite clear that in LA he has > presented > >> something similar (draft-whatwasitsname). I was searching for your > >> presentation and the according draft, but all i found on your homepage > was > >> .... > >> > >> > >> * The 35th Internet Engineering Task Force meeting, Los Angeles, CA, > March > >> 4-8, 1996: > >> > >> "Design Questions in Route Optimization", Mobile IP Working > Group > >> Meeting, March 7, 1996. > >> "Location Areas in Mobile IP", Mobile IP Working Group > meeting, > >> David B. Johnson, March 7, 1996 > >> > >> > >> I'm working in the MIP / MIP IPv6/MicroMobility enviroment. Could you > or > >> somebody on the list please send the documents directly to me or just > make > >> them available on any public homepage or via the MIP mailinglist. > >> > >> Best regards and many thanks in advance > >> > >> Jochen Grimminger > >> > >> PS: I'm pretty sure i'm not the only one who was interested ;-) with > respect > >> to the fast handover discussions > >> on the list. By the way what about the state of all the micro mobility > >drafts, > >> most of them are and cellularIP is about to expire . > >> > >> > > > > -------------------------------------------------------------------------- > ----------------------------------- > Gopal Dommety 408 525 1404 gdommety@cisco.com > Cisco Systems, San Jose, CA, 95051 > > It is preoccupation with possessions, more than anything else, that > prevents us from living freely and nobly. -Bertrand Russell From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed May 10 17:14:07 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03884 for ; Wed, 10 May 2000 17:14:07 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1BA28FD0@standards.nortelnetworks.com>; Wed, 10 May 2000 17:06:40 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 57493 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 10 May 2000 17:05:06 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E3779830@standards.nortelnetworks.com>; Wed, 10 May 2000 17:05:05 -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 OAA20294; Wed, 10 May 2000 14:12:05 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id OAA05448; Wed, 10 May 2000 14:00:52 -0700 X-Virus-Scanned: Wed, 10 May 2000 14:00:52 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from (charliep.iprg.nokia.com [205.226.2.89]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma005216; Wed, 10 May 00 14:00:47 -0700 X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3919D09F.9E4A1C55@iprg.nokia.com> Date: Wed, 10 May 2000 14:11:59 -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] Regional Registration Questions X-To: "pcalhoun@eng.sun.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Pat, What would you say if the mobile node had a key that worked with both the GFA and the FA simultaneously? In other words, what if the mobile node had a MN<-->*FA security association? Presumably, the GFA could pass the MN<-->*FA security association along to any foreign agent in the same domain. Of course, any suggestions about simplifying the protocol will be appreciated. Regards, Charlie P. "pcalhoun@eng.sun.com" wrote: > > I have a couple of last questions, and assumptions regarding the above draft. > > First, I am assuming that the *dynamic* security associations that get created > as a result of AAA are as follows (communication path is shown by single line, > while SAs are shown by double lines): > > +=========================+ > || || > MN =========+ || > | || || > | || || > | || || > FA---------GFA ========== HA > | | > | | > | | > AAAF-----------AAAH > > This means that the Mobile Node gets keying information that it would use to > authenticate MN-GFA messages, and the GFA would auth with the MN and the HA. > Of course, the MN would also create the MN-HA auth ext. > > So, the FA should NEVER have a security association with the HA, right? And > furthermore, the MN should NEVER have a security association with the FA, > right? If not, please let me know why. The idea of the MN share an SA with > both the FA and the GFA seems odd. First, they are owned by the same > administrative domain, so they trust themselves, and it reduces the overhead > and complexity of the protocol. > > Am I wrong? > > PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed May 10 17:20:11 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03921 for ; Wed, 10 May 2000 17:20:11 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F42F92D0@standards.nortelnetworks.com>; Wed, 10 May 2000 17:12:43 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 57536 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 10 May 2000 17:11:24 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C522BE40@standards.nortelnetworks.com>; Wed, 10 May 2000 17:11:24 -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 PAA23723; Wed, 10 May 2000 15:18:22 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA24523; Wed, 10 May 2000 14:18:17 -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 OAA16892; Wed, 10 May 2000 14:18:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Wed, 10 May 2000 14:18:16 -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] Regional Registration Questions X-To: "Charles E. Perkins" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <3919D09F.9E4A1C55@iprg.nokia.com> > > Hello Pat, > > What would you say if the mobile node had a key that worked > with both the GFA and the FA simultaneously? In other words, > what if the mobile node had a MN<-->*FA security association? > Presumably, the GFA could pass the MN<-->*FA security > association along to any foreign agent in the same domain. What would I say? I would say that it would make me REALLY happy! This simplification would really benefit the I-D. > > Of course, any suggestions about simplifying the protocol > will be appreciated. So, it sounds like what is needed is when the GFA receives the keying information from the AAA infrastructure, it is able to forward the keys to the FA. This *could* be done by using the Foreign Agent blob extensions, or through some other yet to be defined extension. When the FA receives the RegReq, if the MN-AAA is not present, it could then authenticate the MN-FA. This ensures security throughout the whole path, and minimizes the number of security associations. Perfect! PatC > > Regards, > Charlie P. > > > > "pcalhoun@eng.sun.com" wrote: > > > > I have a couple of last questions, and assumptions regarding the above draft. > > > > First, I am assuming that the *dynamic* security associations that get created > > as a result of AAA are as follows (communication path is shown by single line, > > while SAs are shown by double lines): > > > > +=========================+ > > || || > > MN =========+ || > > | || || > > | || || > > | || || > > FA---------GFA ========== HA > > | | > > | | > > | | > > AAAF-----------AAAH > > > > This means that the Mobile Node gets keying information that it would use to > > authenticate MN-GFA messages, and the GFA would auth with the MN and the HA. > > Of course, the MN would also create the MN-HA auth ext. > > > > So, the FA should NEVER have a security association with the HA, right? And > > furthermore, the MN should NEVER have a security association with the FA, > > right? If not, please let me know why. The idea of the MN share an SA with > > both the FA and the GFA seems odd. First, they are owned by the same > > administrative domain, so they trust themselves, and it reduces the overhead > > and complexity of the protocol. > > > > Am I wrong? > > > > PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed May 10 17:57:23 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04199 for ; Wed, 10 May 2000 17:57:23 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2571A4A0@standards.nortelnetworks.com>; Wed, 10 May 2000 17:49:53 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 57649 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 10 May 2000 17:48:10 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.81F07460@standards.nortelnetworks.com>; Wed, 10 May 2000 17:38:09 -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 PAA13148 for ; Wed, 10 May 2000 15:45:07 -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 RAA22246; Wed, 10 May 2000 17:45:06 -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 RAA26547; Wed, 10 May 2000 17:45:15 -0400 (EDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Wed, 10 May 2000 17:45:02 -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] Reverse Tunneling (encapsulated delivery) X-To: "Kevin Purser (EUS)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <125911DC0503D4119E2400508B0CCD2F012227CB@eamrcnt718.exu.ericsson.se> > Hello all, > > A couple of questions regarding the draft on reverse tunneling > (draft-ietf-mobileip-rfc2344-bis-01.txt), encapsulated delivery method: > > 1) As described in Sec 3.3, the encapsulated delivery style extension must > be included after the MN-HA Auth extension and before the MN-FA Auth > extension. So it looks like this: <----- direction of packet ----- {Registration Request, MN-HA auth, EDS extentino, MN-FA auth} > Additionally, the FA must consume the extension. The problem > that arises is that the authentication value calculated by the MN includes > this extension (by virtue of it's placement among the extensions) and this > authentication value can only be verified by the HA/AAA, not the FA. Not true. The last two items above are consumed after the FA verifies the MN-FA auth. > 2) I have not seen any mention of the protocol behavior from the FA-->MN for > regular data packets. Shouldn't these packets be encapsulated as well to > allow the MN to receive multi-/broadcast packets from it's home network? There is no change here as this is NOT a reverse tunneling issue. These packets are multiply encapsulated by the HA so the FA knows where they are going. That is, the packet looks like: <------direction of travel---- { (FAdst, HAsrc), (MNdst, HAsrc), (MCASTdst, CNsrc), data } The HA adds the two "forward-most" IP headers. In the inverse, when the MN wants to send a multi/broadcast message to it's home subnet, it MUST use reverse tunneling, and it MUST encapsulate the packet itself (the FA just reverse tunnels it as usual). If not, it would be sending to the multi/broadcast ip address, and the FA's HW address. The packet then looks like: <------direction of travel---- { (FAdst, MNsrc), (MCASTdst, MNsrc), data } The FA consumes the first IP header, and puts the reverse tunnel header on the packet. When the HA gets it, it strips off the outer header, then just delivers the packet to the MN's link as usual. Hope this clears things up! Cheers, Steve From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed May 10 18:10:23 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04359 for ; Wed, 10 May 2000 18:10:23 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F922CCB0@standards.nortelnetworks.com>; Wed, 10 May 2000 18:02:58 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 57727 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 10 May 2000 18:01:12 -0400 Received: from ftpbox.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B9F20AB0@standards.nortelnetworks.com>; Wed, 10 May 2000 18:01:12 -0400 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id PAA04923 for ; Wed, 10 May 2000 15:08:12 -0700 (MST)] Received: [from az33exb01.corp.mot.com ([199.2.84.12]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id PAA15411 for ; Wed, 10 May 2000 15:08:11 -0700 (MST)] Received: by AZ33EXB01 with Internet Mail Service (5.5.2650.21) id ; Wed, 10 May 2000 15:08:11 -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: Wed, 10 May 2000 15:08:10 -0700 Reply-To: Core Scott-P18750 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Core Scott-P18750 Subject: Re: [MOBILE-IP] Regional Registration Questions To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Pat I must have missed something. Why is it valuable to have the MN-FA security association common to the MN-GFA association? If the MN moves to another FA, the registration request must still be sent to the GFA to update the local care-of-address (the new FA) so you don't save any registration time by having the keying information at the FA. What did I miss. scott > > Hello Pat, > > What would you say if the mobile node had a key that worked > with both the GFA and the FA simultaneously? In other words, > what if the mobile node had a MN<-->*FA security association? > Presumably, the GFA could pass the MN<-->*FA security > association along to any foreign agent in the same domain. What would I say? I would say that it would make me REALLY happy! This simplification would really benefit the I-D. > > Of course, any suggestions about simplifying the protocol > will be appreciated. So, it sounds like what is needed is when the GFA receives the keying information from the AAA infrastructure, it is able to forward the keys to the FA. This *could* be done by using the Foreign Agent blob extensions, or through some other yet to be defined extension. When the FA receives the RegReq, if the MN-AAA is not present, it could then authenticate the MN-FA. This ensures security throughout the whole path, and minimizes the number of security associations. Perfect! PatC > > Regards, > Charlie P. > > > > "pcalhoun@eng.sun.com" wrote: > > > > I have a couple of last questions, and assumptions regarding the above draft. > > > > First, I am assuming that the *dynamic* security associations that get created > > as a result of AAA are as follows (communication path is shown by single line, > > while SAs are shown by double lines): > > > > +=========================+ > > || || > > MN =========+ || > > | || || > > | || || > > | || || > > FA---------GFA ========== HA > > | | > > | | > > | | > > AAAF-----------AAAH > > > > This means that the Mobile Node gets keying information that it would use to > > authenticate MN-GFA messages, and the GFA would auth with the MN and the HA. > > Of course, the MN would also create the MN-HA auth ext. > > > > So, the FA should NEVER have a security association with the HA, right? And > > furthermore, the MN should NEVER have a security association with the FA, > > right? If not, please let me know why. The idea of the MN share an SA with > > both the FA and the GFA seems odd. First, they are owned by the same > > administrative domain, so they trust themselves, and it reduces the overhead > > and complexity of the protocol. > > > > Am I wrong? > > > > PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed May 10 18:16:25 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04396 for ; Wed, 10 May 2000 18:16:25 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D3405AC0@standards.nortelnetworks.com>; Wed, 10 May 2000 18:09:04 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 57800 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 10 May 2000 18:07:27 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.99826710@standards.nortelnetworks.com>; Wed, 10 May 2000 18:07: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 QAA03283; Wed, 10 May 2000 16:14:21 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA09199; Wed, 10 May 2000 15:14:14 -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 PAA18515; Wed, 10 May 2000 15:14:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Wed, 10 May 2000 15:14:10 -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] Regional Registration Questions X-To: Core Scott-P18750 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" > Pat > I must have missed something. Why is it valuable to have the MN-FA security > association common to the MN-GFA association? If the MN moves to another FA, > the registration request must still be sent to the GFA to update the local > care-of-address (the new FA) so you don't save any registration time by > having the keying information at the FA. What did I miss. Of course, this would be dependent upon one of the hand-off proposals, that would allow the old FA to exchange keying information to the new FA. However, I do see your point, that simply supporting Regional Registration would make it really difficult for the new FA to retrieve the necessary keying information without any additional support. PatC > > scott > > > > > > Hello Pat, > > > > What would you say if the mobile node had a key that > worked > > with both the GFA and the FA simultaneously? In other > words, > > what if the mobile node had a MN<-->*FA security > association? > > Presumably, the GFA could pass the MN<-->*FA security > > association along to any foreign agent in the same domain. > > What would I say? I would say that it would make me REALLY > happy! This > simplification would really benefit the I-D. > > > > > Of course, any suggestions about simplifying the protocol > > will be appreciated. > So, it sounds like what is needed is when the GFA receives > the keying > information from the AAA infrastructure, it is able to > forward the keys to the > FA. This *could* be done by using the Foreign Agent blob > extensions, or > through some other yet to be defined extension. > > When the FA receives the RegReq, if the MN-AAA is not > present, it could then > authenticate the MN-FA. This ensures security throughout the > whole path, and > minimizes the number of security associations. > > Perfect! > > PatC > > > > Regards, > > Charlie P. > > > > > > > > "pcalhoun@eng.sun.com" wrote: > > > > > > I have a couple of last questions, and assumptions > regarding the above draft. > > > > > > First, I am assuming that the *dynamic* security > associations that get created > > > as a result of AAA are as follows (communication path is > shown by single line, > > > while SAs are shown by double lines): > > > > > > +=========================+ > > > || || > > > MN =========+ || > > > | || || > > > | || || > > > | || || > > > FA---------GFA ========== HA > > > | | > > > | | > > > | | > > > AAAF-----------AAAH > > > > > > This means that the Mobile Node gets keying information > that it would use to > > > authenticate MN-GFA messages, and the GFA would auth > with the MN and the HA. > > > Of course, the MN would also create the MN-HA auth ext. > > > > > > So, the FA should NEVER have a security association with > the HA, right? And > > > furthermore, the MN should NEVER have a security > association with the FA, > > > right? If not, please let me know why. The idea of the > MN share an SA with > > > both the FA and the GFA seems odd. First, they are owned > by the same > > > administrative domain, so they trust themselves, and it > reduces the overhead > > > and complexity of the protocol. > > > > > > Am I wrong? > > > > > > PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed May 10 18:19:36 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04417 for ; Wed, 10 May 2000 18:19:36 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F792C160@standards.nortelnetworks.com>; Wed, 10 May 2000 18:10:05 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 57809 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 10 May 2000 18:09:04 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D3157A30@standards.nortelnetworks.com>; Wed, 10 May 2000 18:09:03 -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 QAA04444; Wed, 10 May 2000 16:16:00 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA09624; Wed, 10 May 2000 15:15:42 -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 PAA18543; Wed, 10 May 2000 15:15:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Wed, 10 May 2000 15:15:39 -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] Regional Registration Questions X-To: Core Scott-P18750 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" Actually, now that I think of it more, one of the Internet Drafts that I co-authored defines an extension that allows the Mobile Node to carry the keying information as opaque data. This would work very well. PatC > Pat > I must have missed something. Why is it valuable to have the MN-FA security > association common to the MN-GFA association? If the MN moves to another FA, > the registration request must still be sent to the GFA to update the local > care-of-address (the new FA) so you don't save any registration time by > having the keying information at the FA. What did I miss. > > scott > > > > > > Hello Pat, > > > > What would you say if the mobile node had a key that > worked > > with both the GFA and the FA simultaneously? In other > words, > > what if the mobile node had a MN<-->*FA security > association? > > Presumably, the GFA could pass the MN<-->*FA security > > association along to any foreign agent in the same domain. > > What would I say? I would say that it would make me REALLY > happy! This > simplification would really benefit the I-D. > > > > > Of course, any suggestions about simplifying the protocol > > will be appreciated. > So, it sounds like what is needed is when the GFA receives > the keying > information from the AAA infrastructure, it is able to > forward the keys to the > FA. This *could* be done by using the Foreign Agent blob > extensions, or > through some other yet to be defined extension. > > When the FA receives the RegReq, if the MN-AAA is not > present, it could then > authenticate the MN-FA. This ensures security throughout the > whole path, and > minimizes the number of security associations. > > Perfect! > > PatC > > > > Regards, > > Charlie P. > > > > > > > > "pcalhoun@eng.sun.com" wrote: > > > > > > I have a couple of last questions, and assumptions > regarding the above draft. > > > > > > First, I am assuming that the *dynamic* security > associations that get created > > > as a result of AAA are as follows (communication path is > shown by single line, > > > while SAs are shown by double lines): > > > > > > +=========================+ > > > || || > > > MN =========+ || > > > | || || > > > | || || > > > | || || > > > FA---------GFA ========== HA > > > | | > > > | | > > > | | > > > AAAF-----------AAAH > > > > > > This means that the Mobile Node gets keying information > that it would use to > > > authenticate MN-GFA messages, and the GFA would auth > with the MN and the HA. > > > Of course, the MN would also create the MN-HA auth ext. > > > > > > So, the FA should NEVER have a security association with > the HA, right? And > > > furthermore, the MN should NEVER have a security > association with the FA, > > > right? If not, please let me know why. The idea of the > MN share an SA with > > > both the FA and the GFA seems odd. First, they are owned > by the same > > > administrative domain, so they trust themselves, and it > reduces the overhead > > > and complexity of the protocol. > > > > > > Am I wrong? > > > > > > PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 11 04:19:03 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22533 for ; Thu, 11 May 2000 04:19:02 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F53B58B0@standards.nortelnetworks.com>; Thu, 11 May 2000 4:11:18 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 58693 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 11 May 2000 04:09:25 -0400 Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B1A9FBB0@standards.nortelnetworks.com>; Thu, 11 May 2000 4:09:25 -0400 Received: from esealnt409.al.sw.ericsson.se (esealnt409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.9) with ESMTP id e4B8GNp00016 for ; Thu, 11 May 2000 10:16:24 +0200 (MET DST) Received: from SMTP ([153.88.251.32]) by esealnt409.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1); Thu, 11 May 2000 10:14:36 +0200 Received: from esealnt409-in.al.sw.ericsson.se ([153.88.251.32]) by 153.88.251.32 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 11 May 2000 08:14:36 0000 (GMT) Received: from esealnt400.al.sw.ericsson.se ([153.88.251.21]) by esealnt409-in.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1); Thu, 11 May 2000 10:14:36 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2448.0) id ; Thu, 11 May 2000 10:16:22 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 11 May 2000 08:14:36.0406 (UTC) FILETIME=[F20EB160:01BFBB20] Message-ID: <5F05C89FB2F8D211B6430008C791912703EA7FEA@esealnt190> Date: Thu, 11 May 2000 10:16:14 +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] Regional Registration Questions X-To: Core Scott-P18750 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello Scott > I must have missed something. Why is it valuable to have the > MN-FA security > association common to the MN-GFA association? If the MN > moves to another FA, > the registration request must still be sent to the GFA to > update the local > care-of-address (the new FA) so you don't save any > registration time by > having the keying information at the FA. What did I miss. I see your point with respect to the 2-level hierarchy model (GFA-FA-MN). However when using multiple-level hierarchies one could distribute the key info to all the FAs in the path to the MN. When the MN moves to a new FA, one could then have the appropriate intermediate FA send the reply back to the MN without always going up to the GFA (the resulting Reg'n lifetime would be what is left from the MN-GFA/MN-HA Reg'n lifetime which must not be about to expire). This may speed up the handoff process when a MN is moving often within a multi-level hierarchical domain. Cheers /Karim From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 11 08:29:23 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25673 for ; Thu, 11 May 2000 08:29:23 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EB344750@standards.nortelnetworks.com>; Thu, 11 May 2000 8:21:34 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 58894 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 11 May 2000 08:19:36 -0400 Received: from smtprich.nortel.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A5050DF0@standards.nortelnetworks.com>; Thu, 11 May 2000 8:19:36 -0400 Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprich.nortel.com; Thu, 11 May 2000 07:18:00 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 11 May 2000 07:26:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFBB44.275605E4" X-Orig: Message-ID: Date: Thu, 11 May 2000 07:26:35 -0500 Reply-To: Ron Young Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Ron Young Subject: [MOBILE-IP] Test 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_01BFBB44.275605E4 Content-Type: text/plain; charset="iso-8859-1" Sorry to bother everyone. Just sending a note for some test purposes. ------------------------------------------------------------------------ Ron Young ronyoung@nortelnetworks.com http://www.nortelnetworks.com/ There are only two truly infinite things, the universe and stupidity. And I am unsure about the universe. --- Albert Einstein ------_=_NextPart_001_01BFBB44.275605E4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Test

Sorry to bother everyone.  Just sending a note = for some test purposes.

---------------------------------------------------------------= ---------
Ron Young   = ronyoung@nortelnetworks.com   http://www.nortelnetworks.com/

 There are only two truly infinite things, the = universe and stupidity.
        And I am = unsure about the universe. --- Albert Einstein
 

------_=_NextPart_001_01BFBB44.275605E4-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 11 10:15:43 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28631 for ; Thu, 11 May 2000 10:15:42 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CA4D4870@standards.nortelnetworks.com>; Thu, 11 May 2000 10:08:01 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 59206 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 11 May 2000 10:07:22 -0400 Received: from ebene.inrialpes.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B1FC27A0@standards.nortelnetworks.com>; Thu, 11 May 2000 10:07:20 -0400 Received: from iseran.inrialpes.fr (iseran.inrialpes.fr [194.199.24.100]) by ebene.inrialpes.fr (8.9.3/8.8.5) with ESMTP id QAA10482; Thu, 11 May 2000 16:06:56 +0200 (MET DST) Received: from iseran (localhost [127.0.0.1]) by iseran.inrialpes.fr (8.8.7/8.8.5) with SMTP id QAA01014; Thu, 11 May 2000 16:13:49 +0200 (MET DST) X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.6 sun4u) MIME-Version: 1.0 References: <3919D09F.9E4A1C55@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <391AC01D.66DF@inrialpes.fr> Date: Thu, 11 May 2000 16:13:49 +0200 Reply-To: Claude.Castelluccia@INRIALPES.FR Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Claude Castelluccia Subject: Re: [MOBILE-IP] Regional Registration Questions X-To: charliep@IPRG.NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Charles E. Perkins wrote: > > Hello Pat, > > What would you say if the mobile node had a key that worked > with both the GFA and the FA simultaneously? In other words, > what if the mobile node had a MN<-->*FA security association? > Presumably, the GFA could pass the MN<-->*FA security > association along to any foreign agent in the same domain. > > Of course, any suggestions about simplifying the protocol > will be appreciated. > Hello Charlie, I find the CellularIP solution quite interesting. It should be easy to adapt it to MIP with Regional Registration? What do you think? regards, Claude. Cellular IP IETF draft pg 14: "Each Cellular IP Network has a secret network key of arbitrary length known to all Cellular IP nodes. The network key is kept secret from mobile hosts and other nodes outside the Cellular IP Network, however. Upon initial registration the Gateway must authenticate and possibly authorize the mobile host. This initial authentication and authorization can be based on any known symmetric or asymmetric method. After authentication the Gateway concatenates the key of the network and the IP address of the mobile host and calculates the PID of the mobile host by an MD5 Hash similarly as in [4]: PID := MD5(network key, IP address of MH) Then it acquires the public key of the mobile host from a trusted party, encrypts the PID and sends it to the mobile host. This way the mobile host and the Cellular IP network have a shared secret. The PID remains the same during handoff and can be easily computed by each Base Station. The PID can be used to authenticate (and optionally to encrypt) IP packets over the air interface. Authentication is performed by creating a short hash from the (PID, timestamp, packet content) triple that is placed into the transmitted packets. The validity of each packet can be easily checked by any Base Station even immediately after a handoff and without prior communication with the mobile host or with the old Base Station." -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 11 11:08:02 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29896 for ; Thu, 11 May 2000 11:08:02 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.18197EF0@standards.nortelnetworks.com>; Thu, 11 May 2000 11:00:18 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 59397 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 11 May 2000 10:58:32 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D8A60EA0@standards.nortelnetworks.com>; Thu, 11 May 2000 10:58:32 -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 IAA19292; Thu, 11 May 2000 08:04:27 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id HAA02020; Thu, 11 May 2000 07:50:07 -0700 X-Virus-Scanned: Thu, 11 May 2000 07:50:07 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from (charliep.iprg.nokia.com [205.226.2.89]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma001837; Thu, 11 May 00 07:50:01 -0700 X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <3919D09F.9E4A1C55@iprg.nokia.com> <391AC01D.66DF@inrialpes.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <391ACBF5.4B27523E@iprg.nokia.com> Date: Thu, 11 May 2000 08:04:21 -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] Regional Registration Questions X-To: Claude.Castelluccia@INRIALPES.FR To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Claude, Generally, I would prefer to keep the security framework separate from the regional registration document. However, I can offer the following comments: > "Each Cellular IP Network has a secret network key of arbitrary length > known to all Cellular IP nodes. The network key is kept secret from > mobile hosts and other nodes outside the Cellular IP Network, > however. Upon initial registration the Gateway must authenticate and > possibly authorize the mobile host. This initial authentication and > authorization can be based on any known symmetric or asymmetric > method. After authentication the Gateway concatenates the key of the > network and the IP address of the mobile host and calculates the PID > of the mobile host by an MD5 Hash similarly as in [4]: > > PID := MD5(network key, IP address of MH) So far, so good... > Then it acquires the public key of the mobile host from a trusted > party, encrypts the PID and sends it to the mobile host. This way > the mobile host and the Cellular IP network have a shared secret. > The PID remains the same during handoff and can be easily computed by > each Base Station. This is also workable, but I don't think we should restrict our solution to public key mechanisms only. I think it is just as likely that the AAA infrastructure will be used to distribute symmetric keys. > The PID can be used to authenticate (and optionally to encrypt) IP > packets over the air interface. Authentication is performed by > creating a short hash from the (PID, timestamp, packet content) > triple that is placed into the transmitted packets. The validity of > each packet can be easily checked by any Base Station even > immediately after a handoff and without prior communication with the > mobile host or with the old Base Station." This is also fine with me, but it has to be recognized that the security needs for privacy over the air can be considered as distinct from the security needs for authenticating binding updates and registration messages. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 11 11:39:23 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00748 for ; Thu, 11 May 2000 11:39:22 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.71730B20@standards.nortelnetworks.com>; Thu, 11 May 2000 11:31:26 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 59450 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 11 May 2000 11:30:07 -0400 Received: from ertpg14e1.nortelnetworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DCC09890@standards.nortelnetworks.com>; Thu, 11 May 2000 11:20:07 -0400 Received: from zcard00m.ca.nortel.com (actually zcard00m) by ertpg14e1.nortelnetworks.com; Thu, 11 May 2000 11:24:53 -0400 Received: from zcard00p.ca.nortel.com ([47.141.0.104]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id K4DZWXB9; Thu, 11 May 2000 11:24:48 -0400 Received: from americasm01.nt.com (zcars02x.ca.nortel.com [47.23.81.10]) by zcard00p.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KWF00BPF; Thu, 11 May 2000 11:24:48 -0400 X-Mailer: Mozilla 4.6C-CCK-MCD [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <391AD0C1.B9C648AD@americasm01.nt.com> Date: Thu, 11 May 2000 11:24:49 -0400 Reply-To: Cheng-Yin Lee Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Cheng-Yin Lee Organization: Nortel Networks Subject: [MOBILE-IP] How does an FA know its GFA? To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit How does an FA know its GFA (or next level FA) in draft-ietf-mobileip-reg-tunnel-02.txt? thanks, cyl From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 11 11:59:22 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01291 for ; Thu, 11 May 2000 11:59:21 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.42902560@standards.nortelnetworks.com>; Thu, 11 May 2000 11:51:36 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 59635 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 11 May 2000 11:49:50 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9DC84450@standards.nortelnetworks.com>; Thu, 11 May 2000 11:39:50 -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 JAA10179; Thu, 11 May 2000 09:46:42 -0600 (MDT) Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM [129.146.101.34]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id IAA03075; Thu, 11 May 2000 08:45:57 -0700 (PDT) Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA07396; Thu, 11 May 2000 08:45:45 -0700 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Thu, 11 May 2000 08:45:45 -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] How does an FA know its GFA? X-To: Cheng-Yin Lee To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <391AD0C1.B9C648AD@americasm01.nt.com> In my implementation, it is statically configured. However, it would be interesting to see a proposal that allows for the hierarchy to be dynamically built. PatC --- > How does an FA know its GFA (or next level FA) in > draft-ietf-mobileip-reg-tunnel-02.txt? > > thanks, > cyl From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 11 12:06:31 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01509 for ; Thu, 11 May 2000 12:06:31 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3F258DB0@standards.nortelnetworks.com>; Thu, 11 May 2000 11:58:40 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 59693 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 11 May 2000 11:57:06 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.06E78340@standards.nortelnetworks.com>; Thu, 11 May 2000 11:57:05 -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 JAA24594; Thu, 11 May 2000 09:04:06 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id IAA09086; Thu, 11 May 2000 08:49:36 -0700 X-Virus-Scanned: Thu, 11 May 2000 08:49:36 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from (charliep.iprg.nokia.com [205.226.2.89]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma008939; Thu, 11 May 00 08:49:31 -0700 X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <391AD0C1.B9C648AD@americasm01.nt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <391AD9F2.EFC3331F@iprg.nokia.com> Date: Thu, 11 May 2000 09:04:02 -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] How does an FA know its GFA? X-To: Cheng-Yin Lee To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Cheng-Yin, It doesn't say how to set up the interconnection between FA and GFA in that draft. We hoped this could be considered separately, since it is a router discovery issue and not a registration issue. Do you think that manual configuration is an acceptable answer for the purposes of discussion in the regional registration draft? Regards, Charlie P. Cheng-Yin Lee wrote: > > How does an FA know its GFA (or next level FA) in > draft-ietf-mobileip-reg-tunnel-02.txt? > > thanks, > cyl From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 11 12:12:32 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01659 for ; Thu, 11 May 2000 12:12:32 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.195D8190@standards.nortelnetworks.com>; Thu, 11 May 2000 12:04:46 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 59774 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 11 May 2000 12:03:17 -0400 Received: from tiku.hut.fi by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E436F050@standards.nortelnetworks.com>; Thu, 11 May 2000 12:03:17 -0400 Received: from akaatti.hut.fi (tweckstr@akaatti.hut.fi [130.233.249.61]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id TAA13628; Thu, 11 May 2000 19:05:50 +0300 (EET DST) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Message-ID: Date: Thu, 11 May 2000 19:05:49 +0300 Reply-To: =?ISO-8859-1?Q?Tom_Weckstr=F6m?= Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: =?ISO-8859-1?Q?Tom_Weckstr=F6m?= Subject: Re: [MOBILE-IP] Regional Registration Questions X-To: "Karim El-Malki (ERA)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <5F05C89FB2F8D211B6430008C791912703EA7FEA@esealnt190> Content-Transfer-Encoding: 8BIT Hello, On Thu, 11 May 2000, Karim El-Malki (ERA) wrote: Karim. >Hello Scott Karim. > Karim. >> I must have missed something. Why is it valuable to have the Karim. >> MN-FA security Karim. >> association common to the MN-GFA association? If the MN Karim. >> moves to another FA, Karim. >> the registration request must still be sent to the GFA to Karim. >> update the local Karim. >> care-of-address (the new FA) so you don't save any Karim. >> registration time by Karim. >> having the keying information at the FA. What did I miss. Karim. > Karim. >I see your point with respect to the 2-level hierarchy model Karim. >(GFA-FA-MN). However when using multiple-level hierarchies Karim. >one could distribute the key info to all the FAs in the path Karim. >to the MN. When the MN moves to a new FA, one could then have Karim. >the appropriate intermediate FA send the reply back to the MN Karim. >without always going up to the GFA (the resulting Reg'n lifetime Karim. >would be what is left from the MN-GFA/MN-HA Reg'n lifetime which Karim. >must not be about to expire). This may speed up the handoff Karim. >process when a MN is moving often within a multi-level Karim. >hierarchical domain. Karim. > Karim. >Cheers Karim. >/Karim Karim. > Exactly, Karim! This has been implemented in the hierarchical Dynamics - HUT Mobile IPv4 about one year ago. The protocol has also matured a lot since May 1999. Maybe it would be worth looking at the publications on the Dynamics web site? ;-) Regards, Tom -- Tom Weckström Dynamics group Helsinki University of Technology dynamics@cs.hut.fi http://www.cs.hut.fi/Research/Dynamics/ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 11 12:59:34 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03084 for ; Thu, 11 May 2000 12:59:33 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AE2314B0@standards.nortelnetworks.com>; Thu, 11 May 2000 12:51:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 59860 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 11 May 2000 12:50:42 -0400 Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.842E4440@standards.nortelnetworks.com>; Thu, 11 May 2000 12:50:42 -0400 Received: from esealnt406.al.sw.ericsson.se (esealnt406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.9) with ESMTP id e4BGvip13203 for ; Thu, 11 May 2000 18:57:44 +0200 (MET DST) Received: from SMTP ([153.88.251.29]) by esealnt406.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1); Thu, 11 May 2000 18:54:15 +0200 Received: from esealnt406-in.al.sw.ericsson.se ([153.88.251.29]) by 153.88.251.29 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 11 May 2000 16:54:15 0000 (GMT) Received: from esealnt400.al.sw.ericsson.se ([153.88.251.21]) by esealnt406-in.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1); Thu, 11 May 2000 18:54:14 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2448.0) id ; Thu, 11 May 2000 18:57:43 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 11 May 2000 16:54:14.0984 (UTC) FILETIME=[89F02480:01BFBB69] Message-ID: <5F05C89FB2F8D211B6430008C791912703EA7FF5@esealnt190> Date: Thu, 11 May 2000 18:57:35 +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] Regional Registration Questions X-To: =?iso-8859-1?Q?=27Tom_Weckstr=F6m=27?= To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello Tom > Exactly, Karim! This has been implemented in the > hierarchical Dynamics - > HUT Mobile IPv4 about one year ago. The protocol has also > matured a lot > since May 1999. Maybe it would be worth looking at the > publications on the > Dynamics web site? ;-) Happy to hear you have the same view. I certainly do appreciate the HUT implementation, though I must admit I was actually thinking about the Fast Handoff hierarchical MIP draft where some of these issues are discussed. (draft-elmalki-soliman-hmipv4v6-00) Any of your comments would be much appreciated given your hierarchical MIPv4 implementation. Cheers, Karim From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 11 14:09:54 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04777 for ; Thu, 11 May 2000 14:09:53 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7D5FAAF0@standards.nortelnetworks.com>; Thu, 11 May 2000 14:02:05 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 60025 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 11 May 2000 14:00:51 -0400 Received: from ertpg14e1.nortelnetworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.50E4CBE0@standards.nortelnetworks.com>; Thu, 11 May 2000 14:00:51 -0400 Received: from zcard00n.ca.nortel.com (actually zcard00n) by ertpg14e1.nortelnetworks.com; Thu, 11 May 2000 14:06:50 -0400 Received: from zcard00p.ca.nortel.com ([47.141.0.104]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KXJMRBKL; Thu, 11 May 2000 14:06:51 -0400 Received: from americasm01.nt.com (zcars02x.ca.nortel.com [47.23.81.10]) by zcard00p.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KWF00C8H; Thu, 11 May 2000 14:06:47 -0400 X-Mailer: Mozilla 4.6C-CCK-MCD [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: <391AD0C1.B9C648AD@americasm01.nt.com> <391AD9F2.EFC3331F@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <391AF6B8.ADAFAFF@americasm01.nt.com> Date: Thu, 11 May 2000 14:06:48 -0400 Reply-To: Cheng-Yin Lee Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Cheng-Yin Lee Organization: Nortel Networks Subject: Re: [MOBILE-IP] How does an FA know its GFA? X-To: charliep@IPRG.NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Charlie, "Charles E. Perkins" wrote: > Hello Cheng-Yin, > > It doesn't say how to set up the interconnection between > FA and GFA in that draft. We hoped this could be considered > separately, since it is a router discovery issue and not a > registration issue. Do you think that manual configuration > is an acceptable answer for the purposes of discussion in > the regional registration draft? i think it would be helpful if the draft discuss this and provide some recommendations. In the longer term it would be nice if manual configuration is not necessary. thanks, cyl > > > Regards, > Charlie P. > > Cheng-Yin Lee wrote: > > > > How does an FA know its GFA (or next level FA) in > > draft-ietf-mobileip-reg-tunnel-02.txt? > > > > thanks, > > cyl From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri May 12 01:38:33 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20818 for ; Fri, 12 May 2000 01:38:33 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B4AD3940@standards.nortelnetworks.com>; Fri, 12 May 2000 1:30:50 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 61176 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 12 May 2000 01:29:06 -0400 Received: from smtp-2.hut.fi by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.10910180@standards.nortelnetworks.com>; Fri, 12 May 2000 1:19:05 -0400 Received: from cc.hut.fi (root@alpha.hut.fi [130.233.224.50]) by smtp-2.hut.fi (8.9.3/8.9.3) with ESMTP id IAA19161; Fri, 12 May 2000 08:26:02 +0300 (EEST) X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20 i586) X-Accept-Language: en MIME-Version: 1.0 References: <391AD0C1.B9C648AD@americasm01.nt.com> <391AD9F2.EFC3331F@iprg.nokia.com> <391AF6B8.ADAFAFF@americasm01.nt.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <391B9646.48B7D2F3@cc.hut.fi> Date: Fri, 12 May 2000 08:27:34 +0300 Reply-To: "Tom K. =?iso-8859-1?Q?Weckstr=F6m?=" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Tom K. =?iso-8859-1?Q?Weckstr=F6m?=" Organization: HUT Subject: Re: [MOBILE-IP] How does an FA know its GFA? X-To: Cheng-Yin Lee To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit Hello folks, Cheng-Yin Lee wrote: > > Hello Charlie, > > "Charles E. Perkins" wrote: > > > Hello Cheng-Yin, > > > > It doesn't say how to set up the interconnection between > > FA and GFA in that draft. We hoped this could be considered > > separately, since it is a router discovery issue and not a > > registration issue. Do you think that manual configuration > > is an acceptable answer for the purposes of discussion in > > the regional registration draft? > > i think it would be helpful if the draft discuss this and provide some > recommendations. In the longer term it would be nice if manual > configuration is not necessary. > > > Cheng-Yin Lee wrote: > > > > > > How does an FA know its GFA (or next level FA) in > > > draft-ietf-mobileip-reg-tunnel-02.txt? > > > There is one solution for a FA registration protocol in Jouni K. Malinen's thesis I mentioned some time ago on this list. The protocol is implemented in HUT Dynamics. The protocol still requires one statically configured upper foreign agent IP address for each FA in the hierarchy, but with the protocol, each foreign agent automatically makes its NAI known to all the foreign agents above it in the hierarchy. One shared secret is needed between all the foreign agents to improve security (authentication and integrity). The protocol enables the movement of FA's without the need to reconfiqure many FA's manually. Regards, Tom -- Tom Weckström Dynamics group Helsinki University of Technology dynamics@cs.hut.fi http://www.cs.hut.fi/Research/Dynamics/ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri May 12 08:45:38 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01253 for ; Fri, 12 May 2000 08:45:38 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.53EFA200@standards.nortelnetworks.com>; Fri, 12 May 2000 8:37:37 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 61842 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 12 May 2000 08:36:23 -0400 Received: from marvin.axion.bt.co.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.27B2B650@standards.nortelnetworks.com>; Fri, 12 May 2000 8:36:23 -0400 Received: from cbtlipnt02.btlabs.bt.co.uk by marvin (local) with ESMTP; Fri, 12 May 2000 13:43:05 +0100 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2651.88) id ; Fri, 12 May 2000 13:43:03 +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: Fri, 12 May 2000 13:42:41 +0100 Reply-To: alan.w.oneill@BT.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Alan O'Neill" Subject: [MOBILE-IP] IPv6 Mobility draft comments To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Comments on the draft...Apologies if these have been discussed before but I'm new to the list... 1) CN / MN forwarding path control. On page 19 it states that 'When a mobile node receives a packet tunneled to it from its home agent, the mobile node assumes that the original sending correspondent node has no Binding Cache entry for the mobile node, since the correspondent node would otherwise have sent the packet directly to the mobile node using a Routing header' whilst on page 20 it states that 'Since correspondent nodes cache bindings, it is expected that correspondent nodes usually will route packets directly to the mobile node's care-of address, so that the home agent is rarely involved with packet transmission to the mobile node' This clearly gives the right for the CN to send to MN-HA whilst the MH assumes it won't, leading to repeated (but rate limited) sending of BU's to CN. This seems overly loose to me, and the MH shouldn't be guessing like this. Would it not be better if the CN sent something like a BR to trigger BU from MN ? Given the discussion on the list wrt forwarding control, reverse tunnelling etc this would also enable CN to indicate it's policy directly, whilst giving the MN some opportunity to override this policy based on it's configured policy (from Home operator etc). I guess the counter argument though is that we will be legitimising hosts (like large servers etc) that would rather conserve local resources (Binding, IPSEC and Routing Header processing)than conserve net resources (they can of course still do this with the existing spec but the tone of the spec is clearly against this.... 2) I couldn't find any specific reference to reverse tunneling support, or it's reasons for not being included (maybe should be mentioned for continuity reasons wrt MIP4). We may also given above need to re-install reverse tunneling support as I strongly agree with Fred's position on this... 3) Binding cancellation On page 54 'If the Lifetime specified in the Binding Update is zero OR the specified Care-of Address matches the home address for the binding, then this is a request to delete the mobile node's cached binding. 10.13. Receiving Binding Requests Note, however, that the mobile node MAY choose to keep its current binding private from the sender of the Binding Request. In this case, the mobile node instead SHOULD returns a Binding Update to the sender, in which the Lifetime field is set to zero and the care-of address is set to the mobile node's home address. In the former, either condition is used whilst in the latter both are used. Should we not be consistent or is there a good reason for this ? 4) HA reselection and discovery On page 83 'It is possible that when the mobile node needs to send a Binding Update to its home agent to register its new primary care-of address, as described in Section 10.6, the mobile node may not know the address of any router on its home link that can serve as a home agent for it.' Is it worth adding some text to describe how a MH detects that it's present HA is unreacheable and whether it should then use another HA from it's list or undertake Home Agent Discovery (or did I miss this text) ? 5)Forwarding Issues when changing CoA '10.9. Establishing Forwarding from a Previous Care-of Address When a mobile node connects to a new link and forms a new care-of address, it MAY establish forwarding of packets from a previous care-of address to this new care-of address. To do so, the mobile node sends a Binding Update to any home agent on the link on which the previous care-of address is located, indicating this previous care-of address as the home address for the binding, and giving its new care-of address as the binding's care-of address.' On returning home whilst communicating, we may need to support forwarding which I think that means that we need new text in 10.19, indicating that the BU-HA = Previous CoA and Bu-CoA=MN-HA...(Bizarre I know but is it ok ?) Also, in the case of rapid movement, policy or failed communication with HA, the MN may still be receiving tunnelled packets when it changes CoA and therefore won't we end up with multiple encapsulations ? It works but should it be prevented... Finally, the section does not mention how this forwarding state is recommended to be eliminated (time-out or explicit cancel by MN). The latter would seem better with the lifetime as a fail safe ? 6)Additional text in 10.19 Returning Home section also does not mention that we should send a binding update to all CN's to cancel the bindings to the care of address, and return to using the MN-HA. 7) General: Hand-over modes The 10.9 Forwarding section deals with 'unplanned' hand-over whereby the MH is now at the new CoA, remembers the old CoA and old HA, and so installs forwarding. The draft does not however deal with planned hand-over (routed at old HA as in cellular) which may be useful for the IP fast hand-over work. In planned hand-over (see EMA draft), the 'system' knows where you are going and can therefore install the temporary tunnel before you leave and subsequently lose the link to the HA. Probably out of scope for this draft (big divergence from model) but worth looking at the cellular equivalent messaging for comparison. Alan. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri May 12 11:11:12 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03762 for ; Fri, 12 May 2000 11:11:11 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B0CF2D60@standards.nortelnetworks.com>; Fri, 12 May 2000 11:03:23 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 62384 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 12 May 2000 11:01:56 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7C4F8A80@standards.nortelnetworks.com>; Fri, 12 May 2000 11:01:55 -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 IAA00507; Fri, 12 May 2000 08:08:58 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id HAA30339; Fri, 12 May 2000 07:50:24 -0700 X-Virus-Scanned: Fri, 12 May 2000 07:50:24 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from (charliep.iprg.nokia.com [205.226.2.89]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma030064; Fri, 12 May 00 07:50:18 -0700 X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <391C1E84.4B7064C3@iprg.nokia.com> Date: Fri, 12 May 2000 08:08: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 Mobility draft comments X-To: alan.w.oneill@BT.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Alan, > on page 20 it states that 'Since correspondent nodes cache bindings, > it is expected that > correspondent nodes usually will route packets directly to the mobile > node's care-of address, so that the home agent is rarely involved > with packet transmission to the mobile node' This means the the correspondent nodes usually have valid bindings for the mobile node, unless the mobile node wishes otherwise. > This clearly gives the right for the CN to send to MN-HA whilst the MH > assumes it won't, leading to repeated (but rate limited) sending of BU's to > CN. This seems overly loose to me, and the MH shouldn't be guessing like > this. Would it not be better if the CN sent something like a BR to trigger > BU from MN ? With the interpretation above, the CN is not granted such rights. Of course, we could not necessarily prevent the CN from abrogating those rights anyway, but thems the breaks. I would much prefer to allow the mobile node to send unsolicited Binding Updates as it is in the current specification. > Given the discussion on the list wrt forwarding control, reverse tunnelling > etc this would also enable CN to indicate it's policy directly, whilst > giving the MN some opportunity to override this policy based on it's > configured policy (from Home operator etc). I didn't get the part about how CNs were involved with reverse tunneling. Furthermore, the mobile node should be able to execute whatever protocols it wants to execute without getting explicit permission from the Mobile IPv6 document. Reverse tunneling in IPv6 does not have sufficient interaction with Mobile IPv6 to merit inclusion in that document. If a node wishes to tunnel, I don't see that Mobile IPv6 should cause it to ask permission from anyone. > 2) I couldn't find any specific reference to reverse tunneling support, or > it's reasons for not being included (maybe should be mentioned for > continuity reasons wrt MIP4). We may also given above need to re-install > reverse tunneling support as I strongly agree with Fred's position on > this... I hope it is obvious from the above that I do not think we need this. And, especially, I do not think it has to be resolved before we go to Proposed Standard. If you would like to submit another Internet Draft detailing a reverse tunneling procedure, then that could be considered as a separate matter. > On returning home whilst communicating, we may need to support forwarding > which I think that means that we need new text in 10.19, indicating that > the BU-HA = Previous CoA and Bu-CoA=MN-HA...(Bizarre I know but is it ok ?) I couldn't parse this. Does it mean that the mobile node should tell the previous router that it has gone home? In that case, I reckon that the previous router still has to tunnel the packet back to the mobile node, presumably with the tunnel destination set equal to the home address. > Also, in the case of rapid movement, policy or failed communication with HA, > the MN may still be receiving tunnelled packets when it changes CoA and > therefore won't we end up with multiple encapsulations ? It works but should > it be prevented... What is wrong with multiple encapsulations? Are you suggesting that the intermediate encapsulator should first decapsulate? This seems like it would be a nightmare to specify correctly. Maybe this would also be suitable for another draft, or for insertion when the draft goes from Proposed Standard to Draft Standard. > Finally, the section does not mention how this forwarding state is > recommended to be eliminated (time-out or explicit cancel by MN). The latter > would seem better with the lifetime as a fail safe ? I thought that the mobile node should typically make an explicit determination to invalidate bindings at the appropriate correspondent nodes. > 7) General: Hand-over modes > > The 10.9 Forwarding section deals with 'unplanned' hand-over whereby the MH > is now at the new CoA, remembers the old CoA and old HA, and so installs > forwarding. The draft does not however deal with planned hand-over (routed > at old HA as in cellular) which may be useful for the IP fast hand-over > work. In planned hand-over (see EMA draft), the 'system' knows where you are > going and can therefore install the temporary tunnel before you leave and > subsequently lose the link to the HA. Probably out of scope for this draft > (big divergence from model) but worth looking at the cellular equivalent > messaging for comparison. I don't think that this belongs in the current Mobile IPv6 draft. Furthermore, it is possible that cellular handovers will become more initiated by the mobile nodes as IPv6 gains wider deployment. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri May 12 11:44:18 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04720 for ; Fri, 12 May 2000 11:44:17 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5095E650@standards.nortelnetworks.com>; Fri, 12 May 2000 11:36:29 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 62455 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 12 May 2000 11:34:35 -0400 Received: from ztxmail04.ztx.compaq.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0AC39A00@standards.nortelnetworks.com>; Fri, 12 May 2000 11:34:32 -0400 Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345) id BF757679; Fri, 12 May 2000 10:41:37 -0500 (CDT) Received: from exctay-gh01.tay.cpqcorp.net (exctay-gh01.tay.cpqcorp.net [16.103.129.42]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 8560B46B for ; Fri, 12 May 2000 10:41:37 -0500 (CDT) Received: by exctay-gh01.tay.cpqcorp.net with Internet Mail Service (5.5.2650.21) id ; Fri, 12 May 2000 11:41:36 -0400 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, 12 May 2000 11:41:32 -0400 Reply-To: "Powell, Ken" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Powell, Ken" Subject: Re: [MOBILE-IP] Mobile IPv6 questions To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM I had a few additional thoughts on my previous questions. > should the conditions for sending a router advertisement to > a mobile node include some sort of unconditional periodic > retransmission? My concern is the home agent could define > a prefix with a fixed lifetime that the mobile node will treat > as decrementing in realtime. The prefix on the mobile node > could expire without any updates from the home agent. The > retransmission could occur on an hourly or even daily basis, > depending on the Preferred and Valid Lifetimes of the prefixes. Rather than having the home agent periodically retransmit the router advertisement, would it be better to say the mobile node SHOULD send a router solicit to the home agent when any of it's home addresses' preferred or valid lifetimes approach expiration? The router solicit could contain: Source: Mobile Node's primary care-of address Dest: Home Agent's address Destination Options w/ Home Address Option w/ Home Address: Mobile Node's Home Address Authentication header Router Solicitation The Home Agent could respond with a Router Advertisement as sent in section 9.7 with all address prefixes for the home network. However, there would be no Binding Request option needed with the Router Advertisement. The Binding Request/Update sequence described in section 9.7 is used as an acking mechanism to ensure the mobile node receives an unsolicited router advertisement. For solicited router advertisements, RFC 2461 section 6.3.7 says the mobile node may transmit the router solicitation up to MAX_RTR_SOLICITATIONS (3) times, each separated by at least RTR_SOLICITATION_INTERVAL (4) seconds. If no response occurs, the mobile node could perform home agent address discovery again. > If not, then should the home > agent send a router advertisement with all known home subnet > prefixes to the mobile node with the first Binding > Acknowledgement? This will account for prefixes the home > agent knows which the mobile node doesn't. > > => this is a nice idea. I noticed this was not added to the latest revision of the Mobile IPv6 spec. It would probably be cleaner to have the mobile node send a router solicitation with the first binding update it sends to a new home agent instead. This would would achieve the same result by triggering the home agent to send a router advertisement with all known prefixes. > > However, I think this I-D should be able to cover how > > to initialize its state on the home agent and the mobile node > > from a limited amount of information that is relatively easy > > to configure. For example, start with the assumption that the > > mobile node can always get the Home Agent's Anycast Address. > > > > => I agree this is useful but I think this is out of the > > scope of the I-D. I think a few restrictions on the process may be useful. Perhaps something like: The method for initializing a mobile node's home addresses on power-up or after an extended period of being disconnected from the network is beyond the scope of this specification. Whatever procedure is used, it SHOULD result in the mobile node having the same stateless or statefull (DHCPv6) home address autoconfiguration information it would have if it were attached to the home network. Due to the possibility that the home network could be renumbered while the mobile node is disconnected, the mobile node SHOULD NOT rely on storing these addresses locally. > I tried to understand how a Mobile IPv6 node would > initialize its addresses on power-up using stateless > address autoconfiguration when away from home. The > steps I came up with were: > > > > What information can I expect the mobile node have to > break this deadlock? Is my reading of how this should > work way off? Would it be reasonable for a mobile node to generate a temporary home address for itself using: o the subnet prefix from the home network's mobile agent anycast address, and o the globally unique interface identifier that would have been used to generate the link local address if the mobile node were attached directly to the home network. Such a temporary address could be used to establish a binding with a home agent in the absence of any other known home addresses. It could be created with short valid lifetime and a preferred lifetime of zero to ensure a quick transition to other addresses generated when stateless or statefull (DHCPv6) address autoconfiguration runs. If this were allowed, I can see how a mobile node could initialize by: 1) Query DNS for the home network's mobile agent anycast address. 2) Generate a temporary home address as defined above. 3) Send a Home Agent Address Discovery Request message to the home network. 4) Receive Home Agent Address Discovery Reply message. 5) Send a binding update option with a router solicit to a home agent using the temporary home address. 6) Receive a binding acknowledgement option with a router advertisement from the home agent. This router advertisement could indicate to use stateless and/or statefull address autoconfiguration. If statefull, start the DHCPv6 procedures. 7) Autoconfigure home addresses according to the prefix information options received. 8) Send binding update option(s) to establish bindings for the new home addresses (if needed). Ken Powell Compaq Computer Corporation From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri May 12 12:11:25 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05622 for ; Fri, 12 May 2000 12:11:25 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1F157CE0@standards.nortelnetworks.com>; Fri, 12 May 2000 12:03:44 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 62598 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 12 May 2000 12:03:16 -0400 Received: from eagle.aud.alcatel.com (128.251.96.217) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A83C7D40@standards.nortelnetworks.com>; Fri, 12 May 2000 11:53:15 -0400 Received: from usa.alcatel.com by eagle.aud.alcatel.com (8.8.8+Sun/SMI-SVR4) id KAA22590; Fri, 12 May 2000 10:59:39 -0500 (CDT) X-Mailer: Mozilla 4.72 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 References: <391C1E84.4B7064C3@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <391C2A01.6940B3EF@usa.alcatel.com> Date: Fri, 12 May 2000 10:57:53 -0500 Reply-To: Vincent Magret Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Vincent Magret Subject: [MOBILE-IP] IPv6 Mobility draft question To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello, I wasn't really following the discussion on mobile Ipv6, so some comments might have already been discussed. Anyway, here is one though and some comments My friday though I have a question on the mobile home address. Since IPv6 is designed to allow dynamic address allocation, this means the host are mainly going to use this feature, except may be in some corporate networks where they still want to implement the old behavior (i.e. static address). So why should a mobile node have a static address? It could be a useful feature to allow the mobile node to discover its home address (at least in my opinion) and this could be done using ICMP message similar to the one to discover the list of home agents. comments In section 10.9 Should we have a "bullet" stating that the mobile node MAY request the home agent on the previous link to send an acknowledgment? In section 10.10 The section describes the behavior of the mobile node when requesting an acknowledgment to its binding update message. What happens when the maximum number of message has been sent? Should the mobile node considers itself in the impossibility to have mobility support and thus should turn down its interface (or something like that)? Should the mobile node turn down its mobile IP component? Should the MN try the process again after a certain time? In section 10.13 It is stated that the mobile node MAY decide to not inform the correspondent of its current location and "the mobile node instead SHOULD returns a Binding Update to the sender, in which the Lifetime field is set to zero and the care-of address is set to the mobile node's home address". The packet will be sent using the care-of address and the home address destination option to allow the packet to go through ingress filtering router. Well with such message the correspondent (if its goal is to learn the current location of the mobile) can learn the current location by reading the source address of the binding update. I think the mobile node should not send any response to the sender, and that implies that the sender can only send a limited number of binding request messages. Should we limited the number of binding requests? Or is it limited to a single binding request? (section 8.6) Section 10.19 ID excerpt : "... when the mobile node detects that its home subnet prefix is again on-link. The mobile node SHOULD then send a Binding Update to its home agent..." Why don't we have a MUST? Best regards. Vincent Magret. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri May 12 12:31:25 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06436 for ; Fri, 12 May 2000 12:31:25 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.ED4D2A70@standards.nortelnetworks.com>; Fri, 12 May 2000 12:23:49 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 62685 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 12 May 2000 12:21:54 -0400 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A81374A0@standards.nortelnetworks.com>; Fri, 12 May 2000 12:21:53 -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 e4CGSqx31592; Fri, 12 May 2000 18:28:52 +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 SAA00688; Fri, 12 May 2000 18:28:51 +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 SAA72860; Fri, 12 May 2000 18:30:28 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-ID: <200005121630.SAA72860@givry.rennes.enst-bretagne.fr> Date: Fri, 12 May 2000 18:30:28 +0200 Reply-To: Francis.Dupont@ENST-BRETAGNE.FR Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: [MOBILE-IP] ID mobileip-ipv6-12.txt and Duplicated Address Detection X-cc: ipng@sunroof.eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM I don't like many things in draft-ietf-mobileip-ipv6-12.txt section 10.19: - DAD only for the home address when after it is for all addresses - a wrong duplicate case - the MUST for the unspecified address as source (incorrect because it is not always needed, ugly because the answer will be sent the the all-nodes multicast) - the MUST NOT for DAD when there are some cases DAD could be performed without harm (then it should be performed :-) - nothing about the case when the mobile returns at home during the DAD procedure performed by the home agent. First they are many cases: - the mobile asked for DAD or not in its (previous) home registration - the mobile set a zero or a not zero prefix length in its home registration - the mobile returns at home during the DAD procedure done by the home agent or after, ie a DAD collision is possible or not (*) - the mobile knows or doesn't know the link-layer address of the home agent. (*) the mobile node should know if a DAD collision is possible because the home agent sends the acknowledge after DAD: - Finally, if the Duplicate Address Detection (D) bit is set in the Binding Update, this home agent MUST perform Duplicate Address Detection [27] on the mobile node's home link for the home address in this binding (before returning the Binding Acknowledgement). Note this statement should be changed in order to perform DAD for all addresses if prefix length is not zero as it is described in the prefix length paragraph. --first point-- A summary about DAD procedure: DAD uses NS/NA, NSs are special (source is the unspecified address) and NAs are answers to special NSs (and a bit non-standard too because they are sent to the all-node multicast address). During DAD, special NSs are sent with: - the unspecified address as source - the solicited-node multicast address (of the checked address) as destination - checked address as target - no source link-layer extension On reception of NSs: - if the source is unicast (ie for standard NSs), the NS is discarded - if the source is unspecified (ie for special NSs) and the packet from another node, then there is a duplicate. On reception of NAs: - the checked address is a duplicate. After/without DAD, the only specific processing is for special NSs: a NA must be sent to the all-nodes multicast destination, in order to signal to the other node that the address is already used, with a link-layer address extension (because the destination is a multicast). Then in short DAD has two phases: - DAD itself (special NSs) == "perform DAD" - after DAD or without DAD (answer to special NSs) == "defend for DAD" If the mobile returns at home when the home agent is performing DAD on mobile addresses, then the mobile will answer to special NDs and home registration will fail. I believe it doesn't matter because the mobile has to send a home deregistration but this is another proof that the mobile must deregister before perform a DAD (see after the 4th point). --fifth point-- The proposed solution is to fake a DAD for the home agent address (this is *confusing*) and to get the link-layer address in the NA... ... If the mobile node does Neighbor Solicitation to learn the home agent's link-layer address, in this special case of the mobile node returning home, the mobile node MUST set the Source Address of this Neighbor Solicitation to the unspecified address. I think there are better solutions and they are necessary only with a non-zero prefix length (ie with a zero prefix length the link-local address can be used, checked by DAD, ..., without problems). --third point-- The following statement from ID 12 is wrong: In particular, a Neighbor Solicitation from the mobile node using its home address as the Source Address would be detected by the home agent as a duplicate address. because the DAD is using special NDs. In this case the home agent can log the event (as it should be done for the similar in ARP) but the problem is not a false duplicate. The home address (and others if prefix length is not zero) are proxied by the home agent then the home agent doesn't know how to reach them (in fact it believes they are at the end of an old tunnel or must be discarded) until the home agent processes the home deregistration. This problem occurs only when the mobile needs to do a NS/NA exchange in order to get the home agent link-layer address and hurts only with a non-zero prefix length (which makes all the mobile addresses unusable). --second point-- This statement is not accurate: In addition, when returning home and configuring its home address on its network interface on its home link, the mobile node MUST NOT perform Duplicate Address Detection on its own home address, in order to avoid confusion or conflict with its home agent's use of the same address. In fact, the mobile node may perform DAD but after home deregistration: - the mobile node sends a binding update for home deregistration - the home agent ceases to defend addresses for DAD and flush them from its neighbor cache/proxy server - the home agent does a NS/NA exchange with the mobile node in order to get its link-layer address from its home address - the home agent sends a binding acknowledge for home deregistration - then the mobile node may perform DAD. --fourth point-- Here is a proposal for a better (IMHO) solution for the 3rd point: the mobile recognizes the case (no known link-layer address of the home agent, non-zero prefix length), creates a temporary address with a local interface ID, performs DAD for it (mandatory!) and uses it only for the NS/NA exchange with the home agent. Regards Francis.Dupont@enst-bretagne.fr PS: two remarks: - the DAD procedure itself is short (DupAddrDetectTransmits(1) * RetransTimer(1000ms) ie *one* second for the default) - I don't know whether the zero or the non-zero prefix length is the common case. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri May 12 13:21:01 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07766 for ; Fri, 12 May 2000 13:21:01 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D236A3E0@standards.nortelnetworks.com>; Fri, 12 May 2000 13:13:10 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 62925 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 12 May 2000 13:11:14 -0400 Received: from gandalf.axion.bt.co.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8CE2D660@standards.nortelnetworks.com>; Fri, 12 May 2000 13:11:14 -0400 Received: from cbtlipnt02.btlabs.bt.co.uk by gandalf (local) with ESMTP; Fri, 12 May 2000 18:07:53 +0100 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2651.88) id ; Fri, 12 May 2000 18:07:53 +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: Fri, 12 May 2000 18:07:37 +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] IPv6 Mobility draft comments X-To: charliep@iprg.nokia.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Thanks Charlie, > -----Original Message----- > From: Charles E. Perkins [SMTP:charliep@iprg.nokia.com] > Sent: Saturday, May 13, 2000 12:39 AM > To: alan.w.oneill@BT.COM > Cc: Mobile IP Mailing List > Subject: Re: [MOBILE-IP] IPv6 Mobility draft comments > > > Hello Alan, > > > on page 20 it states that 'Since correspondent nodes cache > bindings, > > it is expected that > > correspondent nodes usually will route packets directly to the mobile > > node's care-of address, so that the home agent is rarely involved > > with packet transmission to the mobile node' > > This means the the correspondent nodes usually have valid bindings > for the mobile node, unless the mobile node wishes otherwise. > [AWO] Or the CN wishes otherwise. How big a concern do you think the case of the large server might be wrt IPSEC, binding processing and header manipulations ? > > This clearly gives the right for the CN to send to MN-HA whilst the MH > > assumes it won't, leading to repeated (but rate limited) sending of BU's > to > > CN. This seems overly loose to me, and the MH shouldn't be guessing like > > this. Would it not be better if the CN sent something like a BR to > trigger > > BU from MN ? > > With the interpretation above, the CN is not granted such rights. > Of course, we could not necessarily prevent the CN from abrogating > those rights anyway, but thems the breaks. I would much prefer to > allow the mobile node to send unsolicited Binding Updates as it > is in the current specification. > [AWO] Ok > > Given the discussion on the list wrt forwarding control, reverse > tunnelling > > etc this would also enable CN to indicate it's policy directly, whilst > > giving the MN some opportunity to override this policy based on it's > > configured policy (from Home operator etc). > > I didn't get the part about how CNs were involved with reverse > tunneling. > [AWO] There not, but people were discussing 'corporate' control over policy as to how the CN and MN forward using either bindings or HA encaps or reverse tunneling. I felt if this was going to be considered then the CN BR would at least enable the CN to express it's view directly. Probably a rat hole given the diverse views on the subject. > Furthermore, the mobile node should be able to execute whatever > protocols it wants to execute without getting explicit permission > from the Mobile IPv6 document. Reverse tunneling in IPv6 does > not have sufficient interaction with Mobile IPv6 to merit inclusion > in that document. If a node wishes to tunnel, I don't see that > Mobile IPv6 should cause it to ask permission from anyone. > [AWO] Understood. > > 2) I couldn't find any specific reference to reverse tunneling support, > or > > it's reasons for not being included (maybe should be mentioned for > > continuity reasons wrt MIP4). We may also given above need to re-install > > reverse tunneling support as I strongly agree with Fred's position on > > this... > > I hope it is obvious from the above that I do not think we need > this. And, especially, I do not think it has to be resolved before > we go to Proposed Standard. If you would like to submit another > Internet Draft detailing a reverse tunneling procedure, then that > could be considered as a separate matter. > [AWO] Ok. Just trying to establish continuity from MIP4 which does explicitly mention reverse tunneling but as you say, even there the detail is still a separate spec. > > On returning home whilst communicating, we may need to support > forwarding > > which I think that means that we need new text in 10.19, indicating that > > the BU-HA = Previous CoA and Bu-CoA=MN-HA...(Bizarre I know but is it ok > ?) > > I couldn't parse this. Does it mean that the mobile node should > tell the previous router that it has gone home? In that case, > I reckon that the previous router still has to tunnel the packet > back to the mobile node, presumably with the tunnel destination > set equal to the home address. > [AWO] Yes thats it. The present text does not cover the case of a mobile returning home and wanting temporary forwarding from the previous CoA to the home address. The text only covers forwarding from a previous CoA to the present CoA (ie not home). > > Also, in the case of rapid movement, policy or failed communication with > HA, > > the MN may still be receiving tunnelled packets when it changes CoA and > > therefore won't we end up with multiple encapsulations ? It works but > should > > it be prevented... > > What is wrong with multiple encapsulations? Are you suggesting that the > intermediate encapsulator should first decapsulate? This seems like > it would be a nightmare to specify correctly > [AWO] I guess I was worried about any potential for these multiple encaps to continue to build up. Certainly not suggesting decaps because it would be a nightmare as you say. > > Finally, the section does not mention how this forwarding state is > > recommended to be eliminated (time-out or explicit cancel by MN). The > latter > > would seem better with the lifetime as a fail safe ? > > I thought that the mobile node should typically make an explicit > determination to invalidate bindings at the appropriate correspondent > nodes. [AWO] Thats the sensible thing yes. > > 7) General: Hand-over modes > > > > The 10.9 Forwarding section deals with 'unplanned' hand-over whereby the > MH > > is now at the new CoA, remembers the old CoA and old HA, and so installs > > forwarding. The draft does not however deal with planned hand-over > (routed > > at old HA as in cellular) which may be useful for the IP fast hand-over > > work. In planned hand-over (see EMA draft), the 'system' knows where you > are > > going and can therefore install the temporary tunnel before you leave > and > > subsequently lose the link to the HA. Probably out of scope for this > draft > > (big divergence from model) but worth looking at the cellular equivalent > > messaging for comparison. > > I don't think that this belongs in the current Mobile IPv6 draft. > Furthermore, it is possible that cellular handovers will become > more initiated by the mobile nodes as IPv6 gains wider deployment. > [AWO] Agreed on both counts - but I'm not sure that the latter statement eliminates the speed benefits of forward hand-over rooted at the old node whether initiated by MH or node itself. Best to leave this for know as a new draft from us will probably cover this in more detail soonish ok. > Regards, > Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri May 12 14:31:36 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09346 for ; Fri, 12 May 2000 14:31:35 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A93EEC90@standards.nortelnetworks.com>; Fri, 12 May 2000 14:23:36 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 63236 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 12 May 2000 14:22:21 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7C47FFB0@standards.nortelnetworks.com>; Fri, 12 May 2000 14:22:21 -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 LAA20668; Fri, 12 May 2000 11:29:24 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id LAA24982; Fri, 12 May 2000 11:10:15 -0700 X-Virus-Scanned: Fri, 12 May 2000 11:10:15 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from (charliep.iprg.nokia.com [205.226.2.89]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma024609; Fri, 12 May 00 11:10:09 -0700 X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <391C4D7D.838D3AD@iprg.nokia.com> Date: Fri, 12 May 2000 11:29:17 -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 Mobility draft comments X-To: alan.w.oneill@bt.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello again Alan, >> This means the the correspondent nodes usually have valid bindings >> for the mobile node, unless the mobile node wishes otherwise. > [AWO] Or the CN wishes otherwise. How big a concern do you > think the case of the large server might be wrt IPSEC, > binding processing and header manipulations ? I think that IPsec is likely to get major hardware assist, and that the use of IPsec for other reasons will swamp out any performance consideration for the processing of the relatively infrequent Binding Updates that the server may receive from mobile nodes. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri May 12 15:25:25 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10633 for ; Fri, 12 May 2000 15:25:25 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3DD53CE0@standards.nortelnetworks.com>; Fri, 12 May 2000 15:17:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 63433 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 12 May 2000 15:16:51 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.19212E40@standards.nortelnetworks.com>; Fri, 12 May 2000 15:16:51 -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 MAA26374; Fri, 12 May 2000 12:23:50 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id MAA17414; Fri, 12 May 2000 12:04:32 -0700 X-Virus-Scanned: Fri, 12 May 2000 12:04:32 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from (charliep.iprg.nokia.com [205.226.2.89]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma017170; Fri, 12 May 00 12:04:25 -0700 X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <391C1E84.4B7064C3@iprg.nokia.com> <391C2A01.6940B3EF@usa.alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <391C5A3F.361549ED@iprg.nokia.com> Date: Fri, 12 May 2000 12:23:43 -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 Mobility draft question X-To: Vincent Magret To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Vincent, > I have a question on the mobile home address. Since IPv6 is designed to allow > dynamic address allocation, this means the host are mainly going to use this > feature, except may be in some corporate networks where they still want to > implement the old behavior (i.e. static address). So why should a mobile node have > a static address? It could be a useful feature to allow the mobile node to > discover its home address (at least in my opinion) and this could be done using > ICMP message similar to the one to discover the list of home agents. The IPv6 address allocation philosophy seems to me more accurately described as one of automatically allocated static addresses. In other words, a node will configure its address automatically, and keep it a while. An IPv6 node should have a static address because that is the most efficient way to establish end-to-end connectivity for applications. Renumbering events are considered to be pretty rare, certainly not happening every day unless some administrator is trying to prove a point or test out some software. > In section 10.10 > > The section describes the behavior of the mobile node when requesting an > acknowledgment to its binding update message. What happens when the maximum number > of message has been sent? Should the mobile node considers itself in the > impossibility to have mobility support and thus should turn down its interface (or > something like that)? Should the mobile node turn down its mobile IP component? > Should the MN try the process again after a certain time? Maybe it would be time to do a home agent discovery operation. I don't think the other questions are much different in spirit from the question about whether to restart TCP connections that don't work right the first time. > In section 10.13 > > It is stated that the mobile node MAY decide to not inform the correspondent of > its current location and "the mobile node instead SHOULD returns a Binding Update > to the sender, in which the Lifetime field is set to zero and the care-of address > is set to the mobile node's home address". The packet will be sent using the > care-of address and the home address destination option to allow the packet to go > through ingress filtering router. Well with such message the correspondent (if its > goal is to learn the current location of the mobile) can learn the current > location by reading the source address of the binding update. I think the mobile > node should not send any response to the sender, and that implies that the sender > can only send a limited number of binding request messages. You are right that the mobile node should not try to invalidate a previous binding when it decides that it wants to keep its current care-of address private. However, wouldn't that typically mean that the mobile node didn't send its previous care-of address either? Why would a mobile node want privacy in some domains, and not in others? The answer to this question might well imply a closer entanglement between physical location and IP addressability than heretofore has been considered germane to network-layer protocol design. If the mobile node has to use the Home Address option to satisfy ingress filtering, and also use reverse tunneling to shield its current location, then I guess the tunneling has to have the Home Address option in the outer encapsulating IP header in order for the operation to make sense. > ID excerpt : "... when the mobile node detects that its home subnet prefix is > again on-link. The mobile node SHOULD then send a Binding Update to its home > agent..." > > Why don't we have a MUST? That would be fine with me. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat May 13 00:55:22 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23508 for ; Sat, 13 May 2000 00:55:21 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B2D4C520@standards.nortelnetworks.com>; Sat, 13 May 2000 0:46:39 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 65394 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 13 May 2000 00:44:58 -0400 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.76E1A1F0@standards.nortelnetworks.com>; Sat, 13 May 2000 0:44:58 -0400 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA00898; Fri, 12 May 2000 21:52:02 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.83.130]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id VAA14046; Fri, 12 May 2000 21:52:03 -0700 (PDT) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.10.1+Sun/8.10.1) with SMTP id e4D4q1h656003; Fri, 12 May 2000 21:52:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Fri, 12 May 2000 21:43:38 -0700 Reply-To: Erik Nordmark Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Erik Nordmark Subject: Re: [MOBILE-IP] IPv6 Mobility draft comments X-To: alan.w.oneill@BT.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > This clearly gives the right for the CN to send to MN-HA whilst the MH > assumes it won't, leading to repeated (but rate limited) sending of BU's to > CN. This seems overly loose to me, and the MH shouldn't be guessing like > this. Would it not be better if the CN sent something like a BR to trigger > BU from MN ? The CN doesn't know whether its peer is mobile or not. So if you go the above path you are really saying that all IPv6 nodes should (periodically? retransmit with exponential backoff?) send BRs to all their communication peers. > Given the discussion on the list wrt forwarding control, reverse tunnelling > etc this would also enable CN to indicate it's policy directly, whilst > giving the MN some opportunity to override this policy based on it's > configured policy (from Home operator etc). The CN might not have a policy. Do you have an example of sensible CN policy? The organization which runs the HA might have a policy. And the owner of the MN might have a policy (not disclose the location of the MN by sending BUs or Home Address Options to CNs - or only to certain CNs). Erik From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat May 13 00:55:22 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23510 for ; Sat, 13 May 2000 00:55:22 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B7FD9220@standards.nortelnetworks.com>; Sat, 13 May 2000 0:46:47 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 65473 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 13 May 2000 00:45:34 -0400 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8BE45B10@standards.nortelnetworks.com>; Sat, 13 May 2000 0:45:33 -0400 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA00905; Fri, 12 May 2000 21:52:39 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.83.130]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id VAA14073; Fri, 12 May 2000 21:52:40 -0700 (PDT) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.10.1+Sun/8.10.1) with SMTP id e4D4qbh656239; Fri, 12 May 2000 21:52:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Fri, 12 May 2000 21:44:14 -0700 Reply-To: Erik Nordmark Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Erik Nordmark Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question X-To: "Casati, Alessio (Alessio)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Alessio said, > Erik said: > > Also, if the employees can't be trusted to this extent we can't solve > > that with technology - it is a social problem that requires social > > solutions. > > (Many companies make statements about the possible effects of violating > > company security policies like connecting an externally accessible modem > > to the desktop allowing people to break in etc) > > > > > This statement is kind of strange, and would really mean that > Mobile IPv6 has not the service capabilities Mobile IPv4 > has with reverse tunneling. Sorry, I was reacting to the general thread of discussion (where there was mention of using MIPv6 technology to enforce corporate policy) and not to specific suggestions you made. > Just add to the biding update ACK from the Home Agent a flag to turn off > sending > binding updates to CNs and forcing reverse tunneling, > and we have solved the problem. If we want to allow the HA to suggest policy to the MN it would make sense to add such support. But there might also be cases where it is the MN that is in control of the "location privacy policy" i.e. the MN will decide when and to whom it will send BU and send Home Address options vs. doing reverse tunneling. Erik From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat May 13 05:50:43 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07131 for ; Sat, 13 May 2000 05:50:42 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1EFDAFE0@standards.nortelnetworks.com>; Sat, 13 May 2000 5:43:10 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 66547 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 13 May 2000 05:41:26 -0400 Received: from auemail2.firewall.lucent.com (192.11.223.163) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E107B7D0@standards.nortelnetworks.com>; Sat, 13 May 2000 5:41:26 -0400 Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id FAA27363 for ; Sat, 13 May 2000 05:48:33 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id FAA27353 for ; Sat, 13 May 2000 05:48:32 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2448.0) id ; Sat, 13 May 2000 10:48:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Message-ID: <976F7C55E3B2D111A0720008C728549C04876C4C@en0060exch001u.uk.lucent.com> Date: Sat, 13 May 2000 10:48:31 +0100 Reply-To: "Casati, Alessio (Alessio)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Casati, Alessio (Alessio)" Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question X-To: Erik Nordmark To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > If we want to allow the HA to suggest policy to the MN it would make > sense to add such support. > But there might also be cases where it is the MN that is in control > of the "location privacy policy" i.e. the MN will decide when and to whom > it will send BU and send Home Address options vs. doing reverse tunneling. > > Agreed. I would also suggest that it should be clear in the spec that the HA policy cannot be overridden by the mobile node, as long as the address (logically) used by the mobile is the Home Address. alessio From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun May 14 11:58:05 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09103 for ; Sun, 14 May 2000 11:58:04 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.62505BB0@standards.nortelnetworks.com>; 14 May 2000 11:48:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 68688 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 14 May 2000 11:47:48 -0400 Received: from gandalf.axion.bt.co.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.39D69280@standards.nortelnetworks.com>; 14 May 2000 11:47:48 -0400 Received: from cbtlipnt02.btlabs.bt.co.uk by gandalf (local) with ESMTP; Sun, 14 May 2000 16:54:53 +0100 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2651.88) id ; Sun, 14 May 2000 16:54:51 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.88) Content-Type: text/plain Message-ID: Date: Sun, 14 May 2000 16:54:51 +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] IPv6 Mobility draft comments X-To: Erik.Nordmark@eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Thanks Eric > -----Original Message----- > From: Erik Nordmark [SMTP:Erik.Nordmark@eng.sun.com] > Sent: Saturday, May 13, 2000 2:14 PM > To: alan.w.oneill@BT.COM > Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] IPv6 Mobility draft comments > > > This clearly gives the right for the CN to send to MN-HA whilst the MH > > assumes it won't, leading to repeated (but rate limited) sending of BU's > to > > CN. This seems overly loose to me, and the MH shouldn't be guessing like > > this. Would it not be better if the CN sent something like a BR to > trigger > > BU from MN ? > > The CN doesn't know whether its peer is mobile or not. > So if you go the above path you are really saying that all IPv6 nodes > should (periodically? retransmit with exponential backoff?) send > BRs to all their communication peers. > [AWO] Hmm - bad idea... ? > > > Given the discussion on the list wrt forwarding control, reverse > tunnelling > > etc this would also enable CN to indicate it's policy directly, whilst > > giving the MN some opportunity to override this policy based on it's > > configured policy (from Home operator etc). > > The CN might not have a policy. > Do you have an example of sensible CN policy? > [AWO] Given the above probably not. Simply thinking that a CN may WANT to go via a HA (CN may also be a roamer away from the corporate net, or for CN processing load issues (although Charlie is pretty comfortable about the latter). For the former I could imagine that the CN may be able to access 'better' net services if it's packets are recognised (HA->MN outer header src addr) in the net as being from a particular corporate (access diff-serv aggregate, better bandwidth etc). How efficient do you think classification will be on the Routing header (and the HAb option for that matter) to match into corporate specific net resources for example ? > The organization which runs the HA might have a policy. > And the owner of the MN might have a policy (not disclose > the location of the MN by sending BUs or Home Address Options to > CNs - or only to certain CNs). > > Erik From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 15 01:14:00 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17936 for ; Mon, 15 May 2000 01:13:59 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BB575870@standards.nortelnetworks.com>; Mon, 15 May 2000 1:05:59 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 69406 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 15 May 2000 01:04:29 -0400 Received: from mailsrv1.dlink.com.tw by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1EBA60D0@standards.nortelnetworks.com>; Mon, 15 May 2000 0:54:27 -0400 Received: from dlink.com.tw (h2-210-68-85.dlink.com.tw [210.68.85.2] (may be forged)) by mailsrv1.dlink.com.tw (8.9.3/8.9.3) with SMTP id NAA17740 for ; Mon, 15 May 2000 13:20:14 +0800 Received: by dlink.com.tw(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 482568E0.001B8FCB ; Mon, 15 May 2000 13:01:02 +0800 X-Lotus-FromDomain: D-LINK Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <482568E0.001B8EC9.00@dlink.com.tw> Date: Mon, 15 May 2000 13:03:13 +0800 Reply-To: paul_chao@DLINK.COM.TW Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Shiang-wei Chao Subject: [MOBILE-IP] Maximum fequency of hand-offs in MIP To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello, When mobility of MNs is getting high, what is the maximum frequency of hand-offs that is allowed by MIP? What is the proper range of this frequency? Is there any document or simulation result refering to this ? Appreciate for your help Paul From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 15 04:20:50 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29491 for ; Mon, 15 May 2000 04:20:50 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D8375160@standards.nortelnetworks.com>; Mon, 15 May 2000 4:12:55 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 70136 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 15 May 2000 04:11:08 -0400 Received: from mailsrv1.dlink.com.tw by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.97F48320@standards.nortelnetworks.com>; Mon, 15 May 2000 4:11:07 -0400 Received: from dlink.com.tw (h2-210-68-85.dlink.com.tw [210.68.85.2] (may be forged)) by mailsrv1.dlink.com.tw (8.9.3/8.9.3) with SMTP id QAA22140 for ; Mon, 15 May 2000 16:37:07 +0800 Received: by dlink.com.tw(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 482568E0.002D934D ; Mon, 15 May 2000 16:17:48 +0800 X-Lotus-FromDomain: D-LINK Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <482568E0.002D91A6.00@dlink.com.tw> Date: Mon, 15 May 2000 16:19:58 +0800 Reply-To: paul_chao@DLINK.COM.TW Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Shiang-wei Chao Subject: Re: [MOBILE-IP] Maximum fequency of hand-offs in MIP To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Sorry for my incorrect statement. When mobility of MNs is getting high, how much is the maximum frequency of hand-offs that is allowed by MIP? How much is the proper range of this frequency? Is there any document or simulation result refering to this ? Appreciate for your help Paul From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 15 07:08:19 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00908 for ; Mon, 15 May 2000 07:08:18 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3D672120@standards.nortelnetworks.com>; Mon, 15 May 2000 7:00:23 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 70468 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 15 May 2000 06:58:34 -0400 Received: from prue.eim.surrey.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.970C4400@standards.nortelnetworks.com>; Mon, 15 May 2000 6:48:34 -0400 Received: from engomi.ee.surrey.ac.uk ([131.227.86.20] helo=ee.surrey.ac.uk ident=eep2cp) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 12rIXK-0001Sm-00 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 15 May 2000 11:55:46 +0100 X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en, el MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <391FD7B0.4D67341A@ee.surrey.ac.uk> Date: Mon, 15 May 2000 11:55:44 +0100 Reply-To: c.politis@EIM.SURREY.AC.UK Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Christos Politis Organization: Centre for Communication Systems Research, UniS Subject: [MOBILE-IP] A Question! To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi out there, I am a Ph.D. student at the University of Surrey at the UK, and i would like to ask sth relevant to my Ph.D.: I want to model a MAC layer for the HIPERLAN/2 or a more general one for WLANs, i would like to know which is the best simulation tool (easy to learn, friendly to the user, scaleability, e.t.c) to do that: a) the NS (network simulator) or b) the OPNET or c) Anything else that you can suggest. Thanks. Best Regards, Christos. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 15 10:30:00 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04660 for ; Mon, 15 May 2000 10:29:59 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.61A5EF00@standards.nortelnetworks.com>; Mon, 15 May 2000 10:21:49 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 70815 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 15 May 2000 10:20:30 -0400 Received: from angelo.kcl.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CAE97BA0@standards.nortelnetworks.com>; Mon, 15 May 2000 10:10:27 -0400 Received: from somewher9a5qdn (EE105.eee.kcl.ac.uk [137.73.11.105]) by angelo.kcl.ac.uk with SMTP id PAA12728 for ; Mon, 15 May 2000 15:17:37 +0100 (BST) References: <45AFD48D077ED211BB4700A0C9DCE8FD15AD68@monza.broadswitch.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004E_01BFBE80.F6727210" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Message-ID: <005101bfbe78$94e21260$690b4989@somewher9a5qdn> Date: Mon, 15 May 2000 15:19:28 +0100 Reply-To: Piyush Khengar Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Piyush Khengar Subject: [MOBILE-IP] unsubscribe To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_004E_01BFBE80.F6727210 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable unsubscribe ------=_NextPart_000_004E_01BFBE80.F6727210 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

unsubscribe

------=_NextPart_000_004E_01BFBE80.F6727210-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 15 10:38:05 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04831 for ; Mon, 15 May 2000 10:38:04 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.838A9480@standards.nortelnetworks.com>; Mon, 15 May 2000 10:29:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 70847 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 15 May 2000 10:29:35 -0400 Received: from mx1.ustc.edu.cn (202.102.223.33) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.08DFF370@standards.nortelnetworks.com>; Mon, 15 May 2000 10:19:20 -0400 Received: from ustc.edu.cn (hpe25.nic.ustc.edu.cn [202.38.64.1]) by mx1.ustc.edu.cn (8.8.7/8.8.6) with SMTP id WAA11741 for ; Mon, 15 May 2000 22:34:37 -0800 Received: from mail.ustc.edu.cn by ustc.edu.cn with SMTP (8.6.10/16.2) id WAA11300; Mon, 15 May 2000 22:21:40 +0800 Received: (qmail 2252 invoked by uid 3007); 15 May 2000 14:13:27 -0000 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Mon, 15 May 2000 22:13:27 +0800 Reply-To: Yu Dum Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Yu Dum Subject: [MOBILE-IP] Questions about the optim-draft To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello, everyone! I have just read the draft-ietf-mobileip-optim-09 and there are some questions puzzling me. Could you please kindly help me? in section 3.1, it says: 1.The home agent SHOULD then send a Binding Update message to the original source node, informing it of the mobile node's current mobility binding. No acknowledgment for such a Binding Update message is needed, since additional future datagrams from this source node intercepted by the home agent for the mobile node will cause transmission of another Binding Update. ? why shouldn't there be an acknowledgement, and it seems to conflict with the description of the Binding Update message which define the 'A' bit. 2.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. ? How can the 'any node' deduce whether its or the tunneling node has an out-of-date binding cache entry for this mobile node? Thanks for your answer! Regards, Yu -----*-----*-----*-----*-----*----* * *----*-----*-----*-----*-----*----- Miss Yu Du Tel: 86-551-3603400-219(lab) P.O. Box 4 3-167 86-551-3656437 (Dorm) Hefei,Anhui Department of Computer Science&Technology University of Science and Technology of China People's Republic of China 230027 -----------------------------------*****---------------------------------- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 15 11:14:03 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05441 for ; Mon, 15 May 2000 11:14:02 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.92656DE0@standards.nortelnetworks.com>; Mon, 15 May 2000 11:06:08 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 71055 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 15 May 2000 11:04:58 -0400 Received: from eagle.aud.alcatel.com (128.251.96.217) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.02C1B0A0@standards.nortelnetworks.com>; Mon, 15 May 2000 10:54:58 -0400 Received: from usa.alcatel.com by eagle.aud.alcatel.com (8.8.8+Sun/SMI-SVR4) id KAA14429; Mon, 15 May 2000 10:01:39 -0500 (CDT) X-Mailer: Mozilla 4.72 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 References: <391C1E84.4B7064C3@iprg.nokia.com> <391C2A01.6940B3EF@usa.alcatel.com> <391C5A3F.361549ED@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <392010EC.2E67C5B6@usa.alcatel.com> Date: Mon, 15 May 2000 09:59:57 -0500 Reply-To: Vincent Magret Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Vincent Magret Subject: Re: [MOBILE-IP] IPv6 Mobility draft question X-To: "Charles E. Perkins" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Charles, I don't want to create a controversial debate, but the concept of mobility on which the group is working allows the mobile node to node have a home address (RFC 2794, draft-ietf-mobileip-aaa-key-01.txt). And as you stated it a node acquires an address and keeps it for while, not indefinitely. So, why not having a similar feature for IPv6? Regards, Vincent. "Charles E. Perkins" wrote: > Hello Vincent, > > > I have a question on the mobile home address. Since IPv6 is designed to allow > > dynamic address allocation, this means the host are mainly going to use this > > feature, except may be in some corporate networks where they still want to > > implement the old behavior (i.e. static address). So why should a mobile node have > > a static address? It could be a useful feature to allow the mobile node to > > discover its home address (at least in my opinion) and this could be done using > > ICMP message similar to the one to discover the list of home agents. > > The IPv6 address allocation philosophy seems to me more accurately described > as one of automatically allocated static addresses. In other words, a node > will configure its address automatically, and keep it a while. > > An IPv6 node should have a static address because that is the most > efficient way to establish end-to-end connectivity for applications. > Renumbering events are considered to be pretty rare, certainly not > happening every day unless some administrator is trying to prove a > point or test out some software. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 15 12:32:12 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06821 for ; Mon, 15 May 2000 12:32:11 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7D493850@standards.nortelnetworks.com>; Mon, 15 May 2000 12:24:17 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 71185 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 15 May 2000 12:23:14 -0400 Received: from mailgw.ust.hk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EA2C0BC0@standards.nortelnetworks.com>; Mon, 15 May 2000 12:13:01 -0400 Received: from uxmail.ust.hk (root@uxmail.ust.hk [143.89.14.30]) by mailgw.ust.hk (8.9.3/8.9.3) with ESMTP id AAA21507; Tue, 16 May 2000 00:11:01 +0800 (HKT) Received: from dmy019 (dmy019.resnet.ust.hk [143.89.66.69]) by uxmail.ust.hk (8.9.3/8.9.3) with SMTP id AAA13017; Tue, 16 May 2000 00:20:00 +0800 (HKT) References: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: <000d01bfbe89$237db0a0$4542598f@resnet.ust.hk> Date: Tue, 16 May 2000 00:17:59 +0800 Reply-To: Zhao Jian Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Zhao Jian Subject: Re: [MOBILE-IP] Questions about the optim-draft X-To: Yu Dum To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id MAA06821 Hi, Here is my understanding: ----- Original Message ----- From: Yu Dum To: Sent: Monday, May 15, 2000 10:13 PM Subject: [MOBILE-IP] Questions about the optim-draft > Hello, everyone! > > I have just read the draft-ietf-mobileip-optim-09 and there are > some questions puzzling me. Could you please kindly help me? > > in section 3.1, it says: > > 1.The home agent SHOULD then send > a Binding Update message to the original source node, informing it > of the mobile node's current mobility binding. No acknowledgment > for such a Binding Update message is needed, since additional future > datagrams from this source node intercepted by the home agent for the > mobile node will cause transmission of another Binding Update. > > ? why shouldn't there be an acknowledgement, and it seems to conflict > with the description of the Binding Update message which define the 'A' > bit. The draft does not say "shouldn't", but says "it is not needed/necessary". It is better for the home agent to do the task. > > 2.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. > > ? How can the 'any node' deduce whether its or the tunneling node has > an out-of-date binding cache entry for this mobile node? when the mentioned mobile is not in FA's visitor list, this mobile, most likely, has handed-off to another nearby FA. > > Thanks for your answer! > > Regards, > > Yu > > -----*-----*-----*-----*-----*----* * *----*-----*-----*-----*-----*----- > Miss Yu Du Tel: 86-551-3603400-219(lab) > P.O. Box 4 3-167 86-551-3656437 (Dorm) > Hefei,Anhui > Department of Computer Science&Technology > University of Science and Technology of China > People's Republic of China 230027 > -----------------------------------*****---------------------------------- > Zhao Jian Department of Computer Science HKU of Science & Tech. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 15 21:51:20 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13828 for ; Mon, 15 May 2000 21:51:20 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9C9E5250@standards.nortelnetworks.com>; Mon, 15 May 2000 21:43:31 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 72881 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 15 May 2000 21:42:20 -0400 Received: from mx1.ustc.edu.cn (202.102.223.33) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6D728410@standards.nortelnetworks.com>; Mon, 15 May 2000 21:42:11 -0400 Received: from ustc.edu.cn (hpe25.nic.ustc.edu.cn [202.38.64.1]) by mx1.ustc.edu.cn (8.8.7/8.8.6) with SMTP id KAA26667 for ; Tue, 16 May 2000 10:07:03 -0800 Received: from mail.ustc.edu.cn by ustc.edu.cn with SMTP (8.6.10/16.2) id JAA19240; Tue, 16 May 2000 09:54:14 +0800 Received: (qmail 28502 invoked by uid 3007); 16 May 2000 01:45:59 -0000 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Tue, 16 May 2000 09:45:59 +0800 Reply-To: Yu Dum Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Yu Dum Subject: [MOBILE-IP] Improvement to single HA? To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello,all there, In the basic Mobile IP protocol, there exists only one HA. However, this is far from robust, for, when the HA is down, any MN depending on it will be unreachable. And I believe some improvement must be done to make it work on real scale. Is there some corresponding material or project? Thanks for your answer! Regards, Yu -----*-----*-----*-----*-----*----* * *----*-----*-----*-----*-----*----- Miss Yu Du Tel: 86-551-3603400-219(lab) P.O. Box 4 3-167 86-551-3656437 (Dorm) Hefei,Anhui Department of Computer Science&Technology University of Science and Technology of China People's Republic of China 230027 -----------------------------------*****---------------------------------- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 16 10:45:04 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06309 for ; Tue, 16 May 2000 10:45:03 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.ACAE2370@standards.nortelnetworks.com>; Tue, 16 May 2000 10:37:03 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 74001 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 16 May 2000 10:35:30 -0400 Received: from iti-idsc.gov.eg (163.121.12.2) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.72448670@standards.nortelnetworks.com>; Tue, 16 May 2000 10:35:25 -0400 Received: from iti-idsc.gov.eg (seg28.iti.idsc.gov.eg [163.121.28.7] (may be forged)) by iti-idsc.gov.eg (8.9.1b+Sun/8.9.1) with ESMTP id RAA02647 for ; Tue, 16 May 2000 17:43:42 +0300 (EET DST) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------C712F12BA7C394DC8D145314" Message-ID: <3736FE38.2E58335B@iti-idsc.gov.eg> Date: Mon, 10 May 1999 18:41:45 +0300 Reply-To: zozo Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: zozo Subject: [MOBILE-IP] [Fwd: Mobile Ad hoc] To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------C712F12BA7C394DC8D145314 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------C712F12BA7C394DC8D145314 Content-Type: message/rfc822 Content-Disposition: inline X-Mozilla-Status2: 00000000 Message-ID: <3736F3EB.9224F83D@iti-idsc.gov.eg> Date: Mon, 10 May 1999 17:57:47 +0300 From: zozo X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf@ietf.org Subject: Mobile Ad hoc Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit What are the benefits from "Integeration between Mobile IP and Ad hoc networks"? --------------C712F12BA7C394DC8D145314-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 16 20:20:57 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14495 for ; Tue, 16 May 2000 20:20:56 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2273EC70@standards.nortelnetworks.com>; Tue, 16 May 2000 20:13:00 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 75470 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 16 May 2000 20:11:26 -0400 Received: from slb-smtpout-01.boeing.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.84656370@standards.nortelnetworks.com>; Tue, 16 May 2000 20:01:26 -0400 Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id RAA24125 for ; Tue, 16 May 2000 17:08:43 -0700 (PDT) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id RAA27434 for ; Tue, 16 May 2000 17:08:42 -0700 (PDT) Received: from xch-pssbh-01.ca.boeing.com by slb-hub-01.boeing.com with ESMTP; Tue, 16 May 2000 17:08:39 -0700 Received: by xch-pssbh-01.ca.boeing.com with Internet Mail Service (5.5.2650.21) id ; Tue, 16 May 2000 17:08:37 -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: Tue, 16 May 2000 17:08:35 -0700 Reply-To: "Mohammad, Alimuddin" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Mohammad, Alimuddin" Subject: Re: [MOBILE-IP] Dynamic Address Assignment in Mobile IP X-To: Pete McCann To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM We were thinking of using DHCP with mobile IP and came across this thread. I don't see a problem for a MN to use DHCP to acquire an address directly. DHCP DISCOVER is a broadcast message and need not be reverse tunneled to the home network. All that is required is that the routers act as DHCP relay agents so that the DHCP DISCOVER message reaches the DHCP server. I would very much appreciate any discussion on this issue. Thanks. ---Alim -----Original Message----- From: Pete McCann [mailto:mccap@RESEARCH.BELL-LABS.COM] Sent: Tuesday, March 28, 2000 10:21 PM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] Dynamic Address Assignment in Mobile IP There is nothing in the draft that precludes the Home Agent from using DHCP to manage the address pool. However I think there is a problem if the MN tries to use DHCP directly to acquire an address. The problem is that the MN's DHCP DISCOVER message needs to be reverse-tunneled to the home network *before* the MN has even acquired an IP address, and the response needs to be properly encapsulated by the HA - essentially, the FA and HA are acting in concert as a BOOTP relay, which I am not sure is supported. Any comments from DHCP experts? From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 16 20:40:47 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14652 for ; Tue, 16 May 2000 20:40:46 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EFF653C0@standards.nortelnetworks.com>; Tue, 16 May 2000 20:33:04 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 75526 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 16 May 2000 20:31:15 -0400 Received: from catarina.usc.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.ADFA63D0@standards.nortelnetworks.com>; Tue, 16 May 2000 20:31:14 -0400 Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id RAA07268 for ; Tue, 16 May 2000 17:38:29 -0700 (PDT) Received: from localhost (meeta@localhost) by rumi.usc.edu (8.9.3/8.9.3) with ESMTP id RAA79516 for ; Tue, 16 May 2000 17:38:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Tue, 16 May 2000 17:38:56 -0700 Reply-To: Meeta Sharma Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Meeta Sharma Subject: [MOBILE-IP] some suggestions please To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: hi, We were working on verification and performance evaluation of Mobile IP . We have used the initial specifications for Mobile IP (rfc 2002), and according to that we have defined correctness as: 1. If mobile node has registration with home agent as i, then it should be in foreign agent i. 2. For every mobile node there should be a home agent this is the basic condition we have come up with. Can you give some feedback on this. But along with this, have some questions, 1. In NS what version of MobileIP has been implemented? 2. Is there any modification of Mobile IP which would have 'no packet' loss! that is there is inherent packet loss during handoff, so is there anyway to deal with it. Looking forward to your response, thanks Regards, Meeta From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 16 21:00:58 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14783 for ; Tue, 16 May 2000 21:00:57 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BDC04B60@standards.nortelnetworks.com>; Tue, 16 May 2000 20:53:09 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 75583 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 16 May 2000 20:52:06 -0400 Received: from catarina.usc.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.97A1D750@standards.nortelnetworks.com>; Tue, 16 May 2000 20:52:05 -0400 Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id RAA07348 for ; Tue, 16 May 2000 17:59:17 -0700 (PDT) Received: from localhost (meeta@localhost) by rumi.usc.edu (8.9.3/8.9.3) with ESMTP id RAA79650 for ; Tue, 16 May 2000 17:59:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Tue, 16 May 2000 17:59:44 -0700 Reply-To: Meeta Sharma Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Meeta Sharma Subject: [MOBILE-IP] mobile IP scripts To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: hi all, I wanted to run some simulations for Mobile IP.Are there any scripts which have been implemented in ns-version 6 for mobile IP? Thanks, Regards, Meeta From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed May 17 02:54:25 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00543 for ; Wed, 17 May 2000 02:54:24 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.12811C20@standards.nortelnetworks.com>; Wed, 17 May 2000 2:46:16 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 76435 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 17 May 2000 02:44:57 -0400 Received: from mgw-x1.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E3100780@standards.nortelnetworks.com>; Wed, 17 May 2000 2:44:56 -0400 Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60]) by mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id JAA16690 for ; Wed, 17 May 2000 09:52:14 +0300 (EETDST) Received: from esebh03nok.ntc.nokia.com (esebh03nok.ntc.nokia.com [131.228.118.244]) by mgw-i1.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id JAA00334 for ; Wed, 17 May 2000 09:52:13 +0300 (EETDST) Received: by esebh03nok with Internet Mail Service (5.5.2650.10) id ; Wed, 17 May 2000 09:52:12 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 17 May 2000 09:52:09 +0300 Reply-To: patrik.flykt@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrik Flykt Subject: Re: [MOBILE-IP] IPv6 Mobility Last Call Question To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello all, > > But there might also be cases where it is the MN that is in control > > of the "location privacy policy" i.e. the MN will decide > when and to whom > > it will send BU and send Home Address options vs. doing > reverse tunneling. IMHO, this is exactly what we should do. The MN should remain in charge of its binding updates. All the time. > Agreed. I would also suggest that it should be clear in > the spec that the HA policy cannot be overridden > by the mobile node, as long as the address (logically) > used by the mobile is the Home Address. I have a slight problem with the HA dictating the policy. If the HA is to be capable of knowing which policy is the best one for which CoA, the HA must "learn" the whole network and its topology. There are situations where the MN can decide that a subset of the nodes can be trusted with (network) location information. An example of the trusted nodes would be those in my home network and at work, while the untrusted ones would basically be the rest. If the MN would receive an incoming SIP connection request, the MN should send a binding update to the requesting node in order to minimize delay for the connection. An all or nothing rule imposed by the HA would not be adequate in this case. There is a wide grey area between always reverse tunnel and always send binding updates where the tradeoff is between location privacy and minimized delay. Regards, Patrik From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed May 17 08:28:51 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03945 for ; Wed, 17 May 2000 08:28:51 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CBA829E0@standards.nortelnetworks.com>; Wed, 17 May 2000 8:20:44 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 76791 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 17 May 2000 08:19:07 -0400 Received: from relay.kfupm.edu.sa by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2B9915F0@standards.nortelnetworks.com>; Wed, 17 May 2000 8:09:05 -0400 Received: from relayin.kfupm.edu.sa (relayin.kfupm.edu.sa [212.26.2.26]) by relay.kfupm.edu.sa (8.9.2/8.9.2) with ESMTP id PAA172096; Wed, 17 May 2000 15:13:23 +0300 Received: from iws20.dpc.kfupm.edu.sa (iws20.dpc.kfupm.edu.sa [196.15.32.20]) by relayin.kfupm.edu.sa (8.9.2/8.9.2) with ESMTP id PAA41762; Wed, 17 May 2000 15:13:23 +0300 Received: from itcH70.itc.kfupm.edu.sa (itc.itc.kfupm.edu.sa [196.15.32.8]) by iws20.dpc.kfupm.edu.sa (8.9.2/8.9.2) with ESMTP id PAA16738; Wed, 17 May 2000 15:10:01 +0400 Received: from localhost (s954269@localhost) by itcH70.itc.kfupm.edu.sa (8.9.2/8.9.2) with ESMTP id PAA51986; Wed, 17 May 2000 15:13:14 +0300 X-Sender: s954269@itcH70.itc.kfupm.edu.sa MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Wed, 17 May 2000 15:13:13 +0300 Reply-To: "Hosam K. Rowaihy" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hosam K. Rowaihy" Subject: [MOBILE-IP] [Mobile IP]: How can I unsubscribe??Mobile IP] X-To: Patrik Flykt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Please help me. I would like to unsubscribe from this list but I am not able to do so. Regards, Hosam K .Rowaihy From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed May 17 10:16:18 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05414 for ; Wed, 17 May 2000 10:16:18 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C7CB18F0@standards.nortelnetworks.com>; Wed, 17 May 2000 10:08:00 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 76997 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 17 May 2000 10:07:47 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C03B0FF0@standards.nortelnetworks.com>; Wed, 17 May 2000 10:07:47 -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 IAA20129; Wed, 17 May 2000 08:15:05 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA00632; Wed, 17 May 2000 07:14:59 -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 HAA24991; Wed, 17 May 2000 07:14:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Wed, 17 May 2000 07:14:51 -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] Dynamic Address Assignment in Mobile IP X-To: "Mohammad, Alimuddin" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" Although it seems like it *could* work, I am not sure how we could support tunnelled DHCP when supporting private address clients. PatC ---- > We were thinking of using DHCP with mobile IP and came across this thread. > I don't see a problem for a MN to use DHCP to acquire an address directly. > DHCP DISCOVER is a broadcast message and need not be reverse tunneled to the > home network. All that is required is that the routers act as DHCP relay > agents so that the DHCP DISCOVER message reaches the DHCP server. > > I would very much appreciate any discussion on this issue. > > Thanks. > > ---Alim > > -----Original Message----- > From: Pete McCann [mailto:mccap@RESEARCH.BELL-LABS.COM] > Sent: Tuesday, March 28, 2000 10:21 PM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Dynamic Address Assignment in Mobile IP > > > > There is nothing in the draft that precludes the Home Agent from using > DHCP to manage the address pool. However I think there is a problem > if the MN tries to use DHCP directly to acquire an address. The problem > is that the MN's DHCP DISCOVER message needs to be reverse-tunneled > to the home network *before* the MN has even acquired an IP address, > and the response needs to be properly encapsulated by the HA - essentially, > the FA and HA are acting in concert as a BOOTP relay, which I am not > sure is supported. Any comments from DHCP experts? From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed May 17 10:58:09 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05699 for ; Wed, 17 May 2000 10:58:09 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AAD4CB50@standards.nortelnetworks.com>; Wed, 17 May 2000 10:50:08 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 77107 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 17 May 2000 10:48:44 -0400 Received: from dirty.research.bell-labs.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7868ED40@standards.nortelnetworks.com>; Wed, 17 May 2000 10:48:43 -0400 Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Wed May 17 10:55:37 EDT 2000 Received: from king.research.bell-labs.com ([135.1.152.1]) by grubby; Wed May 17 10:55:36 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 3766657042 for ; Wed, 17 May 2000 09:55:36 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: X-Mailer: VM 6.33 under Emacs 19.34.2 Message-ID: <20000517145536.3766657042@king.research.bell-labs.com> Date: Wed, 17 May 2000 09:55:36 -0500 Reply-To: Pete McCann Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Pete McCann Subject: Re: [MOBILE-IP] Dynamic Address Assignment in Mobile IP To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Content-Transfer-Encoding: 7bit I agree with Pat. It is possible to tunnel DHCP over Mobile IP back to the home network, but you need to have been assigned an address *first*, during Mobile IP registration, by the HA using the NAI extension. Once you've done that getting a new address seems unnecessary, but you could still use DHCPINFORM to get other parameters from the home network. If you don't assign the address in the first phase (using Mobile IP+NAI) then you have to deal with a 0.0.0.0 address for the mobile during tunneled DHCP operation. This gets really complicated and requires FA and HA to look at the internals of the DHCP message in order to route it properly (they are essentially acting like DHCP relays). I don't think this is the right way to go. -Pete "pcalhoun@eng.sun.com" (psc) writes: psc> Although it seems like it *could* work, I am not sure how we could support psc> tunnelled DHCP when supporting private address clients. psc> PatC psc> ---- >> We were thinking of using DHCP with mobile IP and came across this thread. >> I don't see a problem for a MN to use DHCP to acquire an address directly. >> DHCP DISCOVER is a broadcast message and need not be reverse tunneled to the >> home network. All that is required is that the routers act as DHCP relay >> agents so that the DHCP DISCOVER message reaches the DHCP server. >> >> I would very much appreciate any discussion on this issue. >> >> Thanks. >> >> ---Alim >> >> -----Original Message----- >> From: Pete McCann [mailto:mccap@RESEARCH.BELL-LABS.COM] >> Sent: Tuesday, March 28, 2000 10:21 PM >> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM >> Subject: Re: [MOBILE-IP] Dynamic Address Assignment in Mobile IP >> >> >> >> There is nothing in the draft that precludes the Home Agent from using >> DHCP to manage the address pool. However I think there is a problem >> if the MN tries to use DHCP directly to acquire an address. The problem >> is that the MN's DHCP DISCOVER message needs to be reverse-tunneled >> to the home network *before* the MN has even acquired an IP address, >> and the response needs to be properly encapsulated by the HA - essentially, >> the FA and HA are acting in concert as a BOOTP relay, which I am not >> sure is supported. Any comments from DHCP experts? From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed May 17 12:42:25 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08385 for ; Wed, 17 May 2000 12:42:24 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.402FEE10@standards.nortelnetworks.com>; Wed, 17 May 2000 12:34:31 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 77375 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 17 May 2000 12:33:14 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.ABCE81B0@standards.nortelnetworks.com>; Wed, 17 May 2000 12:23:13 -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 KAA26354 for ; Wed, 17 May 2000 10:30:30 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA25917 for ; Wed, 17 May 2000 09:30:26 -0700 (PDT) Received: from sunray-mpke (sunray-mpke [129.146.6.32]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id JAA27730; Wed, 17 May 2000 09:30:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: n0LIU5jigl1w/ORj/x+grw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Message-ID: <200005171630.JAA27730@nasnfs.eng.sun.com> Date: Wed, 17 May 2000 09:30:25 -0700 Reply-To: Vipul Gupta Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Vipul Gupta Subject: Re: [MOBILE-IP] Dynamic Address Assignment in Mobile IP To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Alim, You may also be interested in the DRCP work at Telecordia (formerly Bellcore) and Toshiba: http://search.ietf.org/internet-drafts/draft-itsumo-drcp-00.txt This draft "proposes an enhanced version of DHCP for roaming users" vipul > > We were thinking of using DHCP with mobile IP and came across this thread. > > I don't see a problem for a MN to use DHCP to acquire an address directly. > > DHCP DISCOVER is a broadcast message and need not be reverse tunneled to the > > home network. All that is required is that the routers act as DHCP relay > > agents so that the DHCP DISCOVER message reaches the DHCP server. > > > > I would very much appreciate any discussion on this issue. > > > > Thanks. > > > > ---Alim > > > > -----Original Message----- > > From: Pete McCann [mailto:mccap@RESEARCH.BELL-LABS.COM] > > Sent: Tuesday, March 28, 2000 10:21 PM > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: [MOBILE-IP] Dynamic Address Assignment in Mobile IP > > > > > > > > There is nothing in the draft that precludes the Home Agent from using > > DHCP to manage the address pool. However I think there is a problem > > if the MN tries to use DHCP directly to acquire an address. The problem > > is that the MN's DHCP DISCOVER message needs to be reverse-tunneled > > to the home network *before* the MN has even acquired an IP address, > > and the response needs to be properly encapsulated by the HA - essentially, > > the FA and HA are acting in concert as a BOOTP relay, which I am not > > sure is supported. Any comments from DHCP experts? From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed May 17 23:15:24 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15410 for ; Wed, 17 May 2000 23:15:24 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A78EE950@standards.nortelnetworks.com>; Wed, 17 May 2000 23:07:21 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 78755 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 17 May 2000 23:05:33 -0400 Received: from paul-milea-jr (4.4.213.112) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.00482590@standards.nortelnetworks.com>; Wed, 17 May 2000 22:55:30 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 17 May 2000 23:05:33 -0400 Reply-To: "Paul J. Milea jr." Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Paul J. Milea jr." Subject: [MOBILE-IP] Fiber Optic cable available ! To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM If this email has reached you by error please forgive the intrusion. Type "remove" in the subject line and hit send and I will promptlty remove you from any future mailings .Please accept my sincerest apology.I am sorry if I have inconvenienced you in any way. Dear Sir(s),Ms.,Mrs., I have available quantities of Fitel/Lucent, Chromatic and Superior Fiber Optic Cable.This is all brand new IN STOCK and ready for immediate delivery ! ALL PRICES ARE CENTS PER FOOT,IN U.S. FUNDS. ENTIRE QUANTITY MUST BE PURCHASED TO OBTAIN THESE PRICES. CUT PRICES PLEASE ADD 20 %. THERE MAY BE DISCOUNT AVAILABLE ON LARGER PURCHASES. These types and amounts available ; FITEL/LUCENT 1.) 24 strand (12 single mode & 12 non-zero dispersion) P/N CMAE-12/12-34 3,416,162 ft available @ $.69 2.) 24 strand (12 single mode & 12 non zero dispersion) P/N CLCB-12/12-34 4,687,400 ft available @ $.69 3.) 48 strand single mode ,P/N FO-112-072, 340,000 ft available @ $1.59 CHROMATIC 1.) 12 strand single mode ,P/N CABD740L612010X 18,728 ft available @ $.91 2.) 24 strand single mode ,P/N CABD740L624010X 29,010 ft. available @ $1.23 3.) 48 strand single mode ,P/N CABD74OL1248010X 48,433 ft available @$1.99 4.)96 strand single mode ,P/N CABD74011296010X 87,400 ft available @ $3.25 SUPERIOR 1.)12 strand(5 posit.) sngl. jacket,P/N 110129200 170,000 ft available @$.78 2.)24 strand(5 posit.) sngl. jacket,P/N 110249200 170,000 ft available @$.97 3.)48 strand(5 posit.) sngl.jacket,P/N 110489100 180,000 ft. available @$1.64 4.)96 strand(5 posit.) sngl.jacket,P/N 110969100 100,000 ft available @ 2.74 Everthing is FOB Georgia except Fitel/Lucent items #1 and #2 which are FOB Toronto . Please email for questions or cut pricing . Also please feel free to call with any questions. Regards,Paul J. Milea jr. ph 315 374 1560, fax 315 463 4337 Thank you again for your time ! From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 18 00:35:25 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16286 for ; Thu, 18 May 2000 00:35:25 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D8404520@standards.nortelnetworks.com>; Thu, 18 May 2000 0:27:27 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 78824 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 18 May 2000 00:26:03 -0400 Received: from smtp10.atl.mindspring.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.405738A0@standards.nortelnetworks.com>; Thu, 18 May 2000 0:16:02 -0400 Received: from uf4xc (user-33qsd2k.dialup.mindspring.com [199.174.52.84]) by smtp10.atl.mindspring.net (8.9.3/8.8.5) with SMTP id AAA03855; Thu, 18 May 2000 00:23:23 -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 CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Message-ID: <001701bfc081$c30bae20$020aa8c0@uf4xc> Date: Wed, 17 May 2000 23:30:13 -0500 Reply-To: Basavaraj Patil Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: Re: [MOBILE-IP] Dynamic Address Assignment in Mobile IP X-cc: Alimuddin.Mohammad@PSS.BOEING.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit >We were thinking of using DHCP with mobile IP and came across this thread. >I don't see a problem for a MN to use DHCP to acquire an address directly. >DHCP DISCOVER is a broadcast message and need not be reverse tunneled to the >home network. All that is required is that the routers act as DHCP >relay agents so that the DHCP DISCOVER message reaches the DHCP server. > >I would very much appreciate any discussion on this issue. > >Thanks. > >---Alim Alim, If it is a colocated COA that the MN wants when in a foreign network, then you could use DHCP and the DISCOVER message would get to some local DHCP server. This would work. However the discussion in the thread below was the scenario where a MN does not have a permanently assigned IP address by it's home network and needs to get one at registration. If your question was on the same lines as the thread below then there is definitely an issue. -Basavaraj > >-----Original Message----- >From: Pete McCann [mailto:mccap@RESEARCH.BELL-LABS.COM] >Sent: Tuesday, March 28, 2000 10:21 PM >To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM >Subject: Re: [MOBILE-IP] Dynamic Address Assignment in Mobile IP > > > >There is nothing in the draft that precludes the Home Agent from using >DHCP to manage the address pool. However I think there is a problem >if the MN tries to use DHCP directly to acquire an address. The problem >is that the MN's DHCP DISCOVER message needs to be reverse-tunneled >to the home network *before* the MN has even acquired an IP address, >and the response needs to be properly encapsulated by the HA - essentially, >the FA and HA are acting in concert as a BOOTP relay, which I am not >sure is supported. Any comments from DHCP experts? > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 18 00:42:22 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16400 for ; Thu, 18 May 2000 00:42:22 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D4A12FF0@standards.nortelnetworks.com>; Thu, 18 May 2000 0:34:30 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 78827 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 18 May 2000 00:33:21 -0400 Received: from paul-milea-jr (4.48.171.95) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.452AC440@standards.nortelnetworks.com>; Thu, 18 May 2000 0:23:20 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Thu, 18 May 2000 00:33:21 -0400 Reply-To: "Paul J. Milea jr." Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Paul J. Milea jr." Subject: [MOBILE-IP] WANTED .....Large quantity of Cellular Telephones ! To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM If this email has reached you by error please forgive the intrusion. Type "remove" in the subject line and hit send and I will promptlty remove you from any future mailings .Please accept my sincerest apology.I am sorry if I have inconvenienced you in any way. Dear Sir(s),Ms.,Mrs., I have a client looking for 20,000 Motorola V3688 European GSM 900 MHZ Cellular Telephones.Preferably "titanium" in color but will accept some black and blue .If I can come up with the right price I can be assured of another order for 30,000 pieces in the next 90 days .We will contract to buy this amount . They must not be locked,white box,in English ,retail box,one battery and charger. *** ALSO These are needed immediatly ! Brand & Model Number Quantities Needed Siemans Model # C25 Euro GSM 5,000 Siemans Model # S25 Euro GSM 5,000 Nokia Model # 7110 GSM 5,000 Nokia Model # 6150 GSM 5,000 Nokia Model # 8210 5,000 Please contact me immediateley if you can provide these or similar or know of any one who can .If you are able to provide please send best price on this quantity,FOB point,type of packaging,what is included (type charger,type battery,etc.),send email or fax 315 463 4337 in the USA. Also I am interested in any TDMA or other types ,as below,of cellular phones in quantity ,with prices you may have . Thank You,Paul J. Milea Jr. 1 (315) 374-1560 fax 1 (315) 463-4337 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 18 00:45:19 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16419 for ; Thu, 18 May 2000 00:45:19 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1C4B97A0@standards.nortelnetworks.com>; Thu, 18 May 2000 0:36:30 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 78828 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 18 May 2000 00:34:36 -0400 Received: from smtp10.atl.mindspring.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.727C2D30@standards.nortelnetworks.com>; Thu, 18 May 2000 0:24:36 -0400 Received: from uf4xc (user-33qsd2k.dialup.mindspring.com [199.174.52.84]) by smtp10.atl.mindspring.net (8.9.3/8.8.5) with SMTP id AAA27581; Thu, 18 May 2000 00:31:56 -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 CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Message-ID: <001801bfc082$f4eb3540$020aa8c0@uf4xc> Date: Wed, 17 May 2000 23:38:44 -0500 Reply-To: Basavaraj Patil Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: Re: [MOBILE-IP] Maximum fequency of hand-offs in MIP X-cc: paul_chao@DLINK.COM.TW To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit >Sorry for my incorrect statement. > > > When mobility of MNs is getting high, how much is the maximum >frequency of hand-offs that is allowed by MIP? How much is the >proper range of this frequency? >Is there any document or simulation result refering to this ? > >Appreciate for your help > >Paul The frequency of handoffs depends on cell size, the MNs speed , the MN itself, among other factors. The Mobile IP spec does not specify any limits for the number of handoffs. -Basavaraj From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 18 05:37:41 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01626 for ; Thu, 18 May 2000 05:37:41 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EE86AFC0@standards.nortelnetworks.com>; Thu, 18 May 2000 5:28:43 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 79761 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 18 May 2000 05:27:33 -0400 Received: from albatross.wise.edt.ericsson.se (193.180.251.36) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5F3642A0@standards.nortelnetworks.com>; Thu, 18 May 2000 5:17:33 -0400 Received: from penguin.wise.edt.ericsson.se (penguin.wise.edt.ericsson.se [153.88.253.23]) by albatross.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.9) with ESMTP id e4I9CPH05027 for ; Thu, 18 May 2000 11:12:26 +0200 (MET DST) Received: from lt.eth.ericsson.se (lt.eth.ericsson.se [164.48.158.205]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.9) with ESMTP id e4I9LIq13281; Thu, 18 May 2000 11:21:18 +0200 (MET DST) Received: from eth.ericsson.se by lt.eth.ericsson.se (8.8.8+Sun/SMI-SVR4) id LAA17479; Thu, 18 May 2000 11:21:11 +0200 (MET DST) X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: <3919D09F.9E4A1C55@iprg.nokia.com> <391AC01D.66DF@inrialpes.fr> <391ACBF5.4B27523E@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3923B607.D29B32DC@eth.ericsson.se> Date: Thu, 18 May 2000 11:21:11 +0200 Reply-To: Zoltan.Turanyi@ETH.ERICSSON.SE Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Zoltan Richard Turanyi Subject: Re: [MOBILE-IP] Regional Registration Questions X-To: charliep@IPRG.NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi Charlie, > > Then it acquires the public key of the mobile host from a trusted > > party, encrypts the PID and sends it to the mobile host. This way > > the mobile host and the Cellular IP network have a shared secret. > > The PID remains the same during handoff and can be easily computed by > > each Base Station. > > This is also workable, but I don't think we should restrict > our solution to public key mechanisms only. I think it is > just as likely that the AAA infrastructure will be used to > distribute symmetric keys. You are definitely right. The wording of the draft suggest the exclusive use of public key mechanisms although it is not the only way to go. Let me clarify something here. We can divide key exchange events into two groups (at least with Cellular IP or micro-mobility in general). The first one is the initial key exchange between the mobile host and the access (e.g., Celluar IP) network. Global (e.g., Mobile IP) authentication may also happen during this phase if needed. We can say this is similar to the process when we log in to an operating system. The initial authentication (login) may take some time, but it needs to be performed rarely as once connected, the user is expected to spend some time in an access network. The second event type happens when a mobile host already attached to an access network changes base station. This is similar to the case when we are already logged in to an operating system and wish to launch a new job. Authentication in this case should be really fast. The Cellular IP draft does not wish to specify the first, "login" type of key exchange. (This will be influenced/solved by the global mobility protocol. Alternatively existing ideas/protocols for dial-in authentication and key exchange could be re-used in this context.) The security discussion in the Cellular IP draft addresses the second problem area, that is, how to establish a security association between mobile hosts and the new base station after an intra-Cellular IP handoff. For this purpose the draft describes a keying mechanism that allows the establishment of a SA without the base station contacting anyone apart from the mobile host. This mechanism rely on an initial key exchange performed by whatever global AAA protocol available. > > The PID can be used to authenticate (and optionally to encrypt) IP > > packets over the air interface. Authentication is performed by > > creating a short hash from the (PID, timestamp, packet content) > > triple that is placed into the transmitted packets. The validity of > > each packet can be easily checked by any Base Station even > > immediately after a handoff and without prior communication with the > > mobile host or with the old Base Station." > > This is also fine with me, but it has to be recognized that the > security needs for privacy over the air can be considered as > distinct from the security needs for authenticating binding > updates and registration messages. Again, sorry for the wording. The draft does not wish to promote an obligatory tie between signalling authentication and data privacy. It just states that an exisiting security association between mobile hosts and base stations can be used for both. However, if one wish to have separate SA for the two, I guess it is easy to solve, although personally I do not see why it would be necessary. Best Regards Zoltan -- Zoltan Richard Turanyi Research Fellow, Ericsson Hungary Traffic Analysis and Network Performance Lab From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 18 12:05:07 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09664 for ; Thu, 18 May 2000 12:05:07 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.258F8600@standards.nortelnetworks.com>; Thu, 18 May 2000 11:56:48 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 80475 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 18 May 2000 11:56:18 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AE16C3F0@standards.nortelnetworks.com>; Thu, 18 May 2000 11:46:18 -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 JAA19771 for ; Thu, 18 May 2000 09:53:06 -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 LAA06012 for ; Thu, 18 May 2000 11:51:31 -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 LAA26253 for ; Thu, 18 May 2000 11:51:46 -0400 (EDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Thu, 18 May 2000 11:51:26 -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] Dynamic Address Assignment in Mobile IP To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" All, I've just finished a rev-00 draft on this, actually, and I'm having some DHCP experts here look it over. The trick is the NAI, and no one needs to be a DHCP "relay" (!). I'll be posting it in the very near future (tomorrow?). Cheers, Steve > We were thinking of using DHCP with mobile IP and came across this thread. > I don't see a problem for a MN to use DHCP to acquire an address directly. > DHCP DISCOVER is a broadcast message and need not be reverse tunneled to the > home network. All that is required is that the routers act as DHCP relay > agents so that the DHCP DISCOVER message reaches the DHCP server. > > I would very much appreciate any discussion on this issue. > > Thanks. > > ---Alim > > -----Original Message----- > From: Pete McCann [mailto:mccap@RESEARCH.BELL-LABS.COM] > Sent: Tuesday, March 28, 2000 10:21 PM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Dynamic Address Assignment in Mobile IP > > > > There is nothing in the draft that precludes the Home Agent from using > DHCP to manage the address pool. However I think there is a problem > if the MN tries to use DHCP directly to acquire an address. The problem > is that the MN's DHCP DISCOVER message needs to be reverse-tunneled > to the home network *before* the MN has even acquired an IP address, > and the response needs to be properly encapsulated by the HA - essentially, > the FA and HA are acting in concert as a BOOTP relay, which I am not > sure is supported. Any comments from DHCP experts? From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 18 19:59:18 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14768 for ; Thu, 18 May 2000 19:59:18 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.704EA1C0@standards.nortelnetworks.com>; Thu, 18 May 2000 19:51:20 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 81684 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 18 May 2000 19:49:39 -0400 Received: from stl-smtpout-01.boeing.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.33F9D690@standards.nortelnetworks.com>; Thu, 18 May 2000 19:49:39 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id SAA26235 for ; Thu, 18 May 2000 18:57:02 -0500 (CDT) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id SAA16458 for ; Thu, 18 May 2000 18:57:01 -0500 (CDT) Received: from xch-pssbh-03.ca.boeing.com by stl-hub-01.boeing.com with ESMTP; Thu, 18 May 2000 18:56:48 -0500 Received: by xch-pssbh-03.ca.boeing.com with Internet Mail Service (5.5.2650.21) id ; Thu, 18 May 2000 16:56:47 -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: Thu, 18 May 2000 16:56:47 -0700 Reply-To: "Mohammad, Alimuddin" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Mohammad, Alimuddin" Subject: Re: [MOBILE-IP] Dynamic Address Assignment in Mobile IP X-To: "chaos@mindspring.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM A DHCP server can be forced to assign the same IP address to a client by using DHCP reservations. Using DHCP reservations has no basic functional difference from statically assigning a client an IP address. However, using DHCP reservations allows an admin. to have a central point of reference for all IP allocations in the organization i.e., a complete list of active reservations is available in one location. ---Alim -----Original Message----- From: David Frascone [mailto:chaos@mindspring.com] Sent: Tuesday, May 16, 2000 7:44 PM To: Mohammad, Alimuddin Subject: Re: [MOBILE-IP] Dynamic Address Assignment in Mobile IP Assuming the mobile node is in the foreign state, how would the DHCP server listening on the foreign network be able to allocate an address on the mobile node's home network? That's why most agree that DHCP could be used for address pool management for the HA, but would not really be usable by the MN. On Tue, May 16, 2000 at 05:08:35PM -0700, Mohammad, Alimuddin wrote: > We were thinking of using DHCP with mobile IP and came across this thread. > I don't see a problem for a MN to use DHCP to acquire an address directly. > DHCP DISCOVER is a broadcast message and need not be reverse tunneled to the > home network. All that is required is that the routers act as DHCP relay agents > so that the DHCP DISCOVER message reaches the DHCP server. > > I would very much appreciate any discussion on this issue. > > Thanks. > > ---Alim > > -----Original Message----- > From: Pete McCann [mailto:mccap@RESEARCH.BELL-LABS.COM] > Sent: Tuesday, March 28, 2000 10:21 PM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Dynamic Address Assignment in Mobile IP > > > > There is nothing in the draft that precludes the Home Agent from using > DHCP to manage the address pool. However I think there is a problem > if the MN tries to use DHCP directly to acquire an address. The problem > is that the MN's DHCP DISCOVER message needs to be reverse-tunneled > to the home network *before* the MN has even acquired an IP address, > and the response needs to be properly encapsulated by the HA - essentially, > the FA and HA are acting in concert as a BOOTP relay, which I am not > sure is supported. Any comments from DHCP experts? From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 18 21:54:51 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16404 for ; Thu, 18 May 2000 21:54:51 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8CE47DE0@standards.nortelnetworks.com>; Thu, 18 May 2000 21:46:40 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 81951 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 18 May 2000 21:45:02 -0400 Received: from webmail2.hansolm.com (210.112.10.141) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.ECBD7520@standards.nortelnetworks.com>; Thu, 18 May 2000 21:35:02 -0400 Received: from ns ([210.112.7.7]) by webmail2.hansolm.com with Microsoft SMTPSVC(5.5.1877.197.19); Fri, 19 May 2000 10:37:29 +0900 References: <001801bfc082$f4eb3540$020aa8c0@uf4xc> MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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: <009501bfc133$86a64640$5c12060a@hansol.co.kr> Date: Fri, 19 May 2000 10:42:40 +0900 Reply-To: Jiwoong Lee Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Jiwoong Lee Subject: Re: [MOBILE-IP] Maximum fequency of hand-offs in MIP X-To: Basavaraj Patil X-cc: cellular@diameter.org To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id VAA16404 I think the "handoff of MN in Mobile IP" does not depenp on the cell size. It depend on the size of coverage managed by a PDSN(FA). This PDSN can be attached to the MSC, RNC, or somewhere else. But I don't think it has to be attached to the BTS. It is just too much waste of network resource; Between BTSs, it's very easy to support handoffs, on the data link layer. In 2G cell, it is reported that the max value of handoff time (to switch the primary BTS) is about 3 seconds for 100Km-moving user. (Of course it can happen even faster.) The time to be added in the neighbor list can be a few millisecs. Generally the RNC/PDSN or MSC/PDSN coverage is bigger than the 'cell', it is reasonable to set the period of Agent Advertisement Message as 1 second. which is proposed in RFC2002. (Not RFC2002bis) All the truth is finally up to the network operators. They have to optimize the proper parameters for networks. My guess. It's my opinion. If any specific comments or different opinions, I'll appreciate it. Thank you. Jiwoong Lee Since the real form of a cell is not isotropic, the handoff can be occurred where cannot be predicted or calculated easily. Moreover, the cell form changes from time to time, due to the other noise source. Therefore the frequencey spectrum of handoff is spreaded from 0 to large number. In 2G network, we have to concern two time values. a. Time to add a neighbor ( In practice, the handoff frequency is deeply related to the frequency of Agent Advertisement message. ----- Original Message ----- ----- Original Message ----- From: Basavaraj Patil To: Sent: Thursday, May 18, 2000 1:38 PM Subject: Re: [MOBILE-IP] Maximum fequency of hand-offs in MIP > >Sorry for my incorrect statement. > > > > > > When mobility of MNs is getting high, how much is the maximum > >frequency of hand-offs that is allowed by MIP? How much is the > >proper range of this frequency? > >Is there any document or simulation result refering to this ? > > > >Appreciate for your help > > > >Paul > > The frequency of handoffs depends on cell size, the MNs speed , the MN > itself, among other factors. > The Mobile IP spec does not specify any limits for the number of > handoffs. > > -Basavaraj > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri May 19 01:04:22 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19150 for ; Fri, 19 May 2000 01:04:22 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.075FEF40@standards.nortelnetworks.com>; Fri, 19 May 2000 0:56:13 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 82360 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 19 May 2000 00:54:58 -0400 Received: from mailsrv1.dlink.com.tw by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DA134140@standards.nortelnetworks.com>; Fri, 19 May 2000 0:54:57 -0400 Received: from dlink.com.tw (h2-210-68-85.dlink.com.tw [210.68.85.2] (may be forged)) by mailsrv1.dlink.com.tw (8.9.3/8.9.3) with SMTP id NAA30491 for ; Fri, 19 May 2000 13:20:58 +0800 Received: by dlink.com.tw(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 482568E4.001BA648 ; Fri, 19 May 2000 13:02:00 +0800 X-Lotus-FromDomain: D-LINK Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <482568E4.001BA4C7.00@dlink.com.tw> Date: Fri, 19 May 2000 12:59:29 +0800 Reply-To: paul_chao@DLINK.COM.TW Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Shiang-wei Chao Subject: Re: [MOBILE-IP] Maximum fequency of hand-offs in MIP To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi Basavaraj , >> When mobility of MNs is getting high, how much is the maximum >>frequency of hand-offs that is allowed by MIP? How much is the >>proper range of this frequency? >>Is there any document or simulation result refering to this ? >The frequency of handoffs depends on cell size, the MNs speed , the MN >itself, among other factors. >The Mobile IP spec does not specify any limits for the number of >handoffs. > >-Basavaraj i agree with you. The frequency of handoffs depends on advertising interval of FAs, power range of FA, MN mobility ... ,etc. Maybe i should make myself clear. Is there minimum registration interval in HA ? i mean, if two registration messages arrive HA in very close time, will there be a time constraint to accpet the later one? Or this registration frequency (registration message per sec) has no limitation in spec and only relies on the computing power/bandwidth of HA? Thank you in advance Paul From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri May 19 05:16:12 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01972 for ; Fri, 19 May 2000 05:16:12 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2B396770@standards.nortelnetworks.com>; Fri, 19 May 2000 5:07:45 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 82773 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 19 May 2000 05:06:17 -0400 Received: from sonne.darmstadt.gmd.de by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F650F0A0@standards.nortelnetworks.com>; Fri, 19 May 2000 5:06:16 -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 LAA19447; Fri, 19 May 2000 11:13:35 +0200 (MET DST) X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: de,en,it MIME-Version: 1.0 References: <482568E4.001BA4C7.00@dlink.com.tw> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39250575.296E5E8D@darmstadt.gmd.de> Date: Fri, 19 May 2000 11:12:21 +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] Maximum fequency of hand-offs in MIP To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit In addition to previous answers, let me mention that RFC2002bis specifies - the maximal frequency by which a mobile node issues registration requests (in 2.4.2, p. 20): "However, the mobile node MUST NOT register more frequently than once per second on average,..." (in 3.6, p. 33): "In the absence of link-layer indications, a mobile node MUST NOT attempt to register more often than once per second." This sets an upper limit to the handoff frequency. - the frequency by which a foreign agent forwards requests (in 3.7.2):"...except in cases where the foreign agent would be required to send out more than one such denial per second to the same mobile node." This means that the foreign agent reacts accordingly, but does not impose any limits by itself. - no frequency by which the home agent processes requests However, if the requests do not suffer from too much jitter, you may expect that the frequency of requests handled by the home agent is at most once per second "on average". Clearly, there is no minimal frequency. Like everything in the Internet, requests are handled in a best-effort way. Wolfgang Shiang-wei Chao wrote: > > Hi Basavaraj , > > >> When mobility of MNs is getting high, how much is the maximum > >>frequency of hand-offs that is allowed by MIP? How much is the > >>proper range of this frequency? > >>Is there any document or simulation result refering to this ? > > >The frequency of handoffs depends on cell size, the MNs speed , the MN > >itself, among other factors. > >The Mobile IP spec does not specify any limits for the number of > >handoffs. > > > >-Basavaraj > > i agree with you. The frequency of handoffs depends on advertising interval of > FAs, power range of > FA, MN mobility ... ,etc. > > Maybe i should make myself clear. Is there minimum registration interval in HA > ? i mean, if two registration messages > arrive HA in very close time, will there be a time constraint to accpet the > later one? Or this registration frequency > (registration message per sec) has no limitation in spec and only relies on the > computing power/bandwidth of HA? > > Thank you in advance > > Paul -- Wolfgang Schoenfeld, GMD-IPSI, +49-6151-869-865 (Phone), +49-170-2285450 (Mobile) From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri May 19 20:00:29 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11979 for ; Fri, 19 May 2000 20:00:29 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C4C01DF0@standards.nortelnetworks.com>; Fri, 19 May 2000 19:52:31 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 85521 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 19 May 2000 19:50:41 -0400 Received: from ndmail1.name-server.de (212.63.147.253) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1D878B00@standards.nortelnetworks.com>; Fri, 19 May 2000 19:40:41 -0400 Received: from host (1Cust251.tnt2.providence.ri.da.uu.net [63.21.182.251]) by ndmail1.name-server.de (2.5 Build 2639 (Berkeley 8.8.6)/8.8.4) with ESMTP id BAA00553; Sat, 20 May 2000 01:39:46 +0200 X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <200005192339.BAA00553@ndmail1.name-server.de> Date: Fri, 19 May 2000 18:49:40 -0500 Reply-To: Karl Serny Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Karl Serny Subject: [MOBILE-IP] You Can Win... X-To: all87h@ndmail1.name-server.de To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA11979 Are you interested in increasing your odds in winning a lottery? To find out how, reply to: mailto:aamk@crosswinds.net?subject=How_to_win We will only respond if all of the information below is completed. Thanks for your time. Name: _________________________________________ Email Address: __________________________________ Address __________________________________________ City ________________________ ST _____ ZIP __________ Phone (_______) ______________________Best time to call. ***************************************************************** This message is sent in compliance of the new email bill section 301. PerSection 301, Paragraph (a)(2)(C) of S. 1618, further transmissions to you by the sender of this email may be stopped at no cost to you. This message is not intended for residents in the State of WA, CA & VA Screening of addresses has been done to the best of our technical ability. If you are a Washington, Virginia, or California resident please remove yourself. ================================================================= If you wish to be removed from future mailings, please Reply to:mailto:yykpm@usa.net?subject=remove From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat May 20 01:12:16 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16704 for ; Sat, 20 May 2000 01:12:15 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4DEA8040@standards.nortelnetworks.com>; Sat, 20 May 2000 1:04:09 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 86002 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 20 May 2000 01:03:08 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.297DDAE0@standards.nortelnetworks.com>; Sat, 20 May 2000 1:03: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 WAA15946; Fri, 19 May 2000 22:10:35 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id WAA17769; Fri, 19 May 2000 22:10:33 -0700 X-Virus-Scanned: Fri, 19 May 2000 22:10:33 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from (charliep.iprg.nokia.com [205.226.2.89]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma017624; Fri, 19 May 00 22:10:27 -0700 X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39261E45.B0E89AC5@iprg.nokia.com> Date: Fri, 19 May 2000 22:10:29 -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] More thoughts on Regional Registrations X-To: "pcalhoun@eng.sun.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Pat, Here are some more answers. > 2. new MN-GFA Extension > > The Internet drafts introduces a new authentication extension, which is the > MN-GFA. First, I have concerns with this one primarily because (to me) the > whole idea behind the Regional draft is to try to hide alot of the internals > of the network, but this new authentication extension forces the Mobile Node > to KNOW that a GFA is being used. Certainly, the draft does state that the > local FA doesn't have to advertise it's care-of address, and could include > only the GFA, but HOW would the MN know that it should use the MN-GFA as > opposed to the MN-FA? Furthermore, what occurs with RFC2002 mobile nodes? Annika, Eva, and I have come to the conclusion, each time that we discuss this matter, that the mobile node has to know that it is doing a regional registration. And, the leaf FA has to know. The details about why are grungy and would take too long to type in just now, but I can try it if you aren't happy with the mere statement of it. RFC 2002 mobile nodes do home registrations, not regional registrations. > This extension does allow a mobile to share a secret with both the local FA > and the GFA, but I question how often this would EVER be used. It really is > too complex, IMHO. On the other hand, we don't want to mandate a restrictive security model in the regional registration draft. Everything we have specified will work with diverse or uniform key distribution in the collection of regional foreign agents. If you want to manually distribute the same key to every FA and every GFA, fine. If you want to do IPsec++ with trimordial block vigilantism algorithms, then that is also fine with us. We just want to specify what the control flow for the registration traffic should be. That can be considered separately from how the security associations are managed. We also expect that a good security draft will discuss AAA mechanisms. We don't want to discuss AAA in the regional registration draft. > 3. Hierarchical FA extension > > I question the use of this extension. Certainly all socket (and variant) > implementations that I know of allow an application to know the source of the > packet. If this wasn't the case, how would the FA know the source port? In my heart of hearts, I resonate with this philosophy. Unfortunately, every time I try to follow it, the working group repudiates it. The feeling seems to be that most programmers can't handle the extra bit of programming. Examples where I have tried and failed to follow this philosophy include Mobile IP, SLP, and DHCP drafts. If you can manage the sociological process of transferring requirements off the wire and onto the CPU (and the mind of the lowest common denominator of the programming breed), then I wish you the best of luck. Be sure to work it out with one or two IESG members before unleashing it onto the working group. Furthermore, it apparently matters not in the least that extra bits over the air are bad for wireless, at least not in the mindset of the current IETF leadership. > The problem here is that this extension breaks network address translation. > The draft states that this extension contains the IP address of the Foreign > Agent, and this COULD be an address that eventually gets translated. In my > case, I have to write an ALG that handles this specific extension. Is there > anyway that we could simply require that the GFA know that IP address of the > sender through an API mechanism? Can't ALGs be made infinitely smart with unbounded state? Isn't this good for the industry? I don't understand the interaction of GFA with API, and besides I didn't think that we did APIs here. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat May 20 10:21:58 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29647 for ; Sat, 20 May 2000 10:21:58 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1A0604F0@standards.nortelnetworks.com>; Sat, 20 May 2000 10:13:53 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 86498 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 20 May 2000 10:12:20 -0400 Received: from 255.255.255.255 (61.10.17.95) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.78960170@standards.nortelnetworks.com>; Sat, 20 May 2000 10:02:13 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <419.436616.92192627promotiontech@hongkong.com> Date: Sat, 20 May 2000 10:12:20 -0400 Reply-To: "PROMOTION TECH INDUSTRIAL CO." Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "PROMOTION TECH INDUSTRIAL CO." Subject: [MOBILE-IP] ¦UÃþ¥Û­^Áx, ¥Û­^¦Ì¥JÁx, ¥Û­^¤Ó¶§ºÞ, ¿OÁx, ¤uµ{ To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit °¥ ¼í ¦æ PROMOTION TECH INDUSTRIAL CO. Rm 21, 9/F, New City Centre, 2 Lei Yue Mun Road, Kwun Tong,Kln., Hong Kong Tel : (852) 2709-9298 Fax : (852) 2243-3798 ±z¦n: ·|§_·P¨ì¦bµó¤WÁʶRªº¥Û­^Áx©Î¥ú·½²£«~¤Ó¶Q¤S¤£­@¥Î, ¦Ó¥B¨S¦³¥ô¦ó«Oµý. ¥»¤½¥q±MÀç¦U°ê¥Û­^Áx, ¥Û­^¦Ì¥JÁx, ¥Û­^¤Ó¶§ºÞ, ¿OÁx, ¸_¤lºÞ, ¸ô­y¿O, ¤Ñªá ¿O, ¤uµ{¿O, ±í¿O, ¹q¤l¤õ¤û, ¶Ç²Î¤õ¤û...................µ¥µ¥!!! µ´¹ï¾A¦X¦U¦æ¦U·~, ¦p®É¸Ë©±, ºë«~©±, °s¼Ó, ¤uµ{¤½¥q, ¸Ë¹¢¤Î«Ç¤º³]­p¤½¥q©Ò ±Ä¥Î. ¦Ó¥»¤½¥q§óºaÀò¥»´ä¦h¶¡°s¼Ó, ®É¸Ë³sÂꩱ, ¤uµ{¤½¥q«ü©w¤§¥ú·½²£«~¨ÑÀ³°Ó. ¥»¤½¥q¨M©w¤@³s¥|¶g±À¥X¯S»ù³f«~¥H¹SÁ«ÈÅU : 1, ´¶³q¤Ï¥úªM 12V 50W ¥Û­^Áx...........................................$ 8.00 2, ­¸§Q»Z ( PHILIPS ) 12V 50W ¥Û­^Áx..................................$18.00 3, ­¸§Q®ú ( PHILIPS ) 12V 50W ¥Û­^Áx (¥[¬Á¼þ­±)................$28.00 4, ¬_¤hªL ( OSRAM ) 12V 50W ¥Û­^Áx..................................$18.00 5, ¬_¤hªL ( OSRAM ) 12V 50W ¥Û­^Áx ( ¥[¬Á¼þ­±)...............$28.00 6, ¦U´Ú¸ô­y¿O.......................................................................$28.00 ( ¬Y¨Ç«¬¸¹°£¥~) 7, ¦U´Ú¸ô­y¿O + ´¶³q¤Ï¥úªM 12V 50W ¥Û­^Áx....................$35.00 ( ¬Y¨Ç«¬¸¹°£¥~) 8, 78mm ¥Û­^¤Ó¶§ºÞ 100W ¦Ü 250W......................................$15.00 9, 118mm ¥Û­^¤Ó¶§ºÞ 100W ¦Ü 500W...................................$15.00 10, PL-C 13W ¸_¤lºÞ ( ¥Õ¥ú 6400K, ¶À¥ú 2700K )....................$25.00 11, 6" 2*13W ¾î´¡±í¿O³s 13W ¸_¤lºÞ.....................................$110.00 ¦Ó¥»¤½¥q§ó»ô³Æ¦UºØ±M·~ªº¥ú·½²£«~, ¥Ñ©ó½s´T¦³­­, ¸Ô±¡½Ð­P¹q : 2709-9298 §õ¥ý¥Í ¤ZÁʶR¥Û­^Áxº¡ 20 ­Ó, §¡¥iÀò±o§K¶O°e³fªA°È. ¦p·Qª¾¹D§ó¦h, Åwªï­P¹q¬d¸ß, ¥»¤½¥q·|¬£¥X±M·~¤H­û¨ì¶Q¤½¥q´£¨Ñ·N¨£. ¦p¦¹«Ê¹q¶l©Î¶Ç¯u¹ï¶Q¥q³y¦¨¤£«K, ½Ð¥ß§Y¦^Âйq¶l­P¥»¤½¥q : promotiontech@hongkong.com ¥H«K²×¤î¶Ç°e, ÁÂÁÂ! ¯¬¶Q¤½¥q·~°È»]»]¤é¤W. ÁÂÁÂ! From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun May 21 02:35:06 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17605 for ; Sun, 21 May 2000 02:35:06 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.018D7D30@standards.nortelnetworks.com>; 21 May 2000 2:26:44 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 87203 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 21 May 2000 02:25:14 -0400 Received: from webmail2.hansolm.com (210.112.10.141) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.660529E0@standards.nortelnetworks.com>; 21 May 2000 2:15:14 -0400 Received: from ns ([210.112.7.7]) by webmail2.hansolm.com with Microsoft SMTPSVC(5.5.1877.197.19); Sun, 21 May 2000 15:18:05 +0900 References: <482568E4.001BA4C7.00@dlink.com.tw> <39250575.296E5E8D@darmstadt.gmd.de> MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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: <00c701bfc2ed$114167c0$5c12060a@hansol.co.kr> Date: Sun, 21 May 2000 15:23:23 +0900 Reply-To: Jiwoong Lee Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Jiwoong Lee Subject: Re: [MOBILE-IP] Maximum fequency of hand-offs in MIP To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id CAA17605 Thank Schoenfeld for the concise comments. RFC2002bis: in 3.6 pp.33, > "In the absence of link-layer indications, a mobile node > MUST NOT attempt to register more often than once per second." This sentence seems to imply that MN's switching to the new base station MAY trigger MN's new registration, with, if any, link-layer indication. How about the Mobile IP test implementations ? Are they supporting the triggering by a link-layer indication? Jiwoong Lee ----- Original Message ----- From: Wolfgang Schoenfeld To: Sent: Friday, May 19, 2000 6:12 PM Subject: Re: [MOBILE-IP] Maximum fequency of hand-offs in MIP > In addition to previous answers, > let me mention that RFC2002bis specifies > > - the maximal frequency by which a mobile node issues registration requests > > (in 2.4.2, p. 20): > "However, the mobile node MUST NOT register > more frequently than once per second on average,..." > (in 3.6, p. 33): > "In the absence of link-layer indications, a mobile node > MUST NOT attempt to register more often than once per second." > This sets an upper limit to the handoff frequency. > > - the frequency by which a foreign agent forwards requests > > (in 3.7.2):"...except in cases where the foreign agent would be > required to send out more than one such denial per second to the same > mobile node." > This means that the foreign agent reacts accordingly, > but does not impose any limits by itself. > > - no frequency by which the home agent processes requests > > However, if the requests do not suffer from too much jitter, > you may expect that the frequency of requests > handled by the home agent is at most once per second "on average". > > Clearly, there is no minimal frequency. > Like everything in the Internet, > requests are handled in a best-effort way. > > Wolfgang > > Shiang-wei Chao wrote: > > > > Hi Basavaraj , > > > > >> When mobility of MNs is getting high, how much is the maximum > > >>frequency of hand-offs that is allowed by MIP? How much is the > > >>proper range of this frequency? > > >>Is there any document or simulation result refering to this ? > > > > >The frequency of handoffs depends on cell size, the MNs speed , the MN > > >itself, among other factors. > > >The Mobile IP spec does not specify any limits for the number of > > >handoffs. > > > > > >-Basavaraj > > > > i agree with you. The frequency of handoffs depends on advertising interval of > > FAs, power range of > > FA, MN mobility ... ,etc. > > > > Maybe i should make myself clear. Is there minimum registration interval in HA > > ? i mean, if two registration messages > > arrive HA in very close time, will there be a time constraint to accpet the > > later one? Or this registration frequency > > (registration message per sec) has no limitation in spec and only relies on the > > computing power/bandwidth of HA? > > > > Thank you in advance > > > > Paul > > > -- > Wolfgang Schoenfeld, GMD-IPSI, > +49-6151-869-865 (Phone), +49-170-2285450 (Mobile) > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun May 21 08:38:55 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07357 for ; Sun, 21 May 2000 08:38:55 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E1B2DAE0@standards.nortelnetworks.com>; 21 May 2000 8:30:55 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 87349 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 21 May 2000 08:29:46 -0400 Received: from iti-idsc.gov.eg (163.121.12.2) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B3D25150@standards.nortelnetworks.com>; 21 May 2000 8:29:38 -0400 Received: from localhost (habanoub@localhost) by iti-idsc.gov.eg (8.9.1b+Sun/8.9.1) with ESMTP id PAA02835 for ; Sun, 21 May 2000 15:38:07 +0300 (EET DST) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Sun, 21 May 2000 15:38:07 +0300 Reply-To: SSDP143 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: SSDP143 Subject: [MOBILE-IP] implementation To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM we are a group of students , and we want to implement MOBILE IP software on linux machines, we wonder if the cor4rectaction is to start modifying the ip layer of the tcp/ip stack, to include mobility support, or we do it in the application layer? we use Red Hat Linux 6.1 thanks for your help Hany From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun May 21 10:30:20 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08178 for ; Sun, 21 May 2000 10:30:20 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6774CE90@standards.nortelnetworks.com>; 21 May 2000 10:22:02 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 87440 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 21 May 2000 10:20:33 -0400 Received: from iti-idsc.gov.eg (163.121.12.2) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2E9972B0@standards.nortelnetworks.com>; 21 May 2000 10:20:26 -0400 Received: from iti-idsc.gov.eg (seg28.iti.idsc.gov.eg [163.121.28.7] (may be forged)) by iti-idsc.gov.eg (8.9.1b+Sun/8.9.1) with ESMTP id RAA03949 for ; Sun, 21 May 2000 17:28:29 +0300 (EET DST) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------C0E2105F13A919AF4A398DD4" Message-ID: <373D9210.81C31AE@iti-idsc.gov.eg> Date: Sat, 15 May 1999 18:26:09 +0300 Reply-To: zozo Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: zozo Subject: [MOBILE-IP] Implementation of Mobile IP To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --------------C0E2105F13A919AF4A398DD4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit we are a group of students , and we want to implement MOBILE IP software on linux machines, we wonder if the cor4rectaction is to start modifying the ip layer of the tcp/ip stack, to include mobility support, or we do it in the application layer? we use Red Hat Linux 6.1 thanks for your help azza --------------C0E2105F13A919AF4A398DD4 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit we are a group of students , and we want to implement MOBILE IP software
on linux machines, we wonder if the cor4rectaction is to start modifying
the ip layer of the tcp/ip stack, to include mobility support, or we do it
in the application layer? we use Red Hat Linux 6.1

thanks for your help
azza --------------C0E2105F13A919AF4A398DD4-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 22 01:24:04 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17402 for ; Mon, 22 May 2000 01:24:03 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.42C37740@standards.nortelnetworks.com>; Mon, 22 May 2000 1:15:47 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 87984 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 22 May 2000 01:14:36 -0400 Received: from smtp-2.hut.fi by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B27FF790@standards.nortelnetworks.com>; Mon, 22 May 2000 1:04:36 -0400 Received: from cc.hut.fi (root@alpha.hut.fi [130.233.224.50]) by smtp-2.hut.fi (8.9.3/8.9.3) with ESMTP id IAA42416; Mon, 22 May 2000 08:12:06 +0300 (EEST) X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20 i586) X-Accept-Language: en MIME-Version: 1.0 References: <482568E4.001BA4C7.00@dlink.com.tw> <39250575.296E5E8D@darmstadt.gmd.de> <00c701bfc2ed$114167c0$5c12060a@hansol.co.kr> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <3928C205.63AADCF9@cc.hut.fi> Date: Mon, 22 May 2000 08:13:41 +0300 Reply-To: "Tom K. =?iso-8859-1?Q?Weckstr=F6m?=" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Tom K. =?iso-8859-1?Q?Weckstr=F6m?=" Organization: HUT Subject: Re: [MOBILE-IP] Maximum fequency of hand-offs in MIP X-To: Jiwoong Lee To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit Hi, Good points, Wolfgang. Jiwoong, please check Dynamics - HUT Mobile IP (url in signature). Dynamics has a 'Monitor' module that provides information from the IEEE 802.11 link layer to the mobile node to support more intelligent and more efficient handoffs. There is also an API for the Monitor module, and the mobile node supports 'handoff policies' that are rules according to which the handoff decisions are made. The 'iwspy' is used for the quality infromation. The code is available from Dynamics CVS repository. The idea can be extended to any link layer that provides link quality information. Our wireless network covering parts of the HUT campus only has IEEE 802.11 WLAN as a link layer, so we do not have experience about measuring other link layers. Regards, Tom Jiwoong Lee wrote: > > Thank Schoenfeld for the concise comments. > > RFC2002bis: in 3.6 pp.33, > > > "In the absence of link-layer indications, a mobile node > > MUST NOT attempt to register more often than once per second." > > This sentence seems to imply that MN's switching to the new base > station MAY trigger MN's new registration, with, if any, link-layer > indication. > > How about the Mobile IP test implementations ? Are they supporting > the triggering by a link-layer indication? > > Jiwoong Lee -- Tom Weckström Dynamics group Helsinki University of Technology dynamics@cs.hut.fi http://www.cs.hut.fi/Research/Dynamics/ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 22 12:58:09 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05197 for ; Mon, 22 May 2000 12:58:08 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.327CA170@standards.nortelnetworks.com>; Mon, 22 May 2000 12:49:41 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 88664 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 22 May 2000 12:49:26 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.294921A0@standards.nortelnetworks.com>; Mon, 22 May 2000 12:49:26 -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 KAA06014; Mon, 22 May 2000 10:56:59 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA18512; Mon, 22 May 2000 09:56: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 JAA14614; Mon, 22 May 2000 09:56:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Mon, 22 May 2000 09:56:55 -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] More thoughts on Regional Registrations X-To: "Charles E. Perkins" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <39261E45.B0E89AC5@iprg.nokia.com> > > Hello Pat, > > Here are some more answers. > > > 2. new MN-GFA Extension > > > > The Internet drafts introduces a new authentication extension, which is the > > MN-GFA. First, I have concerns with this one primarily because (to me) the > > whole idea behind the Regional draft is to try to hide alot of the internals > > of the network, but this new authentication extension forces the Mobile Node > > to KNOW that a GFA is being used. Certainly, the draft does state that the > > local FA doesn't have to advertise it's care-of address, and could include > > only the GFA, but HOW would the MN know that it should use the MN-GFA as > > opposed to the MN-FA? Furthermore, what occurs with RFC2002 mobile nodes? > > Annika, Eva, and I have come to the conclusion, each time that we > discuss this matter, that the mobile node has to know that it is > doing a regional registration. And, the leaf FA has to know. > The details about why are grungy and would take too long to type > in just now, but I can try it if you aren't happy with the mere > statement of it. Well, just because really doesn't answer my question :( I don't specifically have a problem with the Mobile Node having to know that it is doing a regional registration, but it would be REALLY nice to simplify the security model. > > > This extension does allow a mobile to share a secret with both the local FA > > and the GFA, but I question how often this would EVER be used. It really is > > too complex, IMHO. > > On the other hand, we don't want to mandate a restrictive security > model in the regional registration draft. Everything we have specified > will work with diverse or uniform key distribution in the collection of > regional foreign agents. If you want to manually distribute the same > key to every FA and every GFA, fine. If you want to do IPsec++ with > trimordial block vigilantism algorithms, then that is also fine with us. > We just want to specify what the control flow for the registration > traffic should be. That can be considered separately from how the > security associations are managed. We also expect that a good security > draft will discuss AAA mechanisms. We don't want to discuss AAA in > the regional registration draft. I agree that it doesn't need to be discussed in the draft, but a single authentication mechanism between the Mobile/FA/GFA would be really nice, and alot simpler. > > > 3. Hierarchical FA extension > > > > I question the use of this extension. Certainly all socket (and variant) > > implementations that I know of allow an application to know the source of the > > packet. If this wasn't the case, how would the FA know the source port? > > In my heart of hearts, I resonate with this philosophy. Unfortunately, > every time I try to follow it, the working group repudiates it. The > feeling seems to be that most programmers can't handle the extra bit > of programming. Examples where I have tried and failed to follow this > philosophy include Mobile IP, SLP, and DHCP drafts. If you can manage > the sociological process of transferring requirements off the wire and > onto the CPU (and the mind of the lowest common denominator of the > programming breed), then I wish you the best of luck. Be sure to > work it out with one or two IESG members before unleashing it onto > the working group. Furthermore, it apparently matters not in the > least that extra bits over the air are bad for wireless, at least > not in the mindset of the current IETF leadership. Well, given that there really aren't that many "legacy" devices out there that I am aware of that cannot produce the source of a packet to an application, I cannot see why this could not be considered. Do you think that this should be taken up in the general IETF list since it appears to be more of a sociological problem? > > > The problem here is that this extension breaks network address translation. > > The draft states that this extension contains the IP address of the Foreign > > Agent, and this COULD be an address that eventually gets translated. In my > > case, I have to write an ALG that handles this specific extension. Is there > > anyway that we could simply require that the GFA know that IP address of the > > sender through an API mechanism? > > Can't ALGs be made infinitely smart with unbounded state? Isn't this > good for the industry? But I wanted to no NO ALGs required... I already have Mobile IP working through my NAT fine, and this extension breaks it. PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 22 13:22:59 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05910 for ; Mon, 22 May 2000 13:22:59 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B3B6B980@standards.nortelnetworks.com>; Mon, 22 May 2000 13:14:46 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 88734 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 22 May 2000 13:13:20 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7FC88130@standards.nortelnetworks.com>; Mon, 22 May 2000 13:13:19 -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 KAA27252; Mon, 22 May 2000 10:20:50 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id KAA24675; Mon, 22 May 2000 10:20:48 -0700 X-Virus-Scanned: Mon, 22 May 2000 10:20:48 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from (charliep.iprg.nokia.com [205.226.2.89]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma022432; Mon, 22 May 00 10:19:54 -0700 X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39296C3B.A4201374@iprg.nokia.com> Date: Mon, 22 May 2000 10:19: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: Re: [MOBILE-IP] More thoughts on Regional Registrations X-To: "pcalhoun@eng.sun.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Pat, > Well, just because really doesn't answer my question :( I don't specifically > have a problem with the Mobile Node having to know that it is doing a > regional registration, but it would be REALLY nice to simplify the security > model. I guess I wasn't very clear. 1) I was asking for a rain check on answering the question, not saying just because. 2) You can use a simple security model. I just say that it isn't the _only_ security model. > I agree that it doesn't need to be discussed in the draft, but a single > authentication mechanism between the Mobile/FA/GFA would be really nice, and > alot simpler. Beauty is in the eye of the beholder. But I agree with you on all counts, except that I don't want to be restrictive in the regional registration draft. > Well, given that there really aren't that many "legacy" devices out there that > I am aware of that cannot produce the source of a packet to an application, I > cannot see why this could not be considered. Do you think that this should be > taken up in the general IETF list since it appears to be more of a > sociological problem? I hope you have a lot of spare time. There's a lot of things that should be taken up on the general IETF list, like how drafts get disapproved for making illustrative citations using example protocols that somehow don't meet the litmus tests of certain IESG members. I personally can't mess with it, and I don't like getting into antagonistic pissing matches with people who have all the cards. Maybe somebody else can find the magic algorithm for improvement. > But I wanted to no NO ALGs required... I already have Mobile IP working > through my NAT fine, and this extension breaks it. The function is important. You can make a specific proposal that meets working group approval and I'll be happy to go along. I hope we are not yet at the stage yet where we have to include a NAT Considerations section in each document, even for protocols in the Routing Area. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 22 14:27:07 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07454 for ; Mon, 22 May 2000 14:27:07 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AA63DBC0@standards.nortelnetworks.com>; Mon, 22 May 2000 14:18:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 88866 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 22 May 2000 14:17:09 -0400 Received: from omega.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6A0B89B0@standards.nortelnetworks.com>; Mon, 22 May 2000 14:17:08 -0400 Received: from gopal (dhcp-171-70-57-29.cisco.com [171.70.57.29]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id LAA02715; Mon, 22 May 2000 11:24:40 -0700 (PDT) X-Sender: gdommety@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 References: <"Your message with ID" <39261E45.B0E89AC5@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <4.1.20000522112447.02015b50@omega.cisco.com> Date: Mon, 22 May 2000 11:31:08 -0700 Reply-To: Gopal Dommety Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gopal Dommety Subject: [MOBILE-IP] draft-ietf-mobileip-challenge-09.txt X-To: "pcalhoun@eng.sun.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Hello Charlie and Pat: I would appreciate you clarificaiton regarding the following sentance the draft. If the MN-AAA Authentication extension is present, then the Registration Message MAY be sent by the mobile node without containing the Mobile-HA Authentication extension [12] Could you elaborate on how the HA authenticates the mobile in this case (i.e, only the MN-AAA is present). It may prove useful to add this clarification to the draft to avoid confusion. Thanks Gopal From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 22 19:08:22 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10961 for ; Mon, 22 May 2000 19:08:22 -0400 (EDT) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F7887A10@standards.nortelnetworks.com>; Mon, 22 May 2000 19:00:16 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 89121 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 22 May 2000 18:58:17 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B09F6690@standards.nortelnetworks.com>; Mon, 22 May 2000 18:58: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 RAA09545; Mon, 22 May 2000 17:05:52 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA28283; Mon, 22 May 2000 16:05:41 -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 QAA22010; Mon, 22 May 2000 16:05:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Mon, 22 May 2000 16:05:38 -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-challenge-09.txt X-To: Gopal Dommety To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <4.1.20000522112447.02015b50@omega.cisco.com> > > Hello Charlie and Pat: > > I would appreciate you clarificaiton regarding the following sentance the > draft. > > > If the MN-AAA Authentication > extension is present, then the Registration Message MAY be sent by > the mobile node without containing the Mobile-HA Authentication > extension [12] > > > Could you elaborate on how the HA authenticates the mobile in this case > (i.e, only the MN-AAA is present). It may prove useful to add this > clarification to the draft to avoid confusion. Well, the intent is that the AAAH and the HA inherently trust each other, and therefore that trust is assumed to be good enough to not require the MN-HA be present. This is especially important in cases where the MN doesn't have an HA allocated to it (initially), or when the HA is allocated in a foreign network. The AAA protocol *will* have to allow for messages between the AAAH and the HA to be reasonably secure, in order for the HA to be able to trust the request from the HA. Hope this helps, PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon May 22 21:43: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 VAA12214 for ; Mon, 22 May 2000 21:43:31 -0400 (EDT) Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.499B0470@standards.nortelnetworks.com>; Mon, 22 May 2000 21:32:53 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0040 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 22 May 2000 21:31:55 -0400 Received: from omega.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.24094000@standards.nortelnetworks.com>; Mon, 22 May 2000 21:31:50 -0400 Received: from gopal (dhcp-171-70-57-29.cisco.com [171.70.57.29]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id SAA03836; Mon, 22 May 2000 18:39:00 -0700 (PDT) X-Sender: gdommety@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 References: <"Your message with ID" <4.1.20000522173420.020170f0@omega.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <4.1.20000522175733.0201bb00@omega.cisco.com> Date: Mon, 22 May 2000 18:45:28 -0700 Reply-To: Gopal Dommety Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gopal Dommety Subject: Re: [MOBILE-IP] [tsgp] Re: Comments on PN-4732 -- MN-AAA Extension and FAC Draft X-To: "pcalhoun@eng.sun.com" , tsgp@3gpp2.org X-cc: "pcalhoun@eng.sun.com" , tsgp@3gpp2.org, smartin@cisco.com, cnee@cisco.com, mobileip-coders@cisco.com, gellert@cig.mot.com, afarcas1@email.mot.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Pat, The reason I am concerned is that the optional MN-HA Authentication might work for DIAMETER but might not work for RADIUS. In fact, I would appreciate if you could provide clarification as to how it would work. Thanks Gopal At 05:43 PM 22/05/00 -0700, pcalhoun@eng.sun.com wrote: >I would seriously caution this group to make sure that Mobile behaviour is >consistent regardless of the AAA protocol used. So, always assume that the >MN-HA is NOT present when MN-AAA is present. The MN-HA MUST be present in the >corresponding response. > >PatC >> >> >... and since the AAAH and the HA inherently trust each other, I don't see >> the >problem. If the AAAH tells the HA "take this here packet and process >> it. Trust >me, I've checked it, and you can make sure that I am the AAAH by >> checking >these bits". >> >> The case we are looking at is with RADIUS SPI and RADIUS processing. In this >> case the AAAH does not tell the HA anything. We are debating if having MN-HA >> AE optional with MN_AAA with RADIUS SPI >> >> Thanks >> Gopal >> >> >> > >> >Let's remember that one of the main reasons for the AAA is to reduce the >> >amount of administration that would otherwise be necessary on the HA, and >> even >allow for HAs to be allocated within a Foreign Domain. Now how would a >> Mobile >Node create a MN-HA, if: 1. The HA is unknown, and >> >2. The MN has no long lived security association with the (potentially) >> >unknown HA. >> > >> >> >> >> 3. The FAC draft does not specify what the PDSN has to do with the >> MN-AAA >> extension. Some implementations may want to send the MN-AAA >> to the AAA >> infrastructure and the MN-HA to the HA. >> >Well, as I stated above, I see no need for both the MN-AAA and the MN-HA. By >> >doing so, this eliminates all of the benefits of the MN-AAA, and the FAC >> draft >as well. The FAC draft doesn't state what to do with the AAA data, >> because >this is a AAA protocol thing, and has nothing to do with the FAC >> draft. In >fact, an older version of the FAC and NAI draft had some >> examples, which the >IESG requested that we remove for no real good reason >> (as far as the >co-authors can see). >> > >> > >> >> >> >> 4. We would like to reiterate the possibility that the AAA server may >> not >> have the key for HA authentication, especially in the case where >> >> the HA is outside the operator's network. >> > >> >And I would like to re-iterate, that one such AAA protocol actually defines >> in >quite a bit of detail how the HA is allocated in a foreign network, and >> even >what the payload looks like. >> > >> >Let us not forget that the MObile IP WG cannot document what the AAA >> protocol >looks like, because this belongs to another WG. Therefore, we need >> to also >look at the AAA protocol details. >> > >> >Hopefully this clarifies the issue. >> > >> >PatC >> >> >> >> Regards, >> >> Anda Farcasanu and Dorothy Gellert >> >> >> >> >> >> > X-Sender: gdommety@omega.cisco.com >> >> > Date: Mon, 22 May 2000 14:38:51 -0700 >> >> > To: tsgp@3gpp2.org >> >> > From: Gopal Dommety >> >> > Subject: [tsgp] Re: Comments on PN-4732 -- MN-AAA Extension and FAC >> >Draft >> > Cc: smartin@cisco.com, cnee@cisco.com, mobileip-coders@cisco.com >> >> > Mime-Version: 1.0 >> >> > List-Unsubscribe: >> >> > >> >> > At 11:14 AM 22/05/00 -0700, Raymond Hsu wrote: >> >> > >Hi Gopal: >> >> > > >> >> > >IS-835 has filled the blank in Section 6.3.4. Basically, the HA >> performs >> > >similarly to how PDSN handle MN-AAA authentication >> information. >> > >Specifically, when the HA recevies the MN-AAA Extension, >> the HA will >> > >communicate the MN-AAA authentication information to the >> local RADIUS >> > >server in a RADIUS Access-Request. >> >> > >> >> > Couple of points: >> >> > >> >> > 1. Going a bit further in your line of thought (althoguh this is not >> >> specified/mentioned). >> >> > If the HA uses the authentication infrastructure and the registration >> >fails >> >> the >> >> > authentication due to lifetime mismatch, how is the HA going to handel >> >this >> >> case. >> >> > >> >> > 2. You are assuming that the Local RADIUS to the HA has the Key, which >> >might >> >> not be true. In which >> >> > case how will be handel it. >> >> > >> >> > 3. The FAC draft states that the MN-AAA can be removed then what >> happens >then? >> >> > >> >> > In my opinion the FAC draft is not clear when the MN-HA is optional. >> And I >> believe that >> >> > statement has been in there with a different operational model than >> what >we >> >> have in PN-4732. >> >> > >> >> > MY REQUEST: >> >> > It might be a good idea to remove the optionality of MN-HA in the >> PN-4732 >> until we are clear on how it will work. >> >> > >> >> > Thanks >> >> > Gopal >> >> > >> >> > >> >> > > >> >> > >Regards, >> >> > > >> >> > >Raymond >> >> > > >> >> > >At 11:04 AM 5/22/00 -0700, Gopal Dommety wrote: >> >> > >>At 10:35 AM 22/05/00 -0700, Raymond Hsu wrote: >> >> > >>>Hi Rajesh: >> >> > >>> >> >> > >>>According to the FAC draft, if MN-AAA Extension is included in the >> >RRQ, the >> >> > >>>MN-HA Authentication Extension is optional. Since IS-835 has >> required >> > >>>MN-AAA Extension already, this is why MN-HA Authentication >> Extension is >> > >>>optional in IS-835, which is consistent with the FAC >> draft. >> > >> >> >> > >>FAC draft does not specify how the HA is supposed to authenticate if >> >HA gets >> >> > >>only the MN-AAA. >> >> > >> >> >> > >>Any thoughts on how this should be done? >> >> > >> >> >> > >>-Gopal >> >> > >> >> >> > >> >> >> > >>> >> >> > >>>Regards, >> >> > >>> >> >> > >>>Raymond >> >> > >>> >> >> > >>>At 12:04 AM 5/21/00 -0700, Rajesh Bhalla wrote: >> >> > >>>>Ray, Mark, et al >> >> > >>>> >> >> > >>>> I have a question related to the following text that has been >> >added to >> >> > >>>> section 6.5.2.3. (lines 8-9, page 33, clean-PDF version) >> >> > >>>> "The mobile station may include the MN-HA Authentication >> Extension >> > >>>> [RFC 2002]." >> >> > >>>> >> >> > >>>> The question is: MN-HA Authentication Extension is now optional >> at >> > >>>> the mobile; and if the mobile does not include the MN-HA >> >Authentication >> >> > >>>> Extension, what should the mobile expect from the HA in the RRP >> - >> > >>>> a MN-HA Authentication Extension or MN-AAA Extension ?? >> >> > >>>> >> >> > >>>> Both the FAC draft and IS-835 are quite on this for HA behaviour. >> >> > >>>> >> >> > >>>> Do we need to add text to IS-835 to address this ambiguity !! >> >> > >>>> >> >> > >>>>Thanks >> >> > >>>>Rajesh >> >> > >>>> >> >> > >>>>At 11:54 AM 5/9/00 -0700, Raymond Hsu wrote: >> >> > >>>>>Mark: >> >> > >>>>> >> >> > >>>>>Adding new text to remove technical inconsistency should be OK, >> >because >> >> we >> >> > >>>>>don't want our document to contradict itself. One example is the >> >> > >following: >> >> > >>>>> >> >> > >>>>>During the last meeting, we agreed in Section 6.5.2.3 to add the >> >sentence >> >> > >>>>>"The mobile station may include the MN-HA Authentication Extension >> >[RFC >> > >>>>>2002]." (lines 8-9, page 33, clean-PDF version). Because of >> this >> > >>>>>agreement, the sentence stated on lines 14-16 needs to be >> changed as >> > >>follows: >> >> > >>>>> >> >> > >>>>>"If the MN-HA Authentication Extension is included in the MIP RRQ, >> the >> > >>>>>mobile station shall compute the MN-HA Authentication >> Extension, >> according >> >> > >>>>>to [RFC 2002], based on the shared secret the mobile station has >> >with the >> >> > >>>HA." >> >> > >>>>> >> >> > >>>>>The new text is the beginning clause, and the rest of the sentence >> is >> same >> >> > >>>>>as before. This new text is necessary, because without it the >> >sentence >> >> on >> >> > >>>>>lines 14-16 contradicts the sentence on lines 8-9 in Section >> 6.5.2.3. >> > >>>>> >> >> > >>>>>Thanks, >> >> > >>>>> >> >> > >>>>>Raymond >> >> > >>>>> >> >> > >>>>>At 02:19 PM 5/9/00 -0400, Munson, Mark A. wrote: >> >> > >>>>>>Ray, >> >> > >>>>>> >> >> > >>>>>>Inasmuch as the document was approved by the committee at the end >> >of the >> > >>>>>>meeting, I don't plan to spend more meeting time >> reviewing editorial >> > >>>>>>corrections - the editor and I will just put >> them in before we >send it >> >> in >> >> > >>>>>>for publication. If I am not comfortable that the change is >> >editorial, >> >> > >>then >> >> > >>>>>>it won't get in. Cleaning up things in the accounting tables >> such >as >> >> > >>making >> >> > >>>>>>sure the values are consistent and defined is editorial. Adding >> new >> text >> >> > >>>>>>isn't. Let me point out that this isn't like a last call >> process. > As >> >> for >> >> > >>>>>>when it gets submitted - that's a problem with the FAC as you >> >pointed >> >> out. >> >> > >>>>>>I still haven't heard from Tom/Pete on its status. >> >> > >>>>>> >> >> > >>>>>>Regards, >> >> > >>>>>>Mark >> >> > >>>>>> >> >> > >>>>>>> ---------- >> >> > >>>>>>> From: Raymond Hsu[SMTP:rhsu@qualcomm.com] >> >> > >>>>>>> Reply To: Raymond Hsu >> >> > >>>>>>> Sent: Tuesday, May 09, 2000 1:38 PM >> >> > >>>>>>> To: tsgp@3gpp2.org >> >> > >>>>>>> Subject: [tsgp] Re: Conference Call Tomorrow -- Comments on >> >> PN-4732 >> >> > >>>>>>> >> >> > >>>>>>> Hi: >> >> > >>>>>>> >> >> > >>>>>>> My notes show that tomorrow's conference call is to resolve >> ballot >> > >>>>>>> comments >> >> > >>>>>>> on PN-4286-A, not PN-4732. >> >> > >>>>>>> >> >> > >>>>>>> Since our last face-to-face meeting, there were several e-mails >> >> > >>requesting >> > >>>>>>> editorial changes for PN-4732. What is the >> status of these >> > >requests? Do >> >> > >>>>>>> we need a separate conference call to review these editorial >> >> > >comments? I >> >> > >>>>>>> like to re-emphasize that we should not accept anymore >> technical >> ballot >> >> > >>>>>>> comments for PN-4732 at this point; however, we should flush >> out >> > >>editorial >> >> > >>>>>>> inconsistency and mistakes from PN-4732. >> >> > >>>>>>> >> >> > >>>>>>> Regards, >> >> > >>>>>>> >> >> > >>>>>>> Raymond >> >> > >>>>>>> >> >> > >>>>>>> At 10:10 AM 5/9/00 -0700, Rajesh Bhalla wrote: >> >> > >>>>>>> >Content-Type: text/plain; charset="us-ascii" >> >> > >>>>>>> >X-MIME-Autoconverted: from 8bit to quoted-printable by >> >> > >>>>>>> >sj-msg-core-2.cisco.com id KAA00480 >> >> > >>>>>>> > >> >> > >>>>>>> >Hello All, >> >> > >>>>>>> > >> >> > >>>>>>> > From further implementation experience, we stumbled on >> another >> 'typo' >> >> > >>>>>>> in >> >> > >>>>>>> > PN-4732. The typo results in a conflict in the assignment of >> >the >> > >>'Type' >> >> > >>>>>>> value >> >> > >>>>>>> > >> >> > >>>>>>> > to one of the Airlink Record Specific Parameters in the >> >horizontal >> >> > >>>>>>> Table-5 >> >> > >>>>>>> > in Section 9.4. This typo is in addition to two other >> >comments that >> >> I >> >> > >>>>>>> had >> >> > >>>>>>> > forwarded to the group earlier on May 2nd. >> >> > >>>>>>> > >> >> > >>>>>>> > Below is the consolidated list of the THREE comments with the >> >> > >request >> > >>>>>>> > that these be addressed at the upcoming >> conference call >tomorrow. >> >> > >>>>>>> > >> >> > >>>>>>> > 1. 'y1 Airlink Record Type' has been assigned a value of >> >'26/40'. >> >> > >>>>>>> Value >> >> > >>>>>>> >'26/40' >> >> > >>>>>>> > is already used for parameter 'C2 Correlation ID'. The >> >> > >proposal is >> >> > >>>>>>> to >> >> > >>>>>>> >assign >> >> > >>>>>>> > value of '26/44'(or some other non-conflicting value) to >> the >> > >>>>>>> parameter >> >> > >>>>>>> >'y1'. >> >> > >>>>>>> > >> >> > >>>>>>> > 2. The second comment relates to some typos regards the >> 'y1' >type >> >> > >>>>>>> airlink >> >> > >>>>>>> > parameters. Table 5, section 9.4 specifies the >> enumerated >> > >values >> >> > >>>>>>> > for various airlink events as: >> >> > >>>>>>> > >> >> > >>>>>>> > y1= 1 (Connection Setup) >> >> > >>>>>>> > y1= 2 (Active Start) >> >> > >>>>>>> > y1= 3 (Active Stop) >> >> > >>>>>>> > y1= 4 (SDB Record) >> >> > >>>>>>> > >> >> > >>>>>>> > We need to modify the Airlink Record Types in the >> >tables in >> >> > >>>>>>> sections >> >> > >>>>>>> > 9.2.2, 9.2.3 and 9.2.4 also to account for the removal >> >of >> the >> >> > >>>>>>> >Connection >> >> > >>>>>>> > Release type airlink record. >> >> > >>>>>>> > >> >> > >>>>>>> > 3. The third comment relates to the need for address some >> >details >> >> on >> >> > >>>>>>> > the SDB Airlink Record. Attached is a proposal that >> >contains >> >> two >> >> > >>>>>>> options >> >> > >>>>>>> > >> >> > >>>>>>> > for addressing the changes. Though two options are >> >included, >> >> we >> >> > >>>>>>> prefer >> >> > >>>>>>> > Option-1 as it uses fewer airlink parameters.. >> >> > >>>>>>> > >> >> > >>>>>>> > Again, we would appreciate that these comments be >> addressed >at >> >> the >> >> > >>>>>>> > conference call tomorrow. >> >> > >>>>>>> > >> >> > >>>>>>> >Thanks >> >> > >>>>>>> >Rajesh Bhalla >> >> > >>>>>>> >Cisco Systems Inc. >> >> > >>>>>>> > >> >> > >>>>>>> > >> >> > >>>>>>> > >> >> > >>>>>>> >> >> > >>>>>>> >> >> > >>>>>>> --- >> >> > >>>>>>> You are currently subscribed to tsgp as: >> mmunson@mobilnet.gte.com >> > >>>>>>> >> >> > >>>>>> >> >> > >>>>>>--- >> >> > >>>>>>You are currently subscribed to tsgp as: rhsu@qualcomm.com >> >> > >>>>>> >> >> > >>>>> >> >> > >>>>> >> >> > >>>>>--- >> >> > >>>>>You are currently subscribed to tsgp as: rabhalla@cisco.com >> >> > >>>>> >> >> > >>>> >> >> > >>>> >> >> > >>>>--- >> >> > >>>>You are currently subscribed to tsgp as: rhsu@qualcomm.com >> >> > >>>> >> >> > >>> >> >> > >>> >> >> > >>>--- >> >> > >>>You are currently subscribed to tsgp as: gdommety@cisco.com >> >> > >>> >> >> > >>> >> >> > >> >> >> > >> >> >> > >>--- >> >> > >>You are currently subscribed to tsgp as: rhsu@qualcomm.com >> >> > >> >> >> > > >> >> > > >> >> > >--- >> >> > >You are currently subscribed to tsgp as: gdommety@cisco.com >> >> > > >> >> > > >> >> > >> >> > >> >> > --- >> >> > You are currently subscribed to tsgp as: cdg014@email.mot.com >> >> >> >> >> >> --- >> >> You are currently subscribed to tsgp as: pcalhoun@eng.sun.com >> >> >> > >> > >> > >> >--- >> >You are currently subscribed to tsgp as: gdommety@cisco.com >> > >> > >> > > > >--- >You are currently subscribed to tsgp as: gdommety@cisco.com > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 23 10:12: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 KAA03865 for ; Tue, 23 May 2000 10:12:16 -0400 (EDT) Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F1D8CC90@standards.nortelnetworks.com>; Tue, 23 May 2000 10:02:03 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1019 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 23 May 2000 10:00:46 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C3EC5C20@standards.nortelnetworks.com>; Tue, 23 May 2000 10:00:46 -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 IAA09594 for ; Tue, 23 May 2000 08:08:24 -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 HAA27667 for ; Tue, 23 May 2000 07:08:20 -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 HAA02420 for ; Tue, 23 May 2000 07:08:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Tue, 23 May 2000 07:08:17 -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] Comments on PN-4732 -- MN-AAA Extension and FAC Draft To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM OK, In my Home Agent, if I receive a packet from a Foreign Agent, which includes an MN-AAA Authentication extension, that was computed using the "RADIUS" algorith, as defined in the Internet-Draft, when the Home Agent generates an Access-Request. The Challenge is included, and the Response as well, as produced from the alforithm defined in the draft. The Home Agent knows that it shouldn't expect to see the MN-HA auth ext, because it saw the MN-AAA authentication extension. If the RADIUS server says yes, then the HA is happy, and produces the MN-HA using whatever key distribution mechanism you've come up with in TSG-P, which smells of sending the user's password in the clear. PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 23 14:39: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 OAA07815 for ; Tue, 23 May 2000 14:38:59 -0400 (EDT) Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3E38CD40@standards.nortelnetworks.com>; Tue, 23 May 2000 14:29:03 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1288 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 23 May 2000 14:28:39 -0400 Received: from omega.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3004F000@standards.nortelnetworks.com>; Tue, 23 May 2000 14:28:39 -0400 Received: from gopal (dhcp-171-70-57-29.cisco.com [171.70.57.29]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id LAA22860; Tue, 23 May 2000 11:35:44 -0700 (PDT) X-Sender: gdommety@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <4.1.20000523113155.02035b70@omega.cisco.com> Date: Tue, 23 May 2000 11:42:08 -0700 Reply-To: Gopal Dommety Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gopal Dommety Subject: Re: [MOBILE-IP] length field in vendor specific extension X-To: Woo-June Kim To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <003f01bfc4ab$5e682b00$b4b1d5a5@keg.telecom.samsung.co.kr> Hello Woo-June: >2.1. Critical Vendor/Organization Specific Extension (CVSE) > > The format of this extension is as shown below. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Reserved | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vendor/Org-ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vendor-CVSE-Type | Vendor-CVSE-Value | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Figure 1: Critical Vendor/Organization Specific Extension > > Type 38 (To be assigned by IANA) > > > Reserved Reserved for future use. MUST be set to 0 on sending, > MUST be ignored on reception. > > Length Length in bytes of this extension, not including the > Type and Length bytes. > >....." > > >I noticed that it seems unclear on whether the Reserved field should be >included in the length field or not. If taken literally it seems you must >include it, but not include the type and length fields on either side of it. > >Could you clarify ?? > Length feild should indicate Length in bytes of this extension, not including the number of bytes in the Type field and Length field. So it is the total number of bytes, not including the Type and Length feilds (it does not include the Vendor-NVSE/CVSE-Type). Is the following clarification enough? Length Length in bytes of this extension, not including the Type and Length feild bytes. Thanks, Gopal From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 23 14:53: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 OAA07817 for ; Tue, 23 May 2000 14:39:00 -0400 (EDT) Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8631CA20@standards.nortelnetworks.com>; Tue, 23 May 2000 14:31:03 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1296 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 23 May 2000 14:30:22 -0400 Received: from omega.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6CFE3890@standards.nortelnetworks.com>; Tue, 23 May 2000 14:30:21 -0400 Received: from gopal (dhcp-171-70-57-29.cisco.com [171.70.57.29]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id LAA23309; Tue, 23 May 2000 11:37:58 -0700 (PDT) X-Sender: gdommety@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <4.1.20000523100705.0202b3d0@omega.cisco.com> Date: Tue, 23 May 2000 11:44:21 -0700 Reply-To: Gopal Dommety Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gopal Dommety Subject: Re: [MOBILE-IP] Comments on PN-4732 -- MN-AAA Extension and FAC Draft X-To: "pcalhoun@eng.sun.com" X-cc: rcoltun@siara.com, oran@cisco.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: At 07:08 AM 23/05/00 -0700, pcalhoun@eng.sun.com wrote: >OK, In my Home Agent, if I receive a packet from a Foreign Agent, which >includes an MN-AAA Authentication extension, that was computed using the >"RADIUS" algorith, as defined in the Internet-Draft, when the Home Agent >generates an Access-Request. The Challenge is included, and the Response as >well, as produced from the alforithm defined in the draft. > >The Home Agent knows that it shouldn't expect to see the MN-HA auth ext, >because it saw the MN-AAA authentication extension. If the RADIUS server says So, the HA checks the lifetime etc and passes an Access-Request to the RADIUS server, which checks CHAP auth. >yes, then the HA is happy, and produces the MN-HA using whatever key >distribution mechanism you've come up with in TSG-P, which smells of sending >the user's password in the clear. Hmmm. Are you saying that the Registration request will have MN-AAA AE and the reply will have a MN-HA AE in this case? This is confusing and needs clarification. The MN-AAA AE is used for AAA authentication and MN-HA is used for HA authentication. And optionalizing MN-HA AE implies that the mobile IP message Need Not Be AUTHENTICATED by the HA but should check for replay protection (essentailly HA believes the AAA). This changes the security model and the processing in the HA. We have two options: 1. HA asks the AAA to authenticate the MN and 2. AAA authenticates the MN and tells the HA. What is not clear is the details and whether this works? When we are operating with RADIUS (or any other protocol depending on the operation), the HA could ask the RADIUS server for authenticating, in which case some clarification is needed as to what the operations should be. Either we remove the text optionalizing the HA-MN AE or we should provide clarification how it is supposed to work. Since this changes the mandatory authentication of RFC2002 (and some of the procedures) I think some clarification text is need to the draft. Clarifing these procedures will enable interoperability. If there any intricacies of AAA protocols that are involved, those should also be clarified. Would the statement about making MN-HA was made optional apply to Diamater like protocol only. If you could supply some clarification as to how it is supposed to work with the details that would help. I have no problem with the procedures as long as there is enough clarification provided that will help understand how it is supposed to work. Thanks Gopal > >PatC > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 23 16:06: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 QAA08910 for ; Tue, 23 May 2000 16:06:15 -0400 (EDT) Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.726FD7F0@standards.nortelnetworks.com>; Tue, 23 May 2000 15:56:24 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1482 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 23 May 2000 15:55:21 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4CA26A10@standards.nortelnetworks.com>; Tue, 23 May 2000 15:55:21 -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 OAA26573; Tue, 23 May 2000 14:02:53 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA12879; Tue, 23 May 2000 13:02:46 -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 NAA07344; Tue, 23 May 2000 13:02:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Tue, 23 May 2000 13:02:43 -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] Comments on PN-4732 -- MN-AAA Extension and FAC Draft X-To: Gopal Dommety X-cc: rcoltun@siara.com, oran@cisco.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <4.1.20000523100705.0202b3d0@omega.cisco.com> > At 07:08 AM 23/05/00 -0700, pcalhoun@eng.sun.com wrote: > >OK, In my Home Agent, if I receive a packet from a Foreign Agent, which > >includes an MN-AAA Authentication extension, that was computed using the > >"RADIUS" algorith, as defined in the Internet-Draft, when the Home Agent > >generates an Access-Request. The Challenge is included, and the Response as > >well, as produced from the alforithm defined in the draft. > > > >The Home Agent knows that it shouldn't expect to see the MN-HA auth ext, > >because it saw the MN-AAA authentication extension. If the RADIUS server > says > > So, the HA checks the lifetime etc and passes an Access-Request to the > RADIUS server, which checks CHAP auth. When supporting RADIUS, that is about as good as it gets. > > >yes, then the HA is happy, and produces the MN-HA using whatever key > >distribution mechanism you've come up with in TSG-P, which smells of sending > >the user's password in the clear. > > > Hmmm. Are you saying that the Registration request will have MN-AAA AE and > the reply will have a MN-HA AE in this case? This is confusing and needs > clarification. OK. I re-read the draft, and it does state: "The mobile node MAY include a MN-AAA Authentication extension in any Registration Request." It never mentions the MN-AAA ever being present in the reply. Are you asking that the text be clarified in order to state that the MN-HA would be present in the response? Since I've already seen four implementations interoperate, I would like to make sure that the new proposed text is really clear, and doesn't change the behavior of the I-D. > > The MN-AAA AE is used for AAA authentication and MN-HA is used for HA > authentication. And optionalizing MN-HA AE implies that the mobile IP > message Need Not Be AUTHENTICATED by the HA but should check for replay > protection (essentailly HA believes the AAA). This changes the security > model and the processing in the HA. > > We have two options: 1. HA asks the AAA to authenticate the MN and 2. AAA > authenticates the MN and tells the HA. What is not clear is the details and > whether this works? But the design goal behind most of the AAA/Mobile IP work was to assume that the AAA did not know how to decode/parse/build Mobile IP registration messages. I would REALLY like for this to not change, since the AAA server needs to be kept as simple as possible. > > When we are operating with RADIUS (or any other protocol depending on the > operation), the HA could ask the RADIUS server for authenticating, in > which case some clarification is needed as to what the operations should be. > > Either we remove the text optionalizing the HA-MN AE or we should provide > clarification how it is supposed to work. Since this changes the mandatory > authentication of RFC2002 (and some of the procedures) I think some > clarification text is need to the draft. Clarifing these procedures will > enable interoperability. See my comment above. Further, the draft DOES include the following text: " If the MN-AAA Authentication extension is present, then the Registration Message MAY be sent by the mobile node without containing the Mobile-HA Authentication extension [12]." So, are you stating that you would prefer to see a MUST NOT instead of a MAY? > > If there any intricacies of AAA protocols that are involved, those should > also be clarified. Would the statement about making MN-HA was made optional > apply to Diamater like protocol only. If you could supply some clarification > as to how it is supposed to work with the details that would help. I have no > problem with the procedures as long as there is enough clarification > provided that will help understand how it is supposed to work. First, just for the record, whatever the AAA protocol happens to be (modulo RADIUS), it should behave in the manner that we've been talking about for well over 1.5 years, which is how DIAMETER is implemented. The actual AAA protocol itself is really irrelevant. PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 23 17:48: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 RAA10274 for ; Tue, 23 May 2000 17:48:49 -0400 (EDT) Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C4EC72F0@standards.nortelnetworks.com>; Tue, 23 May 2000 17:38:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1594 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 23 May 2000 17:37:53 -0400 Received: from omega.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9F9D5CD0@standards.nortelnetworks.com>; Tue, 23 May 2000 17:37:53 -0400 Received: from gopal (dhcp-171-70-57-29.cisco.com [171.70.57.29]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id OAA19116; Tue, 23 May 2000 14:45:29 -0700 (PDT) X-Sender: gdommety@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 References: <"Your message with ID" <4.1.20000523100705.0202b3d0@omega.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <4.1.20000523144927.02036810@omega.cisco.com> Date: Tue, 23 May 2000 14:51:22 -0700 Reply-To: Gopal Dommety Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gopal Dommety Subject: Re: [MOBILE-IP] Comments on PN-4732 -- MN-AAA Extension and FAC Draft X-To: "pcalhoun@eng.sun.com" X-cc: mobileip-coders@cisco.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: >See my comment above. Further, the draft DOES include the following text: > >" If the MN-AAA Authentication extension is present, then the Registration >Message MAY be sent by the mobile node without containing the Mobile-HA >Authentication extension [12]." > >So, are you stating that you would prefer to see a MUST NOT instead of a MAY? Adding MUST NOT instead of MAY will remove the confusion. If we want to leave it as MAY then clarification is needed. Thanks Gopal From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue May 23 21:38: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 VAA14465 for ; Tue, 23 May 2000 21:38:50 -0400 (EDT) Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E76F6330@standards.nortelnetworks.com>; Tue, 23 May 2000 21:28:57 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1887 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 23 May 2000 21:26:58 -0400 Received: from avana.net (64.30.69.179) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.39DA8C50@standards.nortelnetworks.com>; Tue, 23 May 2000 21:16:57 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=200005232116=" X-Mailer: 1254025F.11253E12.78e8be231e06d70c5f2c961f9741341b Message-ID: Date: Tue, 23 May 2000 21:26:58 -0400 Reply-To: amerisep@AVANA.NET Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: amerisep@AVANA.NET Subject: [MOBILE-IP] Sorry It Took So Long To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --=200005232116= Content-Type: text/plain;charset=US-ASCII Here Is the septic system info you requested http://www.amerisep.com/ --=200005232116=-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed May 24 02:08: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 CAA29903 for ; Wed, 24 May 2000 02:08:10 -0400 (EDT) Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.68E57A60@standards.nortelnetworks.com>; Wed, 24 May 2000 1:57:26 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2092 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 24 May 2000 01:55:51 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CA8F6110@standards.nortelnetworks.com>; Wed, 24 May 2000 1:45:51 -0400 Received: from ccefs.adm.cce.puc-rio.br (ccefs.adm.cce.puc-rio.br [139.82.88.2]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id AAA09629 for ; Wed, 24 May 2000 00:53:28 -0500 (CDT) Received: from phhj060hj0jh0jh (sdn-ar-004cthartP272.dialsprint.net [158.252.36.202]) by ccefs.adm.cce.puc-rio.br with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id LKAR5BGS; Wed, 24 May 2000 02:54:00 -0300 Message-ID: <200005243896HAA40999@cfdertgh6u.adm.cce.puc-rio.br> Date: Wed, 24 May 2000 00:53:28 -0500 Reply-To: Stacy Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: Authenticated sender is From: Stacy Subject: [MOBILE-IP] Diplomas 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. remove---- steve4761@excite.com 411380821671269450140302 ± nlh. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed May 24 10:12: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 KAA06398 for ; Wed, 24 May 2000 10:12:16 -0400 (EDT) Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1D0148B0@standards.nortelnetworks.com>; Wed, 24 May 2000 10:02:04 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2448 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 24 May 2000 10:00:10 -0400 Received: from anchor-post-34.mail.demon.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.73428010@standards.nortelnetworks.com>; Wed, 24 May 2000 9:50:10 -0400 Received: from panasonic-pmdc.demon.co.uk ([194.222.202.84] helo=panasonic-pmdc.co.uk) by anchor-post-34.mail.demon.net with smtp (Exim 2.12 #1) id 12ubfR-000MpJ-0Y for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 24 May 2000 14:57:50 +0100 MIME-Version: 1.0 Message-ID: Date: Wed, 24 May 2000 14:50:05 +0100 Reply-To: Gavin Button Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gavin Button Subject: [MOBILE-IP] A General question. To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi, When the Internet Draft 'Mobility Support for IPv6' talks of MobileIPv6 being fully integrated into IPv6. Does it mean that an IPv6 stack will be able to operate as a Mobile Node or Home Agent just by configuration or will additional software be required? Thanks, Gavin Button Panasonic Mobile Communications Development Office From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed May 24 12:28: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 MAA08555 for ; Wed, 24 May 2000 12:28:23 -0400 (EDT) Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.57BE3B30@standards.nortelnetworks.com>; Wed, 24 May 2000 12:19:43 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2589 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 24 May 2000 12:18:35 -0400 Received: from mgw-x1.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2EB32E80@standards.nortelnetworks.com>; Wed, 24 May 2000 12:18:34 -0400 Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id TAA10036; Wed, 24 May 2000 19:26:02 +0300 (EETDST) Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id TAA06564; Wed, 24 May 2000 19:26:01 +0300 (EETDST) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id ; Wed, 24 May 2000 11:24:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2BCD506C@daeis07nok> Date: Wed, 24 May 2000 11:24:04 -0500 Reply-To: Basavaraj.Patil@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: Re: [MOBILE-IP] Comments on PN-4732 -- MN-AAA Extension and FAC D raft X-cc: gdommety@CISCO.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM >>See my comment above. Further, the draft DOES include the following text: >> >>" If the MN-AAA Authentication extension is present, then the Registration >>Message MAY be sent by the mobile node without containing the Mobile-HA >>Authentication extension [12]." >> >>So, are you stating that you would prefer to see a MUST NOT instead of a MAY? > > >Adding MUST NOT instead of MAY will remove the confusion. If we want >to leave it as MAY then clarification is needed. > >Thanks >Gopal I would prefer to keep it MAY and add further clarification to the draft. -Basavaraj From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed May 24 17:36: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 RAA13251 for ; Wed, 24 May 2000 17:36:43 -0400 (EDT) Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.70D9F070@standards.nortelnetworks.com>; Wed, 24 May 2000 17:28:14 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2835 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 24 May 2000 17:26:49 -0400 Received: from franklin.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3E078860@standards.nortelnetworks.com>; Wed, 24 May 2000 17:26:49 -0400 Received: from gwz (sj-dial-3-215.cisco.com [171.68.180.216]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id OAA05046; Wed, 24 May 2000 14:34:15 -0700 (PDT) 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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: Date: Wed, 24 May 2000 14:18:11 -0700 Reply-To: gwz@cisco.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Glen Zorn Subject: Re: [MOBILE-IP] [tsgp] Re: Comments on PN-4732 -- MN-AAA Extension and FAC Draft X-To: Gopal Dommety To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <4.1.20000522175733.0201bb00@omega.cisco.com> Content-Transfer-Encoding: 7bit Gopal Dommety [mailto://gdommety@cisco.com] writes: > Pat, > > The reason I am concerned is that the optional MN-HA > Authentication might work for DIAMETER > but might not work for RADIUS. RADIUS is dead. > In fact, I would appreciate if you > could provide clarification as to how > it would work. > > Thanks > Gopal > > > > At 05:43 PM 22/05/00 -0700, pcalhoun@eng.sun.com wrote: > >I would seriously caution this group to make sure that Mobile > behaviour is > >consistent regardless of the AAA protocol used. So, always > assume that the > >MN-HA is NOT present when MN-AAA is present. The MN-HA MUST be > present in the > >corresponding response. > > > >PatC > >> > >> >... and since the AAAH and the HA inherently trust each > other, I don't see > >> the >problem. If the AAAH tells the HA "take this here packet > and process > >> it. Trust >me, I've checked it, and you can make sure that I > am the AAAH by > >> checking >these bits". > >> > >> The case we are looking at is with RADIUS SPI and RADIUS > processing. In this > >> case the AAAH does not tell the HA anything. We are debating > if having MN-HA > >> AE optional with MN_AAA with RADIUS SPI > >> > >> Thanks > >> Gopal > >> > >> > >> > > >> >Let's remember that one of the main reasons for the AAA is to > reduce the > >> >amount of administration that would otherwise be necessary on > the HA, and > >> even >allow for HAs to be allocated within a Foreign Domain. > Now how would a > >> Mobile >Node create a MN-HA, if: 1. The HA is unknown, and > >> >2. The MN has no long lived security association with the > (potentially) > >> >unknown HA. > >> > > >> >> > >> >> 3. The FAC draft does not specify what the PDSN has to do with the > >> MN-AAA >> extension. Some implementations may want to > send the MN-AAA > >> to the AAA >> infrastructure and the MN-HA to the HA. > >> >Well, as I stated above, I see no need for both the MN-AAA > and the MN-HA. By > >> >doing so, this eliminates all of the benefits of the MN-AAA, > and the FAC > >> draft >as well. The FAC draft doesn't state what to do with > the AAA data, > >> because >this is a AAA protocol thing, and has nothing to do > with the FAC > >> draft. In >fact, an older version of the FAC and NAI draft had some > >> examples, which the >IESG requested that we remove for no real > good reason > >> (as far as the >co-authors can see). > >> > > >> > > >> >> > >> >> 4. We would like to reiterate the possibility that the > AAA server may > >> not >> have the key for HA authentication, especially in > the case where > >> >> the HA is outside the operator's network. > >> > > >> >And I would like to re-iterate, that one such AAA protocol > actually defines > >> in >quite a bit of detail how the HA is allocated in a foreign > network, and > >> even >what the payload looks like. > >> > > >> >Let us not forget that the MObile IP WG cannot document what the AAA > >> protocol >looks like, because this belongs to another WG. > Therefore, we need > >> to also >look at the AAA protocol details. > >> > > >> >Hopefully this clarifies the issue. > >> > > >> >PatC > >> >> > >> >> Regards, > >> >> Anda Farcasanu and Dorothy Gellert > >> >> > >> >> > >> >> > X-Sender: gdommety@omega.cisco.com > >> >> > Date: Mon, 22 May 2000 14:38:51 -0700 > >> >> > To: tsgp@3gpp2.org > >> >> > From: Gopal Dommety > >> >> > Subject: [tsgp] Re: Comments on PN-4732 -- MN-AAA > Extension and FAC > >> >Draft >> > Cc: smartin@cisco.com, cnee@cisco.com, > mobileip-coders@cisco.com > >> >> > Mime-Version: 1.0 > >> >> > List-Unsubscribe: > >> >> > > >> >> > At 11:14 AM 22/05/00 -0700, Raymond Hsu wrote: > >> >> > >Hi Gopal: > >> >> > > > >> >> > >IS-835 has filled the blank in Section 6.3.4. Basically, the HA > >> performs >> > >similarly to how PDSN handle MN-AAA authentication > >> information. >> > >Specifically, when the HA recevies the > MN-AAA Extension, > >> the HA will >> > >communicate the MN-AAA authentication > information to the > >> local RADIUS >> > >server in a RADIUS Access-Request. > >> >> > > >> >> > Couple of points: > >> >> > > >> >> > 1. Going a bit further in your line of thought (althoguh > this is not > >> >> specified/mentioned). > >> >> > If the HA uses the authentication infrastructure and the > registration > >> >fails > >> >> the > >> >> > authentication due to lifetime mismatch, how is the HA > going to handel > >> >this > >> >> case. > >> >> > > >> >> > 2. You are assuming that the Local RADIUS to the HA has > the Key, which > >> >might > >> >> not be true. In which > >> >> > case how will be handel it. > >> >> > > >> >> > 3. The FAC draft states that the MN-AAA can be removed then what > >> happens >then? > >> >> > > >> >> > In my opinion the FAC draft is not clear when the MN-HA > is optional. > >> And I >> believe that > >> >> > statement has been in there with a different operational > model than > >> what >we > >> >> have in PN-4732. > >> >> > > >> >> > MY REQUEST: > >> >> > It might be a good idea to remove the optionality of MN-HA in the > >> PN-4732 >> until we are clear on how it will work. > >> >> > > >> >> > Thanks > >> >> > Gopal > >> >> > > >> >> > > >> >> > > > >> >> > >Regards, > >> >> > > > >> >> > >Raymond > >> >> > > > >> >> > >At 11:04 AM 5/22/00 -0700, Gopal Dommety wrote: > >> >> > >>At 10:35 AM 22/05/00 -0700, Raymond Hsu wrote: > >> >> > >>>Hi Rajesh: > >> >> > >>> > >> >> > >>>According to the FAC draft, if MN-AAA Extension is > included in the > >> >RRQ, the > >> >> > >>>MN-HA Authentication Extension is optional. Since IS-835 has > >> required >> > >>>MN-AAA Extension already, this is why MN-HA > Authentication > >> Extension is >> > >>>optional in IS-835, which is consistent > with the FAC > >> draft. >> > >> > >> >> > >>FAC draft does not specify how the HA is supposed to > authenticate if > >> >HA gets > >> >> > >>only the MN-AAA. > >> >> > >> > >> >> > >>Any thoughts on how this should be done? > >> >> > >> > >> >> > >>-Gopal > >> >> > >> > >> >> > >> > >> >> > >>> > >> >> > >>>Regards, > >> >> > >>> > >> >> > >>>Raymond > >> >> > >>> > >> >> > >>>At 12:04 AM 5/21/00 -0700, Rajesh Bhalla wrote: > >> >> > >>>>Ray, Mark, et al > >> >> > >>>> > >> >> > >>>> I have a question related to the following text > that has been > >> >added to > >> >> > >>>> section 6.5.2.3. (lines 8-9, page 33, clean-PDF version) > >> >> > >>>> "The mobile station may include the MN-HA Authentication > >> Extension >> > >>>> [RFC 2002]." > >> >> > >>>> > >> >> > >>>> The question is: MN-HA Authentication Extension is > now optional > >> at >> > >>>> the mobile; and if the mobile does not include the MN-HA > >> >Authentication > >> >> > >>>> Extension, what should the mobile expect from the > HA in the RRP > >> - >> > >>>> a MN-HA Authentication Extension or MN-AAA Extension ?? > >> >> > >>>> > >> >> > >>>> Both the FAC draft and IS-835 are quite on this for > HA behaviour. > >> >> > >>>> > >> >> > >>>> Do we need to add text to IS-835 to address this > ambiguity !! > >> >> > >>>> > >> >> > >>>>Thanks > >> >> > >>>>Rajesh > >> >> > >>>> > >> >> > >>>>At 11:54 AM 5/9/00 -0700, Raymond Hsu wrote: > >> >> > >>>>>Mark: > >> >> > >>>>> > >> >> > >>>>>Adding new text to remove technical inconsistency > should be OK, > >> >because > >> >> we > >> >> > >>>>>don't want our document to contradict itself. One > example is the > >> >> > >following: > >> >> > >>>>> > >> >> > >>>>>During the last meeting, we agreed in Section > 6.5.2.3 to add the > >> >sentence > >> >> > >>>>>"The mobile station may include the MN-HA > Authentication Extension > >> >[RFC >> > >>>>>2002]." (lines 8-9, page 33, clean-PDF > version). Because of > >> this >> > >>>>>agreement, the sentence stated on lines 14-16 > needs to be > >> changed as >> > >>follows: > >> >> > >>>>> > >> >> > >>>>>"If the MN-HA Authentication Extension is included > in the MIP RRQ, > >> the >> > >>>>>mobile station shall compute the MN-HA Authentication > >> Extension, >> according > >> >> > >>>>>to [RFC 2002], based on the shared secret the mobile > station has > >> >with the > >> >> > >>>HA." > >> >> > >>>>> > >> >> > >>>>>The new text is the beginning clause, and the rest > of the sentence > >> is >> same > >> >> > >>>>>as before. This new text is necessary, because > without it the > >> >sentence > >> >> on > >> >> > >>>>>lines 14-16 contradicts the sentence on lines 8-9 in Section > >> 6.5.2.3. >> > >>>>> > >> >> > >>>>>Thanks, > >> >> > >>>>> > >> >> > >>>>>Raymond > >> >> > >>>>> > >> >> > >>>>>At 02:19 PM 5/9/00 -0400, Munson, Mark A. wrote: > >> >> > >>>>>>Ray, > >> >> > >>>>>> > >> >> > >>>>>>Inasmuch as the document was approved by the > committee at the end > >> >of the >> > >>>>>>meeting, I don't plan to spend more meeting time > >> reviewing editorial >> > >>>>>>corrections - the editor and I > will just put > >> them in before we >send it > >> >> in > >> >> > >>>>>>for publication. If I am not comfortable that the change is > >> >editorial, > >> >> > >>then > >> >> > >>>>>>it won't get in. Cleaning up things in the > accounting tables > >> such >as > >> >> > >>making > >> >> > >>>>>>sure the values are consistent and defined is > editorial. Adding > >> new >> text > >> >> > >>>>>>isn't. Let me point out that this isn't like a last call > >> process. > As > >> >> for > >> >> > >>>>>>when it gets submitted - that's a problem with the > FAC as you > >> >pointed > >> >> out. > >> >> > >>>>>>I still haven't heard from Tom/Pete on its status. > >> >> > >>>>>> > >> >> > >>>>>>Regards, > >> >> > >>>>>>Mark > >> >> > >>>>>> > >> >> > >>>>>>> ---------- > >> >> > >>>>>>> From: Raymond Hsu[SMTP:rhsu@qualcomm.com] > >> >> > >>>>>>> Reply To: Raymond Hsu > >> >> > >>>>>>> Sent: Tuesday, May 09, 2000 1:38 PM > >> >> > >>>>>>> To: tsgp@3gpp2.org > >> >> > >>>>>>> Subject: [tsgp] Re: Conference Call > Tomorrow -- Comments on > >> >> PN-4732 > >> >> > >>>>>>> > >> >> > >>>>>>> Hi: > >> >> > >>>>>>> > >> >> > >>>>>>> My notes show that tomorrow's conference call is > to resolve > >> ballot >> > >>>>>>> comments > >> >> > >>>>>>> on PN-4286-A, not PN-4732. > >> >> > >>>>>>> > >> >> > >>>>>>> Since our last face-to-face meeting, there were > several e-mails > >> >> > >>requesting >> > >>>>>>> editorial changes for PN-4732. > What is the > >> status of these >> > >requests? Do > >> >> > >>>>>>> we need a separate conference call to review > these editorial > >> >> > >comments? I > >> >> > >>>>>>> like to re-emphasize that we should not accept anymore > >> technical >> ballot > >> >> > >>>>>>> comments for PN-4732 at this point; however, we > should flush > >> out >> > >>editorial > >> >> > >>>>>>> inconsistency and mistakes from PN-4732. > >> >> > >>>>>>> > >> >> > >>>>>>> Regards, > >> >> > >>>>>>> > >> >> > >>>>>>> Raymond > >> >> > >>>>>>> > >> >> > >>>>>>> At 10:10 AM 5/9/00 -0700, Rajesh Bhalla wrote: > >> >> > >>>>>>> >Content-Type: text/plain; charset="us-ascii" > >> >> > >>>>>>> >X-MIME-Autoconverted: from 8bit to quoted-printable by > >> >> > >>>>>>> >sj-msg-core-2.cisco.com id KAA00480 > >> >> > >>>>>>> > > >> >> > >>>>>>> >Hello All, > >> >> > >>>>>>> > > >> >> > >>>>>>> > From further implementation experience, we stumbled on > >> another >> 'typo' > >> >> > >>>>>>> in > >> >> > >>>>>>> > PN-4732. The typo results in a conflict in the > assignment of > >> >the >> > >>'Type' > >> >> > >>>>>>> value > >> >> > >>>>>>> > > >> >> > >>>>>>> > to one of the Airlink Record Specific Parameters in the > >> >horizontal > >> >> > >>>>>>> Table-5 > >> >> > >>>>>>> > in Section 9.4. This typo is in addition to two other > >> >comments that > >> >> I > >> >> > >>>>>>> had > >> >> > >>>>>>> > forwarded to the group earlier on May 2nd. > >> >> > >>>>>>> > > >> >> > >>>>>>> > Below is the consolidated list of the THREE > comments with the > >> >> > >request >> > >>>>>>> > that these be addressed at the upcoming > >> conference call >tomorrow. > >> >> > >>>>>>> > > >> >> > >>>>>>> > 1. 'y1 Airlink Record Type' has been > assigned a value of > >> >'26/40'. > >> >> > >>>>>>> Value > >> >> > >>>>>>> >'26/40' > >> >> > >>>>>>> > is already used for parameter 'C2 > Correlation ID'. The > >> >> > >proposal is > >> >> > >>>>>>> to > >> >> > >>>>>>> >assign > >> >> > >>>>>>> > value of '26/44'(or some other > non-conflicting value) to > >> the >> > >>>>>>> parameter > >> >> > >>>>>>> >'y1'. > >> >> > >>>>>>> > > >> >> > >>>>>>> > 2. The second comment relates to some typos > regards the > >> 'y1' >type > >> >> > >>>>>>> airlink > >> >> > >>>>>>> > parameters. Table 5, section 9.4 specifies the > >> enumerated >> > >values > >> >> > >>>>>>> > for various airlink events as: > >> >> > >>>>>>> > > >> >> > >>>>>>> > y1= 1 (Connection Setup) > >> >> > >>>>>>> > y1= 2 (Active Start) > >> >> > >>>>>>> > y1= 3 (Active Stop) > >> >> > >>>>>>> > y1= 4 (SDB Record) > >> >> > >>>>>>> > > >> >> > >>>>>>> > We need to modify the Airlink Record Types in the > >> >tables in > >> >> > >>>>>>> sections > >> >> > >>>>>>> > 9.2.2, 9.2.3 and 9.2.4 also to account > for the removal > >> >of >> the > >> >> > >>>>>>> >Connection > >> >> > >>>>>>> > Release type airlink record. > >> >> > >>>>>>> > > >> >> > >>>>>>> > 3. The third comment relates to the need for > address some > >> >details > >> >> on > >> >> > >>>>>>> > the SDB Airlink Record. Attached is a > proposal that > >> >contains > >> >> two > >> >> > >>>>>>> options > >> >> > >>>>>>> > > >> >> > >>>>>>> > for addressing the changes. Though two options are > >> >included, > >> >> we > >> >> > >>>>>>> prefer > >> >> > >>>>>>> > Option-1 as it uses fewer airlink parameters.. > >> >> > >>>>>>> > > >> >> > >>>>>>> > Again, we would appreciate that these comments be > >> addressed >at > >> >> the > >> >> > >>>>>>> > conference call tomorrow. > >> >> > >>>>>>> > > >> >> > >>>>>>> >Thanks > >> >> > >>>>>>> >Rajesh Bhalla > >> >> > >>>>>>> >Cisco Systems Inc. > >> >> > >>>>>>> > > >> >> > >>>>>>> > > >> >> > >>>>>>> > > >> >> > >>>>>>> > >> >> > >>>>>>> > >> >> > >>>>>>> --- > >> >> > >>>>>>> You are currently subscribed to tsgp as: > >> mmunson@mobilnet.gte.com >> > >>>>>>> > >> >> > >>>>>> > >> >> > >>>>>>--- > >> >> > >>>>>>You are currently subscribed to tsgp as: rhsu@qualcomm.com > >> >> > >>>>>> > >> >> > >>>>> > >> >> > >>>>> > >> >> > >>>>>--- > >> >> > >>>>>You are currently subscribed to tsgp as: rabhalla@cisco.com > >> >> > >>>>> > >> >> > >>>> > >> >> > >>>> > >> >> > >>>>--- > >> >> > >>>>You are currently subscribed to tsgp as: rhsu@qualcomm.com > >> >> > >>>> > >> >> > >>> > >> >> > >>> > >> >> > >>>--- > >> >> > >>>You are currently subscribed to tsgp as: gdommety@cisco.com > >> >> > >>> > >> >> > >>> > >> >> > >> > >> >> > >> > >> >> > >>--- > >> >> > >>You are currently subscribed to tsgp as: rhsu@qualcomm.com > >> >> > >> > >> >> > > > >> >> > > > >> >> > >--- > >> >> > >You are currently subscribed to tsgp as: gdommety@cisco.com > >> >> > > > >> >> > > > >> >> > > >> >> > > >> >> > --- > >> >> > You are currently subscribed to tsgp as: cdg014@email.mot.com > >> >> > >> >> > >> >> --- > >> >> You are currently subscribed to tsgp as: pcalhoun@eng.sun.com > >> >> > >> > > >> > > >> > > >> >--- > >> >You are currently subscribed to tsgp as: gdommety@cisco.com > >> > > >> > > >> > > > > > > > >--- > >You are currently subscribed to tsgp as: gdommety@cisco.com > > > > > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 25 10:07: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 KAA08766 for ; Thu, 25 May 2000 10:07:24 -0400 (EDT) Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BA60ECA0@standards.nortelnetworks.com>; Thu, 25 May 2000 9:58:08 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3388 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 25 May 2000 09:56:50 -0400 Received: from smtprich.nortel.com (47.100.129.12) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.23B03910@standards.nortelnetworks.com>; Thu, 25 May 2000 9:46:45 -0400 Received: from qhars002.nortel.com (actually zhars00t) by smtprich.nortel.com; Thu, 25 May 2000 08:45:43 -0500 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Thu, 25 May 2000 14:47:42 +0100 Received: from zsc4c002.corpwest.baynetworks.com (actually h0295.s86b1.BayNetworks.COM) by ertpg14e1.nortelnetworks.com; Thu, 25 May 2000 09:47:26 -0400 Received: from zbl6c008.corpeast.baynetworks.com ([132.245.205.58]) by zsc4c002.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LS8679B5; Thu, 25 May 2000 06:47:23 -0700 Received: from mitton (mitton.corpeast.baynetworks.com [132.245.145.106]) by zbl6c008.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LS9C8QBF; Thu, 25 May 2000 09:47:23 -0400 X-Sender: dmitton@ZBL6C008.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 References: <4.1.20000522175733.0201bb00@omega.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Orig: Message-ID: <4.2.2.20000525094017.00d09560@ZBL6C008.corpeast.baynetworks.com> Date: Thu, 25 May 2000 09:49:51 -0400 Reply-To: David Mitton Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: David Mitton Subject: Re: [MOBILE-IP] [tsgp] Re: Comments on PN-4732 -- MN-AAA Extension and FAC Draft X-To: gwz@cisco.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: At 02:18 PM 5/24/00 -0700, Glen Zorn wrote: >Gopal Dommety [mailto://gdommety@cisco.com] writes: > > > Pat, > > > > The reason I am concerned is that the optional MN-HA > > Authentication might work for DIAMETER > > but might not work for RADIUS. > >RADIUS is dead. It's not dead yet. In fact several "new" RADIUS RFCs should emerge from the Editor's queue any day now. (they are only several years old) ...which says something sorry about this process. While it's sometimes suggested that RADIUS be advanced to "Historic", RADIUS will not be dead until something _else_ prys it out of the ISPs fingers. At the moment, I'm not aware of a commercial Diameter server. Now that I've sent a message to this list, I have a question being new here; Has anyone written a draft on supporting Mobile-IP with RADIUS?? I have several non-ID proposals on the subject, but I haven't seen a public, practices documents. Dave. --------------------------------------------------------------- David Mitton ESN: 248-4570 Advisor, Nortel Networks 978-288-4570 Direct Carrier Packet Solutions, IP Mobility 978-288-3030 FAX Billerica, MA 01821 dmitton@nortelnetworks.com From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 25 10: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 KAA09639 for ; Thu, 25 May 2000 10:34:57 -0400 (EDT) Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.ADBAB770@standards.nortelnetworks.com>; Thu, 25 May 2000 10:26:25 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3478 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 25 May 2000 10:24:32 -0400 Received: from ietf.org (132.151.1.176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0510BA30@standards.nortelnetworks.com>; Thu, 25 May 2000 10:14:32 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09084; Thu, 25 May 2000 10:22:15 -0400 (EDT) Message-ID: <200005251422.KAA09084@ietf.org> Date: Thu, 25 May 2000 10:22:15 -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: Mobility Support in IPv6 to Proposed Standard To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM The IESG has received a request from the IP Routing for Wireless/Mobile Hosts Working Group to consider Mobility Support in IPv6 as a Proposed Standard. 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 June 8, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-12.txt From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 25 14:19: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 OAA16918 for ; Thu, 25 May 2000 14:19:26 -0400 (EDT) Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0C4A89E0@standards.nortelnetworks.com>; Thu, 25 May 2000 14:10:58 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3637 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 25 May 2000 14:09:44 -0400 Received: from paul-milea-jr (4.48.171.150) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.783A4AC0@standards.nortelnetworks.com>; Thu, 25 May 2000 13:59:40 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Thu, 25 May 2000 14:09:44 -0400 Reply-To: "Paul J. Milea jr." Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Paul J. Milea jr." Subject: [MOBILE-IP] Fiber Optic Cable needed immediateley ! To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM If this email has reached you by error please forgive the intrusion. Type "remove" in the subject line and hit send and I will promptlty remove you from any future mailings .Please accept my sincerest apology.I am very sorry if I have inconvenienced you in any way. Dear Sir(s),Ms.,Mrs., I have a client looking for a sizable quantity (688,964 ft.) of Fiber Optic Cable.It must be 24 Strand ,single mode and armored. The manufacturer at this point is not a great concern. If this is available from your company, please quote price and availabilty .i.e. FOB ,amounts available, payment arrangements etc. If more specifications are needed, they are available. I need a quotation promptly and the buyer is willing to contract to purchase all ,if it is located. THERE IS AN IMMEDIATE NEED FOR THIS PRODUCT. PLEASE CALL IF YOU HAVE IT OR CAN HELP LOCATE !!! (there would be a finders fee awarded if you locate this fiber) Please email quotes or questions. Also please feel free to call with any questions. Regards,Paul J. Milea jr. ph 315 374 1560, fax 315 463 4337 Thank you again for your time ! From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu May 25 16:06: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 QAA19518 for ; Thu, 25 May 2000 16:06:01 -0400 (EDT) Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EFB5CE20@standards.nortelnetworks.com>; Thu, 25 May 2000 15:57:32 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3743 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 25 May 2000 15:57:04 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.78DCCE80@standards.nortelnetworks.com>; Thu, 25 May 2000 15:47:03 -0400 Received: from attila.versiliaplanet.it (attila.versiliaplanet.it [212.48.161.129]) by hosaka.smallworks.com (8.9.1/8.9.1) with SMTP id OAA21273 for ; Thu, 25 May 2000 14:54:44 -0500 (CDT) Received: from ripe (unverified [216.78.229.12]) by attila.versiliaplanet.it (EMWAC SMTPRS 0.83) with SMTP id ; Thu, 25 May 2000 22:06:50 +0200 Message-ID: Date: Thu, 25 May 2000 22:06:50 +0200 Reply-To: michelle525@CCNMAIL.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: michelle525@CCNMAIL.COM Subject: [MOBILE-IP] $1 + your labor = $100 - $500 per sale X-To: mobile-ip@smallworks.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello, If you're interested in Earning $100 - $500 per sale, Then listen Up! Here's How... The Product.... Imagine coming 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! Now how many people do you think would LOVE seeing this when they look up from their beds at night? The Opportunity: How To Make $100 - $500 per sale Here's How YOU Make Money. 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 astounding masterpiece for $100 to $500! Talk about NICE PROFITS! And It Only Takes You An Hour Or Two! Whew! The Official Money-Making Opportunity of the Millenium! (Well... we 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 sale, Simply Email Us Back The Following Information To: Mailto:starbiz65@newmail.net Name: E-Mail: Phone: Street: City: State: ZIP or Postal Code: Country (available INTERNATIONALLY): Mailto:starbiz65@newmail.net And we'll send you the full details on How to Make $100 - $500 per sale, as well as pictures of these murals so you can see for yourself how breathtaking they are! Best regards, Michelle 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:unsubscribe523@newmail.net From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed May 31 17:56: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 RAA25764 for ; Wed, 31 May 2000 17:56:53 -0400 (EDT) Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4820C220@standards.nortelnetworks.com>; Wed, 31 May 2000 17:47:25 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0224 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 31 May 2000 17:46:00 -0400 Received: from pavilion (63.16.243.85) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AEE54500@standards.nortelnetworks.com>; Wed, 31 May 2000 17:35:59 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 31 May 2000 17:46:00 -0400 Reply-To: JERALD Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: JERALD Subject: [MOBILE-IP] THE $19.95 DO IT YOURSELF CREDIT REPAIR KIT To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM ARE YOU TIRED OF BEING TURNED DOWN FOR CREDIT? TAKE CHARGE OF YOUR FUTURE AND REPAIR YOUR CREDIT! FOR ONLY $19.95 YOU CAN GET AN EASY TO UNDERSTAND, DO IT YOURSELF CREDIT REPAIR MANUAL!!!!!!!! ORDER AT HTTP:// WWW.MYCREDITREPAIRKIT.COM DON'T PAY PEOPLE THOUSANDS TO DO IT FOR YOU!!!! EVERYONE CAN BENEFIT FROM THIS INFORMATION!! FOR MORE INFO GO TO HTTP://WWW.MYCREDITREPAIRKIT.COM THANKS AND GOOD LUCK!!!!!!!!!!!!!! JERALD AAACREDIT_2000@YAHOO.COM This message is sent in compliance of the new e-mail bill: SECTION 301. Per Section 301, Paragraph (a)(2)(C) of S. 1618, http://www.senate.gov/~murkowski/commercialemail/S771index.html Further transmissions to you by the sender of this email may be stopped at no cost to you by sending a reply to this email address with the word "remove" in the subject line. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed May 31 20:59: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 UAA28868 for ; Wed, 31 May 2000 20:59:53 -0400 (EDT) Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0A3308A0@standards.nortelnetworks.com>; Wed, 31 May 2000 20:51:48 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0373 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 31 May 2000 20:49:57 -0400 Received: from webmail2.hansolm.com (210.112.10.141) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.61B87FD0@standards.nortelnetworks.com>; Wed, 31 May 2000 20:39:56 -0400 Received: from ns ([210.112.7.7]) by webmail2.hansolm.com with Microsoft SMTPSVC(5.5.1877.197.19); Thu, 1 Jun 2000 09:43:09 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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: <003101bfcb63$20812a80$5c12060a@hansol.co.kr> Date: Thu, 1 Jun 2000 09:48:39 +0900 Reply-To: Jiwoong Lee Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Jiwoong Lee Subject: [MOBILE-IP] State transition Diagram of Mobile IP To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id UAA28868 Dear All I'm looking for a paper that describes the whole state machine and state transition diagram of current Mobile IPv4. Would you please recommend one for me ? Thank you, Jiwoong Lee From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed May 31 21:07: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 VAA29018 for ; Wed, 31 May 2000 21:07:33 -0400 (EDT) Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.04BBFF20@standards.nortelnetworks.com>; Wed, 31 May 2000 20:58:49 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0495 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 31 May 2000 20:57:42 -0400 Received: from catarina.usc.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DC6ACC90@standards.nortelnetworks.com>; Wed, 31 May 2000 20:57:41 -0400 Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id SAA88262; Wed, 31 May 2000 18:05:45 -0700 (PDT) Received: from localhost (meeta@localhost) by rumi.usc.edu (8.9.3/8.9.3) with ESMTP id SAA57627; Wed, 31 May 2000 18:05:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Wed, 31 May 2000 18:05:45 -0700 Reply-To: Meeta Sharma Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Meeta Sharma Subject: Re: [MOBILE-IP] State transition Diagram of Mobile IP X-To: Jiwoong Lee To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <003101bfcb63$20812a80$5c12060a@hansol.co.kr> hi, I have done some modeling for Mobile IP, interms of finite state machine, but am not aware of any paper stating the state machine as such. Thanks, Meeta On Thu, 1 Jun 2000, Jiwoong Lee wrote: > Dear All > > I'm looking for a paper that describes the whole state machine and state > > transition diagram of current Mobile IPv4. > > Would you please recommend one for me ? > > Thank you, > > Jiwoong Lee > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed May 31 21:31: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 VAA29343 for ; Wed, 31 May 2000 21:31:32 -0400 (EDT) Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.615E9140@standards.nortelnetworks.com>; Wed, 31 May 2000 21:22:53 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0560 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 31 May 2000 21:21:43 -0400 Received: from ms.hansol.co.kr (203.235.136.4) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.374F8210@standards.nortelnetworks.com>; Wed, 31 May 2000 21:21:42 -0400 Received: from ns ([210.112.7.7]) by ms.hansol.co.kr (8.9.3/8.9.3) with SMTP id KAA11806 for ; Thu, 1 Jun 2000 10:29:29 +0900 References: 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.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: <002b01bfcb68$f5446200$d012060a@hansol.co.kr> Date: Thu, 1 Jun 2000 10:29:53 +0900 Reply-To: "Lee, Jiwoong" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Lee, Jiwoong" Subject: Re: [MOBILE-IP] State transition Diagram of Mobile IP To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Dear Meeta Could you please release your Mobile IP FSM in public ? I'll refer to that in an official way. If it has not gone public yet, I'll refer to it as an interim result. Regards, Jiwoong Lee ----- Original Message ----- From: Meeta Sharma To: Sent: Thursday, June 01, 2000 10:05 AM Subject: Re: [MOBILE-IP] State transition Diagram of Mobile IP > hi, > > I have done some modeling for Mobile IP, interms of finite state machine, > but am not aware of any paper stating the state machine as such. > > Thanks, > Meeta > > On Thu, 1 Jun 2000, Jiwoong Lee wrote: > > > Dear All > > > > I'm looking for a paper that describes the whole state machine and state > > > > transition diagram of current Mobile IPv4. > > > > Would you please recommend one for me ? > > > > Thank you, > > > > Jiwoong Lee > > >