From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Jul 1 02:18:07 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17010 for ; Sat, 1 Jul 2000 02:18:06 -0400 (EDT) Received: from standards (47.234.32.16:1914) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7A0D4@standards.nortelnetworks.com>; Sat, 1 Jul 2000 2:07:58 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2918 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 1 Jul 2000 02:07:58 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7A0D3@standards.nortelnetworks.com>; Sat, 1 Jul 2000 1:57:58 -0400 Received: from envh01.ysgear.co.jp (hi051.enshu-net.or.jp [210.154.119.51]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id BAA26701 for ; Sat, 1 Jul 2000 01:07:31 -0500 (CDT) Received: from [207.193.0.193] by envh01.ysgear.co.jp (Post.Office MTA v3.1.2J release 205-101-J ID# 0-0U10L2S100) with SMTP id AAA182; Sat, 1 Jul 2000 15:07:01 +0900 X-Priority: 3 X-MSMail-Priority: Normal Errors-To: cybrmrktg@winning.com Message-ID: <00005771382b$00002d8e$000049c1@taffar (pool-209-138-205-92-dlls.grid.net [219.138.205.92]) by smtp7.atl.mindspring.net (ts029d25.nil-ny.concentric.net [216.173.24.181])> Date: Sat, 1 Jul 2000 01:05:53 -0500 Reply-To: rlp53633@interserve.com.hk Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: rlp53633@interserve.com.hk Subject: [MOBILE-IP] It is now here...Flat Rate Long Distance-Unlimited Calls 18881 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM It's Finally Here! We have all been waiting for this one! FLAT RATE UNLIMITED LONG DISTANCE CALLING! CALL ALL-YOU-WANT! 24 hrs/day, 7 days a week! You are already familiar with the Fiber-Optic technology of the three service providers for our program. Over 90% of the long distance traffic is already handled by these companies, in fact, you are probably already a customer of one of them! So, you already know the quality! We are a retail resell vendor of the largest long distance networks in the U.S. through which our Flat Rate Long Distance service is now being offered. Others have tried to provide a flat rate long distance service via Internet Telephony or Prepaid Phone Card Platform but these platforms do not give the ability to create a line connection with the clarity of standard fiber-optic technology. Fixed Monthly Flat Rate Clear, commercial grade sound quality Not VOIP or internet calling No Hidden Charges! No more guessing about your monthly phone bill! No need to switch carriers with one of our plans! In & Out of State Calling! NO per-call time limits! NO need to dial a pin number! Residential & Commercial plans to choose from: 24/7 Residential $59.95 All you can talk! Call anytime from a Dedicated Registered Phone 24 hours a day, 7 days a week, 365 days a year to 100% (including INTRAstate) of the phones in the Continental USA Unlimited 24/7 (not for business use) Commercial/HBB Plan 1.) 3900 min - 1 + Dialing -- $79.95/line plus taxes 3-way calling, faxing, conference calls 5.9¢/min. spill over Plan 2.) 5000 min - 1 + Dialing -- $99.95/line plus taxes 24/7, INTERstate calling, 48 continental states 3-way calling, faxing, conference calls 5.9¢/min. spill over Call Us TODAY and get all the details for yourself! 1-800-242-0363....Ext 2828 Coming soon! International unlimited residential plan! \|||/ (. .) ---oOoo--------------- (REMOVAL INSTRUCTIONS) This is a one-time mailing, done by an independent marketing company. We respect your online privacy and apologize if you have received this message in error. We do respect our remove lists! Please do not use the reply to this e-mail, e-mail reply cannot be read! If you would like to be removed from our mailing list just click below and send us an remove request email. Please be aware that any disruption to our remove link prevents those that want to be removed from our database from being removed. mailto:nadapromos358@usa.com?subject=pleaseremovelngdstpromo It's Finally Here! We have all been waiting for this one! From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Jul 1 14:54:40 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21602 for ; Sat, 1 Jul 2000 14:54:40 -0400 (EDT) Received: from standards (47.234.32.16:4632) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7A2DA@standards.nortelnetworks.com>; Sat, 1 Jul 2000 14:44:12 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3614 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 1 Jul 2000 14:44:12 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7A2D6@standards.nortelnetworks.com>; Sat, 1 Jul 2000 14:34:12 -0400 Received: from aomail.asahiorikomi.co.jp (aomail.asaori.co.jp [210.225.81.14]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id NAA00027 for ; Sat, 1 Jul 2000 13:43:50 -0500 (CDT) Received: from [195.179.91.129] ([207.193.2.26]) by aomail.asahiorikomi.co.jp (Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-45575U200L2S100) with SMTP id ABE257; Sun, 2 Jul 2000 03:17:22 +0900 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Errors-To: cybrmrktg@winning.com Message-ID: <000036764f96$000024fc$00007668@195.143.58.206> Date: Sat, 1 Jul 2000 13:10:57 -0500 Reply-To: hrt355@singnet.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: hrt355@singnet.com Subject: [MOBILE-IP] Your Own Pro Website For Your Business 30312 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: quoted-printable Free Web Site Promotion!

FREE Professional 6 Page Website value= d at $2000!

Includes the following and more!
FREE 6 Page Professional = Web Site
FREE Placement of Graphic Images and Links
FREE Secure Server
FREE Registration of your Domain Name
FREE Color Banner Ad
FREE Email account w/6 aliases
FREE FTP Access

Our Webmasters will build you a
FREE Professional 6 Page = Website valued at $2000!
Custom designed for you and tailored to your business needs
with your logo, photos, order forms, content, graphics, artwork etc.

No tricks, No gimmicks, No sales pitches.
We can provide your business with just about
everything you need for a successful and profitable
prescence on the internet. Simply pay a modest price for
state of the art hosting on our high speed secure servers-
Everything Else is FREE...YOU $AVE BIG MONEY!

Our FREE Professional 6 P= age Website valued at $2000
is the easiest, fastest, most effective way for your business
to join the worldwide web community and the global eceonomy!
Just imagine, you could take an order from anywhere in the world!

We encourage you to respond quickly! Limited Availability!
Reservations are currently being taken for the first
40 companies that respond within 72 hours!

TWELVE GOOD REASONS FOR DEVELOPING A WEB SITE:
*Your competition is probably already on the web.
*More cost effective than newspaper, radio, billboard, or television adv= ertising.
*Provides convenient, 24 hour, 7 day a week, centralized information acc= ess.
*Visibility to tens of millions of people. (with average annual household= incomes of $65,000)
*Increases productivity-reduced expenses.
*Improves service to new and old customers.
*Conveys a professional worldwide image of your company.
*Reduces workload for your staff.
*For a small investment, it levels the playing field with larger companies=
*The internet is where consumers now look to have their product needs met.=
*Internet sales/marketing are catapulting forward daily at an astounding r= ate!
*The internet is where thousands of fortunes will be made in the next deca= de.

All you need to do is fill out the form below and e-mail
us your request by clicking the "I Authorize" Button.
We will contact you by phone just as soon as we can. =
*Requests without phone number and required
info will NOT be processed.

For Continental US Residents = Only!!!

Full Name

(Required)

Address

(Required)

City

(Required)

State

(Required)

Zip Code

(Required)

Phone Number

(Required)

Fax Number

(Optional)

Best Time To Call

(Optional)

EMail Address

(Optional)xxxxx= xxxxxx
 
PLEASE CLICK ONE TIME ONLY---IT MAY TAKE UP TO 30 SECONDS
Your email address will be held private for in house use only.
We will not release your email address to any other party.


If you wish to be removed, please type in your email
address in the above remove box and click the remove button.

<= SCRIPT LANGUAGE=3D"JavaScript1.1">

From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Jul 1 22:56: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 WAA25369 for ; Sat, 1 Jul 2000 22:55:59 -0400 (EDT) Received: from standards (47.234.32.16:4806) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7A393@standards.nortelnetworks.com>; Sat, 1 Jul 2000 22:45:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3859 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 1 Jul 2000 22:45:52 -0400 Received: from email-broadcast.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7A390@standards.nortelnetworks.com>; Sat, 1 Jul 2000 22:35:52 -0400 Received: from spysguidesnet12@rocketmail.com by spysguidesnet13@rocketmail.com (8.8.5/8.6.5) with SMTP id GAA05225 for ; Sat, 01 Jul 2000 20:15:34 -0600 (EST) Message-ID: <200007020238.TAA02881@email-broadcast.com> Date: Sat, 1 Jul 2000 20:15:34 EST Reply-To: spysguidesnet12@ROCKETMAIL.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: spysguidesnet12@ROCKETMAIL.COM Subject: [MOBILE-IP] INTERNET SPY GUIDE finds info! X-To: spysguidesnet13@rocketmail.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM READY TO KNOW? CONFIDENTIAL! The SOFTWARE They Want BANNED In all 50 STATES. Why? Because these secrets were never intended to reach your eyes... Get the facts on anyone! Locate Missing Persons, find Lost Relatives, obtain Addresses and Phone Numbers of old school friends, even Skip Trace Dead Beat Spouses. This is not a Private Investigator, but a sophisticated SOFTWARE program DESIGNED to automatically CRACK YOUR CASE with links to thousands of Public Record databases. Find out SECRETS about your relatives, friends, enemies, and everyone else! Even your spouse! With the New, INTERNET SPY AND YOU! It's absolutely astounding! Here's what you can learn. License plate number! Get anyone's name and address with just a license plate number! (Find that girl you met in traffic!) Driving record! Get anyone's driving record! Social security number! Trace anyone by social security number! Address! Get anyone's address with just a name! Unlisted phone numbers! Get anyone's phone number with just a name even unlisted numbers! Locate! Long lost friends, relatives, a past lover who broke your heart! E-mail! Send anonymous e-mail completely untraceable! Dirty secrets! Discover dirty secrets your in-laws don't want you to know! Investigate anyone! Use the sources that private investigators use (all on the Internet) secretly! Ex-spouse! Learn how to get information on an ex-spouse that will help you win in court! (Dig up old skeletons)! Criminal search Background check! Find out about your daughter's boyfriend! Find out! If you are being investigated! Neighbors! Learn all about your mysterious neighbors! Find out what they have to hide! People you work with! Be astonished by what you'll learn about people you work with! Education verification! Did he really graduate college? Find out! Internet Spy and You! Software will help you discover ANYTHING about anyone, with clickable hyperlinks and no typing in Internet addresses! Just insert the floppy disk and Go! You will be shocked and amazed by the secrets that can be discovered about absolutely everyone! Find out the secrets they don't want you to know! About others, about yourself! It's INCREDIBLE what you can find out using Internet Spy and You and the Internet! You'll be riveted to your computer screen! Get the software they're trying to ban! Before it's too late! LIMITED TIME OFFER ORDER TODAY! Only $24.95 We will RUSH YOU our Internet Spy and You SOFTWARE so you can begin discovering all the secrets you ever wanted to know! You can Know EVERYTHING about ANYONE with our Internet Spy and You Software. Works with all browsers and all versions of AOL! ORDER TODAY. SEND ONLY $24.95 US CASH, CHECK, OR CREDIT CARD (you may also send one of your own address labels for accuracy if you have one). Foreign money orders must be payable on a US BANK AND IN US FUNDS! NO EXCEPTIONS! DON'T WAIT TO GET STARTED...It's as easy as 1, 2, 3. STEP 1 - Print the order form text below. STEP 2 - Type or print your order information into the order form section. STEP 3 - Mail order form and payment to the address below. Send to: INFORMATION PLUS PO BOX 9889 PCBEACH, FL 32417 Name: ________________________________________ Address: ________________________________________ City/State/Zip: ______________________________________ FOR CREDIT CARD ORDERS ONLY! Account Number: ____________________________________ Exp. Date: ________________________ DISCLAIMER: The seller of this powerful software resource will not be held responsible for how the purchaser chooses to use it's resources. To be removed from our mailing list midwest12@dcemail.com and put remove in the subject. Thank you From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jul 3 07:53:17 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29709 for ; Mon, 3 Jul 2000 07:53:16 -0400 (EDT) Received: from standards (47.234.32.16:1037) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7A708@standards.nortelnetworks.com>; Mon, 3 Jul 2000 7:42:43 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5028 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 3 Jul 2000 07:42:43 -0400 Received: from sonne.darmstadt.gmd.de by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7A707@standards.nortelnetworks.com>; Mon, 3 Jul 2000 7:42:40 -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 NAA07570; Mon, 3 Jul 2000 13:51:35 +0200 (MET DST) X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: de,en,it MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39607DD5.7D4AF77F@darmstadt.gmd.de> Date: Mon, 3 Jul 2000 13:49:41 +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] begginers question X-To: Noam Gonen - Israel To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Noam Gonen - Israel wrote: > > Hi, > Where does one find the required stuff/documentation for a beginners lecture > on IP & cellulars ? > I mean the required stuff to make a bottom-up acquaintance with how these > two sectors "meet" and work it from there . (not straghit into FAs, and > PDSNs etc. but more structured) > > Appologies for the "beginner" tone of the question, yet if one shall not > ask..... > > Noam Gonnen > Gilat Satellite Networks LTD. > Direct : 972-4-9939330 > > ---------------------------------------------------------------------------- > ---------------- Noam, As far as I know, there is not yet a "complete" lecture on the topic in question. I tried to address it in my lecture "mobility in communication" last winter, but this is still very sketchy (and in German), see http://www.darmstadt.gmd.de/mobile/teaching/courses/mobinkom/3Vermittlung.pdf . English translation is on the way and will (has to!) be complete in September. The colleagues in Finland are heavily working on the topic, see http://www.cs.hut.fi/Research/Dynamics/ But I don't know of any lecture there. I'm convinced that, if a "more structured" (abstract) approach existed, work on UMTS ("IP to the base station") would be much easier. Hence, I think your question is by no means a beginner's question. Wolfgang -- Wolfgang Schoenfeld, GMD-IPSI, +49-6151-869-865 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jul 3 10:18:28 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02434 for ; Mon, 3 Jul 2000 10:18:28 -0400 (EDT) Received: from standards (47.234.32.16:4730) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7A7B7@standards.nortelnetworks.com>; Mon, 3 Jul 2000 10:08:09 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5259 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 3 Jul 2000 10:08:09 -0400 Received: from mail0.u-aizu.ac.jp by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7A7B6@standards.nortelnetworks.com>; Mon, 3 Jul 2000 10:08:08 -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 XAA19634; Mon, 3 Jul 2000 23:17:38 +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 XAA18638; Mon, 3 Jul 2000 23:17:37 +0900 (JST) X-Mailer: Mozilla 4.7 [en_jp] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: multipart/alternative; boundary="------------0077B70F7EFE9D3C9A962AF3" Message-ID: <3960A080.2E762218@u-aizu.ac.jp> Date: Mon, 3 Jul 2000 23:17:36 +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] beginners question X-To: Noam Gonen - Israel To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --------------0077B70F7EFE9D3C9A962AF3 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Hello, Just today I posted the handouts of the tutorial entitled Mobile IP in Cellular Networks that I presented at IPCN 2000 that was held on May 23/ 26, 2000 in Paris, France on my homepage at: http://www.u-aizu.ac.jp/~sarikaya/ just follow the recent presentations link (or presentation.html). It just may help you to start out. Have a great summer everyone! -- Behcet Sarikaya Computer Communications Lab. The University of Aizu Tsuruga, Ikki-machi, Aizu-wakamatsu City Fukushima, 965-8580 Japan Tel. +81-242-37-2559 Fax. +81-242-37-2742 Home page: http://www.u-aizu.ac.jp/~sarikaya/ email: sarikaya@u-aizu.ac.jp --------------0077B70F7EFE9D3C9A962AF3 Content-Type: text/html; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Hello,
  Just today I posted the handouts of the tutorial entitled
Mobile IP in Cellular Networks
that I presented at IPCN 2000 that was held
on May 23/ 26, 2000 in Paris, France on my homepage at:
http://www.u-aizu.ac.jp/~sarikaya/
just follow the recent presentations link (or presentation.html).
 It just may help you to start out.

Have a great summer everyone! 

-- 
Behcet Sarikaya
Computer Communications Lab.
The University of Aizu
Tsuruga, Ikki-machi, Aizu-wakamatsu City
Fukushima, 965-8580 Japan
Tel. +81-242-37-2559 Fax. +81-242-37-2742 
Home page:  http://www.u-aizu.ac.jp/~sarikaya/
email: sarikaya@u-aizu.ac.jp
  --------------0077B70F7EFE9D3C9A962AF3-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jul 3 16:28:58 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07399 for ; Mon, 3 Jul 2000 16:28:58 -0400 (EDT) Received: from standards (47.234.32.16:3971) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7A8B5@standards.nortelnetworks.com>; Mon, 3 Jul 2000 16:18:44 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5599 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 3 Jul 2000 16:18:43 -0400 Received: from taurus.cs.albany.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7A8B0@standards.nortelnetworks.com>; Mon, 3 Jul 2000 16:08:43 -0400 Received: from euler.cs.albany.edu (euler.cs.albany.edu [169.226.2.43]) by taurus.cs.albany.edu (8.9.3+Sun/8.9.1) with ESMTP id QAA13639; Mon, 3 Jul 2000 16:16:33 -0400 (EDT) Received: (from ravi@localhost) by euler.cs.albany.edu (SMI-8.6/CLI2) id QAA15531; Mon, 3 Jul 2000 16:16:31 -0400 Message-ID: <200007032016.QAA15531@euler.cs.albany.edu> Date: Mon, 3 Jul 2000 16:16:31 -0400 Reply-To: "S.S.Ravi" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "S.S.Ravi" Subject: [MOBILE-IP] DIAL M Workshop (Early Registration Deadline: July 15, 2000) X-To: dmanet@zpr.uni-koeln.de, im-net-digest@iwr.uni-heidelberg.de, itc@ieee.org, manet@itd.nrl.navy.mil, mobility@media.mit.edu, opt-net@zib.de, orcs-l@listserv.okstate.edu, podc-post@research.telcordia.com, tccc@ieee.org, theorynt@listserv.nodak.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM CALL FOR PARTICIPATION 4th International Workshop on Discrete Algorithms and Methods for Mobile Computing & Communications (DIALM for Mobility) August 11, 2000 Boston, Massachusetts, USA In conjunction with ACM MobiCom 2000 Workshop URL : http://www.eecis.udel.edu/~elloyd/dialm.d/home.html EARLY REGISTRATION DEADLINE: July 15, 2000 SPONSORS: (a) National Science Foundation. (b) ACM SIGMOBILE (in cooperation with ACM SIGACT) (c) Basic and Applied Simulation Science Group (TSA-2) of Los Alamos National Laboratory. SCOPE: Mobile computing and communications devices such as portable phones, laptops and palmtops will have an enormous impact on our lifestyle over the next several decades. The introduction of mobility raises a number of new research issues. This workshop is devoted to discrete algorithms and methods in the context of mobile and wireless computing and communications. The workshop is intended to serve as a forum for open discussions and lively debate, and to foster cooperation among practitioners and theoreticians. The conference program includes three invited talks and 11 contributed papers. The list of contributed papers and the presentation schedule are available through the workshop URL given above. REGISTRATION INFORMATION: DIAL M Workshop registration is being conducted in conjunction with the MobiCom 2000 conference registration. Please see the Mobicom 2000 home page (http://www.argreenhouse.com/mobicom2000) for registration and related information. STUDENT TRAVEL GRANTS: Students attending DIAL M may apply for Student Grants to defray a part of the cost of attending the workshop. Any student may apply (presenting a paper is NOT a prerequisite). For further information, please contact the DIAL M Program Chair Professor Errol Lloyd (elloyd@udel.edu). Funding for these grants is provided by the National Science Foundation. INVITED TALKS: (a) ``Data Structures for Mobile Data'', by Leonidas Guibas (Stanford University). (b) ``The Post-PC Era: It's about the New Services-Enabled Internet'', by Randy Katz (University of California, Berkeley). (c) ``Application of a Theory of Simulation to Models of Mobile Communication Systems'', by Chris Barrett (Los Alamos National Laboratory). PROGRAM CHAIR: Errol L. Lloyd Department of Computer and Information Sciences University of Delaware Newark, DE, USA Email: elloyd@udel.edu PROGRAM COMMITTEE Amotz Bar-Noy, AT&T Labs and Tel Aviv University, Israel Anthony Ephremides, University of Maryland, USA Aura Ganz, University of Massachusetts, USA Juraj Hromkovic, RWTH Aachen, Germany Bo Li, Hong Kong University of Science and Technology, Hong Kong Jason Yi-Bing Lin, National Chiao-Tung University, ROC Errol Lloyd, University of Delaware,USA -- Program Chair Madhav Marathe, Los Alamos National Lab Marina Papatriantafilou, Chalmers Univ. of Technology, Sweden Stephane Perennes, INRIA, France Cynthia Phillips, Sandia National Laboratories, USA Balaji Raghavachari, University of Texas at Dallas, USA S. S. Ravi, SUNY Albany, USA -- Publicity Chair Andrea Richa, Arizona State University, USA Aravind Srinivasan, Bell Labs, USA Martha Steenstrup, BBN, USA Subhash Suri, Washington University, USA Eli Upfal, Brown University, USA Peter Widmayer, ETH Zurich, Switzerland STEERING COMMITTEE Ian Akyildiz, Georgia Tech, USA Maurizio Bonuccelli, University of Pisa, Italy (Chair) Afonso Ferreira, CNRS - I3S - INRIA - Sophia Antipolis, France Arunabha Sen, Arizona State University, USA. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jul 3 19:45:58 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08431 for ; Mon, 3 Jul 2000 19:45:57 -0400 (EDT) Received: from standards (47.234.32.16:2863) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7A909@standards.nortelnetworks.com>; Mon, 3 Jul 2000 19:35:44 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5720 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 3 Jul 2000 19:35:44 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7A908@standards.nortelnetworks.com>; Mon, 3 Jul 2000 19:25:43 -0400 Received: from eagle.prod.itd.earthlink.net (eagle.prod.itd.earthlink.net [207.217.120.24]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id SAA14225; Mon, 3 Jul 2000 18:35:24 -0500 (CDT) Received: from 209.178.164.237 (pool0237.cvx7-bradley.dialup.earthlink.net [209.178.164.237]) by eagle.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with SMTP id QAA04515; Mon, 3 Jul 2000 16:35:06 -0700 (PDT) X-Priority: 3 X-MSMail-Priority: Normal Message-ID: <000011134e23$0000442b$00000ade@> Date: Mon, 3 Jul 2000 16:35:11 -0700 Reply-To: boliver577@HOTMAIL.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: boliver577@HOTMAIL.COM Subject: [MOBILE-IP] Complete Merchant Services 2782 X-To: Undisclosed.Recipients@earthlink.net To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Are you losing business and customers by not having your very own Web presence? Are you currently selling products in an *Auction House Environment* on the Internet? Are you losing business because you are unable to process credit cards and checks over the Internet? IF YOU ANSWERED *YES* TO THESE QUESTIONS, READ ON! Have Your Online Storefront Built or Build Your Own Site With the Following Features: *** E-Commerce - the ability to transact business on the Internet *** Web design - creating your own virtual storefront *** Web hosting - where your store is located on the Internet *** Shopping cart - calculates pricing for multiple product orders Secure Processing: Allows customers to pay with all major credit cards and checks directly from your Web site within 2-5 seconds. *YOU can be vacationing in Hawaii and STILL making money from your electronic storefront!* ******************************************************* Please reply to this message with your name, number and best time to call and we'll answer all of your questions, and help your build your own online presence. DOUBLE CLICK ON: mailto:cardservices1@mailcity.com?subject=interested ******************************************************* *** QUICK FACTS: - 161 million people are currently online - 510 million people are projected to be online by 2003 - Online shopping will account for $108 billion in sales in 2000, growing from $7.8 billion in 1998 - Online shopping will account for 6% of all U.S. retail sales by 2003, growing from 1% in 1998 This is your chance to have an online storefront with a fully-integrated shopping cart solution so that your customers can purchase many products from your site 24 hours a day, 7 days a week making money while you sleep! YOU have the opportunity to be your own boss, set your own hours and reap all the benefits of having an electronic business. BECOME A PART OF THE BIGGEST TRANSFER OF WEALTH SINCE THE INDUSTRIAL REVOLUTION! Here's what our customers have to say: I am a single mom, divorced less than one year ago, with three small children. I have no formal education or job experience. I was headed for the welfare rolls. You showed me how to build a business on the Internet and now I am making over $5,000 per month from my electronic store. I am so grateful, the Internet has changed my life. -CG, Idaho I was a security guard working for a large company for a $10.00 per hour wage that was just barely enough to provide for my family of five. I was laid off in February 1999 and did not know how to make ends meet. You all helped me create a business on the Internet. My e-store currently generates over $10,000 per month in revenue. It took me six months to make $10,000 at my old job! -JD, South Dakota At 72 years old, I was concerned that we would not have enough financial security for our remaining years. I just purchased a computer five months ago and became an Internet user three months ago. It is easy to make a profitable business on the Internet! In just two months, I have paid for my computer and I am already making enough money from my referral partnerships to cover all of my Internet business costs plus an extra $1,000 per month. Thanks for getting me up and running. -JMF, Arizona *** Do Not Waste Another Day! *** Our friendly and knowledgeable staff will answer any and all of your questions. There is no obligation to buy *ANYTHING* ******************************************************* Please reply to this message with your name, number and best time to call and we'll answer all of your questions, and help your build your own online presence. DOUBLE CLICK ON: mailto:cardservices1@mailcity.com?subject=interested ******************************************************* This email has been delivered to you by the OPT IN PLUS email delivery service. If you feel that this has reached you in error please DOUBLE CLICK ON mailto:remo31@beer.com?subject=unsubscribe We will insure that your email address is removed from our database immediately. Thank you for participating in OPT IN PLUS! We value your membership. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jul 4 22:55:42 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04196 for ; Tue, 4 Jul 2000 22:55:41 -0400 (EDT) Received: from standards (47.234.32.16:3071) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7AC74@standards.nortelnetworks.com>; Tue, 4 Jul 2000 22:45:09 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6876 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 4 Jul 2000 22:45:08 -0400 Received: from mcn.xidian.edu.cn by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7AC73@standards.nortelnetworks.com>; Tue, 4 Jul 2000 22:35:06 -0400 Received: from ns1 (jxli [192.168.1.37]) by mcn.xidian.edu.cn (8.9.3/8.8.7) with SMTP id KAA16404 for ; Wed, 5 Jul 2000 10:25:56 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002D_01BFE66E.1FB35260" 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: <003001bfe62b$11d1af40$2501a8c0@xidian.edu.cn> Date: Wed, 5 Jul 2000 10:45:24 +0800 Reply-To: jxli Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: jxli Subject: [MOBILE-IP] unsubscribe To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_002D_01BFE66E.1FB35260 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 dW5zdWJzY3JpYmUNCg== ------=_NextPart_000_002D_01BFE66E.1FB35260 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4yNjE0LjM1MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj51bnN1YnNjcmliZTwvRk9O VD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_002D_01BFE66E.1FB35260-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jul 5 12:15:41 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10149 for ; Wed, 5 Jul 2000 12:15:40 -0400 (EDT) Received: from standards (47.234.32.16:2009) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7AECF@standards.nortelnetworks.com>; Wed, 5 Jul 2000 12:05:07 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7638 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 5 Jul 2000 12:05:07 -0400 Received: from motgate.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7AEC6@standards.nortelnetworks.com>; Wed, 5 Jul 2000 11:55:06 -0400 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id JAA23409 for ; Wed, 5 Jul 2000 09:04:58 -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 JAA11071 for ; Wed, 5 Jul 2000 09:04:57 -0700 (MST)] Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2650.21) id ; Wed, 5 Jul 2000 11:04:57 -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, 5 Jul 2000 11:04:49 -0500 Reply-To: Roberts Phil-QA3445 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Roberts Phil-QA3445 Subject: [MOBILE-IP] my email address To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi, it's come to my attention that quite a few people may have a bad email address for me. Please note that my email address is qa3445@email.mot.com. This address is the address listed on the web page, but some of you may have something else through the addressing configuration of a previous email server that I used. Sorry about the mixup. Thanks, Phil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jul 5 13:37:30 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12675 for ; Wed, 5 Jul 2000 13:37:28 -0400 (EDT) Received: from standards (47.234.32.16:4127) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7AF83@standards.nortelnetworks.com>; Wed, 5 Jul 2000 13:27:06 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7856 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 5 Jul 2000 13:27:06 -0400 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7AF82@standards.nortelnetworks.com>; Wed, 5 Jul 2000 13:27:06 -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 e65Havs05145 for ; Wed, 5 Jul 2000 19:36:57 +0200 (MET DST) Received: from SMTP ([153.88.251.32]) by esealnt409.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1); Wed, 5 Jul 2000 19:36:57 +0200 Received: from esealnt172.ericsson.se ([130.100.184.165]) by 153.88.251.32 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 05 Jul 2000 17:36:56 0000 (GMT) Received: by esealnt172 with Internet Mail Service (5.5.2651.58) id ; Wed, 5 Jul 2000 19:36:18 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 05 Jul 2000 17:36:57.0030 (UTC) FILETIME=[9DC19660:01BFE6A7] Message-ID: <5F05C89FB2F8D211B6430008C791912703EA80CF@esealnt190> Date: Wed, 5 Jul 2000 19:36:55 +0200 Reply-To: "Karim El-Malki (ERA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Karim El-Malki (ERA)" Subject: [MOBILE-IP] Fast Handoffs (fast-handoffs and proactive-FA) To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello Pat and James I have read your proactive-FA-01 draft. This new version is quite different from v00 and now describes a similar hierarchical mechanism to the Fast Handoffs presented in Adelaide: draft-elmalki-soliman-hmipv4v6-00 (previously presented in Oslo as draft-elmalki-mobileip-fast-handoffs-01). This has undergone a few revisions and we think it is now in quite a stable state. I haven't seen any comparison or reference to it in your memo. Could you elaborate on the differences? If my understanding is correct, your approach requires a registration following L2 handoff (to a new FA) before the MN can resume communication. We have tried to avoid this added delay. Also, why did you choose to introduce a new message between RFA and GFA when there is the (Regional) Registration Request available? What is the advantage? MIP transparency to the MN should be maintained IMO. In our approach we have decided to maintain this and no new messages are used. Rgds, Karim P.S. The MIPv4 part of the draft presented in Adelaide has just been resubmitted as: draft-elmalki-mobileip-fast-handoffs-02 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jul 5 14:36:37 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13710 for ; Wed, 5 Jul 2000 14:36:35 -0400 (EDT) Received: from standards (47.234.32.16:1900) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B006@standards.nortelnetworks.com>; Wed, 5 Jul 2000 14:26:07 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8014 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 5 Jul 2000 14:26:07 -0400 Received: from qhars002.nortel.com (47.101.112.102:36464) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7AFFD@standards.nortelnetworks.com>; Wed, 5 Jul 2000 14:16:06 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Wed, 5 Jul 2000 19:22:52 +0100 Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch1.nortel.com; Wed, 5 Jul 2000 12:50:43 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) id <3F6D4GNL>; Wed, 5 Jul 2000 12:52:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFE6A9.D5F42BD6" Message-ID: Date: Wed, 5 Jul 2000 12:52:50 -0500 Reply-To: Glenn Morrow Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Glenn Morrow Subject: [MOBILE-IP] Security Questions for Mobility in IPv6 Drafts 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_01BFE6A9.D5F42BD6 Content-Type: text/plain Excuse me but can the binding update option be encrypted for security purposes? If not, do people feel it should be? If so, would IPv6 security have to be altered in some way or do people believe there should be some encryption that is option specific? ------_=_NextPart_001_01BFE6A9.D5F42BD6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Security Questions for Mobility in IPv6 Drafts

Excuse me but can the binding update = option be encrypted for security purposes?

If not, do people feel it should = be?

If so, would IPv6 security have to be = altered in some way or do people believe there should be some = encryption that is option specific?

------_=_NextPart_001_01BFE6A9.D5F42BD6-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jul 5 16:03: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 QAA15796 for ; Wed, 5 Jul 2000 16:03:25 -0400 (EDT) Received: from standards (47.234.32.16:1900) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B123@standards.nortelnetworks.com>; Wed, 5 Jul 2000 15:53:08 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8400 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 5 Jul 2000 15:53:08 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B122@standards.nortelnetworks.com>; Wed, 5 Jul 2000 15:53: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 OAA24011 for ; Wed, 5 Jul 2000 14:02:59 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA19405; Wed, 5 Jul 2000 13:02:56 -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 NAA03553; Wed, 5 Jul 2000 13:02:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: xKcoa/msKgMyXFpY6dkr2Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Message-ID: <200007052002.NAA03553@nasnfs.eng.sun.com> Date: Wed, 5 Jul 2000 13:06:53 -0700 Reply-To: James Kempf Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: James Kempf Subject: Re: [MOBILE-IP] Fast Handoffs (fast-handoffs and proactive-FA) X-To: Karim.El-Malki@ERA.ERICSSON.SE To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM >I have read your proactive-FA-01 draft. This new version >is quite different from v00 and now describes a similar >hierarchical mechanism to the Fast Handoffs presented >in Adelaide: draft-elmalki-soliman-hmipv4v6-00 (previously >presented in Oslo as draft-elmalki-mobileip-fast-handoffs-01). >This has undergone a few revisions and we think it is >now in quite a stable state. I haven't seen any comparison >or reference to it in your memo. Could you elaborate on the >differences? If my understanding is correct, your approach I haven't had a chance to read it. I will take a look at it. >requires a registration following L2 handoff (to a new FA) See below for more on this. >before the MN can resume communication. We have tried to >avoid this added delay. Also, why did you choose to introduce The MN starts getting packets as soon as the FA and GFA have set up the registration. There is no need for the MN to do any registration back to the HA because the GFA has not changed. >a new message between RFA and GFA when there is the >(Regional) Registration Request available? What is the >advantage? MIP transparency to the MN should be maintained >IMO. In our approach we have decided to maintain this and >no new messages are used. > I'll take a look and see if I can give you a more detailed answer. >Rgds, >Karim > >P.S. The MIPv4 part of the draft presented in Adelaide has >just been resubmitted as: draft-elmalki-mobileip-fast-handoffs-02 Regarding your statement about L2 handoff, there is additionally a need to do handoff when there is no L2 connection between the old and new RANs. I'm thinking about the CDMA hard handoff case here, in which there is no physical interconnection directly between the old and new RAN, and so the handoff must go through the L3 core (currently, this is done by involving the MSCs in handoff). This will, of necessity, involve communicating radio specific information across L3, channel parameters, current cell site, etc. We believe FA assisted handoff as we have outlined it will handle this case, with an extension to carry the radio specific information needed in order to have the new RAN set up the handoff. Does your proposal work for this as well? jak From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jul 5 17:32:02 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17500 for ; Wed, 5 Jul 2000 17:32:02 -0400 (EDT) Received: from standards (47.234.32.16:4074) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B1A7@standards.nortelnetworks.com>; Wed, 5 Jul 2000 17:21:49 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8572 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 5 Jul 2000 17:21:49 -0400 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B1A6@standards.nortelnetworks.com>; Wed, 5 Jul 2000 17:21:48 -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 e65LVZ646332; Wed, 5 Jul 2000 23:31:35 +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 XAA21925; Wed, 5 Jul 2000 23:31:29 +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 XAA46607; Wed, 5 Jul 2000 23:33:01 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-ID: <200007052133.XAA46607@givry.rennes.enst-bretagne.fr> Date: Wed, 5 Jul 2000 23:33:01 +0200 Reply-To: Francis.Dupont@ENST-BRETAGNE.FR Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] Security Questions for Mobility in IPv6 Drafts X-To: Glenn Morrow To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Wed, 05 Jul 2000 12:52:50 CDT. In your previous mail you wrote: Excuse me but can the binding update option be encrypted for security purposes? => it may but there is an issue if the home address option (which must be in the same packet) is encrypted because the security association should use it. If so, would IPv6 security have to be altered in some way or do people believe there should be some encryption that is option specific? => the only thing which has to be altered is the recommended order of IPv6 extension headers: ESP must be after the destination option header which carries the home address. The constraints are: - the home address option must be before any IPsec header (then tunnel mode doesn't work) - there must be an AH header with anti-replay The binding update can be after or before the home address option and any IPsec header, in the same or a different destination option header than the home address. Francis.Dupont@enst-bretagne.fr PS: for instance in my code (which works with IPsec and negociates SA with IKE) you get: IPv6 header: src = care-of address dst = home agent address Dest-option header: Binding Update Home Address (with the home address) Auth-header (with SPI for mobile home address -> home agent address SA) No-next-header (empty) From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jul 6 04:43:36 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09725 for ; Thu, 6 Jul 2000 04:43:35 -0400 (EDT) Received: from standards (47.234.32.16:2245) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B3F9@standards.nortelnetworks.com>; Thu, 6 Jul 2000 4:32:59 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9315 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Jul 2000 04:32:58 -0400 Received: from ish7.ericsson.com.au (203.61.155.111:42517) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B3F8@standards.nortelnetworks.com>; Thu, 6 Jul 2000 4:32:57 -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 SAA29373; Thu, 6 Jul 2000 18:41:32 +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 SAA27679; Thu, 6 Jul 2000 18:42:38 +1000 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id <3FW9RALN>; Thu, 6 Jul 2000 18:42:27 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFE726.1D3A0B60" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A5089EB0F3@eaubrnt018.epa.ericsson.se> Date: Thu, 6 Jul 2000 18:42:27 +1000 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] Security Questions for Mobility in IPv6 Drafts X-To: Francis Dupont 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_01BFE726.1D3A0B60 Content-Type: text/plain The binding update can be after or before the home address option and any IPsec header, in the same or a different destination option header than the home address. I think we should be careful with this case though, because if you place the BU after the ESP header it probably won't work through the translators. Which would impact the V6 <-> V4 communication. PS: for instance in my code (which works with IPsec and negociates SA with IKE) you get: IPv6 header: src = care-of address dst = home agent address Dest-option header: Binding Update Home Address (with the home address) Auth-header (with SPI for mobile home address -> home agent address SA) No-next-header (empty) Yes this is great but placing BU after the IPsec header will be a problem for the migration mechanisms available today. ------_=_NextPart_001_01BFE726.1D3A0B60 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] Security Questions for Mobility in IPv6 = Drafts

 
The binding update can be after or before the home = address option
and any IPsec header, in the same or a different = destination option
header than the home address.

I think we should be careful with this case though, = because if you place the BU after the ESP header it probably won't work = through the translators. Which would impact the V6 <-> V4 = communication.

PS: for instance in my code (which works with IPsec = and negociates
SA with IKE) you get:

IPv6 header:
 src =3D care-of address
 dst =3D home agent address
Dest-option header:
 Binding Update
 Home Address (with the home address)
Auth-header (with SPI for mobile home address -> = home agent address SA)
No-next-header (empty)

Yes this is great but placing BU after the IPsec = header will be a problem for the migration mechanisms available = today.

------_=_NextPart_001_01BFE726.1D3A0B60-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jul 6 05:24:41 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09995 for ; Thu, 6 Jul 2000 05:24:41 -0400 (EDT) Received: from standards (47.234.32.16:2245) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B44E@standards.nortelnetworks.com>; Thu, 6 Jul 2000 5:14:22 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9422 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Jul 2000 05:14:22 -0400 Received: from mcn.xidian.edu.cn by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B44D@standards.nortelnetworks.com>; Thu, 6 Jul 2000 5:12:51 -0400 Received: from ns1 (jxli [192.168.1.37]) by mcn.xidian.edu.cn (8.9.3/8.8.7) with SMTP id QAA18658; Thu, 6 Jul 2000 16:57:47 -0800 References: <5F05C89FB2F8D211B6430008C791912703EA80CF@esealnt190> 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: <001001bfe72a$f7bc03c0$2501a8c0@xidian.edu.cn> Date: Thu, 6 Jul 2000 17:17:10 +0800 Reply-To: jxli Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: jxli Subject: Re: [MOBILE-IP] Fast Handoffs (fast-handoffs and proactive-FA) X-To: "Karim El-Malki (ERA)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id FAA09995 unsubscribe ----- Original Message ----- From: Karim El-Malki (ERA) To: Sent: Thursday, July 06, 2000 1:36 AM Subject: [MOBILE-IP] Fast Handoffs (fast-handoffs and proactive-FA) > Hello Pat and James > > I have read your proactive-FA-01 draft. This new version > is quite different from v00 and now describes a similar > hierarchical mechanism to the Fast Handoffs presented > in Adelaide: draft-elmalki-soliman-hmipv4v6-00 (previously > presented in Oslo as draft-elmalki-mobileip-fast-handoffs-01). > This has undergone a few revisions and we think it is > now in quite a stable state. I haven't seen any comparison > or reference to it in your memo. Could you elaborate on the > differences? If my understanding is correct, your approach > requires a registration following L2 handoff (to a new FA) > before the MN can resume communication. We have tried to > avoid this added delay. Also, why did you choose to introduce > a new message between RFA and GFA when there is the > (Regional) Registration Request available? What is the > advantage? MIP transparency to the MN should be maintained > IMO. In our approach we have decided to maintain this and > no new messages are used. > > Rgds, > Karim > > P.S. The MIPv4 part of the draft presented in Adelaide has > just been resubmitted as: draft-elmalki-mobileip-fast-handoffs-02 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jul 6 05:31: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 FAA10106 for ; Thu, 6 Jul 2000 05:31:33 -0400 (EDT) Received: from standards (47.234.32.16:2245) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B47E@standards.nortelnetworks.com>; Thu, 6 Jul 2000 5:21:16 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9485 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Jul 2000 05:21:16 -0400 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B47D@standards.nortelnetworks.com>; Thu, 6 Jul 2000 5:21:15 -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 e669Uv614508; Thu, 6 Jul 2000 11:30:58 +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 LAA27602; Thu, 6 Jul 2000 11:30:57 +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 LAA48919; Thu, 6 Jul 2000 11:32:36 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-ID: <200007060932.LAA48919@givry.rennes.enst-bretagne.fr> Date: Thu, 6 Jul 2000 11:32:36 +0200 Reply-To: Francis.Dupont@ENST-BRETAGNE.FR Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] Security Questions for Mobility in IPv6 Drafts X-To: "Hesham Soliman (EPA)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Thu, 06 Jul 2000 18:42:27 +1000. <4B6BC00CD15FD2119E5F0008C7A419A5089EB0F3@eaubrnt018.epa.ericsson.se> In your previous mail you wrote: >The binding update can be after or before the home address option >and any IPsec header, in the same or a different destination option >header than the home address. I think we should be careful with this case though, because if you place the BU after the ESP header it probably won't work through the translators. Which would impact the V6 <-> V4 communication. => I don't believe in a V6 <-> V4 translator with mobility support (for instance IPv4 source-routing is not available in the today Internet for many reasons). Yes this is great but placing BU after the IPsec header will be a problem for the migration mechanisms available today. => it is a problem for firewalls too. I am in favour of a SHOULD (for BU in the same header than HA) but we can't sell a MUST here. I believe the I-D 12 doesn't specify this because to do the right thing is more simple... Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jul 6 05:42: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 FAA10182 for ; Thu, 6 Jul 2000 05:42:25 -0400 (EDT) Received: from standards (47.234.32.16:2245) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B4BB@standards.nortelnetworks.com>; Thu, 6 Jul 2000 5:32:08 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9559 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Jul 2000 05:32:08 -0400 Received: from mcn.xidian.edu.cn by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B4BA@standards.nortelnetworks.com>; Thu, 6 Jul 2000 5:32:05 -0400 Received: from ns1 (jxli [192.168.1.37]) by mcn.xidian.edu.cn (8.9.3/8.8.7) with SMTP id RAA18746 for ; Thu, 6 Jul 2000 17:23:07 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0038_01BFE771.8F1E1FA0" 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: <003b01bfe72e$810ba880$2501a8c0@xidian.edu.cn> Date: Thu, 6 Jul 2000 17:42:30 +0800 Reply-To: jxli Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: jxli Subject: [MOBILE-IP] To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_0038_01BFE771.8F1E1FA0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 dW5zdWJzY3JpYmUganhsaUBtY24ueGlkaWFuLmVkdS5jbg0K ------=_NextPart_000_0038_01BFE771.8F1E1FA0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4yNjE0LjM1MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj51bnN1YnNjcmliZSA8QSAN CmhyZWY9Im1haWx0bzpqeGxpQG1jbi54aWRpYW4uZWR1LmNuIj5qeGxpQG1jbi54aWRpYW4uZWR1 LmNuPC9BPjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0038_01BFE771.8F1E1FA0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jul 6 05:45:51 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10206 for ; Thu, 6 Jul 2000 05:45:51 -0400 (EDT) Received: from standards (47.234.32.16:2245) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B4E3@standards.nortelnetworks.com>; Thu, 6 Jul 2000 5:34:15 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9606 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Jul 2000 05:34:15 -0400 Received: from mcn.xidian.edu.cn by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B4E0@standards.nortelnetworks.com>; Thu, 6 Jul 2000 5:34:12 -0400 Received: from ns1 (jxli [192.168.1.37]) by mcn.xidian.edu.cn (8.9.3/8.8.7) with SMTP id RAA18731 for ; Thu, 6 Jul 2000 17:21:39 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01BFE771.5AF6AEE0" 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: <002501bfe72e$4ced5f80$2501a8c0@xidian.edu.cn> Date: Thu, 6 Jul 2000 17:41:03 +0800 Reply-To: jxli Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: jxli Subject: [MOBILE-IP] unsubscribe To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_0022_01BFE771.5AF6AEE0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQo= ------=_NextPart_000_0022_01BFE771.5AF6AEE0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4yNjE0LjM1MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPiZuYnNwOzwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0022_01BFE771.5AF6AEE0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jul 6 05:54:46 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10208 for ; Thu, 6 Jul 2000 05:45:51 -0400 (EDT) Received: from standards (47.234.32.16:2245) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B4E5@standards.nortelnetworks.com>; Thu, 6 Jul 2000 5:34:19 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9609 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Jul 2000 05:34:19 -0400 Received: from mcn.xidian.edu.cn by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B4B5@standards.nortelnetworks.com>; Thu, 6 Jul 2000 5:31:34 -0400 Received: from ns1 (jxli [192.168.1.37]) by mcn.xidian.edu.cn (8.9.3/8.8.7) with SMTP id RAA18738 for ; Thu, 6 Jul 2000 17:22:23 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002F_01BFE771.75382E00" 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: <003201bfe72e$672edea0$2501a8c0@xidian.edu.cn> Date: Thu, 6 Jul 2000 17:41:47 +0800 Reply-To: jxli Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: jxli Subject: [MOBILE-IP] To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_002F_01BFE771.75382E00 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 dW5zdWJzY3JpYmUNCg== ------=_NextPart_000_002F_01BFE771.75382E00 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4yNjE0LjM1MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj51bnN1YnNjcmliZTwvRk9O VD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_002F_01BFE771.75382E00-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jul 6 06:09: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 GAA10343 for ; Thu, 6 Jul 2000 06:09:23 -0400 (EDT) Received: from standards (47.234.32.16:2245) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B583@standards.nortelnetworks.com>; Thu, 6 Jul 2000 5:59:09 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9805 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Jul 2000 05:59:09 -0400 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B582@standards.nortelnetworks.com>; Thu, 6 Jul 2000 5:59:04 -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 e66A8qs23450 for ; Thu, 6 Jul 2000 12:08:52 +0200 (MET DST) Received: from SMTP ([153.88.251.32]) by esealnt409.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1); Thu, 6 Jul 2000 12:08:51 +0200 Received: from esealnt172.ericsson.se ([130.100.184.165]) by 153.88.251.32 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 06 Jul 2000 10:08:51 0000 (GMT) Received: by esealnt172 with Internet Mail Service (5.5.2651.58) id ; Thu, 6 Jul 2000 12:08:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 06 Jul 2000 10:08:51.0499 (UTC) FILETIME=[2F24DFB0:01BFE732] Message-ID: <5F05C89FB2F8D211B6430008C791912703EA80D0@esealnt190> Date: Thu, 6 Jul 2000 12:08:47 +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] Fast Handoffs (fast-handoffs and proactive-FA) To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello James > The MN starts getting packets as soon as the FA and GFA > have set up the registration. There is no need for the MN > to do any registration back to the HA because the GFA has > not changed. Of course this is true in Regional Registrations and therefore also in our approach. However my question is: following movement to a new RFA, the MN cannot resume communication until it has performed a regional registration with the new RFA. Are you saying that the previous RFA registers with the new RFA and the new RFA registers with the GFA without involving the MN? (using the BU and a "surrogate" registration which would be your new handoff request message) If so, wouldn't this break RFC2002 which requires the MN to send the Registration Request for a binding with a FA to be established? > > Regarding your statement about L2 handoff, there is additionally a > need to do handoff when there is no L2 connection between the old > and new RANs. I'm thinking about the CDMA hard handoff case here, > in which there is no physical interconnection directly between > the old and new RAN, and so the handoff must go through the > L3 core (currently, this is done by involving the MSCs in handoff). > This will, of necessity, involve communicating radio specific > information across L3, channel parameters, current cell site, etc. > We believe FA assisted handoff as we have outlined it will handle > this case, with an extension to carry the radio specific information > needed in order to have the new RAN set up the handoff. Does your > proposal work for this as well? > Our proposal describes a way to do an L3 Fast Handoff possibly utilising L2 functions/information. The lack of a soft-handoff does not mean there will not be a L2 interface to the radio/cellular specific part of the network (which exists today). From your mail above I conclude that you take a different assumption: L3 interface to the radio network. Am I correct? I think that radio-specific information should be left to L2 since it is an overkill to bring complex radio-technology-specific parameters up to L3. This is also due to the fact that every radio/cellular standard has its set of parameters. Only a few L2 parameters need to be made visible to L3 (e.g. handoff indication), possibly through some API to obtain the improved handoffs which we are aiming for. This is the assumption we should work with IMO, since it allows us to define a generic L3 (MIP) fast handoff method. Rgds, Karim From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jul 6 07:46: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 HAA12756 for ; Thu, 6 Jul 2000 07:46:01 -0400 (EDT) Received: from standards (47.234.32.16:3465) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B62B@standards.nortelnetworks.com>; Thu, 6 Jul 2000 7:35:37 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10019 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Jul 2000 07:35:37 -0400 Received: from ish7.ericsson.com.au (203.61.155.111:44090) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B62A@standards.nortelnetworks.com>; Thu, 6 Jul 2000 7:35:35 -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 VAA03626; Thu, 6 Jul 2000 21:44:08 +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 VAA06235; Thu, 6 Jul 2000 21:45:14 +1000 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id <3FW9RCAH>; Thu, 6 Jul 2000 21:45:03 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFE73F.9F5CD3C0" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A5089EB0F5@eaubrnt018.epa.ericsson.se> Date: Thu, 6 Jul 2000 21:45:03 +1000 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] Security Questions for Mobility in IPv6 Drafts X-To: Francis Dupont 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_01BFE73F.9F5CD3C0 Content-Type: text/plain I think we should be careful with this case though, because if you place the BU after the ESP header it probably won't work through the translators. Which would impact the V6 <-> V4 communication. => I don't believe in a V6 <-> V4 translator with mobility support (for instance IPv4 source-routing is not available in the today Internet for many reasons). I don't really understand what that means. Are you against translators that support mobility ? I'm not sure how source routing is related to this. Yes this is great but placing BU after the IPsec header will be a problem for the migration mechanisms available today. => it is a problem for firewalls too. I am in favour of a SHOULD (for BU in the same header than HA) but we can't sell a MUST here. I believe the I-D 12 doesn't specify this because to do the right thing is more simple... Maybe it should be stated in the relevant translator drafts instead of the MIPv6 draft ? We have a draft for NGTRANS and this is one of the topics addressed. Hopefully coming out soon. Cheers, Hesham ------_=_NextPart_001_01BFE73F.9F5CD3C0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] Security Questions for Mobility in IPv6 Drafts =

  
   I think we should be careful with this = case though, because if you
place the
   BU after the ESP header it probably = won't work through the
translators.
   Which would impact the V6 <-> V4 = communication.
  
=3D> I don't believe in a V6 <-> V4 = translator with mobility support
(for instance IPv4 source-routing is not available = in the today Internet
for many reasons).

I don't really understand what that means. Are you = against translators that support mobility ? I'm not sure how source = routing is related to this.

   Yes this is great but placing BU after = the IPsec header will be a
problem
   for the migration mechanisms available = today.
  
=3D> it is a problem for firewalls too. I am in = favour of a SHOULD (for
BU in the same header than HA) but we can't sell a = MUST here.
I believe the I-D 12 doesn't specify this because to = do the right thing
is more simple...

Maybe it should be stated in the relevant translator = drafts instead of the MIPv6 draft ? We have a draft for NGTRANS and = this is one of the topics addressed. Hopefully coming out = soon.

Cheers,
Hesham

------_=_NextPart_001_01BFE73F.9F5CD3C0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jul 6 09:47:47 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16331 for ; Thu, 6 Jul 2000 09:47:46 -0400 (EDT) Received: from standards (47.234.32.16:2122) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B69B@standards.nortelnetworks.com>; Thu, 6 Jul 2000 9:37:23 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10157 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Jul 2000 09:37:22 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B69A@standards.nortelnetworks.com>; Thu, 6 Jul 2000 9:37:22 -0400 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA16613 for ; Thu, 6 Jul 2000 07:47:15 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA28176; Thu, 6 Jul 2000 06:47:13 -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 GAA26387; Thu, 6 Jul 2000 06:47:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Thu, 6 Jul 2000 06:46:30 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: Re: [MOBILE-IP] Fast Handoffs (fast-handoffs and proactive-FA) X-To: "Karim El-Malki (ERA)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <5F05C89FB2F8D211B6430008C791912703EA80D0@esealnt190> > Hello James > > > The MN starts getting packets as soon as the FA and GFA > > have set up the registration. There is no need for the MN > > to do any registration back to the HA because the GFA has > > not changed. > > Of course this is true in Regional Registrations and therefore > also in our approach. However my question is: following > movement to a new RFA, the MN cannot resume communication > until it has performed a regional registration with the new RFA. > Are you saying that the previous RFA registers with the new RFA > and the new RFA registers with the GFA without involving the MN? > (using the BU and a "surrogate" registration which would be your > new handoff request message) If so, wouldn't this break RFC2002 > which requires the MN to send the Registration Request for a > binding with a FA to be established? No it doesn't break RFC 2002 anymore than Regional Registration Does. The main idea is to let the GFA be aware that the Mobile Node is entering a new cell, before MN registration occurs. This allows the network to adjust itself to provide service to the Mobile Node when it does enter the cell. The inverse requires that the Mobile Node detects it has entered a new cell by receiving (or soliciting) an advertisement, then proceed with the registration process. If we can provide temporary service while the registration process is occuring, then we have what I would call hard hand-off. There would be nearly no service impact (read packet loss) to the Mobile Node, especially if both the old and new cell overlap. Of course, the "temporary" registration is just that, temporary. We still require that the Mobile Node issues a regional registration within a specified amount of time. > > > > > Regarding your statement about L2 handoff, there is additionally a > > need to do handoff when there is no L2 connection between the old > > and new RANs. I'm thinking about the CDMA hard handoff case here, > > in which there is no physical interconnection directly between > > the old and new RAN, and so the handoff must go through the > > L3 core (currently, this is done by involving the MSCs in handoff). > > This will, of necessity, involve communicating radio specific > > information across L3, channel parameters, current cell site, etc. > > We believe FA assisted handoff as we have outlined it will handle > > this case, with an extension to carry the radio specific information > > needed in order to have the new RAN set up the handoff. Does your > > proposal work for this as well? > > > > Our proposal describes a way to do an L3 Fast Handoff possibly utilising > L2 functions/information. The lack of a soft-handoff does not mean > there will not be a L2 interface to the radio/cellular specific part > of the network (which exists today). From your mail above I conclude > that you take a different assumption: L3 interface to the radio network. > Am I correct? I think that radio-specific information should be left to > L2 since it is an overkill to bring complex radio-technology-specific > parameters up to L3. This is also due to the fact that every radio/cellular > standard has its set of parameters. Only a few L2 parameters need to be > made visible to L3 (e.g. handoff indication), possibly through some API > to obtain the improved handoffs which we are aiming for. This is the > assumption we should work with IMO, since it allows us to define a generic > L3 (MIP) fast handoff method. Well, James eluded to another draft, which isn't even published yet, and has no bearings on the pro-active FA draft. The proposal does not require that we pass along layer 2 information, and it would work just fine without it. Similarly to your proposal, we assume that the Foreign Agent will receive an indication from the layer 2 when the Mobile is entering a new cell. This draft does define a generic L3 fast handoff method. PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jul 6 10:23: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 KAA17019 for ; Thu, 6 Jul 2000 10:23:23 -0400 (EDT) Received: from standards (47.234.32.16:2122) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B6F7@standards.nortelnetworks.com>; Thu, 6 Jul 2000 10:12:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10270 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Jul 2000 10:12:55 -0400 Received: from scarlatti.cs.colostate.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B6F4@standards.nortelnetworks.com>; Thu, 6 Jul 2000 10:02:54 -0400 Received: (from gupta@localhost) by scarlatti.cs.colostate.edu (8.9.3/8.9.3) id IAA29750 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Jul 2000 08:12:48 -0600 (MDT) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <200007061412.IAA29750@scarlatti.cs.colostate.edu> Date: Thu, 6 Jul 2000 08:12:48 -0600 Reply-To: Sandeep Gupta Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Sandeep Gupta Subject: [MOBILE-IP] CFP PERVASIVE COMPUTING To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Call for Papers IEEE Personal Communications Magzine Special Issue on Pervasive Computing Publication Date: April 2001 http://www.cs.colostate.edu/~gupta/pervasiveComp-cfp.html SCOPE: The importance of pervasive or ubiquitous computing is rapidly increasing with the current trend towards universal presence of mobile computing, computer networks, and wireless communication in everyday life. The word pervasive means having power to spread throughout. Pervasive Computing essentially means to enable network devices to be aware of their surroundings and peers, and to be capable of providing services to and using services from peers effectively. The purpose of this special issue is to bring together the researchers and practitioners working on diverse aspects of this important emerging area in order to identify current status, fundamental issues, future problems and applications. We invite papers describing both theoretical and experimental research as well as experience reports and vision papers. Specific areas of interest include (but are not limited to): - Computing and communication Paradigms - Infrastructures Issues - Data Management Issues - Security and Authentication Issues - E-commerce - Service Issues: Interface and Semantics - Discovery/Advertisement and Applications - Resource Discovery and Utilization - Power Conservation - User Interfaces - Agents, Brokers - Information Sharing, Access, Storage and Management - Dynamic Context (e.g., time, space, and events) - Enabling Technologies Papers should report well-defined innovative ideas and practical results in real-life applications; they should include evaluations through analysis, simulation and experiments. Papers must be written in the IEEE Personal Communications style. Please submit your manuscript to either of the guest editors by September 30, 2000 : Wang-Chien Lee GTE Laboratories Inc. 40 Sylvan Road Waltham, MA 02451 Voice: (781) 466-3321 Fax: (781) 466-4387 wlee@gte.com Sandeep K. S. Gupta Dept. of Computer Science Colorado State University Ft. Collins, CO 80523 Voice: (970) 491-7323 Fax: (970) 491-2466 gupta@cs.colostate.edu Apratim Purakayastha IBM T.J. Watson Research Center 30 Saw Mill River Road Hawthorne, NY 10532 Voice: (914) 784-7004 Fax: (914) 784-3812 apu@us.ibm.com Pradip K. Srimani Dept. of Computer Science Colorado State University Ft. Collins, CO 80523 Voice: (970) 491-7097 Fax: (970) 491-2466 srimani@CS.ColoState.Edu Instructions for submitting papers: Papers should include a 200 word abstract and five to ten index words. Authors must follow the IEEE Personal Communications guidelines regarding the manuscript and its format. For more details, please refer to "Information for Authors" in each IEEE Personal Communications issue, or check guidelines. Electronic submissions are strongly encouraged. Schedule: Submission Deadline September 30, 2000 Acceptance Decision January 10, 2001 Final manuscript February 15, 2001 Publication April, 2001 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jul 6 10:26:48 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17095 for ; Thu, 6 Jul 2000 10:26:48 -0400 (EDT) Received: from standards (47.234.32.16:2122) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B722@standards.nortelnetworks.com>; Thu, 6 Jul 2000 10:16:11 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10327 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Jul 2000 10:16:11 -0400 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B721@standards.nortelnetworks.com>; Thu, 6 Jul 2000 10:16:11 -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 e66EQ4s19216 for ; Thu, 6 Jul 2000 16:26:04 +0200 (MET DST) Received: from SMTP ([153.88.251.32]) by esealnt409.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1); Thu, 6 Jul 2000 16:26:04 +0200 Received: from esealnt172.ericsson.se ([130.100.184.165]) by 153.88.251.32 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 06 Jul 2000 14:26:04 0000 (GMT) Received: by esealnt172 with Internet Mail Service (5.5.2651.58) id ; Thu, 6 Jul 2000 16:25:24 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 06 Jul 2000 14:26:04.0698 (UTC) FILETIME=[1E0C27A0:01BFE756] Message-ID: <5F05C89FB2F8D211B6430008C791912703EA80D4@esealnt190> Date: Thu, 6 Jul 2000 16:25:45 +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] Fast Handoffs (fast-handoffs and proactive-FA) To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello Pat > No it doesn't break RFC 2002 anymore than Regional > Registration Does. The main > idea is to let the GFA be aware that the Mobile Node is > entering a new cell, > before MN registration occurs. This allows the network to > adjust itself to > provide service to the Mobile Node when it does enter the cell. Regional Registration messages are sent by the MN to the RFA. Your draft however makes the MN unaware that the network is setting up bindings for it. This is the reason why I think that it does not do the same as Regional Registrations with respect to RFC2002. Also, your new handoff request message is basically a surrogate or proxy Registration Request message. IMO it is possible to do without a new message (see below). You also refer to entering the "cell" above. I think that we should not involve specific cellular issues when considering a generic L3 fast handoff mechanism. > > The inverse requires that the Mobile Node detects it has > entered a new cell by > receiving (or soliciting) an advertisement, then proceed > with the registration > process. There is another option though, which is the one we have chosen and presented in Adelaide. Have you had a look at this? The MN may register with the new FA through the old wireless access point. Rgds, Karim From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jul 6 12:03: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 MAA19573 for ; Thu, 6 Jul 2000 12:03:26 -0400 (EDT) Received: from standards (47.234.32.16:1574) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B7D2@standards.nortelnetworks.com>; Thu, 6 Jul 2000 11:52:59 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0139 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Jul 2000 11:52:59 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B7D1@standards.nortelnetworks.com>; Thu, 6 Jul 2000 11: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 KAA18932 for ; Thu, 6 Jul 2000 10:02:52 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA10221; Thu, 6 Jul 2000 09:02: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 JAA29802; Thu, 6 Jul 2000 09:02:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: DkXI0WIZQKbfPmu6YE6Flg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Message-ID: <200007061602.JAA29802@nasnfs.eng.sun.com> Date: Thu, 6 Jul 2000 09:06:43 -0700 Reply-To: James Kempf Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: James Kempf Subject: Re: [MOBILE-IP] Fast Handoffs (fast-handoffs and proactive-FA) X-To: Karim.El-Malki@ERA.ERICSSON.SE To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM >> Regarding your statement about L2 handoff, there is additionally a >> need to do handoff when there is no L2 connection between the old >> and new RANs. I'm thinking about the CDMA hard handoff case here, >> in which there is no physical interconnection directly between >> the old and new RAN, and so the handoff must go through the >> L3 core (currently, this is done by involving the MSCs in handoff). >> This will, of necessity, involve communicating radio specific >> information across L3, channel parameters, current cell site, etc. >> We believe FA assisted handoff as we have outlined it will handle >> this case, with an extension to carry the radio specific information >> needed in order to have the new RAN set up the handoff. Does your >> proposal work for this as well? >> > >Our proposal describes a way to do an L3 Fast Handoff possibly utilising >L2 functions/information. The lack of a soft-handoff does not mean >there will not be a L2 interface to the radio/cellular specific part >of the network (which exists today). From your mail above I conclude >that you take a different assumption: L3 interface to the radio network. >Am I correct? I think that radio-specific information should be left to As Pat indicated in his reply, there is no requirement for an L3 interface to the radio network in our draft. Our draft is independent of L2. >L2 since it is an overkill to bring complex radio-technology-specific >parameters up to L3. This is also due to the fact that every radio/cellular >standard has its set of parameters. Only a few L2 parameters need to be >made visible to L3 (e.g. handoff indication), possibly through some API >to obtain the improved handoffs which we are aiming for. This is the >assumption we should work with IMO, since it allows us to define a generic >L3 (MIP) fast handoff method. > I think it should be possible to allow radio specific parameters to be exchanged between FAs that can handle them in a way that is generic enough to handle multiple kinds of radio link technologies. L3 would be used just for exchange of radio-link specific information, nothing more. For CDMA and TDMA technologies, I don't believe a single parameter or generic set of parameters will be sufficient to handle hard handoff between noninterconnected RANs, i.e. the hard handoff case. There is otherwise no way for the two RANs to find out information on the channel and cell that the mobile is using in order to perform the handoff. Whether or not the mobile IP working group, or even IETF, is the right place for defining this is another question. It may be something more appropriate for the 3G arena. jak From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jul 6 13:14:23 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21360 for ; Thu, 6 Jul 2000 13:14:23 -0400 (EDT) Received: from standards (47.234.32.16:3790) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B841@standards.nortelnetworks.com>; Thu, 6 Jul 2000 13:03:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0280 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Jul 2000 13:03:51 -0400 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B840@standards.nortelnetworks.com>; Thu, 6 Jul 2000 13:03:51 -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 e66HDa604116; Thu, 6 Jul 2000 19:13:36 +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 TAA03713; Thu, 6 Jul 2000 19:13:35 +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 TAA50311; Thu, 6 Jul 2000 19:15:16 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-ID: <200007061715.TAA50311@givry.rennes.enst-bretagne.fr> Date: Thu, 6 Jul 2000 19:15:16 +0200 Reply-To: Francis.Dupont@ENST-BRETAGNE.FR Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] Security Questions for Mobility in IPv6 Drafts X-To: "Hesham Soliman (EPA)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Thu, 06 Jul 2000 21:45:03 +1000. <4B6BC00CD15FD2119E5F0008C7A419A5089EB0F5@eaubrnt018.epa.ericsson.se> In your previous mail you wrote: => I don't believe in a V6 <-> V4 translator with mobility support (for instance IPv4 source-routing is not available in the today Internet for many reasons). I don't really understand what that means. Are you against translators that support mobility ? => I am not against translators that support mobility, I just believe it is not possible for a translator to support mobility (but we have to define what is to support mobility too :-). I'm not sure how source routing is related to this. => IPv6 mobility uses source routing and if a translator translates an IPv6 source route header to an IPv4 source route option the next router will likely drop the packet on the floor: this doesn't work! Yes this is great but placing BU after the IPsec header will be a problem for the migration mechanisms available today. => it is a problem for firewalls too. I am in favour of a SHOULD (for BU in the same header than HA) but we can't sell a MUST here. I believe the I-D 12 doesn't specify this because to do the right thing is more simple... Maybe it should be stated in the relevant translator drafts instead of the MIPv6 draft ? We have a draft for NGTRANS and this is one of the topics addressed. Hopefully coming out soon. => if you cannot justify a MUST then the place you put the SHOULD is not really important... In fact if someone is using ESP (with a real cipher) then both translators and firewalls will have some problems (you have to explain how to deal with headers and data which are not in the clear part). Regards Francis.Dupont@enst-bretagne.fr PS: in fact I've disliked translators since I proposed to use them for TUBA. There are too many ugly little details and no good solution for address translation. I prefer clean design like DSTM! From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jul 6 18:44:40 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26949 for ; Thu, 6 Jul 2000 18:44:38 -0400 (EDT) Received: from standards (47.234.32.16:2787) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B97A@standards.nortelnetworks.com>; Thu, 6 Jul 2000 18:34:10 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0671 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Jul 2000 18:34:10 -0400 Received: from cheetah.cs.ucla.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B977@standards.nortelnetworks.com>; Thu, 6 Jul 2000 18:24:09 -0400 Received: from localhost (sjlee@localhost) by cheetah.cs.ucla.edu (8.9.1/UCLACS-5.0) with ESMTP id PAA26629; Thu, 6 Jul 2000 15:33:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Thu, 6 Jul 2000 15:33:54 -0700 Reply-To: SJ Lee Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: SJ Lee Subject: [MOBILE-IP] MobiHOC 2000: Call for Participation To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM [Please accept our apologies if you receive duplicate messages] ================================================================== Announcement & Call for Participation THE FIRST ANNUAL WORKSHOP ON MOBILE AD HOC NETWORKING & COMPUTING (MobiHOC 2000) in conjunction with Mobicom 2000 August 11, 2000 Boston, Massachusetts, USA Advance program, registration information, and hotel information for the MobiHOC workshop are now available at http://www.cs.tamu.edu/faculty/vaidya/mobihoc/ If you are unable to access the above web page, please send an e-mail to vaidya@cs.tamu.edu -------------------------------------------------------------------------- MobiHOC 2000 Advance Program -------------------------------------------------------------------------- MobiHoc received 82 submissions, of which 13 were accepted as regular papers, and 12 as posters. The accepted papers/posters came from 13 countries. -------------------------------------------------------------------------- Keynote Leonard Kleinrock will present a keynote address on Beyond the Netherworld of Cyberspace. -------------------------------------------------------------------------- Introductions and Welcome 8:00 - 8:30 a.m. -------------------------------------------------------------------------- Session A: Routing 8:30 - 10:15 a.m. Session Chair: David B. Johnson, CMU and Rice University * On the Impact of Alternate Path Routing for Load Balancing in Mobile Ad-Hoc Networks Marc Pearlman, Zygmunt Haas (Cornell University), Peter Sholander (Scientific Research Corporation), and Siamak S. Tabrizi (Air Force Rome Laboratories) * LANMAR: Landmark Routing for Large Scale Wireless Ad Hoc Networks with Group Mobility Guangyu Pei, Mario Gerla, and Xiaoyan Hong (University of California, Los Angeles) * DDR-Distributed Dynamic Routing Algorithm for Mobile Ad Hoc Networks Navid Nikaein, Houda Labiod, and Christian Bonnet (Eurecom Institute) * Predicting Node Proximity in Ad-Hoc Networks: A Least Overhead Adaptive Model for Selecting Stable Routes A. Bruce McDonald and Taieb Znati (University of Pittsburgh) -------------------------------------------------------------------------- Session B: Multicasting 10:45 - 12:00 a.m. Session Chair: Joseph Macker, Naval Research Laboratory * Neighbor Supporting Ad Hoc Multicast Routing Protocol Seungjoon Lee and Chongkwon Kim (Seoul National University) * Role-Based Multicast in Highly Mobile but Sparsely Connected Ad Hoc Networks Linda Briesemeister (DaimlerChrysler Research and Technology) and Gunter Hommel (Technical University of Berlin) * Content Based Multicast (CBM) in Ad Hoc Networks Hu Zhou and Suresh Singh (Oregon State University) -------------------------------------------------------------------------- Keynote Address and Lunch 12:00 - 1:30 p.m. Keynote Speaker: Leonard Kleinrock Topic: Beyond the Netherworld of Cyberspace -------------------------------------------------------------------------- Session C: Novel Issues 1:30 - 2:45 p.m. Session Chair: Andrew Campbell, Columbia University * An Architecture for Building Self-Configurable Systems Lakshminarayanan Subramanian and Randy H. Katz (University of California, Berkeley) * MIPMANET - Mobile IP for Mobile Ad Hoc Networks Ulf Jonsson, Fredrik Alriksson, Tony Larsson, Per Johansson (Ericsson Radio Systems), and Gerald Q. Maguire Jr. (Royal Institute of Technology) * Enforcing Service Availability in Mobile Ad-Hoc WANs Levente Buttyan and Jean-Pierre Hubaux (Swiss Federal Institute of Technology, Lausanne) -------------------------------------------------------------------------- Session D: Link Layer 3:15 - 4:30 p.m. Session Chair: Fred L. Templin, SRI International * Fair Medium Access in 802.11 based Wireless Ad-Hoc Networks Brahim Bensaou, Yu Wang, and Chi Chung Ko (National University of Singapore) * Low Power Rendezvous in Embedded Wireless Networks Terry Todd (McMaster University), Frazer Bennett (PA Consulting Group), and Alan Jones (AT&T Laboratories Cambridge) * Assignment Methods for Spatial Reuse TDMA Jimmi Gronkvist (Swedish Defence Research Establishment) -------------------------------------------------------------------------- Poster Session 4:30 - 6:00 p.m. Session Chair: TBA * A Speech-Optimised Multiple Access Scheme for a Mobile Ad Hoc Network V. N. Muthiah and W. C. Wong (National University of Singapore) * On the Reduction of Broadcast Redundancy in Mobile Ad Hoc Networks Wei Peng and Xi-Cheng Lu (Changsha Institute of Technology) * Central Controller Handover Procedure for ETSI-BRAN HiperLAN/2 Ad Hoc Networks and Clustering with Quality of Service Guarantees Jorg Habetha, Andreas Hettich, Jorg Peetz (Aachen Institute of Technology), and Yonggang Du (Philips Research Laboratories) * DEAPspace -- Transient Ad-hoc Networking of Pervasive Devices Reto Hermann, Dirk Husemann, Michael Moser, Michael Nidd, Christian Rohner, and Andreas Schade (IBM Zurich Research Lab) * Securing Ad Hoc Services, a Jini View Christian Gehrmann (Ericsson Research), and Pekka Nikander (Helsinki Institute of Technology) * Dynamic Quality-of-Service for Mobile Ad Hoc Networks M. Mirhakkak, N. Schult, and D. Thomson (MITRE Corporation) * A Simulation Analysis on Reactive Route Repair Techniques for QoS Sensitive Applications in Mobile Ad Hoc Networks George Aggelou and Rahim Tafazolli (University of Surrey) * Proximity Awareness and Fast Connection Establishment in Bluetooth Theodoros Salonidis (University of Maryland), Pravin Bhagwat (IBM T. J. Watson Research Center), and Leandros Tassiulas (University of Maryland) * Utility-Based Decision-Making in Wireless Sensor Networks John Byers and Gabriel Nasser (Boston University) * A Distributed Mechanism for Topology Discovery in Ad hoc Wireless Networks using Mobile Agents Romit RoyChoudhury (Haldia Institute of Technology), Somprakash Bandyopadhyay (PricewaterhouseCoopers Ltd.), and Krishna Paul (CTS-Calcutta) * Performance Aspects of Bluetooth Scatternet Formation G. Miklos, A. Racz, Z. Turanyi, A. Valko (Ericsson Research), and P. Johansson (Ericsson Radio Systems) * Load Balancing via Relay in Next Generation Wireless Systems Chunming Qiao, Hongyi Wu, and Ozan Tonguz (University at Buffalo) -------------------------------------------------------------------------- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jul 6 18:47:57 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26985 for ; Thu, 6 Jul 2000 18:47:57 -0400 (EDT) Received: from standards (47.234.32.16:2787) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B9B8@standards.nortelnetworks.com>; Thu, 6 Jul 2000 18:37:37 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0752 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Jul 2000 18:37:37 -0400 Received: from turin.trillium.com (38.187.146.197:4455) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B9B7@standards.nortelnetworks.com>; Thu, 6 Jul 2000 18:37:37 -0400 Received: from aiglos.trillium.com (smtp.trillium.com) by turin.trillium.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Thu, 6 Jul 2000 16:01:22 -0700 Received: from aega.trillium.com (aega.trillium.com [192.168.1.19]) by aiglos.trillium.com (8.9.3/8.9.3) with ESMTP id PAA29865 for ; Thu, 6 Jul 2000 15:47:28 -0700 (PDT) Received: by aega.trillium.com with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Jul 2000 15:43:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <8BBD33A986C5D311804000902719FF5D952B42@aega.trillium.com> Date: Thu, 6 Jul 2000 15:43:49 -0700 Reply-To: Prem Shankar Sharma Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Prem Shankar Sharma Subject: [MOBILE-IP] some queries on To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi, I have some questions on the draft . Though it proposes some interesting schemes to imbibe MPLS techniques in Mobile IP, to enhance data efficiency (packet header compression techniques), expedite data forwarding and to use of CRLSPs for QoS requirements, but I feel, it doesn't fully address some of the issues. * This draft doesn't address the cases when the route optimization techniques are employed. What if they are employed? Can the LSPs could be established directly from CN to FA or from CN to MN? What if CN is not MPLS capable? What if MN itself is MPLS capable? [not fully sure whether these questions need to be handled within this draft or some other work on MPLS]. * How the packets in transit are going to be handled during handoff? Can a "short lived" LSP be provisioned between the old FA and the new FA. The new FA could be the HA itself. If such data driven LSPs are provisioned, what are going to be their implications on the scalability of the soln.? Besides this, in section 2.4, there seems to be a typo - It says "HA strips off the label and sends the packet to IP layer". Instead of HA, it should have been FA. Looking for the responses!!! Thanks. Prem From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jul 7 05:00:34 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18966 for ; Fri, 7 Jul 2000 05:00:34 -0400 (EDT) Received: from standards (47.234.32.16:4941) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7BCDF@standards.nortelnetworks.com>; Fri, 7 Jul 2000 4:49:53 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1811 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jul 2000 04:49:52 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7BCDA@standards.nortelnetworks.com>; Fri, 7 Jul 2000 4:39:52 -0400 Received: from emu.prod.itd.earthlink.net (emu.prod.itd.earthlink.net [207.217.121.31]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id DAA07062; Fri, 7 Jul 2000 03:49:47 -0500 (CDT) Received: from 209.179.245.134 (pool0389.cvx19-bradley.dialup.earthlink.net [209.179.245.134]) by emu.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with SMTP id BAA22710; Fri, 7 Jul 2000 01:49:36 -0700 (PDT) X-Priority: 3 X-MSMail-Priority: Normal Message-ID: <000004f6670c$00004f21$00000b04@> Date: Fri, 7 Jul 2000 01:25:24 -0700 Reply-To: cardacct2505@HOTMAIL.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: cardacct2505@HOTMAIL.COM Subject: [MOBILE-IP] Merchant Account - No Setup Fee 2820 X-To: Undisclosed.Recipients@earthlink.net To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM HOW TO SUBSTANTIALLY INCREASE SALES: Easily accept major credit cards right away! Act now and all Setup & App. fees waived ******************************************************** For Free Setup DOUBLE CLICK ON: mailto:cardacct4@mailcity.com?subject=merchant_interested Include your name, phone number and best time to call. Or you can call 1(888) 242-8260 now! Our courteous customer care reps are anxious to help you get your merchant account today. ******************************************************** Merchant Status will help you increase sales by an incredible 50% to 400%. Stop losing valuable sales! With one phone call you can be: Accepting all major credit cards! Accepting checks over the net or by Fax! Accepting real time processing for member sites! Gaining costumer loyalty and trust! Close the sale now. No more wondering if "The check is in the mail" We specialize in helping those entrepreneurs who are just starting out: no credit, poor credit, or even if you have great credit. Almost everyone is approved! For the next 5 days we will waive all Setup & App. fees! (other companies charge $200 to $500 to set up) In Business since 1992 ******************************************************** For Free Setup DOUBLE CLICK ON: mailto:cardacct4@mailcity.com?subject=merchant_interested Include your name, phone number and best time to call. Or you can call 1(888) 242-8260 now! Our courteous customer care reps are anxious to help you get your merchant account today. ******************************************************** This email has been delivered to you by the OPT IN PLUS email delivery service. If you feel that this has reached you in error please DOUBLE CLICK ON mailto:remov1@yahoo.com?subject=unsubscribe We will insure that your email address is removed from our database immediately. Thank you for participating in OPT IN PLUS! We value your membership. HOW TO SUBSTANTIALLY INCREASE SALES: Easily accept major credit cards right away! From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jul 7 05:28: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 FAA19154 for ; Fri, 7 Jul 2000 05:28:44 -0400 (EDT) Received: from standards (47.234.32.16:3009) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7BD4F@standards.nortelnetworks.com>; Fri, 7 Jul 2000 5:18:09 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1975 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jul 2000 05:18:09 -0400 Received: from ish7.ericsson.com.au (203.61.155.111:61121) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7BD4E@standards.nortelnetworks.com>; Fri, 7 Jul 2000 5:18:08 -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 TAA26312; Fri, 7 Jul 2000 19:26:46 +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 TAA07725; Fri, 7 Jul 2000 19:27:53 +1000 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id <3FW9RV1Y>; Fri, 7 Jul 2000 19:27:43 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFE7F5.99FEF550" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A5089EB0FE@eaubrnt018.epa.ericsson.se> Date: Fri, 7 Jul 2000 19:27:42 +1000 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] Security Questions for Mobility in IPv6 Drafts X-To: Francis Dupont 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_01BFE7F5.99FEF550 Content-Type: text/plain In your previous mail you wrote: => I don't believe in a V6 <-> V4 translator with mobility support (for instance IPv4 source-routing is not available in the today Internet for many reasons). I don't really understand what that means. Are you against translators that support mobility ? => I am not against translators that support mobility, I just believe it is not possible for a translator to support mobility (but we have to define what is to support mobility too :-). That's right, we need to define minimum level of support. As you say translation of options is going to be really difficult. I meant minimum support that allows an IPv6 MN to talk to an IPv4 MN. That's actually fairly straight forward. PS: in fact I've disliked translators since I proposed to use them for TUBA. There are too many ugly little details and no good solution for address translation. I prefer clean design like DSTM! Well DSTM doesn't solve the same problem. If you have a small device that can't have a dual stack then you need a translator. I suppose that's getting beyond this list. But anyway our solution combines both, translators and DSTM. I'll look forward to the discussion in the NGTRANS meeting. ------_=_NextPart_001_01BFE7F5.99FEF550 Content-Type: text/html RE: [MOBILE-IP] Security Questions for Mobility in IPv6 Drafts

 In your previous mail you wrote:

   => I don't believe in a V6 <-> V4 translator with mobility support
   (for instance IPv4 source-routing is not available in the today
Internet
   for many reasons).

   I don't really understand what that means. Are you against
translators that
   support mobility ?

=> I am not against translators that support mobility, I just believe it
is not possible for a translator to support mobility (but we have to
define what is to support mobility too :-).

That's right, we need to define minimum level of support.
As you say translation of options is going to be really difficult.
I meant minimum support that allows an IPv6 MN to talk to an
IPv4 MN. That's actually fairly straight forward.


PS: in fact I've disliked translators since I proposed to use them for
TUBA. There are too many ugly little details and no good solution for
address translation. I prefer clean design like DSTM!

Well DSTM doesn't solve the same problem. If you have a small
device that can't have a dual stack then you need a translator.
I suppose that's getting beyond this list.
But anyway our solution combines both, translators and DSTM.
I'll look forward to the discussion in the NGTRANS meeting.

------_=_NextPart_001_01BFE7F5.99FEF550-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jul 7 07:02:40 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20137 for ; Fri, 7 Jul 2000 07:02:40 -0400 (EDT) Received: from standards (47.234.32.16:3009) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7BDFB@standards.nortelnetworks.com>; Fri, 7 Jul 2000 6:52:12 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2191 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jul 2000 06:52:12 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7BDF1@standards.nortelnetworks.com>; Fri, 7 Jul 2000 6:42:12 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19957; Fri, 7 Jul 2000 06:52:08 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200007071052.GAA19957@ietf.org> Date: Fri, 7 Jul 2000 06:52:08 -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-aaa-reqs-04.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 : Mobile IP Authentication, Authorization, and Accounting Requirements Author(s) : S. Glass, T. Hiller, S. Jacobs, C. Perkins Filename : draft-ietf-mobileip-aaa-reqs-04.txt Pages : 25 Date : 06-Jul-00 The Mobile IP and AAA working groups are currently looking at defining the requirements for Authentication, Authorization, and Accounting. This document contains the requirements which would have to be supported by a AAA service to aid in providing Mobile IP services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-aaa-reqs-04.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-aaa-reqs-04.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-aaa-reqs-04.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: <20000706151851.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-aaa-reqs-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-aaa-reqs-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000706151851.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jul 7 08:17:05 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22861 for ; Fri, 7 Jul 2000 08:17:05 -0400 (EDT) Received: from standards (47.234.32.16:4966) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7BE8A@standards.nortelnetworks.com>; Fri, 7 Jul 2000 8:06:42 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2384 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jul 2000 08:06:42 -0400 Received: from cedar.dcs.shef.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7BE89@standards.nortelnetworks.com>; Fri, 7 Jul 2000 8:06:42 -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 NAA23464; Fri, 7 Jul 2000 13:16:30 +0100 (BST) References: <395A0645.92D77115@informatik.tu-muenchen.de> <01e001bfe5bb$d012c7c0$2c0ba78f@dcs.shef.ac.uk> <3961F064.879E82E8@informatik.tu-muenchen.de> <020d01bfe5c7$341f91c0$2c0ba78f@dcs.shef.ac.uk> <3961FEE4.C16E36F0@informatik.tu-muenchen.de> MIME-Version: 1.0 Content-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: <018801bfe80d$7c2b61e0$2c0ba78f@dcs.shef.ac.uk> Date: Fri, 7 Jul 2000 13:18:39 +0100 Reply-To: Chern Nam Yap Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Chern Nam Yap Subject: Re: [MOBILE-IP] Fast Handovers/offs X-To: Wolfgang Liebl To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi > > > > Currently I am working in the area of IIP (attachment) > > and very interested on get information about cell size > > and one's own location within a cell to calculate the > > expected cell visiting time before handover to another > > cell and herewith possibly to handoff to another subnetwork, > > that hence improves handoff in IIP. > > I guess that IIP is that imaging prot. and thus on top of IP or tcp, isn't it? My apology that I don't understand what you mean by imaging prot. IIP is an mobility mangement protocol that sits on top of TCP/IP, without changing TCP/IP. I have look through the you slides. How do you got the information for the converage area of any data network (LAN and MAN)? Thanks and Regards ---------------------------------------------------------------------------- --- Chern Nam Yap Research Associate Center for Mobile Communication Research Department of Electronic and Electrical Engineering University of Sheffield Regent Court 211 Portobello Street Sheffield S1 4DP United Kingdom Tel:+44 (0) 114-222-3308 Fax:+44 (0) 114-222-8299 Web: www.mobile1.net E-mail: cny@dcs.shef.ac.uk E-mail: cny@ieee.org From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jul 7 11:13:31 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29181 for ; Fri, 7 Jul 2000 11:13:31 -0400 (EDT) Received: from standards (47.234.32.16:2702) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7BFA2@standards.nortelnetworks.com>; Fri, 7 Jul 2000 11:01:16 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2734 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jul 2000 11:01:16 -0400 Received: from cedar.dcs.shef.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7BF9C@standards.nortelnetworks.com>; Fri, 7 Jul 2000 11:01:15 -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 QAA10347; Fri, 7 Jul 2000 16:06:42 +0100 (BST) MIME-Version: 1.0 Content-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: <026401bfe825$a6891960$2c0ba78f@dcs.shef.ac.uk> Date: Fri, 7 Jul 2000 16:08:11 +0100 Reply-To: Chern Nam Yap Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Chern Nam Yap Subject: Re: [MOBILE-IP] why IIP? To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi Even though IIP is not meant to solve every problem, but IIP trying to resolve what Mobile IP can't resolve currently. Such as 1) Trianglar routing For MIPv4 is still stuck with Triangluar routing and Reverse Tunnelling. 2) Signalling Traffic, Current mobility protocols generate too much traffic and low reliability. 3) Topology Complexity for fast hand off for IPv4 and IPv6, Hierarchical model is far too complex just to solve handoff problem. 4) Mobility transition between IPv4 and IPv6. Any node meant for MIPv4 would not work in MIPv6 environment, via visa. Cheers ---------------------------------------------------------------------------- --- Chern Nam Yap Research Associate Center for Mobile Communication Research Department of Electronic and Electrical Engineering University of Sheffield Regent Court 211 Portobello Street Sheffield S1 4DP United Kingdom Tel:+44 (0) 114-222-3308 Fax:+44 (0) 114-222-8299 Web: www.mobile1.net E-mail: cny@dcs.shef.ac.uk E-mail: cny@ieee.org > > > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jul 7 22:39:53 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18811 for ; Fri, 7 Jul 2000 22:39:52 -0400 (EDT) Received: from standards (47.234.32.16:4792) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7C16C@standards.nortelnetworks.com>; Fri, 7 Jul 2000 22:29:15 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3301 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jul 2000 22:29:15 -0400 Received: from hansolm (210.112.10.141:18665) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7C16B@standards.nortelnetworks.com>; Fri, 7 Jul 2000 22:19:14 -0400 Received: from ns ([210.112.7.7]) by hansolm with Microsoft SMTPSVC(5.5.1877.197.19); Sat, 8 Jul 2000 11:27:29 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: <009c01bfe884$63e8ee00$d012060a@hansol.co.kr> Date: Sat, 8 Jul 2000 11:29:47 +0900 Reply-To: "Lee, Jiwoong" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Lee, Jiwoong" Subject: [MOBILE-IP] Terms: Home Link vs Home Network To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Dear Authors of , Whereas RFC2002bis defines "Home Network" and uses this term generally, Mobility Support in IPv6 defines "Home Link" instead of "Home Network" while uses "Home Link" together with "Home Network" through this docuemnt. Do you try to express particular meaning when the term "Home Link" is used instead of "Home Network"? How about the mixed use of these two terms? I appreciate your comment. J Lee M.com From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Jul 8 00:18:02 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19992 for ; Sat, 8 Jul 2000 00:18:02 -0400 (EDT) Received: from standards (47.234.32.16:3278) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7C1CB@standards.nortelnetworks.com>; Sat, 8 Jul 2000 0:07:34 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3406 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 8 Jul 2000 00:07:34 -0400 Received: from default (c07-207.006.popsite.net) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7C1BD@standards.nortelnetworks.com>; Fri, 7 Jul 2000 23:57:30 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Sat, 8 Jul 2000 00:07:34 -0400 Reply-To: LifeTime Homes Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: LifeTime Homes Subject: [MOBILE-IP] LifeTime Homes To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM "Lifetime Homes" You are invited to sign up to be a "Lifetime Homes" Distributors (Worldwide). Become our distributor (free), and get your free web site. We Close All The Sales For You, You Do Nothing But Have People Look At Your FREE Web Site That We Put Up For You In 24 Hours With Your Company Name On It And Collect 15% To 20% . Your Site Will Have Photos, Floor plans, And Pricing! The housing business is booming and we have only scratched 1% of the market. Click Here To See The Web Site: Your FREE Web Site Will Look Just Like Mine. http://www.lifetime-homes.com/SteelHomes/ajr/start.html Earn as much as $9,500 Per sale with us!! As a Life time Homes Associate, you'll be selling quality steel framed homes manufactured by Tri-Steel Structures, Inc., one of the largest manufacturer in the world and earn 15% to 20% commissions per home sold. These home packages come pre-cut ready to assemble. Our business opportunity is worldwide. We currently ship home packages to over 50 countries which has made us one of the largest distributors of this phenomenal product. From small homes to commercial office buildings, we are sure you will find our business opportunity the best out there as you breeze through our various pages and floor plans. Take a look at the PAY PLAN below: 1st $60,000 home...earn US$9,000 (15% commission) 2nd $60,000 home...earn US$9,000 (15% commission) 3rd $60,000 home...earn US$9,000 (15% commission) 4th $60,000 home...earn US$12,000 (20% commission) Your Total Income from selling 4 homes = US$39,000 >From your 4th home sold and up, you'll earn 20% commission. Imagine what your earning will be when you sell one of our $100,000 metal homes? Please Preview our website for only (INFORMATION PURPOSES) at http://www.lifetime-homes.com/SteelHomes/ajr/start.html To become our distributor (free), and get your free website, Fill out the CONTRACT AGREEMENT form below. Email Back To: lifetimehomes@yahoo.com or print and fill in the agent agreement form and fax back to 1-888-584-7194 ( TOLL FREE ) Make sure you complete every aspect of this form for easier processing. THANK YOU ----------------- APPLICATION --------------------- NEW ASSOCIATE DISTRIBUTOR AGREEMENT ( NO COST- FREE TO SIGN UP ) Tri-Steel Structures, Inc. Sponsored by: Anthony J. Russo Sr. Russo Communication Group Lifetime Homes Independent Authorized Distributor 1-888-584-7194 Toll Free Yes, I want to be an Independent Authorized Associate Distributor to refer Steel Framed Lifetime Homes & Metal Buildings and receive a free website. Sponsored by: Anthony J. Russo Sr. Membership Contract Agreement for: (new distributor name) and between R & R Welding Lifetime Homes, referred to as CONTRACTING PARTY, Male: Female: Name: (to make checks to) Date of Birth: (Must be over 18 yrs, no date, you will be rejected) Address: City: State: Zip: (Address will not be shown on your website) What Business Name for your new Website: (a must, or, one will be assigned for you). Phone Number: Show on website? Yes or No Fax Number if any: Show on website? Yes or No Business E-mail Address: Home E-mail Address: Referred to as INDEPENDENT AUTHORIZED ASSOCIATE DISTRIBUTOR ( FINDER & REFERRAL AGENT ), Agreement: ASSOCIATE DISTRIBUTOR shall perform the following services for CONTRACTING PARTY: To find referrals (customers) for R & R Welding Lifetime Homes. At the following rate of remuneration: For each home sold,(on the steel framed packages only) through your referrals, 15% commission, first (3) lifetime homes, 20% commission on forth & thereafter. (please, insert correct dates below) (You may Renew Yearly.) This agreement shall begin on: , and shall terminate on: (fill in date you signed up) THIS IS AN AGREEMENT FOR INDEPENDENT REFERRAL SERVICES. THE CONTRACTING PARTY PROVIDES NO BENEFITS SUCH AS UNEMPLOYMENT INSURANCE OR WORKER'S COMPENSATION INSURANCE TO INDEPENDENT, ASSOCIATE DISTRIBUTORS. ALL ASSOCIATE DISTRIBUTORS ARE RESPONSIBLE FOR THEIR OWN SUPPLIES & ADVERTISEMENTS. CONTRACTING PARTY IS ONLY INTERESTED IN THE RESULTS OBTAINED BY THE INDEPENDENT ASSOCIATE DISTRIBUTOR. ALL INDEPENDENT, ASSOCIATE DISTRIBUTORS ARE RESPONSIBLE FOR PAYMENT OF ALL FEDERAL STATE AND LOCAL TAXES. VIDEOS, BROCHURES & SALES MATERIALS ARE AVAILABLE THROUGH OUR SALES DEPARTMENT, etc. X: Rudolph Ortiz, Sr. Date: Contracting party: R & R Welding Lifetime Homes: IMPORTANT, Type in your Associate Distributor Signature and current date below X: Date: Please email this agreement to the following address to activate: lifetimehomes@yahoo.com We will email your URL to your website within 24 hrs. Thank You Anthony J. Russo Sr. Russo Communication Group Steel Framed Lifetime Homes 1905 Fairfield St. Ste. A Eureka Ca. 95501 lifetimehomes@yahoo.com To send by fax: 1-888-584-7194 ( TOLL FREE ) http://www.lifetime-homes.com/SteelHomes/ajr/start.html ************************************************************************************ This message is sent in compliance of the new e-mail bill: SECTION 301. Per Section 301, Paragraph (a)(2)(C) of S. 1618, 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 an Email To: delete_2000_2002@yahoo.com with the word "remove" in the subject line. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Jul 8 08:45:07 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05440 for ; Sat, 8 Jul 2000 08:45:06 -0400 (EDT) Received: from standards (47.234.32.16:4280) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7C2D3@standards.nortelnetworks.com>; Sat, 8 Jul 2000 8:34:16 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3756 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 8 Jul 2000 08:34:16 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7C2D0@standards.nortelnetworks.com>; Sat, 8 Jul 2000 8:24:16 -0400 Received: from email.emailmkt ([208.225.197.49]) by hosaka.smallworks.com (8.9.1/8.9.1) with SMTP id HAA14692; Sat, 8 Jul 2000 07:33:58 -0500 (CDT) Message-ID: <200007081233.HAA14692@hosaka.smallworks.com> Date: Sat, 8 Jul 2000 07:33:58 -0500 Reply-To: a_z55@YAHOO.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: a_z55@YAHOO.COM Subject: [MOBILE-IP] To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM TIRED OF ENDLESSLY POSTING YOUR ONLINE CLASSIFIED AD AND GETTING NORESULTS? The fact is there are over 7000 such sites scattered about the web and frankly none of them generate enough traffic to be worth your while. Even when someone does find or visits one of these sites, your ad is hopelessly lost in a myriad of similar offerings. Another frustration is search engines. If you are not in the Top 10 forget about high traffic visiting your web site. Not everyone can be in the Top 10 and stay there, when there are estimates of 4 million that have a web pages. You ask, how do we know? That's exactly what we used to do. The greatest way of marketing this century is undoubtedly direct e-mail. It's similar to the postman delivering a letter to your mailbox. There is NO stumbling on to it! The ability to promote your product, service, website, or MLM/Network Marketing opportunity to millions instantly is what advertisers have been dreaming of for over 100 years. We will e-mail your one page promotion to a list of our general addresses. The greatest part is, it's completely affordable. ----------------------------------------------------------------------- NOTICE: No pornography, chain letters, get quick rich, pyramid scheme, or any threatening or questionable materials. Don't even Ask!! ----------------------------------------------------------------------- STANDARD PRICING AND PROCEDURES ----------------------------------------------------------------------- EXTRACTING:Our list of general Internet addreses are actually extracted from the most popular web sites on the Internet. The addresses are verified and run through our purification process. The process includes addresses run against our custom filter of 2,492 keywords to remove as well as through our 192MB remove /flamer list. The EDU, ORG, GOV, Mil, and US domains are removed as well as well as other domains that asked not to receive e-mail. ----------------------------------------------------------------------- SET-UP FEE: $150.00 This will cover the costs of uploading files, Internet Access (ISP), and software set-up. ----------------------------------------------------------------------- EVALUATION: $350.00 (optional) One of our Marketing Specialists will evaluate your sales letter, and offer his/her expertise on how to make it the most successful. ----------------------------------------------------------------------- STANDARD PRICING: (Emails Delivered)1 Million- $800.00 per2 Million- $700.00 per 3 Million & up- $600.00 per ----------------------------------------------------------------------- SPECIAL OFFER!This introductory offer of $475.00 includes:1. Set-Up Fee 2. Evaluation of sales letter 3. 250,000 e-mails delivered to a general list of recipients. ----------------------------------------------------------------------- PAYMENT POLICY All services must be paid in full prior to delivery of advertisement. Under NO CIRCUMSTANCES will any sales or marketing strategies be discussed until payment is received. ----------------------------------------------------------------------- If you are serious about Direct Email Marketing-Fax the following form to (520) 438-2702 ---------------------------------------------------------------------- THIS FORM MUST BE COMPLETELY FILLED OUT! Contact Name: _____________________________________________ Business Name: ______________________________________ Business Type: ______________________________________ # Years in Business: _________________________ Address: _________________________________________________ City: ____________________ State: ______ Zip: ______________ Country: _______________ Email Address: _______________________________________________ Phone: __________________________Fax: ____________________________ ----------------------------------------------------------------------- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Jul 8 09:12:04 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05638 for ; Sat, 8 Jul 2000 09:12:04 -0400 (EDT) Received: from standards (47.234.32.16:4280) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7C33E@standards.nortelnetworks.com>; Sat, 8 Jul 2000 9:01:33 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3899 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 8 Jul 2000 09:01:33 -0400 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7C33D@standards.nortelnetworks.com>; Sat, 8 Jul 2000 9:01:33 -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 e68DBM625878; Sat, 8 Jul 2000 15:11:23 +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 PAA24959; Sat, 8 Jul 2000 15:11:22 +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 PAA60539; Sat, 8 Jul 2000 15:13:13 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-ID: <200007081313.PAA60539@givry.rennes.enst-bretagne.fr> Date: Sat, 8 Jul 2000 15:13:13 +0200 Reply-To: Francis.Dupont@ENST-BRETAGNE.FR Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] Terms: Home Link vs Home Network X-To: "Lee, Jiwoong" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Sat, 08 Jul 2000 11:29:47 +0900. <009c01bfe884$63e8ee00$d012060a@hansol.co.kr> In your previous mail you wrote: Dear Authors of , Whereas RFC2002bis defines "Home Network" and uses this term generally, Mobility Support in IPv6 defines "Home Link" => ID 12 uses "home link" because IPv6 has an accurate notion of "link". instead of "Home Network" while uses "Home Link" together with "Home Network" through this docuemnt. => "home network" is used only twice in ID 12 for the home agent interception of packets to the home address (which belongs to the home link). I believe the idea is these packets can never be on the home link itself, for instance if the router between the outside and the home link is the home agent (in fact the home link can be fully virtual, ie. be used only as an address space without a concrete physical incarnation). Then the "home network" is the place where is the home stuff and packets to a home destination go through it. Do you try to express particular meaning when the term "Home Link" is used instead of "Home Network"? How about the mixed use of these two terms? => I'd like to read ID 12 authors' answer but the two terms are not used inconsistently (and home subnetwork which had been ambiguous can't be found in ID 12). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Jul 9 07:17:48 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07513 for ; Sun, 9 Jul 2000 07:17:47 -0400 (EDT) Received: from standards (47.234.32.16:1105) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7C588@standards.nortelnetworks.com>; 9 Jul 2000 7:06:59 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4619 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 9 Jul 2000 07:06:59 -0400 Received: from neopolis.t.u-tokyo.ac.jp by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7C584@standards.nortelnetworks.com>; 9 Jul 2000 6:56:58 -0400 Received: from mori (mori.t.u-tokyo.ac.jp [133.11.65.210]) by neopolis.t.u-tokyo.ac.jp (8.9.3/3.7W-01/12/00) with ESMTP id UAA04684; Sun, 9 Jul 2000 20:01:27 +0900 (JST) X-Sender: mori@neopolis.t.u-tokyo.ac.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.2.0.58.J.20000709200858.00b3bef0@neopolis.t.u-tokyo.ac.jp> Date: Sun, 9 Jul 2000 20:09:20 +0900 Reply-To: Hiroyuki Morikawa Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Hiroyuki Morikawa Subject: [MOBILE-IP] Call for Papers: MoMuC2000 and IEICE special issue To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM ------------- MoMuC2000: Call for Papers --------------- CALL FOR PAPERS The 7th International Workshop on Mobile Multimedia Communications MoMuC2000 http://www.giti.or.jp/activity/momucj Date: October 23.-26. 2000 Place: Waseda, Tokyo, JAPAN Submission due: August 11, 2000 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The 7th International Workshop on Mobile Multimedia Communications (MoMuC2000) will provide an international forum for the discussion for research in mobile multimedia communications and platforms regardless of wireless and wired medium. The workshop, to be held in Tokyo, Waseda, a city where the 1st MoMuC(MoMuC-1) was held back in 1993, will bring together researchers, developers and practitioners working in all facets of advanced mobile multimedia communications. The scope of MoMuC2000 will include mobile multimedia systems and applications together with associated mobile computing, broadband wireless networking, video processing and enabling software technologies. The workshop will be corss-diciplinary, well focused, consisting keynote speakers, tutorials, panels and solicited contributions with the emphasis on innovations. An amount of time should be devoted to informal discussion. Authors are cordially invited to submit previously unpublished papers including short papers. Papers with regard to concept and proposal of immature idea are also welcome for an inherent nature of workshop. Technical visit to Yokosuka Research Park(YRP) is also planned. Further information will be provided through MoMuC2000 web page with the following URL. http://www.giti.or.jp/activity/momucj Suggested Areas - Mobile multimedia applications and platforms - Mobile computing and advanced mobile IP - Source coding and channel coding for mobile multimedia including MPEG-4 - Distributed systems and mobile multimedia communications - Mobile ad hoc networks - Mobile multimedia networks - High speed wireless packet systems and technologies - Mobile multimedia applications and technologies in IMT-2000 - Intelligent Transportation System for mobile multimedia - Internetworking of wired and wireless networks - Next generation mobile Internet - Mobile agent technology - Enabling software technologies for mobile systems - Quality of service in wireless and mobile networks - Medium access/data link control - Wireless networks management & service control for mobile multimedia - Software radio for mobile multimedia Workshop Committee - Steering Committee: D. Goodman (Polytechnic University, USA) D. Raychaudhuri (NEC, Princeton, USA) H. Tominaga (Waseda University, JAPAN) - Organizing Committee Chair: H. Tominaga(Waseda University) - Technical Program Committee: Chair: T. Hattori(Sophia University) Co-Chairs: H. Yasuda(University of Tokyo) S. Komaki(University of Osaka) K. Aizawa(University of Tokyo) - Local Organization Committee: Chair: M. Matsumoto(Waseda University) - Secretariat: Ms. Noriko Hosokawa Global Information and Telecommunication Institute, Waseda University, 29-7 Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 JAPAN Tel. /Fax. +81-3-5286-9863 E-mail: momuc2000@giti.or.jp http://www.giti.or.jp/activity/momucj Important Dates Paper(Extended Abstract) Submission Deadline: 11 August 2000 Acceptance of Notification: 4 September 2000 Camera Ready Copy Submission: 22 September 2000 Instructions Manuscripts must be in English and not exceed 3000 words and may include figures and tables. Each copy of the manuscript should include a cover page containing: 1. Name of all authors 2. Name of contact author, affiliation, return address, e-mail, telephone and fax numbers of contact author. 3. A double-spaced, 100-word abstract containing no equations and printed in a 12 point or larger plain font suitable for electronic scanning. 4. All other pages should be marked with the title of the paper, name of the first author, and page numbers. For electronic submissions, file format will be disirable in whether MS-Word 6.0/higher or Adobe PDF format. On-line paper submission is available at the following URL; http://www.giti.or.jp/activity/momucj/submissions.html Sponsors Host: MoMuC-J of IEICE, Waseda University Co-sponsors: IEEE Commnucation Society Japan Chapter, IEEE Communication Society, IEICE (Institute of Electronics, Information and Communication Engineering), IPSJ (Information Processing Society of Japan), IIEEJ (The Institute of Image Electronics Engineers of Japan), ITE (The Institute fo Image Information and Television Engineers) ------------- IEICE special issue: Call for Papers --------------- CALL FOR PAPERS IEICE Special Issue on Mobile Multimedia Communications The IEICE (Institute of Electronics, Information and Communication Engineering) Transactions on Communications announces a forthcoming special issue on Mobile Multimedia Communications to be published in April 2001. Recently, intensive efforts are now underway to promote practical use of mobile multimedia communications technologies; Progress has been achieved in the international standardization activities such as IMT-2000, IrDA, MPEG-4, etc. Many test bed experiments have been carried out as mobile communications systems such as wireless ATM, wireless Internet, etc. Also, various research and developments are widely in progress in the field of application and terminal technologies such as mobile contents, data broadcasting, PDA terminals, information appliance, etc., and of networking technologies such as mobile IP, quality of service, mobile agent, etc. The purpose of this special issue is to present the recent advance of mobile multimedia communications technologies including mobile applications, terminals, network, broadcasting, etc., and to promote future progress of research, development, and new applications of mobile multimedia communications. We are calling for papers from engineers in Japan and abroad. Submission of a paper presented at MoMuC 2000, to be held in Tokyo during October 23rd to 26th, 2000, is encouraged, but presentation of the paper at the workshop is not a requirement for its inclusion in this special issue. Conversely, presentation at the conference will not guarantee acceptance in the special issue. 1. Scope Suggested topics include but are not limited to the following: - Mobile multimedia applications and terminals Mobile computing, mobile contents, architecture for multimedia mobile terminals, mobile IP, personal multimedia applications, audiovisual compressions for mobile applications, security - Mobile multimedia systems and implementations System architecture for mobile multimedia (including fast LAN), quality of service for mobile multimedia communications, agent systems, multimedia satellite, implementation techniques of advanced wireless systems for mobile multimedia, data integration for mobile communications, multimedia location service - Network for Mobile Multimedia Broadband/fast wireless network (including wireless ATM), IP adaptive wireless access method, distributed networking, mobile multimedia advanced wireless techniques (including IrDA), multimedia data integrated service network for mobile communications 2. Submission Instructions Submitted papers will be reviewed by referees in accordance with the regular rules of the Transactions Editorial Committee. The standard number of pages is 8 for a paper and 2 for a letter. Refer to ``Information for Authors'' at the following web site for more details; http://www.ieice.or.jp/eng/shiori/mokuji.html. Prospective authors are requested to send four copies of their manuscripts to the address below. ``Special Issue on Mobile Multimedia Communications'' should be placed on top of the first page. Hirohisa Jozawa NTT Department III (R&D Strategy Department) Teishin Building 8F, 2-3-1, Otemachi, Chiyoda-ku, Tokyo, 100-8116 Japan Tel: +81 3 5205 5379, Fax: +81 3 5205 5369 E-mail: h.jozawa@hco.ntt.co.jp 3. Paper Submission Deadline Papers must be received by August 25, 2000. ^^^^^^^^^^^^^^^ 4. Special Issue Editorial Committee Editor-in-Chief Takeshi Hattori (Sophia University) Secretary Hirohisa Jozawa (NTT), Takehiko Kobayashi (YRP), Hisashi Miyamori (CRL) Guest Editors Hirotaka Nakano (NTT DoCoMo), Shiro Sakata (NEC), Tadanori Mizuno (Shizuoka Univ), Kiyoharu Aizawa (Univ of Tokyo), Ki-ichi Matsuda (Fujitsu Lab), Minoru Etoh (Matsushita), Hiroshi Watanabe (NTT), Shuuichi Matsumoto (KDD Lab), Yoshihiko Akaiwa (Kyushu Univ), Shozo Komaki (Osaka Univ), Mitsuji Matsumoto (Waseda University), Mitsuo Iwama (Sharp), Kouichi Honma (Matsushita), Hiroshi Nakamura (NTT DoCoMo), Fumiyuki Adachi (Touhoku Univ), Hiroyuki Morikawa (Univ of Tokyo), Takuro Satoh (Niigata Univ) * Please note that if accepted for publication, all authors, including authors of invited papers, should pay for the page charges covering partial cost of publication. Authors will receive 100 copies of the reprint. ---------------------------------------------------- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Jul 9 16:49:24 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10796 for ; Sun, 9 Jul 2000 16:49:24 -0400 (EDT) Received: from standards (47.234.32.16:3251) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7C68F@standards.nortelnetworks.com>; 9 Jul 2000 16:38:37 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4930 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 9 Jul 2000 16:38:37 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7C68C@standards.nortelnetworks.com>; 9 Jul 2000 16:28:37 -0400 Received: from beta.vinet.com.mx ([200.34.41.11]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id PAA23077 for ; Sun, 9 Jul 2000 15:38:39 -0500 (CDT) Received: from eol (host-216-78-227-58.mco.bellsouth.net [216.78.227.58]) by beta.vinet.com.mx (Build 98 8.9.3/NT-8.9.3) with SMTP id PAA04156; Sun, 09 Jul 2000 15:34:11 -0500 Message-ID: <200007092034.PAA04156@beta.vinet.com.mx> Date: Sun, 9 Jul 2000 15:34:11 -0500 Reply-To: michelle3@BUSINESSWEEKMAIL.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: michelle3@BUSINESSWEEKMAIL.COM Subject: [MOBILE-IP] How to make $100 - $1,500 per hour or two To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM From: Michelle Smith - publisher of the "Work From Home Opportunities" Newsletter Saturday, 9:30 p.m. Hello, If you're interested in earning $100 - $1,500 per hour or two, Then I want to share something with you... Now you can make an additional $100 - $1,500 Per Hour or Two! Imagine you come home from a hard day's work (exhausted..), You immediately go straight to bed. You get undressed, lay down, turn off the lights, and snuggle up face-down on the pillow. A few moments later, you feel uncomfortable and stressed out so you lie on your back. When you look up at the ceiling, it's as if the ceiling has been removed! You see exactly what you would see if outside stargazing! A stunning, accurate 3-dimensional re-creation of the starry night sky, including constellations such as the Big Dipper, Pegasus and the Milky Way galaxy, ...and even shooting stars! You can't see it during the day. The ceiling looks normal. But at night, when the lights are off, you see what looks like the sky outside! It's so relaxing and romantic. And educational! And talk about stress-relief! The moment you look at it, it'll melt your tension away faster than a great massage! Now how many people do you think would LOVE seeing this when they look up in their beds at night? "It's like you're sleeping under the stars!" Ok, I know you want to know How You Make Money. Here's how. You can put that awesome "convertible ceiling" in ANYONE'S bedroom with a product cost to you of.. Guess how much.. Only ONE to TWO Dollars! And you offer this masterpiece for $100 - $1,500! Talk about *nice* profits! And it only takes you an hour or two! Here's an important point: These profits are similar to the profits of selling Information: the material costs next to nothing, but the customer really VALUES the END RESULT. So you can charge more (a LOT more). "Who'd want this?" Anyone with a bedroom ceiling (or any ceiling), as well as homes, hotels, etc. Who do you know that has a bedroom ceiling? Whew! The official money-making opportunity of the Millenium! (Well... I think it should be!) |;-) Anyway, I know you want more information to make a decision, so ... To receive more FREE information on How To Make $100 - $1,500 Per Hour or Two, Simply Click On The Email Link Below and Send Back The Following: Mailto:starbiz140@newmail.net Name: E-Mail: Phone: Street: City: State: ZIP or Postal Code: Country (available INTERNATIONALLY): Mailto:starbiz140@newmail.net And you'll be sent the full details on how to make $100 - $1,500 Per Hour or Two, as well as pictures of these murals so you can see for yourself how breathtaking they are! Best regards, Michelle Smith P.S. We'll also send you a free Opportunity E-zine with more interesting Money-Making Opportunities like this one, and important info. for the home-based entrepreneur! P.P.S. Also, even though 99% of people don't know about this opportunity, that won't be the case forever, so hurry up and reply to make sure you get to lock down YOUR city! To unsubscribe mailto:unsubscribe708@newmail.net From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jul 10 06:40: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 GAA02645 for ; Mon, 10 Jul 2000 06:40:57 -0400 (EDT) Received: from standards (47.234.32.16:3131) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7C7A3@standards.nortelnetworks.com>; Mon, 10 Jul 2000 6:30:16 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5296 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Jul 2000 06:30:16 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7C7A1@standards.nortelnetworks.com>; Mon, 10 Jul 2000 6:20:16 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01715; Mon, 10 Jul 2000 06:30:21 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200007101030.GAA01715@ietf.org> Date: Mon, 10 Jul 2000 06:30:21 -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-elmalki-mobileip-fast-handoffs-02.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Fast Handoffs in Mobile IPv4 Author(s) : K. El Malki, H. Soliman Filename : draft-elmalki-mobileip-fast-handoffs-02.txt Pages : 15 Date : 07-Jul-00 This draft describes a method to achieve Fast Handoffs in Mobile IPv4. Fast Handoffs are required in Mobile IPv4 in order to limit the period of service disruption experienced by a wireless Mobile Node when moving between Foreign Agents. This requirement becomes even more important when supporting real-time services. Fast Handoffs involve anticipating the movement of MNs by sending multiple copies of the traffic to potential Mobile Node movement locations (i.e. FAs). Both a flat and a Hierarchical Mobile IPv4 model are considered. The Hierarchical MIPv4 model in Regional Tunnel Management [1] already offers improvements to Mobile IP handoffs by providing local Home Agent functionality. Some additions are made to the operation of this existing Hierarchical model to achieve Fast Handoffs and limit or avoid triangle routing within the hierarchical domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-elmalki-mobileip-fast-handoffs-02.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-elmalki-mobileip-fast-handoffs-02.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-elmalki-mobileip-fast-handoffs-02.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: <20000707143157.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-elmalki-mobileip-fast-handoffs-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-elmalki-mobileip-fast-handoffs-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000707143157.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jul 10 19:33:09 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01801 for ; Mon, 10 Jul 2000 19:33:09 -0400 (EDT) Received: from standards (47.234.32.16:1773) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CAD6@standards.nortelnetworks.com>; Mon, 10 Jul 2000 19:22:19 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6399 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Jul 2000 19:22:18 -0400 Received: from emaxr1.emax.com.pl (emax-gw.man.poznan.pl) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CAD5@standards.nortelnetworks.com>; Mon, 10 Jul 2000 19:12:17 -0400 Received: from intra.emax.com.pl (intra.emax.com.pl [212.126.5.50]) by emaxr1.emax.com.pl (8.8.5/8.8.5) with ESMTP id BAA19673; Tue, 11 Jul 2000 01:26:48 +0200 Received: from INTRA/SpoolDir by intra.emax.com.pl (Mercury 1.44); 11 Jul 00 01:27:50 +0100 Received: from SpoolDir by INTRA (Mercury 1.44); 11 Jul 00 01:11:12 +0100 Received: from djdswk (204.164.170.21) by intra.emax.com.pl (Mercury 1.44) with ESMTP; 11 Jul 00 01:11:09 +0100 X-Mailer: Mozilla 4.70 [en] (Win95; I) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Mon, 10 Jul 2000 17:20:07 -0500 Reply-To: "Edward R." Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Edward R." Subject: [MOBILE-IP] Your Call #47C4 X-To: today39d@emaxr1.emax.com.pl To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA01801 WE MAKE IT EASY & AFFORDABLE TO ACCEPT CREDIT CARDS FOR YOUR BUSINESS ! INTERNET (Auction Vendors & Online Mall Stores Too!) STOREFRONT OR MAIL ORDER MERCHANTS WE SPECIALIZE IN APPROVING YOU! APPLY TODAY AND START FOR JUST $9.95! FREE APPLICATION!! FREE PROGRAMMING!! DON'T LOSE ANOTHER SALE! APPLY TO ACCEPT CREDIT CARDS AND CALL (888) 264-9272 DON'T FORGET TO ASK ABOUT OUR WEB DESIGN AND HOSTING PACKAGE !!! ************************************************************ If you receive this message and have never joined one of our email lists you can be removed by replying to: mailto:maiqx@188mail.com?subject=remove ************************************************************ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jul 11 01:22:46 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10649 for ; Tue, 11 Jul 2000 01:22:46 -0400 (EDT) Received: from standards (47.234.32.16:1557) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CC0C@standards.nortelnetworks.com>; Tue, 11 Jul 2000 1:12:09 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6794 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jul 2000 01:12:09 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CC02@standards.nortelnetworks.com>; Tue, 11 Jul 2000 1:02:09 -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 WAA04790; Mon, 10 Jul 2000 22:12:18 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id WAA11633; Mon, 10 Jul 2000 22:12:14 -0700 X-Virus-Scanned: Mon, 10 Jul 2000 22:12:14 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from jmalinen.iprg.nokia.com (205.226.2.98, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpd7MHcFJ; Mon, 10 Jul 2000 22:12:10 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <396AB430.902573CA@comet.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <396AACAD.D48FEA1F@iprg.nokia.com> Date: Mon, 10 Jul 2000 22:12:13 -0700 Reply-To: jmalinen@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Jari T. Malinen" Subject: Re: [MOBILE-IP] Paging X-To: campbell@comet.columbia.edu X-cc: Henry.Haverinen@nokia.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello, Andrew, Indeed, we did submit an Internet-Draft on how to use paging with Regional Registrations. The draft is available at the IETF Internet Drafts archive, at URL http://www.ietf.org/internet-drafts/ draft-haverinen-mobileip-reg-paging-00.txt It seems there are spaces in the URL thus it might be that it does not show correctly in all places (e.g. the I-D search does not seem to find it). However, it is available behind the above link with the spaces included. The draft presents paging as a rather straightforward extension to Regional Registrations, and provides thus a different approach to that taken in Cellular IP. The paging area is also static providing opportunities for supporting timeslot-based paging ,and with it, power- constrained operation. Best Regards, --jari Jari T. Malinen, Nokia Research Center. "Andrew T. Campbell" wrote: > Hi Jari: > > One of my students mentioned that you authors an Intenet > Draft on paging. Could you let me have a copy? > > Andrew From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jul 11 07:26:02 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25749 for ; Tue, 11 Jul 2000 07:26:02 -0400 (EDT) Received: from standards (47.234.32.16:1053) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CE10@standards.nortelnetworks.com>; Tue, 11 Jul 2000 7:15:25 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7500 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jul 2000 07:15:25 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CE07@standards.nortelnetworks.com>; Tue, 11 Jul 2000 7:05:25 -0400 Received: from staff-svcs.geckosss (ip123.phoenix8.az.pub-ip.psi.net [38.29.61.123]) by hosaka.smallworks.com (8.9.1/8.9.1) with SMTP id GAA03529; Tue, 11 Jul 2000 06:15:28 -0500 (CDT) Message-ID: <200007111115.GAA03529@hosaka.smallworks.com> Date: Tue, 11 Jul 2000 06:15:28 -0500 Reply-To: a_z48@YAHOO.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: a_z48@YAHOO.COM Subject: [MOBILE-IP] To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM For Homeowners Only!! Want to pay off your credit card debt? Need cash for some other reason? We can get you the loan you need regardless of whether you have good or bad credit. Qualify even if you have hard to prove income (Self-Employed.) Pay off tax liens, judgments, or collection accounts. Pay off your chapter 13 bankruptcy or avoid foreclosure. Get CASH for ANY REASON!! If you are serious about improving your lifestyle APPLY NOW! We can help. We specialize in funding the loans that other lenders turn down. Click on the link below for the fastest free loan quote!!! http://www.whattodoifyouneedmoney.com Can't take the time to apply now? Then print out the form below and fax it to us today. FAX: (509) 562-7964 Please fill out this form completely. Enter NA in those fields which do not apply. ************************************************************************ Are you a HomeOwner? Y / N Applicant First and Last Name: ________________________________ Co-Applicant First and Last Name: _____________________________ Address: __________________________________________________ City, State: ________________________________________________ Zip code: _______________________ Home Phone: ___________________________ Work Phone: ____________________________ Property Type: Single Family Residence, Town-home, Condo, Other Purchase Price: _________________________________________ Year Property was Acquired: ______________________________ Present Value of Property: ________________________________ Amount Owed on First Mortgage: __________________________ Current Interest Rate: ____________________________________ Fixed or Adjustable: _____________________________________ Monthly Payment: _______________________________________ Second Mortgage Balance: ________________________________ Current Employer: _______________________________________ Years with Current Employer: ______________________________ Yearly Income: __________________________________________ How would you describe Your Credit: Excellent/Good/Fair/Poor Best Time to Contact You: _________________________________ Type of Loan Desired: ____________________________________ Loan Amount Desired: ____________________________________ Email Address: __________________________________________ ************************************************************************ We respect your online time and privacy and pledge not to abuse this medium. If you prefer not to receive further e-mails from us of this type, please reply to this e-mail and type 'Remove' in the subject line. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jul 11 13:59:14 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12187 for ; Tue, 11 Jul 2000 13:59:13 -0400 (EDT) Received: from standards (47.234.32.16:3336) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D040@standards.nortelnetworks.com>; Tue, 11 Jul 2000 13:48:31 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0316 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jul 2000 13:48:30 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D03F@standards.nortelnetworks.com>; Tue, 11 Jul 2000 13:48:25 -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 LAA01404 for ; Tue, 11 Jul 2000 11:57:23 -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 KAA24118 for ; Tue, 11 Jul 2000 10:44: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 KAA11320 for ; Tue, 11 Jul 2000 10:44:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Tue, 11 Jul 2000 10:44:01 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: Re: [MOBILE-IP] WG Internet Drafts to last call... To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Raj, As per the e-mail below on June 16th, you had agreed to move draft-ietf-mobileip-gnaie-00.txt to last call. I haven't seen a last call e-mail from you. Is a last call for this spec still in the cards? PatC ---- Date: Fri, 16 Jun 2000 13:43:08 -0500 Reply-To: Basavaraj.Patil@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: Re: WG Internet Drafts to last call... X-cc: Pat.Calhoun@Eng.Sun.COM Content-Type: text/plain; charset="iso-8859-1" Pat, >All, > >I was wondering if the following Internet Drafts could be moved to WG >last call, and sent to the IESG for publication: >1.draft-ietf-mobileip-mier-03.txt. >This one has already received interoperability, and I believe it is >ready. This one has already completed WG last call and has been submitted to the IESG. >2.draft-ietf-mobileip-aaa-key-01.txt. This one was also sucessfully >tested at the last connectathon, and should be moved ahead. References to DIAMETER in this document need to be removed and also the use of MD5 as suggested in the draft needs to be updated to be more in-line with the FA challenge draft (ver.12). Maybe you should reissue a new draft and then we can do a WG last call. >3.draft-ietf-mobileip-gnaie-00.txt. This fairly non-controversial >draft is a no-brainer and should be moved ahead as well. Sounds reasonable. > >Thanks, > >PatC -Basavaraj From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jul 11 18:14:45 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21884 for ; Tue, 11 Jul 2000 18:14:45 -0400 (EDT) Received: from standards (47.234.32.16:2934) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D0DD@standards.nortelnetworks.com>; Tue, 11 Jul 2000 18:04:01 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0519 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jul 2000 18:04:01 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D0DC@standards.nortelnetworks.com>; Tue, 11 Jul 2000 18:04: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 PAA02343 for ; Tue, 11 Jul 2000 15:14:07 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id PAA00462 for ; Tue, 11 Jul 2000 15:14:04 -0700 X-Virus-Scanned: Tue, 11 Jul 2000 15:14:04 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdvIlrhO; Tue, 11 Jul 2000 15:13:56 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <38A4588D.92FCE771@alcatel.be> <38A4951C.A369B13F@iprg.nokia.com> <00021414482106.24820@tpce13> <38BB4A9F.34ACF492@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <396B9C27.FAB4C9D4@iprg.nokia.com> Date: Tue, 11 Jul 2000 15:13: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] micromobility in IPv6 ? To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello folks, I am preparing a new revision for RFC2002bis, incorporating all of the comments over the past months. Recently, RFC 2794 has been promoted to Proposed Standard. This specification makes it legal for a Mobile IP registration message to be accepted by the Home Agent without containing a Mobile-Home authentication extension. Therefore, I propose to change the relevant portions of RFC2002bis to allow for this possibility. I hope this is O.K. It is a lot of work! I expect that I will make it more easily digestible by defining a new piece of terminology called something like "Admissible Authentication Extension", where admissible means admissible to the home agent. This might otherwise be ambiguous, except that in RFC2002bis there is only one context where it matters. Comments? Sorry for the short notice, but like everybody else I put this task off a little too long for extended debate. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jul 11 18:49:31 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22486 for ; Tue, 11 Jul 2000 18:49:31 -0400 (EDT) Received: from standards (47.234.32.16:1068) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D12D@standards.nortelnetworks.com>; Tue, 11 Jul 2000 18:38:58 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0611 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jul 2000 18:38:58 -0400 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D122@standards.nortelnetworks.com>; Tue, 11 Jul 2000 18:28:58 -0400 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA02571; Tue, 11 Jul 2000 15:39:06 -0700 (PDT) Received: from atlantic.East.Sun.COM (atlantic.East.Sun.COM [129.148.174.27]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA23069; Tue, 11 Jul 2000 18:39:05 -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 SAA28778; Tue, 11 Jul 2000 18:39:56 -0400 (EDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Tue, 11 Jul 2000 18:38:59 -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] micromobility in IPv6 ? X-To: charliep@IPRG.NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <396B9C27.FAB4C9D4@iprg.nokia.com> > Hello folks, > > I am preparing a new revision for RFC2002bis, incorporating all > of the comments over the past months. How about the comments on the "V" bit? Yes, late for anything resembling extended debate... > Recently, RFC 2794 has been promoted to Proposed Standard. > This specification makes it legal for a Mobile IP registration > message to be accepted by the Home Agent without containing > a Mobile-Home authentication extension. Therefore, I propose > to change the relevant portions of RFC2002bis to allow for this > possibility. > > I hope this is O.K. It is a lot of work! I expect that I will > make it more easily digestible by defining a new piece of > terminology called something like "Admissible Authentication Extension", > where admissible means admissible to the home agent. ^^^^^^^^^^ More like the "home authentication agent", which is similar to 'home agent' only it may not be the home agent doing the authenticating? Cheers, Steve From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jul 11 19:11:31 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22842 for ; Tue, 11 Jul 2000 19:11:31 -0400 (EDT) Received: from standards (47.234.32.16:4332) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D1A3@standards.nortelnetworks.com>; Tue, 11 Jul 2000 19:00:59 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0790 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jul 2000 19:00:59 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D1A2@standards.nortelnetworks.com>; Tue, 11 Jul 2000 19:00:59 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA08834; Tue, 11 Jul 2000 16:11:09 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id QAA16086; Tue, 11 Jul 2000 16:11:06 -0700 X-Virus-Scanned: Tue, 11 Jul 2000 16:11:06 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdNFZNG9; Tue, 11 Jul 2000 16:11:02 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <396BA989.AC651E2A@iprg.nokia.com> Date: Tue, 11 Jul 2000 16:11:05 -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] micromobility in IPv6 ? X-To: Steven Glass - Solaris Software To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Steve, I'll take the `V' bit out unless somebody complains. I never implemented it either. > How about the comments on the "V" bit? Yes, late for anything resembling > extended debate... > > I hope this is O.K. It is a lot of work! I expect that I will > > make it more easily digestible by defining a new piece of > > terminology called something like "Admissible Authentication Extension", > > where admissible means admissible to the home agent. > ^^^^^^^^^^ > More like the "home authentication agent", which is similar to 'home > agent' only it may not be the home agent doing the authenticating? Well, all that is needed is that whatever authentication is performed has to be _acceptable_ to the home agent. So, I sort-of like the "admissible" terminology better for that reason, but I'm still open to suggestion... Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jul 12 00:41: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 AAA29356 for ; Wed, 12 Jul 2000 00:40:59 -0400 (EDT) Received: from standards (47.234.32.16:3994) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D258@standards.nortelnetworks.com>; Wed, 12 Jul 2000 0:30:00 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1034 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jul 2000 00:30:00 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D251@standards.nortelnetworks.com>; Wed, 12 Jul 2000 0:20:00 -0400 Received: from correo.interlink.es (correo.interlink.es [194.224.34.22]) by hosaka.smallworks.com (8.9.1/8.9.1) with SMTP id XAA08257 for ; Tue, 11 Jul 2000 23:30:10 -0500 (CDT) Received: from stacy (unverified [216.78.230.161]) by correo.interlink.es (EMWAC SMTPRS 0.83) with SMTP id ; Wed, 12 Jul 2000 06:30:09 +0200 Message-ID: Date: Wed, 12 Jul 2000 06:30:09 +0200 Reply-To: stacy2@SONICNETMAIL.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: stacy2@SONICNETMAIL.COM Subject: [MOBILE-IP] ByOwner Income Opportunity To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM ByOwner Income Opportunity Be your own boss! Help people sell BY OWNER! Now you can make money working from home or add to your existing income. No Real Estate experience is necessary! You can become a BYOWNER COACH WE WILL TRAIN YOU TO HELP SOME OF THE OVER 1 MILLION HOME SELLERS WHO SELL their OWN HOME EACH YEAR. These home sellers need advice, advertising and marketing power, and you're just the one to give it to them. We will train you on: - How to find FSBO's - How to close them on our services - How to integrate this program into your existing business - How to generate more dollars for you And we'll also: - Provide you with ad slicks - Provide you with leads! As you may already know, THIS MARKET IS HUGE! We support you 24 hrs a day 7 days a week via: - email - chat - 800# For The Full, Exciting Details, Send Your Phone # and Zip Code To: Mailto:fsbo-opp2@newmail.net 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! To unsubscribe mailto:unsubscribe708@newmail.net From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jul 12 10:38:58 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24960 for ; Wed, 12 Jul 2000 10:38:56 -0400 (EDT) Received: from standards (47.234.32.16:4739) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D5A8@standards.nortelnetworks.com>; Wed, 12 Jul 2000 10:28:05 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2173 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jul 2000 10:28:05 -0400 Received: from prue.eim.surrey.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D5A5@standards.nortelnetworks.com>; Wed, 12 Jul 2000 10:18:05 -0400 Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 13CNUn-0000ok-00 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jul 2000 15:28:17 +0100 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Wed, 12 Jul 2000 15:28:17 +0100 Reply-To: Eleftheria Menegou Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Eleftheria Menegou Subject: [MOBILE-IP] PRMA Implementation To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Dear All: I am working towards my MSc thesis and currently studying the PRMA protocol. As I am new in this field, is any one that can provide me with a prototype implementation of PRMA to have this as a reference point on my study? I am working with MAISIE/PARSEC and C. Thanks in advance. Eleftheria From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jul 12 11:41:07 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28329 for ; Wed, 12 Jul 2000 11:41:06 -0400 (EDT) Received: from standards (47.234.32.16:4739) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D667@standards.nortelnetworks.com>; Wed, 12 Jul 2000 11:30:02 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2437 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jul 2000 11:30:02 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D666@standards.nortelnetworks.com>; Wed, 12 Jul 2000 11:30:02 -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 IAA16997; Wed, 12 Jul 2000 08:40:15 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id IAA04257; Wed, 12 Jul 2000 08:40:11 -0700 X-Virus-Scanned: Wed, 12 Jul 2000 08:40:11 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdY5eqyY; Wed, 12 Jul 2000 08:39:59 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <38FF86A8.563413B8@Motorola.Com> <002901bfab60$a3b63260$d012060a@hansol.co.kr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <396C9151.DD5B6617@iprg.nokia.com> Date: Wed, 12 Jul 2000 08:40:01 -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] Missing Terminology in RFC2002bis X-To: "Lee, Jiwoong" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Jiwoong Lee, I am processing more of the comments that you have submitted regarding RFC 2002bis. I appreciate that you have taken the time to contribute these ideas. As editor, and in consideration of the status of Mobile IP, I feel that changes to the document need to be selected very judiciously. Thus, I didn't add two of your suggested terminology definitions, for reasons as follows. > Authentication > The recipient of a message should be able to determine ho the actual > (real) originator of the message is. Here's what I wrote: The process of verifying (using cryptographic techniques, for all applications in this specification) the identity of the originator of a message. > Authorisation > Provide the ability to an organisation that owns and/or operates a > network to decide who may attach to the network resources may be > used by the attaching node. This term is not used in RFC2002bis, so I didn't use this definition. It is much more relevant to recent work done in the aaa-wg. > Location Privacy > Gives the ability to a sender of a message to control which, if any, > receivers know the location of the sender's current physical attachment > to the network. Location privacy is concerned with hiding the location > of > an MN from CN's. Location Privacy does not play a significant role in RFC2002{,bis}. There is a section describing privacy considerations, but it is self-contained. Therefore, defining this new term seems unnecessary for understanding the rest of the document, and unnecessary for understanding the privacy section. Thanks again for these comments. If you still think that the other two terms need to be defined, please send your additional comments to the mailing list. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jul 12 12:23:13 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00651 for ; Wed, 12 Jul 2000 12:23:13 -0400 (EDT) Received: from standards (47.234.32.16:3831) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D6CB@standards.nortelnetworks.com>; Wed, 12 Jul 2000 12:12:21 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2570 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jul 2000 12:12:21 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D6CA@standards.nortelnetworks.com>; Wed, 12 Jul 2000 12:12:20 -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 JAA21702 for ; Wed, 12 Jul 2000 09:22:33 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id JAA10895 for ; Wed, 12 Jul 2000 09:22:31 -0700 X-Virus-Scanned: Wed, 12 Jul 2000 09:22:31 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdSLo8PS; Wed, 12 Jul 2000 09:22:26 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <396C9B44.21520805@iprg.nokia.com> Date: Wed, 12 Jul 2000 09:22:28 -0700 Reply-To: charliep@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: [MOBILE-IP] New version of RFC2002bis To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello, I have almost completed editing the new revision of RFC2002bis. Here is the text of the appendix listing the changes: ========================================================================= This section lists the changes between this version (...-02.txt) and the previous version of the document. - Allowed registrations to be authenticated by use of a security association between the mobile node and a suitable authentication entity acceptable to the home agent. Defined "Admissible Authentication extension" to be an authentication extension that makes a registration message acceptable to the recipient. - Allowed registration replies to be processed by the mobile node, even in the absence of any Mobile-Home Authentication extension, when containing rejection code by the foreign agent. - Specified that the mobile node SHOULD take the first care-of address in a list offered by a foreign agent, and MAY try each subsequent advertised address in turn if the attempted registrations are rejected by the foreign agent - Eliminated Van-Jacobson Compression feature - Updated assigned numbers lists - Removed Open Issues - Still more syntax corrections and editorial improvements ======================================================================== I have made the following resolutions for the Open Issues: ------------------------------------------------------------------------ J. Open Issues - Whenever the foreign agent can change the Code in a Registration Reply from the home agent to indicate rejection, the mobile node can no longer check validity. This is also true if the foreign agent can change the granted lifetime in a Registration Reply. On the other hand, the mobile node could re-calculate with its record of what Lifetime it had requested, or assuming that the registration Code was a successful code. Should the revised draft specify these behaviors? Answer: This is addressed by allowing rejection codes to be processed by the mobile node. If a foreign agent rejects registrations, and it is bogus, then you don't want to use that foreign agent anyway. If the foreign agent changes the lifetime, the authentication is bad and the mobile node SHOULD NOT believe it. The foreign agent can send back a modified Registration Reply with a rejection Code if it doesn't like the home agent's modified Lifetime. This is already covered by the draft. ------------------------------------------------------------------------ - Should we just get rid of the possibility of considering the Router Addresses in Agent Advertisements? Answer: If anyone wants to suggest some further changes to the draft, then the working group can discuss the changes. Until then, I don't see any substantial reason to make further changes. ------------------------------------------------------------------------ - From the mailing list: Q: new FA forwarding text; sometimes two MNs on the same FA sometimes get traffic forwarded directly rather than via HA. Also MNs can introduce denial of service if they make a mistake in their registration messages - sometimes re-registrations can be redirected at a MN! Is anything needed here? Answer: This is done better by using Binding Updates from the Route Optimization draft. Thus, it should not be considered an open issue for RFC 2002bis. ------------------------------------------------------------------------ - What does a home agent do with a reverse-tunneled broadcast packet? Does it send the broadcast on the appropriate network interface? Does it drop the packet? Does the behavior depend on whether the mobile node set the 'B' bit in its Registration Request? Answer: These behaviors should be specified by the revised Reverse Tunneling draft. I suggest moving the open issue to that draft. ------------------------------------------------------------------------ If the changes, and the resolutions to the open issues are acceptable, I think the draft is ready for Last Call to Draft Standard. Regards, Charlie P. PS. I will send the URL for the revised RFC2002bis soon. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jul 12 15:02: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 PAA09154 for ; Wed, 12 Jul 2000 15:02:42 -0400 (EDT) Received: from standards (47.234.32.16:2309) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D7B0@standards.nortelnetworks.com>; Wed, 12 Jul 2000 14:51:43 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2826 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jul 2000 14:51:43 -0400 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D790@standards.nortelnetworks.com>; Wed, 12 Jul 2000 14:41:42 -0400 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA29139; Wed, 12 Jul 2000 11:51:47 -0700 (PDT) Received: from atlantic.East.Sun.COM (atlantic.East.Sun.COM [129.148.174.27]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA22971; Wed, 12 Jul 2000 14:45:25 -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 OAA00445; Wed, 12 Jul 2000 14:46:16 -0400 (EDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Wed, 12 Jul 2000 14:43:01 -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] micromobility in IPv6 ? X-To: charliep@IPRG.NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <396BA989.AC651E2A@iprg.nokia.com> > Hello Steve, > > I'll take the `V' bit out unless somebody complains. I never > implemented it either. I don't think it's even implementable, but as I've never tried, how would I know! Personally, my take is if the bit can be shown to have been unimplimentable, we can label it reserved for now, and reuse it later, though I don't know how the general internet community feels about this. Another argument is as 2002-bis is going to obsolete 2002, only people with current Mobile IP implementations [of the V-bit] can object (and SHOULD object!); anyone implementing in the future should be implementing to 2002-bis as RFC, so if there are no objections now... (nice theory, but does it work?) > > > I hope this is O.K. It is a lot of work! I expect that I will > > > make it more easily digestible by defining a new piece of > > > terminology called something like "Admissible Authentication Extension", > > > where admissible means admissible to the home agent. > > ^^^^^^^^^^ > > More like the "home authentication agent", which is similar to 'home > > agent' only it may not be the home agent doing the authenticating? > > Well, all that is needed is that whatever authentication is performed > has to be _acceptable_ to the home agent. So, I sort-of like the > "admissible" terminology better for that reason, but I'm still open > to suggestion... We're comming towards the same point from different sides, so lets just get a little closer. "Admissible Mobile-Home Authentication Extension" where admissible means authenticated in a way acceptable to the home agent. This means we can also use the term "Admissible Mobile-Foreign Authentication Extension" where admissible means authenticated in a way acceptable to the foreign agent (FA passes M-F authentication extension to its AAA server, etc), and "Admissible Foreign-Home Authentication Extension", etc... Cheers, Steve From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jul 12 16:00:24 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11627 for ; Wed, 12 Jul 2000 16:00:23 -0400 (EDT) Received: from standards (47.234.32.16:1846) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D820@standards.nortelnetworks.com>; Wed, 12 Jul 2000 15:49:39 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2973 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jul 2000 15:49:39 -0400 Received: from motgate2.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D7FC@standards.nortelnetworks.com>; Wed, 12 Jul 2000 15:39:39 -0400 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id MAA13199 for ; Wed, 12 Jul 2000 12:49:52 -0700 (MST)] Received: [from il02exi01.comm.mot.com (il02exi01.comm.mot.com [145.1.204.40]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id MAA10259 for ; Wed, 12 Jul 2000 12:49:52 -0700 (MST)] Received: by il02exi01.comm.mot.com with Internet Mail Service (5.5.2650.21) id <3X56VHHD>; Wed, 12 Jul 2000 14:49:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <1DA6058E1005D411BC0600805F31E078616C8D@il02exi01.comm.mot.com> Date: Wed, 12 Jul 2000 14:49:49 -0500 Reply-To: Stanaway Chris-CCS018 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Stanaway Chris-CCS018 Subject: Re: [MOBILE-IP] micromobility in IPv6 ? To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > From: Steven Glass - Solaris Software > > > Hello Steve, > > > > I'll take the `V' bit out unless somebody complains. I never > > implemented it either. > > I don't think it's even implementable, but as I've never > tried, how would > I know! Personally, my take is if the bit can be shown to have been > unimplimentable, we can label it reserved for now, and reuse > it later, though > I don't know how the general internet community feels about > this. Another > argument is as 2002-bis is going to obsolete 2002, only > people with current > Mobile IP implementations [of the V-bit] can object (and > SHOULD object!); > anyone implementing in the future should be implementing to > 2002-bis as RFC, > so if there are no objections now... (nice theory, but does it work?) I would like to see the V bit marked as obsoleted rather than reserved for some other future use. Chris From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jul 12 16:13:07 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12070 for ; Wed, 12 Jul 2000 16:13:06 -0400 (EDT) Received: from standards (47.234.32.16:1846) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D868@standards.nortelnetworks.com>; Wed, 12 Jul 2000 16:02:23 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3117 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jul 2000 16:02:23 -0400 Received: from mgw-x1.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D867@standards.nortelnetworks.com>; Wed, 12 Jul 2000 16:02:23 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nok.ntc.nokia.com [131.228.10.150]) by mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id XAA24345 for ; Wed, 12 Jul 2000 23:12:35 +0300 (EETDST) Received: from daebh02nok.americas.nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Wed, 12 Jul 2000 23:12:35 +0300 Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id <3VXA7C92>; Wed, 12 Jul 2000 15:12:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E04A@daeis07nok> Date: Wed, 12 Jul 2000 15:10:03 -0500 Reply-To: Basavaraj.Patil@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: [MOBILE-IP] WG Last Call - draft-ietf-mobileip-gnaie-00.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is the Mobile IP Working group last call on draft-ietf-mobileip-gnaie-00.txt before sending it on to IETF Last call. This draft is recommended for Standards track. If you have any comments on it, please send them to the authors or to the Mobile IP WG mailing list BEFORE July 27, 2000. http://www.ietf.org/internet-drafts/draft-ietf-mobileip-gnaie-00.txt -Basavaraj (For Basavaraj and Phil) From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jul 12 16:24:42 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12749 for ; Wed, 12 Jul 2000 16:24:42 -0400 (EDT) Received: from standards (47.234.32.16:1846) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D8B3@standards.nortelnetworks.com>; Wed, 12 Jul 2000 16:12:10 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3221 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jul 2000 16:12:10 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D8B2@standards.nortelnetworks.com>; Wed, 12 Jul 2000 16:12:09 -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 NAA18012; Wed, 12 Jul 2000 13:22:23 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id NAA14511; Wed, 12 Jul 2000 13:22:20 -0700 X-Virus-Scanned: Wed, 12 Jul 2000 13:22:20 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdzPt4vq; Wed, 12 Jul 2000 13:22:15 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <396CD378.8C7A929D@iprg.nokia.com> Date: Wed, 12 Jul 2000 13:22:16 -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] micromobility in IPv6 ? X-To: Steven Glass - Solaris Software To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Mr. Solaris Software, As I understand it, you would like to have a proper (and general) definition for "admissible authentication extension", even though RFC 2002bis does not need the extra generality. Here is what I've come up with, in the Terminology section: ============================================================================== Admissible Authentication extension An authentication which makes a (registration) message acceptable to the ultimate recipient of the registration message. In this document, all uses of admissible authentication extension refer to authentication extensions that enable the Registration Request message to be acceptable to the home agent. Using additional protocol structures specified outside of this document, it may be possible for the mobile node to provide authentication of its registration to the home agent, by way of another authenticating entity within the network that is acceptable to the home agent (for example, see RFC 2794 [5]). An admissible authentication extension MUST contain an SPI. ============================================================================== Plus, I made the clarification later in the text that an admissible authentication extension to the Registration Request _MUST_ be the _first_ authentication extension. Hope this works! Regards, Charlie P. PS. Just kidding about the appellation... :-) Steven Glass - Solaris Software wrote: >> Well, all that is needed is that whatever authentication is performed >> has to be _acceptable_ to the home agent. So, I sort-of like the >> "admissible" terminology better for that reason, but I'm still open >> to suggestion... > > We're comming towards the same point from different sides, so lets just > get a little closer. "Admissible Mobile-Home Authentication Extension" where > admissible means authenticated in a way acceptable to the home agent. This > means we can also use the term "Admissible Mobile-Foreign Authentication > Extension" where admissible means authenticated in a way acceptable to the > foreign agent (FA passes M-F authentication extension to its AAA server, etc), > and "Admissible Foreign-Home Authentication Extension", etc... > > Cheers, > Steve From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jul 12 16:49:31 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14469 for ; Wed, 12 Jul 2000 16:49:31 -0400 (EDT) Received: from standards (47.234.32.16:1846) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D939@standards.nortelnetworks.com>; Wed, 12 Jul 2000 16:38:50 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3368 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jul 2000 16:38:50 -0400 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D921@standards.nortelnetworks.com>; Wed, 12 Jul 2000 16:28:50 -0400 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA18546; Wed, 12 Jul 2000 13:39:01 -0700 (PDT) Received: from atlantic.East.Sun.COM (atlantic.East.Sun.COM [129.148.174.27]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA12008; Wed, 12 Jul 2000 16:39:00 -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 QAA00948; Wed, 12 Jul 2000 16:39:51 -0400 (EDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Wed, 12 Jul 2000 16:38:55 -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] micromobility in IPv6 ? X-To: "Charles E. Perkins" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <396CD378.8C7A929D@iprg.nokia.com> > > Hello Mr. Solaris Software, Hi, Mr. Nokia! > As I understand it, you would like to have a proper (and general) > definition for "admissible authentication extension", even though > RFC 2002bis does not need the extra generality. I just think if you're going to replace "allowable to the home link" with "allowable to the home domain" (in spirit), and add a term, it should be defined. > Here is what I've come up with, in the Terminology section: > > ============================================================================== > Admissible Authentication extension > An authentication which makes a (registration) message > acceptable to the ultimate recipient of the registration > message. In this document, all uses of admissible > authentication extension refer to authentication > extensions that enable the Registration Request message > to be acceptable to the home agent. Using additional > protocol structures specified outside of this document, > it may be possible for the mobile node to provide > authentication of its registration to the home agent, by > way of another authenticating entity within the network > that is acceptable to the home agent (for example, see > RFC 2794 [5]). An admissible authentication extension > MUST contain an SPI. > > ============================================================================== What about the other types of "admissible authentication extensions" such as MN-Foreign, and F-H? I'm not saying we need to define these in 2002-bis, but we shouldn't preclude these by not calling this the "Admissible Mobile-Home Authentication extension". There are extensions the MN sends the FA which may be authenticated (e.g. RFC2344, Vendor-specific, etc), which in the analogous authentication mechanisms on the foreign subnet may involve authenticators for the foreign AAA servers, and not specifically (only) the FA. (Actually, I think this is the crux of our entire discussion). I agree that *any* admissible authentication extension MUST contain an SPI. > Plus, I made the clarification later in the text that an admissible > authentication extension to the Registration Request _MUST_ be > the _first_ authentication extension. Again, this is because this definition of admissible authentication extension excludes everything except MN-HomeDomain. You can say, however, that an admissible mobile-home authentication extension MUST be the first authentication extension. Cheers, Steve From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jul 12 17:12:13 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15099 for ; Wed, 12 Jul 2000 17:12:13 -0400 (EDT) Received: from standards (47.234.32.16:1846) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D98F@standards.nortelnetworks.com>; Wed, 12 Jul 2000 17:01:33 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3512 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jul 2000 17:01:33 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D98E@standards.nortelnetworks.com>; Wed, 12 Jul 2000 17:01: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 OAA23370; Wed, 12 Jul 2000 14:11:46 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id OAA04317; Wed, 12 Jul 2000 14:11:43 -0700 X-Virus-Scanned: Wed, 12 Jul 2000 14:11:43 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpd0Hxgnj; Wed, 12 Jul 2000 14:11:38 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <396CDF0D.F1DFBDC2@iprg.nokia.com> Date: Wed, 12 Jul 2000 14:11:41 -0700 Reply-To: charliep@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: [MOBILE-IP] Admissible authentication extension terminology X-To: Steven Glass - Solaris Software To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello again Steve, Thanks for your comments to help illuminate what is needed here. > I just think if you're going to replace "allowable to the home link" with > "allowable to the home domain" (in spirit), and add a term, it should be > defined. I think it's important for RFC2002 to require allowable to the _home agent_. Anything else would push the specification too far past the limit of what would be considered refinement to a Proposed Standard. I don't want to take that step just yet. > What about the other types of "admissible authentication extensions" such > as MN-Foreign, and F-H? These are not prohibited by the suggested definition. In fact the definition was written exactly to make them allowable. Would it be better to make two paragraphs in the definition, so that the second paragraph could be construed to be specific only to the uses within RFC2002bis? > I'm not saying we need to define these in 2002-bis, > but we shouldn't preclude these by not calling this the "Admissible > Mobile-Home Authentication extension". Isn't the existing definition good enough, if everywhere in context it is clear that the admissibility is from the point of view of the home agent? > There are extensions the MN sends the > FA which may be authenticated (e.g. RFC2344, Vendor-specific, etc), which in > the analogous authentication mechanisms on the foreign subnet may involve > authenticators for the foreign AAA servers, and not specifically (only) the > FA. (Actually, I think this is the crux of our entire discussion). I agree with you, but I am not getting why it matters for the purposes of defining an admissible authentication extension. > > Plus, I made the clarification later in the text that an admissible > > authentication extension to the Registration Request _MUST_ be > > the _first_ authentication extension. > > Again, this is because this definition of admissible authentication > extension excludes everything except MN-HomeDomain. You can say, however, > that an admissible mobile-home authentication extension MUST be the first > authentication extension. Doesn't the original statement work if instead you understand it to mean something about the way the mobile node sends an authentication admissible from the point of view of the home agent? Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jul 12 17:53:14 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16367 for ; Wed, 12 Jul 2000 17:53:14 -0400 (EDT) Received: from standards (47.234.32.16:4518) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D9FE@standards.nortelnetworks.com>; Wed, 12 Jul 2000 17:42:36 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3657 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jul 2000 17:42:36 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D9FD@standards.nortelnetworks.com>; Wed, 12 Jul 2000 17:42:35 -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 PAA08767 for ; Wed, 12 Jul 2000 15:52:49 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA23924; Wed, 12 Jul 2000 14:52:47 -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 OAA22400; Wed, 12 Jul 2000 14:52:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: q+jFQPfHMsnretqSnCvVaQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Message-ID: <200007122152.OAA22400@nasnfs.eng.sun.com> Date: Wed, 12 Jul 2000 14:56:54 -0700 Reply-To: James Kempf Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: James Kempf Subject: [MOBILE-IP] Comparison of Fast Handoff and Proactive Handoff X-To: karim.el-malki@era.ericsson.se, hesham.soliman@ericsson.com.au To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Karim and Hesham, I just had an opportunity to look through your draft, draft-elmalki-mobile-ip-fast-handoffs-02.txt and compare it with the work that Pat and I are doing. A major and important difference from our work is that in the work we are doing agent advertisment beacons at L3 are not necessary, nor is there a need for the mobile node to register before receiving packets from the new FA. The old FA directs the new FA to take the handoff without the involvement of the mobile node, and the GFA registers the mobile for some period of time. The mobile, upon receiving packets from the new FA, then performs a full registration. This has a number of consequences: 1) The lack of need for L3 beacons means that there is no need to take up precious air time on a bearer channel for those radio systems (like 3G systems) where spectrum is licensed, and often very expensive. 2) The new FA has an opportunity to perform checks of QoS capacity and other resource checks before admitting the mobile. A new FA can additionally reject a handoff if taking the mobile would exceed the QoS capacity. In that case, the old FA can try to hand off the mobile to another FA before the mobile's signal fades to the point where packet drop becomes a problem. 3) As mentioned in my previous email, with our draft, it is possible to perform handoff between two RANs that are not directly connected at L2, although it would require some L2 support and some exchange of L2 information between the two disconnected RANs through L3. This is important for 3G systems, but probably not something the mobile IP group wants to dwell on, since it does involve L2 details. On the other hand, your draft proposes triangle routing elimination within the purview of the GFA without having to do binding updates, which is something that we haven't discussed in our draft. jak From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jul 12 19:18:49 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18053 for ; Wed, 12 Jul 2000 19:18:48 -0400 (EDT) Received: from standards (47.234.32.16:2429) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7DAA7@standards.nortelnetworks.com>; Wed, 12 Jul 2000 19:08:10 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3869 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jul 2000 19:08:09 -0400 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7DAA0@standards.nortelnetworks.com>; Wed, 12 Jul 2000 18:58:09 -0400 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA16478; Wed, 12 Jul 2000 16:08:17 -0700 (PDT) Received: from atlantic.East.Sun.COM (atlantic.East.Sun.COM [129.148.174.27]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA27973; Wed, 12 Jul 2000 19:08:16 -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 TAA01446; Wed, 12 Jul 2000 19:09:07 -0400 (EDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Wed, 12 Jul 2000 19:08:11 -0400 Reply-To: Steven Glass - Solaris Software Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Steven Glass - Solaris Software Subject: [MOBILE-IP] Another 2002-bis comment X-To: "Charles E. Perkins" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <396CDF0D.F1DFBDC2@iprg.nokia.com> Charlie, I'm working on my own draft right now, and as I refered to a section on the colocated MN, I realized another good example for Appendix D "Example Scenarios" would be the apparently always confusing situation of a colocated mobile node registering with a FA because it set the 'R' bit. (As if you don't have enough editing to do already!) Cheers, Steve From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jul 13 04:49:07 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10197 for ; Thu, 13 Jul 2000 04:49:04 -0400 (EDT) Received: from standards (47.234.32.16:5000) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7DC61@standards.nortelnetworks.com>; Thu, 13 Jul 2000 4:38:02 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4470 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Jul 2000 04:38:01 -0400 Received: from techtransfer.swift.shef.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7DC60@standards.nortelnetworks.com>; Thu, 13 Jul 2000 4:38:01 -0400 X-Mailer: Lotus Notes Release 5.0.1a (Intl) 17 August 1999 X-MIMETrack: Serialize by Router on TechTransfer/Swift(Release 5.0.4 |June 8, 2000) at 07/13/2000 09:54:46 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Message-ID: Date: Thu, 13 Jul 2000 09:54:42 +0100 Reply-To: Matthias.Kraner@SWIFT.SHEF.AC.UK Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Matthias Kraner Subject: Re: [MOBILE-IP] Comparison of Fast Handoff and Proactive Handoff X-To: James Kempf To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM James, Maybe you like to have a look at the following ID: 1. http URL:draft-cnyap-iip-00.txt Summary Title: Itinerant Internet Protocol There are some things in common (especially the issues with beacons). Matthias James Kempf To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Sent by: "IP Routing for cc: Wireless/Mobile Hosts Subject: [MOBILE-IP] Comparison of Fast Handoff and Proactive Handoff (mobile-ip)" 12/07/2000 22:56 Please respond to James Kempf Karim and Hesham, I just had an opportunity to look through your draft, draft-elmalki-mobile-ip-fast-handoffs-02.txt and compare it with the work that Pat and I are doing. A major and important difference from our work is that in the work we are doing agent advertisment beacons at L3 are not necessary, nor is there a need for the mobile node to register before receiving packets from the new FA. The old FA directs the new FA to take the handoff without the involvement of the mobile node, and the GFA registers the mobile for some period of time. The mobile, upon receiving packets from the new FA, then performs a full registration. This has a number of consequences: 1) The lack of need for L3 beacons means that there is no need to take up precious air time on a bearer channel for those radio systems (like 3G systems) where spectrum is licensed, and often very expensive. 2) The new FA has an opportunity to perform checks of QoS capacity and other resource checks before admitting the mobile. A new FA can additionally reject a handoff if taking the mobile would exceed the QoS capacity. In that case, the old FA can try to hand off the mobile to another FA before the mobile's signal fades to the point where packet drop becomes a problem. 3) As mentioned in my previous email, with our draft, it is possible to perform handoff between two RANs that are not directly connected at L2, although it would require some L2 support and some exchange of L2 information between the two disconnected RANs through L3. This is important for 3G systems, but probably not something the mobile IP group wants to dwell on, since it does involve L2 details. On the other hand, your draft proposes triangle routing elimination within the purview of the GFA without having to do binding updates, which is something that we haven't discussed in our draft. jak From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jul 13 06:09:52 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10855 for ; Thu, 13 Jul 2000 06:09:52 -0400 (EDT) Received: from standards (47.234.32.16:3455) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7DCE9@standards.nortelnetworks.com>; Thu, 13 Jul 2000 5:59:05 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4652 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Jul 2000 05:59:05 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7DCE8@standards.nortelnetworks.com>; Thu, 13 Jul 2000 5:59:05 -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.3) with ESMTP id e6DA9KM18402 for ; Thu, 13 Jul 2000 12:09:20 +0200 (MEST) Received: from SMTP ([153.88.251.32]) by esealnt409.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1); Thu, 13 Jul 2000 12:09:19 +0200 Received: from esealnt400.al.sw.ericsson.se ([153.88.251.21]) by 153.88.251.32 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 13 Jul 2000 10:09:19 0000 (GMT) Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id ; Thu, 13 Jul 2000 12:08:50 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 13 Jul 2000 10:09:19.0605 (UTC) FILETIME=[68C9C250:01BFECB2] Message-ID: <5F05C89FB2F8D211B6430008C791912703EA80F2@esealnt190> Date: Thu, 13 Jul 2000 12:09:17 +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] Comparison of Fast Handoff and Proactive Handoff X-To: James Kempf To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello James > I just had an opportunity to look through your draft, > draft-elmalki-mobile-ip-fast-handoffs-02.txt and compare it with the > work that Pat and I are doing. Thanks for the comments, it's good we've started discussing this. It would have been better though if you had looked at it before issuing your draft since we could have started this exchange of ideas earlier. Too bad :) > A major and important difference from our work is that in the > work we are doing agent advertisment beacons at L3 are not > necessary, nor > is there a need for the mobile node to register before receiving > packets from the new FA. The old FA directs the new FA to take > the handoff without the involvement of the mobile node, and the GFA > registers the mobile for some period of time. Yes. That was what I was talking about in my past email. You are performing registrations on behalf of the MN without the MN having any control on this or being aware that it is happening. I have reservations regarding this approach. First, this is different from RFC2002 and Regional Registrations, since the MN is not involved in the registration process. Also, say that the MN does not want to register with certain FAs. Hiding the L3 handoff procedure from the MN removes any possible L3 handoff control from the MN. Network control of L3 handoff is possible in both our approaches, but MN control of L3 handoff is not possible in your approach. > The mobile, upon > receiving packets from the new FA, then performs a full registration. I assume that one of these packets is an advertisement? > This has a number of consequences: > > 1) The lack of need for L3 beacons means that there is no need > to take up precious air time on a bearer channel for those > radio systems (like > 3G systems) where spectrum is licensed, and often very expensive. Well, it is not necessary to send advertisements all the time over the air. This saves spectrum. Some systems specify that advertisements should be sent over the air following L2 handoff. However I can't see how this relates specifically to your draft. Please expand. According to my understanding, in terms of spectrum there is no difference between our approaches. We have the MN register before the handoff while you have the MN register after the handoff. Therefore the same amount of messages (advertisements and registrations) are sent over the air, just the timing is different. > > 2) The new FA has an opportunity to perform checks of QoS > capacity and other > resource checks before admitting the mobile. A new FA can > additionally > reject a handoff if taking the mobile would exceed the QoS capacity. > In that case, the old FA can try to hand off the mobile to another > FA before the mobile's signal fades to the point where packet drop > becomes a problem. This can all be done in our approach too. The new FA can reject the MN's registration before the handoff, and multiple FAs may be advertised to the MN in case of failure etc.. Our advantage is that the MN is aware that it is registering and that it's registration is accepted/rejected. > > 3) As mentioned in my previous email, with our draft, it is possible > to perform handoff between two RANs that are not directly > connected at L2, > although it would require some L2 support and some exchange > of L2 information > between the two disconnected RANs through L3. This is important for > 3G systems, but probably not something the mobile IP group wants to > dwell on, since it does involve L2 details. I agree with you that we should not dwell on L2 details. However I don't agree that what you are saying above is necessarily an important thing for 3G systems. Radio networks don't always need to be directly connected, but they exchange messages which we consider as radio-specific L2 messages. That is our assumption which is applicable IMO and allows us to hide most L2 details and concentrate on generic L3 handoffs. Regards, Karim From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jul 13 10:18:43 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20311 for ; Thu, 13 Jul 2000 10:18:43 -0400 (EDT) Received: from standards (47.234.32.16:3601) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7DD9F@standards.nortelnetworks.com>; Thu, 13 Jul 2000 10:07:49 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4906 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Jul 2000 10:07:49 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7DD9E@standards.nortelnetworks.com>; Thu, 13 Jul 2000 10:07:49 -0400 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA13809 for ; Thu, 13 Jul 2000 08:18:04 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA28908; Thu, 13 Jul 2000 07:18:02 -0700 (PDT) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA11832; Thu, 13 Jul 2000 07:18:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Thu, 13 Jul 2000 07:17: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] Comparison of Fast Handoff and Proactive Handoff X-To: "Karim El-Malki (ERA)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <5F05C89FB2F8D211B6430008C791912703EA80F2@esealnt190> > Hello James > > > I just had an opportunity to look through your draft, > > draft-elmalki-mobile-ip-fast-handoffs-02.txt and compare it with the > > work that Pat and I are doing. > > Thanks for the comments, it's good we've started discussing this. > It would have been better though if you had looked at it before > issuing your draft since we could have started this exchange of > ideas earlier. Too bad :) I don't think it's too late. I believe that exchanging ideas in this fairly complicated, and possibly controversial space, can only benefit the WG. We need different mechanisms so that we can explore the alternatives, and agree on the best solution. It could very well be that the best solution is a combination of two or more. > > > A major and important difference from our work is that in the > > work we are doing agent advertisment beacons at L3 are not > > necessary, nor > > is there a need for the mobile node to register before receiving > > packets from the new FA. The old FA directs the new FA to take > > the handoff without the involvement of the mobile node, and the GFA > > registers the mobile for some period of time. > > Yes. That was what I was talking about in my past email. > You are performing registrations on behalf of the MN without > the MN having any control on this or being aware that it is happening. > I have reservations regarding this approach. First, this is different > from RFC2002 and Regional Registrations, since the MN is not involved > in the registration process. Also, say that the MN does not want to > register with certain FAs. Hiding the L3 handoff procedure from the > MN removes any possible L3 handoff control from the MN. The draft makes it clear that the Mobile Node MAY ignore packets from a Foreign Agent, and it certainly does not have to register with it either. Yes, it is different from RFC 2002 and the Regional Registration draft, but keep in mind that we are trying to solve a problem that I believe wasn't fully covered in those specs. btw, the FA is NOT registering on behalf of the Mobile Node, it is simply informing its GFA that a Mobile Node is entering its cell. The Mobile Node STILL needs to register. > > Network control of L3 handoff is possible in both our approaches, but > MN control of L3 handoff is not possible in your approach. Incorrect. The Mobile Node has full control over who it is willing to register with. If two FAs share a common GFA, then the draft does allow new FAs to receive traffic for the Mobile Node entering its cell before the registration occurs. However, this assumes that the GFA and FAs are under the same administrative control, so I see no harm since your traffic is already traversing that net. The advantage is that the Mobile Node sees virtually no packet drops as it moves into a new cell. > > > > The mobile, upon > > receiving packets from the new FA, then performs a full registration. > > I assume that one of these packets is an advertisement? Correct. > > > > This has a number of consequences: > > > > 1) The lack of need for L3 beacons means that there is no need > > to take up precious air time on a bearer channel for those > > radio systems (like > > 3G systems) where spectrum is licensed, and often very expensive. > > Well, it is not necessary to send advertisements all the time over the > air. This saves spectrum. Some systems specify that advertisements should > be sent over the air following L2 handoff. However I can't see how this > relates specifically to your draft. Please expand. We do not get into L2 advertisement issues in our draft, as the Mobile IP WG tries to stay away from L2 issues. Certainly, an air interface is more than welcome to add advertisements to their protocol. I agree that advertisements must be issued sparingly, but when should the FA issue them? That is the issue at hand. The longer the delay between a Mobile Node entering a cell, and receiving the advertisement, the longer the hand-off. We still require that the advertisements be sent by the FA to the MN, but service is already provided before registration (again, this is inter-domain). > > According to my understanding, in terms of spectrum there is no difference > between our approaches. We have the MN register before the handoff while > you have the MN register after the handoff. Therefore the same amount of > messages (advertisements and registrations) are sent over the air, just the > timing is different. But how long does it take for the MN to detect that it needs to perform the handoff? The timing is what fast hand-off is all about. > > > > > 2) The new FA has an opportunity to perform checks of QoS > > capacity and other > > resource checks before admitting the mobile. A new FA can > > additionally > > reject a handoff if taking the mobile would exceed the QoS capacity. > > In that case, the old FA can try to hand off the mobile to another > > FA before the mobile's signal fades to the point where packet drop > > becomes a problem. > > This can all be done in our approach too. The new FA can reject the > MN's registration before the handoff, and multiple FAs may be advertised > to the MN in case of failure etc.. Our advantage is that the MN is aware > that it is registering and that it's registration is accepted/rejected. same here. > > > > > 3) As mentioned in my previous email, with our draft, it is possible > > to perform handoff between two RANs that are not directly > > connected at L2, > > although it would require some L2 support and some exchange > > of L2 information > > between the two disconnected RANs through L3. This is important for > > 3G systems, but probably not something the mobile IP group wants to > > dwell on, since it does involve L2 details. > > I agree with you that we should not dwell on L2 details. However I don't > agree that what you are saying above is necessarily an important thing > for 3G systems. Radio networks don't always need to be directly connected, > but they exchange messages which we consider as radio-specific L2 messages. > That is our assumption which is applicable IMO and allows us to hide most > L2 details and concentrate on generic L3 handoffs. This is also NOT covered by the pro-active FA draft, and the draft works quite well without the propagation of L2 data, so let's not worry about this in this WG. PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jul 13 11:33: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 LAA24237 for ; Thu, 13 Jul 2000 11:33:14 -0400 (EDT) Received: from standards (47.234.32.16:4247) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7DE0D@standards.nortelnetworks.com>; Thu, 13 Jul 2000 11:22:14 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5049 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Jul 2000 11:22:13 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7DE0C@standards.nortelnetworks.com>; Thu, 13 Jul 2000 11:22:13 -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 IAA13353 for ; Thu, 13 Jul 2000 08:32:29 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id IAA07420 for ; Thu, 13 Jul 2000 08:32:28 -0700 X-Virus-Scanned: Thu, 13 Jul 2000 08:32:28 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdtwVrhO; Thu, 13 Jul 2000 08:32:21 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <396DE106.2F8D8A16@iprg.nokia.com> Date: Thu, 13 Jul 2000 08:32:22 -0700 Reply-To: charliep@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: [MOBILE-IP] draft-ietf-mobileip-rfc2002-bis-02.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello folks, I have the new revision prepared for RFC 2002bis. For those who are interested, please have a look: http://www.iprg.nokia.com/~charliep/txt/mobileip/mobileip.txt I'll probably send it in later today if there are no further comments... Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jul 13 12:57:43 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28850 for ; Thu, 13 Jul 2000 12:57:43 -0400 (EDT) Received: from standards (47.234.32.16:2594) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7DE4B@standards.nortelnetworks.com>; Thu, 13 Jul 2000 12:46:45 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5131 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Jul 2000 12:46:45 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7DE4A@standards.nortelnetworks.com>; Thu, 13 Jul 2000 12:46:40 -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.3) with ESMTP id e6DGutM26205 for ; Thu, 13 Jul 2000 18:56:55 +0200 (MEST) Received: from SMTP ([153.88.251.29]) by esealnt406.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1); Thu, 13 Jul 2000 18:56:55 +0200 Received: from esealnt172.ericsson.se ([130.100.184.165]) by 153.88.251.29 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 13 Jul 2000 16:56:55 0000 (GMT) Received: by esealnt172 with Internet Mail Service (5.5.2651.58) id <3Y6RGRD4>; Thu, 13 Jul 2000 18:56:06 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 13 Jul 2000 16:56:55.0767 (UTC) FILETIME=[59CBEE70:01BFECEB] Message-ID: <5F05C89FB2F8D211B6430008C791912703EA80F4@esealnt190> Date: Thu, 13 Jul 2000 18:56:51 +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] Comparison of Fast Handoff and Proactive Handoff X-To: "pcalhoun@eng.sun.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello Pat > I don't think it's too late. I believe that exchanging ideas > in this fairly > complicated, and possibly controversial space, can only > benefit the WG. We > need different mechanisms so that we can explore the > alternatives, and agree > on the best solution. It could very well be that the best > solution is a > combination of two or more. Of course, I fully agree and we need this discussion to take a step ahead in Pittsburgh. > > The draft makes it clear that the Mobile Node MAY ignore > packets from a > Foreign Agent, and it certainly does not have to register > with it either. Yes, > it is different from RFC 2002 and the Regional Registration > draft, but keep in > mind that we are trying to solve a problem that I believe > wasn't fully covered > in those specs. btw, the FA is NOT registering on behalf of > the Mobile Node, > it is simply informing its GFA that a Mobile Node is > entering its cell. The > Mobile Node STILL needs to register. OK, so my understanding was correct. However, you state in your draft that proactive FA plus Regional Registrations provide a complete fast-handoff solution for Mobile IP. I think proactive FA is not compatible with Regional Registrations. Also, as I already mentioned in previous emails, I don't like the word "cell" above since it implies L2 scenarios. As you say below, we don't want to get into L2 issues. Let me put what I wrote previously in another way. The GFA/FA establish some form of a binding with a small lifetime for the MN without involving the MN. Maybe this is a better description. > > > > Network control of L3 handoff is possible in both our > approaches, but > > MN control of L3 handoff is not possible in your approach. > > Incorrect. The Mobile Node has full control over who it is > willing to register > with. If two FAs share a common GFA, then the draft does > allow new FAs to > receive traffic for the Mobile Node entering its cell before > the registration > occurs. However, this assumes that the GFA and FAs are under the same > administrative control, so I see no harm since your traffic > is already > traversing that net. How is it possible for a MN to have control over L3 handoff if it isn't aware that a L3 handoff is occurring? I think the MN has no real control over the L3 handoff process since it doesn't perform movement detection and doesn't originate the (Regional) Registration Request message. When the MN stays within the same domain, the MN may not want to move to a certain RFA for a number of reasons (preference? cost?). You seem to assume that a MN will have no preference between FAs within a domain. IMO this is a limitation. > We do not get into L2 advertisement issues in our draft, as > the Mobile IP WG > tries to stay away from L2 issues. Certainly, an air > interface is more than > welcome to add advertisements to their protocol. What is a L2 advertisement? I don't know what you mean but this was never suggested. > > I agree that advertisements must be issued sparingly, but > when should the FA > issue them? That is the issue at hand. We cover this in our draft. > > > > According to my understanding, in terms of spectrum there > is no difference > > between our approaches. We have the MN register before the > handoff while > > you have the MN register after the handoff. Therefore the > same amount of > > messages (advertisements and registrations) are sent over > the air, just the > > timing is different. > > But how long does it take for the MN to detect that it needs > to perform the > handoff? With appropriate movement detection (which is probably the most important factor) this can be very fast. That's why we discuss this in our draft. > The timing is what fast hand-off is all about. Agreed. What you want to minimise is the disruption interval due to a handoff. That depends a lot on L2 and coordination between L2 and L3 handoffs. IMO we won't be able to answer this question (involving L2) and it shouldn't be our aim. We need to concentrate on minimizing L3 handoff delays without posing limitations on Mobile IP. > > > 3) As mentioned in my previous email, with our draft, > it is possible > > > to perform handoff between two RANs that are not directly > > > connected at L2, > > > although it would require some L2 support and some exchange > > > of L2 information > > > between the two disconnected RANs through L3. This is > important for > > > 3G systems, but probably not something the mobile IP > group wants to > > > dwell on, since it does involve L2 details. > > > > I agree with you that we should not dwell on L2 details. > However I don't > > agree that what you are saying above is necessarily an > important thing > > for 3G systems. Radio networks don't always need to be > directly connected, > > but they exchange messages which we consider as > radio-specific L2 messages. > > That is our assumption which is applicable IMO and allows > us to hide most > > L2 details and concentrate on generic L3 handoffs. > > This is also NOT covered by the pro-active FA draft, and the > draft works quite > well without the propagation of L2 data, so let's not worry > about this in this > WG. I'm a bit confused. You seem to have different views than James regarding this particular point, so I can't understand what the assumptions behind your draft are. As I said previously propagation of L2 data should not be an item here. Regards, /Karim From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jul 13 14:24:58 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04121 for ; Thu, 13 Jul 2000 14:24:58 -0400 (EDT) Received: from standards (47.234.32.16:4874) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7DE9D@standards.nortelnetworks.com>; Thu, 13 Jul 2000 14:14:03 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5239 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Jul 2000 14:14:03 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7DE9C@standards.nortelnetworks.com>; Thu, 13 Jul 2000 14:14:02 -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 MAA21030; Thu, 13 Jul 2000 12:24:05 -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 LAA06413; Thu, 13 Jul 2000 11:20:57 -0700 (PDT) Received: from sunray-mpkd (sunray-mpkd [129.146.6.31]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id LAA17865; Thu, 13 Jul 2000 11:20:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Thu, 13 Jul 2000 11:20:56 -0700 Reply-To: Gabriel Montenegro Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gabriel Montenegro Subject: Re: [MOBILE-IP] draft-ietf-mobileip-rfc2002-bis-02.txt X-To: charliep@IPRG.NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <396DE106.2F8D8A16@iprg.nokia.com> charlie, please change: 129 Traversal Extension [21] 130 Encapsulating Delivery Style Extension [22] to: 129 Traversal Extension [22] 130 Encapsulating Delivery Style Extension [21] -gabriel From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jul 13 14:42:58 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04917 for ; Thu, 13 Jul 2000 14:42:58 -0400 (EDT) Received: from standards (47.234.32.16:4874) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7DED8@standards.nortelnetworks.com>; Thu, 13 Jul 2000 14:32:11 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5319 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Jul 2000 14:32:11 -0400 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7DED7@standards.nortelnetworks.com>; Thu, 13 Jul 2000 14:32:10 -0400 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA08520; Thu, 13 Jul 2000 11:42:25 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.87.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id LAA03193; Thu, 13 Jul 2000 11:42:25 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with SMTP id e6DIgMj410763; Thu, 13 Jul 2000 11:42:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: L8QcFuMK2bQuFpblAsEovQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Message-ID: <200007131842.e6DIgMj410763@jurassic.eng.sun.com> Date: Thu, 13 Jul 2000 11:42:35 -0700 Reply-To: Samita Chakrabarti Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Samita Chakrabarti Subject: Re: [MOBILE-IP] draft-ietf-mobileip-rfc2002-bis-02.txt X-To: charliep@IPRG.NOKIA.COM X-cc: samita@jurassic.Eng.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi Charlie, I wanted to get back on the multicast section, but sorry for the delay. Section 4.4 on the rfc2002-bis draft is little bit confusing for implementors--when I read it first time, I was not clear at all on the requirements. So, I have some questions to clarify and I think it will be helpful for the community if that section is clarified. I haven't heard any implementation suporting multicast over the forward/reverse tunnel yet though. Second paragraph on section 4.4 writes: In order receive multicasts, a mobile node MUST join the multicast group in one of two ways. First, a mobile node MAY join the group via a (local) multicast router on the visited subnet. This option assumes that there is a multicast router present on the visited subnet. If the mobile node is using a co-located care-of address, it SHOULD use this address as the source IP address of its IGMP [8] messages. Otherwise, it MAY use its home address. So, if a MN joins the multicast group in the visitor network and if the FA is not a mcast router, then FA will not know about the MN's activity. I think, that's why in the 4th paragraph it says: Because multicast routing in general depends upon the IP source address, a mobile node which sends multicast datagrams directly on the visited network MUST use a co-located care-of address as the IP source address. ^^^^^^^^ SO, does it imply that *only* MN's using co-located care of address can join the multicast group directly in the foreign network ? If so, we need to clarify that in the second paragraph. So I can see steps in case 1)i,e sending mcast directly on the visited network : 1. Multicast router forwards the packet to CN in regular multicast routing path as MN joins the mcast group in foreign network. 2. The CNs will send multicast packet -- Now how HA will get this packet ? How does the packet come back to MN ? Does it mean that HA MUST be a mcast router always ? Currently it does not say so. Even if HA is a mcast router it has to know that MN with co-located care-of-addr has joined the particular group ? Thinking about this complicacy and providing two ways of sending multicast datagram seems to me complicate the whole protocol for implementation. I wonder, what if we restrict only one way of supporting multicast packets? option 1) I understand that air bandwith is expensive and cell phone folks do not like tunneling too much, so what if we just provide multicast capability for MNs with co-located care of address only ? option 2) For multicast packets, the MN will always encapsulate the mcast packet and FA must provide EDS service and HA must be a mcast router. MN joins the multicast group over FA-HA tunnel. Also, I don't completely understand the following text in third paragraph in section 4.4 : Alternatively, a mobile node which wishes to receive multicasts MAY join groups via a bi-directional tunnel to its home agent, assuming that its home agent is a multicast router. The mobile node tunnels IGMP messages to its home agent and the home agent forwards multicast datagrams down the tunnel to the mobile node. SO, I assume "bi-directional tunnel" above means that MN can encapsulate multicast packet with outer dst=HA and outer src= MN's home-addr. Also MN is capable of decapsulating any packets coming from HA for which the outer dest = MN's homeaddr and outer src=HAA. This seems to be not clear in the draft. A diagram similar to the following is helpful also: Datagram flowing from HA to FA forward tunnel when HA is a multicast router and it received a multicast packet for MN. -------------| |dst = COA | |src = HAA | outer IP hdr -------------| |dst = MN | |src =HAA | inner IP hdr1 -------------| |dst = MCAST | inner IP hdr2 |src = CN | -------------| Now the question is how HA keeps it binding list for multicast, if N number of MN's have joined the same MCAST group, then when HA gets a mcast packet for MCAST, it needs to forward through different nested tunnels and/or home network appropriately. I assume this should be part of normal multicast routing. I am not a multicast expert, so I don't have the proper answer. Thanks very much, -Samita > > I have the new revision prepared for RFC 2002bis. For those who > are interested, please have a look: > http://www.iprg.nokia.com/~charliep/txt/mobileip/mobileip.txt > > I'll probably send it in later today if there are no further > comments... > > Regards, > Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jul 13 16:58:12 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26783 for ; Thu, 13 Jul 2000 16:58:12 -0400 (EDT) Received: from standards (47.234.32.16:2136) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7DFF4@standards.nortelnetworks.com>; Thu, 13 Jul 2000 16:47:17 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5611 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Jul 2000 16:47:17 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7DFBB@standards.nortelnetworks.com>; Thu, 13 Jul 2000 16:37:16 -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 OAA04024; Thu, 13 Jul 2000 14:47:25 -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 QAA22007; Thu, 13 Jul 2000 16:46:40 -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 QAA28697; Thu, 13 Jul 2000 16:47:31 -0400 (EDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Thu, 13 Jul 2000 16:46:35 -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] Admissible authentication extension terminology X-To: "Charles E. Perkins" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <396CDF0D.F1DFBDC2@iprg.nokia.com> > > What about the other types of "admissible authentication extensions" > > such as MN-Foreign, and F-H? > > These are not prohibited by the suggested definition. In fact the > definition was written exactly to make them allowable. > > Would it be better to make two paragraphs in the definition, so that > the second paragraph could be construed to be specific only to the > uses within RFC2002bis? Well, I don't want this to start ballooning into it's own section (!). Actually, now that I'm seeing the document with this definition in context, this helps. The first paragraph of the definition in section 1.6 meets my generic requirements, and the second then says that 2002-bis only uses the term in the context of the "generic" mobile-to-home authenticator as being acceptable to the home agent. This is fine, except I don't think 2002-bis needs to confine itself only to the MN-HA bit. 2002[-bis] talks about MN-to-FA, FA-to-MN, and HA-to-FA which are all Admissible Authentication extensions (by the definition; please don't change it). In the AAA model, there may be a MN which includes a Mobile-to-Foriegn Admissible Authentication extension, which the FA relays to its AAA server, then gets an "alls-well" back. I see your point - 2002-bis shouldn't go there, and I agree, but I don't think 2002-bis needs to limit the discussion of "Admissible Authentication extensions" to only what's acceptable to the HA. Let me comment on specific sections to see if we can make our minds meet... >>2002-bis > > 3.5.2. Mobile-Home Authentication Extension > > Exactly one admissible authentication extension MUST be present in > all Registration Requests, and also in all Registration Replies > generated by the Home Agent. Do you mean *at least* one? "Exactly one" is required here because your earlier (section 1.6) "disclaimer" says the document doesn't (therefore can't) refer to AAE's in any other context except what's acceptable to the HA. What about MN->FA in the request, and HA->FA in the reply? These are also "admissible authentication extensions" by the definition in section 1.6. >>2002-bis > > 3.6.1.3. Extensions > > This section describes the ordering of any mandatory and any optional > Extensions that a mobile node appends to a Registration Request. > This following ordering MUST be followed: > > a) The IP header, followed by the UD header, followed by the > fixed-length portion of the Registration Request, followed by > > b) If present, any non-authentication Extensions expected to be > used by the home agent (which may or may not also be useful > to the foreign agent), followed by > > c) An admissible authentication extension, followed by > > d) If present, any non-authentication Extensions used only by > the foreign agent, followed by > > e) The Mobile-Foreign Authentication Extension, if present. Again, e) is a "admissible authentication extension" as defined by 1.6. If you change c) to read "An admissible mobile-home authentication extension", and e) to read "An admissible mobile-foreign authentication extention" then maybe my point is a little clearer. I also really like the way this is put in sectino 3.7.2.2: >>2002-bis: > > 3.7.2.2. Forwarding a Valid Request to the Home Agent ... > The foreign agent MUST NOT modify any of the fields beginning with the > fixed portion of the Registration Request up through and including the > Mobile-Home Authentication Extension or other authentication extension > supplied by the mobile node as an admissible authentication extension > for the home agent. ... Similarly, in section 3.8.2.1 section a) says something similar, but then it says "...if no admissible authentication extension is found, or if more than one admissible authentication extension is found, ..." which by the definition in section 1.6 is incorrect. "If no admissible mobile-home authentication extension is found, or if more than one admissible mobile-home authentication extension is found, ..." is accurate to the definition in section 1.6. If the FA attaches a FA-HA authenticator, then more than one admissible authentication extension may be found. I've tried to locate them all for you in case you want to update them as there isn't a lot of time left. I really feel the solution is to leave the definition generic, then specify which admissible authentication extension you mean in context. This wont change the specification more than what would be considered refinement to a Proposed Standard. Also, two off-topic comments I came across when searching out all "admissible" references: >>2002-bis: > > 3.2. Authentication > > Each mobile node, foreign agent, and home agent MUST be able to > support a mobility security association for mobile entities, indexed > by their SPI and IP address. Each mobile node doesn't have to support a mobility security association for mobile entities (unless you mean for itself). Also, HAs MUST be able to do this, FA's MAY (SHOULD?) be able to do this, and both FAs and HAs SHOULD (MUST?) be able to support mobility security associations for mobile entities indexed by SPI and NAI. It's probably best to break this section into two paragraphs, one for mobile nodes, the other for mobility agents. Section 3.6.2.1, paragraph "a)" the mobile node only checks for the presence of a mobile-foreign authenticator if the code indicates the registration was denied by the FA, and the MN and FA share a security association (that is, start 'a)' by saying "If the Code field indicates the service is denied by the foreign agent..."). Cheers, Steve From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jul 13 17:09:16 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01718 for ; Thu, 13 Jul 2000 17:09:16 -0400 (EDT) Received: from standards (47.234.32.16:2136) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E049@standards.nortelnetworks.com>; Thu, 13 Jul 2000 16:57:58 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5805 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Jul 2000 16:57:58 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E047@standards.nortelnetworks.com>; Thu, 13 Jul 2000 16:57:58 -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 PAA20946 for ; Thu, 13 Jul 2000 15:08:09 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA29021; Thu, 13 Jul 2000 14:08:06 -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 OAA22073; Thu, 13 Jul 2000 14:08:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: CnzyhB3uKlIGpG7wq0tnaw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Message-ID: <200007132108.OAA22073@nasnfs.eng.sun.com> Date: Thu, 13 Jul 2000 14:12:13 -0700 Reply-To: James Kempf Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: James Kempf Subject: Re: [MOBILE-IP] Comparison of Fast Handoff and Proactive Handoff X-To: Karim.El-Malki@ERA.ERICSSON.SE To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi Karim, (Apologies if this slipped off incomplete). Comments interspersed. >> >> The draft makes it clear that the Mobile Node MAY ignore >> packets from a >> Foreign Agent, and it certainly does not have to register >> with it either. Yes, >> it is different from RFC 2002 and the Regional Registration >> draft, but keep in >> mind that we are trying to solve a problem that I believe >> wasn't fully covered >> in those specs. btw, the FA is NOT registering on behalf of >> the Mobile Node, >> it is simply informing its GFA that a Mobile Node is >> entering its cell. The >> Mobile Node STILL needs to register. > >OK, so my understanding was correct. >However, you state in your draft that proactive FA plus Regional >Registrations provide a complete fast-handoff solution for Mobile IP. >I think proactive FA is not compatible with Regional Registrations. > Why do you think it isn't compatible? >Also, as I already mentioned in previous emails, I don't like the word >"cell" above since it implies L2 scenarios. As you say below, we don't >want to get into L2 issues. > >Let me put what I wrote previously in another way. The GFA/FA establish >some form of a binding with a small lifetime for the MN without >involving the MN. Maybe this is a better description. > Agreed. >> > >> > Network control of L3 handoff is possible in both our >> approaches, but >> > MN control of L3 handoff is not possible in your approach. >> >> Incorrect. The Mobile Node has full control over who it is >> willing to register >> with. If two FAs share a common GFA, then the draft does >> allow new FAs to >> receive traffic for the Mobile Node entering its cell before >> the registration >> occurs. However, this assumes that the GFA and FAs are under the same >> administrative control, so I see no harm since your traffic >> is already >> traversing that net. > >How is it possible for a MN to have control over L3 handoff if it >isn't aware that a L3 handoff is occurring? I think the MN has no >real control over the L3 handoff process since it doesn't perform >movement detection and doesn't originate the (Regional) Registration >Request message. When the MN stays within the same domain, the MN >may not want to move to a certain RFA for a number of reasons >(preference? cost?). You seem to assume that a MN will have no >preference between FAs within a domain. IMO this is a limitation. > It certainly becomes aware when the advertisement shows up, and could reject it at that point. However, I think this discussion is hiding the real issue. The fundamental difference between our proposal and yours is who has ultimate control over handoff, the network or the mobile . We are proposing that the network is in a much better position to perform functions such as load balancing, QoS determination, etc, especially in 3G-type networks, and therefore the network should be the final arbiter of where the mobile is placed. In your proposal, the mobile gets the final say over whether it will or will not take a handoff, so the network's decision could be overridden. There are a couple problems with giving the mobile the final say: 1) In wireless LAN networks where spectrum is free, cells are small, channels are shared, and a rich L2 hides the details of handoff from the mobile, there is really not much sense in having the network involved. If a particular cell gets congested, another access point can be installed for a couple hundred dollars or so, and in the interim, the user usually isn't paying for the spectrum anyway. In 3G networks, spectrum is very expensive, cells are large because the equipment is not cheap, channels aren't shared, and the L2 is pretty thin, since the mobility control is being done by the RAN protocol which is really an L5 protocol. An operator can't simply install another cell by going out and buying another access point as easily as in a wireless LAN, and users get very upset if their cell phone service is spotty because they are paying for it. Consequently, the operators want the network to have the ability to control where and when handoff occurs, so they can perform proper load balancing, etc., because, ultimately, their customers are paying them for maintaining "telephony quality" service. 2) If the mobile gets final say, then the mobile has to perform load balancing, QoS determination, etc. This means the mobile has to be considerably "fatter" in terms of its functionality. If we want to enable a new generation of mobile wireless network appliances, we are going to have to have a design in which the functionality impact of the fast handoff mobility design on the mobile is minimal. This leaves more room for the software that counts to the user, namely the application software. I realize that the "mobile gets final say" position is the traditional mobile IP position, but remember that originated from a wireless LAN base. The economics and engineering of 3G wireless WANs are considerably different. And our proposal isn't saying that "network gets the final say" is the right solution for all cases. In a wireless LAN, it may work just fine. >> We do not get into L2 advertisement issues in our draft, as >> the Mobile IP WG >> tries to stay away from L2 issues. Certainly, an air >> interface is more than >> welcome to add advertisements to their protocol. > >What is a L2 advertisement? I don't know what you mean but >this was never suggested. > Here's a quote from your draft: This solution assumes that the FA with which the MN is currently registered is aware of the IP address of the "new" FA which the MN is moving to. The method by which the current FA is informed of this may depend on interaction with L2 and is outside the scope of this draft. That sounds like an L2 advertisment to me. >> >> I agree that advertisements must be issued sparingly, but >> when should the FA >> issue them? That is the issue at hand. > >We cover this in our draft. > Your draft makes alot of assumptions about L2 interaction (including passage cited the above) with mobile IP that IMHO are trying to get around the need for a multicast L3 FA Advert. Our draft makes no such assumptions. We only require that: 1) The old FA, the mobile, and/or the new FA in conjunction be able to provide information about power level from possible candidate new RANs/access points, so the old FA can make a determination, based on information about network load and QoS availability, which candidate new FA is the appropriate one to hand the mobile off to. 2) There be some way for the old FA, in conjunction with the new FA and the mobile, to be able to initiate an L2 handoff. Both of these are within the capability of existing 3G RAN protocols (though not of 802.11, since it does handoff at L2 and tells the mobile and access point about it if they ask). >> > > 3) As mentioned in my previous email, with our draft, >> it is possible >> > > to perform handoff between two RANs that are not directly >> > > connected at L2, >> > > although it would require some L2 support and some exchange >> > > of L2 information >> > > between the two disconnected RANs through L3. This is >> important for >> > > 3G systems, but probably not something the mobile IP >> group wants to >> > > dwell on, since it does involve L2 details. >> > >> > I agree with you that we should not dwell on L2 details. >> However I don't >> > agree that what you are saying above is necessarily an >> important thing >> > for 3G systems. Radio networks don't always need to be >> directly connected, >> > but they exchange messages which we consider as >> radio-specific L2 messages. >> > That is our assumption which is applicable IMO and allows >> us to hide most >> > L2 details and concentrate on generic L3 handoffs. >> >> This is also NOT covered by the pro-active FA draft, and the >> draft works quite >> well without the propagation of L2 data, so let's not worry >> about this in this >> WG. > >I'm a bit confused. You seem to have different views than >James regarding this particular point, so I can't understand what >the assumptions behind your draft are. As I said previously >propagation of L2 data should not be an item here. > I think Pat and I agree that the mobile IP working group is not the place to get into details about where and how L2 data gets propagated over L3. However, I think we also agree that there are some 3G scenerios where exchanging L2 data over L3 is necessary. Whether IETF gets involved in specifying this is an open question at this point. jak From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jul 13 18:22:43 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27449 for ; Thu, 13 Jul 2000 18:22:42 -0400 (EDT) Received: from standards (47.234.32.16:2608) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E0BE@standards.nortelnetworks.com>; Thu, 13 Jul 2000 18:11:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5948 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Jul 2000 18:11:56 -0400 Received: from ux11.cso.uiuc.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E0B7@standards.nortelnetworks.com>; Thu, 13 Jul 2000 18:01:55 -0400 Received: from localhost by ux11.cso.uiuc.edu (8.10.1/8.10.1) with ESMTP id e6DMCC427094; Thu, 13 Jul 2000 17:12:12 -0500 (CDT) X-Authentication-Warning: ux11.cso.uiuc.edu: pairla owned process doing -bs X-Sender: pairla@ux11.cso.uiuc.edu MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Thu, 13 Jul 2000 17:12:12 -0500 Reply-To: Chandana Pairla Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Chandana Pairla Subject: Re: [MOBILE-IP] Comparison of Fast Handoff and Proactive Handoff X-cc: "pcalhoun@eng.sun.com" , James Kempf To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <5F05C89FB2F8D211B6430008C791912703EA80F4@esealnt190> >How is it possible for a MN to have control over L3 >handoff if it isn't aware that a L3 handoff is occurring? >I think the MN has no real control over the L3 handoff >process since it doesn't perform movement detection and >doesn't originate the (Regional) Registration Request >message. When the MN stays within the same domain, the MN >may not want to move to a certain RFA for a number of >reasons (preference? cost?). You seem to assume that a MN >will have no preference between FAs within a domain. IMO >this is a limitation. The handoff isnt completed until the MN registers with the "new" FA. Hence the MN has complete control over it. The draft only talks about preparing the "new" FA in anticipation of the arrival of the MN. After the MN arrives in the service area of the "new" FA it is upto it to accept or reject the FA. The MN is free to exercise its preference. >> > According to my understanding, in terms of spectrum there >> is no difference >> > between our approaches. We have the MN register before the >> handoff while >> > you have the MN register after the handoff. Therefore the >> same amount of >> > messages (advertisements and registrations) are sent over >> the air, just the >> > timing is different. Actually, your draft requires that a total of 5 messages need to be sent before the MN "can" recieve service from the new FA. On the other hand we require only 2 messages sent before the MN "can" recieve service. It is upto the MN to decide whether it want to accept the service or not. >> But how long does it take for the MN to detect that it needs >> to perform the >> handoff? > >With appropriate movement detection (which is probably the most >important factor) this can be very fast. That's why we discuss >this in our draft. > While your draft proposes the mobile handle this, we propose the network handle it. >Agreed. What you want to minimise is the disruption interval >due to a handoff. The issue is to minimize the interval of service disruption irrespective of whether it is due to a handoff or not. Regards, Chandana From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jul 13 18:32:49 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00138 for ; Thu, 13 Jul 2000 18:32:48 -0400 (EDT) Received: from standards (47.234.32.16:2608) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E10D@standards.nortelnetworks.com>; Thu, 13 Jul 2000 18:22:07 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6064 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Jul 2000 18:22:06 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E10C@standards.nortelnetworks.com>; Thu, 13 Jul 2000 18:22:06 -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 QAA19102 for ; Thu, 13 Jul 2000 16:32:22 -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 PAA20990 for ; Thu, 13 Jul 2000 15:32:21 -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 PAA24550 for ; Thu, 13 Jul 2000 15:32:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: c20tWwgQNUA5cSq4jkk9tA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Message-ID: <200007132232.PAA24550@nasnfs.eng.sun.com> Date: Thu, 13 Jul 2000 15:36:28 -0700 Reply-To: James Kempf Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: James Kempf Subject: Re: [MOBILE-IP] Comparison of Fast Handoff and Proactive Handoff To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM >However, I think this discussion is hiding the real issue. The fundamental >difference between our proposal and yours is who has ultimate >control over handoff, the network or the mobile . We are proposing that the >network is in a much better position to perform functions such as load >balancing, QoS determination, etc, especially in 3G-type networks, and therefore >the network should be the final arbiter of where the mobile is placed. In your >proposal, the mobile gets the final say over whether it will or will not take a >handoff, so the network's decision could be overridden. > I think I overstated my case here. Rather than "ultimate", I think I should have said "principle". There is nothing in our proposal to prevent the MN from rejecting the advertisement sent to it by the new FA. If it does, it risks losing service once the old FA signal fades. The MN could perform an FA solicitation to try to find another new FA, but if the network operator, as a policy decision, decides not to allow an FA to respond to the solicitation, then the MN is essentially hosed. Sorry. jak From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jul 13 22:43: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 WAA14941 for ; Thu, 13 Jul 2000 22:43:44 -0400 (EDT) Received: from standards (47.234.32.16:2843) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E216@standards.nortelnetworks.com>; Thu, 13 Jul 2000 22:32:59 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6418 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Jul 2000 22:32:58 -0400 Received: from breeze.research.telcordia.com (breeze-fddi.research.telcordia.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E211@standards.nortelnetworks.com>; Thu, 13 Jul 2000 22:22:58 -0400 Received: from research.telcordia.com (localhost [127.0.0.1]) by breeze.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e6E2XFJ15891 for ; Thu, 13 Jul 2000 22:33:15 -0400 (EDT) Message-ID: <200007140233.e6E2XFJ15891@breeze.research.telcordia.com> Date: Thu, 13 Jul 2000 22:33:15 -0400 Reply-To: Ashutosh Dutta Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Ashutosh Dutta Subject: [MOBILE-IP] "MobiCom 2000: Discounted registration ends on July 15" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM (Our apologies for duplicate transmission) ANNOUNCEMENT AND CALL FOR PARTICIPATION MobiCom 2000 The Sixth Annual International Conference on Mobile Computing and Networking August 6 - 11, 2000 Seaport Hotel at World Trade Center Boston Boston, Massachusetts, USA THE COMPLETE ADVANCE PROGRAM AND REGISTRATION INFORMATION ARE AVAILABLE AT ---------------------------------------------- http://www.research.telcordia.com/mobicom2000/ ---------------------------------------------- Sponsored by ACM SIGMOBILE In cooperation with ACM SIGCOMM and SIGMETRICS; IEEE Communications Society; the USENIX Association; the IEE (UK); the IEICE and IPSJ (Japan); the KICS (Korea); and the IFIP WG 6.3 With support from: IBM Research, HP Laboratories, Compaq,Nokia, TRW, AT&T Laboratories Cambridge, Xerox PARC, 3Com, BBN/GTE, Aether Systems, Nortel Networks, Metricom, Boston Communications Group, Toshiba America Research,ThinAirApps CONFERENCE HIGHLIGHTS --------------------- o Keynote Address: "Sentient Computing: The Interface is Everywhere," by Andy Hopper, Professor, University of Cambridge, and Managing Director, AT&T Laboratories Cambridge. o Technical Sessions: Twenty-eight technical papers will be presented describing previously unpublished research on a wide variety of topics in mobile computing and wireless networking, including prototype systems and networks, location support and data dissemination, packet scheduling and channel allocation, mobile internetworking, data management in mobile systems, and routing for ad hoc networks. Papers in a special session will challenge the community with new technologies and visionary applications. This year's conference received the largest number of paper submissions ever, resulting in a highly selective technical program. o Panels: We have organized two panels on timely issues with panelists who are passionate about these topics. P1: Comm'n Sense: Wireless Sensor Networks (Moderator: Deborah Estrin, UCLA and USC/ISI) P2: The Future Wireless Internet: Gazing Into the Crystal Ball (Moderator: Armando Fox, Stanford University) o Tutorials: There will be eight tutorials on cutting-edge topics: T1: Mobile IP for Current and Future Internet (David B. Johnson, CMU and Rice University) T2: Database Management Systems and Mobile Computing (Wang-Chien Lee, GTE Labs, Sandeep K.S. Gupta and Pradeep Srimani, Colorado State University) T3: Personal Area Networking Over Bluetooth (Pravin Bhagwat, AT&T Labs Research) T4: Service Discovery and Device Cooperation (Golden Richard III, University of New Orleans) T5: Energy Efficiency in Mobile Computing and Networking (Mani Srivastava, UCLA) T6: Mobile Voice over IP (Prathima Agrawal, Telcordia, Parmesh Ramanathan, University of Wisconsin, and Cormac J. Sreenan, University College Cork) T7: Mobile Ad Hoc Networks: Routing, MAC and Transport Issues (Nitin Vaidya, Texas A&M University) T8: Shaping the User Experience for Handheld Computing (Phillip B. Shoemaker, Palm Inc.) o Research Demos and Exhibits: The conference will also feature research demos from academic and industry research groups as well as the newest cutting edge products and services from a wealth of companies. o Workshops: Tackling the dominant issues of the day, the following workshops will allow extended considerations of particular topics. - Dial-M: Discrete Algorithms and Methods for Mobile Computing and Communications - WoWMoM: Wireless Mobile Multimedia - MSWiM: Modeling Analysis and Simulation of Wireless and Mobile Systems - MobiHOC: Mobile Ad Hoc Networking and Computing REGISTRATION ------------ The MobiCom 2000 web pages have all the conference registration and hotel reservation specific information: http://www.research.telcordia.com/mobicom2000/ Important Dates: July 7, 2000 -- Discounted hotel reservation deadline. July 15, 2000 -- Early conference registration deadline. Don't delay -- register today for MobiCom 2000. Come, celebrate the wireless revolution and its convergence with the Internet, on Boston's historic waterfront. It is THE conference to attend. We look forward to seeing you in Boston. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jul 14 01:22:51 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27772 for ; Fri, 14 Jul 2000 01:22:51 -0400 (EDT) Received: from standards (47.234.32.16:1700) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E295@standards.nortelnetworks.com>; Fri, 14 Jul 2000 1:11:54 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6591 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jul 2000 01:11:53 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E290@standards.nortelnetworks.com>; Fri, 14 Jul 2000 1:01:53 -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 WAA05823; Thu, 13 Jul 2000 22:12:11 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id WAA03330; Thu, 13 Jul 2000 22:12:08 -0700 X-Virus-Scanned: Thu, 13 Jul 2000 22:12:08 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from jmalinen.iprg.nokia.com (205.226.2.98, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdrLtMGE; Thu, 13 Jul 2000 22:12:03 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <200007132232.PAA24550@nasnfs.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <396EA125.62A259FC@iprg.nokia.com> Date: Thu, 13 Jul 2000 22:12:05 -0700 Reply-To: jmalinen@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Jari T. Malinen" Subject: Re: [MOBILE-IP] Comparison of Fast Handoff and Proactive Handoff X-To: James Kempf To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit James Kempf wrote: > >However, I think this discussion is hiding the real issue. The fundamental > >difference between our proposal and yours is who has ultimate > >control over handoff, the network or the mobile . We are proposing that the > >network is in a much better position to perform functions such as load > >balancing, QoS determination, etc, especially in 3G-type networks, and > therefore > >the network should be the final arbiter of where the mobile is placed. In your > >proposal, the mobile gets the final say over whether it will or will not take a > >handoff, so the network's decision could be overridden. > > > > I think I overstated my case here. Rather than "ultimate", I think I > should have said "principle". > > There is nothing in our proposal to prevent the MN from rejecting > the advertisement sent to it by the new FA. If it does, it risks > losing service once the old FA signal fades. The MN could perform > an FA solicitation to try to find another new FA, but if the network > operator, as a policy decision, decides not to allow an FA to respond > to the solicitation, then the MN is essentially hosed. > > Sorry. > > jak The discussion of proactive vs. reactive approach has brought up the fact that it is not easy to merge the two conflicting principles in the L2 systems vs. L3 protocols whose interaction is attempted with these relatively simple protocols. On the one hand, features known in the complex telecom systems often require tight network-controlled approach, on the other hand, the layered Internet protocols usually attempt to solve issues one-by-one separating concerns, with independence of the communication endpoint, and also counting on abundance of resources. Claiming that one is better than another, in particular when the L3 protocols should _also_ work with other technologies, leads to problems. If we really start to consider the many issues in resource control, traffic control, QoS, etc. we might see that the complexity of the one protocol might, after those additions, grow beyond reasonable. The separation of concerns that has worked quite nicely for Internet protocols should not be abandoned, instead, when experimenting with the idea of introducing these telecom-inspired features to the L3, we might want to consider a more flexible, frameworked approach. The we should have something where we have components that provide smooth handoff support for a combination of approaches, separated from other issues and we could address each issue separately. Regards, --jari Jari T. Malinen Nokia Research Center. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jul 14 06:13: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 GAA28262 for ; Fri, 14 Jul 2000 06:13:16 -0400 (EDT) Received: from standards (47.234.32.16:3626) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E345@standards.nortelnetworks.com>; Fri, 14 Jul 2000 6:02:10 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6836 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jul 2000 06:02:10 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E344@standards.nortelnetworks.com>; Fri, 14 Jul 2000 6:02:10 -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.3) with ESMTP id e6EACSM25366 for ; Fri, 14 Jul 2000 12:12:28 +0200 (MEST) Received: from SMTP ([153.88.251.32]) by esealnt409.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1); Fri, 14 Jul 2000 12:12:27 +0200 Received: from esealnt400.al.sw.ericsson.se ([153.88.251.21]) by 153.88.251.32 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 14 Jul 2000 10:12:27 0000 (GMT) Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id ; Fri, 14 Jul 2000 12:11:55 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 14 Jul 2000 10:12:27.0880 (UTC) FILETIME=[036BFE80:01BFED7C] Message-ID: <5F05C89FB2F8D211B6430008C791912703EA80F6@esealnt190> Date: Fri, 14 Jul 2000 12:12:21 +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] Comparison of Fast Handoff and Proactive Handoff X-To: James Kempf To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello James > >OK, so my understanding was correct. > >However, you state in your draft that proactive FA plus Regional > >Registrations provide a complete fast-handoff solution for > Mobile IP. > >I think proactive FA is not compatible with Regional Registrations. > > > > Why do you think it isn't compatible? > OK, please correct me if I'm wrong. In your draft you create temporary bindings for the MN in the GFA and new RFA without having the MN issue a Regional Registration Request. I think that this is not according to the Regional Reg'n draft. > > It certainly becomes aware when the advertisement shows up, and could > reject it at that point. But the new FA already has a short/temporary binding for the MN and is receiving the MN's traffic. The MN may not want that FA to receive it's traffic at all and it can't control this. > However, I think this discussion is hiding the real issue. > The fundamental > difference between our proposal and yours is who has ultimate > control over handoff, the network or the mobile . This is not the difference. I think the difference is that your draft only allows network control while we are allowing both. Mobile IPv4 allows the MN to take a decision on performing a registration (e.g. movement detection) and also allows the FA to accept/reject it before any binding is created. So we leave both options open. Indeed, if it is decided that only network control is required then your draft fits the requirement. However, if the option to have MN control is needed then it does not satisfy this. To clarify my point: In your draft, the new FA already has a binding for the MN when the time comes for the MN to take control of the new registration. So the new FA is already receiving traffic for the MN, and the MN may then decide whether to extend the binding or not. IMO that is different from taking control of the L3 handoff. In your draft the MN may decide to reject the L3 handoff (binding with the new FA) after the L3 handoff (binding with new FA) has happened. This is the issue I was trying to bring to your attention. We are > proposing that the > network is in a much better position to perform functions > such as load > balancing, QoS determination, etc, especially in 3G-type > networks, and therefore > the network should be the final arbiter of where the mobile > is placed. In your > proposal, the mobile gets the final say over whether it will > or will not take a > handoff, so the network's decision could be overridden. The MN does not get the final say since the new RFA/intermediate RFA/GFA may reject the Registration. Also, the network may even not advertise the new RFA to the MN if the network decides that this L3 handoff should not happen. > I realize that the "mobile gets final say" position is the > traditional > mobile IP position, but remember that originated from a wireless > LAN base. As above, I don't agree since the FA may reject a Registration Request and thus the network gets the final say. > The economics and engineering of 3G wireless WANs are > considerably different. And our proposal isn't saying that "network > gets the final say" is the right solution for all cases. In > a wireless > LAN, it may work just fine. Yes, I also know something about 3G ;) However you seem to be taking radio-specific L2 considerations when saying that the "network gets the final say". We are working at L3 though and I'm not sure whether we should be too dependent on technology-specific requirements now. > Here's a quote from your draft: > > This solution assumes that the FA with which the MN is currently > registered is aware of the IP address of the "new" FA > which the MN is > moving to. The method by which the current FA is informed > of this may > depend on interaction with L2 and is outside the scope of > this draft. > > That sounds like an L2 advertisment to me. > No. Nothing to do with an advertisement. It relates to the radio network specific messaging and control in the network. > >> > >> I agree that advertisements must be issued sparingly, but > >> when should the FA > >> issue them? That is the issue at hand. > > > >We cover this in our draft. > > > > Your draft makes alot of assumptions about L2 interaction (including > passage cited the above) with mobile IP that IMHO are trying to > get around the need for a multicast L3 FA Advert. Our draft makes > no such assumptions. Again, I think there is some misunderstanding regarding the advertisement you mentioned before. Our assumptions on L2 are quite simple. > We only require that: > > 1) The old FA, the mobile, and/or the new FA in conjunction > be able to provide > information about power level from possible candidate new > RANs/access points, so the old FA can make a determination, based on > information about network load and QoS availability, which > candidate new FA > is the appropriate one to hand the mobile off to. I don't understand your focus on power levels and radio issues. Your underlying principle seems to be to replace L2 functionality and messaging with L3. I don't think this is part of L3 Fast handoffs. > > I think Pat and I agree that the mobile IP working group is not > the place to get into details about where and how L2 data gets > propagated over L3. However, I think we also agree that > there are some > 3G scenerios where exchanging L2 data over L3 is necessary. Whether > IETF gets involved in specifying this is an open question at > this point. OK, but what is not clear to me is that your explanations above often rely on this assumption. My understanding is that the proactive draft is a step in that direction. Regards, Karim From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jul 14 07:05:40 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14205 for ; Fri, 14 Jul 2000 07:05:39 -0400 (EDT) Received: from standards (47.234.32.16:1870) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E38E@standards.nortelnetworks.com>; Fri, 14 Jul 2000 6:54:54 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6932 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jul 2000 06:54:53 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E38D@standards.nortelnetworks.com>; Fri, 14 Jul 2000 6:44:53 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10137; Fri, 14 Jul 2000 06:55:12 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200007141055.GAA10137@ietf.org> Date: Fri, 14 Jul 2000 06:55:11 -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-tsao-mobileip-duelstack-model-00.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mobility Support for IPv4 and IPv6 Interconnected Networks based on Dual-Stack Model Author(s) : S. Tsao, J. Liu Filename : draft-tsao-mobileip-duelstack-model-00.txt Pages : 8 Date : 13-Jul-00 To support IP mobility, mobile IPv4 was designed for IPv4 network and the mobility extension for IPv6 has been also drafted. However, mobile IPv4 and mobile IPv6 are not compatible to each other so that a mobile IPv4 host can not function properly while it changes its point of attachment to IPv6 networks and vice versa. The document specifies an architecture and mechanisms to solve mobility problems in IPv4 and IPv6 interconnected networks. The solution presents a dual stack model that implements a new address mapper on mobile hosts. The address mapper on a mobile host associates the home address in one protocol such as IPv4 with a care-of-address in the other protocol, i.e. IPv6. It dispatches IPv4/IPv6 packets to proper layers of the protocol stack, and provides transparent services to upper layers regardless of the attached networks. Therefore, the new architecture facilitates the mobility of hosts in IPv4 and IPv6 interconnected networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-tsao-mobileip-duelstack-model-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-tsao-mobileip-duelstack-model-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-tsao-mobileip-duelstack-model-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: <20000713145447.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-tsao-mobileip-duelstack-model-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-tsao-mobileip-duelstack-model-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000713145447.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jul 14 09:14:31 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21187 for ; Fri, 14 Jul 2000 09:14:30 -0400 (EDT) Received: from standards (47.234.32.16:1519) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E441@standards.nortelnetworks.com>; Fri, 14 Jul 2000 9:03:27 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7166 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jul 2000 09:03:27 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E440@standards.nortelnetworks.com>; Fri, 14 Jul 2000 9:03:27 -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.3) with ESMTP id e6EDDjM28088 for ; Fri, 14 Jul 2000 15:13:45 +0200 (MEST) Received: from SMTP ([153.88.251.32]) by esealnt409.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1); Fri, 14 Jul 2000 15:13:45 +0200 Received: from esealnt172.ericsson.se ([130.100.184.165]) by 153.88.251.32 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 14 Jul 2000 13:13:45 0000 (GMT) Received: by esealnt172 with Internet Mail Service (5.5.2651.58) id <37823S5B>; Fri, 14 Jul 2000 15:13:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 14 Jul 2000 13:13:45.0497 (UTC) FILETIME=[56FCA090:01BFED95] Message-ID: <5F05C89FB2F8D211B6430008C791912703EA80F7@esealnt190> Date: Fri, 14 Jul 2000 15:13:40 +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] Comparison of Fast Handoff and Proactive Handoff X-To: Chandana Pairla To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello Chandana > The handoff isnt completed until the MN registers with the > "new" FA. Hence the MN has complete control over it. The > draft only talks about preparing the "new" FA in > anticipation of the arrival of the MN. After the MN arrives > in the service area of the "new" FA it is upto it to accept > or reject the FA. The MN is free to exercise its preference. As I wrote in my previous email, at the time when the MN is free to exercise its preference, the "new" RFA already has a binding for the MN. The MN may therefore choose to extend this binding by performing a Registration. The L3 handoff (binding with new RFA) goes on beforehand and the MN only has the choice whether to renew the binding or not. I can't see any "complete control" on the L3 handoff by the MN. The MN can only react after the binding with the new RFA (L3 handoff) has already been established. > > >> > According to my understanding, in terms of spectrum there > >> is no difference > >> > between our approaches. We have the MN register before the > >> handoff while > >> > you have the MN register after the handoff. Therefore the > >> same amount of > >> > messages (advertisements and registrations) are sent over > >> the air, just the > >> > timing is different. > > Actually, your draft requires that a total of 5 messages > need to be sent before the MN "can" recieve service from > the new FA. Our draft is no different in message exchanges to Mobile IP and Regional Registrations. There is an advertisement, a (Regional) Registration Request and Reply. It wouldn't be Mobile IP if these messages were not present. What are the other two messages you are referring to? > On the other hand we require only 2 messages > sent before the MN "can" recieve service. It is upto the MN > to decide whether it want to accept the service or not. Again, the new FA already has a binding for the MN. The MN may only decide whether to renew this binding, but it can't stop the new FA from providing service to it (i.e. receiving and buffering the MN's data) for at least a short time. So it can't really decide whether it wants to accept the service, it can only decide whether it wants to renew the binding and receive data from the FA. > > >> But how long does it take for the MN to detect that it needs > >> to perform the > >> handoff? > > > >With appropriate movement detection (which is probably the most > >important factor) this can be very fast. That's why we discuss > >this in our draft. > > > > While your draft proposes the mobile handle this, we > propose the network handle it. That is not correct, our draft allows both the network and the MN to control the L3 handoff, while proactive FA does not allow the MN to control the L3 handoff (establishment of binding with new FA). Please refer to my previous email. > >Agreed. What you want to minimise is the disruption interval > >due to a handoff. > > The issue is to minimize the interval of service disruption > irrespective of whether it is due to a handoff or not. I can't understand your point. We are working on L3 MIP handoffs. Regards, Karim From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jul 14 10:13: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 KAA07040 for ; Fri, 14 Jul 2000 10:13:00 -0400 (EDT) Received: from standards (47.234.32.16:3522) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E4B3@standards.nortelnetworks.com>; Fri, 14 Jul 2000 10:02:06 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7315 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jul 2000 10:02:06 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E4B2@standards.nortelnetworks.com>; Fri, 14 Jul 2000 10:02:05 -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 IAA22393 for ; Fri, 14 Jul 2000 08:12:23 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA17366; Fri, 14 Jul 2000 07:12:22 -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 HAA16467; Fri, 14 Jul 2000 07:12:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Fri, 14 Jul 2000 07:11:27 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: Re: [MOBILE-IP] Comparison of Fast Handoff and Proactive Handoff X-To: "Karim El-Malki (ERA)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <5F05C89FB2F8D211B6430008C791912703EA80F7@esealnt190> > Hello Chandana > > > The handoff isnt completed until the MN registers with the > > "new" FA. Hence the MN has complete control over it. The > > draft only talks about preparing the "new" FA in > > anticipation of the arrival of the MN. After the MN arrives > > in the service area of the "new" FA it is upto it to accept > > or reject the FA. The MN is free to exercise its preference. > > As I wrote in my previous email, at the time when the MN is > free to exercise its preference, the "new" RFA already has a > binding for the MN. The MN may therefore choose to extend this > binding by performing a Registration. The L3 handoff (binding > with new RFA) goes on beforehand and the MN only has the choice > whether to renew the binding or not. I can't see any > "complete control" on the L3 handoff by the MN. The MN can only > react after the binding with the new RFA (L3 handoff) has > already been established. Yes, but again, keep in mind that this can only occur *if* the FA is under the same administrative control as the GFA, so to be honest with you, I don't see the problem. BTW, when Regional Registration is involved, the Mobile never has complete control anyways, since the hierarchy may be hidden from the mobile. Further, as a mobile moves around the wireless network, you are making assumptions that it knows a priori about certain routers, and where it wants to get service from, I would argue that in the real world, people want service, and in many cases don't know where it is coming from. This is no different. Certainly a user may care about the carrier, but a specific router within a carrier's network?? Perhaps your point is valid in a LAN or campus environment. > > > On the other hand we require only 2 messages > > sent before the MN "can" recieve service. It is upto the MN > > to decide whether it want to accept the service or not. > > Again, the new FA already has a binding for the MN. The MN may > only decide whether to renew this binding, but it can't stop the > new FA from providing service to it (i.e. receiving and buffering > the MN's data) for at least a short time. So it can't really > decide whether it wants to accept the service, it can only decide > whether it wants to renew the binding and receive data from the FA. It is always free to get service from another Foreign Agent, or continue receiving service from the old FA until the signal fades away. Ultimately, the mobile has control, but network is simply trying to assist. > > > > > >> But how long does it take for the MN to detect that it needs > > >> to perform the > > >> handoff? > > > > > >With appropriate movement detection (which is probably the most > > >important factor) this can be very fast. That's why we discuss > > >this in our draft. > > > > > > > While your draft proposes the mobile handle this, we > > propose the network handle it. > > > That is not correct, our draft allows both the network and the MN > to control the L3 handoff, while proactive FA does not allow the MN > to control the L3 handoff (establishment of binding with new FA). > Please refer to my previous email. Please refer to my above response. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jul 14 10:49:11 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17261 for ; Fri, 14 Jul 2000 10:49:10 -0400 (EDT) Received: from standards (47.234.32.16:3522) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E537@standards.nortelnetworks.com>; Fri, 14 Jul 2000 10:38:39 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7484 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jul 2000 10:38:39 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E536@standards.nortelnetworks.com>; Fri, 14 Jul 2000 10:38:39 -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 IAA15236 for ; Fri, 14 Jul 2000 08:48:52 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA05490; Fri, 14 Jul 2000 07:48:50 -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 HAA17384; Fri, 14 Jul 2000 07:48:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Fri, 14 Jul 2000 07:47:54 -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] Comparison of Fast Handoff and Proactive Handoff X-To: "Karim El-Malki (ERA)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <5F05C89FB2F8D211B6430008C791912703EA80F6@esealnt190> > Hello James > > > >OK, so my understanding was correct. > > >However, you state in your draft that proactive FA plus Regional > > >Registrations provide a complete fast-handoff solution for > > Mobile IP. > > >I think proactive FA is not compatible with Regional Registrations. > > > > > > > Why do you think it isn't compatible? > > > > OK, please correct me if I'm wrong. > In your draft you create temporary bindings for the MN in the GFA and > new RFA without having the MN issue a Regional Registration Request. > I think that this is not according to the Regional Reg'n draft. I believe that we state that in our draft, the Regional Reg draft is not enough, which is why we add more functionality on top of the infrastructure introduced by the Regional Draft. The Regional Draft is very useful, and provides a mechanism to provide faster hand-off than RFC 2002 does, but we believe that the network has to be more pro-active in order to minimize service disruption. This is in line with how the cellular networks work today, but we are providing the Mobile with additional flexibility, allowing it to NOT register with a new FA. > > > > > It certainly becomes aware when the advertisement shows up, and could > > reject it at that point. > > But the new FA already has a short/temporary binding for the MN and > is receiving the MN's traffic. The MN may not want that FA to receive > it's traffic at all and it can't control this. Karim, there are LOTS of routers in the network that will be receiving your traffic before the FA will, and this is completely outside of your control. What exactly is your issue? > > > > However, I think this discussion is hiding the real issue. > > The fundamental > > difference between our proposal and yours is who has ultimate > > control over handoff, the network or the mobile . > > This is not the difference. I think the difference is that your > draft only allows network control while we are allowing both. > Mobile IPv4 allows the MN to take a decision on performing a > registration (e.g. movement detection) and also allows the FA > to accept/reject it before any binding is created. So we leave > both options open. While we believe that the fastest method is best, which involves a more proactive foreign agent. > > > We are > > proposing that the > > network is in a much better position to perform functions > > such as load > > balancing, QoS determination, etc, especially in 3G-type > > networks, and therefore > > the network should be the final arbiter of where the mobile > > is placed. In your > > proposal, the mobile gets the final say over whether it will > > or will not take a > > handoff, so the network's decision could be overridden. > > The MN does not get the final say since the new RFA/intermediate > RFA/GFA may reject the Registration. Also, the network may even not > advertise the new RFA to the MN if the network decides that this L3 > handoff should not happen. Well, if the local policy does not allow the new FA to advertise service, I would think there would be a reason correct. Similarly, in your scheme, the Mobile would receive a registration error in the reply. So I don't see our schemes are being any different here. Our scheme actually has the ability of allowing the FA to decide whether it will even provide service, and perhaps it cannot due to overloaded conditions. If such an event does occur, the network can then find another FA that *could* provide service, and has the bandwidth to do so. In the typical RFC2002 network, the mobile would have to solicit the various FAs and find one that will accept to provide service. I believe that the former provides a much smoother hand-off. > > > > I realize that the "mobile gets final say" position is the > > traditional > > mobile IP position, but remember that originated from a wireless > > LAN base. > > As above, I don't agree since the FA may reject a Registration > Request and thus the network gets the final say. That is *always* the case. The FA ALWAYS has the option to reject a registration, regardless of the hand-off proposal. > > > > We only require that: > > > > 1) The old FA, the mobile, and/or the new FA in conjunction > > be able to provide > > information about power level from possible candidate new > > RANs/access points, so the old FA can make a determination, based on > > information about network load and QoS availability, which > > candidate new FA > > is the appropriate one to hand the mobile off to. > > I don't understand your focus on power levels and radio issues. > Your underlying principle seems to be to replace L2 functionality > and messaging with L3. I don't think this is part of L3 Fast handoffs. Not at all. We simply assume that the radio network is in place, and create an interface between the radio interface and the Mobile IP stack on the Foreign Agent, an API of sorts, to get triggered on specific events. We do not carry, nor propagate L2 information. > > > > > I think Pat and I agree that the mobile IP working group is not > > the place to get into details about where and how L2 data gets > > propagated over L3. However, I think we also agree that > > there are some > > 3G scenerios where exchanging L2 data over L3 is necessary. Whether > > IETF gets involved in specifying this is an open question at > > this point. > > OK, but what is not clear to me is that your explanations above > often rely on this assumption. My understanding is that the proactive > draft is a step in that direction. Not at all. PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jul 14 12:21:56 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20382 for ; Fri, 14 Jul 2000 12:21:56 -0400 (EDT) Received: from standards (47.234.32.16:3522) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E5D8@standards.nortelnetworks.com>; Fri, 14 Jul 2000 12:10:44 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7695 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jul 2000 12:10:44 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E5D7@standards.nortelnetworks.com>; Fri, 14 Jul 2000 12:10:43 -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 JAA21641; Fri, 14 Jul 2000 09:21:03 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id JAA03678; Fri, 14 Jul 2000 09:21:01 -0700 X-Virus-Scanned: Fri, 14 Jul 2000 09:21:01 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdKyz8J1; Fri, 14 Jul 2000 09:20:36 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <200007131842.e6DIgMj410763@jurassic.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <396F3DD5.B48DBF71@iprg.nokia.com> Date: Fri, 14 Jul 2000 09:20:37 -0700 Reply-To: charliep@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: Re: [MOBILE-IP] draft-ietf-mobileip-rfc2002-bis-02.txt X-To: Samita Chakrabarti To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Samita, Here are my last-minute comments on your questions about multicast. > Section 4.4 on the rfc2002-bis draft is little bit confusing for > implementors--when I read it first time, I was not clear at all > on the requirements. So, I have some questions to clarify and I think > it will be helpful for the community if that section is clarified. I will try to think of a clarification, but right now I don't know what it is. > Second paragraph on section 4.4 writes: > In order receive multicasts, a mobile node MUST join the multicast > group in one of two ways. First, a mobile node MAY join the group > via a (local) multicast router on the visited subnet. This option > assumes that there is a multicast router present on the visited > subnet. If the mobile node is using a co-located care-of address, > it SHOULD use this address as the source IP address of its IGMP [8] > messages. Otherwise, it MAY use its home address. > > So, if a MN joins the multicast group in the visitor network and if the > FA is not a mcast router, then FA will not know about the MN's activity. Isn't that O.K.? If the FA is not a multicast router, it's hard to know how or why the FA could/should be aware. > I think, that's why in the 4th paragraph it says: > > Because multicast routing > in general depends upon the IP source address, a mobile node which > sends multicast datagrams directly on the visited network MUST use a > co-located care-of address as the IP source address. ^^^^^^^^ > > SO, does it imply that *only* MN's using co-located care of address > can join the multicast group directly in the foreign network ? I don't think it implies this, especially if somebody wants to design a protocol for making it happen with the foreign-agent care-of address. If the foreign agent gets a packet for a multicast group, and if it knows that the mobile node is in the multicast group, why shouldn't it send the multicast packet to the mobile node? The question would then be how to make the foreign agent aware of the mobile node's desire to be part of the multicast group. That's for receiving. For sending, one could still imagine an arrangement by which the foreign agent sent multicast packets on behalf of the mobile node. So, I don't believe we should make the suggested restriction. > So I can see steps in case 1)i,e sending mcast directly on the visited network : > > 1. Multicast router forwards the packet to CN in regular multicast routing path > as MN joins the mcast group in foreign network. > > 2. The CNs will send multicast packet -- Now how HA will get this packet ? If the correspondent node sends a multicast packet to a multicast group, it goes by way of the multicast tree. The HA may be a member of the multicast group, and it may keep records to indicate that the mobile node is also a member of the multicast group, but I do not think that the correspondent node has to do anything special here. > How does the packet come back to MN ? Does it mean that HA MUST be a mcast > router always ? Currently it does not say so. Even if HA is a mcast router > it has to know that MN with co-located care-of-addr has joined the > particular group ? Even if the HA is not a multicast router, the mobile node could get multicast packets by joining the multicast group locally. > Thinking about this complicacy and providing two ways of sending multicast > datagram seems to me complicate the whole protocol for implementation. > > I wonder, what if we restrict only one way of supporting multicast packets? That would represent a major change, and would need a lot of discussion in the working group before it could be put into the specification. > Also, I don't completely understand the following text in third paragraph > in section 4.4 : > Alternatively, a mobile node which wishes to receive multicasts > MAY join groups via a bi-directional tunnel to its home agent, > assuming that its home agent is a multicast router. The mobile node > tunnels IGMP messages to its home agent and the home agent forwards > multicast datagrams down the tunnel to the mobile node. > > SO, I assume "bi-directional tunnel" above means that MN can encapsulate > multicast packet with outer dst=HA and outer src= MN's home-addr. I think this is right, especially considering that the text was written before RFC 2344. > Also MN is capable of decapsulating any packets coming from HA for which > the outer dest = MN's homeaddr and outer src=HAA. > This seems to be not clear in the draft. I'll try to find a place to put these points. > A diagram similar to the following is helpful also: > > Datagram flowing from HA to FA forward tunnel when HA is a multicast > router and it received a multicast packet for MN. > > -------------| > |dst = COA | > |src = HAA | outer IP hdr > -------------| > |dst = MN | > |src =HAA | inner IP hdr1 > -------------| > |dst = MCAST | inner IP hdr2 > |src = CN | > -------------| Unfortunately, I don't have enough time to construct this diagram before the deadline today. Please bring this up during IETF 48 if you believe it still isn't clear after the new explanatory sentences I have put into the new revision. > Now the question is how HA keeps it binding list for multicast, if N number > of MN's have joined the same MCAST group, then when HA gets a mcast packet > for MCAST, it needs to forward through different nested tunnels and/or > home network appropriately. I assume this should be part of normal multicast > routing. I am not a multicast expert, so I don't have the proper answer. There are interesting papers about this. Look for them in previous Mobicom conference presentations, or scan for papers by Vineet Chikarmane, Carey L. Williamson, Richard B. Bunt, or Wayne L. Mackrell in previous year's Mobicom conferences, or our special issue of MONET from last year. I'll put the newest RFC 2002bis at: http://www.iprg.nokia.com/~charliep/txt/mobileip/mobileip.txt in a few minutes when I get these changes made. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jul 14 14:24:24 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28497 for ; Fri, 14 Jul 2000 14:24:24 -0400 (EDT) Received: from standards (47.234.32.16:3312) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E655@standards.nortelnetworks.com>; Fri, 14 Jul 2000 14:13:22 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7859 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jul 2000 14:13:22 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E653@standards.nortelnetworks.com>; Fri, 14 Jul 2000 14:13:21 -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.3) with ESMTP id e6EINeM06863 for ; Fri, 14 Jul 2000 20:23:40 +0200 (MEST) Received: from SMTP ([153.88.251.32]) by esealnt409.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1); Fri, 14 Jul 2000 20:23:40 +0200 Received: from esealnt172.ericsson.se ([130.100.184.165]) by 153.88.251.32 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 14 Jul 2000 18:23:40 0000 (GMT) Received: by esealnt172 with Internet Mail Service (5.5.2651.58) id <3782PJ1W>; Fri, 14 Jul 2000 20:23:37 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 14 Jul 2000 18:23:40.0466 (UTC) FILETIME=[A273B920:01BFEDC0] Message-ID: <5F05C89FB2F8D211B6430008C791912703EA80F9@esealnt190> Date: Fri, 14 Jul 2000 20:23:37 +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] Comparison of Fast Handoff and Proactive Handoff To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello Pat Sorry if I'm not writing a detailed reply. I only want to summarise my understanding of our exchanges so as to provide a basis for the discussion in Pittsburgh since we have covered most of the arguments already: 1) The proactive FA draft supports network-controlled L3 handoffs. The MN may react to the network-controlled handoff after it has moved and obtained L2 connectivity to the new RFA. Proactive FA probably requires changes to the normal Mobile IP and Regional Registrations models. 2) The Fast Handoffs draft supports both network-controlled and MN-controlled L3 handoffs. 3) The Fast Handoffs draft requires the MN to register with the new RFA/GFA before it moves and before it obtains L2 connectivity to that new RFA, thus anticipating the MN's movement. 4) The proactive draft requires the MN to register with the new RFA after it has moved to it, but the new RFA will already hold a temporary binding for the MN through a network-based mechanism (binding update from the old RFA). 5) The proactive draft introduces a new message (handoff request). 6) The Fast Handoffs draft only reuses Regional Registration messages. 7) Both drafts require an RFA to have some notification (from L2) identifying which new RFA the MN will move to. 8) The details of L2 issues should not come into the fast handoffs area. Regards, Karim > -----Original Message----- > From: pcalhoun@eng.sun.com [mailto:Pat.Calhoun@Eng.Sun.COM] > Sent: Friday, July 14, 2000 4:11 PM > To: Karim El-Malki (ERA) > Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Comparison of Fast Handoff and Proactive > Handoff > > > > Hello Chandana > > > > > The handoff isnt completed until the MN registers with the > > > "new" FA. Hence the MN has complete control over it. The > > > draft only talks about preparing the "new" FA in > > > anticipation of the arrival of the MN. After the MN arrives > > > in the service area of the "new" FA it is upto it to accept > > > or reject the FA. The MN is free to exercise its preference. > > > > As I wrote in my previous email, at the time when the MN is > > free to exercise its preference, the "new" RFA already has a > > binding for the MN. The MN may therefore choose to extend this > > binding by performing a Registration. The L3 handoff (binding > > with new RFA) goes on beforehand and the MN only has the choice > > whether to renew the binding or not. I can't see any > > "complete control" on the L3 handoff by the MN. The MN can only > > react after the binding with the new RFA (L3 handoff) has > > already been established. > > Yes, but again, keep in mind that this can only occur *if* > the FA is under the > same administrative control as the GFA, so to be honest with > you, I don't see > the problem. > > BTW, when Regional Registration is involved, the Mobile > never has complete > control anyways, since the hierarchy may be hidden from the > mobile. Further, > as a mobile moves around the wireless network, you are > making assumptions that > it knows a priori about certain routers, and where it wants > to get service > from, I would argue that in the real world, people want > service, and in many > cases don't know where it is coming from. This is no > different. Certainly a > user may care about the carrier, but a specific router > within a carrier's > network?? > > Perhaps your point is valid in a LAN or campus environment. > > > > > > On the other hand we require only 2 messages > > > sent before the MN "can" recieve service. It is upto the MN > > > to decide whether it want to accept the service or not. > > > > Again, the new FA already has a binding for the MN. The MN may > > only decide whether to renew this binding, but it can't stop the > > new FA from providing service to it (i.e. receiving and buffering > > the MN's data) for at least a short time. So it can't really > > decide whether it wants to accept the service, it can only decide > > whether it wants to renew the binding and receive data from the FA. > > It is always free to get service from another Foreign Agent, > or continue > receiving service from the old FA until the signal fades > away. Ultimately, the > mobile has control, but network is simply trying to assist. > > > > > > > > > >> But how long does it take for the MN to detect that it needs > > > >> to perform the > > > >> handoff? > > > > > > > >With appropriate movement detection (which is probably the most > > > >important factor) this can be very fast. That's why we discuss > > > >this in our draft. > > > > > > > > > > While your draft proposes the mobile handle this, we > > > propose the network handle it. > > > > > > That is not correct, our draft allows both the network and the MN > > to control the L3 handoff, while proactive FA does not allow the MN > > to control the L3 handoff (establishment of binding with new FA). > > Please refer to my previous email. > > Please refer to my above response. > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jul 14 15:23:28 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20147 for ; Fri, 14 Jul 2000 15:23:28 -0400 (EDT) Received: from standards (47.234.32.16:2748) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E745@standards.nortelnetworks.com>; Fri, 14 Jul 2000 15:12:33 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8205 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jul 2000 15:12:32 -0400 Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E744@standards.nortelnetworks.com>; Fri, 14 Jul 2000 15:12:32 -0400 Received: from esvir03nok.ntc.nokia.com (esvir03nok.ntc.nokia.com [131.228.10.152]) by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e6EJMmu28064 for ; Fri, 14 Jul 2000 22:22:49 +0300 (EET DST) Received: from daebh01nok.americas.nokia.com (unverified) by esvir03nok.ntc.nokia.com (Content Technologies SMTPRS 4.1.2) with ESMTP id for ; Fri, 14 Jul 2000 22:22:48 +0300 Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id <3W1R6ZAF>; Fri, 14 Jul 2000 14:20:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E06F@daeis07nok> Date: Fri, 14 Jul 2000 14:20:17 -0500 Reply-To: Basavaraj.Patil@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: [MOBILE-IP] WG Sessions at IETF48 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello, The agenda for the two Mobile IP WG sessions at IETF48 in Pittsburgh are completely packed. What I want to remind the presenters and WG members is that the intent at the meeting is to have discussion, gauge interest and clarify the concepts being presented. It is NOT intended to be a tutorial. So please format your presentations appropriately and expect WG members to have read the I-Ds prior to the meeting. I would encourage as much discussion as possible to occur on the mailing list before the actual meetings to make it more productive. -Basavaraj From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jul 14 15:31:39 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22333 for ; Fri, 14 Jul 2000 15:31:39 -0400 (EDT) Received: from standards (47.234.32.16:2748) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E792@standards.nortelnetworks.com>; Fri, 14 Jul 2000 15:20:30 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8308 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jul 2000 15:20:30 -0400 Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E791@standards.nortelnetworks.com>; Fri, 14 Jul 2000 15:20:29 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nok.ntc.nokia.com [131.228.10.150]) by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e6EJUju14860 for ; Fri, 14 Jul 2000 22:30:46 +0300 (EET DST) Received: from daebh02nok.americas.nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Fri, 14 Jul 2000 22:30:45 +0300 Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id <3VXA7SHY>; Fri, 14 Jul 2000 14:30:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E070@daeis07nok> Date: Fri, 14 Jul 2000 14:28:12 -0500 Reply-To: Basavaraj.Patil@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: [MOBILE-IP] Handoff Discussions To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi folks, I see that you're all interested in handoff! That's good. The request for timeslots for handoff related topics would consume most of our time at this IETF so we're going to propose the following: Our goal at the end of this IETF meeting is to have a single draft for a working group item for handoff. (Two may be needed, perhaps a separate item for v4 and for v6). To that end we would like the authors of the various handoff proposals and other interested WG members to work together and come up with a merger of some of the existing proposals, or a small set of proposals (such as two) from which the working group could pick one. Here's how we would like to structure the time for this. Before the meeting we'd like the authors of the handoff drafts and other concerned parties to reach an agreement on some criteria that such a draft must meet and to compare your drafts to find common features and differences between the proposals (such as the dialogue that has been going on between Karim, Pat, James and others). We'd like to allocate 20 minutes in the first session to discuss handoff in the context of progress that has been made on this activity. Between the two sessions we'd like a small group to go work offline to merge some proposals or pick one, or one or two for the group to decide upon. In the second session we'd like to allocate 30 minutes to talk about the outcome of this activity, and a very short presentation of the one or two proposals that have been agreed upon. Also remember that we would like as much as possible to be accomplished on the mailing list between now and July 31st. Comments? Cheers, the chairs. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jul 14 15:53:09 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28711 for ; Fri, 14 Jul 2000 15:53:09 -0400 (EDT) Received: from standards (47.234.32.16:2748) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E7DC@standards.nortelnetworks.com>; Fri, 14 Jul 2000 15:42:18 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8388 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jul 2000 15:42:17 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E7CF@standards.nortelnetworks.com>; Fri, 14 Jul 2000 15:32:16 -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 NAA13929; Fri, 14 Jul 2000 13:42:31 -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 PAA03286; Fri, 14 Jul 2000 15:42:30 -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 PAA07942; Fri, 14 Jul 2000 15:43:23 -0400 (EDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Fri, 14 Jul 2000 15:42:25 -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] Handoff Discussions X-To: Basavaraj.Patil@NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E070@daeis07nok> > Our goal at the end of this IETF meeting is to have a single draft for > a working group item for handoff. (Two may be needed, perhaps a > separate item for v4 and for v6). Why can't there be multiple hand-off technologies? > Between the two sessions we'd like a small group to go work offline to merge > some proposals or pick one, or one or two for the group to decide upon. In > the second session we'd like to allocate 30 minutes to talk about the > outcome of this activity, and a very short presentation of the one or > two proposals that have been agreed upon. This is a lot to accomplish in 2 weeks, since in order for a group (of unbiased individuals) to merge proposals, or select 2 for the WG to then select during the second session, they're going to have to be in a very finished state. I would rather the WG discuss the merits of each proposal in Pittsburg, perhaps what is required of a WG sanctioned proposal, then this smaller group meet after the meeting to discuss recommendations to the group within 2 weeks. Cheers, Steve From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jul 14 15:57: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 PAA29792 for ; Fri, 14 Jul 2000 15:57:32 -0400 (EDT) Received: from standards (47.234.32.16:2748) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E7E7@standards.nortelnetworks.com>; Fri, 14 Jul 2000 15:43:21 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8419 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jul 2000 15:43:20 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E7E6@standards.nortelnetworks.com>; Fri, 14 Jul 2000 15:43:20 -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 NAA21020; Fri, 14 Jul 2000 13:53:39 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA07031; Fri, 14 Jul 2000 12:53: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 MAA25746; Fri, 14 Jul 2000 12:53:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 3Z/dr27kwh7RlSx3cTWLhw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Message-ID: <200007141953.MAA25746@nasnfs.eng.sun.com> Date: Fri, 14 Jul 2000 12:57:39 -0700 Reply-To: James Kempf Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: James Kempf Subject: Re: [MOBILE-IP] Handoff Discussions X-To: Basavaraj.Patil@NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Raj/Phil, One thing that has come out in the discussings between Karim, Pat, and I is that the requirements other than simply "make handoff faster" are going to have a big effect on the solution. Would it make sense to have some discussion around this topic either in the full working group or among the group assembled afterwards to discuss? It's a pity the draft deadline is about to expire, this would probably have been a good draft topic... jak From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jul 14 15:59: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 PAA00342 for ; Fri, 14 Jul 2000 15:59:32 -0400 (EDT) Received: from standards (47.234.32.16:2748) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E837@standards.nortelnetworks.com>; Fri, 14 Jul 2000 15:48:11 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8525 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jul 2000 15:48:11 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E836@standards.nortelnetworks.com>; Fri, 14 Jul 2000 15:48:10 -0400 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA23949; Fri, 14 Jul 2000 13:58:25 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA07844; Fri, 14 Jul 2000 12:58:23 -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 MAA25886; Fri, 14 Jul 2000 12:58:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Fri, 14 Jul 2000 12:56:54 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: Re: [MOBILE-IP] Handoff Discussions X-To: Basavaraj.Patil@NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E070@daeis07nok> > Hi folks, > > I see that you're all interested in handoff! That's good. The > request for timeslots for handoff related topics would consume most of > our time at this IETF so we're going to propose the following: > > Our goal at the end of this IETF meeting is to have a single draft for > a working group item for handoff. (Two may be needed, perhaps a > separate item for v4 and for v6). To that end we would like the > authors of the various handoff proposals and other interested WG > members to work together and come up with a merger of some of the > existing proposals, or a small set of proposals (such as two) from > which the working group could pick one. I think that melding our ideas is a fine idea, and I firmly support this. > > Here's how we would like to structure the time for this. Before the > meeting we'd like the authors of the handoff drafts and other > concerned parties to reach an agreement on some criteria that such a > draft must meet and to compare your drafts to find common features and > differences between the proposals (such as the dialogue that has been > going on between Karim, Pat, James and others). Again, I think that this a great idea, but I suspect that the authors in question will require some assistance from the rest of the WG. Just among ourselves, we probably will have a hard time agreeing on the correct model, hence our disagreements on the list. > We'd like to allocate > 20 minutes in the first session to discuss handoff in the context of > progress that has been made on this activity. Between the two > sessions we'd like a small group to go work offline to merge some > proposals or pick one, or one or two for the group to decide upon. I presume that the authors are part of the small group. > In > the second session we'd like to allocate 30 minutes to talk about the > outcome of this activity, and a very short presentation of the one or > two proposals that have been agreed upon. Great idea! PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jul 14 17:28:28 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27034 for ; Fri, 14 Jul 2000 17:28:28 -0400 (EDT) Received: from standards (47.234.32.16:4330) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E935@standards.nortelnetworks.com>; Fri, 14 Jul 2000 17:17:42 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8834 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jul 2000 17:17:42 -0400 Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E934@standards.nortelnetworks.com>; Fri, 14 Jul 2000 17:17:41 -0400 Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Fri Jul 14 17:27:22 EDT 2000 Received: from dnrc.bell-labs.com (IDENT:21257@ramjeepc [135.180.240.106]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id RAA25300; Fri, 14 Jul 2000 17:27:27 -0400 (EDT) X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.0.36 i686) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <396F8880.7FB1C273@dnrc.bell-labs.com> Date: Fri, 14 Jul 2000 21:39:12 +0000 Reply-To: ramjee@DNRC.BELL-LABS.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Ramachandran Ramjee Subject: [MOBILE-IP] HAWAII drafts update... To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello folks, I have updated the HAWAII and HAWAII Paging drafts, available at: http://www.bell-labs.com/user/ramjee/papers/draft-ietf-mobileip-hawaii-01.txt (there is a new section on interactions between HAWAII and Mobile IP HA running on the same router). http://www.bell-labs.com/user/ramjee/papers/draft-ietf-mobileip-paging-hawaii-01.txt (The paging algorithm has been modified a little and a discussion on HA and FA paging has been added). Comments welcome. Cheers, Ram From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jul 14 20:42:46 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27677 for ; Fri, 14 Jul 2000 20:42:45 -0400 (EDT) Received: from standards (47.234.32.16:4176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E9E7@standards.nortelnetworks.com>; Fri, 14 Jul 2000 20:31:48 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9068 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jul 2000 20:31:48 -0400 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E9E6@standards.nortelnetworks.com>; Fri, 14 Jul 2000 20:31:47 -0400 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA18452; Fri, 14 Jul 2000 17:42:02 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.87.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id RAA27926; Fri, 14 Jul 2000 17:42:02 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with SMTP id e6F0g0j632917; Fri, 14 Jul 2000 17:42:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: QkErudIkVajdAssQEGhYIA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Message-ID: <200007150042.e6F0g0j632917@jurassic.eng.sun.com> Date: Fri, 14 Jul 2000 17:42:13 -0700 Reply-To: Samita Chakrabarti Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Samita Chakrabarti Subject: Re: [MOBILE-IP] draft-ietf-mobileip-rfc2002-bis-02.txt X-To: charliep@IPRG.NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello Charlie, Thanks for agreeing to put some clarifying text in the draft for the multicast section. Please see my comments below. > > Section 4.4 on the rfc2002-bis draft is little bit confusing for > > implementors--when I read it first time, I was not clear at all > > on the requirements. So, I have some questions to clarify and I think > > it will be helpful for the community if that section is clarified. > > I will try to think of a clarification, but right now I don't know > what it is. > > > Second paragraph on section 4.4 writes: > > In order receive multicasts, a mobile node MUST join the multicast > > group in one of two ways. First, a mobile node MAY join the group > > via a (local) multicast router on the visited subnet. This option > > assumes that there is a multicast router present on the visited > > subnet. If the mobile node is using a co-located care-of address, > > it SHOULD use this address as the source IP address of its IGMP [8] > > messages. Otherwise, it MAY use its home address. > > > > So, if a MN joins the multicast group in the visitor network and if the > > FA is not a mcast router, then FA will not know about the MN's activity. > > Isn't that O.K.? If the FA is not a multicast router, it's hard to > know how or why the FA could/should be aware. > Yes that is true. FA does not need to know if MN has co-located COA. > > I think, that's why in the 4th paragraph it says: > > > > Because multicast routing > > in general depends upon the IP source address, a mobile node which > > sends multicast datagrams directly on the visited network MUST use a > > co-located care-of address as the IP source address. ^^^^^^^^ > > > > SO, does it imply that *only* MN's using co-located care of address > > can join the multicast group directly in the foreign network ? > > I don't think it implies this, especially if somebody wants to design > a protocol for making it happen with the foreign-agent care-of address. > If the foreign agent gets a packet for a multicast group, and if it > knows that the mobile node is in the multicast group, why shouldn't > it send the multicast packet to the mobile node? The question would > then be how to make the foreign agent aware of the mobile node's > desire to be part of the multicast group. That's for receiving. > For sending, one could still imagine an arrangement by which the > foreign agent sent multicast packets on behalf of the mobile node. > > So, I don't believe we should make the suggested restriction. > > If the mobile node uses it's homeaddr as the source address, then it may join the multicast group in the foreign network, but it should send packets through it's home network using reverse tunnel (rfc2344-bis)-- right ? The multicast router may not forward the packet, if the source addres is not topologically correct. > > So I can see steps in case 1)i,e sending mcast directly on the visited network : > > > > 1. Multicast router forwards the packet to CN in regular multicast routing path > > as MN joins the mcast group in foreign network. > > > > 2. The CNs will send multicast packet -- Now how HA will get this packet ? > > If the correspondent node sends a multicast packet to a multicast > group, it goes by way of the multicast tree. The HA may be a member > of the multicast group, and it may keep records to indicate that > the mobile node is also a member of the multicast group, but I do > not think that the correspondent node has to do anything special here. > I was under the impression that packet from CN must come via HA always. It is not the case for multicast packets. I see your point. > > How does the packet come back to MN ? Does it mean that HA MUST be a mcast > > router always ? Currently it does not say so. Even if HA is a mcast router > > it has to know that MN with co-located care-of-addr has joined the > > particular group ? > > Even if the HA is not a multicast router, the mobile node could get > multicast packets by joining the multicast group locally. > > > > Thinking about this complicacy and providing two ways of sending multicast > > datagram seems to me complicate the whole protocol for implementation. > > > > I wonder, what if we restrict only one way of supporting multicast packets? > > That would represent a major change, and would need a lot of discussion > in the working group before it could be put into the specification. > It would simplify the protocol if we say something like the following : 1) If the MN uses home-addr as source address, then it MUST use encapsulated packet delivery to FA which in turn reverse tunnel the packet to the home agent acting as multicast router. Home agent is responsible for multicast packet delivery using nested tunneling through forward tunnel. 2) If the MN sends/receive multicast packets through the multicast router on the foreign network, then it MUST use a co-lacated COA in the foreign network. > > Also, I don't completely understand the following text in third paragraph > > in section 4.4 : > > Alternatively, a mobile node which wishes to receive multicasts > > MAY join groups via a bi-directional tunnel to its home agent, > > assuming that its home agent is a multicast router. The mobile node > > tunnels IGMP messages to its home agent and the home agent forwards > > multicast datagrams down the tunnel to the mobile node. > > > > SO, I assume "bi-directional tunnel" above means that MN can encapsulate > > multicast packet with outer dst=HA and outer src= MN's home-addr. > > I think this is right, especially considering that the text was > written before RFC 2344. > > > Also MN is capable of decapsulating any packets coming from HA for which > > the outer dest = MN's homeaddr and outer src=HAA. > > This seems to be not clear in the draft. > > I'll try to find a place to put these points. > > > A diagram similar to the following is helpful also: > > > > Datagram flowing from HA to FA forward tunnel when HA is a multicast > > router and it received a multicast packet for MN. > > > > -------------| > > |dst = COA | > > |src = HAA | outer IP hdr > > -------------| > > |dst = MN | > > |src =HAA | inner IP hdr1 > > -------------| > > |dst = MCAST | inner IP hdr2 > > |src = CN | > > -------------| > > Unfortunately, I don't have enough time to construct this diagram > before the deadline today. Please bring this up during IETF 48 > if you believe it still isn't clear after the new explanatory > sentences I have put into the new revision. > > > Now the question is how HA keeps it binding list for multicast, if N number > > of MN's have joined the same MCAST group, then when HA gets a mcast packet > > for MCAST, it needs to forward through different nested tunnels and/or > > home network appropriately. I assume this should be part of normal multicast > > routing. I am not a multicast expert, so I don't have the proper answer. > > There are interesting papers about this. Look for them in previous > Mobicom conference presentations, or scan for papers by > Vineet Chikarmane, Carey L. Williamson, Richard B. Bunt, or > Wayne L. Mackrell in previous year's Mobicom conferences, or our > special issue of MONET from last year. > Thanks for the pointers. > I'll put the newest RFC 2002bis at: > http://www.iprg.nokia.com/~charliep/txt/mobileip/mobileip.txt > in a few minutes when I get these changes made. > Thanks and regards, -Samita From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jul 14 21:06:43 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02992 for ; Fri, 14 Jul 2000 21:06:43 -0400 (EDT) Received: from standards (47.234.32.16:2383) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7EA25@standards.nortelnetworks.com>; Fri, 14 Jul 2000 20:56:04 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9152 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jul 2000 20:56:04 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7EA24@standards.nortelnetworks.com>; Fri, 14 Jul 2000 20:56: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 SAA11826; Fri, 14 Jul 2000 18:06:21 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id SAA16375; Fri, 14 Jul 2000 18:06:19 -0700 X-Virus-Scanned: Fri, 14 Jul 2000 18:06:19 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpd72W63z; Fri, 14 Jul 2000 18:06:15 PDT X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <396FB86A.AEA24E07@iprg.nokia.com> Date: Fri, 14 Jul 2000 18:03:38 -0700 Reply-To: Charlie Perkins Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Charlie Perkins Organization: Nokia Subject: [MOBILE-IP] Smooth handovers X-cc: Govind Krishnamurthi , "Jari T. Malinen" , Rajeev Koodli , robertc@iprg.nokia.com, Hannu Flinck To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello folks, We have developed a framework architecture for smooth handovers for IPv6. In addition to the basic framework draft, we have designed suboptions for three interesting features: - header compression - buffer management - regional registration. The framework draft is available at: http://www.iprg.nokia.com/~charliep/txt/smoothv6/smoothv6.txt A specification for the header-compression feature handover is in: http://www.iprg.nokia.com/~charliep/txt/rohc/hc-ho-draft.txt The buffer management suboption is specified in the following draft: http://www.iprg.nokia.com/~charliep/txt/mobilebuf/buffer6.txt Regional registration also interacts with smooth handovers. Our specification for the protocol and interactions is available at: http://www.iprg.nokia.com/~charliep/txt/regreg6/regreg6.txt We think that this framework architecture works very well with IPv6, but should also be considered in the upcoming discussion for managing smooth handovers for IPv4. The destination options and suboptions defined for IPv6 could almost as well be fit into Mobile IPv4 extensions following after the Previous Foreign Agent Notifiication extension. Comments will be appreciated! Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jul 14 21: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 VAA04215 for ; Fri, 14 Jul 2000 21:12:18 -0400 (EDT) Received: from standards (47.234.32.16:2383) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7EA59@standards.nortelnetworks.com>; Fri, 14 Jul 2000 21:01:37 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9220 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jul 2000 21:01:37 -0400 Received: from sirius.ctr.columbia.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7EA58@standards.nortelnetworks.com>; Fri, 14 Jul 2000 21:01: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 VAA20946; Fri, 14 Jul 2000 21:11:54 -0400 (EDT) X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E070@daeis07nok> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <396FE83A.E9242F86@comet.columbia.edu> Date: Fri, 14 Jul 2000 21:27:38 -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: [MOBILE-IP] Handoff (and Paging?) Discussions X-cc: Basavaraj.Patil@NOKIA.COM, cellularip@comet.columbia.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Folks: I think there are a number of important extensions required to make Mobile IP the 4G technology of choice. Two issues that we have looked at in the COMET Group are fast handoff and paging. I would argue that it is important to consider both registration and paging to fully optimize Mobile IP networks. Looking at one optimization (i.e., registration) for fast handoff without considering paging (which can reduce signaling on the core IP network and power consumption of the mobiles) may be too near-term? Looks like what Basavaraj is proposing is solely fast handoff. I'm questioning that here. Some micro-mobility protocols have 'integrated' support for fast handoff and paging (Cellular IP and Hawaii) others only support fast handoff (hierarchical Mobile IP). Still others provide a minimal set of paging extensions the base Mobile IP protocol (P-MIP). I think IP paging should be a priority too among other issues (AAA, etc.). But especially when we are considering optimizing registration - which is on the agenda. On another related note. We have recently completed an extensive evaluation of a number of micro-mobility protocols (viz. Cellular IP, Hawaii, Ethernet Switch, Hierarchical Mobile IP). We observe that theses protocols can be considered as realization of a generic micro-mobility model. We implemented Cellular IP, Hawaii, Hierarchical Mobile IP in ns using Dave Johnson's extensions and studied handoff performance. We can make two observations. First, we found that in typical scenarios the difference interms of handoff quality is small. Second, we identified the reasons for these differences and related them to the generic model. Other issues outside the scope of the protocols can impact the handoff performance far more than the differences observed e.g., movement detection. We hope to provide an ID, presentation and release the source code for all the models soon. Apologies for the verbose message - its the water in these parts :-) Andrew Basavaraj Patil wrote: > > Hi folks, > > I see that you're all interested in handoff! That's good. The > request for timeslots for handoff related topics would consume most of > our time at this IETF so we're going to propose the following: > > Our goal at the end of this IETF meeting is to have a single draft for > a working group item for handoff. (Two may be needed, perhaps a > separate item for v4 and for v6). To that end we would like the > authors of the various handoff proposals and other interested WG > members to work together and come up with a merger of some of the > existing proposals, or a small set of proposals (such as two) from > which the working group could pick one. > > Here's how we would like to structure the time for this. Before the > meeting we'd like the authors of the handoff drafts and other > concerned parties to reach an agreement on some criteria that such a > draft must meet and to compare your drafts to find common features and > differences between the proposals (such as the dialogue that has been > going on between Karim, Pat, James and others). We'd like to allocate > 20 minutes in the first session to discuss handoff in the context of > progress that has been made on this activity. Between the two > sessions we'd like a small group to go work offline to merge some > proposals or pick one, or one or two for the group to decide upon. In > the second session we'd like to allocate 30 minutes to talk about the > outcome of this activity, and a very short presentation of the one or > two proposals that have been agreed upon. > > Also remember that we would like as much as possible to be > accomplished on the mailing list between now and July 31st. > > Comments? > > Cheers, > the chairs. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Jul 15 00:10:42 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01991 for ; Sat, 15 Jul 2000 00:10:42 -0400 (EDT) Received: from standards (47.234.32.16:2782) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7EAFA@standards.nortelnetworks.com>; Fri, 14 Jul 2000 23:59:55 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9434 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jul 2000 23:59:55 -0400 Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7EAF9@standards.nortelnetworks.com>; Fri, 14 Jul 2000 23:59:50 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nok.ntc.nokia.com [131.228.10.153]) by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e6F4A9u14775 for ; Sat, 15 Jul 2000 07:10:10 +0300 (EET DST) Received: from daebh02nok.americas.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Sat, 15 Jul 2000 00:40:54 +0300 Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id <3VXA7TSV>; Fri, 14 Jul 2000 16:40:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E07F@daeis07nok> Date: Fri, 14 Jul 2000 16:38:22 -0500 Reply-To: Basavaraj.Patil@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: [MOBILE-IP] Draft Agenda for IETF48 X-cc: qa3445@email.mot.com, oran@cisco.com, rcoltun@siara.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Draft Agenda for Mobile IP at 48th IETF First Session Mon 1530-1730 ---------------------------- WG Status and Agenda Bashing 10 min C. Perkins draft-ietf-mobileip-rfc2002-bis-02.txt 10min C. Perkins Regional Registration for IPv6 10min Claude Castellucia Hierarchical Mobile IPv6 - draft-castelluccia-mobileip-hmipv6-00.txt 20min Shiao-Li Tsao Mobility Support for Dual Stack Systems 10min Dynamic Home Addressing draft-thuel-mobileip-tt-00.txt S. Thuel 15min Dynamic Home Address Allocation G. Dommety 10min (Tentative) Discussion of handoff 20min Second Session Wed 0900-1130 ---------------------------- Discussion of handoff and output from handoff team 30min J. Malinen Mobile IP Regional Registrations draft-haverinen-mobileip-reg-pag-00.txt and Mobile IP GSM Sim Authenticaion draft-haverinen-mobileip-gsmsim-00.txt - 15 Mins A. Campbell P-MIP: Minimal Paging Extensions for Mobile IP - 10 Min V. Magret Multicast micro-mobility draft-magret-mobileip-mmm-00.txt - 10 Mins R. Ramjee HAWAII 5min Michael Wren Mobile IP and MPLS draft-zhong-mobile-ip-mpls-01.txt 10 Min C N Yap Mobile VPNs draft-sanchez-mvpn-00.txt 15 min -Chairs From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Jul 15 00:58:30 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07439 for ; Sat, 15 Jul 2000 00:58:30 -0400 (EDT) Received: from standards (47.234.32.16:4985) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7EB44@standards.nortelnetworks.com>; Sat, 15 Jul 2000 0:47:49 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9531 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 15 Jul 2000 00:47:49 -0400 Received: from mail0.u-aizu.ac.jp by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7EB43@standards.nortelnetworks.com>; Sat, 15 Jul 2000 0:47:48 -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 NAA15165; Sat, 15 Jul 2000 13:58:06 +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 NAA01391; Sat, 15 Jul 2000 13:58:05 +0900 (JST) X-Mailer: Mozilla 4.7 [en_jp] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E070@daeis07nok> <396FE83A.E9242F86@comet.columbia.edu> Content-Type: text/plain; charset=iso-8859-9 Content-Transfer-Encoding: 7bit Message-ID: <396FEF5D.8D15BBE5@u-aizu.ac.jp> Date: Sat, 15 Jul 2000 13:58:05 +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] Handoff (and Paging?) Discussions X-To: campbell@comet.columbia.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Andrew said: ... >First, we found that in typical >scenarios the difference interms of handoff >quality is small. I don't quite agree with this. We compared Mobile IPv4 handoff performance with the results reported in Communication Availability (CA) technique of the Dynamics Group at Helsinki Univ. of Technology (HUT) as reported in IPCN 2000 proceedings and we found that the differences are not so small, i.e. CA is really performing well. Our Mobile IP v4 performance results were based on ns simulations (ns using Dave Johnson's extensions). Of course, expect to see more to come on this. --behcet From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Jul 15 01:31:54 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23853 for ; Sat, 15 Jul 2000 01:31:54 -0400 (EDT) Received: from standards (47.234.32.16:3034) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7EB7D@standards.nortelnetworks.com>; Sat, 15 Jul 2000 1:21:10 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9609 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 15 Jul 2000 01:21:09 -0400 Received: from sirius.ctr.columbia.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7EB7C@standards.nortelnetworks.com>; Sat, 15 Jul 2000 1:21:09 -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 BAA24950; Sat, 15 Jul 2000 01:31:23 -0400 (EDT) X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E070@daeis07nok> <396FE83A.E9242F86@comet.columbia.edu> <396FEF5D.8D15BBE5@u-aizu.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3970250A.9F72C77F@comet.columbia.edu> Date: Sat, 15 Jul 2000 01:47:06 -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] Handoff (and Paging?) Discussions X-To: Behcet Sarikaya X-cc: cellularip@comet.columbia.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Behcet: Thanks for your note. I think you may have misunderstood my e-mail. (Apologies for not making it clearer). We do not compare micro-mobility protocols to the base Mobile IP protocol (that would be unfair). We only evaluated the micro-mobility protocols against each other - that is fair. We implemented Cellular IP, Hawaii and Hierarchical Mobile IP in ns. In the case of handoff performance they were very close - 'small beer' as we say in England. This is encouraging for consensus which the chairs are looking for. What this mean is that if handoff performance is the sole criteria to select one of the above micro-mobility protocols as say 'the working group protocol' (I'm not suggesting this - even if CIP is a mighty fine protocol ;-) then you could just as well toss a coin and any of these micro-mobility protocols would do the job. Really there is nothing in it. However, the micro-mobility protocols implemented show significant differences in processing requirement, routing efficiency, manageability and other parameters related to implementation and deployment. Therefore you have to understand the requirements. What features make one better than the other. E.g., Hierarchical Mobile IP is more synergistic to the root protocol. CIP and Hawaii have built in paging. CIP is a L2 and L3 technology, etc., the list goes on and on - just for this small sample of m-m protocols. There are lots of factors to consider. Andrew Behcet Sarikaya wrote: > > Andrew said: > ... > >First, we found that in typical > >scenarios the difference interms of handoff > >quality is small. > > I don't quite agree with this. We compared Mobile IPv4 > handoff performance with the results reported in > Communication Availability (CA) technique of the Dynamics Group at > Helsinki > Univ. of Technology (HUT) as reported in IPCN 2000 proceedings > and we found that the differences are not so small, i.e. CA is really > performing > well. > Our Mobile IP v4 performance results were based on ns simulations > (ns using Dave Johnson's extensions). > Of course, expect to see more to come on this. > > --behcet From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Jul 15 04:11:56 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01900 for ; Sat, 15 Jul 2000 04:11:55 -0400 (EDT) Received: from standards (47.234.32.16:1682) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7EC04@standards.nortelnetworks.com>; Sat, 15 Jul 2000 4:01:07 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9780 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 15 Jul 2000 04:01:07 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7EBFE@standards.nortelnetworks.com>; Sat, 15 Jul 2000 3:51:07 -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 BAA28475; Sat, 15 Jul 2000 01:01:28 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id BAA26488; Sat, 15 Jul 2000 01:01:27 -0700 X-Virus-Scanned: Sat, 15 Jul 2000 01:01:27 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from jmalinen.iprg.nokia.com (205.226.2.98, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdTqnEDn; Sat, 15 Jul 2000 01:01:24 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E070@daeis07nok> <396FE83A.E9242F86@comet.columbia.edu> <396FEF5D.8D15BBE5@u-aizu.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39701A54.99D731A0@iprg.nokia.com> Date: Sat, 15 Jul 2000 01:01:25 -0700 Reply-To: jmalinen@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Jari T. Malinen" Subject: Re: [MOBILE-IP] Handoff (and Paging?) Discussions X-To: sarikaya@U-AIZU.AC.JP To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello, Bechet, Behcet Sarikaya wrote: > Andrew said: > ... > >First, we found that in typical > >scenarios the difference interms of handoff > >quality is small. > > I don't quite agree with this. We compared Mobile IPv4 > handoff performance with the results reported in > Communication Availability (CA) technique of the Dynamics Group at > Helsinki > Univ. of Technology (HUT) as reported in IPCN 2000 proceedings > and we found that the differences are not so small, i.e. CA is really > performing > well. > Our Mobile IP v4 performance results were based on ns simulations > (ns using Dave Johnson's extensions). > Of course, expect to see more to come on this. The experiments we took at HUT had the MCHO case for which there were many scenarios where signal quality policies did have a difference. First of all, having no signal-based control vs. signal-based handoff scenarios made a big difference. Then issues like weak vs. strong fields, few vs. many access points within range (sparse vs. over-dense network) etc for different scenarios favored different policies. But these did not affect the signalling as within our constraints there was no need for protocol extensions. However, to find a protocol that would provide a synthesis of the handoff work different scenarios like MCHO and NCHO adaptable to different L2 technologies should be addressed by the end result. I hope the suggested work should address separate (minimal, IPR-free, core design) components. The concept handoff is getting a bit fuzzy, e.g. the following solve a bit different problems and on some level each affect handoff efficiency. Proposals solving core handoff issues tend to have sketchy solutions for many of the issues below. - "basic" handoff state management between current and previous router - "micro" or regional mobility, security - extensions for special-purpose optimizations (QoS, buffer mgmt, header compression, paging, traffic control, you name it..) And, the constraints for IPv4 and IPv6 are quite different, solutions for IPv4 and IPv6 should be separated. Maybe a distribution of work could be attempted so that interested parties would co-author new documents on relevant handoff-related subproblems? (the aim is interoperable standards, right?). To have a more concrete baseline suggestion for an IPv6-based framework, we recently issued (see Charlie's recent mail) a set of drafts, in addition to some new or complementary design ideas brought up by each component. Regards, --jari Jari T. Malinen, Nokia Research Center. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Jul 15 21:29:28 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09556 for ; Sat, 15 Jul 2000 21:29:28 -0400 (EDT) Received: from standards (47.234.32.16:4977) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7EDE7@standards.nortelnetworks.com>; Sat, 15 Jul 2000 21:18:14 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10488 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 15 Jul 2000 21:18:14 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7EDE6@standards.nortelnetworks.com>; Sat, 15 Jul 2000 21:18:13 -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 TAA17924; Sat, 15 Jul 2000 19:28:36 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA08328; Sat, 15 Jul 2000 18:28:35 -0700 (PDT) Received: from suntana (suntana [129.146.122.88]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id SAA22519; Sat, 15 Jul 2000 18:28:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: U8FHG/dnF7xMZjdOuqawTA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Message-ID: <200007160128.SAA22519@nasnfs.eng.sun.com> Date: Sat, 15 Jul 2000 18:32:46 -0700 Reply-To: James Kempf Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: James Kempf Subject: Re: [MOBILE-IP] Handoff (and Paging?) Discussions X-To: campbell@comet.columbia.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Andrew, Another point I think you are missing is the effect of a particular fast handoff technique on factors other than handoff performance itself. For example, buffering techniques have the effect of introducing state into the network, whereas techniques that don't do buffering don't. Depending on the requirements for a solution, this may or may not be acceptable. This is why I think it is important to have a list of requirements that state what the desirable characteristics of a solution are, beyond simply "it makes real time stream handoff faster." jak From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Jul 15 21:58:40 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13647 for ; Sat, 15 Jul 2000 21:58:40 -0400 (EDT) Received: from standards (47.234.32.16:3092) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7EE1B@standards.nortelnetworks.com>; Sat, 15 Jul 2000 21:47:59 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10556 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 15 Jul 2000 21:47:58 -0400 Received: from sirius.ctr.columbia.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7EE1A@standards.nortelnetworks.com>; Sat, 15 Jul 2000 21:47:58 -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 VAA08320; Sat, 15 Jul 2000 21:58:17 -0400 (EDT) X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <200007160128.SAA22519@nasnfs.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39714495.1DFE3DCB@comet.columbia.edu> Date: Sat, 15 Jul 2000 22:13:57 -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] Handoff (and Paging?) Discussions X-To: James Kempf X-cc: cellularip@comet.columbia.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi James: I wasn't missing the buffer/state thing but I agree with your general point. But there is no free lunch here, right? If you want zero loss and fast handoff then the are state, synchronization and complexity penalties at play here - if you want to do things in the access network that is. Alternatively, you can have smart TCPs which are more robust against the typical loss patterns caused by handoff, in which case, you may not need the heavy duty buffering/sync techniques you point too to minimize loss. That's clean, fast and e2e friendly - hey I like that! Just a flip side to your point. But I see both side to this argument and as you point out there are multiple prespectives based on your requirement. The question is what is the minimum control that needs to be added (to the net) with the least complexity for the max performance (e.g., fast handoff with min loss is a simple metric, there are others clearly). Andrew James Kempf wrote: > > Andrew, > > Another point I think you are missing is the effect of a particular > fast handoff technique on factors other than handoff performance itself. > For example, buffering techniques have the effect of introducing > state into the network, whereas techniques that don't do buffering don't. > Depending on the requirements for a solution, this may or may not > be acceptable. > > This is why I think it is important to have a list of requirements that > state what the desirable characteristics of a solution are, beyond simply > "it makes real time stream handoff faster." > > jak From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Jul 16 01:23:36 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17148 for ; Sun, 16 Jul 2000 01:23:36 -0400 (EDT) Received: from standards (47.234.32.16:1831) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7EEB3@standards.nortelnetworks.com>; 16 Jul 2000 1:12:45 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10752 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 16 Jul 2000 01:12:45 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7EEAC@standards.nortelnetworks.com>; 16 Jul 2000 1:02:40 -0400 Received: from server.eirpage.ie ([194.106.129.249]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id AAA04744 for ; Sun, 16 Jul 2000 00:12:59 -0500 (CDT) X-Internal-ID: 396DD9CF00001972 Received: from [209.81.129.232] (209.81.129.232) by server.eirpage.ie (NPlex 2.0.108); 15 Jul 2000 19:08:26 +0100 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Errors-To: 69chevelle@hongkong.com Message-ID: <000032075495$00007f90$000044fe@147.109.47.4> Date: Sat, 15 Jul 2000 13:22:20 -0500 Reply-To: admin@notodrugs.org Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: broklvr@JOESUSEDPC.COM Subject: [MOBILE-IP] Europe is paying $5 per gallon for gasoline 17662 X-To: admin@notodrugs.org To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: quoted-printable Current Market Information.
New strategy could realize up to 40% or greater returns.

 Free Video
 Free "How to" manual for successfully trading in the = oil marketplace
Find out where today's profits are

We are so confident that you will be able to use our easy investing method= s to
profit from today's soaring fuel prices that we will give you a "FREE TRADE"
just to try us out.

Take advantage of the high gasoline prices.... NOW!

Earn a "Fortune" in the oil market!

Act Now -- click below for complete information.

click here






To be removed:
click here

Current Market Information.

New strategy could realize up to <= /FONT>

40%

From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jul 17 10:09:58 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23264 for ; Mon, 17 Jul 2000 10:09:57 -0400 (EDT) Received: from standards (47.234.32.16:4912) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7F29F@standards.nortelnetworks.com>; Mon, 17 Jul 2000 9:58:26 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12141 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 17 Jul 2000 09:58:26 -0400 Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7F29E@standards.nortelnetworks.com>; Mon, 17 Jul 2000 9:58:25 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nok.ntc.nokia.com [131.228.10.154]) by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e6HE8ix03999 for ; Mon, 17 Jul 2000 17:08:45 +0300 (EET DST) Received: from daebh01nok.americas.nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Mon, 17 Jul 2000 17:07:49 +0300 Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id <3W1R68Z5>; Mon, 17 Jul 2000 09:05:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E085@daeis07nok> Date: Mon, 17 Jul 2000 09:05:13 -0500 Reply-To: Basavaraj.Patil@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: Re: [MOBILE-IP] Handoff Discussions X-cc: Steven.Glass@East.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Steve, >> Our goal at the end of this IETF meeting is to have a single draft for >> a working group item for handoff. (Two may be needed, perhaps a >> separate item for v4 and for v6). > > Why can't there be multiple hand-off technologies? Handoff technologies are either of the following types : Network initiated, Mobile initiated, Mobile assisited (MAHO) and a hybrid combination of these. The network elements that play a role in the handoffs differ and optimization to enhance the performance of handoff can be done by multiple methods. There is a bunch of other issues as well but to answer your question, yes there can be multiple solutions, but what we are trying to do here is to take all the commonlaities of the different proposals currently on the table and resolve the differences to arrive at a single (or two) solutions. > >> Between the two sessions we'd like a small group to go work offline to merge >> some proposals or pick one, or one or two for the group to decide upon. In >> the second session we'd like to allocate 30 minutes to talk about the >> outcome of this activity, and a very short presentation of the one or >> two proposals that have been agreed upon. > > This is a lot to accomplish in 2 weeks, since in order for a group (of >unbiased individuals) to merge proposals, or select 2 for the WG to then >select during the second session, they're going to have to be in a very >finished state. > We do not expect this to be done in 2 weeks. It's a start. If required we can talk about an interim meeting to merge the proposals and arrive at a consensus solution. > I would rather the WG discuss the merits of each proposal in Pittsburg, >perhaps what is required of a WG sanctioned proposal, then this smaller group >meet after the meeting to discuss recommendations to the group within 2 weeks. > This can happen on the discussion list and the merits of each proposal can be highlighted at the meteing in Pittsburgh. > Cheers, > Steve > Regards, -Basavaraj From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jul 17 15:18:14 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26587 for ; Mon, 17 Jul 2000 15:18:14 -0400 (EDT) Received: from standards (47.234.32.16:4470) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7F3A3@standards.nortelnetworks.com>; Mon, 17 Jul 2000 15:07:03 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12481 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 17 Jul 2000 15:07:02 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7F39C@standards.nortelnetworks.com>; Mon, 17 Jul 2000 14:57:01 -0400 Received: from cse.uta.edu (cse.uta.edu [129.107.12.1]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id OAA14702 for ; Mon, 17 Jul 2000 14:07:29 -0500 (CDT) Received: from localhost by cse.uta.edu (8.9.0/8.9.0) with SMTP id OAA13946; Mon, 17 Jul 2000 14:01:17 -0500 (CDT) X-Sender: ramesh@cse MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Mon, 17 Jul 2000 14:01:17 -0500 Reply-To: Ramesh Yeraballi Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Ramesh Yeraballi Subject: [MOBILE-IP] WoWMoM-2000 Call for Participation X-To: Sajal Das To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Please accept my apologies if you receive multiple copies of this announcment. --------------------------------------------------------------------- CALL FOR PARTICIPATION WoWMoM-2000 The Third ACM International Workshop on Wireless Mobile Multimedia (in conjunction with MobiCom-2000) August 11, 2000 (Friday) Seaport Hotel at the World Trade Center, Boston, Massachusetts, USA --------------------------------------------------------------------- Sponsors: * ACM SigMobile Support from: * Nortel Networks * The University of California at Riverside * DIMACS - The Center for Discrete Mathematics & Theoretical Computer Science * CReWMaN at the University of Texas at Arlington --------------------------------------------------------------------- For uptodate technical program, registration information, and hotel information for the WoWMoM workshop are now available at http://www-cse.uta.edu/crewman/conferences/wowmom-2000/ If you are unable to access the above web page, please send e-mail to ramesh@cse.uta.edu -------------------------------------------------------------------------- WoWMoM 2000 Technical Program -------------------------------------------------------------------------- Welcome Address (8:00 am - 8:30 am) -------------------------------------------------------------------------- Session I ( 8:30 am - 10:00 am) Wireless QoS: Admission and Call Control * W2F2Q: Packet Fair Queuing in Wireless Packet Networks Yung Yi, Yongho Seok, Taekyoung Kwon and Yanghee Choi Seoul National University * A Wireless Fair Scheduling Algorithm for Error'Prone Wireless Channels Peng Lin, B. Bensaou, Q. L. Ding, and K.C. Chua National University of Singapore * A Novel Distributed Call Admission Control for Wireless Mobile Multimedia Networks Youssef Iraqi , University of Montreal Raouf Boutaba, University of Waterloo, Canada * Real-time Prioritized Call Admission Control in a Base Station Scheduler Jay R. Moorma, John W. Lockwood and Sung Mo Kang University of Illinois and Washington University, St. Louis -------------------------------------------------------------------------- Coffee Break (10:00 am - 10:30 am) -------------------------------------------------------------------------- Session II (10:30 am - 12:00 noon) Wireless Mobility: Support and Performance Analysis * An Integrated Mobility and Traffic Model for Resource Allocation in Wireless Networks Hisashi Kobayashi, Shum-Zheng Yu and Brian L. Mark Princeton University and George Mason University * Mobility Modeling of Rush Hour Traffic for Location Design Area in Cellular Networks Apurva Kumer, IBM - India Research Lab. M. N. Umesh, Silicon Automation Systems, India Rajesh Jha, Lucent Technologies, NJ * Multicast Support for Mobile IP with the Hierarchical Local Registration Approach H. Omar, T. Saadawi and M. Lee The City University of New York * Performance Evaluation of ATM/AAL2 as switching technology in 3G Mobile Access Networks Oscar Mezquita Baeza, GMD Fokus GmbH Berlin, Germany Enrico Scarrone, CSELT Turin, Italy -------------------------------------------------------------------------- Lunch Break (12:00 noon - 1:30 pm) -------------------------------------------------------------------------- Session III (1:30 pm - 3:00 pm) Resource Management in Mobile Systems * Managing the Storage and Battery Resources in an Image Capture Device (Digital Camera) using Dynamic Transcoding Surendar Chandra, Carla Schlatter Ellis and Amin Vahdat Duke University * Performance Modelling of Speculative Prefetching for Compound Requests in Low Bandwidth Networks N.J. Tuah, M. Kumar and S. Venkatesh Curtin University of Technology, Australia * A Modified CDMA/PRMA Medium Access Control Protocol for Integrated Services in LEO Satellite Systems Abbas Ibrahim and Samie Tohme Ecole Nationale Superieure des Telecommunications, Paris, France * Delay Jitter Performance of Video Traffic in a Cellular Wireless ATM Network T.C. Wong, J. W. Mark and K. C. Chua National University of Singapore and University of Waterloo, Canada -------------------------------------------------------------------------- Coffee Break (3:00 pm - 3:30 pm) -------------------------------------------------------------------------- Session IV (3:30 pm - 5:00 pm) Panel -- TBD -------------------------------------------------------------------------- END OF PROGRAM From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jul 17 17:44: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 RAA28882 for ; Mon, 17 Jul 2000 17:44:51 -0400 (EDT) Received: from standards (47.234.32.16:3326) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7F478@standards.nortelnetworks.com>; Mon, 17 Jul 2000 17:33:11 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12797 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 17 Jul 2000 17:33:11 -0400 Received: from qhars002.nortel.com (47.101.112.102:45559) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7F477@standards.nortelnetworks.com>; Mon, 17 Jul 2000 17:33:09 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Mon, 17 Jul 2000 22:37:31 +0100 Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch1.nortel.com; Mon, 17 Jul 2000 15:23:10 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 17 Jul 2000 15:26:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BFF02D.3D04BDFE" Message-ID: Date: Mon, 17 Jul 2000 15:26:06 -0500 Reply-To: Glenn Morrow Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Glenn Morrow Subject: [MOBILE-IP] Location Hiding Route Optimization Draft To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BFF02D.3D04BDFE Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFF02D.3D04BDFE" ------_=_NextPart_001_01BFF02D.3D04BDFE Content-Type: text/plain > Greetings all, > > Attached is a draft we have submitted that details a solution that begins > to address the problem set of providing end to end route optimization > while not disclosing an entity's location, in the form of the COA/CCAO, to > the correspondent host for personal security reasons. > > The draft also points out some possible optimizations to existing proposed > solutions; in particular, the removal of tunneling between mobile hosts > and mobility agents by the use of end to end redirection. > > The proposed solution is currently geared to mobile IP signaling built > upon IPv4 at this time. The solution affects only the FIB at this point > and thus makes some assumptions about the basic trust relationships > between entities who maintain router/NAS equipment and entities associated > with hosts. > > RIB affecting solutions are beyond the current scope; however, business, > and consumer drivers may force open yet secure solutions to this problem > set in the end. > > Another draft will be available for IPv6 soon. While we are aware that > other signaling could also be used to achieve these functions, at this > stage we are focusing on backwards compatible mobile IP signaling based > solutions. > > We believe that location hiding for personal security reasons is a hard > requirement for mobility solutions in a public infrastructure and that it > is in the consumers best interest to not sacrifice end to end route > optimization for it. > > We are very interested in the WGs feedback on these approaches and are > open to collaboration with others interested in solutions to this problem > set on future drafts - in particular, the IPv6 solution. > > Attached is the draft. > > <> > > Thank You, > > Cheng-Yin Lee, leecy@nortelnetworks.com > > Glenn Morrow, gmorrow@nortelnetworks.com > > Fayaz Kadri, fayaz@nortelnetworks.com > ------_=_NextPart_001_01BFF02D.3D04BDFE Content-Type: text/html Content-Transfer-Encoding: quoted-printable Location Hiding Route Optimization Draft

Greetings all,

Attached is a draft we have submitted = that details a solution that begins to address the problem set of = providing end to end route optimization while not disclosing an = entity's location, in the form of the COA/CCAO, to the correspondent = host for personal security reasons.

The draft also points out some = possible optimizations to existing proposed solutions; in particular, = the removal of tunneling between mobile hosts and mobility agents by = the use of end to end redirection.

The proposed solution  is = currently geared to mobile IP signaling built upon IPv4 at this time. = The solution affects only the FIB at this point and thus makes some = assumptions about the basic trust relationships between entities who = maintain router/NAS equipment and entities associated with hosts. =

RIB affecting solutions are beyond the = current scope; however, business, and consumer drivers may force open = yet secure solutions to this problem set in the end.

Another draft will be available for = IPv6 soon. While we are aware that other signaling could also be used = to achieve these functions, at this stage we are focusing on backwards = compatible mobile IP signaling based solutions.

We believe that location hiding for = personal security reasons is a hard requirement for mobility solutions = in a public infrastructure and that it is in the consumers best = interest to not sacrifice end to end route optimization for it. =

We are very interested in the WGs = feedback on these approaches and are open to collaboration with others = interested in solutions to this problem set on future drafts - in = particular, the IPv6 solution.

Attached is the draft.

= <<draft-lmk-mobileip-intercepting-update-00.txt>>

Thank You,

   Cheng-Yin Lee, = leecy@nortelnetworks.com

   Glenn Morrow, = gmorrow@nortelnetworks.com

   Fayaz Kadri, = fayaz@nortelnetworks.com

------_=_NextPart_001_01BFF02D.3D04BDFE-- ------_=_NextPart_000_01BFF02D.3D04BDFE Content-Type: text/plain; name="draft-lmk-mobileip-intercepting-update-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-lmk-mobileip-intercepting-update-00.txt" Content-Transfer-Encoding: quoted-printable Internet Engineering Task Force C-Y Lee INTERNET DRAFT G. Morrow July 2000 F. Kadri Intercepting Location Updates Status of this memo 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." To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Expires January 2001 [Page = 1] Internet Draft Intercepting Location Updates July 2000 Abstract The base Mobile IP allows a host to transparently send datagrams to mobile nodes as it would to any other nodes. Datagrams addressed to the mobile are always routed via the Home Agent in the home network. However, as the mobile node moves away from its home network, it may no longer be topologically close to its home agent. Route optimization [MIP-OPTIM] has been proposed to allow a host to send packets to the mobile as a mobile node (MN) moves, without having to route the packets via the home agent each time. The mobile provides its current address to a host (or correspondent node, CN) that it is communicating with as it moves. The host updates the cache of the mobile location with this new address and tunnels datagrams (addressed to the mobile) to the current address of the mobile. However not all correspondent nodes are capable of tunneling IP datagrams as required by the route optimization mechanisms described in [MIP-OPTIM]. More importantly, disclosing the current location = (or COA) of the mobile node to correspondent nodes is not always desirable, nor is the overhead of encapsulating datagram to the MN ideal. This proposal provides an optional means for a host, using an existing IP host stack to communicate transparently with a mobile node, when a route optimization scheme such as [MIP-OPTIM] is utilized. At the same time, this proposal does not reveal the current location of the MN to correspondent nodes. In conjunction, = it is not necessary to encapsulate datagram sent from the CN to the MN in a foreign network. To prevent datagram sourced by the MN from being filtered at firewalls data sent from the MN to the CN does not have to be routed via the home agent all the time, nor is it necessary to encapsulate the data tunneled from the MN to a CN. In addition, this proposal provides a means to regionalize location update [REGIONAL-REG] transparent to mobile nodes. Mobile nodes do not have to be aware or capable of regionalizing or localizing location update messages. Furthermore, location update messages can be localized within a network or a routing area or domain, by leveraging existing routing hierarchies in the network. This obviates the need to construct a hierarchy of foreign agents and the consequent need to ensure the hierarchy is reasonably optimal for routing and loop free. Expires January 2001 [Page = 2] Internet Draft Intercepting Location Updates July 2000 1.0 Introduction A mobile node (MN) is identified by its home IP address, and when it moves to a new location, it has to notify its home agent. This enables the home agent to route IP datagrams to the mobile node at its new location. The mobile node notifies its home agent of its new care of address by sending a Registration Request message. This registration mechanism is defined in the base Mobile IP protocol [MIP]. To allow hosts (referred to as correspondent nodes, CNs) to send IP datagrams to the mobile node 's care of address directly without having to go to the home agent first, correspondent nodes need to be notified as well when the mobile node moves. In MIP-OPTIM, a mobile node may notify the correspondent nodes its care of address via the home agent. As described in MIP-OPTIM, a mobile node may send a Binding Warning message to is home agent to request that the home agent inform (by sending Binding Update messages) the correspondent nodes its new care-of address (COA). A mobile may append this message (Binding Warning Extension) in the Registration Request message to the home agent. On reception of the Binding Warning Extension message, the home agent should send Binding Update messages to the correspondent nodes listed in the Binding Warning message, to notify the correspondent nodes the mobile node's new care-of address. The location hiding route optimization described in this document requires a minor modification to the Binding Update message defined in MIP-OPTIM, the addition of Router Alert Option [ROUTER-ALERT] in the message. The Router Alert Option allows an IP packet to be inspected by routers for further processing if necessary. [Note: Ideally an Edge Router Alert, which is only inspected by edge = devices would be more suitable for this purpose] Here, the Binding Update message is forwarded as any other IP datagrams by intermediate routers towards the correspondent node. When the Binding Update message reaches the router serving the subnet where the = correspondent node resides, the router will perform the necessary operations to allow datagrams addressed to the mobile node, from this subnet to be redirected to the care-of address of the mobile node. This router = is referred to as the correspondent agent. The mechanisms required to redirect datagrams to the mobile node is described in the section below, Correspondent Agent (CA) Operations. The benefits of this proposal are : * backward compatibility with RFC2002 and [MIP-OPTIM]. Expires January 2001 [Page = 3] Internet Draft Intercepting Location Updates July 2000 * not necessary to encapsulate or decapsulate data, reducing header overhead * allows optimized route to the mobile without requiring changes to correspondent nodes on the Internet. * hides the care-of address of the mobile node from the = correspondent node. Otherwise, knowledge of the care-of address can be used to infer the where-abouts of the mobile user. * allows the mobile node to send data to the correspondent node without necessarily going through the home agent [REVERSE-TUNNEL], i.e it allows route optimization in the reverse direction from the mobile node to the correspondent node. * the hierarchy of foreign agents are transparent to mobile nodes. A mobile does not have to know whether it is using a hierarchical foreign agent or a RFC2002 foreign agent. * leverages routing hierarchy e.g routing area, routing domain to localize location update messages Expires January 2001 [Page = 4] Internet Draft Intercepting Location Updates July 2000 2.0 Motivation The motivations for this proposal are: i) to allow existing hosts not capable of tunneling IP datagrams, to communicate with a mobile node using a more optimal path to the MN than via the HA (in the case where the MN has moved away from its home network). ii) to allow the traffic from a CN to use the more optimal path to the MN without having to reveal the current location of the MN or = the COA of the MN, to the CN. iii) to obviate the need for encapulation of data (in both forward and reverse directions) iv) to allow a MN to use the more optimal path to the CN when data destined to a CN is tunneled first from the MN to HA to prevent data sourced by the MN from being filtered by firewalls. v) constraining location update message within a region or domain in a way that is transparent to mobile nodes 3.0 Overview This proposal allows an IP host using an existing TCP/IP stack to communicate with a mobile IP host, without requiring datagrams to go through a router (the Home Agent) in the home network when the = mobile node is not in its home network. A host (correspondent node, CN) sends data to a mobile node (MN) transparently using its home = address and need not be aware of the MN's address in a foreign network. The CN does not need to be able to encapsulate or decapsulate IP datagrams. The router serving the CN binds the MN home address to the care-of-address (COA) of the MN when it receives a location update message from the MN or Foreign Agent (FA). [ Note: This router is referred to as the Correspondent Agent (CA). The location update message is referred to as the binding update to be consistent with Mobile IP terminology. If requested by a MN, a Foreign Agent provides routing services to a MN, and sends and receives binding messages on behalf of the MN. The COA of a MN can be a Foreign Agent or a temporary address the MN acquires when it visits a Foreign Network. ] Expires January 2001 [Page = 5] Internet Draft Intercepting Location Updates July 2000 +-------------+ |correspondent| |node | +-------------+ # # packet sent to # mobile node home address # +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ |correspondent| |agent | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ # * At t0, packet # * At t1 packet redirected to sent to # * care-of address of mobile node home addr # * # * +=3D=3D=3D=3D=3D+ * |Home | * |Agent| * +=3D=3D=3D=3D=3D+ * # * # * +------+ +------+ mobile node |mobile| - - - -> |mobile| - - - -> moving away |node | |node | from home +------+ +------+ network t0 t1 -------> time axis mobile node at home network at t0 A MN or Foreign Agent notifies the CN that the MN has moved by triggering a binding update towards the CN. This update message is sent with the Router Alert Option, allowing the router (CA) serving the CN to intercept it and binds the mobile node's care-of address with the mobile node's home address. The details of this scheme is described in Correspondent Agent Operations. 4.0 Correspondent Agent Operations As described in the Introduction section, as a mobile node moves to = a new location, it sends a Registration Request to its home agent, informing the home agent of its new care-of address. The home agent in turn sends a Binding Update message (setting the IP destination address of the message to the correspondent node address and Expires January 2001 [Page = 6] Internet Draft Intercepting Location Updates July 2000 including the Router Alert option in the IP packet) to notify the correspondent node of the mobile node new care-of-address. This Binding Update is intercepted by the last hop router (referred to as correspondent agent) to the correspondent node. To provide transparent optimal routing for the the correspondent node, and the benefits listed in the Introduction Section, the = access router(s) serving the correspondent nodes MUST support the Correspondent Agent functions described here. Otherwise, the Binding Update message will reach the correspondent node. If the access routers in the network where the correspondent node resides supports the location hiding route optimization proposed here, the correspondent agent caches the mobility bindings as described in MIP-OPTIM, and tunnels data for the mobile node to the care-of address. If there are no correspondent agents in the access network, the location hiding route optimization has the same effect as MIP-OPTIM, i.e. if the correspondent node supports MIP-OPTIM, it tunnels data for the mobile node to the care-of address. If the correspondent node does not support MIP-OPTIM, packets addressed to the mobile node are routed via the home agent (i.e no route optimization), as in MIP. In other words, this scheme is backward compatible with both MIP and MIP-OPTIM. Expires January 2001 [Page = 7] Internet Draft Intercepting Location Updates July 2000 +-------------+ |correspondent| |node | +-------------+ # # data addressed to # mobile node home address # Binding +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ Update (BU) |correspondent| ------->|agent | | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ | # * | # * | # * | # * | # * +=3D=3D=3D=3D=3D+ Registration * |Home | Request * |Agent|<----------+ * +=3D=3D=3D=3D=3D+ | * # | * # | * # home | * # address | * COA +------+ | +------+ |mobile| | |mobile| |node | |-- |node | +------+ +------+ mobile node mobile node at home network at foreign network When a correspondent agent receives a Binding Update message, it caches the mobile node's home address and its care-of address, if = the correspondent agent is the next hop to the care-of address, off this subnet. It should send an ICMP redirect message to the correspondent node, to redirect packets addressed to the mobile node to the correspondent agent. The redirect message should cause the correspondent node IP stack to add or update a route towards the mobile IP home address with the next hop set to the correspondent agent . This ensures that the correspondent node IP stack forwards datagrams addressed to the mobile node, to the correspondent agent instead of another gateway or router. Note that existing hosts can process the ICMP redirect message as required above. According to RFC1122 on host requirements when receiving an ICMP redirect = message, "A host receiving a Redirect message MUST update its routing information accordingly." Expires January 2001 [Page = 8] Internet Draft Intercepting Location Updates July 2000 If the correspondent agent is not the next hop to the care-of = address it sends the Binding Update message to, the next hop router to the care-of address. The next hop router, which is referred to as the redirector, caches the mobile node's home address and its care-of address and acknowledges the binding update message. The collective functions of the binding update interceptor and data redirector = shown in the figure below will be referred to as the correspondent agent. Note that here, the interceptor and redirector are not co-located, whereas in the scenario described in the preceding paragraph, the interceptor is also the the next hop to the care-of address i.e the interceptor and redirector are co-located. When the interceptor receives the acknowledgement message for the binding update from the redirector, it should send an ICMP redirect message to the correspondent node to redirect the packets addressed to the mobile node and the redirection router. The correspondent = node processes the ICMP redirect message as described in the preceeding scenario where the interceptor and redirector are co-located. If = the correspondent node, interceptor and redirector are on the same LAN, the Binding Update to the redirector may be encrypted to prevent the correspondent node from obtaining the care-of address of the mobile node in the clear by snooping on binding update messages on the LAN. +-------------+ |correspondent| |node | +-------------+ # # data addressed to # mobile node home address # = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D#=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D+ | # | | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ BU = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ | Correspondent | |interceptor|------>|redirector| | Agent | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ | | ^ * | = +=3D=3D=3D=3D|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D*=3D=3D=3D=3D=3D+ | * Binding | * Update(BU) | * +=3D=3D=3D=3D=3D+ * COA |Home | +------+ |Agent|<------------------|mobile| +=3D=3D=3D=3D=3D+ Registration |node | Request +------+ at foreign network Expires January 2001 [Page = 9] Internet Draft Intercepting Location Updates July 2000 5.0 Binding Messages In [MIP-OPTIM], it is not necessary to acknowledge Binding Update messages. This may result in the home agent needlessly = retransmitting the binding update message to correspondent nodes that do not = support these messages. Quoted from [MIP-OPTIM], "When a mobile node's home agent intercepts a datagram from the home network and tunnels it to the mobile node, the home agent may deduce that the original source of the datagram has no binding cache entry for the destination mobile node. 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. For a Binding Update to be authenticated by the original source node, the source node and the home agent must have established a mobility security association." We propose that the home agent be provisioned with 2 parameters "binding_update_retry count", "binding_update_abandon_count". "binding_update_retry count" is the count of packets received from the CN and addressed to the MN since the sending of the last binding update message to a correspondent node. It should be configured to = be on the order of < 10 packets. "binding_update_abandon_count" is the count of binding updates sent from the HA to a CN. The number determines when the HA should give up sending binding updates to CN at the "binding_update_retry_count" interval. This parameter should be on the order of < 3. By using these parameters, the home agent can determine if it should send further Binding Update messages to a correspondent node. The same scheme should be used by Foreign agents and MNs(co-located FA) on the binding warning. 6.0 Constraining location update information to a domain or routing = area When a mobile node or foreign agent sends a location update message (i.e Registration Request with Binding Warning Extension or Binding Warning) to the home agent, it should add the Router Alert Option to the location update message. It is then possible for an "intermediate" router to intercept the location update message (i.e Binding Warning Extension message sent with the Registration Request Expires January 2001 [Page = 10] Internet Draft Intercepting Location Updates July 2000 message or Binding Warning) from the mobile node/foreign agent to = the home agent and create a tunnel to the mobile node or foreign agent. The "intermediate" router should forward the update message towards the CN after changing the ip source address of the message to its = own address. This allows the correspondent agent or node (if no agent) = to setup a tunnel to the intermediate router instead. The advantage of allowing tunnels to be setup to intermediate routers is to reduce location update latency. If a MN moves within a domain, the binding update message does not have to travel all the way to the correspondent agent/node, i.e a tunnel does not have to be reconstructed from CA/CN to MN/FA when an MN moves. Using such a hierarchy of "foreign agents" in the networks such that update messages do not have to be relayed all the way to the Home Agent are advocated in HAWAII/CellularIP/REGIONAL-REG. This proposal facilitates the use of such "hierarchical foreign agents" by leveraging border routers or firewalls at the edges of a network domain to function as these "hierarchical foreign agents". Border routers or firewalls where the Registration Request message traverses on its way to the home agent can be configured to act as "gateway foreign agents". Mobile nodes or foreign agents send location update (Registration Request) messages to the home agent as in the base Mobile IP specification, instead of having to send special "regional" registration messages to a "gateway foreign agent". The advantages of the scheme proposed here facilitate contraining location update messages to a region or domain include: * intra-domain mobility improvement is performed using the base Mobile IP messages. No new registration messages (such as regional tunnel messages in REGIONAL-REG) are required. The Registration Request messages defined in RFC2002 can be used with the addition of Router Alert Option. * no assumptions are made about foreign nodes or mobile nodes being informed of a "gateway foreign agent" or foreign nodes or mobile nodes being configured with a default route to a "domain root router". * the "gateway care-of address" does not have to "flood a beacon periodically in the access network to allow base stations to create routes back to the gateway". To quote from Cellular IP, "All packets transmitted by mobile hosts regardless of their destination address are routed to the gateway using these routes." * no host-based forwarding (which has scalability issues) in = internal Expires January 2001 [Page = 11] Internet Draft Intercepting Location Updates July 2000 routers of a foreign domain required, i.e no states are stored in internal routers. In HAWAII, and quoted from the HAWAII draft "Each router in the path between the mobile host and the "domain root router" adds a forwarding entry for the mobile host". * foreign agents do not have to be configured with the domain "gateway foreign agent" and need not advertise the "gateway foreign agent". When the location update message traverses the border router/firewall of a domain on its way to the home agent, the "gateway foreign agent" function can be activated. * If the home agent is in the same network domain as the foreign agent or mobile node, the location update message goes directly to the home agent without having to be sent to a "gateway foreign = agent" first. Expires January 2001 [Page = 12] Internet Draft Intercepting Location Updates July 2000 6.1 Location Update Message intercepted by border routers 6.1.1 Mobile node and correspondent node in different domains +-------------+ |correspondent| |node | +-------------+ H H H Binding = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ Update (BU) |correspondent| +------>|agent |dddddddddddddddddd | = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ d home | a d address(H) | a d +=3D=3D=3D=3D=3D=3D+ +=3D=3D=3D=3D=3D+ a = d |mobile| |home | a RR d |node | |agent| a <----to home---+ d +=3D=3D=3D=3D=3D=3D+ +=3D=3D=3D=3D=3D+ a = agent | d ^ a | d RR=3DCOAa | aaaaaaaaaaaaaaaaa | d | a | d | a COAa | d COAd +=3D=3D=3D=3D=3D=3D+ Registration = +=3D=3D=3D=3D=3D=3D+ |Border| Request (RR) |Border| |Router|<---------+ |Router| +=3D=3D=3D=3D=3D=3D+cccccccc | = +=3D=3D=3D=3D=3D=3D+ ^ b c | ^ e RR=3DCOAb | b c | RR=3DCOAc RR| e | b c | | e | b COAb c | COAc | e COAe +------+ c | +------+ +------+ |mobile| c +---|mobile| |mobile| |node | ccccccc|node | |node | +------+ +------+ +------+ ---------> mobile node moves to another mobile node = moves location in the same foreign to another network domain foreign = domain i) Mobile node and correspondent node in different = domains ii) Mobile node moves to different domain Expires January 2001 [Page = 13] Internet Draft Intercepting Location Updates July 2000 A provider may configure these "intermediate" routers e.g border routers or firewalls, to process the update message and setup tunnels. Intermediate routers may setup tunnels towards the mobile node if configured to do so. In most operation networks, only border routers or firewalls and the serving router (correspondent agent) of the correspondent node may need to setup these tunnels. The update message will be terminated at a router which already has a tunnel = for this mobile node. The "intermediate" router which intercepts the update message sets up a tunnel to the care-of address of the mobile node (or the foreign agent) When the mobile node moves within a foreign network domain e.g = moving from one cell to another, the update message may be intercepted at a border router within the foreign network. The update message does = not have to be relayed to the home agent because the care-of address (COAa), from the home agent perspective has not changed. When the mobile node moves from one mobile network into another mobile network, the update message will reach another border router. This = BR sends an update message towards the home agent to inform the home agent that the tunnel endpoint has changed. The BR setup a tunnel to the COA of the mobile node or FA. The home agent sends a binding update message towards the correspondent node. The correspondent agent or node may set up a tunnel to the BR. Expires January 2001 [Page = 14] Internet Draft Intercepting Location Updates July 2000 6.1.2 Mobile node and correspondent node in the same domain If a mobile node is not in its home domain, and a node in the = foreign domain initiates communication with the mobile node, data addressed to the mobile node home address from this foreign domain will be redirected to the local co-located care-of address (COAb in this case), as shown below. The location update (Registration Request) message may be intercepted by a border router (BR#1) for this = foreign domain, and BR#1 redirects data to the mobile node by sending a Binding Update message towards the correspondent node. BR#1 is acting as a "proxy" home agent - the correspondent agent/node should be able to trust, or authenticate BR#1 if necessary. For instance, all border routers serving a domain can be provided with a "private key" and can be authenticated by any nodes within the domain using the "public key". If the mobile node moves to another location = within this foreign network, BR#1 intercepts the Registration Request from the mobile node or foreign agent and sends a Binding Update message with the new COA (which may be a private address) towards the correspondent node. home address(H) +=3D=3D=3D=3D=3D=3D+ +=3D=3D=3D=3D=3D+ |mobile| |home | |node | |agent| +=3D=3D=3D=3D=3D=3D+ +=3D=3D=3D=3D=3D+ ^ RR=3DCOAa| | | COAa +=3D=3D=3D=3D=3D=3D+ |Border|HHHHHHHHHHHHHHHHHHHHHHHHH |Router| BU=3DCOAb H |#1 |----------------------+ H | | | H +=3D=3D=3D=3D=3D=3D+ | H ^ b | H RR=3DCOAb| b BU=3DCOAb | H | b | H | b COAb V H +------+ +-------------+ = +-------------+ |mobile| |correspondent| = |correspondent| |node |bbbbbbbbbbbbb|agent |HHHHHHHH|node = | +------+ +-------------+ = +-------------+ mobile node and correspondent node in the same foreign domain (Note: BU - Binding Update) Expires January 2001 [Page = 15] Internet Draft Intercepting Location Updates July 2000 A more efficient way of notifying the correspondent node in the same domain is by sending the location update message (eg Binding Update) directly towards the correspondent node, but this approach places more burden on the mobile node. Nevertheless, it is possible to = have BR#1 send the list of correspondent nodes that it has redirected within the domain in the Registration Reply message to the mobile node. This allows the mobile node to send Binding Update messages directly (if necessary, to further reduce handoff latency) to the correspondent nodes, subsequently when it moves to another location within the domain. Otherwise data from within this domain, = addressed to the mobile node is routed via BR#1. Expires January 2001 [Page = 16] Internet Draft Intercepting Location Updates July 2000 6.1.2.1 Mobile node and correspondent node in the mobile node's home domain Even when the location update message has to be sent via BR#1, the handoff latency is still less than if the local correspondent nodes have to be notified via a home agent which is not in the same = domain. If the home agent is in the same domain, the location update ( Registration Request) message is forwarded to the home agent without having to go through a border router, as shown below. In both cases (figure above and below), subsequent data (after being notified of new location) addressed to the mobile node from within this domain = is routed directly to the mobile node (not via BR#1 or home agent). +=3D=3D=3D=3D=3D=3D+ |home |; Tue, 18 Jul 2000 05:33:51 -0400 (EDT) Received: from standards (47.234.32.16:2050) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7F652@standards.nortelnetworks.com>; Tue, 18 Jul 2000 5:22:44 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13407 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 18 Jul 2000 05:22:43 -0400 Received: from techtransfer.swift.shef.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7F651@standards.nortelnetworks.com>; Tue, 18 Jul 2000 5:22:43 -0400 X-Mailer: Lotus Notes Release 5.0.1a (Intl) 17 August 1999 X-MIMETrack: Serialize by Router on TechTransfer/Swift(Release 5.0.4 |June 8, 2000) at 07/18/2000 10:33:14 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Message-ID: Date: Tue, 18 Jul 2000 10:33:12 +0100 Reply-To: Matthias.Kraner@SWIFT.SHEF.AC.UK Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Matthias Kraner Subject: Re: [MOBILE-IP] Handoff Discussions X-To: Basavaraj.Patil@NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello, I am following the discussion from some distance. Regarding handoffs, IIP can offer some nice new thoughts on how to do them very quickly and in some cases even without interruption. It offers some new thoughts though. The fundamental difference is that it assumes hosts to be mobile aware but it offers for all reluctant hosts, that are not mobile aware, a nice and neat solution to communicate with mobile nodes. The entity for that is called TVR. I believe MIP and the fast hand off issues can benefit from some of the proposed solutions. Chern Nam will present IIP in Pittsburgh and I believe he would be interested in sharing his ideas with you Matthias Basavaraj Patil To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Sent by: "IP Routing for cc: Wireless/Mobile Hosts Subject: Re: [MOBILE-IP] Handoff Discussions (mobile-ip)" 17/07/2000 15:05 Please respond to Basavaraj.Patil Steve, >> Our goal at the end of this IETF meeting is to have a single draft for >> a working group item for handoff. (Two may be needed, perhaps a >> separate item for v4 and for v6). > > Why can't there be multiple hand-off technologies? Handoff technologies are either of the following types : Network initiated, Mobile initiated, Mobile assisited (MAHO) and a hybrid combination of these. The network elements that play a role in the handoffs differ and optimization to enhance the performance of handoff can be done by multiple methods. There is a bunch of other issues as well but to answer your question, yes there can be multiple solutions, but what we are trying to do here is to take all the commonlaities of the different proposals currently on the table and resolve the differences to arrive at a single (or two) solutions. > >> Between the two sessions we'd like a small group to go work offline to merge >> some proposals or pick one, or one or two for the group to decide upon. In >> the second session we'd like to allocate 30 minutes to talk about the >> outcome of this activity, and a very short presentation of the one or >> two proposals that have been agreed upon. > > This is a lot to accomplish in 2 weeks, since in order for a group (of >unbiased individuals) to merge proposals, or select 2 for the WG to then >select during the second session, they're going to have to be in a very >finished state. > We do not expect this to be done in 2 weeks. It's a start. If required we can talk about an interim meeting to merge the proposals and arrive at a consensus solution. > I would rather the WG discuss the merits of each proposal in Pittsburg, >perhaps what is required of a WG sanctioned proposal, then this smaller group >meet after the meeting to discuss recommendations to the group within 2 weeks. > This can happen on the discussion list and the merits of each proposal can be highlighted at the meteing in Pittsburgh. > Cheers, > Steve > Regards, -Basavaraj From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jul 18 05:51:23 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28850 for ; Tue, 18 Jul 2000 05:51:23 -0400 (EDT) Received: from standards (47.234.32.16:4086) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7F686@standards.nortelnetworks.com>; Tue, 18 Jul 2000 5:40:21 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13474 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 18 Jul 2000 05:40:20 -0400 Received: from techtransfer.swift.shef.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7F685@standards.nortelnetworks.com>; Tue, 18 Jul 2000 5:40:20 -0400 X-Mailer: Lotus Notes Release 5.0.1a (Intl) 17 August 1999 X-MIMETrack: Serialize by Router on TechTransfer/Swift(Release 5.0.4 |June 8, 2000) at 07/18/2000 10:50:52 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Message-ID: Date: Tue, 18 Jul 2000 10:50:43 +0100 Reply-To: Matthias.Kraner@SWIFT.SHEF.AC.UK Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Matthias Kraner Subject: Re: [MOBILE-IP] Europe is paying $5 per gallon for gasoline 17662 X-To: admin@notodrugs.org To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi, appologising for a naughty comment, but this auto reply comments are mega annoying. Theey are flooding the email account and I am not particularly intersted who is in holiday and who is not. Could you please code your clients not to auto reply to lists???!!!!! Matthias broklvr@JOESUSEDPC.COM Sent by: "IP Routing for To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Wireless/Mobile Hosts cc: (mobile-ip)" Subject: [MOBILE-IP] Europe is paying $5 per gallon for gasoline 17662 15/07/2000 19:22 Please respond to admin Current Market Information. New strategy could realize up to 40% or greater returns. Free Video Free "How to" manual for successfully trading in the oil marketplace Find out where today's profits are We are so confident that you will be able to use our easy investing methods to profit from today's soaring fuel prices that we will give you a "FREE TRADE" just to try us out. Take advantage of the high gasoline prices.... NOW! Earn a "Fortune" in the oil market! Act Now -- click below for complete information. click here To be removed: click here Current Market Information. New strategy could realize up to 40% From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jul 18 06:43:38 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16990 for ; Tue, 18 Jul 2000 06:43:38 -0400 (EDT) Received: from standards (47.234.32.16:2268) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7F6CB@standards.nortelnetworks.com>; Tue, 18 Jul 2000 6:32:18 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13565 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 18 Jul 2000 06:32:17 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7F6C9@standards.nortelnetworks.com>; Tue, 18 Jul 2000 6:22:16 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12300; Tue, 18 Jul 2000 06:32:47 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200007181032.GAA12300@ietf.org> Date: Tue, 18 Jul 2000 06:32:47 -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-hawaii-01.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 : IP micro-mobility support using HAWAII Author(s) : R. Ramjee, T. La Porta, S. Thuel, K. Varadhan, L. Salgarelli Filename : draft-ietf-mobileip-hawaii-01.txt Pages : 31 Date : 17-Jul-00 In this contribution, we present HAWAII: a domain-based approach for supporting mobility. HAWAII uses specialized path setup schemes which install host-based forwarding entries in specific routers to support intra-domain micro-mobility and defaults to using Mobile-IP for inter-domain macro-mobility. These path setup schemes deliver excellent performance by reducing mobility related disruption to user applications, and by operating locally, reduce the number of mobility related updates. Also, in HAWAII, mobile hosts retain their network address while moving within the domain, simplifying Quality of Service support. Furthermore, reliability is achieved through maintaining soft-state forwarding entries for the mobile hosts and leveraging fault detection mechanisms built in existing intra-domain routing protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-hawaii-01.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-hawaii-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-hawaii-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000717145400.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-hawaii-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-hawaii-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000717145400.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jul 18 07:24:19 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16992 for ; Tue, 18 Jul 2000 06:43:38 -0400 (EDT) Received: from standards (47.234.32.16:2268) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7F6CD@standards.nortelnetworks.com>; Tue, 18 Jul 2000 6:32:21 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13566 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 18 Jul 2000 06:32:21 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7F6CA@standards.nortelnetworks.com>; Tue, 18 Jul 2000 6:22:21 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12333; Tue, 18 Jul 2000 06:32:52 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200007181032.GAA12333@ietf.org> Date: Tue, 18 Jul 2000 06:32:52 -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-paging-hawaii-01.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 : Paging support for IP mobility using HAWAII Author(s) : R. Ramjee, T. La Porta, L. Li Filename : draft-ietf-mobileip-paging-hawaii-01.txt Pages : 21 Date : 17-Jul-00 This document defines extensions to the HAWAII IP micro-mobility protocol to enable paging. Paging facilitates efficient power management at the mobile host by allowing the host to update the network less frequently at the cost of providing the network with only approximate location information. The protocol extensions described here provide a means for the network to determine the exact location of a mobile host before delivering packets destined to the mobile host. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-paging-hawaii-01.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-paging-hawaii-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-paging-hawaii-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000717145409.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-paging-hawaii-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-paging-hawaii-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000717145409.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jul 18 12:46:41 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24477 for ; Tue, 18 Jul 2000 12:46:41 -0400 (EDT) Received: from standards (47.234.32.16:1948) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7F7E6@standards.nortelnetworks.com>; Tue, 18 Jul 2000 12:34:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13932 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 18 Jul 2000 12:34:52 -0400 Received: from ebene.inrialpes.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7F7E5@standards.nortelnetworks.com>; Tue, 18 Jul 2000 12:34:51 -0400 Received: from galibier.inrialpes.fr (galibier.inrialpes.fr [194.199.24.97]) by ebene.inrialpes.fr (8.9.3/8.8.5) with ESMTP id SAA16543 for ; Tue, 18 Jul 2000 18:45:16 +0200 (MET DST) Received: from inrialpes.fr (localhost [127.0.0.1]) by galibier.inrialpes.fr (8.8.7/8.8.5) with ESMTP id SAA22101 for ; Tue, 18 Jul 2000 18:45:16 +0200 (MET DST) X-Mailer: Mozilla 4.6 [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: <3974899C.74843739@inrialpes.fr> Date: Tue, 18 Jul 2000 18:45:16 +0200 Reply-To: Thierry.Ernst@INRIALPES.FR Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Thierry Ernst Organization: INRIA Rhone-Alpes Subject: [MOBILE-IP] Mobile Networks To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Dear working group members, I have posted an internet draft entitled "Mobile Networks Support in Mobile IPv6" http://www.ietf.org/internet-drafts/draft-ernst-mobileip-v6-network-00.txt This draft addresses the problems of routing datagrams to nodes located in an IPv6 mobile network. A MOBILE NETWORK is a network that is changing its point of attachment dynamically such as a network deployed in an aircraft, a boat, or a car. As the Mobile IPv6 specification says that the mobile node could be a HOST or a ROUTER, this means that the specification does (implicitly) consider Mobile Networks too: a router and all its attached nodes. However, Mobile IPv6 has been developed with the focus of mobile HOSTS and is unable to maintain communication between a Correspondent Node and a host attached to the mobile router. Our draft therefore discusses the Mobile IPv6 ability to support mobile networks and proposes some extensions to Mobile IPv6. Basically, the mobile router that connects the mobile network to the Internet performs Mobile-IPv6. As any mobile node, it gets a care-of address and registers it with its Home Agent. In addition, it sends its care-of address to the Correspondent Nodes. However, this is not enough if a Correspondent Node wants to communicate with one of the node located in the mobile network. We therefore proposes extensions to instruct the Home Agent and the Correspondent Node to use the care-of address of the mobile router when they want to communicate with a node located in the mobile network. We use the term "Prefix scope binding updates". Please read the draft and tell us if you agree that Mobile IPv6 needs extensions. Then, any comment about our way to extend Mobile IPv6 is welcome. Thank you for your consideration, Regards, Thierry. -- * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) * http://www.inrialpes.fr/planete/pub/MobiNet/mobinet.html From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jul 18 19:08:14 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08299 for ; Tue, 18 Jul 2000 19:08:14 -0400 (EDT) Received: from standards (47.234.32.16:3467) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7F954@standards.nortelnetworks.com>; Tue, 18 Jul 2000 18:57:09 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 14434 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 18 Jul 2000 18:57:09 -0400 Received: from dnsmx2pya.telcordia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7F946@standards.nortelnetworks.com>; Tue, 18 Jul 2000 18:47:09 -0400 Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8]) by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with SMTP id SAA04398; Tue, 18 Jul 2000 18:53:18 -0400 (EDT) Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 85256920.007DB5EE ; Tue, 18 Jul 2000 18:53:05 -0400 X-Lotus-FromDomain: TELCORDIA Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <85256920.007DB577.00@notes949.cc.telcordia.com> Date: Tue, 18 Jul 2000 18:52:24 -0400 Reply-To: Archan Misra Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Archan Misra Subject: [MOBILE-IP] A draft submission to the IETF X-cc: Subir Das , mcauley@research.telcordia.com, das@cse.uta.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Folks, Just wanted to inform you that we have submitted a draft to the online IETF directories describing a mobility protocol specifically designed for intra-domain mobility. The proposal includes mechanisms for suporting paging and fast handoffs. Since it may be a while before the draft is available from the IETF site, those of you who are interested may obtain it from the following ftp site: ftp://ftp.research.telcordia.com/pub/world/archan/draft-ietf-idmp-00.txt Suggestions and comments are appreciated. Archan and Subir From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jul 19 09:50:56 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08902 for ; Wed, 19 Jul 2000 09:50:55 -0400 (EDT) Received: from standards (47.234.32.16:2654) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7FB25@standards.nortelnetworks.com>; Wed, 19 Jul 2000 9:39:37 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 15052 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 19 Jul 2000 09:39:37 -0400 Received: from flower.comeng.chungnam.ac.kr (168.188.44.2:54605) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7FB1E@standards.nortelnetworks.com>; Wed, 19 Jul 2000 9:29:36 -0400 Received: from Beethoven (Beethoven.comeng.chungnam.ac.kr [168.188.46.199]) by flower.comeng.chungnam.ac.kr (8.9.1/8.9.1) with SMTP id WAA22941 for ; Wed, 19 Jul 2000 22:35:24 +0900 (KST) 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.2919.6600 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Message-ID: <010601bff186$d942ab40$c72ebca8@ce.cnu.ac.kr> Date: Wed, 19 Jul 2000 22:40:00 +0900 Reply-To: "Park, Hyun Seo" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Park, Hyun Seo" Subject: [MOBILE-IP] Questions about Route Optimization in Mobile IPv4 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id JAA08902 I have some questions as follows .... Any comments are appreciated .... 1) How much 'cost' does "Triangle Routing" impose on packets from CH to MN in basic Mobile IPv4 ? Is there any Modeling, Demonstration or Simulation about it ? 2) In Route Optimization draft, CH maintains Binding Cache. How much 'overhead' on it ? And, How about 'tradeoff' btw. this 'overhead' and above 'cost' ? 3) In Route Optimization draft, If above 'cost' imposed by "Triangle Routing" is very high and CH can't understand Route Optimization protocol, CH doesn't acknowledge "Binding Update" ..... How about my humble opinion ? My thoughts ..... If HA doesn't "Binding Acknowledge" from CH for some time, it deduces the CH can't understand Route Optimization protocol ... Then, it tries to send "Binding Update" to Routers 1~3 hops apart from the CH .... So this activity will be able to solve "Triangle Routing" problem indirectly ... HA +++++++++++ FA ---- MN | + + | + + | + + | + + | + + R2 + | + R1 + tunneling | - link CH It's too difficult to figure it ...... *^^* Thanks for your time to read this mail .... And any comments will be good enough to me .... Thanks in advance for any comments .... From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jul 19 12:50:43 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23636 for ; Wed, 19 Jul 2000 12:50:43 -0400 (EDT) Received: from standards (47.234.32.16:1721) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7FBE0@standards.nortelnetworks.com>; Wed, 19 Jul 2000 12:39:07 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 15315 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 19 Jul 2000 12:39:06 -0400 Received: from shako.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7FBDF@standards.nortelnetworks.com>; Wed, 19 Jul 2000 12:29:06 -0400 Received: from cisco.com (msubbara-u10.cisco.com [161.44.59.58]) by shako.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA18621 for ; Wed, 19 Jul 2000 12:39:26 -0400 (EDT) X-Mailer: Mozilla 4.7C-CISCOENG [en] (X11; U; 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: <3975D9CD.9080814@cisco.com> Date: Wed, 19 Jul 2000 12:39:41 -0400 Reply-To: msubbara@cisco.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Madhavi W Subbarao Organization: Cisco Systems Subject: [MOBILE-IP] Q's regarding Regional Registrations To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit HI, I just read draft-ietf-mobileip-reg-tunnel-02.txt, and have a few questions: - Suppose MN has a co-located COA, but wishes to use an advertised GFA COA, and the 'R' bit is set in the local FA advertisements. Then the MN sends a Registration Request to the local FA with the COA=GFA COA and a Hierarchical Foreign Agent Extension indicating its co-located COA. According to the draft, when the local FA receives this Reg. Req., it adds a Hierarchical Foreign Agent extension indicating it's FA address and relays the Reg. Req. to the GFA. Why does the FA need to add this extension? - How does the HA know that it must issue back 'registration keys' upon receiving a Registration Request, especially if the COA=GFA COA and there is no GFA extension included in the Reg. Req.? How are 'registration keys' from the HA communicated back to a GFA or MN? - According to the draft, in a regional registration, the MN sets the COA field to either the FA COA or zero. What about co-located COA? If these questions have already been posed and answered, I apologize. Please refer me to the answers. Thanks, Madhavi From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jul 19 18:00:11 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29617 for ; Wed, 19 Jul 2000 18:00:11 -0400 (EDT) Received: from standards (47.234.32.16:3207) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7FCEE@standards.nortelnetworks.com>; Wed, 19 Jul 2000 17:49:05 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 15686 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 19 Jul 2000 17:49:04 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7FCED@standards.nortelnetworks.com>; Wed, 19 Jul 2000 17:49:04 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA21576; Wed, 19 Jul 2000 14:59:39 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id OAA19608; Wed, 19 Jul 2000 14:59:35 -0700 X-Virus-Scanned: Wed, 19 Jul 2000 14:59:35 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdLcrzrh; Wed, 19 Jul 2000 14:59:24 PDT X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <010601bff186$d942ab40$c72ebca8@ce.cnu.ac.kr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39762413.39451C25@iprg.nokia.com> Date: Wed, 19 Jul 2000 14:56:35 -0700 Reply-To: Charlie Perkins Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Charlie Perkins Organization: Nokia Subject: Re: [MOBILE-IP] Questions about Route Optimization in Mobile IPv4 X-To: "Park, Hyun Seo" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello, I'll try to make some answers, but of course the questions that you ask do not have any absolute answers. > 1) How much 'cost' does "Triangle Routing" impose on packets from > CH to MN in basic Mobile IPv4 ? This depends on the placement of the network entities, and the traffic models employed. There is no one answer. > Is there any Modeling, Demonstration or Simulation about it ? There have been quite a few attempts to analyze parts of the situation. Off the top of my head, I can remember work by Stuart Jacobs for authentication, and by Ruixi Yuan for an idea about "friends" of a mobile node. There are quite a few other works. > 2) In Route Optimization draft, CH maintains Binding Cache. > How much 'overhead' on it ? Memory is the main overhead, along with additional search time. These costs are typically considered to be insignificant compared to the network messaging costs. > And, How about 'tradeoff' btw. this 'overhead' and above 'cost' ? Thus, the tradeoff would usually be for more processing complexity and less messaging complexity (i.e., maintaining more "state"). > 3) In Route Optimization draft, > If above 'cost' imposed by "Triangle Routing" is very high and O.K. > CH can't understand Route Optimization protocol, > CH doesn't acknowledge "Binding Update" ..... O.K. We agree so far... > How about my humble opinion ? > My thoughts ..... > If HA doesn't "Binding Acknowledge" from CH for some time, > it deduces the CH can't understand Route Optimization protocol ... > Then, it tries to send "Binding Update" to Routers 1~3 hops apart from > the CH .... > So this activity will be able to solve "Triangle Routing" problem indirectly ... Take a look at VIP, from Teraoka/Sony, which does things this way. The problem seems to be that it's hard to establish security associations with random infrastructure routers. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jul 19 19:36: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 TAA03035 for ; Wed, 19 Jul 2000 19:36:01 -0400 (EDT) Received: from standards (47.234.32.16:1568) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7FD33@standards.nortelnetworks.com>; Wed, 19 Jul 2000 19:24:50 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 15775 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 19 Jul 2000 19:24:50 -0400 Received: from qhars002.nortel.com (47.101.112.102:35711) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7FD30@standards.nortelnetworks.com>; Wed, 19 Jul 2000 19:14:50 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Thu, 20 Jul 2000 00:22:56 +0100 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Wed, 19 Jul 2000 19:12:46 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Wed, 19 Jul 2000 19:12:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFF1D6.D77297D0" Message-ID: Date: Wed, 19 Jul 2000 19:12:42 -0400 Reply-To: Muhammad Jaseemuddin Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Muhammad Jaseemuddin Subject: Re: [MOBILE-IP] Questions about Route Optimization in Mobile IPv4 X-To: Charlie Perkins 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_01BFF1D6.D77297D0 Content-Type: text/plain > -----Original Message----- > From: Charlie Perkins [SMTP:charliep@IPRG.NOKIA.COM] > Sent: Wednesday, July 19, 2000 5:57 PM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Questions about Route Optimization in Mobile > IPv4 > > Hello, > > I'll try to make some answers, but of course the questions that > you ask do not have any absolute answers. > > > > 1) How much 'cost' does "Triangle Routing" impose on packets from > > CH to MN in basic Mobile IPv4 ? > > This depends on the placement of the network entities, and the traffic > models employed. There is no one answer. > > > Is there any Modeling, Demonstration or Simulation about it ? > > There have been quite a few attempts to analyze parts of the situation. > Off the top of my head, I can remember work by Stuart Jacobs for > authentication, and by Ruixi Yuan for an idea about "friends" of a > mobile node. There are quite a few other works. > > > 2) In Route Optimization draft, CH maintains Binding Cache. > > How much 'overhead' on it ? > > Memory is the main overhead, along with additional search time. > These costs are typically considered to be insignificant compared > to the network messaging costs. > [MJ] It may not be in the overhead category, but it requires changes in host's IP stack implementation. > > And, How about 'tradeoff' btw. this 'overhead' and above 'cost' ? > > Thus, the tradeoff would usually be for more processing complexity > and less messaging complexity (i.e., maintaining more "state"). > > > 3) In Route Optimization draft, > > If above 'cost' imposed by "Triangle Routing" is very high and > > O.K. > > > CH can't understand Route Optimization protocol, > > CH doesn't acknowledge "Binding Update" ..... > > O.K. We agree so far... > > > How about my humble opinion ? > > My thoughts ..... > > If HA doesn't "Binding Acknowledge" from CH for some time, > > it deduces the CH can't understand Route Optimization protocol ... > > Then, it tries to send "Binding Update" to Routers 1~3 hops apart > from > > the CH .... > > So this activity will be able to solve "Triangle Routing" problem > indirectly ... > > Take a look at VIP, from Teraoka/Sony, which does things this way. > The problem seems to be that it's hard to establish security associations > with random infrastructure routers. > > Regards, > Charlie P. ------_=_NextPart_001_01BFF1D6.D77297D0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] Questions about Route Optimization in Mobile = IPv4

    -----Original Message-----
    From:   Charlie Perkins = [SMTP:charliep@IPRG.NOKIA.COM]
    Sent:   Wednesday, July 19, 2000 5:57 PM
    To:     MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Re: [MOBILE-IP] Questions about = Route Optimization in Mobile IPv4

    Hello,

    I'll try to make some answers, but of = course the questions that
    you ask do not have any absolute = answers.


    > 1) How much 'cost' does = "Triangle Routing" impose on packets from
    >     CH to MN = in basic Mobile IPv4 ?

    This depends on the placement of the = network entities, and the traffic
    models employed.  There is no = one answer.

    >     Is there = any Modeling, Demonstration or Simulation about it ?

    There have been quite a few attempts = to analyze parts of the situation.
    Off the top of my head, I can = remember work by Stuart Jacobs for
    authentication, and by Ruixi Yuan for = an idea about "friends" of a
    mobile node.  There are quite a = few other works.

    > 2) In Route Optimization draft, = CH maintains Binding Cache.
    >     How much = 'overhead' on it ?

    Memory is the main overhead, along = with additional search time.
    These costs are typically considered = to be insignificant compared
    to the network messaging = costs.

    [MJ]  It may not be in the overhead category, but it = requires changes
    in host's IP stack = implementation.

    >     And, How = about 'tradeoff' btw. this 'overhead' and above 'cost' ?

    Thus, the tradeoff would usually be = for more processing complexity
    and less messaging complexity (i.e., = maintaining more "state").

    > 3) In Route Optimization = draft,
    >     If above = 'cost' imposed by "Triangle Routing" is very high and

    O.K.

    >     CH can't = understand Route Optimization protocol,
    >     CH = doesn't acknowledge "Binding Update" .....

    O.K.  We agree so far...

    >     How about = my humble opinion ?
    >     My = thoughts .....
    >     If HA = doesn't "Binding Acknowledge" from CH for some time,
    >     it = deduces the CH can't understand Route Optimization protocol ...
    >     Then, it = tries to send "Binding Update" to Routers 1~3 hops apart = from
    >     the CH = ....
    >     So this = activity will be able to solve "Triangle Routing" problem = indirectly ...

    Take a look at VIP, from Teraoka/Sony, = which does things this way.
    The problem seems to be that it's = hard to establish security associations
    with random infrastructure = routers.

    Regards,
    Charlie P.

------_=_NextPart_001_01BFF1D6.D77297D0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jul 19 21:30:19 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10947 for ; Wed, 19 Jul 2000 21:30:18 -0400 (EDT) Received: from standards (47.234.32.16:1172) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7FDBF@standards.nortelnetworks.com>; Wed, 19 Jul 2000 21:19:11 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 15969 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 19 Jul 2000 21:19:11 -0400 Received: from flower.comeng.chungnam.ac.kr (168.188.44.2:61580) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7FDBC@standards.nortelnetworks.com>; Wed, 19 Jul 2000 21:09:10 -0400 Received: from Beethoven (Beethoven.comeng.chungnam.ac.kr [168.188.46.199]) by flower.comeng.chungnam.ac.kr (8.9.1/8.9.1) with SMTP id KAA03065 for ; Thu, 20 Jul 2000 10:15:03 +0900 (KST) References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B9_01BFF234.05545FA0" 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: <00bc01bff1e8$95c0a400$c72ebca8@ce.cnu.ac.kr> Date: Thu, 20 Jul 2000 10:19:43 +0900 Reply-To: "Park, Hyun Seo" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Park, Hyun Seo" Subject: Re: [MOBILE-IP] Questions about Route Optimization in Mobile IPv4 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_00B9_01BFF234.05545FA0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 UkU6IFtNT0JJTEUtSVBdIFF1ZXN0aW9ucyBhYm91dCBSb3V0ZSBPcHRpbWl6YXRpb24gaW4gTW9i aWxlIElQdjQNCiAgVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLCBDaGFybGllIGFuZCBNdWhhbW1h ZCAuLi4uIA0KICBNeSBjb21tZW50cyBhcmUgaW5jbHVkZWQgLi4uLi4NCiAgICAgICAgICAgIEhl bGxvLCANCg0KICAgICAgICAgICAgSSdsbCB0cnkgdG8gbWFrZSBzb21lIGFuc3dlcnMsIGJ1dCBv ZiBjb3Vyc2UgdGhlIHF1ZXN0aW9ucyB0aGF0IA0KICAgICAgICAgICAgeW91IGFzayBkbyBub3Qg aGF2ZSBhbnkgYWJzb2x1dGUgYW5zd2Vycy4gDQoNCiAgICAgICAgICAgID4gMSkgSG93IG11Y2gg J2Nvc3QnIGRvZXMgIlRyaWFuZ2xlIFJvdXRpbmciIGltcG9zZSBvbiBwYWNrZXRzIGZyb20gDQog ICAgICAgICAgICA+ICAgICBDSCB0byBNTiBpbiBiYXNpYyBNb2JpbGUgSVB2NCA/IA0KDQogICAg VGhpcyBkZXBlbmRzIG9uIHRoZSBwbGFjZW1lbnQgb2YgdGhlIG5ldHdvcmsgZW50aXRpZXMsIGFu ZCB0aGUgdHJhZmZpYyANCiAgICBtb2RlbHMgZW1wbG95ZWQuICBUaGVyZSBpcyBubyBvbmUgYW5z d2VyLiANCg0KICAgID4gICAgIElzIHRoZXJlIGFueSBNb2RlbGluZywgRGVtb25zdHJhdGlvbiBv ciBTaW11bGF0aW9uIGFib3V0IGl0ID8gDQoNCiAgICBUaGVyZSBoYXZlIGJlZW4gcXVpdGUgYSBm ZXcgYXR0ZW1wdHMgdG8gYW5hbHl6ZSBwYXJ0cyBvZiB0aGUgc2l0dWF0aW9uLiANCiAgICBPZmYg dGhlIHRvcCBvZiBteSBoZWFkLCBJIGNhbiByZW1lbWJlciB3b3JrIGJ5IFN0dWFydCBKYWNvYnMg Zm9yIA0KICAgIGF1dGhlbnRpY2F0aW9uLCBhbmQgYnkgUnVpeGkgWXVhbiBmb3IgYW4gaWRlYSBh Ym91dCAiZnJpZW5kcyIgb2YgYSANCiAgICBtb2JpbGUgbm9kZS4gIFRoZXJlIGFyZSBxdWl0ZSBh IGZldyBvdGhlciB3b3Jrcy4gDQoNCiAgICBbUGFya10gSG93IGNhbiBJIGZpbmQgaXQgPyBJZiB5 b3Uga25vdywgcGxlYXNlIGxldCBtZSBrbm93IC4gDQoNCiAgICBPciB5b3UgY2FuIHNlbmQgZS1t YWlsIGFkZHJlc3NlcyB0byBjb250YWN0IHRoZW0sIGlmIHlvdSBrbm93Lg0KDQogICAgICAgICAg ICA+IDIpIEluIFJvdXRlIE9wdGltaXphdGlvbiBkcmFmdCwgQ0ggbWFpbnRhaW5zIEJpbmRpbmcg Q2FjaGUuIA0KICAgICAgICAgICAgPiAgICAgSG93IG11Y2ggJ292ZXJoZWFkJyBvbiBpdCA/IA0K DQogICAgTWVtb3J5IGlzIHRoZSBtYWluIG92ZXJoZWFkLCBhbG9uZyB3aXRoIGFkZGl0aW9uYWwg c2VhcmNoIHRpbWUuIA0KICAgIFRoZXNlIGNvc3RzIGFyZSB0eXBpY2FsbHkgY29uc2lkZXJlZCB0 byBiZSBpbnNpZ25pZmljYW50IGNvbXBhcmVkIA0KICAgIHRvIHRoZSBuZXR3b3JrIG1lc3NhZ2lu ZyBjb3N0cy4gDQoNCiAgICBbTUpdICBJdCBtYXkgbm90IGJlIGluIHRoZSBvdmVyaGVhZCBjYXRl Z29yeSwgYnV0IGl0IHJlcXVpcmVzIGNoYW5nZXMgDQogICAgaW4gaG9zdCdzIElQIHN0YWNrIGlt cGxlbWVudGF0aW9uLiANCg0KICAgIFtQYXJrXSBJIGFncmVlIHdpdGggeW91LiBUaGFua3MNCg0K ICAgID4gICAgIEFuZCwgSG93IGFib3V0ICd0cmFkZW9mZicgYnR3LiB0aGlzICdvdmVyaGVhZCcg YW5kIGFib3ZlICdjb3N0JyA/IA0KDQogICAgVGh1cywgdGhlIHRyYWRlb2ZmIHdvdWxkIHVzdWFs bHkgYmUgZm9yIG1vcmUgcHJvY2Vzc2luZyBjb21wbGV4aXR5IA0KICAgIGFuZCBsZXNzIG1lc3Nh Z2luZyBjb21wbGV4aXR5IChpLmUuLCBtYWludGFpbmluZyBtb3JlICJzdGF0ZSIpLiANCg0KICAg ID4gMykgSW4gUm91dGUgT3B0aW1pemF0aW9uIGRyYWZ0LCANCiAgICA+ICAgICBJZiBhYm92ZSAn Y29zdCcgaW1wb3NlZCBieSAiVHJpYW5nbGUgUm91dGluZyIgaXMgdmVyeSBoaWdoIGFuZCANCg0K ICAgIE8uSy4gDQoNCiAgICA+ICAgICBDSCBjYW4ndCB1bmRlcnN0YW5kIFJvdXRlIE9wdGltaXph dGlvbiBwcm90b2NvbCwgDQogICAgPiAgICAgQ0ggZG9lc24ndCBhY2tub3dsZWRnZSAiQmluZGlu ZyBVcGRhdGUiIC4uLi4uIA0KDQogICAgTy5LLiAgV2UgYWdyZWUgc28gZmFyLi4uIA0KDQogICAg PiAgICAgSG93IGFib3V0IG15IGh1bWJsZSBvcGluaW9uID8gDQogICAgPiAgICAgTXkgdGhvdWdo dHMgLi4uLi4gDQogICAgPiAgICAgSWYgSEEgZG9lc24ndCAiQmluZGluZyBBY2tub3dsZWRnZSIg ZnJvbSBDSCBmb3Igc29tZSB0aW1lLCANCiAgICA+ICAgICBpdCBkZWR1Y2VzIHRoZSBDSCBjYW4n dCB1bmRlcnN0YW5kIFJvdXRlIE9wdGltaXphdGlvbiBwcm90b2NvbCAuLi4gDQogICAgPiAgICAg VGhlbiwgaXQgdHJpZXMgdG8gc2VuZCAiQmluZGluZyBVcGRhdGUiIHRvIFJvdXRlcnMgMX4zIGhv cHMgYXBhcnQgZnJvbSANCiAgICA+ICAgICB0aGUgQ0ggLi4uLiANCiAgICA+ICAgICBTbyB0aGlz IGFjdGl2aXR5IHdpbGwgYmUgYWJsZSB0byBzb2x2ZSAiVHJpYW5nbGUgUm91dGluZyIgcHJvYmxl bSBpbmRpcmVjdGx5IC4uLiANCg0KICAgIFRha2UgYSBsb29rIGF0IFZJUCwgZnJvbSBUZXJhb2th L1NvbnksIHdoaWNoIGRvZXMgdGhpbmdzIHRoaXMgd2F5LiANCiAgICBUaGUgcHJvYmxlbSBzZWVt cyB0byBiZSB0aGF0IGl0J3MgaGFyZCB0byBlc3RhYmxpc2ggc2VjdXJpdHkgYXNzb2NpYXRpb25z IA0KICAgIHdpdGggcmFuZG9tIGluZnJhc3RydWN0dXJlIHJvdXRlcnMuIA0KDQogICAgW1Bhcmtd IEkgd2lsbCBsb29rIGludG8gVklQIC4uLi4gVGhhbmtzIGEgbG90IC4uLi4NCg0KICAgIEJ1dCwg VGhlcmUgaXMgdGhlIHNhbWUgcHJvYmxlbSB0aGF0IGl0J3MgaGFyZCB0byBlc3RhYmxpc2ggc2Vj dXJpdHkgYXNzb2NpYXRpb25zIHdpdGggcmFuZG9tIA0KDQogICAgQ0hzLCBpc24ndCBpdCA/IEFu ZCBJIHRoaW5rIHRoZSBwcm9ibGVtIHdpdGggQ0hzIGlzIG1vcmUgc2VyaW91cyB0aGFuIHdpdGgg cmFuZG9tIFJvdXRlcnMgLi4uIA0KDQogICAgQW0gSSByaWdodCA/DQoNCg0KDQo= ------=_NextPart_000_00B9_01BFF234.05545FA0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT5SRTogW01PQklMRS1JUF0gUXVlc3Rpb25zIGFib3V0 IFJvdXRlIE9wdGltaXphdGlvbiBpbiBNb2JpbGUgSVB2NDwvVElUTEU+DQo8TUVUQSBjb250ZW50 PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9a3NfY181NjAxLTE5ODciIGh0dHAtZXF1aXY9Q29udGVudC1U eXBlPg0KPE1FVEEgY29udGVudD0iTVNIVE1MIDUuMDAuMjkxOS42MzA3IiBuYW1lPUdFTkVSQVRP Uj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFEPg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJ Vj4mbmJzcDs8L0RJVj4NCjxCTE9DS1FVT1RFIA0Kc3R5bGU9IkJPUkRFUi1MRUZUOiAjMDAwMDAw IDJweCBzb2xpZDsgTUFSR0lOLUxFRlQ6IDVweDsgTUFSR0lOLVJJR0hUOiAwcHg7IFBBRERJTkct TEVGVDogNXB4OyBQQURESU5HLVJJR0hUOiAwcHgiPg0KICA8RElWPjxGT05UIHNpemU9Mj5UaGFu a3MgZm9yIHlvdXIgY29tbWVudHMsIENoYXJsaWUgYW5kIE11aGFtbWFkIC4uLi4gDQogIDwvRk9O VD48L0RJVj4NCiAgPERJVj48Rk9OVCBzaXplPTI+TXkgY29tbWVudHMgYXJlIGluY2x1ZGVkJm5i c3A7Li4uLi48L0ZPTlQ+PC9ESVY+DQogIDxQPjxGT05UIGZhY2U9QXJpYWwgDQogIHNpemU9Mj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQog IEhlbGxvLDwvRk9OVD4mbmJzcDs8L1A+DQogIDxQPjxGT05UIGZhY2U9QXJpYWwgDQogIHNpemU9 Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDtJJ2xsIHRyeSB0byANCiAgbWFrZSBzb21lIGFuc3dlcnMsIGJ1dCBvZiBjb3Vyc2UgdGhl IHF1ZXN0aW9ucyB0aGF0PC9GT05UPiA8QlI+PEZPTlQgDQogIGZhY2U9QXJpYWwgc2l6ZT0yPiZu YnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgeW91IGFzayBk byANCiAgbm90IGhhdmUgYW55IGFic29sdXRlIGFuc3dlcnMuPC9GT05UPiA8L1A+DQogIDxQPjxG T05UIGZhY2U9QXJpYWwgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgDQogICZndDsgMSkgSG93IG11Y2ggJ2Nvc3QnIGRvZXMgIlRyaWFuZ2xl IFJvdXRpbmciIGltcG9zZSBvbiBwYWNrZXRzIA0KICBmcm9tPC9GT05UPiZuYnNwOzxCUj48Rk9O VCBmYWNlPUFyaWFsIA0KICBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAN CiAgQ0ggdG8gTU4gaW4gYmFzaWMgTW9iaWxlIElQdjQgPzwvRk9OVD4gPC9QPg0KICA8VUw+DQog ICAgPFA+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+VGhpcyBkZXBlbmRzIG9uIHRoZSBwbGFjZW1l bnQgb2YgdGhlIG5ldHdvcmsgDQogICAgZW50aXRpZXMsIGFuZCB0aGUgdHJhZmZpYzwvRk9OVD4g PEJSPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPm1vZGVscyANCiAgICBlbXBsb3llZC4mbmJzcDsg VGhlcmUgaXMgbm8gb25lIGFuc3dlci48L0ZPTlQ+IDwvUD4NCiAgICA8UD48Rk9OVCBmYWNlPUFy aWFsIHNpemU9Mj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElzIHRoZXJlIGFueSANCiAg ICBNb2RlbGluZywgRGVtb25zdHJhdGlvbiBvciBTaW11bGF0aW9uIGFib3V0IGl0ID88L0ZPTlQ+ IDwvUD4NCiAgICA8UD48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5UaGVyZSBoYXZlIGJlZW4gcXVp dGUgYSBmZXcgYXR0ZW1wdHMgdG8gYW5hbHl6ZSANCiAgICBwYXJ0cyBvZiB0aGUgc2l0dWF0aW9u LjwvRk9OVD4gPEJSPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPk9mZiB0aGUgdG9wIG9mIG15IA0K ICAgIGhlYWQsIEkgY2FuIHJlbWVtYmVyIHdvcmsgYnkgU3R1YXJ0IEphY29icyBmb3I8L0ZPTlQ+ IDxCUj48Rk9OVCBmYWNlPUFyaWFsIA0KICAgIHNpemU9Mj5hdXRoZW50aWNhdGlvbiwgYW5kIGJ5 IFJ1aXhpIFl1YW4gZm9yIGFuIGlkZWEgYWJvdXQgImZyaWVuZHMiIG9mIA0KICAgIGE8L0ZPTlQ+ IDxCUj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5tb2JpbGUgbm9kZS4mbmJzcDsgVGhlcmUgYXJl IHF1aXRlIGEgDQogICAgZmV3IG90aGVyIHdvcmtzLjwvRk9OVD4gPC9QPg0KICAgIDxQPjxGT05U IGNvbG9yPSM4MDAwODAgZmFjZT1BcmlhbCBzaXplPTI+W1BhcmtdIEhvdyBjYW4gSSBmaW5kIGl0 IA0KICAgID8mbmJzcDs8L0ZPTlQ+PEZPTlQgY29sb3I9IzgwMDA4MCBmYWNlPUFyaWFsIHNpemU9 Mj5JZiB5b3Uga25vdywgcGxlYXNlIGxldCANCiAgICBtZSBrbm93IC4gPC9GT05UPjwvUD4NCiAg ICA8UD48Rk9OVCBjb2xvcj0jODAwMDgwIGZhY2U9QXJpYWwgc2l6ZT0yPk9yIHlvdSBjYW4gc2Vu ZCZuYnNwO2UtbWFpbCANCiAgICBhZGRyZXNzZXMgdG8gY29udGFjdCZuYnNwO3RoZW0sJm5ic3A7 aWYgeW91IGtub3cuPC9GT05UPjwvUD48L1VMPg0KICA8UD48Rk9OVCBmYWNlPUFyaWFsIHNpemU9 Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7IA0KICAm Z3Q7IDIpIEluIFJvdXRlIE9wdGltaXphdGlvbiBkcmFmdCwgQ0ggbWFpbnRhaW5zIEJpbmRpbmcg Q2FjaGUuPC9GT05UPiANCiAgPEJSPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPiZuYnNwOyZuYnNw OyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogICZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgSG93IG11Y2ggJ292ZXJoZWFkJyBvbiBpdCA/PC9GT05UPiA8L1A+DQog IDxVTD4NCiAgICA8UD48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5NZW1vcnkgaXMgdGhlIG1haW4g b3ZlcmhlYWQsIGFsb25nIHdpdGggDQogICAgYWRkaXRpb25hbCBzZWFyY2ggdGltZS48L0ZPTlQ+ IDxCUj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5UaGVzZSBjb3N0cyBhcmUgDQogICAgdHlwaWNh bGx5IGNvbnNpZGVyZWQgdG8gYmUgaW5zaWduaWZpY2FudCBjb21wYXJlZDwvRk9OVD4gPEJSPjxG T05UIA0KICAgIGZhY2U9QXJpYWwgc2l6ZT0yPnRvIHRoZSBuZXR3b3JrIG1lc3NhZ2luZyBjb3N0 cy48L0ZPTlQ+IDwvUD4NCiAgICA8UD48Qj48ST48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJp YWwgDQogICAgc2l6ZT0yPltNSl08L0ZPTlQ+PC9JPjwvQj48ST48L0k+Jm5ic3A7PEZPTlQgY29s b3I9IzAwMDBmZiBmYWNlPUFyaWFsIA0KICAgIHNpemU9Mj4gSXQgbWF5IG5vdCBiZSBpbiB0aGUg b3ZlcmhlYWQgY2F0ZWdvcnksIGJ1dCBpdCByZXF1aXJlcyANCiAgICBjaGFuZ2VzPC9GT05UPiA8 QlI+PEZPTlQgY29sb3I9IzAwMDBmZiBmYWNlPUFyaWFsIHNpemU9Mj5pbiBob3N0J3MgSVAgc3Rh Y2sgDQogICAgaW1wbGVtZW50YXRpb24uPC9GT05UPiA8L1A+DQogICAgPFA+PEZPTlQgY29sb3I9 IzgwMDA4MCBmYWNlPUFyaWFsIHNpemU9Mj5bUGFya10gSSBhZ3JlZSB3aXRoIHlvdS4gDQogICAg VGhhbmtzPC9GT05UPjwvUD4NCiAgICA8UD48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj4mZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFuZCwgSG93IGFib3V0IA0KICAgICd0cmFkZW9mZicgYnR3 LiB0aGlzICdvdmVyaGVhZCcgYW5kIGFib3ZlICdjb3N0JyA/PC9GT05UPiA8L1A+DQogICAgPFA+ PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+VGh1cywgdGhlIHRyYWRlb2ZmIHdvdWxkIHVzdWFsbHkg YmUgZm9yIG1vcmUgDQogICAgcHJvY2Vzc2luZyBjb21wbGV4aXR5PC9GT05UPiA8QlI+PEZPTlQg ZmFjZT1BcmlhbCBzaXplPTI+YW5kIGxlc3MgbWVzc2FnaW5nIA0KICAgIGNvbXBsZXhpdHkgKGku ZS4sIG1haW50YWluaW5nIG1vcmUgInN0YXRlIikuPC9GT05UPiA8L1A+DQogICAgPFA+PEZPTlQg ZmFjZT1BcmlhbCBzaXplPTI+Jmd0OyAzKSBJbiBSb3V0ZSBPcHRpbWl6YXRpb24gZHJhZnQsPC9G T05UPiANCiAgICA8QlI+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBJZiBhYm92ZSAnY29zdCcgDQogICAgaW1wb3NlZCBieSAiVHJpYW5nbGUgUm91 dGluZyIgaXMgdmVyeSBoaWdoIGFuZDwvRk9OVD4gPC9QPg0KICAgIDxQPjxGT05UIGZhY2U9QXJp YWwgc2l6ZT0yPk8uSy48L0ZPTlQ+IDwvUD4NCiAgICA8UD48Rk9OVCBmYWNlPUFyaWFsIHNpemU9 Mj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENIIGNhbid0IHVuZGVyc3RhbmQgDQogICAg Um91dGUgT3B0aW1pemF0aW9uIHByb3RvY29sLDwvRk9OVD4gPEJSPjxGT05UIGZhY2U9QXJpYWwg DQogICAgc2l6ZT0yPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ0ggZG9lc24ndCBhY2tu b3dsZWRnZSAiQmluZGluZyBVcGRhdGUiIA0KICAgIC4uLi4uPC9GT05UPiA8L1A+DQogICAgPFA+ PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+Ty5LLiZuYnNwOyBXZSBhZ3JlZSBzbyBmYXIuLi48L0ZP TlQ+IDwvUD4NCiAgICA8UD48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj4mZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IEhvdyBhYm91dCBteSBodW1ibGUgDQogICAgb3BpbmlvbiA/PC9GT05UPiA8 QlI+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBN eSANCiAgICB0aG91Z2h0cyAuLi4uLjwvRk9OVD4gPEJSPjxGT05UIGZhY2U9QXJpYWwgDQogICAg c2l6ZT0yPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSWYgSEEgZG9lc24ndCAiQmluZGlu ZyBBY2tub3dsZWRnZSIgZnJvbSANCiAgICBDSCBmb3Igc29tZSB0aW1lLDwvRk9OVD4gPEJSPjxG T05UIGZhY2U9QXJpYWwgDQogICAgc2l6ZT0yPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg aXQgZGVkdWNlcyB0aGUgQ0ggY2FuJ3QgdW5kZXJzdGFuZCBSb3V0ZSANCiAgICBPcHRpbWl6YXRp b24gcHJvdG9jb2wgLi4uPC9GT05UPiA8QlI+PEZPTlQgZmFjZT1BcmlhbCANCiAgICBzaXplPTI+ Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGVuLCBpdCB0cmllcyB0byBzZW5kICJCaW5k aW5nIFVwZGF0ZSIgDQogICAgdG8gUm91dGVycyAxfjMgaG9wcyBhcGFydCBmcm9tPC9GT05UPiA8 QlI+PEZPTlQgZmFjZT1BcmlhbCANCiAgICBzaXplPTI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB0aGUgQ0ggLi4uLjwvRk9OVD4gPEJSPjxGT05UIGZhY2U9QXJpYWwgDQogICAgc2l6ZT0y PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU28gdGhpcyBhY3Rpdml0eSB3aWxsIGJlIGFi bGUgdG8gc29sdmUgDQogICAgIlRyaWFuZ2xlIFJvdXRpbmciIHByb2JsZW0gaW5kaXJlY3RseSAu Li48L0ZPTlQ+IDwvUD4NCiAgICA8UD48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5UYWtlIGEgbG9v ayBhdCBWSVAsIGZyb20gVGVyYW9rYS9Tb255LCB3aGljaCBkb2VzIA0KICAgIHRoaW5ncyB0aGlz IHdheS48L0ZPTlQ+IDxCUj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5UaGUgcHJvYmxlbSBzZWVt cyB0byBiZSANCiAgICB0aGF0IGl0J3MgaGFyZCB0byBlc3RhYmxpc2ggc2VjdXJpdHkgYXNzb2Np YXRpb25zPC9GT05UPiA8QlI+PEZPTlQgDQogICAgZmFjZT1BcmlhbCBzaXplPTI+d2l0aCByYW5k b20gaW5mcmFzdHJ1Y3R1cmUgcm91dGVycy48L0ZPTlQ+IDwvUD4NCiAgICA8UD48Rk9OVCBjb2xv cj0jODAwMDgwIGZhY2U9QXJpYWwgc2l6ZT0yPltQYXJrXSZuYnNwO0kgd2lsbCBsb29rIA0KICAg IGludG8mbmJzcDtWSVAgLi4uLiBUaGFua3MgYSBsb3QgLi4uLjwvRk9OVD48L1A+DQogICAgPFA+ PEZPTlQgY29sb3I9IzgwMDA4MCBmYWNlPUFyaWFsIHNpemU9Mj5CdXQsIFRoZXJlIGlzJm5ic3A7 dGhlIHNhbWUgcHJvYmxlbSANCiAgICB0aGF0IGl0J3MgaGFyZCB0byBlc3RhYmxpc2ggc2VjdXJp dHkgYXNzb2NpYXRpb25zIHdpdGggDQogICAgcmFuZG9tJm5ic3A7PC9GT05UPjwvUD4NCiAgICA8 UD48Rk9OVCBjb2xvcj0jODAwMDgwIGZhY2U9QXJpYWwgc2l6ZT0yPkNIcywmbmJzcDtpc24ndCBp dCA/IEFuZCBJIHRoaW5rIA0KICAgIHRoZSBwcm9ibGVtIHdpdGggQ0hzIGlzIG1vcmUgc2VyaW91 cyB0aGFuJm5ic3A7d2l0aCByYW5kb20gUm91dGVycyAuLi4gDQogICAgPC9GT05UPjwvUD4NCiAg ICA8UD48Rk9OVCBjb2xvcj0jODAwMDgwIHNpemU9Mj5BbSBJIHJpZ2h0ID88L0ZPTlQ+PC9QPg0K ICAgIDxQPiZuYnNwOzwvUD48L1VMPjwvQkxPQ0tRVU9URT48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_00B9_01BFF234.05545FA0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jul 19 21:51:21 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19644 for ; Wed, 19 Jul 2000 21:51:20 -0400 (EDT) Received: from standards (47.234.32.16:3231) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7FDED@standards.nortelnetworks.com>; Wed, 19 Jul 2000 21:40:22 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 16034 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 19 Jul 2000 21:40:21 -0400 Received: from mail0.u-aizu.ac.jp by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7FDEC@standards.nortelnetworks.com>; Wed, 19 Jul 2000 21:40:21 -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 KAA23263; Thu, 20 Jul 2000 10:50:54 +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 KAA07494; Thu, 20 Jul 2000 10:50:54 +0900 (JST) X-Mailer: Mozilla 4.7 [en_jp] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: <00bc01bff1e8$95c0a400$c72ebca8@ce.cnu.ac.kr> Content-Type: multipart/alternative; boundary="------------63DF8FA3E624F23DB481E8F3" Message-ID: <39765AFD.B789258B@u-aizu.ac.jp> Date: Thu, 20 Jul 2000 10:50:53 +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] Questions about Route Optimization in Mobile IPv4 X-To: "Park, Hyun Seo" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --------------63DF8FA3E624F23DB481E8F3 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Hi Hyun Seo, Can I recommend you to try to work out a simple exercise to evaluate what is gained with route optimization? I sometimes give in my graduate course on Wireless Networks simple exercises of this nature. You can use this simple formula: T=propagation time + transmission time + queueing time and take a simple case of three nodes (CN, MN and HA) and calculate T once without route optimization and once with route optimization and see the difference your self especially on links with high propagation time. Regarding VIP solution, there are newer solutions of more or less the same nature (if I can mandate things on my routers type of thinking) i.e., CIP and HAWAII and they do give much better performance. Lastly, if you look into mipv6 which is based on ipv6 which mandates binding caches on all hosts, so your concerns are naturally resolved. Regards, -- Behcet --------------63DF8FA3E624F23DB481E8F3 Content-Type: text/html; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Hi Hyun Seo,
  Can I recommend you to try to work out a simple exercise to evaluate what is gained with route optimization?
I sometimes give in my graduate course on Wireless Networks simple exercises of this nature. You can use this simple formula:
T=propagation time + transmission time + queueing time
and take a simple case of three nodes (CN, MN and HA) and calculate T once without route optimization and once with route
optimization and see the difference your self especially on links with high propagation time.
  Regarding VIP solution, there are newer solutions of more or less the same nature (if I can mandate things on my routers type of thinking)
i.e., CIP and HAWAII and they do give much better performance.
  Lastly, if you look into mipv6 which is based on ipv6 which mandates binding caches on all hosts, so your concerns are naturally resolved.

Regards, 

-- 
Behcet
  --------------63DF8FA3E624F23DB481E8F3-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jul 20 06:54:11 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16158 for ; Thu, 20 Jul 2000 06:54:11 -0400 (EDT) Received: from standards (47.234.32.16:3683) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7FFA6@standards.nortelnetworks.com>; Thu, 20 Jul 2000 6:42:53 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 16578 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 20 Jul 2000 06:42:52 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7FFA1@standards.nortelnetworks.com>; Thu, 20 Jul 2000 6:32:52 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10057; Thu, 20 Jul 2000 06:43:28 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200007201043.GAA10057@ietf.org> Date: Thu, 20 Jul 2000 06:43:28 -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-rfc2002-bis-02.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 : IP Mobility Support for IPv4, revised Author(s) : C. Perkins Filename : draft-ietf-mobileip-rfc2002-bis-02.txt Pages : 92 Date : 19-Jul-00 This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. 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 its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care-of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-rfc2002-bis-02.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-rfc2002-bis-02.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-rfc2002-bis-02.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: <20000719140925.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-rfc2002-bis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-rfc2002-bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000719140925.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jul 20 06:54:11 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16163 for ; Thu, 20 Jul 2000 06:54:11 -0400 (EDT) Received: from standards (47.234.32.16:3683) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7FFA8@standards.nortelnetworks.com>; Thu, 20 Jul 2000 6:42:57 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 16579 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 20 Jul 2000 06:42:57 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7FFA2@standards.nortelnetworks.com>; Thu, 20 Jul 2000 6:32:56 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10097; Thu, 20 Jul 2000 06:43:32 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200007201043.GAA10097@ietf.org> Date: Thu, 20 Jul 2000 06:43:32 -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-challenge-13.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 : Mobile IP Challenge/Response Extensions Author(s) : C. Perkins, P. Calhoun Filename : draft-ietf-mobileip-challenge-13.txt Pages : 17 Date : 19-Jul-00 Mobile IP, as originally specified, defines an authentication extension (the Mobile-Foreign Authentication extension) by which a mobile node can authenticate itself to a foreign agent. Unfortunately, this extension does not provide ironclad replay protection for the foreign agent, and does not allow for the use of existing techniques (such as CHAP) for authenticating portable computer devices. In this specification, we define extensions for the Mobile IP Agent Advertisements and the Registration Request that allow a foreign agent to use a challenge/response mechanism to authenticate the mobile node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-challenge-13.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-challenge-13.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-challenge-13.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: <20000719140933.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-challenge-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-challenge-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000719140933.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jul 20 11:19: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 LAA06569 for ; Thu, 20 Jul 2000 11:19:50 -0400 (EDT) Received: from standards (47.234.32.16:1974) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8011F@standards.nortelnetworks.com>; Thu, 20 Jul 2000 11:08:21 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17042 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 20 Jul 2000 11:08:21 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8011E@standards.nortelnetworks.com>; Thu, 20 Jul 2000 10:58:08 -0400 Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id KAA03309 for ; Thu, 20 Jul 2000 10:08:44 -0500 (CDT) Received: from btmq9s.rc.bel.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id e6KF75520080; Thu, 20 Jul 2000 17:07:05 +0200 (MET DST) Received: from alcatel.be (bt00t9 [138.203.66.143]) by btmq9s.rc.bel.alcatel.be (8.8.8+Sun/8.8.8/1.1) with ESMTP id RAA09310; Thu, 20 Jul 2000 17:05:05 +0200 (MET DST) X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <39771510.44594B9F@alcatel.be> Date: Thu, 20 Jul 2000 17:04:48 +0200 Reply-To: Omar Elloumi Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Omar Elloumi Organization: Alcatel Corporate Research Center Subject: [MOBILE-IP] 6th ISCC - CFP X-To: "diffserv@ietf.org" , "tcplw@bsdi.com" , cabernet-events@ncl.ac.uk, cellular@dfv.rwth-aachen.de, cnom@maestro.bellcore.com, commsoft@cc.bellcore.com, cost237-transport@comp.lancs.ac.uk, ctc-members@redbank.tinac.com, dbworld@cs.wisc.edu, DMANET@zpr.uni-koeln.de, end2end-interest@ISI.EDU, enternet@bbn.com, giga@tele.pitt.edu, hipparch@sophia.inria.fr, ieeetcpc@ccvm.sunysb.edu, itc@ieee.org, kuvs-elg@fokus.gmd.de, manet@itd.nrl.navy.mil, mobile-ip@smallworks.com, multicomm@cc.bellcore.com, multicomm@research.panasonic.com, performance@haven.epm.ornl.gov, reres@laas.fr, sig-dsm@doc.ic.ac.uk, sigmetrics-bb@haven.epm.ornl.gov, tccc@ieee.org, tchen@seas.smu.edu, tcos-announce@Dartmouth.EDU, testnet@canarie.ca, theorynt@listserv.nodak.edu, xtp-relay@cs.concordia.ca, "Dr. wahab" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit ****************************************** This e-mail has been sent to several distribution lists. We apologize if you receive multiple copies of it. ****************************************** The 6th IEEE Symposium on Computers and Communications 3-5 July, 2001 Hammamet, Tunisia http://www.cs.unc.edu/~jeffay/meetings/iscc2001/ http://www.ComSoc.org/ISCC/ Preliminary Call for Papers Sponsored by* IEEE Communications Society and IEEE Computer Society** General Chairs H. Abdel-Wahab, Old Dominion U., USA C. Savolaine, AT&T, USA Steering Committee H. Abdel-Wahab, Old Dominion U., USA T. N. Saadawi, City U of N.Y., USA M. H. Sherif, AT&T, USA A. Tantawy, IBM T.J. Watson Research Ctr., USA Technical Program Committee H. Akimaru, Asahi U., Japan K. Al-Tawil, KFUPM, Saudi Arabia M. Ammar, Georgia Tech, USA J. Ash, AT&T, USA A. Bestavros, Boston U., USA R. Boutaba, U. Waterloo, Canada K. Calvert, U. Kentucky, USA R. Chang, Polytech. Uni., Hong Kong M. Daneshmand, AT&T, USA J. Diaz, U. La Plata, Argentina M. T. El-Hadidi, Cairo U., Egypt N. Georganas, U. Ottawa S. Goddard, U. of Nebraska, Lincoln, USA M. Gouda, UTexas, USA S. Guan, National U. Singapore, Singapore A. Karmouch, U. Ottawa, Canada F. Kamoun, ENSI, Tunisia M. Karsten, Darmstadt U. of Tech., Germany A. Kujoory, AT&T, USA I. Matta, Boston U., USA K. Mills, NIST, USA K. Mori, Tokyo Inst. Tech., Japan H. Mouftah, Queens U., Canada H. Mueller, Siemens, Germany C. Perkins, Nokia,USA A. Pitsillides, U of Cyprus, Cyprus B. Plattner, ETH Zurich, Switzerland R. Popescu-Zeletin, GMD Fokus, Germany A. Puliafito, IIT, Italy I. Rhee, North Carolina State U., USA L. Saidane, ENSI, Tunisia D. Smith, UNC-Chapel Hill, USA G. Stassinopoulos, NTUA, Greece A. Tantawi, IBM T.J. Watson Research Ctr, USA S. Tohme, ENST-Paris, France M. Ulema, Daewoo Telecom, Ltd., USA A. Vahdat, Duke U., USA J. E. Wieselthier, Naval Research Lab, USA A. Youssef, George Washington U., USA Registration & Finance R. Ammar, U. Connecticut, USA A. Elmaghraby, U. Louisville, USA Local Organization Committee A. Ben-Youssef, ENSI, Tunisia K. Ben Rhouma, ENSI, Tunisia A. Ghedamsi, FST, Tunisia S. M'Hiri, ENSI, Tunisia Tutorials Committee H. Akhtar, AT&T, USA S. Fdida, U. Paris, France A. Yongacoglu, U. Ottawa Publicity Committee H. Afifi, INRIA, France O. Elloumi, Alcatel, France F. Gheni, ENSI, Tunisia G. Schaefer, ENST, France Continuing the tradition of this series of symposia, ISCC’2001 will provide an international technical forum for experts from industry and academia to exchange ideas and present results of ongoing research in the areas listed below. This year, special focus will be on the challenging issues related to the creation, management, dissemination, and communication of information. You are invited to submit a full paper, or a proposal for a panel, invited session, or tutorial, related to the following topics: Internet Services and Applications Electronic Commerce Security, Privacy and Information Access Multimedia Information Management and Exchange Distributed Systems Architecture and Management Wireless, Cellular and Mobile Communications Agent Technology Ad'hoc Networks High Performance Networking and Protocols Data Mining and Knowledge Discovery and Applications Programmable and Active Networks Network Design, Operation, and Management Control and Optimization of Communication Systems Network Reliability and Quality of Service Software Testing and Reliability Access Networks Management of Information Technology Signal Processing in Communications and Networking Cable Telephony and Broadband Service Please send four copies of your original unpublished paper (not to exceed 20 double-spaced pages) to reach either Technical Program Co-Chair at the addresses below by November 20, 2000. A concise and representative abstract should be included. The paper should clearly indicate the complete postal and electronic mailing addresses, as well as the phone and fax numbers of the corresponding author. Electronic submissions (e.g., Word, or PDF) are encouraged. Prof. Dr. Kevin Jeffay Prof. Dr. Ralf Steinmetz Dept. of Computer Science Dept. of EE & Info. Technology UNC-Chapel Hill Darmstadt U. of Technology Chapel Hill Merckstr. 25, D-64283 N.C. 27599, USA Darmstadt, Germany Tel: +1 919 962-1938 Tel: +49.6151.16.6151 Fax: +1 919 962-1799 Fax: +49.6151.16.6152 jeffay@cs.unc.edu ralf.steinmetz@kom.tu-darmstadt.de Important Dates: ----------------- November 20, 2000 Paper submission deadline February 19, 20 Notification of acceptance mailedto authors April 9, 2001 Final camera-ready manuscripts due Web Site http://www.ComSoc.org/ISCC http://www.cs.unc.edu/iscc2001 * Approval Pending ** Technical Committee on Simulation ISCC'2001 is hosted by the Ecole Nationale des Sciences de l'Informatique (ENSI), Tunisia. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jul 21 07:51:38 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05564 for ; Fri, 21 Jul 2000 07:51:38 -0400 (EDT) Received: from standards (47.234.32.16:2056) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB803DD@standards.nortelnetworks.com>; Fri, 21 Jul 2000 7:40:07 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17933 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jul 2000 07:40:07 -0400 Received: from prue.eim.surrey.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB803DC@standards.nortelnetworks.com>; Fri, 21 Jul 2000 7:30:06 -0400 Received: from carter-e0.ee.surrey.ac.uk ([131.227.86.16] helo=ee.surrey.ac.uk) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 13FbAc-0001gh-00 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jul 2000 12:40:46 +0100 X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <397836BE.44A3DEA0@ee.surrey.ac.uk> Date: Fri, 21 Jul 2000 12:40:46 +0100 Reply-To: g.aggelou@EIM.SURREY.AC.UK Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "George N. Aggelou" Organization: University of Surrey, Guildford, England Subject: [MOBILE-IP] Encapsulation/Decapsulation delay To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello, Does anyone know how much delay does the encapsulation/decapsulation process adds on the processing time of an IP packet? In my experiments I am considering IP in IP encapsulation but if anyone has such delay on hand for other encapsulation types instead (such as Minimal or GRE encapsulation) this would be very welcome. (Charlie, David any ideas?) Thanks, George A. -- *.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*. George N. Aggelou Research Fellow Centre for Communications Systems Research University of Surrey http://www.ee.surrey.ac.uk/Personal/G.Aggelou *.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jul 21 09:17:35 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11472 for ; Fri, 21 Jul 2000 09:17:35 -0400 (EDT) Received: from standards (47.234.32.16:1578) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB80485@standards.nortelnetworks.com>; Fri, 21 Jul 2000 9:06:11 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18143 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jul 2000 09:06:11 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8047F@standards.nortelnetworks.com>; Fri, 21 Jul 2000 8:56:09 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07432; Fri, 21 Jul 2000 09:06:48 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200007211306.JAA07432@ietf.org> Date: Fri, 21 Jul 2000 09:06:48 -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-regkey-02.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 : Registration Keys for Route Optimization Author(s) : C. Perkins, D. Johnson, N. Asokan Filename : draft-ietf-mobileip-regkey-02.txt Pages : 28 Date : 20-Jul-00 Route optimization defines extensions to Mobile IP Registration Requests that allow datagrams in flight when a mobile node moves, and datagrams sent based on an out-of-date cached binding, to be forwarded directly to the mobile node's new binding. These extensions for smooth handoff require a registration key to be established between the mobile node and foreign agent. This document defines additional extensions to the registration requests to allow for the establishment of single-use registration keys between a mobile node and foreign agent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-regkey-02.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-regkey-02.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-regkey-02.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: <20000720141334.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-regkey-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-regkey-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000720141334.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jul 21 09:17:36 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11474 for ; Fri, 21 Jul 2000 09:17:35 -0400 (EDT) Received: from standards (47.234.32.16:1578) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB80487@standards.nortelnetworks.com>; Fri, 21 Jul 2000 9:06:14 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18144 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jul 2000 09:06:14 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB80480@standards.nortelnetworks.com>; Fri, 21 Jul 2000 8:56:13 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07484; Fri, 21 Jul 2000 09:06:52 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200007211306.JAA07484@ietf.org> Date: Fri, 21 Jul 2000 09:06:52 -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-rfc2344-bis-02.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 : Reverse Tunneling for Mobile IP, revised Author(s) : G. Montenegro Filename : draft-ietf-mobileip-rfc2344-bis-02.txt Pages : 30 Date : 20-Jul-00 Mobile IP uses tunneling from the home agent to the mobile node's care-of address, but rarely in the reverse direction. Usually, a mobile node sends its packets through a router on the foreign network, and assumes that routing is independent of source address. When this assumption is not true, it is convenient to establish a topologically correct reverse tunnel from the care-of address to the home agent. This document proposes backwards-compatible extensions to Mobile IP to support topologically correct reverse tunnels. This document does not attempt to solve the problems posed by firewalls located between the home agent and the mobile node's care-of address. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-rfc2344-bis-02.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-rfc2344-bis-02.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-rfc2344-bis-02.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: <20000720141343.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-rfc2344-bis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-rfc2344-bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000720141343.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jul 21 09:49:17 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13386 for ; Fri, 21 Jul 2000 09:49:16 -0400 (EDT) Received: from standards (47.234.32.16:1578) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8050B@standards.nortelnetworks.com>; Fri, 21 Jul 2000 9:38:01 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18313 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jul 2000 09:38:01 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB80504@standards.nortelnetworks.com>; Fri, 21 Jul 2000 9:28:01 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12529; Fri, 21 Jul 2000 09:38:40 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200007211338.JAA12529@ietf.org> Date: Fri, 21 Jul 2000 09:38:40 -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-mkhalil-mobileip-ggpse-00.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Generalized GPS Extension (GGPSE) Author(s) : M. Khalil, E. Qaddoura, H. Akhtar, P. Calhoun Filename : draft-mkhalil-mobileip-ggpse-00.txt Pages : 10 Date : 20-Jul-00 The Mobile IP Working Group is considering proposals to provide fast hand-off capabilities to the Mobile IP protocol. It is important that such proposals do not require usage additional bandwidth, such as required by frequent mobility agent advertisements. This specification allows a mobility agent to provide its coverage area, and the location of neighboring cells, allowing the Mobile Node to determine when it must initiate a hand-off. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mkhalil-mobileip-ggpse-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-mkhalil-mobileip-ggpse-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-mkhalil-mobileip-ggpse-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: <20000720141554.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mkhalil-mobileip-ggpse-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-mkhalil-mobileip-ggpse-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000720141554.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jul 21 09:55:14 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13649 for ; Fri, 21 Jul 2000 09:55:14 -0400 (EDT) Received: from standards (47.234.32.16:1578) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8051A@standards.nortelnetworks.com>; Fri, 21 Jul 2000 9:38:40 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18315 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jul 2000 09:38:40 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB80506@standards.nortelnetworks.com>; Fri, 21 Jul 2000 9:28:40 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12660; Fri, 21 Jul 2000 09:39:19 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200007211339.JAA12660@ietf.org> Date: Fri, 21 Jul 2000 09:39:19 -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-glass-mobileip-reg-revok-00.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Registration Revocation for Mobile IP Author(s) : S. Glass Filename : draft-glass-mobileip-reg-revok-00.txt Pages : 14 Date : 20-Jul-00 During the original design of Mobile IP, the potential need for an administrative domain to be able to actively revoke a current Mobile IP registration was recognized. Due to the lack of a specific scenario requiring such a mechanism, it was decided that a passive mechanism, namely short registration lifetimes, and the denial of a subsequent registration from a MN, would be sufficient for this purpose. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-glass-mobileip-reg-revok-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-glass-mobileip-reg-revok-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-glass-mobileip-reg-revok-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: <20000720141712.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-glass-mobileip-reg-revok-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-glass-mobileip-reg-revok-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000720141712.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jul 21 18:47:04 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07437 for ; Fri, 21 Jul 2000 18:47:03 -0400 (EDT) Received: from standards (47.234.32.16:1411) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB806BB@standards.nortelnetworks.com>; Fri, 21 Jul 2000 18:35:38 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18911 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jul 2000 18:35:38 -0400 Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB806BA@standards.nortelnetworks.com>; Fri, 21 Jul 2000 18:35:38 -0400 Received: from esvir06nok.ntc.nokia.com (esvir06nok.ntc.nokia.com [131.228.10.155]) by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e6LMkID25873 for ; Sat, 22 Jul 2000 01:46:18 +0300 (EET DST) Received: from daebh02nok.americas.nokia.com (unverified) by esvir06nok.ntc.nokia.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Sat, 22 Jul 2000 01:46:17 +0300 Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id <3VXA9CAA>; Fri, 21 Jul 2000 17:46:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E0E2@daeis07nok> Date: Fri, 21 Jul 2000 17:43:41 -0500 Reply-To: Basavaraj.Patil@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: [MOBILE-IP] Comments on Proactive HO X-cc: pat.calhoun@eng.sun.com, shavantha.kularatna@nokia.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Pat, Just a few observations on the proactive FA HO proposal: 1. You mention that an FA can determine if a MN can be better served by another FA using current location and movement patterns via underlying link layer or radio protocols. Rather than trying to predict the best possible FA that can serve the MN using movements patterns (it's quite hard) it is probably better to have a list of possible FA candidates that could serve the MN. In that case the FA can send a BU to all the possible FAs. A lot depends on how you engineer the network and if you consider every BTS to have an FA or a set of them to be served by an FA. 2. Karim's proposal of doing a registration with a new FA while connected to the old FA seems to be much more reasonable than sending a binding update. You avoid having the GFA deal with a new Hand Off message which you propose. 3. The FA should not worry about determining if it has link layer connectivity to a MN. So instead of the FA determining this and sending a HO request with lifetime zero, it is better to have the new FA that is now serving the MN send an equivalent message to the oFA to deregister the MN. -Raj, Sha From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Jul 22 17:15:24 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26335 for ; Sat, 22 Jul 2000 17:15:23 -0400 (EDT) Received: from standards (47.234.32.16:2693) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB80810@standards.nortelnetworks.com>; Sat, 22 Jul 2000 17:03:51 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19354 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 22 Jul 2000 17:03:51 -0400 Received: from sirius.ctr.columbia.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8080D@standards.nortelnetworks.com>; Sat, 22 Jul 2000 16:53:50 -0400 Received: from comet.columbia.edu (argo.comet.columbia.edu [128.59.68.36]) by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with ESMTP id RAA01848 for ; Sat, 22 Jul 2000 17:04:35 -0400 (EDT) X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------D41CE02ECAF274477869CF99" Message-ID: <397A0C62.1F4F12DE@comet.columbia.edu> Date: Sat, 22 Jul 2000 17:04:34 -0400 Reply-To: Xiaowei Cissy Zhang Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Xiaowei Cissy Zhang Subject: [MOBILE-IP] P-MIP To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --------------D41CE02ECAF274477869CF99 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, We have submitted an internet draft on a protocol we are developing in the COMET Group called P-MIP (Minimal Paging Extensions for Mobile IP draft-zhang-pmip-00.txt). The project web page can be found at http://comet.columbia.edu/pmip/ where the ID and other info can be found. As the ID title suggests the idea is to come up with the minimal changes to Mobile IP to support paging idle mobiles. Any comments welcome. Xiaowei -- Xiaowei Cissy Zhang http://comet.columbia.edu/~xzhang --------------D41CE02ECAF274477869CF99 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

We have submitted an internet draft on
a protocol we are developing in the COMET Group
called P-MIP (Minimal Paging Extensions for Mobile IP
draft-zhang-pmip-00.txt).

As the ID title suggests the idea is to
come up with the minimal changes
to Mobile IP to support paging
idle mobiles.

Any comments welcome.
 

Xiaowei 

-- 
Xiaowei Cissy Zhang
http://comet.columbia.edu/~xzhang
  --------------D41CE02ECAF274477869CF99-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Jul 22 21:39:27 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06774 for ; Sat, 22 Jul 2000 21:39:26 -0400 (EDT) Received: from standards (47.234.32.16:4026) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB80877@standards.nortelnetworks.com>; Sat, 22 Jul 2000 21:28:07 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19497 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 22 Jul 2000 21:28:06 -0400 Received: from catarina.usc.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB80876@standards.nortelnetworks.com>; Sat, 22 Jul 2000 21:28:04 -0400 Received: from localhost (meeta@localhost) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id SAA39395; Sat, 22 Jul 2000 18:38:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Sat, 22 Jul 2000 18:38:48 -0700 Reply-To: Meeta Sharma Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Meeta Sharma Subject: [MOBILE-IP] Scripts for Mobile IP X-To: ns-users@isi.edu X-cc: dphds@catarina.usc.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi, I was working on running some simulations for Mobile Ip, wanted to know if there are any scripts examples for the same in NS, Thanks, Meeta From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Jul 23 08:52: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 IAA17427 for ; Sun, 23 Jul 2000 08:52:01 -0400 (EDT) Received: from standards (47.234.32.16:2907) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8091A@standards.nortelnetworks.com>; 23 Jul 2000 8:40:37 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19716 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 23 Jul 2000 08:40:37 -0400 Received: from mail0.u-aizu.ac.jp by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB80919@standards.nortelnetworks.com>; 23 Jul 2000 8:40:37 -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 VAA23330 for ; Sun, 23 Jul 2000 21:51:21 +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 VAA12042 for ; Sun, 23 Jul 2000 21:51:21 +0900 (JST) X-Mailer: Mozilla 4.7 [en_jp] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Message-ID: <397AEA48.B76B9CF@u-aizu.ac.jp> Date: Sun, 23 Jul 2000 21:51:20 +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: [MOBILE-IP] draft-malinen-mobileip-regreg6-00.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi Jari and Charlie, I have some questions on this I-D: The method is based on advertizing regional care-of addresses to MNs that can do a regional BU taking one of them as its alternate care-of address and thereafter using this address in the visited domain. This means that the data is continously tunneled from GMA to MN as long as MN stays in the domain (sounds like HAWAII in which MN is given an IPv4 address in the domain, doesn't it?). So address autoconfiguration at each access router and its associated BU traffic are compromised with MIPv4 like tunneling. This same idea can also be found in the I-D by Karim. Can you provide some clarification on this? Has this I-D been submitted to IETF? Regards, -- Behcet From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Jul 23 10:13:59 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 KAA06450 for ; Sun, 23 Jul 2000 10:13:59 -0400 (EDT) Received: from standards (47.234.32.16:1505) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB80967@standards.nortelnetworks.com>; 23 Jul 2000 10:02:28 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19805 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 23 Jul 2000 10:02:28 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8095E@standards.nortelnetworks.com>; 23 Jul 2000 9:52:23 -0400 Received: from NS.r-net.sk (root@NS.r-net.sk [193.58.193.10]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id JAA22741 for ; Sun, 23 Jul 2000 09:03:08 -0500 (CDT) Received: from jakab (Kosice53.r-net.sk [193.58.192.181]) by NS.r-net.sk (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id PAA25628; Sun, 23 Jul 2000 15:59:30 +0200 X-Authentication-Warning: NS.r-net.sk: Host Kosice53.r-net.sk [193.58.192.181] claimed to be jakab MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002F_01BFF4B9.30201800" 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: <055e01bff4af$df4294c0$b5c03ac1@jakab> Date: Sun, 23 Jul 2000 15:18:00 +0200 Reply-To: jakab frantisek Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: jakab frantisek Subject: [MOBILE-IP] Symposium ATMTU 2000 - Second Announcement and Call for Participation, Kosice, Slovakia X-To: xtp-relay@cs.concordia.ca X-cc: dbworld@cs.wisc.edu, end2end-interest@isi.edu, enternet@bbn.com, giga@tele.pitt.edu, hipparch@sophia.inria.fr, ieeetcpc@ccvm.sunysb.edu, kuvs-elg@fokus.gmd.de, mobile-ip@smallworks.com, multicomm@cc.bellcore.com, multicomm@research.panasonic.com, performance@haven.epm.ornl.gov, reres@laas.fr, sig-dsm@doc.ic.ac.uk, sigmetrics-bb@haven.epm.ornl.gov, tccc@ieee.org, tchen@seas.smu.edu, tcos-announce@dartmouth.edu, testnet@canarie.ca To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_002F_01BFF4B9.30201800 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [Please accept our apologies if you receive this mail more than once...] Dear Sirs, you can find the second announcement on our web serever: = www.elfa.sk/index-4-en.html and new information about the international symposium ATMTU 2000 (Second ATM Technology Users Symposium) , which is = held on 13 - 15 September 2000 in Kosice, Slovak Republic. In = particular, you will find the registration forms there. It is just another two months until the ATMTU 2000 will take place here = in Kosice, Slovakia. Therefore, we want to invite you to join us and participate at the symposium. We are looking forward to seeing you! Best regards, Frantisek Jakab ATMTU 2000 Symposium Org. Comm. Chair ___________________________ Preliminary List of presentations: 1. Broadband wireless access systems based on ATM Raks=E1ny P., Hargas J., Ericsson Slovakia, Bratislava, Slovakia 2. Broadband fixed line access Raks=E1ny P., Kostrej A., Ericsson Slovakia, Bratislava, Slovakia 3. Information about facts and experiences from the integration of ATM networks with IP protocol Francisci C., VUS, Bansk=E1 Bystrica, Slovakia 4. IP versus ATM Kukura P., Lucent Technologies Slovensko, Bratislava, Slovakia 5. Channels versus packets - conflict or symbiosis Chal=E1s P., ICN Siemens, Bratislava, Slovakia 6. Signalisation at the estabilishment of connection between broadband = and narrowband end-users Janetka A., Martinec L., Kevick=FD F., SWH Siemens Business Services, = Bratislava, Slovakia 7. VoIP or VoATM Lunter P., SWH Siemens Business Services, Bratislava, Slovakia 8. QOS in IP versus ATM Dekan R., SWH Siemens Business Services, Bratislava, Slovakia 9. ATM solutions in end-to-end solutions at the Alcatel 2iP Fiacan I., Alcatel Slovakia, Liptovsk=FD Hr=E1dok, Slovakia 10. Applications of ATM technologies in wireless LMDS access systems Kub=EDk E., Alcatel Slovakia, Liptovsk=FD Hr=E1dok, Slovakia 11. Telematics Services over ATM Networks: The case of Teleteaching Bouras Ch., Gkamas A., Kapoulas V., Tsiatsos Th., Computer Technology = Institute Patras, Greece 12. Migration to Broadband Networks Baron=E1k I., Poliak P., Department of Telecommunications, Faculty of Electrical Engineering and Informatics, Slovak University of Technology, = Bratislava, Slovakia 13. ATM access equipment of the RAD manufacturer Man=E1k V., ITM Bratislava, Slovakia 14. Design of an ATM Network Control and Monitoring System Gizelis C., National Technical University of Athens, Greece 15. Plasma PNNI 1.0: ATMIPNNI network simulation program Somogyi H., Ericsson Hungary, Hungary 16. Videoconferencing and applications of the TTC Telecom based on PictureTel Salzer E., TTC Telecom, Kosice, Slovakia 17. The utilisation of the ATM in the access technologies Koprda L., BGS Bratislava, Slovakia 18. Broadening of the activities of the Z-ATM in Slovakia with the = accesses to the end-users Sebo J., The ATM Association in the Slovak Republic Bratislava, Slovakia 19. MPLS (Multiprotocol Label Switching) and IP QoS in Service Provider = ATMNeworks Janovic R., Cisco Systems Slovakia 20. Perspectives for QoS in IP Public Networks Basso E., TTC Marconi, Prague, Czech Republic 21. Distribution MPEG2 streams in ATM end-to-end environments Danthine O., TOLMA SA, Paris, France 22. Liberalisation versus regulation in electronic communication = networks and services Scehovic A., V=DAS Bansk=E1 Bystrica, Slovakia 23. Steps Towards a World-Wide Broadband Multimedia Network Finley Marion R. Jr., Asahi University, Japan 24. ATM services and applications integration access to a large = community of users in the region of Aveiro Fontes F., Portugal Telecom, Aveiro, Portugal 25. The necessity of the building of academic "information = superhighways" Horvath P., SANET Bratislava, Slovakia 26. The effectivity of the extranets in companies Lavrin A., Zelko M., Technical University of Kosice, Slovakia 27. Operator of the broadband services - the vision Zirko M1., Jakab F2., Cizm=E1r A2., Slovak Telecom Bratislava1, = Technical University of Kosice, Slovakia 28. Some remarks to the implementation maintance of the ST-ATM network Trstensk=FD D., et al., Slovak Telecom, Bansk=E1 Bystrica, Slovakia 29. Presentation 1 Ambasador ATM FORUM 30. Presentation 2 Ambasador ATM FORUM 31. Preparation and developing strategy of the information society in = the Slovak Republic Podhorsk=FD V., Ministry of Transport, Post and Telecommunications in = SR, Bratislava. Slovakia 32. Information highways in information society Karovic K., SAV Bratislava, Slovakia 33. Experiences of the Corinex company with the ATM technologies Sl=E1nicka, CORINEX Group, Slovakia 34. Experiences of the IBM company with the ATM technologies Labanc, IBM Slovensko, Slovakia 35. IP net next generation - voice/multimedia transport Linhart Z., CONTACTEL, Czech Republic 36. Next Generation Networks and Services - ATM and IP Asatani K., Kogakuin University, Tokyo, Japan 37. Secure services Tomasov P., University of Zilina, Slovakia 38. Algoritmics and tool for virtual audience training Tsejtlin G.T., International Solomon University, Kiev, Ukraine 39. Expert estimations of validity and reliability of programme and technical maintance of computer networks Grygorovych V.F., Oleksiivna M.O., Uzhgorod State Institute of = Informatics Science, Ukraine 40. The algebraic approach to minimization of computing Expences in = computer networks Olegovich N.M., Uzhgorod State Institute of Informatics Science, Ukraine 41. ATM Subscriber Access Multiplexer: the complete ADSL solution Lizuch P., Alcatel Slovakia, Liptovsk=FD Hr=E1dok, Slovakia 42. Design of an Input-queueded ATM Switch supporting multicast and = research on its Scheduling Policy Minguy Z., Nanjing University, China 43. Videoconferencing room=20 Baron=E1k I., Moln=E1r M., Department of Telecommunications, Faculty of Electrical Engineering and Informatics, Slovak University of Technology, = Bratislava, Slovakia 44. Application of the implementation models of the broadband networks Zabka J., Faculty of Mechatronics, University of Trenc=EDn, Slovakia 45. VPN networks based on MPLS Kollar S., BGS, Bratislava, Slovakia 46. Virtual networks in ATM Skorpil V., FEI, VUT, Brno, Czech Republic 47. Distributed Speech Recognition Syst=E9m over ATM Cizm=E1r A., Dobos L., Hintos L., Juh=E1r J., Faculty of Electrical = Engineering and Informatics of the Technical University of Kosice, Slovakia 48. Wireles ATM Physical Layer Simulation Dobos L., Palifetka R., Cizm=E1r A., Juh=E1r J., Faculty of Electrical Engineering and Informatics of the Technical University of Kosice, = Slovakia 49. Teleeducation services in broadband networks Jakab F., Samuelis L., Faculty of Electrical Engineering and Informatics = of the Technical University of Kosice, Slovakia 50. Methods of the evaluation of the QoS in ATM networks Jakab F., Faculty of Electrical Engineering and Informatics of the = Technical University of Kosice, Slovakia ______________________________________ ATMTU 2000 Symposium Symposium Secretariat elfa, s.r.o., Letna 9 042 00 Kosice, Slovakia Tel./fax.: +421 95 6253839, 6253200, 6253202 e-mail: elfa@elfa.sk www.elfa.sk/index-4-en.html ------=_NextPart_000_002F_01BFF4B9.30201800 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
[Please accept our apologies if you receive this = mail more=20 than once...]

Dear Sirs,

you can find the second = announcement on=20 our web serever: www.elfa.sk/index-4-en.html and=20 new information about the international
symposium ATMTU 2000 (Second = ATM=20 Technology Users Symposium)  , which is held on 13 - 15 September = 2000 in=20 Kosice, Slovak Republic. In particular,
you will find the = registration forms=20 there.

It is just another two months until the ATMTU 2000 will = take place=20 here in Kosice, Slovakia. Therefore, we want to invite you to join us=20 and
participate at the symposium.

We are looking forward to = seeing=20 you!

 Best regards,

Frantisek Jakab
ATMTU 2000 = Symposium=20 Org. Comm. Chair
___________________________

Preliminary List = of=20 presentations:

1. Broadband wireless access systems based on=20 ATM
Rakš=E1ny P., Hargaš J., Ericsson Slovakia, Bratislava, = Slovakia

2.=20 Broadband fixed line access
Rakš=E1ny P., Kostrej A., Ericsson = Slovakia,=20 Bratislava, Slovakia

3. Information about facts and experiences = from the=20 integration of ATM
networks with IP protocol
Francisci C., VUS, = Bansk=E1=20 Bystrica, Slovakia

4. IP versus ATM
Kukura P., Lucent = Technologies=20 Slovensko, Bratislava, Slovakia

5. Channels versus packets - = conflict or=20 symbiosis
Chal=E1s P., ICN Siemens, Bratislava, Slovakia

6.=20 Signalisation at the estabilishment of connection between broadband and=20 narrowband end-users
Janetka A., Martinec Ľ., Kevick=FD F., SWH = Siemens=20 Business Services, Bratislava, Slovakia

7. VoIP or = VoATM
Lunter P.,=20 SWH Siemens Business Services, Bratislava, Slovakia

8. QOS in IP = versus=20 ATM
Dekan R., SWH Siemens Business Services, Bratislava, = Slovakia

9.=20 ATM solutions in end-to-end solutions at the Alcatel 2iP
Fiačan = I., Alcatel=20 Slovakia, Liptovsk=FD Hr=E1dok, Slovakia

10. Applications of ATM = technologies=20 in wireless LMDS access systems
Kub=EDk E., Alcatel Slovakia, = Liptovsk=FD Hr=E1dok,=20 Slovakia

11. Telematics Services over ATM Networks: The case of=20 Teleteaching
Bouras Ch., Gkamas A., Kapoulas V., Tsiatsos Th., = Computer=20 Technology Institute Patras, Greece

12. Migration to Broadband=20 Networks
Baroň=E1k I., Poliak P., Department of = Telecommunications, Faculty=20 of
Electrical Engineering and Informatics, Slovak University of = Technology,=20 Bratislava, Slovakia

13. ATM access equipment of the RAD=20 manufacturer
Man=E1k V., ITM Bratislava, Slovakia

14. Design = of an ATM=20 Network Control and Monitoring System
Gizelis C., National Technical=20 University of Athens, Greece

15. Plasma PNNI 1.0: ATMIPNNI = network=20 simulation program
Somogyi H., Ericsson Hungary, Hungary

16.=20 Videoconferencing and applications of the TTC Telecom based=20 on
PictureTel
Salzer E., TTC Telecom, Košice, = Slovakia

17. The=20 utilisation of the ATM in the access technologies
Koprda L., BGS = Bratislava,=20 Slovakia

18. Broadening of the activities of the Z-ATM in = Slovakia with=20 the accesses to the end-users
Šebo J., The ATM Association in = the Slovak=20 Republic Bratislava, Slovakia

19. MPLS (Multiprotocol Label = Switching)=20 and IP QoS in Service Provider ATMNeworks
Janovic R., Cisco Systems=20 Slovakia

20. Perspectives for QoS in IP Public Networks
Basso = E., TTC=20 Marconi, Prague, Czech Republic

21. Distribution MPEG2 streams in = ATM=20 end-to-end environments
Danthine O., TOLMA SA, Paris, = France

22.=20 Liberalisation versus regulation in electronic communication networks = and=20 services
Ščehovič A., V=DAS Bansk=E1 Bystrica, = Slovakia

23. Steps Towards=20 a World-Wide Broadband Multimedia Network
Finley Marion R. Jr., Asahi = University, Japan

24. ATM services and applications integration = access to=20 a large community of
users in the region of Aveiro
Fontes F., = Portugal=20 Telecom, Aveiro, Portugal

25. The necessity of the building of = academic=20 "information superhighways"
Horvath P., SANET Bratislava, = Slovakia

26.=20 The effectivity of the extranets in companies
Lavrin A., Zelko M., = Technical=20 University of Košice, Slovakia

27. Operator of the broadband = services -=20 the vision
Žirko M1., Jakab F2., Čižm=E1r A2., Slovak = Telecom Bratislava1,=20 Technical
University of Košice, Slovakia

28. Some remarks = to the=20 implementation maintance of the ST-ATM network
Trstensk=FD D., et = al., Slovak=20 Telecom, Bansk=E1 Bystrica, Slovakia

29. Presentation = 1
Ambasador ATM=20 FORUM

30. Presentation 2
Ambasador ATM FORUM

31. = Preparation=20 and developing strategy of the information society in the Slovak=20 Republic
Podhorsk=FD V., Ministry of Transport, Post and = Telecommunications in=20 SR, Bratislava. Slovakia

32. Information highways in information=20 society
Karovič K., SAV Bratislava, Slovakia

33. = Experiences of the=20 Corinex company with the ATM technologies
Sl=E1nička, CORINEX = Group,=20 Slovakia

34. Experiences of the IBM company with the ATM=20 technologies
Labanc, IBM Slovensko, Slovakia

35. IP net next=20 generation - voice/multimedia transport
Linhart Z., CONTACTEL, Czech=20 Republic

36. Next Generation Networks and Services - ATM and=20 IP
Asatani K., Kogakuin University, Tokyo, Japan

37. Secure=20 services
Tomašov P., University of Žilina, = Slovakia

38. Algoritmics=20 and tool for virtual audience training
Tsejtlin G.T., International = Solomon=20 University, Kiev, Ukraine

39. Expert estimations of validity and=20 reliability of programme and
technical maintance of computer=20 networks
Grygorovych V.F., Oleksiivna M.O., Uzhgorod State Institute = of=20 Informatics Science, Ukraine

40. The algebraic approach to = minimization=20 of computing Expences in computer networks
Olegovich N.M., Uzhgorod = State=20 Institute of Informatics Science, Ukraine

41. ATM Subscriber = Access=20 Multiplexer: the complete ADSL solution
Lizuch P., Alcatel Slovakia,=20 Liptovsk=FD Hr=E1dok, Slovakia

42. Design of an Input-queueded = ATM Switch=20 supporting multicast and research on its Scheduling Policy
Minguy Z., = Nanjing=20 University, China

43. Videoconferencing room
Baroň=E1k = I., Moln=E1r M.,=20 Department of Telecommunications, Faculty of
Electrical Engineering = and=20 Informatics, Slovak University of Technology, Bratislava, = Slovakia

44.=20 Application of the implementation models of the broadband = networks
Žabka J.,=20 Faculty of Mechatronics, University of Trenč=EDn, = Slovakia

45. VPN networks=20 based on MPLS
Kollar S., BGS, Bratislava, Slovakia

46. Virtual = networks in ATM
Škorpil V., FEI, VUT, Brno, Czech = Republic

47.=20 Distributed Speech Recognition Syst=E9m over ATM
Čižm=E1r = A., Doboš Ľ., Hintoš=20 L., Juh=E1r J., Faculty of Electrical Engineering
and Informatics of = the=20 Technical University of Košice, Slovakia

48. Wireles ATM = Physical Layer=20 Simulation
Doboš Ľ., Palifetka R., Čižm=E1r A., = Juh=E1r J., Faculty of=20 Electrical
Engineering and Informatics of the Technical University of = Košice,=20 Slovakia

49. Teleeducation services in broadband = networks
Jakab F.,=20 Samuelis L., Faculty of Electrical Engineering and Informatics of
the = Technical University of Košice, Slovakia

50.  Methods = of the=20 evaluation of the QoS in ATM networks
Jakab F., Faculty of Electrical = Engineering and Informatics of the Technical
University of = Košice,=20 Slovakia
______________________________________

ATMTU 2000=20 Symposium
Symposium Secretariat
elfa, s.r.o., Letna 9
042 00 = Kosice,=20 Slovakia
Tel./fax.: +421 95 6253839, 6253200, 6253202
e-mail: elfa@elfa.sk
www.elfa.sk/index-4-en.html

------=_NextPart_000_002F_01BFF4B9.30201800-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Jul 23 12:17:36 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05704 for ; Sun, 23 Jul 2000 12:17:36 -0400 (EDT) Received: from standards (47.234.32.16:4442) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB809C1@standards.nortelnetworks.com>; 23 Jul 2000 12:06:15 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19932 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 23 Jul 2000 12:06:15 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB809C0@standards.nortelnetworks.com>; 23 Jul 2000 12:06:14 -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 JAA22318; Sun, 23 Jul 2000 09:17:01 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id JAA18826; Sun, 23 Jul 2000 09:16:59 -0700 X-Virus-Scanned: Sun, 23 Jul 2000 09:16:59 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdLtlnsz; Sun, 23 Jul 2000 09:16:57 PDT X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <397AEA48.B76B9CF@u-aizu.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <397B19C5.CB746281@iprg.nokia.com> Date: Sun, 23 Jul 2000 09:13:57 -0700 Reply-To: Charlie Perkins Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Charlie Perkins Organization: Nokia Subject: Re: [MOBILE-IP] draft-malinen-mobileip-regreg6-00.txt X-To: sarikaya@U-AIZU.AC.JP To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Behcet, Here are some answers to your questions. > The method is based on advertizing regional care-of addresses to MNs > that > can do a regional BU taking one of them as its alternate care-of address > and thereafter using this address > in the visited domain. This means that the data is continously tunneled > from GMA to MN as long as MN stays in the > domain Yes, the data _can_ be tunneled to the mobile node as long as it stays in the domain, from a particular GMA. > (sounds like HAWAII in which MN is given an IPv4 address in the > domain, doesn't it?). The idea of tunneling from a root foreign agent, gateway foreign agent, gateway mobility agent, etc. is not at all unique to HAWAII. > So address autoconfiguration at each access router and its associated BU > traffic are compromised with MIPv4 like tunneling. How do you mean compromised? Address autoconfiguration is done at every access router, binding updates are performed, and I suppose it is true that MIPv6 tunneling is "like" MIPv4 tunneling. Compromised usually means accepting something less than desired. What better solution would you like to see? > This same idea can also be found in the I-D by Karim. > Can you provide some clarification on this? Similar ideas have been popping up with regularity for years. Our goal is to find some solution that is not encumbered with intellectual property, so it is perfectly natural that we would work with ideas that have been around for years. Isn't this a good thing? > Has this I-D been submitted to IETF? Yes. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Jul 23 15:02:35 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17132 for ; Sun, 23 Jul 2000 15:02:35 -0400 (EDT) Received: from standards (47.234.32.16:3751) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB80A29@standards.nortelnetworks.com>; 23 Jul 2000 14:51:17 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20075 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 23 Jul 2000 14:51:17 -0400 Received: from dirty.research.bell-labs.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB80A28@standards.nortelnetworks.com>; 23 Jul 2000 14:51:16 -0400 Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Sun Jul 23 15:00:40 EDT 2000 Received: from king.research.bell-labs.com ([135.1.152.1]) by grubby; Sun Jul 23 15:00:40 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 CC6C15701F for ; Sun, 23 Jul 2000 14:00:39 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: VM 6.33 under Emacs 19.34.2 Message-ID: <20000723190039.CC6C15701F@king.research.bell-labs.com> Date: Sun, 23 Jul 2000 14:00:39 -0500 Reply-To: Pete McCann Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Pete McCann Subject: [MOBILE-IP] Fast Handoff Issues To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi, I've been catching up on the recent fast handoff threads. I wanted to raise a couple of issues about handoff that I think have gone unexamined here. First, there is the overhead of link-layer re-establishment. All of the proposals I've seen discussed here assume that after a handoff, the link-layer can be re-established instantaneously. However, low-bandwidth links, like cellular interfaces, will make use of stateful protocols like PPP. Statefulness is required for header compression and the negotiation of options like character escaping, payload compression, and others. Negotiation at link establishment time can take several round-trips that could add up to several hundred milliseconds, depending on latency of the physical layer. To make handoffs fast, this overhead has to be addressed. There are basically 3 options as I see it: 1) Define a new, "stateless" link layer that requires zero negotiation, yet nevertheless, meets all of the requirements of a low-bandwidth, serial IP connection; 2) Provide some way for the state of the link to "migrate" from one point of attachment to the next; or, 3) Allow for data to be tunneled back to the old point of attachment for a short period of time until negotiation can be completed at the new point of attachment. In my opinion, (1) would be difficult or impossible to achieve. (2) seems to add quite a bit of complexity. (3) seems the most reasonable, especially since there is already some amount of link-layer tunneling present in the 3GPP2 architecture (see the 3gwireless-ext draft). Second, I would like to see more discussion of inter-domain handoff issues. Solving the fast handoff problem within a given (routing) domain is only part of the problem - we should develop a solution that is capable of providing fast handoffs from one domain to another, much in the way that "hard handoff" is designed to work between neighboring cellular systems run by different operators. I think it is reasonable for neighboring BSCs or FAs to have direct relationships, which would actually be required for doing the kind of "pro-active" handoffs discussed by Pat & James, that require power measurements of neighboring cells to be taken. However, it might not be reasonable for neighboring systems to share a routing domain or have any GFAs in common. Taken together, these two requirements would probably lead to an architecture most similar to the one in the proactive FA draft, but it would have a couple of differences: - Tunneling from previous FA to next FA would be initiated as a side effect of the pro-active binding update (in personal communication, Pat said this was already possible but I don't think it was mentioned directly in the draft). I think this is discussed in Khalil's draft. - Data could be tunneled at either layer 3 or layer 2, depending on whether the above-mentioned link-layer establishment issues are addressed. - Handoff from one "leaf" FA to another would be more transparent and network-controlled, i.e., the MN would not see or need to participate in the handoff as long as the GFA didn't change. Also I think it is a mistake to use the "S" bit in this case because you are essentially requiring 2x bandwidth for the period of time when the MN is connected to both FAs. I know some of the considerations I've raised are really link-specific issues, but their impact on the fast handoff mechanism should be considered. It may turn out that fast handoff is best addressed in the appropriate link-layer groups (3GPPs, IEEE) and not the IETF. Thanks, -Pete From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Jul 23 17:23:28 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18073 for ; Sun, 23 Jul 2000 17:23:28 -0400 (EDT) Received: from standards (47.234.32.16:2924) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB80A81@standards.nortelnetworks.com>; 23 Jul 2000 17:11:55 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20194 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 23 Jul 2000 17:11:54 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB80A80@standards.nortelnetworks.com>; 23 Jul 2000 17:11:54 -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 PAA18591; Sun, 23 Jul 2000 15:22:38 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA10903; Sun, 23 Jul 2000 14:22:37 -0700 (PDT) Received: from nasnfs.Eng.Sun.COM (japanapp.Singapore.Sun.COM [129.158.124.50]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id OAA06736; Sun, 23 Jul 2000 14:22:14 -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: <200007232122.OAA06736@nasnfs.eng.sun.com> Date: Sun, 23 Jul 2000 13:23: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] Fast Handoff Issues X-To: Pete McCann To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Pete, Some comments. >Hi, > >I've been catching up on the recent fast handoff threads. I wanted to >raise a couple of issues about handoff that I think have gone unexamined >here. > >First, there is the overhead of link-layer re-establishment. All of >the proposals I've seen discussed here assume that after a handoff, >the link-layer can be re-established instantaneously. However, >low-bandwidth links, like cellular interfaces, will make use of >stateful protocols like PPP. Statefulness is required for header >compression and the negotiation of options like character escaping, >payload compression, and others. Negotiation at link establishment >time can take several round-trips that could add up to several hundred >milliseconds, depending on latency of the physical layer. > >To make handoffs fast, this overhead has to be addressed. There are >basically 3 options as I see it: > >1) Define a new, "stateless" link layer that requires zero negotiation, > yet nevertheless, meets all of the requirements of a low-bandwidth, > serial IP connection; >2) Provide some way for the state of the link to "migrate" from one > point of attachment to the next; or, >3) Allow for data to be tunneled back to the old point of attachment > for a short period of time until negotiation can be completed at > the new point of attachment. > >In my opinion, (1) would be difficult or impossible to achieve. (2) >seems to add quite a bit of complexity. (3) seems the most >reasonable, especially since there is already some amount of >link-layer tunneling present in the 3GPP2 architecture (see the >3gwireless-ext draft). > In FA assisted handoff, the data continues to be delivered through the old point of attachment until completion of the network set up at the new point. The mobile continues to receive data through both points until it breaks off from the old, when the new point of attachment becomes the exclusive source of the data. And, as you mention below, tunneling could be done in FA assisted handoff, though the draft doesn't mention it. >Second, I would like to see more discussion of inter-domain handoff >issues. Solving the fast handoff problem within a given (routing) >domain is only part of the problem - we should develop a solution that >is capable of providing fast handoffs from one domain to another, much >in the way that "hard handoff" is designed to work between neighboring >cellular systems run by different operators. I think it is reasonable >for neighboring BSCs or FAs to have direct relationships, which would >actually be required for doing the kind of "pro-active" handoffs >discussed by Pat & James, that require power measurements of >neighboring cells to be taken. However, it might not be reasonable >for neighboring systems to share a routing domain or have any GFAs in >common. > Yes, I've been trying to move discussion in that direction, but there seems to be a certain resistance to it, for what I believe are reasons I'll discuss below. >Taken together, these two requirements would probably lead to an >architecture most similar to the one in the proactive FA draft, but >it would have a couple of differences: > >- Tunneling from previous FA to next FA would be initiated as a side > effect of the pro-active binding update (in personal communication, > Pat said this was already possible but I don't think it was mentioned > directly in the draft). I think this is discussed in Khalil's draft. > >- Data could be tunneled at either layer 3 or layer 2, depending on > whether the above-mentioned link-layer establishment issues are > addressed. > >- Handoff from one "leaf" FA to another would be more transparent and > network-controlled, i.e., the MN would not see or need to participate > in the handoff as long as the GFA didn't change. Also I think it > is a mistake to use the "S" bit in this case because you are essentially > requiring 2x bandwidth for the period of time when the MN is connected > to both FAs. > >I know some of the considerations I've raised are really link-specific >issues, but their impact on the fast handoff mechanism should be >considered. It may turn out that fast handoff is best addressed in >the appropriate link-layer groups (3GPPs, IEEE) and not the IETF. > Well, there's an issue you've not included: - There needs to be some radio-link independent way to transfer radio quality measurements and radio link context information between the two FAs at L3. The reason for this is that the two FAs may not share an L2 RAN connection. If they do not share this connection, there is no way for radio quality measurements and radio channel information to be exchanged between the mobile and the new RAN. If this information cannot be exchanged, the FA at the old RAN can't judge whether the new RAN is getting good enough reception to take the mobile and the new RAN can't establish a radio link with the mobile because it doesn't know what channel the mobile is on. I think this is a major issue in accommodating inter-domain handoff. There seems to be a taboo on discussing L2 issues, even if they are accommodated in a way that is not specific to a particular L2. Unlike 802.11, CDMA and TDMA need some kind of support for sending L2 information over L3, otherwise, the new RAN simply can't find the mobile if there is no RAN interconnection. That said, if there is a RAN connection, there is no need for this information to be exchanged over L3 because it can be done over (logical) L2. As I mentioned in my response to Karim, the mobile IP working group may not be the place to work this out if the taboo on L2 is so strong, but it *will* have to be worked out somewhere, regardless of the ultimate fast handoff scheme we adopt, if mobile IP interdomain handoff is to work with CDMA and TDMA. jak From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Jul 23 21:31:21 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11109 for ; Sun, 23 Jul 2000 21:31:21 -0400 (EDT) Received: from standards (47.234.32.16:3966) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB80B8B@standards.nortelnetworks.com>; 23 Jul 2000 21:20:01 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20545 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 23 Jul 2000 21:20:01 -0400 Received: from mail0.u-aizu.ac.jp by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB80B8A@standards.nortelnetworks.com>; 23 Jul 2000 21:20:00 -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 KAA05966; Mon, 24 Jul 2000 10:29:52 +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 KAA12600; Mon, 24 Jul 2000 10:29:52 +0900 (JST) X-Mailer: Mozilla 4.7 [en_jp] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: <397AEA48.B76B9CF@u-aizu.ac.jp> <397B19C5.CB746281@iprg.nokia.com> Content-Type: multipart/alternative; boundary="------------5B035366029F421984427AF8" Message-ID: <397B9C0F.A71848B4@u-aizu.ac.jp> Date: Mon, 24 Jul 2000 10:29:52 +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] draft-malinen-mobileip-regreg6-00.txt X-To: Charlie Perkins To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --------------5B035366029F421984427AF8 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Hi Charlie, Thanks for your clarifications. By compromise I meant "replaces" or "optimizes". I thought that a persistent tunnel would be against MIPv6 philosophy of design. More importantly, in case of MIPv4, I think it is clear that regional registrations would lead to performance improvement. I could not yet see how this would be the case for MIPv6. What do you think? Regards, -- Behcet --------------5B035366029F421984427AF8 Content-Type: text/html; charset=iso-2022-jp Content-Transfer-Encoding: 7bit 
Hi Charlie,
  Thanks for your clarifications.
By compromise I meant "replaces" or "optimizes".
I thought that a persistent tunnel would be against MIPv6
philosophy of design.
  More importantly, in case of MIPv4, I think it is clear that
regional registrations would lead to performance improvement. I could
not yet see how this would be the case for MIPv6.



What do you think?






Regards,



-- 
Behcet

 

--------------5B035366029F421984427AF8--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Jul 24 01:59:11 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24933
	for ; Mon, 24 Jul 2000 01:59:10 -0400 (EDT)
Received: from standards (47.234.32.16:3487) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB80C41@standards.nortelnetworks.com>; Mon, 24 Jul 2000 1:47:43 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 20787 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jul 2000 01:47:43
          -0400
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFB80C3D@standards.nortelnetworks.com>; Mon, 24 Jul 2000 1:37:43
          -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 WAA03902;
          Sun, 23 Jul 2000 22:48:31 -0700 (PDT)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.9.3/8.9.3-VIRSCAN) id WAA19116; Sun, 23 Jul 2000 22:48:29 -0700
X-Virus-Scanned:  Sun, 23 Jul 2000 22:48:29 -0700 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from jmalinen.iprg.nokia.com (205.226.2.98,
          claiming to be "iprg.nokia.com") by
          darkstar.iprg.nokia.com(WTS.12.69) smtpd7olu76; Sun, 23 Jul 2000
          22:34:45 PDT
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
References: <397AEA48.B76B9CF@u-aizu.ac.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <397BD577.630F13F0@iprg.nokia.com>
Date:         Sun, 23 Jul 2000 22:34:47 -0700
Reply-To: jmalinen@IPRG.NOKIA.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: "Jari T. Malinen" 
Subject:      Re: [MOBILE-IP] draft-malinen-mobileip-regreg6-00.txt
X-To:         sarikaya@U-AIZU.AC.JP
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi, Bechet,

thanks for your comments,

Behcet Sarikaya wrote:

> Hi Jari and Charlie,
>   I have some questions on this I-D:
> The method is based on advertizing regional care-of addresses to MNs
> that can do a regional BU taking one of them as its alternate care-of address
> and thereafter using this address
> in the visited domain. This means that the data is continously tunneled
> from GMA to MN as long as MN stays in the
> domain (sounds like HAWAII in which MN is given an IPv4 address in the
> domain, doesn't it?).
> So address autoconfiguration at each access router and its associated BU
> traffic are compromised with MIPv4 like tunneling.
> This same idea can also be found in the I-D by Karim.
> Can you provide some clarification on this?

This IPv6-specifc design uses the general idea of IPv4 regional registrations
with a stationary care-of-address, but with the following distinctions to the
designs of HAWAII or Karim's I-D:

-  HA does not need to be regional-aware (or MAP-aware) as in Karim's
    I-D. The first packets from CN via HA to MN are re-capsulated at GMA
    via possible lower regional routers down to MN's autoconfigured on-link CoA.
    MN can recognize it needs to send a BU to CN from an encapsulated packet
    from CN, encapsulator being the access router. After MN sent a BU with
    alternate CoA to CN, this can start sending route-optimized packets to MN
    via GMA. Inner packet AH is not touched in intermediate routers.
    Packets are forwarded locally in the visited domain and not from HA.
    We can thus do without using an additional routing header with tunneling.

- In our design, most of the data packets are neither tunneled nor
   host-routed (note also that signaling is not tunneled).
   Route-optimized packets towards the MN are forwarded in a special
   way based only on the regional binding cache. Normal processing of
   source-routed packets is skipped if there is a regional binding cache
   entry for the route-optimized home address in the regional CoA router
   receiving the packet. Only IPhdr destination is changed, AH prevails.
   The packet is then just forwarded to the lower CoA as seen in the
   regional binding cache.  Thus, no extra routing state is needed.
   This is much simpler than in Karim's proposal and is quite different
   from IPv4-solutions. Universal route optimization as provided in basic
   Mobile IPv6 is not compromized. Such route optimization is not
   even possible in IPv4 due to its legacy CNs.

- When MN changes link and gets a new address by autoconfiguration
   it performs a regional binding update. This updates the lower CoA as
   seen by GMA or a lower crossover router. The regional binding cache
   can thus direct packets to the new direction, i.e. MN's ability to move is
   not compromized despite the use of address autoconfiguration.
   Those packets that were able to get past the crossover after MN started
   moving and before the crossover received a new regional BU can sometimes
   go to the MN via the simultaneous connection through the old on-link CoA.
   This amounts to no duplication of data packets (bicasting), just a careful
   switching of MN's default route from the old access router to the new one.
   Or, data packets can be buffered by the old router when no simultaneous
   connection is possible, e.g. in "hard handoff" conditions.

- Buffering was provided as one component of the handoff framework where
   our Mobile IPv6 regional registrations is another. Thus, this draft separates
   the problem of location update localization from the handoff state transition
   management.

The smooth handoff framework design, as described by the documents at

http://www.iprg.nokia.com/~charliep/txt/regreg6/regreg6.txt
http://www.iprg.nokia.com/~charliep/txt/smoothv6/smoothv6.txt
http://www.iprg.nokia.com/~charliep/txt/mobilebuf/buffer6.txt
http://www.iprg.nokia.com/~charliep/txt/rohc/hc-ho-draft.txt

> Has this I-D been submitted to IETF?

Yes, with the same procedure & boilerplate as draft-haverinen-reg-paging-00.txt,
Fri Jul/14/00. Curiously, no I-D-Action message resulted.

>
> Regards,
> --
> Behcet

Best Regards,

-Jari


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Jul 24 07:06:07 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18059
	for ; Mon, 24 Jul 2000 07:06:06 -0400 (EDT)
Received: from standards (47.234.32.16:1621) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB80D12@standards.nortelnetworks.com>; Mon, 24 Jul 2000 6:54:35 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 21059 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jul 2000 06:54:34
          -0400
Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB80D0F@standards.nortelnetworks.com>; Mon, 24 Jul 2000 6:44:33
          -0400
Received: from nscolmar.colmar.uha.fr (nscolmar.colmar.uha.fr [194.167.108.34])
          by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id FAA28232 for
          ; Mon, 24 Jul 2000 05:55:21 -0500 (CDT)
Received: from colmar.colmar.uha.fr (colmar.colmar.uha.fr [194.167.107.31]) by
          nscolmar.colmar.uha.fr (8.9.3/8.9.3) with ESMTP id MAA15922; Mon, 24
          Jul 2000 12:20:20 +0200
Received: from gtrpc13 (gtrpc13.colmar.uha.fr [192.168.12.51]) by
          colmar.colmar.uha.fr (8.8.8/8.8.8) with SMTP id MAA07734; Mon, 24 Jul
          2000 12:47:52 +0100 (WET DST)
X-Sender: conf@colmar.colmar.uha.fr
X-Mailer: Windows Eudora Pro Version 3.0.1 (32) [F]
Mime-Version: 1.0
Content-Type: text/enriched; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Message-ID:  <3.0.1.32.20000724135349.0090d940@colmar.colmar.uha.fr>
Date:         Mon, 24 Jul 2000 13:53:49 +0200
Reply-To: conf@COLMAR.UHA.FR
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: conf@COLMAR.UHA.FR
Subject:      [MOBILE-IP] Call for papers of ICN'01 & Final program of ECUMN'00
X-To:         conf@colmar.colmar.uha.fr
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: quoted-printable

Please feel free to circulate this following :

        - call for papers of ICN'01 (see
0000,0000,fefehttp://iutsun1.colmar.uha.fr/=
ICN01.html
) AND=20

        - final program of ECUMN'00  (see=
 0000,0000,fefehttp://iutsun1.colmar.uha.fr=
/ECUMN2000.html )

to interested colleagues.

Accept our sincere apologies if you receive multiple copies.

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


     CALL FOR PAPERS=20

IEEE International Conference on Networking=20

ICN'01=20

July 11-13, 2001 - CREF, Colmar, France=20




GENERAL INFORMATION=20


The 2001 International Conference on Networking (ICN'01) is sponsored by=
 IEEE/Comsoc, IEEE/Computer, by IEE, by SEE and by WSES. ICN'01 is organized=
 by academic, research and industrial societies will be held at the=
 Technical Institute, Colmar, part of the University of Haute Alsace,=
 France, from Wednesday July 11, 2001 to Friday July 13, 2001. The city of=
 Colmar is ideally situated in the eastern part of France, near the German=
 and Swiss borders. The city of Colmar has been working on its own=
 Metropolitan Area Network (MAN) project, called OASICE, including LAN=
 interconnection, PBX interconnection and interactive video. An exhibition=
 illustrating these topics will be organized for industrial companies and=
 development research institutes.=20

In order to encourage closer interaction between academic and industrial ATM=
 research communities, we solicit both academic research papers and=
 industrial contributions.=20


TOPICS OF SPECIAL INTEREST=20


Topics of interest include, but are not limited to the following:=20

 =20

  Communications switching and routing =20

Communications modeling =20

Communications security =20

Computer communications =20

Multimedia and multicast communications =20

Internet environment =20

Network Management and control =20

Quality of Service (IntServ, DiffServ, =85) =20

Wireless Communications (Satellite, WLL, 3G) =20

Voice over IP =20

Java, Tina, Corba architectures Network signaling =20

ATM networks =20

ATM/IP integration =20

Integrated services =20

Traffic engineering =20

Telecommunication networks architectures =20

Performance evaluation, simulation =20

Mobile agents, active and intelligent networks =20

Applications and case studies =20

Protocol design and evaluation =20

MPLS=20



These topics can be discussed in term of concepts, state of the art,=
 standards, implementations, running experiments and applications.=20


INSTRUCTIONS FOR AUTHORS=20


Mail four papers or E-mail preferably in Word 6 format, or alternately a=
 postscript version of a 2000-word extended abstract summarizing an original=
 work. All the manuscripts must be written in English. The top of the first=
 page of each paper should include the title of the paper, authors' name,=
 position, address, telephone and fax numbers, e-mail of the author=
 responsible for correspondence and a list of four keywords. The deadline=
 for submission of all extended abstracts is December 10, 2000 with=
 notification of acceptance by February 20, 2001. Submission of camera-ready=
 paper is by March 30, 2001.=20

Authors of accepted papers will be invited to submit full-length manuscripts=
 for inclusion in the proceedings with ISBN.=20


All submitted papers should be sent to the following address:=20


Pascal LORENZ=20

University of Haute Alsace=20

IUT - Department GTR=20

34 rue du Grillenbreit=20

68008 Colmar, France=20

Phone: 33 (0)389202366 Fax: 33 (0)389202359 Mobile: 33 (0)603658042=20

E-mail: lorenz@colmar.uha.fr=20


Check our Web page at=
 0000,0000,fefehttp://iutsun1.colmar.uha.fr=
/ICN01.html for the latest information concerning the=
 conference.=20

Best papers will be forwarded for consideration in a special issue of a=
 journal.=20


TUTORIALS AND WORKSHOPS=20


Tutorials and workshops provide overviews of current high interest topics.=
 Proposals for half of full day tutorials are due by December 10, 2000.=20


INTERNATIONAL ADVISORY COMMITTEE=20


R. Addie (Australia) - University of Southern Queensland=20

K. Begain (Jordan) - Mu'tah University=20

A. Benslimane (France) - University of Belfort-Montbeliard=20

B. Bing (Singapore) - Ngee Ann Polytechnic=20

D. Bonjour (France) - CNET=20

A. Brandwajn (USA) - University of California Santa Cruz=20

J.P. Coudreuse (France) =96 Mitsubishi=20

J. Crowcroft (UK) =96 University College London=20

S. Fdida (France) =96 LIP6=20

B. Gavish (USA) - Vanderbilt University=20

H. Guyennet (France) - University of Franche-Comte=20

J. Halpern (USA) =96 Newbridge=20

Z. Hulicki (Poland) =96 University of Cracow=20

R. Israel (France) - IEEE=20

A. Jajszczyk (Poland) - University of Mining & Metallurgy=20

A. Jamalipour (Australia) - University of Sydney=20

S. Kota (USA) - Lockeed Martin=20

D. Kouvatsos (UK) - University of Bradford=20

S. Kumar (USA) =96 Ericsson=20

G.S. Kuo (Taiwan) =96 National Central University=20

F. Le Faucheur (France) - Cisco=20

M. Lee (Korea) =96 Dongshin University=20

P. Lorenz (France) - University of Haute Alsace=20

H.. Mouftah (Canada) - Queen's University=20

G. Omidyar (USA) - Computer Sciences Corp.=20

J.J. Pansiot (France) - University of Strasbourg=20

M. Potts (Switzerland) - Martel=20

Z. Mammeri (France) - University of Toulouse=20

N. Mastorakis (Greece) - Military Institutions of University Education=20

S. Moyer (USA) - Bellcore=20

R. Muraine (France) - Newbridge=20

G. Pujolle (France) - University of Versailles-Saint-Quentin=20

S. Rao (Switzerland) - Ascom=20

A. Reid (UK) - British Telecom=20

S. Ritzenthaler (France) - Newbridge=20

P. Rolin (France) - ENST Bretagne=20

R. Saracco (Italy) - CSELT=20

G. Swallow (USA) - Cisco=20

H. Tobiet (France) =96 Clemessy=20

M. Trehel (France) =96 University of Franche-Comte=20

V.A. Villagra (Spain) =96 University of Madrid=20

E. Vazquez Gallo (Spain) =96 University of Madrid=20

O. Yang (Canada) - University of Ottawa=20


IMPORTANT DATES=20


Extended Abstract due: December 10, 2000=20

Notification of acceptance: February 20, 2001=20

Deadline for full-length camera-ready manuscript: March 30, 2001=20


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


1st IEEE European Conference on Universal Multiservice=
 Networks  ECUMN'2000

 October 2-4, 2000 - CREF, Colmar, France

FINAL PROGRAM


=20

08:30 - 18:30 Conference Registration


Monday October 2, 2000



09:00 - 09:20 Opening Address=20


09:20 - 10:30 Tutorial Session 1

Internet Services over Mobile and Wireless Networks: Architectures and=
 Protocols

G. Omidyar, Computer Sciences Corp., USA ; M.J. Montpetit, Teledesic LLC,=
 USA


10:30 - 11:00 Coffee Break


11:00 - 12:15 Network Architecture and Convergence

Chair: S. Ritzenthaler, Newbridge, France


MPLS and Next Generation Access Network

A. Kankkunen, Integral Access Inc, USA


Deutsche Telekom's View on Network Convergence

L. Falkenhagen Deutsche Telekom AG, Germany


A Functional Architecture for End-to-end Quality-of-Service in a=
 Multi-domain Network

E. Pagani, G.P. Rossi, University of Milano, Italy


12:15 - 13:00 Panel Discussion 1 - Network Evolution and Convergence


13:00 - 14:30 Lunch


14:30 - 16:15 Traffic=20

Chair: M. Villen, Telefonica I+D, Spain


The Relevance of the Bufferless Analysis for Traffic Management in=
 Telecommunication Networks

G. Hasslinger, F. Hartleb, Telekom Innovations-GmbH, Germany ; M. Fiedler,=
 University of Karlskrona/Ronneby, Sweden


Mapping of Loss and Delay Between IntServ and DiffServ

T. Chahed, G. H=E9buterne, C. Fayet, National Institute of=
 Telecommunications, France


Resource Demand of Aggregated Resource Reservations

J. Ehrensberger, Swiss Federal Institute of Technology, Switzerland


Characterization of the MPEG-2 Video Traffic Generated by DVD Applications

A. Chodorek, Kielce University of Technology, Poland ; R. Chodorek,=
 University of Mining and Metallurgy, Poland


14:30 - 16:15 Interworking between narrow band and broadband networks

Chair: S. Chakraborty, Technical University of Helsinki, Finland


Integrating Euro-ISDN with ATM Technology: Interworking Mechanisms and=
 Services Support

L. Mandalos, K. Leonidou, C. Andreopoulos, J. Drakos, S. Koubias, G.=
 Papadopoulos, University of Patras, Greece


Extending the Internet with the Intelligent Network Capabilities

B. El Ouahidi, M. Bouhdadi, University of Rabat, Morocco ; D. Bourget, ENST,=
 France


A Suitable Service Discipline for ATM-Ethernet Interconnection

J.M. Arco, D. Meziat, B. Alarcos, University of Alcala, Spain


Interoperability of ATM-Ethernet Interworking System: Design and Congestion=
 Control

R. Ouni, A. Soudani, S. Nasri, M. Abid, R. Tourki, University of Monastir,=
 Tinisia ; K. Torki, INPG, France


16:15 - 16:45 Coffee Break


16:45 - 18:30 Routing

Chair: P. Chemouil, France Telecom R&D, France


Adaptive Routing and Load Balancing of Ephemeral Connections

M. Heusse, ENST de Bretagne, France


A new Multi-Services Rerouting Algorithm

A. Gueroui, University of Versailles, France ; L. Mokdad University of=
 Dauphine, France ; J. Ben-Othman University of Paris 6, France


Extending Mobile IP-v6 with Multicast to Support Mobile Networks in  IPv6

T. Ernst, C. Castelluccia, INRIA Rh=F4ne-Alpes, France ; H.Y. Lach, Motorola=
 Labs, France


16:45 - 18:30 Interworking between IP and ATM

Chair: M. Potts, Martel, Switzerland


Topology Optimization of IP over ATM

L. Frelechou, M. Osborne, R. Haas, IBM Research, Switzerland


Resource Reservation with Boomerang via Open Interfaces

M. Maliosz, Budapest University of Technology and Economics, Hungary


Efficient Translation of Network Performance Parameters for Transport of IP=
 Packets over Cell-Switched Subnetworks

J. Schmitt, M. Karsten, R. Steinmetz, Darmstadt University of Technology,=
 Germany


Design of Adaptive Access Network and Control Protocol

H. Nakagawa, I. Kazunari, N. Ohta, NTT Information Sharing Platform=
 Laboratories, Japan


19:15 Reception - Town Hall


Tuesday October 3, 2000



09:00 - 10:45 End to end traffic Control (1)

Chair: U. Krieger, Deutsche Telecom, Germany


Guaranteed QoS for TCP flows in ATM-based DiffServ Networks

T. M=FCller, Dresden University of Technology, Germany


Virtual Buffering Strategy for GFR Services in IP/ATM Internetworks

S.C. Hu, Ming Shin Institute of Technology, Taiwan ; P.C. Wang, Y.C. Chen,=
 National Chiao Tung University, Taiwan ; C.T. Chan, Chunghwa Telecom,=
 Taiwan


An Efficient Weight Assignment Process for GPS Servers

G. Urvoy, PRISM, France ; G. Hebuterne, Institut National des=
 T=E9l=E9communications, France


Some Aspects of RTP - TCP Coexistence in Universal Multiservice  Networks

R. Chodorek, University of Mining and Metallurgy, Poland


09:00 - 10:45 Mobile Networks and Mobile Services

Chair: G. Omidyar, Computer Sciences Corp, USA


Voice Enabled Request and Response for Mobile Devices Supporting WAP=
 Protocol: the Constraints

A. Mohan, Himachal Futuristic Communications, India ; A. Mohan, Indian=
 Institute of Technology, India


IP based enhanced Data Casting Services over Radio Broadcast Networks

W. Kellerer, P. Sties, J. Ebersp=E4cher, Munich University of Technology,=
 Germany


Location-Dependant and Value Added Services (VAS) for Mobile Communications

P. Lorenz, University of Haute Alsace, France ; H. Tobiet, NMG, France=20


The IP Revolution and Potential gains for ISP/Mobile/Fixed Telephony=
 Operators in the Liberalization of Telecommunications

D. Vergados, D. Drakoulis, E. Vayias, J. Soldatos, N. Mitrou, National=
 Technical University of Athens, Greece


10:45 - 11:15 Coffee Break


11:15 - 13:00 Multicast

Chair: G. Girardi, CSELT, Italy


A Scalable Fault Tolerant Approach to Core Election in an Inter-Domain=
 Multicast Routing Environment

M.D.Ech-Cherif El Kettani, ENSIAS, Morocco; Y. Souissi, EMI, Morocco


A New Routing Algorithm for Delay-Constrained Dynamic Multicast

T. Asaka, NTT Service Integration Laboratories, Japan ; T. Miyoshi, Y.=
 Tanaka, Waseda University, Japan


Remote Time-Alignment of Interactive Services through Efficient Multicast=
 Algorithms

A. Borella, G. Cancellieri, University of Ancona, Italy


Key Establishment for IGMP Authentication in IP Multicast

T. Hardjono, B. Cain, Nortel Networks, USA


11:15 - 13:00 IP Test-beds

Chair: H. Tobiet, NMG, France


Real-Time Multimedia Services over Internet

A. Benslimane, Technical University of Belfort-Montb=E9liard, France


Telephony over IP: Theoretical Modelling and Lab Experiments

P. Senesi, P. Ferrabone, G. Gritella, R. Rinaldi, M. Siviero, CSELT, Italy


User-domain Multiservice Architecture for Wired and Wireless IP  Networks

L. Cheng, I. Marsic, The State University of New Jersey, USA


A Testbed Environment for the Performance Evaluation of Modular Network=
 Architectures

D. Maggiorini, E. Pagani, G.P. Rossi, University of Milano, Italy


13:00 - 14:30 Lunch


14:30 - 16:15 Modeling

Chair: G. H=E9buterne, INT, France


Estimation of the Renewal Function by Empiral Data - A Bayesian  Approach

N.M. Markovitch, Russian Academy of Sciences, Russia ; U.R. Krieger, T-Nova=
 Deutsche Telekom, Germany


Modeling Access Networks for Quality of Service

F. Duran, T. Lizambri, S. Wakid, National Institute of Standards and=
 Technology, USA ; D.R. Vaman, Megaxess, USA


Managing Wireless Internet Information of Electronic Advertising

E. Rashid, Y. Yoshioka, Hirosaki University, Japan ; Y. Nemoto, T. Nakamura,=
 Tohoku University, Japan


Performance Evaluation of a full Memory Multidestination Protocol for=
 Satellite Based Reliable Multicast with and without Local Recovery

H. Jianhua, K.R. Subramanian, Y. ZongKai, H. Ping, Nanyang Technological=
 University, Singapore


14:30 - 16:15 Tariffs and Bandwidth Allocation

Chair: P. Lorenz, University of Haute Alsace, France


INEDAC Project: A Tool to Calculate Interconnection Tariff based on a=
 Bottom-up Method

J.A. Portilla, K.D. Hackbarth, A.E. Garcia, University of Cantabria, Spain ;=
 R. W=F6hrl, F. Gonzalez, Institut f=FCr Kommunikationsdienste GmbH, Germany


Auction Method and its Performance in a Dynamic Bandwidth Allocation Service

E. Takahashi, Y. Tanaka, Waseda Universiy, Japan


Multivariable Feedforward Plus Feedback Control for Adapting MPEG Video=
 Streams to Variable Channel Bandwidth

H.F. Raynaud, M. Luong, University of Paris Nord, France


Robust Topology for Enterprise Networks against Diverse Tariff Structures

T. Miyoshi, K. Mouri, Y. Tanaka, Waseda University, Japan ; T. Asaka, NTT=
 Service Integration Laboratories, Japan


16:15 - 16:45 Coffee Break


16:45 - 18:30 End to end Traffic Control (2)

Chair: G. H=E9buterne, INT, France


An Architecture of QoS Services for a Core Internet Network over DTM

C.J. Barenco, Polytechnic University of Madrid, Spain ; A.A. Salona, J.I.=
 Moreno, University Carlos III of Madrid, Spain


Congestion Avoidance for Unicast and Multicast Traffic

A. Dracinschi, S. Fdida, University Pierre et Marie Curie, France


MPOA and QoS Support in LIS Internetworking Environments

I. Erturk, Kocaeli University, UK ; E. Stipidis, University of Sussex, UK


A Method for Increasing Throughput based on Packet Striping

F. Jacquet, M. Misson, IUT of Clermont-Ferrand, France


16:45 - 18:30 Advanced Networking

Chair: G.V. Morson, Cambridge Network, England


A New Network Service Environment using Active Network

K. Widoyo, T. Aoki, H. Yasuda, University of Tokyo, Japan


Adaptive Applications over Active Networks: Case Study on Layered Multicast

L. Yamamoto, G. Leduc, University of Li=E8ge, Belgium


Integrated Performance Monitoring of Client/Server Software

C. Steigner, J. Wilke, I. Wulff, University of Koblenz-Landau, Germany


Who needs Addresses ?

V. Guruprasad, IBM, USA


20:00 Gala Dinner - Restaurant Meistermann


Wednesday October 4, 2000



09:00 - 10:00 Tutorial Session 2

Chair: P. Rolin, France Telecom R&D, France


Active Networks and its Management

M. Brunner, NEC Europe Ltd, Germany


10:00- 10:30 Coffee Break


10:30 - 11:45 New Architectures for New Services

Chair: A. Gravey, ENST-Bretagne, France


A Novel Architecture for Efficient Protocol Processing in High Speed=
 Communication Environments

G. Konstantoulakis, V. Nellas, C. Georgopoulos, T. Orphanoudakis, N. Zervos,=
 Ellemedia Technologies, Greece ; M. Steck, Hyperstone electronics GmbH,=
 Germany; D. Verkest, Interuniversity Microelectronics Centre (IMEC),=
 Belgium; G. Doumenis, D.Reisis, University of Athens, Greece; N. Nikolaou,=
 J.A. Sanchez, Lucent Technologies, The Netherlands


Using T=E9l=E9domotis Interface for a new Multiservice Network applied to=
 Monitoring the Elderly

T. Val, E. Campo, IUT of Blagnac, France ; P. Kauffmann, M. Misson,=
 University of Clermont II, France ; P.Y. Danet, France T=E9l=E9com R&D,=
 France


Video and Interactive Internet access in a DVB Network

R. Jaeger, BetaResearch, Germany


11:45 - 13:00 Panel Discussion 2 - New Architectures for New Services


13:00 - 14:30 Lunch


14:30 Visit of Vialis


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Jul 24 11:20:55 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20923
	for ; Mon, 24 Jul 2000 11:20:54 -0400 (EDT)
Received: from standards (47.234.32.16:4046) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB80DC8@standards.nortelnetworks.com>; Mon, 24 Jul 2000 11:07:31 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 21297 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jul 2000 11:07:30
          -0400
Received: from crufty.research.bell-labs.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB80DC7@standards.nortelnetworks.com>; Mon, 24 Jul 2000 11:07:30
          -0400
Received: from grubby.research.bell-labs.com ([135.104.2.9]) by crufty; Mon Jul
          24 11:17:31 EDT 2000
Received: from king.research.bell-labs.com ([135.1.152.1]) by grubby; Mon Jul
          24 11:17: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 D597F5701F; Mon, 24 Jul 2000 10:17:29 -0500 (CDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <200007232122.OAA06736@nasnfs.eng.sun.com>
X-Mailer: VM 6.33 under Emacs 19.34.2
Message-ID:  <20000724151729.D597F5701F@king.research.bell-labs.com>
Date:         Mon, 24 Jul 2000 10:17:29 -0500
Reply-To: Pete McCann 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: Pete McCann 
Subject:      Re: [MOBILE-IP] Fast Handoff Issues
X-To:         James.Kempf@Eng.Sun.COM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <200007232122.OAA06736@nasnfs.eng.sun.com>
Content-Transfer-Encoding: 7bit

Hi, James,

James Kempf  (JK) writes:

>> I know some of the considerations I've raised are really link-specific
>> issues, but their impact on the fast handoff mechanism should be
>> considered.  It may turn out that fast handoff is best addressed in
>> the appropriate link-layer groups (3GPPs, IEEE) and not the IETF.

JK> Well, there's an issue you've not included:

JK> - There needs to be some radio-link independent way to transfer radio
JK> quality measurements and radio link context information between the two FAs
JK> at L3.

I'm not so sure that there is a need for this.  Just for information,
here's how it works in CDMA today: the BSC, based on pre-provisioned
information, tells the MN to watch the pilot strengths of a number of
neighbor BSCs in a "candidate set."  When some of these measurements
exceed a threshold for a given duration, the MN reports that fact to
the BSC.  The BSC then decides whether to initiate a hard or soft
handoff.  Soft handoff is uninteresting here because it does not
involve a change in the MN's L3 point of attachment.  In hard handoff,
a message is sent to the candidate BSC asking if it has the radio
resources (and other resources) necessary to accept the handoff.  If
so, the handoff is requested and the MN is told on which channels
to re-tune.

To me, this process only makes sense if both BSCs are of the same
technology.  It is theoretically possible for BSCs of different
technologies to run the message flow above, but at each step, the
information must be translated from one system's representation to
another, and the measurements might even be so totally different in
shape that this is not possible.

If you do have two different technologies, such as 802.11 and
cdma2000, then it should be up to the MN to decide when it wants to
hand off.  I do not think we can expect the cdma2000 BSC to get
involved in asking for power measurements from WaveLAN.  The MN
supports both technologies (and there is probably a different pricing
model involved for the two services) so it is in the unique best
position to make a decision.  Also, a fast handoff can be completed
simply by bringing up the WaveLAN before shutting down the cdma2000
link - both interfaces are physically present on the MN so this should
be doable.  No interaction between the two networks is required.

JK> As I mentioned in my response to Karim, the mobile IP working
JK> group may not be the place to work this out if the taboo on L2 is
JK> so strong, but it *will* have to be worked out somewhere,
JK> regardless of the ultimate fast handoff scheme we adopt, if mobile
JK> IP interdomain handoff is to work with CDMA and TDMA.

I guess I was really talking about inter-domain, single technology
handoffs, because it seems to me that the inter-domain, different
technology handoff problem has a simple solution (let the MN decide).
So maybe "proactive FA" only makes sense in the case of homogeneous
radio transmission technology, but I think it can be of great benefit
there, assuming we can solve the "PPP re-establishment" problem.  The
way I think of the proactive FA solution is that there is always an
unshown flow of information between the BSCs attached to each leaf FA
to exchange information and decide whether the handoff should take
place.  It seems to me this flow of information should be left
unspoken in the IETF and defined elsewhere (i.e., in the 3GPPs).

-Pete


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Jul 24 11:33:06 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25713
	for ; Mon, 24 Jul 2000 11:33:04 -0400 (EDT)
Received: from standards (47.234.32.16:4046) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB80E05@standards.nortelnetworks.com>; Mon, 24 Jul 2000 11:21:08 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 21373 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jul 2000 11:21:08
          -0400
Received: from ebene.inrialpes.fr by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB80E04@standards.nortelnetworks.com>; Mon, 24 Jul 2000 11:21:03
          -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 RAA22704; Mon, 24 Jul
          2000 17:31:52 +0200 (MET DST)
Received: from inrialpes.fr (localhost [127.0.0.1]) by iseran.inrialpes.fr
          (8.8.7/8.8.5) with ESMTP id RAA14939; Mon, 24 Jul 2000 17:31:52 +0200
          (MET DST)
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <397AEA48.B76B9CF@u-aizu.ac.jp> <397BD577.630F13F0@iprg.nokia.com>
Content-Type: multipart/alternative;
              boundary="------------4EF36036F008B5FB41098E47"
Message-ID:  <397C6167.94728DC4@inrialpes.fr>
Date:         Mon, 24 Jul 2000 17:31:52 +0200
Reply-To: Claude.Castelluccia@INRIALPES.FR
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: Claude Castelluccia 
Subject:      Re: [MOBILE-IP] draft-malinen-mobileip-regreg6-00.txt
X-To:         jmalinen@IPRG.NOKIA.COM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

--------------4EF36036F008B5FB41098E47
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Jari,

Your  "Mobile IPv6 Regional Registrations" proposal has a lot of simillarities with
our HMIPv6
proposal (the ID that will be presented in Pittsburg is available on
http://www.inrialpes.fr/planete/people/ccastel/draft-castelluccia-mobileip-hmipv6-00.txt
but I am sure
you know our work since you were at IPCN...).
FYI a FreeBSD implementation of HMIPv6 is available since April 2000 on
http://www.inrialpes.fr/planete.

One difference  that I see between our proposals is that in HMIPv6 a MH  configures
its GCoA (this is what you
call regional CoA) by itself
(we make full use of IPv6 functionalties). The access router only advertises the
subnet prefix address of the
MS (this is what you call MGA) instead of a long list of  IPv6 addresses.
Since these router adv. are sent frequently, our proposal  results in a better
utilization of the wireless ressources....

Beside that autoconfiguration solves a lot of problem. In your scheme when a
MH gets a Regional CoA from the
router adv. ,this address has to be removed from the advertised list otherwise you
will have address collision.
This implies to have a protocol between the MGA and the access routers  and results
in higher  registration and
handoff delays..
In HMIP, since the GCoA is build by concatening the MS prefix and EUI64, address
collision is very unlikely
(but the MS verifies the unicity of the address by performing a DaD on its link).
Why don't you use the nice IPv6  autoconfiguration capability?

I have another question: why does a mobile host  send its regionalized BU to the
access router instead of sending it
directly to the closed Regional MA as we do (the RMA address could be advertised in
the router adv.)?
This would  provide more flexibility in the deployement of the Regional-aware
routers (they don't have to be on a tree anymore)...

regards,

Claude.



"Jari T. Malinen" wrote:

> Hi, Bechet,
>
> thanks for your comments,
>
> Behcet Sarikaya wrote:
>
> > Hi Jari and Charlie,
> >   I have some questions on this I-D:
> > The method is based on advertizing regional care-of addresses to MNs
> > that can do a regional BU taking one of them as its alternate care-of address
> > and thereafter using this address
> > in the visited domain. This means that the data is continously tunneled
> > from GMA to MN as long as MN stays in the
> > domain (sounds like HAWAII in which MN is given an IPv4 address in the
> > domain, doesn't it?).
> > So address autoconfiguration at each access router and its associated BU
> > traffic are compromised with MIPv4 like tunneling.
> > This same idea can also be found in the I-D by Karim.
> > Can you provide some clarification on this?
>
> This IPv6-specifc design uses the general idea of IPv4 regional registrations
> with a stationary care-of-address, but with the following distinctions to the
> designs of HAWAII or Karim's I-D:
>
> -  HA does not need to be regional-aware (or MAP-aware) as in Karim's
>     I-D. The first packets from CN via HA to MN are re-capsulated at GMA
>     via possible lower regional routers down to MN's autoconfigured on-link CoA.
>     MN can recognize it needs to send a BU to CN from an encapsulated packet
>     from CN, encapsulator being the access router. After MN sent a BU with
>     alternate CoA to CN, this can start sending route-optimized packets to MN
>     via GMA. Inner packet AH is not touched in intermediate routers.
>     Packets are forwarded locally in the visited domain and not from HA.
>     We can thus do without using an additional routing header with tunneling.
>
> - In our design, most of the data packets are neither tunneled nor
>    host-routed (note also that signaling is not tunneled).
>    Route-optimized packets towards the MN are forwarded in a special
>    way based only on the regional binding cache. Normal processing of
>    source-routed packets is skipped if there is a regional binding cache
>    entry for the route-optimized home address in the regional CoA router
>    receiving the packet. Only IPhdr destination is changed, AH prevails.
>    The packet is then just forwarded to the lower CoA as seen in the
>    regional binding cache.  Thus, no extra routing state is needed.
>    This is much simpler than in Karim's proposal and is quite different
>    from IPv4-solutions. Universal route optimization as provided in basic
>    Mobile IPv6 is not compromized. Such route optimization is not
>    even possible in IPv4 due to its legacy CNs.
>
> - When MN changes link and gets a new address by autoconfiguration
>    it performs a regional binding update. This updates the lower CoA as
>    seen by GMA or a lower crossover router. The regional binding cache
>    can thus direct packets to the new direction, i.e. MN's ability to move is
>    not compromized despite the use of address autoconfiguration.
>    Those packets that were able to get past the crossover after MN started
>    moving and before the crossover received a new regional BU can sometimes
>    go to the MN via the simultaneous connection through the old on-link CoA.
>    This amounts to no duplication of data packets (bicasting), just a careful
>    switching of MN's default route from the old access router to the new one.
>    Or, data packets can be buffered by the old router when no simultaneous
>    connection is possible, e.g. in "hard handoff" conditions.
>
> - Buffering was provided as one component of the handoff framework where
>    our Mobile IPv6 regional registrations is another. Thus, this draft separates
>    the problem of location update localization from the handoff state transition
>    management.
>
> The smooth handoff framework design, as described by the documents at
>
> http://www.iprg.nokia.com/~charliep/txt/regreg6/regreg6.txt
> http://www.iprg.nokia.com/~charliep/txt/smoothv6/smoothv6.txt
> http://www.iprg.nokia.com/~charliep/txt/mobilebuf/buffer6.txt
> http://www.iprg.nokia.com/~charliep/txt/rohc/hc-ho-draft.txt
>
> > Has this I-D been submitted to IETF?
>
> Yes, with the same procedure & boilerplate as draft-haverinen-reg-paging-00.txt,
> Fri Jul/14/00. Curiously, no I-D-Action message resulted.
>
> >
> > Regards,
> > --
> > Behcet
>
> Best Regards,
>
> -Jari

--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/



--------------4EF36036F008B5FB41098E47
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Hi Jari,

Your  "Mobile IPv6 Regional Registrations" proposal has a lot of
simillarities with our HMIPv6

proposal (the ID that will be presented in Pittsburg is available
on

http://www.inrialpes.fr/planete/people/ccastel/draft-castelluccia-mobileip-hmipv6-00.txt
but I am sure

you know our work since you were at IPCN...).

FYI a FreeBSD implementation of HMIPv6 is available since April
2000 on http://www.inrialpes.fr/planete.

One difference  that I see between our proposals is that in HMIPv6
a MH  configures its GCoA (this is what you

call regional CoA) by itself

(we make full use of IPv6 functionalties). The access router only advertises
the subnet prefix address of the

MS (this is what you call MGA) instead of a long list of 
IPv6 addresses.

Since these router adv. are sent frequently, our proposal  results
in a better utilization of the wireless ressources....

Beside that autoconfiguration solves a lot of problem. In your scheme
when a MH gets a Regional CoA from the

router adv. ,this address has to be removed from the advertised list
otherwise you will have address collision.

This implies to have a protocol between the MGA and the access routers 
and results in higher  registration and

handoff delays..

In HMIP, since the GCoA is build by concatening the MS prefix
and EUI64, address collision is very unlikely

(but the MS verifies the unicity of the address by performing a DaD
on its link).

Why don't you use the nice IPv6  autoconfiguration capability?

I have another question: why does a mobile host  send its regionalized
BU to the access router instead of sending it

directly to the closed Regional MA as we do (the RMA address could
be advertised in the router adv.)?

This would  provide more flexibility in the deployement of the
Regional-aware routers (they don't have to be on a tree anymore)...

regards,

Claude.

 

 

"Jari T. Malinen" wrote:

Hi, Bechet,

thanks for your comments,

Behcet Sarikaya wrote:

> Hi Jari and Charlie,

>   I have some questions on this I-D:

> The method is based on advertizing regional care-of addresses to
MNs

> that can do a regional BU taking one of them as its alternate care-of
address

> and thereafter using this address

> in the visited domain. This means that the data is continously tunneled

> from GMA to MN as long as MN stays in the

> domain (sounds like HAWAII in which MN is given an IPv4 address in
the

> domain, doesn't it?).

> So address autoconfiguration at each access router and its associated
BU

> traffic are compromised with MIPv4 like tunneling.

> This same idea can also be found in the I-D by Karim.

> Can you provide some clarification on this?

This IPv6-specifc design uses the general idea of IPv4 regional registrations

with a stationary care-of-address, but with the following distinctions
to the

designs of HAWAII or Karim's I-D:

-  HA does not need to be regional-aware (or MAP-aware) as in Karim's

    I-D. The first packets from CN via HA to MN are
re-capsulated at GMA

    via possible lower regional routers down to MN's
autoconfigured on-link CoA.

    MN can recognize it needs to send a BU to CN from
an encapsulated packet

    from CN, encapsulator being the access router. After
MN sent a BU with

    alternate CoA to CN, this can start sending route-optimized
packets to MN

    via GMA. Inner packet AH is not touched in intermediate
routers.

    Packets are forwarded locally in the visited domain
and not from HA.

    We can thus do without using an additional routing
header with tunneling.

- In our design, most of the data packets are neither tunneled nor

   host-routed (note also that signaling is not tunneled).

   Route-optimized packets towards the MN are forwarded in
a special

   way based only on the regional binding cache. Normal processing
of

   source-routed packets is skipped if there is a regional
binding cache

   entry for the route-optimized home address in the regional
CoA router

   receiving the packet. Only IPhdr destination is changed,
AH prevails.

   The packet is then just forwarded to the lower CoA as
seen in the

   regional binding cache.  Thus, no extra routing state
is needed.

   This is much simpler than in Karim's proposal and is quite
different

   from IPv4-solutions. Universal route optimization as provided
in basic

   Mobile IPv6 is not compromized. Such route optimization
is not

   even possible in IPv4 due to its legacy CNs.

- When MN changes link and gets a new address by autoconfiguration

   it performs a regional binding update. This updates the
lower CoA as

   seen by GMA or a lower crossover router. The regional
binding cache

   can thus direct packets to the new direction, i.e. MN's
ability to move is

   not compromized despite the use of address autoconfiguration.

   Those packets that were able to get past the crossover
after MN started

   moving and before the crossover received a new regional
BU can sometimes

   go to the MN via the simultaneous connection through the
old on-link CoA.

   This amounts to no duplication of data packets (bicasting),
just a careful

   switching of MN's default route from the old access router
to the new one.

   Or, data packets can be buffered by the old router when
no simultaneous

   connection is possible, e.g. in "hard handoff" conditions.

- Buffering was provided as one component of the handoff framework where

   our Mobile IPv6 regional registrations is another. Thus,
this draft separates

   the problem of location update localization from the handoff
state transition

   management.

The smooth handoff framework design, as described by the documents at

http://www.iprg.nokia.com/~charliep/txt/regreg6/regreg6.txt

http://www.iprg.nokia.com/~charliep/txt/smoothv6/smoothv6.txt

http://www.iprg.nokia.com/~charliep/txt/mobilebuf/buffer6.txt

http://www.iprg.nokia.com/~charliep/txt/rohc/hc-ho-draft.txt

> Has this I-D been submitted to IETF?

Yes, with the same procedure & boilerplate as draft-haverinen-reg-paging-00.txt,

Fri Jul/14/00. Curiously, no I-D-Action message resulted.

>

> Regards,

> --

> Behcet

Best Regards,

-Jari



-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

 

--------------4EF36036F008B5FB41098E47--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Jul 24 12:04: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 MAA05344
	for ; Mon, 24 Jul 2000 12:04:20 -0400 (EDT)
Received: from standards (47.234.32.16:4046) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB80E44@standards.nortelnetworks.com>; Mon, 24 Jul 2000 11:52:28 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 21456 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jul 2000 11:52:28
          -0400
Received: from omega.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB80E43@standards.nortelnetworks.com>; Mon, 24 Jul 2000 11:52:28
          -0400
Received: from gdommety-laptop1.cisco.com (gdommety-dsl3.cisco.com
          [10.19.17.140]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8)
          with ESMTP id JAA24612; Mon, 24 Jul 2000 09:03:13 -0700 (PDT)
X-Sender: gdommety@omega.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
References: <397AEA48.B76B9CF@u-aizu.ac.jp> <397BD577.630F13F0@iprg.nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.3.1.2.20000724084539.00aee490@omega.cisco.com>
Date:         Mon, 24 Jul 2000 09:07:51 -0700
Reply-To: Gopal Dommety 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: Gopal Dommety 
Subject:      Re: [MOBILE-IP] draft-malinen-mobileip-regreg6-00.txt
X-To:         Claude.Castelluccia@INRIALPES.FR
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <397C6167.94728DC4@inrialpes.fr>

Hello:

On similar lines, we have submitted a draft
(draft-dommety-mobileip-lma-ipv6.txt) on July 14th.
I did not go through the new drafts by Charlie to know the differences. I
did go through the
draft-soliman-mobileip-hmipv6-00.txt. The LMA Draft does talk about the
similarities and
differences between these two drafts.

I am appending the draft below.

Thanks
Gopal


At 05:31 PM 7/24/00 +0200, Claude Castelluccia wrote:
>Hi Jari,
>
>Your  "Mobile IPv6 Regional Registrations" proposal has a lot of
>simillarities with our HMIPv6
>proposal (the ID that will be presented in Pittsburg is available on
>http://www.inrialpes.fr/planete/people/ccastel/draft-castelluccia-mobileip-hmipv6-00.txt
>but I am sure
>you know our work since you were at IPCN...).
>FYI a FreeBSD implementation of HMIPv6 is available since April 2000 on
>http://www.inrialpes.fr/planete.
>
>One difference  that I see between our proposals is that in HMIPv6 a
>MH  configures its GCoA (this is what you
>call regional CoA) by itself
>(we make full use of IPv6 functionalties). The access router only
>advertises the subnet prefix address of the
>MS (this is what you call MGA) instead of a long list of  IPv6 addresses.
>Since these router adv. are sent frequently, our proposal  results in a
>better utilization of the wireless ressources....
>
>Beside that autoconfiguration solves a lot of problem. In your scheme when
>a MH gets a Regional CoA from the
>router adv. ,this address has to be removed from the advertised list
>otherwise you will have address collision.
>This implies to have a protocol between the MGA and the access
>routers  and results in higher  registration and
>handoff delays..
>In HMIP, since the GCoA is build by concatening the MS prefix and EUI64,
>address collision is very unlikely
>(but the MS verifies the unicity of the address by performing a DaD on its
>link).
>Why don't you use the nice IPv6  autoconfiguration capability?
>
>I have another question: why does a mobile host  send its regionalized BU
>to the access router instead of sending it
>directly to the closed Regional MA as we do (the RMA address could be
>advertised in the router adv.)?
>This would  provide more flexibility in the deployement of the
>Regional-aware routers (they don't have to be on a tree anymore)...
>
>regards,
>
>Claude.
>
>
>
>"Jari T. Malinen" wrote:
>>Hi, Bechet,
>>
>>thanks for your comments,
>>
>>Behcet Sarikaya wrote:
>>
>> > Hi Jari and Charlie,
>> >   I have some questions on this I-D:
>> > The method is based on advertizing regional care-of addresses to MNs
>> > that can do a regional BU taking one of them as its alternate care-of
>> address
>> > and thereafter using this address
>> > in the visited domain. This means that the data is continously tunneled
>> > from GMA to MN as long as MN stays in the
>> > domain (sounds like HAWAII in which MN is given an IPv4 address in the
>> > domain, doesn't it?).
>> > So address autoconfiguration at each access router and its associated BU
>> > traffic are compromised with MIPv4 like tunneling.
>> > This same idea can also be found in the I-D by Karim.
>> > Can you provide some clarification on this?
>>
>>This IPv6-specifc design uses the general idea of IPv4 regional
>>registrations
>>with a stationary care-of-address, but with the following distinctions to
>>the
>>designs of HAWAII or Karim's I-D:
>>
>>-  HA does not need to be regional-aware (or MAP-aware) as in Karim's
>>     I-D. The first packets from CN via HA to MN are re-capsulated at GMA
>>     via possible lower regional routers down to MN's autoconfigured
>> on-link CoA.
>>     MN can recognize it needs to send a BU to CN from an encapsulated
>> packet
>>     from CN, encapsulator being the access router. After MN sent a BU with
>>     alternate CoA to CN, this can start sending route-optimized packets
>> to MN
>>     via GMA. Inner packet AH is not touched in intermediate routers.
>>     Packets are forwarded locally in the visited domain and not from HA.
>>     We can thus do without using an additional routing header with
>> tunneling.
>>
>>- In our design, most of the data packets are neither tunneled nor
>>    host-routed (note also that signaling is not tunneled).
>>    Route-optimized packets towards the MN are forwarded in a special
>>    way based only on the regional binding cache. Normal processing of
>>    source-routed packets is skipped if there is a regional binding cache
>>    entry for the route-optimized home address in the regional CoA router
>>    receiving the packet. Only IPhdr destination is changed, AH prevails.
>>    The packet is then just forwarded to the lower CoA as seen in the
>>    regional binding cache.  Thus, no extra routing state is needed.
>>    This is much simpler than in Karim's proposal and is quite different
>>    from IPv4-solutions. Universal route optimization as provided in basic
>>    Mobile IPv6 is not compromized. Such route optimization is not
>>    even possible in IPv4 due to its legacy CNs.
>>
>>- When MN changes link and gets a new address by autoconfiguration
>>    it performs a regional binding update. This updates the lower CoA as
>>    seen by GMA or a lower crossover router. The regional binding cache
>>    can thus direct packets to the new direction, i.e. MN's ability to
>> move is
>>    not compromized despite the use of address autoconfiguration.
>>    Those packets that were able to get past the crossover after MN started
>>    moving and before the crossover received a new regional BU can sometimes
>>    go to the MN via the simultaneous connection through the old on-link
>> CoA.
>>    This amounts to no duplication of data packets (bicasting), just a
>> careful
>>    switching of MN's default route from the old access router to the new
>> one.
>>    Or, data packets can be buffered by the old router when no simultaneous
>>    connection is possible, e.g. in "hard handoff" conditions.
>>
>>- Buffering was provided as one component of the handoff framework where
>>    our Mobile IPv6 regional registrations is another. Thus, this draft
>> separates
>>    the problem of location update localization from the handoff state
>> transition
>>    management.
>>
>>The smooth handoff framework design, as described by the documents at
>>
>>http://www.iprg.nokia.com/~charliep/txt/regreg6/regreg6.txt
>>
>>http://www.iprg.nokia.com/~charliep/txt/smoothv6/smoothv6.txt
>>http://www.iprg.nokia.com/~charliep/txt/mobilebuf/buffer6.txt
>>
>>http://www.iprg.nokia.com/~charliep/txt/rohc/hc-ho-draft.txt
>>
>> > Has this I-D been submitted to IETF?
>>
>>Yes, with the same procedure & boilerplate as
>>draft-haverinen-reg-paging-00.txt,
>>Fri Jul/14/00. Curiously, no I-D-Action message resulted.
>>
>> >
>> > Regards,
>> > --
>> > Behcet
>>
>>Best Regards,
>>
>>-Jari
>
>--
>
>----------------------------------------
>Claude CASTELLUCCIA, INRIA Rhone-Alpes
>ph:  +33 4.76.61.52.15 (fax: 52.52)
>http://www.inrialpes.fr/planete/



INTERNET DRAFT                                        Gopal Dommety, Cisco
Category: Standards Track
Title: draft-dommety-mobileip-lma-ipv6-00.txt         Madhavi Subbarao, Cisco
                                                       Raj Patil, Nokia
July 2000

Expires  December 2000

                         Local Mobility Agents in IPv6
                    draft-dommety-mobileip-lma-ipv6-00.txt

Status of this Memo

    This document is a submission by the mobile-ip Working Group of the
    Internet Engineering Task Force (IETF).  Comments should be submitted
    to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list.

    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 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.

Abstract

  Mobile  IPv6 is better  integrated into  IPv6, thereby  obviating the
need for Foreign Agents  (FA) in IPv6 [5]. In IPv6 most if  not all of the
functions  of the Mobile-IPv4  FA [1] are  assumed by  other parts  of the
Mobile-IPv6  architecture.   Specifically,  all  routers  send  Router
Advertisements and the MN does  its own detunneling and Routing Header
processing.

This draft proposes the concept of Local Mobility Agents (LMA)in
Mobile IPv6 Architecture.  LMA is an optional entity.  The main
advantage is that it enables the feasibility of fast handoffs. The
other advantage is Authentication in Local Domain. The other reason
is that in any commercial operators network you will need a
controlling element for mobile users/stations.

1. Introduction


  Mobile  IPv6 is better  integrated into  IPv6, thereby  obviating the
need for Foreign Agents  (FA) in IPv6. In IPv6 most if  not all of the
functions  of the Mobile-IPv4  FA are  assumed by  other parts  of the
Mobile-IPv6  architecture.   Specifically,  all  routers  send  Router
Advertisements and the MN does  its own detunneling and Routing Header
processing.

This  draft introduces the  concept of  Local  Mobility Agents  (LMA)in
Mobile  IPv6  Architecture.  LMA  is  an  optional  entity.  The  main
advantage of  having LMA  is that it  enables the feasibility  of fast
handoffs  (Similar  to  the   proposal  [4].  The  other  advantage  is
Authentication in Local Domain (Similar to the proposal [14]).

In wide area deployment, the handoff latencies of the current mobileip
could be high. In a mobile  environment, it is very important to limit
the delay experienced  in communication when a mobile  moves from base
station\access point  to another.  Introduction of LMA  in Mobile IPv6
Architecture enables fast handoffs.

1.1 Problem Description

Mobility agents similar to Foreign  Agents in Mobile IPv4 do not exist
in Mobile  IPv6. Although  there is  no need for  such agents  for the
operation  of mobile  IP, in  certain  scenarios they  help solve  the
problem of  Fast Handoffs  and provide a  agent for  Authentication in
local Domain. Other advantages will be discussed later.


A) Handoff: When  a Mobile moves from one subnet  to another the break
in  communication  perceived by  the  user has  to  be  low.  This  is
especially important  for voice applications. Having  a Local Mobility
Agent provides an advantage due to the following reasons:

         1. It    provides   an   option    of   using    LMACoA   (LMA
CareofAddress).  This  eliminates one  round trip  if  using DHCPv6 [6]  or
Autoconfiguration [11] (more than one round trip?) to obtain the COA.

         2. It  introduces  the   possibility  of  performing  handoffs
locally by  performing quick  rerouting. Examples of  such mechanisms
are Local Anchoring [15], Regionalized Tunnels [12], and Proactive
Handoffs[13].
         NOTE:  Fast Handoff  in  the case  where  L2 permits  wireless
  access to  more than one access  point can be  done with simultaneous
  bindings. So, might not need LMAs for this case.

B) Authentication in the local Doamin.  The Mobile has to authenticate to
the Foreign Domain.

C) Other  potential advantages:

2. Solution

2.1 Network Model

The network model being considered is illustrated in Fig 1.

    +----------------------------------+                 +----------------+
    |                        Visited   |                 |                |
    |                        Network   |                 |                |
    |                                  |                 |                |
    |  +------+             +-------+  |                 |    +------+    |
    |  |      |             |       |  |                 |    |      |    |
    |  |  MN  |-------------|  LMA  |-------------------------|HA/CN |    |
    |  |      |             |       |  |                 |    |      |    |
    |  +------+             +-------+  |                 |    +------+    |
    |                                  |                 |                |
    |                                  |                 +----------------+

    |                       +-------+  |
    |                       |  LMA  |  |
    |                       |       |  |
    |                       |       |  |
    |                       +-------+  |
    +----------------------------------+

                         Fig 1: Network Model


An optional entity referred to as LMA has a link layer connectivity to
the Mobile. It is also possible to have an additional LMA without link
layer connectivity to the mobile (Similar to Anchor FA [15] or GFA [12] in
IPv4 or MAP in IPv6).  There are procesing differences between the LMA
if it has link layer connectivity  to the Mobile and the LMA that does
not.

2.2 Enhancements

The neighbor  discovey is proposed to  be enhanced to  send the LMACoA
(Care Of Address) in the router Advertisement message.  Binding Update
is proposed to be enhanced to be  able to send a Binding Update to the
LMA  which is then  relayed to  the destination.  This is  a one-phase
approach by which bindings at the  LMA and the HA/CN can be updated in
one phase. It is also possible  to have a Two-Phase Binding Update. In
this  approach  a Binding  Update  is first  sent  to  the LMA  (Local
Mobility Agent) and Once the Binding Update is accepted by the LMA the
Mobile can  send Biding  updates to HA  (and possibly  CNs). Two-Phase
Binding update may incur higher latency than the one-phase.

2.2.1 Neighbour Discovery Extension

    The LMAs send router advertisements with this following new option.
This is borrowed from Agent Advertisement of Mobile IPv4.


     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      |    Length     |        Sequence Number        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Binding      Lifetime      |                  reserved     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
    +                      LMA CoA                                  +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   More LMA Care of Addresses                  |
    +                                                               +


    Fields:

        Type            Message type. To be assigned.

        Length          8-bit unsigned  integer.  The  length in  bytes
                        of the option (including the type and length fields).

       Sequence Number

                The  count of Agent  Advertisement messages  sent since
                the agent  was initialized (Similar  to Sequence number
                in Mobile IPv4).

       LMA CoA  is the address of the  LMA that this mobile  can use as
CoA in its  Binding update. Currently all the LMA  CoA have link layer
connectivty to the Mobile.

TBW (To be Worked on) If there are multiple LMAs on the Link.

2.2.2 Binding Update and Binding Update Acknowledge Usage

In this proposal the Binding Updates are encapsulated Since AH and ESP
are used for Authentication in Mobile IP v6, the actual binding update
between the Mobile Node and  the HA/CN will be encapsulated in binding
update sent  to the LMA.  (Note: only one  binding update needs  to go
through this way,rest  of then can go  to the CNs with the  LMA CoA as
the CoA in the Binding Updte).


                             +----------------------------------//-----+
                             | Original |                              |
                             |          |   Original Packet Payload    |
                             | Header
                             | w BU DH  |                              |
                             +----------------------------------//-----+
                              < Binding Update  between MN and HA/CN  >
                                               |
                                               v
         <       Original Packet                 >
        
       +---------+ - - - - - +-------------------------//--------------+
       | IPv6    | IPv6      |                                         |
       |         | Extension | Original Packet with Binding Update     |
       | Header  | Headers   |                                         |
       +---------+ - - - - - +-------------------------//--------------+
        <   Binding Update with  the original binding update Tunneled >

            BU: Binding Update
            DH: Destination Header

NOTE: The  Original Binding  Update that is  encapsulated is  a entire
Binding Update  with all the  necessary extensions [5]. Similar  to the
Binding Update Binding Update Acknowledge can also be Tunneled.

   Using this  tunnenling mechanisim a static/dynamic  hierarchy can be
created as required [12][15].


3 Processing Considerations

3.1 Mobile Node

The Mobile Node behaves like a  regular IPv6 mobile IP node when using
the  CoA,ie., Thee Mobile  Node uses  the LMA  CoA as  the CoA  in the
Binding Update. The  Variation is that the CoA is  not a Colocated CoA
but LMA CoA.

The Mobile  Node learns of the  LMA CoA either by  listining to Router
Advertisements or performs Router Solicitation as specified in [].

The Mobile node Sends two Binding Updates one encapsulated in another.

Mobile Node  receives Packets from the  LMA with a  routing header and
Destination  set   to  LMA  CoA   (This  is  a  departure   from  IPv6
Specification).   (In  order to  stay within  the IPv6  specification
tunneling can  be performed.  This  adds an overhead of  an additional
IPv6 header Overhead.)


3.2 Local Mobility Agent

3.2.1 LMA with Link Layer connectivity

Flow with LMA with Link Layer Connectivity

Option 1:


     MN     Advertisement   LMA                     HA/CN
     |<--------------------- |                       |
     | Binding Update        |                       |
     |---------------------->|  Binding Update       |
     |                       |---------------------->|
     |                       |                       |
     |                       |                       |
     |                       |  Binding Ack          |
     |  Binding Ack          |<----------------------|
     |<----------------------|                       |


Option 2:


     MN     Advertisement   LMA                     HA/CN
     |<--------------------- |                       |
     | Binding Update        |                       |
     |---------------------->|  Binding Update       |
     |                       |---------------------->|
     |                       |                       |
     |  Binding Ack          |                       |
     |<----------------------|                       |
     |<----------------------------------------------|

Option 2 will result in lower  latency. In this option, if the Binding
Update Ack  for the encapsulated BU  is received, then  the MN assumes
that the  Binding Update Ack for the  outer BU has been  send but lost
(Can  we ignore  and  assume that  it has  be  received -  Is there  a
security Hole - Do we want to give this as an option in the BU).

If  the First Ack  (for BU  between MN  and LMA)  is received  but the
second Ack  (for BU between  MN and HA/LMA/CN)  is lost then  only the
second BU is sent.


The LMA will send periodic router advertisements as defined in Section
2.2.1 to facilitate neighbor discovery.   If the LMA receives a router
solication  message,   it  will  respond  by  sending   a  LMA  router
advertisement.

When the LMA  receives a Binding Update from a MN,  it checks that the
proper authentication  is present.   If the update  is valid,  the LMA
strips off the tunnel headers and forwards the internal Binding Update
packet to the HA.  It enters the binding update request in its pending
binding update table.

LMA relays the packet  to the
  mobile node.  If the LMA receives the packet
  sends it to the mobile much like a FA in Mobile IPv4
  Architecture.


3.2.2 LMA with out link Layer connectivity

Tunnels the  packet to  the registered CoA  in the Binding  Update. It
additionally  authenticates  the Binding  updates  and sends  tunneled
Binding  Updates/Acknowledgements. This  operation is  similar  to the
operation of  a HA  in IPv6  (The other alternative  is to  change the
Routing Header and  the Destination Header - Need  to Reassemble as IP
Sec assumes a certain  order of the headers).

3.3 Home Agent

Th Home Agent is a regular IPv6 Home Agent.

3.4 Correspondent Node

The Correspondent node also behaves like a regular IPv6 node.

4 How Existing Handoff Proposals for IPv4 apply to IPv6

   To Be Discussed Later

5. How Local Authentication can be performed in IPv6

    To Be Discussed Later

6. Synergies and differences between MAP [4] and this draft


The approach described herein does not require the MN to obtain a
co-located CoA (using either DHCP or Autoconfiguration).  The MN registers
back with the HA using the LMA CoA, and anchors with the LMA as it moves in
foreign domains.  Hence, the latency involved with the MN acquiring a
co-located CoA is avoided.

Since the Binding Update is forwarded to the HA/CN directly by the LMA,
the delay in the MN waiting for a Binding Acknowledgement from the LMA and then
registering back with the HA/CN using the LMA CoA is also avoided.

The reduction in latency will aid in the efficiency of fast handoffs.

6. Security Considerations

Security associations  as specified in [5]  as used to  protect all the
binding update and reply mesages.

7. IANA Considerations


8. References

   [1] C. Perkins.  IP Mobility Support.  Request for Comments
         (Proposed Standard) 2002, Internet Engineering Task Force,
         October 1996.

   [2] S. Deering.  ICMP Router Discovery Messages.  Request for
         Comments (Proposed Standard) 1256, Internet Engineering Task
         Force, September 1991.

   [3] E. Gustafsson, et. al.  Mobile IP Regional Tunnel Management.
       draft-ietf-mobileip-reg-tunnel-01.txt, August 1999.

   [4] H.  Soliman and K. El  Malki, Hierarchical Mobile  IPv6 and Fast
   Handoffs. draft-soliman-mobileip-hmipv6-00.txt, June 2000.

   [5] D. Johnson and C. Perkins, "Mobility Support in IPv6",
          draft-ietf-mobileip-ipv6-10.txt, February 2000.

     [6] Jim Bound and Charles Perkins.  Dynamic Host Configuration
         Protocol for IPv6 (DHCPv6), February 1999.  Work in progress.

     [7] Alex Conta and Stephen Deering.  Generic packet tunneling in
         IPv6 specification.  RFC 2473, December 1998.

     [8] Alex Conta and Stephen Deering.  Internet Control Message
         Protocol (ICMPv6) for the Internet Protocol version 6 (IPv6)
         specification.  RFC 2463, December 1998.

     [9] Stephen E. Deering and Robert M. Hinden.  Internet Protocol
         version 6 (IPv6) specification.  RFC 2460, December 1998.

    [10] Thomas Narten, Erik Nordmark, and William Allen Simpson.
         Neighbor Discovery for IP version 6 (IPv6).  RFC 2461, December
         1998.

    [11] Susan Thomson and Thomas Narten.  IPv6 stateless address
         autoconfiguration.  RFC 2462, December 1998.

    [12] Eva Gustafsson, et. al.  Mobile IP Regional Tunnel Management.
         draft-ietf-mobileip-reg-tunnel-01.txt, August 1999.

    [13] J. Kempf, P. Calhoun, and C. Pairla, Foreign Agent Assisted Hand-off,
         draft-calhoun-mobileip-proactive-fa-01.txt, June 2002

    [14] N.  Asokhan   et.   al,  AAA   for   IPv6  Network   Access,
         draft-perkins-aaav6-00.txt, March 2000.

    [15]  G. Dommety  and T.  Ye, "Local  and Indirect  Registration for
         Anchoring Handoffs",
         draft-dommety-mobileip-anchor-handoff-01.txt(work  in
         progress), July 2000.


Dommety                                                 [Page 4]

Internet Draft

Authors Information

    Gopal Dommety
    Cisco Systems, Inc.
    170 West Tasman Drive
    San Jose, CA 95134
    e-mail: gdommety@cisco.com





Notes:

1. Do we need other options of IPv4 adv

2. How does IPv6 MN IP address

3. Do we use constant Src address for IP

4. Route Processing

5. IPv4 tunnels

6. How does the IPv6 Binding update sent?


Appendix:

Three options of sending Binding Updates.

1. Sequential Bindings (Similar to MAP[4])

     MN     Advertisement   LMA                     HA/CN
     |<--------------------- |                       |
     | Binding Update        |                       |
     |---------------------->|
     |  Binding Ack          |
     |<----------------------|                       |

     |---------------------------------------------->|
     |<----------------------------------------------|

The Problem in this case is the Latency.

2. Relay Bindings


     MN     Advertisement   LMA                     HA/CN
     |<--------------------- |                       |
     | Binding Update        |                       |
     |---------------------->|  Binding Update       |
     |                       |---------------------->|
     |                       |                       |
     |                       |                       |
     |                       |  Binding Ack          |
     |  Binding Ack          |<----------------------|
     |<----------------------|                       |

     In this  case MN  sends a binding  update to  LMA and LMA  sends a
     Binding update to HA/CN on behalf  of MN. If the Binding Update is
     required to be Acknowledged, LMA waits  for the BU ack and once it
     receives  it  the  ACK  for   the  Original  BU  from  the  MN  is
     Acked. Security  might be  a problem in  this case, since  the LMA
     sends the Binding Update on the MN's behalf.

3. Encapsulated Binidngs


     MN     Advertisement   LMA                     HA/CN
     |<--------------------- |                       |
     | Binding Update        |                       |
     |---------------------->|  Binding Update       |
     |                       |---------------------->|
     |                       |                       |
     |                       |                       |
     |                       |                       |
     |  Binding Ack          |                       |
     |<----------------------|                       |
     |<----------------------------------------------|

In   this  case   MN  sends   a  BU   to  LMA   with  a   MN-HA/CN  BU
encapsulated. Once the  LMA authenticates the MN, the  LMA relays tthe
BU to HA.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Jul 24 12:21:02 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10337
	for ; Mon, 24 Jul 2000 12:21:02 -0400 (EDT)
Received: from standards (47.234.32.16:4046) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB80E97@standards.nortelnetworks.com>; Mon, 24 Jul 2000 12:09:15 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 21563 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jul 2000 12:09:15
          -0400
Received: from omega.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB80E96@standards.nortelnetworks.com>; Mon, 24 Jul 2000 12:09:15
          -0400
Received: from gdommety-laptop1.cisco.com (gdommety-dsl3.cisco.com
          [10.19.17.140]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8)
          with ESMTP id JAA26448 for ;
          Mon, 24 Jul 2000 09:20:04 -0700 (PDT)
X-Sender: gdommety@omega.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.20000724091958.00a7f3f0@omega.cisco.com>
Date:         Mon, 24 Jul 2000 09:24:42 -0700
Reply-To: Gopal Dommety 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: Gopal Dommety 
Subject:      [MOBILE-IP] FYI New ID: draft-dommety-mobileip-lma-ipv6-00.txt
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hello:

        We submitted a new ID (draft-dommety-mobileip-lma-ipv6-00.txt - I appended
this
in my previous email) and revision of
the Anchor Handoff ID ( draft-dommety-mobileip-anchor-handoff-01.txt).

Thanks
Gopal


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Jul 24 12:33: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 MAA14995
	for ; Mon, 24 Jul 2000 12:33:31 -0400 (EDT)
Received: from standards (47.234.32.16:4046) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB80ED0@standards.nortelnetworks.com>; Mon, 24 Jul 2000 12:21:58 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 21633 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jul 2000 12:21:57
          -0400
Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB80ECF@standards.nortelnetworks.com>; Mon, 24 Jul 2000 12:21:57
          -0400
Received: from esvir03nok.ntc.nokia.com (esvir03nok.ntc.nokia.com
          [131.228.10.152]) by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with
          ESMTP id e6OGWNR08680 for ;
          Mon, 24 Jul 2000 19:32:39 +0300 (EET DST)
Received: from daebh01nok.americas.nokia.com (unverified) by
          esvir03nok.ntc.nokia.com (Content Technologies SMTPRS 4.1.2) with
          ESMTP id  for
          ; Mon, 24 Jul 2000 19:32:13
          +0300
Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id <3W1R8FLH>;
          Mon, 24 Jul 2000 11:29:48 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E0EC@daeis07nok>
Date:         Mon, 24 Jul 2000 11:29:35 -0500
Reply-To: Basavaraj.Patil@NOKIA.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: Basavaraj Patil 
Subject:      [MOBILE-IP] WG Last Call - draft-ietf-mobileip-rfc2344-bis-02.txt
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

This is the Mobile IP Working group last call on
draft-ietf-mobileip-rfc2344-bis-02.txt before sending it on to IETF
Last call. This draft is recommended for Standards track.

If you have any comments on it, please send them to the authors or to
the Mobile IP WG mailing list BEFORE August 4th, 2000.

http://www.ietf.org/internet-drafts/draft-ietf-mobileip-rfc2344-bis-02.txt

-Basavaraj (For Basavaraj and Phil)


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Jul 24 16:59:13 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04889
	for ; Mon, 24 Jul 2000 16:59:13 -0400 (EDT)
Received: from standards (47.234.32.16:4832) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB80FA2@standards.nortelnetworks.com>; Mon, 24 Jul 2000 16:47:45 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 21913 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jul 2000 16:47:45
          -0400
Received: from ish7.ericsson.com.au (203.61.155.111:62942) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB80F9F@standards.nortelnetworks.com>; Mon, 24 Jul 2000
          16:47: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 GAA17920; Tue,
          25 Jul 2000 06:57:00 +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 GAA10486; Tue, 25
          Jul 2000 06:58:17 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service
          (5.5.2650.21) id <3FW952C8>; Tue, 25 Jul 2000 06:58:11 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFF5B1.DF526A00"
Message-ID:  <4B6BC00CD15FD2119E5F0008C7A419A5089EB130@eaubrnt018.epa.ericsson.se>
Date:         Tue, 25 Jul 2000 06:58:09 +1000
Reply-To: "Hesham Soliman (EPA)" 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: "Hesham Soliman (EPA)" 
Subject:      Re: [MOBILE-IP] draft-malinen-mobileip-regreg6-00.txt
X-To:         Charlie Perkins 
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_01BFF5B1.DF526A00
Content-Type: text/plain;
        charset="iso-8859-1"

Hello Charlie,

I actually have a number of comments on the draft. I would say
it's attempting to solve a similar problem to what we did.
However, I disagree that it solves it the same way.

I will bring up the comments in a separate mail.


> This same idea can also be found in the I-D by Karim.
> Can you provide some clarification on this?

Similar ideas have been popping up with regularity for years.
Our goal is to find some solution that is not encumbered with
intellectual property, so it is perfectly natural that we would
work with ideas that have been around for years.  Isn't this
a good thing?

=> I really don't think that will be a problem. Our goal is to
provide the best technical solution. I am not a lawyer
and I can't make official statements on behalf of my company.
However, I can tell you that we (the authors) are not aware of
any IPR on this draft today. We put this statement in good faith
because we thought that there might be one later. So there is
clearly no hidden agendas or encumberences intended.

If there happens to be an IPR, I still don't believe there will
be a problem, everything will be in full conformance with IETF
rules on IPR's. This is not the first time this scenario occurs,
and a recent example has occured in the ROHC WG where no problems
had occurred.

I hope that when we discuss the different proposals we really
base our choices on the BEST technical solution.
If, after choosing this solution we find that there are
"non-technical" issues, I do not doubt that they will be solved quite
smoothly.

So far I haven't received any comments on our proposal, but
I'll be happy to discuss it with the memebers of the WG.

Hesham

------_=_NextPart_001_01BFF5B1.DF526A00
Content-Type: text/html;
        charset="iso-8859-1"






RE: [MOBILE-IP] draft-malinen-mobileip-regreg6-00.txt




Hello Charlie,




I actually have a number of comments on the draft. I would say

it's attempting to solve a similar problem to what we did.

However, I disagree that it solves it the same way.




I will bring up the comments in a separate mail.

 




> This same idea can also be found in the I-D by Karim.

> Can you provide some clarification on this?




Similar ideas have been popping up with regularity for years.

Our goal is to find some solution that is not encumbered with

intellectual property, so it is perfectly natural that we would

work with ideas that have been around for years.  Isn't this

a good thing?




=> I really don't think that will be a problem. Our goal is to 

provide the best technical solution. I am not a lawyer

and I can't make official statements on behalf of my company.

However, I can tell you that we (the authors) are not aware of

any IPR on this draft today. We put this statement in good faith

because we thought that there might be one later. So there is 

clearly no hidden agendas or encumberences intended.




If there happens to be an IPR, I still don't believe there will 

be a problem, everything will be in full conformance with IETF 

rules on IPR's. This is not the first time this scenario occurs,

and a recent example has occured in the ROHC WG where no problems

had occurred. 




I hope that when we discuss the different proposals we really 

base our choices on the BEST technical solution. 

If, after choosing this solution we find that there are 

"non-technical" issues, I do not doubt that they will be solved quite 

smoothly.




So far I haven't received any comments on our proposal, but 

I'll be happy to discuss it with the memebers of the WG.




Hesham





------_=_NextPart_001_01BFF5B1.DF526A00--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Jul 24 18:34:59 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 SAA04923
	for ; Mon, 24 Jul 2000 18:34:59 -0400 (EDT)
Received: from standards (47.234.32.16:3298) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8101D@standards.nortelnetworks.com>; Mon, 24 Jul 2000 18:23:18 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 22079 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jul 2000 18:23:18
          -0400
Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1b) with SMTP id <0.FFB8101C@standards.nortelnetworks.com>;
          Mon, 24 Jul 2000 18:23:17 -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 QAA18242; Mon, 24 Jul 2000 16:34:02
          -0600 (MDT)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by
          engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id
          PAA24530; Mon, 24 Jul 2000 15:34:01 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (euroapp.Holland.Sun.COM [129.159.197.58]) by
          nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id PAA04203; Mon, 24
          Jul 2000 15:33:41 -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:  <200007242233.PAA04203@nasnfs.eng.sun.com>
Date:         Mon, 24 Jul 2000 14:34:37 -0700
Reply-To: James.Kempf@eng.sun.com
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: James Kempf 
Subject:      Re: [MOBILE-IP] Fast Handoff Issues
X-To:         Pete McCann 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi Pete,

Actually, I was talking about interdomain, single technology
hard (break before make) handoff.

The case is the following. Suppose in today's network you have
two RANs (wCDMA, cdma2000, EDGE) whose only connection is through an MSC.
Now, replace the MSC with an IP core network. The only way you can do hard
handoff is if there is some RAN specific information
that goes through the IP core. Otherwise, the old RAN can't
learn the radio quality seen by the new, and the new can't learn
the channel parameters.

The IS-41 HandoffMeasurementRequest and FacDir messages accomplish
this in today's core networks. For interdomain hard handoff to
work in all IP networks, there would need to be some kind of
replacement.

I agree that, for the intertechnology handoff to work, the mobile
node may need to get involved.

                jak

>Hi, James,
>
>James Kempf  (JK) writes:
>
>>> I know some of the considerations I've raised are really link-specific
>>> issues, but their impact on the fast handoff mechanism should be
>>> considered.  It may turn out that fast handoff is best addressed in
>>> the appropriate link-layer groups (3GPPs, IEEE) and not the IETF.
>
>JK> Well, there's an issue you've not included:
>
>JK> - There needs to be some radio-link independent way to transfer radio
>JK> quality measurements and radio link context information between the two FAs
>JK> at L3.
>
>I'm not so sure that there is a need for this.  Just for information,
>here's how it works in CDMA today: the BSC, based on pre-provisioned
>information, tells the MN to watch the pilot strengths of a number of
>neighbor BSCs in a "candidate set."  When some of these measurements
>exceed a threshold for a given duration, the MN reports that fact to
>the BSC.  The BSC then decides whether to initiate a hard or soft
>handoff.  Soft handoff is uninteresting here because it does not
>involve a change in the MN's L3 point of attachment.  In hard handoff,
>a message is sent to the candidate BSC asking if it has the radio
>resources (and other resources) necessary to accept the handoff.  If
>so, the handoff is requested and the MN is told on which channels
>to re-tune.
>
>To me, this process only makes sense if both BSCs are of the same
>technology.  It is theoretically possible for BSCs of different
>technologies to run the message flow above, but at each step, the
>information must be translated from one system's representation to
>another, and the measurements might even be so totally different in
>shape that this is not possible.
>
>If you do have two different technologies, such as 802.11 and
>cdma2000, then it should be up to the MN to decide when it wants to
>hand off.  I do not think we can expect the cdma2000 BSC to get
>involved in asking for power measurements from WaveLAN.  The MN
>supports both technologies (and there is probably a different pricing
>model involved for the two services) so it is in the unique best
>position to make a decision.  Also, a fast handoff can be completed
>simply by bringing up the WaveLAN before shutting down the cdma2000
>link - both interfaces are physically present on the MN so this should
>be doable.  No interaction between the two networks is required.
>
>JK> As I mentioned in my response to Karim, the mobile IP working
>JK> group may not be the place to work this out if the taboo on L2 is
>JK> so strong, but it *will* have to be worked out somewhere,
>JK> regardless of the ultimate fast handoff scheme we adopt, if mobile
>JK> IP interdomain handoff is to work with CDMA and TDMA.
>
>I guess I was really talking about inter-domain, single technology
>handoffs, because it seems to me that the inter-domain, different
>technology handoff problem has a simple solution (let the MN decide).
>So maybe "proactive FA" only makes sense in the case of homogeneous
>radio transmission technology, but I think it can be of great benefit
>there, assuming we can solve the "PPP re-establishment" problem.  The
>way I think of the proactive FA solution is that there is always an
>unshown flow of information between the BSCs attached to each leaf FA
>to exchange information and decide whether the handoff should take
>place.  It seems to me this flow of information should be left
>unspoken in the IETF and defined elsewhere (i.e., in the 3GPPs).
>
>-Pete
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Jul 24 19: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 TAA16500
	for ; Mon, 24 Jul 2000 19:08:09 -0400 (EDT)
Received: from standards (47.234.32.16:1716) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8104F@standards.nortelnetworks.com>; Mon, 24 Jul 2000 18:56:38 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 22146 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jul 2000 18:56:38
          -0400
Received: from motgate2.mot.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB8104E@standards.nortelnetworks.com>; Mon, 24 Jul 2000 18:46:38
          -0400
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by
          motgate2.mot.com (motgate2 2.1) with ESMTP id PAA06415 for
          ; Mon, 24 Jul 2000 15:57:29
          -0700 (MST)]
Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100])
          by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id PAA27132 for
          ; Mon, 24 Jul 2000 15:57:29
          -0700 (MST)]
Received: from email.mot.com (app3.cig.mot.com [160.15.1.24]) by
          il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id PFJRQZH7; Mon, 24 Jul 2000 17:57:28
          -0500
X-Mailer: Mozilla 4.51 [en] (X11; U; 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:  <397CC9D9.9AA184B7@email.mot.com>
Date:         Mon, 24 Jul 2000 17:57:29 -0500
Reply-To: "Sebastian T. Thalanany" 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: "Sebastian T. Thalanany" 
Subject:      [MOBILE-IP] Quick handoff draft
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

A New Internet-Draft is available from the on-line Internet-Drafts
directories.


        Title           : Quick handoff scheme in a 3G Wireless Network
        Author(s)       : S. Thalanany, A. Singh
        Filename        : draft-thalanany-mobileip-qh-00.txt
        Pages           : 8
        Date            : 19-Jul-00

This draft proposes a scheme to for a quick handoff of a Mobile
Station (MS) from a source Packet Data Serving Node (PDSN) to a
target PDSN. This draft describes a wireless link assisted quick
handoff scheme for a cdma2000 based Radio Network Node(RNN).
The proposed scheme may be generalized for application to any
wireless access system to support a low latency handoff.

The target PDSN acquires the IP address of the source PDSN via the
signaling messages necessary to support a wireless link hard handoff.
This information is used by the target PDSN to acquire packets, that
were destined for the mobile station, from the source PDSN, while the
mobile station changed it's point of attachment from the source to the
target PDSN.

This draft proposes extensions to the signaling messages in the RNN, and
a
new interface between a source and a target PDSN. The objective of this
version of the draft is to propose the following concepts:

    1. A wireless infrastructure triggered mechanism to provide the
source PDSN IP
        address to the target PDSN.

    2. A new interface between a source PDSN and a target PDSN so that
the target
        PDSN can acquire and deliver packets to the mobile station.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-thalanany-mobileip-qh-00.txt

Regards,

Sebastian Thalanany


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Jul 24 19:20: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 TAA22695
	for ; Mon, 24 Jul 2000 19:20:15 -0400 (EDT)
Received: from standards (47.234.32.16:1716) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB81081@standards.nortelnetworks.com>; Mon, 24 Jul 2000 19:08:53 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 22212 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jul 2000 19:08:53
          -0400
Received: from qhars002.nortel.com (47.101.112.102:47244) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB81080@standards.nortelnetworks.com>; Mon, 24 Jul 2000
          19:08:53 -0400
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by
          qhars002.nortel.com; Tue, 25 Jul 2000 00:14:19 +0100
Received: from zcard00n.ca.nortel.com (actually zcard00n) by
          ertpg14e1.nortelnetworks.com; Mon, 24 Jul 2000 19:10:44 -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.2652.39) id PRZ1QW19; Mon, 24 Jul 2000 19:08:49
          -0400
Received: from nortelnetworks.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 N2LHLP7V; Mon, 24 Jul 2000 19:08:48
          -0400
X-Mailer: Mozilla 4.6C-CCK-MCD [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: 
            <00bc01bff1e8$95c0a400$c72ebca8@ce.cnu.ac.kr>
Content-Type: multipart/alternative;
              boundary="------------39412F8CCC4F03B758AF860B"
Message-ID:  <397CCCF2.3B708B31@nortelnetworks.com>
Date:         Mon, 24 Jul 2000 19:10:42 -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] Questions about Route Optimization in Mobile IPv4
X-To:         "Park, Hyun Seo" 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

--------------39412F8CCC4F03B758AF860B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Park, Hyun Seo" wrote:

>      Thanks for your comments, Charlie and Muhammad ....My
>      comments are included .....          Hello,
>
>                I'll try to make some answers, but of course the
>      questions that
>                you ask do not have any absolute answers.
>
>                > 1) How much 'cost' does "Triangle Routing"
>      impose on packets from
>                >     CH to MN in basic Mobile IPv4 ?
>
>           This depends on the placement of the network entities,
>           and the traffic
>           models employed.  There is no one answer.
>
>           >     Is there any Modeling, Demonstration or
>           Simulation about it ?
>
>           There have been quite a few attempts to analyze parts
>           of the situation.
>           Off the top of my head, I can remember work by Stuart
>           Jacobs for
>           authentication, and by Ruixi Yuan for an idea about
>           "friends" of a
>           mobile node.  There are quite a few other works.
>
>           [Park] How can I find it ? If you know, please let me
>           know .
>
>           Or you can send e-mail addresses to contact them, if
>           you know.
>
>                > 2) In Route Optimization draft, CH maintains
>      Binding Cache.
>                >     How much 'overhead' on it ?
>
>           Memory is the main overhead, along with additional
>           search time.
>           These costs are typically considered to be
>           insignificant compared
>           to the network messaging costs.
>
>           [MJ]  It may not be in the overhead category, but it
>           requires changes
>           in host's IP stack implementation.
>
>           [Park] I agree with you. Thanks
>
>
>           >     And, How about 'tradeoff' btw. this 'overhead'
>           and above 'cost' ?
>
>           Thus, the tradeoff would usually be for more processing
>           complexity
>           and less messaging complexity (i.e., maintaining more
>           "state").
>
>           > 3) In Route Optimization draft,
>           >     If above 'cost' imposed by "Triangle Routing" is
>           very high and
>
>           O.K.
>
>           >     CH can't understand Route Optimization protocol,
>           >     CH doesn't acknowledge "Binding Update" .....
>
>           O.K.  We agree so far...
>
>           >     How about my humble opinion ?
>           >     My thoughts .....
>           >     If HA doesn't "Binding Acknowledge" from CH for
>           some time,
>           >     it deduces the CH can't understand Route
>           Optimization protocol ...
>           >     Then, it tries to send "Binding Update" to
>           Routers 1~3 hops apart from
>           >     the CH ....
>           >     So this activity will be able to solve "Triangle
>           Routing" problem indirectly ...
>

Another way is to perhaps have the Binding messages
processed/intercepted by access routers or firewalls instead, making the
route optim transparent to CN/CHs.

If the Registration Request message is also intercepted, within a
foreign network domain, then there is opportunity to reduce handoff
latency as well.  What do you think?

cheers,
cyl

--------------39412F8CCC4F03B758AF860B
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit




"Park, Hyun Seo" wrote:




Thanks
for your comments, Charlie and Muhammad ....My comments are included .....         
Hello,

         
I'll try to make some answers, but of course the questions that

         
you ask do not have any absolute answers.

         
> 1) How much 'cost' does "Triangle Routing" impose on packets from

         
>     CH to MN in basic Mobile IPv4 ?

    This depends on the placement of the
network entities, and the traffic

    models employed.  There is no
one answer.

    >     Is there
any Modeling, Demonstration or Simulation about it ?

    There have been quite a few attempts
to analyze parts of the situation.

    Off the top of my head, I can remember
work by Stuart Jacobs for

    authentication, and by Ruixi Yuan
for an idea about "friends" of a

    mobile node.  There are quite
a few other works.

    [Park] How can
I find it ? If you know, please let me know .

    Or you can send
e-mail addresses to contact them, if you know.

         
> 2) In Route Optimization draft, CH maintains Binding Cache.

         
>     How much 'overhead' on it ?

    Memory is the main overhead, along
with additional search time.

    These costs are typically considered
to be insignificant compared

    to the network messaging costs.

    [MJ] 
It may not be in the overhead category, but it requires changes

    in host's IP
stack implementation.

    [Park] I agree
with you. Thanks











     

    >     And, How
about 'tradeoff' btw. this 'overhead' and above 'cost' ?

    Thus, the tradeoff would usually be
for more processing complexity

    and less messaging complexity (i.e.,
maintaining more "state").

    > 3) In Route Optimization draft,

    >     If above
'cost' imposed by "Triangle Routing" is very high and

    O.K.

    >     CH can't
understand Route Optimization protocol,

    >     CH doesn't
acknowledge "Binding Update" .....

    O.K.  We agree so far...

    >     How about
my humble opinion ?

    >     My thoughts
.....

    >     If HA doesn't
"Binding Acknowledge" from CH for some time,

    >     it deduces
the CH can't understand Route Optimization protocol ...

    >     Then, it
tries to send "Binding Update" to Routers 1~3 hops apart from

    >     the CH ....

    >     So this
activity will be able to solve "Triangle Routing" problem indirectly ...








Another way is to perhaps have the Binding messages processed/intercepted
by access routers or firewalls instead, making the route optim transparent
to CN/CHs.

If the Registration Request message is also intercepted, within a foreign
network domain, then there is opportunity to reduce handoff latency as
well.  What do you think?

cheers,

cyl



--------------39412F8CCC4F03B758AF860B--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Jul 25 01:20:56 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17263
	for ; Tue, 25 Jul 2000 01:20:55 -0400 (EDT)
Received: from standards (47.234.32.16:2336) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB811E0@standards.nortelnetworks.com>; Tue, 25 Jul 2000 1:09:29 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 22676 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jul 2000 01:09:29
          -0400
Received: from oo.net (rochester-ip-4-29.dynamic.ziplink.net) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB811DF@standards.nortelnetworks.com>; Tue, 25 Jul 2000
          0:59:28 -0400
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=200007242257="
X-Mailer: 25F13208.501A24CD.d5cfb5158bfca2e6242a469eb866cc91
Message-ID:  
Date:         Tue, 25 Jul 2000 01:09:29 -0400
Reply-To: pmilea@OO.NET
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: pmilea@OO.NET
Organization: Wing N' A Prayer Excess Property
Subject:      [MOBILE-IP] New Nortel Double Bay OC-48's for sale !
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

--=200007242257=
Content-Type: text/plain;charset=US-ASCII

If this email has reached you by error please forgive the intrusion.
Simply 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,

All this Nortel equipment is new in the box. Let me know very quickly if you're
interested as we expect these to go quickly. Price  $150,000.00 each
 34)available, Complete Double Bay OC-48's (NEW IN ORIGINAL BOXES)
 (96 DS3's )

4 Shelf Kit
 Cards in each as follows:
 1) NTZH50HF
 1) NTFF07AA
 97) NT7E14AA Rel 09
 4) NT7E27EA Rel 06
 16) NT8E17AA Rel 04
 2) NT8E18AC Rel 03
 2) NT7E20GD Rel 02
 2) NT7E19AA Rel 09
 4) NT8E15AA Rel 04
 4) NT8E01PC Rel 25
 4) NT8E02DE Rel 01
 2) NT7E23AA Rel 21 > 4) NT8E06AB Rel 07
 24) NT7E08BA Rel 06
 9) NT7E08BA Rel 07
 1) NTN459ST

Paul J. Milea jr.
Wing N' A Prayer Excess Property
3504 James Street
Syracuse,.New York ,USA 13206
ph 315 374 1560
fax 315 463 4337
--=200007242257=--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Jul 25 02:28: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 CAA23999
	for ; Tue, 25 Jul 2000 02:28:01 -0400 (EDT)
Received: from standards (47.234.32.16:4683) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8122F@standards.nortelnetworks.com>; Tue, 25 Jul 2000 2:16:16 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 22773 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jul 2000 02:16:15
          -0400
Received: from mail0.u-aizu.ac.jp by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB8122C@standards.nortelnetworks.com>; Tue, 25 Jul 2000 2:16:10
          -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
          PAA22042; Tue, 25 Jul 2000 15:26:51 +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 PAA14182; Tue, 25 Jul
          2000 15:26:51 +0900 (JST)
X-Mailer: Mozilla 4.7 [en_jp] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <397AEA48.B76B9CF@u-aizu.ac.jp> <397BD577.630F13F0@iprg.nokia.com>
            <397C6167.94728DC4@inrialpes.fr>
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Message-ID:  <397D332A.38C9369B@u-aizu.ac.jp>
Date:         Tue, 25 Jul 2000 15:26:51 +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] draft-malinen-mobileip-regreg6-00.txt
X-To:         Claude.Castelluccia@INRIALPES.FR
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi Claude,

>Beside that autoconfiguration solves a lot of problem. In your scheme
when a MH gets a Regional CoA from the
>router adv. ,this address has to be removed from the advertised list
otherwise you will have address collision.
>This implies to have a protocol between the MGA and the access routers
and results in higher  registration and
>handoff delays.
I think the same problem exists in mipv4. It is OK, as long as MGA and
FA associate the addresses with the correct and unique
home address.

A comment on your terminology, please change MS it is a widely used
acronym for Mobile Station in cellular networks
(like BS for Base Station, MS for Mobile Station). Also change MH to MN.

>In HMIP, since the GCoA is build by concatening the MS prefix and
EUI64, address collision is very unlikely
>(but the MS verifies the unicity of the address by performing a DaD on
its link).
What if MN moves to GMA link?

Regards,

--
Behcet


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Jul 25 05:03: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 FAA02744
	for ; Tue, 25 Jul 2000 05:03:43 -0400 (EDT)
Received: from standards (47.234.32.16:2200) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8128C@standards.nortelnetworks.com>; Tue, 25 Jul 2000 4:51:48 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 22892 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jul 2000 04:51:48
          -0400
Received: from ebene.inrialpes.fr by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB8128B@standards.nortelnetworks.com>; Tue, 25 Jul 2000 4:51:47
          -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 LAA06547; Tue, 25 Jul
          2000 11:02:36 +0200 (MET DST)
Received: from inrialpes.fr (localhost [127.0.0.1]) by iseran.inrialpes.fr
          (8.8.7/8.8.5) with ESMTP id LAA19319; Tue, 25 Jul 2000 11:02:36 +0200
          (MET DST)
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <397AEA48.B76B9CF@u-aizu.ac.jp> <397BD577.630F13F0@iprg.nokia.com>
            <397C6167.94728DC4@inrialpes.fr> <397D332A.38C9369B@u-aizu.ac.jp>
Content-Type: multipart/alternative;
              boundary="------------AA892574C2A15C66001BF2AC"
Message-ID:  <397D57AB.9372A9C1@inrialpes.fr>
Date:         Tue, 25 Jul 2000 11:02:36 +0200
Reply-To: Claude.Castelluccia@INRIALPES.FR
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: Claude Castelluccia 
Subject:      Re: [MOBILE-IP] draft-malinen-mobileip-regreg6-00.txt
X-To:         sarikaya@U-AIZU.AC.JP
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

--------------AA892574C2A15C66001BF2AC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Behcet and thanks for your reply.

Behcet Sarikaya wrote:

> Hi Claude,
>
> >Beside that autoconfiguration solves a lot of problem. In your scheme
> when a MH gets a Regional CoA from the
> >router adv. ,this address has to be removed from the advertised list
> otherwise you will have address collision.
> >This implies to have a protocol between the MGA and the access routers
> and results in higher  registration and
> >handoff delays.
> I think the same problem exists in mipv4.

I don't think so. In the regional regist. draft for IPv4, all MNs will use
the  same GCoA that is
in fact the address of the GFA.

In IPv6 (or at least in our proposal), each MN has a different and unique
GCoA (Global CoA).
All these GCoA however belong to the MGA subnet. As a result, since the
GCoA are
different than the MGA address, the MGA can be changed dynamically and
transparently to the HA and CNs
(the MN advertise their GCoA, not the GFA address...). We argue this is
more flexible and robust (for ex.
MGA can be replaced transparently if it crashes., additional MGAs can be
deployed for scalability purpose...)...


>
> A comment on your terminology, please change MS it is a widely used
> acronym for Mobile Station in cellular networks
> (like BS for Base Station, MS for Mobile Station). Also change MH to MN.
>

thanks. I'll try to find a better  terminology.

>
> >In HMIP, since the GCoA is build by concatening the MS prefix and
> EUI64, address collision is very unlikely
> >(but the MS verifies the unicity of the address by performing a DaD on
> its link).
> What if MN moves to GMA link?
>

 Very good question. There are 2 actually 2 answers:
1- the simplest solution is to prohibit MNs on the GMA link  ...
2-  if MNs are allowed on the GMA link they must then use regular MIPv6 on
this link (we of course allow that).

BTW  the Mobility Network in our a draft is just a "concept" to define a
separate address space for the MNs,
it does not  actually have to be implemented as a LAN.

regards,

Claude.


--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/



--------------AA892574C2A15C66001BF2AC
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Hi Behcet and thanks for your reply.

Behcet Sarikaya wrote:

Hi Claude,

>Beside that autoconfiguration solves a lot of problem. In your scheme

when a MH gets a Regional CoA from the

>router adv. ,this address has to be removed from the advertised list

otherwise you will have address collision.

>This implies to have a protocol between the MGA and the access routers

and results in higher  registration and

>handoff delays.

I think the same problem exists in mipv4.

I don't think so. In the regional regist. draft for IPv4, all MNs will
use the  same GCoA that is

in fact the address of the GFA.

In IPv6 (or at least in our proposal), each MN has a different and unique
GCoA (Global CoA).

All these GCoA however belong to the MGA subnet. As a result,
since the GCoA are

different than the MGA address, the MGA can be changed dynamically
and transparently to the HA and CNs

(the MN advertise their GCoA, not the GFA address...). We argue
this is more flexible and robust (for ex.

MGA can be replaced transparently if it crashes., additional MGAs
can be deployed for scalability purpose...)...  

 

 

A comment on your terminology, please change MS it is a widely used

acronym for Mobile Station in cellular networks

(like BS for Base Station, MS for Mobile Station). Also change MH to
MN.

 

thanks. I'll try to find a better  terminology.

 

>In HMIP, since the GCoA is build by concatening the MS prefix and

EUI64, address collision is very unlikely

>(but the MS verifies the unicity of the address by performing a DaD
on

its link).

What if MN moves to GMA link?

 

 Very good question. There are 2 actually 2 answers:

1- the simplest solution is to prohibit MNs on the GMA link  ...

2-  if MNs are allowed on the GMA link they must then use regular
MIPv6 on this link (we of course allow that).

BTW  the Mobility Network in our a draft is just a "concept" to
define a separate address space for the MNs,

it does not  actually have to be implemented as a LAN.

regards,

Claude.

 

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

 

--------------AA892574C2A15C66001BF2AC--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Jul 25 06:43:37 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26217
	for ; Tue, 25 Jul 2000 06:43:37 -0400 (EDT)
Received: from standards (47.234.32.16:4972) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB812CB@standards.nortelnetworks.com>; Tue, 25 Jul 2000 6:32:15 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 22976 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jul 2000 06:32:15
          -0400
Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFB812C8@standards.nortelnetworks.com>; Tue, 25 Jul 2000 6:22:15
          -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org
          (8.9.1a/8.9.1a) with ESMTP id GAA22342; Tue, 25 Jul 2000 06:33:06
          -0400 (EDT)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Message-ID:  <200007251033.GAA22342@ietf.org>
Date:         Tue, 25 Jul 2000 06:33:05 -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-regkey-03.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           : Registration Keys for Route Optimization
        Author(s)       : C. Perkins, D. Johnson, N. Asokan
        Filename        : draft-ietf-mobileip-regkey-03.txt
        Pages           : 29
        Date            : 24-Jul-00

Route optimization defines extensions to Mobile IP Registration
Requests that allow datagrams in flight when a mobile node moves, and
datagrams sent based on an out-of-date cached binding, to be forwarded
directly to the mobile node's new binding.  These extensions for smooth
handoff require a registration key to be established between the mobile
node and foreign agent.  This document defines additional extensions to
the registration requests to allow for the establishment of single-use
registration keys between a mobile node and foreign agent.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-regkey-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-mobileip-regkey-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-mobileip-regkey-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.

--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:     <20000724141736.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mobileip-regkey-03.txt

--OtherAccess
Content-Type: Message/External-body;
        name="draft-ietf-mobileip-regkey-03.txt";
        site="ftp.ietf.org";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <20000724141736.I-D@ietf.org>

--OtherAccess--

--NextPart--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Jul 25 07:29:30 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08778
	for ; Tue, 25 Jul 2000 07:29:30 -0400 (EDT)
Received: from standards (47.234.32.16:4972) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB81326@standards.nortelnetworks.com>; Tue, 25 Jul 2000 7:18:11 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 23102 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jul 2000 07:18:11
          -0400
Received: from gandalf.axion.bt.co.uk by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFB81325@standards.nortelnetworks.com>; Tue, 25 Jul 2000 7:18:10
          -0400
Received: from cbtlipnt01.btlabs.bt.co.uk by gandalf (local) with ESMTP; Tue,
          25 Jul 2000 12:27:48 +0100
Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service
          (5.5.2651.88) id <3GLQ5M5Z>; Tue, 25 Jul 2000 12:27:47 +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, 25 Jul 2000 12:27:31 +0100
Reply-To: alan.w.oneill@BT.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: "Alan O'Neill" 
Subject:      [MOBILE-IP] Drafts on MIP:EMA co-existence.
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hi Folks,

I enclose below details of a new draft which discusses our view of the
relationship of MIP to Edge Mobility Architecture which I am sure should
provoke some discussion, along with links to the updated EMA draft v02. The
former specifically includes a description of reverse hand-over, as well as
forward hand-over under control of either MN via the old link, or the
network, which are relevant to the hand-over discussions... Lots of
similarities with other work which I will summarise in separate mail.

The EMA-MIP draft unfortunately has a couple of bugs to ignore which crept
though in the rush to meet the deadline. These are that the AAA Data Options
(for transfer of policy / AAA parameters from old to new access routers
(FA's/CoRs) should be decoupled from the Binding Update and EMA Hand-over
Options (see draft-ietf-koodli-smoothv6-00 for related work), and the
problematic use of Home Address = CoA (for extending scope of the concept of
home from link to home EMA domain) which should be replaced by simply using
the Home address. We will send out an updated draft covering these in more
detail after the IETF.


Setting the hand-over discussion aside for now, in terms of follow-up
activity I'm very keen to see if the other micro-mobility folks would be
willing to jointly specify a common MIP:micro-mobility framework draft
covering signalling, address allocation, paging, MIP co-existence to try to
get some badly needed convergence for OBAST and the MIP wg. I believe the
aims should be to isolate the MN from the specific micro-mobility protocol
selected by the network operator (save specific option data), to support
incremental and partial deployment of micromobility, and ensure MIP and
micro-mobility can work seamlessly independent of the status of MN or
visited domain ?

In addition, I think we need to find the best way to support the general
need I think for the new access router to undertake hand-over processing for
MIP:micro-mobility in conjunction with the BU which is not addressed to the
new access router but the tunnel endpoint. Both MIP:EMA and
draft-ietf-koodli-smoothv6-00 address this in different ways.

Thanks,  Alan.

---------------------------------------------------------------
 New Internet-Draft is available from the on-line Internet-Drafts
directories.


        Title           : EMA Enhanced Mobile IPv6/IPv4
        Author(s)       : A. O'Neill, G. Tsirtsis, S. Corson
        Filename        : draft-oneill-ema-mip-00.txt
        Pages           : 42
        Date            : 18-Jul-00

It is well recognised by all micro and macro-mobility routing
protocols that Mobile IP (MIP) is likely to be used to support
inter-domain mobility. It is also widely accepted that Mobile IP
could be used as the basis for signalling between the mobile and the
micro-mobility domains for simplicity of the mobile terminal and
interoperability purposes. The Edge Mobility Architecture (EMA)
defines a generic IP hand-over model which operates in conjunction
with a Mobility Enhanced Routing (MER) protocol to provide large-
scale, intra-domain, IP address mobility. The aim of this document
is to describe the minimum MIP signalling requirements for EMA:MER,
and to propose additional changes necessary to [MIPv6] and [MIPv4]
for them to support EMA:MER. The document deals with mobiles moving
inside and between EMA:MER domains as well as coming and going
from/to non-EMA:MER domains, demonstrating EMA/MIP interoperability
and inter-domain hand-overs. The document also demonstrates the
benefits a mobile and an operator will see when a mobile host is
within an EMA domain.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-oneill-ema-mip-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
        "get draft-oneill-ema-mip-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
        mailserv@ietf.org.
In the body type:
        "FILE /internet-drafts/draft-oneill-ema-mip-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.

draft-oneill-ema-mip-00.txt

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


A New Internet-Draft is available from the on-line Internet-Drafts
directories.


        Title           : Edge Mobility Architecture
        Author(s)       : A. O'Neill, G. Tsirtsis, S. Corson
        Filename        : draft-oneill-ema-02.txt
        Pages           : 32
        Date            : 19-Jul-00

This draft outlines a system  for domain-based routing and
addressing support in handling edge mobility such as encountered in
cellular systems and Internet roaming.  The system includes novel
features for IP session, address and localised host redirect route
management which promise significant scaling benefits compared to
other micro-mobility solutions. In addition, the system is closely
integrated with the Mobile IP architecture for both signalling and
data forwarding, so that a rich set of capabilities and Internet
Services are possible, and incremental deployment of EMA is possible
within and between AS's. The draft also suggests a specific protocol
based on TORA for the implementation of such an architecture. It
advocates the creation of a specific IETF working group to address
an overall architecture for edge mobility routing, specific
extensions to existing routing protocols to accomplish that
architecture, and extensions to existing Internet technologies such
as Mobile IP to support this architecture.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-oneill-ema-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
        "get draft-oneill-ema-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
        mailserv@ietf.org.
In the body type:
        "FILE /internet-drafts/draft-oneill-ema-02.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.

draft-oneill-ema-02.txt


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Jul 25 08:24: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 IAA24302
	for ; Tue, 25 Jul 2000 08:24:00 -0400 (EDT)
Received: from standards (47.234.32.16:1609) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB81370@standards.nortelnetworks.com>; Tue, 25 Jul 2000 8:12:37 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 23200 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jul 2000 08:12:37
          -0400
Received: from ebene.inrialpes.fr by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB8136F@standards.nortelnetworks.com>; Tue, 25 Jul 2000 8:12:37
          -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 OAA10463; Tue, 25 Jul
          2000 14:23:23 +0200 (MET DST)
Received: from inrialpes.fr (localhost [127.0.0.1]) by iseran.inrialpes.fr
          (8.8.7/8.8.5) with ESMTP id OAA20356; Tue, 25 Jul 2000 14:23:23 +0200
          (MET DST)
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: 
Content-Type: multipart/alternative;
              boundary="------------822419EAE0121696C1F159F4"
Message-ID:  <397D86BA.FAC4BDA5@inrialpes.fr>
Date:         Tue, 25 Jul 2000 14:23:22 +0200
Reply-To: Claude.Castelluccia@INRIALPES.FR
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: Claude Castelluccia 
Subject:      Re: [MOBILE-IP] Drafts on MIP:EMA co-existence.
X-To:         alan.w.oneill@BT.COM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

--------------822419EAE0121696C1F159F4
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Alan O'Neill wrote:

> Setting the hand-over discussion aside for now, in terms of follow-up
> activity I'm very keen to see if the other micro-mobility folks would be
> willing to jointly specify a common MIP:micro-mobility framework draft
> covering signalling, address allocation, paging, MIP co-existence to try to
> get some badly needed convergence for OBAST and the MIP wg. I believe the
> aims should be to isolate the MN from the specific micro-mobility protocol
> selected by the network operator (save specific option data), to support
> incremental and partial deployment of micromobility, and ensure MIP and
> micro-mobility can work seamlessly independent of the status of MN or
> visited domain ?
>

I am supporting  this idea!
This  was actually exactly the goal  of an Internet Draft that we presented
last year at the Oslo
IETF... (see http://www.inrialpes.fr/planete/people/ccastel/draft.txt). The
idea was to define a
a commun  micro-mobility registration protocol that would be independent of the
different micro-mobility
protocols ...

I have attached the abstract of the draft to this email.

regards,

Claude.

  Abstract

   As the number of Mobile Nodes increases in the Internet, it becomes
   clear that a hierarchical mobility management protocol is necessary.
   The macro-mobility is the mobility between domains.  The micro-
   mobility is the mobility within one domain.  Several proposals that
   separate macro and micro-mobility has been proposed recently
   (CellularIP[4], HAWAII[3], HMIP[1],...).

   All these proposals agree that Mobile IP is suitable to handle
   macro-mobility (inter-domain mobility) but they all propose a
   different micro-mobility scheme. As a result, a Mobile Node won't be
   able to roam seamlessly if it does not understand the different
   micro-mobility management protocols of the domain that it visits.

   In this document, we present a framework that allows the deployment
   of various micro-mobility management protocols in different parts of
   the Internet while still providing connectivity to Mobile Nodes.

   We propose to decompose the Internet mobility management protocol
   into three components. The first one, the access protocol, specifies
   the registration procedures between the Mobile Node and the domain it
   is attached to. It is standard and unique. The second one, the
   micro-mobility protocol, manages local mobility and varies from one
   domain to another. The third one, the macro-mobility protocol,
   manages mobility across domains.  We suggest to use Mobile IP as the
   macro-mobility protocol.

   This Internet Draft first describes the architecture of the proposed
   framework. It then show how micro-Mobile IP and Cellular IP could be
   deployed within this framework.

--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/



--------------822419EAE0121696C1F159F4
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Alan O'Neill wrote:

Setting the hand-over discussion aside for now, in
terms of follow-up

activity I'm very keen to see if the other micro-mobility folks would
be

willing to jointly specify a common MIP:micro-mobility framework draft

covering signalling, address allocation, paging, MIP co-existence to
try to

get some badly needed convergence for OBAST and the MIP wg. I believe
the

aims should be to isolate the MN from the specific micro-mobility protocol

selected by the network operator (save specific option data), to support

incremental and partial deployment of micromobility, and ensure MIP
and

micro-mobility can work seamlessly independent of the status of MN
or

visited domain ?

 




I am supporting  this idea!

This  was actually exactly the goal  of an Internet Draft
that we presented last year at the Oslo

IETF... (see http://www.inrialpes.fr/planete/people/ccastel/draft.txt).
The idea was to define a

a commun  micro-mobility registration protocol that would be independent
of the different micro-mobility

protocols ...

I have attached the abstract of the draft to this email.

regards,

Claude.

  Abstract

   As the number of Mobile Nodes increases in the Internet,
it becomes

   clear that a hierarchical mobility management protocol
is necessary.

   The macro-mobility is the mobility between domains. 
The micro-

   mobility is the mobility within one domain.  Several
proposals that

   separate macro and micro-mobility has been proposed recently

   (CellularIP[4], HAWAII[3], HMIP[1],...).

   All these proposals agree that Mobile IP is suitable to
handle

   macro-mobility (inter-domain mobility) but they all propose
a

   different micro-mobility scheme. As a result, a Mobile
Node won't be

   able to roam seamlessly if it does not understand the
different

   micro-mobility management protocols of the domain that
it visits.

   In this document, we present a framework that allows the
deployment

   of various micro-mobility management protocols in different
parts of

   the Internet while still providing connectivity to Mobile
Nodes.

   We propose to decompose the Internet mobility management
protocol

   into three components. The first one, the access protocol,
specifies

   the registration procedures between the Mobile Node and
the domain it

   is attached to. It is standard and unique. The second
one, the

   micro-mobility protocol, manages local mobility and varies
from one

   domain to another. The third one, the macro-mobility protocol,

   manages mobility across domains.  We suggest to use
Mobile IP as the

   macro-mobility protocol.

   This Internet Draft first describes the architecture of
the proposed

   framework. It then show how micro-Mobile IP and Cellular
IP could be

   deployed within this framework.

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

 

--------------822419EAE0121696C1F159F4--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Jul 25 10:09: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 KAA28107
	for ; Tue, 25 Jul 2000 10:09:57 -0400 (EDT)
Received: from standards (47.234.32.16:4496) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB813BF@standards.nortelnetworks.com>; Tue, 25 Jul 2000 9:58:22 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 23308 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jul 2000 09:58:21
          -0400
Received: from cedar.dcs.shef.ac.uk by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB813BE@standards.nortelnetworks.com>; Tue, 25 Jul 2000 9:58:21
          -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 PAA09935 for
          ; Tue, 25 Jul 2000 15:09:13
          +0100 (BST)
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_010A_01BFF64A.94D0FC00"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Message-ID:  <010d01bff642$33481660$2c0ba78f@dcs.shef.ac.uk>
Date:         Tue, 25 Jul 2000 15:11:17 +0100
Reply-To: Chern Nam Yap 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: Chern Nam Yap 
Subject:      [MOBILE-IP] ESP protection
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_010A_01BFF64A.94D0FC00
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi

In section 4.4 MIPv6 draft 12 contains

<
Use of ESP for protecting the Binding Update or Binding Acknowledgement =
is
not currently defined in this document, since ESP does not protect
the portion of the packet above the ESP header itself [12].
>

Does this mean that Binding Updates and Binding Acknowledgement is not =
protected by ESP?

Cheers
Chern Nam Yap

------=_NextPart_000_010A_01BFF64A.94D0FC00
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









Hi


 


In section 4.4 MIPv6 draft 12 =
contains


 


<


Use of ESP for protecting the Binding =
Update or=20
Binding Acknowledgement is
not currently defined in this document, =
since ESP=20
does not protect
the portion of the packet above the ESP header =
itself=20
[12].
>


 


Does this mean that Binding =
Updates and=20
Binding Acknowledgement is not protected by ESP?



Cheers


Chern Nam =
Yap


------=_NextPart_000_010A_01BFF64A.94D0FC00--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Jul 25 11:04:21 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17960
	for ; Tue, 25 Jul 2000 11:04:21 -0400 (EDT)
Received: from standards (47.234.32.16:4496) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB81440@standards.nortelnetworks.com>; Tue, 25 Jul 2000 10:52:58 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 23478 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jul 2000 10:52:58
          -0400
Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB8143F@standards.nortelnetworks.com>; Tue, 25 Jul 2000 10:52:57
          -0400
Received: from esvir05nok.ntc.nokia.com (esvir05nok.ntc.nokia.com
          [131.228.10.154]) by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with
          ESMTP id e6PF3LR12773 for ;
          Tue, 25 Jul 2000 18:03:37 +0300 (EET DST)
Received: from daebh02nok.americas.nokia.com (unverified) by
          esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.1.5) with
          ESMTP id  for
          ; Tue, 25 Jul 2000 17:42:16
          +0300
Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id <3VXA98T0>;
          Tue, 25 Jul 2000 09:42:14 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E101@daeis07nok>
Date:         Tue, 25 Jul 2000 09:39:36 -0500
Reply-To: Basavaraj.Patil@NOKIA.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: Basavaraj Patil 
Subject:      [MOBILE-IP] Mobile IP WG Agenda for IETF48
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Agenda for Mobile IP at 48th IETF (Revised)

First Session  Tuesday 1300-1515
--------------------------------------------------

WG Status and Agenda Bashing 10 min

C. Perkins draft-ietf-mobileip-rfc2002-bis-02.txt 10min

C. Perkins Regional Registration for IPv6 10min

Claude Castellucia Hierarchical Mobile IPv6 -
draft-castelluccia-mobileip-hmipv6-00.txt 15min

Hesham Soliman - Hierarchical Mobile IPv6 -
draft-ietf-mobileip-hmipv6-00.txt - 10 Mins

Thierry Ernst - Extending MobileIPv6 with network scope Binding
Updates - draft-ernst-mobileip-v6-network-00.txt 10min

Shiao-Li Tsao Mobility Support for Dual Stack Systems 10min

Discussion of handoff

Second Session Wed 0900-1130
-----------------------------------------------

Discussion of handoff and output from handoff team 30min

J. Malinen Mobile IP Regional Registrations
draft-haverinen-mobileip-reg-pag-00.txt
and Mobile IP GSM Sim Authenticaion
draft-haverinen-mobileip-gsmsim-00.txt  - 15 Mins

Dynamic Home Addressing draft-thuel-mobileip-tt-00.txt S. Thuel 10min

Dynamic Home Address Allocation G. Dommety 10min (Tentative)

A. Campbell P-MIP: Minimal Paging Extensions for Mobile IP - 10 Min

V. Magret Multicast micro-mobility draft-magret-mobileip-mmm-00.txt -
10 Mins

R. Ramjee HAWAII 5min

Michael Wren Mobile IP and MPLS draft-zhong-mobile-ip-mpls-01.txt
10 Min

C N Yap Mobile VPNs draft-sanchez-mvpn-00.txt 15 min


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Jul 25 12:42:14 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22534
	for ; Tue, 25 Jul 2000 12:42:14 -0400 (EDT)
Received: from standards (47.234.32.16:4385) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB814E2@standards.nortelnetworks.com>; Tue, 25 Jul 2000 12:29:08 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 23701 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jul 2000 12:29:08
          -0400
Received: from dirty.research.bell-labs.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB814E1@standards.nortelnetworks.com>; Tue, 25 Jul 2000 12:29:07
          -0400
Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Tue Jul
          25 12:39:32 EDT 2000
Received: from king.research.bell-labs.com ([135.1.152.1]) by scummy; Tue Jul
          25 12:39:31 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 057535701F; Tue, 25 Jul 2000 11:39:30 -0500 (CDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <200007242233.PAA04203@nasnfs.eng.sun.com>
X-Mailer: VM 6.33 under Emacs 19.34.2
Message-ID:  <20000725163931.057535701F@king.research.bell-labs.com>
Date:         Tue, 25 Jul 2000 11:39:31 -0500
Reply-To: Pete McCann 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: Pete McCann 
Subject:      Re: [MOBILE-IP] Fast Handoff Issues
X-To:         James.Kempf@eng.sun.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <200007242233.PAA04203@nasnfs.eng.sun.com>
Content-Transfer-Encoding: 7bit

Hi, James,

James Kempf  (JK) writes:

JK> Actually, I was talking about interdomain, single technology
JK> hard (break before make) handoff.

Ok - when you said "radio link independent" I thought you meant
supporting handoff between heterogeneous technologies.

If you are only worried about the homogeneous case, then yes, this
signaling should eventually be done over IP - but is the IETF the
right place to standardize such signaling?  It seems like a link-layer
specific problem that should be solved in the 3GPP's.

-Pete


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Jul 25 15:20:12 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07652
	for ; Tue, 25 Jul 2000 15:20:11 -0400 (EDT)
Received: from standards (47.234.32.16:2240) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8159C@standards.nortelnetworks.com>; Tue, 25 Jul 2000 15:08:32 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 23947 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jul 2000 15:08:32
          -0400
Received: from ish7.ericsson.com.au (203.61.155.111:50086) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB8159B@standards.nortelnetworks.com>; Tue, 25 Jul 2000
          15:08:30 -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 FAA19133; Wed,
          26 Jul 2000 05:17:48 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id FAA13299; Wed, 26
          Jul 2000 05:19:07 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service
          (5.5.2650.21) id <3FW958SP>; Wed, 26 Jul 2000 05:19:00 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFF66D.2DB57C80"
Message-ID:  <4B6BC00CD15FD2119E5F0008C7A419A5089EB132@eaubrnt018.epa.ericsson.se>
Date:         Wed, 26 Jul 2000 05:18:56 +1000
Reply-To: "Hesham Soliman (EPA)" 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: "Hesham Soliman (EPA)" 
Subject:      Re: [MOBILE-IP] draft-malinen-mobileip-regreg6-00.txt
X-To:         "jmalinen@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_01BFF66D.2DB57C80
Content-Type: text/plain;
        charset="iso-8859-1"

Hello Jari,

Please find below my response to your comparison with our draft.
I will send another mail with some comments on your draft.

Regards,
Hesham


> Hi Jari and Charlie,
>   I have some questions on this I-D:
> The method is based on advertizing regional care-of addresses to MNs
> that can do a regional BU taking one of them as its alternate care-of
address
> and thereafter using this address
> in the visited domain. This means that the data is continously tunneled
> from GMA to MN as long as MN stays in the
> domain (sounds like HAWAII in which MN is given an IPv4 address in the
> domain, doesn't it?).
> So address autoconfiguration at each access router and its associated BU
> traffic are compromised with MIPv4 like tunneling.
> This same idea can also be found in the I-D by Karim.
> Can you provide some clarification on this?

This IPv6-specifc design uses the general idea of IPv4 regional
registrations
with a stationary care-of-address, but with the following distinctions to
the
designs of HAWAII or Karim's I-D:

-  HA does not need to be regional-aware (or MAP-aware) as in Karim's
    I-D. The first packets from CN via HA to MN are re-capsulated at GMA
    via possible lower regional routers down to MN's autoconfigured on-link
CoA.
    MN can recognize it needs to send a BU to CN from an encapsulated packet
    from CN, encapsulator being the access router.

=> That is an inaccurate observation. That's not the reason the HA has to
add a routing header (if that's what you mean by regional-aware).
The HA has to do that when it forwards packets that were addressed to an MN
address that was not registered with the MAP.
I might be wrong but I don't think you've addressed this problem in your
draft. Therefore according to your proposal, other home addresses that
the regional router is not aware of, will not be received by the MN as they
will be dropped by the regional router.


After MN sent a BU with
    alternate CoA to CN, this can start sending route-optimized packets to
MN
    via GMA. Inner packet AH is not touched in intermediate routers.
    Packets are forwarded locally in the visited domain and not from HA.
    We can thus do without using an additional routing header with
tunneling.

=> I don't really understand how that affects our decision of adding a
routing header.
AH is not affected in our proposal either, end to end security is
maintained.
What you mention above is not related to adding a routing header from the
HA.
The routing header from the CN is mandatory according to MIPv6.

- In our design, most of the data packets are neither tunneled nor
   host-routed (note also that signaling is not tunneled).
   Route-optimized packets towards the MN are forwarded in a special
   way based only on the regional binding cache.

=> If I understand that special way you refer to correctly, it is done by
changing the destination address in the packet. I think it is dangerous
to allow intermediate nodes to modify packets. I think tunnelling
is a better way to go here.


Normal processing of
   source-routed packets is skipped if there is a regional binding cache
   entry for the route-optimized home address in the regional CoA router
   receiving the packet. Only IPhdr destination is changed, AH prevails.
   The packet is then just forwarded to the lower CoA as seen in the
   regional binding cache.  Thus, no extra routing state is needed.
   This is much simpler than in Karim's proposal and is quite different
   from IPv4-solutions. Universal route optimization as provided in basic
   Mobile IPv6 is not compromized. Such route optimization is not
   even possible in IPv4 due to its legacy CNs.

=> I don't understand why you chose not to process the routing header.
This breaks RFC 2460 (IPv6 spec) for no reason.


- When MN changes link and gets a new address by autoconfiguration
   it performs a regional binding update. This updates the lower CoA as
   seen by GMA or a lower crossover router. The regional binding cache
   can thus direct packets to the new direction, i.e. MN's ability to move
is
   not compromized despite the use of address autoconfiguration.
   Those packets that were able to get past the crossover after MN started
   moving and before the crossover received a new regional BU can sometimes
   go to the MN via the simultaneous connection through the old on-link CoA.
   This amounts to no duplication of data packets (bicasting), just a
careful
   switching of MN's default route from the old access router to the new
one.
   Or, data packets can be buffered by the old router when no simultaneous
   connection is possible, e.g. in "hard handoff" conditions.



- Buffering was provided as one component of the handoff framework where
   our Mobile IPv6 regional registrations is another. Thus, this draft
separates
   the problem of location update localization from the handoff state
transition
   management.

=>I'll keep my comments here for the other two drafts you refer to below.

The smooth handoff framework design, as described by the documents at

http://www.iprg.nokia.com/~charliep/txt/regreg6/regreg6.txt
http://www.iprg.nokia.com/~charliep/txt/smoothv6/smoothv6.txt
http://www.iprg.nokia.com/~charliep/txt/mobilebuf/buffer6.txt
http://www.iprg.nokia.com/~charliep/txt/rohc/hc-ho-draft.txt

> Has this I-D been submitted to IETF?

Yes, with the same procedure & boilerplate as
draft-haverinen-reg-paging-00.txt,
Fri Jul/14/00. Curiously, no I-D-Action message resulted.

>
> Regards,
> --
> Behcet

Best Regards,

-Jari

------_=_NextPart_001_01BFF66D.2DB57C80
Content-Type: text/html;
        charset="iso-8859-1"






RE: [MOBILE-IP] draft-malinen-mobileip-regreg6-00.txt




Hello Jari,




Please find below my response to your comparison with our draft.

I will send another mail with some comments on your draft.




Regards,

Hesham






> Hi Jari and Charlie,

>   I have some questions on this I-D:

> The method is based on advertizing regional care-of addresses to MNs

> that can do a regional BU taking one of them as its alternate care-of address

> and thereafter using this address

> in the visited domain. This means that the data is continously tunneled

> from GMA to MN as long as MN stays in the

> domain (sounds like HAWAII in which MN is given an IPv4 address in the

> domain, doesn't it?).

> So address autoconfiguration at each access router and its associated BU

> traffic are compromised with MIPv4 like tunneling.

> This same idea can also be found in the I-D by Karim.

> Can you provide some clarification on this?




This IPv6-specifc design uses the general idea of IPv4 regional registrations

with a stationary care-of-address, but with the following distinctions to the

designs of HAWAII or Karim's I-D:




-  HA does not need to be regional-aware (or MAP-aware) as in Karim's

    I-D. The first packets from CN via HA to MN are re-capsulated at GMA

    via possible lower regional routers down to MN's autoconfigured on-link CoA.

    MN can recognize it needs to send a BU to CN from an encapsulated packet

    from CN, encapsulator being the access router. 




=> That is an inaccurate observation. That's not the reason the HA has to 

add a routing header (if that's what you mean by regional-aware). 

The HA has to do that when it forwards packets that were addressed to an MN

address that was not registered with the MAP. 

I might be wrong but I don't think you've addressed this problem in your 

draft. Therefore according to your proposal, other home addresses that 

the regional router is not aware of, will not be received by the MN as they

will be dropped by the regional router.






After MN sent a BU with

    alternate CoA to CN, this can start sending route-optimized packets to MN

    via GMA. Inner packet AH is not touched in intermediate routers.

    Packets are forwarded locally in the visited domain and not from HA.

    We can thus do without using an additional routing header with tunneling.




=> I don't really understand how that affects our decision of adding a routing header. 

AH is not affected in our proposal either, end to end security is maintained.

What you mention above is not related to adding a routing header from the HA.

The routing header from the CN is mandatory according to MIPv6.




- In our design, most of the data packets are neither tunneled nor

   host-routed (note also that signaling is not tunneled).

   Route-optimized packets towards the MN are forwarded in a special

   way based only on the regional binding cache. 




=> If I understand that special way you refer to correctly, it is done by 

changing the destination address in the packet. I think it is dangerous 

to allow intermediate nodes to modify packets. I think tunnelling 

is a better way to go here.






Normal processing of

   source-routed packets is skipped if there is a regional binding cache

   entry for the route-optimized home address in the regional CoA router

   receiving the packet. Only IPhdr destination is changed, AH prevails.

   The packet is then just forwarded to the lower CoA as seen in the

   regional binding cache.  Thus, no extra routing state is needed.

   This is much simpler than in Karim's proposal and is quite different

   from IPv4-solutions. Universal route optimization as provided in basic

   Mobile IPv6 is not compromized. Such route optimization is not

   even possible in IPv4 due to its legacy CNs.




=> I don't understand why you chose not to process the routing header.

This breaks RFC 2460 (IPv6 spec) for no reason.






- When MN changes link and gets a new address by autoconfiguration

   it performs a regional binding update. This updates the lower CoA as

   seen by GMA or a lower crossover router. The regional binding cache

   can thus direct packets to the new direction, i.e. MN's ability to move is

   not compromized despite the use of address autoconfiguration.

   Those packets that were able to get past the crossover after MN started

   moving and before the crossover received a new regional BU can sometimes

   go to the MN via the simultaneous connection through the old on-link CoA.

   This amounts to no duplication of data packets (bicasting), just a careful

   switching of MN's default route from the old access router to the new one.

   Or, data packets can be buffered by the old router when no simultaneous

   connection is possible, e.g. in "hard handoff" conditions.








- Buffering was provided as one component of the handoff framework where

   our Mobile IPv6 regional registrations is another. Thus, this draft separates

   the problem of location update localization from the handoff state transition

   management.




=>I'll keep my comments here for the other two drafts you refer to below.




The smooth handoff framework design, as described by the documents at




http://www.iprg.nokia.com/~charliep/txt/regreg6/regreg6.txt

http://www.iprg.nokia.com/~charliep/txt/smoothv6/smoothv6.txt

http://www.iprg.nokia.com/~charliep/txt/mobilebuf/buffer6.txt

http://www.iprg.nokia.com/~charliep/txt/rohc/hc-ho-draft.txt




> Has this I-D been submitted to IETF?




Yes, with the same procedure & boilerplate as draft-haverinen-reg-paging-00.txt,

Fri Jul/14/00. Curiously, no I-D-Action message resulted.




>

> Regards,

> --

> Behcet




Best Regards,




-Jari





------_=_NextPart_001_01BFF66D.2DB57C80--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Jul 25 15:28:13 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10237
	for ; Tue, 25 Jul 2000 15:28:12 -0400 (EDT)
Received: from standards (47.234.32.16:2240) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB815CA@standards.nortelnetworks.com>; Tue, 25 Jul 2000 15:16:46 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 24012 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jul 2000 15:16:46
          -0400
Received: from ish7.ericsson.com.au (203.61.155.111:50132) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB815C9@standards.nortelnetworks.com>; Tue, 25 Jul 2000
          15:16: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 FAA19261 for
          ; Wed, 26 Jul 2000 05:26:04
          +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id FAA13586 for
          ; Wed, 26 Jul 2000 05:27:23
          +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service
          (5.5.2650.21) id <3FW95841>; Wed, 26 Jul 2000 05:27:16 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFF66E.56E4E4A0"
Message-ID:  <4B6BC00CD15FD2119E5F0008C7A419A5089EB133@eaubrnt018.epa.ericsson.se>
Date:         Wed, 26 Jul 2000 05:27:15 +1000
Reply-To: "Hesham Soliman (EPA)" 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: "Hesham Soliman (EPA)" 
Subject:      Re: [MOBILE-IP] draft-malinen-mobileip-regreg6-00.txt
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_01BFF66E.56E4E4A0
Content-Type: text/plain;
        charset="iso-8859-1"

Hello Jari and Charlie,

After reading your draft on regional registration for IPv6, I
came up with the following comments.

General comment:


I believe mandating hop by hop encapsulation-decapsulation between
regional routers will have the following effects:

- We end up with a reserved path in the network, hence you lose
the inherent redundancy that we get with IP routing. ie. if one
of the regional aware routers crash, the MN won't receive anything.

- Encapsulation-decapsulation at each node adds extra and unnecessary
delays.

BTW our draft allows the same scenario, but it also allows the MN
to receive directly from the MAP. So there is a choice and it
depends on the MNs preferences / configuration.


Other comments:

- I believe propagating the BU  in the hierarchy breaks the basic
design of MIPv6. Furthermore, it is not clear from the draft
how you can maintain the SA between the MN and each regional router
if the MN doesn't know they exist. As I understood it, the destination
address of the BU is the access router on the same link as the MN.
I assume from ch 7 that you will do some sort of key distribution
protocol. I still can't see how that would work and more importanly
don't see the need for it.
It seems this would add extra complexity / protocols, for no apparent
benefit.
Please elaborate if I missed something here.


- It is unclear to me how the regional BAck is processed. The draft assumes
there is only one sent back. Is it propagated down the hierarchy ?
If so then how would the SA work ?
If not then what happens if one router fails and the others succeed?

- By not processing the routing header in the regional router, you
are breaking the extension header processing rules in RFC 2460.
I also don't see why this is necessary.

- I have some concerns about the way the inbound packets are routed
within the hierarchy. You mention encapsulation in the draft, but
when it is described it doesn't actually say the same thing. It seems
that the destination address is modified in the original packet.
I know that end to end AH will still work, but this is not a normal
IPv6 stack behaviour and I don't see why it is necessary.

- If the MN decides to register its alt-COA with the HA. I believe
any Site-local packets forwarded by the HA to the MNs COA will be
dropped by the regional router (ie. the owner of the COA).
That's one of the reasons we attach a routing header between the HA
and the MAP.


Regards,
Hesham




------_=_NextPart_001_01BFF66E.56E4E4A0
Content-Type: text/html;
        charset="iso-8859-1"






RE: [MOBILE-IP] draft-malinen-mobileip-regreg6-00.txt




Hello Jari and Charlie,




After reading your draft on regional registration for IPv6, I 

came up with the following comments.




General comment:






I believe mandating hop by hop encapsulation-decapsulation between 

regional routers will have the following effects:




- We end up with a reserved path in the network, hence you lose

the inherent redundancy that we get with IP routing. ie. if one 

of the regional aware routers crash, the MN won't receive anything.




- Encapsulation-decapsulation at each node adds extra and unnecessary

delays.




BTW our draft allows the same scenario, but it also allows the MN

to receive directly from the MAP. So there is a choice and it 

depends on the MNs preferences / configuration.






Other comments:




- I believe propagating the BU  in the hierarchy breaks the basic

design of MIPv6. Furthermore, it is not clear from the draft

how you can maintain the SA between the MN and each regional router

if the MN doesn't know they exist. As I understood it, the destination

address of the BU is the access router on the same link as the MN.

I assume from ch 7 that you will do some sort of key distribution

protocol. I still can't see how that would work and more importanly 

don't see the need for it.

It seems this would add extra complexity / protocols, for no apparent

benefit.

Please elaborate if I missed something here.






- It is unclear to me how the regional BAck is processed. The draft assumes 

there is only one sent back. Is it propagated down the hierarchy ?

If so then how would the SA work ?

If not then what happens if one router fails and the others succeed?




- By not processing the routing header in the regional router, you 

are breaking the extension header processing rules in RFC 2460.

I also don't see why this is necessary.




- I have some concerns about the way the inbound packets are routed

within the hierarchy. You mention encapsulation in the draft, but 

when it is described it doesn't actually say the same thing. It seems

that the destination address is modified in the original packet.

I know that end to end AH will still work, but this is not a normal

IPv6 stack behaviour and I don't see why it is necessary.




- If the MN decides to register its alt-COA with the HA. I believe

any Site-local packets forwarded by the HA to the MNs COA will be

dropped by the regional router (ie. the owner of the COA).

That's one of the reasons we attach a routing header between the HA 

and the MAP.






Regards,

Hesham









------_=_NextPart_001_01BFF66E.56E4E4A0--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Jul 25 15:47: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 PAA15689
	for ; Tue, 25 Jul 2000 15:47:14 -0400 (EDT)
Received: from standards (47.234.32.16:2240) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB81607@standards.nortelnetworks.com>; Tue, 25 Jul 2000 15:35:42 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 24089 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jul 2000 15:35:42
          -0400
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFB81600@standards.nortelnetworks.com>; Tue, 25 Jul 2000 15:25:41
          -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 MAA04356
          for ; Tue, 25 Jul 2000
          12:36:35 -0700 (PDT)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.9.3/8.9.3-VIRSCAN) id MAA01925 for
          ; Tue, 25 Jul 2000 12:36:32
          -0700
X-Virus-Scanned:  Tue, 25 Jul 2000 12:36:32 -0700 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from jmalinen.iprg.nokia.com (205.226.2.98,
          claiming to be "iprg.nokia.com") by
          darkstar.iprg.nokia.com(WTS.12.69) smtpdUOhU8d; Tue, 25 Jul 2000
          12:36:30 PDT
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
References: <397AEA48.B76B9CF@u-aizu.ac.jp> <397BD577.630F13F0@iprg.nokia.com>
            <397C6167.94728DC4@inrialpes.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <397DEC3F.8AE1F8CA@iprg.nokia.com>
Date:         Tue, 25 Jul 2000 12:36:31 -0700
Reply-To: jmalinen@IPRG.NOKIA.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: "Jari T. Malinen" 
Organization: Nokia
Subject:      Re: [MOBILE-IP] draft-malinen-mobileip-regreg6-00.txt
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi, Claude,

Thanks for your comments, and sorry for not being able to communicate more with
you on the interesting work that you have been providing. Our approach was to get
a simpler, efficient, and secure solution. I think we don't lose too much,
see my comments embedded below..

Claude Castelluccia wrote:

> Hi Jari,
>
> Your  "Mobile IPv6 Regional Registrations" proposal has a lot of simillarities with
> our HMIPv6 proposal (the ID that will be presented in Pittsburg is available on
> http://www.inrialpes.fr/planete/people/ccastel/draft-castelluccia-mobileip-hmipv6-00.txt
> but I am sure you know our work since you were at IPCN...).
> FYI a FreeBSD implementation of HMIPv6 is available since April 2000 on
> http://www.inrialpes.fr/planete.
>
> One difference  that I see between our proposals is that in HMIPv6 a MH  configures
> its GCoA (this is what you call regional CoA) by itself
> (we make full use of IPv6 functionalties). The access router only advertises the
> subnet prefix address of the MS (this is what you call MGA) instead of a long list of
> IPv6 addresses.
> Since these router adv. are sent frequently, our proposal  results in a better
> utilization of the wireless ressources...

In fact, you can do quite a small advertisement with our approach. You have the
regional CoA in the advertisement and the access router address in the IPhdr.
In the network-controlled crossover router selection you only need to know the
regional CoA.
The access router knows how to advertise regional addresses (and other capabilities)
so it is naturally regional-aware. The handoff state management, which is
an access router issue, when combined with the IPv6 regional registrations as
in our framework, will make this even more natural.

> Beside that autoconfiguration solves a lot of problem. In your scheme when a
> MH gets a Regional CoA from the router adv. ,this address has to be removed from
> the advertised list otherwise you will have address collision.
> This implies to have a protocol between the MGA and the access routers  and results
> in higher  registration and handoff delays..

The situation is better since we can share the regional CoA thanks to the regional-
aware data routing (we have the home address as regional forwarding key). We have a
rather fast operation when we don't need to reconfigure a regional-aware CoA at all
under normal operation.

> In HMIP, since the GCoA is build by concatening the MS prefix and EUI64, address
> collision is very unlikely (but the MS verifies the unicity of the address by
> performing a DaD on its link). Why don't you use the nice IPv6  autoconfiguration
> capability?

This is for efficiency reasons, if the GCoA does not usually need to be configured
at all, no delay occurs. However, your comment brings to mind that renumbering
should cause reconfiguration of access router advertisements.
At this moment we limited hierarchy reconfiguration (dynamic knowledge of regional
care-of-addresses, children, and father) out of scope, however. This can be done
with a separate protocol extension for these hopefully infrequent events, including
renumbering.

> I have another question: why does a mobile host  send its regionalized BU to the
> access router instead of sending it directly to the closed Regional MA as we do
> (the RMA address could be advertised in the router adv.)?
> This would  provide more flexibility in the deployement of the Regional-aware
> routers (they don't have to be on a tree anymore)...

A region is naturally a hierarchy and in our model the network decides on the
crossover router (the highest guy changing its binding cache and answering to
this BU) thus distributing the signalling load down to the hierarchy. The
communication path per mobile at a time is usually a tree because the root is
anchored, anyway, however, the global structure can be more generic, once you
use many GMAs and MN-controlled selection.

> regards,
>
> Claude.
>
>
> "Jari T. Malinen" wrote:
>
> > Hi, Bechet,
> >
> > thanks for your comments,
> >
> > Behcet Sarikaya wrote:
> >
> > > Hi Jari and Charlie,
> > >   I have some questions on this I-D:
> > > The method is based on advertizing regional care-of addresses to MNs
> > > that can do a regional BU taking one of them as its alternate care-of address
> > > and thereafter using this address
> > > in the visited domain. This means that the data is continously tunneled
> > > from GMA to MN as long as MN stays in the
> > > domain (sounds like HAWAII in which MN is given an IPv4 address in the
> > > domain, doesn't it?).
> > > So address autoconfiguration at each access router and its associated BU
> > > traffic are compromised with MIPv4 like tunneling.
> > > This same idea can also be found in the I-D by Karim.
> > > Can you provide some clarification on this?
> >
> > This IPv6-specifc design uses the general idea of IPv4 regional registrations
> > with a stationary care-of-address, but with the following distinctions to the
> > designs of HAWAII or Karim's I-D:
> >
> > -  HA does not need to be regional-aware (or MAP-aware) as in Karim's
> >     I-D. The first packets from CN via HA to MN are re-capsulated at GMA
> >     via possible lower regional routers down to MN's autoconfigured on-link CoA.
> >     MN can recognize it needs to send a BU to CN from an encapsulated packet
> >     from CN, encapsulator being the access router. After MN sent a BU with
> >     alternate CoA to CN, this can start sending route-optimized packets to MN
> >     via GMA. Inner packet AH is not touched in intermediate routers.
> >     Packets are forwarded locally in the visited domain and not from HA.
> >     We can thus do without using an additional routing header with tunneling.
> >
> > - In our design, most of the data packets are neither tunneled nor
> >    host-routed (note also that signaling is not tunneled).
> >    Route-optimized packets towards the MN are forwarded in a special
> >    way based only on the regional binding cache. Normal processing of
> >    source-routed packets is skipped if there is a regional binding cache
> >    entry for the route-optimized home address in the regional CoA router
> >    receiving the packet. Only IPhdr destination is changed, AH prevails.
> >    The packet is then just forwarded to the lower CoA as seen in the
> >    regional binding cache.  Thus, no extra routing state is needed.
> >    This is much simpler than in Karim's proposal and is quite different
> >    from IPv4-solutions. Universal route optimization as provided in basic
> >    Mobile IPv6 is not compromized. Such route optimization is not
> >    even possible in IPv4 due to its legacy CNs.
> >
> > - When MN changes link and gets a new address by autoconfiguration
> >    it performs a regional binding update. This updates the lower CoA as
> >    seen by GMA or a lower crossover router. The regional binding cache
> >    can thus direct packets to the new direction, i.e. MN's ability to move is
> >    not compromized despite the use of address autoconfiguration.
> >    Those packets that were able to get past the crossover after MN started
> >    moving and before the crossover received a new regional BU can sometimes
> >    go to the MN via the simultaneous connection through the old on-link CoA.
> >    This amounts to no duplication of data packets (bicasting), just a careful
> >    switching of MN's default route from the old access router to the new one.>
> >    Or, data packets can be buffered by the old router when no simultaneous
> >    connection is possible, e.g. in "hard handoff" conditions.
> >
> > - Buffering was provided as one component of the handoff framework where
> >    our Mobile IPv6 regional registrations is another. Thus, this draft separates
> >    the problem of location update localization from the handoff state transition
> >    management.
> >
> > The smooth handoff framework design, as described by the documents at
> >
> > http://www.iprg.nokia.com/~charliep/txt/regreg6/regreg6.txt
> > http://www.iprg.nokia.com/~charliep/txt/smoothv6/smoothv6.txt
> > http://www.iprg.nokia.com/~charliep/txt/mobilebuf/buffer6.txt
> > http://www.iprg.nokia.com/~charliep/txt/rohc/hc-ho-draft.txt
> >
> > > Has this I-D been submitted to IETF?
> >
> > Yes, with the same procedure & boilerplate as draft-haverinen-reg-paging-00.txt,
> > Fri Jul/14/00. Curiously, no I-D-Action message resulted.
> >
> > >
> > > Regards,
> > > --
> > > Behcet
> >
> > Best Regards,
> >
> > -Jari
>
> --
>
> ----------------------------------------
> 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  Tue Jul 25 16:40:14 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29489
	for ; Tue, 25 Jul 2000 16:40:13 -0400 (EDT)
Received: from standards (47.234.32.16:3343) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8167D@standards.nortelnetworks.com>; Tue, 25 Jul 2000 16:28:47 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 24254 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jul 2000 16:28:47
          -0400
Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB8167C@standards.nortelnetworks.com>; Tue, 25 Jul 2000 16:28:46
          -0400
Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by
          mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e6P86Hv02331 for
          ; Tue, 25 Jul 2000 11:06:23
          +0300 (EET DST)
Received: from esebh02nok.ntc.nokia.com (esebh02nok.ntc.nokia.com
          [131.228.118.151]) by mgw-i2.ntc.nokia.com (8.10.2/8.10.2/Nokia) with
          ESMTP id e6P85r627632 for ;
          Tue, 25 Jul 2000 11:06:04 +0300 (EET DST)
Received: by esebh02nok with Internet Mail Service (5.5.2650.10) id ;
          Tue, 25 Jul 2000 11:05:53 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <6D1A8E7871B9D211B3B00008C7490AA501697E59@treis03nok>
Date:         Tue, 25 Jul 2000 11:05:51 +0300
Reply-To: henry.haverinen@NOKIA.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: Henry Haverinen 
Subject:      Re: [MOBILE-IP] Comments on draft-haverinen-mobileip-gsmsim-00.tx
              t
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hello Pat,

I'm sorry it took me so long to reply your mail.

> > The "AAA server" in this case is deep within the GSM cloud.
> > Therefore, the "MN-AAA key" (which is the GSM SIM key Ki) cannot be
> > used in arbitrary ways. The mobile node must get the RAND values
> > from the AAA server before it is able to generate a usable key.
> >
...
> OK, here is where my mis-understanding is. I was under the
> impression that the
> Mobile has a secret that it shared with some entity in its
> home network. Be it
> a AAA server, the Authentication Center, the HLR, whatever.
> This is the key
> that is used to decrypt the dynamic keys, and the one I was
> proposing that is
> used to generate the authentication extensions.
>
> Is there a particular reason why this long lived key cannot
> be used in the
> initial round trip? Or is there truly NO long lived key, and
> there is magic
> involved in the key decryption that I am unaware of :)

There truly is a long lived key (Ki) on the SIM, but it can only be
used as input to the GSM authentication algorithms that run
on the SIM. The SIM card does not (and must not) have an interface for
reading Ki. The reason is to make it harder to duplicate SIM cards.
The GSM SIM specification (02.17) reads:
"All reasonable steps shall be taken to ensure that the algorithms
(A3 and A8) and subscriber authentication key (Ki) cannot be
read, altered, manipulated or bypassed in such a way as to reveal
secret information."

On the mobile node, we could input "well-known" RANDs, or RANDs
that are based on the time of day, for instance, to the SIM
authentication algorithms and generate an authentication key for
the first round trip. However, since
we want to leverage the existing GSM networks, we wouldn't
be able to generate the same keys on the network side. In the
GSM world, the authentication center must generate the RANDs.
By not requiring changes to the GSM network, we'll be able to
use the existing GSM roaming and authentication
infrastructure.

What we have in mind is a gateway box on the border of the GSM and IP
networks. The gateway box talks standard GSM protocols (MAP) to the
GSM network and an AAA protocol to the IP network. Given an IMSI, the
gateway box is able to obtain the RAND challenges and the Kc keys that
correspond the RANDs from the authentication center of the subsriber's
home operator.  Thus, we need the first round trip for delivering the IMSI
to the gateway box and getting the RANDs back to the terminal.

I think we need to add a section about this architectural stuff
to the gsmsim draft to make it more understandable.

> > > How about all registrations (perhaps except the last reply)
> > > include the MN-AAA. This solves all of your problems, and you
> > > can REALLY ignore any un-authenticated message (which is what you
> > > should do!).
> > [...]
> > > What I am missing here is the lack of authentication
> > > extensions. The SIM Key Request is not an authentication
> extension,
> > > correct? Since  the Mobile already has a secret with the
> key generating
> > > entity, simply re-use that to secure the initial messages...
> >
> > As explained above, the equivalent of the MN-HAAA key (Ki)
> is known to
> > the SIM card on the MN and the GSM AuC (authentication
> center), the latter
> > does not participate in the Mobile IP authorization process
> (because it is
> > deep
> > within the GSM cloud).
>
> Ahhh... here is my answer. Can the AuC then not perform some
> hashing of its
> own to generate the authentication extension response? Can it
> be modified in
> any way to handle this?

We don't want to modify the AuC or any other component of the GSM
network (as explained above). Thus we have to do all the Mobile IP
and Internet AAA specific tasks (generate the authentication extensions)
on the gateway box or on the mobility agents.

Regards,
Henry


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Jul 25 17:11:51 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08488
	for ; Tue, 25 Jul 2000 17:11:51 -0400 (EDT)
Received: from standards (47.234.32.16:3343) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB816CF@standards.nortelnetworks.com>; Tue, 25 Jul 2000 17:00:25 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 24365 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jul 2000 17:00:25
          -0400
Received: from ish7.ericsson.com.au (203.61.155.111:51017) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB816CE@standards.nortelnetworks.com>; Tue, 25 Jul 2000
          17:00:24 -0400
Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id HAA21295; Wed,
          26 Jul 2000 07:09:43 +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 HAA18247; Wed, 26
          Jul 2000 07:11:02 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service
          (5.5.2650.21) id <3FW959QZ>; Wed, 26 Jul 2000 07:10:55 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFF67C.D13B5F50"
Message-ID:  <4B6BC00CD15FD2119E5F0008C7A419A5089EB136@eaubrnt018.epa.ericsson.se>
Date:         Wed, 26 Jul 2000 07:10:53 +1000
Reply-To: "Hesham Soliman (EPA)" 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: "Hesham Soliman (EPA)" 
Subject:      Re: [MOBILE-IP] draft-malinen-mobileip-regreg6-00.txt
X-To:         "jmalinen@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_01BFF67C.D13B5F50
Content-Type: text/plain;
        charset="iso-8859-1"

Hi Jari,

I agree with Claude's comments regarding the sending of BUs.
Here are some more comments on your reply below

Hesham

> In HMIP, since the GCoA is build by concatening the MS prefix and EUI64,
address
> collision is very unlikely (but the MS verifies the unicity of the address
by
> performing a DaD on its link). Why don't you use the nice IPv6
autoconfiguration
> capability?

This is for efficiency reasons, if the GCoA does not usually need to be
configured
at all, no delay occurs. However, your comment brings to mind that
renumbering
should cause reconfiguration of access router advertisements.
At this moment we limited hierarchy reconfiguration (dynamic knowledge of
regional
care-of-addresses, children, and father) out of scope, however. This can be
done
with a separate protocol extension for these hopefully infrequent events,
including
renumbering.

=>I don't really see a need for new protocols to handle renumbering. In our
proposal (and I blieve in Claude's one too) the renumbering is handled
automatically because the rtr adv will announce new MAP addresses (in our
case) or new prefixes (in Claude's draft).
I think the basic IPv6 functionality in this case is certainly enough
and provides very flexible and generic mechanisms without introducing
more protocols. The less complexity, the better IMO.



> I have another question: why does a mobile host  send its regionalized BU
to the
> access router instead of sending it directly to the closed Regional MA as
we do
> (the RMA address could be advertised in the router adv.)?
> This would  provide more flexibility in the deployement of the
Regional-aware
> routers (they don't have to be on a tree anymore)...

A region is naturally a hierarchy and in our model the network decides on
the
crossover router (the highest guy changing its binding cache and answering
to
this BU) thus distributing the signalling load down to the hierarchy.

=>I don't see how the signalling load is distributed from a router's
point of view. Every router in the heirarchy will still receive a BU.
So the only difference is in our case (and again Claude's draft),
is that the MN is aware who's receiving the BU. Which is what MIPv6 says,
and I think that is a cleaner way to do it and less complex.

The
communication path per mobile at a time is usually a tree because the root
is
anchored, anyway, however, the global structure can be more generic, once
you
use many GMAs and MN-controlled selection.

Agreed. But that doesn't mean things should be transparent to the MN IMO.

------_=_NextPart_001_01BFF67C.D13B5F50
Content-Type: text/html;
        charset="iso-8859-1"






RE: [MOBILE-IP] draft-malinen-mobileip-regreg6-00.txt




Hi Jari,




I agree with Claude's comments regarding the sending of BUs. 

Here are some more comments on your reply below




Hesham




> In HMIP, since the GCoA is build by concatening the MS prefix and EUI64, address

> collision is very unlikely (but the MS verifies the unicity of the address by

> performing a DaD on its link). Why don't you use the nice IPv6  autoconfiguration

> capability?




This is for efficiency reasons, if the GCoA does not usually need to be configured

at all, no delay occurs. However, your comment brings to mind that renumbering

should cause reconfiguration of access router advertisements.

At this moment we limited hierarchy reconfiguration (dynamic knowledge of regional

care-of-addresses, children, and father) out of scope, however. This can be done

with a separate protocol extension for these hopefully infrequent events, including

renumbering.




=>I don't really see a need for new protocols to handle renumbering. In our 

proposal (and I blieve in Claude's one too) the renumbering is handled 

automatically because the rtr adv will announce new MAP addresses (in our 

case) or new prefixes (in Claude's draft). 

I think the basic IPv6 functionality in this case is certainly enough

and provides very flexible and generic mechanisms without introducing

more protocols. The less complexity, the better IMO.








> I have another question: why does a mobile host  send its regionalized BU to the

> access router instead of sending it directly to the closed Regional MA as we do

> (the RMA address could be advertised in the router adv.)?

> This would  provide more flexibility in the deployement of the Regional-aware

> routers (they don't have to be on a tree anymore)...




A region is naturally a hierarchy and in our model the network decides on the

crossover router (the highest guy changing its binding cache and answering to

this BU) thus distributing the signalling load down to the hierarchy. 




=>I don't see how the signalling load is distributed from a router's 

point of view. Every router in the heirarchy will still receive a BU.

So the only difference is in our case (and again Claude's draft), 

is that the MN is aware who's receiving the BU. Which is what MIPv6 says, 

and I think that is a cleaner way to do it and less complex.




The

communication path per mobile at a time is usually a tree because the root is

anchored, anyway, however, the global structure can be more generic, once you

use many GMAs and MN-controlled selection.




Agreed. But that doesn't mean things should be transparent to the MN IMO.





------_=_NextPart_001_01BFF67C.D13B5F50--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Jul 25 21:35: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 VAA23724
	for ; Tue, 25 Jul 2000 21:35:52 -0400 (EDT)
Received: from standards (47.234.32.16:4676) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB817CD@standards.nortelnetworks.com>; Tue, 25 Jul 2000 21:24:22 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 24703 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jul 2000 21:24:22
          -0400
Received: from extmx.itri.org.tw by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB817CA@standards.nortelnetworks.com>; Tue, 25 Jul 2000 21:14:18
          -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 JAA29502 for
          ; Wed, 26 Jul 2000 09:28:11
          +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
          JAA11009 for ; Wed, 26 Jul
          2000 09:26:02 +0800 (CST)
Received: from Tsao2 ([140.96.104.146]) by cclmail.ccl.itri.org.tw (Lotus
          Domino Release 5.0.2a (Intl)) with SMTP id 2000072609285993:1506 ;
          Wed, 26 Jul 2000 09:28:59 +0800
References:  <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E101@daeis07nok>
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/07/26 09:28:59 AM,
             Serialize by Router on CCLMAIL/ITRI(Release 5.0.2a (Intl)|23
             November 1999) at 2000/07/26 09:29:00 AM,
             Serialize complete at 2000/07/26 09:29:00 AM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <029b01bff69f$e879e9c0$9268608c@Tsao2>
Date:         Wed, 26 Jul 2000 09:22:04 +0800
Reply-To: "S. L. Tsao" 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: "S. L. Tsao" 
Subject:      Re: [MOBILE-IP] Mobile IP WG Agenda for IETF48
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Dear All,

Sorry for interrupting you.
I will present at the IETF48 meeting. The topic is about Mobile IPv4 /
Mobile IPv6 interworking(The title is "Mobility Support for IPv4 and IPv6
Interconnected Networks based on Dual-Stack Model"). My presentation is
based on the new I-D that we sumbitted serveral weeks ago. You can get it
from the following URL, if you are interested in it
http://www.ietf.org/internet-drafts/draft-tsao-mobileip-duelstack-model-00.t
xt

I appreciate your suggestions and comments. Thank you.

Shiao-Li Tsao


----- Original Message -----
From: Basavaraj Patil 
To: 
Sent: Tuesday, July 25, 2000 10:39 PM
Subject: [MOBILE-IP] Mobile IP WG Agenda for IETF48


> Agenda for Mobile IP at 48th IETF (Revised)
>
> First Session  Tuesday 1300-1515
> --------------------------------------------------
>
> WG Status and Agenda Bashing 10 min
>
> C. Perkins draft-ietf-mobileip-rfc2002-bis-02.txt 10min
>
> C. Perkins Regional Registration for IPv6 10min
>
> Claude Castellucia Hierarchical Mobile IPv6 -
> draft-castelluccia-mobileip-hmipv6-00.txt 15min
>
> Hesham Soliman - Hierarchical Mobile IPv6 -
> draft-ietf-mobileip-hmipv6-00.txt - 10 Mins
>
> Thierry Ernst - Extending MobileIPv6 with network scope Binding
> Updates - draft-ernst-mobileip-v6-network-00.txt 10min
>
> Shiao-Li Tsao Mobility Support for Dual Stack Systems 10min
>
> Discussion of handoff
>
> Second Session Wed 0900-1130
> -----------------------------------------------
>
> Discussion of handoff and output from handoff team 30min
>
> J. Malinen Mobile IP Regional Registrations
> draft-haverinen-mobileip-reg-pag-00.txt
> and Mobile IP GSM Sim Authenticaion
> draft-haverinen-mobileip-gsmsim-00.txt  - 15 Mins
>
> Dynamic Home Addressing draft-thuel-mobileip-tt-00.txt S. Thuel 10min
>
> Dynamic Home Address Allocation G. Dommety 10min (Tentative)
>
> A. Campbell P-MIP: Minimal Paging Extensions for Mobile IP - 10 Min
>
> V. Magret Multicast micro-mobility draft-magret-mobileip-mmm-00.txt -
> 10 Mins
>
> R. Ramjee HAWAII 5min
>
> Michael Wren Mobile IP and MPLS draft-zhong-mobile-ip-mpls-01.txt
> 10 Min
>
> C N Yap Mobile VPNs draft-sanchez-mvpn-00.txt 15 min


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Jul 26 03:44:55 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22610
	for ; Wed, 26 Jul 2000 03:44:55 -0400 (EDT)
Received: from standards (47.234.32.16:2257) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8194E@standards.nortelnetworks.com>; Wed, 26 Jul 2000 3:33:21 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 25189 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jul 2000 03:33:21
          -0400
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFB8194B@standards.nortelnetworks.com>; Wed, 26 Jul 2000 3:23:20
          -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 AAA04168
          for ; Wed, 26 Jul 2000
          00:34:15 -0700 (PDT)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.9.3/8.9.3-VIRSCAN) id AAA00865 for
          ; Wed, 26 Jul 2000 00:34:14
          -0700
X-Virus-Scanned:  Wed, 26 Jul 2000 00:34:14 -0700 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from jmalinen.iprg.nokia.com (205.226.2.98,
          claiming to be "iprg.nokia.com") by
          darkstar.iprg.nokia.com(WTS.12.69) smtpdqIISDM; Wed, 26 Jul 2000
          00:34:12 PDT
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
References: <4B6BC00CD15FD2119E5F0008C7A419A5089EB132@eaubrnt018.epa.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <397E9475.36547AF9@iprg.nokia.com>
Date:         Wed, 26 Jul 2000 00:34:13 -0700
Reply-To: jmalinen@IPRG.NOKIA.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: "Jari T. Malinen" 
Organization: Nokia
Subject:      Re: [MOBILE-IP] draft-malinen-mobileip-regreg6-00.txt
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello, Hesham,

Thanks for your comments, please find my remarks to them embedded below.

> Hello Jari,
>
> Please find below my response to your comparison with our draft.
> I will send another mail with some comments on your draft.
>
> Regards,
> Hesham
>
>
> > -  HA does not need to be regional-aware (or MAP-aware) as in Karim's
> >     I-D. The first packets from CN via HA to MN are re-capsulated at GMA
> >     via possible lower regional routers down to MN's autoconfigured on-link CoA.
> >     MN can recognize it needs to send a BU to CN from an encapsulated packet
> >     from CN, encapsulator being the access router.
>
> => That is an inaccurate observation. That's not the reason the HA has to
> add a routing header (if that's what you mean by regional-aware).
> The HA has to do that when it forwards packets that were addressed to an MN
> address that was not registered with the MAP.

Note that I commented your design in the first sentence and thereafter explained
ours to clarify Bechet's questions thereof. WRT your design I only wanted to note
that the HA inserts this routing header thus making it different from a plain
Mobile IPv6 HA. By regional-awareness I only refer to the fact that you need
to alter the HA for MAP to operate correctly in some cases (explained later).

> I might be wrong but I don't think you've addressed this problem in your
> draft. Therefore according to your proposal, other home addresses that
> the regional router is not aware of, will not be received by the MN as they
> will be dropped by the regional router.

Let me explain. In our design, other home addresses will not be dropped when no
regional entry exists. Note that in such a case, the GMA behaves like a normal
router. If the packet is targeted to the on-link CoA of the MN, this leads to
basic Mobile IPv6 behavior where gateway router is just like any other intermediate
router between HA and MN. If the HA tries to send to a regional CoA, the
entry is still in the GMA. It is the responsibility of the MN to make
sure that a regional binding cache entry in the GMA has a large enough
lifetime. And it is also the responsibility of the MN to register with
the GMA before traffic starts to arrive from remote nodes where MN registers
with a regional CoA. Furthermore, MN uses either regional or non-regional
CoA but not both simultaneously when sending binding updates out of the visited
domain.

> > After MN sent a BU with
> >     alternate CoA to CN, this can start sending route-optimized packets to MN
> >     via GMA. Inner packet AH is not touched in intermediate routers.
> >     Packets are forwarded locally in the visited domain and not from HA.
> >     We can thus do without using an additional routing header with tunneling.
>
> => I don't really understand how that affects our decision of adding a
> routing header. AH is not affected in our proposal either, end to end security is
> maintained. What you mention above is not related to adding a routing header from the
> HA. The routing header from the CN is mandatory according to MIPv6.

Again, I explain our design here. I only refer to MAP in how you describe
HA operation in your section 13. You use a routing entry to find home address.

Our forwarding only uses the binding cache, after which the destination
address is that of a lower CoA which is in its topologically correct place,
i.e. no mobility-specific additional routing entries are needed. Why have
extra routing state for home addresses when we have the binding cache entry,
in both designs, anyway?

> > - In our design, most of the data packets are neither tunneled nor
> >    host-routed (note also that signaling is not tunneled).
> >    Route-optimized packets towards the MN are forwarded in a special
> >    way based only on the regional binding cache.
>
> => If I understand that special way you refer to correctly, it is done by
> changing the destination address in the packet. I think it is dangerous
> to allow intermediate nodes to modify packets. I think tunnelling
> is a better way to go here.

If you look at RFC2460, the pseudo-code on page 16 explains how source
routing (consumption of routing headers in intermediate routers) changes
the destination IP address in the process (swap the IPv6 Destination Address
and Address[i]). In fact, this is a precedence for changing IPhdr destination
address in intermediate routers. We don't break this, we simply don't use it
for a very special kind of a routing header, that sent by users of basic
Mobile IPv6 route optimization and this only in regional-aware routers.

We use a different kind of forwarding (a regional binding cache based next
hop routing) which does not do anything more to the packet that source
routing would, it does less . When we can skip routing header processing this
even speeds up the IP forwarding. And we avoid the tunnelling overhead for
route-optimized packets which form the vast majority of data packets.

> > Normal processing of
> >    source-routed packets is skipped if there is a regional binding cache
> >    entry for the route-optimized home address in the regional CoA router
> >    receiving the packet. Only IPhdr destination is changed, AH prevails.
> >    The packet is then just forwarded to the lower CoA as seen in the
> >    regional binding cache.  Thus, no extra routing state is needed.
> >    This is much simpler than in Karim's proposal and is quite different
> >    from IPv4-solutions. Universal route optimization as provided in basic
> >    even possible in IPv4 due to its legacy CNs.
>
> => I don't understand why you chose not to process the routing header.
> This breaks RFC 2460 (IPv6 spec) for no reason.

First, a normal routing header processing would assume local knowledge
of home address routing. This would need the extra routing entry for the
home address when you process the routing header normally.

In our design, for the routing headers (from CNs or HAs) or even
for recapsulation, all we do is a regional binding cache lookup based
on home address which is used for all regional forwarding.

I do not consider our design choice a breach,
it is something new as was the introduction of binding cache -based
forwarding to HA in the basic Mobile IPv6. That "breaks" 2460 in that
it does not forward packets to the home link but to another address
based on MN's home binding. Our approach is analogous. For a special
mobility routing case we skip a part of 2460 to be more efficient in
header overhead and forwarding processing. Furthermore, we this way
localize this forwarding to a visited domain router.

Your HA Operation chapter 13 implies that this routing state exists and
for the cases that you explain,
"HA MUST include a routing header .. to enable the MAP to find the right
routing entry for the MN", which is what I meant by non-local forwarding
support (from the HA) for your visited-domain routing to operate correctly.

Additionally, as described in the AH RFC, IPhdr dstaddr is mutable but
predictable when a type 0 routing header is present. The check is done
for packet as seen after reception, that is, after applying routing header
in the final destination. With our design, we have the home address in
the DST field just like with basic Mobile IPv6.

Your design ends with the same, but with a bit more complicated routing
as described above. Our designs have similarities, but are not the same.
Having a convergence of some sort would be nice.. Would this call for
a framework for many regional/micro-mobility protocols or a simpler
common approach, what do you think?

It would be nice to continue discussing the options in Pittsburgh?


Best Regards,

-Jari


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Jul 26 04:13:11 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28865
	for ; Wed, 26 Jul 2000 04:13:10 -0400 (EDT)
Received: from standards (47.234.32.16:4927) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8197C@standards.nortelnetworks.com>; Wed, 26 Jul 2000 4:01:49 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 25256 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jul 2000 04:01:48
          -0400
Received: from omega.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB8197B@standards.nortelnetworks.com>; Wed, 26 Jul 2000 4:01:48
          -0400
Received: from gdommety-laptop1.cisco.com (gdommety-dsl3.cisco.com
          [10.19.17.140]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8)
          with ESMTP id BAA01564; Wed, 26 Jul 2000 01:12:14 -0700 (PDT)
X-Sender: gdommety@omega.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.20000726011201.00b0da10@omega.cisco.com>
Date:         Wed, 26 Jul 2000 01:13:58 -0700
Reply-To: Gopal Dommety 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: Gopal Dommety 
Subject:      Re: [MOBILE-IP] Handoff Discussions
X-To:         Basavaraj.Patil@NOKIA.COM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E070@daeis07nok>

At 02:28 PM 7/14/00 -0500, Basavaraj Patil wrote:
>Hi folks,
>
>         I see that you're all interested in handoff!  That's good.  The
>request for timeslots for handoff related topics would consume most of
>our time at this IETF so we're going to propose the following:
>
>Our goal at the end of this IETF meeting is to have a single draft for
>a working group item for handoff. (Two may be needed, perhaps a
>separate item for v4 and for v6).  To that end we would like the
>authors of the various handoff proposals and other interested WG
>members to work together and come up with a merger of some of the
>existing proposals, or a small set of proposals (such as two) from
>which the working group could pick one.
>
>Here's how we would like to structure the time for this.  Before the
>meeting we'd like the authors of the handoff drafts and other
>concerned parties to reach an agreement on some criteria that such a
>draft must meet and to compare your drafts to find common features and
>differences between the proposals (such as the dialogue that has been
>going on between Karim, Pat, James and others).  We'd like to allocate
>20 minutes in the first session to discuss handoff in the context of
>progress that has been made on this activity.  Between the two
>sessions we'd like a small group to go work offline to merge some
>proposals or pick one, or one or two for the group to decide upon.  In
>the second session we'd like to allocate 30 minutes to talk about the
>outcome of this activity, and a very short presentation of the one or
>two proposals that have been agreed upon.


It is a good idea. Since the first session is on Tue. How about interested
people
meet on Monday?

Thanks
Gopal


>Also remember that we would like as much as possible to be
>accomplished on the mailing list between now and July 31st.
>
>Comments?
>
>Cheers,
>the chairs.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Jul 26 05: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 FAA12127
	for ; Wed, 26 Jul 2000 05:12:16 -0400 (EDT)
Received: from standards (47.234.32.16:3754) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB819B2@standards.nortelnetworks.com>; Wed, 26 Jul 2000 5:00:50 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 25328 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jul 2000 05:00:50
          -0400
Received: from techtransfer.swift.shef.ac.uk by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB819B1@standards.nortelnetworks.com>; Wed, 26 Jul 2000 5:00:48
          -0400
X-Mailer: Lotus Notes Release 5.0.1a (Intl) 17 August 1999
X-MIMETrack: Serialize by Router on TechTransfer/Swift(Release 5.0.4 |June 8,
             2000) at 07/26/2000 10:11:45 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Message-ID:  
Date:         Wed, 26 Jul 2000 10:11:41 +0100
Reply-To: Matthias.Kraner@SWIFT.SHEF.AC.UK
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: Matthias Kraner 
Subject:      Re: [MOBILE-IP] Mobile IP WG Agenda for IETF48
X-To:         Basavaraj.Patil@NOKIA.COM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Short remark to Agenda:

Last item

"C N Yap Mobile VPNs draft-sanchez-mvpn-00.txt 15 min"

should be:

"Erika Snachez:  Mobile VPNs draft-sanchez-mvpn-00.txt 15 min"

Thanks

Matthias Kraner





                    Basavaraj Patil
                               To:     MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
                    Sent by: "IP Routing for              cc:
                    Wireless/Mobile Hosts                 Subject:     [MOBILE-IP] Mobile IP WG Agenda for IETF48
                    (mobile-ip)"
                    


                    25/07/2000 15:39
                    Please respond to
                    Basavaraj.Patil





Agenda for Mobile IP at 48th IETF (Revised)

First Session  Tuesday 1300-1515
--------------------------------------------------

WG Status and Agenda Bashing 10 min

C. Perkins draft-ietf-mobileip-rfc2002-bis-02.txt 10min

C. Perkins Regional Registration for IPv6 10min

Claude Castellucia Hierarchical Mobile IPv6 -
draft-castelluccia-mobileip-hmipv6-00.txt 15min

Hesham Soliman - Hierarchical Mobile IPv6 -
draft-ietf-mobileip-hmipv6-00.txt - 10 Mins

Thierry Ernst - Extending MobileIPv6 with network scope Binding
Updates - draft-ernst-mobileip-v6-network-00.txt 10min

Shiao-Li Tsao Mobility Support for Dual Stack Systems 10min

Discussion of handoff

Second Session Wed 0900-1130
-----------------------------------------------

Discussion of handoff and output from handoff team 30min

J. Malinen Mobile IP Regional Registrations
draft-haverinen-mobileip-reg-pag-00.txt
and Mobile IP GSM Sim Authenticaion
draft-haverinen-mobileip-gsmsim-00.txt  - 15 Mins

Dynamic Home Addressing draft-thuel-mobileip-tt-00.txt S. Thuel 10min

Dynamic Home Address Allocation G. Dommety 10min (Tentative)

A. Campbell P-MIP: Minimal Paging Extensions for Mobile IP - 10 Min

V. Magret Multicast micro-mobility draft-magret-mobileip-mmm-00.txt -
10 Mins

R. Ramjee HAWAII 5min

Michael Wren Mobile IP and MPLS draft-zhong-mobile-ip-mpls-01.txt
10 Min

C N Yap Mobile VPNs draft-sanchez-mvpn-00.txt 15 min


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Jul 26 06:29:14 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28820
	for ; Wed, 26 Jul 2000 06:29:14 -0400 (EDT)
Received: from standards (47.234.32.16:3926) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB81A15@standards.nortelnetworks.com>; Wed, 26 Jul 2000 6:17:48 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 25450 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jul 2000 06:17:47
          -0400
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFB81A0C@standards.nortelnetworks.com>; Wed, 26 Jul 2000 6:07:47
          -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 DAA13232
          for ; Wed, 26 Jul 2000
          03:18:42 -0700 (PDT)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.9.3/8.9.3-VIRSCAN) id DAA13630 for
          ; Wed, 26 Jul 2000 03:18:41
          -0700
X-Virus-Scanned:  Wed, 26 Jul 2000 03:18:41 -0700 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from jmalinen.iprg.nokia.com (205.226.2.98,
          claiming to be "iprg.nokia.com") by
          darkstar.iprg.nokia.com(WTS.12.69) smtpd5xKn4Y; Wed, 26 Jul 2000
          03:18:38 PDT
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
References: <4B6BC00CD15FD2119E5F0008C7A419A5089EB132@eaubrnt018.epa.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <397EBAFF.7C5A0017@iprg.nokia.com>
Date:         Wed, 26 Jul 2000 03:18:39 -0700
Reply-To: jmalinen@IPRG.NOKIA.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: "Jari T. Malinen" 
Organization: Nokia
Subject:      Re: [MOBILE-IP] draft-malinen-mobileip-regreg6-00.txt
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi, Hesham,

> Hi Jari,
>
> I agree with Claude's comments regarding the sending of BUs.

Since I am not sure which of Claude's comments you refer to, I'll address both.

About sending BUs directly to the GMA, with a local model we distribute
the load down to the hierarchy as explained at end of this mail.

About autoconfiguration of GCoA,
if we compare HMIPv6 and ours, both use a link-address to for
local communication. HMIPv6 calls this PCoA. This takes one autoconfiguration.

In addition to that, HMIPv6 favors another autoconfiguration for the GCoA.

But with the regional binding cache -based forwarding, our regional
CoA can be static. We save the second autoconfiguration overhead with its
DAD operation etc. Our regional CoA can be re-used by many MNs since it is not
a real address on MN's link but an address in a GMA. This address is defended
against re-use by GMA. Inbound packets to MNs' home addresses are forwarded
with the lower CoAs to the correct MN. No address deletion from advertisements
thus no housekeeping for this is needed. In fact, we can do with only one constant
regional CoA in the advertisement re-used by all MNs. If MN-based selection is
desired, several regional CoAs can be advertised.

Can you explain more why we need the second autoconfiguration.

> Here are some more comments on your reply below
>
> Hesham
>
> > In HMIP, since the GCoA is build by concatening the MS prefix and EUI64, address
> > collision is very unlikely (but the MS verifies the unicity of the address by
> > performing a DaD on its link). Why don't you use the nice IPv6
> > autoconfiguration capability?
> >
> > This is for efficiency reasons, if the GCoA does not usually need to be
> > configured
> > at all, no delay occurs. However, your comment brings to mind that
> > renumbering
> > should cause reconfiguration of access router advertisements.
> > At this moment we limited hierarchy reconfiguration (dynamic knowledge of
> > regional
> > care-of-addresses, children, and father) out of scope, however. This can be done
> > with a separate protocol extension for these hopefully infrequent events, including
> > renumbering.

> =>I don't really see a need for new protocols to handle renumbering. In our
> proposal (and I blieve in Claude's one too) the renumbering is handled
> automatically because the rtr adv will announce new MAP addresses (in our
> case) or new prefixes (in Claude's draft).
> I think the basic IPv6 functionality in this case is certainly enough
> and provides very flexible and generic mechanisms without introducing
> more protocols. The less complexity, the better IMO.

In fact, I did not find specific description in MAP about what happens in
renumbering, how exactly is the knowledge of this distributed to the routers
advertising MAP? Since MAP is a specific sub-option to the router advertisement,
IPv6 will not automatically provide this. In this sense I do not think we have
very different approach..

> > > I have another question: why does a mobile host  send its regionalized BU
> > > to the access router instead of sending it directly to the closed Regional
> > > MA as we do (the RMA address could be advertised in the router adv.)?
> > > This would  provide more flexibility in the deployement of the Regional-aware
> > > routers (they don't have to be on a tree anymore)...
>
> > A region is naturally a hierarchy and in our model the network decides on the
> > crossover router (the highest guy changing its binding cache and answering
> > to this BU) thus distributing the signalling load down to the hierarchy.
>
> =>I don't see how the signalling load is distributed from a router's
> point of view. Every router in the heirarchy will still receive a BU.
> So the only difference is in our case (and again Claude's draft),
> is that the MN is aware who's receiving the BU. Which is what MIPv6 says,
> and I think that is a cleaner way to do it and less complex.

Not every BU goes to all routers in our model. If MN moves between adjacent
branches in a subtree, that BU propagates only to the crossover, not up to the
GMA. If you move frequently between these two only, signaling load is distributed
down from the GMA to the crossover. Tunneling directly to the MAP behaves like a
shallow (2-level) hierarchy. Our design provides optimization from the depth of
hierarchy even without changing the GMA.

Best Regards,

-Jari


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Jul 26 07:00: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 HAA06532
	for ; Wed, 26 Jul 2000 07:00:50 -0400 (EDT)
Received: from standards (47.234.32.16:3926) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB81A47@standards.nortelnetworks.com>; Wed, 26 Jul 2000 6:49:12 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 25526 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jul 2000 06:49:12
          -0400
Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFB81A42@standards.nortelnetworks.com>; Wed, 26 Jul 2000 6:39:11
          -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org
          (8.9.1a/8.9.1a) with ESMTP id GAA03413; Wed, 26 Jul 2000 06:50:06
          -0400 (EDT)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Message-ID:  <200007261050.GAA03413@ietf.org>
Date:         Wed, 26 Jul 2000 06:50:05 -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-reg-tunnel-03.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           : Mobile IP Regional Registration
        Author(s)       : E. Gustafsson, A. Jonsson, C. Perkins
        Filename        : draft-ietf-mobileip-reg-tunnel-03.txt
        Pages           : 33
        Date            : 25-Jul-00

Using Mobile IP, a mobile node registers with its home agent each
time it changes care-of address.  If the distance between the
visited network and the home network of the mobile node is large,
the signaling delay for these registrations may be long.  We propose
a new kind of 'regional' registration, i.e., registration local to
the visited domain.  Regional registrations reduce the number of
signaling messages to the home network, and reduce the signaling
delay when a mobile node moves from one foreign agent to another,
within the same visited domain.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-reg-tunnel-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-mobileip-reg-tunnel-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-mobileip-reg-tunnel-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.

--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:     <20000725113137.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mobileip-reg-tunnel-03.txt

--OtherAccess
Content-Type: Message/External-body;
        name="draft-ietf-mobileip-reg-tunnel-03.txt";
        site="ftp.ietf.org";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <20000725113137.I-D@ietf.org>

--OtherAccess--

--NextPart--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Jul 26 07:42: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 HAA15970
	for ; Wed, 26 Jul 2000 07:42:23 -0400 (EDT)
Received: from standards (47.234.32.16:3926) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB81A7F@standards.nortelnetworks.com>; Wed, 26 Jul 2000 7:30:53 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 25600 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jul 2000 07:30:53
          -0400
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFB81A78@standards.nortelnetworks.com>; Wed, 26 Jul 2000 7:20:52
          -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 EAA16586
          for ; Wed, 26 Jul 2000
          04:31:48 -0700 (PDT)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.9.3/8.9.3-VIRSCAN) id EAA04040 for
          ; Wed, 26 Jul 2000 04:31:46
          -0700
X-Virus-Scanned:  Wed, 26 Jul 2000 04:31:46 -0700 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from jmalinen.iprg.nokia.com (205.226.2.98,
          claiming to be "iprg.nokia.com") by
          darkstar.iprg.nokia.com(WTS.12.69) smtpdVWoCfW; Wed, 26 Jul 2000
          04:31:44 PDT
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
References: <4B6BC00CD15FD2119E5F0008C7A419A5089EB136@eaubrnt018.epa.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <397ECC21.9CAE2B59@iprg.nokia.com>
Date:         Wed, 26 Jul 2000 04:31:45 -0700
Reply-To: jmalinen@IPRG.NOKIA.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: "Jari T. Malinen" 
Organization: Nokia
Subject:      Re: [MOBILE-IP] draft-malinen-mobileip-regreg6-00.txt
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello, Hesham,

Thanks again for your comments,

> Hello Jari and Charlie,
>
> After reading your draft on regional registration for IPv6, I
> came up with the following comments.
>
> General comment:
>
>
> I believe mandating hop by hop encapsulation-decapsulation between
> regional routers will have the following effects:
>
> - We end up with a reserved path in the network, hence you lose
> the inherent redundancy that we get with IP routing. ie. if one
> of the regional aware routers crash, the MN won't receive anything.

This path maintains soft state so it recovers after timeout.. If access
router fails, there is not much difference from basic Mobile IPv6 in failure
behavior. Actually, the design is as flexible as basic Mobile IPv6.
On the other hand, maintaining redundant home address -based tunnels or
host routes would require a routing protocol.

Additionally, using direct access from MAP to
access routers reduces us to a shallow hierarchy case of Mobile IPv6
regional registrations. MN-specific route- or hierarchy configuration
maintenance wuold need to be a separate protocol, ours describes the
mobility transport in a given hierarchy. Separating these problems
might lead to an EMA-style hierarchy/mesh management with an efficient
mobility transport part, perhaps..

> - Encapsulation-decapsulation at each node adds extra and unnecessary
> delays.

Note that only very few first packets are recapsulated, most of data
packets are route-optimized. See my earlier mail explaining how we
have an efficient forwarding in that case. Recapsulation is perhaps not
optimal, but adding an IPv6 header is straightforward and even fast
if done based on the regional binding cache. Even MAP recapsulates at
the root of hierarchy.

> BTW our draft allows the same scenario, but it also allows the MN
> to receive directly from the MAP. So there is a choice and it
> depends on the MNs preferences / configuration.

This is what you basically get with a shallow (access routers and a
GMA) hierarchy. Configurable in our solution, too. Adjacent regional
routers can have non-regional routers between which reduces the
solutions quite the same wrt. this issue.

> Other comments:
>
> - I believe propagating the BU  in the hierarchy breaks the basic
> design of MIPv6. Furthermore, it is not clear from the draft
> how you can maintain the SA between the MN and each regional router
> if the MN doesn't know they exist. As I understood it, the destination
> address of the BU is the access router on the same link as the MN.
> I assume from ch 7 that you will do some sort of key distribution
> protocol. I still can't see how that would work and more importanly
> don't see the need for it.
> It seems this would add extra complexity / protocols, for no apparent
> benefit.
> Please elaborate if I missed something here.

Reasoning:
Hiding a deep hierarchy allows for short advertisement (e.g. only 1 RCoA),
maintaining stateless network-controlled crossover selection leads to
scalability down the hierarchy without changing the RCoA. This leads to
the hop-by-hop forwarding. With right security association generation it
is doable. Adding AAA brings a key distribution component,
having a group key in the visited domain provides initial association
for intra-domain key propagation and subsequently BU propagation. MN
initiates the propagation and with a session key shared by potential
recipients the SA is predictable, network-controlled crossover selection
can be made with signaling security.

> - It is unclear to me how the regional BAck is processed. The draft assumes
> there is only one sent back. Is it propagated down the hierarchy ?
> If so then how would the SA work ?
> If not then what happens if one router fails and the others succeed?

It must go the same path down, with MN-visted-domain association the
SA exists there, AHs are different on different hops.

> - By not processing the routing header in the regional router, you
> are breaking the extension header processing rules in RFC 2460.
> I also don't see why this is necessary.

See my comments in a previous mail on our regional-aware data
forwarding.

> - I have some concerns about the way the inbound packets are routed
> within the hierarchy. You mention encapsulation in the draft, but
> when it is described it doesn't actually say the same thing. It seems
> that the destination address is modified in the original packet.
> I know that end to end AH will still work, but this is not a normal
> IPv6 stack behaviour and I don't see why it is necessary.

This also with motivation in the previous mail. Recapsulation for tunneled
packets, regional forwarding for route-optimized packets.

> - If the MN decides to register its alt-COA with the HA. I believe
> any Site-local packets forwarded by the HA to the MNs COA will be
> dropped by the regional router (ie. the owner of the COA).
> That's one of the reasons we attach a routing header between the HA
> and the MAP.

With our regional binding cache -based forwarding we can forward those
addresses we like. Site-local addresses must be registered
separately. If these are in regional binding cache then our implementation
does forwarding, lower RCoAs are not that address so real routing engine
does not drop these, delivery occurs locally from last CoA (on-link on MN)
to the site-local address. Proxying addresses from below works for our
benefit here.

> Regards,
> Hesham

Best Regards,

-Jari


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Jul 26 09:07:37 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06144
	for ; Wed, 26 Jul 2000 09:07:37 -0400 (EDT)
Received: from standards (47.234.32.16:3926) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB81B63@standards.nortelnetworks.com>; Wed, 26 Jul 2000 8:56:04 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 25911 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jul 2000 08:56:04
          -0400
Received: from ebene.inrialpes.fr by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB81B62@standards.nortelnetworks.com>; Wed, 26 Jul 2000 8:56:03
          -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 PAA02605; Wed, 26 Jul
          2000 15:06:56 +0200 (MET DST)
Received: from inrialpes.fr (localhost [127.0.0.1]) by iseran.inrialpes.fr
          (8.8.7/8.8.5) with ESMTP id PAA03590; Wed, 26 Jul 2000 15:06:55 +0200
          (MET DST)
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <4B6BC00CD15FD2119E5F0008C7A419A5089EB132@eaubrnt018.epa.ericsson.se>
            <397EBAFF.7C5A0017@iprg.nokia.com>
Content-Type: multipart/alternative;
              boundary="------------6E3684BC46C83B9736FD1BE9"
Message-ID:  <397EE26F.E091A665@inrialpes.fr>
Date:         Wed, 26 Jul 2000 15:06:55 +0200
Reply-To: Claude.Castelluccia@INRIALPES.FR
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: Claude Castelluccia 
Subject:      Re: [MOBILE-IP] draft-malinen-mobileip-regreg6-00.txt
X-To:         jmalinen@IPRG.NOKIA.COM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

--------------6E3684BC46C83B9736FD1BE9
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hello Jari,

here follows some comments...

"Jari T. Malinen" wrote:

> About autoconfiguration of GCoA,
> if we compare HMIPv6 and ours, both use a link-address to for
> local communication. HMIPv6 calls this PCoA. This takes one autoconfiguration.
>
> In addition to that, HMIPv6 favors another autoconfiguration for the GCoA.
>
> But with the regional binding cache -based forwarding, our regional
> CoA can be static. We save the second autoconfiguration overhead with its
> DAD operation etc.

I don't follow you! If you really think that there is a high overhead due to
autoconfiguration
you should  also (and mainly) try to avoid the first autoconfiguration (for the PCoA)...
The GCoA autoconfiguration happens only once when the MH moves into a new domain while
the PCoA autoconfig. happens at each movement which is without doubt much  more costly...


> Our regional CoA can be re-used by many MNs since it is not
> a real address on MN's link but an address in a GMA. This address is defended
> against re-use by GMA. Inbound packets to MNs' home addresses are forwarded
> with the lower CoAs to the correct MN. No address deletion from advertisements
> thus no housekeeping for this is needed. In fact, we can do with only one constant
> regional CoA in the advertisement re-used by all MNs. If MN-based selection is
> desired, several regional CoAs can be advertised.
>
> Can you explain more why we need the second autoconfiguration.
>

mainly if MN-based selection is desired. You then do not have to send  a list of addresses
in the Rt. adv.
And I see may good reasons to attribute a different GCoA per MH.

1- the MAP is merely a HA (it uses the same proxy mechanisms...no more no less). It is
very easy to implement.
2- Since the MAP get the PCoA only by looking at the destination address of incoming
packets, all packets will be forwarded to the MH without
having to look for the HomeAddress inside the packets   (As a result even an ICMP packets
that could
be generated for a packet with the source address set to a GCoA will be directly
encapsulated to the MH's PCoA...).. this is much simpler.
3- In our IPv6 implementation (the one from F.Dupont INRIA) a DaD is performed even if the
address is not autoconfigured (i.e.
obtained via a router advertissement). We therefore cannot attribute the same GCoA to 2
different MHs on the same link without
hacking the kernel...
4- The Source Address field (that can be set to the GCoA) could be used by other protocols
to perform some traffic shaping, policing,
control, billing, etc...it is therefore useful to be able to assign different GCoA to the
different MHs...



> In fact, I did not find specific description in MAP about what happens in
> renumbering, how exactly is the knowledge of this distributed to the routers
> advertising MAP? Since MAP is a specific sub-option to the router advertisement,
> IPv6 will not automatically provide this. In this sense I do not think we have
> very different approach..
>

In our HMIPv6 (INRIA one), we use a protocol between the MS (MAP) and the access routers
to distribute/update the MAP address ....

regards,

Claude.


--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/



--------------6E3684BC46C83B9736FD1BE9
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



 

Hello Jari,

here follows some comments...

"Jari T. Malinen" wrote:

About autoconfiguration of GCoA,

if we compare HMIPv6 and ours, both use a link-address to for

local communication. HMIPv6 calls this PCoA. This takes one autoconfiguration.

In addition to that, HMIPv6 favors another autoconfiguration for the
GCoA.

But with the regional binding cache -based forwarding, our regional

CoA can be static. We save the second autoconfiguration overhead with
its

DAD operation etc.

I don't follow you! If you really think that there is a high overhead
due to autoconfiguration

you should  also (and mainly) try to avoid the first autoconfiguration
(for the PCoA)...

The GCoA autoconfiguration happens only once when the MH moves
into a new domain while

the PCoA autoconfig. happens at each movement which is without doubt
much  more costly...

 

Our regional CoA can be re-used by many MNs since
it is not

a real address on MN's link but an address in a GMA. This address is
defended

against re-use by GMA. Inbound packets to MNs' home addresses are forwarded

with the lower CoAs to the correct MN. No address deletion from advertisements

thus no housekeeping for this is needed. In fact, we can do with only
one constant

regional CoA in the advertisement re-used by all MNs. If MN-based selection
is

desired, several regional CoAs can be advertised.

Can you explain more why we need the second autoconfiguration.

 

mainly if MN-based selection is desired. You then do not have to send 
a list of addresses in the Rt. adv.

And I see may good reasons to attribute a different GCoA per MH.

1- the MAP is merely a HA (it uses the same proxy mechanisms...no
more no less). It is very easy to implement.

2- Since the MAP get the PCoA only by looking at the destination
address of incoming packets, all packets will be forwarded to the MH without

having to look for the HomeAddress inside the packets   (As
a result even an ICMP packets that could

be generated for a packet with the source address set to a GCoA will
be directly encapsulated to the MH's PCoA...).. this is much simpler.

3- In our IPv6 implementation (the one from F.Dupont INRIA) a DaD is
performed even if the address is not autoconfigured (i.e.

obtained via a router advertissement). We therefore cannot attribute
the same GCoA to 2 different MHs on the same link without

hacking the kernel...

4- The Source Address field (that can be set to the GCoA) could be
used by other protocols to perform some traffic shaping, policing,

control, billing, etc...it is therefore useful to be able to assign
different GCoA to the different MHs...

 

 

In fact, I did not find specific description in MAP
about what happens in

renumbering, how exactly is the knowledge of this distributed to the
routers

advertising MAP? Since MAP is a specific sub-option to the router advertisement,

IPv6 will not automatically provide this. In this sense I do not think
we have

very different approach..

 

In our HMIPv6 (INRIA one), we use a protocol between the MS (MAP) and
the access routers

to distribute/update the MAP address ....

regards,

Claude.

 

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

 

--------------6E3684BC46C83B9736FD1BE9--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Jul 26 09:49: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 JAA13978
	for ; Wed, 26 Jul 2000 09:49:14 -0400 (EDT)
Received: from standards (47.234.32.16:2520) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB81BBA@standards.nortelnetworks.com>; Wed, 26 Jul 2000 9:37:48 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 26035 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jul 2000 09:37:47
          -0400
Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1b) with SMTP id <0.FFB81BB9@standards.nortelnetworks.com>;
          Wed, 26 Jul 2000 9:37: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 HAA18234; Wed, 26 Jul 2000 07:48:41
          -0600 (MDT)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by
          engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id
          GAA27623; Wed, 26 Jul 2000 06:48:39 -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 GAA02636; Wed, 26 Jul 2000 06:48:38
          -0700 (PDT)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Message-ID:  
Date:         Wed, 26 Jul 2000 06:47: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] Handoff Discussions
X-To:         Gopal Dommety 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  "Your message with ID"
              <4.3.1.2.20000726011201.00b0da10@omega.cisco.com>

>It is a good idea. Since the first session is on Tue. How about interested
>people
>meet on Monday?

How about dinner on Monday? We could all meet at the IETF registration...

PatC


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Jul 26 09:55: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 JAA15098
	for ; Wed, 26 Jul 2000 09:55:32 -0400 (EDT)
Received: from standards (47.234.32.16:2520) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB81BE3@standards.nortelnetworks.com>; Wed, 26 Jul 2000 9:44:11 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 26028 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jul 2000 09:44:11
          -0400
Received: from ftpbox.mot.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB81BB4@standards.nortelnetworks.com>; Wed, 26 Jul 2000 9:34:11
          -0400
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by
          ftpbox.mot.com (ftpbox 2.1) with ESMTP id GAA25283 for
          ; Wed, 26 Jul 2000 06:45:05
          -0700 (MST)]
Received: [from il75exm02.cig.mot.com (IL75EXM02.cig.mot.com [136.182.110.102])
          by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id GAA24769 for
          ; Wed, 26 Jul 2000 06:45:05
          -0700 (MST)]
Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2650.21) id
          ; Wed, 26 Jul 2000 08:45:05 -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, 26 Jul 2000 08:45:02 -0500
Reply-To: Roberts Phil-QA3445 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: Roberts Phil-QA3445 
Subject:      [MOBILE-IP] handoff breakout session
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hi folks,

    we're planning to have a breakout session on Monday night to discuss
handoff.  We've requested a room but haven't heard anything back.  We'd like
the session to include the authors of the various handoff proposals and try
to work together to come to some agreements about the commonalities and
differences between the different proposals and nominate one or a couple of
people to give summaries to the working group on Tuesday.  We'd like to keep
this session really small, so mainly just the handoff draft authors and the
working group chairs.

   As soon as we find out about a room we'll post details on the list.

Phil


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Jul 26 12:34:04 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16773
	for ; Wed, 26 Jul 2000 12:34:03 -0400 (EDT)
Received: from standards (47.234.32.16:3150) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB81D11@standards.nortelnetworks.com>; Wed, 26 Jul 2000 12:22:28 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 26463 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jul 2000 12:22:28
          -0400
Received: from nsmail.corp.globalstar.com (gibraltar.globalstar.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB81CFE@standards.nortelnetworks.com>; Wed, 26 Jul 2000
          12:12:28 -0400
Received: from globalstar.com ([207.88.153.18]) by nsmail.corp.globalstar.com
          (Netscape Messaging Server 3.6) with ESMTP id AAA4EDC for
          ; Wed, 26 Jul 2000 09:22:43
          -0700
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------47492C6195A36B01DE421891"
Message-ID:  <397F1085.AFCC5B89@globalstar.com>
Date:         Wed, 26 Jul 2000 09:23:33 -0700
Reply-To: Jonathan.Chan@globalstar.com
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: Jonathan Chan 
Organization: Globalstar
Subject:      [MOBILE-IP] subscribe
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.
--------------47492C6195A36B01DE421891
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

subscribe

--
    \||/
___m(..)m___


--------------47492C6195A36B01DE421891
Content-Type: text/x-vcard; charset=us-ascii;
 name="Jonathan.Chan.vcf"
Content-Description: Card for Jonathan Chan
Content-Disposition: attachment;
 filename="Jonathan.Chan.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard
n:Chan;Jonathan
tel;work:408/933-4685
x-mozilla-html:TRUE
url:http://www.globalstar.com
org:Globalstar
version:2.1
email;internet:jonathan.chan@globalstar.com
adr;quoted-printable:;;3200 Zanker Road, Bldg #220,=0D=0A;San Jose;CA;95134;United States
x-mozilla-cpt:;-17712
fn:Jonathan Chan
end:vcard

--------------47492C6195A36B01DE421891--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Jul 26 13:25:47 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25836
	for ; Wed, 26 Jul 2000 13:25:47 -0400 (EDT)
Received: from standards (47.234.32.16:2933) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB81D5E@standards.nortelnetworks.com>; Wed, 26 Jul 2000 13:14:18 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 26592 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jul 2000 13:14:17
          -0400
Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1b) with SMTP id <0.FFB81D5D@standards.nortelnetworks.com>;
          Wed, 26 Jul 2000 13:14:17 -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 LAA01792; Wed, 26 Jul 2000 11:25:11
          -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
          KAA22476; Wed, 26 Jul 2000 10:25:10 -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 KAA07729; Wed, 26
          Jul 2000 10:25:02 -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:  <200007261725.KAA07729@nasnfs.eng.sun.com>
Date:         Wed, 26 Jul 2000 13:27:13 -0400
Reply-To: James.Kempf@Eng.Sun.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: James Kempf 
Subject:      Re: [MOBILE-IP] handoff breakout session
X-To:         Roberts Phil-QA3445 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Phil,

Do you want us to sign up for presentations or should it just be ad hoc?

                jak
>Hi folks,
>
>    we're planning to have a breakout session on Monday night to discuss
>handoff.  We've requested a room but haven't heard anything back.  We'd like
>the session to include the authors of the various handoff proposals and try
>to work together to come to some agreements about the commonalities and
>differences between the different proposals and nominate one or a couple of
>people to give summaries to the working group on Tuesday.  We'd like to keep
>this session really small, so mainly just the handoff draft authors and the
>working group chairs.
>
>   As soon as we find out about a room we'll post details on the list.
>
>Phil


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Jul 26 13:33: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 NAA27876
	for ; Wed, 26 Jul 2000 13:33:15 -0400 (EDT)
Received: from standards (47.234.32.16:2933) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB81D8C@standards.nortelnetworks.com>; Wed, 26 Jul 2000 13:21:36 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 26656 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jul 2000 13:21:36
          -0400
Received: from omega.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB81D8B@standards.nortelnetworks.com>; Wed, 26 Jul 2000 13:21:35
          -0400
Received: from gdommety-laptop1.cisco.com (dhcp-171-70-57-32.cisco.com
          [171.70.57.32]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8)
          with ESMTP id KAA12605; Wed, 26 Jul 2000 10:31:16 -0700 (PDT)
X-Sender: gdommety@omega.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
References: <"Your message with ID"
            <4.3.1.2.20000726011201.00b0da10@omega.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.3.1.2.20000726103535.00b182d0@omega.cisco.com>
Date:         Wed, 26 Jul 2000 10:35:48 -0700
Reply-To: Gopal Dommety 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: Gopal Dommety 
Subject:      Re: [MOBILE-IP] Handoff Discussions
X-To:         "pcalhoun@eng.sun.com" 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  

At 06:47 AM 7/26/00 -0700, pcalhoun@eng.sun.com wrote:
> >It is a good idea. Since the first session is on Tue. How about interested
> >people
> >meet on Monday?
>
>How about dinner on Monday? We could all meet at the IETF registration...

That sounds good.

-Gopal


>PatC


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Jul 26 13:37:19 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29138
	for ; Wed, 26 Jul 2000 13:37:18 -0400 (EDT)
Received: from standards (47.234.32.16:2933) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB81DA5@standards.nortelnetworks.com>; Wed, 26 Jul 2000 13:23:52 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 26689 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jul 2000 13:23:52
          -0400
Received: from motgate3.mot.com (144.189.100.103:37513) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB81DA4@standards.nortelnetworks.com>; Wed, 26 Jul 2000
          13:23:52 -0400
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by
          motgate3.mot.com (motgate3 2.1) with ESMTP id KAA15154 for
          ; Wed, 26 Jul 2000 10:33:20
          -0700 (MST)]
Received: [from il75exm02.cig.mot.com (IL75EXM02.cig.mot.com [136.182.110.102])
          by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id KAA01746 for
          ; Wed, 26 Jul 2000 10:34:43
          -0700 (MST)]
Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2650.21) id
          ; Wed, 26 Jul 2000 12:34:43 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  
Date:         Wed, 26 Jul 2000 12:34:39 -0500
Reply-To: Roberts Phil-QA3445 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: Roberts Phil-QA3445 
Subject:      Re: [MOBILE-IP] Handoff Discussions
X-To:         "pcalhoun@eng.sun.com" 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

I think dinner is a good idea.  I'd like to have a small room with some sort
of writing surface for afterwards though as I imagine there will be some
discussion where we'll want to be able to draw to explain.

I've had a few requests from people who are not authors who would like to
attend.  I'd like to allow this but don't know what kind of room we'll be
able to get.  For now please just the authors of handover drafts that made
it in before the deadline plan to attend.  If we get a room that's big
enough we'll make it more open.



> -----Original Message-----
> From: pcalhoun@eng.sun.com [mailto:Pat.Calhoun@ENG.SUN.COM]
> Sent: Wednesday, July 26, 2000 8:48 AM
> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: [MOBILE-IP] Handoff Discussions
>
>
> >It is a good idea. Since the first session is on Tue. How
> about interested
> >people
> >meet on Monday?
>
> How about dinner on Monday? We could all meet at the IETF
> registration...
>
> PatC
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Jul 26 13:44:27 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01542
	for ; Wed, 26 Jul 2000 13:44:27 -0400 (EDT)
Received: from standards (47.234.32.16:2933) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB81DE8@standards.nortelnetworks.com>; Wed, 26 Jul 2000 13:32:59 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 26783 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jul 2000 13:32:58
          -0400
Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1b) with SMTP id <0.FFB81DE7@standards.nortelnetworks.com>;
          Wed, 26 Jul 2000 13:32:58 -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 LAA00528 for
          ; Wed, 26 Jul 2000 11:43:46
          -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
          KAA22034; Wed, 26 Jul 2000 10:23:28 -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 KAA07683; Wed, 26
          Jul 2000 10:23:17 -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:  <200007261723.KAA07683@nasnfs.eng.sun.com>
Date:         Wed, 26 Jul 2000 13:25:31 -0400
Reply-To: James.Kempf@eng.sun.com
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: James Kempf 
Subject:      Re: [MOBILE-IP] Handoff Discussions
X-To:         "pcalhoun@eng.sun.com" 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Fine by me. What time?

                        jak
>>It is a good idea. Since the first session is on Tue. How about interested
>>people
>>meet on Monday?
>
>How about dinner on Monday? We could all meet at the IETF registration...
>
>PatC


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Jul 26 16:50:20 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15493
	for ; Wed, 26 Jul 2000 16:50:20 -0400 (EDT)
Received: from standards (47.234.32.16:2127) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB81E92@standards.nortelnetworks.com>; Wed, 26 Jul 2000 16:38:29 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 26998 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jul 2000 16:38:28
          -0400
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFB81E8B@standards.nortelnetworks.com>; Wed, 26 Jul 2000 16:28:28
          -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 NAA07609
          for ; Wed, 26 Jul 2000
          13:39:25 -0700 (PDT)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.9.3/8.9.3-VIRSCAN) id NAA05694 for
          ; Wed, 26 Jul 2000 13:39:22
          -0700
X-Virus-Scanned:  Wed, 26 Jul 2000 13:39:22 -0700 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from jmalinen.iprg.nokia.com (205.226.2.98,
          claiming to be "iprg.nokia.com") by
          darkstar.iprg.nokia.com(WTS.12.69) smtpdPxSfwq; Wed, 26 Jul 2000
          13:39:19 PDT
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
References: <4B6BC00CD15FD2119E5F0008C7A419A5089EB132@eaubrnt018.epa.ericsson.se> <397EBAFF.7C5A0017@iprg.nokia.com>
            <397EE26F.E091A665@inrialpes.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <397F4C78.DEA27ABF@iprg.nokia.com>
Date:         Wed, 26 Jul 2000 13:39:20 -0700
Reply-To: jmalinen@IPRG.NOKIA.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: "Jari T. Malinen" 
Organization: Nokia
Subject:      Re: [MOBILE-IP] draft-malinen-mobileip-regreg6-00.txt
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello, Claude,

Some comments still..
Maybe the discussion could be continued in Pittsburgh, over dinner,
for example, in trying to figure out tradeoffs / missing pieces,
convergence possiblities, in a very small group looking at the IPv6
regional / hierarchical mobility problem?

> > But with the regional binding cache -based forwarding, our regional
> > CoA can be static. We save the second autoconfiguration overhead with its
> > DAD operation etc.
>
> I don't follow you! If you really think that there is a high overhead due to
> autoconfiguration
> you should  also (and mainly) try to avoid the first autoconfiguration (for the PCoA)...
> The GCoA autoconfiguration happens only once when the MH moves into a new domain while
> the PCoA autoconfig. happens at each movement which is without doubt much  more costly...

Agreed that the elimination of PCoA autoconfig would win more. I am not sure
if any of the three discussed designs completely achieves that since you seem
to use it for intra-visited-domain CN communication at least. But you have a
point here, this would be nice.


> > Can you explain more why we need the second autoconfiguration.
>
>
> mainly if MN-based selection is desired. You then do not have to send  a list of
> addresses in the Rt. adv. And I see may good reasons to attribute a different
> GCoA per MH.

> 1- the MAP is merely a HA (it uses the same proxy mechanisms...no more no less). It is
> very easy to implement.

Ours can do with even less than that since we don't need the proxying, the
GCoA is already statically there. We also otherwise exploit the HA functionality.

> 2- Since the MAP get the PCoA only by looking at the destination address of incoming
> packets, all packets will be forwarded to the MH without
> having to look for the HomeAddress inside the packets   (As a result even an ICMP packets
> that could
> be generated for a packet with the source address set to a GCoA will be directly
> encapsulated to the MH's PCoA...).. this is much simpler.

Note also that packets coming from MN have the on-link CoA as source causing
the ICMP most likely to have a target different from the GCoA. Our lookup is really
nothing much more a routing engine would do (IPdst for tunneled, routing header IP for
optimized packets).

> 3- In our IPv6 implementation (the one from F.Dupont INRIA) a DaD is performed even if the
> address is not autoconfigured (i.e.
> obtained via a router advertissement). We therefore cannot attribute the same GCoA to 2
> different MHs on the same link without hacking the kernel...
>
> 4- The Source Address field (that can be set to the GCoA) could be used by other protocols
> to perform some traffic shaping, policing,
> control, billing, etc...it is therefore useful to be able to assign different GCoA to the
> different MHs...

Source address field in our model is distinct at GMA, it only overlaps in the
hierarchy. For traffic control one might also consider outgoing address, with mobility
and billing, a registration identity (e.g. a NAI) rather than the source IP.

> regards,
>
> Claude.

Best Regards,

-Jari


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Jul 26 18:33: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 SAA14571
	for ; Wed, 26 Jul 2000 18:33:56 -0400 (EDT)
Received: from standards (47.234.32.16:2843) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB81F4D@standards.nortelnetworks.com>; Wed, 26 Jul 2000 18:22:28 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 27234 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jul 2000 18:22:28
          -0400
Received: from babbage.ececs.uc.edu (ececs.uc.edu) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB81F39@standards.nortelnetworks.com>; Wed, 26 Jul 2000
          18:12:28 -0400
Received: from wayward.ececs.uc.edu (wayward.ececs.uc.edu [129.137.9.117]) by
          babbage.ececs.uc.edu (8.10.2/8.10.2) with ESMTP id e6QMNNL16646 for
          ; Wed, 26 Jul 2000 18:23:23
          -0400 (EDT)
Received: (from sdas@localhost) by wayward.ececs.uc.edu (8.9.3+Sun/8.9.1) id
          SAA25697 for mobile-ip@standards.nortelnetworks.com; Wed, 26 Jul 2000
          18:22:43 -0400 (EDT)
X-Mailer: ELM [version 2.4ME+ PL61 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-ID:  <200007262222.SAA25697@wayward.ececs.uc.edu>
Date:         Wed, 26 Jul 2000 18:22:43 -0400
Reply-To: Samir Das 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: Samir Das 
Subject:      [MOBILE-IP] Final Call for Participation: MobiCom 2000, Aug 6-11,
              Boston
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

                  Final Call for Participation

                          MobiCom 2000

           The Sixth Annual International Conference on
                  Mobile Computing and Networking
                       August 6 - 11,  2000

            Seaport Hotel at World Trade Center Boston
                   Boston, Massachusetts, USA

    The complete program for paper, panel and tutorial sessions,
    as well as registration and hotel information are available
    at the conference web site below.

          http://www.research.telcordia.com/mobicom2000/

 Come, celebrate the wireless revolution and its convergence with the
 Internet, on Boston's historic waterfront. We look forward to seeing
 you in MobiCom 2000.

 Registration by mail or fax will be accepted until July 31.
 Registrations beyond this date will be accepted on site only.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Jul 26 23:58:37 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05636
	for ; Wed, 26 Jul 2000 23:58:36 -0400 (EDT)
Received: from standards (47.234.32.16:3828) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB820EA@standards.nortelnetworks.com>; Wed, 26 Jul 2000 23:46:49 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 27778 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jul 2000 23:46:49
          -0400
Received: from smtprch1. (47.113.64.103:37663) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB820DB@standards.nortelnetworks.com>; Wed, 26 Jul 2000 23:36:49
          -0400
Received: by smtprch1. (SMI-8.6/SMI-SVR4) id WAA25104; Wed, 26 Jul 2000
          22:47:45 -0500
Content-Type: multipart/mixed;
Message-ID:  <200007270347.WAA25104@smtprch1.>
Date:         Wed, 26 Jul 2000 22:47:45 -0500
Reply-To: "Morrow, Glenn [RICH2:C301:EXCH]" 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: "Morrow, Glenn [RICH2:C301:EXCH]" 
Subject:      [MOBILE-IP] FW: I-D
              ACTION:draft-lmk-mobileip-intercepting-update-00.txt
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01BFF742.FFC75920
Content-Type: multipart/alternative;
        boundary="----_=_NextPart_001_01BFF742.FFC75920"


------_=_NextPart_001_01BFF742.FFC75920
Content-Type: text/plain;
        charset="iso-8859-1"

> -----Original Message-----
> From: Internet-Drafts@ietf.org [SMTP:Internet-Drafts@ietf.org]
> Sent: Tuesday, July 25, 2000 5:35 AM
> To:   IETF-Announce
> Subject:      I-D ACTION:draft-lmk-mobileip-intercepting-update-00.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
>       Title           : Intercepting Location Updates
>       Author(s)       : C. Lee, G. Morrow, F. Kadri
>       Filename        : draft-lmk-mobileip-intercepting-update-00.txt
>       Pages           : 24
>       Date            : 24-Jul-00
>
> The base Mobile IP allows a host to transparently send datagrams to
> mobile nodes as it would to any other nodes. Datagrams addressed to
> the mobile are always routed via the Home Agent in the home network.
> However, as the mobile node moves away from its home network, it may
> no longer be topologically close to its home agent. Route
> optimization [MIP-OPTIM] has been proposed to allow a host to send
> packets to the mobile as a mobile node (MN) moves, without having to
> route the packets via the home agent each time.  The mobile provides
> its current address to a host (or correspondent node, CN) that it is
> communicating with as it moves. The host updates the cache of the
> mobile location with this new address and tunnels datagrams
> (addressed to the mobile) to the current address of the mobile.
> However not all correspondent nodes are capable of tunneling IP
> datagrams as required by the route optimization mechanisms described
> in [MIP-OPTIM]. More importantly, disclosing the current location (or
> COA) of the mobile node to correspondent nodes is not always
> desirable, nor is the overhead of encapsulating datagram to the MN
> ideal.
>
> This proposal provides an optional means for a host, using an
> existing IP host stack to communicate transparently with a mobile
> node, when a route optimization scheme such as [MIP-OPTIM] is
> utilized.  At the same time, this proposal does not reveal the current
> location of the MN to correspondent nodes. In conjunction, it
> is not necessary to encapsulate datagram sent from the CN to the MN
> in a foreign network. To prevent datagram sourced by the MN from
> being filtered at firewalls data sent from the MN to the CN does not
> have to be routed via the home agent all the time, nor is it
> necessary to encapsulate the data tunneled from the MN to a CN. In
> addition, this proposal provides a means to regionalize location
> update [REGIONAL-REG] transparent to mobile nodes.  Mobile nodes do
> not have to be aware or capable of regionalizing or localizing
> location update messages.  Furthermore, location update messages can
> be localized within a network or a routing area or domain, by
> leveraging existing routing hierarchies in the network.  This
> obviates the need to construct a hierarchy of foreign agents and the
> consequent need to ensure the hierarchy is reasonably optimal for
> routing and loop free.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-lmk-mobileip-intercepting-update
> -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-lmk-mobileip-intercepting-update-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-lmk-mobileip-intercepting-update-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_001_01BFF742.FFC75920
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






FW: I-D =
ACTION:draft-lmk-mobileip-intercepting-update-00.txt




-----Original Message-----

From:   Internet-Drafts@ietf.org =
[SMTP:Internet-Drafts@ietf.org]

Sent:   Tuesday, July 25, 2000 5:35 AM

To:     IETF-Announce

Subject:       =
 I-D =
ACTION:draft-lmk-mobileip-intercepting-update-00.txt




A New Internet-Draft is available from =
the on-line Internet-Drafts directories.






        Title   =
        : Intercepting Location =
Updates

        Author(s)       : C. Lee, =
G. Morrow, F. Kadri

        Filename        : =
draft-lmk-mobileip-intercepting-update-00.txt

        Pages   =
        : 24

        Date    =
        : 24-Jul-00

       =20

The base Mobile IP allows a host to =
transparently send datagrams to

mobile nodes as it would to any other =
nodes. Datagrams addressed to

the mobile are always routed via the =
Home Agent in the home network.

However, as the mobile node moves =
away from its home network, it may

no longer be topologically close to =
its home agent. Route

optimization [MIP-OPTIM] has been =
proposed to allow a host to send

packets to the mobile as a mobile =
node (MN) moves, without having to

route the packets via the home agent =
each time.  The mobile provides

its current address to a host (or =
correspondent node, CN) that it is

communicating with as it moves. The =
host updates the cache of the

mobile location with this new address =
and tunnels datagrams

(addressed to the mobile) to the =
current address of the mobile.

However not all correspondent nodes =
are capable of tunneling IP

datagrams as required by the route =
optimization mechanisms described

in [MIP-OPTIM]. More importantly, =
disclosing the current location (or

COA) of the mobile node to =
correspondent nodes is not always

desirable, nor is the overhead of =
encapsulating datagram to the MN

ideal.




This proposal =
provides an optional means for a host, using an

existing IP host =
stack to communicate transparently with a mobile

node, when a route =
optimization scheme such as [MIP-OPTIM] is

utilized.  At =
the same time, this proposal does not reveal the current 

location of the MN =
to correspondent nodes. In conjunction, it

is not necessary to =
encapsulate datagram sent from the CN to the MN

in a foreign =
network. To prevent datagram sourced by the MN from

being filtered at =
firewalls data sent from the MN to the CN does not

have to be routed =
via the home agent all the time, nor is it

necessary to =
encapsulate the data tunneled from the MN to a CN. In

addition, this =
proposal provides a means to regionalize location

update =
[REGIONAL-REG] transparent to mobile nodes.  Mobile nodes =
do

not have to be =
aware or capable of regionalizing or localizing

location update =
messages.  Furthermore, location update messages can

be localized within =
a network or a routing area or domain, by

leveraging existing =
routing hierarchies in the network.  This

obviates the need =
to construct a hierarchy of foreign agents and the

consequent need to =
ensure the hierarchy is reasonably optimal for

routing and loop =
free.




A URL for this Internet-Draft =
is:

http://www.ietf.org/internet-drafts/draft-lmk-mobileip=
-intercepting-update-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-lmk-mobileip-intercepting-update-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-lmk-mobileip-intercepting-update-00.txt".

       =20

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.

        =
       =20

        =
       =20

Below is the data which will enable a =
MIME compliant mail reader

implementation to automatically =
retrieve the ASCII version of the

Internet-Draft. <<Untitled Attachment>> =






------_=_NextPart_001_01BFF742.FFC75920--

------_=_NextPart_000_01BFF742.FFC75920
Content-Type: message/rfc822
Content-Description: Untitled Attachment

To:
Subject:
Date: Tue, 25 Jul 2000 09:38:57 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/mixed;
        boundary="----_=_NextPart_002_01BFF742.FFC75920"


------_=_NextPart_002_01BFF742.FFC75920
Content-Type: multipart/alternative;
        boundary="----_=_NextPart_003_01BFF742.FFC75920"


------_=_NextPart_003_01BFF742.FFC75920
Content-Type: text/plain



------_=_NextPart_003_01BFF742.FFC75920
Content-Type: text/html











 



------_=_NextPart_003_01BFF742.FFC75920--

------_=_NextPart_002_01BFF742.FFC75920
Content-Type: application/octet-stream;
        name="ATT21045"
Content-Disposition: attachment;
        filename="ATT21045"

Content-type: message/external-body;
        access-type="mail-server";
        server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:     <20000724142031.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-lmk-mobileip-intercepting-update-00.txt

------_=_NextPart_002_01BFF742.FFC75920
Content-Type: message/external-body;
        site="internet-drafts";
        dir="draft-lmk-mobileip-intercepting-update-00";
        mode="ftp.ietf.org";
        access-type="anon-ftp"


------_=_NextPart_002_01BFF742.FFC75920--

------_=_NextPart_000_01BFF742.FFC75920--
-------


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Jul 27 05:10: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 FAA29032
	for ; Thu, 27 Jul 2000 05:10:56 -0400 (EDT)
Received: from standards (47.234.32.16:3602) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB82222@standards.nortelnetworks.com>; Thu, 27 Jul 2000 4:59:12 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 28160 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jul 2000 04:59:12
          -0400
Received: from atlrel1.hp.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB82212@standards.nortelnetworks.com>; Thu, 27 Jul 2000 4:49:11
          -0400
Received: from ccm.india.hp.com (ccm.india.hp.com [15.10.45.147]) by
          atlrel1.hp.com (Postfix) with ESMTP id 2C4B73C3 for
          ; Thu, 27 Jul 2000 05:00:08
          -0400 (EDT)
Received: (from muthul@localhost) by ccm.india.hp.com (8.8.6 (PHNE_14041)/8.8.6
          SMKit7.02) id OAA29355 for mobile-ip@standards.nortelnetworks.com;
          Thu, 27 Jul 2000 14:36:05 +0530 (IST)
X-Mailer: Elm [revision: 212.4]
Message-ID:  <200007270906.OAA29355@ccm.india.hp.com>
Date:         Thu, 27 Jul 2000 14:36:05 IST
Reply-To: Muthu Kumar L 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: Muthu Kumar L 
Subject:      [MOBILE-IP] A query on MobileIP
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hello,
           I am an engineer working on gated( routing daemon). I need some
   clarifications from you regarding Mobile IP.
     I have a router that has the gated daemon running on it. Assume i have
   installed the mobility agent software on the router. Assume i have a mobile
   node that goes to a foreign network and tries to register with the home
   agent. Once the foreign agent approves the registration request, it will
   add a new logical interface for the mobile node say tunl0. I just need to
   know whether the addition of this new logical interface will affect the
   normal routing that is taken care by gated.This is because gated will learn
   the logical interface from the kernel and i feel it might intimate this new
   logical interface to the neighbouring routers.
Thank you,
Regards,
Muthukumar
--
                                         ,,,
                                        /'^'\
                                       ( o o )
*----------------------------------oOOO--(_)--OOOo----------------------*
^                                                                       ^
^ Muthu Kumar L                    Tel. 91-80-225 1554 Ext.1306         ^
^ HEWLETT PACKARD                  Fax. 91-80-220 0196                  ^
^ INDIA SOFTWARE OPERATIONS        Email. muthul@india.hp.com           ^
^ 29, CUNNINGHAM ROAD              Telnet. 847-1306                     ^
^ BANGALORE 560 052                                                     ^
^                                                                       ^
^                                    .oooO                              ^
^                                    (   )   Oooo.                      ^
*------------------------------------\ (----(   )-----------------------*
                                      \_)    ) /
                                            (_/


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Jul 27 10:35:29 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06107
	for ; Thu, 27 Jul 2000 10:35:28 -0400 (EDT)
Received: from standards (47.234.32.16:1416) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB822FB@standards.nortelnetworks.com>; Thu, 27 Jul 2000 10:23:39 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 28459 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jul 2000 10:23:39
          -0400
Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB822FA@standards.nortelnetworks.com>; Thu, 27 Jul 2000 10:23:39
          -0400
Received: from baldo.fub.it (baldo.fub.it [193.204.211.129]) by
          hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id JAA19049 for
          ; Thu, 27 Jul 2000 09:34:21 -0500 (CDT)
Received: from [193.204.209.162] by baldo.fub.it (Post.Office MTA v3.5.3
          release 223 ID# 506-59675U600L2S100V35) with ESMTP id it for
          ; Thu, 27 Jul 2000 16:36:41 +0200
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  
Date:         Thu, 27 Jul 2000 16:35:53 +0200
Reply-To: Roberto Winkler 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: Roberto Winkler 
Subject:      [MOBILE-IP] a question about Mobile Ip and fast handoff
X-To:         mobile-ip@smallworks.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

hello,

I don't know how much stupid is my question, I guess I'll be able to rank
it from the answers I'll get.....

Given that Mobile IP is considered to preserve TCP-oriented sessions from
the effects of mobility and given that real time communications will
(mostly, only ? I don't know) be RTP-oriented, what's the reason for the
large interest around fast handoffs enhancements to Mobile IP, where
seamless/lossless handoff should instead be pursued (and I believe that
solutions to the fast and seamless issues are different) ?
Put in another form, why worry about limited scope signaling (e.g. for
registration), for communications which are presumably not bound to be
damaged by some transient extra delay ? Isn't enough to run Mobile Ip (may
be with Routing Optimization) and take advantage of TCP retransmission ?
What strikes me is that I haven't met many proposals for fast handoff
support in RTP-oriented communications, I think that HMMP is the only one I
remember of, whereas I would say that this is the case where smart ideas
should be developed.....

My concern is instead not related to the micro-mobility control (e.g.
Cellular IP, HAWAII and TeleMIP).

Thanks for any hint....

Roberto Winkler
Senior Researcher
Fondazione Ugo Bordoni
Via B. Castiglione, 59
00142 Rome Italy

tel +39 0654803411
fax. +39 0654804404
e-mail wnk@fub.it


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Jul 27 10:41:07 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07534
	for ; Thu, 27 Jul 2000 10:41:07 -0400 (EDT)
Received: from standards (47.234.32.16:1416) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB82327@standards.nortelnetworks.com>; Thu, 27 Jul 2000 10:29:28 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 28519 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jul 2000 10:29:28
          -0400
Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1b) with SMTP id <0.FFB82326@standards.nortelnetworks.com>;
          Thu, 27 Jul 2000 10:29:26 -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 IAA23573 for
          ; Thu, 27 Jul 2000 08:40:23
          -0600 (MDT)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by
          engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id
          HAA26065; Thu, 27 Jul 2000 07:40: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 HAA04977; Thu, 27 Jul 2000 07:40:19
          -0700 (PDT)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Message-ID:  
Date:         Thu, 27 Jul 2000 07:39:15 -0700
Reply-To: "pcalhoun@eng.sun.com" 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: "pcalhoun@eng.sun.com" 
Subject:      Re: [MOBILE-IP] a question about Mobile Ip and fast handoff
X-To:         Roberto Winkler 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  "Your message with ID" 

> hello,
>
> I don't know how much stupid is my question, I guess I'll be able to rank
> it from the answers I'll get.....
>
> Given that Mobile IP is considered to preserve TCP-oriented sessions from
> the effects of mobility and given that real time communications will
> (mostly, only ? I don't know) be RTP-oriented, what's the reason for the
> large interest around fast handoffs enhancements to Mobile IP, where
> seamless/lossless handoff should instead be pursued (and I believe that
> solutions to the fast and seamless issues are different) ?
> Put in another form, why worry about limited scope signaling (e.g. for
> registration), for communications which are presumably not bound to be
> damaged by some transient extra delay ? Isn't enough to run Mobile Ip (may
> be with Routing Optimization) and take advantage of TCP retransmission ?
> What strikes me is that I haven't met many proposals for fast handoff
> support in RTP-oriented communications, I think that HMMP is the only one I
> remember of, whereas I would say that this is the case where smart ideas
> should be developed.....

Actually, I believe that the pro-active Foreign Agent I-D does in fact address
RTP (or real time) traffic. The idea is to provide the data to the mobile as
it enters a new cell, *before* the registration occurs. This will guarantee
the least amount of packet drops.

PatC


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Jul 27 10:51: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 KAA09676
	for ; Thu, 27 Jul 2000 10:51:15 -0400 (EDT)
Received: from standards (47.234.32.16:1416) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB82362@standards.nortelnetworks.com>; Thu, 27 Jul 2000 10:39:39 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 28600 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jul 2000 10:39:39
          -0400
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFB82361@standards.nortelnetworks.com>; Thu, 27 Jul 2000 10:39:38
          -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 HAA23847;
          Thu, 27 Jul 2000 07:50:37 -0700 (PDT)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.9.3/8.9.3-VIRSCAN) id HAA12863; Thu, 27 Jul 2000 07:50:36 -0700
X-Virus-Scanned:  Thu, 27 Jul 2000 07:50:36 -0700 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from charliep.iprg.nokia.com (205.226.2.89,
          claiming to be "iprg.nokia.com") by
          darkstar.iprg.nokia.com(WTS.12.69) smtpdTZVRBV; Thu, 27 Jul 2000
          07:50:33 PDT
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39804C3A.F3C91554@iprg.nokia.com>
Date:         Thu, 27 Jul 2000 07:50:34 -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] a question about Mobile Ip and fast handoff
X-To:         Roberto Winkler 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello Roberto,

Answering your question could take megabytes, but I hope a simpler
answer will be at least somewhat useful.

The main point is simplicity.  Mobile IP is one of the simplest
approaches, and even Route Optimization is pretty simple in
terms of control structures.

Smooth handover is to a certain extent independent of Mobile IP.
The point is that higher speed requires maintaining more context
about the mobile node for various reasons, and pushing that state
around is the task for various smooth handover mechanisms.

If you don't have Mobile IP, then you have more state in other
places to substitute (typically poorly) for Mobile IP, and thus
smooth handover is harder.  You can put that state at layer 2
(more complicated! and specific to the medium), at the transport
layer (a reasonable approach as long as you only care about that
transport layer), or at the application (ditto, as long as you only
care about that application, and performance is not an issue).

As always, the devil is in the details.  The details are just
easier at the network layer.

Regards,
Charlie P.




Roberto Winkler wrote:
>
> hello,
>
> I don't know how much stupid is my question, I guess I'll be able to rank
> it from the answers I'll get.....
>
> Given that Mobile IP is considered to preserve TCP-oriented sessions from
> the effects of mobility and given that real time communications will
> (mostly, only ? I don't know) be RTP-oriented, what's the reason for the
> large interest around fast handoffs enhancements to Mobile IP, where
> seamless/lossless handoff should instead be pursued (and I believe that
> solutions to the fast and seamless issues are different) ?
> Put in another form, why worry about limited scope signaling (e.g. for
> registration), for communications which are presumably not bound to be
> damaged by some transient extra delay ? Isn't enough to run Mobile Ip (may
> be with Routing Optimization) and take advantage of TCP retransmission ?
> What strikes me is that I haven't met many proposals for fast handoff
> support in RTP-oriented communications, I think that HMMP is the only one I
> remember of, whereas I would say that this is the case where smart ideas
> should be developed.....
>
> My concern is instead not related to the micro-mobility control (e.g.
> Cellular IP, HAWAII and TeleMIP).
>
> Thanks for any hint....
>
> Roberto Winkler
> Senior Researcher
> Fondazione Ugo Bordoni
> Via B. Castiglione, 59
> 00142 Rome Italy
>
> tel +39 0654803411
> fax. +39 0654804404
> e-mail wnk@fub.it


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Jul 27 11:22:02 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16577
	for ; Thu, 27 Jul 2000 11:22:02 -0400 (EDT)
Received: from standards (47.234.32.16:1416) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB823A2@standards.nortelnetworks.com>; Thu, 27 Jul 2000 11:10:25 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 28684 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jul 2000 11:10:25
          -0400
Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB823A1@standards.nortelnetworks.com>; Thu, 27 Jul 2000 11:10:24
          -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.3) with ESMTP id e6RFLNQ28198 for
          ; Thu, 27 Jul 2000 17:21:23
          +0200 (MEST)
Received: from SMTP ([153.88.251.32]) by esealnt409.al.sw.ericsson.se with
          Microsoft SMTPSVC(5.0.2172.1); Thu, 27 Jul 2000 17:21:22 +0200
Received: from esealnt400.al.sw.ericsson.se ([153.88.251.21]) by 153.88.251.32
          (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 27 Jul 2000
          15:21:22 0000 (GMT)
Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id ;
          Thu, 27 Jul 2000 17:21:21 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain; charset="iso-8859-1"
X-OriginalArrivalTime: 27 Jul 2000 15:21:22.0982 (UTC)
                       FILETIME=[5292DC60:01BFF7DE]
Message-ID:  <5F05C89FB2F8D211B6430008C791912703EA8113@esealnt190>
Date:         Thu, 27 Jul 2000 17:21:17 +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] a question about Mobile Ip and fast handoff
X-To:         Roberto Winkler 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hello Roberto

>  Given that Mobile IP is considered to preserve TCP-oriented
>  sessions from
>  the effects of mobility and given that real time communications will
>  (mostly, only ? I don't know) be RTP-oriented, what's the
>  reason for the
>  large interest around fast handoffs enhancements to Mobile IP, where
>  seamless/lossless handoff should instead be pursued (and I
>  believe that
>  solutions to the fast and seamless issues are different) ?

A fast handoff mechanism should minimize the period of service
disruption when a MN moves between subnets, thus taking a step towards
lossless/seamless communication. So I think that there is a relation
between the fast and seamless issues. However, we are only improving
L3 handoffs, and L2 characteristics may still cause losses and delay.

>  Put in another form, why worry about limited scope signaling
>  (e.g. for
>  registration), for communications which are presumably not
>  bound to be
>  damaged by some transient extra delay ?

I believe that the amount of added delay is important for the
quality of a real-time service and may damage it. What we don't
want is for the user to experience a drop in quality every time
a L3 handoff is performed.

>  What strikes me is that I haven't met many proposals for fast handoff
>  support in RTP-oriented communications, I think that HMMP is
>  the only one I
>  remember of, whereas I would say that this is the case where
>  smart ideas
>  should be developed.....

Could you clarify your point further?
IMO Fast Handoffs covers this already.

Regards,
Karim


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Jul 27 14:02:09 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14646
	for ; Thu, 27 Jul 2000 14:02:08 -0400 (EDT)
Received: from standards (47.234.32.16:3476) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB82512@standards.nortelnetworks.com>; Thu, 27 Jul 2000 13:50:23 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 29150 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jul 2000 13:50:23
          -0400
Received: from po4.glue.umd.edu by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB82505@standards.nortelnetworks.com>; Thu, 27 Jul 2000 13:40:23
          -0400
Received: from jewels (macscott.isr.umd.edu [128.8.140.119]) by
          po4.glue.umd.edu (8.10.1/8.10.1) with SMTP id e6RHpJo22469; Thu, 27
          Jul 2000 13:51:19 -0400 (EDT)
X-Sender: mscorson@popd.ix.netcom.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  <3.0.6.32.20000727135149.0087fb80@popd.ix.netcom.com>
Date:         Thu, 27 Jul 2000 13:51:49 -0400
Reply-To: "M. Scott Corson" 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: "M. Scott Corson" 
Subject:      Re: [MOBILE-IP] a question about Mobile Ip and fast handoff
X-To:         charliep@IPRG.NOKIA.COM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <39804C3A.F3C91554@iprg.nokia.com>

>
>As always, the devil is in the details.  The details are just
>easier at the network layer.
 ^^^^^^
 and more general ;-)


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Jul 27 16:25: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 QAA24839
	for ; Thu, 27 Jul 2000 16:25:18 -0400 (EDT)
Received: from standards (47.234.32.16:4978) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB825DB@standards.nortelnetworks.com>; Thu, 27 Jul 2000 16:13:36 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0150 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jul 2000 16:13:35
          -0400
Received: from prue.eim.surrey.ac.uk by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB825C8@standards.nortelnetworks.com>; Thu, 27 Jul 2000 16:03:35
          -0400
Received: from carter-e0.ee.surrey.ac.uk ([131.227.86.16]) by
          prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 13Hu38-0003Ob-00
          for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jul 2000 21:14:34
          +0100
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID:  
Date:         Thu, 27 Jul 2000 21:14:34 +0100
Reply-To: Karann Chew 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: Karann Chew 
Subject:      [MOBILE-IP] NAI
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Could anyone briefly explain what NAI does?  It seems to be much related
to DHCP and Mobile IP.

Where can I get further information (eg I-D or RFC or any paper) regarding
NAI?

Cheers!

Karann

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
             Karann Chew
   Mobile Communications Research Group
Centre for Communication Systems Research
          University of Surrey

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Jul 27 17:31:28 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10589
	for ; Thu, 27 Jul 2000 17:31:28 -0400 (EDT)
Received: from standards (47.234.32.16:4978) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB82680@standards.nortelnetworks.com>; Thu, 27 Jul 2000 17:19:38 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0332 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jul 2000 17:19:38
          -0400
Received: from news.comp.lancs.ac.uk by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB8264C@standards.nortelnetworks.com>; Thu, 27 Jul 2000 17:09:38
          -0400
Received: from SPOCK (egcsky000002.lancs.ac.uk [148.88.155.83]) by
          news.comp.lancs.ac.uk (8.10.2/8.10.2) with SMTP id e6RLL6h11709 for
          ; Thu, 27 Jul 2000 22:21:07
          +0100 (BST)
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Message-ID:  
Date:         Thu, 27 Jul 2000 22:18:59 +0100
Reply-To: Stefan Schmid 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: Stefan Schmid 
Subject:      [MOBILE-IP] Implementation Issues re MobileIP and IPSec
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi,

  we are currently implementing IPsec support for our Mobile IPv6
stack. However, after looking closely at the Mobile IPv6 specification, we
found the following contradictions/obscurities:

1. According to the Mobile IPv6 specification only "once the packet is
fully assembled, the necessary IPsec authentication [...] processing
is performed on the packet, initializing the Authentication Data in
the AH or ESP header" (see 10.2). This implies that the mobile node's
care-of-address must be used within the IPv6 source address.
However, at the receiver, the Mobile IPv6 specification demands: "when
any node receives a packet containing a Home Address option, it MUST
process the option in a manner consistent with copying the Home
Address field from the Home Address option into the IPv6 header,
replacing the original value of the Source Address field there [...]
Further processing of such a packet after option processing (e.g., at
the transport layer) thus need not know that the original Source
Address was a care-of address [...]" (see 8.1.) Therefore, by the time
the AH header is processed (note that the AH must be processed after
the Home Address option), it would use the home address to compute the
authentication data rather than the care-of-address.

2. According to the IPv6 RFC (2460) "extension headers must be
processed strictly in the order they appear in the packet". It
explicitly states that "a receiver MUST NOT, for example, scan through
a packet looking for a particular kind of extension header and process
that header prior to processing all preceding ones".
However, in contrast, the Mobile IPv6 specification declares that "the
Destination Options header in which the Binding Update option is
inserted MAY appear either before or after the AH or ESP header".
Since a Binding Update option cannot be processed before the packet
was properly authenticated (note that "any packet carrying a BU MUST
be protected by IPSEC [...]" (see 4.4), it should never occur before
the AH header in the packet.

In addition, we believe the current specification lacks clarification
regarding:

1. It should explicitly state which address, the mobile node's Home
Address or care-of-address, must be used as IPv6 source address for
the authentication calculation.

   We believe that only the latter makes sense, as the
care-of-address must be authenticated in order to prevent malicious
binding update messages. Note that otherwise (i.e. the source address
is set
to the Home Address when authentication is perfomed) the
care-of-address would not be authenticated.

2. It should clarify which address, the mobile node's Home Address or
care-of-address, must be used for the SA/SP lookup.

   Here we believe that only the former is useful. Since using the
care-of-address as key to identify the correct SA/SP for
authentication would result in exploding number of SAs/SPs (one for
each care-of-address). However, a clear statement in the specification
that the Home Address must be used is missing.

Any comments? Also, could anybody please confirm if we are on the
right track, or if we have overlooked something.

Regards,

- Stefan

---
  Stefan Schmid (Dipl.-Inf)      Distributed Multimedia Research Group
  Research Assistant                              Computing Department
  Phone: +44 (0)7989 400707                       Lancaster University
  Fax:   +44 (0)1524 593608                          Lancaster LA1 4YR
  Email: mailto:sschmid@comp.lancs.ac.uk                          U.K.
  WWW:   http://www.landmarc.net/people/stefan.htm
  SMS:   mailto:sschmid@sms.genie.co.uk


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Jul 27 17:50:14 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14737
	for ; Thu, 27 Jul 2000 17:50:14 -0400 (EDT)
Received: from standards (47.234.32.16:4978) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB826DF@standards.nortelnetworks.com>; Thu, 27 Jul 2000 17:38:42 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0536 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jul 2000 17:38:42
          -0400
Received: from franklin.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB826DE@standards.nortelnetworks.com>; Thu, 27 Jul 2000 17:38:42
          -0400
Received: from gwz (atlantis-dial-1-6.cisco.com [171.68.181.7]) by
          franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id
          OAA09021; Thu, 27 Jul 2000 14:49:08 -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:         Thu, 27 Jul 2000 14:47:09 -0700
Reply-To: gwz@cisco.com
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: Glen Zorn 
Subject:      Re: [MOBILE-IP] NAI
X-To:         Karann Chew 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  
Content-Transfer-Encoding: 7bit

Karann Chew [mailto://k.chew@EIM.SURREY.AC.UK] writes:

> Could anyone briefly explain what NAI does?  It seems to be much related
> to DHCP and Mobile IP.
>
> Where can I get further information (eg I-D or RFC or any paper) regarding
> NAI?

ftp://ftp.isi.edu/in-notes/rfc2486.txt and (Mobile IP specific)
ftp://ftp.isi.edu/in-notes/rfc2794.txt.

>
> Cheers!
>
> Karann
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>              Karann Chew
>    Mobile Communications Research Group
> Centre for Communication Systems Research
>           University of Surrey
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Jul 28 04:20: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 EAA23756
	for ; Fri, 28 Jul 2000 04:20:10 -0400 (EDT)
Received: from standards (47.234.32.16:3972) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB828A9@standards.nortelnetworks.com>; Fri, 28 Jul 2000 4:08:28 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1137 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jul 2000 04:08:28
          -0400
Received: from baldo.fub.it by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1b) with SMTP id <0.FFB828A8@standards.nortelnetworks.com>;
          Fri, 28 Jul 2000 4:08:26 -0400
Received: from [193.204.209.162] by baldo.fub.it (Post.Office MTA v3.5.3
          release 223 ID# 506-59675U600L2S100V35) with ESMTP id it for
          ; Fri, 28 Jul 2000 10:21:58
          +0200
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  
Date:         Fri, 28 Jul 2000 10:21:12 +0200
Reply-To: Roberto Winkler 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: Roberto Winkler 
Subject:      Re: [MOBILE-IP] a question about Mobile Ip and fast handoff
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <39804C3A.F3C91554@iprg.nokia.com>

Hello again,

Charlie Perkins  wrote:

>As always, the devil is in the details.  The details are just
>easier at the network layer.

I understand Charlie's position (and mostly agree with it) that operating
at the network layer is better, but I'm not sure I've understood what does
Charlie means with this sentence.

More, something I've not found in the replies I've got so far: can you
confirm me that Mobile IP (and related enhancements) are ok in RTP-oriented
communications, altough they've been devised for TCP ?

Thanks again

Roberto

Roberto Winkler
Senior Researcher
Fondazione Ugo Bordoni
Via B. Castiglione, 59
00142 Rome Italy

tel +39 0654803411
fax. +39 0654804404
e-mail wnk@fub.it


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Jul 28 04:59:03 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06250
	for ; Fri, 28 Jul 2000 04:59:03 -0400 (EDT)
Received: from standards (47.234.32.16:3972) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB828ED@standards.nortelnetworks.com>; Fri, 28 Jul 2000 4:47:29 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1226 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jul 2000 04:47:29
          -0400
Received: from gollum.axion.bt.co.uk by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB828EC@standards.nortelnetworks.com>; Fri, 28 Jul 2000 4:47:28
          -0400
Received: from cbtlipnt02.btlabs.bt.co.uk by gollum (local) with ESMTP; Fri, 28
          Jul 2000 09:59:19 +0100
Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service
          (5.5.2651.88) id ; Fri, 28 Jul 2000 09:58:04 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.88)
Content-Type: text/plain
Message-ID:  
Date:         Fri, 28 Jul 2000 09:57: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] Handoff Discussions
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Scott, George and myself will be there...

> -----Original Message-----
> From: pcalhoun@eng.sun.com [SMTP:Pat.Calhoun@ENG.SUN.COM]
> Sent: Wednesday, July 26, 2000 11:18 PM
> To:   MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: [MOBILE-IP] Handoff Discussions
>
> >It is a good idea. Since the first session is on Tue. How about
> interested
> >people
> >meet on Monday?
>
> How about dinner on Monday? We could all meet at the IETF registration...
>
> PatC


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Jul 28 10:04:54 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25290
	for ; Fri, 28 Jul 2000 10:04:52 -0400 (EDT)
Received: from standards (47.234.32.16:2261) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB82A2A@standards.nortelnetworks.com>; Fri, 28 Jul 2000 9:52:36 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1630 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jul 2000 09:52:36
          -0400
Received: from ish7.ericsson.com.au (203.61.155.111:55913) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB82A29@standards.nortelnetworks.com>; Fri, 28 Jul 2000
          9:52:33 -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 AAA18225; Sat,
          29 Jul 2000 00:01:57 +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 AAA20936; Sat, 29
          Jul 2000 00:03:17 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service
          (5.5.2650.21) id ; Sat, 29 Jul 2000 00:03:11 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFF89C.90084170"
Message-ID:  <4B6BC00CD15FD2119E5F0008C7A419A5089EB13D@eaubrnt018.epa.ericsson.se>
Date:         Sat, 29 Jul 2000 00:03:10 +1000
Reply-To: "Hesham Soliman (EPA)" 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: "Hesham Soliman (EPA)" 
Subject:      Re: [MOBILE-IP] draft-malinen-mobileip-regreg6-00.txt
X-To:         "jmalinen@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_01BFF89C.90084170
Content-Type: text/plain;
        charset="iso-8859-1"

Hi Jari,

Sorry for the late reply, email problems !
Here are some more comments.
I'm sure we will continue this in Pittsburgh.

Regards,
Hesham




> I agree with Claude's comment regarding the sending of BUs.

Since I am not sure which of Claude's comments you refer to, I'll address
both.

About sending BUs directly to the GMA, with a local model we distribute
the load down to the hierarchy as explained at end of this mail.

=> The comment was on the transparency of the BUs to the MN.
I think it's better that the MN knows its regional address(es).
This would comply with the MIPv6 design and will save a lot of
complications with security which are not solved in your proposal
as you mentioned in ch 7.


About autoconfiguration of GCoA,
if we compare HMIPv6 and ours, both use a link-address to for
local communication. HMIPv6 calls this PCoA. This takes one
autoconfiguration.

In addition to that, HMIPv6 favors another autoconfiguration for the GCoA.




But with the regional binding cache -based forwarding, our regional
CoA can be static. We save the second autoconfiguration overhead with its
DAD operation etc. Our regional CoA can be re-used by many MNs since it is
not
a real address on MN's link but an address in a GMA. This address is
defended
against re-use by GMA. Inbound packets to MNs' home addresses are forwarded
with the lower CoAs to the correct MN. No address deletion from
advertisements
thus no housekeeping for this is needed. In fact, we can do with only one
constant
regional CoA in the advertisement re-used by all MNs. If MN-based selection
is
desired, several regional CoAs can be advertised.
Can you explain more why we need the second autoconfiguration.



=>Which HMIPv6 ;) ?
In our proposal we don't need autoconfig or DAD. We use a COA that
belongs to a MAP interface. Similar to yours. But the difference is that
the MN knows all its addresses which makes things very simple.


> > In HMIP, since the GCoA is build by concatening the MS prefix and EUI64,
address
> > collision is very unlikely (but the MS verifies the unicity of the
address by
> > performing a DaD on its link). Why don't you use the nice IPv6
> > autoconfiguration capability?
> >
> > This is for efficiency reasons, if the GCoA does not usually need to be
> > configured
> > at all, no delay occurs. However, your comment brings to mind that
> > renumbering
> > should cause reconfiguration of access router advertisements.
> > At this moment we limited hierarchy reconfiguration (dynamic knowledge
of
> > regional
> > care-of-addresses, children, and father) out of scope, however. This can
be done
> > with a separate protocol extension for these hopefully infrequent
events, including
> > renumbering.

> =>I don't really see a need for new protocols to handle renumbering. In
our
> proposal (and I blieve in Claude's one too) the renumbering is handled
> automatically because the rtr adv will announce new MAP addresses (in our
> case) or new prefixes (in Claude's draft).
> I think the basic IPv6 functionality in this case is certainly enough
> and provides very flexible and generic mechanisms without introducing
> more protocols. The less complexity, the better IMO.

In fact, I did not find specific description in MAP about what happens in
renumbering, how exactly is the knowledge of this distributed to the routers
advertising MAP? Since MAP is a specific sub-option to the router
advertisement,
IPv6 will not automatically provide this. In this sense I do not think we
have
very different approach..

=> Well there is no difference to normal IPv6 operation. If the MAP address
changes due to renumbering then the information in the MAP option
will change and the MN will register with the new address. The information
can be distributed to routers using the MAP discovery mechanism in the
draft.

> > > I have another question: why does a mobile host  send its regionalized
BU
> > > to the access router instead of sending it directly to the closed
Regional
> > > MA as we do (the RMA address could be advertised in the router adv.)?
> > > This would  provide more flexibility in the deployement of the
Regional-aware
> > > routers (they don't have to be on a tree anymore)...
>
> > A region is naturally a hierarchy and in our model the network decides
on the
> > crossover router (the highest guy changing its binding cache and
answering
> > to this BU) thus distributing the signalling load down to the hierarchy.
>
> =>I don't see how the signalling load is distributed from a router's
> point of view. Every router in the heirarchy will still receive a BU.
> So the only difference is in our case (and again Claude's draft),
> is that the MN is aware who's receiving the BU. Which is what MIPv6 says,
> and I think that is a cleaner way to do it and less complex.

Not every BU goes to all routers in our model. If MN moves between adjacent
branches in a subtree, that BU propagates only to the crossover, not up to
the
GMA. If you move frequently between these two only, signaling load is
distributed
down from the GMA to the crossover. Tunneling directly to the MAP behaves
like a
shallow (2-level) hierarchy. Our design provides optimization from the depth
of
hierarchy even without changing the GMA.

=> No, there is no assumption of a 2-level hierarchy at all.
The exact same outcome as in your proposal can be obtained but
the difference is that the MN is aware of its regional addresses.

> > -  HA does not need to be regional-aware (or MAP-aware) as in Karim's
> >     I-D. The first packets from CN via HA to MN are re-capsulated at GMA
> >     via possible lower regional routers down to MN's autoconfigured
on-link CoA.
> >     MN can recognize it needs to send a BU to CN from an encapsulated
packet
> >     from CN, encapsulator being the access router.
>
> => That is an inaccurate observation. That's not the reason the HA has to
> add a routing header (if that's what you mean by regional-aware).
> The HA has to do that when it forwards packets that were addressed to an
MN
> address that was not registered with the MAP.

Note that I commented your design in the first sentence and thereafter
explained
ours to clarify Bechet's questions thereof. WRT your design I only wanted to
note
that the HA inserts this routing header thus making it different from a
plain
Mobile IPv6 HA. By regional-awareness I only refer to the fact that you need
to alter the HA for MAP to operate correctly in some cases (explained
later).

=>You have to change something in the HA. Otherwise Site-local packets
addressed to the MN will be dropped by the regional routers or delivered
to the wrong MN. You don't address this issue in your draft and that's
why I think it is not complete.


> I might be wrong but I don't think you've addressed this problem in your
> draft. Therefore according to your proposal, other home addresses that
> the regional router is not aware of, will not be received by the MN as
they
> will be dropped by the regional router.

Let me explain. In our design, other home addresses will not be dropped when
no
regional entry exists. Note that in such a case, the GMA behaves like a
normal
router. If the packet is targeted to the on-link CoA of the MN, this leads
to
basic Mobile IPv6 behavior where gateway router is just like any other
intermediate
router between HA and MN. If the HA tries to send to a regional CoA, the
entry is still in the GMA. It is the responsibility of the MN to make
sure that a regional binding cache entry in the GMA has a large enough
lifetime. And it is also the responsibility of the MN to register with
the GMA before traffic starts to arrive from remote nodes where MN registers
with a regional CoA.

=>Please refer to my comment above.


 Furthermore, MN uses either regional or non-regional
CoA but not both simultaneously when sending binding updates out of the
visited
domain.

=> Why ? how can that be controlled. I think the MN should be able to use
any of its COAs (on link and regional). I don't see a need to limit that.
Furthermore, it can't really be policed even if you want to restrict it.

> > After MN sent a BU with
> >     alternate CoA to CN, this can start sending route-optimized packets
to MN
> >     via GMA. Inner packet AH is not touched in intermediate routers.
> >     Packets are forwarded locally in the visited domain and not from HA.
> >     We can thus do without using an additional routing header with
tunneling.
>
> => I don't really understand how that affects our decision of adding a
> routing header. AH is not affected in our proposal either, end to end
security is
> maintained. What you mention above is not related to adding a routing
header from the
> HA. The routing header from the CN is mandatory according to MIPv6.

Again, I explain our design here. I only refer to MAP in how you describe
HA operation in your section 13. You use a routing entry to find home
address.

Our forwarding only uses the binding cache, after which the destination
address is that of a lower CoA which is in its topologically correct place,
i.e. no mobility-specific additional routing entries are needed. Why have
extra routing state for home addresses when we have the binding cache entry,
in both designs, anyway?

=>We don't add the Routing header in the HA all the time, only for addresses
that were
not registered. eg. a Site-local home address.

> > - In our design, most of the data packets are neither tunneled nor
> >    host-routed (note also that signaling is not tunneled).
> >    Route-optimized packets towards the MN are forwarded in a special
> >    way based only on the regional binding cache.
>
> => If I understand that special way you refer to correctly, it is done by
> changing the destination address in the packet. I think it is dangerous
> to allow intermediate nodes to modify packets. I think tunnelling
> is a better way to go here.

If you look at RFC2460, the pseudo-code on page 16 explains how source
routing (consumption of routing headers in intermediate routers) changes
the destination IP address in the process (swap the IPv6 Destination Address
and Address[i]). In fact, this is a precedence for changing IPhdr
destination
address in intermediate routers. We don't break this, we simply don't use it
for a very special kind of a routing header, that sent by users of basic
Mobile IPv6 route optimization and this only in regional-aware routers.



We use a different kind of forwarding (a regional binding cache based next
hop routing) which does not do anything more to the packet that source
routing would, it does less . When we can skip routing header processing
this
even speeds up the IP forwarding. And we avoid the tunnelling overhead for
route-optimized packets which form the vast majority of data packets.

=>There is a fundamental difference. RFC 2460 states that you can
use the contents of the packet to change the packet. That is not
the same as simply changing the packet.

> > Normal processing of
> >    source-routed packets is skipped if there is a regional binding cache
> >    entry for the route-optimized home address in the regional CoA router
> >    receiving the packet. Only IPhdr destination is changed, AH prevails.
> >    The packet is then just forwarded to the lower CoA as seen in the
> >    regional binding cache.  Thus, no extra routing state is needed.
> >    This is much simpler than in Karim's proposal and is quite different
> >    from IPv4-solutions. Universal route optimization as provided in
basic
> >    even possible in IPv4 due to its legacy CNs.
>
> => I don't understand why you chose not to process the routing header.
> This breaks RFC 2460 (IPv6 spec) for no reason.

First, a normal routing header processing would assume local knowledge
of home address routing. This would need the extra routing entry for the
home address when you process the routing header normally.

In our design, for the routing headers (from CNs or HAs) or even
for recapsulation, all we do is a regional binding cache lookup based
on home address which is used for all regional forwarding.

=> Ok how do you look up an entry in the Binding Cache ? I guess the key
is the Home address. Where do you get it from in the packet received from
the CN ?

I do not consider our design choice a breach,
it is something new as was the introduction of binding cache -based
forwarding to HA in the basic Mobile IPv6. That "breaks" 2460 in that
it does not forward packets to the home link but to another address
based on MN's home binding. Our approach is analogous. For a special
mobility routing case we skip a part of 2460 to be more efficient in
header overhead and forwarding processing. Furthermore, we this way
localize this forwarding to a visited domain router.

=>I really can't see the analogy here. The breach is that you ignore
the routing header and RFC 2460 says you shouldn't.

Your HA Operation chapter 13 implies that this routing state exists and
for the cases that you explain,
"HA MUST include a routing header .. to enable the MAP to find the right
routing entry for the MN", which is what I meant by non-local forwarding
support (from the HA) for your visited-domain routing to operate correctly.

=> I think the answer to your question is in the ".." area ;)
basically Site-local addresses is the answer.

Additionally, as described in the AH RFC, IPhdr dstaddr is mutable but
predictable when a type 0 routing header is present. The check is done
for packet as seen after reception, that is, after applying routing header
in the final destination. With our design, we have the home address in
the DST field just like with basic Mobile IPv6.

Your design ends with the same, but with a bit more complicated routing
as described above. Our designs have similarities, but are not the same.

=>Yes it adds a fraction more complexity in the rare case of forwarding
Site-local packets, but it guarantees that nothing is lost. your proposal
doesn't guarantee that.

Having a convergence of some sort would be nice.. Would this call for
a framework for many regional/micro-mobility protocols or a simpler
common approach, what do you think?

=>I agree that there are some good ideas in all proposals and I look
forward to discussing this in Pittsburgh.

It would be nice to continue discussing the options in Pittsburgh?

=> Definitely.



------_=_NextPart_001_01BFF89C.90084170
Content-Type: text/html;
        charset="iso-8859-1"






RE: [MOBILE-IP] draft-malinen-mobileip-regreg6-00.txt




Hi Jari,




Sorry for the late reply, email problems !

Here are some more comments.

I'm sure we will continue this in Pittsburgh.




Regards,

Hesham










> I agree with Claude's comment regarding the sending of BUs.




Since I am not sure which of Claude's comments you refer to, I'll address both.




About sending BUs directly to the GMA, with a local model we distribute

the load down to the hierarchy as explained at end of this mail.




=> The comment was on the transparency of the BUs to the MN.

I think it's better that the MN knows its regional address(es).

This would comply with the MIPv6 design and will save a lot of 

complications with security which are not solved in your proposal

as you mentioned in ch 7.






About autoconfiguration of GCoA,

if we compare HMIPv6 and ours, both use a link-address to for

local communication. HMIPv6 calls this PCoA. This takes one autoconfiguration.




In addition to that, HMIPv6 favors another autoconfiguration for the GCoA.










But with the regional binding cache -based forwarding, our regional

CoA can be static. We save the second autoconfiguration overhead with its

DAD operation etc. Our regional CoA can be re-used by many MNs since it is not

a real address on MN's link but an address in a GMA. This address is defended

against re-use by GMA. Inbound packets to MNs' home addresses are forwarded

with the lower CoAs to the correct MN. No address deletion from advertisements

thus no housekeeping for this is needed. In fact, we can do with only one constant

regional CoA in the advertisement re-used by all MNs. If MN-based selection is

desired, several regional CoAs can be advertised.

Can you explain more why we need the second autoconfiguration.








=>Which HMIPv6 ;) ?

In our proposal we don't need autoconfig or DAD. We use a COA that 

belongs to a MAP interface. Similar to yours. But the difference is that

the MN knows all its addresses which makes things very simple.






> > In HMIP, since the GCoA is build by concatening the MS prefix and EUI64, address

> > collision is very unlikely (but the MS verifies the unicity of the address by

> > performing a DaD on its link). Why don't you use the nice IPv6

> > autoconfiguration capability?

> >

> > This is for efficiency reasons, if the GCoA does not usually need to be

> > configured

> > at all, no delay occurs. However, your comment brings to mind that

> > renumbering

> > should cause reconfiguration of access router advertisements.

> > At this moment we limited hierarchy reconfiguration (dynamic knowledge of

> > regional

> > care-of-addresses, children, and father) out of scope, however. This can be done

> > with a separate protocol extension for these hopefully infrequent events, including

> > renumbering.




> =>I don't really see a need for new protocols to handle renumbering. In our

> proposal (and I blieve in Claude's one too) the renumbering is handled

> automatically because the rtr adv will announce new MAP addresses (in our

> case) or new prefixes (in Claude's draft).

> I think the basic IPv6 functionality in this case is certainly enough

> and provides very flexible and generic mechanisms without introducing

> more protocols. The less complexity, the better IMO.




In fact, I did not find specific description in MAP about what happens in

renumbering, how exactly is the knowledge of this distributed to the routers

advertising MAP? Since MAP is a specific sub-option to the router advertisement,

IPv6 will not automatically provide this. In this sense I do not think we have

very different approach..




=> Well there is no difference to normal IPv6 operation. If the MAP address

changes due to renumbering then the information in the MAP option 

will change and the MN will register with the new address. The information

can be distributed to routers using the MAP discovery mechanism in the 

draft. 




> > > I have another question: why does a mobile host  send its regionalized BU

> > > to the access router instead of sending it directly to the closed Regional

> > > MA as we do (the RMA address could be advertised in the router adv.)?

> > > This would  provide more flexibility in the deployement of the Regional-aware

> > > routers (they don't have to be on a tree anymore)...

>

> > A region is naturally a hierarchy and in our model the network decides on the

> > crossover router (the highest guy changing its binding cache and answering

> > to this BU) thus distributing the signalling load down to the hierarchy.

>

> =>I don't see how the signalling load is distributed from a router's

> point of view. Every router in the heirarchy will still receive a BU.

> So the only difference is in our case (and again Claude's draft),

> is that the MN is aware who's receiving the BU. Which is what MIPv6 says,

> and I think that is a cleaner way to do it and less complex.




Not every BU goes to all routers in our model. If MN moves between adjacent

branches in a subtree, that BU propagates only to the crossover, not up to the

GMA. If you move frequently between these two only, signaling load is distributed

down from the GMA to the crossover. Tunneling directly to the MAP behaves like a

shallow (2-level) hierarchy. Our design provides optimization from the depth of

hierarchy even without changing the GMA.




=> No, there is no assumption of a 2-level hierarchy at all. 

The exact same outcome as in your proposal can be obtained but

the difference is that the MN is aware of its regional addresses.




> > -  HA does not need to be regional-aware (or MAP-aware) as in Karim's

> >     I-D. The first packets from CN via HA to MN are re-capsulated at GMA

> >     via possible lower regional routers down to MN's autoconfigured on-link CoA.

> >     MN can recognize it needs to send a BU to CN from an encapsulated packet

> >     from CN, encapsulator being the access router.

>

> => That is an inaccurate observation. That's not the reason the HA has to

> add a routing header (if that's what you mean by regional-aware).

> The HA has to do that when it forwards packets that were addressed to an MN

> address that was not registered with the MAP.




Note that I commented your design in the first sentence and thereafter explained

ours to clarify Bechet's questions thereof. WRT your design I only wanted to note

that the HA inserts this routing header thus making it different from a plain

Mobile IPv6 HA. By regional-awareness I only refer to the fact that you need

to alter the HA for MAP to operate correctly in some cases (explained later).




=>You have to change something in the HA. Otherwise Site-local packets

addressed to the MN will be dropped by the regional routers or delivered

to the wrong MN. You don't address this issue in your draft and that's 

why I think it is not complete.






> I might be wrong but I don't think you've addressed this problem in your

> draft. Therefore according to your proposal, other home addresses that

> the regional router is not aware of, will not be received by the MN as they

> will be dropped by the regional router.




Let me explain. In our design, other home addresses will not be dropped when no

regional entry exists. Note that in such a case, the GMA behaves like a normal

router. If the packet is targeted to the on-link CoA of the MN, this leads to

basic Mobile IPv6 behavior where gateway router is just like any other intermediate

router between HA and MN. If the HA tries to send to a regional CoA, the

entry is still in the GMA. It is the responsibility of the MN to make

sure that a regional binding cache entry in the GMA has a large enough

lifetime. And it is also the responsibility of the MN to register with

the GMA before traffic starts to arrive from remote nodes where MN registers

with a regional CoA.




=>Please refer to my comment above.






 Furthermore, MN uses either regional or non-regional

CoA but not both simultaneously when sending binding updates out of the visited

domain.




=> Why ? how can that be controlled. I think the MN should be able to use 

any of its COAs (on link and regional). I don't see a need to limit that.

Furthermore, it can't really be policed even if you want to restrict it.




> > After MN sent a BU with

> >     alternate CoA to CN, this can start sending route-optimized packets to MN

> >     via GMA. Inner packet AH is not touched in intermediate routers.

> >     Packets are forwarded locally in the visited domain and not from HA.

> >     We can thus do without using an additional routing header with tunneling.

>

> => I don't really understand how that affects our decision of adding a

> routing header. AH is not affected in our proposal either, end to end security is

> maintained. What you mention above is not related to adding a routing header from the

> HA. The routing header from the CN is mandatory according to MIPv6.




Again, I explain our design here. I only refer to MAP in how you describe

HA operation in your section 13. You use a routing entry to find home address.




Our forwarding only uses the binding cache, after which the destination

address is that of a lower CoA which is in its topologically correct place,

i.e. no mobility-specific additional routing entries are needed. Why have

extra routing state for home addresses when we have the binding cache entry,

in both designs, anyway?




=>We don't add the Routing header in the HA all the time, only for addresses that were

not registered. eg. a Site-local home address.




> > - In our design, most of the data packets are neither tunneled nor

> >    host-routed (note also that signaling is not tunneled).

> >    Route-optimized packets towards the MN are forwarded in a special

> >    way based only on the regional binding cache.

>

> => If I understand that special way you refer to correctly, it is done by

> changing the destination address in the packet. I think it is dangerous

> to allow intermediate nodes to modify packets. I think tunnelling

> is a better way to go here.




If you look at RFC2460, the pseudo-code on page 16 explains how source

routing (consumption of routing headers in intermediate routers) changes

the destination IP address in the process (swap the IPv6 Destination Address

and Address[i]). In fact, this is a precedence for changing IPhdr destination

address in intermediate routers. We don't break this, we simply don't use it

for a very special kind of a routing header, that sent by users of basic

Mobile IPv6 route optimization and this only in regional-aware routers.








We use a different kind of forwarding (a regional binding cache based next

hop routing) which does not do anything more to the packet that source

routing would, it does less . When we can skip routing header processing this

even speeds up the IP forwarding. And we avoid the tunnelling overhead for

route-optimized packets which form the vast majority of data packets.




=>There is a fundamental difference. RFC 2460 states that you can 

use the contents of the packet to change the packet. That is not 

the same as simply changing the packet. 




> > Normal processing of

> >    source-routed packets is skipped if there is a regional binding cache

> >    entry for the route-optimized home address in the regional CoA router

> >    receiving the packet. Only IPhdr destination is changed, AH prevails.

> >    The packet is then just forwarded to the lower CoA as seen in the

> >    regional binding cache.  Thus, no extra routing state is needed.

> >    This is much simpler than in Karim's proposal and is quite different

> >    from IPv4-solutions. Universal route optimization as provided in basic

> >    even possible in IPv4 due to its legacy CNs.

>

> => I don't understand why you chose not to process the routing header.

> This breaks RFC 2460 (IPv6 spec) for no reason.




First, a normal routing header processing would assume local knowledge

of home address routing. This would need the extra routing entry for the

home address when you process the routing header normally.




In our design, for the routing headers (from CNs or HAs) or even

for recapsulation, all we do is a regional binding cache lookup based

on home address which is used for all regional forwarding.




=> Ok how do you look up an entry in the Binding Cache ? I guess the key

is the Home address. Where do you get it from in the packet received from 

the CN ?




I do not consider our design choice a breach,

it is something new as was the introduction of binding cache -based

forwarding to HA in the basic Mobile IPv6. That "breaks" 2460 in that

it does not forward packets to the home link but to another address

based on MN's home binding. Our approach is analogous. For a special

mobility routing case we skip a part of 2460 to be more efficient in

header overhead and forwarding processing. Furthermore, we this way

localize this forwarding to a visited domain router.




=>I really can't see the analogy here. The breach is that you ignore

the routing header and RFC 2460 says you shouldn't.




Your HA Operation chapter 13 implies that this routing state exists and

for the cases that you explain,

"HA MUST include a routing header .. to enable the MAP to find the right

routing entry for the MN", which is what I meant by non-local forwarding

support (from the HA) for your visited-domain routing to operate correctly.




=> I think the answer to your question is in the ".." area ;)

basically Site-local addresses is the answer.




Additionally, as described in the AH RFC, IPhdr dstaddr is mutable but

predictable when a type 0 routing header is present. The check is done

for packet as seen after reception, that is, after applying routing header

in the final destination. With our design, we have the home address in

the DST field just like with basic Mobile IPv6.




Your design ends with the same, but with a bit more complicated routing

as described above. Our designs have similarities, but are not the same.




=>Yes it adds a fraction more complexity in the rare case of forwarding

Site-local packets, but it guarantees that nothing is lost. your proposal

doesn't guarantee that.




Having a convergence of some sort would be nice.. Would this call for

a framework for many regional/micro-mobility protocols or a simpler

common approach, what do you think?




=>I agree that there are some good ideas in all proposals and I look 

forward to discussing this in Pittsburgh.




It would be nice to continue discussing the options in Pittsburgh?




=> Definitely.




 





------_=_NextPart_001_01BFF89C.90084170--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Jul 28 10:20:23 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28672
	for ; Fri, 28 Jul 2000 10:20:16 -0400 (EDT)
Received: from standards (47.234.32.16:2261) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB82A5F@standards.nortelnetworks.com>; Fri, 28 Jul 2000 10:08:36 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1705 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jul 2000 10:08:36
          -0400
Received: from ftpbox.mot.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB82A5E@standards.nortelnetworks.com>; Fri, 28 Jul 2000 10:08:35
          -0400
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by
          ftpbox.mot.com (ftpbox 2.1) with ESMTP id HAA08207 for
          ; Fri, 28 Jul 2000 07:19:14
          -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 HAA22765 for
          ; Fri, 28 Jul 2000 07:19:01
          -0700 (MST)]
Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2650.21) id
          ; Fri, 28 Jul 2000 09:19:00 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  
Date:         Fri, 28 Jul 2000 09:19:00 -0500
Reply-To: Roberts Phil-QA3445 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: Roberts Phil-QA3445 
Subject:      [MOBILE-IP] handoff breakout session
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hi folks,

        we've got a room for Monday night from 7:30 to 10.  It's South Room
5.  Whoever would like to go for dinner can meet at the registration desk.
I'll be there.  Did we agree to a time?  Then we can get together in this
conference room afterwards.  We're going to restrict this to authors of
drafts only for the first session.  I'll post some talking points later.
Then during the first mobileip session hopefully we'll be able to summarize
what went on and present the group with a reduced number of proposals and
some requests for feedback on what's been done.

Thanks,
Phil


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Jul 28 10:39:42 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03684
	for ; Fri, 28 Jul 2000 10:39:41 -0400 (EDT)
Received: from standards (47.234.32.16:2261) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB82AA3@standards.nortelnetworks.com>; Fri, 28 Jul 2000 10:27:58 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1797 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jul 2000 10:27:58
          -0400
Received: from qhars002.nortel.com (47.101.112.102:53244) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB82AA2@standards.nortelnetworks.com>; Fri, 28 Jul 2000
          10:27:58 -0400
Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com;
          Fri, 28 Jul 2000 15:36:55 +0100
Received: from zrchb200.us.nortel.com (actually zrchb200) by
          smtprch1.nortel.com; Fri, 28 Jul 2000 09:30:45 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          ; Fri, 28 Jul 2000 09:28:50 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFF8A0.23E79AA0"
Message-ID:  <40DC7CF03BDDD3118F3D0000F806EEEC4F3206@zrchb199.us.nortel.com>
Date:         Fri, 28 Jul 2000 09:28:47 -0500
Reply-To: Haseeb Akhtar 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: Haseeb Akhtar 
Subject:      Re: [MOBILE-IP] handoff breakout session
X-cc:         Roberts Phil-QA3445 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFF8A0.23E79AA0
Content-Type: text/plain

Phil,

Can you please post the title of all the handoff drafts that will be
discussed
in the breakout session?

Thanks.

Haseeb

> -----Original Message-----
> From: Roberts Phil-QA3445 [SMTP:qa3445@EMAIL.MOT.COM]
> Sent: Friday, July 28, 2000 9:19 AM
> To:   MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject:      [MOBILE-IP] handoff breakout session
>
> Hi folks,
>
>         we've got a room for Monday night from 7:30 to 10.  It's South
> Room
> 5.  Whoever would like to go for dinner can meet at the registration desk.
> I'll be there.  Did we agree to a time?  Then we can get together in this
> conference room afterwards.  We're going to restrict this to authors of
> drafts only for the first session.  I'll post some talking points later.
> Then during the first mobileip session hopefully we'll be able to
> summarize
> what went on and present the group with a reduced number of proposals and
> some requests for feedback on what's been done.
>
> Thanks,
> Phil

------_=_NextPart_001_01BFF8A0.23E79AA0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: [MOBILE-IP] handoff breakout session




Phil,




Can you please post =
the title of all the handoff drafts that will be discussed 

in the breakout =
session?




Thanks.




Haseeb



    

    -----Original Message-----

    From:   Roberts Phil-QA3445 =
[SMTP:qa3445@EMAIL.MOT.COM]

    Sent:   Friday, July 28, 2000 9:19 AM

    To:     MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

    Subject:       =
 [MOBILE-IP] handoff breakout =
session

    


    Hi folks,

    


            we've got a =
room for Monday night from 7:30 to 10.  It's South Room

    5.  Whoever would like to go for =
dinner can meet at the registration desk.

    I'll be there.  Did we agree to =
a time?  Then we can get together in this

    conference room afterwards.  =
We're going to restrict this to authors of

    drafts only for the first =
session.  I'll post some talking points later.

    Then during the first mobileip =
session hopefully we'll be able to summarize

    what went on and present the group =
with a reduced number of proposals and

    some requests for feedback on what's =
been done.

    


    Thanks,

    Phil

    




------_=_NextPart_001_01BFF8A0.23E79AA0--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Jul 28 11:24: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 LAA15578
	for ; Fri, 28 Jul 2000 11:24:32 -0400 (EDT)
Received: from standards (47.234.32.16:1275) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB82B05@standards.nortelnetworks.com>; Fri, 28 Jul 2000 11:12:34 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1928 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jul 2000 11:12:34
          -0400
Received: from ftpbox.mot.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB82B04@standards.nortelnetworks.com>; Fri, 28 Jul 2000 11:12:29
          -0400
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by
          ftpbox.mot.com (ftpbox 2.1) with ESMTP id IAA04812 for
          ; Fri, 28 Jul 2000 08:23:30
          -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 IAA19923 for
          ; Fri, 28 Jul 2000 08:23:30
          -0700 (MST)]
Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2650.21) id
          ; Fri, 28 Jul 2000 10:23:30 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BFF8A7.C8512050"
Message-ID:  
Date:         Fri, 28 Jul 2000 10:23:29 -0500
Reply-To: Roberts Phil-QA3445 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: Roberts Phil-QA3445 
Subject:      [MOBILE-IP] handoff premeeting
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01BFF8A7.C8512050
Content-Type: text/plain;
        charset="iso-8859-1"


Hi folks,

        here are the talking points we'd like to use at the pre-meeting.  We
see this working as follows.  Those who want to meet for dinner do so, then
we'll retire to the South Room 5 after dinner, have some presentations on
the drafts, and use these slides to try to reach some agreements.

Phil

 <>

------_=_NextPart_000_01BFF8A7.C8512050
Content-Type: application/octet-stream;
        name="handoff.pdf"
Content-Disposition: attachment;
        filename="handoff.pdf"
Content-Transfer-Encoding: base64

JVBERi0xLjINJeLjz9MNCjE4IDAgb2JqDTw8IA0vTGluZWFyaXplZCAxIA0vTyAyMCANL0ggWyA2
MDIgMTY2IF0gDS9MIDczNjMgDS9FIDI3NzUgDS9OIDYgDS9UIDY4ODUgDT4+IA1lbmRvYmoNICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB4cmVmDTE4IDEwIA0wMDAwMDAwMDE2IDAwMDAwIG4NCjAwMDAwMDA1NDcgMDAwMDAgbg0KMDAw
MDAwMDc2OCAwMDAwMCBuDQowMDAwMDAwOTYwIDAwMDAwIG4NCjAwMDAwMDExNTIgMDAwMDAgbg0K
MDAwMDAwMTE3MyAwMDAwMCBuDQowMDAwMDAyMjc0IDAwMDAwIG4NCjAwMDAwMDI1NTIgMDAwMDAg
bg0KMDAwMDAwMDYwMiAwMDAwMCBuDQowMDAwMDAwNzQ4IDAwMDAwIG4NCnRyYWlsZXINPDwNL1Np
emUgMjgNL0luZm8gMTYgMCBSIA0vUm9vdCAxOSAwIFIgDS9QcmV2IDY4NzUgDS9JRFs8ZjUwNmYw
ZmY1M2I5NWMwNzNjMjUwMjAyNTlmMDJjOGI+PGY1MDZmMGZmNTNiOTVjMDczYzI1MDIwMjU5ZjAy
YzhiPl0NPj4Nc3RhcnR4cmVmDTANJSVFT0YNICAgICAgDTE5IDAgb2JqDTw8IA0vUGFnZXMgMTcg
MCBSIA0vVHlwZSAvQ2F0YWxvZyANPj4gDWVuZG9iag0yNiAwIG9iag08PCAvUyA1NyAvRmlsdGVy
IC9GbGF0ZURlY29kZSAvTGVuZ3RoIDI3IDAgUiA+PiANc3RyZWFtDQpIiWNgYGBmYGCKApPFDNwM
CABiA0UZOBIYGKYcuMPOdegEEgMKBICYDYoZGEQZuEWT1jA4NzEBNQIAxVgLGA1lbmRzdHJlYW0N
ZW5kb2JqDTI3IDAgb2JqDTYyIA1lbmRvYmoNMjAgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFy
ZW50IDE3IDAgUiANL1Jlc291cmNlcyA8PCAvRm9udCA8PCAvRjAgMjMgMCBSID4+IC9Qcm9jU2V0
IDI1IDAgUiA+PiANL0NvbnRlbnRzIDIxIDAgUiANL01lZGlhQm94IFsgMCAwIDc5MiA2MTIgXSAN
L0Nyb3BCb3ggWyAwIDAgNzkyIDYxMiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMjEgMCBvYmoN
PDwgL0xlbmd0aCAyMiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkli0EK
gzAURE/w7zBLXTT+/5NU3IpKD5ALFNsUXSgYpNc3Qd7APAZGIJnjB7JP5LTK8I5xfBGpD6SiRj2s
9aUQBmIUyqOZGM7de6QHG2HbZp/BRjvRrH9Ur/f22WPEsKT5TGnZt1QjrDQGugBddBy8DWVuZHN0
cmVhbQ1lbmRvYmoNMjIgMCBvYmoNMTE0IA1lbmRvYmoNMjMgMCBvYmoNPDwgDS9UeXBlIC9Gb250
IA0vU3VidHlwZSAvVHJ1ZVR5cGUgDS9OYW1lIC9GMCANL0Jhc2VGb250IC9UaW1lc05ld1JvbWFu
IA0vRmlyc3RDaGFyIDMyIA0vTGFzdENoYXIgMjU1IA0vV2lkdGhzIFsgMjUwIDMzMyA0MDggNTAw
IDUwMCA4MzMgNzc4IDE4MCAzMzMgMzMzIDUwMCA1NjQgMjUwIDMzMyAyNTAgMjc4IDUwMCANNTAw
IDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgMjc4IDI3OCA1NjQgNTY0IDU2NCA0NDQg
OTIxIA03MjIgNjY3IDY2NyA3MjIgNjExIDU1NiA3MjIgNzIyIDMzMyAzODkgNzIyIDYxMSA4ODkg
NzIyIDcyMiA1NTYgDTcyMiA2NjcgNTU2IDYxMSA3MjIgNzIyIDk0NCA3MjIgNzIyIDYxMSAzMzMg
Mjc4IDMzMyA0NjkgNTAwIDMzMyANNDQ0IDUwMCA0NDQgNTAwIDQ0NCAzMzMgNTAwIDUwMCAyNzgg
Mjc4IDUwMCAyNzggNzc4IDUwMCA1MDAgNTAwIA01MDAgMzMzIDM4OSAyNzggNTAwIDUwMCA3MjIg
NTAwIDUwMCA0NDQgNDgwIDIwMCA0ODAgNTQxIDc3OCA1MDAgDTc3OCAzMzMgNTAwIDQ0NCAxMDAw
IDUwMCA1MDAgMzMzIDEwMDAgNTU2IDMzMyA4ODkgNzc4IDYxMSA3NzggNzc4IA0zMzMgMzMzIDQ0
NCA0NDQgMzUwIDUwMCAxMDAwIDMzMyA5ODAgMzg5IDMzMyA3MjIgNzc4IDQ0NCA3MjIgMjUwIA0z
MzMgNTAwIDUwMCA1MDAgNTAwIDIwMCA1MDAgMzMzIDc2MCAyNzYgNTAwIDU2NCAzMzMgNzYwIDUw
MCA0MDAgDTU0OSAzMDAgMzAwIDMzMyA1NzYgNDUzIDI1MCAzMzMgMzAwIDMxMCA1MDAgNzUwIDc1
MCA3NTAgNDQ0IDcyMiANNzIyIDcyMiA3MjIgNzIyIDcyMiA4ODkgNjY3IDYxMSA2MTEgNjExIDYx
MSAzMzMgMzMzIDMzMyAzMzMgNzIyIA03MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA1NjQgNzIyIDcy
MiA3MjIgNzIyIDcyMiA3MjIgNTU2IDUwMCA0NDQgDTQ0NCA0NDQgNDQ0IDQ0NCA0NDQgNjY3IDQ0
NCA0NDQgNDQ0IDQ0NCA0NDQgMjc4IDI3OCAyNzggMjc4IDUwMCANNTAwIDUwMCA1MDAgNTAwIDUw
MCA1MDAgNTQ5IDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgXSANL0VuY29kaW5nIC9X
aW5BbnNpRW5jb2RpbmcgDS9Gb250RGVzY3JpcHRvciAyNCAwIFIgDT4+IA1lbmRvYmoNMjQgMCBv
YmoNPDwgDS9UeXBlIC9Gb250RGVzY3JpcHRvciANL0ZvbnROYW1lIC9UaW1lc05ld1JvbWFuIA0v
RmxhZ3MgMzQgDS9Gb250QkJveCBbIC0yNTAgLTIxNiAxMTcxIDEwMDAgXSANL01pc3NpbmdXaWR0
aCAzMjUgDS9TdGVtViA3MyANL1N0ZW1IIDczIA0vSXRhbGljQW5nbGUgMCANL0NhcEhlaWdodCA4
OTEgDS9YSGVpZ2h0IDQ0NiANL0FzY2VudCA4OTEgDS9EZXNjZW50IC0yMTYgDS9MZWFkaW5nIDE0
OSANL01heFdpZHRoIDk3NiANL0F2Z1dpZHRoIDQwMSANPj4gDWVuZG9iag0yNSAwIG9iag1bIA0v
UERGIC9UZXh0IA1dDWVuZG9iag0xIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAxNyAw
IFIgDS9SZXNvdXJjZXMgPDwgL0ZvbnQgPDwgL0YwIDIzIDAgUiA+PiAvUHJvY1NldCAyNSAwIFIg
Pj4gDS9Db250ZW50cyAyIDAgUiANL01lZGlhQm94IFsgMCAwIDc5MiA2MTIgXSANL0Nyb3BCb3gg
WyAwIDAgNzkyIDYxMiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMiAwIG9iag08PCAvTGVuZ3Ro
IDMgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJrVK7ctwgFP0C/cMtnUIy
b0SbcV5FGs+WbuTV1S6JJW1A8o7/3oDA3mI94yKDZkDAPa8LBRqGO0DFFYRPMwJSEHAIQ/V1VzGl
GiZBKB0n2N1VBOKIFbffCQix7Q9VTRqmWhHWeyCNkNKE5RlufiMudjrAj7l78l9g96eqqWobLaHW
aQqgEKE4u4AiPJ0EqA3lgTGZiplOW3cQ+ajSmU9qkvl+ds8IHYyZdh5gOSKMdup9+enW5Tg7DwmQ
QM1FIwsmVZRlTC5avWHmuufO2Xn10LtuWLKXoKcWrFR/SjZVRmUKprjYbt5jv+4x0Uzr+Iguit2I
YJnh5NDjtMTlNdWsNaYkr3WGjFjn2f2NMaSi4C1G/C7EaHOp9uDm9ZRb1Lbx6jVrH5iSb72gJlUF
wF990GyHF+jtMKDDaY8e7BRe17/VOhzDqYdHPIbmXG+GYMUW5+TC1v/qhDGy4Jdev2l+sqPdwo+M
fj+fsDygmOpVwUTxkgKTNKdwPgbrMGEw7zv3kuq+7apXp93gSA1lbmRzdHJlYW0NZW5kb2JqDTMg
MCBvYmoNMzk2IA1lbmRvYmoNNCAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMTcgMCBS
IA0vUmVzb3VyY2VzIDw8IC9Gb250IDw8IC9GMCAyMyAwIFIgPj4gL1Byb2NTZXQgMjUgMCBSID4+
IA0vQ29udGVudHMgNSAwIFIgDS9NZWRpYUJveCBbIDAgMCA3OTIgNjEyIF0gDS9Dcm9wQm94IFsg
MCAwIDc5MiA2MTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTUgMCBvYmoNPDwgL0xlbmd0aCA2
IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiY2SzU6EMBDHn6DvMEc9gP0u
nEzManwAEi9e6lKWNbglfCzRp3daYGWNB1MCkzLz//9mWgYMV3cAIjTgYzgFJSl0DiryUBCueapA
apNyBVDsCIWwQsHdEwUp5/2KJDRlzDCM90BTQaXGcIKbZ3sqfVXBrrPV0N9C8U4SphUkGUtNlIQg
JPhGiIr4B4VmjVfOVazkJm7tILjlVK9uJmNz5ovDXH52cPADWGjwPRdSHfQvxVzkYuuQxCyWBaQf
B0OzxWEJMfNsm9G+NQ4Gj0Mqx72DqXY4rrk1JIVEZMu0sJJSeeXU+r4/Yv2SbiCROlWr5aXzv3vG
NlYikUfdMGE/wYc9fULbeVS3TQ+lhwm57GkImO0YP1GNbumCocnNosi14bPiUOMAOz+29xtKtR7X
fw+IC70kpUow9gvWtohr97W7pq3d35ycy1VMsgUzIobO+gEvme3K45ebiR8L8g1vaK+9DWVuZHN0
cmVhbQ1lbmRvYmoNNiAwIG9iag0zNTUgDWVuZG9iag03IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSAN
L1BhcmVudCAxNyAwIFIgDS9SZXNvdXJjZXMgPDwgL0ZvbnQgPDwgL0YwIDIzIDAgUiA+PiAvUHJv
Y1NldCAyNSAwIFIgPj4gDS9Db250ZW50cyA4IDAgUiANL01lZGlhQm94IFsgMCAwIDc5MiA2MTIg
XSANL0Nyb3BCb3ggWyAwIDAgNzkyIDYxMiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNOCAwIG9i
ag08PCAvTGVuZ3RoIDkgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJpZTN
btswDMefwO/AYwfMrr5lX4tu2LBLgeW4ixbLidpYyiQXwd5++nKaNShQbLBhEwbJ358iaQw4Xn4H
DRUQb0kQcIbAa5iau01DqOgIByZkesHmvkGQrhRx+xkBY+X71LSoQwPD0d5CtimL9gluvig7ummC
O6/Vk3te4ANsHpsW076THFpJu5wYUjrC1lyY50yo5PhBCM9hROZP9wmBiZTFqeOIyOL5feuOGtwE
+4LNUQO0FCXamYNW2aij8jVKFBSJwl5gtKcVhiTvi+/JLHtjQUEwdnfQMLpZGVvqy+Et6Wt17+ZI
xlaOwEPxVVvvQqjpAzgLy15DULOGRW/31h3c7vf/YTnpz62jTL7FHc00aa/tcgXmCdlS+g+9jEjS
v0xOsaPng9o+6QUOSYPXv56N13NEh1qpjDhW63zfxCAhhhUjeor/HtDs3vPLY+GMXiZdzKyzF+vP
0nGdi5trhVigfCbXIt+QRwVZe1/MyPxm7Jjm2djJ+VktJnXfKxtiH7wei2qKhrMgwvtLzW12wPSy
LHTmEDbw2uu48nGq4tNqPQYI+qi8WnRdV1oHa6j/gZJGrjtBOKs7MXk3x0Qu5C38+gDH0kUfVz9u
CcTDBjNBcB9h705xtnSI7iYUDrqY3XRcDItKoEM2IyHpg8XBT52X/KDHHPpp0/wB8tcvDA1lbmRz
dHJlYW0NZW5kb2JqDTkgMCBvYmoNNTEzIA1lbmRvYmoNMTAgMCBvYmoNPDwgDS9UeXBlIC9QYWdl
IA0vUGFyZW50IDE3IDAgUiANL1Jlc291cmNlcyA8PCAvRm9udCA8PCAvRjAgMjMgMCBSID4+IC9Q
cm9jU2V0IDI1IDAgUiA+PiANL0NvbnRlbnRzIDExIDAgUiANL01lZGlhQm94IFsgMCAwIDc5MiA2
MTIgXSANL0Nyb3BCb3ggWyAwIDAgNzkyIDYxMiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMTEg
MCBvYmoNPDwgL0xlbmd0aCAxMiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K
SIndV0uSmzAQPQF30NJZQCShD96mnFQO4GU2GhsCMSACeJLcPkJq4u8QMR47VSm8cNEfqV93v24I
IuZpv6IgFsj8JMWIM4zaFGXBh3VABY04YkJGlCO0XgUYDc9g8P4TRoy591kQ4ogQScz/DcJRjJkw
f3+gxWdVb3WWoVWrsr57h9bfgpAIjkLj2LlEgyNCrRdj6Tw44y+UcmtCpX21QvYYZnUW1qUTs0jy
gwa1hxuN0EpZNMpwhGOxdLKNKnO9r61GLKOXzflwz4NQEu6klX4qyrRo3BnkVGvSBYUAqsIdT+QM
Yzi9VC50MuNgnIzQ5S4rLnjhg5x7jUnkTj1ClIJJ/9PdKKSmfkIb4yB3Cb1DKgmj4LvTZVGpf5LK
WAKgVdE8i/l44jM8jQ2T7BxQTAZAB2DujCkmFNpj1xZdXqtq3/Z5YfWEmPJyXmnsGrLU4xI2BAHC
p32WpS3gyiYy+1pkaTIE9YBqxWNIfa5KVav6l1MRXkHdBilA8j33YIy/A3mt5Uky2HnXaBxbvjfi
7QFK4t34IoEaTasGOAx7JoFBx2+2lXLHCk80juhCNU3pjPE8KM/Z82pNEp4MXv1q8kYkMUzsRVpW
qty5Ro+5PwESKeW8sjwjCrIEUDPVwUTzb4nlOAFgnnUeBH6ZFeoz0ygFonhMhQtwvtVVlfbAFXdj
31NzOa4Y0CKTCTk1ZRzGx59pOLdF/Gib0Me0yAAmB5mu06IsL9xP2bJxYqQjlEv/7eSwJbr8keSt
YSRM3rOij+IxJT22VJH22cXdJlcSuNVO621Z+NP9wE4YSrmrtO5zKEk2uW6/FkvJ/DeJ29jh5m+Y
27YzzBhQftNqtemL59QpMf+xsRzjz1xfJHeYo9Q02/9L2ScFwWEhUvUm160rB+oH6Rt/Fp7AdZGT
j+vgN6Xxjf4NZW5kc3RyZWFtDWVuZG9iag0xMiAwIG9iag02OTIgDWVuZG9iag0xMyAwIG9iag08
PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMTcgMCBSIA0vUmVzb3VyY2VzIDw8IC9Gb250IDw8IC9G
MCAyMyAwIFIgPj4gL1Byb2NTZXQgMjUgMCBSID4+IA0vQ29udGVudHMgMTQgMCBSIA0vTWVkaWFC
b3ggWyAwIDAgNzkyIDYxMiBdIA0vQ3JvcEJveCBbIDAgMCA3OTIgNjEyIF0gDS9Sb3RhdGUgMCAN
Pj4gDWVuZG9iag0xNCAwIG9iag08PCAvTGVuZ3RoIDE1IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29k
ZSA+PiANc3RyZWFtDQpIiXWQTW7DIBCFT+A7zLJd2IUxNs62TbvrzstuqE1iKgcsoLFy+06w86Oq
FQgN8Obj8ThwGn4PWVkDTYkMKsHAa9hlz22GQhYViFoWWAG024zBeZwbnt4YCLGc77KcFRxlTXUH
rCh5xamc4eFlUD5qD+/K9irqR2i/spxXDPKGFzIx4Uwq8Y7EynRDpAXygVilTpTpaAtJJFZRgYiL
cKtpyyBpOWNk/SrHclPeM/NF1NwUvKlkUqQ6qRPyqEc3gbKguk6HAFF3g3Wj259g/Q5v6KW8bNaQ
EkDW8hJGLVZ7xvZ60rTYCAcdB9fDznkI39PkfDR2D6ObFyj7zeOba7hMruGOlKjtTjBQuO5IKX/q
OGt9dTo5Y2O4ATdXmkB+oWECE202cTA2fbQ/GGtC9Cqao4beHRRdkFPVeRfCPw6R8ZvDlfknKRQJ
8NpmP0IFosENZW5kc3RyZWFtDWVuZG9iag0xNSAwIG9iag0zMzYgDWVuZG9iag0xNiAwIG9iag08
PCANL0NyZWF0b3IgKFwzNzZcMzc3XDAwME1cMDAwaVwwMDBjXDAwMHJcMDAwb1wwMDBzXDAwMG9c
MDAwZlwwMDB0XDAwMCBcMDAwUFwwMDBvXDAwMFwNd1wwMDBlXDAwMHJcMDAwUFwwMDBvXDAwMGlc
MDAwblwwMDB0XDAwMCBcMDAwLVwwMDAgXDAwMFtcMDAwaFwwMDBhXDAwMG5cMDAwXA1kXDAwMG9c
MDAwZlwwMDBmXDAwMC5cMDAwcFwwMDBwXDAwMHRcMDAwXSkNL0NyZWF0aW9uRGF0ZSAoRDoyMDAw
MDcyODEwMTY1NikNL1RpdGxlIChcMzc2XDM3N1wwMDBoXDAwMGFcMDAwblwwMDBkXDAwMG9cMDAw
ZlwwMDBmXDAwMC5cMDAwUFwwMDBEXDAwMEYpDS9BdXRob3IgKFwzNzZcMzc3XDAwMHJcMDAwcFww
MDBhXDAwMHRcMDAwaVwwMDBsKQ0vUHJvZHVjZXIgKEFjcm9iYXQgUERGV3JpdGVyIDQuMCBmb3Ig
V2luZG93cyBOVCkNL01vZERhdGUgKEQ6MjAwMDA3MjgxMDIxMjgpDT4+IA1lbmRvYmoNMTcgMCBv
YmoNPDwgDS9LaWRzIFsgMjAgMCBSIDEgMCBSIDQgMCBSIDcgMCBSIDEwIDAgUiAxMyAwIFIgXSAN
L0NvdW50IDYgDS9UeXBlIC9QYWdlcyANPj4gDWVuZG9iag14cmVmDTAgMTggDTAwMDAwMDAwMDAg
NjU1MzUgZg0KMDAwMDAwMjU4NSAwMDAwMCBuDQowMDAwMDAyNzc1IDAwMDAwIG4NCjAwMDAwMDMy
NDcgMDAwMDAgbg0KMDAwMDAwMzI2NyAwMDAwMCBuDQowMDAwMDAzNDU3IDAwMDAwIG4NCjAwMDAw
MDM4ODggMDAwMDAgbg0KMDAwMDAwMzkwOCAwMDAwMCBuDQowMDAwMDA0MDk4IDAwMDAwIG4NCjAw
MDAwMDQ2ODcgMDAwMDAgbg0KMDAwMDAwNDcwNyAwMDAwMCBuDQowMDAwMDA0ODk5IDAwMDAwIG4N
CjAwMDAwMDU2NjkgMDAwMDAgbg0KMDAwMDAwNTY5MCAwMDAwMCBuDQowMDAwMDA1ODgyIDAwMDAw
IG4NCjAwMDAwMDYyOTYgMDAwMDAgbg0KMDAwMDAwNjMxNyAwMDAwMCBuDQowMDAwMDA2Nzc3IDAw
MDAwIG4NCnRyYWlsZXINPDwNL1NpemUgMTgNL0lEWzxmNTA2ZjBmZjUzYjk1YzA3M2MyNTAyMDI1
OWYwMmM4Yj48ZjUwNmYwZmY1M2I5NWMwNzNjMjUwMjAyNTlmMDJjOGI+XQ0+Pg1zdGFydHhyZWYN
MTczDSUlRU9GDQ==

------_=_NextPart_000_01BFF8A7.C8512050--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Jul 28 11:37:25 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20876
	for ; Fri, 28 Jul 2000 11:37:24 -0400 (EDT)
Received: from standards (47.234.32.16:1275) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB82B46@standards.nortelnetworks.com>; Fri, 28 Jul 2000 11:25:41 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2018 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jul 2000 11:25:41
          -0400
Received: from omega.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB82B45@standards.nortelnetworks.com>; Fri, 28 Jul 2000 11:25:41
          -0400
Received: from gdommety-laptop1.cisco.com (gdommety-dsl3.cisco.com
          [10.19.17.140]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8)
          with ESMTP id IAA16753; Fri, 28 Jul 2000 08:36:42 -0700 (PDT)
X-Sender: gdommety@omega.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.20000728082937.00b65390@omega.cisco.com>
Date:         Fri, 28 Jul 2000 08:41:16 -0700
Reply-To: Gopal Dommety 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: Gopal Dommety 
Subject:      Re: [MOBILE-IP] handoff breakout session
X-To:         Roberts Phil-QA3445 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  

Phil,

         Given that time is limited, why don't we have a working dinner (
Everyone gets their own dinner - Just clarification :).  Just to make sure we
read all the drafts, here is a starting list (please add to the list -
Hopefully by the
end of this email thread we will have the entire list).

          E. Gustafsson, et. al.  Mobile IP Regional Tunnel Management.
       draft-ietf-mobileip-reg-tunnel-01.txt, August 1999.

        J. Kempf, P. Calhoun, and C. Pairla, Foreign Agent Assisted Hand-off,
         draft-calhoun-mobileip-proactive-fa-01.txt, June 2002

         G. Dommety  and T.  Ye, "Local  and Indirect  Registration for
         Anchoring Handoffs",
         draft-dommety-mobileip-anchor-handoff-01.txt(work  in
         progress), July 2000.

          K. El Malki, et. al.  Fast Handoff Method for Real-Time Traffic
       over Scaleable Mobile IP Networks.
       draft-elmalki-mobileip-fast-handoffs-01.txt, June 1999.

There are also IPv6 drafts, I think it is a better to have another breakout
for that (There are some
issues that are common and some different -just to keep the group
focused).  what do you think?


At 09:19 AM 7/28/00 -0500, Roberts Phil-QA3445 wrote:
>Hi folks,
>
>         we've got a room for Monday night from 7:30 to 10.  It's South Room
>5.  Whoever would like to go for dinner can meet at the registration desk.
>I'll be there.  Did we agree to a time?  Then we can get together in this
>conference room afterwards.  We're going to restrict this to authors of
>drafts only for the first session.  I'll post some talking points later.
>Then during the first mobileip session hopefully we'll be able to summarize
>what went on and present the group with a reduced number of proposals and
>some requests for feedback on what's been done.
>
>Thanks,
>Phil


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Jul 28 11:48:36 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24611
	for ; Fri, 28 Jul 2000 11:48:35 -0400 (EDT)
Received: from standards (47.234.32.16:1275) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB82B72@standards.nortelnetworks.com>; Fri, 28 Jul 2000 11:36:53 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2079 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jul 2000 11:36:53
          -0400
Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1b) with SMTP id <0.FFB82B71@standards.nortelnetworks.com>;
          Fri, 28 Jul 2000 11:36:52 -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 JAA17570; Fri, 28 Jul 2000 09:47:51
          -0600 (MDT)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by
          engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id
          IAA07903; Fri, 28 Jul 2000 08:47:49 -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 IAA27917; Fri, 28
          Jul 2000 08:47:34 -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:  <200007281547.IAA27917@nasnfs.eng.sun.com>
Date:         Fri, 28 Jul 2000 07:48: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] handoff breakout session
X-To:         Gopal Dommety 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

I agree that the MIPv6 should be handled separately.

                jak
>Phil,
>
>         Given that time is limited, why don't we have a working dinner (
>Everyone gets their own dinner - Just clarification :).  Just to make sure we
>read all the drafts, here is a starting list (please add to the list -
>Hopefully by the
>end of this email thread we will have the entire list).
>
>          E. Gustafsson, et. al.  Mobile IP Regional Tunnel Management.
>       draft-ietf-mobileip-reg-tunnel-01.txt, August 1999.
>
>        J. Kempf, P. Calhoun, and C. Pairla, Foreign Agent Assisted Hand-off,
>         draft-calhoun-mobileip-proactive-fa-01.txt, June 2002
>
>         G. Dommety  and T.  Ye, "Local  and Indirect  Registration for
>         Anchoring Handoffs",
>         draft-dommety-mobileip-anchor-handoff-01.txt(work  in
>         progress), July 2000.
>
>          K. El Malki, et. al.  Fast Handoff Method for Real-Time Traffic
>       over Scaleable Mobile IP Networks.
>       draft-elmalki-mobileip-fast-handoffs-01.txt, June 1999.
>
>There are also IPv6 drafts, I think it is a better to have another breakout
>for that (There are some
>issues that are common and some different -just to keep the group
>focused).  what do you think?
>
>
>At 09:19 AM 7/28/00 -0500, Roberts Phil-QA3445 wrote:
>>Hi folks,
>>
>>         we've got a room for Monday night from 7:30 to 10.  It's South Room
>>5.  Whoever would like to go for dinner can meet at the registration desk.
>>I'll be there.  Did we agree to a time?  Then we can get together in this
>>conference room afterwards.  We're going to restrict this to authors of
>>drafts only for the first session.  I'll post some talking points later.
>>Then during the first mobileip session hopefully we'll be able to summarize
>>what went on and present the group with a reduced number of proposals and
>>some requests for feedback on what's been done.
>>
>>Thanks,
>>Phil


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Jul 28 11:52:43 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25525
	for ; Fri, 28 Jul 2000 11:52:42 -0400 (EDT)
Received: from standards (47.234.32.16:1275) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB82BA0@standards.nortelnetworks.com>; Fri, 28 Jul 2000 11:39:47 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2067 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jul 2000 11:39:47
          -0400
Received: from prue.eim.surrey.ac.uk by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB82B68@standards.nortelnetworks.com>; Fri, 28 Jul 2000 11:29:47
          -0400
Received: from carter-e0.ee.surrey.ac.uk ([131.227.86.16]) by
          prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 13ICFl-00047O-00
          for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jul 2000 16:40:49
          +0100
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID:  
Date:         Fri, 28 Jul 2000 16:40:48 +0100
Reply-To: Karann Chew 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: Karann Chew 
Subject:      [MOBILE-IP] A Question on Mobile IP Regional Tunneling
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hi folks!

I've just read "draft-ietf-mobileip-regtun-03.txt".
A question strike me...

Section B1. Registration with Home Agent says:

"If there is a hierarchy of foreign agents between the GFA and the
announcing foreign agent, the foreign agent MAY include the corresponding
addresses in order between its own address (first) and the GFA address
(last):
    -  Address of announcing foreign agent
    -  Address of the next higher-level Regional Foreign Agent (RFA)
    -  ...
    -  Address of GFA"


In other words, the leave FA advertise the addresses of RFA and GFA
located along the path towards the root.  But what's the need of
advertising all these addresses?  Why not advertising only the
serving-FA's and GFA's addresses only, with 'I' bit set?

Apology if this question has been addressed.  I missed the past
discussions, and am currently trying to catch up with the works
related to micro mobility management done in this group.

Cheers!
        Karann

******************************************
Karann Chew
Mobile Communications Research Group
Centre for Communication Systems Research
University of Surrey, UK
******************************************


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Jul 28 12:01:19 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27611
	for ; Fri, 28 Jul 2000 12:01:19 -0400 (EDT)
Received: from standards (47.234.32.16:1275) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB82BEC@standards.nortelnetworks.com>; Fri, 28 Jul 2000 11:49:39 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2249 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jul 2000 11:49:39
          -0400
Received: from smtpgw1.sprintspectrum.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB82BEB@standards.nortelnetworks.com>; Fri, 28 Jul 2000 11:49:39
          -0400
Received: from pkcex004.sprintspectrum.com (pkcex004.sprintspectrum.com
          [208.10.75.139]) by smtpgw1.sprintspectrum.com (8.9.3/8.9.3) with
          ESMTP id LAA18794 for ; Fri,
          28 Jul 2000 11:00:40 -0500 (CDT)
Received: by pkcex004.sprintspectrum.com with Internet Mail Service
          (5.5.2650.21) id <36SRW9KT>; Fri, 28 Jul 2000 11:00:37 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="ISO-8859-1"
Message-ID:  <2D11BCC7FFD8D3118FD70000D1ECDC88011D5DA8@pkcexv018.sprintspectrum.com>
Date:         Fri, 28 Jul 2000 11:00:36 -0500
Reply-To: "Lipford, Mark" 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: "Lipford, Mark" 
Subject:      [MOBILE-IP] Foreign Agent Challenge I-D #13
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

All,

I am very concerned that the FA Challenge Draft (#13) has not moved to RFC
status.  As an Operator that is very dependent on this draft being completed
so the work in 3GPP2 can be completed I need to see this move forward.  My
understanding that the only difference in #13 and #12 that completed last
call was the title was changed to state IP V4, a table of contents was
added, and an IANA URL was corrected.  None of these appear to be technical
to me.  I would like to see a few minutes at the beginning of the first
mobileip wg session be spent with the co-chairs updating us on its status
and what is needs to get this completed.  I believe all requirements to move
it to RFC have been completed.

Thanks,

Mark A. Lipford
Manager, Wireless Industry Standards - Data
Sprint PCS
15405 College Blvd.
Lenexa, KS  66219

(913) 890-4248 (office)
(913) 890- 4100 (fax)
(913) 226-9060 (PCS)


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Jul 28 12:05:59 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 MAA28650
	for ; Fri, 28 Jul 2000 12:05:58 -0400 (EDT)
Received: from standards (47.234.32.16:1275) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB82C1A@standards.nortelnetworks.com>; Fri, 28 Jul 2000 11:54:04 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2312 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jul 2000 11:54:04
          -0400
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFB82C17@standards.nortelnetworks.com>; Fri, 28 Jul 2000 11:53:59
          -0400
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
          by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA26037;
          Fri, 28 Jul 2000 09:05:01 -0700 (PDT)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.9.3/8.9.3-VIRSCAN) id JAA28977; Fri, 28 Jul 2000 09:04:59 -0700
X-Virus-Scanned:  Fri, 28 Jul 2000 09:04:59 -0700 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from charliep.iprg.nokia.com (205.226.2.89,
          claiming to be "iprg.nokia.com") by
          darkstar.iprg.nokia.com(WTS.12.69) smtpdd64pmh; Fri, 28 Jul 2000
          09:04:56 PDT
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3981AF2A.257DAD94@iprg.nokia.com>
Date:         Fri, 28 Jul 2000 09:04:58 -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] A Question on Mobile IP Regional Tunneling
X-To:         Karann Chew 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello Karann,

First, since I'm typing away, let me again register my objection
to the term "micromobility":
- It gets confused with "link mobility"
- The area over which mobility may be managed might be not
  at all "micro"
So, the term is _harmful_ in my opinion.  "Intra-domain" mobility
is much, much better.

Having said that, here is my answer to your question.

It turns out to be easier for the mobile node to determine
the crossover router, if the information is available.
However, if the router hierarchy does not wish to advertise
its internal structure, then it should _still_ be possible
for the system to work.  Thus, in the draft, we allowed for
both possibilities.  If no one implements the fully advertised
model, then it will be deleted from the draft.

Regards,
Charlie P.


Karann Chew wrote:
>
> Hi folks!
>
> I've just read "draft-ietf-mobileip-regtun-03.txt".
> A question strike me...
>
> Section B1. Registration with Home Agent says:
>
> "If there is a hierarchy of foreign agents between the GFA and the
> announcing foreign agent, the foreign agent MAY include the corresponding
> addresses in order between its own address (first) and the GFA address
> (last):
>     -  Address of announcing foreign agent
>     -  Address of the next higher-level Regional Foreign Agent (RFA)
>     -  ...
>     -  Address of GFA"
>
> In other words, the leave FA advertise the addresses of RFA and GFA
> located along the path towards the root.  But what's the need of
> advertising all these addresses?  Why not advertising only the
> serving-FA's and GFA's addresses only, with 'I' bit set?
>
> Apology if this question has been addressed.  I missed the past
> discussions, and am currently trying to catch up with the works
> related to micro mobility management done in this group.
>
> Cheers!
>         Karann
>
> ******************************************
> Karann Chew
> Mobile Communications Research Group
> Centre for Communication Systems Research
> University of Surrey, UK
> ******************************************


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Jul 28 12:14:46 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00633
	for ; Fri, 28 Jul 2000 12:14:46 -0400 (EDT)
Received: from standards (47.234.32.16:1275) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB82C56@standards.nortelnetworks.com>; Fri, 28 Jul 2000 12:02:56 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2397 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jul 2000 12:02:56
          -0400
Received: from omega.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB82C55@standards.nortelnetworks.com>; Fri, 28 Jul 2000 12:02:56
          -0400
Received: from gdommety-laptop1.cisco.com (gdommety-dsl3.cisco.com
          [10.19.17.140]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8)
          with ESMTP id JAA20971 for ;
          Fri, 28 Jul 2000 09:13:58 -0700 (PDT)
X-Sender: gdommety@omega.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.3.1.2.20000728091618.00b6ccb0@omega.cisco.com>
Date:         Fri, 28 Jul 2000 09:18:27 -0700
Reply-To: Gopal Dommety 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: Gopal Dommety 
Subject:      Re: [MOBILE-IP] handoff breakout session
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <4.3.1.2.20000728082937.00b65390@omega.cisco.com>

Phil,

         Sorry, looks like our messages crossed in transit somewhere on the
cyber-road :) Just saw your
"handoff premeeting" mail.

Thanks
-Gopal


At 08:41 AM 7/28/00 -0700, Gopal Dommety wrote:
>Phil,
>
>         Given that time is limited, why don't we have a working dinner (
>Everyone gets their own dinner - Just clarification :).  Just to make sure we
>read all the drafts, here is a starting list (please add to the list -
>Hopefully by the
>end of this email thread we will have the entire list).
>
>          E. Gustafsson, et. al.  Mobile IP Regional Tunnel Management.
>       draft-ietf-mobileip-reg-tunnel-01.txt, August 1999.
>
>        J. Kempf, P. Calhoun, and C. Pairla, Foreign Agent Assisted Hand-off,
>         draft-calhoun-mobileip-proactive-fa-01.txt, June 2002
>
>         G. Dommety  and T.  Ye, "Local  and Indirect  Registration for
>         Anchoring Handoffs",
>         draft-dommety-mobileip-anchor-handoff-01.txt(work  in
>         progress), July 2000.
>
>          K. El Malki, et. al.  Fast Handoff Method for Real-Time Traffic
>       over Scaleable Mobile IP Networks.
>       draft-elmalki-mobileip-fast-handoffs-01.txt, June 1999.
>
>There are also IPv6 drafts, I think it is a better to have another breakout
>for that (There are some
>issues that are common and some different -just to keep the group
>focused).  what do you think?
>
>
>At 09:19 AM 7/28/00 -0500, Roberts Phil-QA3445 wrote:
>>Hi folks,
>>
>>         we've got a room for Monday night from 7:30 to 10.  It's South Room
>>5.  Whoever would like to go for dinner can meet at the registration desk.
>>I'll be there.  Did we agree to a time?  Then we can get together in this
>>conference room afterwards.  We're going to restrict this to authors of
>>drafts only for the first session.  I'll post some talking points later.
>>Then during the first mobileip session hopefully we'll be able to summarize
>>what went on and present the group with a reduced number of proposals and
>>some requests for feedback on what's been done.
>>
>>Thanks,
>>Phil
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Jul 28 12:22:04 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02293
	for ; Fri, 28 Jul 2000 12:22:03 -0400 (EDT)
Received: from standards (47.234.32.16:1275) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB82C64@standards.nortelnetworks.com>; Fri, 28 Jul 2000 12:03:53 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2308 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jul 2000 12:03:52
          -0400
Received: from thumper.research.telcordia.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB82C16@standards.nortelnetworks.com>; Fri, 28 Jul 2000 11:53:51
          -0400
Received: from marvel.research.telcordia.com (marvel [192.4.16.140]) by
          thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id
          e6SG4qR19147; Fri, 28 Jul 2000 12:04:52 -0400 (EDT)
Received: from marvel (marvel.research.telcordia.com [192.4.16.140]) by
          marvel.research.telcordia.com (8.8.8/8.8.8) with SMTP id MAA02662;
          Fri, 28 Jul 2000 12:04:51 -0400 (EDT)
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 84GeMtnN2JDI0mhCAlCwZQ==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc
Message-ID:  <200007281604.MAA02662@marvel.research.telcordia.com>
Date:         Fri, 28 Jul 2000 12:04:51 -0400
Reply-To: Subir Das 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: Subir Das 
Subject:      Re: [MOBILE-IP] handoff breakout session
X-To:         gdommety@cisco.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

>Phil,
>
>         Given that time is limited, why don't we have a working dinner (
>Everyone gets their own dinner - Just clarification :).  Just to make sure we
>read all the drafts, here is a starting list (please add to the list -
>Hopefully by the
>end of this email thread we will have the entire list).


 I agree with you. I am adding our draft to the ilist.

 Thanks,

 Subir



>
>          E. Gustafsson, et. al.  Mobile IP Regional Tunnel Management.
>       draft-ietf-mobileip-reg-tunnel-01.txt, August 1999.
>
>        J. Kempf, P. Calhoun, and C. Pairla, Foreign Agent Assisted Hand-off,
>         draft-calhoun-mobileip-proactive-fa-01.txt, June 2002
>
>         G. Dommety  and T.  Ye, "Local  and Indirect  Registration for
>         Anchoring Handoffs",
>         draft-dommety-mobileip-anchor-handoff-01.txt(work  in
>         progress), July 2000.
>
>          K. El Malki, et. al.  Fast Handoff Method for Real-Time Traffic
>       over Scaleable Mobile IP Networks.
>       draft-elmalki-mobileip-fast-handoffs-01.txt, June 1999.

        A. Misra, S, Das, A. Ncauley, A. Dutta and S. K. Das, IDMP: An Intra-
        Domain Mobility management Protocol using Mobility Agents.
        draft-misra-mobileip-idmp-00.txt, July 2000

>
>There are also IPv6 drafts, I think it is a better to have another breakout
>for that (There are some
>issues that are common and some different -just to keep the group
>focused).  what do you think?
>
>
>At 09:19 AM 7/28/00 -0500, Roberts Phil-QA3445 wrote:
>>Hi folks,
>>
>>         we've got a room for Monday night from 7:30 to 10.  It's South Room
>>5.  Whoever would like to go for dinner can meet at the registration desk.
>>I'll be there.  Did we agree to a time?  Then we can get together in this
>>conference room afterwards.  We're going to restrict this to authors of
>>drafts only for the first session.  I'll post some talking points later.
>>Then during the first mobileip session hopefully we'll be able to summarize
>>what went on and present the group with a reduced number of proposals and
>>some requests for feedback on what's been done.
>>
>>Thanks,
>>Phil

********************************************************************************
Subir Das                         Ofc: MCC 1D-210R
Telcordia Technologies            Tel: 973 829 4959
(Formerly Bellcore)               Fax: 973 829 5888
445, South Street              E-mail: subir@research.telcordia.com
Morristown, NJ 07960-6438
********************************************************************************


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Jul 28 12:22:04 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02295
	for ; Fri, 28 Jul 2000 12:22:04 -0400 (EDT)
Received: from standards (47.234.32.16:1275) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB82C6D@standards.nortelnetworks.com>; Fri, 28 Jul 2000 12:04:22 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2426 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jul 2000 12:04:22
          -0400
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFB82C6C@standards.nortelnetworks.com>; Fri, 28 Jul 2000 12:04:22
          -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 JAA27272;
          Fri, 28 Jul 2000 09:15:24 -0700 (PDT)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.9.3/8.9.3-VIRSCAN) id JAA11437; Fri, 28 Jul 2000 09:15:23 -0700
X-Virus-Scanned:  Fri, 28 Jul 2000 09:15:23 -0700 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from charliep.iprg.nokia.com (205.226.2.89,
          claiming to be "iprg.nokia.com") by
          darkstar.iprg.nokia.com(WTS.12.69) smtpdWFXpCA; Fri, 28 Jul 2000
          09:15:19 PDT
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
References: <200007281547.IAA27917@nasnfs.eng.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3981B197.7FED9A7E@iprg.nokia.com>
Date:         Fri, 28 Jul 2000 09:15:19 -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] handoff breakout session
X-To:         James.Kempf@Eng.Sun.COM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello Jim,

I agree to the extent that smooth handover for IPv4 and for IPv6
would be specified in separate drafts.

However, the basic philosophy and control flows might be very,
very similar.

Furthermore, I suggest that regional registration is sufficiently
different than smooth handover, that we should take care to make
these topics distinct.  Obviously, there are relationships between
the two mechanisms, but they can both stand alone.

I want to suggest that smooth handover involves transferring state
between two access routers/foreign agents.  Regional registration,
on the other hand, involves constraining the flow of information
about the mobile node's care-of address.  This process of localization
_typically_ (not _necessarily_) involves mobility agents that might
be distant from the leaf access routers/foreign agents.

Regards,
Charlie P.



James Kempf wrote:
>
> I agree that the MIPv6 should be handled separately.
>
>                 jak
> >Phil,
> >
> >         Given that time is limited, why don't we have a working dinner (
> >Everyone gets their own dinner - Just clarification :).  Just to make sure we
> >read all the drafts, here is a starting list (please add to the list -
> >Hopefully by the
> >end of this email thread we will have the entire list).
> >
> >          E. Gustafsson, et. al.  Mobile IP Regional Tunnel Management.
> >       draft-ietf-mobileip-reg-tunnel-01.txt, August 1999.
> >
> >        J. Kempf, P. Calhoun, and C. Pairla, Foreign Agent Assisted Hand-off,
> >         draft-calhoun-mobileip-proactive-fa-01.txt, June 2002
> >
> >         G. Dommety  and T.  Ye, "Local  and Indirect  Registration for
> >         Anchoring Handoffs",
> >         draft-dommety-mobileip-anchor-handoff-01.txt(work  in
> >         progress), July 2000.
> >
> >          K. El Malki, et. al.  Fast Handoff Method for Real-Time Traffic
> >       over Scaleable Mobile IP Networks.
> >       draft-elmalki-mobileip-fast-handoffs-01.txt, June 1999.
> >
> >There are also IPv6 drafts, I think it is a better to have another breakout
> >for that (There are some
> >issues that are common and some different -just to keep the group
> >focused).  what do you think?
> >
> >
> >At 09:19 AM 7/28/00 -0500, Roberts Phil-QA3445 wrote:
> >>Hi folks,
> >>
> >>         we've got a room for Monday night from 7:30 to 10.  It's South Room
> >>5.  Whoever would like to go for dinner can meet at the registration desk.
> >>I'll be there.  Did we agree to a time?  Then we can get together in this
> >>conference room afterwards.  We're going to restrict this to authors of
> >>drafts only for the first session.  I'll post some talking points later.
> >>Then during the first mobileip session hopefully we'll be able to summarize
> >>what went on and present the group with a reduced number of proposals and
> >>some requests for feedback on what's been done.
> >>
> >>Thanks,
> >>Phil


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Jul 28 12:41:07 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06492
	for ; Fri, 28 Jul 2000 12:41:06 -0400 (EDT)
Received: from standards (47.234.32.16:1275) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB82D39@standards.nortelnetworks.com>; Fri, 28 Jul 2000 12:29:11 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2714 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jul 2000 12:29:11
          -0400
Received: from motgate2.mot.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB82D38@standards.nortelnetworks.com>; Fri, 28 Jul 2000 12:29:11
          -0400
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by
          motgate2.mot.com (motgate2 2.1) with ESMTP id JAA14067 for
          ; Fri, 28 Jul 2000 09:40:13
          -0700 (MST)]
Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100])
          by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id JAA04997 for
          ; Fri, 28 Jul 2000 09:40:13
          -0700 (MST)]
Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2650.21) id
          ; Fri, 28 Jul 2000 11:40:12 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  
Date:         Fri, 28 Jul 2000 11:40:12 -0500
Reply-To: Roberts Phil-QA3445 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: Roberts Phil-QA3445 
Subject:      Re: [MOBILE-IP] handoff breakout session
X-To:         "James.Kempf@ENG.SUN.COM" 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Although they are separate I think there will be a lot of similarity about
much of the discussion.  Also, setting up two separate sessions may not be
practical.  So we'll meet on the two topics together, but when we go over v4
and v6 we can group things related to those two together.



> -----Original Message-----
> From: James Kempf [mailto:James.Kempf@ENG.SUN.COM]
> Sent: Friday, July 28, 2000 9:48 AM
> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: [MOBILE-IP] handoff breakout session
>
>
> I agree that the MIPv6 should be handled separately.
>
>                 jak
> >Phil,
> >
> >         Given that time is limited, why don't we have a
> working dinner (
> >Everyone gets their own dinner - Just clarification :).
> Just to make sure we
> >read all the drafts, here is a starting list (please add to
> the list -
> >Hopefully by the
> >end of this email thread we will have the entire list).
> >
> >          E. Gustafsson, et. al.  Mobile IP Regional Tunnel
> Management.
> >       draft-ietf-mobileip-reg-tunnel-01.txt, August 1999.
> >
> >        J. Kempf, P. Calhoun, and C. Pairla, Foreign Agent
> Assisted Hand-off,
> >         draft-calhoun-mobileip-proactive-fa-01.txt, June 2002
> >
> >         G. Dommety  and T.  Ye, "Local  and Indirect
> Registration for
> >         Anchoring Handoffs",
> >         draft-dommety-mobileip-anchor-handoff-01.txt(work  in
> >         progress), July 2000.
> >
> >          K. El Malki, et. al.  Fast Handoff Method for
> Real-Time Traffic
> >       over Scaleable Mobile IP Networks.
> >       draft-elmalki-mobileip-fast-handoffs-01.txt, June 1999.
> >
> >There are also IPv6 drafts, I think it is a better to have
> another breakout
> >for that (There are some
> >issues that are common and some different -just to keep the group
> >focused).  what do you think?
> >
> >
> >At 09:19 AM 7/28/00 -0500, Roberts Phil-QA3445 wrote:
> >>Hi folks,
> >>
> >>         we've got a room for Monday night from 7:30 to 10.
>  It's South Room
> >>5.  Whoever would like to go for dinner can meet at the
> registration desk.
> >>I'll be there.  Did we agree to a time?  Then we can get
> together in this
> >>conference room afterwards.  We're going to restrict this
> to authors of
> >>drafts only for the first session.  I'll post some talking
> points later.
> >>Then during the first mobileip session hopefully we'll be
> able to summarize
> >>what went on and present the group with a reduced number of
> proposals and
> >>some requests for feedback on what's been done.
> >>
> >>Thanks,
> >>Phil
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Jul 28 12:49:22 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08328
	for ; Fri, 28 Jul 2000 12:49:22 -0400 (EDT)
Received: from standards (47.234.32.16:1275) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB82D6D@standards.nortelnetworks.com>; Fri, 28 Jul 2000 12:37:46 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2787 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jul 2000 12:37:46
          -0400
Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB82D6C@standards.nortelnetworks.com>; Fri, 28 Jul 2000
          12:37:45 -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 MAA26540
          for ; Fri, 28 Jul 2000
          12:48:48 -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 MAA26521 for ;
          Fri, 28 Jul 2000 12:48:47 -0400 (EDT)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service
          (5.5.2650.21) id ; Fri, 28 Jul 2000 17:48:45 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Message-ID:  <976F7C55E3B2D111A0720008C728549C04876FB6@en0060exch001u.uk.lucent.com>
Date:         Fri, 28 Jul 2000 17:48:44 +0100
Reply-To: "Casati, Alessio (Alessio)" 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: "Casati, Alessio (Alessio)" 
Subject:      [MOBILE-IP] HO: scoping the problem out
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

I think scoping the domain of application out is a necessary precondition
to the evening event to be successful.

i.e.

-what is the system it is to be used for? All?

-Is it for intradomain or interdomain?

-Lossless?

-Low latency? for voice?

-What about compression state transfer?

-Network driven/mobile driven/both?

-what is the informaion used to drive the HO decision? All L3? at L2?

...

Probably, it will be necessary to scope these aspect out before
diving into the protocol merging/picking pool?

In fact, as Charlie perfectly pointed out, reg reg is
not related to the discussion. Yet, somebody is confused
about it. This is a symptom the discussion may be very difficult
if a clear definition of the problem/goals is not provided


alessio


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Jul 28 13:05:06 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11853
	for ; Fri, 28 Jul 2000 13:05:06 -0400 (EDT)
Received: from standards (47.234.32.16:1275) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB82DA3@standards.nortelnetworks.com>; Fri, 28 Jul 2000 12:53:32 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2855 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jul 2000 12:53:32
          -0400
Received: from gandalf.axion.bt.co.uk by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFB82D9C@standards.nortelnetworks.com>; Fri, 28 Jul 2000 12:43:32
          -0400
Received: from cbtlipnt02.btlabs.bt.co.uk by gandalf (local) with ESMTP; Fri,
          28 Jul 2000 17:54:20 +0100
Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service
          (5.5.2651.88) id ; Fri, 28 Jul 2000 17:54:18 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.88)
Content-Type: text/plain
Message-ID:  <5104D4DBC598D211B5FE0000F8FE7EB2078A5A38@mbtlipnt02.btlabs.bt.co.uk>
Date:         Fri, 28 Jul 2000 17:51:56 +0100
Reply-To: george.tsirtsis@BT.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: George Tsirtsis 
Subject:      Re: [MOBILE-IP] handoff breakout session
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> -----Original Message-----
> From: Charles E. Perkins [SMTP:charliep@IPRG.NOKIA.COM]
> Sent: Friday, July 28, 2000 5:15 PM
> To:   MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: [MOBILE-IP] handoff breakout session
>
> Hello Jim,
>
> I agree to the extent that smooth handover for IPv4 and for IPv6
> would be specified in separate drafts.
>
> However, the basic philosophy and control flows might be very,
> very similar.
>
        I agree to that. The discussion should be both v4 and v6. It would
be a mistake to work on IPv4 and IPv6 independently. The models should, if
possible be the same, the implementations however might be different, and
hopefully better in IPv6 :-)


> Furthermore, I suggest that regional registration is sufficiently
> different than smooth handover, that we should take care to make
> these topics distinct.  Obviously, there are relationships between
> the two mechanisms, but they can both stand alone.
>
        I also think this is a good separation. In EMA for example we
support a number of handover models for both v4 and v6 (including smooth
handover) independently of regional registration.

> I want to suggest that smooth handover involves transferring state
> between two access routers/foreign agents.
>
        Yes!

        Regards
        George

> Regional registration,
> on the other hand, involves constraining the flow of information
> about the mobile node's care-of address.  This process of localization
> _typically_ (not _necessarily_) involves mobility agents that might
> be distant from the leaf access routers/foreign agents.
>
>
> Regards,
> Charlie P.
>
>
>
> James Kempf wrote:
> >
> > I agree that the MIPv6 should be handled separately.
> >
> >                 jak
> > >Phil,
> > >
> > >         Given that time is limited, why don't we have a working dinner
> (
> > >Everyone gets their own dinner - Just clarification :).  Just to make
> sure we
> > >read all the drafts, here is a starting list (please add to the list -
> > >Hopefully by the
> > >end of this email thread we will have the entire list).
> > >
> > >          E. Gustafsson, et. al.  Mobile IP Regional Tunnel Management.
> > >       draft-ietf-mobileip-reg-tunnel-01.txt, August 1999.
> > >
> > >        J. Kempf, P. Calhoun, and C. Pairla, Foreign Agent Assisted
> Hand-off,
> > >         draft-calhoun-mobileip-proactive-fa-01.txt, June 2002
> > >
> > >         G. Dommety  and T.  Ye, "Local  and Indirect  Registration for
> > >         Anchoring Handoffs",
> > >         draft-dommety-mobileip-anchor-handoff-01.txt(work  in
> > >         progress), July 2000.
> > >
> > >          K. El Malki, et. al.  Fast Handoff Method for Real-Time
> Traffic
> > >       over Scaleable Mobile IP Networks.
> > >       draft-elmalki-mobileip-fast-handoffs-01.txt, June 1999.
> > >
> > >There are also IPv6 drafts, I think it is a better to have another
> breakout
> > >for that (There are some
> > >issues that are common and some different -just to keep the group
> > >focused).  what do you think?
> > >
> > >
> > >At 09:19 AM 7/28/00 -0500, Roberts Phil-QA3445 wrote:
> > >>Hi folks,
> > >>
> > >>         we've got a room for Monday night from 7:30 to 10.  It's
> South Room
> > >>5.  Whoever would like to go for dinner can meet at the registration
> desk.
> > >>I'll be there.  Did we agree to a time?  Then we can get together in
> this
> > >>conference room afterwards.  We're going to restrict this to authors
> of
> > >>drafts only for the first session.  I'll post some talking points
> later.
> > >>Then during the first mobileip session hopefully we'll be able to
> summarize
> > >>what went on and present the group with a reduced number of proposals
> and
> > >>some requests for feedback on what's been done.
> > >>
> > >>Thanks,
> > >>Phil


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Jul 28 15:27:30 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21702
	for ; Fri, 28 Jul 2000 15:27:29 -0400 (EDT)
Received: from standards (47.234.32.16:2779) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB82E40@standards.nortelnetworks.com>; Fri, 28 Jul 2000 15:15:45 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3059 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jul 2000 15:15:45
          -0400
Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1b) with SMTP id <0.FFB82E3F@standards.nortelnetworks.com>;
          Fri, 28 Jul 2000 15:15:44 -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 NAA00815; Fri, 28 Jul 2000 13:26:45
          -0600 (MDT)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by
          engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id
          MAA29385; Fri, 28 Jul 2000 12:26:40 -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 MAA02512; Fri, 28
          Jul 2000 12:26: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:  <200007281926.MAA02512@nasnfs.eng.sun.com>
Date:         Fri, 28 Jul 2000 11:26:53 -0700
Reply-To: James.Kempf@eng.sun.com
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: James Kempf 
Subject:      Re: [MOBILE-IP] handoff breakout session
X-To:         "Charles E. Perkins" 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi Charlie,

I agree with your classification and that there are some similarities. My reasons
for keeping the discussions separate are that, as far as I can determine, there
is only one draft on IPv6 smooth handover (as distinct from regional registration,
where there are two), and that the presence of the FA makes IPv4 handover
enough different that I think it would benefit from separating it out.

I agree that regional registration is a separate topic, and should therefore
be discussed separately. There are some links into smooth handover.

                jak
>
>Hello Jim,
>
>I agree to the extent that smooth handover for IPv4 and for IPv6
>would be specified in separate drafts.
>
>However, the basic philosophy and control flows might be very,
>very similar.
>
>Furthermore, I suggest that regional registration is sufficiently
>different than smooth handover, that we should take care to make
>these topics distinct.  Obviously, there are relationships between
>the two mechanisms, but they can both stand alone.
>
>I want to suggest that smooth handover involves transferring state
>between two access routers/foreign agents.  Regional registration,
>on the other hand, involves constraining the flow of information
>about the mobile node's care-of address.  This process of localization
>_typically_ (not _necessarily_) involves mobility agents that might
>be distant from the leaf access routers/foreign agents.
>
>Regards,
>Charlie P.
>
>
>
>James Kempf wrote:
>>
>> I agree that the MIPv6 should be handled separately.
>>
>>                 jak
>> >Phil,
>> >
>> >         Given that time is limited, why don't we have a working dinner (
>> >Everyone gets their own dinner - Just clarification :).  Just to make sure
>we
>> >read all the drafts, here is a starting list (please add to the list -
>> >Hopefully by the
>> >end of this email thread we will have the entire list).
>> >
>> >          E. Gustafsson, et. al.  Mobile IP Regional Tunnel Management.
>> >       draft-ietf-mobileip-reg-tunnel-01.txt, August 1999.
>> >
>> >        J. Kempf, P. Calhoun, and C. Pairla, Foreign Agent Assisted
>Hand-off,
>> >         draft-calhoun-mobileip-proactive-fa-01.txt, June 2002
>> >
>> >         G. Dommety  and T.  Ye, "Local  and Indirect  Registration for
>> >         Anchoring Handoffs",
>> >         draft-dommety-mobileip-anchor-handoff-01.txt(work  in
>> >         progress), July 2000.
>> >
>> >          K. El Malki, et. al.  Fast Handoff Method for Real-Time Traffic
>> >       over Scaleable Mobile IP Networks.
>> >       draft-elmalki-mobileip-fast-handoffs-01.txt, June 1999.
>> >
>> >There are also IPv6 drafts, I think it is a better to have another breakout
>> >for that (There are some
>> >issues that are common and some different -just to keep the group
>> >focused).  what do you think?
>> >
>> >
>> >At 09:19 AM 7/28/00 -0500, Roberts Phil-QA3445 wrote:
>> >>Hi folks,
>> >>
>> >>         we've got a room for Monday night from 7:30 to 10.  It's South
>Room
>> >>5.  Whoever would like to go for dinner can meet at the registration desk.
>> >>I'll be there.  Did we agree to a time?  Then we can get together in this
>> >>conference room afterwards.  We're going to restrict this to authors of
>> >>drafts only for the first session.  I'll post some talking points later.
>> >>Then during the first mobileip session hopefully we'll be able to summarize
>> >>what went on and present the group with a reduced number of proposals and
>> >>some requests for feedback on what's been done.
>> >>
>> >>Thanks,
>> >>Phil


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Jul 28 16:45: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 QAA12082
	for ; Fri, 28 Jul 2000 16:45:24 -0400 (EDT)
Received: from standards (47.234.32.16:1592) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB82EA4@standards.nortelnetworks.com>; Fri, 28 Jul 2000 16:33:52 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3186 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jul 2000 16:33:52
          -0400
Received: from sirius.ctr.columbia.edu by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFB82EA3@standards.nortelnetworks.com>; Fri, 28 Jul 2000 16:33:51
          -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 QAA19883;
          Fri, 28 Jul 2000 16:44:49 -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:  <39821EAE.AF807E8E@comet.columbia.edu>
Date:         Fri, 28 Jul 2000 17:00:46 -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] handoff premeeting
X-To:         Roberts Phil-QA3445 
X-cc:         cellularip@comet.columbia.edu
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Phil:

For completeness I recommend that you
add the other micromobility (sorry CP ;-) working
group drafts found at
http://www.ietf.org/html.charters/mobileip-charter.html
to your list, e.g., CIP, Hawaii, etc.

I would be happy to present the CIP work as input to
the discussion.

Andrew

Roberts Phil-QA3445 wrote:
>
> Hi folks,
>
>         here are the talking points we'd like to use at the pre-meeting.  We
> see this working as follows.  Those who want to meet for dinner do so, then
> we'll retire to the South Room 5 after dinner, have some presentations on
> the drafts, and use these slides to try to reach some agreements.
>
> Phil
>
>  <>
>
>   ------------------------------------------------------------------------
>                   Name: handoff.pdf
>    handoff.pdf    Type: Acrobat (application/pdf)
>               Encoding: base64


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Jul 28 17:19:35 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20865
	for ; Fri, 28 Jul 2000 17:19:34 -0400 (EDT)
Received: from standards (47.234.32.16:1592) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB82EE7@standards.nortelnetworks.com>; Fri, 28 Jul 2000 17:08:04 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3276 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jul 2000 17:08:04
          -0400
Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB82EE6@standards.nortelnetworks.com>; Fri, 28 Jul 2000
          17:08:03 -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 RAA05895
          for ; Fri, 28 Jul 2000
          17:19:06 -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 RAA05891 for ;
          Fri, 28 Jul 2000 17:19:06 -0400 (EDT)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service
          (5.5.2650.21) id ; Fri, 28 Jul 2000 22:19:05 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Message-ID:  <976F7C55E3B2D111A0720008C728549C04876FBC@en0060exch001u.uk.lucent.com>
Date:         Fri, 28 Jul 2000 22:19:04 +0100
Reply-To: "Casati, Alessio (Alessio)" 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: "Casati, Alessio (Alessio)" 
Subject:      Re: [MOBILE-IP] handoff premeeting
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

here is another example of the confusion...

> ----------
> From:         Andrew T. Campbell[SMTP:campbell@comet.columbia.edu]
> Reply To:     campbell@comet.columbia.edu
> Sent:         29 July 2000 01:00
> To:   MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: [MOBILE-IP] handoff premeeting
>
> Phil:
>
> For completeness I recommend that you
> add the other micromobility (sorry CP ;-) working
> group drafts found at
> http://www.ietf.org/html.charters/mobileip-charter.html
> to your list, e.g., CIP, Hawaii, etc.
>
> I would be happy to present the CIP work as input to
> the discussion.
>
> Andrew
>
> Roberts Phil-QA3445 wrote:
> >
> > Hi folks,
> >
> >         here are the talking points we'd like to use at the pre-meeting.
> We
> > see this working as follows.  Those who want to meet for dinner do so,
> then
> > we'll retire to the South Room 5 after dinner, have some presentations
> on
> > the drafts, and use these slides to try to reach some agreements.
> >
> > Phil
> >
> >  <>
> >
> >
> ------------------------------------------------------------------------
> >                   Name: handoff.pdf
> >    handoff.pdf    Type: Acrobat (application/pdf)
> >               Encoding: base64
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Jul 28 17:47:13 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28260
	for ; Fri, 28 Jul 2000 17:47:13 -0400 (EDT)
Received: from standards (47.234.32.16:1592) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB82F36@standards.nortelnetworks.com>; Fri, 28 Jul 2000 17:35:42 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3384 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jul 2000 17:35:42
          -0400
Received: from omega.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB82F35@standards.nortelnetworks.com>; Fri, 28 Jul 2000 17:35:42
          -0400
Received: from gdommety-laptop1.cisco.com (dhcp-171-70-57-49.cisco.com
          [171.70.57.49]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8)
          with ESMTP id OAA04478; Fri, 28 Jul 2000 14:46:41 -0700 (PDT)
X-Sender: gdommety@omega.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.20000728111353.00b7cd50@omega.cisco.com>
Date:         Fri, 28 Jul 2000 12:30:40 -0700
Reply-To: Gopal Dommety 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: Gopal Dommety 
Subject:      Re: [MOBILE-IP] handoff breakout session
X-To:         george.tsirtsis@BT.COM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <5104D4DBC598D211B5FE0000F8FE7EB2078A5A38@mbtlipnt02.btlabs
              .bt.co.uk>

At 05:51 PM 7/28/00 +0100, George Tsirtsis wrote:
> > -----Original Message-----
> > From: Charles E. Perkins [SMTP:charliep@IPRG.NOKIA.COM]
> > Sent: Friday, July 28, 2000 5:15 PM
> > To:   MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> > Subject:      Re: [MOBILE-IP] handoff breakout session
> >
> > Hello Jim,
> >
> > I agree to the extent that smooth handover for IPv4 and for IPv6
> > would be specified in separate drafts.
> >
> > However, the basic philosophy and control flows might be very,
> > very similar.
> >
>         I agree to that. The discussion should be both v4 and v6. It would
>be a mistake to work on IPv4 and IPv6 independently. The models should, if
>possible be the same, the implementations however might be different, and
>hopefully better in IPv6 :-)
>

Clarification:

There are two issues when we discuss IPv6 Fast Handoffs.

1. Introduction of Local Mobility Agents in IPv6 (I am not suggesting any
scheme).
2. using the general framework see how fast handoffs are acheived (this is
the generic stuff
and not dependent on v4 or v6).

We should discuss issue 2 and not sure of 1 in the handoff discussions.

Thanks
Gopal



> > Furthermore, I suggest that regional registration is sufficiently
> > different than smooth handover, that we should take care to make
> > these topics distinct.  Obviously, there are relationships between
> > the two mechanisms, but they can both stand alone.
> >
>         I also think this is a good separation. In EMA for example we
>support a number of handover models for both v4 and v6 (including smooth
>handover) independently of regional registration.
>
> > I want to suggest that smooth handover involves transferring state
> > between two access routers/foreign agents.
> >
>         Yes!
>
>         Regards
>         George
>
> > Regional registration,
> > on the other hand, involves constraining the flow of information
> > about the mobile node's care-of address.  This process of localization
> > _typically_ (not _necessarily_) involves mobility agents that might
> > be distant from the leaf access routers/foreign agents.
> >
> >
> > Regards,
> > Charlie P.
> >
> >
> >
> > James Kempf wrote:
> > >
> > > I agree that the MIPv6 should be handled separately.
> > >
> > >                 jak
> > > >Phil,
> > > >
> > > >         Given that time is limited, why don't we have a working dinner
> > (
> > > >Everyone gets their own dinner - Just clarification :).  Just to make
> > sure we
> > > >read all the drafts, here is a starting list (please add to the list -
> > > >Hopefully by the
> > > >end of this email thread we will have the entire list).
> > > >
> > > >          E. Gustafsson, et. al.  Mobile IP Regional Tunnel Management.
> > > >       draft-ietf-mobileip-reg-tunnel-01.txt, August 1999.
> > > >
> > > >        J. Kempf, P. Calhoun, and C. Pairla, Foreign Agent Assisted
> > Hand-off,
> > > >         draft-calhoun-mobileip-proactive-fa-01.txt, June 2002
> > > >
> > > >         G. Dommety  and T.  Ye, "Local  and Indirect  Registration for
> > > >         Anchoring Handoffs",
> > > >         draft-dommety-mobileip-anchor-handoff-01.txt(work  in
> > > >         progress), July 2000.
> > > >
> > > >          K. El Malki, et. al.  Fast Handoff Method for Real-Time
> > Traffic
> > > >       over Scaleable Mobile IP Networks.
> > > >       draft-elmalki-mobileip-fast-handoffs-01.txt, June 1999.
> > > >
> > > >There are also IPv6 drafts, I think it is a better to have another
> > breakout
> > > >for that (There are some
> > > >issues that are common and some different -just to keep the group
> > > >focused).  what do you think?
> > > >
> > > >
> > > >At 09:19 AM 7/28/00 -0500, Roberts Phil-QA3445 wrote:
> > > >>Hi folks,
> > > >>
> > > >>         we've got a room for Monday night from 7:30 to 10.  It's
> > South Room
> > > >>5.  Whoever would like to go for dinner can meet at the registration
> > desk.
> > > >>I'll be there.  Did we agree to a time?  Then we can get together in
> > this
> > > >>conference room afterwards.  We're going to restrict this to authors
> > of
> > > >>drafts only for the first session.  I'll post some talking points
> > later.
> > > >>Then during the first mobileip session hopefully we'll be able to
> > summarize
> > > >>what went on and present the group with a reduced number of proposals
> > and
> > > >>some requests for feedback on what's been done.
> > > >>
> > > >>Thanks,
> > > >>Phil


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Jul 28 18:49:03 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11586
	for ; Fri, 28 Jul 2000 18:49:03 -0400 (EDT)
Received: from standards (47.234.32.16:2861) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB82FBB@standards.nortelnetworks.com>; Fri, 28 Jul 2000 18:37:33 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3529 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jul 2000 18:37:33
          -0400
Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB82FA8@standards.nortelnetworks.com>; Fri, 28 Jul 2000 18:27:33
          -0400
Received: from exchange1.netcomsystems.com (mushroom.netcomsystems.com
          [12.9.24.195]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id
          RAA27996 for ; Fri, 28 Jul 2000 17:38:35
          -0500 (CDT)
Received: by exchange1.netcomsystems.com with Internet Mail Service
          (5.5.2650.21) id ; Fri, 28 Jul 2000 15:38:04 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFF8E4.7BB17E88"
Message-ID:  <9384475DFC05D2118F9C00805F6F2631018DBF79@exchange1.netcomsystems.com>
Date:         Fri, 28 Jul 2000 15:37:54 -0700
Reply-To: "Perches, Joe" 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: "Perches, Joe" 
Subject:      [MOBILE-IP] subscribe
X-To:         "mobile-ip@smallworks.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_01BFF8E4.7BB17E88
Content-Type: text/plain;
        charset="iso-8859-1"

subscribe mobile-ip Joe_Perches@NetcomSystems.com

------_=_NextPart_001_01BFF8E4.7BB17E88
Content-Type: text/html;
        charset="iso-8859-1"






subscribe




subscribe mobile-ip Joe_Perches@NetcomSystems.com





------_=_NextPart_001_01BFF8E4.7BB17E88--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Jul 28 22:17:30 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28408
	for ; Fri, 28 Jul 2000 22:17:30 -0400 (EDT)
Received: from standards (47.234.32.16:1862) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB830AD@standards.nortelnetworks.com>; Fri, 28 Jul 2000 22:05:57 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3869 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jul 2000 22:05:57
          -0400
Received: from mail0.u-aizu.ac.jp by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB830AC@standards.nortelnetworks.com>; Fri, 28 Jul 2000 22:05:56
          -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
          LAA05431; Sat, 29 Jul 2000 11:16:58 +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 LAA19380; Sat, 29 Jul
          2000 11:16:57 +0900 (JST)
X-Mailer: Mozilla 4.7 [en_jp] (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:  <39823E99.381E1186@u-aizu.ac.jp>
Date:         Sat, 29 Jul 2000 11:16:57 +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] handoff breakout session
X-To:         Roberts Phil-QA3445 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi Phil,
  Here is my 0.002 cents on this:
In this handoff breakout session why not decide to appoint
an editorial board consisting of one or a max of 2 experts that will be
in charge of coming up with a joint text by San Diego meeting.
  As Charlie pointed out there needs to be separation of concerns,
like smooth handover and regional registrations and mipv4 and mipv6.
This
probably call for 4 editors to be agreed upon.
  I nominate Charlie for all (hope he agrees).

Regards,

--behcet


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Jul 28 23:53:59 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 XAA15646
	for ; Fri, 28 Jul 2000 23:53:58 -0400 (EDT)
Received: from standards (47.234.32.16:4426) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83112@standards.nortelnetworks.com>; Fri, 28 Jul 2000 23:42:09 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3986 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jul 2000 23:42:09
          -0400
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFB83105@standards.nortelnetworks.com>; Fri, 28 Jul 2000 23:32: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 UAA28683
          for ; Fri, 28 Jul 2000
          20:43:12 -0700 (PDT)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.9.3/8.9.3-VIRSCAN) id UAA09984 for
          ; Fri, 28 Jul 2000 20:43:09
          -0700
X-Virus-Scanned:  Fri, 28 Jul 2000 20:43:09 -0700 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from jmalinen.iprg.nokia.com (205.226.2.98,
          claiming to be "iprg.nokia.com") by
          darkstar.iprg.nokia.com(WTS.12.69) smtpdIf3OBB; Fri, 28 Jul 2000
          20:43:07 PDT
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
References: <4B6BC00CD15FD2119E5F0008C7A419A5089EB13D@eaubrnt018.epa.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <398252CD.AF7AAB63@iprg.nokia.com>
Date:         Fri, 28 Jul 2000 20:43:09 -0700
Reply-To: jmalinen@IPRG.NOKIA.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: "Jari T. Malinen" 
Organization: Nokia
Subject:      Re: [MOBILE-IP] draft-malinen-mobileip-regreg6-00.txt
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi, Hesham,

Since the discussion of these issues with many proposals was encouraged,
and despite the recent message flood, let me briefly comment on your remarks below,

- Our MN _knows_ its regional addresses, but what it really does not know
  is who answers to the RBU. And it needs not to know. We unlike you are using
  network controlled crossover selection. And, if the MN prefers, it can
  even add an alternate CoA sub-option for the RBU for diverting data out
  of the strict tree if this is really wanted. But, we might want a network
  policy to forbid this. These usages apply basic Mobile IPv6 on our design.
  But we prefer in our design the network-controlled case.

  The advantage comes when you can hide your network topology from MN and keep
  advertisements small even with large hierarchies.

- On alleged breaking of the 2460 semantics: We indirectly use contents of
  the packet (the home address in the routing header) for changing the packet's
  "lower" IP destination. If you consider the home address as the actual
  destination, we do not change that. This is close to actual source routing.
  The RBC entries should (with proper AAA-driven security brought in) even
  be authorized by the HA, what is so bad here?

  An advantage to your design comes from the saving of bandwidth on most
  packets (route optimized regional forwarding vs. mostly tunneled regional data
  forwarding) and in state saving. And, we control forwarding semantics a bit more
  (below)

- On the Site-local address forwarding, if the site-local address comes
  from some parameterized info on the route advertisements, these will go to
  the visited domain tunneled from the HA, thus the GMA could learn the same
  information from there. Since we control the forwarding semantics in our
  model, our GMA could e.g. monitor broadcast packets to get the available L3
  info for each home agent on their home links. If GMA can do the mapping
  the regional forwarding takes place, and the packet is not dropped.
  I am not sure if it even is so useful for HA to defend all these addresses
  not explicitly registered by MN (such as site local) unless their mapping
  to homeaddr is simple. We do not address the problem the same way as you do,
  but is that needed?

  The advantage comes from not altering the HA for any regional purposes.

- That we keep transport and security apart does not mean no security. For
  data, all works as before, for signalling, the only thing different is
  the authorizations for the visited domain. We need to distribute session keys
  anyway. The visited domain and the MN will then have a dynamic security association
  so even the crossover is not known to the MN they do end up having a security
  association for authentication. That we do not access this using the
  the IP source but using the home address, is something that should not
  be surprising when discussing mobile routing. We have "lower" routing (CoAs)
  vs. endpoint addresses (Haddr, CN, seen in the sockets) which make the mobile
  case a bit different from the fixed case for the "end-to-end" entities.

But, more on these in Pittsburgh,

Best Regards,

-Jari


> Hi Jari,
>
> Sorry for the late reply, email problems !
> Here are some more comments.
> I'm sure we will continue this in Pittsburgh.
>
> Regards,
> Hesham
>
> => The comment was on the transparency of the BUs to the MN.
> I think it's better that the MN knows its regional address(es).
> This would comply with the MIPv6 design and will save a lot of
> complications with security which are not solved in your proposal
> as you mentioned in ch 7.
>
>
>
> About autoconfiguration of GCoA,
> if we compare HMIPv6 and ours, both use a link-address to for
> local communication. HMIPv6 calls this PCoA. This takes one
> autoconfiguration.
>

=>You have to change something in the HA. Otherwise Site-local packets
addressed to the MN will be dropped by the regional routers or delivered
to the wrong MN. You don't address this issue in your draft and that's
why I think it is not complete.

See above.

> I might be wrong but I don't think you've addressed this problem in your
> draft. Therefore according to your proposal, other home addresses that
> the regional router is not aware of, will not be received by the MN as
they
> will be dropped by the regional router.

Let me explain. In our design, other home addresses will not be dropped when
no
regional entry exists. Note that in such a case, the GMA behaves like a
normal
router. If the packet is targeted to the on-link CoA of the MN, this leads
to
basic Mobile IPv6 behavior where gateway router is just like any other
intermediate
router between HA and MN. If the HA tries to send to a regional CoA, the
entry is still in the GMA. It is the responsibility of the MN to make
sure that a regional binding cache entry in the GMA has a large enough
lifetime. And it is also the responsibility of the MN to register with
the GMA before traffic starts to arrive from remote nodes where MN registers
with a regional CoA.

=>Please refer to my comment above.


 Furthermore, MN uses either regional or non-regional
CoA but not both simultaneously when sending binding updates out of the
visited
domain.

=> Why ? how can that be controlled. I think the MN should be able to use
any of its COAs (on link and regional). I don't see a need to limit that.
Furthermore, it can't really be policed even if you want to restrict it.

Here was a mistake, we do not need to limit them either.

> > After MN sent a BU with
> >     alternate CoA to CN, this can start sending route-optimized packets
to MN
> >     via GMA. Inner packet AH is not touched in intermediate routers.
> >     Packets are forwarded locally in the visited domain and not from HA.
> >     We can thus do without using an additional routing header with
tunneling.
>
> => I don't really understand how that affects our decision of adding a
> routing header. AH is not affected in our proposal either, end to end
security is
> maintained. What you mention above is not related to adding a routing
header from the
> HA. The routing header from the CN is mandatory according to MIPv6.

Again, I explain our design here. I only refer to MAP in how you describe
HA operation in your section 13. You use a routing entry to find home
address.

Our forwarding only uses the binding cache, after which the destination
address is that of a lower CoA which is in its topologically correct place,
i.e. no mobility-specific additional routing entries are needed. Why have
extra routing state for home addresses when we have the binding cache entry,
in both designs, anyway?

=>We don't add the Routing header in the HA all the time, only for addresses
that were
not registered. eg. a Site-local home address.

Comment collected above.

> > - In our design, most of the data packets are neither tunneled nor
> >    host-routed (note also that signaling is not tunneled).
> >    Route-optimized packets towards the MN are forwarded in a special
> >    way based only on the regional binding cache.
>
> => If I understand that special way you refer to correctly, it is done by
> changing the destination address in the packet. I think it is dangerous
> to allow intermediate nodes to modify packets. I think tunnelling
> is a better way to go here.

If you look at RFC2460, the pseudo-code on page 16 explains how source
routing (consumption of routing headers in intermediate routers) changes
the destination IP address in the process (swap the IPv6 Destination Address
and Address[i]). In fact, this is a precedence for changing IPhdr
destination
address in intermediate routers. We don't break this, we simply don't use it
for a very special kind of a routing header, that sent by users of basic
Mobile IPv6 route optimization and this only in regional-aware routers.



We use a different kind of forwarding (a regional binding cache based next
hop routing) which does not do anything more to the packet that source
routing would, it does less . When we can skip routing header processing
this
even speeds up the IP forwarding. And we avoid the tunnelling overhead for
route-optimized packets which form the vast majority of data packets.

=>There is a fundamental difference. RFC 2460 states that you can
use the contents of the packet to change the packet. That is not
the same as simply changing the packet.

See above.

> > Normal processing of
> >    source-routed packets is skipped if there is a regional binding cache
> >    entry for the route-optimized home address in the regional CoA router
> >    receiving the packet. Only IPhdr destination is changed, AH prevails.
> >    The packet is then just forwarded to the lower CoA as seen in the
> >    regional binding cache.  Thus, no extra routing state is needed.
> >    This is much simpler than in Karim's proposal and is quite different
> >    from IPv4-solutions. Universal route optimization as provided in
basic
> >    even possible in IPv4 due to its legacy CNs.
>
> => I don't understand why you chose not to process the routing header.
> This breaks RFC 2460 (IPv6 spec) for no reason.

First, a normal routing header processing would assume local knowledge
of home address routing. This would need the extra routing entry for the
home address when you process the routing header normally.

In our design, for the routing headers (from CNs or HAs) or even
for recapsulation, all we do is a regional binding cache lookup based
on home address which is used for all regional forwarding.

=> Ok how do you look up an entry in the Binding Cache ? I guess the key
is the Home address. Where do you get it from in the packet received from
the CN ?

The routing header of route-optimized packets from CN contains the home
address.

I do not consider our design choice a breach,
it is something new as was the introduction of binding cache -based
forwarding to HA in the basic Mobile IPv6. That "breaks" 2460 in that
it does not forward packets to the home link but to another address
based on MN's home binding. Our approach is analogous. For a special
mobility routing case we skip a part of 2460 to be more efficient in
header overhead and forwarding processing. Furthermore, we this way
localize this forwarding to a visited domain router.

=>I really can't see the analogy here. The breach is that you ignore
the routing header and RFC 2460 says you shouldn't.

Your HA Operation chapter 13 implies that this routing state exists and
for the cases that you explain,
"HA MUST include a routing header .. to enable the MAP to find the right
routing entry for the MN", which is what I meant by non-local forwarding
support (from the HA) for your visited-domain routing to operate correctly.

=> I think the answer to your question is in the ".." area ;)
basically Site-local addresses is the answer.

Additionally, as described in the AH RFC, IPhdr dstaddr is mutable but
predictable when a type 0 routing header is present. The check is done
for packet as seen after reception, that is, after applying routing header
in the final destination. With our design, we have the home address in
the DST field just like with basic Mobile IPv6.

Your design ends with the same, but with a bit more complicated routing
as described above. Our designs have similarities, but are not the same.

=>Yes it adds a fraction more complexity in the rare case of forwarding
Site-local packets, but it guarantees that nothing is lost. your proposal
doesn't guarantee that.

Having a convergence of some sort would be nice.. Would this call for
a framework for many regional/micro-mobility protocols or a simpler
common approach, what do you think?

=>I agree that there are some good ideas in all proposals and I look
forward to discussing this in Pittsburgh.

It would be nice to continue discussing the options in Pittsburgh?

=> Definitely.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sat Jul 29 14:49: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 OAA02652
	for ; Sat, 29 Jul 2000 14:49:01 -0400 (EDT)
Received: from standards (47.234.32.16:3080) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83313@standards.nortelnetworks.com>; Sat, 29 Jul 2000 14:37:09 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4684 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 29 Jul 2000 14:37:08
          -0400
Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB83312@standards.nortelnetworks.com>; Sat, 29 Jul 2000 14:27:08
          -0400
Received: from omega.cdt.ch (www.cdt.ch [195.141.150.68]) by
          hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id NAA03342 for
          ; Sat, 29 Jul 2000 13:38:13 -0500 (CDT)
Received: from firewall.cdt.ch ([195.141.150.65]) by omega.cdt.ch (Post.Office
          MTA v3.5.3 release 223 ID# 114-54317U100L100S0V35) with SMTP id ch;
          Fri, 28 Jul 2000 19:29:37 +0100
Message-ID:  
Date:         Fri, 28 Jul 2000 02:23:11 AM
Reply-To: 6154eY9AP@PUBLIC1.PTT.JS.CN
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: 6154eY9AP@PUBLIC1.PTT.JS.CN
Subject:      [MOBILE-IP] Fw: good timing?
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Look, we don't want to waste your time...or ours

You must be determined to earn a bare minimum of $10,000 in the next
30 - 45 days and to develop a net worth of over 1 Million Dollars Cash
in the next  24-36 months. My mission is to help other people develop their
life long dreams. Part of what I'm looking for are those people who are
committed to that BIG of a picture and are not afraid to work for it.
We can help you:

                   REGARDLESS OF YOUR CURRENT AGE
                                OR YOUR DEBT LOAD!

                             NOT MLM or FRANCHISE

                   Don't bother to call unless you are serious.

                Learn the Facts  CALL 1-800-220-0670 (24 hrs)

                          $10,000 IN 30 - 45 DAYS
                      RETIREMENT IN 3-5 YEARS

***************************************************************************************
All REMOVE requests AUTOMATICALLY honored upon receipt.
mailto:grapefoot@cybercashguys.com?subject=Remove
PLEASE understand that any effort to disrupt, close or block this REMOVE
account can only result in difficulties for others wanting to be removed from
our mailing list as it will be impossible to take anyone off the list if the
remove instruction can not be received.
****************************************************************************************


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sat Jul 29 15:35: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 PAA08303
	for ; Sat, 29 Jul 2000 15:35:32 -0400 (EDT)
Received: from standards (47.234.32.16:1433) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8339F@standards.nortelnetworks.com>; Sat, 29 Jul 2000 15:22:13 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4868 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 29 Jul 2000 15:22:13
          -0400
Received: from altavistausa.com (async-88.ts2.pouch.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB8338D@standards.nortelnetworks.com>; Sat, 29 Jul 2000
          15:12:10 -0400
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Message-ID:  <662.403500.7459@altavistausa.com>
Date:         Sat, 29 Jul 2000 15:22:13 -0400
Reply-To: callback123@ALTAVISTAUSA.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: callback123@ALTAVISTAUSA.COM
Subject:      [MOBILE-IP] From Lorraine,as promised,I can lower your bill
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM




Untitled Document








 

Today, everyone knows the impact of the Internet.

But not everyone nows how to cut their phone bill in 1/2. Just a Few examples!!!!



Uk $.04     France $.06    UAE  $.31
   Saudi Arabia $.59     Denmark $.04
     Sweden $.05



Click Here Now. 



If you do not have flash please go to

www.macromedia.com

to download it.







From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sun Jul 30 02:34:46 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16112
	for ; Sun, 30 Jul 2000 02:34:46 -0400 (EDT)
Received: from standards (47.234.32.16:2962) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8351D@standards.nortelnetworks.com>; 30 Jul 2000 2:23:06 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5368 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 30 Jul 2000 02:23:06
          -0400
Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB83510@standards.nortelnetworks.com>; 30 Jul 2000 2:13:05 -0400
Received: from ns.evolex.co.jp (ns.evolex.co.jp [210.232.178.114]) by
          hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id BAA06386; Sun, 30
          Jul 2000 01:24:10 -0500 (CDT)
Received: from ppp-207-193-1-128.kscymo.swbell.net_[207.193.1.128]
          (ppp-207-193-1-128.kscymo.swbell.net [207.193.1.128]) by
          ns.evolex.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP id
          PAA00758; Sun, 30 Jul 2000 15:21:53 +0900
Received: from 210.182.56.194 by ppp-207-193-1-128.kscymo.swbell.net with
          ESMTP; Sun, 30 Jul 2000 01:19:46 -0500
X-Priority: 3
X-MSMail-Priority: Normal
Errors-To: bescer23@earthlink.net
Message-ID:  <0000063f167e$00001698$00002ef3@210.182.56.194>
Date:         Sun, 30 Jul 2000 01:19:37 -0500
Reply-To: bescer23@earthlink.net
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: bescer23@earthlink.net
Subject:      [MOBILE-IP] Inside Info On Currency Trading Can Build YOUR Wealth
              Quickly!
              12019
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

YEN YIELDS OVER 100% RETURN IN LESS THAN 60 DAYS!

Do you have a yen to be a millionaire?
Does your stock portfolio look like swiss cheese?
Are you feeling a little down under?
Do you know what pound for pound really means?

Find out how the good old U.S. Dollar Vs the Japanese Yen
properly positioned recently, could have DOUBLED YOUR MONEY
in less than 60 DAYS!  I.E. (in 1/1/00 out 2/22/00).

The Forex Market trades over 1.5 TRILLION DOLLARS 24 hours daily
through banking centers throughout the world!

Enjoy benefits of:
1) Global price transparency
2) No large market gaps equals limited risk
3) Unlimited profit potential.

S.K. Forex will provide you with proprietary trading information on all currencies,
BP, SF , EURO, CANADIAN, and AUSSIE dollars.

Utilize our ability to provide you with as much as 20:1 leverage, I.E. (10,000 x 20).
Therefore, an account of $10,000 U.S. can give you as much as a
$200,00 cash position!(

Risk capital only...Serious inquiries only.

For further information please complete the following request form.
Just Click Below, and Send us an E-Mail with the following info...

mailto:details998@hongkong.com?subject=WebSiteRequestMore
Name__________________________
City____________________
State______
Phone Number___________________
Best time to call__________________
mailto:details998@hongkong.com?subject=RequestMoreCurrencyInfo

We will contact you by phone just as soon as we can.
*Requests without phone number and required
info will NOT be processed.

    \|||/
    (. .)
---oOoo---------------
(REMOVAL INSTRUCTIONS)
This is a one-time mailing, done by an independent marketing company.
We respect your online privacy and apologize if you have received this
message in error.  We do respect our remove lists!   Please do not use
the reply to this e-mail, e-mail reply cannot be read!  If you would like to be
removed from our mailing list just click below and send us an remove request email.

mailto:bescer23@earthlink.net?subject=PleaseRemoveYenPromo


















YEN YIELDS OVER 100% RETURN IN LESS THAN 60 DAYS!

Do you have a yen to be a millionaire?
Does your stock portfolio look like swiss cheese?


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Jul 31 13:30:19 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14209
	for ; Mon, 31 Jul 2000 13:30:18 -0400 (EDT)
Received: from standards (47.234.32.16:3257) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83929@standards.nortelnetworks.com>; Mon, 31 Jul 2000 13:17:55 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0326 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jul 2000 13:17:55
          -0400
Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFB83928@standards.nortelnetworks.com>; Mon, 31 Jul 2000 13:17:54
          -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 e6VHSw653064; Mon, 31 Jul 2000 19:28:59 +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 TAA01703; Mon, 31 Jul 2000 19:28:58 +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 TAA79047; Mon, 31 Jul 2000 19:30:02 +0200 (CEST)
          (envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-ID:  <200007311730.TAA79047@givry.rennes.enst-bretagne.fr>
Date:         Mon, 31 Jul 2000 19:30:02 +0200
Reply-To: Francis.Dupont@ENST-BRETAGNE.FR
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: Francis Dupont 
Subject:      Re: [MOBILE-IP] Implementation Issues re MobileIP and IPSec
X-To:         Stefan Schmid 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  Your message of Thu, 27 Jul 2000 22:18:59 BST. 
              

 In your previous mail you wrote:

     we are currently implementing IPsec support for our Mobile IPv6
   stack. However, after looking closely at the Mobile IPv6 specification, we
   found the following contradictions/obscurities:

   1.

=> this point was signaled by me and others... The final document
is supposed to fix it.

   2. According to the IPv6 RFC (2460) "extension headers must be
   processed strictly in the order they appear in the packet". It
   explicitly states that "a receiver MUST NOT, for example, scan through
   a packet looking for a particular kind of extension header and process
   that header prior to processing all preceding ones".
   However, in contrast, the Mobile IPv6 specification declares that "the
   Destination Options header in which the Binding Update option is
   inserted MAY appear either before or after the AH or ESP header".
   Since a Binding Update option cannot be processed before the packet
   was properly authenticated (note that "any packet carrying a BU MUST
   be protected by IPSEC [...]" (see 4.4), it should never occur before
   the AH header in the packet.

=> I disagree because you put more in "Binding Update option processing"
than it should be. In fact when you decode the BU you don't know if there
is an AH after or (the argumebnt :-) a HA option. I execute the BU only
when I see the upper layer header, the processing itself is restricted
to length/alignement checks.

   1. It should explicitly state which address, the mobile node's Home
   Address or care-of-address, must be used as IPv6 source address for
   the authentication calculation.

=> agree but I don't know what will be in the final document
(then I don't know if my code will interoperate because there are
two options :-).

      We believe that only the latter makes sense, as the
   care-of-address must be authenticated in order to prevent malicious
   binding update messages. Note that otherwise (i.e. the source address
   is set
   to the Home Address when authentication is perfomed) the
   care-of-address would not be authenticated.

=> an older document suggests to swap the two addresses (same protection
but interoperability problem).

   2. It should clarify which address, the mobile node's Home Address or
   care-of-address, must be used for the SA/SP lookup.

=> this is clearly specified in the I-D (home address must be used).

   Any comments? Also, could anybody please confirm if we are on the
   right track, or if we have overlooked something.

=> I know only two missing parts in the last I-D:
 - HA option processing (=> home and care-of address order)
 - protocol(s) in phase 2 IKE ID payloads (I use 60 with no/any port)
Both should not block your work (ie you should get a working implementation
after some fight with/against IKE :-).

Regards

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Jul 31 13:36:21 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15184
	for ; Mon, 31 Jul 2000 13:36:20 -0400 (EDT)
Received: from standards (47.234.32.16:3257) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83962@standards.nortelnetworks.com>; Mon, 31 Jul 2000 13:23:28 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0321 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jul 2000 13:23:28
          -0400
Received: from hotmail.com (f273.law8.hotmail.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB83924@standards.nortelnetworks.com>; Mon, 31 Jul 2000
          13:13:28 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon,
          31 Jul 2000 10:24:39 -0700
Received: from 208.128.200.131 by lw8fd.law8.hotmail.msn.com with HTTP; Mon, 31
          Jul 2000  GMT
X-Originating-IP: [208.128.200.131]
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
X-OriginalArrivalTime: 31 Jul 2000 17:24:39.0209 (UTC)
                       FILETIME=[34B88990:01BFFB14]
Message-ID:  
Date:         Mon, 31 Jul 2000 22:54:39 IST
Reply-To: V Ajay 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: V Ajay 
Subject:      [MOBILE-IP]
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

hi ,
   I am sending the resume for your reference. please find if it is suitable


                                VIJAYSUNDARAN  AJAY


E-mail id : ajay_v@hotmail.com
Tel 408-296-7488 (H)

WORK EXPERIENCE         :  -

Three+ years of experience since October 1996.


TECHNICAL SKILLS                :


Operating Systems       :       MS-DOS, UNIX, VxWorks (Real
                                Time Operating system)
                                Windows NT.

Languages Known         :       C++, C, FoxPro, VC++.

GUI Tools               :       X-Windows(on Unixplatform).

Case Tools              :    Object Geode for Object
                             Oriented Analysis and Design.
                             DOORS for Software
                             Requirements Specifications
                             Rational Rose



EDUCATIONAL QUALIFICATION               :



B.E. in Computer Science & Engineering from Vishwakarma Institute of
Technology
College of Engineering Poona (Maharashtra) affiliated to Poona University
Year of Passing: - June 1996





PROJECTS EXECUTED


1. Stock Management Report in COBOL as minor project in B.E.
2. Hospital Management System developed in 'BCW' Borland C for Windows using
Windows as GUI which takes into account all the data entry, storage and
maintenance operations. This was as a part of final project in B.E.
Curriculum.





DETAILS OF WORK EXPERIENCE              :

August 99 - May 2000.

Presently working as a Senior Engineer in TATA ELXSI India Ltd,
in Design and Development office as a part of Networking Team.
The Internet Printing Protocol(IPP) is an application layer protocol based
on client-server paradigm. The IPP model allows an end user (at the client
side) to request for printer and job operations. The HTTP transport services
are used to communicate between client and server. IPP is developed for
WINDOWS NT operating system. IPP-NT client and server can inter operate with
any other third party IPP client and server.
Operating System : Windows NT
Tools used       : VC++



Period : Nov 97 - August 99


Worked  as a Software Engineer on a Ministry of Defense Project in
R.K.Puram, New Delhi , deputed through Groupware Information Systems Pvt.
Ltd. Pune since Nov 1997

The Project is the design and development of Submarine Combat System for
Indian Navy.
It involves the design of Computerized Action Information System and Command
and Control
onboard a Submarine.
I was involved in the design and code development of the Training Module of
the above
project. Sun Solaris was the host machine on which the Program Development
was done.
VxWorks (x86) was the final target machine on which the final object module
was loaded.This module consists of a set of co-operating tasks communicating
with
each other through message queues and TCP/IP.
Message queue's were used for intertask communication in the
same module.TCP/IP was used for intertask communication
across different modules in different hardware platfroms
X-Windows was used as GUI for  the development of screens on which the real
time data was dynamically presented over a period of time.
Some of the information is stored in the disk which is to be retrieved and
used depending on the operators interaction.
Training module consisted of a communication handler
which formed the packet , out of the data generated
periodically. It is sent to the other modules in the system through TCP/IP.
VxWorks is the final target on which the object module is run as a set of
tasks.(currently x86 target is being used).
Object GEODE was the CASE tool used for generating the Software Design
Description Document. DOORS was used for generating the Software
Requirements Specification from the Functional Specifications.

Operating System        :       Sun OS, VxWorks (RTOS)
Tools used              :       C++





Duration: October 1996 to Nov 1997
Worked on Office Automation Project for a Krupp Industries
(INDIA) Ltd. Pune deputed through Groupware Information Systems
Ltd. Pune. My Role was Design of Data Entry Screens for various
modules and also testing and maintenance of implemented modules.

Platform                :       Windows for Workgroups
Tools Used              :       Powerbuilder  ver 4.0 Watcom SQL as backend







PERSONAL DETAILS        :


DATE OF BIRTH           :       10th June 1974

REFERENCES               :    Mr. K.R.Narayanan
                              Assistant Director General)
                              122  , 'C' Wing Sena Bhavan
                              New Delhi



________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Jul 31 14:09:38 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19033
	for ; Mon, 31 Jul 2000 14:09:38 -0400 (EDT)
Received: from standards (47.234.32.16:3257) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB839EB@standards.nortelnetworks.com>; Mon, 31 Jul 2000 13:57:50 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0595 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jul 2000 13:57:50
          -0400
Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1b) with SMTP id <0.FFB839EA@standards.nortelnetworks.com>;
          Mon, 31 Jul 2000 13:57: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 MAA01248; Mon, 31 Jul 2000 12:08:58
          -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
          LAA29627; Mon, 31 Jul 2000 11:08:56 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (esun1as-be.Central.Sun.COM [129.147.34.142])
          by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id LAA24537; Mon,
          31 Jul 2000 11:08:48 -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:  <200007311808.LAA24537@nasnfs.eng.sun.com>
Date:         Mon, 31 Jul 2000 14:10:09 -0600
Reply-To: Pat.Calhoun@Eng.Sun.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: Patrice Calhoun 
Subject:      Re: [MOBILE-IP] handoff breakout session
X-To:         Gopal Dommety 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

>
>Clarification:
>
>There are two issues when we discuss IPv6 Fast Handoffs.
>
>1. Introduction of Local Mobility Agents in IPv6 (I am not suggesting any
>scheme).
>2. using the general framework see how fast handoffs are acheived (this is
>the generic stuff
>and not dependent on v4 or v6).
>
>We should discuss issue 2 and not sure of 1 in the handoff discussions.

We should NOT be discussing option 1 in the pre-meeting. This is something that
is desperately needed in Mobile IP, and requires alot more than the pre-meeting.

PatC


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Jul 31 19:56:11 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11238
	for ; Mon, 31 Jul 2000 19:56:11 -0400 (EDT)
Received: from standards (47.234.32.16:3829) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83B15@standards.nortelnetworks.com>; Mon, 31 Jul 2000 19:43:44 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0975 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jul 2000 19:43:43
          -0400
Received: from prue.eim.surrey.ac.uk by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB83B14@standards.nortelnetworks.com>; Mon, 31 Jul 2000 19:33:43
          -0400
Received: from carter-e0.ee.surrey.ac.uk ([131.227.86.16]) by
          prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 13JPEt-0007A9-00
          for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 01 Aug 2000 00:44:55
          +0100
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID:  
Date:         Tue, 1 Aug 2000 00:44:55 +0100
Reply-To: Karann Chew 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"              
From: Karann Chew 
Subject:      [MOBILE-IP] Doubts from 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Dear All,

Just read this draft, and am have some doubts.

Section 3, paragraph 3:
"If the packets for the MN are tunnelled from the HA, then the GFA should
change the source and destination IP address of the encapsulating header to the "next" FA towards the MN."

Do the authors mean changing source address to GFA's address, whereas
destination address is changed to the address of the next FA towards the
MN?






Another question (which is not the main issue in this draft):

Section 2, Paragraph 1 and 2 read:
"a MN may be attached directly to any FA within the hierarchy and may
move between FAs from different levels in the hierarchy. The following
figure describes the Hierarchical MIPv4 network.
                          ________
                         |        |
                         |  GFA   |
                         |________|
                          /   |  \
                        ...  ...  ...
                          ____|___
                         |        |
                         |   FA3  |
                         |________|
                    ______/_     _\______
                   |        |   |        |
                   |   FA2  |   |   FA1  |
                   |________|   |________|
                    ____|___     ____|___
                   |        |   |        |
                   |AP/RAN 2|   |AP/RAN 1|
                   |________|   |________|
                        |        ____|___
                                |        |
                       CN       |   MN   |
                                |________|

      Figure 1: Multi-level Hierarchical MIPv4 domain.

In the above figure, Access Points (APs) or Radio Access Networks
(RANs) consisting of multiple access points, are used to provide a MN with
L2 access."

Am I right to say that: when one states that a MN may be attached to and
moved freely among FAs at different levels of the hierarchy (such
statement appears not only in this draft, but others such as HAWAII), it
is assumed that all of the FAs are connected to some kind of Access
Points or RAN?  So, the FA1, FA2, FA3 in figure above should be connected
to some radio access points/network?

If so, how's the network practically look like?  Any example?  What
about: Each FA is connecting to a WaveLan ??  How about the appliciable of
these  hierarchical architecture in a cellular network??

Perhaps I'm confused, or misunderstood some points.  Advice &
comments for enlightenment are much appreciated.

Cheers!
        Karann

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
             Karann Chew
   Mobile Communications Research Group
Centre for Communication Systems Research
          University of Surrey
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



The project web page can be found at

http://comet.columbia.edu/pmip/

where the ID and other info can

be found.