From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Sep 1 07:43: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 HAA09013 for ; Fri, 1 Sep 2000 07:43:48 -0400 (EDT) Received: from standards (47.234.32.16:1692) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8EE3D@standards.nortelnetworks.com>; Fri, 1 Sep 2000 7:30:14 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10596 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 1 Sep 2000 07:30:14 -0400 Received: from qhars002.nortel.com (47.101.112.102:34050) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8EE3C@standards.nortelnetworks.com>; Fri, 1 Sep 2000 7:30:13 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Fri, 1 Sep 2000 12:42:44 +0100 Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch1.nortel.com; Fri, 1 Sep 2000 06:43:51 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Fri, 1 Sep 2000 06:41:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C01409.9B275040" Message-ID: Date: Fri, 1 Sep 2000 06:41:45 -0500 Reply-To: Ron Young Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Ron Young Subject: Re: [MOBILE-IP] about unsubscription 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_01C01409.9B275040 Content-Type: text/plain; charset="iso-8859-1" ZhuGe, You are right in that people who subscribed after the Mobile IP mailing list moved to our server should know how to unsubscribe because of the confirmation e-mail; however, I am guessing 70% of the people on this list subscribed when it was on the Smallworks server so they never got the confirmation e-mail. As an aside to everyone out there, could you update any links you have on your web page, drafts, etc. to point to our server. We still get a number of subscribe request that were forwarded from the Smallworks server. Xinming, I will send a note to the IETF web admin to update our page to include the unsubscribe information. ------------------------------------------------------------------------ Ron Young ronyoung@nortelnetworks.com http://www.nortelnetworks.com/ You can't spell Nortel without Ron; of course, you can't spell moron without Ron either. -----Original Message----- From: ZhuGe Lei [mailto:lzhuge@EEE.HKU.HK] Sent: Thursday, August 31, 2000 9:51 PM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] about unsubscription "You may leave the list at any time by sending a "SIGNOFF MOBILE-IP" or "UNSUBSCRIBE MOBILE-IP" command to LISTSERV@STANDARDS.NORTELNETWORKS.COM." (in the email confirming subscription from the list server :-) On Thu, 31 Aug 2000, Xinming He wrote: > ----------------- > Sorry to bother everyone. But I really do not know how to unsubscribe from > this email list. I suggest there should be information on how to > unsubscribe besides the information on how to subscribe in the web page of > the mobile IP working group. > ------_=_NextPart_001_01C01409.9B275040 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] about unsubscription

ZhuGe,

You are right in that people who subscribed after the = Mobile IP mailing list moved to our server should know how to = unsubscribe because of the confirmation e-mail; however, I am guessing = 70% of the people on this list subscribed when it was on the Smallworks = server so they never got the confirmation e-mail.  As an aside to = everyone out there, could you update any links you have on your web = page, drafts, etc. to point to our server.  We still get a number = of subscribe request that were forwarded from the Smallworks = server.

Xinming, I will send a note to the IETF web admin to = update our page to include the unsubscribe information.

---------------------------------------------------------------= ---------
Ron Young   = ronyoung@nortelnetworks.com   http://www.nortelnetworks.com/
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;          
  You can't spell Nortel without Ron; of = course, you can't spell moron
          &nb= sp;           &nb= sp;    without Ron either.
 

-----Original Message-----
From: ZhuGe Lei [mailto:lzhuge@EEE.HKU.HK]
Sent: Thursday, August 31, 2000 9:51 PM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: Re: [MOBILE-IP] about unsubscription


"You may leave  the list at any  time = by sending a  "SIGNOFF MOBILE-IP" or
"UNSUBSCRIBE MOBILE-IP" command to = LISTSERV@STANDARDS.NORTELNETWORKS.COM."
(in the email confirming subscription from the list = server :-)


On Thu, 31 Aug 2000, Xinming He wrote:

> -----------------
> Sorry to bother everyone. But I really do not = know how to unsubscribe from
> this email list. I suggest there should be = information on how to
> unsubscribe besides the information on how to = subscribe in the web page of
> the mobile IP working group.
>

------_=_NextPart_001_01C01409.9B275040-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Sep 1 10:01: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 KAA12154 for ; Fri, 1 Sep 2000 10:01:26 -0400 (EDT) Received: from standards (47.234.32.16:1136) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8EEE1@standards.nortelnetworks.com>; Fri, 1 Sep 2000 9:47:53 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10800 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 1 Sep 2000 09:47:53 -0400 Received: from hkueee2.eee.hku.hk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8EEE0@standards.nortelnetworks.com>; Fri, 1 Sep 2000 9:47:52 -0400 Received: from hkueee1 (lzhuge@hkueee1.eee.hku.hk [147.8.180.2]) by hkueee2.eee.hku.hk (8.11.0/8.11.0) with ESMTP id e81E0cl09623 for ; Fri, 1 Sep 2000 22:00:38 +0800 (HKT) X-Sender: lzhuge@hkueee1 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Fri, 1 Sep 2000 22:00:37 +0800 Reply-To: ZhuGe Lei Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: ZhuGe Lei Subject: Re: [MOBILE-IP] about unsubscription To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Ron, I guess I did register on Nortel server. Actually I don't know about the Smallworks server. I just want to help Xinming on the unsubscription. I'm an ordinary subscriber of MIP mail list so have nothing to update. However, since we've already seen many unsubscribing emails sent to the wrong address, it's a good idea adding a note on the IETF page about unsubscription. Have a nice day. Lei On Fri, 1 Sep 2000, Ron Young wrote: > ZhuGe, > > You are right in that people who subscribed after the Mobile IP mailing list > moved to our server should know how to unsubscribe because of the > confirmation e-mail; however, I am guessing 70% of the people on this list > subscribed when it was on the Smallworks server so they never got the > confirmation e-mail. As an aside to everyone out there, could you update > any links you have on your web page, drafts, etc. to point to our server. > We still get a number of subscribe request that were forwarded from the > Smallworks server. > > Xinming, I will send a note to the IETF web admin to update our page to > include the unsubscribe information. > > ------------------------------------------------------------------------ > Ron Young ronyoung@nortelnetworks.com http://www.nortelnetworks.com/ > > You can't spell Nortel without Ron; of course, you can't spell moron > without Ron either. > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Sep 1 10:50:54 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13165 for ; Fri, 1 Sep 2000 10:50:53 -0400 (EDT) Received: from standards (47.234.32.16:3492) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8EF48@standards.nortelnetworks.com>; Fri, 1 Sep 2000 10:37:20 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10931 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 1 Sep 2000 10:37:20 -0400 Received: from quicksilver.ukc.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8EF47@standards.nortelnetworks.com>; Fri, 1 Sep 2000 10:37:20 -0400 Received: from pelican.ukc.ac.uk ([129.12.200.26]) by quicksilver.ukc.ac.uk with esmtp (Exim 3.16 #1) id 13Us8V-0007Nq-00 for MOBILE-IP@standards.nortelnetworks.com; Fri, 01 Sep 2000 15:49:43 +0100 Received: from pccomm6.ukc.ac.uk ([129.12.50.119] helo=pccomm6) by pelican.ukc.ac.uk with smtp (Exim 1.92 #1) for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM id 13Us8o-00017V-00; Fri, 1 Sep 2000 15:50:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Message-ID: Date: Fri, 1 Sep 2000 15:44:31 +0100 Reply-To: Kumarendra Sivarajah Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Kumarendra Sivarajah Subject: [MOBILE-IP] WAP versus Mobile IP To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Mobile IP. I have two simple questions. Does WAP uses Mobile IP or does it totally uses a different type of protocol. What are the pro's and con's of WAP in comparison to Mobile IP. Thanks, Indran From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Sep 1 11:46: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 LAA14745 for ; Fri, 1 Sep 2000 11:46:26 -0400 (EDT) Received: from standards (47.234.32.16:3492) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8EFF1@standards.nortelnetworks.com>; Fri, 1 Sep 2000 11:32:53 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 11145 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 1 Sep 2000 11:32:53 -0400 Received: from smtpgw1.sprintspectrum.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8EFF0@standards.nortelnetworks.com>; Fri, 1 Sep 2000 11:32:49 -0400 Received: from pkcex003.sprintspectrum.com (pkcex003.sprintspectrum.com [208.10.75.138]) by smtpgw1.sprintspectrum.com (8.9.3/8.9.3) with ESMTP id KAA22082 for ; Fri, 1 Sep 2000 10:45:29 -0500 (CDT) Received: by PKCEX003 with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Sep 2000 10:45:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <2D11BCC7FFD8D3118FD70000D1ECDC8802FAE4A3@pkcexv018.sprintspectrum.com> Date: Fri, 1 Sep 2000 10:45:09 -0500 Reply-To: "Lipford, Mark" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Lipford, Mark" Subject: Re: [MOBILE-IP] WAP versus Mobile IP X-To: Kumarendra Sivarajah To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM These are two totally different technologies. Without getting into a long drawn-out thread (none of us need the added email), WAP currently uses simple IP protocol for the transport of its protocol stack. Since a WAP client current will always connect with its dedicated WAP gateway the use of mobile IP is not needed (I actually have had this discussion in WAP). If you want to know about WAP's capabilities you should go to the WAP Forum web site (www.wapforum.org) . IETF is not responsible for the WAP protocol (nor do I think they want anything to do with WAP). WAP is working to try and better converge with IETF standards. Thanks Mark A. Lipford -----Original Message----- From: Kumarendra Sivarajah [mailto:ks23@UKC.AC.UK] Sent: Friday, September 01, 2000 9:45 AM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: [MOBILE-IP] WAP versus Mobile IP Hello Mobile IP. I have two simple questions. Does WAP uses Mobile IP or does it totally uses a different type of protocol. What are the pro's and con's of WAP in comparison to Mobile IP. Thanks, Indran From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Sep 1 16:24: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 QAA19602 for ; Fri, 1 Sep 2000 16:24:31 -0400 (EDT) Received: from standards (47.234.32.16:1289) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8F16C@standards.nortelnetworks.com>; Fri, 1 Sep 2000 16:11:09 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 11628 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 1 Sep 2000 16:11:09 -0400 Received: from sj-msg-core-1.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8F16B@standards.nortelnetworks.com>; Fri, 1 Sep 2000 16:11:08 -0400 Received: from shako.cisco.com (shako.cisco.com [161.44.3.76]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA04126; Fri, 1 Sep 2000 13:13:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Fri, 1 Sep 2000 16:12:39 -0400 Reply-To: Madhavi W Subbarao Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Madhavi W Subbarao Subject: Re: [MOBILE-IP] Local Mobility Agents in IPv6 X-To: "Kay, Rodney" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <2A5485D1C9C7D311816F0000F805ADB7697047@vhapugexc1.med.va.gov> Hi Rodney, Yes, LMAs for IPv6 can be viewed as FAs in IPv4. Reduction of latency is because the MN can use the advertised LMA CoA and thus, avoid the delay incurred in obtaining a co-located CoA (DHCP or Autoconfiguration). A dynamic hierarchy of LMAs can be created using the tunneling of Binding Updates, thereby reducing the signaling involved with a MN registering all the way back with the HA everytime the MN moves. This dynamic hierarchy also reduces latency since a handoff does not have to propagate all the way to the HA/CN each time. -Madhavi On Wed, 30 Aug 2000, Kay, Rodney wrote: > The concept of a Local Mobility Agent (LMA) which acts as a reference point > for the MN to the HA/CN seems to be fulfilling the same function as the FA > in IPv4, but I am unclear how latency is improved by "The MN registers back > with the HA using the LMA CoA, and anchors with the LMA as it moves in > foreign domains." > > It would seem that the possibility would exist for the MN to switch LMA > anchors prior to the HA/CN effecting the CoA change. Would it be possible > that the LMA could also be satellite based? > > Rodney H. Kay > Department of Veterans Affairs > Puget Sound Health Care System > Systems Manager > Seattle, Washington 98108 > <> > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Sep 4 01: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 BAA21291 for ; Mon, 4 Sep 2000 01:39:27 -0400 (EDT) Received: from standards (47.234.32.16:4924) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8F5F3@standards.nortelnetworks.com>; Mon, 4 Sep 2000 1:25:27 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13111 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Sep 2000 01:25:26 -0400 Received: from tsbgw.wide.toshiba.co.jp by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8F5F2@standards.nortelnetworks.com>; Mon, 4 Sep 2000 1:25:25 -0400 Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (8.9.3/8.9.1) with ESMTP id OAA25854; Mon, 4 Sep 2000 14:37:57 +0900 (JST) Received: from isl.rdc.toshiba.co.jp (spiffy.isl.rdc.toshiba.co.jp [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id OAA28471; Mon, 4 Sep 2000 14:37:56 +0900 (JST) Received: from isl.rdc.toshiba.co.jp (cent.isl.rdc.toshiba.co.jp [133.196.16.40]) by isl.rdc.toshiba.co.jp (8.9.3/8.9.3/8.4) with ESMTP id OAA02919; Mon, 4 Sep 2000 14:37:56 +0900 (JST) Message-ID: <200009040537.OAA02919@isl.rdc.toshiba.co.jp> Date: Mon, 4 Sep 2000 14:37:56 +0900 Reply-To: FUKUMOTO Atsushi Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: FUKUMOTO Atsushi Subject: Re: [MOBILE-IP] about unsubscription X-To: Ron Young To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: ronyoung's message of "Fri, 01 Sep 2000 06:41:45 EST." Regarding MOBILE-IP mailng list: > Xinming, I will send a note to the IETF web admin to update our page to > include the unsubscribe information. Please update the archive URL along with it; WG charter page lists http://www.nortelnetworks.com/standards , but it's not available there. It must be http://standards.nortelnetworks.com/ FUKUMOTO Atsushi fukumoto@isl.rdc.toshiba.co.jp From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Sep 4 03:08: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 DAA00240 for ; Mon, 4 Sep 2000 03:08:32 -0400 (EDT) Received: from standards (47.234.32.16:3045) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8F65A@standards.nortelnetworks.com>; Mon, 4 Sep 2000 2:55:02 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13243 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Sep 2000 02:55:01 -0400 Received: from mailserv.intranet.GR by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8F655@standards.nortelnetworks.com>; Mon, 4 Sep 2000 2:45:00 -0400 Received: from patreas.patra.intranet.gr by mailserv.intranet.GR with ESMTP (8.8.8/ICM-mailhub-1.0) id JAA24787; Mon, 4 Sep 2000 09:55:07 +0300 (EET DST) Received: from patdpd19.intranet.gr (patdpd19 [146.124.171.45]) by patreas.patra.intranet.gr (8.9.1b+Sun/8.9.0) with SMTP id KAA17923 for ; Mon, 4 Sep 2000 10:07:14 +0300 (EET DST) X-Mailer: KMail [version 1.0.29] Content-Type: text/plain MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: <00090409532700.00778@patdpd19.intranet.gr> Date: Mon, 4 Sep 2000 09:10:52 +0300 Reply-To: Dionisios Gatzounas Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Dionisios Gatzounas Organization: INTRACOM S.A. Subject: [MOBILE-IP] A question on Mobile IP Regional Registration To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit Hi. I have a question on Mobile IP Regional Registration. This is as follows: In the , when a mobile node determines that it is located in a visited domain it performs a home registration. Suppose that the mobile node has acquired a co-located care-of address in the visited domain (e.g., with DHCP) but it wishes to use the address of the GFA of the visited domain as its care-of address. The mobile node will then issue a Registration Request message with the GFA address in the care-of address field and it will add a Hierarchical Foreign Agent extension including its co-located care-of address. Does the same applies when the mobile node performs a Regional Registration? To my understanding, when the mobile node performs a handoff from one subnet to another within the same visited domain, it issues a Regional Registration Request addressed to the GFA. The mobile node includes the GFA address in the HA field, the address of the foreign agent of the new subnet in the care-of address field (?) and it also adds a Hierarchical Foreign Agent extension including its new co-located care-of address. Is that correct? Any comments will be good enough to me... Thank you in advance. BR, Dionisios. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Sep 4 05:19: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 FAA01351 for ; Mon, 4 Sep 2000 05:19:23 -0400 (EDT) Received: from standards (47.234.32.16:1778) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8F7AE@standards.nortelnetworks.com>; Mon, 4 Sep 2000 5:05:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13671 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Sep 2000 05:05:52 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8F7AC@standards.nortelnetworks.com>; Mon, 4 Sep 2000 4:55:51 -0400 Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id e8498lp21178; Mon, 4 Sep 2000 11:08:47 +0200 (MEST) Received: from e00105a2d1ed7 by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id LAA02133; Mon, 4 Sep 2000 11:08:46 +0200 X-Sender: erajoaa@era-t.ericsson.se X-Mailer: Windows Eudora Pro Version 3.0 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <3.0.32.20000904110531.00e96ae0@era-t.ericsson.se> Date: Mon, 4 Sep 2000 11:05:31 +0200 Reply-To: Annika Jonsson Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Annika Jonsson Subject: Re: [MOBILE-IP] A question on Mobile IP Regional Registration X-To: Dionisios Gatzounas To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM At 09:10 2000-09-04 +0300, Dionisios Gatzounas wrote: >Hi. > >I have a question on Mobile IP Regional Registration. This is as follows: > >In the , when a mobile node determines >that it is located in a visited domain it performs a home registration. Suppose >that the mobile node has acquired a co-located care-of address in the >visited domain (e.g., with DHCP) but it wishes to use the address of the GFA of >the visited domain as its care-of address. The mobile node will then issue a >Registration Request message with the GFA address in the care-of address field >and it will add a Hierarchical Foreign Agent extension including its co-located >care-of address. > Correct. >Does the same applies when the mobile node performs a Regional Registration? > Yes. >To my understanding, when the mobile node performs a handoff from one subnet >to another within the same visited domain, it issues a Regional Registration >Request addressed to the GFA. The mobile node includes the GFA address in the >HA field, the address of the foreign agent of the new subnet in the care-of >address field (?) and it also adds a Hierarchical Foreign Agent extension >including its new co-located care-of address. > >Is that correct? > Almost. The MN has two options. The MN either uses it's co-located care-of address and registers directly with the GFA (HA field = GFA, COA field = co-located care-of address, + Hierarchical Foreign Agent extension including its co-located care-of address), which means that the GFA sends traffic directly to the MN and the FA is not involved at all. Or the MN migth decide to use the FA address as COA instead of getting a new co-located care-of address (HA field = GFA, COA field = FA care-of address, no Hierarchical Foreign Agent extension). In this case the FA will add a Hierarchical Foreign Agent extension with its adress, and the GFA will send the traffic to the FA, who will forward it to the MN. >Any comments will be good enough to me... >Thank you in advance. > Hope this helps. /Annika >BR, >Dionisios. > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Sep 4 05:23: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 FAA01377 for ; Mon, 4 Sep 2000 05:23:40 -0400 (EDT) Received: from standards (47.234.32.16:1778) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8F7E9@standards.nortelnetworks.com>; Mon, 4 Sep 2000 5:08:24 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13743 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Sep 2000 05:08:24 -0400 Received: from mailserv.intranet.GR by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8F7E8@standards.nortelnetworks.com>; Mon, 4 Sep 2000 5:08:23 -0400 Received: from patreas.patra.intranet.gr by mailserv.intranet.GR with ESMTP (8.8.8/ICM-mailhub-1.0) id MAA03560; Mon, 4 Sep 2000 12:18:30 +0300 (EET DST) Received: from patdpd19.intranet.gr (patdpd19 [146.124.171.45]) by patreas.patra.intranet.gr (8.9.1b+Sun/8.9.0) with SMTP id MAA20256 for ; Mon, 4 Sep 2000 12:30:47 +0300 (EET DST) X-Mailer: KMail [version 1.0.29] Content-Type: text/plain References: <3.0.32.20000904110531.00e96ae0@era-t.ericsson.se> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: <00090412170001.00778@patdpd19.intranet.gr> Date: Mon, 4 Sep 2000 12:12:38 +0300 Reply-To: Dionisios Gatzounas Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Dionisios Gatzounas Organization: INTRACOM S.A. Subject: Re: [MOBILE-IP] A question on Mobile IP Regional Registration To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <3.0.32.20000904110531.00e96ae0@era-t.ericsson.se> Content-Transfer-Encoding: 8bit Thank you for your time to answer my question. Your hint was very helpful. BR, Dionisios. On Mon, 04 Sep 2000, you wrote: > At 09:10 2000-09-04 +0300, Dionisios Gatzounas wrote: > >Hi. > > > >I have a question on Mobile IP Regional Registration. This is as follows: > > > >In the , when a mobile node determines > >that it is located in a visited domain it performs a home registration. > Suppose > >that the mobile node has acquired a co-located care-of address in the > >visited domain (e.g., with DHCP) but it wishes to use the address of the > GFA of > >the visited domain as its care-of address. The mobile node will then issue a > >Registration Request message with the GFA address in the care-of address > field > >and it will add a Hierarchical Foreign Agent extension including its > co-located > >care-of address. > > > > Correct. > > >Does the same applies when the mobile node performs a Regional Registration? > > > > Yes. > > >To my understanding, when the mobile node performs a handoff from one subnet > >to another within the same visited domain, it issues a Regional Registration > >Request addressed to the GFA. The mobile node includes the GFA address in the > >HA field, the address of the foreign agent of the new subnet in the care-of > >address field (?) and it also adds a Hierarchical Foreign Agent extension > >including its new co-located care-of address. > > > >Is that correct? > > > > Almost. The MN has two options. The MN either uses it's co-located care-of > address and registers directly with the GFA (HA field = GFA, COA field = > co-located care-of address, + Hierarchical Foreign Agent extension > including its co-located care-of address), which means that the GFA sends > traffic directly to the MN and the FA is not involved at all. Or the MN > migth decide to use the FA address as COA instead of getting a new > co-located care-of address (HA field = GFA, COA field = FA care-of address, > no Hierarchical Foreign Agent extension). In this case the FA will add a > Hierarchical Foreign Agent extension with its adress, and the GFA will send > the traffic to the FA, who will forward it to the MN. > > >Any comments will be good enough to me... > >Thank you in advance. > > > > Hope this helps. > > /Annika > > >BR, > >Dionisios. > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Sep 4 16:44: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 QAA06858 for ; Mon, 4 Sep 2000 16:44:33 -0400 (EDT) Received: from standards (47.234.32.16:3261) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8FB18@standards.nortelnetworks.com>; Mon, 4 Sep 2000 16:31:01 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 14800 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Sep 2000 16:31:00 -0400 Received: from mailhub.fokus.gmd.de by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8FB17@standards.nortelnetworks.com>; Mon, 4 Sep 2000 16:21:00 -0400 Received: from welcome.to (nostromo [193.175.132.245]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id WAA26345 for ; Mon, 4 Sep 2000 22:33:56 +0200 (MET DST) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <39B404D8.F502FB74@welcome.to> Date: Mon, 4 Sep 2000 22:23:53 +0200 Reply-To: SerP@welcome.to Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Service Portability Subject: [MOBILE-IP] GLOBECOM2000 Workshop on Service Portability: CFP To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit CALL FOR PAPERS GLOBECOM2000 workshop Service Portability and Virtual Customer Environments San Francisco, Dec. 1rst, 2000 WWW: http://welcome.to/SerP Present day mobile systems focus heavily on the radio access segment, with very little attention paid to mobility at the applications and services level.. Similarly, in the Internet arena, the standardization efforts for mobility support have mostly focussed on enabling the roaming of a terminal identified by its network address. With rapid growth in Internet services and mobile hosts, it has become essential to address new requirements in cases where a customer is roaming between heterogeneous networks and providers. The customer should be able to seamlessly roam between terrestrial and satellite networks, between wireless and wireline networks, between pure internet or IP/ATM connections, and between home and office. The main objectives of the workshop are to gather researchers actively involved in the design, implementation, and development of mobile customer premises environments/networks, multi-domain mobility, virtual home environment architectures, and mobility support architectures and environments for applications such as multimedia messaging service and real-time gaming, and to provide them with a forum suitable for identifying and discussing related issues. The workshop is intended to be a genuinely interactive event with constructive development and exchange of ideas. Topics of interests include: · Mobile Customer Premises Environments/Networks (MCPE/MCPN) and Virtual Home Environment (VHE) issues · Architectural issues for mobility support: IP/Internet, GPRS, IMT2000, UMTS, IN, TINA, OSGi, SIP, H.323.. · Mobility architectures and support for 3G/4G applications · Intelligent support and customization: agents, middleware, user profiling.. · Service roaming and interoperability across multi-provider access networks · Creation support, customization and management of terminal independent services · Scalability and adaptation of user terminal to services and platforms · Address and naming portability · Auto-configuration, programmability for micro/macro/multi-domain mobility.. · Conditional access and authentication · End to end QoS support including QoS routing · Security issues · Service discovery · Content management and XML based architectures.. PAPER SUBMISSION DEADLINE: SEPTEMBER 30TH For more info, Please refer to the web page: http//welcome.to/SerP From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Sep 4 18:03: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 SAA07407 for ; Mon, 4 Sep 2000 18:03:00 -0400 (EDT) Received: from standards (47.234.32.16:3261) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8FB90@standards.nortelnetworks.com>; Mon, 4 Sep 2000 17:49:35 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 14964 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Sep 2000 17:49:35 -0400 Received: from calliope1.fm.intel.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8FB8F@standards.nortelnetworks.com>; Mon, 4 Sep 2000 17:49:34 -0400 Received: from fmsmsx27.FM.INTEL.COM (fmsmsx27.fm.intel.com [132.233.42.27]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.31 2000/08/22 00:15:13 dmccart Exp $) with ESMTP id WAA21656 for ; Mon, 4 Sep 2000 22:02:32 GMT Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 4 Sep 2000 15:02:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4148FEAAD879D311AC5700A0C969E8901CC732@orsmsx35.jf.intel.com> Date: Mon, 4 Sep 2000 15:02:31 -0700 Reply-To: "Iyer, Prakash" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Iyer, Prakash" Subject: [MOBILE-IP] Looking for expired IDs To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM I am looking for the following IDs that appear to have expired. Appreciate if you could forward me a copy. draft-montenegro-aatn-nar-00.txt draft-montenegro-firewall-sup-03.txt draft-ietf-roamops-mobileip-01.txt draft-mccann-thema-00.txt TIA, -Prakash Iyer From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Sep 4 22:59: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 WAA11306 for ; Mon, 4 Sep 2000 22:59:58 -0400 (EDT) Received: from standards (47.234.32.16:4192) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8FD9C@standards.nortelnetworks.com>; Mon, 4 Sep 2000 22:46:27 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 15608 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Sep 2000 22:46:27 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8FD96@standards.nortelnetworks.com>; Mon, 4 Sep 2000 22:36:24 -0400 Received: from mail.modern-english.com ([194.244.94.34]) by hosaka.smallworks.com (8.9.1/8.9.1) with SMTP id VAA11504; Mon, 4 Sep 2000 21:49:14 -0500 (CDT) Received: from [209.178.167.213] by mail.modern-english.com (SMTPD32-4.0) id AB7518F0146; Fri, 01 Sep 2000 07:15:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Message-ID: <0000791c6411$00001fc4$00001125@209.178.167.213> Date: Thu, 31 Aug 2000 22:15:36 -0700 Reply-To: merchserv2531@HOTMAIL.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: merchserv2531@HOTMAIL.COM Subject: [MOBILE-IP] Merchant Services - No Setup Fees 4389 X-To: Undisclosed.Recipients@hosaka.smallworks.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit HOW TO SUBSTANTIALLY INCREASE SALES: Easily accept major credit cards right away! Act now and all Setup & App. fees waived Merchant Status will help you increase sales by an incredible 50% to 400%. Stop losing valuable sales! With one phone call you can be: Accepting all major credit cards! Accepting checks over the net or by Fax! Accepting real time processing for member sites! Gaining costumer loyalty and trust! Close the sale now. No more wondering if "The check is in the mail" We specialize in helping those entrepreneurs who are just starting out: no credit, poor credit, or even if you have great credit. Almost everyone is approved! For the next 5 days we will waive all Setup & App. fees! (other companies charge $200 to $500 to set up) In Business since 1992 ************************************************************** For Free Setup, DOUBLE CLICK ON: mailto:cards25@altavistausa.com?subject=credit Include your name, phone number and best time to call. *Subject must contain the word "credit" for us to receive your request. Or you can call 1(888) 242-8260 now! Our courteous customer care reps are anxious to help you get your merchant account today. ************************************************************** To remove, DOUBLE CLICK ON: mailto:cards25@altavistausa.com?subject=remove We will insure that your email address is removed from our database immediately. *Subject must contain the word "remove" for us to remove you. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Sep 5 21:49: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 VAA18229 for ; Tue, 5 Sep 2000 21:49:19 -0400 (EDT) Received: from standards (47.234.32.16:4486) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB905F0@standards.nortelnetworks.com>; Tue, 5 Sep 2000 19:18:55 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18292 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Sep 2000 19:18:55 -0400 Received: from hub.ecutel.com (ecutel.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB905EF@standards.nortelnetworks.com>; Tue, 5 Sep 2000 19:18:55 -0400 Received: from 192.168.50.149 by smtp.ecutel.com Tue, 05 Sep 2000 19:43:00 -0500 Received: from qiang-ntdesk [192.168.50.164] by hub.ecutel.com (SMTPD32-5.05) id A9531230114; Tue, 05 Sep 2000 20:01:23 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Message-ID: <010301c0179a$87900920$a432a8c0@qiang-ntdesk.ecutel.com> Date: Tue, 5 Sep 2000 19:36:43 -0500 Reply-To: Qiang Zhang Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Qiang Zhang Subject: Re: [MOBILE-IP] WAP versus Mobile IP X-To: Kumarendra Sivarajah To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi, WAP addresses the specific requirement for wireless link in the upper networking layers above IP and IP is only one of the bearers that WAP can run on top of. In another words, WAP and MIP are dealing with different issues. QZ -----Original Message----- From: Kumarendra Sivarajah To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Date: Friday, September 01, 2000 10:20 AM Subject: [MOBILE-IP] WAP versus Mobile IP >Hello Mobile IP. >I have two simple questions. >Does WAP uses Mobile IP or does it totally uses a different type of >protocol. >What are the pro's and con's of WAP in comparison to Mobile IP. >Thanks, >Indran > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Sep 7 03:52: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 DAA13514 for ; Thu, 7 Sep 2000 03:52:46 -0400 (EDT) Received: from standards (47.234.32.16:1536) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB91130@standards.nortelnetworks.com>; Thu, 7 Sep 2000 3:37:32 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 22023 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 7 Sep 2000 03:37:32 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9112D@standards.nortelnetworks.com>; Thu, 7 Sep 2000 3:27:31 -0400 Received: from estaff-svcs (ip90.phoenix8.az.pub-ip.psi.net [38.29.61.90]) by hosaka.smallworks.com (8.9.1/8.9.1) with SMTP id CAA10333; Thu, 7 Sep 2000 02:40:23 -0500 (CDT) Message-ID: <200009070740.CAA10333@hosaka.smallworks.com> Date: Thu, 7 Sep 2000 02:40:23 -0500 Reply-To: insightbook14@EXCITE.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: insightbook14@EXCITE.COM Subject: [MOBILE-IP] To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Dear Friend, Please sit down because the secret I’m about to reveal to you will make you light headed- Would you like to know how to turn $1.00 into $2,500.00 time after time with virtually no effort I CAN SHOW YOU HOW! If you want to change your lives circumstances fast, be able to afford all the good things in life and want your bank account to explode with CASH then this program is for you: PLEASE READ ON. Being a 25yr practicing Real Estate Broker I discovered after retiring a closely guarded secret so phenomenal that I must share it with you! This Real Estate loophole allows the average person to start and operate a Real Estate business without a license or money and make $2,500.00 to $25,000.00 per deal. The best part of this program is that you get to keep all of the money. You don’t have to split your profits with another Real Estate Agent or Broker. Here is some of what you will learn in this program HOW TO SELL AND CONTROL REAL ESTATE WITHOUT A LICENSE OR MONEY. YOU WILL: Learn how to sell Real Estate legally without a license anywhere in the USA! Learn how to make $2,500.00 to $25,00.00 with only $1.00 invested NOW THAT’S REAL LEVERAGE! Learn how to control $1,000,000 in Real Estate for only $100.00! Learn how to control your deals from start to finish! Learn how to create ownership rights in Real Estate without having to make Mortgage tax or insurance payments! Learn how to live in your home for free! Learn how to access a mortgage with 3% interest without a credit check or closing fees! Learn how to access Mortgage Lenders who loan money to almost anyone who has a job regardless of past credit problems! Learn how to sell your properties for full price every time by using Sub-Prime Lenders and make more money than you ever thought possible just by filling out one little piece of paper! TO ORDER: "HOW TO SELL AND CONTROL REAL ESTATE WITHOUT A LICENSE OR MONEY" FOR ONLY $39.00-S&H included! Call Now! 1-602-752-2424 *************** this is a one time mailer hit reply to get off this world info list From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Sep 8 12:39: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 SMTP id MAA25549 for ; Fri, 8 Sep 2000 12:39:02 -0400 (EDT) Received: from standards (47.234.32.16:2776) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB91777@standards.nortelnetworks.com>; Fri, 8 Sep 2000 12:23:29 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 24052 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Sep 2000 12:23:29 -0400 Received: from motgate2.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB91776@standards.nortelnetworks.com>; Fri, 8 Sep 2000 12:13:28 -0400 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id JAA25477 for ; Fri, 8 Sep 2000 09:26:37 -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 JAA23040 for ; Fri, 8 Sep 2000 09:26:37 -0700 (MST)] Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2650.21) id ; Fri, 8 Sep 2000 11:26: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: Date: Fri, 8 Sep 2000 11:26:33 -0500 Reply-To: Roberts Philip-qa3445 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Roberts Philip-qa3445 Subject: [MOBILE-IP] dave johnson please contact me To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Dave, could you please contact me? Thanks, Phil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Sep 10 20:22: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 SMTP id UAA10862 for ; Sun, 10 Sep 2000 20:22:11 -0400 (EDT) Received: from standards (47.234.32.16:1936) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB91C76@standards.nortelnetworks.com>; 10 Sep 2000 20:06:43 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1456 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 10 Sep 2000 20:06:43 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB91C73@standards.nortelnetworks.com>; 10 Sep 2000 19:56:42 -0400 Received: from ntsrv1.san-ken.co.jp (ntsrv1.san-ken.co.jp [210.145.222.67]) by hosaka.smallworks.com (8.9.1/8.9.1) with SMTP id TAA04364 for ; Sun, 10 Sep 2000 19:09:57 -0500 (CDT) Received: from hiokPaRqb [38.33.74.221] by ntsrv1.san-ken.co.jp (SMTPD32-4.05) id A33A196000BA; Mon, 11 Sep 2000 09:07:22 +0900 Message-ID: Date: Sun, 10 Sep 2000 08:37:52 PM Reply-To: A5c7717cF@GLOCOM.AC.JP Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: A5c7717cF@GLOCOM.AC.JP Subject: [MOBILE-IP] Market your product or service to the world ! X-To: cate5@dog.es To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Consider this More People turn to email marketing then any other method online. WHY? Its Simple, IT WORKS!! (Or you wouldn't see this) Market your product or service to the world ! The fact is that Email Marketing is the fastest method of seeing results online. Other methods like search engines, link exchanges, and classifieds could take weeks even months in some cases. However with email its immediate within a few days. Email has opened up a lot areas for selling services, products, business ventures, you name it. We are able to offer our discounted savings to you. So enjoy. They are as follows: 200,000 letters......$325 300,000 letters......$450 500,000 letters......$750 1,000,000 letters...$1,250 Now lets say 100,000 people receive your email ad and 1/10 % of the people responded, and you get half of the people to purchase. With a profit margin of $10 you earn $5000 Its that simple, now imagine if we used more emails here. Here are a few things that you'll be enjoying when you purchase. * A headache-free email promotion! * We handle all aspects of the mailing. * Access to our staff of marketing professionals that are eager to assist in growing your business! * Total protection for your ISP & Email account. We handle everything. * We Cater To Upscale Co's Only who know what they want. * Service you can rely on. Take Advantage Of Our Specials Now! call 1 708 562 8029 or reply to: zxcvb241@yemenmail.com **No Novices** *********************************************************** *********************************************************************** Per Section 301, Paragraph (a)(2)(C) of S.1618, further transmissions to you by the sender of this e-mail may be stopped at no cost to you by sending a remove request to 240xl1@yemenmail.com ************************************************************ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Sep 11 15:32: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 SMTP id PAA08412 for ; Mon, 11 Sep 2000 15:32:30 -0400 (EDT) Received: from standards (47.234.32.16:2354) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB920D7@standards.nortelnetworks.com>; Mon, 11 Sep 2000 15:17:09 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2917 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 11 Sep 2000 15:17:09 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB920D6@standards.nortelnetworks.com>; Mon, 11 Sep 2000 15:17: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 MAA03616 for ; Mon, 11 Sep 2000 12:30:22 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e8BJULQ30573 for ; Mon, 11 Sep 2000 12:30:21 -0700 X-Virus-Scanned: Mon, 11 Sep 2000 12:30:21 -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) smtpdvEcMA9; Mon, 11 Sep 2000 12:30:17 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: <39BD32CA.51AD0154@iprg.nokia.com> Date: Mon, 11 Sep 2000 12:30:18 -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] Revised RFC2002bis available To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello folks, During Last Call for RFC2002bis, I received comments requested some clarifications of the previous text. Here is the short list of what I have changed for revision ...-03.txt: - Added a separate item describing the reserved 'r' bit in the Agent Advertisement extension and the Registration Request message. - Changed "admissible authentication extension" to "authorization-enabling extension". This removes the ambiguity by which it might otherwise have been possible to interpret Mobile-Foreign or Foreign-Home authentication extensions as "inadmissible". The new draft is available on my web page, at: http://www.iprg.nokia.com/~charliep/txt/mobileip/mobileip.txt If there is anything else that needs to be changed before I send this revision in to the Internet Drafts directories, please let me know right away. I believe that these changes are minor enough that RFC2002bis could be considered as having finished working group Last Call, and thus be ready to be sent to the IESG, unless there are further changes that need to be made. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Sep 12 05:43: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 SMTP id FAA27887 for ; Tue, 12 Sep 2000 05:43:08 -0400 (EDT) Received: from standards (47.234.32.16:4981) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB924D0@standards.nortelnetworks.com>; Tue, 12 Sep 2000 5:27:38 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1219 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 12 Sep 2000 05:27:37 -0400 Received: from bells.cs.ucl.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB924CF@standards.nortelnetworks.com>; Tue, 12 Sep 2000 5:27:37 -0400 Received: from ginger.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 12 Sep 2000 10:40:12 +0100 X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: el, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39BDF9FA.7366AC7D@cs.ucl.ac.uk> Date: Tue, 12 Sep 2000 10:40:10 +0100 Reply-To: t.pagtzis@cs.ucl.ac.uk Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Theo PAGTZIS Organization: UCL Subject: Re: [MOBILE-IP] Re charter review X-To: "pcalhoun@eng.sun.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit "pcalhoun@eng.sun.com" wrote: > > Hi all > > > > There has not been not much discussion about about agent discovery recently. > > That is something i am quite puzzle when people are mentioning all sorts of > > fast handoff. > > > > How could one discuss fast handoff without discussing how much delay does > > agent discovery takes in place all sorts of environments. > > Bingo! That is the point that Jim and I have been making all this time, and > the reason why we designed the pro-active FA I-D. It takes time for a mobile > to detect that it has moved (using traditional Agent Advertisements), not to > mention the latency added by the registration process (regardless of how far > the registration request has to be sent). > > Pat Ditto...It is the same issue that I have been pondering about in my work as well as an old thread spawn in the past about proactive vs. reactive handoffs Theo From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Sep 12 06:58: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 SMTP id GAA29005 for ; Tue, 12 Sep 2000 06:58:02 -0400 (EDT) Received: from standards (47.234.32.16:4533) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB92528@standards.nortelnetworks.com>; Tue, 12 Sep 2000 6:42:38 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1332 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 12 Sep 2000 06:42:38 -0400 Received: from exnjus.trigyn.com (12.38.151.11:3127) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB92524@standards.nortelnetworks.com>; Tue, 12 Sep 2000 6:32:36 -0400 Received: from rajneesh (d330.pppdel.vsnl.net.in [202.54.14.30]) by exnjus.trigyn.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id SW4MBL1T; Tue, 12 Sep 2000 06:44:50 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: Date: Tue, 12 Sep 2000 16:15:02 +0530 Reply-To: Rajneesh Mittal Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Rajneesh Mittal Subject: [MOBILE-IP] Queries regarding "ISDN Q.921-User Adaptation Layer" document To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi all , There are some queries regarding the document ISDN Q.921-User Adaptation Layer authored by Sidebottom, Morneault et al. 1. How do we send NT(New Traffic) as the type value in ASPAC message ? Only two values have been mentioned in the type field on Page 19 viz Over ride and Loadshare . 2. Similar problem is with ASPIA as to how do we send GW(Graceful Withdrawal)in ASPIA message (Refer Page 20). Moreover the existing type values in ASPIA are over ride and loadshare which probably hold no significance as ASPIA is sent when ASP wants to withdraw and then there is no need of telling SG about the mode in which it operated. Or is it required for some reason ? Regards , Rajneesh Mittal , Senior Software Engineer, Empowertel Labs (India) Pvt Ltd. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Sep 12 07:09: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 SMTP id HAA29226 for ; Tue, 12 Sep 2000 07:09:27 -0400 (EDT) Received: from standards (47.234.32.16:4533) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB92542@standards.nortelnetworks.com>; Tue, 12 Sep 2000 6:45:42 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1334 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 12 Sep 2000 06:45:42 -0400 Received: from exnjus.trigyn.com (12.38.151.11:3210) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB92526@standards.nortelnetworks.com>; Tue, 12 Sep 2000 6:35:39 -0400 Received: from rajneesh (d330.pppdel.vsnl.net.in [202.54.14.30]) by exnjus.trigyn.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id SW4MBLFH; Tue, 12 Sep 2000 06:47:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: Date: Tue, 12 Sep 2000 16:18:11 +0530 Reply-To: Rajneesh Mittal Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Rajneesh Mittal Subject: [MOBILE-IP] Sorry for the faux pas To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit This was meant for Sigtran mailing list. Embarassed, Rajneesh . -----Original Message----- From: Rajneesh Mittal [mailto:rajneesh.mittal@trigyn.com] Sent: Tuesday, September 12, 2000 4:15 PM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Queries regarding "ISDN Q.921-User Adaptation Layer" document Hi all , There are some queries regarding the document ISDN Q.921-User Adaptation Layer authored by Sidebottom, Morneault et al. 1. How do we send NT(New Traffic) as the type value in ASPAC message ? Only two values have been mentioned in the type field on Page 19 viz Over ride and Loadshare . 2. Similar problem is with ASPIA as to how do we send GW(Graceful Withdrawal)in ASPIA message (Refer Page 20). Moreover the existing type values in ASPIA are over ride and loadshare which probably hold no significance as ASPIA is sent when ASP wants to withdraw and then there is no need of telling SG about the mode in which it operated. Or is it required for some reason ? Regards , Rajneesh Mittal , Senior Software Engineer, Empowertel Labs (India) Pvt Ltd. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Sep 12 07:09: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 SMTP id HAA29236 for ; Tue, 12 Sep 2000 07:09:29 -0400 (EDT) Received: from standards (47.234.32.16:4533) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9254D@standards.nortelnetworks.com>; Tue, 12 Sep 2000 6:46:32 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1335 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 12 Sep 2000 06:46:32 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB92527@standards.nortelnetworks.com>; Tue, 12 Sep 2000 6:36:31 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28521; Tue, 12 Sep 2000 06:49:48 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200009121049.GAA28521@ietf.org> Date: Tue, 12 Sep 2000 06:49: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-vendor-ext-11.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 Vendor/Organization-Specific Extensions Author(s) : G. Dommety, K. Leung Filename : draft-ietf-mobileip-vendor-ext-11.txt Pages : 4 Date : 11-Sep-00 This document proposes two new extensions to Mobile IP [1]. These extensions will facilitate equipment vendors and organizations to make specific use of these extensions as they see fit for research or deployment purposes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-vendor-ext-11.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-vendor-ext-11.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-vendor-ext-11.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: <20000911143303.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-vendor-ext-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-vendor-ext-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000911143303.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Sep 12 08:04: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 SMTP id IAA00930 for ; Tue, 12 Sep 2000 08:04:29 -0400 (EDT) Received: from standards (47.234.32.16:2435) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB92641@standards.nortelnetworks.com>; Tue, 12 Sep 2000 7:49:09 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1704 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 12 Sep 2000 07:49:09 -0400 Received: from ish7.ericsson.com.au (203.61.155.111:48127) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB92640@standards.nortelnetworks.com>; Tue, 12 Sep 2000 7:49:07 -0400 Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id WAA29648 for ; Tue, 12 Sep 2000 22:00: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 XAA05553 for ; Tue, 12 Sep 2000 23:02:04 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Tue, 12 Sep 2000 23:02:06 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C01CB1.453675C0" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A5089EB22D@eaubrnt018.epa.ericsson.se> Date: Tue, 12 Sep 2000 23:02:06 +1100 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: [MOBILE-IP] Drafts submitted 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_01C01CB1.453675C0 Content-Type: text/plain; charset="iso-8859-1" All, Yesterday I submitted the following two drafts: - draft-ietf-mobileip-hmipv6-00.txt This is a result from the merger of the original draft-soliman-mobileip-hmipv6-00.txt and draft-castellucia-mobileip-hmipv6-00.txt, this is the first revision and there will be at least one more before San Diego. Fast Handoffs were taken out of this draft as decided in Pittsburgh. - draft-elmalki-handoffsv6-00.txt This is a personal contribution and is NOT the outcome of the Fast Handoffs design team. This draft contains the Fast Handoff proposal that was first presented in Adelaide. Comments are welcome, Hesham ------_=_NextPart_001_01C01CB1.453675C0 Content-Type: text/html; charset="iso-8859-1" Drafts submitted

All,

Yesterday I submitted the following two drafts:

- draft-ietf-mobileip-hmipv6-00.txt

This is a result from the merger of the original
draft-soliman-mobileip-hmipv6-00.txt and
draft-castellucia-mobileip-hmipv6-00.txt, this is the
first revision and there will be at least one more before
San Diego. Fast Handoffs were taken out of this draft
as decided in Pittsburgh.

- draft-elmalki-handoffsv6-00.txt

This is a personal contribution and is NOT the outcome
of the Fast Handoffs design team. This draft contains the
Fast Handoff proposal that was first presented in Adelaide.


Comments are welcome,

Hesham

------_=_NextPart_001_01C01CB1.453675C0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Sep 12 09:36: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 SMTP id JAA03086 for ; Tue, 12 Sep 2000 09:36:18 -0400 (EDT) Received: from standards (47.234.32.16:1660) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB926D1@standards.nortelnetworks.com>; Tue, 12 Sep 2000 9:20:59 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1859 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 12 Sep 2000 09:20:59 -0400 Received: from mailbreak.com (216.207.225.170:1619) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB926B3@standards.nortelnetworks.com>; Tue, 12 Sep 2000 9:10:59 -0400 Received: from SOLID [166.84.159.26] by mailbreak.com [216.207.225.174] with SMTP (MDaemon.v2.84.R) for ; Tue, 12 Sep 2000 09:19:17 -0400 References: <39BDF9FA.7366AC7D@cs.ucl.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-MDaemon-Deliver-To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM X-Return-Path: eunsoo@mailbreak.com Message-ID: <040201c01cbc$eb122c40$6401a8c0@SOLID> Date: Tue, 12 Sep 2000 09:25:28 -0400 Reply-To: Eunsoo Shim Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Eunsoo Shim Subject: Re: [MOBILE-IP] Re charter review X-To: t.pagtzis@cs.ucl.ac.uk To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit I also agree that time to discover FA could be a significant part of hand-off time. Would Pat and Theo mind sending me any paper or documents describing your work and proactive and reactive handoffs? I'd appreciate any info about the issue. Thanks. Eunsoo ----- Original Message ----- From: "Theo PAGTZIS" To: Sent: Tuesday, September 12, 2000 5:40 AM Subject: Re: [MOBILE-IP] Re charter review > "pcalhoun@eng.sun.com" wrote: > > > > Hi all > > > > > > There has not been not much discussion about about agent discovery recently. > > > That is something i am quite puzzle when people are mentioning all sorts of > > > fast handoff. > > > > > > How could one discuss fast handoff without discussing how much delay does > > > agent discovery takes in place all sorts of environments. > > > > Bingo! That is the point that Jim and I have been making all this time, and > > the reason why we designed the pro-active FA I-D. It takes time for a mobile > > to detect that it has moved (using traditional Agent Advertisements), not to > > mention the latency added by the registration process (regardless of how far > > the registration request has to be sent). > > > > Pat > > Ditto...It is the same issue that I have been pondering about in my work as well > as an old thread > spawn in the past about proactive vs. reactive handoffs > > Theo > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Sep 12 10:21: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 SMTP id KAA04601 for ; Tue, 12 Sep 2000 10:20:58 -0400 (EDT) Received: from standards (47.234.32.16:4862) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB92730@standards.nortelnetworks.com>; Tue, 12 Sep 2000 10:05:37 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2024 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 12 Sep 2000 10:05:37 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9272F@standards.nortelnetworks.com>; Tue, 12 Sep 2000 10:05:37 -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 IAA28914; Tue, 12 Sep 2000 08:18:55 -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 HAA12679; Tue, 12 Sep 2000 07:18: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 HAA04143; Tue, 12 Sep 2000 07:18:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Tue, 12 Sep 2000 07:16:50 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: Re: [MOBILE-IP] Re charter review X-To: Eunsoo Shim To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <040201c01cbc$eb122c40$6401a8c0@SOLID> My proactive I-D is already available draft-calhoun-mobileip-proactive-fa-01.txt. Note, however, that the fast handoff design team is currently working on a solution at this time, and we expect to have something available for the WG soon. PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Sep 12 11:07: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 SMTP id LAA05937 for ; Tue, 12 Sep 2000 11:07:12 -0400 (EDT) Received: from standards (47.234.32.16:4862) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB927BD@standards.nortelnetworks.com>; Tue, 12 Sep 2000 10:51:44 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2204 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 12 Sep 2000 10:51:44 -0400 Received: from mailbreak.com (216.207.225.170:1933) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB927BC@standards.nortelnetworks.com>; Tue, 12 Sep 2000 10:51:44 -0400 Received: from SOLID [166.84.159.26] by mailbreak.com [216.207.225.174] with SMTP (MDaemon.v2.84.R) for ; Tue, 12 Sep 2000 11:00:41 -0400 References: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-MDaemon-Deliver-To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM X-Return-Path: eunsoo@mailbreak.com Message-ID: <045101c01ccb$14d7f510$6401a8c0@SOLID> Date: Tue, 12 Sep 2000 11:06:51 -0400 Reply-To: Eunsoo Shim Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Eunsoo Shim Subject: Re: [MOBILE-IP] Re charter review X-To: "pcalhoun@eng.sun.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit PatC, Unfortunately I could not find the draft in the mobile IP WG home page. Would you mind sending me a copy or a pointer to the document? Thanks. Eunsoo ----- Original Message ----- From: "pcalhoun@eng.sun.com" To: Sent: Tuesday, September 12, 2000 10:16 AM Subject: Re: [MOBILE-IP] Re charter review > My proactive I-D is already available > draft-calhoun-mobileip-proactive-fa-01.txt. Note, however, that the fast > handoff design team is currently working on a solution at this time, and we > expect to have something available for the WG soon. > > PatC > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Sep 12 11:14: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 SMTP id LAA06235 for ; Tue, 12 Sep 2000 11:14:36 -0400 (EDT) Received: from standards (47.234.32.16:4862) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB927D3@standards.nortelnetworks.com>; Tue, 12 Sep 2000 10:54:59 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2232 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 12 Sep 2000 10:54:59 -0400 Received: from mailbreak.com (216.207.225.170:1944) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB927D2@standards.nortelnetworks.com>; Tue, 12 Sep 2000 10:54:58 -0400 Received: from SOLID [166.84.159.26] by mailbreak.com [216.207.225.174] with SMTP (MDaemon.v2.84.R) for ; Tue, 12 Sep 2000 11:03:23 -0400 References: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-MDaemon-Deliver-To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM X-Return-Path: eunsoo@mailbreak.com Message-ID: <045c01c01ccb$7587b260$6401a8c0@SOLID> Date: Tue, 12 Sep 2000 11:09:33 -0400 Reply-To: Eunsoo Shim Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Eunsoo Shim Subject: Re: [MOBILE-IP] Re charter review X-To: "pcalhoun@eng.sun.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit PatC, Also may I ask a couple of questions? In reality or implementations, what is the time range of handoff using the current mobile IP spec? And what is the time range targeted at in the fast handoff design team? Thanks. Eunsoo ----- Original Message ----- From: "pcalhoun@eng.sun.com" To: Sent: Tuesday, September 12, 2000 10:16 AM Subject: Re: [MOBILE-IP] Re charter review > My proactive I-D is already available > draft-calhoun-mobileip-proactive-fa-01.txt. Note, however, that the fast > handoff design team is currently working on a solution at this time, and we > expect to have something available for the WG soon. > > PatC > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Sep 12 16:33:34 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13839 for ; Tue, 12 Sep 2000 16:33:33 -0400 (EDT) Received: from standards (47.234.32.16:2697) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB92A62@standards.nortelnetworks.com>; Tue, 12 Sep 2000 16:18:00 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3027 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 12 Sep 2000 16:18:00 -0400 Received: from qhars002.nortel.com (47.101.112.102:40628) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB92A40@standards.nortelnetworks.com>; Tue, 12 Sep 2000 16:08:00 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Tue, 12 Sep 2000 21:19:32 +0100 Received: from zsc4c002.corpwest.baynetworks.com by ertpg14e1.nortelnetworks.com; Tue, 12 Sep 2000 16:19:12 -0400 Received: from zbl6c008.corpeast.baynetworks.com ([132.245.205.58]) by zsc4c002.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id SQ9VC5PJ; Tue, 12 Sep 2000 13:19:05 -0700 Received: from mitton12.mediaone.net (MITTON12 [47.117.74.168]) by zbl6c008.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id RSQJ710Q; Tue, 12 Sep 2000 16:18:15 -0400 X-Sender: dmitton@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.3.2.7.2.20000912161740.00b078b0@pop.ne.mediaone.net> Date: Tue, 12 Sep 2000 16:18:01 -0400 Reply-To: Dave Mitton Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Dave Mitton Subject: [MOBILE-IP] test msg To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM ignore and delete dave@mitton.com http://www.dave.mitton.com/ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Sep 13 07:07: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 SMTP id HAA04391 for ; Wed, 13 Sep 2000 07:07:46 -0400 (EDT) Received: from standards (47.234.32.16:4828) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB92DB1@standards.nortelnetworks.com>; Wed, 13 Sep 2000 6:52:07 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4126 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 13 Sep 2000 06:52:07 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB92DAF@standards.nortelnetworks.com>; Wed, 13 Sep 2000 6:42:07 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03968; Wed, 13 Sep 2000 06:55:29 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200009131055.GAA03968@ietf.org> Date: Wed, 13 Sep 2000 06:55: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-elmalki-handoffsv6-00.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 MIPv6 Author(s) : K. Malki, H. Soliman Filename : draft-elmalki-handoffsv6-00.txt Pages : 9 Date : 12-Sep-00 This draft describes a method to achieve Fast Handoffs in Mobile IPv6. Fast Handoffs are required in Mobile IPv6 in order to limit the period of service disruption experienced by a wireless Mobile Node when moving between access routers. 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. Both flat and Hierarchical Mobile IPv6 models are considered. The Hierarchical MIPv6 mobility Management model in [1] already offers improvements to Mobile IP handoffs by providing a local Mobility Anchor Point (MAP) functionality. Some additions are made to the operation of this existing Hierarchical model to achieve Fast Handoffs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-elmalki-handoffsv6-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-elmalki-handoffsv6-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-elmalki-handoffsv6-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: <20000912130856.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-elmalki-handoffsv6-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-elmalki-handoffsv6-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000912130856.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Sep 14 05:14: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 SMTP id FAA07605 for ; Thu, 14 Sep 2000 05:14:21 -0400 (EDT) Received: from standards (47.234.32.16:2077) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB933C4@standards.nortelnetworks.com>; Thu, 14 Sep 2000 4:58:48 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6082 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Sep 2000 04:58:48 -0400 Received: from smtp1.cluster.oleane.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB933C3@standards.nortelnetworks.com>; Thu, 14 Sep 2000 4:58:48 -0400 Received: from oleane (dyn-1-1-077.Vin.dialup.oleane.fr [195.25.4.77]) by smtp1.cluster.oleane.net with SMTP id LAA40992 for ; Thu, 14 Sep 2000 11:12:41 +0200 (CEST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0038_01C01E3C.8A84BD80" 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: <003b01c01e2b$c74838c0$0401a8c0@oleane.com> Date: Thu, 14 Sep 2000 11:11:33 +0200 Reply-To: Peter Lewis Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Peter Lewis Subject: [MOBILE-IP] IP over DWDM 2000 international conference To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_0038_01C01E3C.8A84BD80 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable IP over DWDM 2000 international conference, Paris 27-30 November : This event aims at presenting an up-to-date state of the art in the = design of new Internet network architectures. It will be a unique = opportunity for researchers, network operators and service providers = from both the IP world and the optical networking world to discuss the = potentialities of all these promising perspectives.=20 http://www.upperside.fr/badwdm.htm ------=_NextPart_000_0038_01C01E3C.8A84BD80 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
IP over DWDM 2000 international conference, Paris 27-30 November = :
 
This event aims at presenting an up-to-date state of the art in the = design=20 of new Internet network architectures. It will be a unique opportunity = for=20 researchers, network operators and service providers from both the IP = world and=20 the optical networking world to discuss the potentialities of all these=20 promising perspectives.
 
http://www.upperside.fr/badwd= m.htm
 
 
------=_NextPart_000_0038_01C01E3C.8A84BD80-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Sep 14 09:37: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 SMTP id JAA11561 for ; Thu, 14 Sep 2000 09:36:55 -0400 (EDT) Received: from standards (47.234.32.16:4490) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB93489@standards.nortelnetworks.com>; Thu, 14 Sep 2000 9:20:30 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6323 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Sep 2000 09:20:30 -0400 Received: from ish7.ericsson.com.au (203.61.155.111:58325) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB93488@standards.nortelnetworks.com>; Thu, 14 Sep 2000 9:20:26 -0400 Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id XAA06079 for ; Thu, 14 Sep 2000 23:31:31 +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 AAA07918 for ; Fri, 15 Sep 2000 00:33:28 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Sep 2000 00:33:31 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C01E50.5F0F7780" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A5089EB251@eaubrnt018.epa.ericsson.se> Date: Fri, 15 Sep 2000 00:33:30 +1100 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: [MOBILE-IP] draft for WG consensus 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_01C01E50.5F0F7780 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C01E50.5F0F7780" ------_=_NextPart_001_01C01E50.5F0F7780 Content-Type: text/plain; charset="iso-8859-1" Hello Raj and Phil, As promised, I've attached a copy of the submitted draft for you to initiate the appropriate actions to see whether it should be a WG item. The draft is a merger of our initial proposal and INRIA's proposal that was presented in Pittsburgh. We believe the draft is technically stable and is within the charter's scope. The draft is not visible on the web, therefore I'm attaching it to this mail. I look forward to your comments. Regards, Hesham ------_=_NextPart_001_01C01E50.5F0F7780 Content-Type: text/html; charset="iso-8859-1" draft for WG consensus

Hello Raj and Phil,

As promised, I've attached a copy of the submitted
draft for you to initiate the appropriate actions
to see whether it should be a WG item.

The draft is a merger of our initial proposal and INRIA's
proposal that was presented in Pittsburgh. We believe the
draft is technically stable and is within the charter's
scope.

The draft is not visible on the web, therefore I'm attaching it
to this mail.

I look forward to your comments.

Regards,

Hesham

  ------_=_NextPart_001_01C01E50.5F0F7780-- ------_=_NextPart_000_01C01E50.5F0F7780 Content-Type: text/plain; name="draft-ietf-mobileip-hmipv6-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-mobileip-hmipv6-00.txt" Content-Transfer-Encoding: quoted-printable Network Working Group Hesham Soliman, = Ericsson INTERNET-DRAFT Claude Castellucia, = INRIA Expires: February 2001 Karim El-Malki, = Ericsson Ludovic Bellier, = INRIA September, = 2000 Hierarchical MIPv6 mobility management 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 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 cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This draft introduces some extensions for MIPv6 and neighbour discovery to allow for the introduction of a hierarchical MIPv6 mobility management model. The proposed hierarchical mobility management for MIPv6 will reduce the amount of signalling to CNs and the HA and may also improve the performance of MIPv6 in terms of handoff speed. Moreover, HMIPv6 is well-suited to implement access control and handoffs between different access technologies. Soliman, Casteluccia, El-Malki, Bellier [Page = 1] =0C INTERNET-DRAFT HMIPv6 = ****,2000 TABLE OF CONTENTS 1. Introduction.............................................3 3. Hierarchical Mobility Management using MIPv6.............5 4. Overview of the MIPv6 Hierarchical Mobility Management...6 5. Neighbour Discovery extension - MAP discovery............9 6. MIPV6 extensions - Sending Binding Updates..............10 7. MN Operation............................................11 7.1 MAP Discovery...........................................11 7.2 Sending Binding Updates.................................12 7.3 Receiving packets in a foreign network..................12 7.4 Fast Handoff scenario...................................13 8. MAP Operation...........................................14 8.1 MAP Discovery..................................._.......14 8.2 Receiving and forwarding Packets for a MN...............14 8.3 Fast handoff scenario...................................15 9. HA Operation............................................15 10. AAA Considerations for IPv6.............................16 11. Acknowledgements........................................16 12. Notice Regarding Intellectual Property Rights...........16 13. References..............................................17 14. Authors' addresses......................................17 Soliman, Casteluccia, El-Malki, Bellier [Page = 2] =0C INTERNET-DRAFT HMIPv6 = ****,2000 1. Introduction This draft introduces the concept of a Hierarchical Mobile IPv6 network, utilizing a new node called the Mobility Anchor Point = (MAP). In Mobile IPv6 there are no Foreign Agents, but there is still the need to provide a central point to assist with MIP handoffs. Similarly to MIPv4, Mobile IPv6 can benefit from reduced mobility signalling with external networks by employing a regional hierarchical structure. For this reason a new Mobile IPv6 node, called the Mobility Anchor Point (MAP), is used and can be located = at any level in a hierarchical Mobile IPv6 network including the Access Router (AR). Unlike FAs in IPv4, a MAP is not required on each subnet. Two different options are proposed in this memo for the use of a MAP. A MN may use the MAP as an alternate-care-of address (COA) or form a Regional COA (RCOA) on the MAP's subnet while roaming within a hierarchical (MAP) domain, where such a domain involves all access routers advertising that MAP. The two options are described = in detail in chapters 4.1 and 4.2. The MAP will limit the amount of Mobile IPv6 signalling outside the domain and will support Fast Handoffs to help Mobile Nodes in achieving seamless mobility. Other advantages of the introduction of the MAP functionality are covered in chapter 3. This draft assumes the generic case of scaleable multi-level Hierarchical Mobile IP (HMIP) networks and is therefore applicable = to HMIP networks in general. Hierarchical MIPv6 (HMIPv6)can assist with speeding up MIP Handoffs, hence offering advantages which are especially important for the support of real-time services. 3. Hierarchical Mobility Management using MIPv6 The aim of introducing the hierarchical mobility management model in MIPv6 is to enhance the network performance while minimising the impact on MIPv6 or other IPv6 protocols. This is achieved by using the MIPv6 protocol combined with layer 2 features to manage both IP micro and macro mobility, leading to rationalisation and less = complex implementations in the MN and other network nodes. This hierarchical MIPv6 scheme introduces a new function, the Mobility Anchor Point (MAP), and minor extensions to the MN and the Home Agent operations. The CN operation will not be affected. The introduction of the MAP concept minimises the latency due to handoffs between access routers. Furthermore, the addition of bicasting to a MAP allows for Fast Handoffs [5] which will minimise the packet losses due to handoffs and consequently improve the throughput of best effort services and performance of real time data services over the radio interface. Just like MIPv6, this solution is independent of the underlying access technology, allowing Fast Soliman, Casteluccia, El-Malki, Bellier [Page = 3] =0C INTERNET-DRAFT HMIPv6 = ****,2000 Handoffs within, or between, different types of access networks. Furthermore, a smooth architectural migration can be achieved from Hierarchical MIPv4 networks, since a dual operation of IPv4 and IPv6 Hierarchies will be possible making use of the similarity in architecture. The introduction of the MAP concept will further diminish signalling generated by MIPv6 over the radio interface. This is due to the fact that a MN only needs to perform one regional update (MAP) when changing its layer 3 access point within the MAP domain.The advantage can be easily seen when compared to other scenarios (no MAP) where at least two BUs (Binding Updates) will be sent (to one CN and HA). A MAP may also interact with the AAA protocol to perform key distribution during handoffs and eliminate the need for re- authentication as explained in ch 10. 4. Overview of the MIPv6 Hierarchical Mobility Management In order to introduce hierarchical mobility management in MIPv6, the protocol is extended with a new function. The proposed new functionality is the Mobility Anchor Point (MAP). It simply provides an optional mobility management function that can be located at any level in the hierarchy starting from the access router upwards. The MAP may be used by a MN as an alternate-COA [1] while roaming within a certain MAP domain. Alternatively, the MN MAY choose to use a Regional Care of Address (RCOA) on the MAP's subnet as its own COA while roaming within a MAP's domain. In the latter case, a MAP acts essentially as a local Home Agent (HA) for the MN. A MAP domain's boundaries are defined by the Access Routers (ARs) advertising the MAP information to the attached Mobile Nodes. The control of a MAP's mode of operation (as an alternate-CoA or a local HA) is left to the network administrator's discretion. When the MAP is used as an alternate COA, the MAP will receive all packets on behalf of the MN and will encapsulate and forward them directly to the MN's current address. If the MN changes its current address within a regional MAP domain, it needs to register the new address with the MAP. This makes the MN's mobility transparent to = the CNs it is communicating with. The MAP can also be used to execute a Fast Handoff between ARs as explained in [5]. The detailed extensions to MIPv6 and operations of the different nodes will be explained later in this document. Although the proposed method is independent of the network topology, it is best suited to a hierarchical network or one with multi-access technologies. It should be noted that the MAP concept is simply an extension to the MIPv6 protocol. Hence a MAP-aware MN with an implementation of MIPv6 MAY choose to use the MAP or simply use the Soliman, Casteluccia, El-Malki, Bellier [Page = 4] =0C INTERNET-DRAFT HMIPv6 = ****,2000 standard MIPv6 implementation as it sees fit. Furthermore, a MN can at any time stop using the MAP. This provides great flexibility, = both from a MN or a network operations point of view. The network architecture shown below illustrates an example of the use of the MAP in a foreign domain. _______ | HA | |_______| _______ \ | CN | \ |_______| \___ | \ | \ ____| _\___|_ | | | MAP | |_______| / \ / \ / \ / \ ____/____ \_________ | | | | | AR1/MAP | | AR2/MAP | |_________| |_________| | | | | __\/____ \/ | | | MN | |________| __________________\ Movement / Figure 1: Hierarchical MIPv6 domain In Figure 1, the MAP can help in providing seamless mobility for the MN as it moves from Access Router 1 (AR1) to Access Router 2 (AR2), while communicating with the CN. It is possible to use multi-level hierarchies of routers and implement MAP functionality in AR1 and = AR2 if needed. It should be noted that AR1 and AR2 could be two points = of attachment in the same RAN (Radio Access Network) or in different RANs. Upon arrival in a foreign domain, the MN will discover the global address of the MAP. This address is stored in the Access Routers and communicated to the MN via Router Advertisements. The discovery phase will also inform the MN of the distance of the MAP from the = MN. Soliman, Casteluccia, El-Malki, Bellier [Page = 5] =0C INTERNET-DRAFT HMIPv6 = ****,2000 For example, the MAP could also be implemented in AR1 and AR2, in which case the MN can choose the first hop MAP, second hop MAP, or both. A Router advertisement extension is proposed later in this document for MAP discovery. Other service discovery methods may also be used for the same purpose. If a router advertisement is used for MAP discovery, as described in this document, all ARs belonging to the MAP domain MUST advertise the MAP's IP address. The same concept should be used if other methods of MAP discovery are introduced. The MAP option in the router advertisement should inform the MN = about the chosen mode of operation for the MAP. The process of MAP discovery continues as the MN moves from one subnet to the next. As the MN roams within a MAP's domain, the same information announcing the MAP should be received. If a change in = the advertised MAP's address is received, the MN should act on the = change by sending the necessary Binding Updates to its HA and CNs. If the MN is not MAP-aware then the discovery phase will fail resulting in the MN using the MIPv6 [1] protocol for its mobility management. On the other hand, if the MN is MAP-aware it MAY choose to use the MAP implementation. If so, the MN will first need to register with a MAP by sending it a BU containing its Home Address and current address. In the case where the MN uses the MAP as an alternate-COA, the Home address used in the BU is the MNs Home Address on its home subnet. On the other hand, if the MN is using a RCOA, the Home address used in the BU is the RCOA. The MAP MUST = store this information in its Binding Cache to be able to forward packets to their final destination when received from the different CNs or HAs. The MN will always need to know the original sender of any received packets. Since all packets will be tunnelled by the MAP, the MN is not always able to determine whether the packets were originally tunnelled from the Home Agent or received directly from a CN. This knowledge is needed by the MN to decide whether a BU needs to be = sent to a CN in order to initiate route optimisation. For this purpose a check needs to be performed on the internal packet's routing header to find out whether the packet was tunnelled by the HA or originated from a CN using route optimisation instead. If a routing header exists in the internal packet, containng its alternate-COA (MAP address or RCOA) and the MN's Home Address as the final destination, then route optimisation was used. Otherwise, triangular routing through the HA was used. To use the network bandwidth in a more efficient manner, a MN may decide to register with more than one MAP simultaneously and use = each MAP address for a specific group of CNs. For example, in Fig 1, if the CN happens to exist on the same link as the MN, it would be more efficient to use the first hop MAP (in this case assume it is AR1) Soliman, Casteluccia, El-Malki, Bellier [Page = 6] =0C INTERNET-DRAFT HMIPv6 = ****,2000 for communication between them. This will avoid sending all packets via the "highest" MAP in the hierarchy and hence result in a more efficient usage of network bandwidth. The MN can use its current address as a COA as well. 4.1 Using a MAP's address as a COA Using a MAP as an alternate-COA may be a useful tool for some mobility scenarios. In the case where a MN is also a router to which several MN's may be connected (eg. a Personal Area Network), it = would not be possible for such router to obtain a new network prefix = within a visited network. Hence, MNs connected to such router will end up with topologically incorrect addresses. By having the mobile router act as a MAP within the visited network, MNs connected to it may use it as an alternate-COA when registering with their HA and other CNs. Hence, maintaining the IPv6 powerful aggregation of routes witihn = the backbone. In this case the MAP option will be advertised by the AR that the MN is connected to. The MN SHOULD send a BU to the HA and CNs including the MAP's address as an alternate-COA. Hence all packets addressed = to the MN will be sent through the MAP's address as specified by the MN in its BU. The MAP will (acting like a HA) tunnel the packets addressed to the MN to its current address. The details of the MAP operation will be given later in this document. The Home Address contained in the MAP registration MUST be the same Home Address sent in the Home Agent registration. If a MN sends different BU's for different Home Addresses (in the case it has multiple Home Addresses), the same process MUST be performed for the MAP registrations. This is essential to allow a MAP to forward packets to the right COA when they are tunnelled from the HA. The MN SHOULD also have a prefix length of 128 in its BUs to the HA. This would stop the HA from being proxy for other unregistered Home addresses. The MAP will need to know how the final destination in the packet corresponds to the registered address of a MN. This should be = obvious when the packets are sent from a CN to the global Home Address of = the MN or to the COA with a routing header. However, if the HA tunnels packets with addresses other than the MN's Home Address (eg. Site- local), of which the MAP would have no knowledge, the HA MUST add a routing header to the outer packet. This routing header must use one of the MN's registered Home Addresses as the final destination. This will enable the MAP to tunnel the packet to the correct destination (i.e. the MN's current address). 4.2 Using a Regional COA (RCOA) on a MAP's subnet Soliman, Casteluccia, El-Malki, Bellier [Page = 7] =0C INTERNET-DRAFT HMIPv6 = ****,2000 In this scenario, the MN would have two addresses, a RCOA on the MAP's subnet and an on-link COA (LCOA). This RCOA is formed in a stateless manner by combining the MAP's subnet prefix received in = the MAP option with the MNs interface identifier. After forming the RCOA, the MN sends a BU to the MAP. The BU will bind the RCOA (similar to a Home Address) to its LCOA. The BU MUST have both the A and D flags set. The MAP (acting as a HA) will then perform DAD for the MN's RCOA on its subnet. If successful, the MAP will return a Binding Acknowlegement (BAck) to the MN indicating a successful registration. Otherwise, the MAP MUST return a BAck with the appropriate fault code. No new error codes are needed for this operation. The MAP will receive packets addressed to the MN's RCOA (from the HA or CNs). Packets will be tunnelled from the MAP to the MN's LCOA. = The MN will decapsulate the packets and process the packet in the normal manner. 5. Neighbour Discovery extension - Dynamic MAP discovery The process of MAP discovery can be performed in many different = ways. In this document, router advertisements are used for the discovery phase by introducing a new option. The access router is required to send the MAP option in all router advertisements. This option includes the distance from the MN in terms of number of hops, the preference for this particular MAP and the MAP's global IP address. The ARs can be configured manually or automatically with this information. In the case of automatic configuration, each MAP in the network needs to be configured with a default preference, the right interfaces to send this option on and, if necessary, the IP address to be sent. The initial value of the "Distance" field MUST be set to a value of one. Upon reception of a router advertisement with the = MAP option, given that a router is configured to resend this option on certain interfaces, the router MUST copy the option and resend it after incrementing the Distance field by one. If the router was also a MAP, it SHOULD send its own option in the same advertisement. In this manner information about a MAP at a certain level in a = hierarchy can be dynamically passed to a MN. Furthermore, by performing the discovery phase in this way, different MAP nodes are able to change their preferences dynamically based on the local policies, node overload or other load sharing protocols being used. The following figure illustrates the new MAP option. 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 | Distance | Pref | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Plen |R|M| Reserved | Soliman, Casteluccia, El-Malki, Bellier [Page = 8] =0C INTERNET-DRAFT HMIPv6 = ****,2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix / Global IP Address for MAP + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The alignment requirements for this option is 8n. Fields: Type Message type. To be assigned. Length 8-bit unsigned integer. The length of the option (including the type and length fields) in units of 8 octets. The value 0 is = invalid. Nodes MUST silently discard an ND packet that contains an option with length zero. Distance An 8 bit unsigned integer showing the = distance from the receiver of the advertisement. It MUST be set to one in the initial Advertisement, if dynamic MAP discovery is used. Pref The preference of this MAP. An 8 bit unsigned integer. A value of 255 means lowest preference. Plen The prefix length in this option. A prefix length value of 128 indicates that the MAP option contians the MAP's IP address. R Indicates that the MN MUST form a RCOA M Indicates that the MN MUST use the MAP's Own IP address as an alternate-COA Global Address One of the MAP's global addresses. To ensure a secure communication between routers, router advertisements containing the MAP option SHOULD be authenticated by AH. In the case where this authentication is not possible, a network operator may prefer to manually configure all the ARs to send the = MAP option. Soliman, Casteluccia, El-Malki, Bellier [Page = 9] =0C INTERNET-DRAFT HMIPv6 = ****,2000 6. MIPV6 extensions - Sending Binding Updates This section outlines the extensions proposed to the BU option used by the MN in MIPv6. A new flag is added: the M flag that indicates MAP registration. When a MN registers with the MAP, the M flag MUST be set to distinguish this registration from a Home Registration or = a BU being sent to a CN. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|R|D|M| Res | Prefix Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Options... +-+-+-+-+-+-+-+-+-+-+-+- Description of extensions to the BU option: M If set indicates a MAP registration. Res 3 bit reserved field 7. MN OPERATION This section is concerned with the extensions to the MN's operation in a foreign network due to the introduction of the MAP. Unless otherwise specified, the normal MN operation in [1] applies. 7.1 MAP discovery When a MAP-aware MN receives a router advertisement, it should = search for the MAP option. One or more options may be found for different = IP addresses or subnet prefixes. A MN SHOULD register with the MAP having the lowest preference = value. A MAP with a preference value of 255 SHOULD not be used in the MAP registration. A MN MAY however choose to register with one MAP = rather than another depending on the value received in the Distance field, as long as the preference value is below 255. A MN SHOULD store the received option(s) and choose at least one MAP to register with. Storing the options is essential as they will be compared to other options received later for the purpose of the move detection algorithm. Soliman, Casteluccia, El-Malki, Bellier [Page = 10] =0C INTERNET-DRAFT HMIPv6 = ****,2000 If no MAP options are found in the router advertisement, the MN MUST use the MIPv6 protocol as specified in [1]. If the MN receives a duplicated MAP option ( having the same IP address or prefix) with different preference values or Distance values, the MAP IP address SHOULD not be used as an Alternate-COA in any BU's sent by the MN. Finally if the M flag is set in the MAP option, the MN MUST register with the MAP and inform its HA. A MN MAY choose to register with more than one MAP simultaneously or use both MAP address and its own address as COAs simultaneously with different CNs. 7.2 Registration with the MAP - Sending Binding Updates After MAP discovery has taken place, a MN can register with one or more MAPs. The MN performs this regional registration by sending a = BU to the MAP with the appropriate flags set. The contents of the BU will depend on the MAP's mode of operation. When registering with a MAP, the A flag SHOULD be set and the M flag MUST be set in the BU. The H flag MUST not be set when registering with a MAP. A MN SHOULD wait for a BAck (Binding Acknowledgement) from the MAP before using the MAP address or a RCOA from the MAP's subnet as an alternate COA in its BUs. After successfully performing registration with a MAP, a MN can = start sending BUs, with it's Alternate-COA,to CNs and its HA. The MAP's = IP address or RCOA MUST be included in the Alternate-COA sub-option. If the MN uses a MAP's address as an alternate-COA, then for each home address registration sent to the HA with a MAP's address as the COA, a BU MUST be sent to the same MAP using the same home address. The MN SHOULD send a separate home registration BU for each home address, with the prefix length value set to 128. This stops the HA from forming home addresses for that MN on each link that the HA is connected to, thus ensuring consistency in the Binding Caches of = both the MAP and HA for the MN. 7.3 Receiving packets in a foreign network When in a foreign network, a MN needs to know which path a packet = has taken from the CN to the MN. That is, whether triangular routing was used via the HA or route optimisation was used. When using HMIPv6, all packets received from a CN will be tunnelled by the MAP to the MN. When using the MAP's address as a COA, packets tunnelled by the HA to the MAP will be decapsulated and then encapsulated again with the MAP's address as the source address. Soliman, Casteluccia, El-Malki, Bellier [Page = 11] =0C INTERNET-DRAFT HMIPv6 = ****,2000 Therefore a check on whether the packet was tunnelled by the HA will not be sufficient to decide whether route optimisation is required. Hence, a generic check for the existence of a routing header in the encapsulated packet (i.e. with CN as source address), where the MN's home address is the final address, will be sufficient to determine whether the path was route optimised or not. If the routing header does not exist, the MN SHOULD send a BU with the appropriate information to initiate route optimisation. It should be noted that such check is generic and would work for all the various use cases of MIPv6 including the different MAP modes of operation in this memo. 8. MAP Operation 8.1 MAP Discovery As mentioned previously, the MAP discovery is done via router advertisements having the new MAP option added. A MAP will be configured to send its option or relay other MAPs' options on = certain interfaces. The choice of interfaces is done by the network operator and depends on the network architecture. A default preference value should be assigned to each MAP. It should be noted that a MAP can change its preference value at any time due to various reasons (e.g. node overload or load sharing). A preference value of 255 means that the MAP SHOULD not be chosen by a MN. This value could be reached in cases of node overload or node failures. The MAP option is propagated down the hierarchy. Each router along the path to the access router will increment the Distance field. If = a router that is also a MAP receives advertisements from other MAPs, = it SHOULD add its own MAP option and propagate both options to the next level in the hierarchy. 8.2 Receiving and forwarding Packets for a MN The MAP operation is in many ways similar to the HA operation described in [1] with some modifications. Upon reception of a BU = from a MN with the M flag set, and provided it is allowed to accept this message (i.e. no local policy restrictions) the MAP MUST process the BU and if successful, add the information to its Binding Cache. The MAP will need to determine how it should act based on the information given in the BU. Two different modes of operation are described below. 8.2.1 Using a MAP's address as a COA Soliman, Casteluccia, El-Malki, Bellier [Page = 12] =0C INTERNET-DRAFT HMIPv6 = ****,2000 In this scenario, the BU from the MN will contain its LCOA as a source address and its Home address. A MAP MUST first check if the = MN is authorised to use the MAP in this mode. If so, the MAP SHOULD process the BU in the normal manner. If the A flag was set, the MAP MUST send a BAck to the MN. All packets directed to the MN will be received by the MAP and tunnelled to the MN. Upon reception of an encapsulated packet with = no routing header in the outer packet, the packet is decapsulated in = the normal way. If the inside packet contains a destination address that doesn't belong to the MAP, the MAP should check its Binding Cache to see if the address belongs to any of its registered MN's. If it = does, the packet MUST be tunnelled to the MN's current address. Otherwise, the packet is processed in the normal way. If the encapsulated packet contains a routing header in the outer packet containing the MN's home address as the next destination, the MAP MUST process the routing header in the normal way, then tunnel the packet to the MN's current address. 8.2.2 Using a RCOA on the MAP's subnet In this scenario, a MAP would have no knowledge of the MN's Home address. The MN will send a BU to the MAP with the M, A and D flags set. The aim of this BU is to inform the MAP that the MN has formed = a RCOA (contained in the BU as a Home address) and request that a MAP performs DAD on its behalf. This is identical to the HA operation in [1]. If the operation was successful, the MAP MUST respond with a BAck to the MN indicating a successful operation. Otherwise a BAck = is sent with the appropriate error code. No new error codes are introduced for HMIPv6. 8.3 The MAP as a Mobile Router (MR) In the case where a Mobile Router (MR) is located in a foreign network, the MR will not be able to obtain a new network prefix for the MNs attached to it. Hence, the MR MUST act as a MAP and = advertise the MAP option to the MNs attached to it. The MAP option MUST have the M flag set to ensure that the MNs register with it. This will allow the MNs to be reachable without advertising host specific routes to other routers within the network. This approach maintains IPv6 route aggregation and ensures that no additional routing table entries are required due to the MR's network mobility. 9. HA Operation The Home Agent operations are affected in a minor way by the introduction of the MAP. The only impact due to HMIPv6 on the HA implementation is that when tunnelling packets to the MN with destination addresses other than the addresses registered by the MN Soliman, Casteluccia, El-Malki, Bellier [Page = 13] =0C INTERNET-DRAFT HMIPv6 = ****,2000 in its Home Registration, the HA MUST include a routing header in the outer packet with the MN's registered home address as the final destination. This is done to enable the MAP to find the right routing entry for the MN, since it has no knowledge of a non-unicast global home address for the MN. 10. AAA Considerations for IPv6 The MAP can be utilised to perform access control on MNs and may interact with the protocol which will be defined for AAA in IPv6. = The MAP can speed up a handoff by having the MN's security credentials which will allow it to verify whether a certain node is allowed access to the network. This allows greater efficiency in = distributing keys only to certain nodes in the network. One example of the interaction between a MAP and the AAA infrastructure can be seen when considering the handoff scenario. A MAP can store the MN's security credentials after the MN is allowed network access by the AAA infrastructure. During an intra-domain handoff, the MAP could pass the MN's secrity credentials to the = "new" AR to avoid performing the AAA process. These credentials depend on the access enforcement policies in AAAv6 and will not be covered by this draft. 11. Acknowledgements The authors would like to thank Conny Larsson (Ericsson) and Mattias Pettersson (Ericsson) for their valuable input to this draft. In addition, the authors would like to thank the following members = of the working group in alphabetical order: Eva Gustaffson (Ericsson), Dave Johnson (Rice University), Annika Jonsson (Ericsson), Fergal Ladley (Ericsson) and Erik Nordmark (Sun) for their comments on the draft. 12. Notice Regarding Intellectual Property Rights Ericsson may seek patent or other intellectual property protection for some or all of the technologies disclosed in this document. If any standards arising from this disclosure are or become protected = by one or more patents assigned to Ericsson, Ericsson intends to disclose those patents and license them on reasonable and non- discriminatory terms. Future revisions of this draft may contain additional information regarding specific intellectual property protection sought or received. 13. References [1] D. Johnson and C. Perkins, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-12.txt, February 2000. Soliman, Casteluccia, El-Malki, Bellier [Page = 14] =0C INTERNET-DRAFT HMIPv6 = ****,2000 [2] E. Gustafsson, A. Jonsson and C. Perkins, " Mobile IP Regional Tunnel Management ", draft-ietf-mobileip-reg-tunnel-02.txt (work in progress), March 2000. [3] C. Perkins, Editor. "IP Mobility Support", RFC 2002, October 1996. [4] K. El Malki and H. Soliman " Fast Handoffs in Mobile IPv4". (work in progress) [5] K. El Malki and H. Soliman " Fast Handoffs in Mobile IPv6". draft-elmalki-handoffsv6-00.txt (work in progress) 14. Appendix A: Planned additions to future revisions In addition to the existing proposal, the following sections are planned for future revisions: - MAP discovery. Other ways for dynamic MAP discovery are being investigated. The reuse of Router renumbering has been suggested and if suited, it may be included in the next revision. - quick discovery of MAP failures will be essential for the reliability of this mechanism. Some suggestions for handling these scenarios will be included in future revisions. - Detailed notes for implementors will also be added. 15. Authors' Addresses The working group can be contacted via the current chairs: Basavaraj Patil Phil Roberts Nokia Corporation Motorola M/S M8-540 6000 Connection Drive 1501 West Shure Drive Irving, TX 75039 Arlington Heights, IL 60004 USA USA Phone: +1 972-894-6709 Phone: +1 847-632-3148 EMail: Raj.Patil@nokia.com EMail: QA3445@email.mot.com Fax : +1 972-894-5349 Questions about this memo can also be directed to: Hesham Soliman Ericsson Australia 61 Rigall St., Broadmeadows Melbourne, Victoria 3047 AUSTRALIA Soliman, Casteluccia, El-Malki, Bellier [Page = 15] =0C INTERNET-DRAFT HMIPv6 = ****,2000 Phone: +61 3 93012049 Fax: +61 3 93014280 E-mail: Hesham.Soliman@ericsson.com.au Claude Castelluccia INRIA Rhone-Alpes 655 avenue de l'Europe 38330 Montbonnot Saint-Martin France email: claude.castelluccia@inria.fr phone: +33 4 76 61 52 15 fax: +33 4 76 61 52 52 Karim El Malki Ericsson Radio Systems AB Access Networks Research SE-164 80 Stockholm SWEDEN Phone: +46 8 7573561 Fax: +46 8 7575720 E-mail: Karim.El-Malki@era.ericsson.se Ludovic Bellier INRIA Rhone-Alpes 655 avenue de l'Europe 38330 Montbonnot Saint-Martin France email: ludovic.bellier@inria.fr phone: +33 4 76 61 52 15 fax: +33 4 76 61 52 52 Soliman, Casteluccia, El-Malki, Bellier [Page = 16] =0C ------_=_NextPart_000_01C01E50.5F0F7780-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Sep 14 09:59: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 SMTP id JAA12189 for ; Thu, 14 Sep 2000 09:59:42 -0400 (EDT) Received: from standards (47.234.32.16:4490) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB93524@standards.nortelnetworks.com>; Thu, 14 Sep 2000 9:44:15 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6441 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Sep 2000 09:44:14 -0400 Received: from mail.kpnqwest.ch (mail.eunet.ch) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB934E5@standards.nortelnetworks.com>; Thu, 14 Sep 2000 9:34:13 -0400 Received: from oettinger.davidoff.ch ([195.49.110.243]) by mail.kpnqwest.ch (8.9.3/1.34) via ESMTP id NAA29142 for ; Thu, 14 Sep 2000 13:47:36 GMT env-from (vdfvoi@mail.computrain.de) Received: from mail.mindspring.com by oettinger.davidoff.ch via SMTP id smtp\t9eek053.in; 14 Sep 2000 14:56:00 +0200 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <253.292988.409864@mail.mindspring.com> Date: Thu, 14 Sep 2000 09:44:14 -0400 Reply-To: vdfvoi@MAIL.COMPUTRAIN.DE Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: vdfvoi@MAIL.COMPUTRAIN.DE Subject: [MOBILE-IP] To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit GET YOUR OWN 100 MEG WEBSITE FOR ONLY $11.95 PER MONTH TODAY! STOP PAYING $19.95 or more TODAY for your web site, WHEN YOU CAN GET ONE FOR ONLY $11.95 PER MONTH! DO YOU ALREADY HAVE A WEBSITE? ALL YOU HAVE TO DO IS TRANSFER THE DOMAIN TO OUR SERVERS AND UPLOAD YOUR DATA AND YOU ARE READY TO GO! YOUR NEW WEB SPACE CAN BE CREATED INSTANTLY WITH JUST A SIMPLE PHONE CALL TO OUR OFFICE. YOU CAN CHANGE THE DESIGN OF YOUR SITE AS MUCH AS YOU WANT with no extra charge! UNLIMITED TRAFFIC -- no extra charge! FRONT PAGE EXTENSIONS are FULLY SUPPORTED. A SET UP FEE OF $40.00 APPLIES for FIRST TIME CUSTOMERS. ALL FEES PREPAID IN ADVANCE FOR THE YEAR PLUS A $40.00 SET UP CHARGE. FOR DETAILS CALL 1 888 248 0765 Webhosting International From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Sep 14 10:09: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 SMTP id KAA12507 for ; Thu, 14 Sep 2000 10:09:28 -0400 (EDT) Received: from standards (47.234.32.16:4490) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9353F@standards.nortelnetworks.com>; Thu, 14 Sep 2000 9:46:35 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6545 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Sep 2000 09:46:34 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9353E@standards.nortelnetworks.com>; Thu, 14 Sep 2000 9:46:34 -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 HAA05866 for ; Thu, 14 Sep 2000 07:59:57 -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 GAA00067; Thu, 14 Sep 2000 06:59:56 -0700 (PDT) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id GAA27131; Thu, 14 Sep 2000 06:59:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Thu, 14 Sep 2000 06:58:07 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: Re: [MOBILE-IP] draft for WG consensus X-To: "Hesham Soliman (EPA)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <4B6BC00CD15FD2119E5F0008C7A419A5089EB251@eaubrnt018.epa.ericsson.se> Hesham, Glad to see the merged proposals. However, the table of contents contains many sections that I cannot seem to find in the actual document (e.g. fast handoff). Is the table of contents, or the text, incorrect? PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Sep 14 10:11: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 SMTP id KAA12644 for ; Thu, 14 Sep 2000 10:11:53 -0400 (EDT) Received: from standards (47.234.32.16:4490) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB935BE@standards.nortelnetworks.com>; Thu, 14 Sep 2000 9:56:21 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6716 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Sep 2000 09:56:21 -0400 Received: from ish7.ericsson.com.au (203.61.155.111:58685) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB935BC@standards.nortelnetworks.com>; Thu, 14 Sep 2000 9:56:19 -0400 Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id AAA06942; Fri, 15 Sep 2000 00:07:24 +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 BAA10639; Fri, 15 Sep 2000 01:09:22 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Sep 2000 01:09:25 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C01E55.62CBA2E0" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A5089EB253@eaubrnt018.epa.ericsson.se> Date: Fri, 15 Sep 2000 01:09:24 +1100 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] draft for WG consensus X-To: "pcalhoun@eng.sun.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_01C01E55.62CBA2E0 Content-Type: text/plain; charset="iso-8859-1" Pat, Glad to see the merged proposals. However, the table of contents contains many sections that I cannot seem to find in the actual document (e.g. fast handoff). Is the table of contents, or the text, incorrect? => oops ! Fast Handoffs were removed from the draft and are in a separate one :draft-elmalki-handoffsv6 ... So I forgot to update the table of contents. I can do that once we agree on one way or another for the draft. There is also a new section (8.3) titled :MAP as a Mobile Router and again I didn't update the table of contents. thanks, Hesham ------_=_NextPart_001_01C01E55.62CBA2E0 Content-Type: text/html; charset="iso-8859-1" RE: [MOBILE-IP] draft for WG consensus

Pat,

Glad to see the merged proposals. However, the table of contents contains many
sections that I cannot seem to find in the actual document (e.g. fast
handoff). Is the table of contents, or the text, incorrect?

=> oops ! Fast Handoffs were removed from the draft and are
in a separate one :draft-elmalki-handoffsv6 ...
So I forgot to update the table of contents. I can do that
once we agree on one way or another for the draft.

There is also a new section (8.3) titled :MAP as a Mobile Router
and again I didn't update the table of contents.

thanks,
Hesham

------_=_NextPart_001_01C01E55.62CBA2E0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Sep 14 16:23:16 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23489 for ; Thu, 14 Sep 2000 16:23:14 -0400 (EDT) Received: from standards (47.234.32.16:1991) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB939B6@standards.nortelnetworks.com>; Thu, 14 Sep 2000 16:07:43 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7921 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Sep 2000 16:07:43 -0400 Received: from mgw-x1.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB939B5@standards.nortelnetworks.com>; Thu, 14 Sep 2000 16:07:42 -0400 Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com [172.18.242.183]) by mgw-x1.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e8EKKt428879; Thu, 14 Sep 2000 23:20:55 +0300 (EET DST) Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id ; Thu, 14 Sep 2000 15:20:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C01E89.45125F9E" Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E2B0@daeis07nok> Date: Thu, 14 Sep 2000 15:17:37 -0500 Reply-To: Basavaraj.Patil@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: Re: [MOBILE-IP] draft for WG consensus X-cc: Hesham.Soliman@ERICSSON.COM.AU 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_01C01E89.45125F9E Content-Type: text/plain; charset="iso-8859-1" Hesham, Can you please submit the HMIP I-D as a personal draft at the present time? The I-D can be revised and made a WG document after we have had consensus from the WG members. -Basavaraj -----Original Message----- From: EXT Hesham Soliman (EPA) [mailto:Hesham.Soliman@ERICSSON.COM.AU] Sent: Thursday, September 14, 2000 8:34 AM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: [MOBILE-IP] draft for WG consensus Hello Raj and Phil, As promised, I've attached a copy of the submitted draft for you to initiate the appropriate actions to see whether it should be a WG item. The draft is a merger of our initial proposal and INRIA's proposal that was presented in Pittsburgh. We believe the draft is technically stable and is within the charter's scope. The draft is not visible on the web, therefore I'm attaching it to this mail. I look forward to your comments. Regards, Hesham ------_=_NextPart_001_01C01E89.45125F9E Content-Type: text/html; charset="iso-8859-1" draft for WG consensus
Hesham,
 
Can you please submit the HMIP I-D as a personal draft at the present time?
The I-D can be revised and made a WG document after we have had consensus
from the WG members.
 
-Basavaraj
-----Original Message-----
From: EXT Hesham Soliman (EPA) [mailto:Hesham.Soliman@ERICSSON.COM.AU]
Sent: Thursday, September 14, 2000 8:34 AM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: [MOBILE-IP] draft for WG consensus

Hello Raj and Phil,

As promised, I've attached a copy of the submitted
draft for you to initiate the appropriate actions
to see whether it should be a WG item.

The draft is a merger of our initial proposal and INRIA's
proposal that was presented in Pittsburgh. We believe the
draft is technically stable and is within the charter's
scope.

The draft is not visible on the web, therefore I'm attaching it
to this mail.

I look forward to your comments.

Regards,

Hesham

------_=_NextPart_001_01C01E89.45125F9E-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Sep 14 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 SMTP id QAA23683 for ; Thu, 14 Sep 2000 16:40:12 -0400 (EDT) Received: from standards (47.234.32.16:1991) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB939FC@standards.nortelnetworks.com>; Thu, 14 Sep 2000 16:24:49 -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; Thu, 14 Sep 2000 16:24:49 -0400 Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB939FB@standards.nortelnetworks.com>; Thu, 14 Sep 2000 16:24:44 -0400 Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com [172.18.242.183]) by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e8EKcAl12623 for ; Thu, 14 Sep 2000 23:38:10 +0300 (EET DST) Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id ; Thu, 14 Sep 2000 15:38:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E2B1@daeis07nok> Date: Thu, 14 Sep 2000 15:34:56 -0500 Reply-To: Basavaraj.Patil@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: [MOBILE-IP] WG Consensus on HMIPv6 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello, At IETF8 two I-Ds on Hierarchical MIPv6 mobility management were presented 1. draft-castelluccia-mobileip-hmipv6-00.txt and 2. draft-soliman-mobileip-hmipv6-00.txt The authors of these I-Ds have combined the ideas into one new I-D and submitted it to the WG. The new I-D has been submitted to the WG in a previous e-mail by Hesham Soliman (draft-ietf-mobileip-hmipv6-00.txt) and will be announced as a personal I-D by the drafts editor soon and should be available in the standard repositories. Before making this new I-D a WG document we need to have consensus from WG members. Please express your views (in lieu of a hum) by Sept 28th, on making this a WG document. -Basavaraj From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Sep 15 03:11: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 SMTP id DAA15745 for ; Fri, 15 Sep 2000 03:11:03 -0400 (EDT) Received: from standards (47.234.32.16:1238) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB93B6E@standards.nortelnetworks.com>; Fri, 15 Sep 2000 2:55:32 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8498 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 15 Sep 2000 02:55:28 -0400 Received: from mailserv.intranet.GR by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB93B6D@standards.nortelnetworks.com>; Fri, 15 Sep 2000 2:45:27 -0400 Received: from patreas.patra.intranet.gr by mailserv.intranet.GR with ESMTP (8.8.8/ICM-mailhub-1.0) id JAA09944; Fri, 15 Sep 2000 09:56:07 +0300 (EET DST) Received: from intranet.gr (patdpd17 [146.124.171.40]) by patreas.patra.intranet.gr (8.9.1b+Sun/8.9.0) with ESMTP id KAA20639 for ; Fri, 15 Sep 2000 10:08:37 +0300 (EET DST) X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-7 Content-Transfer-Encoding: 7bit Message-ID: <39C1C800.22BF397F@intranet.gr> Date: Fri, 15 Sep 2000 09:56:01 +0300 Reply-To: Christos Chrisanthakopoulos Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Christos Chrisanthakopoulos Subject: [MOBILE-IP] the IGSN mystery (?) To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Dear all, Regarding the stepwised integration of MIP in 3G networks being proposed I would like to know if there is any additional information about the IGSN node (more in focus details if possible) or is it eventually that it behaves and functions more or less like a GGSN in the CN? Thanks for your time Christos From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Sep 15 04:10:49 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA16298 for ; Fri, 15 Sep 2000 04:10:45 -0400 (EDT) Received: from standards (47.234.32.16:3299) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB93BD1@standards.nortelnetworks.com>; Fri, 15 Sep 2000 3:55:16 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8622 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 15 Sep 2000 03:55:16 -0400 Received: from malmo.trab.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB93BCC@standards.nortelnetworks.com>; Fri, 15 Sep 2000 3:45:15 -0400 Received: from trab-hermes.haninge.trab.se (trab-hermes.haninge.trab.se [131.115.158.15]) by malmo.trab.se (8.10.1/TRAB-primary-2) with ESMTP id e8F7wb310105; Fri, 15 Sep 2000 09:58:37 +0200 (MEST) Received: by trab-hermes.haninge.trab.se with Internet Mail Service (5.5.2448.0) id ; Fri, 15 Sep 2000 09:58:36 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-7" Message-ID: <778DFE9B4E3BD111A74E08002BA3DC0D01D110EC@trab-hermes.haninge.trab.se> Date: Fri, 15 Sep 2000 09:58:35 +0200 Reply-To: Johan Helge Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Johan Helge Subject: Re: [MOBILE-IP] the IGSN mystery (?) X-To: Christos Chrisanthakopoulos To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA16298 Hello Christos, The IGSN (introduced in the so called step 3) is supposed to act as combined SGSN and GGSN. On top of that, fuctionality is added for Mobile IP support to handle inter IGSN mobility. The following description of the IGSN is taken from the 3GPP document 23.923: · support of UMTS/GPRS mobility management across the UTRAN/BSS, i.e. what the SGSN does today; · support of MAP (Mobile Application Part) to communicate with UMTS/GPRS specific nodes, such as HLR, EIR, SMS-C and the functionality needed to handle the information to and from these nodes, such as SIM based authentication and handling of keys for encryption over the radio interface; · interaction with the HLR and via the FA with the AAA infrastructure; · charging data collection and formatting according to UMTS/GSM specifications. IETF specifications may be used for FA accounting; · support of Mobile IP with the necessary functionality to be compliant with Mobile IP deployment in non-UMTS networks around the world. For IPv4, this means to provide FA functionality with commonly deployed extensions (e.g. NAI, challenge response) and functionality to utilise RADIUS or another AAA infrastructure according to the IETF specifications at hand when a given UMTS specification is finalised; · support of inter IGSN handovers, either by Mobile IP or GTP. In the control plane, the PDP context(s) for a ME might need to be transferred from the old to the new IGSN by GTP. Hope this helps, Johan -----Original Message----- From: Christos Chrisanthakopoulos [mailto:xchr@INTRANET.GR] Sent: den 15 september 2000 08:56 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: [MOBILE-IP] the IGSN mystery (?) Dear all, Regarding the stepwised integration of MIP in 3G networks being proposed I would like to know if there is any additional information about the IGSN node (more in focus details if possible) or is it eventually that it behaves and functions more or less like a GGSN in the CN? Thanks for your time Christos From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Sep 15 04:46: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 SMTP id EAA16575 for ; Fri, 15 Sep 2000 04:46:30 -0400 (EDT) Received: from standards (47.234.32.16:3404) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB93C3A@standards.nortelnetworks.com>; Fri, 15 Sep 2000 4:31:08 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8761 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 15 Sep 2000 04:31:08 -0400 Received: from mailserv.intranet.GR by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB93C39@standards.nortelnetworks.com>; Fri, 15 Sep 2000 4:31:07 -0400 Received: from patreas.patra.intranet.gr by mailserv.intranet.GR with ESMTP (8.8.8/ICM-mailhub-1.0) id LAA16089; Fri, 15 Sep 2000 11:41:48 +0300 (EET DST) Received: from intranet.gr (patdpd17 [146.124.171.40]) by patreas.patra.intranet.gr (8.9.1b+Sun/8.9.0) with ESMTP id LAA22203 for ; Fri, 15 Sep 2000 11:54:18 +0300 (EET DST) X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-7 Content-Transfer-Encoding: 7bit Message-ID: <39C1E0C5.122631C9@intranet.gr> Date: Fri, 15 Sep 2000 11:41:41 +0300 Reply-To: Christos Chrisanthakopoulos Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Christos Chrisanthakopoulos Subject: Re: [MOBILE-IP] the IGSN mystery (?) To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit The 3GPP 23.923 is the document I'm working on as well and I'm aware of the descriptions included but I was wondering if theres anything more (or more sources) concerning the IGSN node i.e. more functionality details, protocol stack transmission plane e.t.c. Otherwise I'm guessing that it behaves more or less like a GGSN and that is the reason for not including additional information on the 3GPP document. Best regards... Christos From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Sep 15 08:14: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 SMTP id IAA18323 for ; Fri, 15 Sep 2000 08:14:00 -0400 (EDT) Received: from standards (47.234.32.16:1255) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB93CF9@standards.nortelnetworks.com>; Fri, 15 Sep 2000 7:58:27 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8995 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 15 Sep 2000 07:58:27 -0400 Received: from ish7.ericsson.com.au (203.61.155.111:48978) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB93CF8@standards.nortelnetworks.com>; Fri, 15 Sep 2000 7:58:25 -0400 Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id WAA07415; Fri, 15 Sep 2000 22:09:31 +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 XAA02929; Fri, 15 Sep 2000 23:11:29 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Sep 2000 23:11:31 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C01F0E.14F3F770" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A5089EB25C@eaubrnt018.epa.ericsson.se> Date: Fri, 15 Sep 2000 23:11:30 +1100 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] draft for WG consensus X-To: "Basavaraj.Patil@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_01C01F0E.14F3F770 Content-Type: text/plain; charset="iso-8859-1" Ok I'll do that Hesham -----Original Message----- From: Basavaraj Patil [mailto:Basavaraj.Patil@NOKIA.COM] Sent: den 14 september 2000 22:18 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] draft for WG consensus Hesham, Can you please submit the HMIP I-D as a personal draft at the present time? The I-D can be revised and made a WG document after we have had consensus from the WG members. -Basavaraj -----Original Message----- From: EXT Hesham Soliman (EPA) [mailto:Hesham.Soliman@ERICSSON.COM.AU] Sent: Thursday, September 14, 2000 8:34 AM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: [MOBILE-IP] draft for WG consensus Hello Raj and Phil, As promised, I've attached a copy of the submitted draft for you to initiate the appropriate actions to see whether it should be a WG item. The draft is a merger of our initial proposal and INRIA's proposal that was presented in Pittsburgh. We believe the draft is technically stable and is within the charter's scope. The draft is not visible on the web, therefore I'm attaching it to this mail. I look forward to your comments. Regards, Hesham ------_=_NextPart_001_01C01F0E.14F3F770 Content-Type: text/html; charset="iso-8859-1" draft for WG consensus
Ok I'll do that
 
Hesham
-----Original Message-----
From: Basavaraj Patil [mailto:Basavaraj.Patil@NOKIA.COM]
Sent: den 14 september 2000 22:18
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: Re: [MOBILE-IP] draft for WG consensus

Hesham,
 
Can you please submit the HMIP I-D as a personal draft at the present time?
The I-D can be revised and made a WG document after we have had consensus
from the WG members.
 
-Basavaraj
-----Original Message-----
From: EXT Hesham Soliman (EPA) [mailto:Hesham.Soliman@ERICSSON.COM.AU]
Sent: Thursday, September 14, 2000 8:34 AM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: [MOBILE-IP] draft for WG consensus

Hello Raj and Phil,

As promised, I've attached a copy of the submitted
draft for you to initiate the appropriate actions
to see whether it should be a WG item.

The draft is a merger of our initial proposal and INRIA's
proposal that was presented in Pittsburgh. We believe the
draft is technically stable and is within the charter's
scope.

The draft is not visible on the web, therefore I'm attaching it
to this mail.

I look forward to your comments.

Regards,

Hesham

------_=_NextPart_001_01C01F0E.14F3F770-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Sep 15 14:47: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 SMTP id OAA23869 for ; Fri, 15 Sep 2000 14:47:31 -0400 (EDT) Received: from standards (47.234.32.16:2378) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9411A@standards.nortelnetworks.com>; Fri, 15 Sep 2000 14:31:39 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10325 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 15 Sep 2000 14:31:39 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB94119@standards.nortelnetworks.com>; Fri, 15 Sep 2000 14:31:39 -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 LAA20068; Fri, 15 Sep 2000 11:45:09 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e8FIj9X02318; Fri, 15 Sep 2000 11:45:09 -0700 X-Virus-Scanned: Fri, 15 Sep 2000 11:45:09 -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) smtpdElikRf; Fri, 15 Sep 2000 11:45:05 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <399CEF1E.763D1800@era.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39C26E31.38C6BB01@iprg.nokia.com> Date: Fri, 15 Sep 2000 11:45: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] IPv6 handover document X-To: Mattias Pettersson To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Matthias, Sorry for the extreme delay in my response to your note. I hope you can remember what the discussion was! You mention cranking up the rate for IPv6 router advertisement. Since the Mobile IPv6 document is now in Last Call, did you wish to make a proposal about what the (maximum) rate should be? Regards, Charlie P. Mattias Pettersson wrote: > > Linfeng Yang wrote: > > > > => obviously there is something like overlapping cells here. > > > > > > Sure but that doesn't necessarily mean you can receive two > > > separate traffic streams. > > > > Yes my assumption is, there must be some form of overlapping, otherwise you > > cannot achieve zero-delay. > > Hi, > > Yes, overlapping is of course necessary, but that's not what Hesham is pointing > at. The nature of radio link layers is not exactly like an Ethernet, where > everyone can hear everyone else. Since bandwidth is limited and transceivers > are interfering, different transceivers will use different physical and/or > logical channels. > > If the link medium is using different physical channels (different frequencies, > not CDMA technology, for instance), then a receiver can usually only lock onto > one single of these channels, since (due to cost) it is only equipped with one > transceiver. If access point A is on subnet Na and using channel Ca, a mobile > node locked onto channel Ca won't be able to hear or measure anything of a > possible access point B on subnet Nb on channel Cb. The only way for the mobile > node to detect the presence of B would be to start a scan over all channels > (and do so occasionally) or to be informed of its existence by the network over > channel Ca. > > The few radio technologies I've fought with do this and if anyone else have > better news I would be very happy to hear of it. > > The point is: we must understand these limitations inherited from radio links > and take them into consideration when designing a handoff scheme. > > Otherwise, if we assume the opposite with the ability to hear routers > regardless of radio channels and have good enough overlap plus add some > heuristics in reachability detection of routers and maybe crank up the RA rate > a bit, good old Mobile IPv6 will do the work perfectly without our help! > > /Mattias Pettersson From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Sep 15 15:02: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 SMTP id PAA24025 for ; Fri, 15 Sep 2000 15:02:16 -0400 (EDT) Received: from standards (47.234.32.16:2378) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9418E@standards.nortelnetworks.com>; Fri, 15 Sep 2000 14:46:43 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10475 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 15 Sep 2000 14:46:43 -0400 Received: from cs.rice.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9418D@standards.nortelnetworks.com>; Fri, 15 Sep 2000 14:46:39 -0400 Received: from localhost (dbj@localhost) by cs.rice.edu (8.9.0/8.9.0) with ESMTP id OAA15166; Fri, 15 Sep 2000 14:00:05 -0500 (CDT) Message-ID: <15165.969044404@cs.rice.edu> Date: Fri, 15 Sep 2000 14:00:04 -0500 Reply-To: Dave Johnson Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Dave Johnson Subject: Re: [MOBILE-IP] IPv6 handover document X-To: charliep@IPRG.NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of "Fri, 15 Sep 2000 11:45:05 PDT" <39C26E31.38C6BB01@iprg.nokia.com> Charlie, Mobile IPv6 already does not put any limit on the maximum rate for Router Advertisements. It's documented that way in the draft and has been that way for a long time. Dave >Hello Matthias, > >Sorry for the extreme delay in my response to your note. >I hope you can remember what the discussion was! > >You mention cranking up the rate for IPv6 router advertisement. >Since the Mobile IPv6 document is now in Last Call, did you wish >to make a proposal about what the (maximum) rate should be? > >Regards, >Charlie P. > > >Mattias Pettersson wrote: >> >> Linfeng Yang wrote: >> >> > > => obviously there is something like overlapping cells here. >> > > >> > > Sure but that doesn't necessarily mean you can receive two >> > > separate traffic streams. >> > >> > Yes my assumption is, there must be some form of overlapping, otherwise yo u >> > cannot achieve zero-delay. >> >> Hi, >> >> Yes, overlapping is of course necessary, but that's not what Hesham is point ing >> at. The nature of radio link layers is not exactly like an Ethernet, where >> everyone can hear everyone else. Since bandwidth is limited and transceivers >> are interfering, different transceivers will use different physical and/or >> logical channels. >> >> If the link medium is using different physical channels (different frequenci es, >> not CDMA technology, for instance), then a receiver can usually only lock on to >> one single of these channels, since (due to cost) it is only equipped with o ne >> transceiver. If access point A is on subnet Na and using channel Ca, a mobil e >> node locked onto channel Ca won't be able to hear or measure anything of a >> possible access point B on subnet Nb on channel Cb. The only way for the mob ile >> node to detect the presence of B would be to start a scan over all channels >> (and do so occasionally) or to be informed of its existence by the network o ver >> channel Ca. >> >> The few radio technologies I've fought with do this and if anyone else have >> better news I would be very happy to hear of it. >> >> The point is: we must understand these limitations inherited from radio link s >> and take them into consideration when designing a handoff scheme. >> >> Otherwise, if we assume the opposite with the ability to hear routers >> regardless of radio channels and have good enough overlap plus add some >> heuristics in reachability detection of routers and maybe crank up the RA ra te >> a bit, good old Mobile IPv6 will do the work perfectly without our help! >> >> /Mattias Pettersson From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Sep 15 15:53: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 SMTP id PAA24395 for ; Fri, 15 Sep 2000 15:53:32 -0400 (EDT) Received: from standards (47.234.32.16:3558) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB941F4@standards.nortelnetworks.com>; Fri, 15 Sep 2000 15:37:55 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10614 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 15 Sep 2000 15:37:55 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB941F3@standards.nortelnetworks.com>; Fri, 15 Sep 2000 15:37:55 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA25188; Fri, 15 Sep 2000 12:51:26 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e8FJpNQ29763; Fri, 15 Sep 2000 12:51:23 -0700 X-Virus-Scanned: Fri, 15 Sep 2000 12:51: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) smtpdcAKRbb; Fri, 15 Sep 2000 12:51:20 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <200008171644.SAA58508@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39C27DBA.D10FBFAB@iprg.nokia.com> Date: Fri, 15 Sep 2000 12:51: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: Re: [MOBILE-IP] IPv6 handover document X-To: Francis.Dupont@ENST-BRETAGNE.FR To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Francis, I'm catching up on old mail -- your original note in its entirety follows these little snippets... > I guess some L2 help is always needed to make a realistic handoff. > (ie. avoid these RA beacons). > > => I agree! But what does "realistic" mean? What if the medium was a bit faster, and handover had to happen within 50 ms, and if beacons came out "fast enough" but did not consume more than 1% of the bandwidth? > => What you say above is very interesting and we've been looking into > similar algorithms that reuse L2 knowledge. One general comment though, > Sending a Neighbour solicitation (or even worse router solicitation) only > > => I agree about a NS is better than a RS. What would the target address be? Regards, Charlie P. Francis Dupont wrote: > > In your previous mail you wrote: > > I guess some L2 help is always needed to make a realistic handoff. > (ie. avoid these RA beacons). > > => I agree! > > => What you say above is very interesting and we've been looking into > similar algorithms that reuse L2 knowledge. One general comment though, > Sending a Neighbour solicitation (or even worse router solicitation) only > > => I agree about a NS is better than a RS. > > due to signal measurements makes the assummption that whenever you change > Base station, you also change subnets. > > => we need to know the layer 2 property before in order to say if > this assumption was made. In a IEEE 802.11 network in an ad-hoc mode > ("an" because a well-known vendor has its own ad-hoc mode :-) you > can do real good things with signal strength (no base station => no > assumption). Same if base stations and routers are always in the same box. > > That coupling is not required by > MIP and hence may also be inefficient in terms of radio resource usage. > > Also are you making the assumption that you can talk to two routers > in two subnets at the same time ? > > => obviously there is something like overlapping cells here. > > Do you have a specific Layer 2 in mind ? > > => ah! This should be the next point after "Link Layer Assisted ...". > I am afraid it is a bit hard to rely efficiently on a generic layer 2. > Unfortunately not a scoop! > > Thanks > > Francis.Dupont@enst-bretagne.fr > > PS: is there a specialized mailing list for this topic? From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Sep 15 16:23: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 SMTP id QAA24612 for ; Fri, 15 Sep 2000 16:23:40 -0400 (EDT) Received: from standards (47.234.32.16:3558) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9425A@standards.nortelnetworks.com>; Fri, 15 Sep 2000 16:08:15 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10747 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 15 Sep 2000 16:08:14 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB94259@standards.nortelnetworks.com>; Fri, 15 Sep 2000 16:08: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 NAA27525; Fri, 15 Sep 2000 13:21:45 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e8FKLhf16356; Fri, 15 Sep 2000 13:21:43 -0700 X-Virus-Scanned: Fri, 15 Sep 2000 13:21: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) smtpdotJ7mt; Fri, 15 Sep 2000 13:21:39 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <200008171457.QAA57909@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39C284D5.F31661B5@iprg.nokia.com> Date: Fri, 15 Sep 2000 13:21:41 -0700 Reply-To: charliep@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: Re: [MOBILE-IP] IPv6 handover document X-To: Francis.Dupont@ENST-BRETAGNE.FR To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello again Francis, Still catching up... Francis Dupont wrote: > => you have forgotten smart handoff (:-)! What is that? > Fast handoff on the other hand describe how we can achieve it. Fast is > compared with basic MIPv6 in the sense that it will overcome the router > advertisement interval limit. > > => to use router advertisements as a beacon is stupid (from a IPv6 person > point of view). Can you say more about why? > So MN will start fast handoff process when it is in active movement. > MN will constantly measure signal strength of message received from > current router, if it is lower than some threshold value (t1), MN will > then send a router solicitation message in hope of receiving a router > advertisement. > > => I disagree, if you want to poll a router you should use a neighbor > solicitation: > - router solicitations are multicasted then they are more expensive > than unicasted neighbor solicitations Agreed. > - router advertisements are expensive to build, transmit and decode Can you provide a little more insight about why this should be so? > - routers should wait a bit before sending a solicited router advertisement > (in order to avoid synchronization of replies) > > In this way, MN can overcome the Router Advertisement > interval limit, thus speed up handoff process. The Mobile IPv6 document allows routers to send out advertisements more often. > Recommended values for these limits are: > > - MinRtrAdvInterval 0.5 seconds > > - MaxRtrAdvInterval 1.5 seconds > > Use of these modified limits MUST be configurable, and specific > knowledge of the type of network interface in use SHOULD be taken > into account in configuring these limits for each network interface. The actual interval can be set to whatever is needed. Isn't this good enough for many handover scenarios? > => I prefer to use router advertisement in order to get the set of > available routers first and to have a regular measure of the signal > strength in second and in a *passive* way. I agree this is a good plan. > => "forwarding from a previous care-of address" is I-D 12 10.9, isn't it? > This supposes there are enough available home agents (ie. lost of benefits > of the disappearance of foreign agents). Isn't this just a matter of providing needed functionality? If so, then I'm not clear on why it matters about whether you call the access router a home agent or a foreign agent. > PS: fast/smooth/seamless/smart handoffs are fine but mobile IPv6 code should > support other more traditional usage of mobility, for instance it should > be able to change an interface for another, for instance a GSM/GPRS/UMTS/... > cellular device for a 100Mbits/s Ethernet. This is what makes mobile IPv* > more powerful than any layer 2 solution and we should not drop this in order > to fight with better weapons against layer 2 solutions. > I am afraid this was forgotten by some of us... I believe it is an essential part of Mobile IPv6, and always has been. Can you mention where it might have been forgotten and thus needs repair in the specification? I look forward to your further comments. I append your original note in its entirety in case this is so old that you wouldn't remember the context. Regards, Charlie P. ================================================================================ Francis Dupont wrote: > > In your previous mail you wrote: > > > =>Yes I think that is important, but also just as important is to > > separate fast, smooth and seamless handoffs from each other. I believe > > the basic MIPv6 already provides smooth handoffs (as far as routing goes). > > Here is my understanding about the different between fast, smooth and > seamless handoff. Please correct me if I am wrong. > > => you have forgotten smart handoff (:-)! > > I feel smooth handoff and seamless handoff are the same, they describe the > handoff in the way what we want it achieve, i.e., minimized packet loss. > In basic MIPv6 smooth or seamless handoff is achieved through establishing > forwarding from a previous care-of address. > > => this is seamless handoff, smooth is based on bicasting. > The mechanism is not exactly the same. > > Fast handoff on the other hand describe how we can achieve it. Fast is > compared with basic MIPv6 in the sense that it will overcome the router > advertisement interval limit. > > => to use router advertisements as a beacon is stupid (from a IPv6 person > point of view). > > Here I schemed one way of Fast handoff, I call it Link Layer > Assisted Fast Handoff. > > When MN is on idle movement, there is no need to perform fast handoff, > since there is no packet loss issue. > > => idle movement is "not moving", isn't it? And active is "moving"? > > So MN will start fast handoff process when it is in active movement. > MN will constantly measure signal strength of message received from > current router, if it is lower than some threshold value (t1), MN will > then send a router solicitation message in hope of receiving a router > advertisement. > > => I disagree, if you want to poll a router you should use a neighbor > solicitation: > - router solicitations are multicasted then they are more expensive > than unicasted neighbor solicitations > - router advertisements are expensive to build, transmit and decode > - routers should wait a bit before sending a solicited router advertisement > (in order to avoid synchronization of replies) > > In this way, MN can overcome the Router Advertisement > interval limit, thus speed up handoff process. > > => the less-reachability detection of routers should not rely on router > advertisements, I agree. > > MN may then receive more than one Solicited Router Advertisement > from neighboring routers. > > => I prefer to use router advertisement in order to get the set of > available routers first and to have a regular measure of the signal > strength in second and in a *passive* way. > > After compare the signal strength of current router (sc) with the one > received earliest from new router (sn), MN can then decide to perform a > Handoff or not. If (sn + t2) >= sc, MN will perform handoff, otherwise > MN will send another Router Solicitation. t2 is used to prevent > unnecessary handoff in the "ping pong" like movement within the overlap > of two router domain. > > => I prefer to have a second threshold: if (sn + t2) >= sc then the > new candidate router should be polled in order to get a fresh sn, > then if (sn + t3) >= sc MN will perform handoff. This is cheaper > and faster than using router solicitation as a hammer and more > powerful than a decay mechanism on signal strength. It can support > multiple candidates too if movement is both active and fast. > An interesting case is if there are real beacons associated to > routers then signal strengths are available directly. > > After handoff new router becomes current default > router or MN, MN will then measure its signal strength from this router. > > => MN should keep a list of candidate default routers (RFC 2461) then > it is not so expensive to keep signal strengths too. > > We can see this is only local handoff, if accompanied with establishing > forwarding from a previous care-of address, it can achieve even better > smoothness. > > => "forwarding from a previous care-of address" is I-D 12 10.9, isn't it? > This supposes there are enough available home agents (ie. lost of benefits > of the disappearance of foreign agents). > > Thanks > > Francis.Dupont@enst-bretagne.fr > > PS: fast/smooth/seamless/smart handoffs are fine but mobile IPv6 code should > support other more traditional usage of mobility, for instance it should > be able to change an interface for another, for instance a GSM/GPRS/UMTS/... > cellular device for a 100Mbits/s Ethernet. This is what makes mobile IPv* > more powerful than any layer 2 solution and we should not drop this in order > to fight with better weapons against layer 2 solutions. > I am afraid this was forgotten by some of us... From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Sep 15 17:46: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 SMTP id RAA25249 for ; Fri, 15 Sep 2000 17:46:41 -0400 (EDT) Received: from standards (47.234.32.16:2255) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB94324@standards.nortelnetworks.com>; Fri, 15 Sep 2000 17:31:21 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10972 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 15 Sep 2000 17:31:21 -0400 Received: from motgate3.mot.com (144.189.100.103:37749) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB94302@standards.nortelnetworks.com>; Fri, 15 Sep 2000 17:21:19 -0400 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (motgate3 2.1) with ESMTP id OAA02976 for ; Fri, 15 Sep 2000 14:32:31 -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 OAA08429 for ; Fri, 15 Sep 2000 14:34:40 -0700 (MST)] Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Sep 2000 16:34:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-7" Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A0498FA72@il27exm02.cig.mot.com> Date: Fri, 15 Sep 2000 16:34:39 -0500 Reply-To: Nakhjiri Madjid-MNAKHJI1 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Nakhjiri Madjid-MNAKHJI1 Subject: Re: [MOBILE-IP] the IGSN mystery (?) X-To: Christos Chrisanthakopoulos To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Christos, Could you please tell me which 3GPP or 3GPP2 working group the MIP integration into 3G networks is being discussed? Thank you in advance, Madjid Nakhjiri &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& Madjid Nakhjiri mnakhji1@email.mot.com Motorola, IP Network Standards 1501 West Shure Drive,(IL27/2D5) Arlington Heights, IL 60004 USA Phone: +1 847-632-5030 Fax: +1 847-632-7912 It hurts to be on the cutting EDGE &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& -----Original Message----- From: Christos Chrisanthakopoulos [mailto:xchr@INTRANET.GR] Sent: Friday, September 15, 2000 1:56 AM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: [MOBILE-IP] the IGSN mystery (?) Dear all, Regarding the stepwised integration of MIP in 3G networks being proposed I would like to know if there is any additional information about the IGSN node (more in focus details if possible) or is it eventually that it behaves and functions more or less like a GGSN in the CN? Thanks for your time Christos From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Sep 16 00:29: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 SMTP id AAA29940 for ; Sat, 16 Sep 2000 00:29:02 -0400 (EDT) Received: from standards (47.234.32.16:1776) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9446E@standards.nortelnetworks.com>; Sat, 16 Sep 2000 0:13:41 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 11445 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 16 Sep 2000 00:13:40 -0400 Received: from imsp015.netvigator.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9446A@standards.nortelnetworks.com>; Sat, 16 Sep 2000 0:03:38 -0400 Received: from eriko (bbig002048.netvigator.com [208.151.89.48]) by imsp015.netvigator.com (8.9.3/8.9.1) with SMTP id MAA21678; Sat, 16 Sep 2000 12:13:14 +0800 (HKT) X-Priority: 3 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=XXC1BCC120-009CC1BCXX Content-Transfer-Encoding: 7bit Message-ID: <200009160413.MAA21678@imsp015.netvigator.com> Date: Sat, 16 Sep 2000 12:13:14 +0800 Reply-To: mblcom@netvigator.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "mblcom@netvigator.com" Subject: [MOBILE-IP] New developed gift box special for watch business To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a Multipart MIME message. --XXC1BCC120-009CC1BCXX Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Million Band Limited Unit 406-408, 4/F., Manhattan Centre, 8 Kwai Cheong Road, Kwai Chung, N.T. Hong Kong. Tel : 852-24275807 Fax : 852-24285687 To : All Customers Attn. : The General Manager From : Wilson Ng Subject : New developed gift box special for watch business Dear Sirs / Madams, We are the leather strap, nylon strap and any kinds of non-metal band manufacturer. We have special department to produce wallets, hand bags, key holder and any kinds of special leather goods. We also produce premium products and special gift box with special materials. This year we develop a series of gift box special for watch products. So we would like to recommend this special items for you. The advantage of this gift box are as follows. (1) Shock resistance to protect the inside product. (2) This special gift have re-use function, such like to use for pen holder, eye-glass holder, cosmetic box, coins box or other usage. To compare existing through it away gift box, this new gift box is more environmental friendly. (3) The box can create the logo more sharply and best for the company to create the special image. Also the new gift box price is competitive. The quotation and catalogue was enclosed. If you have interesting please don't hesitated to contact us. We can arrange our representative to visit your company to introduce this special packaging for you. Your prompt response are much appreciate. Best Regards Million Band Limited --XXC1BCC120-009CC1BCXX-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Sep 16 08:25: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 SMTP id IAA14494 for ; Sat, 16 Sep 2000 08:25:14 -0400 (EDT) Received: from standards (47.234.32.16:4588) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9456C@standards.nortelnetworks.com>; Sat, 16 Sep 2000 8:09:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 11787 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 16 Sep 2000 08:09:52 -0400 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9456B@standards.nortelnetworks.com>; Sat, 16 Sep 2000 8:09: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 e8GCNBu26789; Sat, 16 Sep 2000 14:23:11 +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 OAA27444; Sat, 16 Sep 2000 14:23:11 +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 OAA05354; Sat, 16 Sep 2000 14:24:39 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-ID: <200009161224.OAA05354@givry.rennes.enst-bretagne.fr> Date: Sat, 16 Sep 2000 14:24:38 +0200 Reply-To: Francis.Dupont@ENST-BRETAGNE.FR Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] IPv6 handover document X-To: Dave Johnson To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Fri, 15 Sep 2000 14:00:04 CDT. <15165.969044404@cs.rice.edu> In your previous mail you wrote: Mobile IPv6 already does not put any limit on the maximum rate for Router Advertisements. It's documented that way in the draft and has been that way for a long time. => I disagree. RFC 2461 puts some limits (Max/MinRtrAdvInterval) for unsolicited multicast Router Advertisements and (MIN_DELAY_BETWEEN_RAS) for any multicast Router Advertisements. I-D 12 changes the unsolicited values (Max/MinRtrAdvInterval). Whether it is a good idea or not is another topic... Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Sep 16 09:26: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 SMTP id JAA14833 for ; Sat, 16 Sep 2000 09:26:15 -0400 (EDT) Received: from standards (47.234.32.16:2779) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB945C6@standards.nortelnetworks.com>; Sat, 16 Sep 2000 9:10:49 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 11908 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 16 Sep 2000 09:10:49 -0400 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB945C5@standards.nortelnetworks.com>; Sat, 16 Sep 2000 9:10:49 -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 e8GDOEu27933; Sat, 16 Sep 2000 15:24:14 +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 PAA27805; Sat, 16 Sep 2000 15:24:14 +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 PAA05559; Sat, 16 Sep 2000 15:25:42 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-ID: <200009161325.PAA05559@givry.rennes.enst-bretagne.fr> Date: Sat, 16 Sep 2000 15:25:42 +0200 Reply-To: Francis.Dupont@ENST-BRETAGNE.FR Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] IPv6 handover document X-To: "Charles E. Perkins" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Fri, 15 Sep 2000 12:51:22 PDT. <39C27DBA.D10FBFAB@iprg.nokia.com> In your previous mail you wrote: > I guess some L2 help is always needed to make a realistic handoff. > (ie. avoid these RA beacons). > > => I agree! But what does "realistic" mean? What if the medium was a bit faster, and handover had to happen within 50 ms, and if beacons came out "fast enough" but did not consume more than 1% of the bandwidth? => my point is the idea to use RAs as a beacon is very bad idea. The RFC 2461 timings for RAs are: - MaxRtrAdvInterval (min 4, max 1800, default 600) - MinRtrAdvInterval (min 3, max 3/4MaxRtrAdvInterval, default 1/3MaxRtr.) - AdvDefaultLifetime (min MaxRtrAdvInterval, max 9000, default 3MaxRtr.) - AdvValidLifetime (default 2592000s/30days) - AdvPreferredLifetime (default 604800s/7days) any proposal with a different scale for one of these values is *broken*. For instance if you'd like to reduce AdvDefaultLifetime to a small value (some seconds) then you should do this indirectly (IMHO it is exactly what Advertisement Interval Option does). If I come back to your text, you seem to ask for RA rates between 20 to 100 per second, then this is IMHO broken, ie. something else should be used (note this doesn't work with I-D 12, rate is limited to 2 RA/s). > => What you say above is very interesting and we've been looking into > similar algorithms that reuse L2 knowledge. One general comment though, > Sending a Neighbour solicitation (or even worse router solicitation) only > > => I agree about a NS is better than a RS. What would the target address be? => the link-local router address. If the purpose is to know if the router is alive, a NS is simply enough... Regards Francis.Dupont@enst-bretagne.fr PS: if you'd like to use an IPv6 packet for a beacon then something like an empty no-next-header to a (new) multicast link-local "all-MN" address is enough and the cheaper. Please keep RAs for more useful things... From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Sep 16 10:02:54 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15048 for ; Sat, 16 Sep 2000 10:02:53 -0400 (EDT) Received: from standards (47.234.32.16:4845) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB94614@standards.nortelnetworks.com>; Sat, 16 Sep 2000 9:47:35 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12016 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 16 Sep 2000 09:47:35 -0400 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB94613@standards.nortelnetworks.com>; Sat, 16 Sep 2000 9:47:34 -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 e8GE14u27395; Sat, 16 Sep 2000 16:01:04 +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 QAA27978; Sat, 16 Sep 2000 16:01:03 +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 QAA05656; Sat, 16 Sep 2000 16:02:32 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-ID: <200009161402.QAA05656@givry.rennes.enst-bretagne.fr> Date: Sat, 16 Sep 2000 16:02:32 +0200 Reply-To: Francis.Dupont@ENST-BRETAGNE.FR Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] IPv6 handover document X-To: "Charles E. Perkins" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Fri, 15 Sep 2000 13:21:41 PDT. <39C284D5.F31661B5@iprg.nokia.com> In your previous mail you wrote: > => you have forgotten smart handoff (:-)! What is that? => just a joke (with a smile). In the list there were fast, smooth and seamless: smart was missing. > Fast handoff on the other hand describe how we can achieve it. Fast is > compared with basic MIPv6 in the sense that it will overcome the router > advertisement interval limit. > > => to use router advertisements as a beacon is stupid (from a IPv6 person > point of view). Can you say more about why? => RAs are too expensive to build, too expensive to send, too expensive to process. In fact they are not designed for this role and a dedicated mechanism should be far better when a fast beacon is needed. I am *really* tired to see people twisting RA timers in order to get fast handoffs: if there is a good reason to use very special timings then there should be a good reason to build a dedicated/simpler/cheaper mechanism. Reuse is not perversion! > - router advertisements are expensive to build, transmit and decode Can you provide a little more insight about why this should be so? => a RA should have at least one prefix information which is the more complex extention of ND, very expensive to process because of prefix timers. And if you'd like to have two kinds of RAs, one regular and one stripped (I-D 12 6.5 last paragraph is a step in this direction) then it will be better to have another kind of packets. The Mobile IPv6 document allows routers to send out advertisements more often. => even if it is fixed in order to have MIN_DELAY_BETWEEN_RAS aligned with MinRtrAdvInterval (:-) then RAs should not be sent in response of a RS without a small delay (because there can be more than one router, in fact the issue is deeper, RS/RA is designed to be multicasted, this is not good for a poll). > Recommended values for these limits are: > > - MinRtrAdvInterval 0.5 seconds > > - MaxRtrAdvInterval 1.5 seconds > > Use of these modified limits MUST be configurable, and specific > knowledge of the type of network interface in use SHOULD be taken > into account in configuring these limits for each network interface. The actual interval can be set to whatever is needed. Isn't this good enough for many handover scenarios? => prediction: this will never be as fast as some people would like. > ... it should be able to change an interface for another ... I believe it is an essential part of Mobile IPv6, and always has been. => we agree but my fear is not a prediction, just based on facts. Can you mention where it might have been forgotten and thus needs repair in the specification? => no, we need to repair brains (a bit harder :-). I look forward to your further comments. I append your original note in its entirety in case this is so old that you wouldn't remember the context. => the discussion begins by the remark that layer 2 should help then some examples about layer 3 weaknesses (with in front RAs/beacon) and what should be done in order to use the layer 2 (you know the conclusion: it will be a nice thing but it is hard to do it in a generic enough way, ...) Thanks Francis.Dupont@enst-bretagne.fr PS: the important point today is to get a working and published spec for mobile IPv6. Improvements should be done after: we need foundations, nice stained-glass windows will come afterwards... From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Sep 16 10:34: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 SMTP id KAA15182 for ; Sat, 16 Sep 2000 10:34:39 -0400 (EDT) Received: from standards (47.234.32.16:2812) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9465E@standards.nortelnetworks.com>; Sat, 16 Sep 2000 10:19:20 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12114 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 16 Sep 2000 10:19:19 -0400 Received: from cedar.dcs.shef.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9465D@standards.nortelnetworks.com>; Sat, 16 Sep 2000 10:19:19 -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 PAA12941; Sat, 16 Sep 2000 15:32:48 +0100 (BST) References: <200009161325.PAA05559@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 Content-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.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: <011d01c01feb$367fe1a0$2c0ba78f@dcs.shef.ac.uk> Date: Sat, 16 Sep 2000 15:34:24 +0100 Reply-To: Chern Nam Yap Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Chern Nam Yap Subject: Re: [MOBILE-IP] IPv6 handover document X-To: Francis.Dupont@ENST-BRETAGNE.FR To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi Agree on that point of using RA as beacon is very bad idea. If the key issue here is to allow mobile node to determine change in Network Prefix. The simpliest, fastest, most feasible way currently that IETF can "talk about" is using IIP method of doing handoff. That is: by looking at the co-located IP address (Network Prefix) that PPP server issue during PPP setup session. Hence no matter how fast, or how quick any IP handoff is, the ultimate limit lies with link layer handover. PS: I presume that the "smart handoff" Francis is looking for... ;) ---------------------------------------------------------------------------- --- 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 ----- Original Message ----- From: "Francis Dupont" To: Sent: Saturday, September 16, 2000 2:25 PM Subject: Re: [MOBILE-IP] IPv6 handover document > In your previous mail you wrote: > > > I guess some L2 help is always needed to make a realistic handoff. > > (ie. avoid these RA beacons). > > > > => I agree! > > But what does "realistic" mean? What if the medium was a bit faster, > and handover had to happen within 50 ms, and if beacons came out > "fast enough" but did not consume more than 1% of the bandwidth? > > => my point is the idea to use RAs as a beacon is very bad idea. > The RFC 2461 timings for RAs are: > - MaxRtrAdvInterval (min 4, max 1800, default 600) > - MinRtrAdvInterval (min 3, max 3/4MaxRtrAdvInterval, default 1/3MaxRtr.) > - AdvDefaultLifetime (min MaxRtrAdvInterval, max 9000, default 3MaxRtr.) > - AdvValidLifetime (default 2592000s/30days) > - AdvPreferredLifetime (default 604800s/7days) > any proposal with a different scale for one of these values is *broken*. > For instance if you'd like to reduce AdvDefaultLifetime to a small value > (some seconds) then you should do this indirectly (IMHO it is exactly > what Advertisement Interval Option does). > If I come back to your text, you seem to ask for RA rates between 20 to > 100 per second, then this is IMHO broken, ie. something else should be > used (note this doesn't work with I-D 12, rate is limited to 2 RA/s). > > > => What you say above is very interesting and we've been looking into > > similar algorithms that reuse L2 knowledge. One general comment though, > > Sending a Neighbour solicitation (or even worse router solicitation) only > > > > => I agree about a NS is better than a RS. > > What would the target address be? > > => the link-local router address. If the purpose is to know if the router > is alive, a NS is simply enough... > > Regards > > Francis.Dupont@enst-bretagne.fr > > PS: if you'd like to use an IPv6 packet for a beacon then something > like an empty no-next-header to a (new) multicast link-local "all-MN" > address is enough and the cheaper. Please keep RAs for more useful things... From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Sep 16 11:25: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 SMTP id LAA15431 for ; Sat, 16 Sep 2000 11:25:26 -0400 (EDT) Received: from standards (47.234.32.16:4959) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB946AC@standards.nortelnetworks.com>; Sat, 16 Sep 2000 11:10:07 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12217 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 16 Sep 2000 11:10:06 -0400 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB946AB@standards.nortelnetworks.com>; Sat, 16 Sep 2000 11:10:04 -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 e8GFNWu28109; Sat, 16 Sep 2000 17:23:32 +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 RAA28453; Sat, 16 Sep 2000 17:23:32 +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 RAA06555; Sat, 16 Sep 2000 17:25:01 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-ID: <200009161525.RAA06555@givry.rennes.enst-bretagne.fr> Date: Sat, 16 Sep 2000 17:25: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] IPv6 handover document X-To: Chern Nam Yap To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Sat, 16 Sep 2000 15:34:24 BST. <011d01c01feb$367fe1a0$2c0ba78f@dcs.shef.ac.uk> In your previous mail you wrote: Agree on that point of using RA as beacon is very bad idea. => RA = IPv6 router advertisements. If the key issue here is to allow mobile node to determine change in Network Prefix. The simpliest, fastest, most feasible way currently that IETF can "talk about" is using IIP method of doing handoff. That is: by looking at the co-located IP address (Network Prefix) that PPP server issue during PPP setup session. => this is not for IPv6 (no PPP, no prefix, ...). But if you mean a PPP shutdown-setup helps movement detection it is true (basic interface change with no interface in the middle of the operation) but new radio links no more use PPP (or do you suggest PPPoE?) even if UTMS will have some kind of point-to-point communication at the layer 2 between BSS and phone *. Hence no matter how fast, or how quick any IP handoff is, the ultimate limit lies with link layer handover. => but this is out of the scope of the WG. Regards Francis.Dupont@enst-bretagne.fr PS *: don't ask why we won't be able to do direct phone to phone communication (:-). From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Sep 16 12:12: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 SMTP id MAA15699 for ; Sat, 16 Sep 2000 12:12:28 -0400 (EDT) Received: from standards (47.234.32.16:3066) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB946F0@standards.nortelnetworks.com>; Sat, 16 Sep 2000 11:57:11 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12310 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 16 Sep 2000 11:57:11 -0400 Received: from cedar.dcs.shef.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB946EF@standards.nortelnetworks.com>; Sat, 16 Sep 2000 11:57:10 -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 RAA22852; Sat, 16 Sep 2000 17:10:37 +0100 (BST) References: <200009161525.RAA06555@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 Content-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.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: <015f01c01ff8$e1c7ebe0$2c0ba78f@dcs.shef.ac.uk> Date: Sat, 16 Sep 2000 17:12:11 +0100 Reply-To: Chern Nam Yap Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Chern Nam Yap Subject: Re: [MOBILE-IP] IPv6 handover document X-To: Francis Dupont To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi ----- Original Message ----- From: "Francis Dupont" To: "Chern Nam Yap" Cc: Sent: Saturday, September 16, 2000 4:25 PM Subject: Re: [MOBILE-IP] IPv6 handover document > In your previous mail you wrote: > > Agree on that point of using RA as beacon is very bad idea. > > => RA = IPv6 router advertisements. yup! > > If the key issue here is to allow mobile node to determine change in Network > Prefix. > > The simpliest, fastest, most feasible way currently > that IETF can "talk about" is using IIP method of doing handoff. > > That is: > by looking at the co-located IP address (Network Prefix) > that PPP server issue during PPP setup session. > > => this is not for IPv6 (no PPP, no prefix, ...). But if you mean a PPP > shutdown-setup helps movement detection it is true (basic interface change > with no interface in the middle of the operation) but new radio links 1) IPv6 have PPP RFC 2472 2) IPv6 support IPv6CP > no more use PPP (or do you suggest PPPoE?) Forget about using 802.11, that is old technology with lots of holes. There are many new technology out there now like Bluetooth, HiperLan, LMDS, CDMA, GPRS..... > even if UTMS will have some > kind of point-to-point communication at the layer 2 between BSS and phone *. > 1) GPRS uses PPP to connect to Mobile station (101 348 version 7.2) 2) CDMA2000 uses PPP. (July 2000 version) TSG-P version 1-A I am sorry that I am not getting the latest version, and I am will grateful if you can provide me with the information that you have. Moreover, it will be even better if you can provide me with realistic equipment to try with, especially W-CDMA/CDMA 2000. > Hence no matter how fast, or how quick any IP handoff is, > the ultimate limit lies with link layer handover. > > => but this is out of the scope of the WG. > I suppose it is true that anything about link layer is out of the scope of this WG But, what i am trying to say is that PPP is a link layer protocol, The speed of handoffs lies with link layer connection. ---------------------------------------------------------------------------- --- 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 Sat Sep 16 12:46: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 SMTP id MAA15892 for ; Sat, 16 Sep 2000 12:46:27 -0400 (EDT) Received: from standards (47.234.32.16:3066) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9474A@standards.nortelnetworks.com>; Sat, 16 Sep 2000 12:31:07 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12412 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 16 Sep 2000 12:31:07 -0400 Received: from web3904.mail.yahoo.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB94739@standards.nortelnetworks.com>; Sat, 16 Sep 2000 12:21:06 -0400 Received: from [216.113.45.83] by web3904.mail.yahoo.com; Sat, 16 Sep 2000 09:34:39 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20000916163439.29191.qmail@web3904.mail.yahoo.com> Date: Sat, 16 Sep 2000 09:34:39 -0700 Reply-To: sarikaya@u-aizu.ac.jp Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Behcet Sarikaya Subject: Re: [MOBILE-IP] IPv6 handover document X-To: Francis.Dupont@ENST-BRETAGNE.FR To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --- Francis Dupont wrote: Thanks Francis for providing the right insight at the right time: > => RAs are too expensive to build, too expensive to > send, too expensive > to process. In fact they are not designed for this > role and a dedicated > mechanism should be far better when a fast beacon is > needed. if there is a good reason to use very > special timings > then there should be a good reason to build a > dedicated/simpler/cheaper > mechanism. Reuse is not perversion! As we move in the direction of layer 3-ization of handoffs, paging, etc. there seems to be a need for designing a fast beacon mechanism. --behcet ===== Behcet Sarikaya Univ. of Aizu Aizu, Japan __________________________________________________ Do You Yahoo!? Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Sep 16 13:00: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 SMTP id NAA15980 for ; Sat, 16 Sep 2000 13:00:04 -0400 (EDT) Received: from standards (47.234.32.16:3066) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9478C@standards.nortelnetworks.com>; Sat, 16 Sep 2000 12:44:43 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12524 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 16 Sep 2000 12:44:43 -0400 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9478B@standards.nortelnetworks.com>; Sat, 16 Sep 2000 12:44:42 -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 e8GGwAu28981; Sat, 16 Sep 2000 18:58:10 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA28966; Sat, 16 Sep 2000 18:58:10 +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 SAA06872; Sat, 16 Sep 2000 18:59:39 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-ID: <200009161659.SAA06872@givry.rennes.enst-bretagne.fr> Date: Sat, 16 Sep 2000 18:59:39 +0200 Reply-To: Francis.Dupont@ENST-BRETAGNE.FR Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] IPv6 handover document X-To: Chern Nam Yap To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Sat, 16 Sep 2000 17:12:11 BST. <015f01c01ff8$e1c7ebe0$2c0ba78f@dcs.shef.ac.uk> In your previous mail you wrote: > => RA = IPv6 router advertisements. yup! => it was just in order to fix the context (before someone begins to talk about the FA :-). > => this is not for IPv6 (no PPP, no prefix, ...). 1) IPv6 have PPP RFC 2472 2) IPv6 support IPv6CP => which is described in RFC 2472 and has nothing like subnet prefix negociation. IPv6CP has two functions (no more): negociate a different interface ID at the two ends, negociate compression protocol (we moved from zero possibilities to one, not too hard to do :-). Prefix acquisition is done by the RA from the other end (which should be a router) and is part of the standard "new link" sequence. This is more general than PPP. > no more use PPP (or do you suggest PPPoE?) Forget about using 802.11, that is old technology with lots of holes. => not yet convinced... 802.11 had large successes at last IETF meetings and I know many places where 802.11b equipment is bought these days (I agree this doesn't make 802.11 a good techno, but this makes Lucent shares attractive :-). There are many new technology out there now like Bluetooth, => a security hole announced? HiperLan, => I can sell to you some photos of HiperLAN 1 devices. It should be very expensive in some years (:-). LMDS, => not yet CDMA, => not living in USA GPRS => not this year (last news from France Telecom) > even if UTMS will have some > kind of point-to-point communication at the layer 2 between BSS and phone 1) GPRS uses PPP to connect to Mobile station (101 348 version 7.2) 2) CDMA2000 uses PPP. (July 2000 version) TSG-P version 1-A => I have heard 3GPP*&co people want to replace PPP by something else. It is too late for GPRS/GSM but not for GPRS/UTMS or CDMA2k. Of course, I have no accurate document about the new choice but even PPP has many advantages it seems everybody gives up PPP... I am sorry that I am not getting the latest version, and I am will grateful if you can provide me with the information that you have. Moreover, it will be even better if you can provide me with realistic equipment to try with, especially W-CDMA/CDMA 2000. => I am sorry but I have not last documents (help) nor CDMA devices (I'm in Europe too and you need the whole thing, not only a handset, and this is *more* than expensive today). I suppose it is true that anything about link layer is out of the scope of this WG => of course it is... But, what i am trying to say is that PPP is a link layer protocol, The speed of handoffs lies with link layer connection. => If I understand your idea is to mandate PPP because it is a simple and very well known link layer with a clear up/down state. You'd like to use it in order to control handoff by the network, this idea works and can be sold to mobile phone people but it will be hard with wireless LAN people... If you succeed it will simplify my code. Regards Francis.Dupont@enst-bretagne.fr (ENST= Telecom Engineer School, Bretagne= Brittany, FR= France (ISO IS 3166)) From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Sep 16 15:23: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 SMTP id PAA16658 for ; Sat, 16 Sep 2000 15:23:10 -0400 (EDT) Received: from standards (47.234.32.16:1805) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB94806@standards.nortelnetworks.com>; Sat, 16 Sep 2000 15:07:36 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12688 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 16 Sep 2000 15:07:35 -0400 Received: from cedar.dcs.shef.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB94805@standards.nortelnetworks.com>; Sat, 16 Sep 2000 15:07:35 -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 UAA03477; Sat, 16 Sep 2000 20:21:01 +0100 (BST) References: <200009161659.SAA06872@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 Content-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.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: <019a01c02013$786f4740$2c0ba78f@dcs.shef.ac.uk> Date: Sat, 16 Sep 2000 20:22:35 +0100 Reply-To: Chern Nam Yap Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Chern Nam Yap Subject: Re: [MOBILE-IP] IPv6 handover document X-To: Francis Dupont To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi > => which is described in RFC 2472 and has nothing like subnet prefix > negociation. IPv6CP has two functions (no more): negociate a different > interface ID at the two ends, negociate compression protocol (we moved from > zero possibilities to one, not too hard to do :-). > Prefix acquisition is done by the RA from the other end (which should be > a router) and is part of the standard "new link" sequence. This is more > general than PPP. Essentially, with mobile node detecting the end process of IPv6CP, and trigger the process to send RS for the required prefix will still better than waiting for the router to send one RA. In current state, this will be easier than strong cell switching for link layer. > > => not yet convinced... 802.11 had large successes at last IETF meetings > and I know many places where 802.11b equipment is bought these days > (I agree this doesn't make 802.11 a good techno, but this makes Lucent > shares attractive :-). > In the research point of view, 802.11 has more issue to get QoS in place. Moreover, it will take some effort to get strong cell switching technology into it. Due to the fact that many people having 802.11, it is even tougher get it done. > > There are many new technology out there now like Bluetooth, > => a security hole announced? > At this moment when fire is small. There is still time for the fireman. > HiperLan, > => I can sell to you some photos of HiperLAN 1 devices. It should be very > expensive in some years (:-). Pentium IV 2Ghz cost a lot too........ > LMDS, > => not yet Singapore has announce licensing for LMDS............. > CDMA, > => not living in USA I suppose you don't go IETF meeting then............ > GPRS > => not this year (last news from France Telecom) Obviously, they have spent about 25.1 billion pounds acquiring Orange ;) Trial running at Hong Kong, Singapore, London ........ Only few months more to 2001...... > > even if UTMS will have some > > kind of point-to-point communication at the layer 2 between BSS and phone > > 1) GPRS uses PPP to connect to Mobile station (101 348 version 7.2) > 2) CDMA2000 uses PPP. (July 2000 version) TSG-P version 1-A > > => I have heard 3GPP*&co people want to replace PPP by something else. > It is too late for GPRS/GSM but not for GPRS/UTMS or CDMA2k. > Of course, I have no accurate document about the new choice but > even PPP has many advantages it seems everybody gives up PPP... I believe that, Bluetooth is part of 3G If you have when to the IP over Bluetooth BOF, those guys has still give up Ethernet and ends up with PPP. May be you can ask them why. > > I am sorry that I am not getting the latest version, and I am will grateful > if you can provide me with the information that you have. > Moreover, it will be even better if you can provide me with > realistic equipment to try with, especially W-CDMA/CDMA 2000. > > => I am sorry but I have not last documents (help) nor CDMA devices > (I'm in Europe too and you need the whole thing, not only a handset, > and this is *more* than expensive today). > > That is why I hope someone in this mailing list will kindly provide me with some "input" ;-) > I suppose it is true that anything about link layer is out of the scope of > this WG > > => of course it is... > > But, what i am trying to say is that PPP is a link layer protocol, > The speed of handoffs lies with link layer connection. > > => If I understand your idea is to mandate PPP because it is a simple > and very well known link layer with a clear up/down state. You'd like > to use it in order to control handoff by the network, this idea works > and can be sold to mobile phone people but it will be hard with > wireless LAN people... If you succeed it will simplify my code. > Does WAP phone consider as "mobile phone people" or "wireless lan people". ---------------------------------------------------------------------------- --- 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 Mon Sep 18 11:29: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 SMTP id LAA11302 for ; Mon, 18 Sep 2000 11:29:09 -0400 (EDT) Received: from standards (47.234.32.16:1860) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB94D1C@standards.nortelnetworks.com>; Mon, 18 Sep 2000 11:12:49 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 14401 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 18 Sep 2000 11:12:49 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB94D17@standards.nortelnetworks.com>; Mon, 18 Sep 2000 11:02:47 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10985; Mon, 18 Sep 2000 11:16:19 -0400 (EDT) Message-ID: <200009181516.LAA10985@ietf.org> Date: Mon, 18 Sep 2000 11:16:19 -0400 Reply-To: The IESG Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: RFC822 error: CC field duplicated. Last occurrence was retained. Comments: RFC822 error: CC field duplicated. Last occurrence was retained. Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: The IESG Subject: [MOBILE-IP] Protocol Action: Mobile IP Challenge/Response Extensions to Proposed Standard To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM The IESG has approved the Internet-Draft 'Mobile IP Challenge/Response Extensions' as a Proposed Standard. This document is the product of the IP Routing for Wireless/Mobile Hosts Working Group. The IESG contact persons are David Oran and Rob Coltun. Technical Summary 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, from the point of view of the foreign agent, and does not allow for the use of existing techniques (such as CHAP) for authenticating portable computer devices. This specification, defines extensions for the Mobile IP Agent Advertisements and the Registration Request that allow a foreign agent to a use challenge/response mechanism to authenticate a mobile node that is roaming in it's serving area. Working Group Summary ---------------------- Two WG last calls have been completed on this draft since October '99, the most recent one in Jan 2000. The draft has undergone multiple revisions based on the feedback received by the authors via the discussion list and also at IETF46. WG members have not expressed any dissent about this draft. The TIA 45.6 body has been very supportive of this draft as this spec is a key component of the 3 wireless data architetcure put forth by them. Protocol Quality ---------------- The proposal in this I-D is the addition of three new extensions to Mobile IP. 1. Mobile IP Agent Advertisement Challenge Extension - Part of Agent Advertisement 2. MN-FA Challenge Extension - Registration request from the MN to the FA 3. Generalized Mobile IP Authentication Extension - This spec specifies the MN-AAA Authentication subtype associated with the Generalized Auth extension. This is also included in the Reg request coming from the MN Implementations of this I-D exist. The exact number is not known at this time. Mobile IP implementations at Connectathon 2000 (1st week of March) will be testing this feature. The results will be posted therefater. This specification was reviewed for the IESG by Dave Oran. Note to RFC Editor: 1) In Section 7 (Reserved SPIs for Mobile IP), please replace http://www.isi.edu/in-notes/iana/assignments/mobileip-numbers. with http://www.iana.org/numbers.html 2) In Section 11 (IANA Considerations), please replace must be specified and approved by the Mobile IP working group with must be specified and approved by a designated expert. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Sep 18 11:42: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 SMTP id LAA11737 for ; Mon, 18 Sep 2000 11:42:24 -0400 (EDT) Received: from standards (47.234.32.16:1860) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB94D30@standards.nortelnetworks.com>; Mon, 18 Sep 2000 11:16:49 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 14405 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 18 Sep 2000 11:16:48 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB94D1B@standards.nortelnetworks.com>; Mon, 18 Sep 2000 11:06:42 -0400 Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id e8IFKKZ01256; Mon, 18 Sep 2000 17:20:21 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id RAA15298; Mon, 18 Sep 2000 17:20:16 +0200 X-Mailer: Mozilla 4.75 [en] (Win95; U) X-Accept-Language: en, sv MIME-Version: 1.0 References: <399CEF1E.763D1800@era.ericsson.se> <39C26E31.38C6BB01@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39C6319C.F180AD2E@era.ericsson.se> Date: Mon, 18 Sep 2000 17:15:40 +0200 Reply-To: Mattias Pettersson Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Mattias Pettersson Organization: Ericsson Radio Systems AB Subject: Re: [MOBILE-IP] IPv6 handover document X-To: "Charles E. Perkins" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit "Charles E. Perkins" wrote: > Hello Matthias, > > Sorry for the extreme delay in my response to your note. > I hope you can remember what the discussion was! > > You mention cranking up the rate for IPv6 router advertisement. > Since the Mobile IPv6 document is now in Last Call, did you wish > to make a proposal about what the (maximum) rate should be? > > > Otherwise, if we assume the opposite with the ability to hear routers > > regardless of radio channels and have good enough overlap plus add some > > heuristics in reachability detection of routers and maybe crank up the RA rate > > a bit, good old Mobile IPv6 will do the work perfectly without our help! > > > > /Mattias Pettersson Hi, Well if we have good enough overlap, that is a few second window in where to do the handoff, the current ~1 RA/s is ok (section 6.5 in I-D 12). I agree that if the overlap is smaller than that, maybe we need another mechanism to detect movement, rather than flooding the link with RAs. /Mattias Pettersson From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Sep 18 12:41: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 SMTP id MAA14203 for ; Mon, 18 Sep 2000 12:41:19 -0400 (EDT) Received: from standards (47.234.32.16:1444) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB94DFE@standards.nortelnetworks.com>; Mon, 18 Sep 2000 12:24:08 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 14658 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 18 Sep 2000 12:24:08 -0400 Received: from tml-gw.tml.hut.fi (tml.hut.fi) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB94DE0@standards.nortelnetworks.com>; Mon, 18 Sep 2000 12:14:08 -0400 Received: (from smap@localhost) by tml-gw.tml.hut.fi (8.8.7/8.8.7) id TAA25439 for ; Mon, 18 Sep 2000 19:27:47 +0300 Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0) id xma025437; Mon, 18 Sep 00 19:27:43 +0300 Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7]) by mail.tml.hut.fi (8.11.0/8.11.0) with ESMTP id e8IGRgF09355 for ; Mon, 18 Sep 2000 19:27:42 +0300 (EEST) Received: from localhost (lpetande@localhost) by morphine.tml.hut.fi (8.9.2/8.7.1) with ESMTP id TAA02366 for ; Mon, 18 Sep 2000 19:27:40 +0300 (EET DST) X-Authentication-Warning: morphine.tml.hut.fi: lpetande owned process doing -bs MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Mon, 18 Sep 2000 19:27:40 +0300 Reply-To: Lars Henrik Petander Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Lars Henrik Petander Subject: [MOBILE-IP] Implementation question about MIPv6 and IPSec To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200007061715.TAA50311@givry.rennes.enst-bretagne.fr> Hello! We have implemented Mobile IPv6 for Linux, check http://www.mipl.mediapoli.com for more information. I am currently designing the addition and processing of the authentication header. According to RFC2460 extension headers should be added in the order they are going to be processed. In order to process a BU the datagram needs to be authenticated. However the Mobile IPv6 draft version 12 does not clearly define the place of the BU. Is there a reason for this ambiguity? I understand, that there are benefits in adding a BU before or after the AH and ESP, but the potential benefits are lost if one can't be sure of the location of the BU. IMO, it would be better if the BU was after the AH and ESP. Any opinions on this? Regards, Henrik Petander From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Sep 18 13:45: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 SMTP id NAA15851 for ; Mon, 18 Sep 2000 13:45:27 -0400 (EDT) Received: from standards (47.234.32.16:1659) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB94E7A@standards.nortelnetworks.com>; Mon, 18 Sep 2000 13:29:43 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 14850 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 18 Sep 2000 13:29:43 -0400 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB94E79@standards.nortelnetworks.com>; Mon, 18 Sep 2000 13:29:43 -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 e8IHfVu22964; Mon, 18 Sep 2000 19:41:32 +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 TAA19352; Mon, 18 Sep 2000 19:41:31 +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 TAA15981; Mon, 18 Sep 2000 19:43:12 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-ID: <200009181743.TAA15981@givry.rennes.enst-bretagne.fr> Date: Mon, 18 Sep 2000 19:43:12 +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 question about MIPv6 and IPSec X-To: Lars Henrik Petander To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Mon, 18 Sep 2000 19:27:40 +0300. In your previous mail you wrote: However the Mobile IPv6 draft version 12 does not clearly define the place of the BU. Is there a reason for this ambiguity? => there is no ambiguity because there is no good reason to put the BU after or before the AH. IMO, it would be better if the BU was after the AH and ESP. => I disagree but this is not the point. You may put it where you'd like but you must be able to find it in any reasonable position. Any opinions on this? => I can't see a reason to specify the BU position. I-D 12 is fine (for this point) for me. Regards Francis.Dupont@enst-bretagne.fr PS: do you know when your implementation will support secure mobile IPv6 (ie. Mobile IPv6 + IPsec, including IKE)? From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Sep 18 17:19: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 SMTP id RAA19884 for ; Mon, 18 Sep 2000 17:19:18 -0400 (EDT) Received: from standards (47.234.32.16:4311) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB94F61@standards.nortelnetworks.com>; Mon, 18 Sep 2000 17:03:28 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 15137 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 18 Sep 2000 17:03:28 -0400 Received: from netmail2.alcatel.com (hosta833.alcatel.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB94F60@standards.nortelnetworks.com>; Mon, 18 Sep 2000 17:03:27 -0400 Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id QAA16446; Mon, 18 Sep 2000 16:16:17 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id e8ILH4F08296; Mon, 18 Sep 2000 16:17:04 -0500 (CDT) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en,fr MIME-Version: 1.0 References: Content-Type: multipart/mixed; boundary="------------74701F65F7D998D477CD55D8" Message-ID: <39C680FA.21F94936@usa.alcatel.com> Date: Mon, 18 Sep 2000 15:54:18 -0500 Reply-To: Laurence Rose Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Laurence Rose Organization: ALCATEL USA Corporate Research Center Subject: Re: [MOBILE-IP] [Fwd: [MOBILE-IP] I-D ACTION:draft-elmalki-handoffsv6-00.txt] X-To: Natalia Syracuse To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------74701F65F7D998D477CD55D8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In this case thanks to annouce my draft. Regards Natalia Syracuse wrote: > If we are talking about WG mailing list I need a special request CC to a > different WG mailing list. If the draft is a WG document and has in its > filename a WG name, it goes automatical to WG mailing list. If a draft is an individual > submussion, please send me a note CC to a WG mailing list or some > organizations. I hope we understood each other :-) > > Natalia Syracuse > > On Mon, 18 Sep 2000, Laurence Rose wrote: > > > http://search.ietf.org/internet-drafts/draft-rose-mobileip-smm-00.txt > > I mean not announced by mail on the mailing list like some others. > > Best Regards > > > > Laurence > > --------------74701F65F7D998D477CD55D8 Content-Type: text/x-vcard; charset=us-ascii; name="Laurence.Rose.vcf" Content-Description: Card for Laurence Rose Content-Disposition: attachment; filename="Laurence.Rose.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rose;Laurence tel;work:972 996 3567 x-mozilla-html:FALSE url:www.alcatel.com org:ALCATEL USA Corporate Research Center adr:;;ALCATEL USA CRC - 1201 East Campbell Road - M/S 446-310;DALLAS;TEXAS;75081-1936;USA version:2.1 email;internet:Laurence.Rose@aud.alcatel.com title:Research Scientist fn:Laurence ROSE end:vcard --------------74701F65F7D998D477CD55D8-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Sep 19 16:33: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 SMTP id QAA24451 for ; Tue, 19 Sep 2000 16:33:48 -0400 (EDT) Received: from standards (47.234.32.16:3570) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9552A@standards.nortelnetworks.com>; Tue, 19 Sep 2000 16:17:48 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 16954 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 19 Sep 2000 16:17:48 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB95529@standards.nortelnetworks.com>; Tue, 19 Sep 2000 16:17: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 NAA27368 for ; Tue, 19 Sep 2000 13:31:30 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e8JKVT001668 for ; Tue, 19 Sep 2000 13:31:29 -0700 X-Virus-Scanned: Tue, 19 Sep 2000 13:31:29 -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) smtpdFydual; Tue, 19 Sep 2000 13:31:24 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: <39C7CD1C.431D3A36@iprg.nokia.com> Date: Tue, 19 Sep 2000 13:31:24 -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] Final list of changes To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello, I have completed a new revision for RFC 2002bis. Here is the list of changes since the last revision. If anyone has any additional comments, please let me know as soon as possible. Regards, Charlie P. ========================================================================= F.1. Changes since revision 02 of RFC2002bis This section lists the changes between this version (...-03.txt) and the previous version of the document. - Added a separate item describing the reserved 'r' bit in the Agent Advertisement extension and the Registration Request message. - Changed "admissible authentication extension" to "authorization-enabling extension". This removes the ambiguity by which it might otherwise have been possible to interpret Mobile-Foreign or Foreign-Home authentication extensions as "inadmissible". - Inserted 'T' bit into its proper place in the Registration Request message format (section 3.3). Changed the 'rsv' tag for the reserved field to be labeled 'x' instead, to make room for the 'T' bit. - Changed the preconfiguration requirements in section 3.6 for the mobile node to reflect the capability, specified in RFC 2794 [4], for the mobile node to identify itself by using its NAI, and then getting a home address from the Registration Reply. - Changed section 3.7.3.1 so that a foreign agent is not required to discard Registration Replies that have a Home Address field that does not match any pending Registration Request. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Sep 20 01:11:10 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA03020 for ; Wed, 20 Sep 2000 01:11:10 -0400 (EDT) Received: from standards (47.234.32.16:4707) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB957B1@standards.nortelnetworks.com>; Wed, 20 Sep 2000 0:55:06 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17793 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 20 Sep 2000 00:55:06 -0400 Received: from ns2.system-io.co.jp. (ns2.system-io.co.jp) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB957B0@standards.nortelnetworks.com>; Wed, 20 Sep 2000 0:45:04 -0400 Received: from gnr.net by ns2.system-io.co.jp. (SMI-8.6/SMI-SVR4) id NAA12269; Wed, 20 Sep 2000 13:58:50 +0900 Message-ID: <200009200458.NAA12269@ns2.system-io.co.jp.> Date: Wed, 20 Sep 2000 13:58:50 +0900 Reply-To: nile333@KADET.CO.UK Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: nile333@KADET.CO.UK Subject: [MOBILE-IP] So, How in the heck have you been? To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM So, How in the heck have you been? Do you remember holding previous conversations regarding business and money making opportunities? I did not send this to you in error! You Said: If only I could find an easier way to make a higher income! and If I had more money, I could spend more time with my Family, and less time at work and I sure could use more money so I could pay off my bills once and for all! And I would love to get involved in a business in which will generate money while I am not at work (like a Gas Pump)! Dear Friend, There is a possibility that we haven’t met, but you were chosen by someone to receive this E-Mail. Please, please, print this off and read thoroughly. Be sure that you don’t miss any of the points outlined. Then put it down, and then read it again. I am sending you a whole lot of information in which you might not understand the first time you read it. If you don’t believe this program will work for you, send it to 10-20 of your closest friends (in which you trust deeply), and ask them what they think? This really works! Have faith, don’t miss this opportunity, get involved also, and it will work for you as it does for us!!!! Due to the popularity of this letter on the Internet, A Major Nightly News Program recently dedicated an entire show to the investigation of the program described below to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved that there are absolutely no laws prohibiting the participation in the program. This has helped to show people that this is a simple, harmless and fun way to make extra money at home. The results have been truly remarkable. So many people are participating that those involved are doing much better than ever before. Since everyone makes more as more people try it out, its been very exciting. You will understand only if you get involved! ********** THE ENTIRE PLAN IS HERE BELOW ********** **** Print This Now For Future Reference **** $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make AT LEAST $50,000 in less than 90 days! If not, forward this to someone who would like to make this kind of money. It works (like designed) but only for those who follow it to the letter! Please read this program THEN READ IT AGAIN!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ THIS IS A LEGITIMATE. LEGAL, MONEY MAKING OPPORTUNITY!! It does NOT require you to come into contact with people or make or take any telephone calls. Just follow the instructions, and you will make money. This simplified e-mail marketing program works perfectly 100% EVERY TIME! E-mail is the sales tool of the future. Take advantage of this virtually free method of advertising NOW!!! The longer you wait, the more people will be doing business using e-mail. Get your piece of this action!!! Hello, My name is Johnathon Rourke, I’m from Rhode Island. The enclosed information is something I almost let slip through my fingers. Fortunately, sometime later I re-read everything and gave some thought and study to it. Two years ago, the corporation I worked for the past twelve yearsdown-sized and my position was eliminated. After unproductive job interviews, I decided to open my own business. Over the past year,I incurred many unforeseen financial problems. I owed my family, friends and creditors over$35,000. The economy was taking a toll on my business and I just could not seem to make ends meet. I had to refinance and borrow against my home to support my family and struggling business. AT THAT MOMENT something significant happened in my life. I am writing to share the experience I hopes that this could change your life FOREVER. FINANCIALLY$$$!!! In mid December, I received this program in my e-mail. Six months prior to receiving this program I had been sending away for information on various business opportunities. All of the programs I received, in my opinion,were not cost effective. They were either toodifficult for me to comprehend or the initial investment was too muchfor me to risk to see if they would work. But as I was saying, in December of 1997 I received this program.I didn’t send for it, or ask for it, they just got my name off a mailing list. THANK GOODNESS FOR THAT!!! After reading it several times, to make sure I was reading it correctly. I couldn’t believe my eyes! Here was a MONEY MAKING MACHINE I could start immediately without any debt. Like most of you I was still a little skeptical and a little worried about the legalaspects of it all. So I checked it out with the U.S. Post Office (1-800-725-2161 24-hrs) and they confirmed that it is indeed legal ! After determining the program was LEGAL I decided WHY NOT!?!?? Initially I sent out 10,000 e-mails. It cost me about $15 for my time on-line. The great thing about e-mail is that I don’t need any paper for printing to send out the program, and because I also send the product (reports) by e-mail, my only expense is my time. In less than one week,I was starting to receive orders for REPORT #1. By January 13, I had received 26 orders for REPORT #1. Your goal is to RECEIVE at least 20 ORDERS FOR REPORT #1 WITHIN 2 WEEKS. IF YOU DON’T SEND OUT MORE PROGRAMS UNTIL YOU DO. My first step in making $50,000 in 90 days was done. By January 30, I had received 196 orders for REPORT #2. Your goal is to RECEIVE AT LEAST 100+ ORDERS FOR REPORT #2 WITHIN 2 WEEKS. IF NOT SEND OUT MORE PROGRAMS UNTIL YOU! DO. ONCE YOU HAVE 100 ORDERS, THE REST IS EASY, RELAX, YOU WILL MAKE YOUR $50,000 GOAL. Well, I had 196 orders for REPORT #2. 96 more than I needed. So I sat back and relaxed. By March 1, of my e-mailing of 10,000, received $58,000 with more coming in every day. I paid off ALL my debts and bought a much need new car! Please take your time to read this plan, IT WILL CHANGE YOUR LIFE FOREVER$!!! Remember, it won’t work if you don’t try it. This program does work, But you must follow it EXACTLY! Especially the rules of not trying to place your name in a different place. It won’t work and you’ll lose out on a lot of money! In order for this program to work, you must meet your goal of 20+ orders for REPORT #1, and 100+ orders for REPORT #2 and you will make $50,000 or more in 90 days. I AM LIVING PROOF THAT IT WORKS!!! If you choose not to participate in this program, I am sorry. It really is a great opportunity with little cost or risk to you. If you choose toparticipate, follow the program and you will be on your way to financial security. If you are a fellow business owner and are financial trouble like I was, or you want to start your own business, consider this a sign. I DID! $$ Sincerely, Johnathon Rourke A PERSONAL NOTE FROM THE ORIGINATOR OF THIS PROGRAM: By the time you have read the enclosed program and reports, you should have concluded that such a program, and one that is legal, cpuld not have been created by an amateur. Let me tell you a little about myself. I had a profitable business for 10 years. Then in 1979 my business began falling off. I was doing the same things that were previously successful for me, but it wasn’t working. Finally, I figured it out. It wasn’t me, it was the economy. Inflation and recession had replaced the stable economy that had been with us since 1945. I don’t have to tell you what happened to the unemployment rate because many of you know from first hand experience. There were more failures and bankruptcies than ever before. The middle class was vanishing. Those who knew what they were doing invested wisely and moved up. Those who did not, including those who never had anything to save or invest, were moving down into the ranks of the poor. As the saying goes, THE RICH GET RICHER ANDTHE POOR GET POORER. The traditional methods of making money will never allow you to move up or get rich, inflation will see to that You have just received the rest of your life, with NO RISK and JUST A LITTLE BIT OF EFFORT. You can make more money in the next few months than you have everimagined.I should also point out that I will not see a penny of this money, nor anyone else who has provided a testimonial for this program. I retired from the program after sending thousands and thousands of programs. Follow the program EXACTLY AS INSTRUCTED. Do not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copyof this exciting report to everyone you can think of. One of the people you send this to may send out 50,000 and your name will be on everyone of them! REMEMBER though, ------ the MORE YOU SEND OUT, the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU!! NOW DO IT!! BEFORE YOU delete this program from your in box, as I almost did, take a little time to read it and REALLY THINK ABOUT IT. Get a pencil and figure out what could happen when YOU participate. Figure out the worst possible response and no matter how you calculate it, you will still make a lot of money! You will definitely get back what you invested. Any doubts you have will vanish when your first orders come in. $$$ IT WORKS!!! $$$ Jody Jacobs Richmond, VA. HERE’S HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS OF DOLLARS$$$$!!!! This method of raising capital REALLY WORKS 100% EVERY TIME. I am sure that you could use up to $50,000 or more in the next 90 days. Before you say BULL, please read this program carefully. This is not a chain letter,but a perfectly legal money making business. As with all multi-level businesses, we build our business by recruiting new partners and selling our products. Every state in the USA allows you to recruit new multi-level business partners, and we sell and deliver a product for EVERY dollar received. YOUR ORDERS COME BY MAIL AND ARE FILLED BY E-MAIL, so you are not involved in personal selling. You do it privately in your own home, store or office. This is the EASIEST marketing plan anywhere! It is simply order filling by e-mail! The product is informational and instructional material, keys to the secrets for everyone on how to open the doors to the magic world of E-COMMERCE, the information highway, the wave of the future ! PLAN SUMMARY: (1) You order the 4 reports listed below ($5 each) They come to you by e-mail. (2) Save a copy of this entire letter and put your name after Report #1 and move the other names down. (3) Via the internet, access Yahoo.com or any of the other major search engines to locate hundreds of bulk e-mail service companies (search for bulk email) and have them send 25,000 50,000 emails for you about $49+. (4) Orders will come to you by postal mail simply e-mail them the Report they ordered. Let me ask you isn’t this about as easy as it gets? By the way there are over 50 MILLION e-mail address with millions more joining the internet each year so don’t worry about running out or saturation. People are used to seeing and hearing the same advertisements every day on radio/TV. How many times have you received the same pizza flyers on your door? Then one day you are hungry for pizza and order one. Same thing with this letter. I received this letter many times then one day I decided it was time to try it. YOU CAN START TODAY UST DO THESE EASY STEPS: STEP #1 ORDER THE FOUR REPORTS Order the four reports shown on the list below (you can’t sell them if you don’t order them). For each report, send $5.00 CASH, the NAME & NUMBER OF THE REPORT YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR NAME & RETURN ADDRESS (in case of a problem) to the person whose name appears on the list next to the report.MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE IN CASE OF ANY MAIL PROBLEMS! Within a few days you will receive, by e-mail each of the four reports.Save them on your computer so you can send them to the 1,000’s of people who will order them from you. STEP #2. ADD YOUR MAILING ADDRESS TO THIS LETTER a. Look below for the listing of the four reports. b. After you’ve ordered the four reports, delete the name and address under REPORT #4. This person has made it through the cycle. c. Move the name and address under REPORT #3 down to REPORT #4. d. Move the name and address under REPORT #2 down to REPORT #3. e. Move the name and address under REPORT #1 down to REPORT #2. f. Insert your name/address in the REPORT #1 position. Please make sure you COPY ALL INFORMATION, every name and address, ACCURATELY! STEP #3. Take this entire letter, including the modified list of names, and save it to your computer. Make NO changes to these instructions. Now you are ready to use this entire e-mail to send by e-mail to prospects. Report #1 will tell you how to download bulk email software and email address so you can send it out to thousands of people while you sleep! Remember that 50,000+ new people are joining the internet every month! Your cost to participate in this is practically nothing ( surely you can afford $20 and initial bulk mailing cost). You obviously already have a computer and an Internet connection and e-mail is FREE! There are two primary methods of building your downline: METHOD #1: SENDING BULK E-MAIL let’s say that you decide to start small, just to see how it goes, and we’ll assume you and all those involved email out only 2,000 programs each. Let’s also assume that the mailing receives a 0.5% response. The response could be much better. Also, many people will email out thousands of thousands of programs instead of 2,000 (Why stop at 2000?) But continuing with this example, you send out only 2,000 programs. With a 0.5% response, that is only 10 orders for REPORT #1. Those 10 people respond by sending out 2,000 programs each for a total of 20,000. Out of those 0.5%, 100 people respond and order REPORT #2.Those 100 mail out 2,000 programs each for a total of 200,000. The 0.5% response to that is 1,000 orders for REPORT #3. Those 1,000 send out 2,000 programs each for a 2,000,000 total. The 0.5% response to that is 10,000 orders for REPORT #4. That’s 10,000 $5 bills for you. CASH!!! Your total income in this example is $50 + $500 + $5000 + $50,000 for a total of $55,550!!! REMEMBER FRIEND, THIS IS ASSUMING 1,990 OUT OF THE 2,000 PEOPLE YOU MAIL TO WILL DO ABSOLUTELY NOTHING AND TRASH THIS PROGRAM! DARE TO THINK FOR A MOMENT WHAT WOULD HAPPEN IF EVERYONE, OR HALF SENT OUT 100,000 PROGRAMS INSTEAD OF 2,000. Believe me, many people will do just that, and more! METHOD #2 PLACING FREE ADS ON THE INTERNET Advertising on the internet is very, very inexpensive, and there are HUNDREDS of FREE places to advertise. Let’s say you decide to start small to see how well it works. Assume your goal is to get ONLY 10 people to participate on your first level. (Placing a lot of FREE ads on the Internet will EASILY get a larger response). Also assume that everyone else in YOUR ORGANIZATION gets only 10 downline members. Look how this small number accumulates to achieve the STAGGERING results below: 1St level your first 10 send you $5........................$50 2nd level 10 members from those 10 ($5 x 100)............$500 3rd level 10 members from those 100 ($5 x 1,000)......$5,000 4th level 10 members from those 1,000 ($5 x 10,000)..$50,000 $$$$$$ THIS TOTALS ------------------------------------------------55,5550 $$$$$ AMAZING ISN’T IT Remember friends, this assumes that the people who participate only recruit 10 people each. Think for a moment what would happen if they got 20 people to participate! Most people get 100’s of participants and many will continue to work this program, sending out programs WITH YOUR NAME ON THEM for years! THINK ABOUT IT! People are going to get emails about this plan from you or somebody else and many will work this plan the question is Don’t you want your name to be on the emails they will send out? *** DON’T MISS OUT !!!*** ***JUST TRY IT ONCE !!!*** ***SEE WHAT HAPPENS !!!*** ***YOU'LL BE AMAZED !!!*** ALWAYS PROVIDE SAME DAY SERVICE ON ALL ORDERS! This will guarantee that the e-mail THEY send out with YOUR name and address on it will be prompt because they can’t advertise until they receive the report! GET STARTED TODAY: PLACE YOUR ORDER FOR THE FOUR REPORTS NOW. Note:-- ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR EACH REPORT. CHECKS NOT ACCEPTED. Make sure the cash is concealed by wrapping it in two sheets of paper. On one of those sheets write: (a) the number & name of the report you are ordering (b) your e-mail address, and (c) your name & postal address. REPORT #1b The Insider’s Guide to Advertising for Free on the Internet ORDER REPORT #1 FROM: NICK NICHOLAS 473 MICHIGAN ST ST.PAUL, MN 55102 NOTE: I and every member below are dedicated at helping you with this program so it will work for you also. TRY US! REPORT #2 The Insider’s Guide to Sending Bulk E-Mail on the Internet ORDER REPORT #2 FROM: DIANE COLON 1811 TAMARIND AVE # 206 LOS ANGELES, CA. 90028 REPORT #3 The Secrets to Multilevel Marketing on the Internet ORDER REPORT #3 FROM: MELISSA HOGENMILLER 3709 MONHEIM ROAD CONOVER, WI 54519 REPORT #4 How to become a Millionaire utilizing the Power of Multilevel Marketing and the Internet ORDER REPORT #4 FROM: CATHY BARROW 10 SYCAMORE STREET CONWAY, SC 29527 *************TIPS FOR SUCCESS*************** TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the directions accurately. Send for the four reports IMMEDIATELY so you will have them when the orders start coming in because: When you receive a $5 order you MUST send out the requested product/report. It is required for this to be a legal business and they need the reports to send out their letter (with your name on them). --ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. Be patient and persistent with this program- If you follow the instructions exactly results WILL FOLLOW. $$$$ ************ YOUR SUCCESS GUIDELINES *************** Follow these guidelines to guarantee your success: If you don’t receive 20 orders for REPORT #1 within two weeks, continue advertising or sending e-mail until you do. Then a couple of weeks later you should receive at least 100 orders for REPORT #2. If you don’t continue advertising or sending e-mail until you do. Once you have received 100 or more orders for REPORT #2, YOU CAN RELAX, because the system is already working for you, and the cash will continue to roll in! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in front of a DIFFERENT report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. To generate more income, simply send another batch of e-mails or continue placing ads and start the whole process again! There is no limit to the income you will generate from this business! Before you make your decision as to whether or not you participate in this program. Please answer one question: ARE YOU HAPPY WITH YOUR PRESENT INCOME OR JOB? 1. If the answer is no, then please look at the following facts about this super simple MLM program: NO face to face selling, NO meetings, NO inventory! NO Telephone calls, NO big cost to start! Nothing to learn, No skills needed! (Surely you know how to send email?) 2. No equipment to buy you already have a computer and internet connection so you have everything you need to fill orders! 3. You are selling a product which does NOT COST ANYTHING TO PRODUCE OR SHIP! (Email copies of the reports are FREE!) 4. All of your customers pay you in CASH! This program will change your LIFE FOREEVER!! Look at the potential for you to be able to quit your job and live a life of luxury you could only dream about! Imagine getting out of debt and buying the car and home of your dreams and being able to work a super-high paying leisurely easy business from home! $$$ FINALLY MAKE SOME DREAMS COME TRUE! $$$ ACT NOW! Take your first step toward achieving financial independence. Order the reports and follow the program outlined above __ SUCCESS will be your reward. Thank you for your time and consideration. PLEASE NOT: If you need help with starting a business, registering a business name, learning now income tax is handled, etc., contact your local office of the Small Business Administration (A Federal Agency) 1-800-827-5722 for free help and answers to questions. Also the Internal Revenue Service offers free help via telephone and free seminars about business tax requirements. Your earnings are highly dependent on your activities and advertising. The information contained on this site and in the report constitutes no guarantees stated nor implied. In the event that it is determined that this site or report constitutes a guarantee of any kind, that guarantee is now void. The earnings amounts listed on this site and in the report are estimates only. If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection in Washington DC. Under Bill s.1618 TITLE III passed by the 105th US Congress this letter cannot be considered spam as long as the sender includes contact information and a method of removal. This is a one time e-mail transmission. No request for removal is necessary. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Sep 20 07:13: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 SMTP id HAA18265 for ; Wed, 20 Sep 2000 07:13:17 -0400 (EDT) Received: from standards (47.234.32.16:1760) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB958FA@standards.nortelnetworks.com>; Wed, 20 Sep 2000 6:57:26 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18226 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 20 Sep 2000 06:57:25 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB958F9@standards.nortelnetworks.com>; Wed, 20 Sep 2000 6:47:25 -0400 Received: from okis-02.okis.com.tw (c162.h202052124.is.net.tw [202.52.124.162]) by hosaka.smallworks.com (8.9.1/8.9.1) with SMTP id GAA07727; Wed, 20 Sep 2000 06:01:02 -0500 (CDT) Received: from amele.com [202.52.124.163] by okis-02.okis.com.tw (SMTPD32-4.03) id AC693A5030A; Wed, 20 Sep 2000 19:03:21 PDT Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Message-ID: <609.302768.467892@amele.com> Date: Wed, 20 Sep 2000 06:57:25 -0400 Reply-To: mythilin@AMELE.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: mythilin@AMELE.COM Subject: [MOBILE-IP] Don't throw money away!!! To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM YOU SPOKE AND WE LISTENED

THE BEST JUST GOT BETTER

E-Commerce Solutions for a fraction of the cost.

If you apply within 72 Hours, you are entitled to:
* Free Technical Training
* Free Electronic Shopping Cart
* Free Hosting
* Free Search Engine Submission
* Free E-Checks
* Free Marketing Package
* Free Internet Access
* Free Custom Referral Website
* Plus the cheapest Merchant Account on the Net!!!

Our Merchant Account has the Lowest Rates on the Net or anywhere!!!
* Discount Rates of 1.55 and 2.1;
* Transaction Fees of $.20 and $.25

Plus you will also receive:
Pre-approved Merchant Account and Internet processing software for your website, in Real Time;
Accept all Major Credit Cards Online Now;
Custom built order page;
We will waive the $195 application and set-up fee
Once registered you are automatically enrolled in our Referral Program;

Plus the Best Websites with Total E-Commerce Solutions in Existence.
We will build you a Custom Website with:
Merchant Account (real time processing)
Free Hosting
Free Search Engine Submission
Free Electronic Shopping Cart
Free E-Checks (ACH)
Free Marketing Package
Free Custom Referral Website
Free Technical Training

For more information simply fill out the following form

 
Your Name:
Your Age:
Company Name:
State:
Business Phone:
Home Phone:
Email:
Type of Business:

 
                                  
        
                                    
 If you received this in error or would like to be removed from our list, PLEASE CLICK HERE

This message is being sent to you in compliance with the proposed Federal legislation for commercial e-mail (S.1618 – SECTION 301). "Pursuant to Section 301, Paragraph (a)(2)(C) of S. 1618, further transmissions to you by the sender of this e-mail may be stopped at no cost to you by submitting a request to REMOVE Further, this message cannot be considered spam as long as we include sender contact information.

From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Sep 20 14:57: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 SMTP id OAA02105 for ; Wed, 20 Sep 2000 14:57:45 -0400 (EDT) Received: from standards (47.234.32.16:1346) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB95B6A@standards.nortelnetworks.com>; Wed, 20 Sep 2000 14:41:47 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19060 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 20 Sep 2000 14:41:47 -0400 Received: from clea.qualcomm.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB95B69@standards.nortelnetworks.com>; Wed, 20 Sep 2000 14:41:45 -0400 Received: from mlioy (mlioy.qualcomm.com [129.46.219.140]) by clea.qualcomm.com (8.9.3/8.9.3/1.0) with ESMTP id LAA20288 for ; Wed, 20 Sep 2000 11:55:23 -0700 (PDT) X-Sender: mlioy@mail1.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.2.2.20000920114504.00d68360@mail1.qualcomm.com> Date: Wed, 20 Sep 2000 11:53:11 -0700 Reply-To: Marcello Lioy Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Marcello Lioy Subject: [MOBILE-IP] Implementations of new extensions To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Does anyone know of any implementations of Mobile IP (preferably for Linux) that implement the NAI extension specified in RFC 2794 and the Foreign Agent Challenge (draft-ietf-mobileip-challenge-13.txt, which is soon to be an RFC)? I know about two or three straight 2002 implementations including the Sun one, but nothing else. Any help would be appreciated. ------------------------------------------------------------------ Marcello Lioy Voice: (619)651-8220 Qualcomm Inc. PGR: (619)635-0867 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Sep 20 17:09: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 SMTP id RAA08123 for ; Wed, 20 Sep 2000 17:09:29 -0400 (EDT) Received: from standards (47.234.32.16:2287) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB95C23@standards.nortelnetworks.com>; Wed, 20 Sep 2000 16:53:35 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19304 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 20 Sep 2000 16:53:35 -0400 Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB95C22@standards.nortelnetworks.com>; Wed, 20 Sep 2000 16:53:34 -0400 Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e8KL65l02078; Thu, 21 Sep 2000 00:06:05 +0300 (EET DST) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id ; Wed, 20 Sep 2000 16:02:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E2F1@daeis07nok> Date: Wed, 20 Sep 2000 16:02:49 -0500 Reply-To: Basavaraj.Patil@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: [MOBILE-IP] Mobile IPv6 Handoff Design team/effort X-cc: qa3445@email.mot.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello, At IETF48 two design teams were created to work on handoff solutions, one for Mobile IPv4 and another one for Mobile IPv6. This message is to let WG members know about the effort for the MIPv6 problem and the logistics. A discussion list has been setup for this and the address of this list is: mipv6-handoff@sunroof.eng.sun.com The list is open to anyone who wishes to contribute to this effort and anyone can be a part of the design team. Phil Roberts and myself will be co-ordinating this effort and if you have any questions, please let us know. -Basavaraj From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Sep 20 18:19: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 SMTP id SAA09465 for ; Wed, 20 Sep 2000 18:18:59 -0400 (EDT) Received: from standards (47.234.32.16:4568) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB95C79@standards.nortelnetworks.com>; Wed, 20 Sep 2000 18:03:24 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19414 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 20 Sep 2000 18:03:24 -0400 Received: from mgw-x1.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB95C78@standards.nortelnetworks.com>; Wed, 20 Sep 2000 18:03:24 -0400 Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-x1.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e8KMH6401081; Thu, 21 Sep 2000 01:17:07 +0300 (EET DST) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id ; Wed, 20 Sep 2000 17:13:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E305@daeis07nok> Date: Wed, 20 Sep 2000 17:13:00 -0500 Reply-To: Basavaraj.Patil@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: [MOBILE-IP] Mobile IPv6 Handoff Design team/effort (Discussion list) X-cc: qa3445@email.mot.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello, Quick note on the discussion list: mipv6-handoff@sunroof.eng.sun.com This list is majordomo supported -Basavaraj From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Sep 20 18:53: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 SMTP id SAA10227 for ; Wed, 20 Sep 2000 18:53:40 -0400 (EDT) Received: from standards (47.234.32.16:4568) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB95CEA@standards.nortelnetworks.com>; Wed, 20 Sep 2000 18:37:58 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19547 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 20 Sep 2000 18:37:58 -0400 Received: from 0015699886 (x142.dialup.conninc.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB95CDB@standards.nortelnetworks.com>; Wed, 20 Sep 2000 18:27:57 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 20 Sep 2000 18:37:58 -0400 Reply-To: "princess28677@yahoo.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "princess28677@yahoo.com" Subject: [MOBILE-IP] phone rates To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM I am looking for new customers who would like to save money on long distance phone calls? Heres the deal Excel Communications is the fastest growing Long Distance Company in the United States. We offer some of the most competitive Rates in the industry. Our state to state rates are priced as low as three ceants per minute. for complete details, Go to www.excelir.com\mrexcel Need a pager? Excel offers free pagers and no activation fees for new or existing long distance customers. Mounthly fees are 9.95 www.excelir.com\mrexcel IF THIS EMAIL IS AN ERROR AND UR NOT ON OUR LIST JUST EMAIL US BACK AND WE WILL TAKE U OFF. SORRY FOR THE INCOVIENCE. SINCERELY B.J MOOSE From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Sep 21 03:42:18 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01017 for ; Thu, 21 Sep 2000 03:42:16 -0400 (EDT) Received: from standards (47.234.32.16:3963) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB95E14@standards.nortelnetworks.com>; Thu, 21 Sep 2000 3:26:05 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19962 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 21 Sep 2000 03:26:04 -0400 Received: from odin2.bull.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB95E13@standards.nortelnetworks.com>; Thu, 21 Sep 2000 3:26:04 -0400 Received: from ecbull20.frec.bull.fr (ecbull20.frec.bull.fr [129.183.4.3]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA14398; Thu, 21 Sep 2000 09:43:22 +0200 Received: from isatis.frec.bull.fr (isatis.frec.bull.fr [129.183.144.1]) by ecbull20.frec.bull.fr (8.9.2/8.9.1) with ESMTP id JAA18380; Thu, 21 Sep 2000 09:37:54 +0200 Received: from bull.net (localhost [127.0.0.1]) by isatis.frec.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id JAA32574; Thu, 21 Sep 2000 09:37:50 +0200 (DFT) X-Mailer: Mozilla 4.06 [en] (X11; I; AIX 4.2) MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39C9BACD.5F685720@bull.net> Date: Thu, 21 Sep 2000 09:37:49 +0200 Reply-To: Aime.Le-Rouzic@BULL.NET Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: AIme Le-Rouzic Organization: Bull Subject: Re: [MOBILE-IP] Implementation question about MIPv6 and IPSec X-To: Lars Henrik Petander To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi, We are also implementing MobileIPv6 with IPSECv6 in AIX. For our opinion we choice to add the BU before the security headers for an easier implementation raison and to make it more accessible even ESP like it has been generalized for the HA. Regards. Lars Henrik Petander wrote: > > Hello! > > We have implemented Mobile IPv6 for Linux, check > http://www.mipl.mediapoli.com for more information. I am currently > designing the addition and processing of the authentication header. > > I understand, that there are benefits in adding a BU before or after the > AH and ESP, but the potential benefits are lost if one can't be sure of > the location of the BU. IMO, it would be better if the BU was after the AH > and ESP. Any opinions on this? > > Regards, > > Henrik Petander -- ________________________Aime LEROUZIC____________________________ BULL S.A ECHIROLLES FRANCE mailto:Aime.Lerouzic@frec.bull.fr http://www-frec.bull.com tel: +33 (0)4 76 29 75 51 Communications TCPIP http://intranet/lerouzic From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Sep 21 05:04:08 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA01612 for ; Thu, 21 Sep 2000 05:04:08 -0400 (EDT) Received: from standards (47.234.32.16:2451) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB95E57@standards.nortelnetworks.com>; Thu, 21 Sep 2000 4:48:14 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20046 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 21 Sep 2000 04:48:14 -0400 Received: from m018.com (210.112.10.141:47212) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB95E55@standards.nortelnetworks.com>; Thu, 21 Sep 2000 4:38:12 -0400 Received: from ns ([210.112.7.7]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Thu, 21 Sep 2000 17:49:10 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: <01a101c023a9$3e2c26e0$d012060a@hansol.co.kr> Date: Thu, 21 Sep 2000 17:52:16 +0900 Reply-To: "Lee, Jiwoong" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Lee, Jiwoong" Subject: [MOBILE-IP] Broadcast/Multicast transmission from MN To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Dear Authors of RFC2002 and bis-02. Is the nested encapsulation required or not when an MN broadcasts/multicasts a packet via a bi-directional tunneling ? This matter seems not addressed or not clarified. Jiwoong Lee From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Sep 21 11:28: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 SMTP id LAA07762 for ; Thu, 21 Sep 2000 11:28:48 -0400 (EDT) Received: from standards (47.234.32.16:2465) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB96091@standards.nortelnetworks.com>; Thu, 21 Sep 2000 11:12:47 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20767 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 21 Sep 2000 11:12:47 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB96090@standards.nortelnetworks.com>; Thu, 21 Sep 2000 11:12: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 IAA05672; Thu, 21 Sep 2000 08:26:35 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e8LFQVC12011; Thu, 21 Sep 2000 08:26:31 -0700 X-Virus-Scanned: Thu, 21 Sep 2000 08:26: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) smtpdqv0l1B; Thu, 21 Sep 2000 08:26:26 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <01a101c023a9$3e2c26e0$d012060a@hansol.co.kr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39CA28A5.7765F047@iprg.nokia.com> Date: Thu, 21 Sep 2000 08:26:29 -0700 Reply-To: charliep@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: Re: [MOBILE-IP] Broadcast/Multicast transmission from MN X-To: "Lee, Jiwoong" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Jiwoong Lee, This is something that should be clarified in RFC 2344{,bis}, if need be, but not in RFC 2002bis. To answer the question, though, I do not think that nested encapsulation is always required. The source IP address field can identify the mobile node. Regards, Charlie P. "Lee, Jiwoong" wrote: > > Dear Authors of RFC2002 and bis-02. > > Is the nested encapsulation required or not when > an MN broadcasts/multicasts a packet via a bi-directional > tunneling ? > > This matter seems not addressed or not clarified. > > Jiwoong Lee From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Sep 21 13:13: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 SMTP id NAA10218 for ; Thu, 21 Sep 2000 13:13:44 -0400 (EDT) Received: from standards (47.234.32.16:3793) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB961BF@standards.nortelnetworks.com>; Thu, 21 Sep 2000 12:57:21 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21084 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 21 Sep 2000 12:57:21 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB96193@standards.nortelnetworks.com>; Thu, 21 Sep 2000 12:47:20 -0400 Received: from kr04.piahost.net (IDENT:root@[211.53.209.164]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id MAA16772 for ; Thu, 21 Sep 2000 12:01:04 -0500 (CDT) Received: from sdn-ar-001tnknoxP246.dialsprint.net_[168.191.249.136] ([168.191.249.136]) by kr04.piahost.net (8.9.3/8.9.3) with SMTP id CAA23014; Fri, 22 Sep 2000 02:00:12 +0900 Received: from by sdn-ar-001tnknoxP246.dialsprint.net with ESMTP; Thu, 21 Sep 2000 13:01:06 -0400 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Message-ID: <0000375971ac$000024a5$000047cd@> Date: Thu, 21 Sep 2000 13:01:06 -0400 Reply-To: chocobo30@EARTHLINK.NET Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: chocobo30@EARTHLINK.NET Subject: [MOBILE-IP] Viagra Is For Everyone!! 18381 X-To: Undisclosed.Recipients@kr04.piahost.net To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: quoted-printable = Get VIAGRA



the breakthrough medication for impotence

delivered to your mailbox...



..without leaving your computer.



In less than 5 minutes you can complete the on-line consultation and in
many cases have the medication in 24 hours.



From our website to your mailbox.

On-line consultation for treatment of compromised sexual function.



Convenient...affordable....confidential.

We ship VIAGRA worldwide at US prices.



To Order Visit:http://www= .allthemeds.com/viagra.htm







Under Bill 1618 TITLE III passed by the 105th U.S. Congress

this letter can not be considered spam as long as we include:

Contact information & a Remove Link.

TO REMOVE CLICK ON mailto:y= en4u2@tokyo.com































 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Sep 22 03:19: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 SMTP id DAA03535 for ; Fri, 22 Sep 2000 03:19:42 -0400 (EDT) Received: from standards (47.234.32.16:4896) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB964F8@standards.nortelnetworks.com>; Fri, 22 Sep 2000 3:03:37 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 22227 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 22 Sep 2000 03:03:37 -0400 Received: from tml-gw.tml.hut.fi (tml.hut.fi) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB964F7@standards.nortelnetworks.com>; Fri, 22 Sep 2000 2:53:36 -0400 Received: (from smap@localhost) by tml-gw.tml.hut.fi (8.8.7/8.8.7) id KAA23285 for ; Fri, 22 Sep 2000 10:07:26 +0300 Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0) id xma023281; Fri, 22 Sep 00 10:07:20 +0300 Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7]) by mail.tml.hut.fi (8.11.0/8.11.0) with ESMTP id e8M77J502502; Fri, 22 Sep 2000 10:07:20 +0300 (EEST) Received: from localhost (lpetande@localhost) by morphine.tml.hut.fi (8.9.2/8.7.1) with ESMTP id KAA09461; Fri, 22 Sep 2000 10:07:10 +0300 (EET DST) X-Authentication-Warning: morphine.tml.hut.fi: lpetande owned process doing -bs MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Fri, 22 Sep 2000 10:07:10 +0300 Reply-To: Lars Henrik Petander Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Lars Henrik Petander Subject: Re: [MOBILE-IP] Implementation question about MIPv6 and IPSec X-To: AIme Le-Rouzic To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <39C9BACD.5F685720@bull.net> On Thu, 21 Sep 2000, AIme Le-Rouzic wrote: > Hi, > > We are also implementing MobileIPv6 with IPSECv6 in AIX. > For our opinion we choice to add the BU before the security headers for > an easier implementation raison and to make it more accessible even ESP > like it has been generalized for the HA. Thanks for your reply. I didn't however quite understand your comment on ESP and HA. Since the HA has a SA with the MN, it should also be able to decrypt the ESP payload or did I misunderstand your comment? In any case it needs to process the security headers, at least AH, before it can process the BU option. I think that the problem with adding BU before the AH, is that you need to add hooks to the AH processing (or after it) to know whether the BU was valid. This makes life difficult if you want to use a generic IPSecv6 implementation. When the AH is before the BU the processing is much more straightforward, since you already have the knowledge of a succesful authentication before you start the processing of the BU. With the BU in the second destination options header the protocol, besides being "cleaner" to implement would also comply better with RFC2460. BR, Henrik > > > Regards. > > Lars Henrik Petander wrote: > > > > Hello! > > > > We have implemented Mobile IPv6 for Linux, check > > http://www.mipl.mediapoli.com for more information. I am currently > > designing the addition and processing of the authentication header. > > > > > I understand, that there are benefits in adding a BU before or after the > > AH and ESP, but the potential benefits are lost if one can't be sure of > > the location of the BU. IMO, it would be better if the BU was after the AH > > and ESP. Any opinions on this? > > > > Regards, > > > > Henrik Petander > > -- > ________________________Aime LEROUZIC____________________________ > BULL S.A ECHIROLLES FRANCE mailto:Aime.Lerouzic@frec.bull.fr > http://www-frec.bull.com tel: +33 (0)4 76 29 75 51 > Communications TCPIP http://intranet/lerouzic > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Sep 22 05:13: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 SMTP id FAA04400 for ; Fri, 22 Sep 2000 05:13:02 -0400 (EDT) Received: from standards (47.234.32.16:4861) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB96570@standards.nortelnetworks.com>; Fri, 22 Sep 2000 4:57:10 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 22384 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 22 Sep 2000 04:57:10 -0400 Received: from esebh01nok.ntc.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9656F@standards.nortelnetworks.com>; Fri, 22 Sep 2000 4:57:09 -0400 Received: by esebh01nok with Internet Mail Service (5.5.2650.10) id ; Fri, 22 Sep 2000 12:10:08 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-7" Message-ID: Date: Fri, 22 Sep 2000 12:10:05 +0300 Reply-To: jonne.soininen@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: jonne.soininen@NOKIA.COM Subject: Re: [MOBILE-IP] the IGSN mystery (?) To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello, I'll try to answer some of the questions. Usage of MIP was discussed in 3GPP TSG SA WG2 Mobile IP Ad Hoc about a year ago. It produced a Technical Report on the feasibility of the usage Mobile IP for intra-system mobility management. The document number was 23.923 and you can find it on the 3GPP web site (http://www.3gpp.org/). The IGSN was a concept that was studied in this Ad Hoc. It was not found feasible at the time. You can find the reasons in the end of the 23.923. Cheers, Jonne. > -----Original Message----- > From: EXT Nakhjiri Madjid-MNAKHJI1 > [mailto:Madjid.Nakhjiri@MOTOROLA.COM] > Sent: 16. September 2000 0:35 > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] the IGSN mystery (?) > > > Christos, > > Could you please tell me which 3GPP or 3GPP2 working group the MIP > integration into 3G networks is being discussed? > > Thank you in advance, > > Madjid Nakhjiri > &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& > Madjid Nakhjiri mnakhji1@email.mot.com > Motorola, IP Network Standards > 1501 West Shure Drive,(IL27/2D5) > Arlington Heights, IL 60004 USA > Phone: +1 847-632-5030 Fax: +1 847-632-7912 > > It hurts to be on the cutting EDGE > &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& > > > -----Original Message----- > From: Christos Chrisanthakopoulos [mailto:xchr@INTRANET.GR] > Sent: Friday, September 15, 2000 1:56 AM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: [MOBILE-IP] the IGSN mystery (?) > > > Dear all, > > Regarding the stepwised integration of MIP in 3G networks > being proposed > > I would like to know if there is any additional information about > the IGSN node (more in focus details if possible) or is it > eventually that it behaves and functions more or less like > a GGSN in the CN? > > Thanks for your time > > Christos > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Sep 22 05:33: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 SMTP id FAA04489 for ; Fri, 22 Sep 2000 05:33:11 -0400 (EDT) Received: from standards (47.234.32.16:4861) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB965B9@standards.nortelnetworks.com>; Fri, 22 Sep 2000 5:17:19 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 22482 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 22 Sep 2000 05:17:18 -0400 Received: from news.comp.lancs.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB965B8@standards.nortelnetworks.com>; Fri, 22 Sep 2000 5:17:18 -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 e8M9Rth15322; Fri, 22 Sep 2000 10:27:55 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Message-ID: Date: Fri, 22 Sep 2000 10:25:26 +0100 Reply-To: Stefan Schmid Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Stefan Schmid Subject: Re: [MOBILE-IP] Implementation question about MIPv6 and IPSec X-To: Lars Henrik Petander To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Content-Transfer-Encoding: 7bit > I think that the problem with adding BU before the AH, is that you need to > add hooks to the AH processing (or after it) to know whether the BU was > valid. This makes life difficult if you want to use a generic IPSecv6 > implementation. When the AH is before the BU the processing is much more > straightforward, since you already have the knowledge of a succesful > authentication before you start the processing of the BU. With the BU in > the second destination options header the protocol, besides being > "cleaner" to implement would also comply better with RFC2460. I completely agree with you. In our implementation for Microsoft, we have done it the way you described it above (BU and BA in 2nd destionation options header) for exactly the same reasons - mainly because we argue it is conceptually the cleanest way (at least according to the current specs.) ... Regards, - Stefan PS: BTW, we (mainly Francis Dupont and myself) had a similar discussion about 2-3 months ago on this list. See archive ... From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Sep 22 05:41: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 SMTP id FAA04571 for ; Fri, 22 Sep 2000 05:41:13 -0400 (EDT) Received: from standards (47.234.32.16:4861) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB965D7@standards.nortelnetworks.com>; Fri, 22 Sep 2000 5:21:15 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 22481 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 22 Sep 2000 05:21:15 -0400 Received: from m018.com (210.112.10.141:61728) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB965B7@standards.nortelnetworks.com>; Fri, 22 Sep 2000 5:11:14 -0400 Received: from ns ([210.112.7.7]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Fri, 22 Sep 2000 18:22:11 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: <036301c02477$0106b9a0$d012060a@hansol.co.kr> Date: Fri, 22 Sep 2000 18:25:10 +0900 Reply-To: "Lee, Jiwoong" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Lee, Jiwoong" Subject: [MOBILE-IP] Reverse Tunneling from MN who is using CL COA To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Dear All Are there any necessary cases that an MN who is using CL COA establishes the reverse tunneling from MN to HA ? Reverse-tunneling document(draft-02) defines reverse tunnel as follows. Reverse Tunnel A tunnel that starts at the mobile node's care-of address and terminates at the home agent. This doc. uses the phrase "mobile node's care-of address" instead of "mobile node's foreign agent care-of address," while the main content of this document deals with only the case of FA COA. I'm sorry if revese-tunneling document has clarified this problem alreay. If not, I hope you take some time to clarify it. Thank you very much. Regards, Jiwoong Lee # CL COA means Co-located care-of address # FA COA means Foreign agnet care-of address From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Sep 22 05:59: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 SMTP id FAA04697 for ; Fri, 22 Sep 2000 05:59:28 -0400 (EDT) Received: from standards (47.234.32.16:4861) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9664F@standards.nortelnetworks.com>; Fri, 22 Sep 2000 5:43:37 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 22678 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 22 Sep 2000 05:43:37 -0400 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9664E@standards.nortelnetworks.com>; Fri, 22 Sep 2000 5:43:36 -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 e8M9tbu25099; Fri, 22 Sep 2000 11:55:37 +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 LAA03057; Fri, 22 Sep 2000 11:55:36 +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 LAA36426; Fri, 22 Sep 2000 11:57:37 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-ID: <200009220957.LAA36426@givry.rennes.enst-bretagne.fr> Date: Fri, 22 Sep 2000 11:57:37 +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 question about MIPv6 and IPSec X-To: Lars Henrik Petander To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Fri, 22 Sep 2000 10:07:10 +0300. In your previous mail you wrote: Thanks for your reply. I didn't however quite understand your comment on ESP and HA. Since the HA has a SA with the MN, it should also be able to decrypt the ESP payload or did I misunderstand your comment? => Aime comment was not very clear (:-). The idea is: 1- it is easier to put home address and binding update options in the same extension header. 2- there is no good reason to hide an option when ESP is used (or with other words if you need to hide something in a header then you should simply use the tunnel mode). IMHO the RFC 2460 is wrong in its recommendation for header ordering: security headers should be last. For instance the tunnel encapsulation limit option (the not-for-mobility destination option) is not useful/usable if it is hidden by an ESP... I think that the problem with adding BU before the AH, is that you need to add hooks to the AH processing (or after it) to know whether the BU was valid. This makes life difficult if you want to use a generic IPSecv6 implementation. => life is difficult (:-)! You have to deal with multiple destination option extensions which should contain a home address and a binding update in any order (between them and with security headers) then you should defer BU execution when you know you have got everything, ie. at the first transport/not-extension header. When the AH is before the BU the processing is much more straightforward, since you already have the knowledge of a succesful authentication before you start the processing of the BU. => you have to support the other case then there is not real benefit here (ie. you should try to make the sending code as easy as possible, the receiving code must be (too) generic). With the BU in the second destination options header the protocol, ^^^ => can you explain why it is not *a* second ...? For instance what is your proposed layout for a BU between two mobiles (with optimized routing). besides being "cleaner" to implement => it is a matter of taste. The only easy thing here is to forget to implement the (mandatory) authentication (:-). IMHO the two hard points in mobile IPv6 is movement detection and IPsec interaction. would also comply better with RFC2460. => compliance is binary... RFC 2460 must be fixed, I don't know how or when and this topics doesn't move crowds in the IPng mailing-list. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Sep 22 06:45: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 SMTP id GAA04953 for ; Fri, 22 Sep 2000 06:45:54 -0400 (EDT) Received: from standards (47.234.32.16:4663) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9669E@standards.nortelnetworks.com>; Fri, 22 Sep 2000 6:29:55 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 22779 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 22 Sep 2000 06:29:54 -0400 Received: from news.comp.lancs.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9669D@standards.nortelnetworks.com>; Fri, 22 Sep 2000 6:29:52 -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 e8MAiAh16595; Fri, 22 Sep 2000 11:44:10 +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: Fri, 22 Sep 2000 11:41:41 +0100 Reply-To: Stefan Schmid Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Stefan Schmid Subject: Re: [MOBILE-IP] Implementation question about MIPv6 and IPSec X-To: Francis.Dupont@ENST-BRETAGNE.FR To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200009220957.LAA36426@givry.rennes.enst-bretagne.fr> Content-Transfer-Encoding: 7bit > => Aime comment was not very clear (:-). The idea is: > 1- it is easier to put home address and binding update options in the > same extension header. True, but using two extension headers is not difficult either ... > 2- there is no good reason to hide an option when ESP is used (or with > other words if you need to hide something in a header then you should > simply use the tunnel mode). > IMHO the RFC 2460 is wrong in its recommendation for header ordering: > security headers should be last. For instance the tunnel encapsulation > limit option (the not-for-mobility destination option) is not > useful/usable > if it is hidden by an ESP... Okay ... but for this reason (i.e. options that have to be clear), the spec defines the 1st destination option header. Options that should be protected (i.e. BU/BA) go in the 2nd destination option header. > When the AH is before the BU the processing is much more > straightforward, since you already have the knowledge of a succesful > authentication before you start the processing of the BU. > > => you have to support the other case then there is not real benefit here > (ie. you should try to make the sending code as easy as possible, > the receiving code must be (too) generic). This argument only holds when the specifiction is not clear. If it would be clear, one would have to support (and may optimize) only the correct way. 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 Fri Sep 22 06:58:08 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA05223 for ; Fri, 22 Sep 2000 06:58:07 -0400 (EDT) Received: from standards (47.234.32.16:4663) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB966E0@standards.nortelnetworks.com>; Fri, 22 Sep 2000 6:42:12 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 22805 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 22 Sep 2000 06:42:12 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB966B2@standards.nortelnetworks.com>; Fri, 22 Sep 2000 6:32: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 GAA04969; Fri, 22 Sep 2000 06:45:57 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200009221045.GAA04969@ietf.org> Date: Fri, 22 Sep 2000 06:45:57 -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-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 : IP Mobility Support for IPv4, revised Author(s) : C. Perkins Filename : draft-ietf-mobileip-rfc2002-bis-03.txt Pages : 94 Date : 21-Sep-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-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-rfc2002-bis-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-rfc2002-bis-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: <20000921133534.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-rfc2002-bis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-rfc2002-bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000921133534.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Sep 22 07:52: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 SMTP id HAA07236 for ; Fri, 22 Sep 2000 07:52:14 -0400 (EDT) Received: from standards (47.234.32.16:1043) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB96730@standards.nortelnetworks.com>; Fri, 22 Sep 2000 7:36:20 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 22971 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 22 Sep 2000 07:36:20 -0400 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9672F@standards.nortelnetworks.com>; Fri, 22 Sep 2000 7:36:19 -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 e8MBnpu31761; Fri, 22 Sep 2000 13:49:52 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id NAA03932; Fri, 22 Sep 2000 13:49:50 +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 NAA36845; Fri, 22 Sep 2000 13:51:52 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-ID: <200009221151.NAA36845@givry.rennes.enst-bretagne.fr> Date: Fri, 22 Sep 2000 13:51:52 +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 question about MIPv6 and IPSec X-To: Stefan Schmid To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Fri, 22 Sep 2000 11:41:41 BST. In your previous mail you wrote: > 2- there is no good reason to hide an option when ESP is used (or with > other words if you need to hide something in a header then you should > simply use the tunnel mode). > IMHO the RFC 2460 is wrong in its recommendation for header ordering: > security headers should be last. For instance the tunnel encapsulation > limit option (the not-for-mobility destination option) is not > useful/usable > if it is hidden by an ESP... Okay ... but for this reason (i.e. options that have to be clear), the spec defines the 1st destination option header. => NO, this is a mistake. The first destination option header in RFC 2460 is for intermediate hops specified by a routing header, this has nothing to do with security or mobility and is currently unused (no such option are defined, nor the way to apply them to the right hop). Options that should be protected (i.e. BU/BA) go in the 2nd destination option header. => I disagree: - ESP in transport mode doesn't provide the needed protection for BU/BA (for instance the source address is not protected). - some destination options should not be hidden (my favorite example is the tunnel encapsulation limit). > => you have to support the other case then there is not real benefit here > (ie. you should try to make the sending code as easy as possible, > the receiving code must be (too) generic). This argument only holds when the specifiction is not clear. => yes the specification is not clear enough but RFC 2460 notes 1 and 3 in section 4.1 page 8 are clear. If it would be clear, one would have to support (and may optimize) only the correct way. => according to RFC 2460 none are correct then you have to wait for the next draft or the next version of RFC 2460... Regards Francis.Dupont@enst-bretagne.fr PS: is there something in the IPv6 Linux implementation which constraints destination option headers? We already had this discussion between me and a Linux guy... From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Sep 22 10:30: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 SMTP id KAA15396 for ; Fri, 22 Sep 2000 10:30:21 -0400 (EDT) Received: from standards (47.234.32.16:1043) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB968B4@standards.nortelnetworks.com>; Fri, 22 Sep 2000 10:14:20 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 23438 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 22 Sep 2000 10:14:20 -0400 Received: from m018.com (210.112.10.141:64850) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB968AB@standards.nortelnetworks.com>; Fri, 22 Sep 2000 10:04:20 -0400 Received: from ns ([210.112.7.7]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Fri, 22 Sep 2000 23:15:18 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: <000e01c0249f$f9833720$d012060a@hansol.co.kr> Date: Fri, 22 Sep 2000 23:18:26 +0900 Reply-To: "Lee, Jiwoong" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Lee, Jiwoong" Subject: [MOBILE-IP] Multicast join of MN who is using FA COA via a local multicast router To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Dear all in Mobile IP WG. According to RFC2002bis-03, an MN who is using a foreign agnet care-of address MAY join a multicast group, via a local multicast router. (FA does not have to be this multicast router.) If this local subnet uses a shared medium such as Ethernet, this make sense enoughly. MN will be able to listen the Mulitcast Router Advertisement message and will generate an IGMP reply message to that link. The Multicast Router will hear of this reply, and start to forward requested multicast traffic to that link (actually to the related interface), without regard to the source address of MN's IGMP reply message. (I guess therefore RFC2002bis-03 declares that MN MAY use its home address as the source IP address of its IGMP message.) If the local subnet uses point-to-point links such as 3G cellular network, where FA is the subnet edge router and establishes PPP sessions with MNs, the scenario just described above will NOT work. The only possible case is that the FA is a multicast router.) I believe that one of the next three statements should be included in the next version of RFC. - FA is assumed to be a multicast router - MN using FA COA cannot join a group via a local mulitcast router in a point-to-point linked subnet - or somewhat else. Comments please. Goodday, Jiwoong Lee PS. ---------------------------------------------- 4.4. Multicast Datagram Routing (bis-03) [...] 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. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Sep 22 10:48: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 SMTP id KAA15919 for ; Fri, 22 Sep 2000 10:48:22 -0400 (EDT) Received: from standards (47.234.32.16:1043) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB96921@standards.nortelnetworks.com>; Fri, 22 Sep 2000 10:32:15 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 23589 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 22 Sep 2000 10:32:15 -0400 Received: from news.comp.lancs.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB96920@standards.nortelnetworks.com>; Fri, 22 Sep 2000 10:32:14 -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 e8MEkRh20264 for ; Fri, 22 Sep 2000 15:46:28 +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: Fri, 22 Sep 2000 15:43:59 +0100 Reply-To: Stefan Schmid Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Stefan Schmid Subject: Re: [MOBILE-IP] Implementation question about MIPv6 and IPSec To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200009221151.NAA36845@givry.rennes.enst-bretagne.fr> Content-Transfer-Encoding: 7bit > => NO, this is a mistake. The first destination option header in RFC 2460 > is for intermediate hops specified by a routing header, So what about the section 4.1 of RFC 2460 ... Recommended header order: " IPv6 header Hop-by-Hop Options header Destination Options header (note 1) Routing header Fragment header Authentication header Encapsulating Security Payload header Destination Options header (note 3) upper-layer header note 1: for options to be processed by the first destination that appears in the IPv6 Destination Address field plus subsequent destinations listed in the Routing header. [...] note 3: for options to be processed only by the final destination of the packet." Note 1 tells me that if no routing header is present, the 1st Destination Options header is (apart from its processing order within the IPv6 stack) equivalent to the 2nd Destination Options header. But it can still be used in the same (or a similar) way as the 1st Destination Options header. Note, only if an routing header is available, the possible options MIGHT be processed (if the node supports the option) by "intermediate destinations". Thus, I can't see why we should not be able to use this extension header for the Home Address Option and Binding Request. > this has nothing > to do with security or mobility and is currently unused (no such option > are defined, nor the way to apply them to the right hop). Moreover, the mobile IPv6 specification even mandates the use of the 1st Destination Options header. I am not sure how you can claim that no such option is defined, when it is even stated by the mobile IPv6 spec? Have a look what it says in section 10.2 (page 74): "Since the mobile node is away from home, the mobile node inserts a Home Address option into the packet, replacing the Source Address in the packet's IP header with a care-of address suitable for the link on which the packet is being sent, as described in Section 10.1. The Destination Options header in which the Home Address option is inserted MUST appear in the packet before the AH [11] (or ESP [12]) header, so that the Home Address option is processed by the destination node before the AH or ESP header is processed." According to the IPv6 RFC (also see above), there is only one Destination Option header which occurs before the AH & ESP header. > Options that should be protected (i.e. BU/BA) go in the 2nd > destination option header. > > => I disagree: > - ESP in transport mode doesn't provide the needed protection for BU/BA > (for instance the source address is not protected). > - some destination options should not be hidden (my favorite example > is the tunnel encapsulation limit). Hence the 1st Destination Option header ... 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 Fri Sep 22 13:12: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 SMTP id NAA20695 for ; Fri, 22 Sep 2000 13:12:49 -0400 (EDT) Received: from standards (47.234.32.16:4559) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB96A5F@standards.nortelnetworks.com>; Fri, 22 Sep 2000 12:56:58 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 23990 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 22 Sep 2000 12:56:57 -0400 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB96A5E@standards.nortelnetworks.com>; Fri, 22 Sep 2000 12:56:56 -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 e8MHAfu17812; Fri, 22 Sep 2000 19:10:41 +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 TAA07360; Fri, 22 Sep 2000 19:10:40 +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 TAA38273; Fri, 22 Sep 2000 19:12:43 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-ID: <200009221712.TAA38273@givry.rennes.enst-bretagne.fr> Date: Fri, 22 Sep 2000 19:12:43 +0200 Reply-To: Francis.Dupont@ENST-BRETAGNE.FR Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] Implementation question about MIPv6 and IPSec X-To: Stefan Schmid To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Fri, 22 Sep 2000 15:43:59 BST. In your previous mail you wrote: > => NO, this is a mistake. The first destination option header in RFC 2460 > is for intermediate hops specified by a routing header, So what about the section 4.1 of RFC 2460 ... Recommended header order: " IPv6 header Hop-by-Hop Options header Destination Options header (note 1) Routing header Fragment header Authentication header Encapsulating Security Payload header Destination Options header (note 3) upper-layer header note 1: for options to be processed by the first destination that appears in the IPv6 Destination Address field plus subsequent destinations listed in the Routing header. [...] note 3: for options to be processed only by the final destination of the packet." Note 1 tells me that if no routing header is present, the 1st Destination Options header is (apart from its processing order within the IPv6 stack) equivalent to the 2nd Destination Options header. => this is not what I read. IMHO note 1 says the 1st DO header is valid only if there is a routing header and it specifies options which will be processed by all intermediate hops (including the first one which is in the destination address field when the packet is sent and the last one which is in the last address field in the routing header until the last segment). But it can still be used in the same (or a similar) way as the 1st Destination Options header. => I disagree. If you put an option in the 1st DO header then the first hop will processed it and will reject the packet if the option is not a pad or is maked as "should be skipped" (which is not the case for BU and HA). Note, only if an routing header is available, the possible options MIGHT be processed (if the node supports the option) by "intermediate destinations". => I can find where is your MIGHT. The text specifies they will be processed. Thus, I can't see why we should not be able to use this extension header for the Home Address Option and Binding Request. => you just don't understand the purpose of this extension header. For the last time, BU and HA are sent to the FINAL destination. Moreover, the mobile IPv6 specification even mandates the use of the 1st Destination Options header. => where? The mobile IPv6 mandates only the use of a DO header placed before the AH header. There is no reference to this section of RFC 2460 (of course, the I-D violates it :-). I am not sure how you can claim that no such option is defined, when it is even stated by the mobile IPv6 spec? => please read the list archive, I have not the time to do the whole discussion again... Hence the 1st Destination Option header ... => definitively NO! Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Sep 22 14:10: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 SMTP id OAA22365 for ; Fri, 22 Sep 2000 14:10:15 -0400 (EDT) Received: from standards (47.234.32.16:4348) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB96ABB@standards.nortelnetworks.com>; Fri, 22 Sep 2000 13:54:22 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 24105 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 22 Sep 2000 13:54:22 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB96AB4@standards.nortelnetworks.com>; Fri, 22 Sep 2000 13:44:22 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22048; Fri, 22 Sep 2000 13:58:11 -0400 (EDT) Message-ID: <200009221758.NAA22048@ietf.org> Date: Fri, 22 Sep 2000 13:58:11 -0400 Reply-To: iesg@ietf.org Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: The IESG Subject: [MOBILE-IP] Last Call: Reverse Tunneling for Mobile IP, revised to Proposed Standard To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM The IESG has received a request from the IP Routing for Wireless/Mobile Hosts Working Group to consider Reverse Tunneling for Mobile IP, revised as a Proposed Standard. This document will obsolete RFC2344. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by October 6, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mobileip-rfc2344-bis-02.txt From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Sep 22 15: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 SMTP id PAA24688 for ; Fri, 22 Sep 2000 15:05:39 -0400 (EDT) Received: from standards (47.234.32.16:2553) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB96B11@standards.nortelnetworks.com>; Fri, 22 Sep 2000 14:49:46 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 24226 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 22 Sep 2000 14:49:46 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB96B10@standards.nortelnetworks.com>; Fri, 22 Sep 2000 14:49:46 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA27973; Fri, 22 Sep 2000 12:03:37 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e8MJ3Zj31908; Fri, 22 Sep 2000 12:03:35 -0700 X-Virus-Scanned: Fri, 22 Sep 2000 12:03:35 -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) smtpd5BCu4C; Fri, 22 Sep 2000 12:03:27 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <7B5C0390ACE7D211BC9C0008C7EABA2BCD4F61@daeis07nok> <390957D0.7299625D@era.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39CBAD00.5C68322C@iprg.nokia.com> Date: Fri, 22 Sep 2000 12:03: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: Re: [MOBILE-IP] WG Last Call - Mobility Support in IPv6 X-To: Mattias Pettersson To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Mattias, I am responding to a note that you sent earlier in the year. > A CN/HA with more than one interface address may get independent BUs > sent to it. The mobile node will consider them as different nodes and > keep one BUL entry for each of them. Especially, it will use independent > sets of sequence numbers, which in turn will cause the receiving CN/HA > to get very confused (and not accept the BUs). > > This can happen to any host/router that has multiple interface addresses > of the same scope as the home address, not only nodes with multiple > interfaces. Agreed. > My suggestion is to keep a Binding Cache on a CN/HA for every interface > address that's assigned, and to clear this out in the draft under > "Conceptual structs". Currently you can read both do and don't out of > the spec. It will be more complex, but it is the logical way to do it. Wouldn't it be easier for the mobile node to use a single monotonically increasing sequence number for all of its interfaces and correspondent nodes? Shouldn't this behavior be mandated, or at least strongly recommended? Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Sep 22 15:31:32 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25174 for ; Fri, 22 Sep 2000 15:31:31 -0400 (EDT) Received: from standards (47.234.32.16:4887) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB96B5D@standards.nortelnetworks.com>; Fri, 22 Sep 2000 15:15:25 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 24330 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 22 Sep 2000 15:15:24 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB96B5C@standards.nortelnetworks.com>; Fri, 22 Sep 2000 15:15:19 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA01316; Fri, 22 Sep 2000 12:29:03 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e8MJSxs17362; Fri, 22 Sep 2000 12:28:59 -0700 X-Virus-Scanned: Fri, 22 Sep 2000 12:28: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) smtpdl1xKai; Fri, 22 Sep 2000 12:28:55 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <200005032346.e43NkM009445@locked.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39CBB2F9.9CD9EE2D@iprg.nokia.com> Date: Fri, 22 Sep 2000 12:28:57 -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] New version of "Mobility Support in IPv6" draft X-To: Mohan Parthasarathy X-cc: Dave Johnson To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Mohan, I am responding to a note that you sent earlier in the year, which I have appended in its entirety after my comments. > The IPsec processing section is not very clear on what exact bits > pass through AH i.e at least what does the source address and the > Home address option contain ? Without this, there might be > potential inter-operability problems. > > In section 10.2, it describes that HOME address option is inserted, > *replacing* the source address in the packet's IP header with a COA, > then AH ICV is computed. What does the HOME address option contain ? > I understand that it contains the original ip6_src which is the > HOME address. *replacing* is really *swap* then. In section 5.4 and > other places, on inbound if a packet contains HOME address option, > it states that it should be processed first which implies that > the source address will be replaced with the HOME address. Again, > this is before the computation of the AH ICV. ICV computed this > way will not match with what was done on outbound as ip6_src > contains the COA while ICV was computed. Is it possible to > clarify this so that everybody computes the ICV with the same > set of bits.. My understanding is that the current specification makes it mandatory to copy the home address into the ip6_src field of the IPv6 header. Swapping should not be performed. Here, "replace" means "copy over". I reckon that the current specification should be made unequivocal on this point. ---- insert big logical break delimiter at this point --------- While thinking about the effects of this requirement, I found myself wondering why. It seems like the natural processing for the mobile node, when creating the Authentication Header, would be to calculate the authentication data starting with the predictable fields of the IPv6 header and extensions with as little change as possible. I would think that, typically, the IPv6 header already has the mobile node's Care-of Address inserted as the ip6_src field before the Authentication Header calculation is initiated. Then, in order to make the spec work, the mobile node has to proceed as follows: - Put in its home address as ip6_src, temporarily - Do the AH thing - Restore its care-of address as ip6_src. This seems like a lot of extra work, and a very handy place to put bugs. What if we make it so that the recipient uses the address in the Home Address option to select the appropriate security association? I understand the current specification to be fashioned so that the recipient can select the security association based on the contents of the source IPv6 address in the IPv6 header. However, whether or not to actually CHANGE the fields, treating them as mutable, seems to introduce a lot of unnecessary specification difficulties that could be avoided. Changing the way that a security association is looked up seems a lot cheaper than copying and recopying data within the challenge data. If everybody hates this idea, then just forget I mentioned it! ------------ End of major logical break delimiter ----------- Regards, Charlie P. ================================================================== Mohan Parthasarathy wrote: > > Dave, > > The IPsec processing section is not very clear on what exact bits > pass through AH i.e at least what does the source address and the > Home address option contain ? Without this, there might be > potential inter-operability problems. > > In section 10.2, it describes that HOME address option is inserted, > *replacing* the source address in the packet's IP header with a COA, > then AH ICV is computed. What does the HOME address option contain ? > I understand that it contains the original ip6_src which is the > HOME address. *replacing* is really *swap* then. In section 5.4 and > other places, on inbound if a packet contains HOME address option, > it states that it should be processed first which implies that > the source address will be replaced with the HOME address. Again, > this is before the computation of the AH ICV. ICV computed this > way will not match with what was done on outbound as ip6_src > contains the COA while ICV was computed. Is it possible to > clarify this so that everybody computes the ICV with the same > set of bits.. > > thanks > -mohan > > > I just submitted a revised version of the Internet-Draft "Mobility > > Support in IPv6", which corrects a number of minor problems and adds > > several clarifications over the previous version of the draft. Here > > is a list of some of the changes since the previous version: > > > > - Moved the definition of IPsec requirements for Binding Updates > > and Binding Acknowledgements to Section 4.4), giving this > > important information its own specific section with a section > > title (IPsec Requirements for Mobile IPv6 Destination Options) > > that will be identifiable in the table of contents for this > > document. This makes these requirements harder to miss than > > where they were defined in Sections 5.1 and 5.2, mixed in with > > the definition of the format of these destination options. > > > > - In Section 4.6, added a precise definition of Sequence Number > > value comparison modulo 2**16. Also added a reference to this > > definition in each other place where Sequence Number comparison > > is discussed. > > > > - Added a statement in Section 9.5 to clarify the sending of a > > Neighbor Advertisement message by the home agent on behalf of the > > mobile node in order to intercept packets addressed to the mobile > > node. Except for the specific fields defined there, all fields > > in each such Neighbor Advertisement SHOULD be set in the same > > way they would be set by the mobile node itself if sending this > > Neighbor Advertisement while at home [17]. > > > > - In Section 10.6, specified that the Lifetime in the Binding > > Update sent by a mobile node to its home agent SHOULD be less > > than or equal to the remaining lifetime of the home address and > > the care-of address specified for the binding. > > > > - In Section 10.8, modified the specification that was there > > about the correct setting of the Lifetime in the Binding > > Update sent by a mobile node to a correspondent node. The > > original specification stated that the Lifetime value MUST be no > > greater than the remaining lifetime of the mobile node's home > > registration of its primary care-of address at its home agent. > > However, there should be no necessary relationship between the > > remaining lifetime of a home registration and the lifetime of > > a binding at a correspondent node. Instead, as with the home > > registration Binding Update, the Lifetime in the Binding Update > > sent by a mobile node to a correspondent node SHOULD be less than > > or equal to the remaining lifetime of the home address and the > > care-of address specified for the binding. > > > > - In Section 5.4, added a statement that a packet MUST NOT contain > > more than one Home Address option, except that an encapsulated > > packet [4] MAY contain a separate Home Address option associated > > with each encapsulating IP header. > > > > - In Section 4.6, added a new field in the Binding Update List > > entry format to record the initial value of the Lifetime field > > sent in that Binding Update. > > > > - In Section 10.12, defined a new step in processing a received > > Binding Acknowledgement: if the value specified in the Lifetime > > field in the Binding Acknowledgement is less than the Lifetime > > value sent in the Binding Update being acknowledged, then the > > mobile node MUST subtract the difference between these two > > Lifetime values from the remaining lifetime for the binding > > as maintained in the corresponding Binding Update List entry. > > The effect of this step is to correctly manage the mobile > > node's view of the binding's remaining lifetime (as maintained > > in the corresponding Binding Update List entry) so that it > > correctly counts down from the Lifetime value given in the > > Binding Acknowledgement, but with the timer countdown beginning > > at the time that the Binding Update was sent. This change also > > affected Section 10.8 in sending Binding Updates, to record both > > the original lifetime and the remaining lifetime in the Binding > > Update List. > > > > - In Sections 5.1 and 9.3, clarified that the Duplicate Address > > Detection performed by the home agent if the Duplicate Address > > Detection (D) bit is set in the Binding Update, is performed > > before returning the Binding Acknowledgement for that Binding > > Update. > > > > - In Section 5.1, clarified that the mobile node SHOULD set the > > Duplicate Address Detection (D) bit in its home registration > > Binding Updates based on any requirements for Duplicate Address > > Detection that would apply to the mobile node if it were at > > home [17, 27]. > > > > - In Section 9.3, specified that a home agent, when performing > > Duplicate Address Detection for a mobile node when the > > Duplicate Address Detection (D) bit is set in a received > > Binding Update, SHOULD NOT delay sending the initial Neighbor > > Solicitation message of Duplicate Address Detection by the random > > delay specified for normal processing of Duplicate Address > > Detection [17, 27]. > > > > - In Section 10.5, defined special considerations for a mobile > > node's use of Duplicate Address Detection upon forming a new > > care-of address. In particular, the mobile node MAY begin > > using the new care-of address without performing Duplicate > > Address Detection, and MAY optionally bypass Duplicate Address > > Detection or begin Duplicate Address Detection asynchronously > > when it begins use of the address, allowing the Duplicate > > Address Detection procedure to complete in parallel with > > normal communication using the address. In addition, the > > mobile node SHOULD NOT delay sending the initial Neighbor > > Solicitation message of Duplicate Address Detection by the random > > delay specified for normal processing of Duplicate Address > > Detection [17, 27], unless the mobile node is initializing after > > rebooting. > > > > - In Section 4.6, added a clarification to the definition of the > > Binding Update List, that for multiple Binding Updates sent to > > the same destination address, the Binding Update List contains > > only the most recent Binding Update (i.e., with the greatest > > Sequence Number value) sent to that destination. This was > > already noted in previous versions of the draft in the sending of > > Binding Updates, as defined in Section update-corresp, but was > > not previously stated explicitly in the definition of the Binding > > Update List conceptual data structure. > > > > - In Section 9.3, added a specification that the lifetime for the > > Binding Cache entry (and thus the Lifetime value returned in the > > Binding Acknowledgement) MUST NOT be greater than the Lifetime > > value specified in the Binding Update. Also added a similar > > specification (and clarification) in Section 8.3 for the Binding > > Cache entry in a correspondent node. > > > > - In Section 10.6, added a clarification that, when sending a > > Binding Update to its home agent, the mobile node MUST also > > create or update the corresponding Binding Update List entry, as > > specified in Section 10.8. > > > > The official announcement of the draft should appear on the mailing > > lists shortly, but you can get a copy of the new draft now from > > > > http://www.monarch.cs.cmu.edu/internet-drafts/draft-ietf-mobileip-ipv6-12.txt > > > > We expect to go to Last Call on this version of the draft shortly. > > Please send any comments on the draft to the Mobile IP mailing list at > > mobile-ip@standards.nortelnetworks.com. > > > > Thanks. > > > > Dave > > > > -- > > David B. Johnson dbj@cs.cmu.edu > > Associate Professor http://www.cs.cmu.edu/~dbj/ > > Computer Science Department http://www.monarch.cs.cmu.edu/ > > Carnegie Mellon University Phone: (412) 268-7399 > > 5000 Forbes Avenue Fax: (412) 268-5576 > > Pittsburgh, PA 15213-3891 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Sep 22 16:00: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 SMTP id QAA25771 for ; Fri, 22 Sep 2000 16:00:06 -0400 (EDT) Received: from standards (47.234.32.16:4887) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB96BAD@standards.nortelnetworks.com>; Fri, 22 Sep 2000 15:44:16 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 24436 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 22 Sep 2000 15:44:16 -0400 Received: from news.comp.lancs.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB96BAC@standards.nortelnetworks.com>; Fri, 22 Sep 2000 15:44:11 -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 e8MJwYh24006 for ; Fri, 22 Sep 2000 20:58:35 +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: Fri, 22 Sep 2000 20:56:07 +0100 Reply-To: Stefan Schmid Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Stefan Schmid Subject: Re: [MOBILE-IP] Implementation question about MIPv6 and IPSec To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200009221712.TAA38273@givry.rennes.enst-bretagne.fr> Content-Transfer-Encoding: 7bit > Note 1 tells me that if no routing header is present, the > 1st Destination > Options header is (apart from its processing order within the > IPv6 stack) > equivalent to the 2nd Destination Options header. > > => this is not what I read. IMHO note 1 says the 1st DO header is valid > only if there is a routing header and it specifies options which will be > processed by all intermediate hops (including the first one which is in > the destination address field when the packet is sent and the last one > which is in the last address field in the routing header until the last > segment). Under certain circumstances there might be some sense in reading it that way, however, Note 1 does not say the first DO header is valid only if there is a routing header. Clarification in the spec is needed. > => I disagree. If you put an option in the 1st DO header then the first > hop will processed it and will reject the packet if the option is > not a pad > or is maked as "should be skipped" (which is not the case for BU and HA). Do you know the exact reason why the HA option could not be skipped by intermediate nodes? > Thus, I can't see why we should not be able to use this > extension header > for the Home Address Option and Binding Request. > > => you just don't understand the purpose of this extension header. > For the last time, BU and HA are sent to the FINAL destination. This wouldn't be a problem if intermediate nodes don't process the mobileip options :-). Unfortunately, this would require modification to current spec(s) :-( > Moreover, the mobile IPv6 specification even mandates the > use of the 1st > Destination Options header. > > => where? The mobile IPv6 mandates only the use of a DO header > placed before the AH header. There is no reference to this section of RFC > 2460 (of course, the I-D violates it :-). Assuming the mobile I-D is compliant with the IPv6 spec (RFC 2460), it _demands_ the use of the 1st DO header. But you are right, that if one simply ignores the spec, one can interpret it your way. ;-) > => please read the list archive, I have not the time to do the whole > discussion again... Sorry, I know we had this discussion already some month ago, but as long as the spec(s) are not changed, your arguments are not well establishied. Hopefully this discussion will stimulate clarification of the Mobile IPv6 spec. Regards, - Stefan From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Sep 22 17:30: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 SMTP id RAA26771 for ; Fri, 22 Sep 2000 17:30:42 -0400 (EDT) Received: from standards (47.234.32.16:1228) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB96C8A@standards.nortelnetworks.com>; Fri, 22 Sep 2000 17:14:32 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 24722 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 22 Sep 2000 17:14:32 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB96C89@standards.nortelnetworks.com>; Fri, 22 Sep 2000 17:14: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 OAA12645; Fri, 22 Sep 2000 14:28:20 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e8MLSGi01912; Fri, 22 Sep 2000 14:28:16 -0700 X-Virus-Scanned: Fri, 22 Sep 2000 14:28:16 -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) smtpdSeQL5N; Fri, 22 Sep 2000 14:28:12 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: <39CBCEEF.756F1AB1@iprg.nokia.com> Date: Fri, 22 Sep 2000 14:28:15 -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] Mobile IPv6 questions X-To: "Powell, Ken" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Ken, I am responding to a note you sent earlier this year, which I have appended in its entirety after my comments. I apologize for the length, but I thought it was important to try to get to a good resolution for all of your points. >> RFC 2461 section 6.2.7 states: >> >> "Note that it is not an error for different routers to >> advertise different sets of prefixes" >> >> => for me "no error" is requirement level below/weaker than a >> "MUST NOT". > > I read it to mean different routers "MAY" advertise different > sets of prefixes. So do I, and I think that this wording should be inserted into the draft. >> Section 9.7 of the Mobile IPv6 draft indicates that it was >> intended to support routers advertising different prefixes: >> >> "The home agent determines these conditions based on its >> own configuration as a router and based on the Router >> Advertisements that it receives on the home link." >> >> => and section 9.7 indicates the home agent should send changes >> for any prefixes of the link, the list is built by the union >> of configured prefixes on the home agent and prefixes listen >> on the link in router advertisements. Things are more simpler >> if both lists in the union are the same. > > I agree that things are simpler if both lists are the same, > but I don't think we can just assume they are without stating > that clearly in the Mobile IPv6 spec. This should be made clear in the draft. The lists are slightly different insofar as their entries are updated differently. >> I think some of your other responses were based on the >> assumption that routers will advertise a consistent set >> of prefixes. I guess before we can resolve the details, >> we need to know if the Mobile IPv6 spec should or should >> not impose this restriction on the home subnet configuration. >> >> => mobile IPv6 spec imposes this restriction for router advertisements >> sent to the mobile node in case of an "important" change. > > I think you may have misinterpreted my statement. I meant to ask > should Mobile IPv6 impose a restriction that all routers on the > home subnet advertise a consistent set of prefixes? If not, then > the Mobile IPv6 spec needs to provide more details about how to > relay prefix information from all routers on the home subnet to > the mobile node. > > Perhaps there could be an alternative restriction that a Mobile > Agent's interface needs to be configured with all possible prefixes > advertised on the home link. Other routers don't. > > I wonder if there are any other ways to solve this problem. What if the home agent supplies router advertisements to the mobile node whenever advertised prefix information changes? >> > I think more details are needed on how the home agent should >> > maintain its list of prefixes >> > >> > => I think it should use standard management and router renumbering >> > as other routers. >> >> Yes, if routers on the home subnet advertise the same set of prefixes. >> Otherwise, we need additional mechanisms to keep the set of home subnet >> prefixes available to the mobile node consistent. I don't think that the information to the mobile node has to be any more consistent while it is away than it would be if it were at home. And, the way things look at home is dictated by other specifications, not Mobile IPv6. >>> Sections 4.3, 5.1, 9.3, and 9.5 describe how the mobile node >>> sends a Router bit to the home agent which the home agent must >>> in turn use for the IsRouter bit on proxy neighbor advertisements >>> for the mobile node. Why is this done? The mobile node can't >>> continue to function as a normal router to other nodes on the >>> home subnet can it? >>> >>> => the mobile node can be either a host or a router then the home >>> agent needs to know if it is a host or a router when it sends >>> proxy NAs (because of the IsRouter bit). The router bit in binding >>> updates provides this information. >> >> I asked this question because of the role the IsRouter bit plays >> in Neighbor Discovery. Specifically, the sole function of the >> IsRouter bit is to signal to hosts on the home link that a node >> which was previously acting as an on-link router is no longer >> capable of accepting messages on the link for forwarding. RFC >> 2461 section 7.3.3 states: >> >> "When a node detects that a neighbor has changed from being a >> router to being a host, the node MUST remove that router from >> the Default Router List and update the Destination Cache as >> described in Section 6.3.5. Note that a router may not be >> listed in the Default Router List, even though a Destination >> Cache entry is using it (e.g., a host was redirected to it). >> In such cases, all Destination Cache entries that reference >> the (former) router must perform next-hop determination >> again before using the entry." >> >> I don't believe RFC 2461 accounted for mobile routers. It seems >> to me that the above host processing makes just as much sense >> when a neighboring mobile router goes off-link as when a >> neighboring router switches from being a router to a host. >> >> => there is two independent parts in "being a router": >> - being an on-link router (this function uses the link-local address >> then will stop when the router goes off-link. Some implementations >> impose the gateway field of a route to be a link-local address, >> this is not stupid because an off-link router can't receive then >> forward packets on the link) >> - being involved in a protocol as a router (in general such a protocol >> is a routing protocol but there are other examples). In this case >> an address with a scope larger than the link is used and if the >> protocol looks at the neighbor discovery stuff then the IsRouter >> flag must be preserved (ie. there is no good reason than a router >> which goes off-link MUST become a host then the IsRouter flag >> MUST be transmitted in binding updates). > > Thanks, I didn't think of this second possible use of IsRouter. > >> Note: the IsRouter should be reset in proxy neighbor advertisements >> for the link-local address, for instance in duplicate address detection. >> Perhaps a SHOULD for a proxy router advertisement with a zero lifetime >> should be added too? >> >> However, I think this I-D should be able to cover how >> to initialize its state on the home agent and the mobile node >> from a limited amount of information that is relatively easy >> to configure. For example, start with the assumption that the >> mobile node can always get the Home Agent's Anycast Address. >> >> => I agree this is useful but I think this is out of the >> scope of the I-D. I agree with most of this discussion. However, I think that other nodes on the home link MUST NOT use the mobile node as a default router while it is away from home, even if the mobile node is still a legitimate router for some advertised prefixes. > Perhaps it would help if I backed up a little. The Mobile IPv6 > draft explains how to handle many parts of stateless address > autoconfiguration between a mobile node and the home network. > This led me to believe that Mobile IPv6 aught to work with a > home subnet that runs stateless address autoconfiguration only. I agree that it should, but I also think that most of the original design attempts a long time ago did not take this into account. We typically thought about the mobile node as having a statically assigned home address, as I remember. > I tried to understand how a Mobile IPv6 node would initialize > its addresses on power-up using stateless address auto- > configuration when away from home. The steps I came up with > were: > > 1) Get the home network mobile agent anycast address. > (Method for this is beyond the scope of this spec) > > 2) Send Home Agent Address Discovery Request message > to home network. > > 3) Receive Home Agent Address Discovery Reply message. > > Now I'm stuck. I still need to: > > 4) Autoconfigure the mobile node's home network global > addresses from router advertisements sent by the > home agent. This cannot be done without the primary > care-of address binding due to the way router > advertisements are tunneled. > > 5) Create the primary care-of address binding. This > cannot be done without the mobile node having a > global address on the home network. > > What information can I expect the mobile node have to break > this deadlock? Is my reading of how this should work way off? A few days later on May 12, you wrote in another note: May12> Would it be reasonable for a mobile node to May12> generate a temporary home address for itself using: May12> May12> o the subnet prefix from the home network's mobile May12> agent anycast address, and May12> May12> o the globally unique interface identifier that May12> would have been used to generate the link local May12> address if the mobile node were attached directly May12> to the home network. May12> Such a temporary address could be used to establish May12> a binding with a home agent in the absence of any May12> other known home addresses. It could be created with May12> short valid lifetime and a preferred lifetime of zero May12> to ensure a quick transition to other addresses May12> generated when stateless or statefull (DHCPv6) May12> address autoconfiguration runs. This seems like a generally good idea for the case when the mobile node really cannot remember a good home address. It should not be used in preference to a statically allocated home address. May12> If this were allowed, I can see how a mobile node May12> could initialize by: May12> May12> 1) Query DNS for the home network's mobile agent May12> anycast address. May12> May12> 2) Generate a temporary home address as defined above. May12> May12> 3) Send a Home Agent Address Discovery Request message May12> to the home network. May12> May12> 4) Receive Home Agent Address Discovery Reply message. May12> May12> 5) Send a binding update option with a router solicit May12> to a home agent using the temporary home address. May12> May12> 6) Receive a binding acknowledgement option with a May12> router advertisement from the home agent. This router May12> advertisement could indicate to use stateless and/or May12> statefull address autoconfiguration. If statefull, May12> start the DHCPv6 procedures. May12> May12> 7) Autoconfigure home addresses according to the prefix May12> information options received. May12> May12> 8) Send binding update option(s) to establish bindings May12> for the new home addresses (if needed). Do you still think this is a reasonable approach? The difference here is generating a temporary home address. That seems reasonable to me, given that the mobile node can't remember its actual home address. >>> Comments on Specific Sections: >>> >>> Page 14: >>> >>> Should section 4.3 (Conceptual Data Structures) define a place >>> where the home agent would store the state of all prefixes >>> advertised by other routers on the home subnet? >>> >>> => the home agent should act as a standard router for this. >> >> Yes, but only if all routers on the home subnet advertise the >> same set of prefixes. >> >> => it is simpler to add the unknown prefixes to the home agent prefix >> list (hosts will not see the difference) but a clarification is needed. > > I'm not sure exactly what you mean. Would the home agent > dynamically add the prefix from another router on the link > to its own list and automatically start advertising that prefix? Discussion elsewhere suggests that the home agent SHOULD keep the mobile node informed about what prefixes are being advertised on the home link. ............ >>> When a mobile agent receives a router advertisement from >>> another router on the home subnet, does it treat the received >>> Valid Lifetime and Preferred Lifetime as fixed or decrementing? >>> I would think given the lack of other information, it should be >>> treated as decrementing. >>> >>> => RFC 2461 6.2.7 provides the answer (use the local fix/decrement mode). >> >> This gets back to the router prefix assumption. >> >> => this is an argument in favor of it because to look at router >> advertisments don't give all infos (thank for the proof :-). > > Yes, but this can be reasonably handled. It just has to be > defined somewhere so everyone does it the same way if its done > at all. I don't see that anything needs to be done, but it would be helpful if you can suggest some wording that needs to be added. >> I think the spec should explicitly state the remaining fields >> are transmitted exactly as if the message were sent on-link. >> >> => SHOULD or MUST? The I-D says "no other options"... > > Good question, I can see arguments for either. A SHOULD would > allow home agent developers to put in value-added features they > may think of later. Would the home agent seriously break neighbor > discovery or stateless address autoconfiguration by sending > different values of these fields to the mobile node? I don't see any arguments against SHOULD here. >> Is there a recommended way to avoid this duplicate coverage? >> >> => none... Worse, if the mobile node reboots and sends a fresh home >> registration then the home agent can be confused and rejects it because >> of a bad sequence number (this point is supposed to be solved by the >> security stuff which resets SAs before but this is in old minutes, >> not in the spec). It should go in the spec somewhere. > New Question: > > Looking at draft-ietf-mobileip-ipv6-12 section 9.7 page 70, > should the conditions for sending a router advertisement to > a mobile node include some sort of unconditional periodic > retransmission? My concern is the home agent could define > a prefix with a fixed lifetime that the mobile node will treat > as decrementing in realtime. The prefix on the mobile node > could expire without any updates from the home agent. The > retransmission could occur on an hourly or even daily basis, > depending on the Preferred and Valid Lifetimes of the prefixes. I think that some sort of periodic transmission or extension to Binding Acknowledgement would be reasonable. Regards, Charlie P. ================================================================== "Powell, Ken" wrote: > > Sorry for the slow turn-around on this, I was sidetracked > by vacation and other priorities at work. > > > > > RFC 2461 section 6.2.7 states: > > > > "Note that it is not an error for different routers to > > advertise different sets of prefixes" > > > > => for me "no error" is requirement level below/weaker than a > > "MUST NOT". > > I read it to mean different routers "MAY" advertise different > sets of prefixes. > > > > > Section 9.7 of the Mobile IPv6 draft indicates that it was > > intended to support routers advertising different prefixes: > > > > "The home agent determines these conditions based on its > > own configuration as a router and based on the Router > > Advertisements that it receives on the home link." > > > > => and section 9.7 indicates the home agent should send changes > > for any prefixes of the link, the list is built by the union > > of configured prefixes on the home agent and prefixes listen > > on the link in router advertisements. Things are more simpler > > if both lists in the union are the same. > > I agree that things are simpler if both lists are the same, > but I don't think we can just assume they are without stating > that clearly in the Mobile IPv6 spec. > > > I think some of your other responses were based on the > > assumption that routers will advertise a consistent set > > of prefixes. I guess before we can resolve the details, > > we need to know if the Mobile IPv6 spec should or should > > not impose this restriction on the home subnet configuration. > > > > => mobile IPv6 spec imposes this restriction for router advertisements > > sent to the mobile node in case of an "important" change. > > I think you may have misinterpreted my statement. I meant to ask > should Mobile IPv6 impose a restriction that all routers on the > home subnet advertise a consistent set of prefixes? If not, then > the Mobile IPv6 spec needs to provide more details about how to > relay prefix information from all routers on the home subnet to > the mobile node. > > Perhaps there could be an alternative restriction that a Mobile > Agent's interface needs to be configured with all possible prefixes > advertised on the home link. Other routers don't. > > I wonder if there are any other ways to solve this problem. > > > => There is > > nothing about other router advertisements... > > My term "other router advertisements" was intended to mean > "router advertisements that the mobile agent receives on the home > link". > > > > > > I think more details are needed on how the home agent should > > > maintain its list of prefixes > > > > > > => I think it should use standard management and router > > renumbering > > > as other routers. > > > > Yes, if routers on the home subnet advertise the same set > > of prefixes. > > Otherwise, we need additional mechanisms to keep the set > > of home subnet > > prefixes available to the mobile node consistent. > > > > => if router management tools are not enough then the home > > agent should > > look at prefixes announced by router advertisements from other routers > > (cf section 9.7). > > Agreed, but which way should it be? > > > > > > Sections 4.3, 5.1, 9.3, and 9.5 describe how the mobile node > > > sends a Router bit to the home agent which the home agent must > > > in turn use for the IsRouter bit on proxy neighbor > > advertisements > > > for the mobile node. Why is this done? The mobile node can't > > > continue to function as a normal router to other nodes on the > > > home subnet can it? > > > > > > => the mobile node can be either a host or a router then the home > > > agent needs to know if it is a host or a router when it sends > > > proxy NAs (because of the IsRouter bit). The router bit > > in binding > > > updates provides this information. > > > > I asked this question because of the role the IsRouter bit plays > > in Neighbor Discovery. Specifically, the sole function of the > > IsRouter bit is to signal to hosts on the home link that a node > > which was previously acting as an on-link router is no longer > > capable of accepting messages on the link for forwarding. RFC > > 2461 section 7.3.3 states: > > > > "When a node detects that a neighbor has changed from being a > > router to being a host, the node MUST remove that router from > > the Default Router List and update the Destination Cache as > > described in Section 6.3.5. Note that a router may not be > > listed in the Default Router List, even though a Destination > > Cache entry is using it (e.g., a host was redirected to it). > > In such cases, all Destination Cache entries that reference > > the (former) router must perform next-hop determination > > again before using the entry." > > > > I don't believe RFC 2461 accounted for mobile routers. It seems > > to me that the above host processing makes just as much sense > > when a neighboring mobile router goes off-link as when a > > neighboring router switches from being a router to a host. > > > > => there is two independent parts in "being a router": > > - being an on-link router (this function uses the link-local address > > then will stop when the router goes off-link. Some implementations > > impose the gateway field of a route to be a link-local address, > > this is not stupid because an off-link router can't receive then > > forward packets on the link) > > - being involved in a protocol as a router (in general such > > a protocol > > is a routing protocol but there are other examples). In this case > > an address with a scope larger than the link is used and if the > > protocol looks at the neighbor discovery stuff then the IsRouter > > flag must be preserved (ie. there is no good reason than a router > > which goes off-link MUST become a host then the IsRouter flag > > MUST be transmitted in binding updates). > > Thanks, I didn't think of this second possible use of IsRouter. > > > Note: the IsRouter should be reset in proxy neighbor advertisements > > for the link-local address, for instance in duplicate address > > detection. > > Perhaps a SHOULD for a proxy router advertisement with a zero lifetime > > should be added too? > > > > However, I think this I-D should be able to cover how > > to initialize its state on the home agent and the mobile node > > from a limited amount of information that is relatively easy > > to configure. For example, start with the assumption that the > > mobile node can always get the Home Agent's Anycast Address. > > > > => I agree this is useful but I think this is out of the > > scope of the I-D. > > Perhaps it would help if I backed up a little. The Mobile IPv6 > draft explains how to handle many parts of stateless address > autoconfiguration between a mobile node and the home network. > This led me to believe that Mobile IPv6 aught to work with a > home subnet that runs stateless address autoconfiguration only. > I tried to understand how a Mobile IPv6 node would initialize > its addresses on power-up using stateless address auto- > configuration when away from home. The steps I came up with > were: > > 1) Get the home network mobile agent anycast address. > (Method for this is beyond the scope of this spec) > > 2) Send Home Agent Address Discovery Request message > to home network. > > 3) Receive Home Agent Address Discovery Reply message. > > Now I'm stuck. I still need to: > > 4) Autoconfigure the mobile node's home network global > addresses from router advertisements sent by the > home agent. This cannot be done without the primary > care-of address binding due to the way router > advertisements are tunneled. > > 5) Create the primary care-of address binding. This > cannot be done without the mobile node having a > global address on the home network. > > What information can I expect the mobile node have to break > this deadlock? Is my reading of how this should work way off? > > > > > > Comments on Specific Sections: > > > > > > Page 14: > > > > > > Should section 4.3 (Conceptual Data Structures) > > define a place > > > where the home agent would store the state of all prefixes > > > advertised by other routers on the home subnet? > > > > > > => the home agent should act as a standard router for this. > > > > Yes, but only if all routers on the home subnet advertise the > > same set of prefixes. > > > > => it is simpler to add the unknown prefixes to the home > > agent prefix list > > (hosts will not see the difference) but a clarification is needed. > > I'm not sure exactly what you mean. Would the home agent > dynamically add the prefix from another router on the link > to its own list and automatically start advertising that prefix? > > > > > > Page 42 penultimate paragraph: > > > "In a solicited Router Advertisement, a router MUST > > > include at least one Prefix Information option with > > > the router Address (R) bit set." > > > > > > This looks like a requirement on all IPv6 routers. I > > > understand why this is a MUST for mobile agents, but > > > I don't get the reasoning for routers that are not acting > > > as mobile agents. > > > > > > => the rationate at the beginning of 6.2 is only about > > home agents > > > then I agree: R bit must be defined for routers but the > > MUST is only > > > for home agents. But I know some situations where router > > addresses > > > are very useful then I'd like to have a SHOULD for > > routers which are > > > not home agents. > > > > I don't understand why "SHOULD" as opposed to "MAY". > > > > => I think you don't understand because of this next statement: > > > > I don't see why a router implementation that has no mobile agent > > support should do this. > > > > => because this gives a nice way to know a global address of a router: > > router advertisements carry only the link-local address and to take > > a prefix and the interface ID from the link-local address is *not* > > a reliable way to get one. > > There are some situations where it is useful: > > - management (it solves the topology discovery issue described by > > Jean-Luc Richier, you know routers the link, you send SNMP queries > > to know further routers and you get only unusable link-local > > addresses, > > with global or site-local addresses you can queries second > > then higher > > layer routers). > > - point-to-point links: some OSs want to get both addresses when you > > add a new prefix. > > - just ask in the IPng list for many other examples... > > This is plenty, I'm convinced. "SHOULD" sounds good. > > > > > I would like to distinguish between the subnet prefix associated > > with the home address on the mobile node's Binding Update, and > > the other subnet prefixes on the home network. > > > > => the problem is this distinction doesn't work for connections which > > are not initiated my the mobile node, for instance when the DNS has > > the whole set of home addresses. > > The latest draft went a long way to clear up my concerns here. > If I read the changes right, the lifetime of bindings with > correspondent nodes is no longer limited to be less than the > lifetime of the binding with the home agent. I was worried > that a mobile node would have to drop all bindings to all > nodes at the end of a renumbering process on the home network. > That won't happen now. > > > > > I agree that when the former times-out, the binding cache entry > > for the mobile node should be flushed. I don't think the binding > > between the mobile node and the home agent should be purged when > > other subnet prefixes on the home network timeout. They > > are not needed > > to maintain communication between the home agent and the mobile > > node, and the mobile node has individual timers on the other > > home addresses which will expire on their own. > > > > => you forget the home agent is a correspondent too then the binding > > cache entry must be flushed as soon as an address in the set timeouts > > (correspondents are simpler because they have one home > > address by entry, > > the prefix length stuff gives one entry for the whole set but this has > > a cost). > > Good point. > > > > > > When a mobile agent receives a router advertisement from > > > another router on the home subnet, does it treat > > the received > > > Valid Lifetime and Preferred Lifetime as fixed or > > decrementing? > > > I would think given the lack of other information, > > it should be > > > treated as decrementing. > > > > > > => RFC 2461 6.2.7 provides the answer (use the local > > fix/decrement mode). > > > > This gets back to the router prefix assumption. > > > > => this is an argument in favor of it because to look at router > > advertisments don't give all infos (thank for the proof :-). > > Yes, but this can be reasonably handled. It just has to be > defined somewhere so everyone does it the same way if its done > at all. > > > > > > What should the mobile agent set the following > > fields to when > > > sending a router advertisement to a mobile node? > > > > > > M (managed address configuration flag) > > > O (other stateful address configuration flag) > > > H (home agent flag) > > > Router Lifetime > > > Reachable Time > > > Retrans Timer > > > Prefix Information > > > L (on-link flag) > > > A (autonomous address configuration flag) > > > R (router address flag) > > > Valid Lifetime > > > Preferred Lifetime > > > Prefix > > > > > > => I don't see a reason to send something different than on > > > the home link? > > > > I guess the possible issues I can think of are: > > > > Retrans Timer: I don't know how address timers are to be > > handled on mobile nodes. For now, I assume > > the mobile node continues to time-out home > > addresses as if they were on-link. Given that, > > the router advertisement must be retransmitted > > periodically by the home agent. I understand > > the time between retransmissions would be > > much greater than on-link. What should this > > time period be? Should this field in the > > advertisement be adjusted accordingly? > > > > => the retrans timer is for NUD and address resolution, the > > mobile node > > can't do something useful with it... > > > > L (on-link flag): The mobile node is no longer on-link. > > As far as I can tell, all communication > > to nodes on the home subnet will work > > exactly like communication to any other > > off-link node. > > > > => idem, it doesn't matter but there is an interesting case: > > - there is only one prefix announced on the link (what you call > > the home subnet?) > > - this prefix is off-link, ie. there are nodes in the prefix > > on other links > > - the mobile node is connected to one of these links. > > IMHO the mobile node is still at home and routing between nodes in the > > prefix must be done with host routes: this is like > > paging/micro mobility > > and needs draft-nordmark-ipv6-aaa-hooks-00.txt registration to work... > > Looking at it again, I agree. These fields don't need any special > handling. > > > > > I think the spec should explicitly state the remaining fields > > are transmitted exactly as if the message were sent on-link. > > > > => SHOULD or MUST? The I-D says "no other options"... > > Good question, I can see arguments for either. A SHOULD would > allow home agent developers to put in value-added features they > may think of later. Would the home agent seriously break neighbor > discovery or stateless address autoconfiguration by sending > different values of these fields to the mobile node? > > > > > > Page 80 Section 10.7: > > > > > > Should a mobile node get its home network anycast > > address from > > > DNS as opposed to constructing it from the > > previously known home > > > network prefix? This would allow a mobile node to > > more easily > > > recover from renumbering events on the home network > > if it happens > > > to be disconnected while the renumbering event occurs. > > > > > > => "previously" is only a way to know the home network prefix > > > (and the way to know it is not specified by the I-D) then you MAY > > > do what you'd like... > > > > By "previously", I intended to convey that the mobile node > > remembers > > the numeric form of the home network prefix last used in > > non-volatile > > memory. I don't think this would be a good thing to do. > > The prefix may > > change. > > > > => we agree, DNS is a superior way but again this is out of the scope. > > OK. > > > > > Is there a recommended way to avoid this duplicate coverage? > > > > => none... Worse, if the mobile node reboots and sends a fresh home > > registration then the home agent can be confused and rejects > > it because > > of a bad sequence number (this point is supposed to be solved by the > > security stuff which resets SAs before but this is in old minutes, > > not in the spec). > > > > If not, should the home agent recognize this as a > > duplicate entry and > > purge the old one? > > > > => same answer, and the issue is open when there is more than > > one home agent. > > Thanks for the history on this. > > New Question: > > Looking at draft-ietf-mobileip-ipv6-12 section 9.7 page 70, > should the conditions for sending a router advertisement to > a mobile node include some sort of unconditional periodic > retransmission? My concern is the home agent could define > a prefix with a fixed lifetime that the mobile node will treat > as decrementing in realtime. The prefix on the mobile node > could expire without any updates from the home agent. The > retransmission could occur on an hourly or even daily basis, > depending on the Preferred and Valid Lifetimes of the prefixes. > > Ken Powell > Compaq Computer Corporation From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Sep 22 17:40: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 SMTP id RAA26910 for ; Fri, 22 Sep 2000 17:40:20 -0400 (EDT) Received: from standards (47.234.32.16:1228) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB96CDA@standards.nortelnetworks.com>; Fri, 22 Sep 2000 17:24:06 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 24830 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 22 Sep 2000 17:24:06 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB96CD9@standards.nortelnetworks.com>; Fri, 22 Sep 2000 17:24:05 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA13604; Fri, 22 Sep 2000 14:37:57 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e8MLbte08067; Fri, 22 Sep 2000 14:37:55 -0700 X-Virus-Scanned: Fri, 22 Sep 2000 14:37:55 -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) smtpddSrtlj; Fri, 22 Sep 2000 14:37:51 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: <39CBD131.3EBF82CD@iprg.nokia.com> Date: Fri, 22 Sep 2000 14:37:53 -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] Mobile IPv6 questions X-To: "Powell, Ken" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Ken, Following up on your next contribution to the discussion: > I had a few additional thoughts on my previous questions. >> should the conditions for sending a router advertisement to >> a mobile node include some sort of unconditional periodic >> retransmission? My concern is the home agent could define >> a prefix with a fixed lifetime that the mobile node will treat >> as decrementing in realtime. The prefix on the mobile node >> could expire without any updates from the home agent. The >> retransmission could occur on an hourly or even daily basis, >> depending on the Preferred and Valid Lifetimes of the prefixes. > Rather than having the home agent periodically retransmit > the router advertisement, would it be better to say the > mobile node SHOULD send a router solicit to the home agent > when any of it's home addresses' preferred or valid lifetimes > approach expiration? I think it would always be better for the home agent to send the advertisement without solicitation. Otherwise, we could easily get into the situation where we are periodically sending both solicitations AND advertisements. That would be twice as bad as periodically sending only advertisements. It will be even better for the mobile node to typically have prefixes with much longer lifetimes, and then to rely on relatively shorter intervals between Binding Updates. This should be a matter of administrative policy, about which we need to get more deployment experience. The mobile node should, of course, send a solicitation if it starts to get nervous about impending address deprecation. > The Binding Request/Update sequence described in section 9.7 > is used as an acking mechanism to ensure the mobile node > receives an unsolicited router advertisement. For solicited > router advertisements, RFC 2461 section 6.3.7 says > the mobile node may transmit the router solicitation up to > MAX_RTR_SOLICITATIONS (3) times, each separated by at least > RTR_SOLICITATION_INTERVAL (4) seconds. If no response occurs, > the mobile node could perform home agent address discovery > again. > >> If not, then should the home >> agent send a router advertisement with all known home subnet >> prefixes to the mobile node with the first Binding >> Acknowledgement? This will account for prefixes the home >> agent knows which the mobile node doesn't. >> >> => this is a nice idea. > > I noticed this was not added to the latest revision of the > Mobile IPv6 spec. It would probably be cleaner to have the > mobile node send a router solicitation with the first binding > update it sends to a new home agent instead. This would > would achieve the same result by triggering the home agent to > send a router advertisement with all known prefixes. I don't see any reason not to add this feature. Contributing text is always appreciated. >> > However, I think this I-D should be able to cover how >> > to initialize its state on the home agent and the mobile node >> > from a limited amount of information that is relatively easy >> > to configure. For example, start with the assumption that the >> > mobile node can always get the Home Agent's Anycast Address. >> > >> > => I agree this is useful but I think this is out of the >> > scope of the I-D. > > I think a few restrictions on the process may be > useful. Perhaps something like: > > The method for initializing a mobile node's > home addresses on power-up or after an extended > period of being disconnected from the network > is beyond the scope of this specification. > Whatever procedure is used, it SHOULD result > in the mobile node having the same stateless or > statefull (DHCPv6) home address autoconfiguration > information it would have if it were attached to > the home network. Due to the possibility that the > home network could be renumbered while the mobile > node is disconnected, the mobile node SHOULD NOT > rely on storing these addresses locally. This does not take into account the possibility for the mobile to use a statically allocated home address, but I generally agree with it except that I think that the mobile node SHOULD be able to try to use locally stored addresses, at least up to some pretty long time like a month or so. >> I tried to understand how a Mobile IPv6 node would >> initialize its addresses on power-up using stateless >> address autoconfiguration when away from home. The >> steps I came up with were: >> >> >> >> What information can I expect the mobile node have to >> break this deadlock? Is my reading of how this should >> work way off? > Would it be reasonable for a mobile node to > generate a temporary home address for itself using: > > o the subnet prefix from the home network's mobile > agent anycast address, and > > o the globally unique interface identifier that > would have been used to generate the link local > address if the mobile node were attached directly > to the home network. > Such a temporary address could be used to establish > a binding with a home agent in the absence of any > other known home addresses. It could be created with > short valid lifetime and a preferred lifetime of zero > to ensure a quick transition to other addresses > generated when stateless or statefull (DHCPv6) > address autoconfiguration runs. As I said in the last note, which included this same text, this seems like a generally good idea for the case when the mobile node really cannot remember a good home address. It should not be used in preference to a statically allocated home address. > If this were allowed, I can see how a mobile node > could initialize by: > > 1) Query DNS for the home network's mobile agent > anycast address. > > 2) Generate a temporary home address as defined above. > > 3) Send a Home Agent Address Discovery Request message > to the home network. > > 4) Receive Home Agent Address Discovery Reply message. > > 5) Send a binding update option with a router solicit > to a home agent using the temporary home address. > > 6) Receive a binding acknowledgement option with a > router advertisement from the home agent. This router > advertisement could indicate to use stateless and/or > statefull address autoconfiguration. If statefull, > start the DHCPv6 procedures. > > 7) Autoconfigure home addresses according to the prefix > information options received. > > 8) Send binding update option(s) to establish bindings > for the new home addresses (if needed). Should this be made into an appendix in the draft? Regards, Charlie P. ================= ORIGINAL NOTE FOLLOWS ==================== "Powell, Ken" wrote: > > I had a few additional thoughts on my previous questions. > > > should the conditions for sending a router advertisement to > > a mobile node include some sort of unconditional periodic > > retransmission? My concern is the home agent could define > > a prefix with a fixed lifetime that the mobile node will treat > > as decrementing in realtime. The prefix on the mobile node > > could expire without any updates from the home agent. The > > retransmission could occur on an hourly or even daily basis, > > depending on the Preferred and Valid Lifetimes of the prefixes. > > Rather than having the home agent periodically retransmit > the router advertisement, would it be better to say the > mobile node SHOULD send a router solicit to the home agent > when any of it's home addresses' preferred or valid lifetimes > approach expiration? The router solicit could contain: > > Source: Mobile Node's primary care-of address > Dest: Home Agent's address > Destination Options w/ > Home Address Option w/ > Home Address: Mobile Node's Home Address > Authentication header > Router Solicitation > > The Home Agent could respond with a Router Advertisement > as sent in section 9.7 with all address prefixes for the > home network. However, there would be no Binding Request > option needed with the Router Advertisement. > > The Binding Request/Update sequence described in section 9.7 > is used as an acking mechanism to ensure the mobile node > receives an unsolicited router advertisement. For solicited > router advertisements, RFC 2461 section 6.3.7 says > the mobile node may transmit the router solicitation up to > MAX_RTR_SOLICITATIONS (3) times, each separated by at least > RTR_SOLICITATION_INTERVAL (4) seconds. If no response occurs, > the mobile node could perform home agent address discovery > again. > > > If not, then should the home > > agent send a router advertisement with all known home subnet > > prefixes to the mobile node with the first Binding > > Acknowledgement? This will account for prefixes the home > > agent knows which the mobile node doesn't. > > > > => this is a nice idea. > > I noticed this was not added to the latest revision of the > Mobile IPv6 spec. It would probably be cleaner to have the > mobile node send a router solicitation with the first binding > update it sends to a new home agent instead. This would > would achieve the same result by triggering the home agent to > send a router advertisement with all known prefixes. > > > > However, I think this I-D should be able to cover how > > > to initialize its state on the home agent and the mobile node > > > from a limited amount of information that is relatively easy > > > to configure. For example, start with the assumption that the > > > mobile node can always get the Home Agent's Anycast Address. > > > > > > => I agree this is useful but I think this is out of the > > > scope of the I-D. > > I think a few restrictions on the process may be > useful. Perhaps something like: > > The method for initializing a mobile node's > home addresses on power-up or after an extended > period of being disconnected from the network > is beyond the scope of this specification. > Whatever procedure is used, it SHOULD result > in the mobile node having the same stateless or > statefull (DHCPv6) home address autoconfiguration > information it would have if it were attached to > the home network. Due to the possibility that the > home network could be renumbered while the mobile > node is disconnected, the mobile node SHOULD NOT > rely on storing these addresses locally. > > > I tried to understand how a Mobile IPv6 node would > > initialize its addresses on power-up using stateless > > address autoconfiguration when away from home. The > > steps I came up with were: > > > > > > > > What information can I expect the mobile node have to > > break this deadlock? Is my reading of how this should > > work way off? > > Would it be reasonable for a mobile node to > generate a temporary home address for itself using: > > o the subnet prefix from the home network's mobile > agent anycast address, and > > o the globally unique interface identifier that > would have been used to generate the link local > address if the mobile node were attached directly > to the home network. > > Such a temporary address could be used to establish > a binding with a home agent in the absence of any > other known home addresses. It could be created with > short valid lifetime and a preferred lifetime of zero > to ensure a quick transition to other addresses > generated when stateless or statefull (DHCPv6) > address autoconfiguration runs. > > If this were allowed, I can see how a mobile node > could initialize by: > > 1) Query DNS for the home network's mobile agent > anycast address. > > 2) Generate a temporary home address as defined above. > > 3) Send a Home Agent Address Discovery Request message > to the home network. > > 4) Receive Home Agent Address Discovery Reply message. > > 5) Send a binding update option with a router solicit > to a home agent using the temporary home address. > > 6) Receive a binding acknowledgement option with a > router advertisement from the home agent. This router > advertisement could indicate to use stateless and/or > statefull address autoconfiguration. If statefull, > start the DHCPv6 procedures. > > 7) Autoconfigure home addresses according to the prefix > information options received. > > 8) Send binding update option(s) to establish bindings > for the new home addresses (if needed). > > Ken Powell > Compaq Computer Corporation From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Sep 23 12:52:29 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22505 for ; Sat, 23 Sep 2000 12:52:27 -0400 (EDT) Received: from standards (47.234.32.16:3310) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB96FB9@standards.nortelnetworks.com>; Sat, 23 Sep 2000 12:36:13 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 25799 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 23 Sep 2000 12:36:13 -0400 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB96FB8@standards.nortelnetworks.com>; Sat, 23 Sep 2000 12:36:12 -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 e8NGeAu27528; Sat, 23 Sep 2000 18:40:11 +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 SAA14076; Sat, 23 Sep 2000 18:40:10 +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 SAA44046; Sat, 23 Sep 2000 18:42:18 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-ID: <200009231642.SAA44046@givry.rennes.enst-bretagne.fr> Date: Sat, 23 Sep 2000 18:42:18 +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 question about MIPv6 and IPSec X-To: Stefan Schmid To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Fri, 22 Sep 2000 20:56:07 BST. In your previous mail you wrote: Under certain circumstances there might be some sense in reading it that way, however, Note 1 does not say the first DO header is valid only if there is a routing header. => I don't know the meaning of note 1 if there is no routing header... Do you know the exact reason why the HA option could not be skipped by intermediate nodes? => first bits are not 00 then the HA option will not be skipped. This wouldn't be a problem if intermediate nodes don't process the mobileip options :-). => the current meaning of note 1 is "if intermediate nodes should process the options, put them here" and note 3 is "if only the final destination should process the options, put them there". Unfortunately, this would require modification to current spec(s) :-( => the mobile IPv6 ID should not ignore this issue... Assuming the mobile I-D is compliant with the IPv6 spec (RFC 2460), => it is not compliant! I expect the next one will be. Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Sep 23 13:39:05 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22687 for ; Sat, 23 Sep 2000 13:39:04 -0400 (EDT) Received: from standards (47.234.32.16:3310) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB97011@standards.nortelnetworks.com>; Sat, 23 Sep 2000 13:23:19 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 25920 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 23 Sep 2000 13:23:19 -0400 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB97010@standards.nortelnetworks.com>; Sat, 23 Sep 2000 13:23:18 -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 e8NHb3u30894; Sat, 23 Sep 2000 19:37:03 +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 TAA14369; Sat, 23 Sep 2000 19:37:03 +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 TAA44354; Sat, 23 Sep 2000 19:39:11 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-ID: <200009231739.TAA44354@givry.rennes.enst-bretagne.fr> Date: Sat, 23 Sep 2000 19:39:11 +0200 Reply-To: Francis.Dupont@ENST-BRETAGNE.FR Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] New version of "Mobility Support in IPv6" draft X-To: charliep@IPRG.NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Fri, 22 Sep 2000 12:28:57 PDT. <39CBB2F9.9CD9EE2D@iprg.nokia.com> In your previous mail you wrote: My understanding is that the current specification makes it mandatory to copy the home address into the ip6_src field of the IPv6 header. Swapping should not be performed. Here, "replace" means "copy over". I reckon that the current specification should be made unequivocal on this point. => I disagree. You need to protect both the source address and the address in the home address option (they should be the care-of and the home addresses of the mobile). If you consider a common binding update then you can see why this is important. IMHO addresses must be swapped but there are two incompatible ways to do this: - swap field contents (easy, simple but some people don't like this) - swap pointers (more difficult but keeps the packet read-only). Someone must do the choice and write the result in the draft! ---- insert big logical break delimiter at this point --------- While thinking about the effects of this requirement, I found myself wondering why. It seems like the natural processing for the mobile node, when creating the Authentication Header, would be to calculate the authentication data starting with the predictable fields of the IPv6 header and extensions with as little change as possible. => you should consider the receiving side for AH processing. When the receiving side executes the home address option then it updates the source address (the field itself (physical) and the pointer to it (logical)). The AH is after then the source address is supposed to be the home address when the AH is processed and (the important point) when the security code looks for its parameters. I would think that, typically, the IPv6 header already has the mobile node's Care-of Address inserted as the ip6_src field before the Authentication Header calculation is initiated. => it is not so clear and: - the security parameters lookup (SPD/SADB) is more important than the AH calculation itself and must be done with the home address. - the AH calculation has to deal with mobility anyway. Then, in order to make the spec work, the mobile node has to proceed as follows: - Put in its home address as ip6_src, temporarily - Do the AH thing - Restore its care-of address as ip6_src. This seems like a lot of extra work, and a very handy place to put bugs. => AH calculation is in general a very handy place to put bugs. Mobility doesn't make things worse, it just justifies we keep AH (:-). What if we make it so that the recipient uses the address in the Home Address option to select the appropriate security association? => this is an important point. The current spec makes this easy for the recipient which: - is the way AH processing is defined (cf routing header case) - puts the burden on the mobile node shoulders - works. I understand the current specification to be fashioned so that the recipient can select the security association based on the contents of the source IPv6 address in the IPv6 header. However, whether or not to actually CHANGE the fields, treating them as mutable, => swapping pointers is better for that (it was proposed by Microsoft Research people who consider the packet as read-only) seems to introduce a lot of unnecessary specification difficulties that could be avoided. Changing the way that a security association is looked up seems a lot cheaper than copying and recopying data within the challenge data. => I am not convinced by your argument. In fact I am not convinced by any argument for field or pointer swapping (:-)... Both are not obviously right but this is a minor point: the real issue is to deal with IKE (the draft proposal works, this is just a bit hard to implement and very hard to configure). If everybody hates this idea, then just forget I mentioned it! => the only thing I really hate is to have no clear statement in the current draft. It will make one half of secure mobile IPv6 implementations not interoperable with mine... Thanks Francis.Dupont@enst-bretagne.fr PS: another missing point in the current mobile IPv6 draft: the home agent is a router then can have more than one address then the draft should *accurately* specify what address the home agent MUST use as the source address of tunneled packet (the answer is obvious but a specification is better than common sense, don't forget a paranoid mobile node will check the source address of tunneled packets). (the similar issue for BA/BR is already in the mailing list archive because it simply breaks sequence number check) From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Sep 24 20:52: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 SMTP id UAA11515 for ; Sun, 24 Sep 2000 20:52:01 -0400 (EDT) Received: from standards (47.234.32.16:4054) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9723D@standards.nortelnetworks.com>; 24 Sep 2000 20:35:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 26682 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 24 Sep 2000 20:35:52 -0400 Received: from sirius.ctr.columbia.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9723C@standards.nortelnetworks.com>; 24 Sep 2000 20:35: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 UAA21516; Sun, 24 Sep 2000 20:49:45 -0400 (EDT) X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39CECF24.AF8C6C58@comet.columbia.edu> Date: Sun, 24 Sep 2000 21:05:56 -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] Cellular IP/Linux Source Code Release X-To: cellularip@comet.columbia.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit http://comet.columbia.edu/cellularip/ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Sep 25 05:15: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 SMTP id FAA28827 for ; Mon, 25 Sep 2000 05:15:13 -0400 (EDT) Received: from standards (47.234.32.16:2867) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB973AF@standards.nortelnetworks.com>; Mon, 25 Sep 2000 4:58:57 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 27181 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 25 Sep 2000 04:58:56 -0400 Received: from iti-idsc.gov.eg by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB973AD@standards.nortelnetworks.com>; Mon, 25 Sep 2000 4:58:54 -0400 Received: from communication ([163.121.19.166]) by iti-idsc.gov.eg (8.9.3+Sun/8.9.3) with ESMTP id MAA24719; Mon, 25 Sep 2000 12:18:40 +0300 (EEST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C026E9.FAF57680" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.37 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.37 Message-ID: <001001c026d0$dd4036c0$a61379a3@communication> Date: Mon, 25 Sep 2000 12:13:14 +0300 Reply-To: azza aziz Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: azza aziz Subject: [MOBILE-IP] X-cc: listserv@standards.nortelnetworks.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C026E9.FAF57680 Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable unsubscribe ------=_NextPart_000_000B_01C026E9.FAF57680 Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
unsubscribe
------=_NextPart_000_000B_01C026E9.FAF57680-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Sep 25 08:31: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 SMTP id IAA01534 for ; Mon, 25 Sep 2000 08:31:58 -0400 (EDT) Received: from standards (47.234.32.16:2418) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB97451@standards.nortelnetworks.com>; Mon, 25 Sep 2000 8:15:55 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 27384 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 25 Sep 2000 08:15:55 -0400 Received: from esebh01nok.ntc.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB97450@standards.nortelnetworks.com>; Mon, 25 Sep 2000 8:15:55 -0400 Received: by esebh01nok with Internet Mail Service (5.5.2650.10) id ; Mon, 25 Sep 2000 15:29:54 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <6D1A8E7871B9D211B3B00008C7490AA504E622AE@treis03nok> Date: Mon, 25 Sep 2000 15:29:52 +0300 Reply-To: henry.haverinen@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Henry Haverinen Subject: [MOBILE-IP] Vendor/Organization-Specific Extensions To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi all, I have some questions concerning draft-ietf-mobileip-vendor-ext-11.txt. Section 2.3 doesn't cover the case of an Agent Advertisement containing a CVSE. Is this because the operation is obvious (MN must silently discard the Advertisement)? Such an extension is useful if a FA doesn't want to receive Registration Requests from MNs that don't support a certain vendor/ organization-specific feature. I wonder why the current version of the vendor-ext draft doesn't suggest any type values for the extensions but just says "to be assigned by IANA". Did the type values used in previous versions (38 and 134) overlap with some other draft? It might be a good idea to give some initial guesses for the types so that people can be implement the draft and test the interoperability of their implementations. I guess even the vendor- specific extensions should be tested for interoperability, as the draft specifies processing considerations for unrecognized vendor types. Regards, Henry From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Sep 25 09:12: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 SMTP id JAA02520 for ; Mon, 25 Sep 2000 09:12:32 -0400 (EDT) Received: from standards (47.234.32.16:2418) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB974B1@standards.nortelnetworks.com>; Mon, 25 Sep 2000 8:56:26 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 27495 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 25 Sep 2000 08:56:26 -0400 Received: from smtp-2.hut.fi by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB974A6@standards.nortelnetworks.com>; Mon, 25 Sep 2000 8:46:25 -0400 Received: from vesper.tky.hut.fi (IDENT:qmailr@vesper.tky.hut.fi [130.233.19.15]) by smtp-2.hut.fi (8.9.3/8.9.3) with SMTP id QAA68354 for ; Mon, 25 Sep 2000 16:00:23 +0300 (EEST) Received: (qmail 13683 invoked by uid 500); 25 Sep 2000 13:00:13 -0000 References: <200009231642.SAA44046@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6us Message-ID: <20000925160013.A13447@vesper.tky.hut.fi> Date: Mon, 25 Sep 2000 16:00:13 +0300 Reply-To: Antti Tuominen Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Antti Tuominen Subject: Re: [MOBILE-IP] Implementation question about MIPv6 and IPSec X-To: Francis Dupont To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200009231642.SAA44046@givry.rennes.enst-bretagne.fr>; from Francis Dupont on Sat, Sep 23, 2000 at 06:42:18PM +0200 On Sat, Sep 23, 2000 at 06:42:18PM +0200, Francis Dupont wrote: > Hello! Since I'm a first time poster on this list, I will say a word or two about myself. I'm a computer science and engineering student doing my master's thesis on using IPv6 in mobile ad hoc networks. I work as a research assistant at telecommunication software lab at HUT and am involved in a Mobile IPv6 implementation for Linux. > => I don't know the meaning of note 1 if there is no routing header... If you take a look at "The Case for IPv6" (http://www.ietf.org/internet-drafts/draft-iab-case-for-ipv6-06.txt) section 2.4, it says: "A Destination Header appearing after a Routing Header, or without a Routing Header, will be processed only by the final destination." Though I perfectly well understand that this document is no specification whatsoever it does imply that RFC 2460 does mean that intermediate nodes should not process the first DO if no routing header is present. > => the current meaning of note 1 is "if intermediate nodes should process > the options, put them here" and note 3 is "if only the final destination > should process the options, put them there". If there is a routing header, that is. Regards, Antti -- Antti J. Tuominen, JMT 3A 131, FIN-02150 Espoo, Finland. Research assistant, TSE Institute at Helsinki University of Technology work: ajtuomin@tml.hut.fi; home: tuominen@iki.fi From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Sep 25 10:06: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 SMTP id KAA03892 for ; Mon, 25 Sep 2000 10:06:03 -0400 (EDT) Received: from standards (47.234.32.16:2418) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB975ED@standards.nortelnetworks.com>; Mon, 25 Sep 2000 9:51:11 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 27920 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 25 Sep 2000 09:51:11 -0400 Received: from zmamail05.zma.compaq.com (mailout.zma.compaq.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB975EC@standards.nortelnetworks.com>; Mon, 25 Sep 2000 9:51:04 -0400 Received: by zmamail05.zma.compaq.com (Postfix, from userid 12345) id 46A37290B; Mon, 25 Sep 2000 10:04:58 -0400 (EDT) Received: from exctay-gh02.tay.cpqcorp.net (exctay-gh02.tay.cpqcorp.net [16.103.129.52]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 32DEC1639; Mon, 25 Sep 2000 10:04:58 -0400 (EDT) Received: by exctay-gh02.tay.cpqcorp.net with Internet Mail Service (5.5.2650.21) id ; Mon, 25 Sep 2000 10:04:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Mon, 25 Sep 2000 10:04:53 -0400 Reply-To: "Powell, Ken" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Powell, Ken" Subject: Re: [MOBILE-IP] Mobile IPv6 questions X-To: "Charles E. Perkins" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: Friday, September 22, 2000 5:28 PM > To: Powell, Ken > Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Mobile IPv6 questions > > > > Hello Ken, > > I am responding to a note you sent earlier this year, which > I have appended in its entirety after my comments. I apologize > for the length, but I thought it was important to try to get > to a good resolution for all of your points. Thanks. I appreciate that. > >> I think some of your other responses were based on the > >> assumption that routers will advertise a consistent set > >> of prefixes. I guess before we can resolve the details, > >> we need to know if the Mobile IPv6 spec should or should > >> not impose this restriction on the home subnet configuration. > >> > >> => mobile IPv6 spec imposes this restriction for router > advertisements > >> sent to the mobile node in case of an "important" change. > > > > I think you may have misinterpreted my statement. I meant to ask > > should Mobile IPv6 impose a restriction that all routers on the > > home subnet advertise a consistent set of prefixes? If not, then > > the Mobile IPv6 spec needs to provide more details about how to > > relay prefix information from all routers on the home subnet to > > the mobile node. > > > > Perhaps there could be an alternative restriction that a Mobile > > Agent's interface needs to be configured with all possible prefixes > > advertised on the home link. Other routers don't. > > > > I wonder if there are any other ways to solve this problem. > > What if the home agent supplies router advertisements to the > mobile node whenever advertised prefix information changes? That would work. The trick is making sure inconsistent information on specific prefixes is handled correctly. I think I spelled out more details on that in a later note. > > >> > I think more details are needed on how the home agent should > >> > maintain its list of prefixes > >> > > >> > => I think it should use standard management and router > renumbering > >> > as other routers. > >> > >> Yes, if routers on the home subnet advertise the same set > of prefixes. > >> Otherwise, we need additional mechanisms to keep the set > of home subnet > >> prefixes available to the mobile node consistent. > > I don't think that the information to the mobile node has to be > any more consistent while it is away than it would be if it were > at home. And, the way things look at home is dictated by other > specifications, not Mobile IPv6. I agree. My intent is to have the addresses a mobile node configures when away from home be consistent with the ones it would configure when home. > > >>> Sections 4.3, 5.1, 9.3, and 9.5 describe how the mobile node > >>> sends a Router bit to the home agent which the home agent must > >>> in turn use for the IsRouter bit on proxy neighbor > advertisements > >>> for the mobile node. Why is this done? The mobile node can't > >>> continue to function as a normal router to other nodes on the > >>> home subnet can it? > >>> > >>> => the mobile node can be either a host or a router then the home > >>> agent needs to know if it is a host or a router when it sends > >>> proxy NAs (because of the IsRouter bit). The router bit in binding > >>> updates provides this information. > >> > >> I asked this question because of the role the IsRouter bit plays > >> in Neighbor Discovery. Specifically, the sole function of the > >> IsRouter bit is to signal to hosts on the home link that a node > >> which was previously acting as an on-link router is no longer > >> capable of accepting messages on the link for forwarding. RFC > >> 2461 section 7.3.3 states: > >> > >> "When a node detects that a neighbor has changed from being a > >> router to being a host, the node MUST remove that router from > >> the Default Router List and update the Destination Cache as > >> described in Section 6.3.5. Note that a router may not be > >> listed in the Default Router List, even though a Destination > >> Cache entry is using it (e.g., a host was redirected to it). > >> In such cases, all Destination Cache entries that reference > >> the (former) router must perform next-hop determination > >> again before using the entry." > >> > >> I don't believe RFC 2461 accounted for mobile routers. It seems > >> to me that the above host processing makes just as much sense > >> when a neighboring mobile router goes off-link as when a > >> neighboring router switches from being a router to a host. > >> > >> => there is two independent parts in "being a router": > >> - being an on-link router (this function uses the > link-local address > >> then will stop when the router goes off-link. Some > implementations > >> impose the gateway field of a route to be a link-local address, > >> this is not stupid because an off-link router can't receive then > >> forward packets on the link) > >> - being involved in a protocol as a router (in general > such a protocol > >> is a routing protocol but there are other examples). In > this case > >> an address with a scope larger than the link is used and if the > >> protocol looks at the neighbor discovery stuff then the IsRouter > >> flag must be preserved (ie. there is no good reason > than a router > >> which goes off-link MUST become a host then the IsRouter flag > >> MUST be transmitted in binding updates). > > > > > Thanks, I didn't think of this second possible use of IsRouter. > > > >> Note: the IsRouter should be reset in proxy neighbor advertisements > >> for the link-local address, for instance in duplicate > address detection. > >> Perhaps a SHOULD for a proxy router advertisement with a > zero lifetime > >> should be added too? > >> > >> However, I think this I-D should be able to cover how > >> to initialize its state on the home agent and the mobile node > >> from a limited amount of information that is relatively easy > >> to configure. For example, start with the assumption that the > >> mobile node can always get the Home Agent's Anycast Address. > >> > >> => I agree this is useful but I think this is out of the > >> scope of the I-D. > > I agree with most of this discussion. However, I think that > other nodes on the home link MUST NOT use the mobile node as > a default router while it is away from home, even if the mobile > node is still a legitimate router for some advertised prefixes. Good point. > > I tried to understand how a Mobile IPv6 node would initialize > > its addresses on power-up using stateless address auto- > > configuration when away from home. The steps I came up with > > were: > > > > 1) Get the home network mobile agent anycast address. > > (Method for this is beyond the scope of this spec) > > > > 2) Send Home Agent Address Discovery Request message > > to home network. > > > > 3) Receive Home Agent Address Discovery Reply message. > > > > Now I'm stuck. I still need to: > > > > 4) Autoconfigure the mobile node's home network global > > addresses from router advertisements sent by the > > home agent. This cannot be done without the primary > > care-of address binding due to the way router > > advertisements are tunneled. > > > > 5) Create the primary care-of address binding. This > > cannot be done without the mobile node having a > > global address on the home network. > > > > What information can I expect the mobile node have to break > > this deadlock? Is my reading of how this should work way off? > > A few days later on May 12, you wrote in another note: > > May12> Would it be reasonable for a mobile node to > May12> generate a temporary home address for itself using: > May12> > May12> o the subnet prefix from the home network's mobile > May12> agent anycast address, and > May12> > May12> o the globally unique interface identifier that > May12> would have been used to generate the link local > May12> address if the mobile node were attached directly > May12> to the home network. > > May12> Such a temporary address could be used to establish > May12> a binding with a home agent in the absence of any > May12> other known home addresses. It could be created with > May12> short valid lifetime and a preferred lifetime of zero > May12> to ensure a quick transition to other addresses > May12> generated when stateless or statefull (DHCPv6) > May12> address autoconfiguration runs. > > This seems like a generally good idea for the case > when the mobile node really cannot remember a good > home address. It should not be used in preference to > a statically allocated home address. I have a problem with the term "statically allocated" in IPv6. I understood addresses were to be generated through Stateless or Statefull (DHCPv6) Address Autoconfiguration. I hope we can avoid the need for anyone to manually configure IPv6 addresses on their mobile nodes. That said, I have no problem with the idea of a mobile node storing its last known home address as the most efficient address to use on subsequent reconnections. Mobile nodes just need a fall-back mechanism in case their saved home address becomes obsolete. > > May12> If this were allowed, I can see how a mobile node > May12> could initialize by: > May12> > May12> 1) Query DNS for the home network's mobile agent > May12> anycast address. > May12> > May12> 2) Generate a temporary home address as defined above. > May12> > May12> 3) Send a Home Agent Address Discovery Request message > May12> to the home network. > May12> > May12> 4) Receive Home Agent Address Discovery Reply message. > May12> > May12> 5) Send a binding update option with a router solicit > May12> to a home agent using the temporary home address. > May12> > May12> 6) Receive a binding acknowledgement option with a > May12> router advertisement from the home agent. This router > May12> advertisement could indicate to use stateless and/or > May12> statefull address autoconfiguration. If statefull, > May12> start the DHCPv6 procedures. > May12> > May12> 7) Autoconfigure home addresses according to the prefix > May12> information options received. > May12> > May12> 8) Send binding update option(s) to establish bindings > May12> for the new home addresses (if needed). > > Do you still think this is a reasonable approach? The difference > here is generating a temporary home address. That seems reasonable > to me, given that the mobile node can't remember its actual home > address. I think its reasonable, but I wouldn't put this in the main body of the spec. Perhaps it might be usefull in an appendix just as an explanation of how a node could be initialized. I know almost nothing about AAA. Could a more reliable technique for getting the initial addresses be easily added onto the AAA exchange? > ............ > > >>> When a mobile agent receives a router advertisement from > >>> another router on the home subnet, does it treat the received > >>> Valid Lifetime and Preferred Lifetime as fixed or > decrementing? > >>> I would think given the lack of other information, > it should be > >>> treated as decrementing. > >>> > >>> => RFC 2461 6.2.7 provides the answer (use the local > fix/decrement mode). > >> > >> This gets back to the router prefix assumption. > >> > >> => this is an argument in favor of it because to look at router > >> advertisments don't give all infos (thank for the proof :-). > > > > Yes, but this can be reasonably handled. It just has to be > > defined somewhere so everyone does it the same way if its done > > at all. > > I don't see that anything needs to be done, but it would be helpful > if you can suggest some wording that needs to be added. OK, can you give me about a week for this and other items you requested wording for? From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Sep 25 10:28: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 SMTP id KAA04283 for ; Mon, 25 Sep 2000 10:28:51 -0400 (EDT) Received: from standards (47.234.32.16:2418) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB97651@standards.nortelnetworks.com>; Mon, 25 Sep 2000 10:12:25 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 28036 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 25 Sep 2000 10:12:25 -0400 Received: from tml-gw.tml.hut.fi (tml.hut.fi) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB97642@standards.nortelnetworks.com>; Mon, 25 Sep 2000 10:02:25 -0400 Received: (from smap@localhost) by tml-gw.tml.hut.fi (8.8.7/8.8.7) id RAA08931 for ; Mon, 25 Sep 2000 17:16:22 +0300 Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0) id xma008929; Mon, 25 Sep 00 17:16:20 +0300 Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7]) by mail.tml.hut.fi (8.11.0/8.11.0) with ESMTP id e8PEGKM15343 for ; Mon, 25 Sep 2000 17:16:20 +0300 (EEST) Received: from localhost (lyang@localhost) by morphine.tml.hut.fi (8.9.2/8.7.1) with ESMTP id RAA14029 for ; Mon, 25 Sep 2000 17:16:14 +0300 (EET DST) X-Authentication-Warning: morphine.tml.hut.fi: lyang owned process doing -bs MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Mon, 25 Sep 2000 17:16:14 +0300 Reply-To: Linfeng Yang Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Linfeng Yang Subject: Re: [MOBILE-IP] Implementation question about MIPv6 and IPSec To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <20000925160013.A13447@vesper.tky.hut.fi> On Mon, 25 Sep 2000, Antti Tuominen wrote: > > => I don't know the meaning of note 1 if there is no routing header... > > If you take a look at "The Case for IPv6" > (http://www.ietf.org/internet-drafts/draft-iab-case-for-ipv6-06.txt) > section 2.4, it says: "A Destination Header appearing after a Routing > Header, or without a Routing Header, will be processed only by the > final destination." > > Though I perfectly well understand that this document is no > specification whatsoever it does imply that RFC 2460 does mean that > intermediate nodes should not process the first DO if no routing > header is present. Both "The Case of IPv6" and RFC 2460 suggest, as I understood, there will be only one DO (Destination Header) if there is no routing header. This only DO will appear just before upper layer header or another IPv6 header if encapsulation is employed. I guess that is the thought behind Francis' comments. Regards, Linfeng Yang Helsinki University of Technology Telecommunications Software and Multimedia Laboratory P.O.Box 9700, 02015 HUT, Finland Phone: +358 9 451 5250 Fax: +358 9 451 5351 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Sep 25 11:14: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 SMTP id LAA05212 for ; Mon, 25 Sep 2000 11:14:55 -0400 (EDT) Received: from standards (47.234.32.16:2418) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9773B@standards.nortelnetworks.com>; Mon, 25 Sep 2000 10:58:22 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 28347 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 25 Sep 2000 10:58:22 -0400 Received: from zmamail05.zma.compaq.com (mailout.zma.compaq.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9773A@standards.nortelnetworks.com>; Mon, 25 Sep 2000 10:58:18 -0400 Received: by zmamail05.zma.compaq.com (Postfix, from userid 12345) id 96BB15B73; Mon, 25 Sep 2000 11:12:16 -0400 (EDT) Received: from exctay-gh02.tay.cpqcorp.net (exctay-gh02.tay.cpqcorp.net [16.103.129.52]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 7D7BF5B08; Mon, 25 Sep 2000 11:12:16 -0400 (EDT) Received: by exctay-gh02.tay.cpqcorp.net with Internet Mail Service (5.5.2650.21) id ; Mon, 25 Sep 2000 11:12:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Mon, 25 Sep 2000 11:11:40 -0400 Reply-To: "Powell, Ken" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Powell, Ken" Subject: Re: [MOBILE-IP] Mobile IPv6 questions X-To: "Charles E. Perkins" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Hello Ken, > > Following up on your next contribution to the discussion: > > > I had a few additional thoughts on my previous questions. > > >> should the conditions for sending a router advertisement to > >> a mobile node include some sort of unconditional periodic > >> retransmission? My concern is the home agent could define > >> a prefix with a fixed lifetime that the mobile node will treat > >> as decrementing in realtime. The prefix on the mobile node > >> could expire without any updates from the home agent. The > >> retransmission could occur on an hourly or even daily basis, > >> depending on the Preferred and Valid Lifetimes of the prefixes. > > > Rather than having the home agent periodically retransmit > > the router advertisement, would it be better to say the > > mobile node SHOULD send a router solicit to the home agent > > when any of it's home addresses' preferred or valid lifetimes > > approach expiration? > > I think it would always be better for the home agent to > send the advertisement without solicitation. Otherwise, > we could easily get into the situation where we are > periodically sending both solicitations AND advertisements. > That would be twice as bad as periodically sending only > advertisements. It will be even better for the mobile node > to typically have prefixes with much longer lifetimes, and > then to rely on relatively shorter intervals between Binding > Updates. This should be a matter of administrative policy, > about which we need to get more deployment experience. > > The mobile node should, of course, send a solicitation if it > starts to get nervous about impending address deprecation. Yes, this sounds good to me. Any idea what the default interval should be for the periodic advertisements? According to RFC 2461, the default MaxRtrAdvInterval is 10 minutes. Is this too frequent for mobile purposes? > > > The Binding Request/Update sequence described in section 9.7 > > is used as an acking mechanism to ensure the mobile node > > receives an unsolicited router advertisement. For solicited > > router advertisements, RFC 2461 section 6.3.7 says > > the mobile node may transmit the router solicitation up to > > MAX_RTR_SOLICITATIONS (3) times, each separated by at least > > RTR_SOLICITATION_INTERVAL (4) seconds. If no response occurs, > > the mobile node could perform home agent address discovery > > again. > > > >> If not, then should the home > >> agent send a router advertisement with all known home subnet > >> prefixes to the mobile node with the first Binding > >> Acknowledgement? This will account for prefixes the home > >> agent knows which the mobile node doesn't. > >> > >> => this is a nice idea. > > > > I noticed this was not added to the latest revision of the > > Mobile IPv6 spec. It would probably be cleaner to have the > > mobile node send a router solicitation with the first binding > > update it sends to a new home agent instead. This would > > would achieve the same result by triggering the home agent to > > send a router advertisement with all known prefixes. > > I don't see any reason not to add this feature. > Contributing text is always appreciated. OK, I'll see what I can put together. > > >> > However, I think this I-D should be able to cover how > >> > to initialize its state on the home agent and the mobile node > >> > from a limited amount of information that is relatively easy > >> > to configure. For example, start with the assumption that the > >> > mobile node can always get the Home Agent's Anycast Address. > >> > > >> > => I agree this is useful but I think this is out of the > >> > scope of the I-D. > > > > I think a few restrictions on the process may be > > useful. Perhaps something like: > > > > The method for initializing a mobile node's > > home addresses on power-up or after an extended > > period of being disconnected from the network > > is beyond the scope of this specification. > > Whatever procedure is used, it SHOULD result > > in the mobile node having the same stateless or > > statefull (DHCPv6) home address autoconfiguration > > information it would have if it were attached to > > the home network. Due to the possibility that the > > home network could be renumbered while the mobile > > node is disconnected, the mobile node SHOULD NOT > > rely on storing these addresses locally. > > This does not take into account the possibility for the > mobile to use a statically allocated home address, but > I generally agree with it except that I think that the > mobile node SHOULD be able to try to use locally stored > addresses, at least up to some pretty long time like > a month or so. I'm still not sure what a statically allocated address is in IPv6. Anyhow, sounds good to me to try locally stored addresses first then fall back to some other technique if the locally stored address fails. The locally stored address being the last known home address. I'm not sure its a good idea to put a time constraint on this other than the home addresses last known lifetime. It is possible for a network administrator to renumber the home subnet in as little as 2 hours without IPsec, and immediately with IPsec. This wouldn't be a smooth renumbering, but it could happen. > > >> I tried to understand how a Mobile IPv6 node would > >> initialize its addresses on power-up using stateless > >> address autoconfiguration when away from home. The > >> steps I came up with were: > >> > >> > >> > >> What information can I expect the mobile node have to > >> break this deadlock? Is my reading of how this should > >> work way off? > > > Would it be reasonable for a mobile node to > > generate a temporary home address for itself using: > > > > o the subnet prefix from the home network's mobile > > agent anycast address, and > > > > o the globally unique interface identifier that > > would have been used to generate the link local > > address if the mobile node were attached directly > > to the home network. > > > Such a temporary address could be used to establish > > a binding with a home agent in the absence of any > > other known home addresses. It could be created with > > short valid lifetime and a preferred lifetime of zero > > to ensure a quick transition to other addresses > > generated when stateless or statefull (DHCPv6) > > address autoconfiguration runs. > > As I said in the last note, which included this same > text, this seems like a generally good idea for the > case when the mobile node really cannot remember a good > home address. It should not be used in preference to > a statically allocated home address. Agreed, except request "last known home address" instead of "statically allocated home address". > > > If this were allowed, I can see how a mobile node > > could initialize by: > > > > 1) Query DNS for the home network's mobile agent > > anycast address. > > > > 2) Generate a temporary home address as defined above. > > > > 3) Send a Home Agent Address Discovery Request message > > to the home network. > > > > 4) Receive Home Agent Address Discovery Reply message. > > > > 5) Send a binding update option with a router solicit > > to a home agent using the temporary home address. > > > > 6) Receive a binding acknowledgement option with a > > router advertisement from the home agent. This router > > advertisement could indicate to use stateless and/or > > statefull address autoconfiguration. If statefull, > > start the DHCPv6 procedures. > > > > 7) Autoconfigure home addresses according to the prefix > > information options received. > > > > 8) Send binding update option(s) to establish bindings > > for the new home addresses (if needed). > > Should this be made into an appendix in the draft? I'll leave that up to you. I just wanted to be sure I understood the protocol. Ken From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Sep 25 11: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 SMTP id LAA05582 for ; Mon, 25 Sep 2000 11:24:18 -0400 (EDT) Received: from standards (47.234.32.16:2418) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9777E@standards.nortelnetworks.com>; Mon, 25 Sep 2000 11:07:53 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 28346 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 25 Sep 2000 11:07:53 -0400 Received: from tml-gw.tml.hut.fi (tml.hut.fi) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB97739@standards.nortelnetworks.com>; Mon, 25 Sep 2000 10:57:53 -0400 Received: (from smap@localhost) by tml-gw.tml.hut.fi (8.8.7/8.8.7) id SAA09397 for ; Mon, 25 Sep 2000 18:11:52 +0300 Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0) id xma009395; Mon, 25 Sep 00 18:11:42 +0300 Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7]) by mail.tml.hut.fi (8.11.0/8.11.0) with ESMTP id e8PFBgM15712 for ; Mon, 25 Sep 2000 18:11:42 +0300 (EEST) Received: from localhost (lyang@localhost) by morphine.tml.hut.fi (8.9.2/8.7.1) with ESMTP id SAA14421 for ; Mon, 25 Sep 2000 18:11:36 +0300 (EET DST) X-Authentication-Warning: morphine.tml.hut.fi: lyang owned process doing -bs MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Mon, 25 Sep 2000 18:11:36 +0300 Reply-To: Linfeng Yang Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Linfeng Yang Subject: Re: [MOBILE-IP] Implementation question about MIPv6 and IPSec To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: > Both "The Case of IPv6" and RFC 2460 suggest, as I understood, there will > be only one DO (Destination Header) if there is no routing header. This > only DO will appear just before upper layer header or another IPv6 header > if encapsulation is employed. Sorry, DO stands for Destination Option. Another correction, if Home Address DO is included, there will be more than one DO, but it will appear even after other DO as MIPv6 recommended. So there is one point not explicitly stated in MIPv6, but it should be assumed, all these DOs (BU, BA, BR and HA) are intended to the final hop. So they should appear after Routing Header if there is. As a result, these DOs all appears after Authentication Header, and be protected. Regards, Linfeng Yang Helsinki University of Technology Telecommunications Software and Multimedia Laboratory P.O.Box 9700, 02015 HUT, Finland Phone: +358 9 451 5250 Fax: +358 9 451 5351 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Sep 25 17:22: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 SMTP id RAA14626 for ; Mon, 25 Sep 2000 17:22:54 -0400 (EDT) Received: from standards (47.234.32.16:2099) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB97B21@standards.nortelnetworks.com>; Mon, 25 Sep 2000 17:06:46 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29507 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 25 Sep 2000 17:06:45 -0400 Received: from ftpbox.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB97AC8@standards.nortelnetworks.com>; Mon, 25 Sep 2000 16:56:45 -0400 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id OAA22395 for ; Mon, 25 Sep 2000 14:10:45 -0700 (MST)] Received: [from il35exm01.cig.mot.com (IL35EXM01.cig.mot.com [160.19.16.101]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id OAA19250 for ; Mon, 25 Sep 2000 14:10:45 -0700 (MST)] Received: by IL35EXM01.cig.mot.com with Internet Mail Service (5.5.2650.21) id ; Mon, 25 Sep 2000 16:10:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: Date: Mon, 25 Sep 2000 16:10:42 -0500 Reply-To: Roberts Philip-qa3445 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Roberts Philip-qa3445 Subject: [MOBILE-IP] ipv4 fast handoff outcome To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi folks, The IPv4 fast handoff design team has finished its work. The output of the work is two drafts, Calhoun, et. al., and Soliman, et. al. The latest versions of these drafts will be submitted as personal drafts in the next couple of days. We had hoped that a single draft could be produced by the design team but this did not happen. The task now is for the working group to examine these drafts and choose one it wants to use as the working group draft for fast handoff for IPv4. Based on experience with the discussions in the design team I want to suggest some criteria for discussing these going forward. First, the drafts attempt to be access technology independent and we would like the discussions not to adopt some specific access technology as an underpinning for the draft. Second, on the other hand, we must keep in mind that the technique must work across specific underlying technologies. So we must walk a fine line between two possible errors: depending too much on a particular technology across which the handoff proposal will work and ignoring requirements of systems across which the handoff proposal will work. So expect to see in the next day or two references to the new drafts as they are submitted to the IETF and a discussion of the differences between the two proposals. The chairs would like to thank the participants of the v4 design team and in particular Pat Calhoun for leading the design team. Phil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Sep 25 17:35: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 SMTP id RAA14992 for ; Mon, 25 Sep 2000 17:35:22 -0400 (EDT) Received: from standards (47.234.32.16:2099) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB97B7E@standards.nortelnetworks.com>; Mon, 25 Sep 2000 17:19:07 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29648 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 25 Sep 2000 17:19:07 -0400 Received: from thalia.eecs.wsu.edu (199.237.73.100:45652) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB97B37@standards.nortelnetworks.com>; Mon, 25 Sep 2000 17:08:53 -0400 Received: from carmel.eecs.wsu.edu (IDENT:root@carmel.eecs.wsu.edu [199.237.72.81]) by thalia.eecs.wsu.edu with ESMTP (8.9.3/) id OAA05008 for ; Mon, 25 Sep 2000 14:22:35 -0700 (PDT) Received: (from dawn@localhost) by carmel.eecs.wsu.edu (8.9.3/) id OAA05454 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 25 Sep 2000 14:22:35 -0700 X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID: <200009252122.OAA05454@carmel.eecs.wsu.edu> Date: Sat, 25 Sep 0100 14:22:35 -0700 Reply-To: "DAWN Research Lab - Dr. Sivalingam" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "DAWN Research Lab - Dr. Sivalingam" Subject: [MOBILE-IP] CFP: ACM MobiCom 2001 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Enclosed below please find a Preliminary Announcement and Call for Papers for the 7th Annual International Conference on Mobile Computing and Networking (MobiCom) to be held in Rome, Italy from July 16-21, 2001. As you might already know, MobiCom has an established reputation as the pre-eminent conference in this area owing to the exceptionally high quality of papers, excellent tutorials and workshops, and stimulating panels conducted by mobile computing illuminati of various stripes. For complete information about the upcoming conference, please visit: http://www.research.ibm.com/mobicom2001/ We apologize if you received multiple copies of this Call for Papers. Please feel free to distribute it to those who might be interested. Very truly yours, ACM SIGMOBILE MobiCom 2001 Organizing Committee *********************************************************************** Preliminary Announcement and Call for Papers *** ACM MobiCom 2001 *** The Seventh Annual International Conference on Mobile Computing and Networking July 16-21, Rome, Italy Sponsored by ACM SIGMOBILE http://www.research.ibm.com/mobicom2001/ http://www.acm.org/sigmobile/ Submission Deadline: January 12, 2001 *********************************************************************** PAPERS: Technical papers describing original, previously unpublished, completed research, not currently under review by another conference or journal, are solicited on the following topics: * Applications and computing services supporting mobile users * Architectures, protocols, and algorithms to cope with mobility, limited bandwidth, or intermittent connectivity * Database and data management issues in mobile computing * Performance of mobile/wireless networks and systems * Security and privacy of mobile/wireless systems * Interaction between different layers of mobile/wireless systems * Integration and interworking of wired and wireless networks * Adaptive applications and systems for mobile environments * Distributed-system aspects of mobile systems * Operating system support for mobility * Location-dependent applications * Wireless multimedia systems * Power management * Mobile agents * Pervasive computing * Wireless sensor networks * Wireless/mobile service management and delivery All papers will be refereed by the program committee. Accepted papers will be published in the conference proceedings. Papers of particular merit will be proposed for publication in the ACM/Baltzer Wireless Networks (WINET) and Mobile Networks and Applications (MONET) journals. CHALLENGES SESSION, PANELS, RESEARCH DEMOS, TUTORIALS: Submissions are also solicited for the Challenges session, panels, tutorials, and research demos. Please refer to the conference website for more details. IMPORTANT DATES: * Technical Paper Submissions due: January 12, 2001 - Please refer to the website for submission instructions * Notification of acceptance: May 1, 2001 * Camera-ready version due: May 15, 2001 * Challenges Session Papers, Panel Proposals, Tutorial Proposals Submissions due: January 12, 2001 - Please refer to the website for submission instructions FOR MORE INFORMATION: Send email to mobicom2001@winlab.rutgers.edu with any questions or comments about the conference or for more information. ORGANIZING COMMITTEE: * General Chair: * Tutorials Co-Chairs: Christopher Rose Ravi Jain Rutgers University, WINLAB Telcordia Technologies * General Vice Chair: Chiara Petrioli Politecnico di Milano Sergio Palazzo Universita` di Catania * Panels Chair: * Program Co-Chairs: Ramesh Rao Univ. of California, San Diego Mahmoud Naghshineh IBM T.J. Watson Research Center * Local Arrangement Chair: Michele Zorzi Marco Listanti Universita` di Ferrara Universita` di Roma "La Sapienza" * Finance Chair: * Sponsorships/Exhibits Chair: David B. Johnson Marco Ajmone Marsan Rice University Politecnico di Torino * Publicity Co-Chairs: * Steering Committee Chair: Stefano Basagni Imrich Chlamtac Univ. of Texas at Dallas Univ. of Texas at Dallas Krishna Sivalingam * ACM Program Director: Washington State University Lisette Burgos (ACM) *********************************************************************** From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Sep 25 18:31: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 SMTP id SAA16300 for ; Mon, 25 Sep 2000 18:31:01 -0400 (EDT) Received: from standards (47.234.32.16:1300) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB97C44@standards.nortelnetworks.com>; Mon, 25 Sep 2000 18:15:03 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29989 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 25 Sep 2000 18:15:03 -0400 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB97C43@standards.nortelnetworks.com>; Mon, 25 Sep 2000 18:15:03 -0400 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA26457; Mon, 25 Sep 2000 15:29:00 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.84.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id PAA18148; Mon, 25 Sep 2000 15:28:55 -0700 (PDT) Received: from lillen (lillen.Eng.Sun.COM [129.146.86.161]) by jurassic.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with SMTP id e8PMSse933623; Mon, 25 Sep 2000 15:28:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Mon, 25 Sep 2000 15:28:52 -0700 Reply-To: Erik Nordmark Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Erik Nordmark Subject: Re: [MOBILE-IP] Implementation question about MIPv6 and IPSec X-To: Stefan Schmid To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" > I completely agree with you. In our implementation for Microsoft, we have > done it the way you described it above (BU and BA in 2nd destionation > options header) for exactly the same reasons - mainly because we argue it is > conceptually the cleanest way (at least according to the current specs.) ... Even in that case you need to carry some extra information between the different extension header processing code. In particular, while the AH processing can find the SADB entry using the destination and the SPI (which doesn't require looking at the home address option) the tail end of the AH processing might very well include a check that the source address of the packet is consistent with the SADB entry. Since the SADB entry is based on the home address of the sender, this check can't be done until the home address option has been processed. (Whether your AH does a "peek ahead" to find the home address option or you defer this part of AH processing until the destination options have been processed is an implementation choice.) If you look at the actual dependencies between the pieces of processing you'll see that all possible orderings (including placing a destination options header just before the AH header that some folks are proposing) you need to carry some information around in all the cases. It would be useful to actually look at the different cases in detail to see if there are significant differences in implementation complexity. The cases I can think of are - Home Agent option in destination options header before AH. Binding Update option in destopt after AH. - Both before AH - is there a difference in the ordering of the options within the destopt header? - Both after AH - does the option order matter here? Erik From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Sep 25 20:01: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 SMTP id UAA17853 for ; Mon, 25 Sep 2000 20:01:42 -0400 (EDT) Received: from standards (47.234.32.16:2008) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB97CE4@standards.nortelnetworks.com>; Mon, 25 Sep 2000 19:45:48 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30192 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 25 Sep 2000 19:45:48 -0400 Received: from mail.haps.tp.edu.tw (163.21.155.3:1608) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB97CE1@standards.nortelnetworks.com>; Mon, 25 Sep 2000 19:35:47 -0400 Received: from teacher ([163.21.155.253]) by mail.haps.tp.edu.tw (Netscape Messaging Server 3.6) with SMTP id 426 for ; Tue, 26 Sep 2000 07:44:19 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01C0278E.3349FCA0" 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: <001e01c0274b$2540ad40$c80145c0@haps.tp.edu.tw> Date: Tue, 26 Sep 2000 07:48:46 +0800 Reply-To: Jeff Chen Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Jeff Chen Subject: [MOBILE-IP] To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C0278E.3349FCA0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_001B_01C0278E.3349FCA0 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
 
------=_NextPart_000_001B_01C0278E.3349FCA0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Sep 26 00:31: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 SMTP id AAA23538 for ; Tue, 26 Sep 2000 00:31:55 -0400 (EDT) Received: from standards (47.234.32.16:3206) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB97DE8@standards.nortelnetworks.com>; Tue, 26 Sep 2000 0:14:10 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30527 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 26 Sep 2000 00:14:10 -0400 Received: from imsp074.netvigator.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB97DE4@standards.nortelnetworks.com>; Tue, 26 Sep 2000 0:04:04 -0400 Received: from frankie (bbig002178.netvigator.com [208.151.89.178]) by imsp074.netvigator.com (8.9.3+Sun/8.9.1) with SMTP id MAA17392; Tue, 26 Sep 2000 12:10:19 +0800 (HKT) X-Priority: 3 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=XX52BF529F-00B052BFXX Content-Transfer-Encoding: 7bit Message-ID: <200009260410.MAA17392@imsp074.netvigator.com> Date: Tue, 26 Sep 2000 12:10:19 +0800 Reply-To: heavenyheaveny@hotmail.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Janiusli Subject: [MOBILE-IP] china factory & new product To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a Multipart MIME message. --XX52BF529F-00B052BFXX Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Heaveny Group Company Limited 260900 Dear Sirs, How are you! Hope everything are getting well on your side! To be one of our valuable customer, we are glad to announce that our company is continuously developing many new and popular models of mobile phone accessories. As you know, our product ranges include: 1. Ni-mh Battery Packs ----90 models Usd 1.3- Usd 3.5 2. Li-ion Battery Packs,----30 models Usd 5.00- Usd 8.00 3. Portable Handsfree Kits,----60 models Usd .48- Usd 1.50 4. Travel Chargers, ----50models Usd 2.1- Usd 2.3 5. Plug in Saver/Car Chargers----50 models Us 0.55- Usd 0.70 6. Antennas ----20 models Usd .150- Usd .40 7. Housing ----200 models Usd 0.45- Usd 2.00 8. Keypads -30 models Usd 0.1- usd 0.2 9. Leather Cases----6 models Usd 0.13- Usd 0.80 We are especially strong for produce batteries, car charger& Handsfre. In particular, we produce OEM/ODM accessories based on your specifications in order to satisfy the different demand of our customers. New Products: A. car handset B. 4 pcs 3a backup battery charger C. 2 sim card battery (usd 8.00-13.00) If you would like to order some models of mobile phone accessories you are welcome to send us your request, once we have receipt of you request, we would quote you our best price very soon. You are welcome to visit our web site http://www.heaveny.com for more update information. Thanks for your kind attention. We look forward to hearing from you and serving you again soon. *** email : Please reply to: janiusli@heaveny.com *** Fax l : Please reply to: 852 24981565 Best regards, Janius Li Heaveny Group Company Limited Room 504-5, Technology Plaza 29-35 Sha Tsui Road Tsuen Wan, Hong Kong Tel: 852-24981617 Fax: 852-24981565 Email: janiusli@heaveny.com URL: http://www.heaveny.com --XX52BF529F-00B052BFXX Content-Type: application/octet-stream Content-Disposition: attachment; filename="2 sim card battery.jpg" Content-Length: 43414 Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgEASABIAAD/7RGiUGhvdG9zaG9wIDMuMAA4QklNA+0AAAAAABAASAAA AAEAAgBIAAAAAQACOEJJTQQNAAAAAAAEAAAAeDhCSU0D8wAAAAAACAAAAAAAAAAAOEJJTQQK AAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgABAGxmZgAG AAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0AAAAG AAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///// ////////////////////////A+gAADhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklN BBQAAAAAAAQAAAAIOEJJTQQMAAAAABASAAAAAQAAAF8AAABwAAABIAAAfgAAAA/2ABgAAf/Y /+AAEEpGSUYAAQIBAEgASAAA//4AJkZpbGUgd3JpdHRlbiBieSBBZG9iZSBQaG90b3Nob3Co IDUuMP/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgR DAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIAHAA XwMBIgACEQEDEQH/3QAEAAb/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEF AQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFR YRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXy s4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgEC BAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPEl BhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG 1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/APVUzXNdO0gwYMa6qj19rn9C6ixupdi3gAeJ revNrOs/WTIx6rsP6vMx6ra6wxxya22n02+k24hv2e5u5v77f3ElPq7nNaJcQ0cSdEznNaJc Q0eJMLxLqPTvrLcyzJzOg3u2gOfbv9WA33bvcbforuuoW5Lfqf8AV8Y1VdlxqoIrucWsAGM4 PLn1h7vZuSKntAQRIMg8EKItqL/TD2l/7sif81eT24vWXuc/9Rr3fSYz1iP85zVf+qzc6v6y dPGTVitr3WAPxy/dJpu0LLW/Rd+9vQtT6YqnUerdM6XWLeo5VWIx0hhteGbiORWHe5/P5iLl ZePiUm7IdsrEyYJ4Bf8Amz+a1eZ/XnrGJn9Zw76XOdRTiOIlrmu32WhhHp2Brm+2hIyF1Yvt 1VRe6q+t/wBWLbBUzqeOHHQb3hgPwdZtb3Wlk5mLiV+rlWtprmA55Ak87W/vOXitmRU5hY8O AtHeCIJLPdDnLt35lZ6Z0G10u9Pp7hoZJs249Tv7W2nIStVPSD60dB3bXZjK/wCVYHVt/wC3 LWsYtP1K/T9XcPTjdvkbdsTu3fury1/1gxrbW1/Z7RvO2Zaef3xK7HEcyz6hu3H9GMC1k/yG Msrb/wBBqQKn/9D0nrNRv6PnUjmzHtYP7THNXkfScp1XTcO31X1tZRv2VwDt9S5oY10b27nU u/8AJr2Z7Q9paeHAg/NeA9OudV0jHMtDXsILYnd+kvZ792793+p/IQKg9R1jDy3/AFctzfRs ZjWY3reoPogGHt9/uat7qodi/U36ul+hrqx6nfH7K/8A9Jrjn9ZzLPq1dhtyHGgYj6nU7iWD YDurDfo+3aux+vLhR9SOmu49OzFA+dbq/wDvyhwVUwL+bW+7Lmv0k18uldnC+2gxqtD6uWts +sfT2/y7HD5UXrim9RMjVdL9RMn1/rRhNJ+iy93/AENv/flKGN9OzsDFz6fQymepVM7Q5zdf 7BavPes/V2hmXiVdRD67LGPFLayCHCubbBPu+i33r0tcj9eK2nqHRLdZY/KAjwONY4/+e1W5 zDxQllEpQnjhPhMDw8Wm02XBOpCBAlGchfFrX9147O6J0+nBysljntdiucws0M/zQa+f+v8A v/4t61t1mPh/VYlv0sS50OEiQzv/ANvKlnNL+l5rq6i8tD7DYY/RhwpY57p/f/TVsWt16tlP TPquW6enjuYNOQ6ird/1Kk5ck4cZO5hG1uUATkB+8WvZmPe73AEE8Qt/ABZ/i6cXD/vOvdHk 5lr2/wDRK43IyNrHOB1a0kfIL0D7MP8AmZ9l7fs30/8AwDYpQxv/0fU3uaxjnuMNaCSfIL5x 6M2u0elk5D6amt3MI4Bknbpu+luX0eQCIOoPIXK5n1D/AMX1DC7LwaMdsl2422Vcnxbcz2pH 7FF8pyDiY2JfVj2m2p9VhL36He5rhth39hegf4xr67P8X2BbWZba/EdX2mWb2z/ZW1jf4v8A 6iur3UdNotrd+fvfYPHR7rXrdyumdOzMP7BlY1V2IAGjHexpYA0QzYyNrPT/AMHt+gmxgI3W tmzaTIkAGvSKFf28T84i/IH5kx4TAXV/4sL3n654rbYG6m8MAPfbu1/stXcZX1M/xY4rnDJZ j40k7mOzbax5+z7S1bPQOgfVLppNvQ8fGFgEG6t3q2AH837Q91trWu/rp1BDuLiP8aL7acPp N9LnMtZmw11ZLXAmm/6Lme/81duquf03B6lU2nOpbfWx4sYHTLXtna9jmw5rvckp8Vzs7NdR a+29z3vYQYvFjyIMB+yx7/pLtPrY7Z0f6uzoBV/6IYulf9UPqxcPRfhseGCCze8wHe6Ht9T8 /wDlrTvwMHJobjZGPVdQ2NtNjGuYNujNtbwWe1ClPjGXl1mmwB7SdrhEjwXsnof5L+zf8B6f /Q2Ku36s/Vtjw9nSsJr2kFrhj1AgjUEH01ppAKf/0ut/xhdb6n0bobLelubXk33Cv1XQdjG1 3Zdzmh4c3f6WM6v6C8tZhdftc/OqIb9oDiy02bLLWOe7dtcWnczdX+k/4td//jetNXQsNw4O U5v+fjZdf/f1xeHk5renY4c5jmeiRS3aQW1eo/d6zmxvc7I/m3IE6KadOZ9YegvGXRkV4t9w G0iyS8udu99cenZssu9Szf8Ao/8ASL0rr/V+oZv1M6fl47hRk9UZjmxrOCbWh76GucfZU+x2 1/u/mV5j1vIsH2Oywhz67HPa0Ajg1m3fv/ltYu/6ifR+of1bcdAGYZ++pr0r0U8/di/Ww6PG C4AEBrjuGojd9H6bI3sUMaz6yYWdi5V9lNPpXV7rajJhzm17Ht9u6q3d6dq0H9SY/Sfmq2Ve H0gT/haY/wC3akLU+uLzr/G51Lq2L+zaenZVuK2wXPv9Gx1ZdDsdlX80Wvdtc9y9FXm3+NWx 46h09rI3fZryJnUF+OLOP5CcVPBV3fWXFstyq8u3Gus1tyG2WMsfuM/psj2Pt3u/0tj13WR1 jPyf8U+DkZd9l9+Xc3HutLoscxuTazabB/wVDWO/0n+EXH22ZD2WNsFe01Fp27wRWfdZ9L2e ptc7/txdBaY/xP8ASHdhmSf/AGIyk0HRTUxKc2xrRXn5FVWxzPSlphjy19tbXbfbXc+tjrWL tPq43Kb9Xur4tuRZd+je+p7yJYH1Or2s9u3buq9T6C4Hp/U2VtAJXc/VrMZb0brVoMtrx9T8 K73JDcJf/9PZ/wAcoP8AzWx3j/B5tbjHnXkV/wDf1yl3THYHRG5Lr8ctqordZtsD3gvLHBjq a/0307tntXoH+Mbo+V1j6p5ePhsNuTUWX1VNEuf6Z3WMY0e51no+p6bG/wA4/wDRryjq2d6m DdVNjS30BYXMIkCN3u/kPb71X5jiMsQF1xXKv8FlxUIzJq60tqdYtxLMSl2PY61zGzkbgfY9 0yxp27fT/Rt/tr0b60bsb/Fx0IuEOqZhNPkRRC8zwcHq3W7a+ndOFmY69w9RrWkMY4E1tsut azb6LGP3717P9degX531Qd0/DDrLcQVPqYxsueKYDmtZPuc6vd7FPWjE+TM6i4nU/BXcTMdd kY9EybMjHbHxupXNm4VPcxztrmkhzSCCCOdzXHc1dL9ROj5fXet0GoO+y4dtd+TeG+0CtwuZ Vv3bfUtdVtQpT7mvNv8AGrXW7q/RvW3Cq2nLYSyN3sFNvtn+yvSFzn196TidR+r91l1e7Iw4 txbAdrmPJFb/AH/uWVu2WMf+jSn8kta0Oq6Fccb2sPkt2PUw2ei3JtodVpYdRuI92/a/3Vtb /q9dTnY7q/8AEvhafzbq7j8H5D3T/wCCq10H/Fb0TqVIzOq2ZJyK7XV2UMtr9Iis7Q3fVW9/ 9f0shd1n9B6Zn9Ff0K6rbgOqbS2thgsbXt9D03a+6l1dbq/6iGP5I2b0Cslccq2t+e2ZDm8F eifUaxz/AKkfWW4niq5oP9XHcf8AvytH/Et03edvU8gM/dLGF0f1/b/1C6vp31R6V036v5HQ MT1G42Wy1l9xcDa51zPQsu3bfT9T09uz9H6f8hOpa//U7nqP10+rnTM93TszKLcqtodaxlVt mzcN7BY6iuxrXvZ7tizrfr59TBYLCLHvB3B7cS6Z8dxpC84+v8j609Ya0kE31Rt0OtNKxctv sBbkVPMcUh7SIb+duLf/ADtNJ6Jp9h/8cz6tDRjMt3wxnj/qtqif8Z3Qe2NnH/rAH/VWNXk1 rv0Vh4Owwfkhmfs7ZsqJBGjd3qdvpfyf7SHEVU+pX/4yfqo+zdb0zMts4LjjVuP+c61SZ/jV +r9bQ2vp3UWsHAbjsAH/AIMvMccn0mSZIEE/AlTLkuJVPp7f8a3QCwvdh59bWzO+lgOmv0fX 3Imd1/C+t/1T6uzotd19jKxWanVlrnOMPDawfpu9q8wx7W13VWuG5tdldjm6e4Me2xzPeHs9 7W7PezYvQvqz9YKh0j6wdWxcYVnCpFraXemA51dVtrd/2SrHZ7vo/Q9RLiJkBWh6qIFHV0f8 XPTszp3SMrHysazEnKc+qu0bSWGukb9v9dr11i8tb/jQ65XFl1/R7GMh1lLBlMscB7n01veL a2XbfZv/AElbLF6knRoCh0QBSkkkkVP/1ee/xgGPrb1c+F9Wo/4mlc8ba9jg0RyDBcf+qc5e j/XD/F39YOqfWDMzsFtN2LmFlg32GtzXMYyp1bhsd/o/YsbJ/wAXH12uAFuLXcGCGxkVjgbP 3WfmhNpLzdjv0T/6p/IgCysCI93J+lx8J2/9FdK7/F79doId0vcHCDtyKOD/AFrWoj/qP9er MdmNZ0211FcbGfaMYxED/T/yGIUVOX0bHblZFFDhuY/cSCSNBuf+Z71t29H6c2yG07R4F9n8 bECj6l/XjFc11HSbGur0a71sYkD+1c5qsWfVv/GJZ9Pp1jp/4XEHH9V6hyY8kpXGXCK7kL4S iBqLefa1znEMBcd21rRqSSdjGtH0nOc5df8AVujIx/qd9bPtFVlLjjuAba1zDHoWa7bA395Z dP1N+ulbxYOkP9Rr2WMBux9u6twuZv8A07fa57fcu9+pvT+tnF6g36ydPqxjlOawUBzLWWV7 Cx/qNbbktdu3bHb1KBLiGmnUrdK8Xy3Mqyq+i4+TbZhfZrRiMDKnD7S0VG70nXM/Nd+lt+1/ 9YXvqyh9VfquDI6Pgyef1ar/ANJrVToxq0E2pJJJOQ//2ThCSU0EBgAAAAAABwADAAAAAQEA /+IMWElDQ19QUk9GSUxFAAEBAAAMSExpbm8CEAAAbW50clJHQiBYWVogB84AAgAJAAYAMQAA YWNzcE1TRlQAAAAASUVDIHNSR0IAAAAAAAAAAAAAAAAAAPbWAAEAAAAA0y1IUCAgAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARY3BydAAAAVAAAAAz ZGVzYwAAAYQAAABsd3RwdAAAAfAAAAAUYmtwdAAAAgQAAAAUclhZWgAAAhgAAAAUZ1hZWgAA AiwAAAAUYlhZWgAAAkAAAAAUZG1uZAAAAlQAAABwZG1kZAAAAsQAAACIdnVlZAAAA0wAAACG dmlldwAAA9QAAAAkbHVtaQAAA/gAAAAUbWVhcwAABAwAAAAkdGVjaAAABDAAAAAMclRSQwAA BDwAAAgMZ1RSQwAABDwAAAgMYlRSQwAABDwAAAgMdGV4dAAAAABDb3B5cmlnaHQgKGMpIDE5 OTggSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkAAGRlc2MAAAAAAAAAEnNSR0IgSUVDNjE5NjYt Mi4xAAAAAAAAAAAAAAASc1JHQiBJRUM2MTk2Ni0yLjEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFhZWiAAAAAAAADzUQABAAAAARbMWFlaIAAA AAAAAAAAAAAAAAAAAABYWVogAAAAAAAAb6IAADj1AAADkFhZWiAAAAAAAABimQAAt4UAABja WFlaIAAAAAAAACSgAAAPhAAAts9kZXNjAAAAAAAAABZJRUMgaHR0cDovL3d3dy5pZWMuY2gA AAAAAAAAAAAAABZJRUMgaHR0cDovL3d3dy5pZWMuY2gAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZGVzYwAAAAAAAAAuSUVDIDYxOTY2LTIuMSBEZWZh dWx0IFJHQiBjb2xvdXIgc3BhY2UgLSBzUkdCAAAAAAAAAAAAAAAuSUVDIDYxOTY2LTIuMSBE ZWZhdWx0IFJHQiBjb2xvdXIgc3BhY2UgLSBzUkdCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGRl c2MAAAAAAAAALFJlZmVyZW5jZSBWaWV3aW5nIENvbmRpdGlvbiBpbiBJRUM2MTk2Ni0yLjEA AAAAAAAAAAAAACxSZWZlcmVuY2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4x AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB2aWV3AAAAAAATpP4AFF8uABDPFAAD7cwABBML AANcngAAAAFYWVogAAAAAABMCVYAUAAAAFcf521lYXMAAAAAAAAAAQAAAAAAAAAAAAAAAAAA AAAAAAKPAAAAAnNpZyAAAAAAQ1JUIGN1cnYAAAAAAAAEAAAAAAUACgAPABQAGQAeACMAKAAt ADIANwA7AEAARQBKAE8AVABZAF4AYwBoAG0AcgB3AHwAgQCGAIsAkACVAJoAnwCkAKkArgCy ALcAvADBAMYAywDQANUA2wDgAOUA6wDwAPYA+wEBAQcBDQETARkBHwElASsBMgE4AT4BRQFM AVIBWQFgAWcBbgF1AXwBgwGLAZIBmgGhAakBsQG5AcEByQHRAdkB4QHpAfIB+gIDAgwCFAId AiYCLwI4AkECSwJUAl0CZwJxAnoChAKOApgCogKsArYCwQLLAtUC4ALrAvUDAAMLAxYDIQMt AzgDQwNPA1oDZgNyA34DigOWA6IDrgO6A8cD0wPgA+wD+QQGBBMEIAQtBDsESARVBGMEcQR+ BIwEmgSoBLYExATTBOEE8AT+BQ0FHAUrBToFSQVYBWcFdwWGBZYFpgW1BcUF1QXlBfYGBgYW BicGNwZIBlkGagZ7BowGnQavBsAG0QbjBvUHBwcZBysHPQdPB2EHdAeGB5kHrAe/B9IH5Qf4 CAsIHwgyCEYIWghuCIIIlgiqCL4I0gjnCPsJEAklCToJTwlkCXkJjwmkCboJzwnlCfsKEQon Cj0KVApqCoEKmAquCsUK3ArzCwsLIgs5C1ELaQuAC5gLsAvIC+EL+QwSDCoMQwxcDHUMjgyn DMAM2QzzDQ0NJg1ADVoNdA2ODakNww3eDfgOEw4uDkkOZA5/DpsOtg7SDu4PCQ8lD0EPXg96 D5YPsw/PD+wQCRAmEEMQYRB+EJsQuRDXEPURExExEU8RbRGMEaoRyRHoEgcSJhJFEmQShBKj EsMS4xMDEyMTQxNjE4MTpBPFE+UUBhQnFEkUahSLFK0UzhTwFRIVNBVWFXgVmxW9FeAWAxYm FkkWbBaPFrIW1hb6Fx0XQRdlF4kXrhfSF/cYGxhAGGUYihivGNUY+hkgGUUZaxmRGbcZ3RoE GioaURp3Gp4axRrsGxQbOxtjG4obshvaHAIcKhxSHHscoxzMHPUdHh1HHXAdmR3DHeweFh5A HmoelB6+HukfEx8+H2kflB+/H+ogFSBBIGwgmCDEIPAhHCFIIXUhoSHOIfsiJyJVIoIiryLd IwojOCNmI5QjwiPwJB8kTSR8JKsk2iUJJTglaCWXJccl9yYnJlcmhya3JugnGCdJJ3onqyfc KA0oPyhxKKIo1CkGKTgpaymdKdAqAio1KmgqmyrPKwIrNitpK50r0SwFLDksbiyiLNctDC1B LXYtqy3hLhYuTC6CLrcu7i8kL1ovkS/HL/4wNTBsMKQw2zESMUoxgjG6MfIyKjJjMpsy1DMN M0YzfzO4M/E0KzRlNJ402DUTNU01hzXCNf02NzZyNq426TckN2A3nDfXOBQ4UDiMOMg5BTlC OX85vDn5OjY6dDqyOu87LTtrO6o76DwnPGU8pDzjPSI9YT2hPeA+ID5gPqA+4D8hP2E/oj/i QCNAZECmQOdBKUFqQaxB7kIwQnJCtUL3QzpDfUPARANER0SKRM5FEkVVRZpF3kYiRmdGq0bw RzVHe0fASAVIS0iRSNdJHUljSalJ8Eo3Sn1KxEsMS1NLmkviTCpMcky6TQJNSk2TTdxOJU5u TrdPAE9JT5NP3VAnUHFQu1EGUVBRm1HmUjFSfFLHUxNTX1OqU/ZUQlSPVNtVKFV1VcJWD1Zc VqlW91dEV5JX4FgvWH1Yy1kaWWlZuFoHWlZaplr1W0VblVvlXDVchlzWXSddeF3JXhpebF69 Xw9fYV+zYAVgV2CqYPxhT2GiYfViSWKcYvBjQ2OXY+tkQGSUZOllPWWSZedmPWaSZuhnPWeT Z+loP2iWaOxpQ2maafFqSGqfavdrT2una/9sV2yvbQhtYG25bhJua27Ebx5veG/RcCtwhnDg cTpxlXHwcktypnMBc11zuHQUdHB0zHUodYV14XY+dpt2+HdWd7N4EXhueMx5KnmJeed6Rnql ewR7Y3vCfCF8gXzhfUF9oX4BfmJ+wn8jf4R/5YBHgKiBCoFrgc2CMIKSgvSDV4O6hB2EgITj hUeFq4YOhnKG14c7h5+IBIhpiM6JM4mZif6KZIrKizCLlov8jGOMyo0xjZiN/45mjs6PNo+e kAaQbpDWkT+RqJIRknqS45NNk7aUIJSKlPSVX5XJljSWn5cKl3WX4JhMmLiZJJmQmfyaaJrV m0Kbr5wcnImc951kndKeQJ6unx2fi5/6oGmg2KFHobaiJqKWowajdqPmpFakx6U4pammGqaL pv2nbqfgqFKoxKk3qamqHKqPqwKrdavprFys0K1ErbiuLa6hrxavi7AAsHWw6rFgsdayS7LC szizrrQltJy1E7WKtgG2ebbwt2i34LhZuNG5SrnCuju6tbsuu6e8IbybvRW9j74KvoS+/796 v/XAcMDswWfB48JfwtvDWMPUxFHEzsVLxcjGRsbDx0HHv8g9yLzJOsm5yjjKt8s2y7bMNcy1 zTXNtc42zrbPN8+40DnQutE80b7SP9LB00TTxtRJ1MvVTtXR1lXW2Ndc1+DYZNjo2WzZ8dp2 2vvbgNwF3IrdEN2W3hzeot8p36/gNuC94UThzOJT4tvjY+Pr5HPk/OWE5g3mlucf56noMui8 6Ubp0Opb6uXrcOv77IbtEe2c7ijutO9A78zwWPDl8XLx//KM8xnzp/Q09ML1UPXe9m32+/eK +Bn4qPk4+cf6V/rn+3f8B/yY/Sn9uv5L/tz/bf////4AJkZpbGUgd3JpdHRlbiBieSBBZG9i ZSBQaG90b3Nob3CoIDUuMP/uAA5BZG9iZQBkAAAAAAH/2wCEAAoHBwcIBwoICAoPCggKDxIN CgoNEhQQEBIQEBQRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBCwwMFRMV IhgYIhQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM DAwMDP/AABEIAakBZwMBEQACEQEDEQH/3QAEAC3/xAGiAAAABwEBAQEBAAAAAAAAAAAEBQMC BgEABwgJCgsBAAICAwEBAQEBAAAAAAAAAAEAAgMEBQYHCAkKCxAAAgEDAwIEAgYHAwQCBgJz AQIDEQQABSESMUFRBhNhInGBFDKRoQcVsUIjwVLR4TMWYvAkcoLxJUM0U5KismNzwjVEJ5Oj szYXVGR0w9LiCCaDCQoYGYSURUaktFbTVSga8uPzxNTk9GV1hZWltcXV5fVmdoaWprbG1ub2 N0dXZ3eHl6e3x9fn9zhIWGh4iJiouMjY6PgpOUlZaXmJmam5ydnp+So6SlpqeoqaqrrK2ur6 EQACAgECAwUFBAUGBAgDA20BAAIRAwQhEjFBBVETYSIGcYGRMqGx8BTB0eEjQhVSYnLxMyQ0 Q4IWklMlomOywgdz0jXiRIMXVJMICQoYGSY2RRonZHRVN/Kjs8MoKdPj84SUpLTE1OT0ZXWF laW1xdXl9UZWZnaGlqa2xtbm9kdXZ3eHl6e3x9fn9zhIWGh4iJiouMjY6Pg5SVlpeYmZqbnJ 2en5KjpKWmp6ipqqusra6vr/2gAMAwEAAhEDEQA/AOzYq7FXYq7FXYq7FXYq7FXYq7FXYq7F XYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXY q7FXYq7FXYq//9Ds2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2 KuxV2KuxV2KtYq7FXYq7FXYq3irWKuxV2Kt4q7FXYq7FWsVdireKuxV2Kv8A/9Hs2KuxV2Ku xV2KuxV2KuxV2KuxV2KuxV2KuxVrBauxtW8KuxV2KuxV2KuxV2KuxV2KuxV2KtYq7BarHdE+ 21K9MbVRlvrSH++uESviwxtViappkh+C7hYj/LXG1RCyo/2WDfI42qpjauwq7FXYLVa7BVqT xHicbVCvqenIaPdwj5yLjatpqenP9i5ib/VcHG1RKsGFQQV9sbVdjat4VdirsVf/0uzYq7FW sVSXXPNOkaE1ul/Kyy3J4wxoObnFUDrHnvRdHlt4r3mjXK84vhLVAbg32OeKpiPMmjcqPP6T f5akYqjYNR0+cVhuYpK/yupxVEc068h9+Koa41GwtEL3NzFCg6s7qMVSm489+VoBX68svtEG f/iIxVJP+Vs+W/rr23CVgvRlX4/+Abj/AMTxVPNE85aHrd29nZysLuNBK0Mq8CUP7SfzfaxV kGKpfq2qQ6VZ/WplZ15oiovUl24riqW/4ti7WzcfHmuQVaPO+koQt2ktsW7stV/4NcVR0Pmf QZv7u9jOTVEfpnSaV+tx0/1sVQ83mXQ4f7y9jH3nFUsm8/6GrcLYSXT/AOQu3/BNiqifP8Pa yb/kYv8AzTiqaaB5ittbFwscbQy2zKroxrs4+FlbFU8xV2KuxV2KtYq7FXlvnP8AMvVbDVzp uioh9H++d1575BWG32s+atWuGubq+eI8aKkTlFH+rxxVu2bU7O3mjhu2f6zVpufxmh+H7TYq p2S3tlYzWdnNwiuPimVlrU8eOKrrR9ZsEVbDUJYVX9nmxH/Atiqe6Z58802EqfXJUvLRPt8x xNMVeuaZqEOoWMN5Duky8tsmqK7VxVguqeZdU1C9ntdKl+q2ls3B7im5P+TkFSiXS5bhma6v bi5b9pnfbFUO2h6cv+6Vb6d8VUH0PTv988f8quKrIrG4tm52V7cWzj+R22xZptpHnPWdPuYY 9VlW80+Vghn40kj5HitcVp6arBgGXcHofbJsF2Kt4q//0+zYq7FWsFq8o/M1EfzfoIP7TcW+ QZW/42xtWcXMMRtlJRX4pRWcdj+zkFY9bNbC9lFzxHL4lZumSCoTUIrb6zLNbqvpcR8SigL/ ALTLkqVJ7h14svxHGlSW+skn5er8cXH408cmqChskVHiT4EH2VXFUM8Ppty4/F/NhKsj8gMq +dbd+jNbpx+lfRbKir3DCrE/PpP1fT4+z3ILf7EYqkP7OV2qlKjMjL8Lf624xtUmuLaJGZ5t NZ/+LbZq/wDCr6UmFUP/ALie9veD/J/e/wDNeKr4obR/ig0pz/xbcmg/5KtI3/CYqjkR1Tfi n+SnTFVhWn2sUp3+X7lNeu4/2ZLdWp8mxV6Rk0OxV2KuxVrFVOZ+ELv/ACgnAVfOLTNPrmpX HL7dw/4McilMEX4sVVW5d/tL8OKrMVbZfgX/AIbAqjLvyX9nFXq35Z3Bm8rQI32oWdPuyaGT X0ohsriT9lI2P4Yq848vIzac8p/3dK7ZBKYOq4qoMuKqLpiqHdWxVLNWhZrSWn2lXl92KvV9 En+s6NYz/wA8Kf8AEeOGKExyRVvCr//U7NirsVayCXkv5l3cVv5y0WaZuMUKO7t7D4sUKup/ m9o8kXp29rKyj9puIrgVitz+YqO/OGyX/ZNkgqGm/MK9kRl+qxIrf5THJWqEbzjen/dKH/gs bV3+LLvjvaof+Cw2rv8AE9V4/VFT+bjtjaoeXW7eVvjiI45MqyTyPcQv5y08wtUNCit8+fxL lRV7vhVhH5kXL20NjcInq+i7yMg+SrirzSbz1e/Zht1H+tvkeFUFL5x1x/scUX/JGPCqi2v6 9K3L1mwKt/TOvf7/AHxV36e1xf8AdrYq7/EmsD7TV/1sVVV82X3L44lOKWc/lnfTXuuNcvF6 aPEyA9iR8WKvWsmh2KuxV2KtYqg9XlWHTbqQ/sxP+rAVfOOjN6sszn4mdmfl898ilOk+1/lY qqsrFuR+1iq3hiq9uSpxP2cCoeXFXof5Tyk6dfQV+xcM1P8AWyaGUeZ5vR0DUJOnGFvxxVhm grw0a1HivL72yCUU8qD9r/Y4qhXu4R1bFUO19b/zfhiqxpoXX4XXFVG5TnDKrfyn/iOKs68j S+r5X08k1KIUP0NhihkOSKuwq//V7NirsVawFXif5yQ3MuuQvDEzrDDydlBNAeP2v+ByKsI0 vyt5h1d+FhZNK3HlyYqgoP8AKk45JU0f8t/N6Lylt0RR9r41PT/U5Yqo/wCANeVqOyK3+y/5 pw0rm8i6sFZjMi8V5t9rpjSrJvJWsRsw9VCy7MvJqgnCypQl8p6+nI+kz/Ey8vdPt5AqhLnR NcgZUmtHH8u3+yyQ5MWQflxFcp5qsZnicQlwiuw2+0v7X+xyoE2tW+issKsD/MWs1xp1mSyx TCUy8DxJA4fDkVYzFoOkx7/V1P8AlPyOBKKSysovsW8Q/wBguKr+CD7Kqv8AscULW4/yr92K qbIh/ZX/AIHFVB7a3f7cSN/rBcVQkuk6ZLy526f7Faf8RwpTbyEPqnmhLWHktvLDI/AtWhA/ ZxV6vk0N4qtJIByKErl1y2Tlw+JkHJxgM6Tux2X8xCspRNPd17HkMr8cMTGSheecJdR0nUIZ bJrYfV3Kuzr1pgjnBKgSDyPy8qrbs77fs5dTNFS3s3N1X4F5cVxpVqyyu27tiU2qvDdpbpO6 ypBJ9iVl2rkCFtYtxMv7bf7LCgKsNyztwkxZPQfysl4XGpQsw5FlZV7/AOVhixZN59fh5U1B vFAv/DZMqxFbn6vbaZYj7csXNvkFyCpZrCy8q82C/sqv0YqkMvMt9t1/yuWNKpXCNFxpMxr+ 0pxpVkVxch1/evx5DriVpkMMzJdpCzckmUqvLx45ArT0H8vD/wA62ifyTSL/AMNk4qWUHJli 3il//9bs2KuxVrAVePfmlqj2OtTRLEr+vZheTMwp+z8PH/XyKrfLeovc3F1Z3G0NpbzPDx2o U+BPs/6+SVEy3s32ebcX+1u3fl/1UxVFWrq68Hlb1WXmycmBQcv+bsNqiXu4tOhb6vcfX3Vi zW/JOFS3PjK38/x42qv/AIht5uKyWSPy4ovJVqOa+pmL+YcgY7bXzNEu/wBVRF/veKqp6/u/ 8nIHUNo09pNrfmrT7aVIpYlVnR0VuCio+xx5f7P48uw5rcfJGmK+Qb6aXzJp9g6qkcE4p1rU Py/42y+w1AvoLAVYH+YDcdW0k/5E3648iqTNL8OBK2v+VirTNih3L4cVWcvhxVbyxVSf/hcK Ub5Np/jS39rabFXquTQ3iqlMaRSf6p/VgKLYBql7NDaPxXi03FOXy+L/AI2zW55052GmOwt8 VWX/AFs1okacnhFrriJXsphyXi60+Lj3+eS0pJkw1AoMKsl9C3ulX4VR2VfozfcTrVsTuWV/ GjY8Sq6yv/L+zxyIm2cLvWuGX0pX5RD7CdhkwV4VuLWFr/C3Mf5OLJnH5b/F5qlf9r0Wp/wO GLFm35iNTyrdf5bRr97ZMqwWKX1vM9vCv2YbNVX2r8WQVMbvTEuW/eK3+xxVL5vLcP8AO/8A wuNqh28twjbm/H/Y42qz9A26NUciwxLJSvlaOa1f7PGVf+acgVekfl4f9wMvgLman/C5OLEs pOTLFvFL/9fs2KuxVrFXif5zqV1yI/z2n/G//NuKpdp0rrfXscS8mlt3VfiUdGS4b7f+THkE oubVJfib6jKqj9nmp6cuX7P/ABW+KrF1OUGq2kvL7P2lxVHW7p9UXjxRvVmZkV9+fLi3wev/ AJP/ACy4qilZkWJ2X4SyN9y8c0ztIHZSZ/g/2BX/AIblikSY55umijeFnt1nq0ir8TCnwxt8 PDMrShxdQofljzk84WfKpPPk3LNkC4j6MwFDAvzF+HUNHb9mkw/5N5FWO88CXeriq5nrv9nF VvPFXK64q0zYqpM2Kpj5KFfOUXtazH/hlyQV6rkkOxVSmj5xug25ilcVYtd+TriZWUXtV6qr L3+/MTLittjkpj+paK+nTLBI4kPGtR75pdVjEC7HT+oIR4nSJ0Xkf2vhLDK9JlEZLqcXEGDv ZXKRX37p/id2Xbxzf/mYOCMJX2mn3LwxViIagVtsx554MxiKKTTJuXxKyrlYyxUxLn09fhUr RmzKBaTJCtYvmSGAUbuF44WJX7NMSyZp+Wlf8SKf+Kjy/wCAOMUSZr+Y+/lWb/jJH/xLJlgG A6MyHzi5P7MIX7kXK0steaHjiqDe4T7OKqLTRYqpNLEcVSrW1RoYW/a9UYqzv8uP+OA58bmX /jXDFDLMkVdhV//Q7NirsVaxV47+dkf+n2T8ft2zry/1W5f8bYqknlx1bWHd7T66ptFZoac/ 7xIk9Tj/AJHPBSVaVUjXheX0sNxIz8omhXY8mVlX9z/lfz40qMt2li48+N36rKzPxVOA/wBV VjyKqcus6e7tpoZuKuV4K1E9Q/FJ8PL/AI0xVNUp9Ri47LxXiv8Ass1NO0jHZD8f+Nf+JPjT WUn1uV44oWRVLMfst1+wvxL/AKn28ydMGrUIf8p09Tzfb/D9n1X/AOFbM23EfQWSKGA/maKP o8n/ABbMn/BKv/NORViqy/D8OBLvVxVv1f8AgsVa9XFXK/hirbPiqzn8WKp15AXn5tlf+SxP 4yrkgr1DJIbxVbgUNE4VIYf5nWup/JBnMdpmp/j+g7XRn0pT6VV/ys1G9uaEEqLyYfzZcJli aRSJCisXTouCUiwJCncxQ+i7ovxBeXFum2XYuK2GQhR0l7S8SX6zaRc1+FW+L/mrOlxHZ1mQ Ks2j2zvwgt0NEHNUR3NSzfZVT/k5lhqDD9fuLKVbiGyRWWBB6qsrAiQPxb7WJZMl/K9G/T0r t+zD+sYxRJmX5i/8ordH+R42/wCHyZYB5rpL/wDOwyv+1w/40XK0sgZ8VUnZcVUuWKrWZlxV A6szcIf9dWxV6J+XS08tIf55pW/4bDFDKckVdhV//9Hs2KuxV2KvLPzphZotMdV5MwnTpX/f bYqxHyXLL+nrXhzLvZj+6fhJsnBuDf8APL7GC0oi39W2195jqT2z3CS3KvZp60kZd+Kwsn8/ DG1VWu3SZmZnn5t8UswpM9f92On+/H/3YmRSEnilR71ULpyilkZUZmNCZf8Adf75vjf/AIwY snommaDfXWh2U8KK6Swo/LkuYfgOT46yXy3qiHe3LUP7PE9G/wCb8icC+Ox7zNaXen2kTzo0 LO6qq8FJeitz4v8A7r9PjzfL4Q3RIqH5N2z/AOIPUK0VLaR1NN/ibhmR1cSQe5YShgv5pof0 fps38lzx/wCDRv8AmnIqwT1cCV3q4q2suKu9XFXK+Kr+fL4cVWM+Ksm/LYc9f1GU/sW0aV+b 8v8AjXJBXpuSQ7FWsVdiqBudMtLp+U0VW8cx8umjNmMpCFPl3TfBh9OY38mwbBq5B5fq9zf2 c3mACYI+lek1snUFHZuXKmRl2fANv5gkpnp0r3WkW9+ftTpUr7/Euc/mxcOSnYQnYRDor28v w/FxP/GuCB3ZTSzyq/8ApNw32vgVVVv9bOk0x2dXlTu2ld7lw6q7cU/Zc/tN/wAs4eXM1xw8 1u+UV3qqurIru3FaMP2/+LAsmLJnv5XWrx6nK8qEGa29WJ69UDLH/wAbYxYFl/nuP1PK194K odvkDkyoeVaJvrDv4o3/ABHK1ZA7YqpNiqxmxVYzcsVQGrN8Cfyhi2KvU/I8Po+WLAfzpz+8 5YhkGKuxV//S7NirsVdirzf8514aJYXP++rkr/waN/zRiryvyzqz2d39ZWJJvTi4Mj9KF2dn /wCeeQSnFvbywa5cX8E00drcs7xS2HESAGX4YmSf0v2F+x/zzxVFyy8rlm5O7L+3Lx9Q/wCX J/xZ/vzFISpHvY7njwb0eTq/JtkQv6v7r96395xT/dWLJ6z5W8y6db+WNPikZucduqstO+V+ Inw01fzFpko+BzyJpxO21V+L/hcgci+GxH8zbmGfSbcwXB5JKW+DvVZfhdsnCW7PhpJvyU5S 6tqEjf7rtkRfkXX/AJpy/q1kvZsBa2G/mglfLaSftR3MLffyT/jbIq8v9XAld6vhirfq4q71 uWKqiy4qvWX/AK6xVtnxVmX5WJW81mXw+rp/wrtkgr0XJIbxV2KuxVaciQFccJS8T89CWz1n XoOI43kKOpHtlUubMVaP8sSs/lix5N8PBl/4bOY1e2f8fzHaY+SLe4/cuB/Kf+I5RAbt00r8 u29z9XuJlRpPi4q0XDb/AILOk042dXlVL27vYm4R28qLJEeTRPSTZv8AivM1xwx3WUlCN8Fx Gr8GZrlquTyHxYsmffldE0kl3claJDEluv382/4jjFhJmPmaL1vL+oxUryt3ovyXJlQ8a0Nv 9yCH+dW/4jlasgZsVU+WKqbNiqnz+LFUv1h6xKv7RU/jxxV7Ro0C22k2dv04Qp/xHLEI/FW8 Vf/T7NirsVdirz3850B8oI38l3F+KyLiryXyakMuovFMivE8MysrtTorN8LYClGLqMsa/um4 f5KxuR/svi/4hkVVEu3lXlB6PFPhZV5DFmpXE2oMy1WJV/yWbFU+sbl0063Q8Vb0viUdM1ct i5wGyK+t/Fx/yv8AjfBIoEUt1y4V9P5FqcXT6f7xcycJ3YZhsnH5Hj/TNWf/ACIx95zO6uBW z2LClif5lpXyhdn+R4W/5KpirxtpeXHIJXrLiq71uQ+1irllXFV6TYqvWZcVVfWU4GTPvyo+ JNZf/l4jX7kyQYl6HkkOxV2KuxVrFXHFXkX5pQ8NeRxt69sVb6Mrk2RKzyslPK1sOtOXxV/y 85fW/wB9f4+h22BExRcl3+z+1/wLZTHm2nkg9AiZnuIYXWNU5OzeP7OdHpeTqsnNNLZ09Zvi 5twX7bMgNWP7SLJ/xDMwNDCdYuJbi5uBI6P9XdVRU3CDlXjyovLEq9O/K2IDRppKfE77/jjF gy3UEEtjcx/zxP8A8RyZV4VpfwXsP/A/8LkEsgZsVU+WKqbNiqnyxVBzJ62oWkP88sK/8G+K vdEQIioOigDJoX4q3ir/AP/U7NirsVdirBPzhVW8mvy6C5h/4lirxHy3bw3d81vNNLDEVdml h+3srOmBLIEt5odRWzle4ltTEZYvqkSSSIgbj8aNx+xkVULjg9w1OXFacea8HP8ArR4ptK3u Lj6wpMqspZvg+EUAb4ePxYrbI9PlVtLt3P2vSK/8M2avNtJ2ET6UQztyb/Wb/ia5Te7ZDkl+ tqz6Y3wsWR0ZVHiGk+1mTgO7Tm5Mr/I1Ar61xrQegvxbH/dubMOB0eu4UMa/MUV8m6n7Ijfd LHirwpZcgl3q4q71cVXLLiq9Zfh/4jiq9Zvh44qqrL+zgZPS/wApN7TVm8bkf8RyQYl6HkkO xV2KuxVrFXHFXmX5oiJNTsXdOdbeVVWtPi/ZyE0xSzywxj8oW7Ovxc3X4e3xcs5nXD95+P6L t8BRMMyhmq1PtKv6v+NsxjzbxyQeiO0U11NGvP43RlpuPizpNHydVn5omG+ls7h5PSfmkXNV idY3NP8ALkSTMsNDEblWW7unmt3tvrLGZGldXJq6fyKuJV69+XnD/DyiNeC+q+MWDJZ/955f 9Rv1ZMq8MhVUvoeP7Xxf8LkEpmzYqsZ8VWM2KqTNiremJ63mGyU9poW+5sVe35NDeKuxV//V 7NirsVdirB/zdH/OlXB/kmgb/h8VeKeTZXTXEYQrMzLL+6flT7Dfy/yZEpTJHsk1tpLOa7uU eJ/W+pu3ro/Lk3D4F/cR/BkVQ92zPeuxeUuG+Jpf7wn/AIs/4s/35k1Q6zRBGBl+Pi/CJkqA TLyZYnZ2/wBd/gixVEaNfO3O1koUSImHxFPtf8TzBzQcvEU4L/E3+s3/ABNMwzFyTyQurMp0 +XmrMo4/CrU/bb7WXYR6mvL9LLvyLX4dbb4uJaCnLf8A39m1deHruKGNfmFv5M1b/jDX7nTF Xz4suQSu9XFV3q4q7niq/wBXFV6S4qqrLxZcDJ6p+UJ5WOq/8xI/4jkggvRckxdirsVdirWK uxV5n+a6/wClaaf8hxlfJKU6A6w+UIY5FZWaV+PLuM0Gu3m7LTzpZ6sS/ab7J5ZURZcgFfZX CR80eLhBLKnHirBJX+zzWT/ivN3oxQdfnFo3T9DhbRpZrtVluLWV0Z25V+22ZLQxzX0RLhFT deD8uPjyjb/iOSDEvUPy8H/Otof+LH/hkmLJJ/7iX/Ub9WKvCIv97oj/ACtkEpizYqsZsVWM +KrGfFUT5cX1PM9kOv74fguKva8mh2KuxV//1uzYq7FXYqwr82x/zot8fB4T/wAlUxV4JoN6 1nfNd8nT4HVXQV3dWX/jbIlKP+vK7rNI/wC9RAiOjcCAPsp+74ZFVjzVdmZl5P8Aa3r/AMSy aeMLZntyq/FyYV4Ly2BP2uPxYrxhbpzKLtPi6q6/8JlObk24Tun5f7X0/wDMvNbe7noTV3b9 HTAfzDl8vVy/D9TRlPpZz+RB5W2st/l24/4WXNoXXh63kUsa/ML/AJQrWP8AmH/42XFXzpz+ HIJXc8VXc8VdzxVer4q2r4qqrK2Bbet/k23LT9V/5iR/xHJBD0jJK7FXYq7FWsVdirzX821o dMf/ACnH4ZE1SGLeVfNktrZehcxevbx1CIvGoP8AssoyYoSLfCdJ5L5x090X09PdG/a5FOnH E4YMhkklmo6/NdTK0FukNrxKtE4Vzv8Aa4/62TiBFqkSV1v5qmgsbiw+qq/rOzo7SNQVbky5 JKS6nq0NzCqNarHcM5+NXqCCq/8AVHJBiXrX5ef8ozD7u/8ADJMWSS/3L/6p/VirwheIvU/y WP8AxHIJRfLFVrNiqxmxVSZsVTLyavPzbZD+WVm+6LFXtOTQ7FXYq//X7NirsVdirDfzYWvk LU/b0T/yWjxV83BmA25Bv8nFBjSK06Fbm7Ecrsi0dmalTsvL9rFE5UE2XSbR+LItxKrfZZY0 3/4liZxDV40j0XpolsV+G0uXr+18I/5l5Ezijikeiuuki24TLYyxUryld12r8P8ALlOTJYcr DIohn+19P/GmYcYWXYjdD6pxfTLofyqrL/yO/wCbsvwsMnJn35Df7waz/wAZof8AiMmZjrhz etY2ljnn5C/k3WEH2jbtT78bV81eqyNQ5FW/rC4qu+sJim131hP5sVtv6zEP2slStfW0xpVv 11uXFFxQ9s/JgN+idQL/AGnmR/vU4q9Kwq7FXYq7FWsVccVed/m2n+haa6tQiZx/wuBXlOlt SJ6/F+9OKphyReP/AAuQS71mLfFirTS/zZMqhbs0aLj/ADf8anIq9v8Ay/H/ADrNv/lM5yaG SP8A3bfI4q8Eb/e3/Zv+GQSimP7OKqbMuKqbNiqnz5YqnnkBOfm2Ej9hZT/wirir2TJodirs Vf/Q7NirsVdirCvzYuYYfI+oJM1PX9OKL3fmr/8AMvFXzykzBFRkV1H2eS74otEWjxC5TjFR m5Ls3iuKJsz0Zm/R6fEzcWf7IX+bMHPtJtwG4oz1mSx9UfbVW4t32bKSd3JjLZS1FnOnTclf t3X+bDAqAAx3k3+f+qmWwbBN01xLDbXEsezcCvLjX7b8f2sniCy5M7/Im8hWLVrLf1uUc1P8 gco8zHXy5vX8rSxn8wpRH5P1Vj3h4D5u6pih80OrFq+OSpVnBsaV3FsaRbvixpbW8XyVMl3p PjSr1hbIoe2fklP/AKDqNs321aNx/q/GuKvUcKt4q7FXYq1irjirz383qfojT35caXP6xgV5 Fp7Uil+Ljxc4qiudGwUldzbl9rGlbaVT/wA1LhKoa5avBV/mP4ZFXuv5finlSx8SpyaGSP8A Yb5HFXgj7Xre00q5BKqzYqpMyt7YqsZ144qpcsVZT+WacvMrn+S3c/8ADIuKvXMmhvFXYq// 0ezYq7FXYq8y/PRmHlqxp0N4vL/kXJirwxePHFirwsqzIf8AKGKJhOIry8i/dwyukX2lVelc HAHGhOS03F2w4NK/H+WrUx4As5ycLm4+GszbNy4sWI/2WPAEjLJe99N/v1eX83wj9rl/xtjw BtGaSBvdQZomh5s6mnLw2wshKTNvyN5jzPep+z9TYn/kbFi3Al7vkEMW/MgE+StUpvREP3Sx 4ofNy5NV3LFXIjyOqJ9psWBJVjp7rx58gxbivzxazMrJoZYGpJ/xr/xri2wkt5Ytko27lixe u/khv+kz+yFjX/hpMVet4q7FXYq7FXYq0cVYD+b6cvLCfu+bCdOLfy5EpeR6XFY/vVvbtbRF +NeaMS/+rQZFUwivol/45+mCRV+Jbq75OSB+0sP7GG1RU2p6sEUNb2e6luP1fw/2WNql7Xyv veWKov2Xlttih/4xNjaFBobQ3FpMtwtzC8vxouzgf5eNq918hJw8p6cKcV4EqPbk2TVkDbqf cYq8KvoZba+mSZeLRXEiv7V/ayCUJLcqn2fi/wApemKoR71+VV48W+zgVSbUG/aVcVXpco7f F8P+TiAhnv5V27tql3c8TwSHhy93bl/xrkqV6lklbxV2Kv8A/9Ls2KuxV2KsZ87+Vl80aG+m iX0bhHE1tKRUCRK/b/yH5Yq8d/5U/wCeGuGh+rwhB/u71k4H/mZ/yTxV0v5QeeYxVbaGT/Um T/jbhiiaBm/LvzzEaNpMz/6jK/8AxF8KeFSH5fedj/0prn/hV/42xXhRUX5Zeen6aS6f60sS /wDMzFdkdB+Tvneb7cVtbD/LmDf8m1lxWwrTfkp5uj4NFPaTEmjBZHHH/K+OPAnieh/l9+X7 eVPrF1dXAudQugEcxgiNEB5cE5fE/wAWKLLOcFKh7u0t722ltbpBJbzIUliPQqcaV5brP5IR HnJomoGM7lLe5XkP9X1k+L/hMKsKvvyx872TH/ccZ0H7du6yf8L9v/hMVSSbQNftmpNplzE3 +VC//NOKSQpLZat9hbG4b/ni9f8AiOLUYhXh8s+Zrni0Gj3j1+yy270/4jizqk2tPy089XdO OlvCD3mdI/8AiT8sWVsp0n8kNQk+PWNQS2H++bYeof8AZSScFxQ9Q8t+WNM8t6f9S09W4s3O WVzV5H/mdsVTrFXYq7FXYq7FWsVSrzDolvrulTadP8KyD4H7q4+y+RKXnUXkfzVZXO+nadqq ooSKe422X7PKPIquu/K/m2/u4rmfTLe1EPHhFbN8G3+S2GlRD+XfMn1JbRbPlwma4WUhaklu Xpv/AMV40qVjy35kt7qX/nX1vIX/AGHlZEH/AAGNIU08ia1f3CRR6NFpMXPlLNzZ/wDiWNK9 c0uxj03TrexjNUt0CKcmqMxVj+t+TtI1mX151aK46NLEaEj/ACsFJSR/yq0Rz8V3cHtSoxpU Ofyd0PteXI9qjBStH8mtCb7V7cn6RjSqqflFoyH/AHtuSv8AL8P9MQhmGkaNY6PaLaWMfpxD r4k+LZJUfireKuxV/9Ps2KuxV2KtYq7FXYq7FXYq7FXYq7FXYq3irsVaxV2KuxV2KuxV2Kux VvFXYq7FXYq7FXYq1irsVap474q3irsVdirsVdirsVdirsVbxV2KtYq7FW8VdirsVf/U7Nir sVdirsVdirsVdirsVdirsVdirsVdirsVdirsVaxV1cVcMVbxV2KuxV2KuxV2KuxV2KuxVrFX Yq7FXYq7FW8VdirsVdirsVdirsVdirsVdirsVdir/9Xs2KuxVrFXVxVJdR82aDp5ZJ7tDKvW JDyP/NOBWO3f5r6NbShPRlaP9qYfEB/sY1fFUuvPNF9qenXGsW9y8NvAZCkcMjx8o1VXT9j7 eKoOz82arBYRa6LiWS1cgm2mlaSqB/Tl+Hiv7Cviqd6f+bGiXTFXt5lX4iroefT9lq+l8WFW T6f5n0bUFHoXCh2FeD/CcVTYGvyxVdirsVaOKoe7vbaziM1zKscQ/aOC1Y7d+cOW1nDRP9+y /wDNGNqlVx5j1qRqLc+mB/Iij/iWKsZm87+Yba4SS/t5b+zicqyxOqc6/Y5cRiqX6Z51197y eS1gmhKbhHk5KK1/399vFWVxea/MCIpe5qdufwId/uxVMbTz3cI3C9tw47vDs/8AwDZFWVab q1jqcPrWcvNf2l6Ov+umKo/Jq3irsVdirsVdirWKuxVC399bWFrLdXL8Io1Lt47b/DgtWG/8 rZ0MygRWly8Rp+94qP8AhK42rLdJ1ix1izS9sn5wvWldmFNviXG1R+Nq7CrsVdiqVy+Y9Chl aGTUIVlX7S812yJVUt9c0i7lEVveRSSn7KK2+G1XX2r6Xp7Il9dx2zPugkYLWmNqrNd2yW31 p5VW348/WJovE9+WNqh/09o3/LbF/wAFjaom3u7e5XlBKki+KGuNqr4q3hV//9bs2KtHpiqD 1HUrLS7OS9vZRDbxCrOf+FX/ACmxV5vL+ZOnamt79b9aG0CUs7ePYyE/7tmlX/k3irzt7uKX q/FVY/DgVSW7X6w/ovRXHBuXv+1iq/8AxPrNvaPbQtE1q7Hnzj5g1/Yf/gcVd/iHWX09rR1i SyVeLKkSoBVq9sVUob27+o/U4mf6oztLwRV6v/lYVTLR9TbS7hLj++4K3OFzQEFSv/B4qyvQ fPGoaZbPcvdfWrSN1R7J/t/H+1C/2k4/8isVepaPq9jrFjFf2EvqW8g+kH9pH/ldcVTDFULq F9BYWc13OaRQrzb3xV5DqPme41a8+s3L/AG/cxfsxj9n/Z5BVZdUi/mxVptUhX+XJKh9L1NH 1G4s1b4z8cP+WOOKu1W9SzFJW+OVuKK3X/KxVb+lIW4/Ev8AL92KrX1CHi3x5FUND5iudKvk vbB6SpTknaQf76kxV7NoesW2s6Zb6hbf3cybqequPtxt/q5NUyxVvFXYq7FXYq8c/Mn8w9Xt tcOg6XL9Tt4CoubhP7xifidV/kRVxVgOp6/eyajM9pqdx9XL/uuMz9PvxVD/AKW1CaVFur2a a1V+KNM7ugP0/tZBV66vwDq0L+qG+EDcH+XFUWNcvrZWmsL17duA9ZYXpSv7LYqvXzfr8bf8 di45BeS/vajFWW+RfzV1ZtWg0vW3+uW10wiiuaKskbn+fj/eR5NXtWKsL/MvVbyy0L6tZy+h Ndtwe46cIx9vj/lvkbV4taKlsrAsr1/ayJKo6HWVsebonxujIro1Ch/ZblhVUTzDY39pDbao 7SPbJ6SPL8Z/1uT4q6XzJFbaM2mw3Et41y/71WduCQjh6USK3/GPFUSmuQ8V/c8f8mq/0xVM LHzTcjU7KewZYJYG4yozbTJ+1E2QBV7dDKs0SSj7LqGH05aFVcKv/9fs2KtHpirxb84tfkm1 aHRon/0ezVZZlB6ySfZr/wAY0wKwCxmt3u0juGZIXcLKydaYqpXLolzKIXZ4eR9Jm6lOXw4q s9X4uTN/tYqvTUJYrd7ZXrbyssrRMKiqfDjarHvXeL0l4xRFuTIv/GzY2rluZVTgrsq/PFVv rN/NT/KxVXluFhlaJJVnRP2kb4PoxVmv5UeYnsPMX6MLlrLUhRd9lm48kb/hfTxV7t3xKsR8 /wAsjafDZp/u5+T/ACT/AJuyKvI9Rt2t2b4uOG1Sp7247N/ssbVRa7uD+1jarHuJuavyZXT4 kdTQj/ZY2q2W7uZJfUkd5Zf53LH/AIlhVct3MMVVVu5j9rIqibKF7l6Yq9g/LMPb2t3Zv9kM siD/AFh8WMVZ1kireFXYq7FXYq+a/PssU3mPVa/33rfD40GBWJsnxYq0zuImj5N6TNy4dq/z Y2q1ZXC8Q7KuNquReew+z+1jatsijG1TryqiJr2n81+M3Ccfkcir6lyQV5d+c9xxi0q3/nlL uP8AJXAVYNFLpjL8UWRVFLb6dIv9z9rFKFfy9pkjcgjriqIttB0+HpCx/wBbFUeunWS/8enL FVs2lwtbTS29v6bwqZef+p8WRZPZ9Ek9TSLJ/wCaCM/8KMsiwR+SV//Q7NirR6Yq+f8Azzp4 vPPmpQmZEKBZmR+VXRF5Oi8R/vtcCpBe2mn2vme+s2t2e0guZkSJWYGiMyxrzY/zYqirHQ4t RiupxwtliuH4xPzd3QLyWKP0g2KphZeVbGaW3PpK9pu1w03OOSn7PpfEuKoq+8saY0qixtYl hC/tmUvXl/xkyKoJ/KsP7MMX3y/9VcVXv5V082ifulS45M8z+o4QIMkqX3ejaJDbuwlX6xt6 SpcK6PVgPg+HnyxVKblNKfUIYbFZkiLIkvrFa15cZfTxVO/K1qlr5001VlVovWZ4VVt+CMzR 8v8AW4Yq+kMSrEvNrK13bg/sQu+RV5pbWS6veu1wzcFZuKrgVNm8o6OOqYqsfyto69ExVSby tpP2REMVWN5Y0n7Ppfjk1WN5W0v+Tj/ssVUn8s6d+yrZFUDfaWmnqtzbOwYN8SYq9M8gzLP+ /GzS268/mjUxirN8kVbwq7FXYq1ir538w2UV/wCbtWeZvsIz8vf1eGBWKrEjyskas7L+zSuK oq3tLea3eZoucSfbZe2RVYbbRPi+JwvzxVERWdi8LPBEzxR/bdm8cVUpbaGaFiiceP2m8P8A WxV3lVWPmfTE5f8AHwi/8Nir6oyQV5F+dLctR0xPCJ2/4bAVYFbq2RVN7Ra4pTGL9nFUWir9 rFVdE/ycVRDJysb1T3tpf+IHIsnoflg8vL2mn/l3j/4jlsWKbYUP/9Hs2KtYq8C84vT8xdTI /Zhl/wCTLYFY7ryt/izUn6sbyVvh6ULtirNfIbv9buvRWZGLzy8rQK7/AO6/9gv2sSqre3Cr c7K3LieTOqhz8X8mRVRSJoYkn/0vlcryd7gcIT9n+55M+VjmlQdVmm9Vri5ieJkVEij5x04/ Fzfn9v8A555Ic1VUmZpV5P6S8jydYmmoP+Yb/d3+pkkMU8wvF+nldHWZV9Pi4tvqfTj8P1bF UltIprnUIkh+J3m5L/wXP/jXJKn+jK8XnHSkZvjjaNWPLqeUmKvpPEqw7zhteL/zDN/xI5FW A6A1JW/1sCWSM32m/wArFVrt/NiqjybviqmzL9rFVjPiqw/FhVKNe/3hbFWa/ll8VrE3/FLf 8TXBFDP8sVvFXYq7FWsVfOurNcf4h12aFV/umb4m7czkAlCXGmJDxurbnBLy4fCy8H+Hkzcf 73Eqi7RriOFPqdoju/8Ae83VK1+Jm5P/ADZEpCKu3SOFXgtEnlfiqRUUdciyUJZfVsqfV+Cu p5RcVrUMF4/D8OTYJHrNtc6fLFGzSo1wnKVZYlj2/wAniz+pkgql5Ybh5n01/wBlblP+JYEP qjJBXjv5zN/ua00eEJ/4ngKWFW7KvxZFU0tnXFUxhZTx+LFUanE4qrJiqMT4re6Xxt5f+IHI smc+T25eWNMP/Lun6stixKd4UP8A/9Ls2KtYq+ffN7/8hC1U9/Rm/wCTTYFY1qjqdeuHb7Tz Fm+lmxVkXlnXLHR29a7t5pucskUS28zQ05+n/ecMSqZXFz616qcl5zLxiTnV6Dk/2v28irby 20apC6+lLErK7c2cmv8AkcF4fZysc0of63bIsp9WXkWDc0lZE+zxVWi9L/jfJDmq63mWOaKX k/H7Stbv6clf+KZD9l8khj+vTfXdU+uol5wdUXlfH1JKjb4pQvFsVSrR34aih8Em/wCTUmSV OvLy8/OOkt/MsLf8SxV9J4lWG+c9rtfe2f8AW2RV55ob8XZv8rAlkXrftfs4q5peX+riqkzr iqg74q1zxVazfDhVLteb/ce+Ksz/ACv/AN5E/wCMLf8AE1wRQ9AyxW8VdirsVaxV876nMh1/ WyvFk4Mrqv8ArSHIBKEY819Fmikvo+ZlCI3qAFf3fqTcuH/AJiVVrRrd4Uk5oV3+3D69Ph/k Z4uORKQq3E1vNDFGzxHgw5K+42X/ACGV8iWS23SWK2ZXdfSZvhVWbhTl/wAHwybBLvMKW91q FvHYPbvxiPMW8kzqCnxPz+ufHH/sMkFQXlZv+dm0+n2vrCftf5WBD6oyQV4z+cm+v2I8IP8A jY4ClhULKMiqY20q/tfaxVMoXxVFxS4qi4pcVRcT/ubgf8Uyf8QORZM68kmvlXTP+MK5bFgn uFX/0+zYq0cVfOnnq6Fp521Z/T9WVw8abj4efwfF/sMCsfu3Z9cuD1VZm+4NiqI+rvdWnwce McsryszKKD938XF2+LJFATmx0toWhHrM1vx5NcRScOHf7PHKiyC65W5a4f6vdzIv7UrSrv8A 8k8NLakqam3wJfSlv8qTr/wUWNLa76pcyrbj1nLp8bLKyUT/AJJYqh75JUiVHumLCVOULcKU LruvBVxVjtk1LmGjcatwZvY/DkkMg8my/WfOOlLx4tG6RN78GpXFX0qcSrC/Ox/0qI+NtJkV ec6O/Hkf8o4Ep0s3w4qtabFVjTfFirufLFVjNirlfCqC1v4tOfFWa/lfvaL7RN/xNcEUPQMs VvFXYq7FWj0xV82yuGvtaPR+c3L/AIJuOQSl1zFLJrNwYZli+BGZefDmOP2cVbtrS5+ot6bn kf8AdPw7/F8XxY2qitlqI+Lg3+T8K42qJSG9isZavRS/L0qV+nlywKsiVofVlmlUShW/dcaO /NeHJXyQVrymiPrcLceUqzRtF7HngQ+o8kFeNfnJtr1k3/Lv/wAb4ClgiPkVRcMtFX/hsKo6 KZvhxVGRTcgowKjIZlxVGRSr6U3H/fT/APEcSyeieR/+UV03/jCMlFiU/wAkh//U7NirWKvm v8ywR511D/jLy/4bAqRy/wDHTlZvteq//EsVZR5Rle2uJZw7w/BNxZLb64+3p/7o+xw/4syR QEXezK1wx+0wXlyYcK/E3+6/91ZUWQUePporrM0zTKzurJQAhv2cjxLSlyV2ZzMqMH4ejwY1 HHlz9THiWkRbzIkqfFEi8TzZ4WuR/s4P92ZNUg1SWJ9cZ4nhdWdOTW8P1aPbh9m3/YxVJLRf 9Ih/1l/4kMkhkf5efH510/8Aypv1Pir6XxKsL89fDcQnxglXIq8x0+Xirf62BKYfWMVc0y4q 0s3xYqv+sLirvVxVv1VwqhNWlrp74qzn8q97EnwTj/w+CKHoOWK3irsVdiq1hVSMVfNN9K36 W1anEtNz5Nxp+1ImQS6+V5ETmrfChZWaGnRf2bn/AHbiqpbpLJ8YlmT01ZuMMfqdF/3Z/kZC 1dczSuq+lK0LFvtIjSH7P8q42rvVeZELOu/Hl8O32h+xklQ+sraJeehCqBfSr+6heDorf3iy /tcskFQvlBOXmrTPa5RuPybAh9S5IK8d/OcU1axb/l3b/ieApecq7ZFVZJf5cKopJmxVEpcL 2+1gVFQ3K/zccVTCG5VklXly+Bv+I4lk9W8j/wDKK6d/xiGSixKf5JD/AP/V7NirWKvnD80l 4edb7/WT/iKtgVjjsv6Qdj3lf4v9lirJdB+twrLLDa3c6p6kMstjJ6JBk9P7Tr8bR/DlZIDI AlESpLLcOHR0Z1PHn8Z/a/vHwGYZcJVppVdYUmmlVoUZOFxLUCrK37leKcMEZi0GJCGW+SOF 4UuH+KbnwSVBH/wGPVPE3bXPo3CuWlX4W4tbMqTf88nb4cIYJHrFz9Z1SW6Vrl1enF7neb7P +7GXJhUqi4rNFT/IySGSfloK+dtOP/FzfxxV9KYlWF+ftvqzf8VzD/iORV5TaOoV/wCblilX aZv5sVb+sLirXrYq2suKq6y/Diq9ZeWKofU3/wBx7Yq9B/Kn/jlyn2X/AIk+KGf5IK3hV2Ku xVrFXy7qNxw1u9+0yiWRW9/jf/gcHNK5/h5IfRhb0mcP6juHB/Z4N+7R8jSLbiu7f6v6piV+ a8WVncUJ/a/dsmV8LK3fXU51ZWbj+zyZP+GjZceFNqlvLDGqTBqoG+LehqGrw5ZYxQ+t3LXN wlzEkoT0vSb1Zmn3/wAiSUs3HFVTyEnPzfpUbftXCf8AEsUPp/JBXkP51J/plg//ABS4/wCG GApeXK+RVUSXCqosuKq6zYqqpcYqmFpcVZ6fyN/xHAWT2/yUKeV9N/4wrkosSnuSQ//W7Nir R6Yq+d/zZt5f8cXfBWfmsT8QK/7qTArD25PdurLx5OytyxVlug26PaM78t5WZOPgFVc1OqyE OfjATDZHqrOi/wAvbMQZS5BiFC7uH4K0tw/EsiMzGtAftceWZWCZ4mGWIAS+b0vqTzC+YSpE W4uqESHjFIvpLxX/AH5JmzLr+LdeunzG2hvPVcKqD4uCU5lefp/EuAMEJrCyoyRer6qLLwRG C7AJz/kT+bJhUh4qtwnFf2kySGV/lZCzeeLGq0oXf/hJDir6LxKsP/MEUhtn9ph/wi5FXj0U vwP/AK2KXNLx/a5Yqt9b3xVf6rdeWKr1mZcVVVm+HFV6zf7HFWr5+Wntir0z8pvi0J39wP8A iWKGeZIK3hV2KuxVrFXyrrzLFrmoJ4XEy/8ADtkApR93D9biiV3b0kUFVY9+P+UitmPkyU5e LFagunW5DDj1FF4mn/GuU+M2eA0ItOhf0Wi58OHrMS1av9j0/iXMzEbcXLGkRp+mNM9xzTh6 LO/pP9sJ8PFWof5WyTWh9Ut4obflEvBthyq1N2/yuWKov8to/U876V/kycv+B3xQ+mMkFeUf nUm+nv8A5Eo/4hgKXkPJsiq9Wwqu54qv54qvWXFUfYzNz4/s8W/4jgLJ9BeUV4+WdMH/AC7p +rJRYlOskh//1+zYq1ir5/8AznRo/OPNWp6lvCf+NP8AjTArB4v97fD4/ixV6FpOnSxaNbSF WHNOXIhv22quaDUgmTtcVUrXFnNDwaZeHqLzT5ZSYEJJihb7TPXho8qRxD45WdqDgPh/42y/ T3bHMRSSIdOguX+rXCTRIk8KQylPsNF+7dfVX+89Z83JOzrOHdkds1PLCDj8ZaJl/wCRXvk1 YzrdvchZZnidYhNxR1DBKmL4q8v9RMVSBeP1le3Hjihmf5PB5vOsTMzP6cMz8m3/AGeH/G+S CvoTBSsP/MUH9HW7/wAruP8AgkORIV4lzor4pUfV+LJBW/VwKqpL+ziq/wBVm2xVd6v2sVXr N474quupW+ouvLrir1v8p04+W+XjKw+7FDOMkFbwq7FXYq1ir5X81J6fmPVU/aF3L/xLlkV6 Mo0nUZU8vW8iNDxVuPpOnM7N/l/HmrzfW7LF9CLt9TZpYo/StBzb7bRf25RKWzKOOikuvX1v JcyxSQwlg3HlFxTqqfvl/wCMfD9vNlpvpcPPsUPZ6rDC128rc2nXiu6k/wC6x4/5GXANCGvp rSe2lcTKHVAqRMGqTzH2f2fs5JU0/KSH1fPFj/kJM/3Jih9GZIK8x/OeKttpz/8AGZf+FVsS l4tyyIV3LFV3LFV3LFDatiqN09v33+wP/EcBV9I+Wk4aBpy+FvH/AMRyUVTXJK//0OzYq1ir wr89IOHmKxk/37agf8A74Fee26q96odqKzfE3gP5sVe22nm6Wy0exgjghkaKKGLm4bcBPt8c 0k9V6nYDTGkTN5ztn4D9HQyLuGLhf+Fyz8wCwGnkxT8ydagngsYrCH6o5MhmZPh5jio9P/Vy 3TSBa8sSGALM435L8X+SuZwjbi3Tf1u4K8Ofwr+zxWmSZL1W7nSaFHZkRHuH49BwX4nxVL3R ku6f6q8v9jih6F+R1uX8yXc3++bZh/wbx5IK91wqxX8wkroPP/fcoP3o65Eq8Ed/hf8A1sil D8/iyQVer4FXK7csVVVdsVb54quV2/ZxVfM/K0Zf8rFXtf5WIF8pQHu0j8sUMyyQVvCrsVdi rsVfMn5i27WfnTVhShM3qp7q6rkVPJfY+iukpwl5/RT9rpmrzfW7LF9CrFKnNBy75TKOzeJN TaSl3M0/1u2jrxXjM1HzY6b6XXajmtl8t3A+w9pN/qSLmQ0ILUdHltrR5rhoYlH2EDKXc/yo uSAVk35JW5k81zzAclgtmLHw5txyKHvmSCsA/Nq39TR7Jz9lJipP+ujf804lLwTlxZl/lyIV ytiq7nirua4ob54qj9L+OV/2eMRwFX03oyenpdmn8sMY/wCFyUVR2SV//9Hs2KtHFXiv59Q0 vtHn/ZMUyfcyN/zMwFXmNk6LfI0i805jkniOS/DkVejXcqOvFV4Ly+FfAfspnOl3QGyHSVld fi/2WICyG6Vedb1p7m1Dv8QV2Wnu2bLQCh+P6Thapj9u1szsJrhk4qeLcM2JcEKrPZekoMrK /Jufw1HDDSUfb3un2OnXX1XUFlu7qL6vLE8LjhG+78H+xjSpFLKHuVKfZ/Zbxp8ORV6j+Q8X K81ab+SOJP8Ag2dv+NMkFez4VY756Tn5auz/ACcH/wCGpir53mb7Y/ysCUNy+LFV6tiq9WxV erfFkVX8vh+1irlbAhVduVs3+tir3L8rhx8oWvu7/ryxWYYq3irsVdirWKvIfzj8qXUrp5gs 4zKOAivAoqVCf3cv+pgO6XmunS/7j+A7Ocwssd3O0/0ohZfiVsq4NmUTul+o3D+sycV48Ry2 Wv8AwWZmIbOHnO6CV3+FV+0fs5c1OlWXlSX7X8uKvefyg8qT6Lo8uoXsZivdRIYRtsyQr/dq 3+v9vCr0TFWN+fdHk1byve20K1uUX1of9dP+bcCvmh1dHYOtHDfEreOKrcbVdjauw0Fd8WNB WQ+StFu9Z162tYVb0uYa4fsEVuTZWAr6XRAiBF2AFBkqVUySv//S7NirWKvKPz3s2fStKvAu 0Nw8Tt4CReS/8mcBV43Fw9ZW5/EzD4cirPJmdF4t8WaAB28pbKKu3L7OJCRLdj/mZw99CGZv 7scVp/lNm10gqLiapKWih3HqkMNuJRsy3BC1lh47Sr/wLYbSt/dNsZV/4FsbVy8A3wy14/F9 lv45FXtP5EWrppWp3jA8Zpo40Pj6SM3/ADNyQV6thVKPNNu1x5e1CJN2MLGn+p8f/GuKvm/U Laa2dw6/tclfxGBKX8/hxV3q4quWbFV/rY0rluP8nGlXrcf5OCkIq3SW64wxqxZm+L4dhjSv onydpf6K8u2NmftqnN/9Z/iySp5ireKuxV2KuxVTdFdSjiqnYg9CMCvGfzD8t6Zp+tQpYQi1 iuojJIkf2OfL7Sr+zmDnnRc/T/SxIaSfiKP9nxGYozNsY7p7oX5YX/mKz/SUN/FbxM5Tg6M5 +D/VZc2GGVhws43T23/I2hVrnVvs/wC+of8AmqTMhoZToH5ZeWtGmF00Rvb0UImuaMAR/JH/ AHeKszwq7FXYFedeb/yqs9WuHv8ATHS1u33eFx+6Y/zLx/u8VYBc/lh5qtnK/owzgd4JUcf8 P6eRVCHyL5kRqPol3/sQn/NeKqsfkHzJJ00S7/2XBf8AjfGlTrTPyk1+5dfrMMVnD+00snN/ +RcY/wCZmNK9R8reVNO8u2vpW3xzP/ezkUJ/5twhU/ySt4q//9Ps2KtYqx/znoA8w+XbvTek 7j1LZj2mj+OP/mjFBfMjW81terbXCGOWOUJKjihBDfZyDKLMdT1OK14NMrcSSNvlmnwYjIuw yTpRtNXs55lhTlyb9ll8N8lkwEBcc7SzzIw/SCS8aqiJ1+fLMzS/Q42o5pa4hl5TceCk/Cq+ /LMmMXHvZF6dcaeYmhvLeJVKfBMo+PnxbvyyapVMsSmityxVdZ2015dRW0KM80jBVVfE4VfU Hk/QE8v6BbaaP71BznYd5H+3iqe4qsdFdCjiqMCGHscVeF+cNIfSdQmtZouVry527kfsH4uO VEKwe49IOyoq8f2cnEqo8xy+yuG1d6qfyrjau9Zf5VwWrvWX+XG1VoX5Mq8K8sjavSvImhPq VygEXC0h4vcy0pzp9mNcbV7GAFoF6ZYq7FW8VdirsVdirWIC280/NOAtqGlyL3Dp+IzXaynM 0zF00vUIllZ7WYJx+0Y2A/VmunGVOTxgvQ/yzHHy6V8J3/hm40xPA4eqA4mY5lOM7FXYq7FX Yq1irsVdirsVdirsVbxV2Kv/1OzYq7FVpwFBYL52/LbTvMDnUrX/AEXVU3MiD4Zafsyr/P8A 8WZFlF5xq/lPVp39GdFrCT8PKjg0/wArMTHjMC2GfEl1t5V1OzuFmSB3YD7NVPX4cnIGQQJc KlrnljW5XkvEt6xQovNAwLin7Sr+3luCNBZytIEsbkvxSJyv7Kqj1/yf2ctJprpG2PljXtQc QWtjM8znly9N1X/gnXFWR6f+UHm259Jp4ktlevwu26U+H48Veo+TPy10jy0RdPS61P8A5aHG yH/ipcKs2xV2KuxVJfMnl201y0aGYUlA+B8jJXh/mbyRrOlTMxt3e3/ZdNxkAVYk1vKrcSrb fzDJK70X/wA1xV3ov/L8OBVSK0mkZVjRnY/ZVd8VZz5T/LbWtTuEmvIWs7LqXkWhI/yEOS4V e26ZpdnplqlpaIEiT7yf5mx4VRuSVvFXYq7FXYq7FWsVAed/mVqFra3+l+t1XlJT2UjMHU4S WzHqBBbqH5p+X7myuLZIpw0kbIrFR1ZfnkstSi0R1EYlNPy3ubSXQ3SGVXcSlnQGpFQv2sOl BAbsuWMyzLMtg3irsVdirsVdirsVdirsVdirsVdirsVf/9Xs2KuxV2KtEVxVLr3RrO6mE7qU m6c07j/KwEWm0G/li2b/AHaadKFFbKTjtbUrbyw1tcJMlzyVD9lk7ffkhGkMgA36ZYCq7Crs VdirsVbxVrFXYKVaVVhRhUe+NKgp9D0a5/3p0+2m/wBeFG/4kuFUP/hPyxWv6JtP+RKf804q vTy15dQ8k0q0U+PoJ/zTiqMgsbO2/uLeKH/URU/4jiqIxV2Kt4q7FXYq7FXYq7FWsHVQ8n/O RE+uaY77ARyb/SMry8nGzCy81VIv9l/lZWZNFEM8/K2Z4fMCRRt+6mhfmPHjQrkotenkeN7N l7tG8VdirsVdirsVdirsVdirsVdirsVdir//1uzYq7FXYq7FWsUOxVvFLWClbwq7FXYq7FXY q7FWq4q6uKt4q7FXYq7FXYq7FXYq7FWgD41xV2KuxVvFWsAV5d+b4/0nRvAs6/qyvK1zFlgq wurM3pKV+P8AHMAScjJjCd/le/8Azs9sv7PpS8czcbqcW2R7hl7sm8VdirsVdirsVdirsVdi rsVaxVvFXYq//9fs2KsW1/8AMTy3oczW80rXFymzxQANxPg7sVRf+CyPEqWWH5w+UrpmWYzW xG6lk5g/8iS+G1V5fzZ8noaCWZ/9WJv+NuONqhn/ADi8rivCG7fwpGor974LVQf85tDH2LG5 PzCj+Jx4lUm/OjTf2dNmPzcD/jXHiVSb86bf9nSpPasv/XvHiVSb86v5dJNfeX/r3g4lU2/O m4/Z0kD5yH/mnHiVTP5z6ifs6ZEPm7HHiVTP5yayemnwD6W/5rx4lUz+cOv9rO3+5v8Aqpjx Ks/5W/5lPS0tz4/Cf+a8eJVn/K3PNR6W0A/2B/5qx4lU2/NrzbU/BCPD4B/XHiVSb83fNw/Y h/4Bf642qhL+cPm9akiNR7Rp/GuNqtk/N/zetPiWhAaojTv/ALHGyqkfzl81jYyKP+eaf804 d1Wn85fNf+/V/wCRcf8AzTjurh+cfmskD1hUmn2I/wDmnHdW2/OPzZG7L6ykqaf3cdP+I47q vi/Obza0ioHiJY0HKNKfhTHdUcPzS88A7/Vj/sV/rgtKr/ytnzfEheSG2ZVFW+Hf8HxtV8H5 0a8KGSyt3HhRl/U+NoR9v+dkjSrFNpqBj14yMNvpRseJXqOn3iX1jb3iKVS4jWQKdyAw5U2y QV5t+cxCDR5G2USvU/7HK8gtqmHnq3ttz+KZuPI9+37OYcYlvllBT78sC3+Krb4fh4y8W7fZ zLiS6+A9b3XLnObxV2KuxV2KuxV2KuxV2KuxV2KuxV2Kv//Q6L551mbRvLV3d2543DARQt/K 0nw8/wDYrkZHZIfOXE3lw7zsWVWOx3qf2mbANkJjF6MYoE+7bFCr6kX8rf8ABYEt+rDTo3/B YqskFq7BnRiRt9sj78FqsMVkf91t/wAGcUu9Cy/303/BnChv0bEf7pb/AIM4Erx9TUACDp3L EnFC4Naf74H34pb5Wv8Avkffirv9E/3wPvxVtWt1J4x8fGhxVtpIv5Wp/rHFVOQW8lKo1QKV 5HFVI29rX7Lf8EcbWlptbNgVZGIPWjHFWzZ2RAHFwAKCjnthtXLZ6etQYi9e7ktTG1b+p6b/ AMsy42Va+qacDtbLtjZVzWensSTbrU7k4LVpbSwVgywAMNwcbVEAoSNuuKrJxHxeNzxD1WvX FKB/RopQXL7f5H9mPEFpXtbdYKgyF+bD4iKe2C1p9L6bEsOnWsKCixwxqB8lAy5iG7i0tbig uIUmA6c1DU/4LGlIU10vTh0s4f8AkWn9MeELQVYrW2h/u4USnTioH6sCKARGFLsVdirsVdir sVdirsVdirsVdirWKt4q/wD/0Zn+aq18oTH+WWI/jTISSHg9t1kH+UcUKepV9GMAnd6YhUEy jiOAJYGnU74UsgFjp8k1nZnUVjglgEs1yyf3chBb0DxP83w8shxeS0gjZ2ctlLdm5pdrLxjt OnKMA85an348F/bx4t6pNIAQrU8gTtUDkeuTtiitLARpRUmoU7/TgKo+uRV2KqN8aWcvyH68 QlARRRiN+a8n24MGNRvvt3ySE3is9Gkm0qG5vHjtyrfX54gWaMk8o14tsW/ZbjkIyNnZkQpy 6bp5tb2cXjh1mVbKEr/fR1+OV2r8Hw5K0JaltGZFEgIQnfc4bQvs4/TvFpt9rapNPvwEpTM7 4FcMCrq4Vd2xVxP3Yq0TiricCtVxVch+JfGuKrnlSDUbGZ6rFHdI8hFTRVNWNBkZCwWUeb1I +cvLBY0vRQn/AH1J/wBU81ngz7nM8SKWeZPMehX+jXFra3SyTtwZECOpPF1bqyLk8WOYkCQx nMU9Tsjys7c+MaH/AIUZuHCV8VdirsVdirsVdirsVdirsVdirsVdirsVdirsVdir/9Kb/ml/ yh13/rxf8TGRkkPArb7Un+scCFuoEcYa/wA/8MQqE9KRWLMwC1qMKVZba4LJGEcvIOUaBTVh /Mgp8WR4h3potC3mKlwCUU8WehoG/lLU+1jxBFLWt5qVBFe2StUTYjjJIp6hFBPvvkShGVGB LYpvX6MVUL7/AHjk+j9YwhUCqy+q1K+memFVXif5v1YENsGY/CaeC1riq10lptWvbphS3bBh cRepu/xV+7AVTIdt/owK3XFWwcVariluoxVo0xVrFDYxVchPIe5xSuJ4alZS0/dw3KSSkb0V T8RyMtwUh6qfN3lskn64n/AH/mnNZ4M+5zPEj3pL5l1/R7yxuYrS4WSR4VVAqkVYSBqdP5cs xYpCQsMJziQ9U0xuWm2jeMMZ/wCEXNqHDSbz9rf6E8q314rtHOy+jA69RJJ8Kt/scSrwVNd1 Z4kZr2cM68uXqv8A81ZCylqPXdWVKSX1wzDoRK3T/gsNlCqvmDUwB/p9wB4Cd/8AmrBZVl35 f/mVcafdDS9dmaawmb9zduSzRMezk1PpN/yTyQKva8krsVdirsVdirsVdirsVdirsVdir//T m/5o/wDKG3n+vF/xMZGSQ8BtvtSf6xwIU9S3ji/18QqncxmWPiDTpX5YqyxPMMCeYbG99aNo NJs/Rt5BG4WZ+BHptH9uHk7/AG8w/BPAR/qknI8TdLl1YL5Zk08spuby9N1cJxIMaj4hwkrw k9Rv+Ayzw/WD/MiwM/TSVh6sPnl7U60P+k3B8aYlKLrgQ3ilQv8A/eOTx2/WMIVDvU26hPtF BihkUepaMusaBKVjFpa20a3z+mSGkIb1BKm3L4uOYvhnhkP50m/j3CAivbM6PqcHpKL25uo5 bc8DVY61k4TV+Bf+K8s4PVE/zYseLYoF2Fcuamh/vdF/qHFKOBwK3irq7Yq6uKtV+g4q1iru 1MVbA/2sVXA0oRiq/n1JG/UnAlvkPDFXBh2H04q+itDblo1g3jbxf8QXLQxYd+dJp5MI8biL +OJS828m6/YaVZTRX0RmhuIwOCqjHdWT4Wf7PGuV9U2ih5wtW0/TrI2qmWzlRjLwRQVUMtGP 7XIH9vBS2jT5x8vLqt7M9iTb3EaR8BHEaOiFGdf5eTY72thKdU17R7zy/bafBbGO/idOU3BF HFRv8S/G7YBGkmT6Iy9g7FXYq7FXYq7FXYq7FXYq7FXYq//Um/5pH/nTLz/Wir/wYyMkh4BB s0n+tgQp6h9iL/XGIVskDcmgwJW84z+0PvxV1A/2WBxVcoIYVxVuzNJ7j5jFUZXArq4qo33+ 8kn0frwhUNz+BAP5Riq4E064quqfHFWq4qvU1vYvZDiqNGBW8VdXAlo++FWif9vAh2FXV364 quGxFcVbrirZ64Fd1PXFLa9adMKvovy+a6Hp5/5d4v8AiAywcmLEPznAbygFJpW5j/42xKXi dlDJMYbeEcpZAI0XpViaZXI0qK1TSr/SpVgv4fRkZeYFQ1R024k5GMxLkkxI5rr/AEPVdPto bq8tzFBPT0nqprUch9k/y4iYPJTEqGn2/wBavre25cfWlSPl1pzYLWn05Ji+p8tV2KuxV2Ku xV2KuxV2KuxV2KuxV//Vm35p/wDKGXf+vF/xMZGSQ8Ag+1J/rYELNQP7uP8A1xiFU7iMyBQD sCKj2xSjDY6Ob+aFbyYaekZa3uDEPUeQLVYpIwfgVpPh55DilXL1MqCjHa2y2kVyJz9dMjLL acfhWMD4ZFl/a5N+xhs3XRHRtiC432rhQts/764+YxKoquBW64qo3h/0ST6P1jCFQz19JeI+ LjtiqJSy0k3ltEbub6lKiNdTiOrxyEH1I0j/AN2Kj/tZHiNHZlQU47e1NrNIZZFvEdBbxBfg dDX1JHf9hl/lw2bQ29aAdThYtoCL2IH+Q4pRuRVXtIPrEyxcuJapr1pQcsjOXCLZRFmk6sfK z30YkjuQinoGQ/1zGOqro2+EipPI06CpvEP+wP8AXB+bHcnwfNDHyjKD/vSv/AH+uH80O5Hg tf4TkG5uV2/yD/XH82O5PgnvQt5oRtYJJjOH9IKSgUioZuHjk8eoEjVIniIFpT3zJaVwHhgQ 6tTil1cVbU74q+jPLy8dC08VJ/0ePc9fsjLRyYsP/Oc/86mnvcx/qbEq8b0WaKDULCeZuEUU iPI3Wig7nKZiwWQ5p9561PTtU1GCWynE0KwlWZAdmqSB8XHKsMSBu2ZCDyRXm7WtLv8AQ9Ot rS5WWaEp6qAEFaJxPUfzYMUSJbrKQMWOaF/x2tPPT/Sod/8AnouZDU+oMtQ7FXYq7FXYq7FX Yq7FXYq7FXYq/wD/1pt+af8Ayhl57PF/xMZGSQ+f4PtP/rYELL/7Ef8Ar4hWmNMUt/ESPlir ZJWlRTArXLk4Pvirdof3s/zGJVFYFdXfFVK83tZPo/XhCocGipX+UYqrJ8QUDYnFXM4JNOnb FVrOCABvTtiq9d76Pt8BxVG07nvgVEWXpfWE9c8Yv2iCQRtt0yvJdbMo1e7IbIeXvT/0i6ZG 8FkcU+7MM+J3f7FvHD3oqQeVAh9O9kLe8smAeJ/N/wBiy9PehWOgHYXTbf8AFsmH953f7FHp 71gXQv8Alrb/AJGvgPid3+xZejvQd/8Ao76vL9XnZ5OSiNS7MGWvxfay3Fx8W4YT4a2KTd6/ jmY464U9/ngVxqK4qtqMVXLs1PxxV9IaKvDR7FfC3i/4guWjkxYT+dR/51aH3uU/U2JV4rAr OqKoLMQAFAqSfkMrKUR9QviWpbTfAOT/ALtth4ttg4gmlMwzQlXmhdVO681Kg/ePixBRSM0D 4tc0+ve6iP8Aw64VfT2WodirsVdirsVdirsVdirsVdirsVf/15t+ahA8l3le7Rf8TGRnySHz 9ATyf54FW326x0/mxCocO7NQnpiq795Xriq74+hauKrWd1NARTFVa0/vJ/mMBVE1wK4dcVU7 w/6NJ9H68QqGUsSqBamm3j92SVf+8ABG1MCuLSNscVWlnQFgASMVVLd2e5iY9eLfhiqYZFUb pRZb6ErGZWBPwAgV2/ytsry/Sd+FnDmzpLvUFRU/QrGgAryi3981vDH+d/unKs9yjNcahQlt HYD/AFo8IiP5yknuQz3V4eulkf7KPDwj+ci/JTN1cdDpxB8OUeHhH85NnuQWqXUx0+dGtDGr cP3nJSF+MU+z4/ZyzCBxbS4mM74eTGqnNg4q6MfEPc4FX3QRJ+IrWR+EaLU1J6KoxSiv0HrW 3+4+4r/xjOV+LDvZeHLuWPpmp29XntJolUBizIQACePI/wCywjJE8igwI6PozTxSwth0pEgp /sRmSGtgP51/8oxb/wDMUv8AxFsBV5L5dKx6zpjuQqetGSxNAN+5yjJyLOPN6zJd2xu9Q/0i Oht0A+Nd9n98wQ5TGPPs9vJoOmIsiu4ZacWDUHDfkFy/DzasnJhOmXBttQtLhF5vFPG4Q9Dx ZTmU0PqTLUOxV2KuxV2KuxV2KuxV2KuxV2Kv/9Ca/mr/AMoXd/68X/ExkJ8kh8/QHd/nihbf VKIAaHliEoZNgxA3/phVkp8v2azaS1zdCOy1K3aZpFYExFfgpI3Hiv7zKwSzICBk0yBdLu7t JuVxa3Qh4GlHiYNSUD+bkuEEsaCVAM5Pt3OwySFazYO0rAeAp8sSqKrkVbGKqd1/vK/0frxC rbCRFulNwhkjI4Oq7N/kmNv2WrklZXB5ZsV1XRLe8mWOz1WB5ZGJqFcH0/SV/s9ePx5EA97I 0lk2jWdtZ6lLJIzyWd0baIhgKinwO0f2m+L7WQPFe30pAFbpCVLVHj49MtYL7Ta5Vf2lDVPb fAVTEDx+jIpR2kpM2oQJCwSViQrEVA2NdjleWuE2yhzZtbx67MvIajGvzhX/AJqzXng7v9k5 O/eqS2GucPj1OIj/AIwj/mrG4d3+yXfvQDWeqb1v0P8AzyH/ADVkrj3f7JaPehp4NRjUsbtD TwjH9ciTD+b/ALJkBLvS68N3Lps0zTK0YZEdOAUmrclKn/WGXYeHjoBjk4uHcpF0OZziLov7 xa9aiuKrrt+Go2r8SxS6U8F3Y0b7K/5WCQ2LKPN6Z/iL4if0VqH/ACJH/NeavwvODmcflJK9 d1iSe0n/ANx15CjxCP1ZYwqA+oG+Mhvs5bihUhvFhOW3J69af7yw16+mv6hm2cJi/wCZPlq/ 8xeXxbaeA1zDKJljY8eYAIKqx25b4CFeUr+XPm4RhTpknICn2kp/xLIUUui/LXziUrLprBva RP8AmvDRVUH5aeah109wO9GQ/wDG2Ciq62/LjzX9ZhJ06RAHUszOlAAQT3xoq9+yxDsVdirs VdirsVdirsVdirsVdir/AP/Rm35qRu/kq94ivBo2angHGQnySHz7CfidT1BxQ3PEJlA5ceJr XFK1LYKf7yvY1FcFqqxoscbIHb4xx+0acT+zTwxW1noDgFEjAb13239sVWfUz/v0/djar4IR CG+Kpb6MBKqtcVbBxV0iCSJo605d8VUVtJB0nIp7YbVXjjKACSV3VQQqhiAOXXjjatPbBt/U bmftNUmp8cbVTNk3+/jTwocbVfBaejJzL89qdMSVRVakYErhJShBoR0IwKu9aWtebf8ABH+u Cgm2/Xl/343/AAR/rjQW2vWk682/4I40EW160n87feceEJtr1WOzMSO4qaYaCLW1OKr4QTKl BvUfrwqqXQddSikVeSwXCyOB1orVNK5EiwkGizo+etLqf3E/3L/zVmv/AC0/Jy/GihNV84ad fWEtnFFMJZaBSwULXkDv8WWY8EoyBLCWUEU9ntd7aH/UX9QzZuIq4q7FXYq7FXYq7FXYq7FX Yq7FXYq7FXYq7FXYq7FX/9Lr97Z29/aTWd0gkt50MciHurCmAi1fP/mr8s/MGj3jNawPeWVf 3NxCpc8f2UnjT4lZf5siNuaUqs/Knmi6BMOlTuAKkhGUbdvjC4q3J5V80x156Ld7daRs3/Ee WKoZtF15Pt6ReLTxhk/5pwKh5dO1gGv1G4jA6gxP/FcKqTwXyfbikX5qR/DAqmWnHWo+jFXe pL4n7sVbE0gG4qfHFVwuH8MVb+sP4D8cCt/WX8B+OKtrdfzD5Uw0q761F4H78aVbJcg04Nxo N+9caVTN04P95hpVOS9lp8MlD9GClVGvHULWWhKgmgrucaVoakVRtzJJ2qAFphpVn6Un/kX8 ceFXLqk5YDgtCad8eFW31OZZGVVUgGgO/THhVyanOzqrKoUnc77Y0qYrNGCCJVr/AK2RVe9y jCV2lBcqx5V3qcUpWJJSP71/+COSQiLGWQTlGWSQkgqetKYCFfUmmOz6baO4Ks0MZZT1BKjL AhFYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FX/0+zYq7FXYq7FXYq1xU9QMVaMcZ6q D9AxVYbW2bcwoa+Kj+mKqbabp7fatYT841/piqk+iaM5q9hbsfExIf8AjXBSqDeV/LbkltKt CT1Pox/8040qk3k7yqwodItN/wDipB/DGlWN5I8osKHSLb6IwP1Y0FWHyH5ObrpFv9CkfqON BVh/L7yYSD+iYdv9b/mrGlWH8uvJR66TH9DSD9UmNKt/5Vt5I/6tSf8AIyX/AKqY0rj+Wvkg /wDSqT/kZN/1VxpWv+Va+SP+rUn/ACMm/wCquNK7/lWvkj/q1J/yMm/6q40rv+VaeR/+rUn/ ACMm/wCquNK7/lWnkf8A6tSf8jJv+quNK7/lWnkf/q1J/wAjJv8AqrjSu/5Vp5H/AOrUn/Iy b/qrjSuH5aeRwajSU/5GS/8AVXGgqov5d+Sl6aRD9Jc/rfGgqsnkTyen2dIt/pWv/EsaCou2 8s+XrRg9vpltE69GWJKj6aY0qZ4VbxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2Kv//U 7NirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVd irsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdir//2Q== --XX52BF529F-00B052BFXX Content-Type: application/octet-stream Content-Disposition: attachment; filename="Car handset.jpg" Content-Length: 44446 Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgEASABIAAD/7RAeUGhvdG9zaG9wIDMuMAA4QklNA+0AAAAAABAASAAA AAEAAgBIAAAAAQACOEJJTQQNAAAAAAAEAAAAeDhCSU0D8wAAAAAACAAAAAAAAAAAOEJJTQQK AAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgABAGxmZgAG AAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0AAAAG AAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///// ////////////////////////A+gAADhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklN BBQAAAAAAAQAAAAFOEJJTQQMAAAAAA6OAAAAAQAAAGgAAABwAAABOAAAiIAAAA5yABgAAf/Y /+AAEEpGSUYAAQIBAEgASAAA//4AJkZpbGUgd3JpdHRlbiBieSBBZG9iZSBQaG90b3Nob3Co IDUuMP/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgR DAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIAHAA aAMBIgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEF AQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFR YRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXy s4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgEC BAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPEl BhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG 1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/AOwa5Ea5V2uRGuWmYucC2WuRGuVZrkDqHWul dKY1/UsurFD5NbXkl7gOTXUwPtf/AJiilQ1OjJE26jXIjJcYAJPkuQyP8YPQXVCrpeVXbm3P FdJym2UY9Zd/2pzL7WV7car92v8ATW2bK/8AhFqO6FX1BjXdWzr+pVvbPo1P+z4bgdfbjYTm +vX/AOGcrJUJIOkdWUab6NrO+tf1d6dY6rLz6xbWCbaqg697A36RurxG3uq2/wDCK70vq3Tu rYgzOm5DcnHLize2QQ5v0q7a7Ayyqz+RYxUOodBwsvoOV0PFDem4+UwtBxWisNdIeHOZXt9R jnN/Ts/w1W9eYYPUPrF9Qut2Yt9bXF+03UEn0cqoTsux7oGyzaX+ld/g/wCbyKvZ6ajlYOrI KI0fbAVMFZvR+r4PWen1dQwH76LdIdo9jx9Oi9n+Dur/ADv+h+jV8FAhIKUFOhgqYKaQuBXS SSQS/wD/0OoDlNrkAOU2uWwQ5QLar9z2tPcgLxbrPUX9U6tmdQe4u9e15rJ7VAlmPW3+Qylr F6x1bOOB0jOzWmHY+PY9n9fbsq/8FcxeNtZtaG+AhUeaOoH1bXL7E/RUr0n/ABUW3fs3qNTn H7PXfWaWHhpcx3r7P622tecbV0/T+s9R6B9V6Bgn0srrN9hrugE10Y/sstrB/wANdkWvYyzb Z+jpUEDRvszSBIodX0jqn1o6H0eW52U1tzeaKwbLewj06/ou930XrF6h1j6i/XPF/ZV+b6F+ 6cO25jqXsscGBrqH2j0rPUda2uzGdZ+m/sV3Ln/q19Q7er41XUuq5VlGJf8ApKKqSPXsafaz Iuvt9RtO/b+7Zd6f7it9d/xY11YTrugXXXXsEvwslzXixscUPayrbdt/Mf8AziceMi60QOEG r1cKm3r31B+sXp3NlxgWNBIpzKAfzXO+jcz/AAVv08e3+c/Rr1vofXen9cwW53T3l1ZO19bx tsrePpU31y7ZY3/zheW/V/rOJ1TDq+qn1mBPTy70sDMMi/DvnZVS+x3+A/wNe9v6D+Zu/V/5 kM/WL/F/9YCyWvFrdrHkH0MukH2te3/BZNX8j9Njv/0tNv6ZgNMhfagVMFZXQut4fXOm1dRw yfTslr63Rvrsb/OUWx+ez/p1/pFpAokIBTApKAKSbS63/9HoGuU2uQGuU2uW4Q4wLkfXi8M+ rllU65N1NTR4w77Q7/o0Lz0VLrPr5lb8rAwGn+bZZlWDzcfs9P8A1Fy5oMWVzMrynw0b+DTG PHVWF02/qObj9Px4FuU/YHHhoANlln/W6mPeuj/xiYteNldHx8cbMevEsx6BoI2Oa3w+k5rm J/qJhizrN2W4SMPHhh8LLz6f/niu5dH9a+gHrvTBXTpnYpNuGZgOdEWY7j/w7R7P+G9P/B+o lDETiMhvf/RTLIBkAOwH/SdP6tWss+rnSnM+j9job82MbU8f9uMctRrl5j9TfrW/pdw6X1D2 YL7S1xf7XYtznbXudu27cSy3+fZ/gLP0v+lrXpYJBg8qTGRKPiFswYy167PFf4wPqk+51v1i 6czdYGT1PH/fY0bftVTf32Vt/WGf9e/0qH9Wuo4v1v6M76qdbfvvrYbenZv55bWNjDqffmYj H+//ALk4f87/AKVd41w7gEHQg6gg9ivL/rf9W3/VjPp6p0t7qcC60Opc0+7FyBL2sDvzqHf4 H+R6lX/GRZIcJsbMsJ2K6tXp+Z1j6ifWR9OQ3e9rWjKpaf0eVjn3V20udt/S1/Spu/Mf+hs/ wy9jwM/E6hh052FaL8XIbvqtbwRwZ/csY72W1u99dnsXEsx8P/GH9XWuvNeP17p5cwvr09Ow +6nez3P+xZrdj/8AgrvV9L+aXNfUv60ZP1a6nZg9SD6cKyw15+O4fzFv0ftbK/5P0Mj0/wCc q/S/4OtM28iv38w+ygpIbHtc0OY4OY4BzXNMgg6tc1w+k1ySNIt//9LXa5EaeyrtcpOyGY9b 8iwxXS11rz4BgNjv+pXQSFAns4US8R1fIGb17qGQPoV2Nxq58KB6Tz/as3KuKwdAhYe70GOf 9OybH/1nn1D/ANUrAdtknsJWBKXFInubdYCgAOgr7HrPqNSWdMycg/8AanKdt/q1NbSP/BPV XStcsX6sVmn6v4DToX1eq742udf/AOjFrNctPFCscR4NOcrnLzP4PPfW76pnqZd1TprQOpMb +mp7ZDQIj/wzs9v/AA6y/qd9caunM/Z3U3PbgNIbRa4EnGdPupuaf0v2T9z+c+zv/wCuej3L HS8saQXtjc0EFwn95v0mrnfrT9U8HOLuo031dOzzO+y5wZRd+8Mjd9B/79zP5z/DVqvlx8J4 4EeLPjyAjgn9C9dXY17WvY4PY8BzHtIc1zTq17Ht9r2O/eTZWNjZ2JdhZlYtxshpZbWe4P7v 7r2O99b/AMx68p6J9Zet9AP2Zm2zGa4zh3ODqj7h6pwshrv0W/3e+n1Mb/CenZ6i7vA+uvQ8 0NbSbzkFu9+Kyl91jezv6MLd7f8AhGJoyRkKOi445ROmrw2Vi9W+onXqrarA4e4Yt5n078cn 3Y2Wxv8A0q/8Haz16f8AAov10+sHQevV43UsWi/D6xTFeSywAssqO72/aKnFtr8exv6Kz9A9 9P8AUrXdZvV+h9QxX4ebgZubQ/6VLun5J1gt3smpjqrdrvZbW/1GLi+tfVPAxel5XUcfFz+m 4NTC5r+pPqD32fzePi4mEycj9K8s335L/wBHjst/RKGUaNA2GaMr3Gr1H+KzqwyeiW9Me4mz p1k1gx/R75spj879HcL2fyP0aSwf8U1V46vm2yfRrwmMsGsb32tfT/0K7v8A1Ikh+j9VfpP/ 07wcsr625fo9EsoaSLM17MdseBPqW/8Agde1aLXLl/rZkOt6njY35mNSbSP5dp2/+eq1u87L gwy/ren/ABnE5SPHmiO3q/xXPD/uTZFm3Gtd4MKg0FLMYfsrwOXkMHxdosOnXA1D6V04bMDE rH5tFLfuYxYvVuv5FjnY+E52PWxzmW2fRscWksc1v+hr3N/42xbrQGQxvDAGj4NG1cz1vpuY zqO7Dqbc3NLntb+cLAA65upb9L+dZ/1xaPNiccUeE+naVNHluGWQ3udYubT0S/q9gqxWhrmO HqXvnYwOne6xzfe/c0fzf567fpPQ+mdLqYzHqa+1gj7TY1psPf2mP0TP3WVLL+rOHlYNmTXl wLbmVWNaOA2bWlv9l30/auga5R8vhjw8ZHq13/Rpkz5ZcXCD6RW36Vq6hg4XVcV2Jn1C+lw0 n6TT+/S/6Vb1w3Uf8XfV6Xl3S7q8ykGam2P9G5pPtHv0rf6f6P3NtZ/Nfzda71rkRrk/JhjL XY9wtx5ZR227PmxZ/jGw5qZ+1mMBMBj3XDhz/bZNv/BfR/4RNT9R/rh1S435VRqe6f1rqF26 wQ5+oZN+Ru+h+YvTmuRGuUB5cdyzDOewaP1X+r+P9XunfZa3+tfc/wBbKvgDdYQG7a9Nzcer /Asf/wB/SWk1ySPtiuHojjO7/9QzDJAHcrisrKGbn5WYNWW2ltZ/4OselV/0WLqOo5Bx+nZd 7TDq6Xlp/lEbWf8AScuSx2bKa2DTa0LW+Kz1hj85n/oxcr4bH55+UB/0pf8AcJWAt1/BHfWL BiN7WZVLD/nIUtmY8law6nPdgdx+0KR/mh1p/wCpWbEeoDuQ6EjQJ7Al7ovl7j5lOWsft3id jg9upEOb9F2nxQQ7VEa5bkogiiLceMmw1yI1yrtciNcmELwU7XIjXIDXKbXKMhkBbDXIjXKu 1yI1yjMV4LZa5JCa5JM4dV96P//Vy/rDud0XLDdYDSR/JD2Of/0Vh1PYWAjWQIhdS5rbGOre NzHgtc09wdHBc3k9E6hhOIw2HLxeWjT1G/yHN/P/ALC2PinL5DOOWMTKPDwy4dTHh9X/AHTk fDeYxxjLHKQiTLiiZaCVjhr/AJqMSNfDhafRA9/Ucas8Ui7Kf/aa3Fq/6p6zaa+rWO9OnBsD z+dYNrB/Wc7a1dJ0fpxwK3utf62VeQbrB9EbfoVVf8GyVU5Pl5zyxPCRCB4pSI/d6Nrm+YhD HKIkDOY4QAf3ty67XIjXKu1yI1y2TFygWw1yI1yrtciNcopRZAWw1yI1yrtciNcoyGQFsNci Ncq4ciNcoyF4LYa5JDa5JMrVfej/AP/ZOEJJTQQGAAAAAAAHAAMAAAABAQD/4gxYSUNDX1BS T0ZJTEUAAQEAAAxITGlubwIQAABtbnRyUkdCIFhZWiAHzgACAAkABgAxAABhY3NwTVNGVAAA AABJRUMgc1JHQgAAAAAAAAAAAAAAAAAA9tYAAQAAAADTLUhQICAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABFjcHJ0AAABUAAAADNkZXNjAAABhAAA AGx3dHB0AAAB8AAAABRia3B0AAACBAAAABRyWFlaAAACGAAAABRnWFlaAAACLAAAABRiWFla AAACQAAAABRkbW5kAAACVAAAAHBkbWRkAAACxAAAAIh2dWVkAAADTAAAAIZ2aWV3AAAD1AAA ACRsdW1pAAAD+AAAABRtZWFzAAAEDAAAACR0ZWNoAAAEMAAAAAxyVFJDAAAEPAAACAxnVFJD AAAEPAAACAxiVFJDAAAEPAAACAx0ZXh0AAAAAENvcHlyaWdodCAoYykgMTk5OCBIZXdsZXR0 LVBhY2thcmQgQ29tcGFueQAAZGVzYwAAAAAAAAASc1JHQiBJRUM2MTk2Ni0yLjEAAAAAAAAA AAAAABJzUkdCIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAPNRAAEAAAABFsxYWVogAAAAAAAAAAAAAAAA AAAAAFhZWiAAAAAAAABvogAAOPUAAAOQWFlaIAAAAAAAAGKZAAC3hQAAGNpYWVogAAAAAAAA JKAAAA+EAAC2z2Rlc2MAAAAAAAAAFklFQyBodHRwOi8vd3d3LmllYy5jaAAAAAAAAAAAAAAA FklFQyBodHRwOi8vd3d3LmllYy5jaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABkZXNjAAAAAAAAAC5JRUMgNjE5NjYtMi4xIERlZmF1bHQgUkdCIGNv bG91ciBzcGFjZSAtIHNSR0IAAAAAAAAAAAAAAC5JRUMgNjE5NjYtMi4xIERlZmF1bHQgUkdC IGNvbG91ciBzcGFjZSAtIHNSR0IAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZGVzYwAAAAAAAAAs UmVmZXJlbmNlIFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAA LFJlZmVyZW5jZSBWaWV3aW5nIENvbmRpdGlvbiBpbiBJRUM2MTk2Ni0yLjEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAHZpZXcAAAAAABOk/gAUXy4AEM8UAAPtzAAEEwsAA1yeAAAAAVhZ WiAAAAAAAEwJVgBQAAAAVx/nbWVhcwAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAo8AAAAC c2lnIAAAAABDUlQgY3VydgAAAAAAAAQAAAAABQAKAA8AFAAZAB4AIwAoAC0AMgA3ADsAQABF AEoATwBUAFkAXgBjAGgAbQByAHcAfACBAIYAiwCQAJUAmgCfAKQAqQCuALIAtwC8AMEAxgDL ANAA1QDbAOAA5QDrAPAA9gD7AQEBBwENARMBGQEfASUBKwEyATgBPgFFAUwBUgFZAWABZwFu AXUBfAGDAYsBkgGaAaEBqQGxAbkBwQHJAdEB2QHhAekB8gH6AgMCDAIUAh0CJgIvAjgCQQJL AlQCXQJnAnECegKEAo4CmAKiAqwCtgLBAssC1QLgAusC9QMAAwsDFgMhAy0DOANDA08DWgNm A3IDfgOKA5YDogOuA7oDxwPTA+AD7AP5BAYEEwQgBC0EOwRIBFUEYwRxBH4EjASaBKgEtgTE BNME4QTwBP4FDQUcBSsFOgVJBVgFZwV3BYYFlgWmBbUFxQXVBeUF9gYGBhYGJwY3BkgGWQZq BnsGjAadBq8GwAbRBuMG9QcHBxkHKwc9B08HYQd0B4YHmQesB78H0gflB/gICwgfCDIIRgha CG4IggiWCKoIvgjSCOcI+wkQCSUJOglPCWQJeQmPCaQJugnPCeUJ+woRCicKPQpUCmoKgQqY Cq4KxQrcCvMLCwsiCzkLUQtpC4ALmAuwC8gL4Qv5DBIMKgxDDFwMdQyODKcMwAzZDPMNDQ0m DUANWg10DY4NqQ3DDd4N+A4TDi4OSQ5kDn8Omw62DtIO7g8JDyUPQQ9eD3oPlg+zD88P7BAJ ECYQQxBhEH4QmxC5ENcQ9RETETERTxFtEYwRqhHJEegSBxImEkUSZBKEEqMSwxLjEwMTIxND E2MTgxOkE8UT5RQGFCcUSRRqFIsUrRTOFPAVEhU0FVYVeBWbFb0V4BYDFiYWSRZsFo8WshbW FvoXHRdBF2UXiReuF9IX9xgbGEAYZRiKGK8Y1Rj6GSAZRRlrGZEZtxndGgQaKhpRGncanhrF GuwbFBs7G2MbihuyG9ocAhwqHFIcexyjHMwc9R0eHUcdcB2ZHcMd7B4WHkAeah6UHr4e6R8T Hz4faR+UH78f6iAVIEEgbCCYIMQg8CEcIUghdSGhIc4h+yInIlUigiKvIt0jCiM4I2YjlCPC I/AkHyRNJHwkqyTaJQklOCVoJZclxyX3JicmVyaHJrcm6CcYJ0kneierJ9woDSg/KHEooijU KQYpOClrKZ0p0CoCKjUqaCqbKs8rAis2K2krnSvRLAUsOSxuLKIs1y0MLUEtdi2rLeEuFi5M LoIuty7uLyQvWi+RL8cv/jA1MGwwpDDbMRIxSjGCMbox8jIqMmMymzLUMw0zRjN/M7gz8TQr NGU0njTYNRM1TTWHNcI1/TY3NnI2rjbpNyQ3YDecN9c4FDhQOIw4yDkFOUI5fzm8Ofk6Njp0 OrI67zstO2s7qjvoPCc8ZTykPOM9Ij1hPaE94D4gPmA+oD7gPyE/YT+iP+JAI0BkQKZA50Ep QWpBrEHuQjBCckK1QvdDOkN9Q8BEA0RHRIpEzkUSRVVFmkXeRiJGZ0arRvBHNUd7R8BIBUhL SJFI10kdSWNJqUnwSjdKfUrESwxLU0uaS+JMKkxyTLpNAk1KTZNN3E4lTm5Ot08AT0lPk0/d UCdQcVC7UQZRUFGbUeZSMVJ8UsdTE1NfU6pT9lRCVI9U21UoVXVVwlYPVlxWqVb3V0RXklfg WC9YfVjLWRpZaVm4WgdaVlqmWvVbRVuVW+VcNVyGXNZdJ114XcleGl5sXr1fD19hX7NgBWBX YKpg/GFPYaJh9WJJYpxi8GNDY5dj62RAZJRk6WU9ZZJl52Y9ZpJm6Gc9Z5Nn6Wg/aJZo7GlD aZpp8WpIap9q92tPa6dr/2xXbK9tCG1gbbluEm5rbsRvHm94b9FwK3CGcOBxOnGVcfByS3Km cwFzXXO4dBR0cHTMdSh1hXXhdj52m3b4d1Z3s3gReG54zHkqeYl553pGeqV7BHtje8J8IXyB fOF9QX2hfgF+Yn7CfyN/hH/lgEeAqIEKgWuBzYIwgpKC9INXg7qEHYSAhOOFR4Wrhg6GcobX hzuHn4gEiGmIzokziZmJ/opkisqLMIuWi/yMY4zKjTGNmI3/jmaOzo82j56QBpBukNaRP5Go khGSepLjk02TtpQglIqU9JVflcmWNJaflwqXdZfgmEyYuJkkmZCZ/JpomtWbQpuvnByciZz3 nWSd0p5Anq6fHZ+Ln/qgaaDYoUehtqImopajBqN2o+akVqTHpTilqaYapoum/adup+CoUqjE qTepqaocqo+rAqt1q+msXKzQrUStuK4trqGvFq+LsACwdbDqsWCx1rJLssKzOLOutCW0nLUT tYq2AbZ5tvC3aLfguFm40blKucK6O7q1uy67p7whvJu9Fb2Pvgq+hL7/v3q/9cBwwOzBZ8Hj wl/C28NYw9TEUcTOxUvFyMZGxsPHQce/yD3IvMk6ybnKOMq3yzbLtsw1zLXNNc21zjbOts83 z7jQOdC60TzRvtI/0sHTRNPG1EnUy9VO1dHWVdbY11zX4Nhk2OjZbNnx2nba+9uA3AXcit0Q 3ZbeHN6i3ynfr+A24L3hROHM4lPi2+Nj4+vkc+T85YTmDeaW5x/nqegy6LzpRunQ6lvq5etw 6/vshu0R7ZzuKO6070DvzPBY8OXxcvH/8ozzGfOn9DT0wvVQ9d72bfb794r4Gfio+Tj5x/pX +uf7d/wH/Jj9Kf26/kv+3P9t/////gAmRmlsZSB3cml0dGVuIGJ5IEFkb2JlIFBob3Rvc2hv cKggNS4w/+4ADkFkb2JlAGQAAAAAAf/bAIQACgcHBwgHCggICg8KCAoPEg0KCg0SFBAQEhAQ FBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAELDAwVExUiGBgiFA4ODhQU Dg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgB 6gHGAwERAAIRAQMRAf/dAAQAOf/EAaIAAAAHAQEBAQEAAAAAAAAAAAQFAwIGAQAHCAkKCwEA AgIDAQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAACAQMDAgQCBgcDBAIGAnMBAgMRBAAFIRIx QVEGE2EicYEUMpGhBxWxQiPBUtHhMxZi8CRygvElQzRTkqKyY3PCNUQnk6OzNhdUZHTD0uII JoMJChgZhJRFRqS0VtNVKBry4/PE1OT0ZXWFlaW1xdXl9WZ2hpamtsbW5vY3R1dnd4eXp7fH 1+f3OEhYaHiImKi4yNjo+Ck5SVlpeYmZqbnJ2en5KjpKWmp6ipqqusra6voRAAICAQIDBQUE BQYECAMDbQEAAhEDBCESMUEFURNhIgZxgZEyobHwFMHR4SNCFVJicvEzJDRDghaSUyWiY7LC B3PSNeJEgxdUkwgJChgZJjZFGidkdFU38qOzwygp0+PzhJSktMTU5PRldYWVpbXF1eX1RlZm doaWprbG1ub2R1dnd4eXp7fH1+f3OEhYaHiImKi4yNjo+DlJWWl5iZmpucnZ6fkqOkpaanqK mqq6ytrq+v/aAAwDAQACEQMRAD8AnVTXNs6tsE4q3U4Et1xVdXAlupwK3U4pbBOBWwcUt1wJ brirdcCVwOBW64pbrgVuuKWwcCt1xS3XArdcUtg4FXVwK6uKW64Et1xVdXAlsHFW64FdXFLd cCt1xS3XArdcUt4FbrireKXYFbxS3irsCt4q3gS3irsVbxV2BLeKuxV2KuxV2KuxV2KuxV2K uxV2Kv8A/9Cc13zbuqbBxS2MCt4Etg4q3gS3ireBK4HArYOKW64FbxS3gVsHFK7AlvArdcUt g4FbxVvAlvFLdcCt4Et1xVuuBWxilvAluuKt4FbxS3gVuuKW8Ct4pbwK3XFXYpbwK3ilvFXY FbxVvFLsCt4q3irsCW8VdirsVdirsVdirsVdirsVdir/AP/RnHfNw6p1cCrsVbBwJbwJbBxV vAluuKt4Etg4FXDFLeBW8Ut1wK2DildXAreBLdcVbBwJbxVvAlvFLYOBW8Ct4pbwK2MUt4Et 4q3gVvFLeBW8Ut4q3gS3gVuuKuxS3gVvFLeKuwK3ireKXYFbxVvFXYEt4q7FXYq7FXYq7FXY q7FXYq//0pt3zcOpbxS2DgVuuKrgcCW8CWwcVbBwJbxVvAluuBVwOKWxgVvFLeBWwcUt1wK3 gSuGKt1wJbxVvAlvFLdcCt4FbxShrvVNOslL3d1FAB19R1U/cTkTIBIYpqv5o6Ja1SwR76Qd 1+CP/g2/5pys5O4MhFil/wDmd5luyVtBHaqfsrEvqP8A8E1f+I5G5FkIhLLnV/zBmjMzSaj6 Q3LhXjQV91VFwUVNJJH5k8ysxkXUrpadW9V/+asFKzLyl+atxYsLLX3e6t2cUvdi8Snb94oH 72Nftf78yQlSKewRSxyxrJGweNwGR1NQVIqrA5YhfilvFW8Ct4pdgVvFW64Et4q3il2BW8Vb wJdireKt4q7AreKXYq7FXYq7FXYq7FXYq//Tmtd83LqG8CW8VbrgS2Diq6uBLdcCWwcVbBwJ bBxVvAluuKrgcCWwcCt4pbwK2DilsYFbxS3XAq4HAluuKtjAlBajrWl6XGZL65jhA7MfiPyQ fFkJTA5pAtiuo/mnpMKkWFvLdP2Zh6afe1X/AOFyBydwZiDFL3zz5r1mUwWbtCjbCG0Qlv8A kZu2VkksxEBuz/LzzTqDercIsHI1Ml05Z9+/BebYRjUyDLNL/KvSoaPqc73j9fTX93HX6Pib LBBjxMusNH0rTkCWVpFAB3VRX/gvtYaRbzX82PNswkGgWblEI5XjqaVWtPT2/mplUzZpMRbz ON3mAi5cIR17ZFnybITkVgHIDq3bGlL078v/AMx7aytItF12TisRSKyuQtVCfZEU9Ps+n+xJ /JkhJjT1kHJobxS3XFW8CW8VdgVvFWwcCW8VbxS7AreKuxS3gVvFW8VdgS3irsVdirsVdirs Vdir/9SaV3zcuobBxVvAlvFW64Et1xVdXAlvAreKWwcCWwcVbwJbxVsYErgcCt4pbwK3XFLY wK3ilsYFSrXPM2laFEGvZf3r/wB3Am7t/scrnMRZAW871b8x9cv2MFgos43NEWMc5iP9b/ml coM5H+i2xgFml+QPMerSfWL4m1jfcy3BLymv/Ff/ADVhjjSZAMu0/wDLHQbch7t5b1h1VzxS v+on/NeWDGGPGyuy0+xsIhFZ28cEY7IoXJ1TEm0VXFDeBLeKvIvzR8pXEd5Jr8R52s3FJh3R t6f7B2yqUWcS8zdCCQfs98rZoiKWoEMS0BPxOcVXOiqxSP427tirO/I35j3OlT/UddnefTnA EczVd4GBp/rNBx+1/vvCDTGntEciSIsiMGRwGVhuCDuCMsQvxS3ireBXYpbwK3ireBLeKt4p dgVvFXYpbwK3ireKuwK7FLeKuxV2KuxV2Kv/1Zn3Obp07sUrgcCt4Et1xVvAluuKtg4ErsVb wJbBwJbrireBWwcUt1wJXVxVvAlvArYOKW64FYZ5088x6VG1jpsiyak2zv8AaWIeLf5f+TlG TJ0DZGNsL0Ly3rfmu6N3LK4tyf31/NVi3+RBX7f/ABBcrjC2wkB6novlbRdGiQWturTqKNcy ANKx8S5/41y8QAazIlOa5Ji3gS3ireBLdcVbwJU7q1t7y3ktrqNZoJRxkjcVBGAhXjfnvyDc aXPcX1jFXRzRwVqTDUBZFfq3p8viV8rlFsBtgMkbxsQNhkE2rQytxEUY3OxY4EtyqkbcE/eS ftEb4q9A/Lbz1Jp1ydL1u7I014wLWSY1ELJRVj5fswun/IvhkommJeyI6OqujBkYAqwNQQeh ByaF+KWwcVbwK7FLeBW8VbGBLeKt4pdgVvFXYpbwK3ireKuwJdireKuxV2KuxV//1pl3zdun dgVuuKVwOBW8CW8VbwJbBxVsHAldXFXVwJXA4Etg4q3gVvFKUav5r0PR2Md7cBZgK+igLPv0 +EZTPLGJpnGBLFr782rRarYWLyeDysFH/Aryyk5z0DYMfeUjuPzS8xSE+ksMI9kLf8SOV+JM 9WfBFQH5meaq19aMjw9NceOXenhiq/8AK0fMRgeFxCS6lfUCkMK7chRuOJyS70GAY5pk2nHU oJNW9WSy5l7oR0MjmhO9Sv2n+3gjQZHye2aB5p8talGlrpk6RmNQqWrD0mCjsiN9r/YZkRyR OzSYkJ8DljFvAldXFW8CW8VbrgS2DireBLTokiNHIodHBVlIqCDsQRiryf8AMLyGLNZNW0uJ U02KNTcwKSWRg3FpUX/ffFl5/wAmVSDYC8ykR42IGwyDIK0M8ccfpxrylbv2GKtvD6VDIeTt 0XArPfIf5jzaT6Wmay9dIROEEoWrw0+wp4/E8P7P/FeESpgQ9jtbq3vLeO6tZFlt5VDRyIaq wPcZYqvilsHFW8CuxS3gVvFW8Ut4FdilvAreKuxS3gVvFW8VdgV2KW8VdirsVf/XmNd83bpn YpbwK3ilcDgVvFLeBW8CWxireBLeKt4ErgcVbrgS8985fmGbZ5NN0VgZVqk951Ct3SDszr+1 JmLky9A3Qx9S80mnlmkaWVzJK5JZ2JJJPck5jN6zvirsVditN1xQ7FK5WKkEEgjoQaEYkKGd +VvzMvNP9Kz1gG5sqhRdV/exg7fH/v5F/wCRmWQyEc2MoXyetxyJIiyRsGRwGVhuCDuCDmS0 r8CWwcVXYEt4q3XAlsHFW8CWpI45Y2ikUPG4KujCoIOxUjFXj3nr8v7qzuZ73S4C2lcfVKJu YSo/eqR9r0vh9RcqlFsBedMrQv8AD9rxytkrwzRpV5QZJD0GKV7ROy+rJ8CnouKGY+QfP1zo k0Gl3XE6LJKeTsKNCZDu6N/vvn8TLhBpiQ9ttLy1vbdLm0mSe3kFUljIZT9IywG0K+Kt1xS3 gV2KW8Ct4q3ilvArsUt4FbxV2KW8Ct4q3irsCuxS3irsVf/Ql/fN46ZsHAreKW8Ct4pXA4Fb xS3gVuuKW64FbBwJbxVuuBLGfP8Arj6ToLLA5ju7xvRiZftKv2pXHyT4eX875TmlUWzHGy8Y zBcprfFDsUl2KuxVvFXYq4HFWwcVeoflR5hmk9fQLmQuIU9axLdRHXjLDX+WNirJ/r5fil0a 5jq9Ky5rbxS2DgVvAlvFW8CVwOKt4EtOiyIyOAyMCrKehB2IxV5H59/L5rJ4rnRLZnsXUrNE tXaNwaq3dvTZPhyqUWyMnmroYmr1ruD2p2ytkiIJFkblcv8AAvRcVK5g8xJQcYh3xVk/kjz1 P5Xle2kT6xpk7q8yV+KM/ZeWH9n7P20/b4YQaYkPebe4huYkmgdZInAZXU1BBFe2WIVcVbri lvArsUt4FbxVvFLeBXYpbwK3irsUt4FbxVvFXYFdilvFX//Rl3c5vHSt4pbrgVvFLYwK3ils HAq7FLdcCt4pbGBW8CW8VeWfmtd+prFnaDpbwGQ/OVqf8RgzC1B3pycI2YL1zHbnYq7FXYq7 FXYq79eKtjFQ3illP5buU842QH7STKfl6bN/xrlmP6mE+T3DMppbrgVvFLYOBW8CV2KuwJXA 4q3gS3iryvz5+Xnoqt9oVuzo7ubmBd+HL4leFP8AffPlyXKpRbBJ5ZPA8EhSTZlJBXuCDQj7 8gytVSeWVVhLcIf2sCV7hCeFsOXi2LFk3knzpN5VupUmRrmxuAPVgVqFXB/vo67cuHwsv7eE GkEPeLK8gvrSG8t25wXCLJE3irjkuWIRGKt1xS3gV2KW8Ct4q3ilvArsUt4FbxV2KW8Ct4q3 irsCuxS//9KW983rpW8Ct1xVsYEt4pbwK3ilsHAq7FLeBW8Utg4FbGBLxHzvdi680ahIDVUc Qj/nkqxN/wAOrZrspuRczGKikGVsy3itOxS7FDsVdil2KuxQ2K4qzD8toAPMEV6+yoTEnzcf FlmPm1zPR7SDmU1N4pbwK3ilppERWZ2AVRViewwEqxy1/MLy1dakdPjmYSElUlZeMbMv7CMT 9o/s8sqGUWyMaCTp+beknVEtjautiz+m14WHw78fUMVP7vl/lZHxd+TLh2V9V/NbRrDUDaRW 8l3FG3Ga4jK0Hj6QP97icm6iNhkFz5x8s2sME9xqESJcossNSSSjjkjlVHJf9lkjMBRElOIJ 4biFJ4HWSGRQ0ciGqsp3DKwySFXFXmP5g/l/EY73XtP5PKzCWa0C1+0QJpUb/krxyqUerMSe SyxSRMQ/w+2QZq0F0yqYowAW2LHAq90SKgB5yNvtirJPJnnO+8s3oM5efTJAVmtQ1afyyRBv suv/AA+EGmJD3fTNRtNTsYL+zcSW1woeNh4Hsf8AKX7LZYEIrFWwcUt4FbxS3gVvFW8Ut4Fd ilvAreKuxS3gVvFXYq3ir//Tlld83rpG8Ut4q3gVuuKW8CW8Ct4pbBwK3ildXAreKWmcIjMe igk/RgV8+Xlw91dT3Mh+OeRpGPu5Lt/xLNUTZdgBso4Fdil2KHYpdvirsUN4q13xWmzUCuKW feWYDafo9F+280XI96u6lv8Ahcsjzccm3rOZbBcDgSslmSGNpHOyDkQOuAmksCh/M+31HUP0 bFCbVJn9GG7Zhs9eI57fBzb4OWYxykthhQYFY+YNZ07U3urqaWUxzNHqEDMfjVWKSIwP7Sf7 rysMyL2SZuQtfWQkENUMOvWoxZBq4UrZxsBQsaVxSGroNHBEBsXwqunQxQIKFn4gn2X7I/HA VTex81+ZNH02Oxs794LdGLRxqFNCxqwDMrNw5fs42UU9G8lfmVZ3OmCLzFdpDfxyemszDiJU I5JI3EcE/kfLIz72Jj3PQY5IpolkjZZIpAGV1IKsp7gjrlrB515//L6G5W71zT/hkWP1JrRV rzKChaIL+2Yx9nK5RZxk8glikiboVHY5U2KlvcJECSvOQ+OKCqtCQvrTGpbcLiUMn8kedb3Q b+CK4lkOhsWE1v8AaC86t6sS/st6n2sYmkEPctM1Ox1WyjvrCUTW0o+Fx4jqrD9ll/ly0IRe Ktg4pbwK3ilvAreKt4pbwK7FLeBW8VdireBLeKuxV//UlffN86RsHFW8CW8VbwK2DgS3ilvA reKWwcCt4qurgSl/mC8+paJfXO1Y4X41/mI4r/wxyGQ1Esoiy8H/AF5q3PaxV2KuxV2KHU+7 ClunfArqYq6n3YpVbeMyXEUfUFhX5d8IYSL0Hy+GuNcs4l3WBwx/1vtf8KgyyPNoeoZloY3r Xn3QNJupLCaV2vEHxKiFgpIqvJth/wADlEsoGzYIEh4/da3qZ1ue5F67y+qzQy8iVK8uUfwn 9j/IzFpuqw6+Fvc6i1xGghW++KaAdI5z/e+n/wAVO372LDSjksecy3l0bs/vpFBZv5nCheR/ yn4/FhTSDSf/AEGS3I35VriyWTSvJbRR02Q1GJQ64laRoVYfYFF+WKV7XLSXFGJEZCK48VTc D/gvixQVVHF3czKqgQsBuf2VQ89v9YjFSpSL65IiIojAU8RT7WBeTL/Kv5k3nly1t9Lmt0ud OhZuRUkSqrsXbh+w3Dk3wZISIYmNvboJ4riFJoWDxSKGVhuCGFRl7Wwfz75A/TTR3+nKkdxE jCaIDj6gHxoV4j+9ryXK5RZxk8UkieJieJA7VFD9OVWzVLeWMP6k55U6LitKxjkmUzN8EI6Y qn/lHzrqPl26SKBuemPKHuoGFQa8UeRG+0rqi4g0xIe86bqunapbi50+4S5gJpzjNaHwb+XL QbQi8VbrilvAreKW8CtjFW8Ut4FdilvAreKuxVvAl2Kv/9WVHqc3zo264pbrireBLeKt4FbB xS3XAlvAreKtg4Et4qxP8ybwQ+XxB+1czIo+S/vG/wCI5jak1Fvwi5PJfbMBy3dsVdirqYqA 6mK03irqdsVapitNjFSibAH1jJ/KMkGEnpH5eWc0lw13KNkBYk9eT/Cv/C5diG7VJOvO/nGT yzBbmG2FxPcsQvNiqqFFeRoPiyWXIY8mWOHE8d1W/n1e+k1FkCzSU5otafCOO1cxW8Ctlnor PbmZTxmi6jFktuLkTJFIg4yx/ap7YVa9OW4kWRQSWNDTGkMw0b8s9YvTHLPxt7WcB+bbsFb/ AIr/AJssGMlgZhPofyhh9F0mv/jH90VTao6c6nJeEx8RTu/ykdYFkgvBJcJWqlaAg/y/5WPh pE2K6t5I1TT2d/SMsRBbmo6UHxBl6rTKzFnd8mNMkkKEA0LbHIpVIphDB6Ma1lk6sewwLS+W BLVFD/FM4rTvQ+OK0nvknzTdeXNXjmuZZP0VKCt1AKuKUPpyIhP20fj/ALDDE0USFvd9N1Ky 1SyivrGUTWsw5RyL9xB8GU/ay8G2ph/nr8vxrSx3OlLHDdKW9ePZBJy351/34jZCUbZxk8Vv bOS0upYJB8ULtG48GQlH/wCGXKmx0c7S0jkbjEO2Kq5pJ8FsPgHVjiik58q+bL3ytfSS2wE6 TKFnt2JCtQ1DCn2ZB/PiDSCHvWiaxaa1plvqNof3U6BuBI5If2o3p+0jfDloNsUwxVuuKW8C t4pbwK3ireKXYFbxS3gV2Kt4q3gS/wD/1pT3Ob90bsVXVwJbxVvAlvFW8Ct1xS3XAlvFWxgV vAl5v+aV5yurGyBFI0aVh3q54L+EbZhao7gOVgHMsDzEb28VapilumKupirqYq7vitupilpt hiqItlb4QvVzTJMC9s8r2baboKySCszqZnHelPgX/gcyoCo20HcvJfNnmrUtdvGivAsdtbSO LeJVoRQlOTN9pmzElIyO7lRgANkphikjpLF8aD7S4q3cunqepBsGHxL+vFknflfyne63dL6a EWZP76cj4V8f9Zv8nJRiS1mVPWfL/k7R9EjYRR+vM1KyygE0HQKP2cyIwAaTMlPxk0LsCt4p cVVgQwBBFCD4YFec+c/y8hNvHc6FbnkrN9YgBLEqw+Foq/yNlM4dzbGd83lk9u9vIxI+JSRT wIPGn0HKmxu2liVjPdVd+w71xSVzQyyqZpPgjPQYEMq/L3ztLoN7Hpc1H0m8mAYn7UUj0T1V /wCK2PH1E/2eSjKmMovcwQRUdMva2GedPIthqWnXVzp1qqaqzCQspI9Tesq8fs8nX/h8hKLM SeL6vo17pU4t7yJopSORVtjQ9Mqqmy0PBPKB6UZ4hup74oIV5BFHRIqPKftHAqdeUPMtz5Z1 ZLty8lq4KXNspoHUj4TRvh5o3xLiNmJD3zSdVs9X06DUbJ+dtcLyQnqOzKw7OjfC2WjdCNxV uuKWxgVvFLeKt1wK7FLdcCt4pbwK7FW8Vf/XlFdznQOibwJdiq4HAlvFW8Ct4pbwK3XFLYOB W8Ut4FeO+erg3Hmi73qsXCJfbiq1/wCHZs1mc3MufhHpY/TKmxxHbAtt0xQ7jiktgVxS6gxV 1MUOpilad2GFU58s6bNqGsW1sgqpceofBR8Tn/gclEWWuRoPWPOOr3mjaBNd2KA3C0SMkVVa 7ciuZWWRA2acYBO7wp5zPcSS3J5SSMWdunxHr06ZhOYjoopIY/Wt3qh+0pwoVNHsW1TWLWzQ Ua4lVD8q8n/4GMPhiLLGRoPfdO0+0060jtLOMRwRj4VHj3J98zQKcUlFVxVsHFK7AreBLeKW wcCvP/PnkcXMf6Q0e25XLyFruJP2gwJMqL/Pz+3lU4dQ2xl0LyS4t2hmYMPsEgjwI2IylsVo nNyw+sScIE/Z7YqtkHqkiBKRjbkR1wKz/wDLjz1a6VH+g9Xkf05Zq2lyfiVOdF9KT9pU9T7G ThOtmEo9XrwOXMGI+fPJ8Ot2cl9AhbVLeI+kg6SBasIj/lfyZCUWUS8Lu7O4tZGWVDG1SOLC hHzByptdb3IiFEUNI3c9sUEK0luIlEk7VkbcL1wUrI/I/m+88v6lEJpXGjytS6gNWADf7ujX 9l1b+X7eEGmJHc9103U7HVLKO+sJRPay14SLXsaMCDurKcsBtCLxVvFLeKt4Et4q3gV2KW8C t4pbxV2BX//Qk56nOgdE3XFXYEt4q2DgS3iq7ArsUt4FXYpbBwK4sFUsegFSflgS8I1K7a+1 K6uzv68ruPkzfD/wuaiRskuxiKFKHGuRZU6mKlum+Kt0wBXcaYUt0xV1PHFXHYVxVZGvJsKC 9M/LLRpIo5tVmUj1B6dvUdRX944/4hmTgj1aMpVfzTvr6LSorSH4be4Yeu/iBvwrgzk8k4QH k8ToG+JajMZyaRzLB6QaGTiT1TDSN2U/lhp63PmA3MikrZxGRWHQSMfTXl/sPUy7EN2nIXsI zJaG8Ut4FbrildXArq4Erq4q3XAl5Z+YXk2O1aTV7NS0NzKTcRAVEbOC3qf6kkv/ABPKJwrd tibeaywsj0avEdRlbMIyGZ7pVtoVEajdnPU4pCHniiRjElXbuwwK9f8Ay287tqludJ1edRqc JAtnY0aeOh/4KWLj8eWwl0LXKNPQMsYsL89+Rv08w1C2kEdzbwsrRFa+pxrIgqOj7suVyizi Xh8sLwsWoV32BFCPnlTYvtpo1f1Z6yEbBcQFKq6STD1mHCPsMUMm8l+e7zy7OloKTaVLKGnj P2l5UR5I3/yft8cYkhgQ97R1dQykMrCoI3BBy5V2BW8Ut4q3gS3ireBXYq3gS3ireKX/0ZMT uc6F0LsCW64quwK7FLeBWxilvAreKW8Ct4pSzzNeNZaDfXCtxcRFUJ/mf92v/EsqzSqJLOAs h4rGM1LsV+KruP34pLqYotumKXUxQ3TGk21xxVZJsAMUq9hZyXUscEQrJMwjQe7GmTAayXu+ mWaWFhb2cf2YEVK+JA+Jv9k2bAChTiE2Xn/5rXV+zW9mDxsf7w7D4mHT4sxM5N05GEB51DKV b7HIZQ5FIqeSB1FIyhpvtgRu9C/KJKJqkgYbtCpTvUB25f7LlmTg6uPlekg5kNTeBW8Ut4Fb BxS3XAreBK7FWmVXUo4DI2xUioIwJeNeefJx0aX6yjepZXUjiIjqh/vBE/8Aw3D/AFMx5Rpu jK2FHmjcQSq9D2yDNFLJGYxDbJWQ/bc4FrvWxSTadeQXkT8bq2kWWI+DIeQ2xXm928k+bo/N GmPcNEILy3f07mEGoBI5I6d+Drl8ZW1EUyTJIYD5+8hrqSC/0qJEmQObqIfD6laMJF/Z5pxy uUWcZd7xd0CNyG6UBU+xytsRFuzXBpM/GJe3QYq6SjMUtxVB+144EF6F+W/nlNMddE1SRmtp 5FFpMTURM3w+m1f91u/H/UyUZUwIexZYreBW8Ut1xVvAreKXYFbxVvAlvFX/0pKepzoXQuxV vAluuKt4FbxS2DgVvFLeBW8Ut1wKw78y730tJt7QfauZeRHfjEOR/wCGZMxNUfSA5OnG9vOI h8PzzXuYvpilsD7vHFDqe22KuoMUt8RirqYodQnfFVBvieg7nCln35eaMJL9r6RapaLROh/e P7H+VcycMd7cbJLZ6VmU0POfzV+uOtqlKWY+Ll25b1zDz3blYap5xDJIr/AtfnlDkIyY3TIC 8YC02xQzv8pJx62pwFaOVikDe3xpxzIwHm4+UPS65ktLdcCV1cCt4pbwK2DilsHAreKW8CqV 5Z2t7bvbXUaywuPiRhUfPARaQaeF+Z/LGoaNOI7sDi5b0ZQRSRUI+ID9n7Sc8xSCG+J7mPxz SwMUi+FjsW8K4GaJKwJGDy9W4bqvWmBG6to2qX+iarbalCxQxOpljBoJI6/vIm/1kw8jand7 75e8xab5h08X2nuTGGKSI44ujgBijj5Nl8ZW0kUmvzwq8r/MbyNHDFHfaNan02Z/rcabhSaG NkT9lPt8sqnFsjK3lkkZSTg3QZWzRcdw8iLbwIBXYt3xVbJEkBoTylxQ9b/LTzvPfLNpmtXS eunD6lJKQryBuQaL/LaPiv8AweTiWBFPScmreKt4Et1xVvAreKXYFbxVvFL/AP/Tkh650ToH Yq3gS3gS2DireBW8Utg4FbxS3gVvFLzX8zbpZNTs7UdYYi7H3kb+kea7Vn1AObphsSxaNPhG YjkL6diMUOpimnUxS6m+BWwMK06mK25hRScVVtC0u41XVI7S3ALkF2J2AVf2mOThEyNMckqD 2Dy5pP6K04QMweV2MkhHTkQFovT9lcz8cOEOHKVlNwcmxYd+ZcF1NosfpCsCyAzECtOyHMXU A0HIwc3kYLh6J9+Yrko8RXbwcnlHHwwpTbyHfHT/ADTaVk4x3JNvKexDj92G/wCeqpxyeM1J qyCw9tzNcRuuKW8CVwOBW8Ut1wK3XFLeBW8Ut1wKlPmPy5Z6/apDcEpJCS0Ei9QSKEH/ACWy Eo2zjKnheq6Xd2c7xTxGKZDR0PYj/iX+TmOQ3oK2uFtnrw5ydq9K4EK89s5T6xcNTnuFwJvu T7yL5wufL2opbGh0m7mUXQYUKFqR+ur/AOR8PP8AyMlGVFjKNvd0kSRFdGDIwqrKagg9wRl7 Uv2IoemKXiPn3yQuhPHc27+ra3TuEHGhjp8axsf8qvwZTKNNsTbB1MkL0GzeORZBFRm3SMsx 5zHoO+BSs4z1EhPAA1UjqCOhrixL3byF51t/MVobWQGPUbSNPWBNfUH2PWT/AGQ+PLIm2HJl +SS3ireBLeKt4FbxS7AreKv/1JFXc50ToG8VbxVvAlvFLYOBW8Ct4pbGBW8Ut1wK8a813hvf Ml7JWqpJ6K/KIen/AMSXNRmlcy7LEKiEMuw6ZUzBXYpdTFXEYpapihv6MVdTFKyXYU8euKhm f5YafzuL3UW/YUQIPd/jY/8AC5l6aPMuPnPR6QNhQZluM3XFUt8yW1zd6HeW9sOUzpQKOrCv xKP9ZcqygmJpsxkCW7wy8heCYxUIdT8QO1D4Zr3OVbSKNx+/lKjwritrTIkMyyW7EPGwZH8G U1VsCl7l5X1wa5o8N8V9OY1jnjHQSIeL8f8AJb7a5n45cQtwpxopvk0N4q3XAlcDgVvFLeBW 8Utg4FbxS3XArGPOXlJNdiS5ibheW6Mo8HU0bg3+VyX4MqnC92yMqeIXMJjYsoI3rv1rlBbl 9s8LEyXjlgo+FffFNrXEk1WReEXavhgV6X+V3nKBIovLN+7etyYWEp3UrTn9XJ/ZZfj9LLIS 6Nc49XqNcua1C9sbO/gNteQrPC25RxUVHfIkWkGnhfnTynd6Pf3EjRkWTyn6rL+ywarogP8A Mi/8Qykim4G2KwyCJ+RFSMCaRoWa9BeQ8Y1HQbYKQqadq9/o959Y0qZoJwOPqLQ1B34uDUMm KkPffKnmey17TIJUnRr8RKbyBdmR6Uf4D+zzy0G2tPsKWxireBLYxVvArsUt4Ff/1ZCepzo3 n264q3gS3ireBLeKt1wJbwK3ilsHFUPqN2tlYXN2xoII3k38VBIyE5UCWURZp4gjNLOXY1Zi WY+53zSO1Rg6YFbA8cKG9u2BLgKHCh1MCbbAwq6nbFbUZzufbFIet+SLA2Ply1VhSScGd+x/ ebrX/nnwzZYY1FwcsrkyDLWtvAlsHFXkHnjRLnT9SmuJByju5HkgkqN60Zww/wAjlmuyQILn Y5WGKxhEblLv7ZW2lHtIbhONvDQDqcKE68leYU8v6m312RhY3ClZlX4grinCXh/k/Zbjksc+ E7sMkLD2KCeK4hSeFxJDKoeN13BUiqsMzgbcNVxVvFLYwJXVxVvAlvArYxS3XAreKW8CvN/z F8qSvIdUsYQLURMbxUoOLKefrEf5S/bzHnDew3Qlezy54/Rlq42BytsCKQy31F2jhQfLFbUe RgmWS1ZhNEwaOVDQqy7qyt4jAtPZfy886Jq9jHYancL+m4yyhW2aaNfiWVf2S3H7f+pl0JXs 1SjTN65YxS3X9CtNd05rG6qoqHjkHVHXowyJFsgaeBeYtEm0vVLmzdSPq7lQxFOSdUkH+uuU EbtqVRuzMEdqIOowJRbvGQsdqvM/tHFFIvQdXufL+r2+qR0eSAnlETxDKwKsjUxukEW+gPLf mC08waVFqVqCquSskTfaR12dDloNsE1wq3ilvAlsYq3gV2KX/9aQHqc6R592BVwOKtg4Et4q 3gS2MVbBwJbxVvAljvny59Dy1cKDQzskQ+lgzf8ACpmNqjUG/ALk8ss1qzN4ZqnYlGUwIbHj hQ2BTArdMUU6nbFW6Dv0wpbAxVSigN1dw2w29eRIwf8AXYL/ABwgWaSTQe5RIsUaRr9lFCr8 gKZt6daqYpbwK3gSkXmvy7+nLSNUkEc9uWZCwqCGFHQ/dlObGZDZtxT4S8ZuISJC5FAOx7ds wHNX291Ow9GKiq3c4qqXFvHBuz+pIfDfFdyzXyB5wNtx0jU5FS0A/wBEnc04Gv8Acuf5D/uv LsWWtifS05Md7h6cCCAQag9DmY4zeBW8Ut4FbBxSuwJbwK3XFLYOBW8UqV3bRXdrNazjlDOj RyDxVxxbIkWkGnjHnPyk+i3SIjNLBMpeOWlBUHiUb/KXMaUabwbYiQ4biSQnf3yDNGCWJ41h tYyZP2nPTFDVnc3OkajbahC4+s2siyIDWhp9pGp+y6/BjdLVvd/J/mqDzNpZvEiME0TmK4hJ rxYANVG/aRlbMiMrDSRTIAckhIfN/lyPW9IuIoYo/wBIFV9CZgAfhYNw5/5ajhkJRtnE08G1 rRrrSrx7W5Qxzx05oe3Icl/4XKabUNb3TQjgigse+BFK0luFX1Z2DM2/HFU78m+ar3QtWgZJ GXTZJAt3Ca8CjfC0nH+eP7eINFjIPfrK+tL+3S6s5knt3+zIhqDlwNsURireKW8Ct4pbwK// 1z89TnSPPOxVvAlcDireBLeKt4Et4q3XAlvFWBfmbe7WVgP8qd/o/dp/xKTNfrJcg5uljzLD bJPgJ8cwC5ZRNMCHYruupihsCmK04DfbCrZG/jimnHZcVpMPKFmLzzLaK32ISZ2/557r/wAO Vy3BG5hjmlUXrubRwGwcCrsUt4FbxS858/8AlyC39O9s4SsU7v8AWqbqHPxRtT9nm3PMHNAR Nhy8U75vP5FeJ+C7EdTlDkBEW8ltEC0oLyHoMC83SRSyD1H+BD0Htih6J5F87Ncy2+h3qDkq enbXIP2uA+GOQH9vgv2syMWQ8i4+SA5h6DmU0N4FbxS3gVsHFLeBLeBV1cVbBwJbxShdT022 1OyltLhQVkUhWoCVYigdP8pcjKNhINPDvNHlu70a7+r3JBZl5qy7hlqV5feMxSCHIBB5JHDc SwvwioCduXhgSiJIIoohLI/OVv2e+A7KN0w8reY77y/q0N1E7JYu6rew9VeM/CzcP9+Rr8SY QaNoIt79Y31rf2kV5Zyia2mXlFIvQg5kg20okHFWF+fvJ9tqVncarAjHUYYq8F3EgTxX+dUy uUerOJ6PEbiF4HNNt9spbF9uYiedwxIHQY0q92eZiIV4oO5xXZnH5dedbXy96mm6iG+qXUod Z1O0TEBGLr/vtuK/ZwxlTEh7SCCAQag7gjLmK7AreKW8Curil//QPq7nOleddilvAreBK4HF W8CW8VbwJbrirYOBLyHzrefXPMd0Q1UgpAngOA+P/koXzTaiVzLs8EagELbpSNfxyi2wq3E9 MaRbfE4q6mKtldsKtgYEuC+OFC2b4QMUhlv5a2hNxf3pAoAsKHvUn1H/AONMzdLHmXH1B5Bn +Zjit4pbBwKuxS3gVzKrqVcBlPUEVGAi0gvJ/NXlO806S5u1UPZNKzRuv7PqtVI2XtxZuGa+ eMxc6EwWI8fRarbntlbai4me6I9aThGvQVpgpVjuVkH1UEcDVZFqCCO4YYop6h5H84Q3lvDp WoTk6mtVjkk/3ao+yOf+/eOZOLL0LjZMdbhm2ZLS2MCt4pbBwK3XFLeBLdcVbwKuBwJbxSkv mby7aa1ZPzjreRRv9WcGh5EVVG/yGfK5xtnGVPDNR0+4s5mjniaKZftIwIIPfMYt4ULSWCJi 0wLt2HvgVfLFNKPVYcI+2KSzT8t/Op0u4g8v3YDWFxKRBOTvFJJ0Q9vSd/8Ah3ycJVs1zj1e x5e1rsVeY/mN5Muri7fVrGJTbCEfWFSi8PT5Mz8f2uSnKZxbYl5OyhJPi6DK2aLS4mnUQwqF H83fFC2W3WLaVqseuKvX/wAs/O82rD9C3wBuLaENbzD9uNKIyv8A8WJ8H+vk4SYEU9EGWIbw K6uKW8Cv/9E8PU50zzrYOBW8Ut4FbwJbBxVdgS3ireBKy4mEFvLO26xIzkeyjlkZGhaQLLw5 5JLm6aWTeSVy7fNjyP680R3dxVBNVWigeGRYUu4mnyxS6hrt3woDdPpwMrbAFMUNU3/DFOxX gYrShcNufbCyAekeQrYweXonIAa4keU+4rwWv+xTNnp41BwM5uTJMvam8Ct4pbBwKuxVvAlQ vrKC/tJbS4HKKUUbxHdWHurZGceIUzjKjbyTzT5dk0vUXhUM1uQGglI+0CPjr/lK2a+ceE05 sJcQtjZVuVGqF8MrZo1LlGjEFunxnYtitALSsmnzRzrIVuY2V0YdVYHkp+/Feb1DyV50XU7f 6tqsyR6iH4xV+H1FIqv+TzH2cysWXpI7uNkx9RyZnmQ0t4FbxS2DgVsHFLeBW8Ut4FXA4Et4 pYX598pnU0bVYHAltoHEsZr8apWT4aft5Tkh1bYS6PHJoTCwY75Q2oiFpbwBZZAkSdBgTajK qBisAqB+0P4YFIes/lx52ivLWDQ9UnJ1VCy28j7+rGo5r8f+/UX+b7XDLoS6NUo9XoWWsGpY o5onhlUNHIpV1PQgihGJCh4j5+8npodzH9V5SW06s6OR9lgael/wOY8hTfE2wtZJI2ovwnxy KUSi24X1J35P4YruV1pqF1Z3UdzYu8E8ZrHKmxH/ADb/AJOBiQ+iPKusPrXl+x1KQASzxgyh egcfA9P9kuXg7NacYUt4Fdil/9I7PU50zzjeKWwcCt4pbwK3gS2Diq7AlvFUm83Xf1Xy9euD RpE9JfnIeB/4UtmPqZVAt2EXMPJ7FOU6+2aZ2hTjj4ZFi6nj9GFDXE9Biq6mKuoOpxVxWuKW wNvHFUFcN18MLYHr+gQtb6JYQsKMsEfIeBKgt/w2bfGKiHVzNyKYjLGLeBLeBW8VbBwJXYpb wKhtRsINRsprScArKjKGpUqSKc1/ylyE4cQpnCVG3kPmTy3c6RcRwzkN6qs0br0YKQrfI/Eu a+UDE0XNjIHcJEsjwNRBRsgzpGRehwae6blJ+yPfClS4SsRLuig1UjY7dCMii3qXknzq+syN p14qrdxJySRekgX4WqD+3mXiyk7FxsmMDcMzrmQ0t4q3gS2DgVsYpbrgS3ireBVwOBLmCspV hVSKEHuDil5V5/8AKKWUiXVhARZMh9SlSEkB/wCFUrmNONN8JW87ZGR6Nsp7ZWzCL+sRFFht 4/j6FsCabtbi50u9t7+Jgt1bOJI67io7N88UEW9j8mef7TXbYx6g0VnqaOEMXLisnL7Dw8z/ ALFky6OS+bVKNMxy1ihdU0621KyltbiNXDqwQsK8WIorj5ZEi0g0+e/Mfl/UNFujBeR+m5rx PZlG3qL7Zj1TdaVwNCjVkHKnbAkoiWVpP7qLiuBDOvyi1O6h1+TTWlpa3ELv6LH4fUQpxZB/ PwZsnDmwk9ny1DeKt4Ff/9M6PU507zjeKt4Etg4FbrilvAreKWwcCt4pYP8AmVe0jsrJT9ot M4+Q4J/xJ81uulyDm6SPMsQ0tKszHttmucyRTMbDAGNuoKj3wrbqDBSW+OFBbC7Yq2V2r3wE qteqoThSEHFF9ZvLe3pX1pEj/wCCYL/HJRFkBkTQe1KAoAHQbAZunVLsVbBxS3gS3ireBLYO BW64q3gSg9T0iw1SJY7yIPwqUcbMtevFvfK54xLm2QmY8nkWu6Dc6fdXAeF0iWRhG7DZk5H0 iG+z8SZr5Ro05sZWEkj+B+UnQdj0yLNGh5dQZUUBIl28OmKNgos7QSgWrMJEOzoSCP8AZLgV 6l5M86W99Da6XfO36UClfUb7MhXp8X+/OGZeLLfpLjZMdbszzIaV1cVbwJbrgVsHFLeBW64p bwKuBwJUru2ju7Wa1l/u5kaN/kw44CLCQaeK+cfKVzokkIZhLHNyEbr1ogFeQ/m+LMSUSHJj IFjEU72hJUfF2JGRZK0MRlVrm4bYdicaXmpUMtSo+EdG6YoOzOvK/wCaGoWDwWOrL9asIx6Z uRUzqB9lm3/fcf8Ag8nGZDEwD0fSfOXlzVw/1O9TnGKvHJ+7YD+bjJx+HLBMFrMSGO/mrpdr e6Cmqq1ZbRgoZdwySMFYch/L9rI5BtbOB6PFgwVtlrlTYjknupo+EaAKO4wo2U1N3ayrOkhS aIh43U0YMu6kEYFL6V0e+S/0u0u0kWUTRIzSIQVLFRz6f5WXgtSOxS3XFX//1Dk9TnTvNuxS urireBLYOBW8Ut4FbxS2DgV5R52uzdeYbgD7NuFhH+xFW/4ZmzS6mV5C7XTxqChp6cIRXvmM Ww80bUYoceuIVxIpTwxtacPwOKgLuo264q6njinZSuNkp44hkAiPKtsbjzJZClVjZpW/2Ckq f+D45kYBcw15jUC9YzauubxVvArdcUt4Et4q3gVsHAlvFW8CUDrWlRatp0tjIePOhR+vFlId T94yvJDiFNmOfCbeS+ZfL8ul331RyHPBZQy1oQxZe/8ALxzAlEg0XOjIEWEj5yLWNSQOhOQZ IxZrWC2CKC9w2FFLEW4spY7wOY5425xMNiCOhwLzeh+T/wAwIpYHt9euAkwcCCdloGVuz8Rx HBv2syMeatpNE8Vn0vQFZWUMpqpFQR0IOZTjrq4q4YErgcCt1xS3gVvFLeBWwcCUDq+i2GsW 4gvU5BTVHU0ZSdvhORlEFlGRDyfz75e0/SbmK3so2DcebSOakhv+aaZjziAab4yJDDHeTaOv wjrlbNEy3MfoR28Io5+22FQ3NELaNU6yOK/fgKAFKSL0kBb7bdsVR1prmq2WmXWmrMTYXgAl gf4lFN6x8v7s/wCrivNJnI/YG2Kom1a5JCowWuwxVVuLSdPieSuKl6p+TN2W07UbFpeXozLJ HFXdVkX4yo/lZ1yzG1l6VliF2BL/AP/VOD1OdQ827FW64Et1xVdgS2DgVvFLdcCtPIscbSNs qAsx9gK4CaCRu8UvLhry/muG6zys5B/ymrnPSlZJd3EUAE4hHBFX8ciwtU2NfbAlw8PuxQ6m FK5emBDqfdhSu6VGKENdNQ0r0whkE/8Ay8t+ep3VyR/cxBAfeRq/8y8zNJH1EtGpOwD0PNi4 LeBLeKt1wK3XFLeBLeKt4FbBwJbGKt4EoPUtIsNSQLdRB2UERv8AtLX3yueMSbIZDF4/rHl+ +0youIWWjcQ/7LGvwlW/yhmuII2LnAg8kojPov6jCrDffxxSi4S1/MZbluMaCtOgwJUXX1pS kI/dpsTgQdmU+XvPupabNaWN06zabHxieq/GkfTkrj7XD/Ky2GUx/qtcsYI/pPUNL1rTNWje TT7hZ1jNHAqCD7q1GzLhkEuTjSgY80dk2LeBK4HAreKW64FbxS3gVsHFKA1XQ9M1dUW+h9Qp 9hgaMPaoyEoAsoyIeU+bfJF1ZapOLC2drKYq1uVq9Kijxk+zDMaUaLkRlYYZLDJbyNzUrIjF SD1BXqDkEuSUvOJZTyp2+WKVZZBdXo5mkYP0Yra94hc3IjT7FSB9AJriiWyC4Ewl/A0xS1ET UfFTwxW0ebQtFz9Yn2JxpFsh/LV57fzlYpHJQTLKkorQMgQvxP8As1XjhhzYze85e1t4pf/W Nz1OdS806uBWwcUt1wK3XFLeBK4YFbriqTebb76noF0wNHlHopTY1k+E/wDCcsxtVPhxlvwR 4ph5VapzuFHYHfNI7cp6OmRa2x44q2K0xS3vvtXFFO9vuwquB+nwxVd2+eKoC6arHC2Bmv5d RUsLuem7zBeXiEUf815sdGNiXC1R3DMQczHFbxVvArdcUt4FdildXAreKW8Ctg4EtjFW8CUB rWkW+sWJtJyVoweNxuVdejZXkhxCmyE+EvLPNHlp9KvhCCXiaMSJIFIBJJDL/scwJxMTRc2E hIWx1/UU+nuB3yDJELeCG39CFR6kh3bvTFfNc8CW1ssjkGWTenU4KXmq6dqOp6Qz3NpO1vJK vFitN1rWlDhBI5IIBeh+WfzFspLCOPWpTHehyhl4/CyfsSNx+z/K2Xwz0Kk0yxb7M6jkSRFk RgyMAysNwQdwRmU467FK4HArdcUt4FbxS3XArYOKW8CsS1r8utI1W+e8DtbtM3OdFAIZu7j+ Vm/aymWKy2jI801vyXrNjfzWkFpNNGjn0ZY0Zg8Z3jaqgjlT7WUkEFtBBY7JFJAxUgq6kq4O xBGxU++Bkn2h2v1fQdU1y5XjGiC1sS3+7JpD+89P+bgg/ZxHK2EhvSRmiWix/tNu2BkhkC8v ixSUfHaRvHyjlow7VxpFlq0e7tbyGa2dhcxSK0Lp9oOCONKfzYoL6biZjGpYUYgFh4GmZLUv rgV//9c1J3OdS803irdcCt4pbGBW8Ut1wJbBwKwj8xrw/wCh2Q+z8Uzf8QT/AI2zWa+W4i5+ jjzLE9MSrF+wzWudIpmAfngYWu22xVv5YUt1xV1an9WBDgae+FV9SBv4YUhLbhqmuLYHovkS Ix+XomP+7ZJHHy5cP+NM2ulFQdbqD62R5ktDYOBLeKrsCuxS3gVvFK4HAreKW8Ct4EtjFW8C VksEE4CzRrIAagMAaH6cjKIPNkJEcnnuveQbwzXl3atGbesk6rUhgD8fp8QO37OYU8Mhf81y 45QfewFoXjIdtqiv0HfKdm63ROGmEku6joMATaKX/T7iuyQrU4qpSr6spihHwr9o4o5Mg0Hz nqmkXdrBJM02nR8Y5IDvxi6fu/8AKTDCZieezGUARyepaN5m0fWmkSwm5yRAF42BVgD+1xb9 nM2GQS5OLKBjzTbJsWwcCrsUt1wK3ilvArYOKW8Ct4EsS8w6N5Ft55NT1dI0mNXkUMQXP/GJ T8TZTMQG5bYmR5PNfN/meLWXt7Oxg+q6RZn/AEa3AoWY7cyq/tfy5TKV/wBVtAr3u1fy9Lo3 li3n1CArqmpTcoQf90wRqG4yfyyys3xJhIoMQbLFk4g/EKjI2zRos4pIvUicBh1AO+NIC/S5 Li31WymRfUljuImRevIh1HHFEn0wDtXMlpbxS//QND1OdU8y2DireBLdcCt4pbrgVuuKW8Cv LvOt79b12Zf2LYCFf9j8Tf8ADtmj1U+LIf6Lt9PGoD+khrCPjCD45ilu6o3G2Nu+eIS4V2GJ QuHXAClxr92SpQ4UPXFS2x+AnwwJASuYjc4Wb1jy3B9X0KwipQ+irN83HqN+LZusMagHU5Tc immWNbsUtg4FbrildgV2KW8Ct1xSuGBW8Ut4FbxS2DgVvAlvrsemKWMeYfJlhf2MgsIEhveQ dW6A0+0n+SrZiZNOK9P1ORjzG/V9LzDVtIu9NmW2uUCTOC3EEHYHj+zmJy5uUN+SEVJgnGOu +C0oq2EkMLKsdXf9o9sK+9qKzlFSy1Y9zjSCUXpbalpd39bspjDPxKchT7LdQQcRYQaPNmdh 5/1SG3WO8gjuZV/3cG4Ej/KUBl5ZaMswP5zWcUSf5qKH5h3H/LAn/I3/AJtw+NLuivgx75Lj +YlwP+PBfb97/wA24PGn3RXwo963/lZEo66eP+Rv/NuPjS7op8KPetP5nMOunj/kZ/zbj40u 6KPCj3rG/NNx009a/wDGT/m3B40u6KfCj3oeT82LsfYsIh/rSMf1BcfGl/RT4QQU35sa0R+7 t7dPoZj+LYDlknw4pdN5z86asSlu8zA/sWsZH/EAWyszJ6shEDoq2X5febtWlEt6v1ZHNWlu X5PQ9/TUs+SjjPcg5Azzy3+XWjaJOt5IzXt6o+CSUDgh/miiH2W/ymZ8ujjAapTti35xX5e7 sdP5DhFGZyo68nJj+L/YJkMp3pljGzzaIhWHIfD3yptpHS2iCITwP18MUJz+XkEdz5w06O4Q OqtJJxPZ40aSN/8AYsMlDmwlye/A5kNbdcCX/9EzJ3OdW8y7ArYOKrsCW64FbxS2DgVTubhL e2luHNFiRnJPgorkZy4QSyiLNPGppHuLhnf4nkYs3zY1Oc3zd6BQTiFAsajwFMiWNKh74QrY 8MULsChuuFLvlittUqa+GJVbKaRn3whIS51aRxGu7OQoHux44WfR7REgjiSNeiKFHyApm+Ao OlJtfXFW8Ct4pbBwK3ilvAreKUPd6lZWSFriZUp0WtWPyXrlM80Y8y2QxylyY3e+c5WqtlEE XtJJuf8AgMwpamZ5ehyhgiOfrROmecLFLKurXCx3KuwAoasv2lYKgyzHqQB6vqYywEn0/Snb 6zpUfDneQr6ieolXAqh/ay854d7UMUz0dLrWkQBTLewqGFV+Ndx7b4DngOqjDM9F9pq2m3kT y21ykkcbcXYGgBpy3r7HDHNAi7WWKQNUhLzzVo1rVfX9aQfsQjn/AMMPg/4bKpamI5etsjp5 Hn6UgvfPV4wK2dukIPR5Tyb/AIBcx5aiZ/m42+OCA5+tK3v/ADTqJor3UinakKlF+9QuVXI9 ZTbKiOkYtJ5R8w3b+pJbgMf253q341OSjil0ig5Y96648ja/FTgI5ARUmMjYj/WpkjimOjEZ Ilijy3Ck9RQkGu3TKmxCi7meSnIhR1OKV8kryzJFbsSx2JxStu/rFu3p+oS57A4FWLcSxSRm csU5AuB1K1+ID/Y4sTy2emaWPy21O9Wwtoybhx+69QyoHNORVGLfb/ycviMZNNMjMC0/Hkfy q9aWgNNjSR9j/wAHlngxYeLJv/AXlWv+8Vf+ekn/ADVj4MV8WSovkXyoDX9Hqfmzn/jbHwYr 4sldPJ/ldSCNLgqPFa/8Sw+FHuXxJd6Kh8vaDAwaLTrZGHQiJK/8Rx8OPcvGe9MI444l4xoq L4KAB+GSpjbUtzbwis0qRjrV2C7D/WwEgJALFdd/MnQdNiZbOUX94DQRRk8B/lPLTj/wGVSy jo2DGerxzUr+51e/nvLlqzzOWb6f2RX9lcx25ZaNGsvo3IoG2DHpirU8ZgkIjaqV6V2xTb0n 8n9Nt5Hv9UlTlcQssELnsrL6klP8pvhy3GGmZep5cxbwK//SMidznVvMOxVvAlsHFV2BLeKt jAlIPOt6bbQ5EX7VwyxfQfjb/hUzC1sqx1/PcrSxuf8AVecWac5wew3zSu1PJOAcDGmweuKS 4HscbYrgRhTa6oPTAFLtu3TCVcDgVTuTSMe+FkFLR4Rca1YQ9mnQn5KfUP8AxHLMQuYH9JGU 1EvX83jp28Utg4FbwK3ilvAqlc3dvaRGW4kEaDue/wAsryZYwFlshAy5MZ1PzZLJWPTx6aH/ AHaw+I/6q/s5rsuplLl6IuZDDEbn1SY5IzyOXZizncsxqTmPTdamajbCtBAapEzwCVesTVPy 74sgUKKyAGtTSgJ7DwwJdDAxQo5+Jdx8q4qnWm2Au/RtLf4riZqAMSFoBy5P/qrkhGzQ5qZc I3ZbZeRhRTfXJPjHCOI/4M/FmTHTSP1H/SuNLUDoE/stC0myoYLZA387Dk3/AATVy+OCA6NM s0j1TEUAoNhltNdt1xVvAlItX8qaXe212YbdEvZkb05NwBIejUH+V9rMeeEUa+pujlPXk8z1 bytqul25nuYOEZYRgggjkenTMQxI5hyhIHqkiB7esnRh3yLNfYlGuDPcmoG4xCCuEf1+9Ppi ka9MeanZSkDC8CQni0TVDLsQR3BGBeSO07XdW0e+aWwuGWWVeMoPxK3uyt8PNf2WxBI5elSA Run2m/mTr2nmaO6IvjLvEZTQoR4cPtL/AJOWRySDCUIlNrL82ZYoHTUbISXVf3TQnghHg4bn xyQznqGJxBFj83LIWlXsZBfdouQ9Pr/vz7XT/ivD45rlujwvND3n5vfu0Fnp/Gc/b9ZqqP8A V4ccBzHoEjEOqR6p+ZvmO6lAt5BYpT7EQBr/ALOQM2QlkkerMQAYxfX19eXXq3szzSyftuST kGSjLG0MilvsttiqpdwmDhMnQ74lQvu2huIEeMUem/zxUKmjWFxqt/bWEVPVuHEYZui1/ab/ ACVwjdEi988t+X7Ty/piWNseRqXmlOxdz1bMmMaDQTabjCreKX//0zAnc51jy7dcVbwJbwJb BxVdgS3irBfzCvKz2tmDsimVh7seK/8AEWzUa+fqEXZaKOxLGtPT7TZrnOKPBxYt1wK2CMVX A/jirq9cKVwNdsUBsHfFKhdtsB9OKQi/J8Xq+ZLXbaPnIa+yMB/wzZkaYXkDVqDUC9Szcuqb wJbxS3XAreBUr1XXYLEGOOktz/JXYf6+YebVCO0fVJysWC9z9LD72/ur6X1bhy56KvRV/wBU ZrySTZ9RcsAAUEPTxGwxVoKCw9zgS3JuKeHhim1J4fUUoRXkKY2hJEYKzx9DGaEd9sWwp15b 0W51q5+A+nboGEktKgfyr/rZPHjMjQYTmIjd6Nonl6x0iP8AdVlnP2p3py+S0+yuZ+LAIf1n CyZjL+qm+XNTsUrgcCt1wJbrireBKG1HTrXUrR7S7XlE1DtsQR9llPjkJwEhRZwmYmwwbzX5 GtrfTo5dOSSRkk/fVNTwoeygftZiZcXCLDk48hkaYNf6Zd2iJ6sTR+tX0+QIqB1IrlDcEPFK 9rGeGxPfFQvsJUhDzSCrtU74p5lbYBJrl55DRdyMQpbgUXN+R+yNhiAgrZY/U1ARLuoNMFK1 cx0vkiG5rSmKa2bvohHcxp3woa1GP0pIz40wEJHJdqSKiwsDU0BJxKhq/lSW2jK7MoxIULBM 81uqNvxFB8sUWq6TYT311BZwgmWeQRqPmacj/krhAQS9l8peQLPy/cC+kmNze8SqmgCLy+1w H2uWXwx1u0ylbL8sYrq4q3XAl//UHk7nOseXbBxVvFW8CW8CWwcVbwJeUeYrz67q91MDVOZR D1+FPgX9Wc5nnxTJd5gjwwAdapwiH35U2FXBxQ2MVpsUxUrlOKt198UN8qHFK4HFULdnfFkE 78gpy1qV/wCSBvvLIMzNEPX/AJrjas+n/Oei5tXWt4q3gS3gSxzW/MLLK9lYt+9XaWUb8aj7 I981mfUmRqP0udhwgbljxB61JY9WJrXMOnKWMvfvhQVMjxwhHJ3IA7jbFbaVgW9q4q2zKD9r vSg3P4YppX0TyrLqepm7ZeFirD1eWxYghuIH+UuW4sRkf6LCeQRH9J6RbWttaxCG2iSGIbhE AUVPsM2UYiPJwDInmrA4UN4pbwK3ilcDgVvAlvFW8CW8VS3W9BstagSK4qrxEmOReor9ofTl WTGJNsMnCwfzP5Ba3FvJpqSXEdCJx1bl+y3Fe2YuTEY/0nIhkB5+liuqeXtTsIomuLd4lmrw LCnTxyogjm2Ajol7QSwwFgrcegNNicCbWW6ywgsKqx6nGltq3d1mM3euxxBSVqyM136p3Knr gW11xK8twrncjfFbau3eVkrue2FbXTJI8ag1O4AxQj7PQdVv7dzZ2skwWgJVSQCcUXTMPK35 a3M59XWFa3twKLENpGP/ABquWRxk82uU+56DpHljQ9HIaytVWUCnrN8T/wDBHLo4wGsyJTfJ obGBW8CW64q//9UcepzrXlnVxVsHAldXFW8CW8CULqtybXTLqcGjJExX50ov45Tnlwwkf6LZ ijcgHkiqWlA6nvnOO+TRdgBigt9sUUuxS3XFWx16YoXVxS7fFFLh44VpB3TfGRiyDJPy8QnU L1/5YkH/AATE/wDGmZuh+ouJrDsGfg5tHXN4Et4q4iqkeIpkJCwQyBovPbyM22t3aN9meki/ MARuPwzRVTto7houGAC4UuqFHXc9cCbUyd9umFipufxxUKcm8LEbEDtiyZTovl4SWkNwFVVl UNybcmuZEMBkLDjzygHdk9laR2kPpIa1PJj4k5nY8fCKcWc+IonJsG8Utg4FbxS3gVvFK4HA reKWxgVvFLYOBWwcCVO4tba6iMVzGssZ/ZYVGRlES5soyI5IO90DS72xNi8CpCSGX0wFIYft KcrOKJFMxkINpLN+XWjPZyQRs6zsapMxrSn7PH+XKzg25sxm3Sy1/K5Qr/WLsciCEEa7A9q1 yAwHqWZzBBWn5XX/AK3GeaOOGpqyksx+imRGGSTlDf8Ayq3UPrTAXEXoE/3m9af6lMfBkvih Nf8AlVlgZEb62/EABhxFSe9DXJ+Ae9HjeTI7byh5eggii+ppJ6XR33YnxbJjFFr8QpxBDDBG I4UWOMdFUAD8MmBTG1XFWwcUtg4FbxS3XAreKX//1hp6nOueWdgVsHFW64ErsVbwJY155vfS 0xLZT8U71P8Aqpv/AMS45ru0J1ER/nOdoo3K/wCawWzWshbwzTO1R2KF1e2K241+nFS2pP09 8ULhirYOFW64ErlOKoG4NXbb5YWTMfy7ipDfTkbs6Rg/6qlv+ZmbLQjYl1+sO4Znme4S4HFW 8CW8VYP5riMV80/T02Vvmknwv9z5ps8amXaYTcQgugp4dMpLbu1wqDXvgUB3AcRtXCmljIS1 KbYCinJGoYhiAPfClm3lO49XR0jrX6uzQhvEL8S/8K2bHSyuH9VwNQKknYOZLQ3ilvAreKW6 4FbxS3gVsYpbBwKuxS3XAreKW64FbrgS3ireBLYOKrgcCW8Ct1xS2DgVsHFLeBLdcCrhilsH AreKW64Ff//XGE7nOueVdireKWxgVsHAldirzzzreevqzRBqx26hAO1T8T5oNbPiyV/Mdzo4 VC/5yU2iUSp6nMRyiia7YEtjFC7FXd8KFw64ErqYUrqA4ocAATihL5d2PzwM2e+QIgmjyyd5 J3J/2IVP4ZttEPR/nOs1Z9bKMzXEbwJXA4q3XAlIPNdmstss9KneJ/8AVb7P/Avmv1sOUnM0 0ujGbZhJCrH7QFG+Y2Oa9zl/ONRV2AXvvilSkvoVH7pTIe3hjbKkI93cvUVVB2pucVoKTL+0 5Zj4k4oemeX4I4NJtzH0lUSEj/KAza6eNQ/rOszSuSZ5e1N4q3gS3gVvFWwcCW8Ut4FbxS2D gVdilvAreKWwcCt4Et1xVuuBLYOKrsCW8Ct4pbGBWwcUt4FbwJbxVcDgS3il/9AUepzr3lWw cVbrgVvFLYOBXM6orOxoqgkn2GRJoWkC3kl9Mbm8mmO5lkZt/c1zl5S4iT/OeihGgAikXioB yKVTwxS4fhihdv44rS4DCtrht174quFe2BWwK4aVfxopPXbCtJTJux+eRZh6V5Mj9Py7anvI Xc/7J2zdaQVjDp9SbyFPcymhvAreBLYOKqd3AtzbSwN0kUgHwPY/flWWHFEhsxy4ZAvOtUsb yxLVDIJHHJad2zSEVsebtoG0COK7UqfFt8DZbmZqYsbXwwyyfZUtiqPi0i5dRJKRGn7Jbriy Zt5X+HSI4g3NYmZFb2ry/Dlmz0h9DrdSKmnGZTjt1wJbrireBLeKt4FbBwJbxS3gVvFLYOBV 2KW8Ct4pbBwK3XAlvFW8CWwcVXYEt4q3gS2DgVsHFLeBW8Ut4FXV2wJf/9ESTuc695RwxVcD iluuBW64pSnzPem00eYqaPN+6X/Zfa/4TlmFrcnDjP8AT9Dk6WHFMf0Xm8K8ph4DOfd4mFN8 VpsCuFSuH44FpcAcVXKMNoXKPvOK0vUdsK0u4bb9cVpcw/dN2AGKQk0h3ORZPU/Lkfp6FYL0 /coae7Dl/HN9gFQj/VdJmNzKaA5c1N4pbwK3ilsHAqG1KzW9sZbc/aYVQ+DD4k/4bKM+Piif 5zdhnwyDBV0tZZGkeT0xU1B617j6M0pduE1XyyscUMvEyCdPUi78lrTpkRKzTMihaZW2hTLQ hVjGxoev4ZljTTP9FxTqYg/zl/mLSi9rBIhoIpAeI6EOPT+L6fizGOCUTZ/hbxnjLYfxIzy/ bCzsPqvqrLIjMzle3M81BzZaQ+mnX6oeq01zLcZvFW64Et1xVsYEt4q3gVsHFLeBLeBW8Ut1 wK2MUrsCt4pbBwK2MCW8VbwJbBxVvAldXFW8CWwcCtg4pbwK3ilvxwK//9IQepzsHlHYq3gV cDilsYFYZ55vGM8FoD8CL6jDxLHj+FM0vaOS5CLtdDDYyY3ZpUls1jsUYoANT0xVtutR0wqV wpirhihUVa4pXhRttXCil6ipxTa8KD8sKFs+0DntTAUhJJOh+nIsnr9hH6VjbRfyRIp+hRnR YxQA/ouhmbJ/rInJsWwcCt4q2MCW8Ut1wKxjzRpwjltry2WjvIY5R+zVxVXP+yXNVq8IieIf xOz0uUy2P8LJbH000y1gADvCpX1ga1BP2R8ss0unA9bXqc5PpVcz3CakRZY2jbdWFDkJxEgQ WUZcJtK9D0RtMmu53mMjXbAlP2VC1pSv+tmNpsBx2S5GfMJ1Scg5luM3gS3ireBLdcVbrgS3 ireBWwcUt1wJbxVvArYOBLeKt4Et4pXVwK3ilvAreBLYOKrq4Etg4q3gS3XArYOKW64FbxS/ /9Nc9TnYvJurgVvFLYOBV1cUvMvMV39b1W4lU1TlxT5L8P8ADOY1GTjyEu/08OGADUCcY1yl vtX2FMVtxGKGjily16YqqowBrihVDL9OFbXqp6+OKVQpQE9sNqsuiBaufHAVCSU5MB15GlPn kWRewxjiir4AD7hnRx5/5roDyVMmxbwJbBwK3XFW8CW8UqF/aLe2ctsxp6goG8D1VvvyjPi4 4mLbhycErUdD059M06OzeT1WQuxf/XYvT/Y8sjp8RhCiyz5BOVhMa5e0uwJbxVvAlcDireBL eKt1wJbxVvAlvFW8Ctg4pbrgS3ireBWwcCW8VbwJbxS2DgVdilvAreBLYOKt4Erq4q3gS3XA rdcUt1wK/wD/1Fj1Odi8k7FWwcUt4EoTVbw2enT3ANGVaJ/rH4V/XmPqcnBjJbsEOKYDzIAy Tbn3JzmA9DyTFBQU8MKFw+/FLdcVaO5r0OKCuXFIK/j1PhirYFThQrIWHyOKolaFaMfowqpX 442Lbd8B5KEos4/VvbeM7c5UWvzYDGG8gEzNRJeuDOjHMug6NjCrdcVbwJXVwK3XFW8CW8Ut g4FbxS3gVvAluuKt4ErsVbwK3iluuBLdcVbGBLeKt4FbriluuBLeKt4FbBwJbrirdcCW8Ut1 wKuxVuuBLeBLdcVbBwJbxVvAlcDgVvtil//VUPU52TyTeKt1wK2MUsb863JSzggBp6jFmHso /wCbs1Pac9oxdjoI7ksPtVq5bNMHbo8bDFQ2KAHFW+22KrgK4oXrt23xpXFuNQcUuV69sKFd BXc9umFUSBWgxVT1UAWO3iMiUpVpChtXslO6meMU/wBkMswi5x/rMMxqB/qvV86Acy6M9G65 JDYOBW64pbwJbBwKurireBLeKWwcCt4pbwK3gS3ireBLdcVXYFdilcMCW8VbwK3ilvArq4pX DAreKW8CtjAlsHFW64Et1xS3XAq4Yq2DgS3gS2MVbBwJbxVuuBK7scVf/9Z56nOyeRbxVvFL dcCsB823nr6m0amqQAIPn1b/AIbOc12Tiyn+h6He6KFQ/rIC0UhAKb9TmG5losj2wq6nhgQ2 oPTvitLwaDp9OKuqF3OFWiwPUfTgSuFPDChURt8UoyEgjChbrH+8AI/mGQLIJboIrrdiP+Ll O3tl+n/vI/1mrUH92XqNc38RzdGW8KG8Utg4FbxS3gVsHAlcDireBLdcUtg4FbxS2MCt4Et4 q3gS3XFW8Ct4pbBwK3XFK7ArsUt4FbxSuBwK3ilvArdcUt1wK3gS3XFLeBW64quBwJbwJbri rdcCW64q32wJf//Xcepzs3kW8VbwKtmlEUTyt0RSx+gVyE5cMSf5rOIsgPLp5HuLlpH+27Fm +ZNc5Ikk2XpoxoUmEC8VAwpVGrirlFMCr16Yqu4064VacCnyxQ0o6YEtkd8KHK2/tilGWxHL c4qq6yFGlqOpLj9eRLIBLvLaltes6DozH6AjZk6UfvIuPqf7svTK5vo26Qt4VbwK3ilsHAre KW8Ct1xSuBwK3gS3ilvAreKtjAlvFW8CW8CWwcVbwK3iluuBW8Ut4FbxS3gVvFK4HAreKW8C t1xS2DgVvAlvFW8CW8VXVwJbwJbxVuuBLdcVf//Qs/aPzzs3kG64q2MUpdr8vpaPckdSvEf7 Ihcw9dKsUnJ0gvIHnsG8pPhnMh6FNI9l6ZJWyd8CuBxVep7YqqgCm/34VWOKbDviraDEKuNO +K2o0qcUIm3O/wAsVROs1/Rcf+uMjJmEJ5UWuvW/sJD/AMI2Zej/AL0OLq/7svRc3keTppNg 5JC7AlvFW64Etg4FbGKW64FbBxSuBwK3XAlvFLdcCt1xS2MCt4q3gS3gS2DireBW8Ut1wK3i lvAreKW8Ct4pXDAreKW8CuxSuBwK3gS3irdcCW8VXA4Et4pbrgVuuBL/AP/Rx6n552jyDsVb BwJSPzhMU0sKP25APoAJzV9qSrGB/Sdh2eLn/msMsxVic0Qd2mIrQYULu9MC22FxQvAAG3XF V3MdDhUreVT7Yq4mm+BLXMnChtcVRNqtWxSjNfj46RFIe8gA/HISLMIPycK62D4ROa/8CMzt D/ef5rha0/u3oGbuPJ1EubeFDYOKrsCW8VbwJbBwK3XFLeBW64pbBwKuwJbxVsYEtg4q3gS3 ireBLeKWwcCt4FbxS2MCt4pbrgVvFLeBW8Utg4FXYpdgVuuKVwOBW64Et4q3gS2DirYOBK7F W8CX/9Kj1Odq8e7AreKWLedpT6dtF2JZj+rNH2rLeIdt2cPqLHbNdvftmpDtSjwKDCrYwIVK ilB174VdWmKraAnrilcABihotgS2BXoMKGwMUoq0FWAxUJh5oAXRbRD9oyBvuGQLYEP5Ggrd 3M/8iBB/sj/17zZ9nR9RP9F1mvlsAzWubaIoAOskbLeSQ3gS2Diq7AluuKt4Etg4FbxS3gVv FLYOBV2BLeKW8Ctg4q3gS3ireBLeKtg4Et4FbxS3ireBLYwK3iluuBW8Utg4FXYpdgVvFK4H AreBLeKt4Et4q3XAld44q//TaTuc7V492KtjFWE+cZS+oLH2RAPv+LOa7SleX+rF33Z8ax3/ ADkvshtXMIOeUbTbFC4U40xVum+BVjijYSgNqB174pb7YFaxVUTc+2EKuK+HzwqiLDeUD3wJ CM82ygW0EI8MgebNF+S4Smnyykf3km3yUD+Jzd9nRqBP9J02ulcgGSVzYuA3ireBLeBLYOKt 4Et4quwJbrgVvFLeBW8Utg4FXVwJbxVvAlsHFW64Et4q3gS3irYwJbxVvAluuKt4Et1xVvAl vAreKW64FbxS3gVvFK4HAreBLdcVbwJbBxVvxwJf/9Rh+0fnnbPHOBxVvAl5/wCZX56vNToC B9wpnKaw3ml/Wek0grEFtl9nKHJRlNsULl3pTGlXlfDrhVTcfF8sCtVGBWifvxVwWv0YoVFI GEJcW22xQjNLFbhfbFIUPM0/qXQTsgp9+RZllfl2L0tHth3YFz/sjXOi0caxB0GqleQpnXMp xl2BLeKt4Et4pbBwK3gS3irYwJXA4q3gS3gVvFLYOBW8CW64q3gSuBxVvAlvFW8CW8VbrgS3 ireBLYOKt4Etg4q3gS3gVvFLYOBW8Ut4FbxSuBwK3ilvAreBLddjir//1Uz1PzztnjnYq2Di rz7zCKarPXu5zktV/ey/rvTaX+7j/VW2bbZS5CNYmlPHFBXR0Ub4qqcx1GKFMtU4qtbFLlHj ihditNNv02wJcFOFCY6ZRXLHsK4lkEo1GX17xj4nbIsi9Esk9Ozgj/kjUfcBnUYhUIj+i81k NyJ/pK+WsGwcCtg4Erq4q3gS3ilsHArYwJbxVuuBVwOKW8CW8CtjFLYOBW8CW8VbwJXA4q3g S3ireBLdcVbrgS3XFW8CW8VbwJbBxVvAlvAreKtg4Et4pbwK3ilsHAq7FLeBWx0OKX//1kj9 o/PO3eNdXFW8CWD+aoSmoO9Pt0YU+Wctro8OaT0WhleMICzYZiBzEyG49sUFwbFXda4UU174 EuG+KhcF2wq5geO2KFgFdsCVUDcDCqM5CC2duhO2BISqxgN3qMUXUO4B+Vd/wyzFDikA15Z8 MSXpQ2FB2zqKecbGKt4pbBwK3gSuBxVuuBLeKWwcCt4FbxS3XAlcMVbGBLdcCt4pbBwK3ilu uBW8CVwOKt4Et4q3gS3ireBLeKt4Et4q3gS3XFW8CW64q3gVsHAlvFLeBW8Utg4FXDFLY6HA r//XRPU/PO3eNdireKWP+bLQyW6TqK8PhP680nauM7T/AMx2vZ2SiYsRgbg9DtmlDukzjeo6 4ULx1xVUHTFXHFDYGKrwNsVXFNvbFVqxYqrxxgNyPQb1xpUDqN4HoiH4RgKQmvk+ydp2u2Hw ICoJ/mPh/sc2XZ+K58XSDrtfkqPD/OZjm7dQ2DilvAreKW64FbwJXA4q3gS3irYOBLYOBLeK t4FbxSuwJbxVvAlsHArdcUt4FbwJbBxVdgS2MVbwJbBxVuuBLYxVvAluuKt1wJbrireBLeKt 4FbBxS3gS3gVvFLYOBV3Y4pf/9BA/aPzzuHjHYpbwKpXkH1m2kh/nFBXxyjUYvEgY/zm3Dk4 JCTz7UbOS2nZWG4JB+jOSnAxkQf4XpsWQSFhbb3HHY9sDajVlB3wsVVT3xSuFD3xVdXFV6nF VQEAVOFW1kAqTsO2K2hL2/XhwQ/M4CUoG2glu7hIkBZmNAPGuMYmRoMJzAFl6NplkLGyjtwa lRViO7Hc502DF4UBF57Nk8SRKLy9qbwKuriluuBW8Ut1wK3XAlsHFV2BLgcVXA4Et4FbxS3X ArYOKV2BLdcVbwJbBwK3XFLeBW8CWwcVbwJXVxVvAluuKt1wJbrireBLeKtjAlvFW8CW8Vbw K2DilvAlvAreKtjocCX/0Q5+0fnncPGOxVvFW8CUm1vSPrSmaMcn/bH8VzTa/RGXrjz/AI3Z 6PVcPpkw64tnhcinTNERTuwbaScr8sLKkUl0ppiShWWZDvXFVRZASBXCqosiV+I0xVTkvEC9 cVQst8zCgwWqjHHJPIFUEk7U8cQLRI0zjy/ogsE9aYf6QwoB14j/AJqzfaLScHql9bpNVqeP 0x+lO82LhN1wK3ilvAq4HFLeBW8Ut1wK3gS2DireBK7FW64Et1wK3iluuBWwcUrsCW8VbwJb BwK3ilvAreKW64FbxSuwK3gS6uKt4Erq4q3gS3irdcCW64q3gS3irdcCt1xS3gS3irdeuBL/ AP/SDH7R+edw8Y3XCrsCt4q3gSg77S7W8U81CydnA3+nMPUaKGX+jP8AnuVh1U8f9KLFr7y9 dwlisZZB+0u4zQZdHkhzHpdzj1cJ9Upe2mQ0IIzEcsSW/vBim2xJIOhxWw1zkJ6nFNhsJK3Y nFFo+y0e6umASMkV3NNhluPFKZqI4mrJmjEbsy0rQ7ewHNqST9mpsv8Aq5vtNoo49z65ul1G rOTYemKa5nOI3ireBWwcUt4EtjAq6uKW8Ct4pbwK3XAlsHFW8CW64q3gSuGKt4Etg4FbxS2D gSurireBLYOBW8Ut4FbrilsHAreKVwwK7AlsYq3gSuBxVvAl2KrhgS3XFW8CW8VbwK2DilvA lsdDgV//0wx6n553LxbWKt1xS3gVvFW8CW8VUZrK0nFJYlavelD94zHyafHPnFuhmnHkUuk8 t2Tn4WZR9BzAl2XA8jJy46+Q5hDt5UjLGko49qjfKT2Ub2k3DtEfzV8flS3H25antRf7clHs rvkiXaJ6RRttoFhCQzAyEfzdPuGZGPs7HHn62meumeXoTNESNQqKFUbADbM6MREUHDMiTZX1 wq3ireBW8Ut1wK3XFLeBLYwKuBxVvAlvFLeBWwcCWwcVbwJbxVuuBK4HFW8CWxgVvFLYwJbx VuuBV1cCW64q3gS3ilsHArdcUt1wK3gS3ireBK4HFW8CuxSuBwJbxVvAreKW8CtjFLddjgV/ /9RA/aP2eudw8Y4f7HAlv/gcVb/4HFW/+BwJb/4HFXf8DgVv/gcUt/8AA4pb/wCBwK3/AMDi rf8AwOBLY/2OKtj/AGOBLf8AwOKt/wDA4Fb/AOBwJb/4HFWx/scCW/8AgcUt/wDA4FXf8Dil 3/A4FXf8Dirf/A4Etj/Y4pb/AOBwK3/wOBLf/A4q3/wOBLY/2OKrvuwJb/4HFW/+BwJb/wCB wK3/AMDilv8A4HArf3YpbH0YFbH0YpXfdgV33YErh9GKt/dgS392Kt/dgS392Ktj6MCWx9GK t/dgS392Kt/dgVv7sUu+7Aq77sUu+7ArY6Hpil//2Q== --XX52BF529F-00B052BFXX Content-Type: application/octet-stream Content-Disposition: attachment; filename="Backup battery charger.jpg" Content-Length: 41860 Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgEASABIAAD/7QxWUGhvdG9zaG9wIDMuMAA4QklNA+0AAAAAABAASAAA AAEAAgBIAAAAAQACOEJJTQQNAAAAAAAEAAAAeDhCSU0D8wAAAAAACAAAAAAAAAAAOEJJTQQK AAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgABAGxmZgAG AAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0AAAAG AAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///// ////////////////////////A+gAADhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklN BBQAAAAAAAQAAAABOEJJTQQMAAAAAArGAAAAAQAAAFUAAABwAAABAAAAcAAAAAqqABgAAf/Y /+AAEEpGSUYAAQIBAEgASAAA//4AJkZpbGUgd3JpdHRlbiBieSBBZG9iZSBQaG90b3Nob3Co IDUuMP/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgR DAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIAHAA VQMBIgACEQEDEQH/3QAEAAb/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEF AQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFR YRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXy s4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgEC BAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPEl BhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG 1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/APUlGy2qlhsue2utvL3EACdPpOUlifWfq2L0 vAfdlMdfU4tr9BriwuLnf6RnuZt27lEl3Eln9D6pX1PpleU1npOBdVZUTuLX1k1ubvhu76O9 aDToipdJJJGkMLbWVMNlh2tbqTz+Rc2frjdZ1HJwsbDqczHeKxdflCgPLjsr2NfS/wBz7G2N 9PdvWr17JfRhEMiXnbqJ5BXlVRyrckNdk+mLavWybnCTZaLHNY9/vYxv8hrf5tBL6r0Tq1vU 6L3X432S7FvfjW1bxYN9YY57mWNazcz3/urSXIfUR9vqdQrstOR+ntm6TtsdXY+n7V6ZL9tm TX6b7PeuvR6qUkkkjwof/9D1NcN/jDrss6fY1jDa8Orc1jZkn3N/N93t3b13C5r634brsSzb q7YXN/rVltzf+oUSWn/i9usczqtNkgi+q8NiPbdSza8NP7/prsWLhv8AFkXWVdQtPZuLVzM+ m20A/wCa5q7liPZTJJJJPpDk/WOvdgh37jwY+MtXm1WHhZD7a8gCwY9tlTNz3AhrToPY5niv UurYtmVhuqrIDpDte8awvJs6ijD6pa27GxbTfvv9a1rt+2XOexzfU2ucxzFH1XdH0P6kYWJi 9OsbjNa1osIAa4uif0rhLi76Tn7l0aw/qf0hvTOj1+yup+XtyH11NLA0va07Hb32eo9n0PU/ R/8AFrcT4hBUkkknIf/R9RkKl1Wtj8eXDcA5unkSAULqvX+k9Io9fqGQ2ppMMYAXvef3aqmT Y/8A74uX6r/jC6Jl4rqcb7UHOBB/Rho1HnYFElu/4ufTrw+pY4YGvpyyHGNYDW1tYf8Ai3V2 Lrm8Lx7onWa8LqONk2ssbXTkOvt9GC54NXpBjmusqbZvt32O9R36P+Wu0r/xi9JdYAMTKDe5 irT+z6yKnr0lVwOo4vUMZuTiu31u0MiHNcPpV2MPuY9qp9Z+sWH0ml9lsuNbdxaPwH9Z/wCa jxUqnVeQGkuMADUleSfWRvr9aZVizcSy1h2Rw8vdW4boa7cz1FtO+vXWsukvZXj0VPn2lpeQ 0/v2Osaz/oLCfj22ZQyja9lzRtBYQ0DRzZ2x9NvqO2oHdIfWMG/GyMKi/EdvxrK2updBEsIG w7XBrm+1HXnOP9Y+s4mLTjU31UUUtbTU302gAAbK2DefpLc6F9acy3JrxepBjm3H0672NLSL D9BlrZczbZ9De3/CJwkEU9UkkknIf//Szfrve+7qgc5xcK2itg7CQLHR/Xc5c/W+wWOnb6cD ZH0p/Olbf1ux8h2dkGpzC3Ho+02B8gkMeMZwr2/16/pLmcezIutrqaG7rDAAEn/pvrZ2/OsY oxsnq6tVgBR8Q3i211rw6txHotH5o/OnQLIy7bsXKux9A6mwsggHjn3NcW/5qNg5mRbe2my2 utjwfe/axu4fR3W2Oa3/AKdX/G1o9Evrn1Oe0Ny6wIPp0PJ8SfVbP+a1ct9fMknNspn2DaT8 YKsf4rerZWfmdTbk2B5rppDAGhkNDrP3fp/SR/rzXjHrnTPVYCx92O23tLXXNY7cf6rk07hQ 6vOYlFeb0ptFwca7AJ2mDodCHLQrYytjK2iGVtDGgyYDRtaNzvpe0LmrKGnJyKawAW2PYwD6 IAcWhbHS8SrHbSbWsc8Mi0wHGfbtFVj/APB+3/0n6aKm/dj4WUxjMpjbWVvba1rnbQHN+jO0 tV+mxvr4docHF+fitMEH6VrP3VWtt9drW4vpssB5sZu9v5zfZ/35B6LZa/8AxrYvqhgcMUtH pghsegTo0/ytyQBtV6PqqSSSfa1//9PM+tTo6rlVlwYLMHIYSeNHV27eHfnNXFtcCO2vYre+ uNm/qdRkkbHA/eFigM/dH3JkdkndiH1taCYjwEI0AVMvL27LCQBrIhMNPDyI7/BWanACO5RU 9b/iitb+2OqNafa7GY5s6TtsG7/q1pf4wsqhvU8C3eNlNlLrT4BtrHu3f2VD6jZB/aGI0nnE yWj5Gqz/AL4sv6+2B97x4Fv5Uwm5JGxcdt5tzL8iplj6rLXuaWtc6QXFwO/b7lbbmZDWktqt c46D9GdBHnt/OVXplm2hrfMq6RuO5uju4E6+ftc1G1M+mdU6lBF9bqrGklvsADgBoxjWn3Wu V/omTe/6+9P6xfj3Y+E2sYrrrWbf0j2WU07w1z/p2WV171WxQGkPdJd2BJMfe5/6T+Wz8xaN Fk2Y3/hzG/8APrErU+ppJp1+aSNrX//U5L62CM2k+If/AN8WOCtz63s/WKHebx+DFhBMjskp AUVjlXCIwooe2+o13+VMIdvSym/+Blyq/XM7siz+sz/qgm+o9sdYxR5Xj76np/rX7si2fL8D KZ1XjZxcN+1hH8pXa7j2WZS7buH8oqwyxEoDsVWq7i2Tbjf+Gsb/AM+sWJVatHCtm/GH/drH /wDPrEFPsW73fP8Aikobv0n9r+KSN/mh/9XnvrfUYpf4WEfe0/8AkVzK77r/AEezqGMaqXhl zXB9Zd9EkS3Y4j6O5rlzDPqh193NVTfja3/vu5RxIpJckKbStpn1I627mzGZ8XuP/U1q1X9Q OpO+nm47fg2x3/fWo2O6qY/UyyOuYY8TaPvptV76yVl77nD80SfgFqfVj6lDpWc3qGVlDJfU 1wpqYwsaHOBrdZY57tz9tbn7GLocjAwry4W0tcLGlj+0tcNrm+3+Smk6pD5JvAe6T3Km25vc rtHf4tukvtc5mblV1kktritxaP3fVc3c/wDzUav/ABZ9C/Pysx/wdW38lKNhFPFsyWD85aHT Mqt+Zi1h3uOVjx/27Wutq/xbfVgfSOY/43gf9RUFr9J+pH1Z6Xl152PjPfk0ndU6+11ga7/S NrdDPUb+Y78xCwnV6ST63lv/AIpKO8xKSCH/2ThCSU0EBgAAAAAABwADAAAAAQEA/+IMWElD Q19QUk9GSUxFAAEBAAAMSExpbm8CEAAAbW50clJHQiBYWVogB84AAgAJAAYAMQAAYWNzcE1T RlQAAAAASUVDIHNSR0IAAAAAAAAAAAAAAAAAAPbWAAEAAAAA0y1IUCAgAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARY3BydAAAAVAAAAAzZGVzYwAA AYQAAABsd3RwdAAAAfAAAAAUYmtwdAAAAgQAAAAUclhZWgAAAhgAAAAUZ1hZWgAAAiwAAAAU YlhZWgAAAkAAAAAUZG1uZAAAAlQAAABwZG1kZAAAAsQAAACIdnVlZAAAA0wAAACGdmlldwAA A9QAAAAkbHVtaQAAA/gAAAAUbWVhcwAABAwAAAAkdGVjaAAABDAAAAAMclRSQwAABDwAAAgM Z1RSQwAABDwAAAgMYlRSQwAABDwAAAgMdGV4dAAAAABDb3B5cmlnaHQgKGMpIDE5OTggSGV3 bGV0dC1QYWNrYXJkIENvbXBhbnkAAGRlc2MAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAA AAAAAAAAAAASc1JHQiBJRUM2MTk2Ni0yLjEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAFhZWiAAAAAAAADzUQABAAAAARbMWFlaIAAAAAAAAAAA AAAAAAAAAABYWVogAAAAAAAAb6IAADj1AAADkFhZWiAAAAAAAABimQAAt4UAABjaWFlaIAAA AAAAACSgAAAPhAAAts9kZXNjAAAAAAAAABZJRUMgaHR0cDovL3d3dy5pZWMuY2gAAAAAAAAA AAAAABZJRUMgaHR0cDovL3d3dy5pZWMuY2gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAZGVzYwAAAAAAAAAuSUVDIDYxOTY2LTIuMSBEZWZhdWx0IFJH QiBjb2xvdXIgc3BhY2UgLSBzUkdCAAAAAAAAAAAAAAAuSUVDIDYxOTY2LTIuMSBEZWZhdWx0 IFJHQiBjb2xvdXIgc3BhY2UgLSBzUkdCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAA AAAALFJlZmVyZW5jZSBWaWV3aW5nIENvbmRpdGlvbiBpbiBJRUM2MTk2Ni0yLjEAAAAAAAAA AAAAACxSZWZlcmVuY2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAB2aWV3AAAAAAATpP4AFF8uABDPFAAD7cwABBMLAANcngAA AAFYWVogAAAAAABMCVYAUAAAAFcf521lYXMAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAKP AAAAAnNpZyAAAAAAQ1JUIGN1cnYAAAAAAAAEAAAAAAUACgAPABQAGQAeACMAKAAtADIANwA7 AEAARQBKAE8AVABZAF4AYwBoAG0AcgB3AHwAgQCGAIsAkACVAJoAnwCkAKkArgCyALcAvADB AMYAywDQANUA2wDgAOUA6wDwAPYA+wEBAQcBDQETARkBHwElASsBMgE4AT4BRQFMAVIBWQFg AWcBbgF1AXwBgwGLAZIBmgGhAakBsQG5AcEByQHRAdkB4QHpAfIB+gIDAgwCFAIdAiYCLwI4 AkECSwJUAl0CZwJxAnoChAKOApgCogKsArYCwQLLAtUC4ALrAvUDAAMLAxYDIQMtAzgDQwNP A1oDZgNyA34DigOWA6IDrgO6A8cD0wPgA+wD+QQGBBMEIAQtBDsESARVBGMEcQR+BIwEmgSo BLYExATTBOEE8AT+BQ0FHAUrBToFSQVYBWcFdwWGBZYFpgW1BcUF1QXlBfYGBgYWBicGNwZI BlkGagZ7BowGnQavBsAG0QbjBvUHBwcZBysHPQdPB2EHdAeGB5kHrAe/B9IH5Qf4CAsIHwgy CEYIWghuCIIIlgiqCL4I0gjnCPsJEAklCToJTwlkCXkJjwmkCboJzwnlCfsKEQonCj0KVApq CoEKmAquCsUK3ArzCwsLIgs5C1ELaQuAC5gLsAvIC+EL+QwSDCoMQwxcDHUMjgynDMAM2Qzz DQ0NJg1ADVoNdA2ODakNww3eDfgOEw4uDkkOZA5/DpsOtg7SDu4PCQ8lD0EPXg96D5YPsw/P D+wQCRAmEEMQYRB+EJsQuRDXEPURExExEU8RbRGMEaoRyRHoEgcSJhJFEmQShBKjEsMS4xMD EyMTQxNjE4MTpBPFE+UUBhQnFEkUahSLFK0UzhTwFRIVNBVWFXgVmxW9FeAWAxYmFkkWbBaP FrIW1hb6Fx0XQRdlF4kXrhfSF/cYGxhAGGUYihivGNUY+hkgGUUZaxmRGbcZ3RoEGioaURp3 Gp4axRrsGxQbOxtjG4obshvaHAIcKhxSHHscoxzMHPUdHh1HHXAdmR3DHeweFh5AHmoelB6+ HukfEx8+H2kflB+/H+ogFSBBIGwgmCDEIPAhHCFIIXUhoSHOIfsiJyJVIoIiryLdIwojOCNm I5QjwiPwJB8kTSR8JKsk2iUJJTglaCWXJccl9yYnJlcmhya3JugnGCdJJ3onqyfcKA0oPyhx KKIo1CkGKTgpaymdKdAqAio1KmgqmyrPKwIrNitpK50r0SwFLDksbiyiLNctDC1BLXYtqy3h LhYuTC6CLrcu7i8kL1ovkS/HL/4wNTBsMKQw2zESMUoxgjG6MfIyKjJjMpsy1DMNM0YzfzO4 M/E0KzRlNJ402DUTNU01hzXCNf02NzZyNq426TckN2A3nDfXOBQ4UDiMOMg5BTlCOX85vDn5 OjY6dDqyOu87LTtrO6o76DwnPGU8pDzjPSI9YT2hPeA+ID5gPqA+4D8hP2E/oj/iQCNAZECm QOdBKUFqQaxB7kIwQnJCtUL3QzpDfUPARANER0SKRM5FEkVVRZpF3kYiRmdGq0bwRzVHe0fA SAVIS0iRSNdJHUljSalJ8Eo3Sn1KxEsMS1NLmkviTCpMcky6TQJNSk2TTdxOJU5uTrdPAE9J T5NP3VAnUHFQu1EGUVBRm1HmUjFSfFLHUxNTX1OqU/ZUQlSPVNtVKFV1VcJWD1ZcVqlW91dE V5JX4FgvWH1Yy1kaWWlZuFoHWlZaplr1W0VblVvlXDVchlzWXSddeF3JXhpebF69Xw9fYV+z YAVgV2CqYPxhT2GiYfViSWKcYvBjQ2OXY+tkQGSUZOllPWWSZedmPWaSZuhnPWeTZ+loP2iW aOxpQ2maafFqSGqfavdrT2una/9sV2yvbQhtYG25bhJua27Ebx5veG/RcCtwhnDgcTpxlXHw cktypnMBc11zuHQUdHB0zHUodYV14XY+dpt2+HdWd7N4EXhueMx5KnmJeed6RnqlewR7Y3vC fCF8gXzhfUF9oX4BfmJ+wn8jf4R/5YBHgKiBCoFrgc2CMIKSgvSDV4O6hB2EgITjhUeFq4YO hnKG14c7h5+IBIhpiM6JM4mZif6KZIrKizCLlov8jGOMyo0xjZiN/45mjs6PNo+ekAaQbpDW kT+RqJIRknqS45NNk7aUIJSKlPSVX5XJljSWn5cKl3WX4JhMmLiZJJmQmfyaaJrVm0Kbr5wc nImc951kndKeQJ6unx2fi5/6oGmg2KFHobaiJqKWowajdqPmpFakx6U4pammGqaLpv2nbqfg qFKoxKk3qamqHKqPqwKrdavprFys0K1ErbiuLa6hrxavi7AAsHWw6rFgsdayS7LCszizrrQl tJy1E7WKtgG2ebbwt2i34LhZuNG5SrnCuju6tbsuu6e8IbybvRW9j74KvoS+/796v/XAcMDs wWfB48JfwtvDWMPUxFHEzsVLxcjGRsbDx0HHv8g9yLzJOsm5yjjKt8s2y7bMNcy1zTXNtc42 zrbPN8+40DnQutE80b7SP9LB00TTxtRJ1MvVTtXR1lXW2Ndc1+DYZNjo2WzZ8dp22vvbgNwF 3IrdEN2W3hzeot8p36/gNuC94UThzOJT4tvjY+Pr5HPk/OWE5g3mlucf56noMui86Ubp0Opb 6uXrcOv77IbtEe2c7ijutO9A78zwWPDl8XLx//KM8xnzp/Q09ML1UPXe9m32+/eK+Bn4qPk4 +cf6V/rn+3f8B/yY/Sn9uv5L/tz/bf////4AJkZpbGUgd3JpdHRlbiBieSBBZG9iZSBQaG90 b3Nob3CoIDUuMP/uAA5BZG9iZQBkAAAAAAH/2wCEAAoHBwcIBwoICAoPCggKDxINCgoNEhQQ EBIQEBQRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBCwwMFRMVIhgYIhQO Dg4UFA4ODg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/A ABEIAjIBqQMBEQACEQEDEQH/3QAEADb/xAGiAAAABwEBAQEBAAAAAAAAAAAEBQMCBgEABwgJ CgsBAAICAwEBAQEBAAAAAAAAAAEAAgMEBQYHCAkKCxAAAgEDAwIEAgYHAwQCBgJzAQIDEQQA BSESMUFRBhNhInGBFDKRoQcVsUIjwVLR4TMWYvAkcoLxJUM0U5KismNzwjVEJ5OjszYXVGR0 w9LiCCaDCQoYGYSURUaktFbTVSga8uPzxNTk9GV1hZWltcXV5fVmdoaWprbG1ub2N0dXZ3eH l6e3x9fn9zhIWGh4iJiouMjY6PgpOUlZaXmJmam5ydnp+So6SlpqeoqaqrrK2ur6EQACAgEC AwUFBAUGBAgDA20BAAIRAwQhEjFBBVETYSIGcYGRMqGx8BTB0eEjQhVSYnLxMyQ0Q4IWklMl omOywgdz0jXiRIMXVJMICQoYGSY2RRonZHRVN/Kjs8MoKdPj84SUpLTE1OT0ZXWFlaW1xdXl 9UZWZnaGlqa2xtbm9kdXZ3eHl6e3x9fn9zhIWGh4iJiouMjY6Pg5SVlpeYmZqbnJ2en5KjpK Wmp6ipqqusra6vr/2gAMAwEAAhEDEQA/AOw5SlvFXYq7FXYq3irsVdirsVbxV2KuxV2KuxV2 KuxV2KuxV2FXYq7FXYq7FXYq7Eq7G1dirsVdirsVdirsVdirsVdgV2KuxV2FXYq7FXYq7FXY 2rsVdirsbV2G1dgV2KuxV2KuxV2Kt4Vf/9DsWUpdirsVdireKuxV2KuxVvFXYq7FXYq7FXYq 7FXYq7FXYq7FXYq7CrsVdirsVdhV2BXYVdgV2FXYFdirsVdgV2KuxV2KuxV2KuxV2Kuwq7Cr sVbxVrFXYq7ArsKuxV2BXYq7CrsVbxpX/9HsWUpdirsVbxV2KuxV2KuxVvFXYq7FXYq7FXYq 7FXYq7CrsVdirsVdhV2KuxV2KuxVvCrWCldiFbxV2NK1jSuwFXYq7ArsVWu4RGc9FBJ+jFWE S/mZbB2MFkZYQxWORpRGW4nixVGTBumkPN+a1vb25uZ9NdYht8MqluVaU+yuO60iE/MoMoYa aSCKj9+vT/gMO6ub8y4owWk01wi/aKyqT93EY7o2W2f5o2N5CZ4tOn9KvFSWjqad6VwbppN9 F86WGrX4sPQltrh1ZofU4lX4Dk6q0bN8Sr8XxYQUEMkw2rsbV2Nq7CreFXYq7FXYFdhQ7FLs VdjaH//S7FlKXYq7FW8VdirsVdirsVbxV2KuxV2KuxV2KuxV2FXYq7FXYq3hV2KuxV2KtYq3 hV2KuwK7CrsFK7FWsVdgV2BVN5guKoR9ThRqFsFpQt9rEK2cxVvi4NQfRjah4heW7nTbe55g ejMvJT1IduP/AAWSVPvL1pa3c0aXcazW4qeLgFeVR9rArMY9K8t+nxl0RkZduSREoR4oy/aX BZZi0Tp+h+Uri4Fv+jPTmZSyiSNgrBact/s/tfZyUSUG2N+ZfLdnpupHTtOpbW95GJVi3KRu xZH4/tem3Dl/kYTzRdoP8s4pYdfjt7o1ngN1HWtQWXjup/1cDF69XxwK6uKt1xVvFXYQreSV 2KHYq7FXYpdih2Kv/9PsWUpdirsVbxV2KuxV2KuxVAatNexWy/UWRZ3dYw8gqi8jx5tTAUhj hk82SaXc3S6kkV/ZyvHcweirxgRnl8H7bc4Skv8As8NebLZl1u7SQRu1CzKCxXpUj9nFgq4q 7FXYq7FXYq7CrsVdirsKt4VdirsVdirsUOxV2KXYq7FXYFdiVawK03TAqEuPsmmApY7dGkrY pS/UWpZzf6h/Vih51cuDoQSgqZoiKeAcZJCe+UYzNexW5H99VRTrucCUVcebPNulXVxp+nvH eWVpK0MU8pCseGzJxKt/ct+5/wCeeDh82RITHyv5+1u78y22lawipDcxSGIxqP71KN8TD9j0 +X2f28aIYlH+c2/52SzHYQJ/yckyRXok3khKecpu1HuiB4/DGuKHqWBW8VdilvFDeSCt4UOx V2KuxV2KuxV2Kv8A/9TsWUpdirsVbxV2KtE0xVYZKYqs9b3xVBa3cyRaa8kcJuHDIBCuxYll XiP9bAUhjkF1qktrr0MemycFP7gswEwl9JG4SIT+8jjbj6ci/sYiLMjzZPoFxPc6PZzXMfpX DRL60e9A4HxdcLApjhQ7FXYFWk4q4HFWxireKuyQVvCrsUOxV2KuxV2KuxV2KuxV2KuxS7Ar sVWt0wKhLjocBSxu7P75sCsW8x+Y4LJxYCF5pp1NOOwH7PU4QrEZo9Qms0g+qhCjq6ksaHia +GSQmmg6re6VeQ3L6f63oH4VWQAn/gh9rIlKrPqsj3N3L+j5ClxPLOlXUMBKxko4HJeS8v5s QFKHtb+4ttc0/VVs5ONk7M0NVPJZEMT0b/J+1iqca95rW/1q31CGxuPRiijR434q3INIXA+L /LT4sd0oby3rsem+YJdQurab6sZJihQKW4SqgXknL7SsmJWnpOi+bdH1m6a0tGkS6RPVEUyF CyV4s8f7L8W+3ihPMUN4q3irskFbwodirsVdirsKuxV2BX//1exZSl2KuxVvFXYqsbFVCTFU KxPIYFVWP7knrxIP3EHFKKSNFuZXA+KRULe/HkuWIUtM/wB5FX+UlfuNMgElF4UOxV2BVpxV odcVXDFW8VbyYV2KuxQ7FXYq7FXYq7FXYq7FXYq7FXYparkVUpJAAcCpXd3yqCK74EsX1S/9 KOafqEUt92+KXma393qWsW95OhRHNIVO/wABHKp/1v5slyQWRzmrUrRVFSflgQx6bzSYp2ij teSjYO7cfwAxSqReZJ2FfqPIHwc/804oVl8xzf8AVtdj2o//ADbjula/mgRuFn0uZFHVlYE8 f5ghC8sNKntu8VzbpPbsJIpVDI3iD7Yqy3yZpSPd/pJqLJbq0cQU0Yq9PU5r/J8PwYqzjAh2 Kt4q7CreSV2KHYVdirsVdhV2BX//1uxZSl2Kt4q7FXYqtYYqoSDFUHJs2BUJqutWOm21Lpip lBWMAVJJxSlKfmPZtcRILKXmQyzAsooAV4PE3+7OXxcuXp5LiPctN6T55txqa6XNaSL9Zmb0 ZgykAOxZeabfZ/yOeAKWbYUOwq7IqtOKtDFK4YobxV2SAVvCrsUOxV2KuxV2KuxV2KuxV2Ku xV2KVjdMgqEuD8JwFLGr5jzO+KUj1JPVt5Y6A8lIoehwoYVdcItSsowgHpooQCnw/s0whSmd 0WFrduDR/SYg9dwK4qwu3hWWyN1IaygKfY4UMu07SoWtYnpTkob78Coy30omOki0cE0KE0I7 dMU0o+c9GFhpGn3qu5aRiq8iW7V+GuG0qPk1+WhxEjpJJt2ALnEsWceXix1zTK7UhuNweo+H 4WyKWe9cUN4q7FXYq7JBW8KHYaV2FXYq7FXY2r//1+x5Sl2KuxV2Kt4qsY4qoSHFUBPKAcCv OvO2uG6uFsQgBgbkJQd60O2ISxm2neS6HqO3IbA/7WSAQjbxpInSdHZZkIZHU0YEftKcVepe Rtau9W0cyXkgluYZDG0lApZaKyMwX4eXxYqyXElWicCrK4q7FVwOKrsVdhCt5JXYodirsVdi rsVdirsVdirsVdirsVWN0yCUHcmiHAUsXvG+M1xSlNwfgb5YoYVfEDVbeopt2+eSC2mF5T6h c/8AGJt/alcVYlZAnRTTcsUQU33+HbCxZ9Z0jgjWu6im+AsgiLAzxoRcurtyNGXpxr8PX/Jw Kt/MFhP5N06Zd/SujHIR2JDYpCQ+TwToMHgXep/2ZwliGfaAqrrumKooBbXDfRVMCWdYodir sVdireSCuySHYVdhV2KuxV2Kv//Q7FlKXYq3irsVccVUnbFUFcy8QcCpRPOSTvil5d5hcvq8 hrWh2H0YQhLbVj9bXpSu4ySp1qUdbYGldsCso/Ky/wCNzdWTHaZA6/60ezf8K2KvSjgVYcVa xV2Ktg4qvGKt4q3kwrsUOxV2Kuwq7ArsVdirsVdirsVdiVWN0yCUFdfYPywJYpet+8YYsksu P7tvCmKGFXwrqduGNB2+YJ75IIKYX+2mXfj6TD8MVY7p0a/oqy5bepKGHyT/AK4xtDIF1ACo JoOmKrYb6SCEI8okcVowFKiu3w4FVtU1Nb7ydqNox5PbyxXEftQ8TiClZ5MQ/oK33NCXO/uz YSrP9FUDX9MFelhO23f44hgVmmKHYq7FXYQFbySHYQrskrsVdirsVdir/9HsWUpbxV2KuxVo 4qoSHFUsvG2OBUndvtfTil5nrzEapIfc7YQhLLdh9bXs1aVySslufitfemBVPybffUdbt5a0 CyhX/wBV/gbEq9wOBVpxS1ih2KW8ULxireKt5NXYodirsVdhV2KuxV2KuwK7FXYq7FVj9Mgl A3Z+BsBSGJXu8rYskvuP7tvkcWLDdRubWGPlIGE6sksD/ssEYJPC3+V6T+omEKib+UHSrtlN V9FiCPlhQkLzRix02CLcQQ7n/LIAPf8Am9V/9niUhTNw1O/viq1pnpTriq1LiUJMlTwlQqy4 qzDyLbl9BtAN6s2w8CxxKh6HpMUb+ZR6BDJY2QimI7PKyui/8DGzYApZTih2FXYq7CFbySHY QrsKuxV2KuxV2Kv/0uxZSlvFXYq7FWjiqHkxVKr47HAlJ3PXxwoeeapbRya2Y7hmVX+zxoan CFSiUwW17wHxoD9o7YVT2W9tTbhQd6dK74FSvTn5X9EOxOx7+2KvfbF3ksYGk3kMa8j70wKr HFXYq7FW8VXjFW8VbyQV2FDsVdhV2KuxV2KuxV2BXYq7FXYqtYbZBKBuVJQ4Clid+hWY1xZI CQVG+KGKahYxJO0Uih0BEkdd9ujD/iS4otS06KKRLizkAktkYoqt3jI5Irf6q/DhQjvqVgAB 9WjG1K8d9sKVQafYU3tYqf6owJsrhp2nbj6tH/wOFbKoum2INUtkU+IFOuBbTXQo7XSYHMCe nDbRu6JUmhoW7/5WJQzfy9py2OnIzCtzc/v7mSlC0jjkxxQm2FXYq7FW8kh2FXZJXYq7FXYq 7FXYq//T7HlKXYq7FXYqtbFVCTocSqVX/Q4EpK5wqwLzhGPriVWtTtU8f+GxCsYuFZJ6vxqa dX5k9B9vJoT2lm9opM1lyAqAVYN9+RSgrRxHqEZjZWI6NEafdyxQ990eYz6XbSFizFBUkcTX 3GBUXil2KHYq3iq8Yq3ireTCuxQ7FXYVdjSuxV2GldgV2BXYq7FXYq0ciUoaZRQ+GApY1q0N KkYEpI4xW0h11QGVu/E1xVKdHestyDu3IV/4Ff8AgsIQU3XfFCui0xSvAJOFVZR/mMFqiCB+ jr3arelQHwqyjfEq9LiFI0HgoH4YUL8VdireGldhQ7JK7CrsVdirsVdirsVf/9TsWUpdireK uxVo4qoSYlKVXw2ORVI5PtHJKwzztF/dycQVBFQxoMQrDbpkDqVWGPpX0SSK+Jr+1kkMks7w tYqn1uHpvG0BNPppgSljOBqKEur9gyLx/wCFIwoe5+VXL6FakljRaDluaA9m/aXIqmxxV2Ku xVvFVwxVdhVvJK7FDsVdkqV2BXYVdirsVdirsCuxV2BWjgKQoyjY5FWPauPhOBmx58WKQ66d 1/1WxSkmiBTc3Q6/ENx/qjJBinqgbeOKVdBvX7sCqgG+Kq6KK1GKUVx/0G6INAUUfe6jAr0c Cige2TDFvGlbxV2FXYQh2SV2KuxV2KuxV2KuxV//1exZSl2KuxVvFWjiqi+JVLL4bHAqQyij nFLF/NsYcRB15R8hyHiK4VSvXtLso7KKe1t0iam5UUwoTDy64ktPT4DYdKYlKR6/H6dwrAUo e22IQ9K/LaZm0+eIseIIYKTUbjfj/LiVZkcCXYodirYxVcMVXYq3kwrsUOwq7CrsVdirsVdi rsKuwK7FXYFaORKVGWmRVINXHwE5FmGOPhQkGvtRa+EbHFWK6LcXVZJIgDy+3U9DTJ0xtPEv boU5KPngVVF3dg14fjiq8X93/vvpgSqpql0NuG+Kqx1i6ReEkREMzxxsw7cnVcCvYhSgp07Z MMW8KXYFdhQ7CFdkldirsVdirsVdirsVf//W7FlKXYq3irsVaPTFVF8VS696HIqkE32zhSkP miAyWDMo+JRUfPCrHJZnn0nck8R0rXcdsUO8r3JVmSv0HCQlZ5nJLpTu2+IQ9B/LQD6nMR/k /TtiUs2wIdireKuxVcMVXYq3k1dih2FXYVdgV2FXYVdgV2KuxV2BXYq0ciUqUvfIpY/q5HA5 FLHJBhQUh1ujSBT/ACNilhWl6XdXHIRlk4n4ivY/I5NiuttJ1Y6zJan1liC1ExBCHw3PwYqQ mh0K+GwuJaV7AdP+CwJXroeo9rmT7v8Am7CqW6vY61aS2vB5pPVbieANBU/tfs4rSbzaPrdr AboyvJDBwlljUGhRWVm7t/xHAtPeoXEkSONwyhgfmMIYqmFXYq7FXYq7Jq7FXYq7FXYq7FXY q//X7FlKXYq3irsVaOKqTjFKAu1qpwKkFwvFziqXarCJbGVSKjicVYXp8fqW00J2ZKinyySo bQKrdyJ036fLFVfzEBwVjsAwBJ99sCvQ/wAtFYadKSCOlK/LFSGaYodirsVbxVcuKrsKt5JX YodhV2G1dirsKuwK7FXYq7ArsKuwK0ciUqMtaHxyJSx7V/snIsmPyb4UJBq4rdBe5QgD54ql Wk3+nC5lhSQLsCeXwkMCVdPi/aXjhQna3MbJRZlIHT4hTFC5XQ9WBPsRileHUj4WFT03GKrf VZGqZAB33GKpimoWA0y9NxdrzeFoY4x9otIPTULx+Jm5NgTb0SxjaOyt4nXi6RIrL4EKARkw xROFDsVdirsICuwq7CrsVdirsVdirsVf/9DsWUpdirsVbxVrFVj4qhLhag4ClIb1KNXFUDIq tGysKgg1GKsAnW/tLyeSyWKSMvxZZHKke9KfZyQVK7dtVhunljaFZWJJShcV8NjiqInvpLmx 9TUYUUs5R03Vdj1rjSHrf5cRrD5Zgt1QhYiwRz1ZWPNd/wDJ5ccSksoOBDWKt4q7FV4xVvCr eSQ7FXYQrsKuxV2FXYq7FXYFdirsaV2BXZEpUZFqMiqSapaSOpoMizDHpreVeowqkmqWM0rr LEQJFFOLbA4rTENb0S4ZmupIvTkP22RhQ+5X+bCChKEsJCKvLIq9mC13998LFXi0q6ehEzj6 Afu+LFKPj8vXjws8N9KZV/3UUIqP9bngVH+W/J9/rbyR/XG9WPd4hIqsF8Wjk+P/ACfh9RMU vRPLf5Z2GlXsWo3c8t3cwHlAjkFEY/t8QPjdf2MIQSzrJMXYq7CrsaV2FXYVdirsVdirsVdi rsVf/9HsWUpdirsVbxV2KrGxVDyrUYCqT38e1cCUqYYVYN5lt501AvaGOOQgUEgNGPhhCpAk OoJduwmiE/7SqtR/wOFCvNcTG3DXyr9orICvw8f5qH7OKvbPJUTw+WNPhZOAjiCx+6dY3/2S 4ElOzihbirsVbxVeMVbwq3kkOxV2SV2KuxV2FXYq7FXYq7FXYFdgV2KtEVyBCVCWIMpwJSa/ tuIJAyLK2K3VfUIIp7YUJNrNvPNakQIHcGpBIXb6cVYeZrgN6DKnEeAJIp8sIQjrOTlKEooS mzKD+o4UJjNc3ljGXg9Nw3Zwy/8ADYEsv/LrSL76y2szel9XlRo09NwxqSP+BxV6Nk2LsVdi rsIV2EBXYVdirsVdirsVdirsVdir/9LsWUpdirsUuxQ7FWjiqk42xKUsvUqpyKpJKtGOFWLe brcOkLljFRh+9ABoe32sKsQMMrXNXunMvTkFCkj5YUK0jSw2xa4JkoSrsF/YO1WVf+JYpe7e X47iLRbKK5p6yQorUpTYbfZwITBsVWYq4Yq2BiqpirsIVvJIdhV2Kuwq7FXYq7FXYq7CrsFq 7FXYFdirsCrW6ZBKAvEqhyJZBhepJxnIwpKWXiPJbSLGAXp8IJp+OKGATahdQ3DkW4J5FWBb oQafs5JCvY3N0ZeQ9NT/ACnkevb4cCoq51XVJP8ARpLFV8JBIQh/4NcVet/l7pdxYaJznCg3 bCZApr8JVVWv3YQhleSQ7FXYVdhV2FXYq7FXYq7FXYq7FXYq7FX/0+xZSl2KuxS7FDsUtYoW OMVQVylVORSkN0lHwqk+tafNf2L28Kh3O4ViBWnucVeeyi8W54mACSI8GDMKVXY4VTTS7G51 nVYdJotpLOjMspYuvwirKQvHCr2+yge3tIYJH5vEioX8eIpXAhXIxVYRirsVbXFV+KuyQVvC h2Kuwq7FXYVdhV2BXYq7FXYq7FXYFdirsCrT0yCUJcD4TgKQw/WQRcGuIZFKZkLRuq9SDT54 oef39xdW97IptwHVqOCa7n/VwhSFWwnuGfkBGp8PiNcKETPf6nKTDLbxgLsH9QgH3+JcCXtX lPS5dK0O3s5ipkUFzwPJRzPKinCGJTvJIdirsKuwq7CrsVdirsVdirsVdirsVdir/9TsWUsn YodirsVdirsVWEVxVQlXbAUpRfwChOBUBAo50OFXnGprw1W8UDYTtT6d8QqYeV5PT806VJ0r IyH5MpySvacCHYqsOKtYquXFV2KuySt4UOxV2FXYq7FXYhXYVdirsVdirsbV2BXYFdirRyJS hphsciUsR1wUlB8cAZJM4qDTvhQwTWGurbUHElv8Q/aLDcfzVH7OEKWrG4nMwZFjVxuVYn/j UYoRs17fX91FaGCJXeVIqmQjdyFVyGX+7xV7holi+n6TaWTkFreNY2I3FR/L/k4QhMMkh2Ku whXZJXYq7FXYq7FXYq7FXYq7FXYq/wD/1ew5SlvFXYq7FXYq7FVpxVSk6Yqll79k5FKUxNSW nvhV57ryhdbvR0rIDQe4GFXaVL6Os6bJ2W5jr9J44qHumKHYqsOKrcVXriq7FXZJW8KHYq7F XYq7CrsVdirsKuxV2KuwK7FXYFdirRyJSoSigORSxXX13BpgDJj7EjChhnmBp7fUQzwlgRVG 5D4l/wCbcVpDWN24uvVEa0/lLgH9WSQmkLS63qtvpqxpDJO/piSRwUrTn2Xl+z/LgV7hp8U0 VlBFOAsscao4UlhVRx+FjkghFYUOwq7CFdhV2KuxV2KuxV2KuxV2KuxV2Kv/1uw5Sl2KuxVv FWsVdXFWjiqm/TFUsvh8ByKQkimk2FLA/M6hNfuO3JUb59RiEIAyFHglHVJY2+5lySh79E4e NGHRlBH0iuBC/FVhxVbiq5cVX4q7JK3hV2KHYq7FXYq7FXYVdirsVdirsVdgV2KuxVo4CqlK wAOQLJi+vulKVwBkxW4uYYBylYKvicKGHa3efWb3nbRvconRlFV9xXDSELY3k63PJbJ37BRx Bwqml0dQubiCSXTJYIFdDJI/HZQylnXh8XJVwJez6b5n0LUZUt7K8WWdhtGQwfYftclHxYQW NJxkkOxV2FXYbV2FXYq7FXYq7FXYq7FXYq7FX//X6/XKUt1xV1cVdirsVdXFWjiq1+mKUuvR 8ByKhIH2lwpYR54T09agl7Sw0p8iMIVJ5eRt+Q3oCRx33Arih7vos4uNIspx/uyGM/8ACjFU cTihTJxVrFVwOKrwcVbxV2StW8bV2FDsVdirsVdirsVdirsVdirsVdirsSqx2oMglKNWunii JXIsww68u5ZW+I7YVY7rT1jIPSmKEh00kh64UKmnnjf9epxCs0vFrp4PgMWQQPkRv+dmhBND Vqf8CcWL2HJhi7FXYVdhCuwq7FXYq7FXYq7FXYq7FXYq/wD/0Ov5Sl2KurirsVdirsVaJpiq lLKqjfAlLLy7j4kVwKxDX9QuLSP1rYrUdQwqMKsX1L61rUEVzdzBZYAfTMaAbN+y27csKbS/ TLZp5fRlmfh0+Gg/hhQy2bUda0nT0hsNSlSJBREYI4UfygsvLjgTaE0bzd5kvJnW41GRlFaE BVG3+quKHrEEhkhjkPVlBP0jFVTFDYOKthjilcGxQurireKuyQKt4Vdih2KuxV2KuxV2KuxV 2KuxV2KqcnTIJSHWx+6bIswwy4PxYVSTV90J/wAnFBSGxmREapHfv0+eFAX2MqC8DMygV2NQ MU0zK5u4m09QrqRTswP8cCoHyPMh80WyqwJLtQAitOLDFS9mybBvCrsIV2GldhV2KuxV2Kux V2KuxV2KuxV//9Hr2UpdirsVdirsVdiqxzgVA3ZPE4EpBdsamuFWN6/vbNXwxVJrVgbAgncD CqX6W5F6fnuMVZHqzcrP6MVSDQpON461AG4398Sr2+xP+hQf6i/qxVEbYobGKtjFVwxVeMVb xV2FW8krsUOxV2KuxV2C0tVGNq0ZFHU4LVaZ4h1YDHiWktv/ADLounLyurpE7cQamvyGPEnh Sd/zI0EEiKO5mp0KxUB+liuDiKeFQb8ydPI20+6I9/TH/G+K0l9757tbhSo02eh6EugwUljd 1rEsz1isyo7gyD+AxpFpfeGS8XjLZo4G4DSEU/4AYaVKP0HP9YWaKKJAhBEbMWBp2IOKqq6V dLfrexRWyFTy9EhvTqP8gYVtHavFPqgQmzs7VlpyaEMCSPoXAtsn0LzVc6VYQ2n6Is3eAUWe JjGSPFgY3/ef7PFU2/5WNqH/AFbYh/z2P/VPGytB3/KxdSptp0P/ACOb/qnjZWg1/wArE1Y/ 8eEA/wCej/8ANGGyigt/5WHrXaytv+Df+mPEU0FWL8xNRBHq2ELjuElZT/wyNjxFaCa2Hn7R rh1jvFk0922Dz0MNT2+sISif89fTyQkjhZOrK6hlIZWFVYbgg5NiuxV2KuxV2KuxV2Kv/9Lr uUpdXFXYq6uKXYobxVY2BUFdqSuBLHr4FSa4VY9q0clxAyRAFz0BNMVYxG93BcppksPCeQEq /McKDxYf804VQtul1ba0LOSMCZzVauOFD4MBhQnnmCW6062T1okcPQApLXr7FcCVPyjoTalc vMdQtIFADGNnJcg/a49F+D7OK09ct7mxgt44TdQn01C15rvT6cCrjqemr1u4R/z0X+uNrTR1 nR1+1f24+ci/1xtaUz5i0BPtalbD/nouNrRVINe0OduMWoW7t4CRa/icNrRTJWUgEGoPQjpi huuKt4q7FXVw2rq42rq42q0uB1wKoyXCruT0xSgJ9URa0OC00ld3rrICQaAd8VYTrHnC8uJX trF6U2eYnYHwAGICUohTk5mmczSnq7GpwoJtFc6jYbDFC0E4q0ScKtUNeuKt8TirYU9R0xV3 HwwK2FxVdxNPfFVw64q4r374pb44obIxVsDtiqoACN9weoOKo7RNW1HQZQbImbTyf32muaLv +3aM3+88v+R/vPJ/xX/eYQaTzel6ZqVrqdlDe2jcoZhUdKqRs8bj9mSN/gkX+fLAWCMwq7FX Yq7FXYq//9PrfIZQlaZFHfG1WG4Qd8bSgNR8xaZp0Rku7hIlHYnf7sFqxK//ADZs42K6fZPc eErngn/NWSpNJPL+a3mJ/wC6traIHxDMcaXZCS/mT5tfYTwpX+WP+3GkWhJfPXmuUfFegfJA P44aW0BN5h16f+9vWIPgAMaVCPc3ku0l1Ka+DEfqxpCHe1EhBkkkcjoWdiR9OEK0bOBvtAuf 5mZifvJxVUFlbnYryp05Et/xI4pVUtLQUpEtf5u+ArurrFGBSnTtviU2V3pxdgMCLLYji7ot e22+K2vWOKuyL4bAYqqCKIndBX5DFbTTTNT1PTmDWF3JBQ14BuUZ/wBaJ+SY0m2eaF55t7jj a6xxtLk0VLjpbykmgAZv7mT/AIrlxRTLsUO3pXFXVxV1cVWM+Koaa4CiuC00k17qHUA4EpTN dbFmOwwpYV5k1uSR/qkDEFvtsP2V/wCasQEWk1txUBU2A8MkqZwDucUIriaUwK6mKu44q3xx VsCuKt07/firuOKrqYq4DfFW+OKrwv34q7jviruPjiq4KcVXKMVVOO1RiqYeWdXOiasqyGml 6kwjuKmixXB+GC4/yVm/3nm/54PhBUvT8tYuxV2KuxV2Kv8A/9Tp8k9O+Y7JCy3VO+KsY80+ ahpdvxi+O5fZE9/E4q8wvL25vpzcXcpklPj9kf6i5MBSo8+lMNK7mPpxVsMfp8cbVuu+Kuri heKeGKVwp3xQuAqflgSvB6++FV69f14FXilela4Vb7V3Fd6HqMitt122xpVyUP04VVVNMbQi oTgSj0ijliMbqGjYUZTuCD44qy3yRrc8cx0G+l9QBeemTOfjZF/vLV2P22h+1G3++v8AUxSW bVxYu8cUrWO2KEPM9ATkSkJNqFzxB398QySGWfkxJOFUo1W9EcZUHfFDB5JS8zyE1Ltv8u2F VW2Y8gD88khObcdMiqLVcVaO3XFNIU6np6yiF7mNJegVmArhQi6fjgVv6PpxVulMVbA23G/b FXU3pirYXFVyr44qvI23+/FUovtetbQsCrylNm9Ja0+ZxTSJ0rVLPVI2e1kLPH/exOOMig/t Mv8AL/l4aQmAWmBK9F3/AI4qrcNtsVQ1xCs0MsDHaRStfCo64q9L8sX76joFheSbSyQqJa7/ ABp+7k/4dMsixKbZJDsVdirsVf/Vn0sx8cx2SVarqK2drJMx+yDTCrym/upru4e4mJLuaipr Rf5RhCoEnf55JDq074FcDXCq4eNcVXDGktjY4qvqO+Ktjv8Aj9GKF3v92FKov45FVRdtsQuy 5aDc7V7Yqv8A86YKQ0ABsSK/fhCr167fScCVRf8AOuKETCa4UpraioGBVe6t5XhEls3p3tuR NayDYrIvxLQ/5X2H/wAjFL0vRtSj1XS7XUEHEXEYZl7q3SRP9i+KEbihTY4qgblyAadsiyDH NWlIqMLJIpp+KnFDGtTuC7NU7dPvxVJG2NO1dskhXtCeVe3iMKp1bbgfqwIRYJptgVK9duZI bWgbh6h4l/5a4pY5bfolLqa01mOYW0kVEnhAMsM32o7gxuP30TfZkh5/YfJBCd+Spp5tMmjl YutvLwjY7/CQDxwSVP2FMCXAVp+rFDdO3bFLYU4oXKtMVXqPpxVqVTwbj1ptirz/AFAmG59S 0m5CF6+um7Ucn4ZVP++viRlkxDIhU8qi4fzRE8J5KA5uCg4rwYeC/ZXnx+HJdGD0SVArEZFk Gl2xSrqNsCoWchWwoZt+XjlvLxBNQtzcBT7eoW/42ycWJZRk0OxV2KuxV//Wmcj1yhkxLzfO 7hLcH4erD9WKsJuVK5IIQR6muSVsf7eBW6YkKpT3Udv1+Jv5RjSt2l9DctwAKSAV4nv/AKuG lRJ2wJbB8dsBVcCO+KriemKrwd98VVF6b7e2KqtaAGmKoa8uvq8TSAbjpiEJI1/fMwkecwch VBxqpH05JCcaPqMl4jpKAJ4jRuIoCP5sBCU0AHTIqiIeuKU4se2KppGKbmmBLIPIclLC9tP2 ba7k4DwWSkv/ABtiFLKMLFSc7YEoC66H8ciyDFdYemSVjd5OQCMVY/dvWTfoaYqgZtqnt45J iutWofnhpU9tT8IwKjVFRvgTSheWcN3A8Ew5RuKMAaH6Dihj8/lOeSWiXKLAQFJ4t6hC9OXx eny/1eGG1ZBpWnW2mWn1a3qwryd26lj3wFQijvil2BC6gxSG/lhQuHXFK8UxVeBipS658taV dyyTEy28swpMYH4Bx/loysjYpR+kaRpeixOtkhLyGryyHk5P+tiSxVnqzE4pLQWp2xSiVG25 wKlt83EnCgs2/Lg10CT/AJi5v1rkoMSyzLEOxV2KuxV//9eWu2UMmI+YHD3jJ3AFMQrFL9aN 064UJcTv/DJK0DXFVQGnXpilLJY+VxP3ZBVRUA0/ya/awoUbYyfWYzvzqCPCmFU9kY8jkUtA +OKrgdvfFC5WIp/Niq8H78CV/KpFdz44VXhu3XAVQmowtcQNGDxJ6H3whUmuuZZEMciyAfD+ 0OXfj/kYUJ3olpLCj3E5/fTUFO9B44CbVNFPgciqIh2IxSnVj0GBKYs9AMUp15Db/StWT/Li b70woLMDixU398CpddtQHIswxHXH7/jkksUu5KnFBSe7YiX37VxQhZyKE/cckrUDfFiik+tK FRiVR618MCSuY4q7b5YodXfAq6gpscKXbU6/PAhsHCoX9RtirYpilcDv7YqvqMUu54quD4FX r7b4oXofi6YqieI4Vp8sUpLqLUrXCgs3/LNuXl6U+F3MP+I5KLEsvyxDsVdirsVf/9CTyvlD Jietkm+bw4ihxVjupD+uEISduv8ADJK4Hb5Yqur4HFVG4tobjdxRx0YdcKutrSK3bkpLN2J7 YqiCSep6/fgSuBoPbFVwOKtgk4lC8HxxCVynFbX1O2+2Kr6Bl6b4ElpI+J2xtCIXYV7+J6Yq qgjw6YFV4dmp44qnmn1oMBSEVOwCgdsQpTfyFJXVdTX+aOFvu5DCpZzixUn6YEpbeHY/dkWT DddNAckrFLg1Y4qUpvD+98TTEItDynY5JVkBq4woZBZmijAqPVthvgSurtih25NP14q2Tird dsUuxQ3X8cCVwNMKr1piq8dMVcQfoxVtU98CqigdMKVw679PHFVRTuPfAqMShTFWPaqwq3hh CCzb8rTXy5MK1peTfjwb+OSixLNMmh2FXYq7FX//0ZDM+UM2K62x+uD3XFCR6hvHUYqkrHen TJoaBxKt1xVwIrirdSRirddgO+KrgaUxVvl7YErlNPlhQu5d8Urlbp74qqA/24qvUkdzgKVR TU74qrL0wIbBI3xVXgffFU/041Ap92K2iLs0XAyTL8v2rrWoAn/dEZH/AATYsSz/AAoUpPbA lLL2pB98DJhev1phVi0vXFUovD+9J9tsIQoSE8dxTChThY89+vY4VZBZk8dxkVR6eGKV1T2x VcKjFXUauK22FYdsUNlWGKbbAJOKrqEDFbbBAPUU+YwKvDoDx5D7xhW2xIld2UfSMVb9aMH7 a/8ABD+uBLjcQru0qL82A/Xiq0ajZ1p68dfDmv8AXFV639nyobiNf9mBjao6O/08Rmt5AD2H qLXFUi1CaG5k4Wzeu7GirFVyT4AJywoLPvyys7q08vyx3UElu7XczqkqlGKngA/Fv2WpkosS zHJodhV2KuxV/9I7mbKGbGder9YQ07YoSO9YGPb7jhQkr0579fDJAK1virYONK7rhVuuKurv tiFXA4CrZOKtg74KVdU03wlLYY9z0xVVV6dT7YqqBq71xVUUknfFUQhNCBgVvkPowKvRqEY0 qf6Y/wAI/XiqLvDRMCUX+X0n/Ox3S/zWw/B2wrb0jFCxhXAhCzwhh03wFkCxrXNPV0Pw4smA 30XpSsn3YUMd1YyIjyoacVow9sIC2m9n5f0y70v6zHdSSXccavPCsg5ISBu0dOfHFCTPYMis yu6kdAaGmEIpSWa/XZbh1GKqvr6ht/pUn0HFV3qXxNRdyjx+LbGlUHfVQxK3bkf5THDSV1pc OJOOoXF2qE/3tsweg8DE/H/hWwEdyhMbyPTQ8H6M1me7jl2kjuIZYpom7BuHOObn/wAU/Hkb LOgoAFLxLeWWZzIQEeMuy/M14NxxtiQQn8WjKGVpKtDWkm7E0P7SHl9pcKAUdbabZRKVeJZC rEBjU1/4I40to2GDT1oDZRH3KA40qubOxbdLOAV7GNT+vBS2hp9KsCfUlhhQDrxjAGEKSqQ6 fo8ibWBnVu8cC0I+dMSu65PLGjrIJrTSbi2uO0vqRon+yiuPVh4/888id0gptYeXrgCWcXFo LmhJt3t4biL/ACZJEhX1IH/n9J/TfIsrYX541G3Ns9jcWFrDfsP3V1ZFZrZwCOfHkI7i1l/4 rlV/9fJhTs869Ohyxrt6N+VBUOQAA4vo/j25AFF7fy5Eoe6ZNDsKuwq7FXYq/wD/0zaZt8oZ sb8xEq8LdK7b4oSO6P7uvjhCEmlJ5e2TQWq7b4pdywK2CMKu5DxGBXc1rXkKZLdWxKn8wyKt GeEHiXAbwPX8cKuNzCOjY0rhdwgfaxV3123HRq/RgS2NRtwe/wB2GlXDVIh0U/djSt/piIGo Q40trxrgHSPBSom3u7+5jaaCBTEg+JmdVp78WPLIlITGzgilsnu59YsLSZD/ALySGRpCOg48 Rxbk37KYLZCOyETzTqFly4QwyoDRWq1DT9pf8nJ0wKncefdSlHEW8Kj2Df1xpNs2/LOdpPMs juatNZhulKUb7I/1ciUPV64ENHFVjbg4pSjVFDRnt1wMg851iEG6OFLFtejCW0hG3w98IRbM 9H0CzuNP0++QyQ3noRqZoBGAyFQTHJyVuS/z81xQx3X4ktNQuYIweCkABuu49sUlIxua5Jiq BSa9hildxIG3TxwKhWkuFc1QOO2Kr7eRHlPqyJAFoQsqvxcD7S+rEG4f7Jfj/nxKhkUciaTP aalpl9Yuzt8Ets5doGpR/WhuP3sa8W48+L80yslspF3fmW5bUa6nLHNdSj92ycTE6kbBGt+U X/DYYsZIuLUvWWkETKSN+RB39iuSDBF2fMryYCrGpwqi16EEYErqkNiluRoOJ9WhX9oN0piq XJBpMTFrS6uLN/C1mdR/yKb1I/8AhMFLxKEdnBBdtdAXOp3D9VuiyqR/Kpj+CP8Aa4/uP9fn g4U8af2c9/aM1zZaXawqR8EaSfV7mh/Zkl/3nk/4TBSbthHn/V4L6eKGOCW1uI1b63azoEkU 7em3JC8U0b/FxkifJAKTswigocnbUz38p6G/k+Ec/rMQD96cfs4Cr3jJBDskrsVdhV2Kv//U OruIoemUM2Pa/ZW91ZSNKD6kSlonBIIYDbpirz1XmeASF2LHqASd/bJsVGWO7ReUsckXtIpX /iWFVDnIf2jhCtFpO7HBSt/Ge5w0rt/lhVciNI4RdyfHoPc/5ORVFz6UYWRXvbMhhXkk4cD/ AFgi8v8AhcGzLhKYanH9WsYrQa7a6pbGkiW8SSOUPT+8liRoW/yPUwD3JISgIleI3HYnJMFa OJWQH7xiVUJY0VyFPw9q42rQAwq3xxVsouKtBAOhpgUJtpE1gs/qarpDanAxAZoXkgdSAfst F+5d/wBpuf8AJkCGYITS38n6jeWs+oWdpepYcm+omWJJGcKaNHcelIjxOrfu1kWDhJg4imgW Pytt6bLxdTRlYd/DJ2wbht4i9JVAUg0IYDenviSVeiflsaeZ7YEUDWclPoKeGRT0eu4GLRxV a2KUp1Q/Ae+Bk881c/6ScKSxXzBxNnID1KnCGNM/8oXxfQrO1QAyCJOJbofhGxxKAxDzUSdX uXKGMniChNaEbH/Y4skjU0NR3ySFVDUAHpgVUJ+GgxSl00lwrkAVHbCxUkuZxNH6iD0+QDA/ DUV3+OnwYlQzq2s9Lju7C60j0zdE/vRqPD0I2oRUzxF+Ubf3fB4soJPVtAa8xW93NqwFzY2c IIrzsChRWP7TcfjZpMnBElfT4kjUcvtDqcsJakxikArvkWQX+sgPXFW2kV+59jjSqFy0hjYJ QntXFUin07UZR/vPbHrQnmp+9Diuylp2n6taXRkMB9Gn+88kjTQtXr+16i/7Fo8EgUgsg0hv MltBeSWbQJyoJbC+YskiipUwsycm+0yfb9T/AH4mR3ZbMJ833Er38fq2P1CT0qtCGEik1pzh kov7r/JyYCJMbPTJ01s8/Kkr+kHFKt9Zh+6mRKve8kh2FXYVdhV2Kv8A/9WR6hTfMdkx7Ud7 WYeKH9WFXnumKtICwqqzIDWo2Lce2SVnGqaYFUrPbxuq0MU0iFvhP+sWXArzi9iEd5MgACq5 C8NlI7EDJhVCm+FVRQBjaG6KeuBXIJFkUwlllB/dlK8q/wCTTFWQx615stbI6RcWKz2sg9NY byyUlWcAJwlZI3V1+H0+T5EiNtgJUda0e50+xtY9Q0cabeKeP1yOcOsqEVBmtuc37z/i+Jo0 f7Hp4iXciQSV1CmgNfcYWDYkYCnLr1GFVh3xCtjxwquGBXGlMVWfEvetMVZN5egF3DM93Lf2 Gn7IZbLhLEshG7SwO3rely4/3f8AxiyuRpsiEVN5Q81Lpb3y3scmmux48rpoTIEJWOVreUpw Zl/u4n/epgEgy372KzUC03BBoRloaiGknjWvw127740r0T8tpP8AnZNLIOz2swp9Ct/xrkCr 2TAhrFVjfhgSlGqf3Z9+mAMnnesf70nJKxfXd7aTxocIQy/yU/G2sgRsY0+4gZIsUk81hTq1 1XYc+vWgpkWTH9iSAenh028MkFtUSgG+JQrKakU6eOBKqlvGw6YoR1tZou9BjSo6NURQFAGN KqilKAAAdgKYaVVjND4YoVBIQTv8sVd6tSa40lekwGNKqiVTjSrhIKfLChekvqEEHphpUZG+ OyvP/wAwQRqtu/ZoWH0hv+bsiy6MU7YWLOvyr5HUJgD/ALvg2pXfIlXvmSCHYVdirsKuxtX/ 1pFqHfKGbH701ikHipGKvOLdwsZJ6LOGYD2cHJIeq6my3WkbE8lWqtU4FeQXbO9xIX+1yIJH iMkEKI9uuSVVYw8I/T58+P70NSnLxj4/sf5LYFWE7dMVX26xGeL12KQlhzkX7Sr/ADin8uJ5 JDNotb0iDSLjRZNauZRc8f8ATkleSIJUDjLZTwuyOqr8SQSep/dx+r6eUEHubQUN5j/w3cpb wafrMVxBaQBqzRMskhA/uI7n0/VRtuXoSM8aO/7vJQBCJFiLEMaKKL2r4Za1LT164q7fCq4V xQuGBK4KMKrTEtffEKiba/1C0Upa3UkUZ6oD8J+aHIkAp4iE1i86eZ4rGbTxfFrOYcWikRHC 9D+65L8H/EMjwBPGx9xRAo6e5rkwxWoqnr0wq9A/LhwvmTRfirWOdW9qJTIFL23vtkULa4qt PTAlKNU+wfwwBk871g1uD+rJJYtrZrBIP8k5KLEsk8oalYomnWkk3G4kREjSh+JgteNfs4Sh LvNVRq94v+UKH2oMim2Pqe+FCquKoqBK79sUo+IBQBhYoqJl7YEqtdsKG1fCqsr4FcX3wqtD Ak4qqIT4Y2rZZxtTCqJgiJUEnr1GBUXHFxw2qJjU0wWrBvzFQieyanVXB+e2Bl0Yb8QBp074 WLOvyuUDVJUDBh68FHFQOmRKvfckEOxV2FXYVdjav//XkGoHrmOzY/eH4H+RxV5swKw3Q7o7 Hw6GuWBiXqhZW0NSDU+mOnywFXkl1/vTLT+Y4QqjhVcMNK3U9cSFXA7YFXfPFWiMVa4ntirV K4VdTFVwBwIXdsUt1wq1XvgVwOKru2KqcmKrYyAdzT3wqzn8vHZfMGiUIKM8w23rRGyspe5Y ENHFVrdMCUo1Qfuz9OAMnnetD/SDkklims/3LD2wxYlkfky2s2SzuJwBwjVg3uNvh/y/8rJF iFDzdFGdXupIJPUiYK4O3MAj9pf+NsiCyLGFJwoVUFWA+nFUdEabV2HjhUIlK1GIKESpp2oM VXFjTxxVcGxtVZanFXCpbG1Xqn3Y2qpGu+G1RQCYLSiIim1MCoxQp6Y2tLkkVWoflTArDvzH L+haF4+KlzwkBBFeO6MP2eX2lwhl0YGG+EjJBgzX8sGA1Nx39eChPhXcbYCr6BwobxV2Kuwq 7Ar/AP/QP9QOxyhmx+5P2sVecTNSS7j7mRgPCpOTDEsytPNts1hFYNp1wGKBGmBVo1oPtFqY CnZgt7T65NvtyOSCFHDat4qurQHw74q4EYq3yxV3InArYJphVumKtgb4FXADCrTHFVtRirdc Crhiq7AqlKMIKqSncUySsz/L48dc0Ruv+kSBaU/33JtlZS96rkUNVOKWj0+WBUq1P+7OLIPO ddp9YO2FLFNX3hPyIGEMSyDykqS2dqjsY0MYVmHb5ZIsUN5pszo/mRfQYtE8STxM26ujckkR v5v8rIhmWPSMnqOyLxUsSq1rSprSuSYtxSln4ggECor3PhgVFRvMRsAPeuFUXbzglYztOSVM Z70+Kq/5LLgVULzFzwYCmwB+VcbVvnMGCmRQx6ChxVVX6xT7S++xwlVZZyIlYgFmHY7E+2BV KS8ZCS1YwOhIBG+BUNLrE6KSjAr05cagH/K3yQAQr2msrKG6qygF42HjWvBh/LjSo+Ni6hxK wDCtNumCkq0MnORY1lb1GNEWoBY9aL/M3+TiqIWdo2RhKxAO4NCD88NKjIrlll9QLz2rxrSv +yOBUg/MK+gk0+KFVIZnDcXBBFBWo/Z+H/WwBl0ed9qZZTBm35YmmpuQK0uIKj2rkSr6DxVv Ch2KuxV2Kv8A/9GQX42OUMmN3dAxHbFLzy4VTdXqkD7Rp4VyYYlnmmTww+V7eV4mMfoqWC0q RTEhFPPdRMbXkrxV9JjySvWmIShfbCq4DJK7ArsVbrilsYopcOuNK2PwxVvkB88CtmQdtvHF Wuq1psdq4VaKSGlBsTQHFW5YZbeT0phxaleoIP0jHZXAj7sVVSCqhj0YVFMCr5YOMCyGhDg0 xVAEEHfJKy3yI9Nb0bf/AI+z+KSZCTIPf65BDVcCtk7YqlWqE+mQMDJ5xr3+9FfnkksU1beN vkR9GSCCnnlGRxaWhUipWgruOvfJEMEP5puZX1N45lVTDsioSUHLdvT5fY5fy5ABmxxyTXx/ tyTFFyD947HtQsR4dziFVlItXJcHnyVoZFPKKWJqcgf9+I6/7NMKolmWsfGpUtQVwKujc83q K0Yb/RihS/d/vGlAdkY+pCftGNvsyIp+2n7D8PsY0lFQTu8K1JYqCpdtyQPs8j+0y/Z5YhUO k9Y4x1qf64qpXrvIqkkhOjkVJH+Vx/aw0hJpbiRH41UmhVmQmjCu2Kq9nKQzjxUYFZKJm/Rz yL1SImnyWuFW7G0Z7WKQKp5opNdxUivfIpRaW0tvx9Q8kdtjWprue2EITJacRv22wJY353Nd NiruFlFPbY4shyYPy298kwZp+WbcdTY9B68FT1Gx/lwFX0PgV2FXYq3hQ7G1f//SkV8NjlDN jF8aOcVef3QA1C79zWn0ZMMWaaGUn8sW8cg5Jw4kHoQD0wlWJeZLeKO7DwgLGRQqKbEbYAqT VG+SVvp16Y2rhUmgOKrl2+BhuT17jFVwQcpFBrx6HphtVo6dcCr+FFrvTofniq6o9Igdj0wK pOaGmFVqkH6MVVY2IdVJ+GvTtiqcWJAjIB4qainb8cCql9bK1mz8gSpHGuISUoYJ6aSKwqSU ePuCP2v9RsKGufwrv44KVa85Cla/D1phCoRnqcNKyryQ/wDuZ0k9KXg3+auMgUh9Ck5WrVcV WtIoG5wJpKdSmQoRUVxS8814/vq5JLFNVI9JvkclFBKYeWb2K3trXmwG2SYIPzDexTarO6sC pIpTp0xAUpS0q8TRvvwkKizdpzrXsMCWlmt1NQAN60HicKFb68lU32B/hkUro9RjV333JH6q YULnv4XpzoabgnsfbFC79JQrGQNtumKUvGoUKb0A6j2xpV76kOFMVSu4nDMGG3ywqujuSpJH hiqbQ6xSD026MoBwItkVvZ2sUSrE7KlBRBISKfSchTJCaxcR2FvHLASXMgDCvIU+/EJQH+J5 1UCm/hkmKW6tq899F6bD4Qa/TiFSgRynopP0HDa0yjyRe/o7UOU0UhVpYpBQU2Rhz+Jvh5YC Vp9E2GpWOoxepZzJKopyCn4lJ3o6/sYAVpF4q7CrsVbwof/TkV8djmOzYvfn4zimmBaiOOp3 Ne/+1kwwKf6FdJ+gPQqNi4YV3FTthQxG/Y/WXBYuK7FuuGkoblhVczVA8KYVbMgpUdSKMDgV szF3DHtQV+WFC7n8bEdxgVqOQAFW6EbEdRiAlsykgiuxpXFWufwEe+EhVjmp+jCAq3l0238c CthyGBOFU5hjgaEMOp3yCr7oKLZwp7bCuNJSWp38ckELqvSlDirRSRuikntjarlsLxzVYHPy Un+GNhKfeWhdWGpWMssZRYrlJOT/AAr1p1yBV9ERyB0VwKBgCB4ZWqx2pgSgbmcgHCEse1O7 dQcKsP1KZpHqcUsa1ahMYPQtQj55IMSliTMg4qdlJ418Mkxab96/I7E/TiqKt9LSbrLxr7Vx tUcvl+3O5uGr8hgtVQeX7P8A3/IfbbBar/8AD9h+1LIafLDarhoWlg/FJJXv8Qx4lpeNE0fa rOR7vgtK79EaEtSxNPeSmNopcNJ8vDqB9Mn9uKab/R/lofsx/TJ/bgTTf1PywP2ID/s6/wDG 2NootiLyyp+FIK9OuNrRXV8uUoI4DXptXG00W4m0OSQRRxw+ofsp0J+QOK7oyOxtQdraMHv8 IpiqqtnbD/j3jHzUHFCosEQNfQj/AOBH9MVTC3SNV2ijoe3EYpAS/UwvE/AoPsAMVZP+U9eO rVFP3kW5G9eHjiEF6JhQ7FXYq7Dav//UNrq5LA5QzY9fSbsx7b4qwHUJTNdSSrQFq/hkwxUr e4khRk5kAnoMlsqHkjeR+VeuKGhbN/MMbS39VPdsbQ2LXxbDati1X+bI2q8Wsfdj742lsW0I 7k1xQu+rwe/34bVsQ2/ht88bSu9G16kD78FlW+NqP2Rjuq4fVf5VwqvRoPsgAV6DAqssan9g DBSu9JRuFG/thV1AOw+dMVR9iTyXYVBwJZTaySel1/DIqluqc/SLV+yyn7mBxtL2OxblZQn/ ACF/VkShdKdsDIJZdnY4VY3qZ2OFWKXv2sVY/qo/uz4N/DJRUpQOp+ZybBUj2OKptY0yJCbT RaUyJVcDQgdTiqor0xVbcRQSUPoRyN/O9a/6u2KVIQQdPqtuPcqT/HFbXLbxbD6tajwPp1/j itrhbxgbR2wH/GEH+OKbXiJBSptwR0/cpX8cUW3wQdZol+UUYwKu5KBX60gHskYwquT95Xhd 1PcKsf8ABcUNvp8UssUs7tK8R5R8uIof9iMUo5aVxVUFCK4FbFK0PfCqMiHwYpS3Uuhr1xUs l/KhhXVVHQvERv8A5JxYPRcVdhV2BXYVf//VFznY5Q2JLqBqrClRTFBedz1Erj3OTDFYMkqo tcCrqYobFMUrlIrQ9MVbkWLl8BahxpFreI9/vxS7gh/28Vb4J4ficaVcFQdhjSGwE7gVwpXD j7U+WBC9WT2+7Cq5kDla/s79BgSqqaYFXHpttilaNz7jriqNsPtivXFDJ7dgI+mRSgNXP+hz GmwFd/Y1rir13SX56ZasN6xqfwyJUKspwMktuyd8Ksb1M7HCrFb3c4qkGqdI/wDWA298IUhK B1PzOTYKiDFU1smIwJTJTXp18PlkVpeCa74quHX3xVep3oTjSqVxDDJQujMSOqOU/DFIUhYW ld4Cx8TK2Kkrhp9udvqq+1ZXwraotjbf8sUNfdnP68FLa9bC3ptaW4+fM4raothbgV+qWwP+ oafrxW1NtKga5huUVIJITWkK8QwP7L7/AGcUJmvicUrh1xVUU03xVcDviqKiJ47bjFUt1I1B ripZN+VRpJqy16tEQPGitixei4q7FW8VdthV/9YVOdjlDNJL/wCy3ywK8+uv96JP9Y5YEKYy SFRTiq4E4Fbrii3YFbU/jhSukjUUKvue2KkLeB/mOKu4DuTiq4IlO/34otsRpWu/34pXCOPa q/jirjGCwKjjTG1VgfxxVcGqfbFV9cBVw6/rxCUXZkcwa9N8Usltm+D2yKoPWDWyuKf77b9W KvV9AflotkfGFP1ZEqipTtgVK7sihwpYzqcnXCrGLtqk4qkeqfYTt8QGSCkJSoNT0pU/rybB UXrgtUwtD0HftgKpkrbUyKVRTt7HFV6k1JPTFWzUbj6K4quqD88Cumt4pEDF5VYdoiN/nywq oizjbYy3X/BKMUrxYwDvcnx/egfxxW1/6Ptu8cx9/X/txW1sVlJDexzQOyW4qJYnkLhqj4SB /k4oTEU7HFV4NO+KVynf9WKr60GBWwThRaLi2XAkJfqB2OFSWTflTX19WHasR+RocUF6Nih2 KuxV1MUv/9dad9jlDNJbxq1GAoYFe7XUv+scsihRGSVUGBC6uKurirf44pdU4ob/AMxilUaL 4AwcfLvjaqfFj+1TCrYQ/wAxxVsIO7H2pgVxVgwIJp74qqg74quU7++BVwbCq8N3/DAq6u+N JRVq3xj59MBVkdq3we2BKH1P4rWdelUYV+g4q9O8qSc/L2nt4wJ/xHIlUxmO2AJSi9brhVjG pt1wpY1Oasa4qk2q/wB2p8GGSCCla13r1qd8kWC9aV/HFUfa9R4YCqPQ/cMDJUDeG2BVVW2C k+GKGw347jGlbH6saVfyxVqWIOgImaEjqVXn94xUKIhr1vJyO1IqfwxS63W7S7AMkktoymrS KFIb2pigpjQDbFW1NMVVARilcDiq4f5jFC9TQ4qi4j8O+BKX3/fCpZL+VH+9Orf88qg/JsUP SK4obxV3bFXYq//Qqduoyhmk9yascCsI1GgvJadzvlgYlDjJKqLiq7Ahun342tO3+7AluuFD sVbxVeI2ZOQIFPHGyqwLJ4jFXVcMN6jFVQHxxS3U4otcuPNV1aD3wJXg9+2KrgfA4VRVsfiF RkSlkFow4YFWX1DBID/Kf1YVei+SX5eVtNP/ABQv6sgUpvMcCUnvT1wqxfUzscKsdmO5wJSj VSPRFenIZKKJJWn7XzOTYLxsRTFUdancfjgKo4UBrgSuDeHXuP6YEqwbavfFC7luKn5Yq3uR uMVXDrttgWl4370wq2qE7g0xVeBTFV6nFV6kdMVXA7/1xW14ah6Yra4H6Diq5W3xVFxNttgV A6gTv74Ulkv5Tmt1qx7UhFf+CxYvSMVbrirhirqfPFX/0Up++UM0pm+0cCsN1Ucb6T3OTigo RckhepxVccUN4pbxV3fFW6+GC1bwq7kfoxVwPvirdScVXDGlbGKrgcVXA7Y0i1wOKrwe2C0q 9uRyFPoxKshsj8HXIsnXe8bL4g4oZ95Bfl5U0/xEYH3bYClO5jtgSlF6djhVi+pGtcVY/ORv gSlGqV9H6RkwxKWR78j75Jiu74AqKt2/2sSqPRv7MCbXhhWmBK9XJ2HTxxQuBPXFK8N08cUL 6kYquDf598bVUQ0+WKrwdsVbU+GFV4PX9WBK4N2xQvqcVXKxPXFbXqw698VRERqtfxwKg781 9yMKsl/KhgLvVQe4i/CuKHpWKurirsVbr7Yq/wD/0kp98oZpTP8AaORJViGsj/TW+QyyKEAD kwheDiq+uBbcMaQ3XFLeKHYpbrih36sVbHXFLeNq329sVbGJW1wOKtjFVwxVcu+KoiA7gnt0 wFKe2TfBXxO9MilVuDVTT6MUM4/Lxq+VLMU6ch9zMMBVkMx2wMkmvTscKsZ1I9RiqQTd8CUo 1SvoH/WH68kEFLYhWo98mwbanLEBURbnfAVR6047YErxtv4YpXBj26d8aVdy9sULgV6YErwe vbxxWlwbtXFVVWqP4YoXDelTviq4H33xVUDd+xxVsHFV4P3Yq2G7YqqKQT88VRMNAOuKoS+8 cQrJvypqb3Vh1FITTb/KxQ9J7e2Ku2xV1fDFW8Vf/9NKbvlDNKrkfEQDkSUsR10EXnWgIG2W RYlLhk0Lxiq44q7ArdcVbBxVsbdcVdXfFFuBxS3irYOKtjr7Yq34Yq2Diq/Aq4GmKtj9eFVe I0I/XgVOrFvhIPbIslec/Cflihmv5cPXyzGP5JZV+52wSSGSTHbAlJ74jfCrGNR74qkU3fBa Ep1T+4JHYjJBJS6ICjfPJMHNSuFbV7cior1wKjkP9mKV1fpP4Y0q4NtgVeTt12wJptSSdzth QuB9/pGBK4vQ07YqqBj1xVUDd64oXA74FVAa7eGFV1dsVXhqfTirYIxVep/DFUVFSlcVQt7W hxVkn5Uj/T9UI/liHT/W74oL0vpilvFDRxV3xf5nFX//1E5soZpVc/bOBQxPXxS6X3GSighK xliFwpiq/FXYq3TFXVwIbrirsUu98Ct4VbxCt4opvw98UrhjatjG1XCmC1XDFVWImuJVObBq qa/RkUoiXocbVmX5bODoLr043Ew/4cnAUsomO2BKT3x2OFWM6ianFUjm6nAmglOqU+rsMmGJ FJdADxJ/yskxc3XFCrD19sUoxD+GRSvrSldsKrlJr+rBSrgfuxSuUjbsBihcCKb74Et9a1xQ vU7D3xSqg0NP864oXjcYqqKe/fuMVXjagwK2PDw74VXKfvxVUVvoOK2ioSabnFULe++Ksl/K ra/1Sm/wRA+I+1vgUvS9/nhQ7ril1a4odXFX/9VObMdmlVyPjOJVi3mID1oiPA5KKClAyxC4 YFX4q1hpWxgVsHFXVGKG8Vd2xS7Glb2xVsYobGKV3TfFW6/jiq4YquB98VXxncYEJvYMfDAy CMl6YFZb+Wjf7iLpf5bqX8SDiUssmO2RSk98euFWNX53OKpJP1OKaSjVBW2eu/thBYoCD7Le 5yTFuTriFXQ1GKhFqdvfAlfvWvj1GFWwQd8CrqkjftuMVtcCd8VXqe9N8Sq6veu2BNr1OKrw QOh2xVeDt8+2BFrw1KD8cKr6muBC8HClsfPbFV6nFUXCdvHFUNenY+GFWTflUT9e1PpULFXx 35DAr0rttire+KHVxV304pf/1mTZQzSu7I54FYt5jHxxH55KKEmGWIXDFV3bFXDAreGldtgp DfhitOxpXYq4Yq3irYOBWwRhVcMUt96YobHbFQvBwUlerCuNLaaWTU6ZEpCNkNRXvirK/wAt GpZ6inYXTUHzRMSrL5jtkWSUXx2OFWN3/U4oSSc7nAlKtSUG2kHgK7ZIKUvt68T88mWDpNjg VuKtcVRSGgwJX8u2FDYJrsfngpK4MdgcVXA7fwxWlwbb9WBV3LFV6kf0w0q+tR7YFXcv7MVp ejEmhxTS+tP44opfywKvBwqvDb0xVFQnbFUPdkU364qyb8qifr+pCu/GOg9iDih6X/mcVbxV 1cVdUYq//9dsuUM0ruh8WBWL+YwaRHoKkVyUWJSQZYrYxVcMVb+XXFW/fFXDFW+mKHYEtY2h sdMUt4ocOuKtjFK4Yq3T32xVcB92C1bH4YqqL1rhVMbM75EpCNc7UwJZV+Wzfu9TXt9YB++N MSrM5TtkVSe+OxwpY3fHfFUlnAqcCoGZOQIPQgg5ILSVQftjwbJMC6Qb4VdHSv8AHAqJQ4FX 1wptuvvXFVwYU98FJDhWhFffDSLXjxrgS3UeOKCvB223OKrgw2wKvBr3piq9WP8AXDQTS8Hx 74EL1NNu+Kr1O1DgVeCThVFxNt/DFUPenY1xVk/5Un/TtTB6hYv+NsVel1wIb64VdirsVf/Q bLlDNLbr7WBWM+YwfSjPbkRkoIKQjpliG98VbGKt4Fbwq7FXYFdirsbVvFXd8VbxQ2MVpcPn ilsdcVb/AFY2re+Kr16g4qmFo2RVGsdtsAZMo/LZv3mqr1pJGfkSg/5pxKGaynbIskovjscK sdvepxVJZ+p/XgVAyfaP07ZJd0rgALP4cjhpg6QYQpWp19sJVEKdhgpV9fvwJbFMUNgjYDDs m2/4YquVu/TAVXE9D274quDbHFV4Y9PH8MVXL93hileDvgVeG2/jioXqab/x2xQvr0xQvVqb YpRULeGKqN2djirJ/wAqz/p2pdxxj7ezYlXplTgVwNRihutcKu3wK//RqXKGaW3fWpwKGOeY h/o8Z8GyUUFjwGWIbwK7CreKuxVsYFdjaurirsaVvFDqf7WKt4q3vTFWxilsE/Riq7ArdcKr l8MaVG2x39sBVHFthgSyX8umpfaoviIT+DLgKWcynbAlKL09cVY9e9cUJNNuTtiyQMn2vDCE JZAKtIP8r+OSYFqUeOKrF6+2KohaUpiq7bG0tg+9TgVup+nvihuu4xVdsP7MUr/8zirdaf59 sVXLT6O2KrxTAq4eJwqvB28cCV4oRiFXqfD7sULlb4h44FRcJ2wqpXZND4Yqyj8rCPr2o7/s x/iDgKvS8VbBxQ3XFXb4q//SqXKGaXXQOBDHvMCn6n8jhipY4uWIccVd2wq3gV2GlcMFq38s KHYpd3wK75YVbwK3TFDsVbBxVvfFWxTFVw/DAVXAn6cUoy2O4/HEqjS2w/hgSGRfl81NY1Ae MMR/4aTAVZ5KdsCUpvehxSx+864qk843OBbQLg1GG1pLICQ8v+tkmDc2EKorWuKq6nFC4fhg S2D7UxVsHbbvirq/fitL603xVtT8XyxVdXfwrilepxVdXpitr6kCvfAq5SKbdcUrhWm/XGlV ARt49jiq8VJ64oRUJPzxQpXZqOvTFLKvys/3u1E9Rxj6+PxYFelA/dirYOKt1xV2KH//09Jl DJL7kbYFSDXVrZNt3whWMLlqGzgVrCh2BLf8cKuwK3irsVcT92KG98Vd/mcVdXFW9sVbxWm8 VbGNq2MCrgR9AwraLt23yKUbX4cQUp75Camv3K/zWy/g+JV6DIfhyKUqvehxVILvqcUpROPi JxVAyChAGEKUsgPxy168jkiwdP74hVEDfEotVXFV4p3xS3UVwK2DXFXV/wBrFWwa40q4Hb5Y q2CdtsaVUVt/14pXcu464quqev34FXKd9hhUFeG33Ptiq4E/PAqoGHXFJRcJ2364oUrrcbYq yv8AK3/e3USTvSMV7d8BV6UDvirdR/bireKHVxV//9S5B9+UMkBcjbFUk1pa2MntitsTTLLQ 2wxQtwq3gS7DaGx1xS7FWvopihvFXdsCt40ru2ICu26YquwK3XFXd8NKu/Xiq4HFaRMB3GAp RhPw4FTvyQ4HmRh/PbN+DjEpeiyHbIpSm8OxxVIrqpJxUpTON8CUDKPiwqlcNfVl2/ayTAtT HCEFSB3xSqqcSq7+GJVsHxwK2CMKt+/hirfX54FbrirY3+Xjiq7l92KVynFVwY/2Yqv5bY0h dXb3xVcDUg4Er1Y16/LFUZCSQD92Kqd0SVPjihlf5Wn/AE3UT7R1+5sCXpQriq6uKur9GKt1 OKv/1XSDKGSCuBtiqS6stbGaorsTgCsPQZahtsUW1hpLjih2KXYFbxtXHFDqVxtLqYq3vih2 Kt/PFXDFab98VbxVv9WK0uGKoiA0wFIRdfhwJTjyaw/xPCD3gk/WmJV6TIdsiqV3nfFKR3Qq cU2lkw3OKEBKtGxVKIh+9mP+VQ5NiXT9foxVQFa4qqKdq/hiq8kU9sVdirgQMVXVHX8cVbB8 MCt9sVbBFK1xVd7eOFVw9sUrwaDArdf9rFC6o74pbDClK4qqBx4/PGlRUDgD9WBWrkgqd8VZ X+Vm17qPyj/UcBQ9LGBLYP8AtYVb/XgV1ThV/9ZSQdcoZIO4G2KpTqKVtJf9U4qwpOtMsQ4j bEIIWjCodil2Nq72xV1cUN4q7Alv3xV2KHf51xV2KtjFDeKWxirf04quGKqsex2/HAlGA/Dg VNPKTcfM9p/lRyj8FbEq9Pk6ZFKVXnfFKS3AxVL5V3xVCvDU/wAcCpAopPOP8rJsStmwqoil cULwe+KWwRihvkMUtc9q4quLCmKthgMUN8/uwJcHxVcH8ThVd6nvgVd6mKu9XfpTDatiQYFb EowqF4lH04ClXhmptX54qrSvyTbArL/yt/3r1E9qRj5bNgKvSsVbqPpwK2MKt1xV/9dZxtlD NCTj4TihLLxa28n+qcCsFH2j498tAQXNixtZhUO64EuxS727Yod8sVdthtW8CuxVsHEqHV+7 FS7FWx4Yq2DjSA7FLffFVwPfFVSM74qi0aq5FKZeWDTzNp58TIPvQnFQHqj1pkWSWXidcVSW 4G5xVAuN9sVaSGrdMUMWmQx311GRTi5/HfChRlbCEKBOSVvliVDueKu59sSruYwUrufSmJVs OcUu9T6cUO5/filvn9+KG/Uwq36m1cCt+p4/RitteocUt+pjsq4S069e2Kr0mp8sVRS3FRTF behflXAxS+uR9h3CV/1QMgUvROJwKuC4VXAYq3QYq//QEPlDJCzDriqX3CExuO9DirASKSsP Anr88mEFa5wsd1PFIdXDSurhV1e+BXVxpW64pdU4EOxV1cUuqcUNg4pdXFDq/wC1ihvlil1f vxQ2GxSvVsaVERyYEp35QQzeZrSgqI0kdvYUCV/4bASr1biTkWSHmtyw6YoSm705iajFNoA6 e/Lpiqoliw7YoYr5usXs7uK8VaRXI4OewkXpX/WTCFLHHkJOTYlZXauKtcjitu5GuKu5Yq7l gVxbCruRxQ7lil3I4Fb5e+FXBzijdvlgS2H/AAwq7lvgV3LFLuX34quDn5UxW0Zp1peahdJa 2qlpHIFewB/aOQMqSA958qaJFo2kRWqj4vtO3csd2Y4AhO6DCrdBirsVdir/AP/REuMoZIaQ Hc4qhJUqCPEYq89vUMN5KjbEMf15KKChy1cmGK2uLJ1RirVcKGyfpwK6uKurirq4pdXFXVwo brgS6uKuBw0h1cCuqMUt1xV1cCt8sVK8PTeu2KA9L/Lny/Jbwvq10pSa4AWKNhQrGDXf/Kl+ 1kCUs74jIpaKA4qoyQq2FUO1omKtfVFxShtT0K21Kylsrgfu5BsR1Vh9l1/ylwLbyjXvLWpa LOUmUy2/VLlVPEj/ACwPsNkhMdUGN8ko5ZMIa5Y0rq++JRTVR4j51wWE03XGwtFujE9CfkDg 4gnhK8QzE0Eb/wDAnHxIo4SvFndnpBKfkjf0wcce9PCV66bqTdLSYj/UODxI968JVU0XV23W ymp4lCP14+IF4FVfLuut9mwl3/yaY+IF4VZfKfmJuli/zJGDxB/STw+asnkrzK3/AB5kfNhj x+SK81aPyD5mb/j2Ar4tjx+S8I70Qn5ceZG/3XGD7sf6Y8Z7loImP8rvMLbFol+/Hjl3LQR9 p+UmpOw+s3SovfgtTT6Tg4pLsz/y95P0vRIwIV5S0+JyNyfniIqd2QjYZJW64ENg4VdXFW64 q//SHvHtlDJDSRnFVBoq4oYr5o0OU1vIFrT7YHhiDSsSNQaEb98s5oarkldXAVdXFS7FXbYq 4HFXVxVwOKtjFXe3XFLq+GC1b38MeILS5Uc9EJ+QOAzCQF4t7hvsxOfkpwccUUVRdOv26W0h /wBicHiDvWlVdF1Z/s2kh+imHxAmkVB5W16Y8Us3Fe7EAficHHass8t/l3KlxHdasVIQ8ltx utR3c/tYLQ9GjjSNQiCijoMUr64q0cCrDhSsOKHYpbxVbLDFMnCVQ6nqCK4EJRP5Q0Cdy72a cj1oKYOEJsrR5K8vA1+pp92NBbKqnlLQF6Wcf3DHhC2VdfLOiL0tI/8AgRjwhd1VNB0lelrG P9iMeEdy2VZdJ05elug+gY8I7kKi6dZDpCg+jDQVVFpbD/dS/cMU0vFvCOiL92K0uEUQ6KPu xRsvCJ/KPuwrS4KPDBaVwpihcKY2q9RhVWUYFVBhVsHArYOFW64odireKurir//TMmyhkpOM VUiN8VWMiupVhUHtiqQaj5RtLpi8R9Nz27YK7kJO3ki95fDItMNlOza+Rrw9ZV/HHiKFVfIk 37c4+gYklVVfIQ73B+7BZVVXyFbj7U7HGz3qrJ5FsP2pGOO/eqsnkfSh9osfpxVWTyXowp8B PzONLurp5R0Vf90A/PfBSd1dfK+ir/x7KfmMaC7q6aBpKdLZPnTHhC7q6aRpy/Zt0H0Y8IVW TT7JekKfcMNBCqtrbjpGo+jFVUQxDog+7CmlRY1/lGKERGgHbFKJXYYqvGBW8KtHFVpxVYcV direKW8ULhirsVbwJXYobGKWxireKrhireKt4q2MVXDFWxiq4CpxQqriqouKr8Vbwq2MCHYU tg4obBxS76cUP//UNDlCVJhilSIxVqmKuAxVcBilun3YodTFK4DFDqYq3TFWwMVXAYquAxVc Biq4DFVwGKrhiq4YquAxVVRcVV0GKqwxVdgVvCrRxVacVWEYq7FWxilvFFt4quxVsYE23ire FDYwK2MVXDFWxilsYq2MVXDFbXAY2hUUYqvHbFVQYq3XCrdcCt1wq6uBWxhVvFXYof/VNW6Z QyUmxVSOKtYFcMKlfirsVbxUtjFVwxVoYquwKuHTCrfhgVcMKrsCt4oXYUrxgVevXCqsnbFV ZcUlUGBC7FW8VdhVaemKrTgSVuFWx1xQ2MVXDAlvvgUt4ShdgS2OuEIXDAreEJXDFW8VXDFD YxVcOmBVwwlV4xCrxiq7FQ4Yq3hVsYq7FWxireKG8Cv/2Q== --XX52BF529F-00B052BFXX-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Sep 26 03:37: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 SMTP id DAA07391 for ; Tue, 26 Sep 2000 03:37:48 -0400 (EDT) Received: from standards (47.234.32.16:2586) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB97EDC@standards.nortelnetworks.com>; Tue, 26 Sep 2000 3:21:34 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30855 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 26 Sep 2000 03:21:34 -0400 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB97EDB@standards.nortelnetworks.com>; Tue, 26 Sep 2000 3:21:34 -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 e8Q7Xnu19014; Tue, 26 Sep 2000 09:33:49 +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 JAA09686; Tue, 26 Sep 2000 09:33:48 +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 JAA56321; Tue, 26 Sep 2000 09:36:11 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-ID: <200009260736.JAA56321@givry.rennes.enst-bretagne.fr> Date: Tue, 26 Sep 2000 09:36:11 +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 question about MIPv6 and IPSec X-To: Linfeng Yang To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Mon, 25 Sep 2000 17:16:14 +0300. In your previous mail you wrote: Both "The Case of IPv6" and RFC 2460 suggest, as I understood, there will be only one DO (Destination Header) if there is no routing header. This only DO will appear just before upper layer header or another IPv6 header if encapsulation is employed. => exactly! I guess that is the thought behind Francis' comments. => we have understood the same thing. Thanks Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Sep 26 03:45: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 SMTP id DAA07460 for ; Tue, 26 Sep 2000 03:45:58 -0400 (EDT) Received: from standards (47.234.32.16:2586) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB97F0E@standards.nortelnetworks.com>; Tue, 26 Sep 2000 3:27:34 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30921 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 26 Sep 2000 03:27:34 -0400 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB97F0D@standards.nortelnetworks.com>; Tue, 26 Sep 2000 3:27: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 e8Q7dmu41452; Tue, 26 Sep 2000 09:39:49 +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 JAA09783; Tue, 26 Sep 2000 09:39:48 +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 JAA56379; Tue, 26 Sep 2000 09:42:11 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-ID: <200009260742.JAA56379@givry.rennes.enst-bretagne.fr> Date: Tue, 26 Sep 2000 09:42:11 +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 question about MIPv6 and IPSec X-To: Linfeng Yang To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Mon, 25 Sep 2000 18:11:36 +0300. In your previous mail you wrote: > Both "The Case of IPv6" and RFC 2460 suggest, as I understood, there will > be only one DO (Destination Header) if there is no routing header. This > only DO will appear just before upper layer header or another IPv6 header > if encapsulation is employed. Sorry, DO stands for Destination Option. Another correction, if Home Address DO is included, there will be more than one DO, but it will appear even after other DO as MIPv6 recommended. So there is one point not explicitly stated in MIPv6, but it should be assumed, all these DOs (BU, BA, BR and HA) are intended to the final hop. So they should appear after Routing Header if there is. => I agree. In fact there is no DO defined for intermediate hops then only pad DOs can occur in the RFC 2460 "first header". As a result, these DOs all appears after Authentication Header, and be protected. => An Authentication Header protects all headers, including headers before it. The mobility draft specifies the home address DO must be before the AH (then it amends RFC 2460 recommendations, both about DO header/security headers order and about multiple final DO headers). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Sep 26 04:07: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 SMTP id EAA07598 for ; Tue, 26 Sep 2000 04:07:02 -0400 (EDT) Received: from standards (47.234.32.16:2586) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB97F7A@standards.nortelnetworks.com>; Tue, 26 Sep 2000 3:50:50 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31069 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 26 Sep 2000 03:50:49 -0400 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB97F79@standards.nortelnetworks.com>; Tue, 26 Sep 2000 3:50:49 -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 e8Q84lu21717; Tue, 26 Sep 2000 10:04:48 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA10200; Tue, 26 Sep 2000 10:04:46 +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 KAA56485; Tue, 26 Sep 2000 10:07:09 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-ID: <200009260807.KAA56485@givry.rennes.enst-bretagne.fr> Date: Tue, 26 Sep 2000 10:07:09 +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 question about MIPv6 and IPSec X-To: Erik Nordmark To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Mon, 25 Sep 2000 15:28:52 PDT. In your previous mail you wrote: > I completely agree with you. In our implementation for Microsoft, we have > done it the way you described it above (BU and BA in 2nd destionation > options header) for exactly the same reasons - mainly because we argue it is > conceptually the cleanest way (at least according to the current specs.) ... Even in that case you need to carry some extra information between the different extension header processing code. In particular, while the AH processing can find the SADB entry using the destination and the SPI (which doesn't require looking at the home address option) the tail end of the AH processing might very well include a check that the source address of the packet is consistent with the SADB entry. Since the SADB entry is based on the home address of the sender, this check can't be done until the home address option has been processed. => AH processing is supposed to do a SPD and a SADB lookups then the real source address (aka the home address) is a priori useful. (another way to say the same thing) (Whether your AH does a "peek ahead" to find the home address option or you defer this part of AH processing until the destination options have been processed is an implementation choice.) => in the mobility draft the home address option is before the AH then this problem doesn't exist (ie. it is solved by the specification). If you look at the actual dependencies between the pieces of processing you'll see that all possible orderings (including placing a destination options header just before the AH header that some folks are proposing) => some folks = draft authors with the support of many of us. you need to carry some information around in all the cases. => I agree. The BU can be before or after the home address and the AH, in the same or a different DO header than the home address. If a correspondent node implements the optional BU processing then it should be prepared to deal with all cases. It would be useful to actually look at the different cases in detail to see if there are significant differences in implementation complexity. => for me significant is mainly for: - mandatory features (vs optional features) - receiving side (vs sending/mobile node side) The cases I can think of are - Home Addrss option in destination options header before AH. Binding Update option in destopt after AH. - Both before AH - is there a difference in the ordering of the options within the destopt header? - Both after AH - does the option order matter here? => the only significant difference is when the Home Address option is after the AH because it makes a real exception in security processing (which is already complex). The BU position is not important (ie. doesn't make a significant difference) then the current proposal is fine for me (I've spent far more time in IKE tuning than in AH+mobility interaction). Regards Francis.Dupont@enst-bretagne.fr PS: I've talked about SPD because it is the way IKE is involved (the SPD is looked up, the policy requires AH/transport, a SADB_ACQUIRE is sent to the registered IKE daemon). Of course the implementation can do this ASAP and not wait for the first BU packet (PS: replace "can" by "should" :-). From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Sep 26 04:55: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 SMTP id EAA07862 for ; Tue, 26 Sep 2000 04:55:11 -0400 (EDT) Received: from standards (47.234.32.16:4240) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB97FD2@standards.nortelnetworks.com>; Tue, 26 Sep 2000 4:39:09 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31189 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 26 Sep 2000 04:39:08 -0400 Received: from news.comp.lancs.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB97FD1@standards.nortelnetworks.com>; Tue, 26 Sep 2000 4:39:08 -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 e8Q8rgh29498; Tue, 26 Sep 2000 09:53:42 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Message-ID: Date: Tue, 26 Sep 2000 09:51:06 +0100 Reply-To: Stefan Schmid Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Stefan Schmid Subject: Re: [MOBILE-IP] Implementation question about MIPv6 and IPSec X-To: Erik Nordmark To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Content-Transfer-Encoding: 7bit > > I completely agree with you. In our implementation for > Microsoft, we have > > done it the way you described it above (BU and BA in 2nd destionation > > options header) for exactly the same reasons - mainly because > we argue it is > > conceptually the cleanest way (at least according to the > current specs.) ... > > Even in that case you need to carry some extra information between the > different extension header processing code. Yep, but I don't think there is anything wrong with that as long you don't have to look ahead in following extension headers. I believe the proper way should be to process the extension headers "in order" as they appear in the packet. > In particular, while the AH processing can find the SADB entry using > the destination and the SPI (which doesn't require looking at > the home address option) the tail end of the AH processing might > very well include a check that the source address of the packet > is consistent with the SADB entry. Since the SADB entry is based on > the home address of the sender, this check can't be done until the > home address option has been processed. Exactly ;-) That's why we propose to put the home address option in the 1st Destination Options header (before the AH/ESP). > (Whether your AH does a "peek ahead" to find the home address option > or you defer this part of AH processing until the destination > options have been processed is an implementation choice.) Yes, but both is conceptually unclean. > If you look at the actual dependencies between the pieces of processing > you'll see that all possible orderings (including placing a destination > options header just before the AH header that some folks are proposing) Yes, we do ;-) Regards, - Stefan From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Sep 26 07:05: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 SMTP id HAA08703 for ; Tue, 26 Sep 2000 07:05:25 -0400 (EDT) Received: from standards (47.234.32.16:3823) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9807E@standards.nortelnetworks.com>; Tue, 26 Sep 2000 6:49:17 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31413 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 26 Sep 2000 06:49:16 -0400 Received: from iabgfw.iabg.de by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9807D@standards.nortelnetworks.com>; Tue, 26 Sep 2000 6:49:16 -0400 Received: by iabgfw.iabg.de; id NAA11182; Tue, 26 Sep 2000 13:03:17 +0200 (MET DST) Received: from iabgmh.iabg.de(10.255.255.2) by iabgfw.iabg.de via smap (V4.2) id xma010396; Tue, 26 Sep 00 13:01:47 +0200 Received: from iabgvw.iabg.de ([10.255.255.8]) by iabgmh.iabg.de (Post.Office MTA v3.5.1 release 219 ID# 127-59214U1600L300S0V35) with ESMTP id de for ; Tue, 26 Sep 2000 13:01:46 +0200 Received: from iabgdns.iabg.de (localhost [127.0.0.1]) by iabgvw.iabg.de (8.8.8+Sun/8.8.8) with ESMTP id NAA04306 for ; Tue, 26 Sep 2000 13:01:46 +0200 (MET DST) Received: from cc31pc01 (cc31pc01.iabg.de [10.5.0.187]) by iabgdns.iabg.de (8.8.8+Sun/8.8.8) with ESMTP id NAA05476 for ; Tue, 26 Sep 2000 13:01:46 +0200 (MET DST) MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Priority: normal X-mailer: Pegasus Mail for Win32 (v3.12cDE) Message-ID: <39D09E3A.22191.13B5BDE@localhost> Date: Tue, 26 Sep 2000 13:01:46 +0200 Reply-To: heissenhuber@iabg.de Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Florian Heissenhuber Organization: IABG mbH Subject: [MOBILE-IP] Mobile IPv6 Whitepaper To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7BIT We like to announce a whitepaper which describes the basic mechanisms in Mobile IPv6. This document can be obtained via http://www.ipv6.iabg.de To download the Mobile IPv6 Whitepaper please go to the Download section. __________________________________________________________________ Florian Heissenhuber Communication Networks Email: heissenhuber@iabg.de Phone: +49 89 6088 3539 Fax: +49 89 6088 2845 URL: www.iabg.de , www.ipv6.iabg.de IABG mbH Dept. IK42 Einsteinstr. 20 D-85521 Ottobrunn Germany From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Sep 26 07:42: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 SMTP id HAA09036 for ; Tue, 26 Sep 2000 07:42:33 -0400 (EDT) Received: from standards (47.234.32.16:3823) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9812C@standards.nortelnetworks.com>; Tue, 26 Sep 2000 7:26:33 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31625 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 26 Sep 2000 07:26:33 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB98127@standards.nortelnetworks.com>; Tue, 26 Sep 2000 7:16:33 -0400 Received: from 5d68fg4.nic.net (sdn-ar-002flmiamP076.dialsprint.net [168.191.77.164]) by hosaka.smallworks.com (8.9.1/8.9.1) with SMTP id GAA18548; Tue, 26 Sep 2000 06:30:31 -0500 (CDT) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Message-ID: <4n28bh40wm6cwh.01atqn57k8p@5d68fg4.nic.net> Date: Tue, 26 Sep 2000 06:58:43 -0500 Reply-To: zpearl@MFUQXKTAHU.EARTHLINK.NET Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: zpearl@MFUQXKTAHU.EARTHLINK.NET Subject: [MOBILE-IP] "WARNING" YOUR WORLD IS ABOUT TO CHANGE! X-To: mr@smallworks.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8BIT Greetings! You will want to investigate this EXPLOSIVE new company RIGHT NOW! NOW is the time for YOU to make OBSCENE money with the HOTTEST Internet opportunity available to ANYONE!! * VERY, "VERY" affordable * Work on-line at HOME or ANYWHERE. * Only days old -- PRE pre-launch. * Revolutionary FAST PAYING compensation plan. * Build your own business, not somebody else's! * Totally AUTOMATED with the finest software available! Our goal is to help make you wealthy using the FINEST system for the HOTTEST Internet website concept. This system IS designed to bring you EXPONENTIAL GROWTH! * BEST of Internet dot-com and networking * TRUE residual income. * International NOW ! * Risk-free GUARANTEE * Have FUN doing what you LOVE for a change! Get all the details NOW - before others get in first!!! ---------------------------------------------------------------- YES this is a GLOBAL opportunity which can be done ANYWHERE! For IMMEDIATE ACCESS to all of the SHOCKING details, Simply include -name: -complete address: -telephone: -amount of time you have to commit: and mailto:tellmemore2@n2mail.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++ For removal mailto:notellmemore2@n2mail.com From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Sep 26 13:41: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 SMTP id NAA13276 for ; Tue, 26 Sep 2000 13:41:23 -0400 (EDT) Received: from standards (47.234.32.16:2764) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB983B7@standards.nortelnetworks.com>; Tue, 26 Sep 2000 13:25:02 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32457 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 26 Sep 2000 13:25:02 -0400 Received: from omega.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB983B6@standards.nortelnetworks.com>; Tue, 26 Sep 2000 13:25:02 -0400 Received: from gopal.cisco.com (dhcp-171-70-57-55.cisco.com [171.70.57.55]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA23603; Tue, 26 Sep 2000 10:38:57 -0700 (PDT) X-Sender: gdommety@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <4.3.2.7.2.20000926103533.00d49e60@omega.cisco.com> Date: Tue, 26 Sep 2000 10:42:50 -0700 Reply-To: Gopal Dommety Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gopal Dommety Subject: Re: [MOBILE-IP] Vendor/Organization-Specific Extensions X-To: henry.haverinen@NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <6D1A8E7871B9D211B3B00008C7490AA504E622AE@treis03nok> At 03:29 PM 25/09/00 +0300, Henry Haverinen wrote: >Hi all, > >I have some questions concerning draft-ietf-mobileip-vendor-ext-11.txt. > >Section 2.3 doesn't cover the case of an Agent Advertisement >containing a CVSE. Is this because the operation is obvious (MN >must silently discard the Advertisement)? That is correct. >Such an extension is useful if a FA doesn't want to receive >Registration Requests from MNs that don't support a certain vendor/ >organization-specific feature. Yes, if you want the entire advertisement to be ignored. >I wonder why the current version of the vendor-ext draft doesn't suggest >any type values for the extensions but just says "to be assigned by IANA". >Did the type values used in previous versions (38 and 134) overlap >with some other draft? It might be a good idea to give some initial >guesses for the types so that people can be implement the draft and test >the interoperability of their implementations. I guess even the vendor- >specific extensions should be tested for interoperability, as the draft >specifies processing considerations for unrecognized vendor types. We did specify the type values and IESG instructed that we remove the any recommended assignments by us. The values we picked were not conflicting with any assigned value. I think this is an IESG policy. >Regards, >Henry From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Sep 26 14:05:08 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13544 for ; Tue, 26 Sep 2000 14:05:04 -0400 (EDT) Received: from standards (47.234.32.16:2764) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB98457@standards.nortelnetworks.com>; Tue, 26 Sep 2000 13:48:10 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32657 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 26 Sep 2000 13:48:10 -0400 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB98456@standards.nortelnetworks.com>; Tue, 26 Sep 2000 13:48:09 -0400 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA04249 for ; Tue, 26 Sep 2000 11:01:52 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.85.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id LAA16531 for ; Tue, 26 Sep 2000 11:01:51 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with SMTP id e8QI1me140756; Tue, 26 Sep 2000 11:01:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: MULTIPART/mixed; BOUNDARY=Wedge_of_Swans_902_000 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Message-ID: <200009261801.e8QI1me140756@jurassic.eng.sun.com> Date: Tue, 26 Sep 2000 10:57:53 -0700 Reply-To: Alper Yegin Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Alper Yegin Subject: [MOBILE-IP] New I-D: draft-yegin-mobileip-nrouting-00.txt X-cc: carlw@jurassic.Eng.Sun.COM, mohanp@jurassic.Eng.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --Wedge_of_Swans_902_000 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ihbRkrzBTqz5LPqk4wsgDw== Hello, We submitted a new draft to IETF yesterday. Before it goes through the IETF editors queue, here's a copy. Title : Mobile IPv6 Neighborhood Routing for Fast Handoff Authors : A. Yegin, M. Parthasarathy, C. Williams Filename : draft-yegin-mobileip-nrouting-00.txt Pages : 15 Date : September 25, 2000 Abstract The Mobile IP working group is currently examining proposals to assist in minimizing the latency and packet loss due to handoffs when a Mobile IPv6 node moves from one point of attachment to another. One of the desires to reduce this latency and packet loss is a result of the strict requirements of real-time network services. This proposal specifies a solution whereby the mobile node sends a binding update with multiple care-of-addresses which match the current link and other links that the mobile node may possibly visit next. After receiving such a binding update, the correspondent nodes and home agent use a new routing header extension to route the packet that will be received by the mobile node at one of the possible care-of-addresses. Thus, the correspondent nodes and home agent can still communicate with the mobile node despite not knowing its exact location while the mobile node moves across links. The proposal presents no new networking entities and the resulting architecture describes a natural extension to the Mobile IPv6 protocol. Alper Yegin Internet Engineering Sun Microsystems, Inc. --Wedge_of_Swans_902_000 Content-Type: TEXT/plain; name="draft-yegin-mobileip-nrouting-00.txt"; charset=us-ascii Content-Description: draft-yegin-mobileip-nrouting-00.txt Content-MD5: vlHXJ5Dner0lNUEMUyhs4Q== Mobile IP Working Group Alper E. Yegin Internet Draft Mohan Parthasarathy Category: Standards Track Carl Williams Expires: March, 2001 Sun Microsystems September, 2000 Mobile IPv6 Neighborhood Routing for Fast Handoff draft-yegin-mobileip-nrouting-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The Mobile IP working group is currently examining proposals to assist in minimizing the latency and packet loss due to handoffs when a Mobile IPv6 node moves from one point of attachment to another. One of the desires to reduce this latency and packet loss is a result of the strict requirements of real-time network services. This proposal specifies a solution whereby the mobile node sends a binding update with multiple care-of-addresses which match the current link and other links that the mobile node may possibly visit next. After receiving such a binding update, the correspondent nodes and home agent use a new routing header extension to route the packet that will be received by the mobile node at one of the possible care-of-addresses. Thus, the correspondent nodes and home agent can still communicate with the mobile node despite not knowing its exact location while the mobile node moves across links. The proposal presents no new networking entities and the resulting architecture describes a natural extension to the Mobile IPv6 protocol. Yegin, Parthasarathy, Williams Expires 25 March 2001 Page 1 Internet Draft Neighborhood Routing 25 September 2000 Contents Status of this Memo 1 Abstract 1 1. Introduction 3 2. Terminology 3 3. Protocol Operation 4 3.1. Access Router Sending Router Advertisements . . . 4 3.2. MN Processing . . . . . . . . . . . . . . . . . . 5 3.3. CN Processing . . . . . . . . . . . . . . . . . . 5 3.4. Access Router Processing Data Packets . . . . . . 6 3.5. Home Agent Processing . . . . . . . . . . . . . . 6 3.6. Other Details . . . . . . . . . . . . . . . . . . 6 4. New Requirements for IPv6 Nodes 7 4.1. Access Routers . . . . . . . . . . . . . . . . . . 7 4.2. Mobile Node . . . . . . . . . . . . . . . . . . . 7 4.3. Correspondent Nodes . . . . . . . . . . . . . . . 8 4.4. Home Agent . . . . . . . . . . . . . . . . . . . . 8 5. Protocol Extensions 9 5.1. Router Advertisement . . . . . . . . . . . . . . . 9 5.2. Binding Update . . . . . . . . . . . . . . . . . . 10 5.3. New Routing Header . . . . . . . . . . . . . . . . 10 6. Security Considerations 14 7. Conclusion 14 References 15 Author's Addresses 15 Yegin, Parthasarathy, Williams Expires 25 March 2001 Page 2 Internet Draft Neighborhood Routing 25 September 2000 1. Introduction MIPv6 draft [1] describes how a MN should send a BU after moving to a new link. When MN is attached to a new link, it configures a new CoA and sends BUs to CNs and HA. Although this would establish "connectivity" as soon as BUs are received by CNs and HA, this method doesn't produce acceptable results for communications that require certain characteristics, such as minimum latency and packet loss . During the time between when MN detaches from old link and the time when BUs are received, MN is "unreachable". All the packets in flight during this period end up at the old link and get dropped. The unreachability problem is due to the lack of knowledge at the CNs and HA about the possible movement of the MN. By the time binding update reaches the CNs and HA, all packets that were sent to the old location of the mobile node are lost. If the MN had provided the information about its neighborhood and if the packet can be routed in that neighborhood, then MN will always be reachable. The "neighborhood" is an area in which the MN may visit in the immediate future. It consists of the known current link and a number of possible other links that the MN might move to next. With this information the CNs and HA will send packets to the "neighborhood" for the MN. Since the MN will be in the "neighborhood" even after detaching from the old link, packets will be delivered successfully. Layer 2 (L2) of access router (AR) can figure out a list of possible next links that MN might visit in the immediate future, by using the layout of ARs in the domain and measurements (e.g. direction of MN), and applying some heuristics. When AR communicates this information to MN, MN can send an extended BU to CNs and HA, telling them about its neighborhood. So with this extended information CNs and HA can send packets to this neighborhood, which tries to reach the MN at the known current link first, and then at the other links in the neighborhood. Packets can be routed to multiple links using a new routing header described later in this document. In this manner, MN can notify CNs and HA where it is now and where else it might be in the immediate future. Instead of "reactively" updating the system to establish connectivity as soon as MN moves, this protocol "proactively" informs CNs and HA to cover MN's possible movements, and refine in time. And although no other entity keeps track of instant movements of MN, it stays reachable. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. Basic Mobile IPv6 terminology is used as defined in [1]. Yegin, Parthasarathy, Williams Expires 25 March 2001 Page 3 Internet Draft Neighborhood Routing 25 September 2000 Additionally, the following terminology is used in this draft: Access Router (AR) The closest router to the mobile node in the visited domain that the mobile node uses to access the network [3]. Neighborhood The ordered list of links which includes the link that MN is currently attached to and a number of other links that MN may visit in the immediate future. Since MN may visit links that are more than one hop away, other links in the neighborhood don't have to be adjacent to current link of attachment. Neighborhood is determined by the L2 of access router MN is currently attached to. Current Care-of-Address Care-of-Address configured using the prefix of the link that MN is currently attached to. Possible Next Link (pn-link) Any of the links in a neighborhood other than the one that MN is currently attached to. Possible Next Prefix (pn-prefix) Prefix of one of the pn-links. Possible Next Care-of-Address (pn-CoA) Care-of-Address configured using one of the pn-prefixes. 3. Protocol Operation This section describes how this proposed protocol works. It uses an example where MN is moving through a series of links: link1, link2, link3, etc. link1 is attached to AR1, and uses the prefix prefix1. Care-of-Address configured by using prefix1 is CoA1. Similarly, link2 is attached to AR2, uses prefix2, and MN configures CoA2 by using prefix2. 3.1. Access Router Sending Router Advertisements Layer 2 of the AR comes up with a list of links that an attached MN might be visiting in the immediate future, by using the layout of ARs in the domain and measurements (e.g. direction of MN), and applying some heuristics. This list would be the "neighborhood of MN". Neighborhood is conveyed to layer 3 in the form of a list of links (e.g. "link1, link2, link3"). Current access router, AR1, needs to map these links to prefixes advertised on each link. One possible way of implementing this mapping could be in the form of a table. This table can be a local one or a centrally maintained one. Note that even without this extension to the protocol, AR1 uses such Yegin, Parthasarathy, Williams Expires 25 March 2001 Page 4 Internet Draft Neighborhood Routing 25 September 2000 a table to advertise its own prefixes on various links. That table can be extended to include other links a MN may visit in this domain. AR1 comes up with a list of prefixes, prefix1, prefix2, etc. after a successful lookup. The first prefix is the one for the link MN is physically attached to. The rest are the prefixes for possible next links in the order of descending possibility. Note that this list is per MN, and its elements and their order can change in time. Now AR1 can send a router advertisement (RA) to MN. This RA includes a prefix information option to carry prefix1 as current prefix, and a number of others to carry pn-prefixes (see section 5.1 3.2. MN Processing When MN receives an RA with pn-prefixes, it can configure one CoA for each prefix. CoA1 will be current CoA, and others pn-CoAs. All the pn-CoAs are marked as deprecated, so that they are not used as source addresses in outgoing packets. Now MN can receive packets that are sent to any of its CoAs. Next, MN sends a new BU to CNs and HA. This BU, in addition to current CoA, contains one pn-CoA destination option sub-option for all pn-CoAs (see section 5.2). 3.3. CN Processing After receiving a BU with pn-CoAs, whenever CN wants to send a packet to MN, it includes a routing header extension in the packet. CN uses new routing header type 1 (instead of type 0) that includes all CoAs as intermediate hops (see section 5.3). The destination of the packet is CoA1, and the routing header is initialized to contain CoA2, CoA3, ..., home address of MN as the route segments. The routing infrastructure makes a best effort to route packet through intermediate hops. But, if a router on the same link as next hop (such as AR1) determines that host at next hop (such as MN at CoA1) is not reachable, it can simply skip this hop, update the routing header, and forward the packet to the following hop (MN at CoA2). If MN is not attached to any of the links, last AR forwards the packet to the home link to be intercepted by HA since the last route segment in the routing header is the home address of the MN (see section 3.5 for more on this). Yegin, Parthasarathy, Williams Expires 25 March 2001 Page 5 Internet Draft Neighborhood Routing 25 September 2000 3.4. Access Router Processing Data Packets When a packet with type 1 routing header arrives, AR1 will forward it to MN for a successful delivery if MN is still attached to link1. It's assumed that L2 of AR can determine whether a MN is attached or not, and convey this information to L3. If MN had already moved to link2 before the packet arrives at AR1, then AR1 would know that MN at CoA1 is no longer attached to link1. AR1 would process the routing header, so that CoA1 is skipped, and the packet is forwarded to next hop, CoA2. This time AR2, seeing that MN at CoA2 is attached to link2, forwards the packet to MN. Although sender of the packet didn't know the exact location of MN, the packet is delivered successfully by using the information about where else MN might be located currently. 3.5. Home Agent Processing As stated in [1], HA intercepts packets from various CNs and tunnels them to MN. Additionally, if HA has the knowledge of pn-CoAs, it puts a routing header type 1 in the encapsulating packet's header. The destination of this packet is CoA1, and the routing header is initialized to contain CoA2, CoA3, ... as the route segments. This way, tunneled packet will be delivered to MN at one of the CoAs. Note that since home address of MN is not included in the routing header (unlike CN processing, see section 3.3), this packet will never be forwarded back to the home link. One special case MAY need to be handled by HA. When a packet from CN with routing header type 1 is not delivered at any of CoAs, it ends up at the HA to be intercepted. If HA blindly processes, the tunneled packet could traverse the same ARs as the original packet and get dropped at the last AR. In order to prevent an extra transmission, HA MAY implement an optional check. HA MAY compare its knowledge of CoAs with the one derived from the routing header of the intercepted packet. If they are same, HA MUST discard the packet. This shows CN already tried the possibilities that HA would try. Sending the packet again won't deliver the packet. This can be the case when MN moved to a different domain, and neither CN nor HA has received the most current BU yet. 3.6. Other Details The neighborhood of MN changes as MN moves within and across links. When MN moves within the same link, current CoA stays the same but pn-CoAs may change. Current CoA changes only when MN moves to another link. Furthermore, each CoA has an associated lifetime and they are removed when their lifetime expires. Each of such changes to the list of CoAs can trigger a new BU transmission. MN proactively makes sure each CN and HA has enough information to Yegin, Parthasarathy, Williams Expires 25 March 2001 Page 6 Internet Draft Neighborhood Routing 25 September 2000 deliver packets wherever it might move next by refining its list of CoAs. In this protocol, if AR doesn't send np-prefixes, or MN doesn't recognize np-prefixes, or MN doesn't send np-CoA sub-options, or CN and HA don't recognize np-CoA sub-options, then this protocol automatically converges to the one in draft [1]. None of the entities need to detect whether new protocol is recognized at others or not. Whenever L2 determines that MN will be staying at the current link for an extended period of time (due to low speed, very large cell, etc.), system can use only one CoA as in [1]. System can use the new protocol to configure pn-CoAs as soon as a possible move to another link is detected. Definition of "immediate future", the heuristic used to come up with a list of next possible links, and maximum number of CoAs to configure on MN are system wide tuning parameters. 4. New Requirements for IPv6 Nodes This protocol extension requires modification to the Access Routers, the Mobile Node, the Correspondent Nodes, and the Home Agent. The proposed MIPv6 extensions are optional to basic Mobile IPv6; networking elements can function with support of the new option independent to any other networking entity providing support. If the extensions are not supported by AR, MN, CN, and HA, the operation will default to the base protocol as defined in [1]. 4.1. Access Routers L3 of AR MUST be capable of interfacing with L2 to obtain a list of links that the MN may be visiting next. The actual interface is beyond the scope of this document. The AR MUST be able to map each link to the prefix information and also be capable of sending router advertisements with the N bit set for these prefixes. Additionally, L3 MUST be capable of determining if a MN is attached to its link or not. The AR MUST be able to process data packets containing the type 1 routing header extension. 4.2. Mobile Node The MN MUST recognize the use of the prefix information option with N bit set so that the extended protocol can be used. The MN MUST be able to configure one CoA for each prefix it receives. The MN MAY perform further processing on the list of prefixes it receives from the AR. This processing MAY include the reordering or reducing the Yegin, Parthasarathy, Williams Expires 25 March 2001 Page 7 Internet Draft Neighborhood Routing 25 September 2000 list of prefixes via some heuristic. The mobile node MUST be able to send a BU with pn-CoA sub-option. The MN MUST be able to process type 1 routing header extensions. 4.3. Correspondent Nodes The CN MUST be able to recognize a BU with pn-CoA sub-option. The CN MUST be capable of maintaining binding cache entries based on the BU with pn-CoA sub-option. The CN MUST be able to send a type 1 routing header extension whenever sending packets to the MN. 4.4. Home Agent The HA MUST be able to recognize BU with pn-CoA sub-option. The HA MUST be capable of maintaining a binding cache entries based on the neighborhood binding updates. The HA MUST be able to send a router header extension of type 1 for all the intercepted packets that are tunneled. The HA MAY also check the router headers in the intercepted packets to handle the case specified in section 3.5. Yegin, Parthasarathy, Williams Expires 25 March 2001 Page 8 Internet Draft Neighborhood Routing 25 September 2000 5. Protocol Extensions 5.1. Router Advertisement This section defines a new bit as part of the prefix information that is sent as part of the router advertisement [4]. Access routers set this bit to indicate that the prefix contained in this option is a pn-prefix (see section 3.1). MN can use this information to configure the additional care of addresses and also use it in the binding updates to indicate its neighborhood. 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 | Prefix Length |L|A|R|N|Resvd1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preferred Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Prefix Information Option N : This indicates that the contained prefix belongs to a router where the MN could possibly be visiting in in the near future. All other fields has the same meaning as that of [4]. If the N bit is not understood by the mobile node, it MUST skip the prefix contained in the option. Thus, this mechanism provides backward compatibility to mobile nodes that does not understand the bit and hence falls back to the old scheme mentioned in the draft [1]. Yegin, Parthasarathy, Williams Expires 25 March 2001 Page 9 Internet Draft Neighborhood Routing 25 September 2000 5.2. Binding Update This section defines a new destination option sub-option for the binding update that lists the possible next care of addresses to be used by the HA or CNs in routing header type 1. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 8 | len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Care-of Address 1 + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Care-of Address n + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Possible Next Care-of-Address Sub-Option (alignment requirement: 8n+6) len : n * 16 where n is the number of care of addresses. The source address of the BUs will be the current CoA. If this sub-option is not understood by the CN or HA, it MUST be skipped as mentioned in the draft [1]. Thus, this mechanism provides backward compatibility to nodes that does not understand the new sub-option and hence falls back to the old scheme mentioned in the draft [1]. 5.3. New Routing Header This proposal defines a new routing header type 1 which is used by CNs and HA when sending packets to MN. This MUST be sent only if CN and HA received a binding update with the new possible next Yegin, Parthasarathy, Williams Expires 25 March 2001 Page 10 Internet Draft Neighborhood Routing 25 September 2000 care-of-address sub-option defined in section 5.2. The Routing header is used by an IPv6 source to list one or more intermediate nodes to be "visited" on the way to a packet's destination. The Routing header is identified by a Next Header value of 43 in the immediately preceding header, and has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | Routing Type | Segments Left | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . type-specific data . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Routing Header Extension All the fields of the routing header remain the same as in type 0 [5] except that the Routing Type is 1. Yegin, Parthasarathy, Williams Expires 25 March 2001 Page 11 Internet Draft Neighborhood Routing 25 September 2000 The Type 1 Routing header has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | Routing Type=1| Segments Left | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Address[1] + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Address[2] + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Address[n] + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Type 1 Routing Header Extension The processing of Routing header type 1 is almost the same except for the difference noted below. A Routing header type 0 is not examined or processed until it reaches the node identified in the Destination Address field of the IPv6 header. But in the case of routing header type 1, the last hop router that forwards the packet to the node identified by the Destination Address of the IPv6 header also processes the packet if the packet can't be delivered. If it knows readily that the node identified by the destination address is reachable, it sends the Yegin, Parthasarathy, Williams Expires 25 March 2001 Page 12 Internet Draft Neighborhood Routing 25 September 2000 packet. If it is not reachable, it swaps the destination addresses with the next hop address contained in the route specific data, as it does with routing header type 0 and forwards the packet to the new destination address. The router that determines that the packet being forwarded is on-link, checks to see whether the destination is reachable or not. It checks for a routing header type 1 and processes it only if the destination is not reachable. The processing is as follows : If (packet being forwarded is on-link) { if (destination is reachable) { Send the packet(*) } else if (routing header type 1 present) { Process the routing header type 1 similar to routing header type 0. Swap the IPv6 destination address with the next hop address in the option and forward the packet to the new destination. } else { drop the packet. } } else { forward the packet using the default IPv6 rules. } (*)If the destination is reachable and the packet was sent to the destination connected on-link, the node receiving the packet would see one of the care of addresses (it sent in the binding update) in the destination field of the IPv6 header, depending on which link it receives the packet. It processes the packet in the following way: if (Segments Left == 0) { Send an ICMP Parameter Problem, Code 0, message to the Source Address, pointing to the Hdr Ext Len field, and discard the packet } else { Swap the Destination address with the next hop address and feed the packet for transmission. As all the addresses belongs to this node, this will eventually stop when the last hop address is processed. } Yegin, Parthasarathy, Williams Expires 25 March 2001 Page 13 Internet Draft Neighborhood Routing 25 September 2000 6. Security Considerations Binding updates MUST be protected by IPsec Authentication header. When Routing header type 1 is used and IPsec is also used, routing header should be protected by IPsec. The processing of routing header type 1 is the same as routing header type 0 in the context of IPsec. 7. Conclusion Standard routing expects a host to be reachable at a certain link. New protocol extends this to reaching a host at one of the possible links it might be attached at that time. All the traffic can be delivered to MN at any of those links by MN knowing which other links it might be moving to and informing CNs and HA about them. AR determines this link information using L2 knowledge and sends it to MN. This new protocol is a natural extension to the one in MIPv6 draft [1]. It doesn't define new networking entities. The data flow is the same as specified in the MIPv6 draft [1]: MN configures CoAs by using the prefixes in RAs, MN informs CNs and HA by use of BUs, CNs use routing header to deliver packets to MN, and HA intercepts packets from CNs and tunnels them. The new protocol shows up as extensions to router advertisement, binding update, and routing header. These extensions are ignored when they are not recognized by any of the networking entities, and the system automatically converges to regular MIPv6. As soon as MN moves to a new link, it can start sending and receiving packets without anyone else keeping track of instant movements of MN. This protocol allows the MIPv6 infrastructure to dynamically adapt itself to changing conditions and different deployment scenarios. If handoffs are happening frequently (fast MN movement, too small cells, etc.), MN sends more CoAs in its BUs. If no handoff is expected for a while, none of the new extensions are used, therefore only one CoA is sent and the system becomes what's described in [1]. Yegin, Parthasarathy, Williams Expires 25 March 2001 Page 14 Internet Draft Neighborhood Routing 25 September 2000 References [1] D. Johnson and C. Perkins. "Mobility support in IPv6", draft-ietf-mobileip-ipv6-12.txt, April 2000. [2] S. Bradner. "Key words for use in RFCs to Indicate Requirement Levels", Request for Comments (Best Current Practice) 2119, March 1997. [3] J. Malinen and C. Perkins. "Mobile IPv6 Regional Registrations", draft-malinen-mobileip-regreg6-00.txt, July 2000. [4] T. Narten, E. Nordmark, and W. Simpson. "Neighbor Discovery for IP Version 6 (IPv6)", Request for Comments (Draft Standard) 2461, December 1998. [5] S. Deering and R. Hinden. "Internet Protocol, Version 6 (IPv6)", Request for Comments (Draft Standard) 2460, December 1998. Author's Addresses Alper E. Yegin Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, CA 94303 USA phone: +1 650 786 4013 fax: +1 650 786 5896 email: Alper.Yegin@eng.sun.com Mohan Parthasarathy Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, CA 94303 USA phone: +1 650 786 8885 fax: +1 650 786 5896 email: Mohan.Parthasarathy@eng.sun.com Carl Williams Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, CA 94303 USA phone: +1 650 786 5186 fax: +1 650 786 5896 email: Carl.Williams@eng.sun.com Yegin, Parthasarathy, Williams Expires 25 March 2001 Page 15 --Wedge_of_Swans_902_000-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Sep 26 14:21: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 SMTP id OAA13865 for ; Tue, 26 Sep 2000 14:21:06 -0400 (EDT) Received: from standards (47.234.32.16:2764) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB984A4@standards.nortelnetworks.com>; Tue, 26 Sep 2000 14:04:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32729 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 26 Sep 2000 14:04:52 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9848E@standards.nortelnetworks.com>; Tue, 26 Sep 2000 13:54:52 -0400 Received: from vanda-bj.vandagroup.com.cn ([202.106.134.178]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id NAA20492 for ; Tue, 26 Sep 2000 13:08:54 -0500 (CDT) Received: from SIX by vanda-bj.vandagroup.com.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1457.7) id TSGGQ8LT; Wed, 27 Sep 2000 02:11:31 +0800 Message-ID: Date: Tue, 26 Sep 2000 01:00:37 PM Reply-To: D5bFu167H@PUBLIC.STA.NET.CN Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: D5bFu167H@PUBLIC.STA.NET.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-743-8442 (24 hrs) $10,000 IN 30 - 45 DAYS RETIREMENT IN 3-5 YEARS Please accept our deepest apologizes, if you received this email unsolicited, and you can be removed automatically below. *************************************************************************************** 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 Tue Sep 26 16:27: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 SMTP id QAA15509 for ; Tue, 26 Sep 2000 16:27:01 -0400 (EDT) Received: from standards (47.234.32.16:1317) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB98671@standards.nortelnetworks.com>; Tue, 26 Sep 2000 16:10:29 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 33319 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 26 Sep 2000 16:10:28 -0400 Received: from motgate.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9866B@standards.nortelnetworks.com>; Tue, 26 Sep 2000 16:00:27 -0400 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id NAA26197 for ; Tue, 26 Sep 2000 13:14:27 -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 NAA24161 for ; Tue, 26 Sep 2000 13:14:27 -0700 (MST)] Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2650.21) id ; Tue, 26 Sep 2000 15:14:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-7" Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A0498FAB6@il27exm02.cig.mot.com> Date: Tue, 26 Sep 2000 15:14:24 -0500 Reply-To: Nakhjiri Madjid-MNAKHJI1 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Nakhjiri Madjid-MNAKHJI1 Subject: Re: [MOBILE-IP] the IGSN mystery (?) X-To: "jonne.soininen@NOKIA.COM" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Dear Jonne, Thanks a lot for your response. I was away for a few days. Christos also responded with the same doc number. I need to track this one down. I was not sure about the WG, since I also got another respond saying that it is discussed in 3GPP2? As I understand Technical reports are from individual companies. You know which company it was from? Regards, Madjid Nakhjiri &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& Madjid Nakhjiri mnakhji1@email.mot.com Motorola, GTSS, IP Network Standards 1501 West Shure Drive,(IL27/2D5) Arlington Heights, IL 60004 USA Phone: +1 847-632-5030 Fax: +1 847-632-7912 It hurts to be on the cutting EDGE &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& Hi there and sorry for the delay but i wasnt at work during the weekend The group you re looking for is the 3GPP TSG and the document im reffering to is the 3G TR 23.923 V.3.0.0 document Hope that helps. Best Regards Christos -- Christos Chrisanthakopoulos INTRACOM S.A. Development Programmes Department Panepistimiou 254 26443 Patras GREECE Tel: (+30 61) 465153 (direct) E-mail: xchr@intranet.gr URL: www.intracom.gr -----Original Message----- From: jonne.soininen@NOKIA.COM [mailto:jonne.soininen@NOKIA.COM] Sent: Friday, September 22, 2000 4:10 AM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] the IGSN mystery (?) Hello, I'll try to answer some of the questions. Usage of MIP was discussed in 3GPP TSG SA WG2 Mobile IP Ad Hoc about a year ago. It produced a Technical Report on the feasibility of the usage Mobile IP for intra-system mobility management. The document number was 23.923 and you can find it on the 3GPP web site (http://www.3gpp.org/). The IGSN was a concept that was studied in this Ad Hoc. It was not found feasible at the time. You can find the reasons in the end of the 23.923. Cheers, Jonne. > -----Original Message----- > From: EXT Nakhjiri Madjid-MNAKHJI1 > [mailto:Madjid.Nakhjiri@MOTOROLA.COM] > Sent: 16. September 2000 0:35 > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] the IGSN mystery (?) > > > Christos, > > Could you please tell me which 3GPP or 3GPP2 working group the MIP > integration into 3G networks is being discussed? > > Thank you in advance, > > Madjid Nakhjiri > &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& > Madjid Nakhjiri mnakhji1@email.mot.com > Motorola, IP Network Standards > 1501 West Shure Drive,(IL27/2D5) > Arlington Heights, IL 60004 USA > Phone: +1 847-632-5030 Fax: +1 847-632-7912 > > It hurts to be on the cutting EDGE > &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& > > > -----Original Message----- > From: Christos Chrisanthakopoulos [mailto:xchr@INTRANET.GR] > Sent: Friday, September 15, 2000 1:56 AM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: [MOBILE-IP] the IGSN mystery (?) > > > Dear all, > > Regarding the stepwised integration of MIP in 3G networks > being proposed > > I would like to know if there is any additional information about > the IGSN node (more in focus details if possible) or is it > eventually that it behaves and functions more or less like > a GGSN in the CN? > > Thanks for your time > > Christos > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Sep 26 18:32: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 SMTP id SAA17023 for ; Tue, 26 Sep 2000 18:32:20 -0400 (EDT) Received: from standards (47.234.32.16:3660) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9874E@standards.nortelnetworks.com>; Tue, 26 Sep 2000 18:16:01 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 33609 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 26 Sep 2000 18:16:00 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9874D@standards.nortelnetworks.com>; Tue, 26 Sep 2000 18:16:00 -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 QAA23512 for ; Tue, 26 Sep 2000 16:30:04 -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 PAA15048 for ; Tue, 26 Sep 2000 15:30:03 -0700 (PDT) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id PAA19209 for ; Tue, 26 Sep 2000 15:30:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Tue, 26 Sep 2000 15:28:01 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: [MOBILE-IP] New Pro-active Foreign Agent I-D available To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM All, I sent the latest draft to the secretariat. For those of you that would like a preview of the draft, it is available at http://www.cdma-2000.org/draft-calhoun-mobileip-proactive-fa-02.txt Enjoy, PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Sep 26 18: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 SMTP id SAA17085 for ; Tue, 26 Sep 2000 18:39:27 -0400 (EDT) Received: from standards (47.234.32.16:3660) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB98784@standards.nortelnetworks.com>; Tue, 26 Sep 2000 18:20:55 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 33682 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 26 Sep 2000 18:20:54 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB98783@standards.nortelnetworks.com>; Tue, 26 Sep 2000 18:20:54 -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 QAA25835 for ; Tue, 26 Sep 2000 16:34:58 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA16104 for ; Tue, 26 Sep 2000 15:34:57 -0700 (PDT) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id PAA19331 for ; Tue, 26 Sep 2000 15:34:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Tue, 26 Sep 2000 15:32:56 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: [MOBILE-IP] Fast Handoff v4 archives available To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM All, The archives for the Mobile IP v4 fast handoff design team are available at http://www.diameter.org/cgi-bin/lwgate/FAST-HANDOFF/archives/. Enjoy PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Sep 26 21:26: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 SMTP id VAA18730 for ; Tue, 26 Sep 2000 21:26:03 -0400 (EDT) Received: from standards (47.234.32.16:3324) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB98895@standards.nortelnetworks.com>; Tue, 26 Sep 2000 21:09:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 34027 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 26 Sep 2000 21:09:56 -0400 Received: from sirius.ctr.columbia.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB98894@standards.nortelnetworks.com>; Tue, 26 Sep 2000 21:09:54 -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 VAA18567; Tue, 26 Sep 2000 21:23:56 -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: <39D17A20.4EAD425E@comet.columbia.edu> Date: Tue, 26 Sep 2000 21:40:00 -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] Fast Handoff v4 archives available X-To: "pcalhoun@eng.sun.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit That is interesting read Pat. Should I be the first to announce that fast/ proactive is dead in IETF? Andrew "pcalhoun@eng.sun.com" wrote: > > All, > > The archives for the Mobile IP v4 fast handoff design team are available at > http://www.diameter.org/cgi-bin/lwgate/FAST-HANDOFF/archives/. > > Enjoy > > PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Sep 27 07:05: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 SMTP id HAA08041 for ; Wed, 27 Sep 2000 07:05:51 -0400 (EDT) Received: from standards (47.234.32.16:4331) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB98A0D@standards.nortelnetworks.com>; Wed, 27 Sep 2000 6:48:58 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 34524 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 27 Sep 2000 06:48:58 -0400 Received: from brasilis (200.241.201.17:51332) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB989FF@standards.nortelnetworks.com>; Wed, 27 Sep 2000 6:38:56 -0400 Received: from monorailpc by brasilis (SMI-8.6/SMI-SVR4) id HAA19708; Wed, 27 Sep 2000 07:57:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Message-ID: <200009271457.HAA19708@brasilis> Date: Wed, 27 Sep 2000 07:57:26 -0700 Reply-To: donald453@BBC.CO.UK Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: donald453@BBC.CO.UK Subject: [MOBILE-IP] Porche Boxter or Luxury Cruise Earn $$$ In Days This Works!!! To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Dear Friend, This really works! Have the faith, don't miss this opportunity, get involved also, and it will work for you as it does for us!!!!! Thank you for your time and interest. This email contains the ENTIRE PLAN of how YOU can make $50,000 or more in the next 90 days simply sending email! Seem impossible? Just read on and see how easy this is.... Due to the popularity of this letter on the Internet, a major nightly news program recently devoted an entire show to the investigation of the program described below to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved that there are absolutely no laws prohibiting participation in the program. This has helped to show people that this is a simple, harmless and fun way to make some extra money at home. The results have been truly remarkable. So many people are participating that those involved are doing much better than ever before. Since everyone makes more as more people try it out, its been very exciting. You will understand once you try it yourself! ********* THE ENTIRE PLAN IS HERE BELOW ********* *** Print This Now For Future Reference *** $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make at least $50,000 in less than 90 days, please read this program...THEN READ IT AGAIN!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ THIS IS A LEGITIMATE, LEGAL, MONEY MAKING OPPORTUNITY!! It does NOT require you to come into contact with people or make or take any telephone calls. Just follow the instructions, and you will make money. This simplified e-mail marketing program works perfectly 100% EVERY TIME! E-mail is the sales tool of the future. Take advantage of this virtually free method of advertising NOW!!! The longer you wait, the more people will be doing business using email. Get your piece of this action!!! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hello - My name is Johnathon Rourke, I'm from Rhode Island. The enclosed information is something I almost let slip through my fingers. Fortunately, sometime later I re-read everything and gave some thought and study to it. Two years ago, the corporation I worked for for the past twelve years down-sized and my position was eliminated. After unproductive job interviews, I decided to open my own business. Over the past year, I incurred many unforeseen financial problems. I owed my family, friends and creditors over $35,000. The economy was taking a toll on my business and I just couldn´t seem to make ends meet. I had to refinance and borrow against my home to support my family and struggling business. AT THAT MOMENT something significant happened in my life. I am writing toshare the experience in hopes that this could change your life FOREVER. FINANCIALLY$$$!!! In mid December, I received this program in my e-mail. Six months prior to receiving this program I had been sending away for information on various business opportunities. All of the programs I received, in my opinion, were not cost effective. They were either too difficult for me to comprehend or the initial investment was too much for me to risk to see if they would work. But as I was saying, in December of 1997 I received this program. I didn´t send for it, or ask for it, they just got my name off a mailing list. THANK GOODNESS FOR THAT!!! After reading it several times, to make sure I was reading it correctly. I couldn´t believe my eyes! Here was a MONEY MAKING MACHINE I could start immediately without any debt. Like most of you I was still a little skeptical and a little worried about the legal aspects of it all. So I checked it out with the U.S. Post Office (1-800-725-2161 24-hrs) and they confirmed that it is indeed legal! After determining the program was LEGAL I decided "WHY NOT!?!??" Initially I sent out 10,000 e-mails. It cost me about $15 for my time on-line. The great thing about e-mail is that I don´t need any money for printing to send out the program, and because I also send the product (reports) by e-mail, my only expense is my time. In less than one week, I was starting to receive orders for REPORT #1. By January 13, I had received 26 orders for REPORT #1. Your goal is to "RECEIVE at least 20 ORDERS FOR REPORT #1 WITHIN 2 WEEKS. IF YOU DON´T, SEND OUT MORE PROGRAMS UNTIL YOU DO. My first step in making $50,000 in 90 days was done. By January 30, I had received 196 orders for REPORT #2. Your goal is to "RECEIVE AT LEAST 100+ ORDERS FOR REPORT #2 WITHIN 2 WEEKS. IF NOT, SEND OUT MORE PROGRAMS UNTIL YOU DO. ONCE YOU HAVE 100 ORDERS, THE REST IS EASY, RELAX, YOU WILL MAKE YOUR $50,000 GOAL." Well, I had 196 orders for REPORT #2, 96 more than I needed. So I sat back and relaxed. By March 1, of my e-mailing of 10,000, I received $58,000 with more coming in every day. I paid off ALL my debts and bought a much needed new car! Please take your time to read this plan, IT WILL CHANGE YOUR LIFE FOREVER$!!! Remember, it won´t work if you don´t try it. This program does work, but you must follow it EXACTLY! Especially the rules of not trying to place your name in a different place. It won´t work and you´ll lose out on a lot of money! In order for this program to work, you must meet your goal of 20+ orders for REPORT #1, and 100+ orders for REPORT #2 and you will make $50,000 or more in 90 days. I AM LIVING PROOF THAT IT WORKS!!! If you choose not to participate in this program, I am sorry. It really is a great opportunity with little cost or risk to you. If you choose to participate, follow the program and you will be on your way to financial security. If you are a fellow business owner and are in financial trouble like I was, or you want to start your own business, consider this a sign. I DID! $$ Sincerely, Johnathon Rourke ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A PERSONAL NOTE FROM THE ORIGINATOR OF THIS PROGRAM: By the time you have read the enclosed program and reports, you should have concluded that such a program, and one that is legal, could not have been created by an amateur. Let me tell you a little about myself. I had a profitable business for 10 years. Then in 1979 my business began falling off. I was doing the same things that were previously successful for me, but it wasn´t working. Finally, I figured it out. It wasn´t me, it was the economy. Inflation and recession had replaced the stable economy that had been with us since 1945. I don´t have to tell you what happened to the unemployment rate...because many of you know from first hand experience. There were more failures and bankruptcies than ever before. The middle class was vanishing. Those who knew what they were doing invested wisely and moved up. Those who did not, including those who never had anything to save or invest, were moving down into the ranks of the poor. As the saying goes, "THE RICH GET RICHER AND THE POOR GET POORER." The traditional methods of making money will never allow you to "move up" or "get rich." Inflation will see to that. You have just received information that can give you financial freedom for the rest of your life, with "NO RISK" and "JUST A LITTLE BIT OF EFFORT." You can make more money in the next few months than you have ever imagined. I should also point out that I will not see a penny of this money, nor anyone else who has provided a testimonial for this program. I have retired from the program after sending thousands and thousands of programs. Follow the program EXACTLY AS INSTRUCTED. Do not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report to everyone you can think of. One of the people you send this to may send out 50,000...and your name will be on every one of them! Remember though, the more you send out, the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU!! NOW DO IT!! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Before you delete this program from your in box, as I almost did, take a little time to read it and REALLY THINK ABOUT IT. Get a pencil and figure out what could happen when YOU participate. Figure out the worst possible response and no matter how you calculate it, you will still make a lot of money! You will definitely get back what you invested. Any doubts you have will vanish when your first orders come in. $$$ IT WORKS!!! $$$ Jody Jacobs Richmond, VA ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ HERE´S HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS OF DOLLAR$$$$!!!! This method of raising capital REALLY WORKS 100% EVERY TIME. I am sure that you could use up to $50,000 or more in the next 90 days. Before you say "BULL... ", please read this program carefully. This is not a chain letter, but a perfectly legal money making business. As with all multi-level businesses, we build our business by recruiting new partners and selling our products. Every state in the USA allows you to recruit new multi-level business partners, and we sell and deliver a product for EVERY dollar received. YOUR ORDERS COME BY MAIL AND ARE FILLED BY E-MAIL, so you are not involved in personal selling. You do it privately in your own home, store or office. This is the EASIEST marketing plan anywhere! It is simply order-filling by email! ******************************************************************* The product is informational and instructional material, keys to the secrets for everyone on how to open the doors to the magic world of E- COMMERCE, the information highway, the wave of the future! PLAN SUMMARY: (1) You order the 4 reports listed below ($5 US each.) They come to you by email. (2) Save a copy of this entire letter and put your name after Report #1 and move the other names down. (3) Via the internet, access Yahoo.com or any of the other major search engines to locate hundreds of bulk email service companies (search for "bulk email") and have them send 25,000 - 50,000 emails for you about $49+). (4) Orders will come to you by postal mail - simply email them the Report they ordered. Let me ask you - isn´t this about as easy as it gets? ************************************************************ By the way there are over 50 MILLION email addresses with millions more joining the internet each year so don´t worry about "running out" or "saturation". People are used to seeing and hearing the same advertisements every day on radio/TV. How many times have you received the same pizza flyers on your door? Then one day you are hungry for pizza and you order one. Same thing with this letter. I received this letter many times - then one day I decided it was time to try it. ************************************************************ YOU CAN START TODAY - JUST DO THESE EASY STEPS: STEP #1. ORDER THE FOUR REPORTS Order the four reports shown on the list below (you can´t sell them if you don´t order them). -- For each report, send $5.00 (US) CASH, the NAME & NUMBER OF THE REPORT YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR NAME & RETURN ADDRESS (in case of a problem) to the person whose name appears on the list next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE IN CASE OF ANY MAIL PROBLEMS! Within a few days you will receive, by e-mail, each of the four reports. Save them on your computer so you can send them to the 1,000´s of people who will order them from you. STEP #2. ADD YOUR MAILING ADDRESS TO THIS LETTER a. Look below for the listing of the four reports. b. After you´ve ordered the four reports, delete the name and address under REPORT #4. This person has made it through the cycle. c. Move the name and address under REPORT #3 down to REPORT #4. d. Move the name and address under REPORT #2 down to REPORT #3. e. Move the name and address under REPORT #1 down to REPORT #2. f. Insert your name and address in the REPORT #1 position. Please make sure you COPY ALL INFORMATION, every name and address, ACCURATELY! STEP #3. SAVE THIS LETTER Take this entire letter, including the modified list of names, and save it to your computer. Make NO changes to these instructions. Now you are ready to use this entire email to send by email to prospects. Report #1 will tell you how to download bulk email software and email addresses so you can send it out to thousands of people while you sleep! Remember that 50,000+ new people are joining the internet every month. Your cost to participate in this is practically nothing; surely you can afford $20 (US) and initial bulk mailing cost. You obviously already have a computer and an Internet connection and e-mail is FREE! There are two primary methods of building your downline: METHOD #1: SENDING BULK E-MAIL Let´s say that you decide to start small, just to see how it goes, and we´ll assume you and all those involved email out only 2,000 programs each. Let´s also assume that the mailing receives a 0.5% response. The response could be much better. Also, many people will email out hundreds of thousands of programs instead of 2,000. (Why stop at 2000?). But continuing with this example, you send out only 2,000 programs. With a 0.5% response, that is only 10 orders for REPORT #1. Those 10 people respond by sending out 2,000 programs each for a total of 20,000. Out of those 0.5% 100 people respond and order REPORT #2. Those 100 mail out 2,000 programs each for a total of 200,000. The 0.5% response to that is 1,000 orders for REPORT #3. Those 1,000 send out 2,000 programs each for a 2,000,000 total. The 0.5% response to that is 10,000 orders for REPORT #4. That´s 10,000 $5 bills for you. CASH!!! Your total income in this example is $50 + $500 + $5,000 + $50,000 for a total of $55,550!!! REMEMBER FRIEND, THIS IS ASSUMING 1,990 OUT OF THE 2,000 PEOPLE YOU MAIL TO WILL DO ABSOLUTELY NOTHING AND TRASH THIS PROGRAM! DARE TO THINK FOR A MOMENT WHAT WOULD HAPPEN IF EVERYONE, OR HALF SENT OUT 100,000 PROGRAMS INSTEAD OF 2,000. Believe me, many people will do just that, and more! METHOD #2: PLACING FREE ADS ON THE INTERNET Advertising on the internet is very, very inexpensive, and there are HUNDREDS of FREE places to advertise. Let´s say you decide to start small just to see how well it works. Assume your goal is to get ONLY 10 people to participate on your first level. (Placing a lot of FREE ads on the Internet will EASILY get a larger response.) Also assume that everyone else in YOUR ORGANIZATION gets ONLY 10 downline members. Look how this small number accumulates to achieve the STAGGERING results below: 1st level--your first 10 send you $5..................................$50 2nd level--10 members from those 10 ($5 x 100).............$500 3rd level--10 members from those 100 ($5 x 1000)........$5,000 4th level--10 members from those 1000 ($5 x 10,000)..$50,000 $$$$$$ THIS TOTALS ----------$55,550 $$$$$$ AMAZING ISN´T IT? Remember friends, this assumes that the people who participate only recruit 10 people each. Think for a moment what would happen if they got 20 people to participate! Most people get 100´s of participants and many will continue to work this program, sending out programs WITH YOUR NAME ON THEM for years! THINK ABOUT IT! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ People are going to get emails about this plan from you or somebody else and many will work this plan. The question is, don´t you want your name to be on the emails they will send out? * * * DON´T MISS OUT!!! * * * JUST TRY IT ONCE!!! * * * * * SEE WHAT HAPPENS!!! *** YOU´LL BE AMAZED!!!* * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ALWAYS PROVIDE SAME-DAY SERVICE ON ALL ORDERS! This will guarantee that the e-mail THEY send out with YOUR name and address on it will be prompt because they can´t advertise until they receive the report! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ GET STARTED TODAY: PLACE YOUR ORDER FOR THE FOUR REPORTS NOW. Notes: ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR EACH REPORT. CHECKS NOT ACCEPTED. Make sure the cash is concealed by wrapping it in two sheets of paper. On one of those sheets of paper write: (a) the number & name of the report you are ordering (b) your e-mail address, and (c) your name & postal address. REPORT #1 "The Insider´s Guide to Advertising for Free on the Internet" ORDER REPORT #1 FROM: Andrew Skidmore 9379 Alexander Rd Alexander, NY 14005 USA REPORT #2 "The Insider´s Guide to Sending Bulk E-mail on the Internet" ORDER REPORT #2 FROM: Lars Pedersen Skejbygaardsvej 7, 1, 10 8240 Risskov Denmark REPORT #3 "The Secrets to Multilevel Marketing on the Internet" ORDER REPORT #3 FROM: John Cole Werner PO Box 3281 Lihue, HI 96766 REPORT #4 "How to become a Millionaire utilizing the Power of Multilevel Marketing and the Internet" ORDER REPORT #4 FROM: Zac Majors 2242 E Woodchuck Way Sandy, UT 84093 ******* TIPS FOR SUCCESS ******* TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the directions accurately. Send for the four reports IMMEDIATELY so you will have them when the orders start coming in because: When you receive a $5 order, you MUST send out the requested product/report. It is required for this to be a legal business and they need the reports to send out their letters (with your name on them!) -- ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. -- Be patient and persistent with this program - If you follow the instructions exactly - results WILL FOLLOW. $$$$ ******* YOUR SUCCESS GUIDELINES ******* Follow these guidelines to guarantee your success: If you don´t receive 20 orders for REPORT #1 within two weeks, continue advertising or sending e-mails until you do. Then, a couple of weeks later you should receive at least 100 orders for REPORT #2. If you don´t, continue advertising or sending e-mails until you do. Once you have received 100 or more orders for REPORT #2, YOU CAN RELAX, because the system is already working for you, and the cash will continue to roll in! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in front of a DIFFERENT report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. To generate more income, simply send another batch of e-mails or continue placing ads and start the whole process again! There is no limit to the income you will generate from this business! Before you make your decision as to whether or not you participate in this program, please answer one question. ARE YOU HAPPY WITH YOUR PRESENT INCOME OR JOB? If the answer is no, then please look at the following facts about this super simple MLM program: 1. NO face to face selling, NO meetings, NO inventory! NO Telephone calls, NO big cost to start! NOthing to learn, NO skills needed! (Surely you know how to send email?) 2. No equipment to buy - you already have a computer and internet connection - so you have everything you need to fill orders! 3. You are selling a product which does NOT COST ANYTHING TO PRODUCE OR SHIP! (Emailing copies of the reports is FREE!) 4. All of your customers pay you in CA$H! This program will change your LIFE FOREVER!! Look at the potential for you to be able to quit your job and live a life of luxury you could only dream about! Imagine getting out of debt and buying the car and home of your dreams and being able to work a super-high paying leisurely easy business from home! $$$ FINALLY MAKE SOME DREAMS COME TRUE! $$$ ACT NOW! Take your first step toward achieving financial independence. Order the reports and follow the program outlined above-- SUCCESS will be your reward. Thank you for your time and consideration. PLEASE NOTE: If you need help with starting a business, registering a business name, learning how income tax is handled, etc., contact your local office of the Small Business Administration (a Federal Agency) at 1-800-827-5722 for free help and answers to questions. Also, the Internal Revenue Service offers free help via telephone and free seminars about business tax requirements. Your earnings are highly dependent on your activities and advertising. The information contained on this site and in the report constitutes no guarantees stated nor implied. In the event that it is determined that this site or report constitutes a guarantee of any kind, that guarantee is now void. The earnings amounts listed on this site and in the report are estimates only. If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection in Washington, DC. ================================================ Under Bill s.1618 TITLE III passed by the 105th US Congress this letter cannot be considered spam as long as the sender includes contact information and a method of removal. This is a one time e-mail transmission. No request for removal is necessary. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Sep 27 09:32: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 SMTP id JAA11762 for ; Wed, 27 Sep 2000 09:32:38 -0400 (EDT) Received: from standards (47.234.32.16:3195) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB98AFF@standards.nortelnetworks.com>; Wed, 27 Sep 2000 9:15:23 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 34850 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 27 Sep 2000 09:15:23 -0400 Received: from tml-gw.tml.hut.fi (tml.hut.fi) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB98AF6@standards.nortelnetworks.com>; Wed, 27 Sep 2000 9:05:22 -0400 Received: (from smap@localhost) by tml-gw.tml.hut.fi (8.8.7/8.8.7) id QAA27645 for ; Wed, 27 Sep 2000 16:19:27 +0300 Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0) id xma027641; Wed, 27 Sep 00 16:19:16 +0300 Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7]) by mail.tml.hut.fi (8.11.0/8.11.0) with ESMTP id e8RDJFM29183 for ; Wed, 27 Sep 2000 16:19:15 +0300 (EEST) Received: from localhost (lyang@localhost) by morphine.tml.hut.fi (8.9.2/8.7.1) with ESMTP id QAA21141 for ; Wed, 27 Sep 2000 16:19:08 +0300 (EET DST) X-Authentication-Warning: morphine.tml.hut.fi: lyang owned process doing -bs MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Wed, 27 Sep 2000 16:19:08 +0300 Reply-To: Linfeng Yang Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Linfeng Yang Subject: Re: [MOBILE-IP] Implementation question about MIPv6 and IPSec To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200009260742.JAA56379@givry.rennes.enst-bretagne.fr> On Tue, 26 Sep 2000, Francis Dupont wrote: > => An Authentication Header protects all headers, including headers before it. > The mobility draft specifies the home address DO must be before the AH > (then it amends RFC 2460 recommendations, both about DO header/security > headers order and about multiple final DO headers). Thanks your correction! Indeed it is clearly stated in Section 10.2. of MIPv6 draft, but I did not check it last time and did not read Stefan's mail thoroughly. On Fri, 22 Sep 2000, Stefan Schmid wrote: >> => Aime comment was not very clear (:-). The idea is: >> 1- it is easier to put home address and binding update options in the >> same extension header. > > True, but using two extension headers is not difficult either ... The paragraph following the note 3 of RFC 2460 Section 4.1 reads: Each extension header should occur at most once, except for the Destination Options header which should occur at most twice (once before a Routing header and once before the upper-layer header). So, if there is a Routing header, HA should appear alone before it, or with BU compose one DO, but not with two extension headers. Shall we interpret the quoted paragraph this way also concerning HA and BU DO -- if there is no Routing header, HA and BU must compose into one DO, and it should appear immediately before upper-layer header. I added the word, 'immediately', I think it is the underlying thought of the RFC. But this interpretation conflict with I-D. Or we can say the composed DO should appear before AH, and it surely before upper-layer header too. No conflict, but I feel strange for this interpretation. Regards, Linfeng Yang Helsinki University of Technology Telecommunications Software and Multimedia Laboratory P.O.Box 9700, 02015 HUT, Finland Phone: +358 9 451 5250 Fax: +358 9 451 5351 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Sep 27 10:51: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 SMTP id KAA13254 for ; Wed, 27 Sep 2000 10:51:10 -0400 (EDT) Received: from standards (47.234.32.16:3195) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB98C0F@standards.nortelnetworks.com>; Wed, 27 Sep 2000 10:34:46 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 35204 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 27 Sep 2000 10:34:46 -0400 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB98C0E@standards.nortelnetworks.com>; Wed, 27 Sep 2000 10:34:45 -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 e8REkvu28596; Wed, 27 Sep 2000 16:46: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 QAA03702; Wed, 27 Sep 2000 16:46: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 QAA64220; Wed, 27 Sep 2000 16:49:27 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-ID: <200009271449.QAA64220@givry.rennes.enst-bretagne.fr> Date: Wed, 27 Sep 2000 16:49:27 +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 question about MIPv6 and IPSec X-To: Linfeng Yang To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Wed, 27 Sep 2000 16:19:08 +0300. In your previous mail you wrote: > The mobility draft specifies the home address DO must be before the AH > (then it amends RFC 2460 recommendations, both about DO header/security > headers order and about multiple final DO headers). The paragraph following the note 3 of RFC 2460 Section 4.1 reads: Each extension header should occur at most once, except for the Destination Options header which should occur at most twice (once before a Routing header and once before the upper-layer header). => this is modified by the mobile IPv6 draft which should state this fact far more clearly. So, if there is a Routing header, HA should appear alone before it, or with BU compose one DO, but not with two extension headers. Shall we interpret the quoted paragraph this way also concerning HA and BU DO -- if there is no Routing header, HA and BU must compose into one DO, and it should appear immediately before upper-layer header. I added the word, 'immediately', I think it is the underlying thought of the RFC. But this interpretation conflict with I-D. => yes, the I-D and the RFC conflicts. Or we can say the composed DO should appear before AH, and it surely before upper-layer header too. No conflict, but I feel strange for this interpretation. => I expect to get a clear statement about that in the new mobility draft. For the moment the I-D (abusively) preempts RFC 2460 recommendations... Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Sep 27 11:00: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 SMTP id LAA13478 for ; Wed, 27 Sep 2000 11:00:43 -0400 (EDT) Received: from standards (47.234.32.16:3195) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB98C62@standards.nortelnetworks.com>; Wed, 27 Sep 2000 10:44:15 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 35320 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 27 Sep 2000 10:44:15 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB98C61@standards.nortelnetworks.com>; Wed, 27 Sep 2000 10:44:15 -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 IAA08242; Wed, 27 Sep 2000 08:58:18 -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 HAA22994; Wed, 27 Sep 2000 07:58:18 -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 HAA06742; Wed, 27 Sep 2000 07:58:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Wed, 27 Sep 2000 07:56:12 -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 Handoff v4 archives available X-To: campbell@comet.columbia.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <39D17A20.4EAD425E@comet.columbia.edu> > > That is interesting read Pat. Good to hear > > Should I be the first to announce that fast/ proactive > is dead in IETF? Well, you may actually get more attention if you were to announce, say, "free beer" in the IETF. However, given that you'd prefer to announce that fast/proactive work is dead in the IETF, could I ask that you expand sufficiently so that we can understand what you mean? PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Sep 27 11:48: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 SMTP id LAA14684 for ; Wed, 27 Sep 2000 11:48:11 -0400 (EDT) Received: from standards (47.234.32.16:3195) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB98CD1@standards.nortelnetworks.com>; Wed, 27 Sep 2000 11:31:53 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 35457 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 27 Sep 2000 11:31:53 -0400 Received: from topaz.3com.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB98CC9@standards.nortelnetworks.com>; Wed, 27 Sep 2000 11:21:53 -0400 Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e8RFZ0L27848; Wed, 27 Sep 2000 08:35:00 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id e8RFZEu21459; Wed, 27 Sep 2000 08:35:14 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256967.0055D1ED ; Wed, 27 Sep 2000 08:37:23 -0700 X-Lotus-FromDomain: 3COM Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <88256967.0055C6A5.00@hqoutbound.ops.3com.com> Date: Wed, 27 Sep 2000 10:35:25 -0500 Reply-To: Phil_Neumiller@3COM.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Phil Neumiller Subject: [MOBILE-IP] Comments on draft-calhoun-mobileip-proactive-fa-02.txt X-To: pcalhoun@eng.sun.com, tom.hiller@lucent.com, james.kempf@eng.sun.com, mccap@lucent.com, pairla@uiuc.edu, sthalan@email.mot.com, asingh1@email.mot.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM 1). Sec 1.2 says "MNs connect to FAs via direct, link layer connections. I disagree, this is not necessary nor desirable in all cases. The FA in theory could gain access to "subtending" link layer info through a variety of mechanisms. Why must it be assumed that the FA is co-located with the link layer equipment? 2). In the discussion of the triggering mechanism. FA handover candidates should be configurable and/or discoverable automagically, allowing active sets of overlapping coverage areas (more on this below). 3). In 1.2 "problems that must be addressed" section under (1). Why worry about registration? Can't we just go ahead and perform the handoff and register in parallel? If the registration fails then boot the MN, but get the traffic going first at all costs. 4). In section 1.2 sub 3, we should allow bi-cast, and tri-cast to all the candidate FAs that were "discovered" as descibed in 2 above. Gee, this is starting to sound like OBAST! :-) 5). In sec 1.2 sub 6., mobile power consumption can be reduced by having MORE FAs listening and performing selection at the anchor FA. Yikes, this smells of OBAST! :-) 6). In sec 2.1 the GFA in theory could be co-located with the one of the two bi-casting FAs. This would reduce the box count (and this is what OBAST does with its call anchor). 7). With respect to Movement detection, could we not generalize this coverage detection? The MN knows its in the coverage are of a collection of subnets and can establish new FA relationships with each new subnet, selectively dropping the old FA relationships as that coverage disappears. Why can't traffic be deliverec while registration is occuring? Presumably the MN already has connections with other hosts that are valid. 8). If a new link layer is detected by a MN it could tell its current FA about it and the FA would know about all valid hand off candidates for that link type due to hand off candidate discovery as described in 2 above. //BEGIN (:-)) For those of you born after about 1980, Phil is starting to sound like a piece of vinyl with grooves encoded with music that would often get cross threaded causing the needle to play the same grooves of music over and over again. //END (:-)) 9). It would not take much of nudge to make this thing work with a make-before break capability, then I would be happy and probably shut up! Do you want me take a stab at this? 10). In section 3.1, To avoid ping-ponging we can use the trick CDMA uses. USE MAKE BEFORE BREAK, and add and drops multiple simultaneously bi-casted, tri-casted call legs! Then thresholds can be added. You can make decisions like, gee statistically, this particular link layer isn't buying me squat anymore, i.e. I don't use the packets coming from that link layer so that active leg can be dropped. 11). I take objection to including section 9.0-9.2. All link layers should be addressed in generalities with maybe a distinction between fixed and wireless being allowed. Of course I am not a fan of the MIER approach at all. Thanks, Phil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Sep 27 12:45: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 SMTP id MAA16361 for ; Wed, 27 Sep 2000 12:45:53 -0400 (EDT) Received: from standards (47.234.32.16:2067) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB98DC6@standards.nortelnetworks.com>; Wed, 27 Sep 2000 12:27:28 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 35771 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 27 Sep 2000 12:27:28 -0400 Received: from mgw-x1.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB98DC5@standards.nortelnetworks.com>; Wed, 27 Sep 2000 12:27:27 -0400 Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-x1.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e8RGfU418809; Wed, 27 Sep 2000 19:41:30 +0300 (EET DST) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id ; Wed, 27 Sep 2000 11:38:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E359@daeis07nok> Date: Wed, 27 Sep 2000 11:38:10 -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-reg-tunnel-03.txt) To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Folks, This is a WG last call for: Mobile IP Regional Registration - draft-ietf-mobileip-reg-tunnel-03.txt Please send in your comments by October 11th, 2000 to the authors or to the WG discussion list. -Basavaraj From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Sep 27 13:56: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 SMTP id NAA19271 for ; Wed, 27 Sep 2000 13:56:35 -0400 (EDT) Received: from standards (47.234.32.16:3436) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB98EE7@standards.nortelnetworks.com>; Wed, 27 Sep 2000 13:40:22 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0032 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 27 Sep 2000 13:40:22 -0400 Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB98EE6@standards.nortelnetworks.com>; Wed, 27 Sep 2000 13:40:17 -0400 Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com [172.18.242.183]) by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e8RHsM413714 for ; Wed, 27 Sep 2000 20:54:22 +0300 (EET DST) Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id ; Wed, 27 Sep 2000 12:54:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E35B@daeis07nok> Date: Wed, 27 Sep 2000 12:51:02 -0500 Reply-To: Basavaraj.Patil@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: Re: [MOBILE-IP] Fast Handoff v4 archives available To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > That is interesting read Pat. > > Should I be the first to announce that fast/ proactive > is dead in IETF? Andrew, I am trying to understand what you are trying to say here. Can you explain your opinion? -Basavaraj > > Andrew > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Sep 27 15:38:49 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21196 for ; Wed, 27 Sep 2000 15:38:49 -0400 (EDT) Received: from standards (47.234.32.16:3436) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB99004@standards.nortelnetworks.com>; Wed, 27 Sep 2000 15:22:33 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0409 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 27 Sep 2000 15:22:33 -0400 Received: from sirius.ctr.columbia.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB99001@standards.nortelnetworks.com>; Wed, 27 Sep 2000 15:22:31 -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 PAA29518; Wed, 27 Sep 2000 15:36:22 -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: <39D27A27.E7029F87@comet.columbia.edu> Date: Wed, 27 Sep 2000 15:52:23 -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] Fast Handoff v4 archives available X-To: "pcalhoun@eng.sun.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Pat and Basavaraj: First, my observations may be completely unfounded since I have not the experience of the design team. While I am not party to the process (and as Pat points out its easy to say "free beer") I had greater expectations given the flurry of activity, ideas and IDs in this space, and the number of real systems that have been built and experience gained with. Let me briefly explain my knee jerk reaction. I think there are a number of conclusions one can draw from reading the archive and the ID on a technical level and from a process point of view. Regards the process: I thought the idea was to come up with a set of requirements, then a strawman proposal that sort consensus and met the requirements? (Reading between the lines from the archive) It looks like the starting point was too narrow? It looks like the output from the design team resulted in deltas to existing IDs? (Why are these two IDs technically superior to others?). It looks like the process and results are narrow? Both IDs are complex and coupled far too closely to the 3G mindset/RANview: 3GPP2 air interface is only one type of cellular technology and cellular is only one type of wireless network, etc. In addition, weeding out some IDs because they didn't support tunneling (e.g., Hawaii) or MIP messaging (e.g., CIP), etc. was a bad call in a process that should have been open and inclusive and now looks like on the surface to have preselected two IDs (i.e., fast handoff/ proactive IDs) that have not been proven "better" than others. Again, I could be way off here on my reading of events. Finally, I still firmly believe that Mobile IP will not be widely deployed until efficient handoff and paging are incorporated. I just don't think we have moved very far forward on this. So I'm very supportive of the work but surprised at the output. Best, Andrew "pcalhoun@eng.sun.com" wrote: > > > > > That is interesting read Pat. > > Good to hear > > > > > Should I be the first to announce that fast/ proactive > > is dead in IETF? > > Well, you may actually get more attention if you were to announce, say, "free > beer" in the IETF. However, given that you'd prefer to announce that > fast/proactive work is dead in the IETF, could I ask that you expand > sufficiently so that we can understand what you mean? > > PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Sep 27 15: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 SMTP id PAA21554 for ; Wed, 27 Sep 2000 15:58:29 -0400 (EDT) Received: from standards (47.234.32.16:3436) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB99066@standards.nortelnetworks.com>; Wed, 27 Sep 2000 15:42:15 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0523 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 27 Sep 2000 15:42:15 -0400 Received: from motgate.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9905F@standards.nortelnetworks.com>; Wed, 27 Sep 2000 15:32:14 -0400 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id MAA11499 for ; Wed, 27 Sep 2000 12:46:17 -0700 (MST)] Received: [from il75exm02.cig.mot.com (IL75EXM02.cig.mot.com [136.182.110.102]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id MAA20031 for ; Wed, 27 Sep 2000 12:46:17 -0700 (MST)] Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2650.21) id ; Wed, 27 Sep 2000 14:45:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A0498FABA@il27exm02.cig.mot.com> Date: Wed, 27 Sep 2000 14:45:56 -0500 Reply-To: Nakhjiri Madjid-MNAKHJI1 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Nakhjiri Madjid-MNAKHJI1 Subject: Re: [MOBILE-IP] Implementation question about MIPv6 and IPSec X-To: "Francis.Dupont@ENST-BRETAGNE.FR" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM I am interested in this conversation, but unfortunately cannot follow all the details and would like to do some reading on the interworking of MIPv6 and IPSec. Should I go to the RFC 2460, or is there a draft that is closer to the subject. Thank you in Advance, Madjid Nakhjiri &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& Madjid Nakhjiri mnakhji1@email.mot.com Motorola, GTSS, IP Network Standards 1501 West Shure Drive,(IL27/2D5) Arlington Heights, IL 60004 USA Phone: +1 847-632-5030 Fax: +1 847-632-7912 It hurts to be on the cutting EDGE &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& -----Original Message----- From: Francis Dupont [mailto:Francis.Dupont@ENST-BRETAGNE.FR] Sent: Wednesday, September 27, 2000 9:49 AM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] Implementation question about MIPv6 and IPSec In your previous mail you wrote: > The mobility draft specifies the home address DO must be before the AH > (then it amends RFC 2460 recommendations, both about DO header/security > headers order and about multiple final DO headers). The paragraph following the note 3 of RFC 2460 Section 4.1 reads: Each extension header should occur at most once, except for the Destination Options header which should occur at most twice (once before a Routing header and once before the upper-layer header). => this is modified by the mobile IPv6 draft which should state this fact far more clearly. So, if there is a Routing header, HA should appear alone before it, or with BU compose one DO, but not with two extension headers. Shall we interpret the quoted paragraph this way also concerning HA and BU DO -- if there is no Routing header, HA and BU must compose into one DO, and it should appear immediately before upper-layer header. I added the word, 'immediately', I think it is the underlying thought of the RFC. But this interpretation conflict with I-D. => yes, the I-D and the RFC conflicts. Or we can say the composed DO should appear before AH, and it surely before upper-layer header too. No conflict, but I feel strange for this interpretation. => I expect to get a clear statement about that in the new mobility draft. For the moment the I-D (abusively) preempts RFC 2460 recommendations... Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Sep 27 16:15: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 SMTP id QAA21888 for ; Wed, 27 Sep 2000 16:15:46 -0400 (EDT) Received: from standards (47.234.32.16:3436) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB990E1@standards.nortelnetworks.com>; Wed, 27 Sep 2000 15:59:07 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0695 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 27 Sep 2000 15:59:07 -0400 Received: from standards (47.234.32.16:3436) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB990E0@standards.nortelnetworks.com>; Wed, 27 Sep 2000 15:59:07 -0400 Message-ID: Date: Wed, 27 Sep 2000 15:59:06 -0400 Reply-To: Rambabu Tummala Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Rambabu Tummala Subject: Re: [MOBILE-IP] Vendor/Organization-Specific Extensions X-To: Gopal Dommety To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Let me understand this case, An FA is allowed to send and Agent Advertisement with "NVSE", correct?. This is very important in the case of a Foreign agent of a specific vendor sending agent advertisement with NVSE extension, where the Mobile Nodes of that vendor understand this extension and process the message, where as other MN's still use the message, but ignore the extension. Is this correct? Gopal, do you know when the official values be assigned? -Regards, Rambabu Tummala Nortel Networks ESN 444-8970 External (972)684-8970 On Tue, 26 Sep 2000 10:42:50 -0700, Gopal Dommety wrote: >At 03:29 PM 25/09/00 +0300, Henry Haverinen wrote: >>Hi all, >> >>I have some questions concerning draft-ietf-mobileip-vendor-ext-11.txt. >> >>Section 2.3 doesn't cover the case of an Agent Advertisement >>containing a CVSE. Is this because the operation is obvious (MN >>must silently discard the Advertisement)? > >That is correct. > >>Such an extension is useful if a FA doesn't want to receive >>Registration Requests from MNs that don't support a certain vendor/ >>organization-specific feature. > >Yes, if you want the entire advertisement to be ignored. > > >>I wonder why the current version of the vendor-ext draft doesn't suggest >>any type values for the extensions but just says "to be assigned by IANA". >>Did the type values used in previous versions (38 and 134) overlap >>with some other draft? It might be a good idea to give some initial >>guesses for the types so that people can be implement the draft and test >>the interoperability of their implementations. I guess even the vendor- >>specific extensions should be tested for interoperability, as the draft >>specifies processing considerations for unrecognized vendor types. > >We did specify the type values and IESG instructed that we remove the >any recommended assignments by us. The values we picked were not >conflicting with any assigned value. I think this is an IESG policy. > > >>Regards, >>Henry From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Sep 27 16: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 SMTP id QAA22007 for ; Wed, 27 Sep 2000 16:23:28 -0400 (EDT) Received: from standards (47.234.32.16:3436) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB99113@standards.nortelnetworks.com>; Wed, 27 Sep 2000 16:04:20 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0654 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 27 Sep 2000 16:04:20 -0400 Received: from explore.kwangwoon.ac.kr (128.134.70.30:48511) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB990C1@standards.nortelnetworks.com>; Wed, 27 Sep 2000 15:54:19 -0400 Received: from eos (eos.kwangwoon.ac.kr [128.134.56.162]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id FAA17702 for ; Thu, 28 Sep 2000 05:05:32 +0900 (KST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01C0290A.4AA03900" 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: <002301c028be$dada22c0$a2388680@kwangwoon.ac.kr> Date: Thu, 28 Sep 2000 05:09:34 +0900 Reply-To: SungJin Lee Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: SungJin Lee Subject: [MOBILE-IP] Mobile IP + / Mobile IP version 2 ? To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_0020_01C0290A.4AA03900 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SSBmb3VuZCB0aGF0ICdNb2JpbGUgSVAgKycgaXMgdXNlZCBpbiAzR1BQIGRvY3VtZW50IA0KYW5k ICdNb2JpbGUgSVAgdmVyc2lvbiAyJyBpbiBjZG1hMjAwMCBhcnRpY2xlLiBBcmUgdGhhdCB3b3Jk cyANCnVzZWQgb2ZmaWNpYWxseSBpbiB0aGUgTW9iaWxlIElQIHdvcmtpbmcgZ3JvdXAgPw0KDQpp ZiB0aGVuLCBwbGVhc2UgbGV0IG1lIGtub3cgd2hpY2ggUkZDcyBhbmQgZHJhZnRzIGFyZQ0KaW5j bHVkZWQgaW4gdGhvc2Ugd29yZHMsIE1vYmlsZSBJUCsgYW5kIE1vYmlsZSBJUCB2ZXJzaW9uIDIu DQo= ------=_NextPart_000_0020_01C0290A.4AA03900 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjUwLjQxMzQuNjAwIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9I RUFEPg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBzaXplPTI+SSBmb3VuZCB0 aGF0ICdNb2JpbGUgSVAgKycgaXMgdXNlZCBpbiAzR1BQIGRvY3VtZW50IA0KPC9GT05UPjwvRElW Pg0KPERJVj48Rk9OVCBzaXplPTI+YW5kICdNb2JpbGUgSVAgdmVyc2lvbiAyJyBpbiBjZG1hMjAw MCBhcnRpY2xlLiA8L0ZPTlQ+PEZPTlQgDQpzaXplPTI+QXJlIHRoYXQgd29yZHMmbmJzcDs8L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj51c2VkIG9mZmljaWFsbHkmbmJzcDtpbiB0aGUg TW9iaWxlIElQJm5ic3A7d29ya2luZyANCmdyb3VwJm5ic3A7PzwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPmlmIHRo ZW4sIHBsZWFzZSBsZXQgbWUga25vdyB3aGljaCBSRkNzIGFuZCBkcmFmdHMgDQphcmU8L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5pbmNsdWRlZCBpbiB0aG9zZSB3b3JkcywgTW9iaWxl IElQKyBhbmQgTW9iaWxlIElQIHZlcnNpb24gDQoyLjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1M Pg0K ------=_NextPart_000_0020_01C0290A.4AA03900-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Sep 27 16:58: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 SMTP id QAA22428 for ; Wed, 27 Sep 2000 16:58:23 -0400 (EDT) Received: from standards (47.234.32.16:3436) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB99192@standards.nortelnetworks.com>; Wed, 27 Sep 2000 16:42:10 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0929 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 27 Sep 2000 16:42:10 -0400 Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB99191@standards.nortelnetworks.com>; Wed, 27 Sep 2000 16:42:05 -0400 Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id QAA19031 for ; Wed, 27 Sep 2000 16:56:07 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id QAA19002 for ; Wed, 27 Sep 2000 16:56:06 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Wed, 27 Sep 2000 21:56:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: <976F7C55E3B2D111A0720008C728549C04877272@en0060exch001u.uk.lucent.com> Date: Wed, 27 Sep 2000 21:55:18 +0100 Reply-To: "Casati, Alessio (Alessio)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Casati, Alessio (Alessio)" Subject: Re: [MOBILE-IP] Mobile IP + / Mobile IP version 2 ? X-To: SungJin Lee To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM I can answer about Mobile IP+. Mobile IP + was a "techno-political" term used within the context of the legendary 3GPP TR 23.923 on the use of mobile IP in GSM/UMTS systems (the one with the "IGSN mistery" in, as somebody had somewhat interestingly observed some time ago on this list). It was meaning RFC 2002 + all what was needed to make mobile IP deployable (AAA hooks, Challenge response...). About Mobile IP v2, I may only guess that paper was talking about the revised RFC2002. Both these are not used in this WG. regards alessio > ---------- > From: SungJin Lee[SMTP:bluezy@CHOLLIAN.NET] > Reply To: SungJin Lee > Sent: 27 September 2000 21:09 > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: [MOBILE-IP] Mobile IP + / Mobile IP version 2 ? > > I found that 'Mobile IP +' is used in 3GPP document > and 'Mobile IP version 2' in cdma2000 article. Are that words > used officially in the Mobile IP working group ? > > if then, please let me know which RFCs and drafts are > included in those words, Mobile IP+ and Mobile IP version 2. > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Sep 27 17:34: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 SMTP id RAA22867 for ; Wed, 27 Sep 2000 17:34:26 -0400 (EDT) Received: from standards (47.234.32.16:3436) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9923D@standards.nortelnetworks.com>; Wed, 27 Sep 2000 17:18:27 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1120 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 27 Sep 2000 17:18:27 -0400 Received: from qhars002.nortel.com (47.101.112.102:50418) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9921C@standards.nortelnetworks.com>; Wed, 27 Sep 2000 17:08:26 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Wed, 27 Sep 2000 22:20:58 +0100 Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch1.nortel.com; Wed, 27 Sep 2000 16:16:39 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Wed, 27 Sep 2000 16:15:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C028C8.199E5130" Message-ID: <52F74DDA50B5D211AF800000F80825210509CA16@zrchb212.us.nortel.com> Date: Wed, 27 Sep 2000 16:15:45 -0500 Reply-To: Thi Nguyen Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Thi Nguyen Subject: Re: [MOBILE-IP] New I-D: draft-yegin-mobileip-nrouting-00.txt X-To: Alper Yegin To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C028C8.199E5130 Content-Type: text/plain; charset="iso-8859-1" Hi All, This is my first time to post here, and I am a beginner in MIP. Please forgive me if my inexperience show. Pardon me if what I am saying below has been discussed and ignored. I don't understand why we do not put the soft-handoff or fast-handoff function in the MN. This is done in CDMA network. The mobile device (MN) can sense that it is drifting into another cell (link) other than it current cell (link). This is done by the signal strength measurement in the mobile device. The mobile device then initiate a soft-handoff (BU), where it can receive signals from both the current cell and the cell it is about to go into. I don't see why this concept can not be repeated for MIPv6. Regards, Thi Nguyen -----Original Message----- From: Alper Yegin [mailto:Alper.Yegin@ENG.SUN.COM] Sent: Tuesday, September 26, 2000 12:58 PM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: [MOBILE-IP] New I-D: draft-yegin-mobileip-nrouting-00.txt Hello, We submitted a new draft to IETF yesterday. Before it goes through the IETF editors queue, here's a copy. Title : Mobile IPv6 Neighborhood Routing for Fast Handoff Authors : A. Yegin, M. Parthasarathy, C. Williams Filename : draft-yegin-mobileip-nrouting-00.txt Pages : 15 Date : September 25, 2000 Abstract The Mobile IP working group is currently examining proposals to assist in minimizing the latency and packet loss due to handoffs when a Mobile IPv6 node moves from one point of attachment to another. One of the desires to reduce this latency and packet loss is a result of the strict requirements of real-time network services. This proposal specifies a solution whereby the mobile node sends a binding update with multiple care-of-addresses which match the current link and other links that the mobile node may possibly visit next. After receiving such a binding update, the correspondent nodes and home agent use a new routing header extension to route the packet that will be received by the mobile node at one of the possible care-of-addresses. Thus, the correspondent nodes and home agent can still communicate with the mobile node despite not knowing its exact location while the mobile node moves across links. The proposal presents no new networking entities and the resulting architecture describes a natural extension to the Mobile IPv6 protocol. Alper Yegin Internet Engineering Sun Microsystems, Inc. ------_=_NextPart_001_01C028C8.199E5130 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] New I-D: = draft-yegin-mobileip-nrouting-00.txt

Hi All,

This is my first time to post here, and I am a = beginner in MIP. Please forgive me if my inexperience show. Pardon me = if what I am saying below has been discussed and ignored.

I don't understand why we do not put the soft-handoff = or fast-handoff function in the MN. This is done in CDMA network. The = mobile device (MN) can sense that it is drifting into another cell = (link) other than it current cell (link). This is done by the signal = strength measurement in the mobile device. The mobile device then = initiate a soft-handoff (BU), where it can receive signals from both = the current cell and the cell it is about to go into.

I don't see why this concept can not be repeated for = MIPv6.

Regards,
Thi Nguyen

-----Original Message-----
From: Alper Yegin [mailto:Alper.Yegin@ENG.SUN.COM]
Sent: Tuesday, September 26, 2000 12:58 PM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: [MOBILE-IP] New I-D: = draft-yegin-mobileip-nrouting-00.txt


Hello,

We submitted a new draft to IETF yesterday. Before it = goes through the IETF
editors queue, here's a copy.


   = Title        : Mobile IPv6 = Neighborhood Routing for Fast Handoff
   Authors      : = A. Yegin, M. Parthasarathy, C. Williams
   Filename     : = draft-yegin-mobileip-nrouting-00.txt
   = Pages        : 15
   = Date         : September 25, = 2000


Abstract

   The Mobile IP working group is currently = examining proposals to
   assist in minimizing the latency and = packet loss due to handoffs
   when a Mobile IPv6 node moves from one = point of attachment to
   another.  One of the desires to = reduce this latency and packet loss
   is a result of the strict requirements = of real-time network
   services.  This proposal specifies = a solution whereby the mobile
   node sends a binding update with = multiple care-of-addresses which
   match the current link and other links = that the mobile node may
   possibly visit next. After receiving = such a binding update, the
   correspondent nodes and home agent use = a new routing header
   extension to route the packet that will = be received by the mobile
   node at one of the possible = care-of-addresses. Thus, the
   correspondent nodes and home agent can = still communicate with
   the mobile node despite not knowing its = exact location while the
   mobile node moves across links. The = proposal presents no new
   networking entities and the resulting = architecture describes a
   natural extension to the Mobile IPv6 = protocol.



Alper Yegin
Internet Engineering
Sun Microsystems, Inc.

------_=_NextPart_001_01C028C8.199E5130-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Sep 27 17:41: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 SMTP id RAA22993 for ; Wed, 27 Sep 2000 17:41:42 -0400 (EDT) Received: from standards (47.234.32.16:3436) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB99290@standards.nortelnetworks.com>; Wed, 27 Sep 2000 17:25:45 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1269 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 27 Sep 2000 17:25:44 -0400 Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9928D@standards.nortelnetworks.com>; Wed, 27 Sep 2000 17:25:44 -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 RAA22973 for ; Wed, 27 Sep 2000 17:39:51 -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 RAA22965 for ; Wed, 27 Sep 2000 17:39:50 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Wed, 27 Sep 2000 22:39:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: <976F7C55E3B2D111A0720008C728549C04877273@en0060exch001u.uk.lucent.com> Date: Wed, 27 Sep 2000 22:39:25 +0100 Reply-To: "Casati, Alessio (Alessio)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Casati, Alessio (Alessio)" Subject: Re: [MOBILE-IP] the IGSN mystery (?) X-To: Nakhjiri Madjid-MNAKHJI1 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > As I understand Technical reports are from individual companies. You know > which company it was from? > TRs are not from companies. They are 3GPP permanent documents used to record some pre-standard activity conducted within the scope of a WG. An approved TR can feed into an existing TS, or can originate one or more new TS's. alessio From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Sep 27 19:48: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 SMTP id TAA25006 for ; Wed, 27 Sep 2000 19:48:24 -0400 (EDT) Received: from standards (47.234.32.16:3081) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB99493@standards.nortelnetworks.com>; Wed, 27 Sep 2000 19:32:20 -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; Wed, 27 Sep 2000 19:32:19 -0400 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB99492@standards.nortelnetworks.com>; Wed, 27 Sep 2000 19:32:19 -0400 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA07620; Wed, 27 Sep 2000 16:46:24 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.86.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id QAA19739; Wed, 27 Sep 2000 16:46:21 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with SMTP id e8RNkIe369339; Wed, 27 Sep 2000 16:46:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 8vIjn7iy+noXVRk19bF6xw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Message-ID: <200009272346.e8RNkIe369339@jurassic.eng.sun.com> Date: Wed, 27 Sep 2000 16:42:22 -0700 Reply-To: Alper Yegin Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Alper Yegin Subject: Re: [MOBILE-IP] New I-D: draft-yegin-mobileip-nrouting-00.txt X-To: nthi@nortelnetworks.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > This is my first time to post here, and I am a beginner in MIP. Please > forgive me if my inexperience show. Pardon me if what I am saying below has > been discussed and ignored. > > I don't understand why we do not put the soft-handoff or fast-handoff > function in the MN. This is done in CDMA network. The mobile device (MN) can > sense that it is drifting into another cell (link) other than it current > cell (link). This is done by the signal strength measurement in the mobile > device. The mobile device then initiate a soft-handoff (BU), where it can > receive signals from both the current cell and the cell it is about to go > into. > > I don't see why this concept can not be repeated for MIPv6. Hi Thi, You are talking about MN being data connected at both the previous link and the new link simultanesouly, right? You are right, if that was the case, it'd be easier: if MN has enough time in the overlapped area to get the latest BUs to CNs/HA and receive the last packet sent to old CoA, then things are fine. But I think when this was discussed, people said not all the technologies provide this "be connected at both links" feature, it may require two receivers ... Also, if the overlap area is too small, MN may get out of it before the last packet sent to old CoA is received. alper > > Regards, > Thi Nguyen > > -----Original Message----- > From: Alper Yegin [mailto:Alper.Yegin@ENG.SUN.COM] > Sent: Tuesday, September 26, 2000 12:58 PM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: [MOBILE-IP] New I-D: draft-yegin-mobileip-nrouting-00.txt > > > Hello, > > We submitted a new draft to IETF yesterday. Before it goes through the IETF > editors queue, here's a copy. > > > Title : Mobile IPv6 Neighborhood Routing for Fast Handoff > Authors : A. Yegin, M. Parthasarathy, C. Williams > Filename : draft-yegin-mobileip-nrouting-00.txt > Pages : 15 > Date : September 25, 2000 > > > Abstract > > The Mobile IP working group is currently examining proposals to > assist in minimizing the latency and packet loss due to handoffs > when a Mobile IPv6 node moves from one point of attachment to > another. One of the desires to reduce this latency and packet loss > is a result of the strict requirements of real-time network > services. This proposal specifies a solution whereby the mobile > node sends a binding update with multiple care-of-addresses which > match the current link and other links that the mobile node may > possibly visit next. After receiving such a binding update, the > correspondent nodes and home agent use a new routing header > extension to route the packet that will be received by the mobile > node at one of the possible care-of-addresses. Thus, the > correspondent nodes and home agent can still communicate with > the mobile node despite not knowing its exact location while the > mobile node moves across links. The proposal presents no new > networking entities and the resulting architecture describes a > natural extension to the Mobile IPv6 protocol. > > > > Alper Yegin > Internet Engineering > Sun Microsystems, Inc. alper From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Sep 27 22:58: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 SMTP id WAA28837 for ; Wed, 27 Sep 2000 22:58:50 -0400 (EDT) Received: from standards (47.234.32.16:4557) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB99560@standards.nortelnetworks.com>; Wed, 27 Sep 2000 22:42:46 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2250 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 27 Sep 2000 22:42:46 -0400 Received: from ish7.ericsson.com.au (203.61.155.111:50692) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9955F@standards.nortelnetworks.com>; Wed, 27 Sep 2000 22:42:44 -0400 Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id MAA13037; Thu, 28 Sep 2000 12:52:34 +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 NAA19942; Thu, 28 Sep 2000 13:54:42 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Thu, 28 Sep 2000 13:54:47 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C028F7.75ACB5A0" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A5089EB2AB@eaubrnt018.epa.ericsson.se> Date: Thu, 28 Sep 2000 13:54:46 +1100 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] New I-D: draft-yegin-mobileip-nrouting-00.txt X-To: Alper Yegin To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C028F7.75ACB5A0 Content-Type: text/plain You are talking about MN being data connected at both the previous link and the new link simultanesouly, right? You are right, if that was the case, it'd be easier: if MN has enough time in the overlapped area to get the latest BUs to CNs/HA and receive the last packet sent to old CoA, then things are fine. But I think when this was discussed, people said not all the technologies provide this "be connected at both links" feature, it may require two receivers ... Also, if the overlap area is too small, MN may get out of it before the last packet sent to old CoA is received. => Actually the overlapping is part of the network planning or cell planning in celular networks and should be enough for the handoff sequence to take place. The problem is as you mentioned above, most raio links don't allow you to have simultaneous data connections. So thees are really two separate issues. ------_=_NextPart_001_01C028F7.75ACB5A0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] New I-D: = draft-yegin-mobileip-nrouting-00.txt

 


You are talking about MN being data connected at both = the previous link
and the
new link simultanesouly, right? You are right, if = that was the case,
it'd be
easier: if MN has enough time in the overlapped area = to get the latest
BUs to
CNs/HA and receive the last packet sent to old CoA, = then things are
fine.

But I think when this was discussed, people said not = all the
technologies
provide this "be connected at both links" = feature, it may require two
receivers
...

Also, if the overlap area is too small, MN may get = out of it before the
last
packet sent to old CoA is received.

=3D> Actually the overlapping is part of the = network planning or cell planning in celular networks and should be = enough for the handoff sequence

to take place. The problem is as you mentioned above, = most raio links don't
allow you to have simultaneous data connections. So = thees are really 
two separate issues.

------_=_NextPart_001_01C028F7.75ACB5A0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Sep 28 02:56: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 SMTP id CAA14166 for ; Thu, 28 Sep 2000 02:56:49 -0400 (EDT) Received: from standards (47.234.32.16:4301) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9965B@standards.nortelnetworks.com>; Thu, 28 Sep 2000 2:40:32 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2589 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 28 Sep 2000 02:40:32 -0400 Received: from mailserv.intranet.GR by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9965A@standards.nortelnetworks.com>; Thu, 28 Sep 2000 2:40:31 -0400 Received: from patreas.patra.intranet.gr by mailserv.intranet.GR with ESMTP (8.8.8/ICM-mailhub-1.0) id JAA14271; Thu, 28 Sep 2000 09:51:47 +0300 (EET DST) Received: from intranet.gr (patdpd17 [146.124.171.40]) by patreas.patra.intranet.gr (8.9.1b+Sun/8.9.0) with ESMTP id KAA24367 for ; Thu, 28 Sep 2000 10:04:32 +0300 (EET DST) X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-7 Content-Transfer-Encoding: 7bit Message-ID: <39D2EA6C.BFFAF66F@intranet.gr> Date: Thu, 28 Sep 2000 09:51:24 +0300 Reply-To: Christos Chrisanthakopoulos Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Christos Chrisanthakopoulos Subject: Re: [MOBILE-IP] The IGSN mystery? To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit "Casati, Alessio (Alessio)" wrote: > I can answer about Mobile IP+. > > Mobile IP + was a "techno-political" term > used within the context of the legendary > 3GPP TR 23.923 on the use of mobile IP in GSM/UMTS systems > (the one with the "IGSN mistery" in, as > somebody had somewhat interestingly observed > some time ago on this list). Therefore the integration of the two support nodes into a new 'IGSN' is not feasible at all? Or is it going to be further considered and investigated in the near future? Is there a problem with the current infrastractures that dont allow the operators to deploy it? And finally, is there ANY feasible integration at all so far ? What about the 'IGSS' that the IETF proposed in recent I-D ? Best regards, Christos -- Christos Chrisanthakopoulos INTRACOM S.A. Development Programmes Department Panepistimiou 254 26443 Patras GREECE Tel: (+30 61) 465153 (direct) E-mail: xchr@intranet.gr URL: www.intracom.gr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Sep 28 03:27: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 SMTP id DAA14387 for ; Thu, 28 Sep 2000 03:27:06 -0400 (EDT) Received: from standards (47.234.32.16:4301) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB996A7@standards.nortelnetworks.com>; Thu, 28 Sep 2000 3:10:51 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2689 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 28 Sep 2000 03:10:51 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB996A6@standards.nortelnetworks.com>; Thu, 28 Sep 2000 3:10:50 -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 CAA00976 for ; Thu, 28 Sep 2000 02:24:48 -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, 28 Sep 2000 09:27:12 +0200 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: Date: Thu, 28 Sep 2000 09:27:15 +0200 Reply-To: Roberto Winkler Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Roberto Winkler Subject: Re: [MOBILE-IP] The IGSN mystery? X-To: mobile-ip@smallworks.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Still, I would really appreciate some clarifications about the unfeasibility of the IGSN concept. In the mentioned 3GPP TR I don't see any clear sentence about that and the only impairment I see is the need for a true availability of AAA architectures in the 3G system to support adequately Mobile IP. Anyone willing to add more ? Thanks 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 Thu Sep 28 03:36: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 SMTP id DAA14480 for ; Thu, 28 Sep 2000 03:36:42 -0400 (EDT) Received: from standards (47.234.32.16:4301) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB996E9@standards.nortelnetworks.com>; Thu, 28 Sep 2000 3:20:39 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2779 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 28 Sep 2000 03:20:39 -0400 Received: from mailserv.intranet.GR by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB996E8@standards.nortelnetworks.com>; Thu, 28 Sep 2000 3:20:38 -0400 Received: from patreas.patra.intranet.gr by mailserv.intranet.GR with ESMTP (8.8.8/ICM-mailhub-1.0) id KAA16633; Thu, 28 Sep 2000 10:31:52 +0300 (EET DST) Received: from intranet.gr (patdpd17 [146.124.171.40]) by patreas.patra.intranet.gr (8.9.1b+Sun/8.9.0) with ESMTP id KAA24838 for ; Thu, 28 Sep 2000 10:44:40 +0300 (EET DST) X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=iso-8859-7 Content-Transfer-Encoding: 7bit Message-ID: <39D2F3D4.902E8A0E@intranet.gr> Date: Thu, 28 Sep 2000 10:31:32 +0300 Reply-To: Christos Chrisanthakopoulos Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Christos Chrisanthakopoulos Subject: Re: [MOBILE-IP] The IGSN mystery? To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Roberto Winkler wrote: > Still, I would really appreciate some clarifications about the > unfeasibility of the IGSN concept. In the mentioned 3GPP TR I don't see any > clear sentence about that and the only impairment I see is the need for a > true availability of AAA architectures in the 3G system to support > adequately Mobile IP. Anyone willing to add more ? I TOTALLY agree with you Roberto !!! The clarifications should be at the end of the 23.923 report more specifically on p.67, section 14 (I think) but the issues are not clear enough :( > > > Thanks > > 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 Regards ! -- Christos Chrisanthakopoulos INTRACOM S.A. Development Programmes Department Panepistimiou 254 26443 Patras GREECE Tel: (+30 61) 465153 (direct) E-mail: xchr@intranet.gr URL: www.intracom.gr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Sep 28 04:58: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 SMTP id EAA15442 for ; Thu, 28 Sep 2000 04:58:16 -0400 (EDT) Received: from standards (47.234.32.16:1282) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB997A0@standards.nortelnetworks.com>; Thu, 28 Sep 2000 4:41:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3019 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 28 Sep 2000 04:41:56 -0400 Received: from mcn.xidian.edu.cn (202.117.114.10:3753) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9979E@standards.nortelnetworks.com>; Thu, 28 Sep 2000 4:31:46 -0400 Received: from mcnibm (mcn_ibm2 [192.168.1.47]) by mcn.xidian.edu.cn (8.9.3/8.8.7) with SMTP id QAA08478 for ; Thu, 28 Sep 2000 16:25:01 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C0296B.92912880" 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: <000a01c02928$854fbd00$2f01a8c0@mcnibm> Date: Thu, 28 Sep 2000 16:45:56 +0800 Reply-To: nzhang Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: nzhang Subject: [MOBILE-IP] Subscribe To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C0296B.92912880 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQo= ------=_NextPart_000_0007_01C0296B.92912880 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS41 MC4zODI1LjEzMDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPiZuYnNwOzwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0007_01C0296B.92912880-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Sep 28 04:58: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 SMTP id EAA15445 for ; Thu, 28 Sep 2000 04:58:17 -0400 (EDT) Received: from standards (47.234.32.16:1282) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB997A8@standards.nortelnetworks.com>; Thu, 28 Sep 2000 4:43:30 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3020 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 28 Sep 2000 04:43:30 -0400 Received: from mcn.xidian.edu.cn by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9979F@standards.nortelnetworks.com>; Thu, 28 Sep 2000 4:33:28 -0400 Received: from mcnibm (mcn_ibm2 [192.168.1.47]) by mcn.xidian.edu.cn (8.9.3/8.8.7) with SMTP id QAA08482 for ; Thu, 28 Sep 2000 16:25:20 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C0296B.9DB1F960" 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: <001301c02928$8fb04b20$2f01a8c0@mcnibm> Date: Thu, 28 Sep 2000 16:46:15 +0800 Reply-To: nzhang Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: nzhang Subject: [MOBILE-IP] To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C0296B.9DB1F960 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 U3Vic2NyaWJlDQo= ------=_NextPart_000_0010_01C0296B.9DB1F960 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS41 MC4zODI1LjEzMDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5TdWJzY3JpYmU8L0ZPTlQ+ PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0010_01C0296B.9DB1F960-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Sep 28 05:54:00 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA15834 for ; Thu, 28 Sep 2000 05:54:00 -0400 (EDT) Received: from standards (47.234.32.16:1282) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9983B@standards.nortelnetworks.com>; Thu, 28 Sep 2000 5:37:53 -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; Thu, 28 Sep 2000 05:37:53 -0400 Received: from esebh02nok.ntc.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9983A@standards.nortelnetworks.com>; Thu, 28 Sep 2000 5:37:53 -0400 Received: by esebh02nok with Internet Mail Service (5.5.2650.10) id ; Thu, 28 Sep 2000 12:51:58 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <6D1A8E7871B9D211B3B00008C7490AA504E622C2@treis03nok> Date: Thu, 28 Sep 2000 12:51:57 +0300 Reply-To: henry.haverinen@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Henry Haverinen Subject: Re: [MOBILE-IP] Vendor/Organization-Specific Extensions To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Raj and Gopal, I hope you don't mind that I'm posting this to the mailing list, because I think others may be interested in this as well. > Seriously, I think the reason why IANA wants to do the > assignment is because once a registry for a protocol has > been setup they become the authority in administering > the type values w.r.t that protocol. It's a very good idea to have a central authority that assigns the protocol numbers. But we should get the type values for the drafts early so that we can implement them and test them for interoperability. Do you think we could get type values for the vender-ext draft and other Mobile IP drafts from IANA soon, even before the protocols get the Proposed Standard status? Regards, Henry From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Sep 28 06:58: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 SMTP id GAA16653 for ; Thu, 28 Sep 2000 06:58:32 -0400 (EDT) Received: from standards (47.234.32.16:1282) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB998DD@standards.nortelnetworks.com>; Thu, 28 Sep 2000 6:41:47 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3379 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 28 Sep 2000 06:41:47 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB998B7@standards.nortelnetworks.com>; Thu, 28 Sep 2000 6:31:47 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16282; Thu, 28 Sep 2000 06:45:55 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200009281045.GAA16282@ietf.org> Date: Thu, 28 Sep 2000 06:45:55 -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-03.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-03.txt Pages : 15 Date : 27-Sep-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-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-elmalki-mobileip-fast-handoffs-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-elmalki-mobileip-fast-handoffs-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: <20000927135913.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-elmalki-mobileip-fast-handoffs-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-elmalki-mobileip-fast-handoffs-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000927135913.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Sep 28 06:58: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 SMTP id GAA16659 for ; Thu, 28 Sep 2000 06:58:32 -0400 (EDT) Received: from standards (47.234.32.16:1282) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB998DF@standards.nortelnetworks.com>; Thu, 28 Sep 2000 6:41:51 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3380 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 28 Sep 2000 06:41:51 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB998B8@standards.nortelnetworks.com>; Thu, 28 Sep 2000 6:31:51 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16298; Thu, 28 Sep 2000 06:45:59 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200009281045.GAA16298@ietf.org> Date: Thu, 28 Sep 2000 06:45:59 -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-calhoun-mobileip-proactive-fa-02.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Foreign Agent Assisted Hand-off Author(s) : P. Calhoun, T. Hiller, J. Kempf, P. McCann, C. Pairla, A. Singh, S. Thalanany Filename : draft-calhoun-mobileip-proactive-fa-02.txt Pages : 26 Date : 27-Sep-00 The Mobile IP protocol allows a Mobile Node to continue using the same home address even after changing its point of attachment to the Internet. This provides transparency to most existing applications that assume a fixed address and a fixed point of attachment. However, new applications, such as voice-over-IP, have additional real-time requirements such that a change in the point of attachment will cause a noticeable degradation of service unless additional steps are taken to reduce the latency of a handoff event. This specification proposes extensions to the Mobile IP protocol that may be used by Foreign Agents to set up a Mobile Node's visitor entry, and forward its packets, prior to receiving a formal Registration Request from the Mobile Node. This enables a very rapid establishment of service at the new point of attachment so that the effect of the handoff on real-time applications is minimized. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-calhoun-mobileip-proactive-fa-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-calhoun-mobileip-proactive-fa-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-calhoun-mobileip-proactive-fa-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: <20000927135922.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-calhoun-mobileip-proactive-fa-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-calhoun-mobileip-proactive-fa-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000927135922.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Sep 28 06:58: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 SMTP id GAA16669 for ; Thu, 28 Sep 2000 06:58:33 -0400 (EDT) Received: from standards (47.234.32.16:1282) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB998E2@standards.nortelnetworks.com>; Thu, 28 Sep 2000 6:42:08 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3386 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 28 Sep 2000 06:42:08 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB998BA@standards.nortelnetworks.com>; Thu, 28 Sep 2000 6:32:07 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16357; Thu, 28 Sep 2000 06:46:13 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200009281046.GAA16357@ietf.org> Date: Thu, 28 Sep 2000 06:46:13 -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-yegin-mobileip-nrouting-00.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mobile IPv6 Neighborhood Routing for Fast Handoff Author(s) : A. Yegin, C. Williams, M. Parthasarathy Filename : draft-yegin-mobileip-nrouting-00.txt Pages : 15 Date : 27-Sep-00 The Mobile IP working group is currently examining proposals to assist in minimizing the latency and packet loss due to handoffs when a Mobile IPv6 node moves from one point of attachment to another. One of the desires to reduce this latency and packet loss is a result of the strict requirements of real-time network services. This proposal specifies a solution whereby the mobile node sends a binding update with multiple care-of-addresses which match the current link and other links that the mobile node may possibly visit next. After receiving such a binding update, the correspondent nodes and home agent use a new routing header extension to route the packet that will be received by the mobile node at one of the possible care-of-addresses. Thus, the correspondent nodes and home agent can still communicate with the mobile node despite not knowing its exact location while the mobile node moves across links. The proposal presents no new networking entities and the resulting architecture describes a natural extension to the Mobile IPv6 protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yegin-mobileip-nrouting-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-yegin-mobileip-nrouting-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-yegin-mobileip-nrouting-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: <20000927135950.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-yegin-mobileip-nrouting-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-yegin-mobileip-nrouting-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000927135950.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Sep 28 13:29: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 SMTP id NAA27237 for ; Thu, 28 Sep 2000 13:29:00 -0400 (EDT) Received: from standards (47.234.32.16:1148) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB99D1D@standards.nortelnetworks.com>; Thu, 28 Sep 2000 13:12:23 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4810 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 28 Sep 2000 13:12:23 -0400 Received: from omega.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB99D1C@standards.nortelnetworks.com>; Thu, 28 Sep 2000 13:12:22 -0400 Received: from gopal.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 KAA05472; Thu, 28 Sep 2000 10:26:26 -0700 (PDT) X-Sender: gdommety@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <4.3.2.7.2.20000928102849.00d46de0@omega.cisco.com> Date: Thu, 28 Sep 2000 10:29:32 -0700 Reply-To: Gopal Dommety Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gopal Dommety Subject: Re: [MOBILE-IP] Vendor/Organization-Specific Extensions X-To: Rambabu Tummala To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <36FA02BD7083D411BC9E0000F8073E435FD145@crchy271.us.nortel. com> At 01:30 PM 26/09/00 -0500, Rambabu Tummala wrote: >Let me understand this case, > >An FA is allowed to send and Agent Advertisement with "NVSE", correct?. > >This is very important in the case of a Foreign agent of a specific vendor sending agent advertisement with NVSE extension, where the Mobile Nodes of that vendor understand this extension and process the message, where as other MN's still use the message, but ignore the extension. > >Is this correct? Your understanding is correct. >Gopal, do you know when the official values be assigned? Waiting for IANA to assign. Thanks gopal >-Regards, > >Rambabu Tummala >Nortel Networks >ESN 444-8970 >External (972)684-8970 > >At 03:29 PM 25/09/00 +0300, Henry Haverinen wrote: >>Hi all, >> >>I have some questions concerning draft-ietf-mobileip-vendor-ext-11.txt. >> >>Section 2.3 doesn't cover the case of an Agent Advertisement >>containing a CVSE. Is this because the operation is obvious (MN >>must silently discard the Advertisement)? > >That is correct. > >>Such an extension is useful if a FA doesn't want to receive >>Registration Requests from MNs that don't support a certain vendor/ >>organization-specific feature. > >Yes, if you want the entire advertisement to be ignored. > >>I wonder why the current version of the vendor-ext draft doesn't suggest >>any type values for the extensions but just says "to be assigned by IANA". >>Did the type values used in previous versions (38 and 134) overlap >>with some other draft? It might be a good idea to give some initial >>guesses for the types so that people can be implement the draft and test >>the interoperability of their implementations. I guess even the vendor- >>specific extensions should be tested for interoperability, as the draft >>specifies processing considerations for unrecognized vendor types. > >We did specify the type values and IESG instructed that we remove the >any recommended assignments by us. The values we picked were not >conflicting with any assigned value. I think this is an IESG policy. > >>Regards, >>Henry From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Sep 28 14:11: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 SMTP id OAA28475 for ; Thu, 28 Sep 2000 14:11:44 -0400 (EDT) Received: from standards (47.234.32.16:1148) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB99DAF@standards.nortelnetworks.com>; Thu, 28 Sep 2000 13:55:12 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4997 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 28 Sep 2000 13:55:12 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB99DAE@standards.nortelnetworks.com>; Thu, 28 Sep 2000 13:55:12 -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 MAA17978; Thu, 28 Sep 2000 12:09:14 -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 LAA23071; Thu, 28 Sep 2000 11:09: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 LAA10911; Thu, 28 Sep 2000 11:09:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Thu, 28 Sep 2000 11:07:02 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: Re: [MOBILE-IP] Comments on draft-calhoun-mobileip-proactive-fa-02.txt X-To: Phil_Neumiller@3com.com X-cc: tom.hiller@lucent.com, james.kempf@eng.sun.com, mccap@lucent.com, pairla@uiuc.edu, sthalan@email.mot.com, asingh1@email.mot.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <88256967.0055C6A5.00@hqoutbound.ops.3com.com> > > > 1). Sec 1.2 says "MNs connect to FAs via direct, link layer connections. > > I disagree, this is not necessary nor desirable in all cases. The FA in > theory could gain access to "subtending" link layer info through a variety of > mechanisms. Why must it be assumed that the FA is co-located with the link > layer equipment? If there is another layer of abstraction, and the trigger makes it to the FA, then we are happy. I am not really sure that we need to go there in the document, but if you feel that strongly about it, I can add such text. > > 2). In the discussion of the triggering mechanism. FA handover candidates > should > be configurable and/or discoverable automagically, allowing active > sets of > overlapping coverage areas (more on this below). good because more is needed in order for me to decode your comment :) > > 3). In 1.2 "problems that must be addressed" section under (1). Why worry > about > registration? Can't we just go ahead and perform the handoff and > register in > parallel? If the registration fails then boot the MN, but get the > traffic going first > at all costs. exactly what our draft does. We simply listed the issues that we know of in that section. We could add a "Get data to new cell before registration", but it is covered elsewhere and if you notice, each one of those bullets has a corresponding section. > > 4). In section 1.2 sub 3, we should allow bi-cast, and tri-cast to all the > candidate FAs that > were "discovered" as descibed in 2 above. Gee, this is starting to > sound like > OBAST! :-) So you must like it, then :) > > 5). In sec 1.2 sub 6., mobile power consumption can be reduced by having > MORE > FAs listening and performing selection at the anchor FA. Yikes, this > smells of > OBAST! :-) see above comment > > 6). In sec 2.1 the GFA in theory could be co-located with the one of the two > bi-casting > FAs. This would reduce the box count (and this is what OBAST does > with its > call anchor). I agree, and we support both what we call anchor FA and GFA. We needed to support both of these modes to comply with the Regional Registration I-D. Personally, I would prefer NOT to support GFA directly, but only the anchor mode. If a GFA is deployed in the network, it would be used by the anchor FA (not the new FA). IMHO, this would really simplify the I-D. > > 7). With respect to Movement detection, could we not generalize this > coverage > detection? The MN knows its in the coverage are of a collection of > subnets > and can establish new FA relationships with each new subnet, > selectively > dropping the old FA relationships as that coverage disappears. Why > can't > traffic be deliverec while registration is occuring? Presumably the > MN already > has connections with other hosts that are valid. Not sure I understand your comment, because the way I read it, the draft already does this. > > 8). If a new link layer is detected by a MN it could tell its current FA > about it > and the FA would know about all valid hand off candidates for that link > type > due to hand off candidate discovery as described in 2 above. and this information is sent in the air interface message, right? Are you proposing that this also has to be sent in the layer 3 (Mobile IP) message? > > //BEGIN (:-)) > For those of you born after about 1980, Phil is starting to sound like a > piece of vinyl with grooves encoded with music that would often get cross > threaded causing the needle to play the same grooves of music over and over > again. //END (:-)) Yeah, and I had to trash all my vinyls about 6 months ago.... :) > > 9). It would not take much of nudge to make this thing work with a > make-before > break capability, then I would be happy and probably shut up! Do you > want > me take a stab at this? Please do! > > 10). In section 3.1, To avoid ping-ponging we can use the trick CDMA uses. > USE MAKE BEFORE BREAK, and add and drops multiple simultaneously > bi-casted, tri-casted call legs! Then thresholds can be added. You > can > make decisions like, gee statistically, this particular link layer > isn't buying > me squat anymore, i.e. I don't use the packets coming from that link > layer > so that active leg can be dropped. but our I-D already does this, right? What is missing? > > 11). I take objection to including section 9.0-9.2. All link layers should > be addressed > in generalities with maybe a distinction between fixed and wireless > being allowed. > Of course I am not a fan of the MIER approach at all. Whether MIER is good or not, it is irrelevant. We have limited address space, and MIER allows us to conserve some space. What, exactly, would you prefer to see in sections 9.0-9.2? Thanks for all the great comments. Certainly does deserve at least one free beer (which reminds me, we really need to meet in Munich again!). PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Sep 28 22:29: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 SMTP id WAA07989 for ; Thu, 28 Sep 2000 22:29:21 -0400 (EDT) Received: from standards (47.234.32.16:1693) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9A079@standards.nortelnetworks.com>; Thu, 28 Sep 2000 22:13:19 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5920 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 28 Sep 2000 22:13:19 -0400 Received: from ftpbox.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9A074@standards.nortelnetworks.com>; Thu, 28 Sep 2000 22:03:18 -0400 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id TAA09774; Thu, 28 Sep 2000 19:17:28 -0700 (MST)] Received: [from relay2.cig.mot.com (relay2.cig.mot.com [136.182.15.24]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id TAA02267; Thu, 28 Sep 2000 19:17:28 -0700 (MST)] Received: from cig.mot.com (t-il06-ab-port28.corp.mot.com [129.188.170.238]) by relay2.cig.mot.com (8.9.0/SCERG-RELAY-1.11b) with ESMTP id VAA07417; Thu, 28 Sep 2000 21:17:25 -0500 (CDT) X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39D3FBAE.6AB27851@cig.mot.com> Date: Thu, 28 Sep 2000 21:17:18 -0500 Reply-To: Peter Lei Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Peter Lei Subject: Re: [MOBILE-IP] New Pro-active Foreign Agent I-D available X-To: "pcalhoun@eng.sun.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Pat, In section 9.0-9.1, can you generalize the "cdma2000 IMSI" to just "IMSI" throughout? The coding format for cdma2000 IMSI follows ITU E.212, which is also used by GSM/3GPP (GSM Rec 3.03, 3GPP TS 23.003). Or is there something that I'm missing?? --peter > > All, > > I sent the latest draft to the secretariat. For those of you that would like a > preview of the draft, it is available at > http://www.cdma-2000.org/draft-calhoun-mobileip-proactive-fa-02.txt > > Enjoy, > > PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Sep 28 22:36: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 SMTP id WAA09044 for ; Thu, 28 Sep 2000 22:36:12 -0400 (EDT) Received: from standards (47.234.32.16:1693) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9A0B7@standards.nortelnetworks.com>; Thu, 28 Sep 2000 22:18:19 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6005 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 28 Sep 2000 22:18:19 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9A0B6@standards.nortelnetworks.com>; Thu, 28 Sep 2000 22:18:19 -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 UAA05717; Thu, 28 Sep 2000 20:32:27 -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 TAA05262; Thu, 28 Sep 2000 19:32:27 -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 TAA23831; Thu, 28 Sep 2000 19:32:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Thu, 28 Sep 2000 19:30:23 -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] New Pro-active Foreign Agent I-D available X-To: Peter Lei To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <39D3FBAE.6AB27851@cig.mot.com> > Pat, > > In section 9.0-9.1, can you generalize the "cdma2000 IMSI" to just "IMSI" > throughout? The coding format for cdma2000 IMSI follows ITU E.212, which > is also used by GSM/3GPP (GSM Rec 3.03, 3GPP TS 23.003). Or is there > something that I'm missing?? The authors felt that it would be nice to distinguish GSM from CDMA, such that an inter-technology hand-off would be identified through the link address. Furthermore, CDMA supports multiple RLPs, so we designed the link address to support this feature. I am not sure that GSM supports this as well, but I am interested in hearing from someone that would know. PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Sep 28 23:29: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 SMTP id XAA09694 for ; Thu, 28 Sep 2000 23:29:53 -0400 (EDT) Received: from standards (47.234.32.16:2451) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9A14F@standards.nortelnetworks.com>; Thu, 28 Sep 2000 23:13:31 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6211 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 28 Sep 2000 23:13:31 -0400 Received: from imc21.ex.nus.edu.sg by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9A14E@standards.nortelnetworks.com>; Thu, 28 Sep 2000 23:03:30 -0400 Received: by imc21.ex.nus.edu.sg with Internet Mail Service (5.5.2650.21) id ; Fri, 29 Sep 2000 11:17:39 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: <30A14FB41CC5D311854D00508B5EEF02035D3DEA@exs23.ex.nus.edu.sg> Date: Fri, 29 Sep 2000 11:17:36 +0800 Reply-To: Koh Chye Soon Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Koh Chye Soon Subject: [MOBILE-IP] Any MIP-Diffserv reports/docs/papers/web-sites available? To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi, Are there any MIP-DiffServ integration papers, drafts or web-pages available? I'm looking for such resources for my research here and would appreciate it if you could pass me the relevant links. To my understanding, there has been a paper in Europe (UK?) on this subject already, and an Internet Draft on this has been submitted before by a research team from Korea. Is this true? Thank you and best regards, Chye Soon From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Sep 29 01:59: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 SMTP id BAA17525 for ; Fri, 29 Sep 2000 01:59:34 -0400 (EDT) Received: from standards (47.234.32.16:1124) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9A1CD@standards.nortelnetworks.com>; Fri, 29 Sep 2000 1:43:00 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6378 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 29 Sep 2000 01:43:00 -0400 Received: from crux.tip.CSIRO.AU by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9A1CA@standards.nortelnetworks.com>; Fri, 29 Sep 2000 1:32:59 -0400 Received: from b2.tip.CSIRO.AU (b2.tip.CSIRO.AU [130.155.194.254]) by crux.tip.CSIRO.AU (8.9.3/8.9.3/TIPAT-1.1e) with ESMTP id QAA02079; Fri, 29 Sep 2000 16:47:05 +1100 (EST) Received: from localhost (mminhazu@localhost) by b2.tip.CSIRO.AU (8.7.5/8.7.3) with ESMTP id QAA10906; Fri, 29 Sep 2000 16:47:01 +1100 (EST) X-Authentication-Warning: b2.tip.CSIRO.AU: mminhazu owned process doing -bs MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Fri, 29 Sep 2000 16:47:00 +1100 Reply-To: Muneyb Minhazuddin Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Muneyb Minhazuddin Subject: [MOBILE-IP] Any MIP-Diffserv reports/docs/papers/web-sites X-To: Koh Chye Soon X-cc: John.Deane@tip.csiro.au To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <10009290427.AA07261@thylacoleo.tip.CSIRO.AU> > Hi, > > Are there any MIP-DiffServ integration papers, drafts or web-pages > available? I'm looking for such resources for my research here and would > appreciate it if you could pass me the relevant links. > > To my understanding, there has been a paper in Europe (UK?) on this subject > already, and an Internet Draft on this has been submitted before by a > research team from Korea. Is this true? > There was an internet draft submitted in the diffserv WG, it expired though Mobility Support in the Differentiated Services, J. Oh. Kim, Y. Mun, draft-kim-mobile-diff-00.txt, Feb 1999 You will find this site useful, it also has a copy of the above mentioned draft http://iamwww.unibe.ch/~balmer/paperindex.html Cheers Muneyb Host Diffserv Implementation list. _________________________________________________________ Muneyb Minhazuddin - Telecommunications Research Engineer CSIRO Telecommunications and Industrial Physics Sydney, NSW, Australia. Phone no. : 61 2 9372 4113 FAX : 61 2 9372 4490 e-mail : mminhazu@tip.csiro.au Home Page : http://www-networks.tip.csiro.au/~mminhazu --------------------------------------------------------- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Sep 29 06:44: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 SMTP id GAA26006 for ; Fri, 29 Sep 2000 06:44:21 -0400 (EDT) Received: from standards (47.234.32.16:4942) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9A2AE@standards.nortelnetworks.com>; Fri, 29 Sep 2000 6:28:04 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6662 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 29 Sep 2000 06:28:04 -0400 Received: from extmx.itri.org.tw by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9A2AA@standards.nortelnetworks.com>; Fri, 29 Sep 2000 6:17:27 -0400 Received: from mail3.itri.org.tw (mail3.itri.org.tw [140.96.157.3]) by extmx.itri.org.tw (8.8.8/8.8.8) with ESMTP id PAA22268 for ; Fri, 29 Sep 2000 15:22:58 +0800 (CST) Received: from nti.itri.org.tw ([140.96.157.2]) by mail3.itri.org.tw (8.9.3+Sun/8.9.1) with ESMTP id PAA28626 for ; Fri, 29 Sep 2000 15:14:26 +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 PAA13597 for ; Fri, 29 Sep 2000 15:20:05 +0800 (CST) Received: from CCLiu ([140.96.104.105]) by cclmail.ccl.itri.org.tw (Lotus Domino Release 5.0.2a (Intl)) with SMTP id 2000092915193971:2479 ; Fri, 29 Sep 2000 15:19:39 +0800 References: <4B6BC00CD15FD2119E5F0008C7A419A5089EB2AB@eaubrnt018.epa.ericsson.se> 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/09/29 03:19:39 PM, Serialize by Router on CCLMAIL/ITRI(Release 5.0.2a (Intl)|23 November 1999) at 2000/09/29 03:20:00 PM, Serialize complete at 2000/09/29 03:20:00 PM Content-Type: multipart/alternative; boundary="----=_NextPart_000_007C_01C02A28.47B9EF00" Message-ID: <007f01c029e5$39af1900$6968608c@cclk400.ccl.itri.org.tw> Date: Fri, 29 Sep 2000 15:16:45 +0800 Reply-To: =?big5?B?vEKr2KfT?= Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: =?big5?B?vEKr2KfT?= Subject: Re: [MOBILE-IP] New I-D: draft-yegin-mobileip-nrouting-00.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_007C_01C02A28.47B9EF00 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] New I-D: draft-yegin-mobileip-nrouting-00.txtIn this = draft, AR has to specify possible prefix candidates and MN provide COAs. But the moving of MN may be fast from one zone to another zone. So I doubt that the prediction of AR and MN is reasonable?? ----- Original Message -----=20 From: Hesham Soliman (EPA)=20 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM=20 Sent: Thursday, September 28, 2000 10:54 AM Subject: Re: [MOBILE-IP] New I-D: draft-yegin-mobileip-nrouting-00.txt =20 You are talking about MN being data connected at both the previous = link=20 and the=20 new link simultanesouly, right? You are right, if that was the case,=20 it'd be=20 easier: if MN has enough time in the overlapped area to get the latest = BUs to=20 CNs/HA and receive the last packet sent to old CoA, then things are=20 fine.=20 But I think when this was discussed, people said not all the=20 technologies=20 provide this "be connected at both links" feature, it may require two=20 receivers=20 ...=20 Also, if the overlap area is too small, MN may get out of it before = the=20 last=20 packet sent to old CoA is received.=20 =3D> Actually the overlapping is part of the network planning or cell = planning in celular networks and should be enough for the handoff = sequence to take place. The problem is as you mentioned above, most raio links = don't=20 allow you to have simultaneous data connections. So thees are really =20 two separate issues.=20 ------=_NextPart_000_007C_01C02A28.47B9EF00 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] New I-D: = draft-yegin-mobileip-nrouting-00.txt
In this draft, AR has to specify possible prefix = candidates=20 and MN provide COAs.
But the moving of MN may be fast from one zone to = another=20 zone.
So I doubt that the prediction of AR and MN is=20 reasonable??
----- Original = Message -----
From:=20 Hesham Soliman (EPA)
To: MOBILE-IP@STANDARDS.NORTEL= NETWORKS.COM=20
Sent: = Thursday, September 28, 2000 10:54=20 AM
Subject: Re: = [MOBILE-IP] New I-D:=20 draft-yegin-mobileip-nrouting-00.txt

 


You are talking about MN being data connected at = both the=20 previous link
and the
new link=20 simultanesouly, right? You are right, if that was the case, =
it'd be
easier: if MN has enough = time in the=20 overlapped area to get the latest
BUs = to=20
CNs/HA and receive the last packet sent to old CoA, = then=20 things are
fine.

But I think when this was discussed, people said not = all=20 the
technologies
provide this=20 "be connected at both links" feature, it may require two =
receivers
...

Also, if the overlap area is too small, MN may get = out of it=20 before the
last
packet sent to=20 old CoA is received.

=3D> Actually the overlapping is part of the = network planning=20 or cell planning in celular networks and should be enough for the = handoff=20 sequence

to take place. The problem is as you mentioned = above, most=20 raio links don't
allow you to have = simultaneous data=20 connections. So thees are really 
two = separate=20 issues.

------=_NextPart_000_007C_01C02A28.47B9EF00-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Sep 29 07:15:58 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA26588 for ; Fri, 29 Sep 2000 07:15:58 -0400 (EDT) Received: from standards (47.234.32.16:4942) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9A324@standards.nortelnetworks.com>; Fri, 29 Sep 2000 6:59:43 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6809 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 29 Sep 2000 06:59:42 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9A319@standards.nortelnetworks.com>; Fri, 29 Sep 2000 6:49:41 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26387; Fri, 29 Sep 2000 07:02:03 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200009291102.HAA26387@ietf.org> Date: Fri, 29 Sep 2000 07:02:03 -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-gnaie-01.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Generalized NAI Extension (GNAIE) Author(s) : M. Khalil, E. Qaddoura, H. Akhtar, P. Calhoun Filename : draft-mkhalil-mobileip-gnaie-01.txt Pages : 7 Date : 28-Sep-00 The Mobile IP Extensions Rationalization (MIER) specification defines a new extension header format, that is intended to extend the Mobile IP extension address space. This document defines the Generalized Network Access Identifier (NAI) extension, which SHOULD be used by any Mobile IP extension specifying an extension containing an NAI. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mkhalil-mobileip-gnaie-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-mkhalil-mobileip-gnaie-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-mkhalil-mobileip-gnaie-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: <20000928133516.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mkhalil-mobileip-gnaie-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-mkhalil-mobileip-gnaie-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000928133516.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Sep 29 08:13: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 SMTP id IAA27659 for ; Fri, 29 Sep 2000 08:13:20 -0400 (EDT) Received: from standards (47.234.32.16:3198) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9A36F@standards.nortelnetworks.com>; Fri, 29 Sep 2000 7:57:16 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6922 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 29 Sep 2000 07:57:15 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9A36E@standards.nortelnetworks.com>; Fri, 29 Sep 2000 7:47:15 -0400 Received: from netranger. ([202.104.88.141]) by hosaka.smallworks.com (8.9.1/8.9.1) with SMTP id HAA08860 for ; Fri, 29 Sep 2000 07:01:25 -0500 (CDT) Received: from dinosaur by netranger. (SMI-8.6/SMI-SVR4) id DAA28187; Sat, 30 Sep 2000 03:59:08 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Message-ID: <200009291959.DAA28187@netranger.> Date: Sat, 30 Sep 2000 03:59:08 +0800 Reply-To: mike22@ARABIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: mike22@ARABIA.COM Subject: [MOBILE-IP] ADV: Search Engine Registration X-To: mobile-ip@smallworks.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Removal instructions below I saw your listing on the internet. I work for a company that specializes in getting clients web sites listed as close to the top of the major search engines as possible. Our fee is only $29.95 per month to submit your site at least twice a month to over 350 search engines and directories. To get started and put your web site in the fast lane, call our toll free number below. Mike Bender 888-532-8842 To be removed call: 888-800-6339 X1377 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Sep 29 13:37: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 SMTP id NAA03830 for ; Fri, 29 Sep 2000 13:37:41 -0400 (EDT) Received: from standards (47.234.32.16:1444) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9A453@standards.nortelnetworks.com>; Fri, 29 Sep 2000 13:21:10 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7212 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 29 Sep 2000 13:21:09 -0400 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9A452@standards.nortelnetworks.com>; Fri, 29 Sep 2000 13:21:09 -0400 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA05300; Fri, 29 Sep 2000 10:35:14 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.86.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id KAA20115; Fri, 29 Sep 2000 10:35:14 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.1+Sun/8.11.1.Beta1) with SMTP id e8THZB5642712; Fri, 29 Sep 2000 10:35:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: hEphFjTPjUHobwIzUNLQcw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Message-ID: <200009291735.e8THZB5642712@jurassic.eng.sun.com> Date: Fri, 29 Sep 2000 10:31:13 -0700 Reply-To: Alper Yegin Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Alper Yegin Subject: Re: [MOBILE-IP] New I-D: draft-yegin-mobileip-nrouting-00.txt X-To: jcliu@ITRI.ORG.TW To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > In this draft, AR has to specify possible prefix candidates and MN provide > COAs. But the moving of MN may be fast from one zone to another zone. > So I doubt that the prediction of AR and MN is reasonable?? This is why the "neighborhood" can consist of more than one link. One case is MN is not moving, or it's moving but will be in the same link for a while (due to big cell, slow speed MN), then neighborhood is only the current link (link1). For other cases, there needs to be more links in the neighborhood. Like in your example, if there's a possiblity that MN might be in link2, and even link3 (MN moving through link1, link2, and link3), then neighborhood will be "link1, link2, link3". alper From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Sep 30 06: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 SMTP id GAA26993 for ; Sat, 30 Sep 2000 06:23:59 -0400 (EDT) Received: from standards (47.234.32.16:4280) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9A62C@standards.nortelnetworks.com>; Sat, 30 Sep 2000 6:07:36 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7817 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 30 Sep 2000 06:07:36 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9A624@standards.nortelnetworks.com>; Sat, 30 Sep 2000 5:57:35 -0400 Received: from kopiweb.kopitime.com ([203.130.232.11]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id FAA15192; Sat, 30 Sep 2000 05:11:41 -0500 (CDT) Received: from 209.179.244.26 ([209.179.244.26]) by kopiweb.kopitime.com with Microsoft SMTPSVC(5.5.1877.197.19); Sat, 30 Sep 2000 17:06:42 +0700 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Message-ID: <0000176f0b91$000013dd$00004a05@> Date: Sat, 30 Sep 2000 03:06:53 -0700 Reply-To: kfranklin2937@HOTMAIL.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: kfranklin2937@HOTMAIL.COM Subject: [MOBILE-IP] Merchant Services Plus!! 18949 X-To: Undisclosed.Recipients@hosaka.smallworks.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: quoted-printable Quick Application
Are you looking to have your own web presence?

Are you losing business because you are
unable to process credit cards & checks
over the internet?

Sign up and get a FREE shopping cart!

Start Your Internet e-Commerce Store today!
* Custom Web-Site for Life
* Unlimited pages and images
* Free Electronic Shopping Cart
* 24 hour customer service
* 99% approval rate!

Studies have shown you can increase your sales up to
1500% by accepting Credit Cards on-line!

Accept Visa, Mastercard, Discover/Novus and
American Express! Also Debit Card, Direct Check,
and countless more!

$79.95 Gets You Started!

Internet Business ~ New Startups ~ Home Office
Mail/Phone Order ~ Retail Stores
99% approval! ~ No set-up fees! ~ Low monthly fees

REPLY NOW! & Learn How to Receive this Custom
Web-Site e-Commerce solution!

STARTING A BUSINESS ONLINE OF ANY KIND?
NEED A WEBSITE & MERCHANT ACCOUNT for your
business?

So what are you waiting for?

If you REPLY within 24 hours
We will waive all application and setup fees! A savings of $295.00!
We will also throw in a shopping cart to complete your e-Commerce store!

THERE IS NO OBLIGATION IN RESPONDING TO THIS EMAIL
EXCEPT TO RECEIVE MORE INFORMATION.

FOR YOUR FREE INFORMATION FILL OUT THE FORM BELOW.





Fill= out this short form to receive your free information.

1. Please en= ter your full name:
2. Please en= ter your phone number:
(xxx-xxx-xxxx)
Home Work
3. What is t= he best time to phone you?
4. State or = Province where you live?
5. Country w= here you live?
6. Please en= ter your email address:
       

If you received this in error or would like to be
removed from our list, PLEASE CLICK HERE