From owner-mobile-ip@sunroof.eng.sun.com Tue May 1 01:56:15 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA12898 for ; Tue, 1 May 2001 01:56:14 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA06910; Mon, 30 Apr 2001 22:56:03 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA17497; Mon, 30 Apr 2001 22:55:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f415s7IM000461 for ; Mon, 30 Apr 2001 22:54:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f415s6nl000460 for mobile-ip-dist; Mon, 30 Apr 2001 22:54:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f415rvIM000453 for ; Mon, 30 Apr 2001 22:53:58 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA27362 for ; Mon, 30 Apr 2001 22:53:57 -0700 (PDT) Received: from ws130.nomadiclab.com (ws130.nomadiclab.com [195.165.196.130]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA06371 for ; Mon, 30 Apr 2001 22:53:56 -0700 (PDT) Received: from ws34.nomadiclab.com (ws34.nomadiclab.com [195.165.196.34]) by ws130.nomadiclab.com (Postfix) with ESMTP id F283C72504 for ; Tue, 1 May 2001 08:53:54 +0300 (EEST) Received: from nomadiclab.com (localhost [127.0.0.1]) by ws34.nomadiclab.com (Postfix) with ESMTP id 590E7BA2F for ; Tue, 1 May 2001 08:53:54 +0300 (EEST) Message-ID: <3AEE4E79.46F6C879@nomadiclab.com> Date: Tue, 01 May 2001 06:49:45 +0100 From: Pekka Nikander X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en,fi MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Authenticating BU and PKI References: <3AE6F2DB.88661142@crm.mot.com> <3AED5196.4771F69@nomadiclab.com> <3AED6D36.26EEA17B@francetelecom.com> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by patan.sun.com id WAA06910 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA12898 > Pekka Nikander a écrit : > .... > > In this particular case (authenticating BUs), secure reverse > > DNS would be the "right" PKI for the purpose. However, getting > > it running seems like quite an obstackle, and even if we had it, > > authenticating a random MN > Jean-Michel COMBES wrote: > I think you wanted to say 'random CN' No, I really meant 'random MN'. Unless I have understood something completely wrong, the "MIPv6 security case" is looking for a solution where the CN can reasonably believe that the MN sending BUs is the "right" MN, i.e. the one that is authorized to set up a binding for the specific home address. For some specific attack scenarios, see e.g. draft-nikander-ipng-address-ownership-00.txt > > Just to clarify: A simple infrastructure with some global CA > > providing simple certificates is not enough and/or feasible. The > > certificate must include the home address, and the issuer of > > the certificate must be authorized to issue certificates > > concerning that particular home address, etc. > > JMC : > A possible solution would be to use the HA. > Explanation : > When the MN receives tunneled packets from its HA, the MN should send BU to > the CN (MIPv6, section 10.3). This is the _FIRST TIME_ that the MN will send > a BU to a CN and will have to set up SA to authenticate BU. So the HA knows > when the MN will have to set up IPsec parameters ... why don't we use this > fact ? When the HA encapsulates packets to the MN, it could send MN's > certificate to the CN too, including the Home Address that the MN can use > (ie. resolving the authorization problem) with the BU. I am sorry but I don't understand what you have in mind. You are right that the first time the MN sends a BU to the CN it must set up an SA. The problem is HOW to set up this SA if there is no prior security relationship between the MN and the CN. How does the CN know that the MN is really the MN whose home address is the one given? I am sorry, but I just don't understand what you are trying to say. Would you please clarify? --Pekka From owner-mobile-ip@sunroof.eng.sun.com Tue May 1 10:53:49 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29627 for ; Tue, 1 May 2001 10:53:48 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA21204; Tue, 1 May 2001 07:53:30 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA02748; Tue, 1 May 2001 07:53:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41EpcIM001436 for ; Tue, 1 May 2001 07:51:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41Epchf001435 for mobile-ip-dist; Tue, 1 May 2001 07:51:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41EpUIM001428 for ; Tue, 1 May 2001 07:51:30 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA27801 for ; Tue, 1 May 2001 07:51:30 -0700 (PDT) Received: from web13802.mail.yahoo.com (web13802.mail.yahoo.com [216.136.175.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id HAA05145 for ; Tue, 1 May 2001 07:51:29 -0700 (PDT) Message-ID: <20010501145127.65214.qmail@web13802.mail.yahoo.com> Received: from [202.190.176.153] by web13802.mail.yahoo.com; Tue, 01 May 2001 07:51:27 PDT Date: Tue, 1 May 2001 07:51:27 -0700 (PDT) From: jae jone Subject: [mobile-ip] hello To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: hi i would like to ask if mobile node move from old router to anther router at the same network do the MN need to have care of address or it may still use its home address ..:) thanx in advance __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ From owner-mobile-ip@sunroof.eng.sun.com Tue May 1 12:09:17 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02394 for ; Tue, 1 May 2001 12:09:17 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA03049; Tue, 1 May 2001 09:08:53 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03950; Tue, 1 May 2001 09:08:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41G6sIM001537 for ; Tue, 1 May 2001 09:06:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41G6rx8001536 for mobile-ip-dist; Tue, 1 May 2001 09:06:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41G6iIM001529 for ; Tue, 1 May 2001 09:06:44 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA23685 for ; Tue, 1 May 2001 09:06:44 -0700 (PDT) Received: from zrc2s03g.us.nortel.com ([47.103.122.66]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17862 for ; Tue, 1 May 2001 09:06:43 -0700 (PDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id LAA20778 for ; Tue, 1 May 2001 11:07:14 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Tue, 1 May 2001 11:01:10 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 May 2001 11:06:33 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E43020D5F5B@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Questions about Route Optimization in MIPv4 Date: Tue, 1 May 2001 11:06:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D258.AF3CDB50" X-Orig: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C0D258.AF3CDB50 Content-Type: text/plain; charset="iso-8859-1" Hyun, Some good points - comments below. -----Original Message----- From: hspark@etri.re.kr [mailto:hspark@etri.re.kr] Sent: Monday, April 30, 2001 9:29 PM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Questions about Route Optimization in MIPv4 Hello, All ... I have some questions about Route Optimization in MIP... It is somewhat an old story... In IMHP (Internet Mobile Host Protocol), the origin of Route Optimization in MIP, there is a notion of "Cache Agent" that is a intermediate router capable of caching a binding for MN... Why was "Cache Agent" excluded from Route Optimization in MIP I-D when adopted by WG ? [Morrow, Glenn ] I do not know why. I'd like to know too. It seems to me that the cache is better suited to be implemented on a purpose-built device than a web server for the majority of Internet Traffic. Is it not workable ? And if Yes, Why ? cf. "Intercepting Location Updates" by Cheng-Yin Lee, et al. attempted a similar work... IMHO, it was a good conception. But that internet-draft was rejected at IETF 49... [Morrow, Glenn ] This draft was trying to develop a framework for providing location privacy yet still allowing the simultaneous operation of route optimization. It also dealt with hierarchy, security. Tunneling or double NAT could be used as options. The draft used the MIP protocol as is. I do not believe the draft was "rejected" by the WG. There was no consensus check ever made for accepting or rejecting the draft. Any minutes indicating rejection are in question in my opinion. One critic of this framework was that it was not a new idea and the WG had previously rejected the concept due to the fact that it relied on installing state in the form of per-node routes and that in working through the "redundancy" schemes of these previous solutions, the WG found some inherent flaw in terms of redundancy. I responded at critic that there was no issue with redundancy, in that if the router acting as the correspondent agent goes down the packets are again routed to the home agent where the process of binding occurs again. Another router that has connectivity to the CN becomes a correspondent agent - no service disruption at all. I honestly do not see realistic deployment scenario of route optimization on IPv4 unless we do do something like the lmk draft. It seems to me that a user is not going to want to indicate on every communication that they want to use optimization or not. It would be helpful if the persons who critic'd both of the proposals clarified just what the percieved issues are. I am certainly not satisfied with the explanations for any percieved rejection of either proposal. I don't think the problems these drafts are trying to solve are going to go away. I do not understand the stall tactics that have been used on providing this functionality. Thanks for bringing up the concept again. I would definitely like to work through any issues and arrive at a workable solution for the WG. It seems to me that the proposals should be WG documents so that the issues can be worked out by the whole group. Thanks, Glenn Another question, I have just found another work for Route Optimization... The title of Internet-Draft was "Routing optimization by a router with cache agent functionality" by Kazuhiro Okanoue I want to know about that and I tried to get that... But I couldn't find that Internet-Draft... If anyone know whereabouts of that document, please let me know where I can get it... [Morrow, Glenn ] I'd like to read this as well. Thanks in advance.... Regards, Hyun Seo ------_=_NextPart_001_01C0D258.AF3CDB50 Content-Type: text/html; charset="iso-8859-1" Questions about Route Optimization in MIPv4
Hyun,
 
Some good points - comments below.
-----Original Message-----
From: hspark@etri.re.kr [mailto:hspark@etri.re.kr]
Sent: Monday, April 30, 2001 9:29 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Questions about Route Optimization in MIPv4

Hello, All ...

I have some questions about Route Optimization in MIP...
It is somewhat an old story...

In IMHP (Internet Mobile Host Protocol), the origin of Route Optimization in MIP,
there is a notion of "Cache Agent" that is a intermediate router capable of caching a binding for MN...
Why was "Cache Agent" excluded from Route Optimization in MIP I-D when adopted by WG ?  

[Morrow, Glenn ]

I do not know why. I'd like to know too. It seems to me that the cache is  better suited to be implemented on a purpose-built device than a web server for the majority of Internet Traffic.

 
Is it not workable ? And if Yes, Why ?
cf. "Intercepting Location Updates" by Cheng-Yin Lee, et al. attempted a similar work...
    IMHO, it was a good conception. But that internet-draft was rejected at IETF 49...

[Morrow, Glenn ] 

This draft was trying to develop a framework for providing location privacy yet still allowing the simultaneous operation of route optimization. It also dealt with hierarchy, security. Tunneling or double NAT could be used as options.

The draft used the MIP protocol as is. I do not believe the draft was "rejected" by the WG. There was no consensus check ever made for accepting or rejecting the draft. Any minutes indicating rejection are in question in my opinion.

One critic of this framework was that it was not a new idea and the WG had previously rejected the concept due to the fact that it relied on installing state in the form of per-node routes and that in working through the "redundancy" schemes of these previous solutions, the WG found some inherent flaw in terms of redundancy.

I responded at critic that there was no issue with redundancy, in that if the router acting as the correspondent agent goes down the packets are again routed to the home agent where the process of binding occurs again. Another router that has connectivity to the CN becomes a correspondent agent - no service disruption at all.

I honestly do not see realistic deployment scenario of route optimization on IPv4 unless we do do something like the lmk draft.  It seems to me that a user is not going to want to indicate on every communication that they want to use optimization or not.

It would be helpful if the persons who critic'd both of the proposals clarified just what the percieved issues are. I am certainly not satisfied with the explanations for any percieved rejection of either proposal.

I don't think the problems these drafts are trying to solve are going to go away. I do not understand the stall tactics that have been used on providing this functionality.

Thanks for bringing up the concept again. I would definitely like to work through any issues and arrive at a workable solution for the WG. It seems to me that the proposals should be WG documents so that the issues can be worked out by the whole group.

Thanks,

Glenn

Another question,
I have just found another work for Route Optimization...
The title of Internet-Draft was
        "Routing optimization by a router with cache agent functionality"
        <draft-okanoue-mobileip-R+A-00.txt> by Kazuhiro Okanoue
I want to know about that and I tried to get that...
But I couldn't find that Internet-Draft...
If anyone know whereabouts of that document, please let me know where I can get it...
[Morrow, Glenn ] I'd like to read this as well. 

Thanks in advance....

Regards,
Hyun Seo

------_=_NextPart_001_01C0D258.AF3CDB50-- From owner-mobile-ip@sunroof.eng.sun.com Tue May 1 12:16:24 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02632 for ; Tue, 1 May 2001 12:16:23 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA06486; Tue, 1 May 2001 09:16:13 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA05060; Tue, 1 May 2001 09:16:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41GEGIM001554 for ; Tue, 1 May 2001 09:14:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41GEG22001553 for mobile-ip-dist; Tue, 1 May 2001 09:14:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41GE7IM001546 for ; Tue, 1 May 2001 09:14:07 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id JAA29722 for ; Tue, 1 May 2001 09:14:07 -0700 (PDT) Message-Id: <200105011614.JAA29722@heliopolis.eng.sun.com> Date: Tue, 1 May 2001 09:14:07 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Some Analysis To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: AbQgJ5d6uHJhXjhf0vgInw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Wolfgang, Just one comment. >Let me finish by giving my peronal interpretation of these numbers >(and I would be very happy to receive critical replies): >Hierarchical mobility support is, in some cases, provably better >than the non-hierarchical counterpart. >But these cases do not occur very often. >Hence it is questionable to attempt an optimization - >it would have an effect only in rare cases. Indeed, that's the question, isn't it? How common are these cases going to be? I think we can argue about light years v.s. millimeters and 60 ms v.s. 6, but we can't know really. It is a judgement call. One thing is for sure. If hierarchy is not supported, then these cases become suboptimal. And, to the extent that these cases correspond to particular business models, any decision we make on not supporting hierarchy will result in an adverse impact on those business models. jak From owner-mobile-ip@sunroof.eng.sun.com Tue May 1 12:21:42 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02843 for ; Tue, 1 May 2001 12:21:42 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA08967; Tue, 1 May 2001 09:21:33 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA18686; Tue, 1 May 2001 09:21:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41GJoIM001576 for ; Tue, 1 May 2001 09:19:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41GJn7n001575 for mobile-ip-dist; Tue, 1 May 2001 09:19:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41GJeIM001568 for ; Tue, 1 May 2001 09:19:40 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA12591 for ; Tue, 1 May 2001 09:19:40 -0700 (PDT) Received: from zrc2s03g.us.nortel.com ([47.103.122.66]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA27971 for ; Tue, 1 May 2001 09:19:39 -0700 (PDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id LAA24439 for ; Tue, 1 May 2001 11:20:10 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Tue, 1 May 2001 11:14:07 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 May 2001 11:19:30 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E43020D5F96@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Multiple flows with single NAI Date: Tue, 1 May 2001 11:19:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D25A.7F6FD920" X-Orig: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C0D25A.7F6FD920 Content-Type: text/plain; charset="iso-8859-1" Madhavi, Are you thinking of the NAI as a: subscription identifier user identifier Equipment identifier? It seems to me that each device might have different home addresses. The key can be a bit more complex than just an NAI into a database/directory used for any purpose. -----Original Message----- From: Madhavi Subbarao [mailto:msubbara@cisco.com] Sent: Monday, April 30, 2001 6:53 PM To: mobile-ip@sunroof.eng.sun.com Cc: Madhavi W Subbarao Subject: [mobile-ip] Multiple flows with single NAI Hi All, For viable deployment of MIP, it seems necessary to support single NAI with multiple static IP flows. For example, if a user opens a MIP session on his laptop and then wants another MIP session on his phone, he couldn't do that now with a single NAI . Now when an HA receives an RRQ with NAI and homeIP#2, but it already has a binding for NAI and homeIP#1, the binding gets 'overwritten'. Hence, only one MIP flow can be supported per NAI. Theoretically, we can say to use multiple NAIs, but practically, it's not possible. Many service providers do not want to create multiple NAIs and user records for multiple devices/applications or instances of the mobile user. While it seems natural then to allow multiple static IPs for the same NAI (dynamic IPs also, but that needs another level of identification), neither RFC2002 nor RFC2974 outline the behavior that should be followed by the various entities. The specs certainly do not preclude the above, but clarity in behavior is needed. We believe this is a simple, yet important issue for deployment and would like feedback from the WG. We've submitted a draft that addresses the above. http://search.ietf.org/internet-drafts/draft-subbarao-mobileip-multipleip-00 .txt Thanks, Madhavi ------_=_NextPart_001_01C0D25A.7F6FD920 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Multiple flows with single NAI

Madhavi,


Are you thinking of the NAI as a:

subscription identifier
user identifier
Equipment identifier?

It seems to me that each device might have different = home addresses. The key can be a bit more complex than just an NAI into = a database/directory used for any purpose.

-----Original Message-----
From: Madhavi Subbarao [mailto:msubbara@cisco.com]=
Sent: Monday, April 30, 2001 6:53 PM
To: mobile-ip@sunroof.eng.sun.com
Cc: Madhavi W Subbarao
Subject: [mobile-ip] Multiple flows with single = NAI


Hi All,

For viable deployment of MIP, it seems necessary to = support single NAI
with multiple static IP flows.  For example, if = a user opens a MIP
session on his laptop and then wants another MIP = session on his phone,
he couldn't do that now with a single NAI .  = Now when an HA receives
an RRQ with NAI and homeIP#2, but it already has a = binding for NAI
and homeIP#1, the binding gets 'overwritten'.  = Hence, only one MIP
flow can be supported per NAI.  Theoretically, = we can say to use
multiple NAIs, but practically, it's not = possible.  Many service providers
do not want to create multiple NAIs and user records = for multiple
devices/applications or instances of the mobile = user.

While it seems natural then to allow multiple static = IPs for the same NAI
(dynamic IPs also, but that needs another level of = identification),
neither RFC2002 nor RFC2974 outline the behavior = that should be
followed by the various entities.  The specs = certainly do not preclude
the above, but clarity in behavior is needed.

We believe this is a simple, yet important issue for = deployment and would
like feedback from the WG.

We've submitted a draft that addresses the = above.
http://search.ietf.org/internet-drafts/draft-subbarao-= mobileip-multipleip-00.txt

Thanks,
Madhavi

------_=_NextPart_001_01C0D25A.7F6FD920-- From owner-mobile-ip@sunroof.eng.sun.com Tue May 1 12:32:21 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03110 for ; Tue, 1 May 2001 12:32:20 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06334; Tue, 1 May 2001 09:31:33 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA20991; Tue, 1 May 2001 09:31:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41GTaIM001638 for ; Tue, 1 May 2001 09:29:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41GTZP6001637 for mobile-ip-dist; Tue, 1 May 2001 09:29:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41GTQIM001630 for ; Tue, 1 May 2001 09:29:27 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA14166 for ; Tue, 1 May 2001 09:29:26 -0700 (PDT) Received: from zrc2s03g.us.nortel.com ([47.103.122.66]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA04534 for ; Tue, 1 May 2001 09:29:25 -0700 (PDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id LAA27148 for ; Tue, 1 May 2001 11:29:57 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Tue, 1 May 2001 11:23:37 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 May 2001 11:29:00 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E43020D5FBE@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Protocol Decision Fixed? Date: Tue, 1 May 2001 11:28:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D25B.D1F69930" X-Orig: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C0D25B.D1F69930 Content-Type: text/plain; charset="iso-8859-1" I agree -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: Friday, April 27, 2001 9:03 AM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Protocol Decision Fixed? On Fri, Apr 27, 2001 at 09:03:40AM -0400, Phil Roberts wrote: > Hi, > > In the interest of progress it's probably not a good idea to be constantly > revisiting which drafts are working group items. Some questions > should be asked "What is different now from when we made the decision?" > or "What do we know now that we didn't know when we made the decision?" or > "What requirements have changed since we made the decision?" > How to proceed is based on working group consensus. > and if consistuents believe that a simpler approach, which may be radically different from existing proposals, would be better, and still meet the requirements, should we ignore them? I think not. To be honest, this recent requirements gathering process, which consisted primarily of the I-D authors anyways, was sort-of a backwards approach. I think that the WG should be open to starting the process from scratch, gathering the requirements and documenting them, and then allow people to contribute their protocol of choice. I think that limiting contributions to existing proposals is the wrong approach. my 2 cents, PatC ------_=_NextPart_001_01C0D25B.D1F69930 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Protocol Decision Fixed?

I agree

-----Original Message-----
From: Pat Calhoun [mailto:pcalhoun@diameter.org]
Sent: Friday, April 27, 2001 9:03 AM
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Protocol Decision Fixed?


On Fri, Apr 27, 2001 at 09:03:40AM -0400, Phil Roberts wrote:
> Hi,
>
> In the interest of progress it's probably not a good idea to be constantly
> revisiting which drafts are working group items.  Some questions
> should be asked "What is different now from when we made the decision?"
> or "What do we know now that we didn't know when we made the decision?" or
> "What requirements have changed since we made the decision?" 
> How to proceed is based on working group consensus.
>
and if consistuents believe that a simpler approach, which may be radically
different from existing proposals, would be better, and still meet the
requirements, should we ignore them?

I think not.

To be honest, this recent requirements gathering process, which consisted
primarily of the I-D authors anyways, was sort-of a backwards approach. I
think that the WG should be open to starting the process from scratch,
gathering the requirements and documenting them, and then allow people
to contribute their protocol of choice.

I think that limiting contributions to existing proposals is the wrong
approach.

my 2 cents,

PatC

------_=_NextPart_001_01C0D25B.D1F69930-- From owner-mobile-ip@sunroof.eng.sun.com Tue May 1 12:50:02 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03687 for ; Tue, 1 May 2001 12:50:00 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA13494; Tue, 1 May 2001 09:29:33 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA14118; Tue, 1 May 2001 09:29:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41GRAIM001628 for ; Tue, 1 May 2001 09:27:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41GR9ZF001627 for mobile-ip-dist; Tue, 1 May 2001 09:27:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41GR1IM001620 for ; Tue, 1 May 2001 09:27:01 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA07041 for ; Tue, 1 May 2001 09:27:00 -0700 (PDT) Received: from zrc2s03g.us.nortel.com ([47.103.122.66]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA09153 for ; Tue, 1 May 2001 10:48:52 -0600 (MDT) Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id LAA26445 for ; Tue, 1 May 2001 11:27:05 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Tue, 1 May 2001 11:26:37 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 May 2001 11:26:17 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E43020D5FB3@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised Localized Mobility Management Requirement s) Date: Tue, 1 May 2001 11:26:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D25B.6F7C2E00" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C0D25B.6F7C2E00 Content-Type: text/plain; charset="iso-8859-1" Phil, I'm sorry I haven't responded to this yet. The traffic has been large on these mailing lists. Sorry again for not getting back to you on the seamoby draft yesterday. I tried to give some comments today for what they are worth. Let me know how things turn out. I would like to participate on the IRTF work. -----Original Message----- From: Phil Roberts [mailto:PRoberts@MEGISTO.com] Sent: Friday, April 27, 2001 2:58 PM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised Localized Mobility Management Requirement s) Hi Glenn, I didn't mean to ignore your earlier post. I responded to something else, got pulled into a meeting, and forgot. I want to respond to your question about changing real routing protocols to meet these requirements. In seamoby there is a small team putting together a problem statement to get some work started on the routing issues in the IRTF. There is a draft of this that SHOULD appear on the seamoby mailing list early next week. Your comments on that are more than welcome. As far as doing that sort of work here, we've tried to focus our work on protocols based on MIP. That doesn't mean there aren't other mobility alternatives and part of seamoby was to figure out whether a good statement could be put together for requirements that would point to the need for alternatives. The outcome of that work so far has been to get some work done in the IRTF on the impacts of using a "real routing" protocol to implement mobility rather than a MIP kind of scheme. Another work item was to produce a list of requirements to send to us for feedback on whether the MIP set of protocols can meet them. Phil -----Original Message----- From: Glenn Morrow [mailto:gmorrow@nortelnetworks.com] Sent: Friday, April 27, 2001 3:51 PM To: mobile-ip@sunroof.eng.sun.com Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised Localized Mobility Management Requirement s) Correction, I believe some vendors have actually tried to make some inroads into these requirements and direction for solutions already That's providers - not vendors. -----Original Message----- From: Morrow, Glenn [RICH2:C330:EXCH] Sent: Thursday, April 26, 2001 1:56 PM To: mobile-ip@sunroof.eng.sun.com Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised Localized Mobility Management Requirement s) Phil, I'm not sure either candidate is exactly what we want in the end. So I am also not sure we should start calling these proposals protocols that have been summarily accepted or rejected, yet. It seems to me that just because the WG has allowed another candidate to become a WG document does not mean that the WG rejected another WG document. I may have missed some hmmm, I admit, though. The way I see it is that two groups have placed different strawmen on the table without any clear requirements to begin with. Now we are going through the requirements discussion. I honestly think that levels of hierarchy (even only 2) gets into the real routing domain unless you spin an LMM to be an application running on a host. Why are we not looking at changing real routing protocols to achieve some of these functions? We haven't even gotten into integrity, race conditions, security associations, routing policy, levels of route propogation and confidentiality amoung these entities. It seems these real routing protocols have already been built with these things in mind and that adding the MM levels might be fairly straight forward. We might even find that we can get rid of single point of failure with this approach. This and the fact that the people were obviating the fact that they were actually doing single per host routes with a name change are my big sticklers on this whole subject and the main reason for my earlier tirade in which I compared RR to other proposed solutions that had the same single point of failure issue but had not been accepted to the WG for this reason in the past. This didn't mean HMIP. Please note - I didn't submit these other solutions. I also think that with this approach, tunnel-relaying or source routing, the scalability concerns in terms of route table size may completely vanish with respect to supporting multiple levels of hierarchy. We also might find that we can leverage the existing security associations of these routers and domains to enhance handoff by adding a new mobile dimension to the routing distance algorithms from a hierarchical point of view. I also seems to me that some other solutions that do not have the SPOF problem have also not been accepted as candidates. The only reason I can suspect for this is that people made up some lame excuse for summarily rejecting the use of existing routing protocols or they wanted to just re-invent the whole wheel from scratch. We really need to start thinking like the network infrastructure owners and their administrative staff instead of new protocol creators. I admit I am also guilty of not doing this in some respects. I believe some vendors have actually tried to make some inroads into these requirements and direction for solutions already. I hate to rehash old decisions but why are we not following this direction? Thanks, Glenn p.s. Sorry about any percieved ranting. -----Original Message----- From: Phil Roberts [ mailto:PRoberts@MEGISTO.com ] Sent: Wednesday, April 25, 2001 3:29 PM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised Localized Mobility Management Requirement s) I'm hoping we don't restart the protocol selection process. If there are compelling reasons to do so we shall. The requirements gathering is more of a way to get some convergence on what is really needed in the protocol. There has been a fair amount of reflection that has gone on since the working group selected the HMIP approach. > -----Original Message----- > From: Behcet Sarikaya [ mailto:behcet.sarikaya@usa.alcatel.com ] > Sent: Wednesday, April 25, 2001 3:20 PM > To: mobile-ip@sunroof.eng.sun.com > Cc: Basavaraj.Patil@nokia.com > Subject: Re: Multiple Levels of LMM agents (was: RE: > [mobile-ip] Revised > Localized Mobility Management Requirement s) > > > Hi Charlie, > I have a feeling that you are talking about regreg6. Is > regreg6 still a > candidate protocol, i.e. after the requirements will the > protocol selection > process for LMM restart? > > Charlie Perkins wrote: > > > Furthermore, > > the upgrade is not a forklift upgrade. One can put in > regional-aware routers > > wherever they are needed, and not disturb the other configuration. > > > > We know that the code to do multiple levels is small, and that the > > protocol isn't bad at all. > > > > Regards, > > Charlie P. > > Regards, > > -- > Behcet > ------_=_NextPart_001_01C0D25B.6F7C2E00 Content-Type: text/html; charset="iso-8859-1" RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised Localized Mobility Management Requirement s)
Phil,
 
I'm sorry I haven't responded to this yet. The traffic has been large on these mailing lists. Sorry again for not getting back to you on the seamoby draft yesterday. I tried to give some comments today for what they are worth. Let me know how things turn out. I would like to participate on the IRTF work.
-----Original Message-----
From: Phil Roberts [mailto:PRoberts@MEGISTO.com]
Sent: Friday, April 27, 2001 2:58 PM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised Localized Mobility Management Requirement s)

Hi Glenn,
 
   I didn't mean to ignore your earlier post.  I responded to something else, got pulled into a meeting, and forgot.
 
   I want to respond to your question about changing real routing protocols to meet these requirements.  In seamoby there is a small team putting together a problem statement to get some work started on the routing issues in the IRTF.  There is a draft of this that SHOULD appear on the seamoby mailing list early next week.  Your comments on that are more than welcome.
 
   As far as doing that sort of work here, we've tried to focus our work on protocols based on MIP.  That doesn't mean there aren't other mobility alternatives and part of seamoby was to figure out whether a good statement could be put together for requirements that would point to the need for alternatives.  The outcome of that work so far has been to get some work done in the IRTF on the impacts of using a "real routing" protocol to implement mobility rather than a MIP kind of scheme.  Another work item was to produce a list of requirements to send to us for feedback on whether the MIP set of protocols can meet them.
 
Phil
 
-----Original Message-----
From: Glenn Morrow [mailto:gmorrow@nortelnetworks.com]
Sent: Friday, April 27, 2001 3:51 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised Localized Mobility Management Requirement s)

Correction,
 
I believe some vendors have actually tried to make some inroads into these requirements  and direction for solutions already
 
That's providers  - not vendors.
-----Original Message-----
From: Morrow, Glenn [RICH2:C330:EXCH]
Sent: Thursday, April 26, 2001 1:56 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised Localized Mobility Management Requirement s)

Phil,

I'm not sure either candidate is exactly what we want in the end. So I am also not sure we should start calling these proposals protocols that have been summarily accepted or rejected, yet.

It seems to me that just because the WG has allowed another candidate to become a WG document does not mean that the WG rejected another WG document.

I may have missed some hmmm, I admit, though. The way I see it is that two groups have placed different strawmen on the table without any clear requirements to begin with. Now we are going through the requirements discussion.

I honestly think that levels of hierarchy (even only 2) gets into the real routing domain unless you spin an LMM to be an application running on a host. 

Why are we not looking at changing real routing protocols to achieve some of these functions? We haven't even gotten into integrity, race conditions, security associations, routing policy, levels of route propogation and confidentiality amoung these entities. It seems these real routing protocols have already been built with these things in mind and that adding the MM levels might be fairly straight forward.

We might even find that we can get rid of single point of failure with this approach. This and the fact that the people were obviating the fact that they were actually doing single per host routes with a name change are my big sticklers on this whole subject and the main reason for my earlier tirade in which I compared RR to other proposed solutions that had the same single point of failure issue but had not been accepted to the WG for this reason in the past. This didn't mean HMIP. Please note - I didn't submit these other solutions.

I also think that with this approach, tunnel-relaying or source routing, the scalability concerns in terms of route table size may completely vanish with respect to supporting multiple levels of hierarchy.

We also might find that we can leverage the existing security associations of these routers and domains to enhance handoff by adding a new mobile dimension to the routing distance algorithms from a hierarchical point of view.

I also seems to me that some other solutions that do not have the SPOF problem have also not been accepted as candidates. The only reason I can suspect for this is that people made up some lame excuse for summarily rejecting the use of existing routing protocols or they wanted to just re-invent the whole wheel from scratch.

We really need to start thinking like the network infrastructure owners and their administrative staff instead of new protocol creators. I admit I am also guilty of not doing this in some respects. I believe some vendors have actually tried to make some inroads into these requirements  and direction for solutions already.

I hate to rehash old decisions but why are we not following this direction?


Thanks,

Glenn

p.s. Sorry about any percieved ranting.

-----Original Message-----
From: Phil Roberts [mailto:PRoberts@MEGISTO.com]
Sent: Wednesday, April 25, 2001 3:29 PM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised
Localized Mobility Management Requirement s)


I'm hoping we don't restart the protocol selection process.  If there are
compelling reasons to do so we shall.  The requirements gathering is more of
a way to get some convergence on what is really needed in the protocol.
There has been a fair amount of reflection that has gone on since the
working group selected the HMIP approach.


> -----Original Message-----
> From: Behcet Sarikaya [mailto:behcet.sarikaya@usa.alcatel.com]
> Sent: Wednesday, April 25, 2001 3:20 PM
> To: mobile-ip@sunroof.eng.sun.com
> Cc: Basavaraj.Patil@nokia.com
> Subject: Re: Multiple Levels of LMM agents (was: RE:
> [mobile-ip] Revised
> Localized Mobility Management Requirement s)
>
>
> Hi Charlie,
>   I have a feeling that you are talking about regreg6. Is
> regreg6 still a
> candidate protocol, i.e. after the requirements will the
> protocol selection
> process for LMM  restart?
>
> Charlie Perkins wrote:
>
> >  Furthermore,
> > the upgrade is not a forklift upgrade.  One can put in
> regional-aware routers
> > wherever they are needed, and not disturb the other configuration.
> >
> > We know that the code to do multiple levels is small, and that the
> > protocol isn't bad at all.
> >
> > Regards,
> > Charlie P.
>
> Regards,
>
> --
> Behcet
>

------_=_NextPart_001_01C0D25B.6F7C2E00-- From owner-mobile-ip@sunroof.eng.sun.com Tue May 1 13:35:38 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05116 for ; Tue, 1 May 2001 13:35:37 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27959; Tue, 1 May 2001 10:35:03 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA15448; Tue, 1 May 2001 10:34:55 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41HX8IM001840 for ; Tue, 1 May 2001 10:33:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41HX7qf001839 for mobile-ip-dist; Tue, 1 May 2001 10:33:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41HWwIM001832 for ; Tue, 1 May 2001 10:32:59 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA29258 for ; Tue, 1 May 2001 10:32:54 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA14575 for ; Tue, 1 May 2001 11:55:28 -0600 (MDT) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f41HWxg05370 for ; Tue, 1 May 2001 12:32:59 -0500 (CDT) Received: from daebh01nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 1 May 2001 12:32:52 -0500 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Tue, 1 May 2001 12:32:52 -0500 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B03213938@daeis07nok> To: mobile-ip@sunroof.eng.sun.com Cc: carl.williams@eng.sun.com Subject: [mobile-ip] LMM Requirements Date: Tue, 1 May 2001 12:32:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: We've asked Carl Williams to pull together the requirements for LMM that have been agreed upon here into an I-D with some explanatory text. Thanks to Carl for taking on this responsibility. We hope to see them in an I-D form in 2-3 weeks. If you would like to provide additional requirements, please feel free to send them to Carl or to discuss them on the list. We would also like some feedback on whether or how having a particular draft on LMM as a working group item effects the requirements making process. Are there example requirements that might be considered if the HMIP draft were not already in place as the working group draft? Basavaraj Phil From owner-mobile-ip@sunroof.eng.sun.com Tue May 1 13:51:34 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05883 for ; Tue, 1 May 2001 13:51:33 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10770; Tue, 1 May 2001 10:51:14 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA03837; Tue, 1 May 2001 10:51:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41HliIM001871 for ; Tue, 1 May 2001 10:47:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41Hlif7001870 for mobile-ip-dist; Tue, 1 May 2001 10:47:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41HlZIM001862 for ; Tue, 1 May 2001 10:47:35 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA18911 for ; Tue, 1 May 2001 10:47:34 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA03274 for ; Tue, 1 May 2001 10:47:29 -0700 (PDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Tue, 1 May 2001 13:41:21 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] LMM Requirements Date: Tue, 1 May 2001 13:41:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi, it's important that discussion of the requirements does take place on the list so everyone is informed. Phil > -----Original Message----- > From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] > Sent: Tuesday, May 01, 2001 1:33 PM > To: mobile-ip@sunroof.eng.sun.com > Cc: carl.williams@eng.sun.com > Subject: [mobile-ip] LMM Requirements > > > We've asked Carl Williams to pull together the requirements > for LMM that > have > been agreed upon here into an I-D with some explanatory text. > Thanks to > Carl for > taking on this responsibility. We hope to see them in an I-D > form in 2-3 > weeks. > > If you would like to provide additional requirements, please > feel free to > send them > to Carl or to discuss them on the list. > > We would also like some feedback on whether or how having a > particular draft > on LMM > as a working group item effects the requirements making > process. Are there > example requirements that might be considered if the HMIP > draft were not > already in place as the working group draft? > > Basavaraj > Phil > From owner-mobile-ip@sunroof.eng.sun.com Tue May 1 13:55:40 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05967 for ; Tue, 1 May 2001 13:55:39 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14400; Tue, 1 May 2001 10:54:59 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21036; Tue, 1 May 2001 10:54:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41HrSIM001889 for ; Tue, 1 May 2001 10:53:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41HrS9e001888 for mobile-ip-dist; Tue, 1 May 2001 10:53:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41HrKIM001881 for ; Tue, 1 May 2001 10:53:20 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA10430 for ; Tue, 1 May 2001 10:53:19 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA25843 for ; Tue, 1 May 2001 12:15:53 -0600 (MDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Tue, 1 May 2001 13:47:10 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Protocol Decision Fixed? Date: Tue, 1 May 2001 13:47:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi, a lot of good stuff snipped. Just to comment on a couple of points. Phil > >"What is different now from when we made the decision?" or > >"What do we know now that we didn't know when we made the decision?" > > 1) People are paying attention. They were not when the > desision was made. > The volume of traffic on this issue, even if most was > generated by a few > highly interested participants, has been quite large in the last > few weeks. This is an indication that there is much interest in the > protocol, which was not the case last summer. I would agree with this assessment. > > 2) Some of the requirements that have been brought up by interested > participants are difficult or not possible to satisfy with the > working group draft. While it may be possible to modify the working > group draft to match the requirements, it seems only fair to open > up the protocol decision to other ideas that might better match > the requirements, rather than requiring a retrofit. Could you spell this out some more? And are there requirements that are not being discussed because the working group already has one draft as a working group item? > My suggestion is to open up the protocol selection phase, allow PhilN > to submit his draft. Anybody is free at any time to present a draft of a proposed solution. It's up to the presenter to make the case that this should be pursued by the working group and up to the working group to decide what it wants to do. We do want to reduce churn, but the traffic on this topic indicates that there are members of the working group open to reconsidering the protocol choice. > From owner-mobile-ip@sunroof.eng.sun.com Tue May 1 14:45:36 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07307 for ; Tue, 1 May 2001 14:45:35 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA19977; Tue, 1 May 2001 11:42:00 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA03465; Tue, 1 May 2001 11:41:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41Ie6IM001962 for ; Tue, 1 May 2001 11:40:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41Ie6Yc001961 for mobile-ip-dist; Tue, 1 May 2001 11:40:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41IdvIM001954 for ; Tue, 1 May 2001 11:39:57 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21382 for ; Tue, 1 May 2001 11:39:56 -0700 (PDT) Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA20901 for ; Tue, 1 May 2001 11:39:55 -0700 (PDT) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id NAA21491 for ; Tue, 1 May 2001 13:39:55 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f41IdsC02223 for ; Tue, 1 May 2001 13:39:54 -0500 (CDT) Message-ID: <3AEF0410.FD2A00BF@usa.alcatel.com> Date: Tue, 01 May 2001 13:44:32 -0500 From: Behcet Sarikaya Organization: Alcatel USA X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] LMM Requirements References: <7B5C0390ACE7D211BC9C0008C7EABA2B03213938@daeis07nok> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit This is the requirements fashion. Throw away a few items and then collect them in I-D format and get them RFCed. IMHO it is for nothing. but probably seamoby mania. Remember many protocols including Mobile IP were developed with no requirements RFCs. I would call upon a stop on this instead. HMIP people already issued a new version. The stage is there for any competing protocols. Basavaraj.Patil@nokia.com wrote: > We've asked Carl Williams to pull together the requirements for LMM that > have > been agreed upon here into an I-D with some explanatory text. Thanks to > Carl for > taking on this responsibility. We hope to see them in an I-D form in 2-3 > weeks. > > If you would like to provide additional requirements, please feel free to > send them > to Carl or to discuss them on the list. > > We would also like some feedback on whether or how having a particular draft > on LMM > as a working group item effects the requirements making process. Are there > example requirements that might be considered if the HMIP draft were not > already in place as the working group draft? > > Basavaraj > Phil My 0.002 cents. --behcet From owner-mobile-ip@sunroof.eng.sun.com Tue May 1 14:46:36 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07334 for ; Tue, 1 May 2001 14:46:35 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26183; Tue, 1 May 2001 11:46:15 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA22679; Tue, 1 May 2001 11:46:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41IieIM001979 for ; Tue, 1 May 2001 11:44:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41IidHF001978 for mobile-ip-dist; Tue, 1 May 2001 11:44:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41IiVIM001971 for ; Tue, 1 May 2001 11:44:31 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08885 for ; Tue, 1 May 2001 11:44:25 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA10267 for ; Tue, 1 May 2001 11:44:24 -0700 (PDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Tue, 1 May 2001 14:38:17 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] LMM Requirements Date: Tue, 1 May 2001 14:38:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: The advantage in having an I-D that documents the requirements is that you can easily point to it rather than dragging a thread out of the email archives. > -----Original Message----- > From: Behcet Sarikaya [mailto:behcet.sarikaya@usa.alcatel.com] > Sent: Tuesday, May 01, 2001 2:45 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] LMM Requirements > > > This is the requirements fashion. > Throw away a few items and then collect them in > I-D format and get them RFCed. > IMHO it is for > nothing. > but probably seamoby mania. > Remember many protocols including Mobile IP were developed > with no requirements RFCs. > > I would call upon a stop on this instead. HMIP people already issued > a new version. The stage is there for any competing protocols. > > Basavaraj.Patil@nokia.com wrote: > > > We've asked Carl Williams to pull together the requirements > for LMM that > > have > > been agreed upon here into an I-D with some explanatory > text. Thanks to > > Carl for > > taking on this responsibility. We hope to see them in an > I-D form in 2-3 > > weeks. > > > > If you would like to provide additional requirements, > please feel free to > > send them > > to Carl or to discuss them on the list. > > > > We would also like some feedback on whether or how having a > particular draft > > on LMM > > as a working group item effects the requirements making > process. Are there > > example requirements that might be considered if the HMIP > draft were not > > already in place as the working group draft? > > > > Basavaraj > > Phil > > My 0.002 cents. > > --behcet > From owner-mobile-ip@sunroof.eng.sun.com Tue May 1 15:43:40 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08726 for ; Tue, 1 May 2001 15:43:40 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA16943; Tue, 1 May 2001 12:42:14 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA21698; Tue, 1 May 2001 12:41:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41JcWIM002314 for ; Tue, 1 May 2001 12:38:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41JcWjF002313 for mobile-ip-dist; Tue, 1 May 2001 12:38:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41JcCIM002306 for ; Tue, 1 May 2001 12:38:20 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA15921 for ; Tue, 1 May 2001 12:37:21 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA25945 for ; Tue, 1 May 2001 13:59:57 -0600 (MDT) 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 MAA28748 for ; Tue, 1 May 2001 12:37:19 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f41JbH127048 for ; Tue, 1 May 2001 12:37:17 -0700 X-mProtect: Tue, 1 May 2001 12:37:17 -0700 Nokia Silicon Valley Messaging Protection Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpd03JszP; Tue, 01 May 2001 12:37:10 PDT Message-ID: <3AEF1068.7A50041F@iprg.nokia.com> Date: Tue, 01 May 2001 12:37:12 -0700 From: Theo Pagtzis Organization: UCL/NOKIA X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386) X-Accept-Language: el, en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] LMM Requirements References: <7B5C0390ACE7D211BC9C0008C7EABA2B03213938@daeis07nok> <3AEF0410.FD2A00BF@usa.alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Bechet, I don't agree..I think the requirements document is probably the best solution for convergence...we do not want to get IETF a battlefield for competition..it is a protocol standardisation effort... rather than putting the protocol like roosters in a fight to kill each other and see who survives...I think we will gain some light years by working together..in hopefully all respects.. things will only benefit from such a draft. If the constituency feels better I would suggest that such drafts acknowledge people's participation either by names or by whatever..as their bandwidth is offered towards solving a problem.. We need to maintain unity on forward progress and look at _all_ solutions to bring some sound core (in particular LMM) specification that can sit on the Net as solid as a rock. We cannot waste precious bandwidth at a time where the .com community feels significantly _deflated_ (perhaps for a reason?). While many protocols were developed without a requirement RFC it becomes clear that when multiple solutions of some weight arise there is an imperative need to strike convergence..and unity in the constituency. The requirements effort is either an initial approach towards solution or over multiple protocol solutions a rule base that the union of the proposed protocols manifest (it is only fair after so much work). The latter although a little longer winded gives actually a much better perspective. Theo UCL/ Mobile Systems Behcet Sarikaya wrote: > This is the requirements fashion. > Throw away a few items and then collect them in > I-D format and get them RFCed. > IMHO it is for > nothing. > but probably seamoby mania. > Remember many protocols including Mobile IP were developed > with no requirements RFCs. > > I would call upon a stop on this instead. HMIP people already issued > a new version. The stage is there for any competing protocols. > > Basavaraj.Patil@nokia.com wrote: > > > We've asked Carl Williams to pull together the requirements for LMM that > > have > > been agreed upon here into an I-D with some explanatory text. Thanks to > > Carl for > > taking on this responsibility. We hope to see them in an I-D form in 2-3 > > weeks. > > > > If you would like to provide additional requirements, please feel free to > > send them > > to Carl or to discuss them on the list. > > > > We would also like some feedback on whether or how having a particular draft > > on LMM > > as a working group item effects the requirements making process. Are there > > example requirements that might be considered if the HMIP draft were not > > already in place as the working group draft? > > > > Basavaraj > > Phil > > My 0.002 cents. > > --behcet From owner-mobile-ip@sunroof.eng.sun.com Tue May 1 16:29:59 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09604 for ; Tue, 1 May 2001 16:29:58 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA07719; Tue, 1 May 2001 13:29:17 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA26575; Tue, 1 May 2001 13:29:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41KRVIM002426 for ; Tue, 1 May 2001 13:27:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41KRUx8002425 for mobile-ip-dist; Tue, 1 May 2001 13:27:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41KRMIM002418 for ; Tue, 1 May 2001 13:27:22 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id NAA07640; Tue, 1 May 2001 13:27:21 -0700 (PDT) Message-Id: <200105012027.NAA07640@heliopolis.eng.sun.com> Date: Tue, 1 May 2001 13:27:21 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] LMM Requirements To: mobile-ip@sunroof.eng.sun.com Cc: carl.williams@eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: sPmABQdGLZRMsGs+aQEYuA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Raj, >We would also like some feedback on whether or how having a particular draft >on LMM >as a working group item effects the requirements making process. Are there >example requirements that might be considered if the HMIP draft were not >already in place as the working group draft? > > Well, certainly the hierarchy requirement, which has been hotly debated, might be already in place, or, at least, we might have some kind of compromise language that reflected what the hierarchy requirement is trying to get at, namely some way of improving signalling latency without changing the externally visible care of address. The status of this requirement is still up in the air, and one of the co-authors of the working group draft has been the strongest opponent. Persumably, there might be more flexibility shown were the draft not already a working group item. jak From owner-mobile-ip@sunroof.eng.sun.com Tue May 1 16:51:08 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09973 for ; Tue, 1 May 2001 16:51:07 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA28948; Tue, 1 May 2001 13:50:36 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA02076; Tue, 1 May 2001 13:50:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41KmnIM002467 for ; Tue, 1 May 2001 13:48:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41Kmmpi002466 for mobile-ip-dist; Tue, 1 May 2001 13:48:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41KmeIM002459 for ; Tue, 1 May 2001 13:48:40 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA17878 for ; Tue, 1 May 2001 13:48:34 -0700 (PDT) Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA05949 for ; Tue, 1 May 2001 15:11:23 -0600 (MDT) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id PAA14774 for ; Tue, 1 May 2001 15:48:32 -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 f41KmWp18402 for ; Tue, 1 May 2001 15:48:32 -0500 (CDT) Message-ID: <3AEF222F.74A61D28@usa.alcatel.com> Date: Tue, 01 May 2001 15:53:04 -0500 From: Behcet Sarikaya Organization: Alcatel USA X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] LMM Requirements References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit But Phil you already posted the final form of the requirements in one of your earlier emails. One can always refer to that online document. Theo: I agree but please agree to it that it IS wishful thinking. Phil Roberts wrote: > The advantage in having an I-D that documents the requirements is that you > can easily point to it rather than dragging a thread out of the email > archives. --behcet From owner-mobile-ip@sunroof.eng.sun.com Tue May 1 16:57:14 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10073 for ; Tue, 1 May 2001 16:57:14 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA21138; Tue, 1 May 2001 13:57:01 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA15243; Tue, 1 May 2001 13:56:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41Ks7IM002484 for ; Tue, 1 May 2001 13:54:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41Ks7jU002483 for mobile-ip-dist; Tue, 1 May 2001 13:54:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41KrwIM002476 for ; Tue, 1 May 2001 13:53:59 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA08527 for ; Tue, 1 May 2001 13:53:55 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA02233 for ; Tue, 1 May 2001 13:53:54 -0700 (PDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Tue, 1 May 2001 16:47:47 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] LMM Requirements Date: Tue, 1 May 2001 16:47:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: The I-D repository is a little easier to use to find things. There is probably also some surrounding context needed and I didn't follow the standards terminology of MUST, SHOULD, etc. so there is work that is to be done. > -----Original Message----- > From: Behcet Sarikaya [mailto:behcet.sarikaya@usa.alcatel.com] > Sent: Tuesday, May 01, 2001 4:53 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] LMM Requirements > > > But Phil you already posted the final form of the requirements in > one of your earlier emails. One can always refer to that > online document. > > Theo: I agree but please agree to it that it IS wishful thinking. > > Phil Roberts wrote: > > > The advantage in having an I-D that documents the > requirements is that you > > can easily point to it rather than dragging a thread out of > the email > > archives. > > --behcet > From owner-mobile-ip@sunroof.eng.sun.com Tue May 1 16:59:36 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10119 for ; Tue, 1 May 2001 16:59:35 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06642; Tue, 1 May 2001 13:59:13 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA09836; Tue, 1 May 2001 13:58:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41Kv2IM002494 for ; Tue, 1 May 2001 13:57:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41Kv1tb002493 for mobile-ip-dist; Tue, 1 May 2001 13:57:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41KuqIM002486 for ; Tue, 1 May 2001 13:56:53 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA03720 for ; Tue, 1 May 2001 13:56:51 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id NAA13992 for ; Tue, 1 May 2001 13:56:49 -0700 (PDT) Received: (qmail 4958 invoked by uid 500); 1 May 2001 20:43:33 -0000 Date: Tue, 1 May 2001 13:43:33 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] LMM Requirements Message-ID: <20010501134333.A4672@charizard.diameter.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from PRoberts@MEGISTO.com on Tue, May 01, 2001 at 02:38:16PM -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Tue, May 01, 2001 at 02:38:16PM -0400, Phil Roberts wrote: > The advantage in having an I-D that documents the requirements is that you > can easily point to it rather than dragging a thread out of the email > archives. and it is much easier to evaluate concensus when there is a document on which a chair can do a last call. This is, after all, how many IETF WG work. [snip] > > This is the requirements fashion. > > Throw away a few items and then collect them in > > I-D format and get them RFCed. No one said anything about actually publishing the document. The idea is that a chair can do a last call on a document. It is a hell of alot harder to do a last call on an e-mail. The IETF doesn't work that way. > > IMHO it is for > > nothing. I guess we are all entitled to our opinions... > > but probably seamoby mania. hmmm... I have resisted the temptation to reply to your other seamoby management basing e-mails, but perhaps I should defend myself now in order to minimize the possibility of any future flames you seem to enjoy writing. Given that I have been contributing in the IETF a hell of alot longer than you have, I have seen many WGs document requirements prior to actual protocol design. In fact, I would point you to probably the most important of requirement documents, RFC 1122 and RFC1123, which are in fact full standards. Doing a quick search in RFC archives, I found 50 published requirements RFCs, so this isn't seamoby mania. Now, for those of us that are willing to have a WG review, and modify, a particular proposal, this isn't a problem. We in fact prefer to create a protocol that has WG concensus, and therefore will have wider deployment (and perhaps even applicability). Then there are those that prefer that WGs simply rubber stamp their protocol... > > Remember many protocols including Mobile IP were developed > > with no requirements RFCs. Remember that the protocol work was initiated over 8 years ago. Things change. Networks and protocol become more complex. Furthermore, people have found many things that they would like to see in MIP, and we have also found some deficiencies. Don't get me wrong, I do like Mobile IP, but a protocol design phase without requirements is NOT necessarily something that we should all strive for. Basic protocol design, IMHO. PatC From owner-mobile-ip@sunroof.eng.sun.com Tue May 1 17:20:47 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10530 for ; Tue, 1 May 2001 17:20:47 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA29719; Tue, 1 May 2001 14:15:53 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA20214; Tue, 1 May 2001 14:15:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41LDKIM002523 for ; Tue, 1 May 2001 14:13:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41LDK2A002522 for mobile-ip-dist; Tue, 1 May 2001 14:13:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41LDBIM002515 for ; Tue, 1 May 2001 14:13:12 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA19661 for ; Tue, 1 May 2001 14:13:09 -0700 (PDT) Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA18676 for ; Tue, 1 May 2001 14:13:08 -0700 (PDT) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id QAA18734 for ; Tue, 1 May 2001 16:13:07 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f41LD7C06417 for ; Tue, 1 May 2001 16:13:07 -0500 (CDT) Message-ID: <3AEF27F2.2C6965E7@usa.alcatel.com> Date: Tue, 01 May 2001 16:17:38 -0500 From: Behcet Sarikaya Organization: Alcatel USA X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] LMM Requirements References: <20010501134333.A4672@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I try always to write the correct things or objective observations, not flames whatever that means. Pat Calhoun wrote: > hmmm... I have resisted the temptation to reply to your other seamoby > management basing e-mails, but perhaps I should defend myself now in order > to minimize the possibility of any future flames you seem to enjoy writing. --behcet From owner-mobile-ip@sunroof.eng.sun.com Tue May 1 18:05:16 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11267 for ; Tue, 1 May 2001 18:05:15 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA01967; Tue, 1 May 2001 15:04:52 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA02364; Tue, 1 May 2001 15:04:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41M2WIM002572 for ; Tue, 1 May 2001 15:02:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41M2Wux002571 for mobile-ip-dist; Tue, 1 May 2001 15:02:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41M2NIM002564 for ; Tue, 1 May 2001 15:02:23 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA26221 for ; Tue, 1 May 2001 15:02:23 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA29894 for ; Tue, 1 May 2001 15:02:21 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f41M0OH03139 for ; Tue, 1 May 2001 15:00:47 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AEW37402; Tue, 1 May 2001 15:01:46 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA13622; Tue, 1 May 2001 15:01:46 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15087.12873.982988.191613@thomasm-u1.cisco.com> Date: Tue, 1 May 2001 15:01:45 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Some thoughts on BAKE and MIPv6 security In-Reply-To: References: <3AD48002.E21502C2@iprg.nokia.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Lars, I hope that after all of the dust settles, we still have a way to secure binding updates with strong authentication when the conditions are right (ie, when it is reasonable to assume some sort of distributed keying system). That said, it would be nice if we had a "secure-enough" mechanism for when that's not practical or desirable. In the home agent cookies draft, I tried to consider what would happen if the wireless link was unprotected. When thinking about how to protect against it, I ran into some issues with NAT's which seemed pretty pathological. After a while, I gave up for the time being since the entire scenario seemed pretty out in the weeds: if you have a first hop which is eavesdroppable where there are potential attackers, you have a pretty basic problem which should be addressed at L2. I'm hoping that the 802.1x folks are trying to address this, as well as the 3G folks because the problems with this scenario are certainly not limited to binding updates. Mike Lars Henrik Petander writes: > Hi all! > > Since BAKE allows active attacks on local links using a broadcast medium > that redirect the traffic to the attackers machine, it allows a similar > attack against CNs as a fake icmp redirect. A good example of a vulnerable > host is a MN in its home network, which is likely to be wireless and > eavesdroppable. > > Although this vulnerability already exists in IPv4 it might lead to > the disabling of MIPv6 CN functionality in many nodes in the same way as > ICMP redirects often are disabled today. Do we really want to limit the > use of full CN functionality to trusted links? > > I am afraid that any unauthenticated key exchange is likely to suffer from > the same (or a similar) vulnerability. Thus it would probably be a good > idea to make strong authentication of the peers possible by using public > key cryptography, which would allow them to retrieve each other's > certificates from DNS or some other repository and authenticate each other > strongly. In absence of a PKI they could always revert to unauthenticated > key establishment, the use of which should be configurable in CNs. > > > Regards, > > Henrik Petander > From owner-mobile-ip@sunroof.eng.sun.com Tue May 1 18:56:58 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11950 for ; Tue, 1 May 2001 18:56:57 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA07315; Tue, 1 May 2001 15:55:26 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA02723; Tue, 1 May 2001 15:55:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41Ms2IM002661 for ; Tue, 1 May 2001 15:54:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41Ms1dC002660 for mobile-ip-dist; Tue, 1 May 2001 15:54:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41MruIM002653 for ; Tue, 1 May 2001 15:53:57 -0700 (PDT) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA16321 for ; Tue, 1 May 2001 18:53:53 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id SAA09735 for mobile-ip@sunroof.eng.sun.com; Tue, 1 May 2001 18:54:06 -0400 (EDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41MBgIM002586 for ; Tue, 1 May 2001 15:11:42 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA23324 for ; Tue, 1 May 2001 15:11:42 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11126 for ; Tue, 1 May 2001 15:11:41 -0700 (PDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f41MBeN05770 for ; Wed, 2 May 2001 00:11:40 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed May 02 00:11:40 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 2 May 2001 00:11:44 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBDDF@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Final(?) Cut on LMM Requirements Date: Wed, 2 May 2001 00:11:39 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > => I don't really undersand your suggestion to not change the CoA. > The Fast Handoff draft is built around the fact that the MN will > change its CoA. There is one case where that fails (DAD for the > new CoA) and the MN keeps the same address. But this is > an error case and 99.99 % of the time it won't happen. > > [MJ] I know that fast handoff solution is built around that assumption, and I am questioning that very basic assumption. I am saying that it is LMM solution's forte to decide whether handing over to new AR should involve new address assignment, especially within an AD. Hence, fast handoff solution should be flexible in handling this situation. The question is why fast handoff always assume change of address? > => Well That's what MIP does. MIP manages the change in CoA. > Now, instead of always assuming new address assignment it can provide in its signaling following options: > > 1. No new address assignment > 2. Autoconfiguration, hence asking new AR to run DAD on behalf of MN > 3. Stateful address assignment > > This will make fast handoff solution quite flexible and capable of being defacto standard handover signaling for any LMM. > => I think it already works with LMM. Both scenarios in the Fast Handoff draft can work with an LMM solution. At least with HMIPv6 I don't see any problem. Based on this requirement we were going to add a section in the draft to show that this interworking is possible. But I'm not sure what the aim of fixing the address is. Anyway, my point is if you're saying this to make it easier for FH to work with LMM, I think both cases would work whether the address changes or not. > Although, I am making this statement but with one caveat that I don't know how fast handoff and CT will work together. I think this discussion should be moved to fast handoff design team mailing list, but my understanding is that it is closed. > => I think we can discuss it on this list. The design team's list hasn't been used for a long time now. > BTW, Hesham how did you get this 99.99% reliability number, through some simulation? > => No, I was trying to explain that it is a very rare probability that a collision would occur considering the 2^64 different IDs in IPv6 in case a random number was used or the probability of an L2 device vendor to reuse the same MAC address. Just making a point, I hope no one starts a simulation on this one too ;) Hesham > Hesham > From owner-mobile-ip@sunroof.eng.sun.com Wed May 2 03:43:43 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03059 for ; Wed, 2 May 2001 03:43:43 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA07892; Wed, 2 May 2001 00:41:51 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA21181; Wed, 2 May 2001 00:41:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f427duIM003175 for ; Wed, 2 May 2001 00:39:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f427duZV003174 for mobile-ip-dist; Wed, 2 May 2001 00:39:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f427dkIM003167 for ; Wed, 2 May 2001 00:39:47 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA09410 for ; Wed, 2 May 2001 00:39:40 -0700 (PDT) Received: from ws130.nomadiclab.com (ws130.nomadiclab.com [195.165.196.130]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA26510 for ; Wed, 2 May 2001 00:39:36 -0700 (PDT) Received: from ws34.nomadiclab.com (ws34.nomadiclab.com [195.165.196.34]) by ws130.nomadiclab.com (Postfix) with ESMTP id 483EF72504 for ; Wed, 2 May 2001 10:39:10 +0300 (EEST) Received: from nomadiclab.com (ws146.nomadiclab.com [195.165.196.146]) by ws34.nomadiclab.com (Postfix) with ESMTP id 0CA09BA2F for ; Wed, 2 May 2001 10:39:10 +0300 (EEST) Message-ID: <3AEFB8AB.1D180B1F@nomadiclab.com> Date: Wed, 02 May 2001 08:35:07 +0100 From: Pekka Nikander X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en,fi MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Some thoughts on BAKE and MIPv6 security References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit [Sorry for the late reply.] Henrik, I am covering just a couple of points. > > MN's home network is indeed vulnerable, since being located there > > allows an attacker to launch an active attack against an arbitrary CN. > I meant MN in the sense of it being just a CN while it is in its home > network. For CNs that are also MNs and away from home, the next revision of BAKE will contain protection. The basic means is to use a reverse ESP tunnel from the CN to its home agent, as suggested by Francis Dupont. Right now we are NOT planning to support insecure home links. IMHO, if your "natural" home link is insecure, you most probably should not use that as a home link at all, but have a box to act as a virtual home link for a large number of MNs. That would certainly be a secure home link, being inside one box :-) The only drawback in that scheme is that your mobiles will always be away-from-home, but maybe you should consider that a benefit :-) ..... > > from the given design constraints: do no harm (or be as safe as IPv4 is) > > and do not require any heavy computations. The latter requirement > > basically made all PK operations and D-H infeasible. > > Probably the MN's will use SSL, SSH or other protocols requiring > similar operations in any case. BAKE is now the only proposed solution > fully without public key operations. Well, I think that there will be very different MNs, and very different CNs. Since being a CN is aimed to be a requirement for anyone (e.g. light bulbs and computers embedded in clothing and shoes), we cannot mandate D-H or public key operations. I am working to see how to have D-H and PK as an optional feature in BAKE, but getting things to work out nicely it not so easy. And I want any D-H or PK operations in BAKE to fit nicely in, meaning that a) there must not be new DoS vulnerabilities b) there must be the _minimum_ amount of options. Reaching those goals is not so easy. > > Authentication and public key operations are a different issue. > > I think that something like CAM/SUCV/PBK-ADDRESSES could and > > probably should be added to BAKE as an optional feature. I just > > haven't had enough time to properly think about that yet. If you > > have any suggestions of how to do that, please share them. > > That sounds complex. I don't think it necessarily needs to be that complex. What I am trying to reach (I don't know if I can) is a protocol that has exactly one option: run without D-H and PK (the current BAKE), or run with both D-H and PK. In the latter case the keys can either come from some CAM/SUCV/PBK-ADDRESSES like mechanism, or from locally trusted certificates or some other locally trusted means. The policy will not be so simple, if you want to support all the alternatives. But the protocol itself MUST be as simple as possible. > > Please remember the underlying authorization problem. This question > > is really not only about knowing who your peer is, but also making > > sure that your peer is indeed authorized to create bindings for the > > given Home Address. > > Yes, that is true and I think that DNS provides a nice way of doing this. > Although with out deployment of DNSSec this approach is > applicable only if MN and CN use the same DNS server. If you go ahead and analyze a little bit what using secure reverse DNS would require in practise, you may realize that it is not necessarily that nice. Yes, it is the "right" PKI, meaning that if we use a PKI for authenticating binding updates, we definitely should use secure reverse DNS. But, just to amuse you, take one realistic example with two arbitrary hosts and try to figure out a) how many DNS queries you need b) how many SIG verifications you need The numbers are not so nice... --Pekka From owner-mobile-ip@sunroof.eng.sun.com Wed May 2 03:55:36 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03263 for ; Wed, 2 May 2001 03:55:36 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA11444; Wed, 2 May 2001 00:55:04 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA10413; Wed, 2 May 2001 00:54:52 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f427qDIM003217 for ; Wed, 2 May 2001 00:52:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f427qCSs003216 for mobile-ip-dist; Wed, 2 May 2001 00:52:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f427q1IM003209 for ; Wed, 2 May 2001 00:52:02 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA21921 for ; Wed, 2 May 2001 00:52:01 -0700 (PDT) From: hspark@etri.re.kr Received: from cms3.etri.re.kr (cms3.etri.re.kr [129.254.16.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA15643 for ; Wed, 2 May 2001 02:17:11 -0600 (MDT) Received: by cms3.etri.re.kr with Internet Mail Service (5.5.2653.19) id ; Wed, 2 May 2001 16:51:22 +0900 Message-ID: <766FA1FC5C2AD511B3C800D0B7A8AC4A230D89@cms3.etri.re.kr> To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Questions about Route Optimization in MIPv4 Date: Wed, 2 May 2001 16:51:21 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D2DC.AD6D1860" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C0D2DC.AD6D1860 Content-Type: text/plain; charset="iso-8859-1" Thanks a lot, Glenn My comments below... -----Original Message----- From: Glenn Morrow [mailto:gmorrow@nortelnetworks.com] Sent: Wednesday, May 02, 2001 1:07 AM To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Questions about Route Optimization in MIPv4 Hyun, Some good points - comments below. -----Original Message----- From: hspark@etri.re.kr [mailto:hspark@etri.re.kr] Sent: Monday, April 30, 2001 9:29 PM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Questions about Route Optimization in MIPv4 Hello, All ... I have some questions about Route Optimization in MIP... It is somewhat an old story... In IMHP (Internet Mobile Host Protocol), the origin of Route Optimization in MIP, there is a notion of "Cache Agent" that is a intermediate router capable of caching a binding for MN... Why was "Cache Agent" excluded from Route Optimization in MIP I-D when adopted by WG ? [Morrow, Glenn ] I do not know why. I'd like to know too. It seems to me that the cache is better suited to be implemented on a purpose-built device than a web server for the majority of Internet Traffic. [Hyun Seo] I agree with you... As you stated, if a "Cache Agent" or "Correspondent Agent" (the name is not a problem) realizable, it is possible to provide route optimization without requiring any change to CNs in the Internet... And security association for authentication of Binding Update message is efficiently managed... But I think the problem is "HOW" to make "Cache Agent" realizable... IMHO, there is no perfect solution for that yet... lmk draft is a good candidate, but NOT every router in the present Internet does processing IP router alert option... And there are some security concerns over "intercepting Binding Update or Reg. Request midway"... Am I right ? I think R+A burdens intermediate routers with bulky datagram discrimination (Is it IP or IP2 ?)... Does anyone have another nice approach ? Thanks in advance... Is it not workable ? And if Yes, Why ? cf. "Intercepting Location Updates" by Cheng-Yin Lee, et al. attempted a similar work... IMHO, it was a good conception. But that internet-draft was rejected at IETF 49... [Morrow, Glenn ] This draft was trying to develop a framework for providing location privacy yet still allowing the simultaneous operation of route optimization. It also dealt with hierarchy, security. Tunneling or double NAT could be used as options. The draft used the MIP protocol as is. I do not believe the draft was "rejected" by the WG. There was no consensus check ever made for accepting or rejecting the draft. Any minutes indicating rejection are in question in my opinion. One critic of this framework was that it was not a new idea and the WG had previously rejected the concept due to the fact that it relied on installing state in the form of per-node routes and that in working through the "redundancy" schemes of these previous solutions, the WG found some inherent flaw in terms of redundancy. I responded at critic that there was no issue with redundancy, in that if the router acting as the correspondent agent goes down the packets are again routed to the home agent where the process of binding occurs again. Another router that has connectivity to the CN becomes a correspondent agent - no service disruption at all. I honestly do not see realistic deployment scenario of route optimization on IPv4 unless we do do something like the lmk draft. It seems to me that a user is not going to want to indicate on every communication that they want to use optimization or not. It would be helpful if the persons who critic'd both of the proposals clarified just what the percieved issues are. I am certainly not satisfied with the explanations for any percieved rejection of either proposal. I don't think the problems these drafts are trying to solve are going to go away. I do not understand the stall tactics that have been used on providing this functionality. Thanks for bringing up the concept again. I would definitely like to work through any issues and arrive at a workable solution for the WG. It seems to me that the proposals should be WG documents so that the issues can be worked out by the whole group. Thanks, Glenn Another question, I have just found another work for Route Optimization... The title of Internet-Draft was "Routing optimization by a router with cache agent functionality" by Kazuhiro Okanoue I want to know about that and I tried to get that... But I couldn't find that Internet-Draft... If anyone know whereabouts of that document, please let me know where I can get it... [Morrow, Glenn ] I'd like to read this as well. [Hyun Seo] I found not a exact match but some helpful documents... IP Mobility Support with IP-Squred(IP2) Encapsulation Technique, by K. Okanoue and T. Ohsawa (IEICE Trans. Commun. Vol.E-80B, No.8) It was an internet-draft and it contains R+A notion... http://search.ieice.org/1997/pdf/b081198.pdf Okanoue's presentation at IETF 36th (June 1996) Meeting http://www.ietf.org/proceedings/96jun/area.and.wg.reports/rtg/mobileip-okano ue-optim/index.html I wish it could be helpful... Thanks a lot... ------_=_NextPart_001_01C0D2DC.AD6D1860 Content-Type: text/html; charset="iso-8859-1" Questions about Route Optimization in MIPv4
Thanks a lot, Glenn
 
My comments below...
 
 
-----Original Message-----
From: Glenn Morrow [mailto:gmorrow@nortelnetworks.com]
Sent: Wednesday, May 02, 2001 1:07 AM
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Questions about Route Optimization in MIPv4

Hyun,
 
Some good points - comments below.
-----Original Message-----
From: hspark@etri.re.kr [mailto:hspark@etri.re.kr]
Sent: Monday, April 30, 2001 9:29 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Questions about Route Optimization in MIPv4

Hello, All ...

I have some questions about Route Optimization in MIP...
It is somewhat an old story...

In IMHP (Internet Mobile Host Protocol), the origin of Route Optimization in MIP,
there is a notion of "Cache Agent" that is a intermediate router capable of caching a binding for MN...
Why was "Cache Agent" excluded from Route Optimization in MIP I-D when adopted by WG ?  

[Morrow, Glenn ]

I do not know why. I'd like to know too.  It seems to me that the cache is  better suited to be implemented on a purpose-built device than a web server for the majority of Internet Traffic. 

[Hyun Seo]

I agree with you...

As you stated, if a "Cache Agent" or "Correspondent Agent" (the name is not a problem) realizable,

it is possible to provide route optimization without requiring any change to CNs in the Internet... 

And security association for authentication of Binding Update message is efficiently managed...

But I think the problem is "HOW" to make "Cache Agent" realizable...

IMHO, there is no perfect solution for that yet...

lmk draft is a good candidate, but NOT every router in the present Internet does processing IP router alert option...

And there are some security concerns over "intercepting Binding Update or Reg. Request  midway"...

Am I right ?

I think R+A burdens intermediate routers with bulky datagram discrimination (Is it IP or IP2 ?)...

Does anyone have another nice approach ?

Thanks in advance...

          Is it not workable ? And if Yes, Why ? 
          cf. "Intercepting Location Updates" by Cheng-Yin Lee, et al. attempted a similar work... 
                IMHO, it was a good conception. But that internet-draft was rejected at IETF 49...

[Morrow, Glenn ] 

This draft was trying to develop a framework for providing location privacy yet still allowing the simultaneous operation of route optimization.   It also dealt with hierarchy, security. Tunneling or double NAT could be used as options.

The draft used the MIP protocol as is. I do not believe the draft was "rejected" by the WG. There was no consensus check ever made for accepting or rejecting the draft. Any minutes indicating rejection are in question in my opinion.

One critic of this framework was that it was not a new idea and the WG had previously rejected the concept due to the fact that it relied on installing state in the form of per-node routes and that in working through the "redundancy" schemes of these previous solutions, the WG found some inherent flaw in terms of redundancy.

I responded at critic that there was no issue with redundancy, in that if the router acting as the correspondent agent goes down the packets are again routed to the home agent where the process of binding occurs again. Another router that has connectivity to the CN becomes a correspondent agent - no service disruption at all.

I honestly do not see realistic deployment scenario of route optimization on IPv4 unless we do do something like the lmk draft.  It seems to me that a user is not going to want to indicate on every communication that they want to use optimization or not.

It would be helpful if the persons who critic'd both of the proposals clarified just what the percieved issues are. I am certainly not satisfied with the explanations for any percieved rejection of either proposal.

I don't think the problems these drafts are trying to solve are going to go away. I do not understand the stall tactics that have been used on providing this functionality.

Thanks for bringing up the concept again. I would definitely like to work through any issues and arrive at a workable solution for the WG. It seems to me that the proposals should be WG documents so that the issues can be worked out by the whole group.

Thanks,

Glenn

Another question,
I have just found another work for Route Optimization...
The title of Internet-Draft was
        "Routing optimization by a router with cache agent functionality"
        <draft-okanoue-mobileip-R+A-00.txt> by Kazuhiro Okanoue
I want to know about that and I tried to get that...
But I couldn't find that Internet-Draft...
If anyone know whereabouts of that document, please let me know where I can get it...
[Morrow, Glenn ] I'd like to read this as well.  

[Hyun Seo] I found not a exact match but some helpful documents...  

IP Mobility Support with IP-Squred(IP2) Encapsulation Technique, by K. Okanoue and T. Ohsawa (IEICE Trans. Commun. Vol.E-80B, No.8)

It was an internet-draft and it contains R+A notion...

http://search.ieice.org/1997/pdf/b081198.pdf  

Okanoue's presentation at IETF 36th (June 1996) Meeting
 
 
I  wish it could be helpful...
 
Thanks a lot...
------_=_NextPart_001_01C0D2DC.AD6D1860-- From owner-mobile-ip@sunroof.eng.sun.com Wed May 2 04:26:24 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03709 for ; Wed, 2 May 2001 04:26:23 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA20133; Wed, 2 May 2001 01:25:43 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA24715; Wed, 2 May 2001 01:25:36 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f428O0IM003298 for ; Wed, 2 May 2001 01:24:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f428Nx2d003297 for mobile-ip-dist; Wed, 2 May 2001 01:23:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.france (bebop.France.Sun.COM [129.157.174.15] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f428NmIM003290 for ; Wed, 2 May 2001 01:23:49 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.france (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id KAA29436 for ; Wed, 2 May 2001 10:23:46 +0200 (MET DST) Date: Wed, 2 May 2001 10:23:46 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] Some Analysis To: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200104262301.QAA29425@heliopolis.eng.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Jim, Your analysis concludes with > But this is not possible by the inequalities in Equation 1 above. > > Thus, the signalling latency in the hierarchical case will always > be better. Assuming my brain has some remaining amount of logic processing, I think there is another possibility. Equation (1) is when you claim it makes sense to deploy an hierarchical scheme. Thus what I've think you've shown is that when it makes sense to deploy the hierarchical scheme (per your constraints) it does better than the non-hiearchical scheme. But that, depending on how you defined (1), might be a tautology - if (1) is defined (which it seems to be) to capture the case when an hierarchical scheme does well then I'm not surprised that you can show that it does well. Thus for this avenue of reasoning to be fruitful I think it needs to be done without the assumptions you call "deploying X only makes sense if". So something more akin to given a topolgy for a network and some movement patterns that might be known in advance, try to first optimally place the LMMs (and presumably the placement is different for hierarchical vs. non) and then compute the handoff delay etc. I think it would be useful to have a single example toplogy to stare at and do some guestimates to get a feel for the differences. An example of such a toplogy would be capture the fact that there are ranges of delay (a lot larger between metro areas than inside metro areas, and presumably likewise at a granularity smaller then a metro). Does anybody have some insight they can share on what this looks in practice? Erik From owner-mobile-ip@sunroof.eng.sun.com Wed May 2 06:30:12 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04896 for ; Wed, 2 May 2001 06:30:11 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA10419; Wed, 2 May 2001 03:29:56 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA01954; Wed, 2 May 2001 03:29:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42ASgIM003431 for ; Wed, 2 May 2001 03:28:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f42ASf2L003430 for mobile-ip-dist; Wed, 2 May 2001 03:28:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42ASXIM003423 for ; Wed, 2 May 2001 03:28:33 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA01918 for ; Wed, 2 May 2001 03:28:33 -0700 (PDT) Received: from p-mail2.cnet.fr (p-mail2.rd.francetelecom.fr [193.49.124.32]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id DAA23511 for ; Wed, 2 May 2001 03:28:31 -0700 (PDT) Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Wed, 2 May 2001 12:28:13 +0200 Received: from francetelecom.com (p-dico.rd.francetelecom.fr [139.100.18.135]) by p-grive.rd.francetelecom.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KD74DWCV; Wed, 2 May 2001 12:28:11 +0200 Message-ID: <3AEFE0EC.C8F7962A@francetelecom.com> Date: Wed, 02 May 2001 12:26:52 +0200 From: Jean-Michel COMBES Organization: France =?iso-8859-1?Q?T=E9l=E9com?= R&D X-Mailer: Mozilla 4.7 [fr] (WinNT; U) X-Accept-Language: fr MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Authenticating BU and PKI References: <200104301808.f3UI81HD359141@jurassic.eng.sun.com> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by patan.sun.com id DAA10419 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA04896 Alper Yegin a écrit : > > Hi, > > > > Pekka Nikander a écrit : > > > > > [Sorry for this late reply but I am way back in my mail.] > > > > > > > I read most of the solutions proposed for authenticating BU, it seems > > > > that none of you wants to use a PKI for the key distribution. > > > > > > > > I wonder why , is it a problem of scalability , computing abilities of > > > > the MN due to public key cryptography or ...? > > > > > > IMHO, experience has (almost) shown that global PKIs just don't work. > > > Local PKIs (e.g. company wide or maybe even country wide) can be made > > > to work. As far as I know, we have only one example of a reasonably > > > well working global PKI (the SSL certificate infrastructure), but > > > even that has far too many technical and trust problems. Just to > > > take one, have you ever checked how many CAs do you implicitly > > > trust once you've installed a new version of your Web browser? > > > What do you think, how many users even understand what are the > > > security CA settings in your web browser (provided that they can > > > open the right configuration panel)? > > > > > > In this particular case (authenticating BUs), secure reverse > > > DNS would be the "right" PKI for the purpose. However, getting > > > it running seems like quite an obstackle, and even if we had it, > > > authenticating a random MN > > > > JMC : > > I think you wanted to say 'random CN' > > > > > would be quite expensive in terms > > > of the number of needed DNS queries and signature verifications. > > > > > > Just to clarify: A simple infrastructure with some global CA > > > providing simple certificates is not enough and/or feasible. The > > > certificate must include the home address, and the issuer of > > > the certificate must be authorized to issue certificates > > > concerning that particular home address, etc. > > > > JMC : > > A possible solution would be to use the HA. > > Explanation : > > When the MN receives tunneled packets from its HA, the MN should send BU to > > the CN (MIPv6, section 10.3). This is the _FIRST TIME_ that the MN will send > > a BU to a CN and will have to set up SA to authenticate BU. So the HA knows > > when the MN will have to set up IPsec parameters ... why don't we use this > > fact ? When the HA encapsulates packets to the MN, it could send MN's > > certificate to the CN too, including the Home Address that the MN can use > > (ie. resolving the authorization problem) with the BU. > > But MN might also initiate the communcation with the CN.... JMC : yes, of course ... and what happens (section 4.7) : 1. MN initiates the communication with this new CN but doesn't send a BU (the CN isn't in MN's Binding Update Cache) 2. CN answers to the MN's Home Address 3. MN receives CN's packet tunneled to it from its HA 4. MN sends BU (ie. SA setting up too) So, the HA knows always when the MN will send a BU for the first time to a new CN > But of course if you > are suggesting that MN should not send BU to CN until MN receives the first > tunneled packet. JMC : I don't think so ... or am I wrong ? > (even if MN is initiating the traffic, it can send first packet > without BU, receive [possibly] a response back through HA, and now send a BU) > > alper > > > Thanks for your comments. > > > > JMC. > > > > > > > > > > > --Pekka Nikander > > > > -- > > > > France Telecom R&D - DTL/SSR > > Jean-Michel COMBES, Internet/Intranet Security > > E-Mail : jeanmichel.combes@francetelecom.com > > Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19 > > PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214 > > > > alper -- France Telecom R&D - DTL/SSR Jean-Michel COMBES, Internet/Intranet Security E-Mail : jeanmichel.combes@francetelecom.com Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19 PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214 From owner-mobile-ip@sunroof.eng.sun.com Wed May 2 07:08:25 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05440 for ; Wed, 2 May 2001 07:08:25 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA00647; Wed, 2 May 2001 03:55:48 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA27674; Wed, 2 May 2001 03:55:38 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42As0IM003598 for ; Wed, 2 May 2001 03:54:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f42ArxFJ003591 for mobile-ip-dist; Wed, 2 May 2001 03:53:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42ArkIM003576 for ; Wed, 2 May 2001 03:53:47 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA27515 for ; Wed, 2 May 2001 03:53:46 -0700 (PDT) Received: from p-mail1.cnet.fr (p-mail1.rd.francetelecom.fr [193.49.124.31]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id DAA20252 for ; Wed, 2 May 2001 03:53:45 -0700 (PDT) Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Wed, 2 May 2001 12:53:22 +0200 Received: from francetelecom.com (p-dico.rd.francetelecom.fr [139.100.18.135]) by p-grive.rd.francetelecom.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KD74DWDC; Wed, 2 May 2001 12:53:19 +0200 Message-ID: <3AEFE6D0.92446410@francetelecom.com> Date: Wed, 02 May 2001 12:52:00 +0200 From: Jean-Michel COMBES Organization: France =?iso-8859-1?Q?T=E9l=E9com?= R&D X-Mailer: Mozilla 4.7 [fr] (WinNT; U) X-Accept-Language: fr MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Authenticating BU and PKI References: <3AE6F2DB.88661142@crm.mot.com> <3AED5196.4771F69@nomadiclab.com> <3AED6D36.26EEA17B@francetelecom.com> <3AEE4E79.46F6C879@nomadiclab.com> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by mercury.Sun.COM id DAA00647 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA05440 Pekka Nikander a écrit : > > Pekka Nikander a écrit : > > .... > > > In this particular case (authenticating BUs), secure reverse > > > DNS would be the "right" PKI for the purpose. However, getting > > > it running seems like quite an obstackle, and even if we had it, > > > authenticating a random MN > > > Jean-Michel COMBES wrote: > > I think you wanted to say 'random CN' > > No, I really meant 'random MN'. JMC : So, what are you calling 'random MN' ? What are the differences with 'not random MN' ? > Unless I have understood something > completely wrong, the "MIPv6 security case" is looking for a solution > where the CN can reasonably believe that the MN sending BUs is the > "right" MN, i.e. the one that is authorized to set up a binding > for the specific home address. JMC : I don't totally agree with you. Yes, there is an authorization problem but, in my mind, the "MIPv6 security case" is looking for a solution where MN sends BU to 'random CN' (ie. big servers like yahoo) which must manage too many SA and BU. > For some specific attack scenarios, see > e.g. draft-nikander-ipng-address-ownership-00.txt > > > > Just to clarify: A simple infrastructure with some global CA > > > providing simple certificates is not enough and/or feasible. The > > > certificate must include the home address, and the issuer of > > > the certificate must be authorized to issue certificates > > > concerning that particular home address, etc. > > > > JMC : > > A possible solution would be to use the HA. > > Explanation : > > When the MN receives tunneled packets from its HA, the MN should send BU to > > the CN (MIPv6, section 10.3). This is the _FIRST TIME_ that the MN will send > > a BU to a CN and will have to set up SA to authenticate BU. So the HA knows > > when the MN will have to set up IPsec parameters ... why don't we use this > > fact ? When the HA encapsulates packets to the MN, it could send MN's > > certificate to the CN too, including the Home Address that the MN can use > > (ie. resolving the authorization problem) with the BU. > > I am sorry but I don't understand what you have in mind. You are right > that the first time the MN sends a BU to the CN it must set up an SA. > The problem is HOW to set up this SA if there is no prior security > relationship between the MN and the CN. How does the CN know that the > MN is really the MN whose home address is the one given? JMC : With not using the HA ... (see below) > I am sorry, > but I just don't understand what you are trying to say. Would you > please clarify? > JMC : Regarding authorization problem, I'm trying to explain that HA knows always : - when the MN will send the first BU to a CN and so will set up IPsec SA with it - what is the Home Address that the MN must use So in using HA, a possible scenario could be : 1. CN sends packet to MN's Home Address 2. HA intercepts it 3. HA tunnels it to the MN's Care-Of Address / HA sends security informations to the CN (and why not to MN too ...) I am enough clear ? BTW, sorry for my poor english :-)) JMC. > > --Pekka -- France Telecom R&D - DTL/SSR Jean-Michel COMBES, Internet/Intranet Security E-Mail : jeanmichel.combes@francetelecom.com Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19 PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214 From owner-mobile-ip@sunroof.eng.sun.com Wed May 2 07:23:11 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05689 for ; Wed, 2 May 2001 07:23:11 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA06908; Wed, 2 May 2001 04:22:39 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA19318; Wed, 2 May 2001 04:22:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42BL1IM003685 for ; Wed, 2 May 2001 04:21:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f42BL0vU003684 for mobile-ip-dist; Wed, 2 May 2001 04:21:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42BKjIM003674 for ; Wed, 2 May 2001 04:20:45 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA23801 for ; Wed, 2 May 2001 04:20:44 -0700 (PDT) Received: from ws130.nomadiclab.com (ws130.nomadiclab.com [195.165.196.130]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA10962 for ; Wed, 2 May 2001 04:20:40 -0700 (PDT) Received: from ws34.nomadiclab.com (ws34.nomadiclab.com [195.165.196.34]) by ws130.nomadiclab.com (Postfix) with ESMTP id 1429F72504 for ; Wed, 2 May 2001 14:20:32 +0300 (EEST) Received: from nomadiclab.com (ws146.nomadiclab.com [195.165.196.146]) by ws34.nomadiclab.com (Postfix) with ESMTP id B6BC0BA2F for ; Wed, 2 May 2001 14:20:31 +0300 (EEST) Message-ID: <3AEFEC8D.4DC8F389@nomadiclab.com> Date: Wed, 02 May 2001 12:16:29 +0100 From: Pekka Nikander X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en,fi MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Authenticating BU and PKI References: <3AE6F2DB.88661142@crm.mot.com> <3AED5196.4771F69@nomadiclab.com> <3AED6D36.26EEA17B@francetelecom.com> <3AEE4E79.46F6C879@nomadiclab.com> <3AEFE6D0.92446410@francetelecom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit ... > So, what are you calling 'random MN' ? What are the > differences with 'not random MN' ? In my terms, a 'random NM' is someone the CN does not know and therefore cannot authenticate, and a 'nonrandom MN' is someone the CN knows and therefore can authenticate. ........... > I don't totally agree with you. Yes, there is an authorization problem but, > in my > mind, the "MIPv6 security case" is looking for a solution where MN sends BU to > 'random CN' (ie. big servers like yahoo) which must manage too many SA and BU. Right, we also have the DoS and performance problems. But they are not specific to MIPv6. From my point of view, they are just design constraints, not part of the actual problem. .............. > Regarding authorization problem, I'm trying to explain that HA knows always : > - when the MN will send the first BU to a CN and so will set > up IPsec SA with it > - what is the Home Address that the MN must use Right. The HA knows that. But who tells the CN which HA to use? The MN. How does the CN know whether it can believe the information or not? One answer is by involving the HA in the check. That is exactly what we do in BAKE. Thus, I don't any more understand what's the problem we were discussing about. And given your detailed explanation.... > So in using HA, a possible scenario could be : > > 1. CN sends packet to MN's Home Address > 2. HA intercepts it > 3. HA tunnels it to the MN's Care-Of Address .... this is exactly what happens in BAKE. And it happens without any public keys. My problem is that I don't see what is the value of adding unauthenticated public keys. I don't see much, if any. --Pekka From owner-mobile-ip@sunroof.eng.sun.com Wed May 2 07:24:51 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05810 for ; Wed, 2 May 2001 07:24:50 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA07646; Wed, 2 May 2001 04:24:36 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA05328; Wed, 2 May 2001 04:24:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42BMtIM003695 for ; Wed, 2 May 2001 04:22:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f42BMsjv003694 for mobile-ip-dist; Wed, 2 May 2001 04:22:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42BMfIM003687 for ; Wed, 2 May 2001 04:22:41 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA05185 for ; Wed, 2 May 2001 04:22:40 -0700 (PDT) Received: from p-mail2.cnet.fr (p-mail2.rd.francetelecom.fr [193.49.124.32]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id EAA11773 for ; Wed, 2 May 2001 04:22:39 -0700 (PDT) Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Wed, 2 May 2001 13:22:20 +0200 Received: from francetelecom.com (p-dico.rd.francetelecom.fr [139.100.18.135]) by p-grive.rd.francetelecom.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KD74DWFB; Wed, 2 May 2001 13:22:15 +0200 Message-ID: <3AEFED98.941BD817@francetelecom.com> Date: Wed, 02 May 2001 13:20:56 +0200 From: Jean-Michel COMBES Organization: France =?iso-8859-1?Q?T=E9l=E9com?= R&D X-Mailer: Mozilla 4.7 [fr] (WinNT; U) X-Accept-Language: fr MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Authenticating BU and PKI References: <200104301808.f3UI81HD359141@jurassic.eng.sun.com> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by mercury.Sun.COM id EAA07646 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA05810 [Sorry if you have already received this reply] Alper Yegin a écrit : > > > > > > In this particular case (authenticating BUs), secure reverse > > > DNS would be the "right" PKI for the purpose. However, getting > > > it running seems like quite an obstackle, and even if we had it, > > > authenticating a random MN > > > > JMC : > > I think you wanted to say 'random CN' > > > > > would be quite expensive in terms > > > of the number of needed DNS queries and signature verifications. > > > > > > Just to clarify: A simple infrastructure with some global CA > > > providing simple certificates is not enough and/or feasible. The > > > certificate must include the home address, and the issuer of > > > the certificate must be authorized to issue certificates > > > concerning that particular home address, etc. > > > > JMC : > > A possible solution would be to use the HA. > > Explanation : > > When the MN receives tunneled packets from its HA, the MN should send BU to > > the CN (MIPv6, section 10.3). This is the _FIRST TIME_ that the MN will send > > a BU to a CN and will have to set up SA to authenticate BU. So the HA knows > > when the MN will have to set up IPsec parameters ... why don't we use this > > fact ? When the HA encapsulates packets to the MN, it could send MN's > > certificate to the CN too, including the Home Address that the MN can use > > (ie. resolving the authorization problem) with the BU. > > But MN might also initiate the communcation with the CN.... JMC : yes, of course ... and what happens (section 4.7) : 1. MN initiates the communication with this new CN but doesn't send a BU (the CN isn't in MN's Binding Update Cache) 2. CN answers to the MN's Home Address 3. MN receives CN's packet tunneled to it from its HA 4. MN sends BU (ie. SA setting up too) So, the HA knows always when the MN will send a BU for the first time to a new CN > But of course if you > are suggesting that MN should not send BU to CN until MN receives the first > tunneled packet. JMC : I don't think that is a suggestion, the draft doesn't specify that the MN sends a BU when it initiates communications with a CN, so by default, MN is waiting for tunneled packet to send BU. Am I wrong ? JMC. > (even if MN is initiating the traffic, it can send first packet > without BU, receive [possibly] a response back through HA, and now send a BU) > > alper > -- France Telecom R&D - DTL/SSR Jean-Michel COMBES, Internet/Intranet Security E-Mail : jeanmichel.combes@francetelecom.com Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19 PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214 From owner-mobile-ip@sunroof.eng.sun.com Wed May 2 08:30:29 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07741 for ; Wed, 2 May 2001 08:30:28 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA08066; Wed, 2 May 2001 05:29:52 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA03852; Wed, 2 May 2001 05:29:38 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42CRwIM003856 for ; Wed, 2 May 2001 05:27:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f42CRvvP003855 for mobile-ip-dist; Wed, 2 May 2001 05:27:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42CRnIM003848 for ; Wed, 2 May 2001 05:27:49 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA28846 for ; Wed, 2 May 2001 05:27:51 -0700 (PDT) From: jlha@etri.re.kr Received: from cms1.etri.re.kr (cms1.etri.re.kr [129.254.16.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA20622 for ; Wed, 2 May 2001 05:27:50 -0700 (PDT) Received: by cms1.etri.re.kr with Internet Mail Service (5.5.2653.19) id ; Wed, 2 May 2001 21:26:39 +0900 Message-ID: <325BAD07FE29D511B0DA00D0B7A8DC08B37F2F@cms1.etri.re.kr> To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] activities in 3GPP Date: Wed, 2 May 2001 21:26:37 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) List-Subscribe: List-Unsubscribe: Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D303.21EA74F0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C0D303.21EA74F0 Content-Type: text/plain; charset="euc-kr" Hi all, As far as I know, TR23.923 (Dec, 1999) is the last document on Mobile IP in 3GPP. Is there any further progress in 3GPP Mobile IP? e.g., Mobile IP vs. All-IP (or 4G) Please inform me whether there is any work or not? And also related documents if any. I appreciate your comments in advance. Best regards, Hammer ------_=_NextPart_001_01C0D303.21EA74F0 Content-Type: text/html; charset="euc-kr" [mobile-ip] activities in 3GPP

Hi all,

As far as I know, TR23.923 (Dec, 1999) is the last document on Mobile IP in 3GPP.

Is there any further progress in 3GPP Mobile IP?
e.g., Mobile IP vs. All-IP (or 4G)

Please inform me whether there is any work or not?
And also related documents if any.

I appreciate your comments in advance.


Best regards,
Hammer

------_=_NextPart_001_01C0D303.21EA74F0-- From owner-mobile-ip@sunroof.eng.sun.com Wed May 2 09:27:04 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09988 for ; Wed, 2 May 2001 09:27:03 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA15671; Wed, 2 May 2001 06:26:12 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA08162; Wed, 2 May 2001 06:26:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42DOIIM004013 for ; Wed, 2 May 2001 06:24:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f42DOHth004012 for mobile-ip-dist; Wed, 2 May 2001 06:24:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42DO9IM004005 for ; Wed, 2 May 2001 06:24:09 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA28077 for ; Wed, 2 May 2001 06:24:10 -0700 (PDT) Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA11411 for ; Wed, 2 May 2001 07:50:02 -0600 (MDT) Received: from darmstadt.gmd.de (pc-morion [141.12.35.155]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id PAA15979; Wed, 2 May 2001 15:23:55 +0200 (MET DST) Message-ID: <3AF00AC7.47A2DEE5@darmstadt.gmd.de> Date: Wed, 02 May 2001 15:25:27 +0200 From: Wolfgang Schoenfeld Organization: GMD X-Mailer: Mozilla 4.7 [de] (WinNT; I) X-Accept-Language: en,de MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Some Analysis References: <200105011614.JAA29722@heliopolis.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Jak, the business model surely plays an important role when the effect of hierarchies is investigated. James Kempf wrote: > > Hi Wolfgang, > > Just one comment. > > >Let me finish by giving my peronal interpretation of these numbers > >(and I would be very happy to receive critical replies): > >Hierarchical mobility support is, in some cases, provably better > >than the non-hierarchical counterpart. > >But these cases do not occur very often. > >Hence it is questionable to attempt an optimization - > >it would have an effect only in rare cases. > > Indeed, that's the question, isn't it? How common are these cases going > to be? I think we can argue about light years v.s. millimeters and > 60 ms v.s. 6, but we can't know really. It is a judgement call. > > One thing is for sure. If hierarchy is not supported, then these > cases become suboptimal. And, to the extent that these cases correspond > to particular business models, any decision we make on not supporting > hierarchy will result in an adverse impact on those business models. If you travel slowly (e.g. by feet), there is great chance that your moves result in topologically (in the sense of the network) small steps where optimization by hierarchy has an effect on the number of BUs. On the other hand, if you travel by plane, you will cover in each step topologically long distances where the difference between the hierarchical and the non-hierarchical solution vanishes. I.e. hierarchical support makes sense for pedestrians and not so much for airmen. (Please, all readers of this mailing list should remember that this is meant only in the context of my simple "wheel" model. No general statement is implied because this depends on many more details.) Wolfgang -- Wolfgang Schoenfeld, GMD-IPSI, Dolivostr. 15, D-64293 Darmstadt Office: +49-6151-869-865 FAX: -6847 Mobile: +49-174-7093455 From owner-mobile-ip@sunroof.eng.sun.com Wed May 2 10:14:18 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12144 for ; Wed, 2 May 2001 10:14:17 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA08053; Wed, 2 May 2001 07:14:04 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA08751; Wed, 2 May 2001 07:13:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42EC2IM004112 for ; Wed, 2 May 2001 07:12:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f42EC1Sc004111 for mobile-ip-dist; Wed, 2 May 2001 07:12:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42EBqIM004104 for ; Wed, 2 May 2001 07:11:53 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA08446 for ; Wed, 2 May 2001 07:11:53 -0700 (PDT) Received: from p-mail1.cnet.fr (p-mail1.rd.francetelecom.fr [193.49.124.31]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id HAA21676 for ; Wed, 2 May 2001 07:11:52 -0700 (PDT) Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Wed, 2 May 2001 16:11:32 +0200 Received: from francetelecom.com (p-dico.rd.francetelecom.fr [139.100.18.135]) by p-grive.rd.francetelecom.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KD74DWRV; Wed, 2 May 2001 16:11:30 +0200 Message-ID: <3AF01543.ECA45B63@francetelecom.com> Date: Wed, 02 May 2001 16:10:11 +0200 From: Jean-Michel COMBES Organization: France =?iso-8859-1?Q?T=E9l=E9com?= R&D X-Mailer: Mozilla 4.7 [fr] (WinNT; U) X-Accept-Language: fr MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Authenticating BU and PKI References: <3AE6F2DB.88661142@crm.mot.com> <3AED5196.4771F69@nomadiclab.com> <3AED6D36.26EEA17B@francetelecom.com> <3AEE4E79.46F6C879@nomadiclab.com> <3AEFE6D0.92446410@francetelecom.com> <3AEFEC8D.4DC8F389@nomadiclab.com> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by mercury.Sun.COM id HAA08053 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA12144 Pekka Nikander a écrit : > ... > > So, what are you calling 'random MN' ? What are the > > differences with 'not random MN' ? > > In my terms, a 'random NM' is someone the CN does not know and > therefore cannot authenticate, and a 'nonrandom MN' is someone > the CN knows and therefore can authenticate. > > ........... > > I don't totally agree with you. Yes, there is an authorization problem but, > > in my > > mind, the "MIPv6 security case" is looking for a solution where MN sends BU to > > 'random CN' (ie. big servers like yahoo) which must manage too many SA and BU. > > Right, we also have the DoS and performance problems. But they > are not specific to MIPv6. From my point of view, they are > just design constraints, not part of the actual problem. > > .............. > > Regarding authorization problem, I'm trying to explain that HA knows always : > > - when the MN will send the first BU to a CN and so will set > > up IPsec SA with it > > - what is the Home Address that the MN must use > > Right. The HA knows that. But who tells the CN which HA to use? JMC : I don't understand ... this is the HA that sends informations ... > > The MN. How does the CN know whether it can believe the information > or not? > One answer is by involving the HA in the check. JMC : Agree. > That is exactly what we do in BAKE. Thus, I don't any more understand what's the > problem we were discussing about. JMC : About delivering, securely, informations about the MN to the CN and so solving authorization problem too. > And given your detailed explanation.... > > > So in using HA, a possible scenario could be : > > > > 1. CN sends packet to MN's Home Address > > 2. HA intercepts it > > 3. HA tunnels it to the MN's Care-Of Address > > .... this is exactly what happens in BAKE. And it happens without > any public keys. My problem is that I don't see what is the value > of adding unauthenticated public keys. I don't see much, if any. JMC : I didn't see how BAKE resolves the authorization problem you mentioned in your latest messages JMC. > > > --Pekka -- France Telecom R&D - DTL/SSR Jean-Michel COMBES, Internet/Intranet Security E-Mail : jeanmichel.combes@francetelecom.com Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19 PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214 From owner-mobile-ip@sunroof.eng.sun.com Wed May 2 10:20:29 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12350 for ; Wed, 2 May 2001 10:20:28 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA20115; Wed, 2 May 2001 07:20:19 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA09398; Wed, 2 May 2001 07:20:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42EJ4IM004134 for ; Wed, 2 May 2001 07:19:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f42EJ4Ut004133 for mobile-ip-dist; Wed, 2 May 2001 07:19:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42EItIM004126 for ; Wed, 2 May 2001 07:18:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA09254 for ; Wed, 2 May 2001 07:18:56 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA12098 for ; Wed, 2 May 2001 08:44:40 -0600 (MDT) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f42EIfg10195 for ; Wed, 2 May 2001 09:18:51 -0500 (CDT) Received: from daebh02nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 2 May 2001 09:18:34 -0500 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Wed, 2 May 2001 09:18:34 -0500 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B0321393F@daeis07nok> To: mobile-ip@sunroof.eng.sun.com Cc: carl.williams@eng.sun.com, James.Kempf@Sun.COM Subject: RE: [mobile-ip] LMM Requirements Date: Wed, 2 May 2001 09:18:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Sorry James, I do not understand what you mean. If we were to develop requirements for HMIP, then we would probably not even have debated the issue of multi-level hieararchy.. But since we are having plenty of discussion on this topic, I do not believe the existence of the HMIP I-D as WG doc is limiting the vision on requirements for LMM. > Hi Raj, > > >We would also like some feedback on whether or how having a > particular draft > >on LMM > >as a working group item effects the requirements making > process. Are there > >example requirements that might be considered if the HMIP > draft were not > >already in place as the working group draft? > > > > > > Well, certainly the hierarchy requirement, which has been > hotly debated, > might be already in place, or, at least, we might have some kind of > compromise language that reflected what the hierarchy requirement is > trying to get at, namely some way of improving signalling > latency without > changing the externally visible care of address. The status of this > requirement is still up in the air, and one of the co-authors of > the working group draft has been the strongest opponent. Persumably, > there might be more flexibility shown were the draft not already > a working group item. > > jak > From a requirements perspective, I believe we need to consider the need for hierarchies. So from a status perspective, I would expect to see this requirement being in the requirements draft. The solution for the problem that meets these requirements may invalidate multi-level hieararchies or may provide solutions for scenarios that need such topologies. The current WG draft does not rule out hierarchies. So I think you should consider the arguments of the co-author as just a debate about the requirement (of course I should let the co-author speak for himself). Speculatively, I would expect that the co-author would have had the same position even if the draft was not a WG document but rather a personal I-D :) -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Wed May 2 10:49:00 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13402 for ; Wed, 2 May 2001 10:49:00 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA12076; Wed, 2 May 2001 07:48:51 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA13058; Wed, 2 May 2001 07:48:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42EkVIM004159 for ; Wed, 2 May 2001 07:46:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f42EkUl6004158 for mobile-ip-dist; Wed, 2 May 2001 07:46:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42EkLIM004151 for ; Wed, 2 May 2001 07:46:22 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA12804 for ; Wed, 2 May 2001 07:46:22 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA09936 for ; Wed, 2 May 2001 07:46:20 -0700 (PDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f42EkJN28010 for ; Wed, 2 May 2001 16:46:19 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed May 02 16:46:17 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 2 May 2001 16:41:31 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBDEC@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Cc: carl.williams@eng.sun.com, James.Kempf@Sun.COM Subject: RE: [mobile-ip] LMM Requirements Date: Wed, 2 May 2001 16:46:09 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > Well, certainly the hierarchy requirement, which has been > > hotly debated, > > might be already in place, or, at least, we might have some kind of > > compromise language that reflected what the hierarchy requirement is > > trying to get at, namely some way of improving signalling > > latency without > > changing the externally visible care of address. The status of this > > requirement is still up in the air, and one of the co-authors of > > the working group draft has been the strongest opponent. Persumably, > > there might be more flexibility shown were the draft not already > > a working group item. > > > > jak > > > > From a requirements perspective, I believe we need to consider the need > for hierarchies. So from a status perspective, I would expect to see this > requirement being in the requirements draft. > The solution for the problem that meets these requirements may invalidate > multi-level hieararchies or may provide solutions for scenarios that need > such > topologies. > The current WG draft does not rule out hierarchies. So I think you should > consider the arguments of the co-author as just a debate about the > requirement > (of course I should let the co-author speak for himself). > => Exactly. At least from "this" co-author's point of view this is what we've been doing. I don't see how having the draft as a WG draft has anything to do with what I think about the requirement. HMIPv6 _will_meet the requirements being discussed if the WG agrees on them. The point is we (the WG) clearly haven't converged one way or the other. So I'm not sure that this requirement is representing the WG. This is my opinion and having HMIPv6 as a WG item has nothing to do with it. > Speculatively, I would expect that the co-author would have had the same > position even if the draft was not a WG document but rather a personal I-D > :) > => Agreed. At least if that co-author is me :) Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed May 2 10:51:27 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13517 for ; Wed, 2 May 2001 10:51:27 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA27603; Wed, 2 May 2001 07:51:17 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA01246; Wed, 2 May 2001 07:51:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42EntIM004178 for ; Wed, 2 May 2001 07:49:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f42EnsZe004177 for mobile-ip-dist; Wed, 2 May 2001 07:49:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42EnkIM004170 for ; Wed, 2 May 2001 07:49:46 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id HAA27532; Wed, 2 May 2001 07:49:46 -0700 (PDT) Message-Id: <200105021449.HAA27532@heliopolis.eng.sun.com> Date: Wed, 2 May 2001 07:49:47 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] LMM Requirements To: mobile-ip@sunroof.eng.sun.com, Basavaraj.Patil@nokia.com Cc: carl.williams@eng.sun.com, James.Kempf@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 3E6f5E3YvmamoTNLk/m5wg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Raj, I misinterpreted your question. I thought you were asking how the existence of a working group draft affects the requirements discussion. My point is that if there is already a working group draft without a preexisting requirements discussion, then it will tend to reflect the requirements of the authors, not the working group. So the authors will tend to argue against any requirements that the working group brings up, just as they would if a free requirements discussion were made prior to the draft. But, since the draft has working group status, it becomes harder for the working group to make changes because one has to convince the authors rather than achieve working group concensus. My impression is that has been the case with the hierarchy requirement in the current situation. Does that make sense? jak >From: Basavaraj.Patil@nokia.com >To: mobile-ip@sunroof.eng.sun.com >Cc: carl.williams@eng.sun.com, James.Kempf@Sun.COM >Subject: RE: [mobile-ip] LMM Requirements >Date: Wed, 2 May 2001 09:18:32 -0500 > > >Sorry James, > >I do not understand what you mean. If we were to develop requirements >for HMIP, then we would probably not even have debated the issue of >multi-level hieararchy.. But since we are having plenty of discussion >on this topic, I do not believe the existence of the HMIP I-D as WG >doc is limiting the vision on requirements for LMM. > >> Hi Raj, >> >> >We would also like some feedback on whether or how having a >> particular draft >> >on LMM >> >as a working group item effects the requirements making >> process. Are there >> >example requirements that might be considered if the HMIP >> draft were not >> >already in place as the working group draft? >> > >> > >> >> Well, certainly the hierarchy requirement, which has been >> hotly debated, >> might be already in place, or, at least, we might have some kind of >> compromise language that reflected what the hierarchy requirement is >> trying to get at, namely some way of improving signalling >> latency without >> changing the externally visible care of address. The status of this >> requirement is still up in the air, and one of the co-authors of >> the working group draft has been the strongest opponent. Persumably, >> there might be more flexibility shown were the draft not already >> a working group item. >> >> jak >> > >>From a requirements perspective, I believe we need to consider the need >for hierarchies. So from a status perspective, I would expect to see this >requirement being in the requirements draft. >The solution for the problem that meets these requirements may invalidate >multi-level hieararchies or may provide solutions for scenarios that need >such >topologies. >The current WG draft does not rule out hierarchies. So I think you should >consider the arguments of the co-author as just a debate about the >requirement >(of course I should let the co-author speak for himself). >Speculatively, I would expect that the co-author would have had the same >position even if the draft was not a WG document but rather a personal I-D >:) > >-Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Wed May 2 11:01:47 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13968 for ; Wed, 2 May 2001 11:01:46 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA22585; Wed, 2 May 2001 08:01:30 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA14952; Wed, 2 May 2001 08:01:16 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42ExpIM004198 for ; Wed, 2 May 2001 07:59:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f42Exot7004197 for mobile-ip-dist; Wed, 2 May 2001 07:59:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42ExfIM004190 for ; Wed, 2 May 2001 07:59:42 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA22616 for ; Wed, 2 May 2001 07:59:42 -0700 (PDT) Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id HAA00336 for ; Wed, 2 May 2001 07:59:42 -0700 (PDT) Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id KAA28672; Wed, 2 May 2001 10:59:38 -0400 Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 2 May 2001 10:59:19 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 May 2001 10:59:22 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C095661@zcard031.ca.nortel.com> From: "Bill Gage" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Final(?) Cut on LMM Requirements Date: Wed, 2 May 2001 10:59:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D318.78FBD620" X-Orig: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C0D318.78FBD620 Content-Type: text/plain; charset="iso-8859-1" > > >-----Original Message----- >From: Phil Roberts [ mailto:PRoberts@MEGISTO.com] >Sent: April 25, 2001 10:37 AM >Subject: [mobile-ip] Final(?) Cut on LMM Requirements > > >Seems like we're converging apart from the multiple levels of >hierarchy discussion. Here's what has emerged: > >1. LMM shall be introduced to minimize the signalling traffic to the >home agent or correspondent nodes for intradomain mobility. >(One comment - how constrained is "domain" here? Certainly >administrative domain but can it be more constrained than that? >Didn't see any other suggestions.) > [wg>] I believe it should be an administrative domain. The rationale behind this is so that we can assume some sort of trust relationship between elements of the domain and avoid going down ratholes associated with AAA issues when moving between access points. Issues associated with domains that cover wide geographical areas should be covered by scalability requirements. > >2. LMM shall be secure from malicious behavior. > [wg>] I assume you mean malicious behaviour by entities outside the (visited) administrative domain (i.e. MN, CN, HA) on the assumption that entities inside the AD either trust each other or have their own intra-network security mechanisms. > >3. Connectivity to the mobiles should be minimized (MUST) or >eliminated(strive for this) in the presence of failure of LMM >agents. > [wg>] I assume this is a Freudian slip and should be "disruption to connectivity" ... >(A couple of comments is that this should be restated to be "in the >presence of topological changes" where failure of an LMM is a >particular instance of this. There was some dissent on this >alternative.) > [wg>] I prefer the alternate wording. The original wording only deals with failure of the LMM agents but there may be other network failures that disrupt the communications between a MN and LMM agents. > >4. LMM shall be compatible with fast handoffs. > >5. LMM shall scale to support millions of nodes. >(Comment had been that this was too broad but only other suggestion >was: >"LMM shall scale so that the number of LMM agents scale linearly or >sublinearly with the number of deployed subnets, not the number of >mobiles." Unless there is more support for the revision we'll stay >with the original) > [wg>] I prefer the alternate wording -- it avoids arguments like "of course it will support a million nodes ... you just have to add 5 gig of memory to every routing table". > >6. LMM shall not increase the number of messages between the MN and >the LMM agents. > >7. Any additional header overhead caused by LMM should be eliminated >by compression and transfer of compressor state on movement should >be possible so as not to introduce any perceived service disruption. >(This depends on work in other groups (ROHC and Seamoby)) > [wg>] I don't like this linkage of LMM to areas beyond its scope (i.e. header compression, context transfer). I suggest that it be replaced by something more stringent (e.g. "LMM protocols will not add additional header overhead to messages between the MN and LMM agents.") > >8. LMM shall not require changes to the HA and the CNs. > [wg>] Like others have said, MUST not. >9. LMM should provide the same level of mobility management support >as in the basic MIPv6 spec. > [wg>] What does this mean? > >10. LMM should support autoconfig. > [wg>] Autoconfig of what? Does this include auto reconfiguration of DNS servers, gateway routers, subnet masks, applications servers, etc. etc. Cheers ... ------_=_NextPart_001_01C0D318.78FBD620 Content-Type: text/html; charset="iso-8859-1"

>
>
>-----Original Message-----
>From: Phil Roberts [mailto:PRoberts@MEGISTO.com]
>Sent: April 25, 2001 10:37 AM
>Subject: [mobile-ip] Final(?) Cut on LMM Requirements
>
>
>Seems like we're converging apart from the multiple levels of
>hierarchy discussion.  Here's what has emerged:
>
>1. LMM shall be introduced to minimize the signalling traffic to the
>home agent or correspondent nodes for intradomain mobility.
>(One comment - how constrained is "domain" here?  Certainly
>administrative domain but can it be more constrained than that?
>Didn't see any other suggestions.)
>
[wg>] I believe it should be an administrative domain. The rationale behind this is so that we can assume some sort of trust relationship between elements of the domain and avoid going down ratholes associated with AAA issues when moving between access points. Issues associated with domains that cover wide geographical areas should be covered by scalability requirements.

>
>2. LMM shall be secure from malicious behavior.
>
[wg>] I assume you mean malicious behaviour by entities outside the (visited) administrative domain (i.e. MN, CN, HA) on the assumption that entities inside the AD either trust each other or have their own intra-network security mechanisms.

>
>3. Connectivity to the mobiles should be minimized (MUST) or
>eliminated(strive for this) in the presence of failure of LMM
>agents.
>
[wg>] I assume this is a Freudian slip and should be "disruption to connectivity" ...

>(A couple of comments is that this should be restated to be "in the
>presence of topological changes" where failure of an LMM is a
>particular instance of this.  There was some dissent on this
>alternative.)
>
[wg>] I prefer the alternate wording. The original wording only deals with failure of the LMM agents but there may be other network failures that disrupt the communications between a MN and LMM agents.

>
>4. LMM shall be compatible with fast handoffs.
>
>5. LMM shall scale to support millions of nodes.
>(Comment had been that this was too broad but only other suggestion
>was:
>"LMM shall scale so that the number of LMM agents scale linearly or
>sublinearly with the number of deployed subnets, not the number of
>mobiles." Unless there is more support for the revision we'll stay
>with the original)
>
[wg>] I prefer the alternate wording -- it avoids arguments like "of course it will support a million nodes ... you just have to add 5 gig of memory to every routing table".

>
>6. LMM shall not increase the number of messages between the MN and
>the LMM agents.
>
>7. Any additional header overhead caused by LMM should be eliminated
>by compression and transfer of compressor state on movement should
>be possible so as not to introduce any perceived service disruption.
>(This depends on work in other groups (ROHC and Seamoby))
>
[wg>] I don't like this linkage of LMM to areas beyond its scope (i.e. header compression, context transfer). I suggest that it be replaced by something more stringent (e.g. "LMM protocols will not add additional header overhead to messages between the MN and LMM agents.")

>
>8. LMM shall not require changes to the HA and the CNs.
>
[wg>] Like others have said, MUST not.

>9. LMM should provide the same level of mobility management support
>as in the basic MIPv6 spec.
>
[wg>] What does this mean?

>
>10. LMM should support autoconfig.
>
[wg>] Autoconfig of what? Does this include auto reconfiguration of DNS servers, gateway routers, subnet masks, applications servers, etc. etc.

Cheers ...

------_=_NextPart_001_01C0D318.78FBD620-- From owner-mobile-ip@sunroof.eng.sun.com Wed May 2 11:08:17 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14129 for ; Wed, 2 May 2001 11:08:16 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA28110; Wed, 2 May 2001 08:08:05 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA16141; Wed, 2 May 2001 08:07:57 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42F6ZIM004217 for ; Wed, 2 May 2001 08:06:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f42F6ZQJ004216 for mobile-ip-dist; Wed, 2 May 2001 08:06:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42F6QIM004209 for ; Wed, 2 May 2001 08:06:26 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA15938 for ; Wed, 2 May 2001 08:06:27 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA04374 for ; Wed, 2 May 2001 08:06:26 -0700 (PDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Wed, 2 May 2001 11:00:17 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Final(?) Cut on LMM Requirements Date: Wed, 2 May 2001 11:00:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D318.9920FA48" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C0D318.9920FA48 Content-Type: text/plain; charset="iso-8859-1" >3. Connectivity to the mobiles should be minimized (MUST) or >eliminated(strive for this) in the presence of failure of LMM >agents. > [wg>] I assume this is a Freudian slip and should be "disruption to connectivity" ... [Phil Roberts] Hah! Well, the stated requirement *is* much easier to meet. The challenge is how to do it elegantly, wouldn't you say? ------_=_NextPart_001_01C0D318.9920FA48 Content-Type: text/html; charset="iso-8859-1"
>3. Connectivity to the mobiles should be minimized (MUST) or
>eliminated(strive for this) in the presence of failure of LMM
>agents.
>
[wg>] I assume this is a Freudian slip and should be "disruption to connectivity" ...

[Phil Roberts] Hah!  Well, the stated requirement *is* much easier to meet.  The challenge is how to do it elegantly, wouldn't you say?
 
------_=_NextPart_001_01C0D318.9920FA48-- From owner-mobile-ip@sunroof.eng.sun.com Wed May 2 11:14:51 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14350 for ; Wed, 2 May 2001 11:14:50 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA11413; Wed, 2 May 2001 08:14:39 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA16766; Wed, 2 May 2001 08:14:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42FClIM004237 for ; Wed, 2 May 2001 08:12:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f42FClve004236 for mobile-ip-dist; Wed, 2 May 2001 08:12:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42FCcIM004229 for ; Wed, 2 May 2001 08:12:38 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA26648 for ; Wed, 2 May 2001 08:12:39 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA14596 for ; Wed, 2 May 2001 09:38:05 -0600 (MDT) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f42FCZO15582 for ; Wed, 2 May 2001 17:12:35 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Wed May 02 17:12:34 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 2 May 2001 17:12:34 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBDEE@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Final(?) Cut on LMM Requirements Date: Wed, 2 May 2001 17:12:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Bill, Raj, Phil, Carl, I sent some comments earlier on this list but I don't know what happened to them. So I'll send them again and in the mean time ad to Bill's comments / questions. > >Seems like we're converging apart from the multiple levels of > >hierarchy discussion. Here's what has emerged: > > > >1. LMM shall be introduced to minimize the signalling traffic to the > >home agent or correspondent nodes for intradomain mobility. > >(One comment - how constrained is "domain" here? Certainly > >administrative domain but can it be more constrained than that? > >Didn't see any other suggestions.) > > > [wg>] I believe it should be an administrative domain. The rationale behind this is so that we can assume some sort of trust relationship between elements of the domain and avoid going down ratholes associated with AAA issues when moving between access points. Issues associated with domains that cover wide geographical areas should be covered by scalability requirements. > => Agreed. > > > >2. LMM shall be secure from malicious behavior. > > > [wg>] I assume you mean malicious behaviour by entities outside the (visited) administrative domain (i.e. MN, CN, HA) on the assumption that entities inside the AD either trust each other or have their own intra-network security mechanisms. > => I don't think you can trust other entities inside a visited domain. These entities may also include other CNs for example. In addition, you don't normally trust a visited domain that you know nothing about. > > > > > > >4. LMM shall be compatible with fast handoffs. > > > >5. LMM shall scale to support millions of nodes. > >(Comment had been that this was too broad but only other suggestion > >was: > >"LMM shall scale so that the number of LMM agents scale linearly or > >sublinearly with the number of deployed subnets, not the number of > >mobiles." Unless there is more support for the revision we'll stay > >with the original) > > > [wg>] I prefer the alternate wording -- it avoids arguments like "of course it will support a million nodes ... you just have to add 5 gig of memory to every routing table". > => Agreed. > >9. LMM should provide the same level of mobility management support > >as in the basic MIPv6 spec. > > > [wg>] What does this mean? > => It means you don't remove functionality from MIPv6. If function X is supported in MIPv6 then it should be supported in LMM. > > > > >10. LMM should support autoconfig. > > > [wg>] Autoconfig of what? Does this include auto reconfiguration of DNS servers, gateway routers, subnet masks, applications servers, etc. etc. > => Agreed. There was another requirement suggested earlier and that is LMM MUST comply with the security requirements of MIPv6 and MUST NOT require additional extensions or limitations over what MIPv6 requires. Someone (Carl) can find a better wording perhaps. Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed May 2 11:39:19 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15073 for ; Wed, 2 May 2001 11:39:18 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA25425; Wed, 2 May 2001 08:39:08 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA21118; Wed, 2 May 2001 08:38:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42FafIM004260 for ; Wed, 2 May 2001 08:36:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f42FaeOh004259 for mobile-ip-dist; Wed, 2 May 2001 08:36:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42FaVIM004252 for ; Wed, 2 May 2001 08:36:31 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA02012 for ; Wed, 2 May 2001 08:36:19 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA23124 for ; Wed, 2 May 2001 08:36:17 -0700 (PDT) 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 IAA27787 for ; Wed, 2 May 2001 08:36:17 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f42FaGu00677 for ; Wed, 2 May 2001 08:36:16 -0700 X-mProtect: Wed, 2 May 2001 08:36:16 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdMmyIVd; Wed, 02 May 2001 08:36:03 PDT Message-ID: <3AF02963.BC75BF87@iprg.nokia.com> Date: Wed, 02 May 2001 08:36:03 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Final(?) Cut on LMM Requirements References: <034BEFD03799D411A59F00508BDF7546013DBDEE@esealnt448.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello folks, I'm finding it difficult to keep up with all the discussion, but the following two items stand out: > 5. LMM shall scale to support millions of nodes. > (Comment had been that this was too broad but only other suggestion > was: > "LMM shall scale so that the number of LMM agents scale linearly or > sublinearly with the number of deployed subnets, not the number of > mobiles." Unless there is more support for the revision we'll stay > with the original) I think the original is better, unless someone can demonstrate that it is actually possible to achieve the suggested linear or sublinear growth rate. > 10. LMM should support autoconfig. Part of the problem of LMM is to figure out what the mobility routing agents are doing, and where they are to be located. If LMM involves host routes, then another part of the problem will be to manage the distribution of the host routes. A third part of the problem will be to find ways for the mobility routing agents to be able to discover their interrelationships (e.g., how they fit in a hierarchy or mesh, perhaps). These problems do not all have to be solved at the same time, and therefore not all in the same draft. So, for instance, one scheme for the distribution of host routes could be compatible with multiple schemes for autoconfiguration. I'd even suggest that manual configuration is acceptable until we have some experience with testing and deployment of some scheme. However, this is not at all to say that autoconfiguration schemes are not of interest. It's just that we can go a long way towards solving LMM problems without the necessary requirement for autoconfiguration. As an example, I think it would be very reasonable to have a Proposed Standard for LMM possibly months or even a year before having a Proposed Standard for LMM autoconfiguration. Look at the example of Router Renumbering for IPv6. On the other hand, if we have both ready sooner, so much the better! Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Wed May 2 12:32:37 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16509 for ; Wed, 2 May 2001 12:32:36 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15503; Wed, 2 May 2001 09:32:22 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA01562; Wed, 2 May 2001 09:32:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42GUpIM004349 for ; Wed, 2 May 2001 09:30:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f42GUo0f004348 for mobile-ip-dist; Wed, 2 May 2001 09:30:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42GUgIM004341 for ; Wed, 2 May 2001 09:30:42 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id JAA00688 for ; Wed, 2 May 2001 09:30:42 -0700 (PDT) Message-Id: <200105021630.JAA00688@heliopolis.eng.sun.com> Date: Wed, 2 May 2001 09:30:42 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Some Analysis To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: CWtq/QoGv2wbfJH/Ol2Gfg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Erik, >Assuming my brain has some remaining amount of logic processing, >I think there is another possibility. Equation (1) is when you claim >it makes sense to deploy an hierarchical scheme. >Thus what I've think you've shown is that when it makes sense to >deploy the hierarchical scheme (per your constraints) it does better >than the non-hiearchical scheme. But that, depending on how you defined >(1), might be a tautology - if (1) is defined (which it seems to be) >to capture the case when an hierarchical scheme does well then >I'm not surprised that you can show that it does well. > Right, the point I was trying to make was, given that it makes sense to deploy a hierarchical scheme (it might not always, basically network engineering is always needed), would not having that capability negatively impact performance. jak From owner-mobile-ip@sunroof.eng.sun.com Wed May 2 13:26:37 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17819 for ; Wed, 2 May 2001 13:26:36 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA25114; Wed, 2 May 2001 10:25:44 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA12460; Wed, 2 May 2001 10:24:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42HMnIM004438 for ; Wed, 2 May 2001 10:22:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f42HMmYk004437 for mobile-ip-dist; Wed, 2 May 2001 10:22:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42HMeIM004430 for ; Wed, 2 May 2001 10:22:40 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA12058 for ; Wed, 2 May 2001 10:22:39 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA27204 for ; Wed, 2 May 2001 11:49:41 -0600 (MDT) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f42HOuw21136 for ; Wed, 2 May 2001 12:25:06 -0500 (CDT) Received: from daebh02nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 2 May 2001 12:22:27 -0500 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Wed, 2 May 2001 12:22:27 -0500 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B03213949@daeis07nok> To: James.Kempf@Sun.COM, mobile-ip@sunroof.eng.sun.com Cc: carl.williams@eng.sun.com Subject: RE: [mobile-ip] LMM Requirements Date: Wed, 2 May 2001 12:22:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: James, >James wrote: >Hi Raj, > ---cut------ >So the authors >will tend to argue against any requirements that the working group >brings up, just as they would if a free requirements discussion >were made prior to the draft. But, since the draft has working group >status, it becomes harder for the working group to make changes because >one has to convince the authors rather than achieve working group >concensus. WG consensus is what matters. If the WG convereges on a concept, that is not supported by the authors, it will still be included in the WG document/solution. I do not believe that you have to convince the authors; you just have to build WG consensus. >My impression is that has been the case with the hierarchy >requirement in the current situation. I do not believe we have WG consensus yet (other than a few views) on this issue. Maybe we need to do a consensus call on just this requirement and hope that we have a wider response. So if we were to do a consensus call on this requirement then the question to the WG would be: 1. Is support for multilevel hierarchies a requirement for LMM? 2. A single level of hierarchy is sufficient as the requirements for LMM can be met by engineering the network right. Do you agree with the above if we were to do a consensus call... > > jak -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Wed May 2 13:50:35 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18533 for ; Wed, 2 May 2001 13:50:29 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24931; Wed, 2 May 2001 10:50:14 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07158; Wed, 2 May 2001 10:49:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42Hm7IM004539 for ; Wed, 2 May 2001 10:48:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f42Hm7fT004538 for mobile-ip-dist; Wed, 2 May 2001 10:48:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42HlwIM004531 for ; Wed, 2 May 2001 10:47:58 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA29650 for ; Wed, 2 May 2001 10:47:44 -0700 (PDT) Received: from ws130.nomadiclab.com (ws130.nomadiclab.com [195.165.196.130]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA10446 for ; Wed, 2 May 2001 12:14:35 -0600 (MDT) Received: from ws34.nomadiclab.com (ws34.nomadiclab.com [195.165.196.34]) by ws130.nomadiclab.com (Postfix) with ESMTP id 4359F72504 for ; Wed, 2 May 2001 20:47:24 +0300 (EEST) Received: from nomadiclab.com (localhost [127.0.0.1]) by ws34.nomadiclab.com (Postfix) with ESMTP id 9A5A8BA2F for ; Wed, 2 May 2001 20:47:23 +0300 (EEST) Message-ID: <3AF0473B.3C6E73E1@nomadiclab.com> Date: Wed, 02 May 2001 18:43:23 +0100 From: Pekka Nikander X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en,fi MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Authenticating BU and PKI References: <3AE6F2DB.88661142@crm.mot.com> <3AED5196.4771F69@nomadiclab.com> <3AED6D36.26EEA17B@francetelecom.com> <3AEE4E79.46F6C879@nomadiclab.com> <3AEFE6D0.92446410@francetelecom.com> <3AEFEC8D.4DC8F389@nomadiclab.com> <3AF01543.ECA45B63@francetelecom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jean-Michel COMBES wrote: > > Right. The HA knows that. But who tells the CN which HA to use? > > JMC : > I don't understand ... this is the HA that sends informations ... Even if so, IP source address spoofing is easy. If the HA sends a packet to the CN, how does the CN know that it really came from the HA? You cannot assume that there is some security association between them, since there can't be, yet. --Pekka From owner-mobile-ip@sunroof.eng.sun.com Wed May 2 14:46:07 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19834 for ; Wed, 2 May 2001 14:46:06 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA07771; Wed, 2 May 2001 11:45:44 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA20580; Wed, 2 May 2001 11:45:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42IiEIM004640 for ; Wed, 2 May 2001 11:44:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f42IiEj6004639 for mobile-ip-dist; Wed, 2 May 2001 11:44:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42Ii5IM004632 for ; Wed, 2 May 2001 11:44:05 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA20175 for ; Wed, 2 May 2001 11:44:05 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA10811 for ; Wed, 2 May 2001 13:11:03 -0600 (MDT) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f42Ii5g06044 for ; Wed, 2 May 2001 13:44:05 -0500 (CDT) Received: from daebh02nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 2 May 2001 13:43:59 -0500 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Wed, 2 May 2001 13:43:58 -0500 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B0321394D@daeis07nok> To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] MIPv6 Fast HO DT concluded Date: Wed, 2 May 2001 13:43:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello, The Mobile IPv6 fast handoff design team has now been shut down. All future work related to fast handoff for MIPv6 will be carried out in the Mobile IP WG discussion list. A new version of the I-D has been announced (draft-ietf-mobileip-fast-mipv6-01.txt). Please provide comments and feedback via the mailing list or to the editor. The archives of the discussion list used by the design team will be made available shortly. -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Wed May 2 15:18:37 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20622 for ; Wed, 2 May 2001 15:18:36 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA11104; Wed, 2 May 2001 12:18:22 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA10496; Wed, 2 May 2001 12:18:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42JEuIM004703 for ; Wed, 2 May 2001 12:14:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f42JEuAb004702 for mobile-ip-dist; Wed, 2 May 2001 12:14:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42JElIM004695 for ; Wed, 2 May 2001 12:14:47 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA12134 for ; Wed, 2 May 2001 12:14:42 -0700 (PDT) Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id NAA25580 for ; Wed, 2 May 2001 13:41:13 -0600 (MDT) Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id PAA22297; Wed, 2 May 2001 15:14:33 -0400 Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 2 May 2001 15:14:21 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 May 2001 15:14:24 -0400 Message-ID: From: "Muhammad Jaseemuddin" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Final(?) Cut on LMM Requirements Date: Wed, 2 May 2001 15:14:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D33C.1595C810" X-Orig: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C0D33C.1595C810 Content-Type: text/plain; charset="iso-8859-1" Hi Charlie: > -----Original Message----- > From: Charles E. Perkins [SMTP:charliep@iprg.nokia.com] > Sent: Monday, April 30, 2001 12:30 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Final(?) Cut on LMM Requirements > > Hello Muhammad, > > You suggest that the fast handover draft for Mobile IPv6 > should either de-emphasize, or eliminate entirely, the > mechanism for assignment of a new care-of address at the > new access router's network. I have two observations about > this. > [MJ] I did not mean to eliminate entirely, and I wouldn't even call my proposal de-emphasizing. Rather my suggestion is to make fast handover more flexible to inter-work with any LMM solution. > 1) Mobile IP deals with binding a care-of address to > a home address, and tunnel management. A protocol > for which the node's care-of address is not relevant > does not necessarily have to be developed within > the mobile-ip working group. > [MJ] I am not suggesting to develop any such solution here. This argument needs to be revisited in the new situation where LMM is being discussed as a solution for especially within an administrative domain. I think that we should provide more flexiblity to an operator to deploy a solution of its choice. Hence, fast handover that involves end-systems (MN and potentially CN and HA) should not assume that LMM always require change of address. In this way it becomes a standard handover signaling while potentially protecting LMM to involve these end systems. As I mentioned previously the fast handover should work both with LMM and also in the absence of LMM with Mobile IP. Currently it is working fine with the later, but by adding this little change in fast handover make it very flexible to work with any LMM solution. Now, I make out after reading requirement 1 and 9 that LMM solution is only for intra-domain and must interwork with Mobile IP for interdomain. So, by allowing fast handover to also include this option of not acquiring new address during handover does not break interworking with Mobile IP. Currently, fast handover allows use of old COA in different situations, e.g. in the absence of not receiving Fast Binding Ack. There is another place where it allows use of old COA, but its not clear in which situation. Let me quote from the draft: Page 15: Description (of Proxy Router Advertisement) ... A Proxy Router Advertisement with Code 1 is sent if handover to the New Attachment Point, as indicated by the New Attachment Point Link Layer address in the corresponding RtSolPr message, does not require change of COA. ... I am not sure if that was intended to provide the option I talked about, but then it is missing from the rest of the design. > 2) The care-of address is used for routing. If the routing > changes, but the care-of address does not change, then > more host routes are needed to handle the exceptional > nature of routing to a care-of address on the "wrong" > access network. > [MJ] You are right. I refrain from discussing any such solution because my understanding is that it is outside the scope of Mobile IP WG. > Of course, these arguments are not absolute in nature. They > only serve to provide design guidelines. You can make packets > arrive at a mobile node in quite a few different ways. It's > an engineering decision about whether to disseminate more, or > fewer, host routes to accomplish the job. > [MJ] With the current decomposition of problem space - Mobile IP + LMM + Fast Handover - perhaps we should make different engineering decisions for different spaces. It does not mean that I am intended to disrupt the LMM work here. The LMM solution within Mobile IP WG is constrained by using Mobile IP tunneling mechanism. > Regards, > Charlie P. > [MJ] I am working on minimal changes in fast handover and will submit to the group soon for consideration, which will hopefully be acceptable to the design team and the WG. Regards, - Muhammad Jaseemuddin > > Muhammad Jaseemuddin wrote: > > > > Hesham: > > > > -----Original Message----- > > From: Hesham Soliman (ERA) [SMTP:Hesham.Soliman@era.ericsson.se] > > Sent: Thursday, April 26, 2001 4:08 PM > > To: 'mobile-ip@sunroof.eng.sun.com' > > Subject: RE: [mobile-ip] Final(?) Cut on LMM Requirements > > > > Muhammad, > > > > > [MJ] I agree that it shall be compatible with fast handoff, > because as > > I posted earlier to me fast handoff provides standard handover > signaling > > (and solution of course). But we also had a discussion that fast > handoff > > should also comply with relevant LMM requirements, because its a > three > > tier solution space we are discussing - Mobile IP then LMM then > Fast > > Handoff. In this regard I had suggested that fast handoff should > not > > always assume change of IP address from LMM perspective. Although > it > > might happen that the LMM solution evolved always does that, but > fast > > handoff signaling should provide at least the provision otherwise. > And if > > the WG feel comfortable with that then it should be captured in LMM > > requriement. I haven't seen any objection to my previous posting. > Or do > > you think that this issue I should discuss with the fast handoff > design > > team? Any idea? > > > > > > > => I don't really undersand your suggestion to not change > the > > CoA. > > The Fast Handoff draft is built around the fact that the MN > will > > change its CoA. There is one case where that fails (DAD for > the > > new CoA) and the MN keeps the same address. But this is > > an error case and 99.99 % of the time it won't happen. > > > > [MJ] I know that fast handoff solution is built around that > assumption, > > and I am questioning that very basic assumption. I am saying that > it is > > LMM solution's forte to decide whether handing over to new AR > should > > involve new address assignment, especially within an AD. Hence, > fast > > handoff solution should be flexible in handling this situation. The > > question is why fast handoff always assume change of address? It > can > > easily provide this flexibility that if an address change is > required > > then it would happen. Let us look the jobs being done by fast > handoff: > > > > 1. It signals new AR about imminent handover > > 2. It arranges new address assignment at the new AR (either > > autoconfiguration or stateful) > > 3. It established temporary tunnel to forward in-flight packets > > > > Now, instead of always assuming new address assignment it can > provide in > > its signaling following options: > > > > 1. No new address assignment > > 2. Autoconfiguration, hence asking new AR to run DAD on behalf of > MN > > 3. Stateful address assignment > > > > This will make fast handoff solution quite flexible and capable of > being > > defacto standard handover signaling for any LMM. Although, I am > making > > this statement but with one caveat that I don't know how fast > handoff and > > CT will work together. I think this discussion should be moved to > fast > > handoff design team mailing list, but my understanding is that it > is > > closed. BTW, Hesham how did you get this 99.99% reliability number, > > through some simulation? > > > > Cheers, > > - Muhammad Jaseemuddin > > > > Hesham ------_=_NextPart_001_01C0D33C.1595C810 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Final(?) Cut on LMM Requirements

Hi Charlie:

    -----Original Message-----
    From:   Charles E. Perkins = [SMTP:charliep@iprg.nokia.com]
    Sent:   Monday, April 30, 2001 12:30 PM
    To:     mobile-ip@sunroof.eng.sun.com
    Subject:       = Re: [mobile-ip] Final(?) Cut on LMM = Requirements

    Hello Muhammad,

    You suggest that the fast handover = draft for Mobile IPv6
    should either de-emphasize, or = eliminate entirely, the
    mechanism for assignment of a new = care-of address at the
    new access router's network.  I = have two observations about
    this.

    [MJ]  I did not mean to eliminate entirely, and I = wouldn't even call my proposal de-emphasizing. Rather my suggestion is = to make fast handover more flexible to inter-work with any LMM = solution.

    1) Mobile IP deals with binding a = care-of address to
       a home address, and = tunnel management.  A protocol
       for which the node's = care-of address is not relevant
       does not necessarily = have to be developed within
       the mobile-ip working = group.

    [MJ]  I am not suggesting to develop any such = solution here. This argument needs to be revisited in the new situation = where LMM is being discussed as a solution for especially within an = administrative domain. I think that we should provide more flexiblity = to an operator to deploy a solution of its choice. Hence, fast handover = that involves end-systems (MN and potentially CN and HA) should not = assume that LMM always require change of address. In this way it = becomes a standard handover signaling while potentially protecting LMM = to involve these end systems. As I mentioned previously the fast = handover should work both with LMM and also in the absence of LMM with = Mobile IP. Currently it is working fine with the later, but by adding = this little change in fast handover make it very flexible to work with = any LMM solution. Now, I make out after reading requirement 1 and 9 = that LMM solution is only for intra-domain and must interwork with = Mobile IP for interdomain. So, by allowing fast handover to also = include this option of not acquiring new address during handover does = not break interworking with Mobile IP.

    Currently, fast = handover allows use of old COA in different situations, e.g. in the = absence of not receiving Fast Binding Ack. There is another place where = it allows use of old COA, but its not clear in which situation. Let me = quote from the draft:

    Page 15: Description = (of Proxy Router Advertisement)

    ...
    A Proxy Router = Advertisement with Code 1 is sent if handover to the New Attachment = Point, as indicated by the New Attachment Point Link Layer address in = the corresponding RtSolPr message, does not require change of = COA.

    ...

    I am not sure if = that was intended to provide the option I talked about, but then it is = missing from the rest of the design.

    2) The care-of address is used for = routing.  If the routing
       changes, but the care-of = address does not change, then
       more host routes are = needed to handle the exceptional
       nature of routing to a = care-of address on the "wrong"
       access network.

    [MJ]   You are right. I refrain from discussing = any such solution because my understanding is that it is outside the = scope of Mobile IP WG.

    Of course, these arguments are not = absolute in nature.  They
    only serve to provide design = guidelines.  You can make packets
    arrive at a mobile node in quite a = few different ways.  It's
    an engineering decision about whether = to disseminate more, or
    fewer, host routes to accomplish the = job.

    [MJ]  With the current decomposition of problem = space - Mobile IP + LMM + Fast Handover - perhaps we should make = different engineering decisions for different spaces. It does not mean = that I am intended to disrupt the LMM work here. The LMM solution = within Mobile IP WG is constrained by using Mobile IP tunneling = mechanism.

     Regards,
    Charlie P.

    [MJ]  I am working on minimal changes in fast = handover and will submit to the group soon for consideration, which = will hopefully be acceptable to the design team and the WG.

    Regards,

    - Muhammad = Jaseemuddin

    > Muhammad Jaseemuddin = wrote:
    >
    > Hesham:
    >
    >      = -----Original Message-----
    >      = From:   Hesham Soliman (ERA) = [SMTP:Hesham.Soliman@era.ericsson.se]
    >      = Sent:   Thursday, April 26, 2001 4:08 PM
    >      = To:     'mobile-ip@sunroof.eng.sun.com'
    >      = Subject:        RE: [mobile-ip] = Final(?) Cut on LMM Requirements
    >
    >         = ;     Muhammad,
    >
    >      = > [MJ]  I agree that it shall be compatible with fast handoff, = because as
    >      I = posted earlier to me fast handoff provides standard handover = signaling
    >      = (and solution of course). But we also had a discussion that fast = handoff
    >      = should also comply with relevant LMM requirements, because its a = three
    >      = tier solution space we are discussing - Mobile IP then LMM then = Fast
    >      = Handoff. In this regard I had suggested that fast handoff should = not
    >      = always assume change of IP address from LMM perspective. Although = it
    >      = might happen that the LMM solution evolved always does that, but = fast
    >      = handoff signaling should provide at least the provision otherwise. And = if
    >      = the WG feel comfortable with that then it should be captured in = LMM
    >      = requriement. I haven't seen any objection to my previous posting. Or = do
    >      = you think that this issue I should discuss with the fast handoff = design
    >      = team? Any idea?
    >
    >      = >
    >         = ;     =3D> I don't really undersand your = suggestion to not change the
    >      = CoA.
    >         = ;     The Fast Handoff draft is built around the = fact that the MN will
    >         = ;     change its CoA. There is one case where that = fails (DAD for the
    >         = ;     new CoA) and the MN keeps the same address. = But this is
    >         = ;     an error case and 99.99 % of the time it = won't happen.
    >
    >      = [MJ]  I know that fast handoff solution is built around that = assumption,
    >      = and I am questioning that very basic assumption. I am saying that it = is
    >      = LMM solution's forte to decide whether handing over to new AR = should
    >      = involve new address assignment, especially within an AD. Hence, = fast
    >      = handoff solution should be flexible in handling this situation. = The
    >      = question is why fast handoff always assume change of address? It = can
    >      = easily provide this flexibility that if an address change is = required
    >      = then it would happen. Let us look the jobs being done by fast = handoff:
    >
    >      1. = It signals new AR about imminent handover
    >      2. = It arranges new address assignment at the new AR (either
    >      = autoconfiguration or stateful)
    >      3. = It established temporary tunnel to forward in-flight packets
    >
    >      = Now, instead of always assuming new address assignment it can provide = in
    >      = its signaling following options:
    >
    >      1. = No new address assignment
    >      2. = Autoconfiguration, hence asking new AR to run DAD on behalf of = MN
    >      3. = Stateful address assignment
    >
    >      = This will make fast handoff solution quite flexible and capable of = being
    >      = defacto standard handover signaling for any LMM. Although, I am = making
    >      = this statement but with one caveat that I don't know how fast handoff = and
    >      CT = will work together. I think this discussion should be moved to = fast
    >      = handoff design team mailing list, but my understanding is that it = is
    >      = closed. BTW, Hesham how did you get this 99.99% reliability = number,
    >      = through some simulation?
    >
    >      = Cheers,
    >      - = Muhammad Jaseemuddin
    >
    >         = ;     Hesham

------_=_NextPart_001_01C0D33C.1595C810-- From owner-mobile-ip@sunroof.eng.sun.com Wed May 2 17:00:06 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23335 for ; Wed, 2 May 2001 17:00:05 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01867; Wed, 2 May 2001 13:59:43 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA16845; Wed, 2 May 2001 13:58:30 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42Kv4IM004937 for ; Wed, 2 May 2001 13:57:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f42Kv4fR004936 for mobile-ip-dist; Wed, 2 May 2001 13:57:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42KusIM004929 for ; Wed, 2 May 2001 13:56:54 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA03619 for ; Wed, 2 May 2001 13:56:53 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA06246 for ; Wed, 2 May 2001 13:56:53 -0700 (PDT) Received: from msubbara-u10.cisco.com (msubbara-u10.cisco.com [64.102.66.20]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f42KvHK09341 for ; Wed, 2 May 2001 13:57:21 -0700 (PDT) Received: (msubbara@localhost) by msubbara-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA14893 for mobile-ip@sunroof.eng.sun.com; Wed, 2 May 2001 16:56:18 -0400 (EDT) Date: Wed, 2 May 2001 16:56:18 -0400 From: Madhavi Subbarao To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: mobile-ip] Multiple flows with single NAI Message-ID: <20010502165618.A14879@cisco.com> References: <85AA7486A2C1D411BCA20000F8073E43020D5F96@crchy271.us.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <85AA7486A2C1D411BCA20000F8073E43020D5F96@crchy271.us.nortel.com>; from gmorrow@nortelnetworks.com on Tue, May 01, 2001 at 11:19:29AM -0500 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Glenn, Sorry for the delayed response... On Tue, May 01, 2001 at 11:19:29AM -0500, Glenn Morrow wrote: > Madhavi, > > > Are you thinking of the NAI as a: > > subscription identifier > user identifier > Equipment identifier? As a user identifier. The NAI identifies the user, not the device. > It seems to me that each device might have different home > addresses. Yes, actually that's what we are saying. Each device will have a different home address...authentication is based on NAI (as is currently). The HA authorizes the (NAI, IP address) combination. > The key > can be a bit more complex than just an NAI into a database/directory used > for any purpose. I'm afraid I didn't catch your point. Are you saying that you can't still authenticate based on NAI? Please elaborate... Regards, Madhavi > -----Original Message----- > From: Madhavi Subbarao [mailto:msubbara@cisco.com] > Sent: Monday, April 30, 2001 6:53 PM > To: mobile-ip@sunroof.eng.sun.com > Cc: Madhavi W Subbarao > Subject: [mobile-ip] Multiple flows with single NAI > > > Hi All, > > For viable deployment of MIP, it seems necessary to support single NAI > with multiple static IP flows. For example, if a user opens a MIP > session on his laptop and then wants another MIP session on his phone, > he couldn't do that now with a single NAI . Now when an HA receives > an RRQ with NAI and homeIP#2, but it already has a binding for NAI > and homeIP#1, the binding gets 'overwritten'. Hence, only one MIP > flow can be supported per NAI. Theoretically, we can say to use > multiple NAIs, but practically, it's not possible. Many service providers > do not want to create multiple NAIs and user records for multiple > devices/applications or instances of the mobile user. > > While it seems natural then to allow multiple static IPs for the same NAI > (dynamic IPs also, but that needs another level of identification), > neither RFC2002 nor RFC2974 outline the behavior that should be > followed by the various entities. The specs certainly do not preclude > the above, but clarity in behavior is needed. > > We believe this is a simple, yet important issue for deployment and would > like feedback from the WG. > > We've submitted a draft that addresses the above. > http://search.ietf.org/internet-drafts/draft-subbarao-mobileip-multipleip-00 > .txt > > Thanks, > Madhavi From owner-mobile-ip@sunroof.eng.sun.com Wed May 2 17:07:50 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23539 for ; Wed, 2 May 2001 17:07:50 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA11812; Wed, 2 May 2001 14:07:40 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA19143; Wed, 2 May 2001 14:06:10 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42L4pIM004971 for ; Wed, 2 May 2001 14:04:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f42L4poT004970 for mobile-ip-dist; Wed, 2 May 2001 14:04:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42L4gIM004963 for ; Wed, 2 May 2001 14:04:42 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA05216 for ; Wed, 2 May 2001 14:04:22 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05728 for ; Wed, 2 May 2001 14:04:21 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f42L4Hj11024 for ; Wed, 2 May 2001 14:04:17 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AFB06392; Wed, 2 May 2001 14:04:15 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA13967; Wed, 2 May 2001 14:04:15 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15088.30287.577756.221752@thomasm-u1.cisco.com> Date: Wed, 2 May 2001 14:04:15 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: mobile-ip] Multiple flows with single NAI In-Reply-To: <20010502165618.A14879@cisco.com> References: <85AA7486A2C1D411BCA20000F8073E43020D5F96@crchy271.us.nortel.com> <20010502165618.A14879@cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Madhavi Subbarao writes: > On Tue, May 01, 2001 at 11:19:29AM -0500, Glenn Morrow wrote: > > Madhavi, > > > > > > Are you thinking of the NAI as a: > > > > subscription identifier > > user identifier > > Equipment identifier? > > As a user identifier. The NAI identifies the user, not the device. Hmm. I'm mat@cisco.com, luser. I don't think an NAI expresses that meaning. I thought an NAI was an _interface_ identifier. Mike From owner-mobile-ip@sunroof.eng.sun.com Wed May 2 17:59:57 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24848 for ; Wed, 2 May 2001 17:59:57 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA20870; Wed, 2 May 2001 14:59:41 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA01238; Wed, 2 May 2001 14:59:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42Lw4IM005299 for ; Wed, 2 May 2001 14:58:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f42Lw3Ax005298 for mobile-ip-dist; Wed, 2 May 2001 14:58:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42LvtIM005291 for ; Wed, 2 May 2001 14:57:55 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA23044 for ; Wed, 2 May 2001 14:57:16 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15702 for ; Wed, 2 May 2001 14:57:15 -0700 (PDT) Received: from msubbara-u10.cisco.com (msubbara-u10.cisco.com [64.102.66.20]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f42LvhK20260 for ; Wed, 2 May 2001 14:57:43 -0700 (PDT) Received: (msubbara@localhost) by msubbara-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA14956 for mobile-ip@sunroof.eng.sun.com; Wed, 2 May 2001 17:56:44 -0400 (EDT) Date: Wed, 2 May 2001 17:56:44 -0400 From: Madhavi Subbarao To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: mobile-ip] Re: mobile-ip] Multiple flows with single NAI Message-ID: <20010502175644.A14942@cisco.com> References: <85AA7486A2C1D411BCA20000F8073E43020D5F96@crchy271.us.nortel.com> <20010502165618.A14879@cisco.com> <15088.30287.577756.221752@thomasm-u1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15088.30287.577756.221752@thomasm-u1.cisco.com>; from mat@cisco.com on Wed, May 02, 2001 at 02:04:15PM -0700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Wed, May 02, 2001 at 02:04:15PM -0700, Michael Thomas wrote: > Madhavi Subbarao writes: > > On Tue, May 01, 2001 at 11:19:29AM -0500, Glenn Morrow wrote: > > > Madhavi, > > > > > > > > > Are you thinking of the NAI as a: > > > > > > subscription identifier > > > user identifier > > > Equipment identifier? > > > > As a user identifier. The NAI identifies the user, not the device. > > Hmm. I'm mat@cisco.com, luser. I don't think an NAI Hmmm...I'm sure you didn't mean to say 'loser'... Careful with your typing... > expresses that meaning. I thought an NAI was an > _interface_ identifier. From RFC 2486: "...it is desirable to have a standardized method for identifying users. This document proposes syntax for the Network Access Identifier (NAI), the userID submitted by the client during PPP authentication..." -Madhavi > Mike From owner-mobile-ip@sunroof.eng.sun.com Wed May 2 18:11:57 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25119 for ; Wed, 2 May 2001 18:11:56 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA09894; Wed, 2 May 2001 15:11:49 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA26909; Wed, 2 May 2001 15:11:28 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42M9TIM005420 for ; Wed, 2 May 2001 15:09:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f42M9TlF005419 for mobile-ip-dist; Wed, 2 May 2001 15:09:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42M9KIM005412 for ; Wed, 2 May 2001 15:09:21 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id PAA11778; Wed, 2 May 2001 15:09:21 -0700 (PDT) Message-Id: <200105022209.PAA11778@heliopolis.eng.sun.com> Date: Wed, 2 May 2001 15:09:21 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] LMM Requirements To: James.Kempf@Sun.COM, mobile-ip@sunroof.eng.sun.com, Basavaraj.Patil@nokia.com Cc: carl.williams@eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Hn1s3eTLks7+HTi1q0mllw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Raj, >I do not believe we have WG consensus yet (other than a few views) on >this issue. Maybe we need to do a consensus call on just this >requirement and hope that we have a wider response. So if we were to >do a consensus call on this requirement then the question to the WG >would be: >1. Is support for multilevel hierarchies a requirement for LMM? >2. A single level of hierarchy is sufficient as the requirements for >LMM can be met by engineering the network right. > >Do you agree with the above if we were to do a consensus call... Actually, no. I much prefer a set of functional requirements as opposed to a structural one. Something like: The protocol shall support the ability to optimize local signalling paths without changing the externally visible CoA so as to reduce or eliminate frequent end to end BU signalling in cases where network engineering or administrative/deployment considerations require small LMM domains. The protocol shall support optimal placement of LMM agents to reduce or elminate additional triangle routing introduced by LMM. These leave open exactly how to achieve the required functionality. Hierarchy is one way, another way that might work is using edge tunnels as PhilN has suggested. There may even be ways to modify HMIP to achieve these requirements. jak From owner-mobile-ip@sunroof.eng.sun.com Thu May 3 05:07:39 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA17614 for ; Thu, 3 May 2001 05:07:38 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA21294; Thu, 3 May 2001 02:04:20 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA13767; Thu, 3 May 2001 02:04:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f4392QIM006094 for ; Thu, 3 May 2001 02:02:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f4392PV2006093 for mobile-ip-dist; Thu, 3 May 2001 02:02:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f4392FIM006086 for ; Thu, 3 May 2001 02:02:15 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA26687 for ; Thu, 3 May 2001 02:02:15 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA20367 for ; Thu, 3 May 2001 02:02:13 -0700 (PDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f4392CO00292 for ; Thu, 3 May 2001 11:02:12 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Thu May 03 11:02:11 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 3 May 2001 11:02:18 +0200 Message-ID: <5F03ACA2F76DD411B8BC00508BE3B4D7EA2E93@esemont203.gbg.edt.ericsson.se> From: "Simon Aladdin (ERV)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] help me,please Date: Thu, 3 May 2001 11:02:31 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="gb2312" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Tang ! The terms are as follow: AR Access Router. Most discussed together within the Mobile IP Working Group (WG) and Hierarchical Mobile IP (HMIP). However Access Router is generally known to be a border router where it interface foreign network and usually has an access list of the allowed users. MAP Mobility Anchor Point, originated from the HMIP drafted by Hesham Soliman et al. BU Binding Update, is a classical word known by the Mobile IP. More explanation you may find in the following links http://search.ietf.org/search/brokers/internet-drafts/query.html -----Original Message----- From: tang [mailto:tangh@cqupt.edu.cn] Sent: den 28 april 2001 09:40 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] help me,please hi,everyone I'm interesting in MOBILE IP,but some terms are strange to me,such as AR ,MAP,BU...etc. Please tell me about these or tell me where I can find these terms' explanation . thanks. tang From owner-mobile-ip@sunroof.eng.sun.com Thu May 3 08:06:29 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA19927 for ; Thu, 3 May 2001 08:06:28 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA16215; Thu, 3 May 2001 05:06:10 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA29845; Thu, 3 May 2001 05:06:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43C4fIM006203 for ; Thu, 3 May 2001 05:04:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f43C4fLh006202 for mobile-ip-dist; Thu, 3 May 2001 05:04:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43C4WIM006195 for ; Thu, 3 May 2001 05:04:32 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA10562 for ; Thu, 3 May 2001 05:04:31 -0700 (PDT) Received: from p-mail1.cnet.fr (p-mail1.rd.francetelecom.fr [193.49.124.31]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id FAA14995 for ; Thu, 3 May 2001 05:04:30 -0700 (PDT) Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Thu, 3 May 2001 14:04:09 +0200 Received: from francetelecom.com (p-dico.rd.francetelecom.fr [139.100.18.135]) by p-grive.rd.francetelecom.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KD74DXWS; Thu, 3 May 2001 14:04:01 +0200 Message-ID: <3AF148E1.9CA23364@francetelecom.com> Date: Thu, 03 May 2001 14:02:41 +0200 From: Jean-Michel COMBES Organization: France =?iso-8859-1?Q?T=E9l=E9com?= R&D X-Mailer: Mozilla 4.7 [fr] (WinNT; U) X-Accept-Language: fr MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Authenticating BU and PKI References: <3AE6F2DB.88661142@crm.mot.com> <3AED5196.4771F69@nomadiclab.com> <3AED6D36.26EEA17B@francetelecom.com> <3AEE4E79.46F6C879@nomadiclab.com> <3AEFE6D0.92446410@francetelecom.com> <3AEFEC8D.4DC8F389@nomadiclab.com> <3AF01543.ECA45B63@francetelecom.com> <3AF0473B.3C6E73E1@nomadiclab.com> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by patan.sun.com id FAA16215 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA19927 Pekka Nikander a écrit : > Jean-Michel COMBES wrote: > > > > Right. The HA knows that. But who tells the CN which HA to use? > > > > JMC : > > I don't understand ... this is the HA that sends informations ... > > Even if so, IP source address spoofing is easy. JMC : agree > If the HA sends > a packet to the CN, how does the CN know that it really came > from the HA? JMC : the CN doesn't need to know that the informations come from HA (or another home network entity such as AAAH, etc.) > You cannot assume that there is some security association > between them, since there can't be, yet. JMC : agree ... but sending MN's certificate doesn't need to have a SA. The certificate is signed and so CN can verify information authenticity. JMC. > > > --Pekka -- France Telecom R&D - DTL/SSR Jean-Michel COMBES, Internet/Intranet Security E-Mail : jeanmichel.combes@francetelecom.com Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19 PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214 From owner-mobile-ip@sunroof.eng.sun.com Thu May 3 08:32:10 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA20856 for ; Thu, 3 May 2001 08:32:10 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA04670; Thu, 3 May 2001 05:31:26 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA07288; Thu, 3 May 2001 05:31:10 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43CTBIM006240 for ; Thu, 3 May 2001 05:29:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f43CTAn7006239 for mobile-ip-dist; Thu, 3 May 2001 05:29:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43CT1IM006231 for ; Thu, 3 May 2001 05:29:01 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA06988 for ; Thu, 3 May 2001 05:29:02 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA29933 for ; Thu, 3 May 2001 05:29:01 -0700 (PDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id FAA14936 for ; Thu, 3 May 2001 05:29:01 -0700 (MST)] Received: [from m-il06-r4.mot.com (m-il06-r4.mot.com [129.188.137.196]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id FAA19036 for ; Thu, 3 May 2001 05:29:00 -0700 (MST)] Received: from [140.101.173.9] by m-il06-r4.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Thu, 3 May 2001 05:28:54 -0700 Received: (from root@localhost) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) id OAA09009 for mobile-ip@sunroof.eng.sun.com.DELIVER; Thu, 3 May 2001 14:28:16 +0200 (METDST) Received: from crm.mot.com (nero.crm.mot.com [140.101.173.36]) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) with ESMTP id OAA08968; Thu, 3 May 2001 14:28:14 +0200 (METDST) Message-Id: <3AF14ED6.3A168BDE@crm.mot.com> Date: Thu, 03 May 2001 14:28:06 +0200 From: Alexis Olivereau Organization: Centre de Recherche de Motorola - Paris X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com, Jean-Michel COMBES Subject: Re: [mobile-ip] Authenticating BU and PKI References: <3AE6F2DB.88661142@crm.mot.com> <3AED5196.4771F69@nomadiclab.com> <3AED6D36.26EEA17B@francetelecom.com> <3AEE4E79.46F6C879@nomadiclab.com> <3AEFE6D0.92446410@francetelecom.com> <3AEFEC8D.4DC8F389@nomadiclab.com> <3AF01543.ECA45B63@francetelecom.com> <3AF0473B.3C6E73E1@nomadiclab.com> <3AF148E1.9CA23364@francetelecom.com> Content-Type: multipart/mixed; boundary="------------9554BB7556075A5C83D554FF" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. --------------9554BB7556075A5C83D554FF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jean-Michel COMBES wrote: > > JMC : > agree ... but sending MN's certificate doesn't need to have a SA. The > certificate is signed and so CN can verify information authenticity. > Then the CN needs a PKI to check and use the certificate, so here we are with the same problem again... Alexis --------------9554BB7556075A5C83D554FF Content-Type: text/x-vcard; charset=us-ascii; name="Alexis.Olivereau.vcf" Content-Description: Card for Alexis Olivereau Content-Disposition: attachment; filename="Alexis.Olivereau.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Olivereau;Alexis tel;fax:+33 (0)1 69 35 25 01 tel;work:+33 (0)1 69 35 25 16 x-mozilla-html:TRUE org:MOTOROLA LABS;Networking and Applications Lab version:2.1 email;internet:Alexis.Olivereau@crm.mot.com title:Research Engineer adr;quoted-printable:;;Immeuble "Le Columbia"=0D=0AEspace Technologique St Aubin=0D=0A;Gif-sur-Yvette;;91193;FRANCE fn:Alexis Olivereau end:vcard --------------9554BB7556075A5C83D554FF-- From owner-mobile-ip@sunroof.eng.sun.com Thu May 3 10:47:35 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26180 for ; Thu, 3 May 2001 10:47:34 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA25265; Thu, 3 May 2001 07:47:01 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA05447; Thu, 3 May 2001 07:46:40 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43EibIM006346 for ; Thu, 3 May 2001 07:44:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f43EiblB006345 for mobile-ip-dist; Thu, 3 May 2001 07:44:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43EiSIM006338 for ; Thu, 3 May 2001 07:44:28 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA18840 for ; Thu, 3 May 2001 07:44:29 -0700 (PDT) Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id HAA07572 for ; Thu, 3 May 2001 07:44:27 -0700 (PDT) Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id KAA11504; Thu, 3 May 2001 10:44:23 -0400 Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Thu, 3 May 2001 10:44:10 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 May 2001 10:44:10 -0400 Message-ID: From: "Muhammad Jaseemuddin" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Final(?) Cut on LMM Requirements Date: Thu, 3 May 2001 10:44:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D3DF.82D48F30" X-Orig: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C0D3DF.82D48F30 Content-Type: text/plain > -----Original Message----- > From: Hesham Soliman (ERA) [SMTP:Hesham.Soliman@era.ericsson.se] > Sent: Tuesday, May 01, 2001 6:12 PM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] Final(?) Cut on LMM Requirements > > > => I don't really undersand your suggestion to not change the > CoA. > > The Fast Handoff draft is built around the fact that the MN will > > > change its CoA. There is one case where that fails (DAD for the > > new CoA) and the MN keeps the same address. But this is > > an error case and 99.99 % of the time it won't happen. > > > > [MJ] I know that fast handoff solution is built around that > assumption, and I am questioning that very basic assumption. I am saying > that it is LMM solution's forte to decide whether handing over to new AR > should involve new address assignment, especially within an AD. Hence, > fast handoff solution should be flexible in handling this situation. The > question is why fast handoff always assume change of address? > > > => Well That's what MIP does. MIP manages the change in CoA. > [MJ] Which COA? If LMM is deployed then MIP will manage RCOA not LCOA (I am using HMIP jargon). Hence, within an LMM domain no address assignment by FH doesn't mean that there is an FH-MIP interworking problem. > > Now, instead of always assuming new address assignment it can > provide in its signaling following options: > > > > 1. No new address assignment > > 2. Autoconfiguration, hence asking new AR to run DAD on behalf of MN > > 3. Stateful address assignment > > > > This will make fast handoff solution quite flexible and capable of > being defacto standard handover signaling for any LMM. > > > => I think it already works with LMM. Both scenarios > in the Fast Handoff draft can work with an LMM solution. > At least with HMIPv6 I don't see any problem. Based on this > requirement we were going to add a section in the draft > to show that this interworking is possible. But I'm not > sure what the aim of fixing the address is. Anyway, my > point is if you're saying this to make it easier for FH to > work with LMM, I think both cases would work whether > the address changes or not. > [MJ] Indeed it works with HMIPv6 if that is the only conceivable LMM solution we can think of. HMIPv6 requires MN to register LCOA, hence the MN has to first get LCOA and FH facilitate that process. But, if an LMM does not require MN to register a new LCOA, then FH doesn't work in that situation. Please read my comments to Charlie's email. I beleive that with small changes in FH will make it flexible enough to interwork with a variety of different LMM solutions. > > Although, I am making this statement but with one caveat that I don't > know how fast handoff and CT will work together. I think this discussion > should be moved to fast handoff design team mailing list, but my > understanding is that it is closed. > > > => I think we can discuss it on this list. The design team's > list hasn't been used for a long time now. > > > > BTW, Hesham how did you get this 99.99% reliability number, through some > simulation? > > > => No, I was trying to explain that it is a very rare probability > that > a collision would occur considering the 2^64 different IDs in IPv6 > in case > a random number was used or the probability of an L2 device vendor > to reuse the same MAC address. Just making a point, I hope no one > starts a simulation on this one too ;) > [MJ] I hop so too. > Hesham > > - Muhammad Jaseemuddin > > Hesham > > ------_=_NextPart_001_01C0D3DF.82D48F30 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Final(?) Cut on LMM Requirements

    -----Original Message-----
    From:   Hesham Soliman (ERA) = [SMTP:Hesham.Soliman@era.ericsson.se]
    Sent:   Tuesday, May 01, 2001 6:12 PM
    To:     'mobile-ip@sunroof.eng.sun.com'
    Subject:       = RE: [mobile-ip] Final(?) Cut on LMM = Requirements

    >         = =3D> I don't really undersand your suggestion to not change the CoA. =
    >         The = Fast Handoff draft is built around the fact that the MN will
    >         = change its CoA. There is one case where that fails (DAD for the
    >         new = CoA) and the MN keeps the same address. But this is
    >         an = error case and 99.99 % of the time it won't happen.
    >
    >       = [MJ]  I know that fast handoff solution is built around that = assumption, and I am questioning that very basic assumption. I am = saying that it is LMM solution's forte to decide whether handing over = to new AR should involve new address assignment, especially within an = AD. Hence, fast handoff solution should be flexible in handling this = situation. The question is why fast handoff always assume change of = address?

    >
            =3D> Well That's what MIP does. MIP manages the = change in CoA.

    [MJ]  Which COA? If LMM is deployed then MIP will = manage RCOA not LCOA (I am using HMIP jargon). Hence, within an LMM = domain no address assignment by FH doesn't mean that there is an FH-MIP = interworking problem.

     
    >       = Now, instead of always assuming new address assignment it can provide = in its signaling following options:
    >
    >       = 1. No new address assignment
    > 2. Autoconfiguration, hence = asking new AR to run DAD on behalf of MN
    > 3. Stateful address assignment =
    >
    >       = This will make fast handoff solution quite flexible and capable of = being defacto standard handover signaling for any LMM.

    >
            =3D> I think it already works with LMM. Both = scenarios
            in the Fast Handoff draft can work with an LMM = solution.
            At least with HMIPv6 I don't see any problem. Based on = this
            requirement we were going to add a section in the draft =
            to show that this interworking is possible. But I'm not =
            sure what the aim of fixing the address is. Anyway, my =
            point is if you're saying this to make it easier for FH = to
            work with LMM, I think both cases would work whether =
            the address changes or not.

    [MJ]  Indeed it works with HMIPv6 if that is the = only conceivable LMM solution we can think of. HMIPv6 requires MN to = register LCOA, hence the MN has to first get LCOA and FH facilitate = that process. But, if an LMM does not require MN to register a new = LCOA, then FH doesn't work in that situation. Please read my comments = to Charlie's email. I beleive that with small changes in FH will make = it flexible enough to interwork with a variety of different LMM = solutions.


    > Although, I am making this = statement but with one caveat that I don't know how fast handoff and CT = will work together. I think this discussion should be moved to fast = handoff design team mailing list, but my understanding is that it is = closed.

    >
            =3D> I think we can discuss it on this list. The = design team's
            list hasn't been used for a long time now.


    > BTW, Hesham how did you get this = 99.99% reliability number, through some simulation?
    >
            =3D> No, I was trying to explain that it is a very = rare probability that
            a collision would occur considering the 2^64 different = IDs in IPv6 in case
            a random number was used or the probability of an L2 = device vendor
            to reuse the same MAC address. Just making a point, I = hope no one
            starts a simulation on this one too ;)

    [MJ]  I hop so too.

            Hesham
            

    - Muhammad = Jaseemuddin

    >       =         Hesham
    >

------_=_NextPart_001_01C0D3DF.82D48F30-- From owner-mobile-ip@sunroof.eng.sun.com Thu May 3 12:01:28 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28356 for ; Thu, 3 May 2001 12:01:27 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA00091; Thu, 3 May 2001 09:00:28 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12130; Thu, 3 May 2001 08:54:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43FqWIM006451 for ; Thu, 3 May 2001 08:52:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f43FqVRp006450 for mobile-ip-dist; Thu, 3 May 2001 08:52:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43FqKIM006443 for ; Thu, 3 May 2001 08:52:20 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA21951; Thu, 3 May 2001 08:52:20 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA22457; Thu, 3 May 2001 08:52:16 -0700 (PDT) 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 IAA25321; Thu, 3 May 2001 08:52:12 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f43FqAX19264; Thu, 3 May 2001 08:52:10 -0700 X-mProtect: Thu, 3 May 2001 08:52:10 -0700 Nokia Silicon Valley Messaging Protection Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdBu7nVF; Thu, 03 May 2001 08:52:01 PDT Message-ID: <3AF17EA2.C8730F03@iprg.nokia.com> Date: Thu, 03 May 2001 08:52:02 -0700 From: Theo Pagtzis Organization: UCL/NOKIA X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386) X-Accept-Language: el, en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: James.Kempf@Sun.COM, Basavaraj.Patil@nokia.com, carl.williams@eng.sun.com Subject: Re: [mobile-ip] LMM Requirements References: <200105022209.PAA11778@heliopolis.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Raj, I would agree with Jak here. The reason: So far we have relied on a WG consensus (so far partial) to bring some LMM scheme as a WG item. You or others in the constituency must have witnessed that such decision was only somewhat "superficial" (with all due respect to anyone involved) since we have found ourselves working _now_ on a set of post-mortem requirements for LMMs. I can thus argue that one could expect that concensus decision on questions raised are bound to find similar "luck". Simply because not everybody can cope with the volume of emails that are flooding the MIP/Seamoby/FooMobility lists...So it is guaranteed that some individuals although they would like to concede to these questions with some answer, they are bound to see them much later when they try to "catch up". For that I would thus, second the sounder approach of having such functional set of requirements that is there with the additions or deletions that we want to see in (at least whoever is actively involved in the issue) and then leave it for individual to peruse and elaborate some more when they have the time.. That is use the list as a carrier of info not as signalling for concensus since the amount of nodes in inversely proportional to the volume of mail traffic flooding the aforementioned lists. (from a protocol perspective... :) I do not know how the rest feel about it James Kempf wrote: > Hi Raj, > > >I do not believe we have WG consensus yet (other than a few views) on > >this issue. Maybe we need to do a consensus call on just this > >requirement and hope that we have a wider response. So if we were to > >do a consensus call on this requirement then the question to the WG > >would be: > >1. Is support for multilevel hierarchies a requirement for LMM? > >2. A single level of hierarchy is sufficient as the requirements for > >LMM can be met by engineering the network right. > > > >Do you agree with the above if we were to do a consensus call... > > Actually, no. I much prefer a set of functional requirements as opposed to > a structural one. Something like: > > The protocol shall support the ability to optimize local signalling > paths without changing the externally visible CoA so as to reduce > or eliminate frequent end to end BU signalling in cases where network > engineering or administrative/deployment considerations require > small LMM domains. > > > The protocol shall support optimal placement of LMM agents to > reduce or elminate additional triangle routing introduced by > LMM. > The placement is closely related to the configuration issue which proves to me once more the need to be included in even if it has to commence from manual approaches (that must be extend to a dynamic form so as the LMM scheme can scale - Theo UCL/Mobile Systems From owner-mobile-ip@sunroof.eng.sun.com Thu May 3 12:21:55 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29026 for ; Thu, 3 May 2001 12:21:54 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00912; Thu, 3 May 2001 09:21:31 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA07858; Thu, 3 May 2001 09:21:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43GJBIM006496 for ; Thu, 3 May 2001 09:19:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f43GJAu5006495 for mobile-ip-dist; Thu, 3 May 2001 09:19:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43GJ1IM006488 for ; Thu, 3 May 2001 09:19:02 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA05489 for ; Thu, 3 May 2001 09:19:02 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA11611 for ; Thu, 3 May 2001 09:19:01 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f43GHDH06271 for ; Thu, 3 May 2001 09:17:25 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AFC02241; Thu, 3 May 2001 09:18:35 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA14263; Thu, 3 May 2001 09:18:35 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15089.34010.877977.641079@thomasm-u1.cisco.com> Date: Thu, 3 May 2001 09:18:34 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Authenticating BU and PKI In-Reply-To: <3AF0473B.3C6E73E1@nomadiclab.com> References: <3AE6F2DB.88661142@crm.mot.com> <3AED5196.4771F69@nomadiclab.com> <3AED6D36.26EEA17B@francetelecom.com> <3AEE4E79.46F6C879@nomadiclab.com> <3AEFE6D0.92446410@francetelecom.com> <3AEFEC8D.4DC8F389@nomadiclab.com> <3AF01543.ECA45B63@francetelecom.com> <3AF0473B.3C6E73E1@nomadiclab.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Pekka Nikander writes: > Jean-Michel COMBES wrote: > > > > Right. The HA knows that. But who tells the CN which HA to use? > > > > JMC : > > I don't understand ... this is the HA that sends informations ... > > Even if so, IP source address spoofing is easy. If the HA sends > a packet to the CN, how does the CN know that it really came > from the HA? You cannot assume that there is some security association > between them, since there can't be, yet. The CN can form the HA's address by forming a Home Agents Anycast address as described in -13. As for how do you know that the HA is sending the information -- just as well as the CN knows that the MN is sending the information. Meaning, to the degree you trust the integrity of the routing system, you can trust replies from the MN's home agent about as much as replies from the MN itself. Mike From owner-mobile-ip@sunroof.eng.sun.com Thu May 3 12:27:15 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29217 for ; Thu, 3 May 2001 12:27:14 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06478; Thu, 3 May 2001 09:27:01 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA29495; Thu, 3 May 2001 09:26:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43GOPIM006513 for ; Thu, 3 May 2001 09:24:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f43GOPUR006512 for mobile-ip-dist; Thu, 3 May 2001 09:24:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43GOGIM006505 for ; Thu, 3 May 2001 09:24:16 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA08758 for ; Thu, 3 May 2001 09:24:11 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA26973 for ; Thu, 3 May 2001 10:54:38 -0600 (MDT) 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 JAA28194 for ; Thu, 3 May 2001 09:24:10 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f43GO8R12702 for ; Thu, 3 May 2001 09:24:08 -0700 X-mProtect: Thu, 3 May 2001 09:24:08 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpd6gxfYW; Thu, 03 May 2001 09:24:02 PDT Message-ID: <3AF18624.51821CC4@iprg.nokia.com> Date: Thu, 03 May 2001 09:24:04 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] LMM Requirements References: <7B5C0390ACE7D211BC9C0008C7EABA2B03213949@daeis07nok> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Basavaraj, > I do not believe we have WG consensus yet (other than a few views) on > this issue. Maybe we need to do a consensus call on just this > requirement and hope that we have a wider response. So if we were to > do a consensus call on this requirement then the question to the WG > would be: > 1. Is support for multilevel hierarchies a requirement for LMM? I would say yes. > 2. A single level of hierarchy is sufficient as the requirements for > LMM can be met by engineering the network right. I could also say yes to this question also, as you have phrased it, if "right" is interpreted in a particular way. If "right" is interpreted instead to mean "according to the best possible technology" then I would disagree. ====================================================================== The problem is not whether restriction to single-level hierarchy CAN be done, it's whether it SHOULD be done. And to me it is obvious both that the restriction CAN be made; in fact, the current restriction is to zero levels, which proves that one level can be done. To re-re-reiterate: - Multilevel topologies are much more natural from the standpoint of how networks will actually be laid out - There are performance gains to be had - Making the restriction to single-level hierarchy doesn't buy much, if anything, in terms of protocol simplification. Besides, if protocol simplification is a goal, we should first eliminate basic mode. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu May 3 12:37:07 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29459 for ; Thu, 3 May 2001 12:37:06 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15396; Thu, 3 May 2001 09:36:33 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA11954; Thu, 3 May 2001 09:36:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43GXuIM006546 for ; Thu, 3 May 2001 09:33:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f43GXuR3006545 for mobile-ip-dist; Thu, 3 May 2001 09:33:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43GXlIM006538 for ; Thu, 3 May 2001 09:33:48 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA01300 for ; Thu, 3 May 2001 09:33:48 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13007 for ; Thu, 3 May 2001 09:33:42 -0700 (PDT) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f43Ga0w06086 for ; Thu, 3 May 2001 11:36:10 -0500 (CDT) Received: from daebh01nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 3 May 2001 11:33:26 -0500 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Thu, 3 May 2001 11:33:25 -0500 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B0321395F@daeis07nok> To: James.Kempf@Sun.COM, mobile-ip@sunroof.eng.sun.com Cc: carl.williams@eng.sun.com Subject: RE: [mobile-ip] LMM Requirements Date: Thu, 3 May 2001 11:33:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: James, I hope Carl has noted the functional requirement. I can live with that. Some thoughts though below: >James wrote: >Hi Raj, ----cut------------ > >Actually, no. I much prefer a set of functional requirements as opposed to >a structural one. Something like: > > The protocol shall support the ability to optimize local signalling > paths without changing the externally visible CoA so as to reduce > or eliminate frequent end to end BU signalling in cases where network > engineering or administrative/deployment considerations require > small LMM domains. > The key problem to be solved with LMM is to reduce the end-to-end BU signaling caused by change in COA. You cannot avoid doing e2e BUs in certain cases. So if you have very small LMM domains for reasons that you state, you will see a lot more BUs to CNs. How big a concern is that? If a MN and CN have an active data session ongoing, the change in COA is notified to the CN via a BU in one of the data packets (part of the active session stream). So there is no real overhead involved in sending that BU. And there is no urgency to get that BU to the CN either as the fast HO mechanism should ensure that packets sent to the pevious COA continue to reach the MN at it's new COA. So if the MN has active sessions with 'n' CNs, the BUs to all 'n' CNs is carried as part of the traffic. The only overhead is the BU DO carried in a few packets. But do we really need to optimize that? If the MN is an idle/dormant state and changes it's COA, and as a result has to notify 'n' number of CNs about the new COA, then it's an overhead. Ideally (just a thought) a MN should send a binding cancellation to the CN at the end of an active session and remove it from it's binding cache. That way the MN would not have to send BUs to CNs, but just to it's HA. And that's probably not a big deal even if it has to traverse long undersea cables. It can be a concern if you have a very large number of MNs changing COAs rapidly and as a result generating a lot of signaling (BUs) to their espective HAs. That's where an LMM agent would probably help. I view the sending BUs to all CNs in an MNs cache as a bigger concern than sending BUs to an MNs HA. Does that make sense? But trying to reduce the signaling paths within the local domain? I do not see much benefit here. Can you elaborate on your view on trying to limit the signaling path in an LMM environment? Do you really see strong reasons for doing so? > The protocol shall support optimal placement of LMM agents to > reduce or elminate additional triangle routing introduced by > LMM. > >These leave open exactly how to achieve the required functionality. >Hierarchy is one way, another way that might work is using edge >tunnels as PhilN has suggested. There may even be ways to modify >HMIP to achieve these requirements. > > jak -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Thu May 3 13:19:31 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00817 for ; Thu, 3 May 2001 13:19:31 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA13974; Thu, 3 May 2001 10:18:54 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA20394; Thu, 3 May 2001 10:18:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43HGHIM006664 for ; Thu, 3 May 2001 10:16:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f43HGHXM006663 for mobile-ip-dist; Thu, 3 May 2001 10:16:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43HG8IM006656 for ; Thu, 3 May 2001 10:16:08 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA19769 for ; Thu, 3 May 2001 10:16:04 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA20699 for ; Thu, 3 May 2001 10:15:58 -0700 (PDT) Received: by zmamail03.zma.compaq.com (Postfix, from userid 12345) id 7DA95A53B; Thu, 3 May 2001 13:15:58 -0400 (EDT) Received: from exctay-gh03.tay.cpqcorp.net (exctay-gh03.tay.cpqcorp.net [16.103.129.53]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 74F88A735 for ; Thu, 3 May 2001 13:15:57 -0400 (EDT) Received: by exctay-gh03.tay.cpqcorp.net with Internet Mail Service (5.5.2652.78) id ; Thu, 3 May 2001 13:15:57 -0400 Message-ID: <88BD5A70CA8BFA4CA15D0ED053E49D69245725@tayexc14.americas.cpqcorp.net> From: "Powell, Ken" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Authenticating BU and PKI Date: Thu, 3 May 2001 13:15:49 -0400 X-Mailer: Internet Mail Service (5.5.2652.78) Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Thursday, May 03, 2001 12:19 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Authenticating BU and PKI > > The CN can form the HA's address by forming a > Home Agents Anycast address as described in -13. > As for how do you know that the HA is sending > the information -- just as well as the CN knows > that the MN is sending the information. Meaning, > to the degree you trust the integrity of the > routing system, you can trust replies from the > MN's home agent about as much as replies from > the MN itself. This may not work if there are multiple home agents on the home network. I expect a home agent will be able to support authentication of the mobile node only if it has a current home registration binding for that mobile node. Any message sent to the home agent's anycast address could go to any of the home agents on the network, not necessarily the one with the mobile node's home registration. From owner-mobile-ip@sunroof.eng.sun.com Thu May 3 13:26:38 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00960 for ; Thu, 3 May 2001 13:26:37 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00829; Thu, 3 May 2001 10:26:16 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA04547; Thu, 3 May 2001 10:25:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43HO9IM006702 for ; Thu, 3 May 2001 10:24:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f43HO8pZ006701 for mobile-ip-dist; Thu, 3 May 2001 10:24:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43HO0IM006694 for ; Thu, 3 May 2001 10:24:00 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA22029 for ; Thu, 3 May 2001 10:23:59 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA02537 for ; Thu, 3 May 2001 11:54:23 -0600 (MDT) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f43HO2g11418 for ; Thu, 3 May 2001 12:24:02 -0500 (CDT) Received: from daebh01nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 3 May 2001 12:23:51 -0500 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Thu, 3 May 2001 12:23:51 -0500 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B03213962@daeis07nok> To: James.Kempf@Sun.COM, mobile-ip@sunroof.eng.sun.com Cc: carl.williams@eng.sun.com Subject: RE: [mobile-ip] LMM Requirements Date: Thu, 3 May 2001 12:23:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello James, >James wrote: >Hi Raj, > -------cut-------- >>If a MN and CN have an active data session ongoing, the change >>in COA is notified to the CN via a BU in one of the data packets (part >>of the active session stream). So there is no real overhead involved >>in sending that BU. And there is no urgency to get that BU to the CN >>either as the fast HO mechanism should ensure that packets sent to the >>pevious COA continue to reach the MN at it's new COA. So if the MN has >>active sessions with 'n' CNs, the BUs to all 'n' CNs is carried as >>part of the traffic. The only overhead is the BU DO carried in a few >>packets. But do we really need to optimize that? >> > >This sounds like an argument against *any* LMM mechanism, or, at >least, any mechanism that involves an agent back in the network >like HMIP or RegReg. > Exactly. Just trying to rationalize the need for LMM. >Actually, I tend to agree with you. By using edge or mesh tunnels, you really >don't need an LMM mechanism like HMIP or RegReg. With low latency >handoff, you can use a mesh tunnel to foward packets from the oAR to >smooth until the BU in the new packets takes effect. You can even >defer CoA change if the MN makes a quick switch to another subnet >or ping-pongs back to the original subnet. > >This is one reason why I'd like to see the protocol selection >opened up again. > Is protocol selection the only way? Let's get the requirements done and then look at what the optimal solution is. Do not let an existing WG document limit your views on requirements and possible solutions. >>If the MN is an idle/dormant state and changes it's COA, and as a >>result has to notify 'n' number of CNs about the new COA, then it's an >>overhead. > >If it's in an idle or dormant state, then it doesn't have any outstanding >CNs, right? Not necessarily. Current spec does not require a MN to delete an entry from it's binding cache explicitly. So you could have entries for CNs in the MNs cache which have not timed out yet when the MN goes into a dormant mode; If the MN changes it's COA in the dormant mode, the MN would start sending BUs to CNs in it's cache that have not timed out. >It could get paged by a new one, but that's a whole >other topic that Seamoby is dealing with. > But if it is being paged, it is an indication to establish a session (possibly) and the MN would send a BU once a session is active. >>Ideally (just a thought) a MN should send a binding >>cancellation to the CN at the end of an active session and remove it >>from it's binding cache. That way the MN would not have to send BUs to >>CNs, but just to it's HA. And that's probably not a big deal even if >>it has to traverse long undersea cables. It can be a concern if you >>have a very large number of MNs changing COAs rapidly and as a result >>generating a lot of signaling (BUs) to their espective HAs. That's >>where an LMM agent would probably help. >> > >Well, with mesh tunnels, the MN simply wouldn't change it's CoA until >its movement settled down or it didn't have an active connection up >(and hence had only to signal the HA of the CoA change). > That's one way. But not necessarily true in all types of networks. >I realize I'm now arguing for a particular solution, but the point >I'm trying to make is that the LMM solutions up until now were >designed with a particular viewpoint in mind that other solutions >that have been since proposed don't have. > Let's just step back and discuss requirements. >>I view the sending BUs to all CNs in an MNs cache as a bigger concern >>than sending BUs to an MNs HA. Does that make sense? >> > >Sure, if there are alot of them. > >>But trying to reduce the signaling paths within the local domain? I do >>not see much benefit here. Can you elaborate on your view on trying to >>limit the signaling path in an LMM environment? Do you really see >>strong reasons for doing so? >> > >See my business model argument above. One can argue about how >common it may be, of course. > I would prefer to not get into business model arguments on this iEtf list. We can take that offline. > jak -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Thu May 3 13:33:21 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01240 for ; Thu, 3 May 2001 13:33:20 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA07100; Thu, 3 May 2001 10:32:58 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA15464; Thu, 3 May 2001 10:32:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43HTlIM006721 for ; Thu, 3 May 2001 10:29:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f43HTkaG006720 for mobile-ip-dist; Thu, 3 May 2001 10:29:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43HTbIM006713 for ; Thu, 3 May 2001 10:29:38 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23467 for ; Thu, 3 May 2001 10:29:33 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA16633 for ; Thu, 3 May 2001 10:29:33 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f43HTad25348 for ; Thu, 3 May 2001 10:29:36 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AFC04236; Thu, 3 May 2001 10:29:27 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA14305; Thu, 3 May 2001 10:29:27 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15089.38263.279199.682100@thomasm-u1.cisco.com> Date: Thu, 3 May 2001 10:29:27 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] home agent discovery question In-Reply-To: <88BD5A70CA8BFA4CA15D0ED053E49D69245725@tayexc14.americas.cpqcorp.net> References: <88BD5A70CA8BFA4CA15D0ED053E49D69245725@tayexc14.americas.cpqcorp.net> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Powell, Ken writes: > > The CN can form the HA's address by forming a > > Home Agents Anycast address as described in -13. > > As for how do you know that the HA is sending > > the information -- just as well as the CN knows > > that the MN is sending the information. Meaning, > > to the degree you trust the integrity of the > > routing system, you can trust replies from the > > MN's home agent about as much as replies from > > the MN itself. > > This may not work if there are multiple home agents > on the home network. I expect a home agent will be > able to support authentication of the mobile node > only if it has a current home registration binding > for that mobile node. Any message sent to the home > agent's anycast address could go to any of the home > agents on the network, not necessarily the one > with the mobile node's home registration. I would think that that would affect home agent discovery in general. That said, Steve Deering mentioned to me a while ago that he didn't see how the home agent anycast couldn't be formed without the knowledge of the subnet mask to form the prefix correctly. So is the implication that the mobile node not only needs to know its home address, but the subnet prefix as well when it's doing home agent discovery? This all sounds rather, well, not very automatic to me, and would have problems with renumbering, etc, etc. Mike From owner-mobile-ip@sunroof.eng.sun.com Thu May 3 13:34:11 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01286 for ; Thu, 3 May 2001 13:34:10 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA07777; Thu, 3 May 2001 10:33:34 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA15834; Thu, 3 May 2001 10:33:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43HV8IM006741 for ; Thu, 3 May 2001 10:31:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f43HV7ro006740 for mobile-ip-dist; Thu, 3 May 2001 10:31:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43HUqIM006733 for ; Thu, 3 May 2001 10:30:53 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id KAA29497; Thu, 3 May 2001 10:30:52 -0700 (PDT) Message-Id: <200105031730.KAA29497@heliopolis.eng.sun.com> Date: Thu, 3 May 2001 10:30:52 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] LMM Requirements To: James.Kempf@Sun.COM, mobile-ip@sunroof.eng.sun.com, Basavaraj.Patil@nokia.com Cc: carl.williams@eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: r6u9Tef5DoamcCIqOGcY5w== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Raj, > >Not necessarily. Current spec does not require a MN to delete an entry >from it's binding cache explicitly. So you could have entries for CNs >in the MNs cache which have not timed out yet when the MN goes into >a dormant mode; If the MN changes it's COA in the dormant mode, the MN >would start sending BUs to CNs in it's cache that have not timed out. > I don't want to get into a detailed discussion of paging here, but one of the requirements with the paging DT in Seamoby is that the MN notify the network when it goes into dormant mode. The paging protocol is not specific to MIP, but the consequences of this for MIP would be that the MN send BUs to the CNs to have them delete their binding cache entries. >But if it is being paged, it is an indication to establish a session >(possibly) and the MN would send a BU once a session is active. > Well, I would imagine for MIP that a page would cause the MN to reestablish a CoA with it's local AR, then register with HA at which point it would get the packet that triggered the page. But this is very MIP specific, and we are not there yet in the paging DT discussions. jak From owner-mobile-ip@sunroof.eng.sun.com Thu May 3 13:50:52 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01689 for ; Thu, 3 May 2001 13:50:51 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA12056; Thu, 3 May 2001 10:15:30 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA18566; Thu, 3 May 2001 10:01:55 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43GxRIM006625 for ; Thu, 3 May 2001 09:59:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f43GxQg4006624 for mobile-ip-dist; Thu, 3 May 2001 09:59:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43GxIIM006617 for ; Thu, 3 May 2001 09:59:18 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id JAA28394; Thu, 3 May 2001 09:59:17 -0700 (PDT) Message-Id: <200105031659.JAA28394@heliopolis.eng.sun.com> Date: Thu, 3 May 2001 09:59:18 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] LMM Requirements To: James.Kempf@Sun.COM, mobile-ip@sunroof.eng.sun.com, Basavaraj.Patil@nokia.com Cc: carl.williams@eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 5UbiRMW8Ih+rTBgR5bXJNA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Raj, >The key problem to be solved with LMM is to reduce the end-to-end BU >signaling caused by change in COA. You cannot avoid doing e2e BUs in >certain cases. So if you have very small LMM domains for reasons that >you state, you will see a lot more BUs to CNs. How big a concern is >that? The problem is, as I mentioned in my response to Juergin, that there are certain business models that would be harmed from not optimizing signalling when LMM domains are small. Suppose there are multiple small wireless providers in an area, and they all want to do optimized signalling in their domain, but they are peering with a larger ISP who would like to set up an LMM domain to allow customers of the smaller providers to switch LMM domains without requiring any global CoA signalling change. If the protocol doesn't support this, then it becomes difficult. I just don't think it is a good idea to design a protocol with restrictions about what network engineering would be required to efficiently support it. The protocol should be designed with reasonable restrictions on network engineering. >If a MN and CN have an active data session ongoing, the change >in COA is notified to the CN via a BU in one of the data packets (part >of the active session stream). So there is no real overhead involved >in sending that BU. And there is no urgency to get that BU to the CN >either as the fast HO mechanism should ensure that packets sent to the >pevious COA continue to reach the MN at it's new COA. So if the MN has >active sessions with 'n' CNs, the BUs to all 'n' CNs is carried as >part of the traffic. The only overhead is the BU DO carried in a few >packets. But do we really need to optimize that? > This sounds like an argument against *any* LMM mechanism, or, at least, any mechanism that involves an agent back in the network like HMIP or RegReg. Actually, I tend to agree with you. By using edge or mesh tunnels, you really don't need an LMM mechanism like HMIP or RegReg. With low latency handoff, you can use a mesh tunnel to foward packets from the oAR to smooth until the BU in the new packets takes effect. You can even defer CoA change if the MN makes a quick switch to another subnet or ping-pongs back to the original subnet. This is one reason why I'd like to see the protocol selection opened up again. >If the MN is an idle/dormant state and changes it's COA, and as a >result has to notify 'n' number of CNs about the new COA, then it's an >overhead. If it's in an idle or dormant state, then it doesn't have any outstanding CNs, right? It could get paged by a new one, but that's a whole other topic that Seamoby is dealing with. >Ideally (just a thought) a MN should send a binding >cancellation to the CN at the end of an active session and remove it >from it's binding cache. That way the MN would not have to send BUs to >CNs, but just to it's HA. And that's probably not a big deal even if >it has to traverse long undersea cables. It can be a concern if you >have a very large number of MNs changing COAs rapidly and as a result >generating a lot of signaling (BUs) to their espective HAs. That's >where an LMM agent would probably help. > Well, with mesh tunnels, the MN simply wouldn't change it's CoA until its movement settled down or it didn't have an active connection up (and hence had only to signal the HA of the CoA change). I realize I'm now arguing for a particular solution, but the point I'm trying to make is that the LMM solutions up until now were designed with a particular viewpoint in mind that other solutions that have been since proposed don't have. >I view the sending BUs to all CNs in an MNs cache as a bigger concern >than sending BUs to an MNs HA. Does that make sense? > Sure, if there are alot of them. >But trying to reduce the signaling paths within the local domain? I do >not see much benefit here. Can you elaborate on your view on trying to >limit the signaling path in an LMM environment? Do you really see >strong reasons for doing so? > See my business model argument above. One can argue about how common it may be, of course. jak From owner-mobile-ip@sunroof.eng.sun.com Thu May 3 13:52:48 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01755 for ; Thu, 3 May 2001 13:52:47 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24502; Thu, 3 May 2001 10:51:59 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA01350; Thu, 3 May 2001 10:51:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43HmIIM006814 for ; Thu, 3 May 2001 10:48:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f43HmFtJ006813 for mobile-ip-dist; Thu, 3 May 2001 10:48:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43HlbIM006804 for ; Thu, 3 May 2001 10:47:39 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA00351 for ; Thu, 3 May 2001 10:47:33 -0700 (PDT) Received: from prserv.net (out2.prserv.net [32.97.166.32] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA17116 for ; Thu, 3 May 2001 12:18:32 -0600 (MDT) Received: from [129.37.42.232] (slip-129-37-42-232.ca.us.prserv.net[129.37.42.232]) by prserv.net (out2) with ESMTP id <2001050317472920205q6gnde>; Thu, 3 May 2001 17:47:30 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: ahmrphd@pop3.attglobal.net Message-Id: In-Reply-To: <200105031659.JAA28394@heliopolis.eng.sun.com> Date: Thu, 3 May 2001 10:47:09 -0700 To: mobile-ip@sunroof.eng.sun.com, James.Kempf@Sun.COM, Basavaraj.Patil@nokia.com From: Arthur Ross Subject: RE: [mobile-ip] LMM Requirements Cc: carl.williams@eng.sun.com Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: At 9:59 -0700 05/03/2001, James Kempf wrote: > >I just don't think it is a good idea to design a protocol with restrictions >about what network engineering would be required to efficiently support >it. The protocol should be designed with reasonable restrictions on >network engineering. > YES! Very important point. >[snip] > >I realize I'm now arguing for a particular solution, but the point >I'm trying to make is that the LMM solutions up until now were >designed with a particular viewpoint in mind that other solutions >that have been since proposed don't have. > Throughout this debate it has seemed to me that the underlying architectural abstractions, business, and regulatory models are, to be charitable, a bit fuzzy ... many different, implicit, unstated mental views. I realize I'm back at one of those heated exchanges from some weeks back, but I still believe that these abstractions and models should be addressed FIRST (more?). I tend to believe that when the abstractions and the problem are properly stated, the solution(s) will come rather easily. It's the unstated (unconcious?) differences in model that underlie a lot of this fractiousness. >>But trying to reduce the signaling paths within the local domain? I do >>not see much benefit here. Can you elaborate on your view on trying to >>limit the signaling path in an LMM environment? Do you really see >>strong reasons for doing so? >> > >See my business model argument above. One can argue about how >common it may be, of course. > Some of the LMM motivation has more to do with radio-ish issues than with signaling load ... like knowledge of where the MN might be, acquired through means other than network signaling. Comes back to the fact that wireless connectivity is "soft", with amelioration methods that are best distributed over the access points. ... and to come back to a point I tried long ago to make to the FCC regarding true spectrum sharing and cooperation, a la James' business model point - sometimes the laws of physics FORCE cooperation among service providers, regardless of what their attorneys, management, and business models would suggest, as in the real-world example of all those cellular & PCS calls from Manhattan high-rises that wind up being served by cell sites in New Jersey and Connecticut, sometimes many miles away; makes for interesting administrative problems, as well as technical ones. -- ahmr Dr. Arthur H. M. Ross 1004 Cottage Way Encinitas, CA 92024-5857 Tel: 760-634-8173 (Res.) 602-677-1021 (Portable) From owner-mobile-ip@sunroof.eng.sun.com Thu May 3 13:57:06 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01914 for ; Thu, 3 May 2001 13:57:00 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28614; Thu, 3 May 2001 10:56:43 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA12153; Thu, 3 May 2001 10:55:28 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43HqQIM006824 for ; Thu, 3 May 2001 10:52:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f43HqNmc006823 for mobile-ip-dist; Thu, 3 May 2001 10:52:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43HpkIM006816 for ; Thu, 3 May 2001 10:51:49 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA01415 for ; Thu, 3 May 2001 10:51:43 -0700 (PDT) Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA17044 for ; Thu, 3 May 2001 10:51:42 -0700 (PDT) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id MAA13545 for ; Thu, 3 May 2001 12:51:41 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f43HpeX07830 for ; Thu, 3 May 2001 12:51:40 -0500 (CDT) Message-ID: <3AF18C3D.A8860B47@usa.alcatel.com> Date: Thu, 03 May 2001 12:50:05 -0400 From: Behcet Sarikaya X-Mailer: Mozilla 4.76 [en]C-CCK-MCD BDPjm-Sony3 (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] LMM Requirements References: <7B5C0390ACE7D211BC9C0008C7EABA2B03213962@daeis07nok> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Here is a strange discussion. Once Alessio said paging is basically routing related therefore paging standardization should move to the routing area, i.e. under Mobile IP WG. Wouldn't you agree with it? Basavaraj.Patil@nokia.com wrote: > Hello James, > > >James wrote: > >Hi Raj, > > > -------cut-------- > >>If a MN and CN have an active data session ongoing, the change > >>in COA is notified to the CN via a BU in one of the data packets (part > >>of the active session stream). So there is no real overhead involved > >>in sending that BU. And there is no urgency to get that BU to the CN > >>either as the fast HO mechanism should ensure that packets sent to the > >>pevious COA continue to reach the MN at it's new COA. So if the MN has > >>active sessions with 'n' CNs, the BUs to all 'n' CNs is carried as > >>part of the traffic. The only overhead is the BU DO carried in a few > >>packets. But do we really need to optimize that? > >> > > > >This sounds like an argument against *any* LMM mechanism, or, at > >least, any mechanism that involves an agent back in the network > >like HMIP or RegReg. > > > > Exactly. Just trying to rationalize the need for LMM. > > >Actually, I tend to agree with you. By using edge or mesh tunnels, you > really > >don't need an LMM mechanism like HMIP or RegReg. With low latency > >handoff, you can use a mesh tunnel to foward packets from the oAR to > >smooth until the BU in the new packets takes effect. You can even > >defer CoA change if the MN makes a quick switch to another subnet > >or ping-pongs back to the original subnet. > > > >This is one reason why I'd like to see the protocol selection > >opened up again. > > > > Is protocol selection the only way? Let's get the requirements done > and then look at what the optimal solution is. Do not let an existing > WG document limit your views on requirements and possible solutions. > > >>If the MN is an idle/dormant state and changes it's COA, and as a > >>result has to notify 'n' number of CNs about the new COA, then it's an > >>overhead. > > > >If it's in an idle or dormant state, then it doesn't have any outstanding > >CNs, right? > > Not necessarily. Current spec does not require a MN to delete an entry > from it's binding cache explicitly. So you could have entries for CNs > in the MNs cache which have not timed out yet when the MN goes into > a dormant mode; If the MN changes it's COA in the dormant mode, the MN > would start sending BUs to CNs in it's cache that have not timed out. > > >It could get paged by a new one, but that's a whole > >other topic that Seamoby is dealing with. > > > > But if it is being paged, it is an indication to establish a session > (possibly) and the MN would send a BU once a session is active. > > >>Ideally (just a thought) a MN should send a binding > >>cancellation to the CN at the end of an active session and remove it > >>from it's binding cache. That way the MN would not have to send BUs to > >>CNs, but just to it's HA. And that's probably not a big deal even if > >>it has to traverse long undersea cables. It can be a concern if you > >>have a very large number of MNs changing COAs rapidly and as a result > >>generating a lot of signaling (BUs) to their espective HAs. That's > >>where an LMM agent would probably help. > >> > > > >Well, with mesh tunnels, the MN simply wouldn't change it's CoA until > >its movement settled down or it didn't have an active connection up > >(and hence had only to signal the HA of the CoA change). > > > > That's one way. But not necessarily true in all types of networks. > > >I realize I'm now arguing for a particular solution, but the point > >I'm trying to make is that the LMM solutions up until now were > >designed with a particular viewpoint in mind that other solutions > >that have been since proposed don't have. > > > > Let's just step back and discuss requirements. > > >>I view the sending BUs to all CNs in an MNs cache as a bigger concern > >>than sending BUs to an MNs HA. Does that make sense? > >> > > > >Sure, if there are alot of them. > > > >>But trying to reduce the signaling paths within the local domain? I do > >>not see much benefit here. Can you elaborate on your view on trying to > >>limit the signaling path in an LMM environment? Do you really see > >>strong reasons for doing so? > >> > > > >See my business model argument above. One can argue about how > >common it may be, of course. > > > > I would prefer to not get into business model arguments on this iEtf > list. We can take that offline. > > > jak > > -Basavaraj -- Behcet From owner-mobile-ip@sunroof.eng.sun.com Thu May 3 14:33:37 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02834 for ; Thu, 3 May 2001 14:33:36 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA22253; Thu, 3 May 2001 10:33:15 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA26557; Thu, 3 May 2001 10:32:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43HULIM006731 for ; Thu, 3 May 2001 10:30:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f43HULwu006730 for mobile-ip-dist; Thu, 3 May 2001 10:30:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43HUAIM006723 for ; Thu, 3 May 2001 10:30:10 -0700 (PDT) Received: from antley (antley.Eng.Sun.COM [129.146.86.225]) by jurassic.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with SMTP id f43HTmHD138900; Thu, 3 May 2001 10:29:48 -0700 (PDT) Message-Id: <200105031729.f43HTmHD138900@jurassic.eng.sun.com> Date: Thu, 3 May 2001 10:24:31 -0700 (PDT) From: Carl Williams Subject: RE: [mobile-ip] LMM Requirements To: James.Kempf@Sun.COM, mobile-ip@sunroof.eng.sun.com Cc: carl.williams@eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: QK+/FDFdNPNS10n1paDsrA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: James, I will structure the requirements as you suggested. I am reading over the discussions now as well as Phil's start of things. Carl X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f From: Basavaraj.Patil@nokia.com To: James.Kempf@Sun.COM, mobile-ip@sunroof.eng.sun.com Cc: carl.williams@eng.sun.com Subject: RE: [mobile-ip] LMM Requirements Date: Thu, 3 May 2001 11:33:23 -0500 MIME-Version: 1.0 List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: James, I hope Carl has noted the functional requirement. I can live with that. Some thoughts though below: >James wrote: >Hi Raj, ----cut------------ > >Actually, no. I much prefer a set of functional requirements as opposed to >a structural one. Something like: > > The protocol shall support the ability to optimize local signalling > paths without changing the externally visible CoA so as to reduce > or eliminate frequent end to end BU signalling in cases where network > engineering or administrative/deployment considerations require > small LMM domains. > The key problem to be solved with LMM is to reduce the end-to-end BU signaling caused by change in COA. You cannot avoid doing e2e BUs in certain cases. So if you have very small LMM domains for reasons that you state, you will see a lot more BUs to CNs. How big a concern is that? If a MN and CN have an active data session ongoing, the change in COA is notified to the CN via a BU in one of the data packets (part of the active session stream). So there is no real overhead involved in sending that BU. And there is no urgency to get that BU to the CN either as the fast HO mechanism should ensure that packets sent to the pevious COA continue to reach the MN at it's new COA. So if the MN has active sessions with 'n' CNs, the BUs to all 'n' CNs is carried as part of the traffic. The only overhead is the BU DO carried in a few packets. But do we really need to optimize that? If the MN is an idle/dormant state and changes it's COA, and as a result has to notify 'n' number of CNs about the new COA, then it's an overhead. Ideally (just a thought) a MN should send a binding cancellation to the CN at the end of an active session and remove it from it's binding cache. That way the MN would not have to send BUs to CNs, but just to it's HA. And that's probably not a big deal even if it has to traverse long undersea cables. It can be a concern if you have a very large number of MNs changing COAs rapidly and as a result generating a lot of signaling (BUs) to their espective HAs. That's where an LMM agent would probably help. I view the sending BUs to all CNs in an MNs cache as a bigger concern than sending BUs to an MNs HA. Does that make sense? But trying to reduce the signaling paths within the local domain? I do not see much benefit here. Can you elaborate on your view on trying to limit the signaling path in an LMM environment? Do you really see strong reasons for doing so? > The protocol shall support optimal placement of LMM agents to > reduce or elminate additional triangle routing introduced by > LMM. > >These leave open exactly how to achieve the required functionality. >Hierarchy is one way, another way that might work is using edge >tunnels as PhilN has suggested. There may even be ways to modify >HMIP to achieve these requirements. > > jak -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Thu May 3 14:40:59 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02984 for ; Thu, 3 May 2001 14:40:58 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05411; Thu, 3 May 2001 11:40:38 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA11150; Thu, 3 May 2001 11:40:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43IcJIM006885 for ; Thu, 3 May 2001 11:38:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f43IcJhO006884 for mobile-ip-dist; Thu, 3 May 2001 11:38:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43Ic9IM006877 for ; Thu, 3 May 2001 11:38:09 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13049 for ; Thu, 3 May 2001 11:38:08 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA15785 for ; Thu, 3 May 2001 11:38:07 -0700 (PDT) Received: by zmamail03.zma.compaq.com (Postfix, from userid 12345) id 72EE0A26F; Thu, 3 May 2001 14:38:06 -0400 (EDT) Received: from exctay-gh03.tay.cpqcorp.net (exctay-gh03.tay.cpqcorp.net [16.103.129.53]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 4C815AE9B for ; Thu, 3 May 2001 14:38:06 -0400 (EDT) Received: by exctay-gh03.tay.cpqcorp.net with Internet Mail Service (5.5.2652.78) id ; Thu, 3 May 2001 14:38:05 -0400 Message-ID: <88BD5A70CA8BFA4CA15D0ED053E49D69245731@tayexc14.americas.cpqcorp.net> From: "Powell, Ken" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] home agent discovery question Date: Thu, 3 May 2001 14:37:57 -0400 X-Mailer: Internet Mail Service (5.5.2652.78) Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Thursday, May 03, 2001 1:29 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] home agent discovery question > > > Powell, Ken writes: > > > The CN can form the HA's address by forming a > > > Home Agents Anycast address as described in -13. > > > As for how do you know that the HA is sending > > > the information -- just as well as the CN knows > > > that the MN is sending the information. Meaning, > > > to the degree you trust the integrity of the > > > routing system, you can trust replies from the > > > MN's home agent about as much as replies from > > > the MN itself. > > > > This may not work if there are multiple home agents > > on the home network. I expect a home agent will be > > able to support authentication of the mobile node > > only if it has a current home registration binding > > for that mobile node. Any message sent to the home > > agent's anycast address could go to any of the home > > agents on the network, not necessarily the one > > with the mobile node's home registration. > > I would think that that would affect home agent > discovery in general. Not really. When a mobile node does home agent discovery, it has no home registrations and needs to find a home agent so it can create one. In this case, any available home agent on the home network will do. > That said, Steve Deering mentioned > to me a while ago that he didn't see how the > home agent anycast couldn't be formed without > the knowledge of the subnet mask to form the > prefix correctly. So is the implication that > the mobile node not only needs to know its home > address, but the subnet prefix as well when > it's doing home agent discovery? You are right, that a mobile node needs to know the home subnet prefix length to generate a home agent anycast address from its own home address. Normally a mobile node will have both during normal operation. If a mobile node looses communication with its current home agent (perhaps the home agent crashed), it makes sense to use this information to generate the home agent anycast address and find a new home agent. On the other hand, when a mobile node boots on a remote network, it's previously configured home address may have timed-out. In this case, it should have another technique to find the home agent anycast address. Appendix B of the mobile IPv6 spec says this could be handled by storing the anycast address in DNS. > This all sounds rather, well, not very > automatic to me, and would have problems with > renumbering, etc, etc. I agree that we want automatic home address autoconfiguration and renumbering to work. Many of the details are beyond the scope of the spec. Appendix B provides one possible approach. T.J. Kniveton is working on a better method. Ken From owner-mobile-ip@sunroof.eng.sun.com Thu May 3 15:00:49 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04120 for ; Thu, 3 May 2001 15:00:48 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21180; Thu, 3 May 2001 12:00:21 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08051; Thu, 3 May 2001 11:59:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43IveIM006912 for ; Thu, 3 May 2001 11:57:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f43Iveea006911 for mobile-ip-dist; Thu, 3 May 2001 11:57:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43IvVIM006904 for ; Thu, 3 May 2001 11:57:31 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA17579 for ; Thu, 3 May 2001 11:57:31 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05689 for ; Thu, 3 May 2001 11:57:30 -0700 (PDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Thu, 3 May 2001 14:51:18 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] LMM Requirements Date: Thu, 3 May 2001 14:51:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Wrong answer for the time being. We've made an effort to focus MIP issues on issues pertaining to MIP. > -----Original Message----- > From: Behcet Sarikaya [mailto:behcet.sarikaya@usa.alcatel.com] > Sent: Thursday, May 03, 2001 12:50 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] LMM Requirements > > > Here is a strange discussion. > Once Alessio said paging is basically routing related therefore paging > standardization should move to the routing area, i.e. under > Mobile IP WG. > > Wouldn't you agree with it? > > Basavaraj.Patil@nokia.com wrote: > > > Hello James, > > > > >James wrote: > > >Hi Raj, > > > > > -------cut-------- > > >>If a MN and CN have an active data session ongoing, the change > > >>in COA is notified to the CN via a BU in one of the data > packets (part > > >>of the active session stream). So there is no real > overhead involved > > >>in sending that BU. And there is no urgency to get that > BU to the CN > > >>either as the fast HO mechanism should ensure that > packets sent to the > > >>pevious COA continue to reach the MN at it's new COA. So > if the MN has > > >>active sessions with 'n' CNs, the BUs to all 'n' CNs is carried as > > >>part of the traffic. The only overhead is the BU DO > carried in a few > > >>packets. But do we really need to optimize that? > > >> > > > > > >This sounds like an argument against *any* LMM mechanism, or, at > > >least, any mechanism that involves an agent back in the network > > >like HMIP or RegReg. > > > > > > > Exactly. Just trying to rationalize the need for LMM. > > > > >Actually, I tend to agree with you. By using edge or mesh > tunnels, you > > really > > >don't need an LMM mechanism like HMIP or RegReg. With low latency > > >handoff, you can use a mesh tunnel to foward packets from > the oAR to > > >smooth until the BU in the new packets takes effect. You can even > > >defer CoA change if the MN makes a quick switch to another subnet > > >or ping-pongs back to the original subnet. > > > > > >This is one reason why I'd like to see the protocol selection > > >opened up again. > > > > > > > Is protocol selection the only way? Let's get the requirements done > > and then look at what the optimal solution is. Do not let > an existing > > WG document limit your views on requirements and possible solutions. > > > > >>If the MN is an idle/dormant state and changes it's COA, and as a > > >>result has to notify 'n' number of CNs about the new COA, > then it's an > > >>overhead. > > > > > >If it's in an idle or dormant state, then it doesn't have > any outstanding > > >CNs, right? > > > > Not necessarily. Current spec does not require a MN to > delete an entry > > from it's binding cache explicitly. So you could have > entries for CNs > > in the MNs cache which have not timed out yet when the MN goes into > > a dormant mode; If the MN changes it's COA in the dormant > mode, the MN > > would start sending BUs to CNs in it's cache that have not > timed out. > > > > >It could get paged by a new one, but that's a whole > > >other topic that Seamoby is dealing with. > > > > > > > But if it is being paged, it is an indication to establish a session > > (possibly) and the MN would send a BU once a session is active. > > > > >>Ideally (just a thought) a MN should send a binding > > >>cancellation to the CN at the end of an active session > and remove it > > >>from it's binding cache. That way the MN would not have > to send BUs to > > >>CNs, but just to it's HA. And that's probably not a big > deal even if > > >>it has to traverse long undersea cables. It can be a > concern if you > > >>have a very large number of MNs changing COAs rapidly and > as a result > > >>generating a lot of signaling (BUs) to their espective HAs. That's > > >>where an LMM agent would probably help. > > >> > > > > > >Well, with mesh tunnels, the MN simply wouldn't change > it's CoA until > > >its movement settled down or it didn't have an active connection up > > >(and hence had only to signal the HA of the CoA change). > > > > > > > That's one way. But not necessarily true in all types of networks. > > > > >I realize I'm now arguing for a particular solution, but the point > > >I'm trying to make is that the LMM solutions up until now were > > >designed with a particular viewpoint in mind that other solutions > > >that have been since proposed don't have. > > > > > > > Let's just step back and discuss requirements. > > > > >>I view the sending BUs to all CNs in an MNs cache as a > bigger concern > > >>than sending BUs to an MNs HA. Does that make sense? > > >> > > > > > >Sure, if there are alot of them. > > > > > >>But trying to reduce the signaling paths within the local > domain? I do > > >>not see much benefit here. Can you elaborate on your view > on trying to > > >>limit the signaling path in an LMM environment? Do you really see > > >>strong reasons for doing so? > > >> > > > > > >See my business model argument above. One can argue about how > > >common it may be, of course. > > > > > > > I would prefer to not get into business model arguments on this iEtf > > list. We can take that offline. > > > > > jak > > > > -Basavaraj > > -- > Behcet > From owner-mobile-ip@sunroof.eng.sun.com Thu May 3 15:01:45 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04170 for ; Thu, 3 May 2001 15:01:45 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA22241; Thu, 3 May 2001 12:01:24 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA08410; Thu, 3 May 2001 12:00:55 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43IxMIM006922 for ; Thu, 3 May 2001 11:59:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f43IxMBD006921 for mobile-ip-dist; Thu, 3 May 2001 11:59:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43IxBIM006914 for ; Thu, 3 May 2001 11:59:11 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA16280 for ; Thu, 3 May 2001 11:59:11 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA28203 for ; Thu, 3 May 2001 11:59:10 -0700 (PDT) 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 LAA12733 for ; Thu, 3 May 2001 11:59:10 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f43Ix7w06871 for ; Thu, 3 May 2001 11:59:07 -0700 X-mProtect: Thu, 3 May 2001 11:59:07 -0700 Nokia Silicon Valley Messaging Protection Received: from tkniveto.iprg.nokia.com (205.226.2.111, claiming to be "Kniveton.com") by darkstar.iprg.nokia.com(P1.5 smtpdIcSyss; Thu, 03 May 2001 11:58:57 PDT Message-ID: <3AF1AA74.820286F1@Kniveton.com> Date: Thu, 03 May 2001 11:59:00 -0700 From: "T.J. Kniveton" Organization: NOKIA Research X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] home agent discovery question References: <88BD5A70CA8BFA4CA15D0ED053E49D69245731@tayexc14.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Powell, Ken" wrote: > > > -----Original Message----- > > From: Michael Thomas [mailto:mat@cisco.com] > > Sent: Thursday, May 03, 2001 1:29 PM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: [mobile-ip] home agent discovery question > > > > > > Powell, Ken writes: > > > > The CN can form the HA's address by forming a > > > > Home Agents Anycast address as described in -13. > > > > As for how do you know that the HA is sending > > > > the information -- just as well as the CN knows > > > > that the MN is sending the information. Meaning, > > > > to the degree you trust the integrity of the > > > > routing system, you can trust replies from the > > > > MN's home agent about as much as replies from > > > > the MN itself. > > > > > > This may not work if there are multiple home agents > > > on the home network. I expect a home agent will be > > > able to support authentication of the mobile node > > > only if it has a current home registration binding > > > for that mobile node. Any message sent to the home > > > agent's anycast address could go to any of the home > > > agents on the network, not necessarily the one > > > with the mobile node's home registration. > > > > I would think that that would affect home agent > > discovery in general. > > Not really. When a mobile node does home agent discovery, > it has no home registrations and needs to find a home > agent so it can create one. In this case, any available > home agent on the home network will do. Wait a minute.. the home agent discovery message might only be *received* by one home agent, but that home agent will *reply* with the addresses of all home agents on the link (i.e. the home agent list). > > > That said, Steve Deering mentioned > > to me a while ago that he didn't see how the > > home agent anycast couldn't be formed without > > the knowledge of the subnet mask to form the > > prefix correctly. So is the implication that > > the mobile node not only needs to know its home > > address, but the subnet prefix as well when > > it's doing home agent discovery? > > You are right, that a mobile node needs to know the > home subnet prefix length to generate a home agent > anycast address from its own home address. > > Normally a mobile node will have both during normal > operation. If a mobile node looses communication with > its current home agent (perhaps the home agent crashed), > it makes sense to use this information to generate the > home agent anycast address and find a new home agent. > > On the other hand, when a mobile node boots on a remote > network, it's previously configured home address may have > timed-out. In this case, it should have another technique > to find the home agent anycast address. Appendix B of the > mobile IPv6 spec says this could be handled by storing the > anycast address in DNS. Yes, there was a fair bit of discussion about this a couple of months ago, but unfortunately the mobile-ip list was fibrillating at the time. And yes, it is true, that the mobile node must at all times be able to figure out, at the bare minimum, what its home network prefix is. Everything else can be bootstrapped from that point. In 99% of cases, the MN will be configured and the prefix is simply cached/in context. When the MN is configuring its home address and doesn't have one cached, i.e. a truly stateless device..or a MN awakening after a prefix renumbering.. it will have to rely on some outside authority to retrieve its home prefix. It seems DNS is a good choice, as Ken has suggested (I believe it's Appendix A, actually?) > > > This all sounds rather, well, not very > > automatic to me, and would have problems with > > renumbering, etc, etc. > > I agree that we want automatic home address > autoconfiguration and renumbering to work. Many of > the details are beyond the scope of the spec. > Appendix B provides one possible approach. T.J. > Kniveton is working on a better method. When I have some free time (grin), I'd like to work out a good approach to this. As we've discussed before, there is a really prickly problem which is that IPv6 addresses behave a bit differently than 'v4 addresses, and you can't rely on them for the same properties (such as prefix stability). I wonder if Steeve Deering would have some comments on this subject. It might be nice to have some sort of discussion at the next IETF on renumbering in general, and how it applies to mobility in particular. > > Ken -- T.J. Kniveton NOKIA Research From owner-mobile-ip@sunroof.eng.sun.com Thu May 3 15:18:38 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04603 for ; Thu, 3 May 2001 15:18:37 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA15234; Thu, 3 May 2001 12:18:23 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA21085; Thu, 3 May 2001 12:18:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43JDdIM006979 for ; Thu, 3 May 2001 12:13:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f43JDadN006978 for mobile-ip-dist; Thu, 3 May 2001 12:13:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43JD2IM006968 for ; Thu, 3 May 2001 12:13:05 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA01043 for ; Thu, 3 May 2001 12:12:53 -0700 (PDT) Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA03372 for ; Thu, 3 May 2001 13:44:08 -0600 (MDT) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id OAA11410 for ; Thu, 3 May 2001 14:12:47 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f43JCkX04124 for ; Thu, 3 May 2001 14:12:46 -0500 (CDT) Message-ID: <3AF1AEB9.BB04BE22@usa.alcatel.com> Date: Thu, 03 May 2001 14:17:13 -0500 From: Behcet Sarikaya Organization: Alcatel USA X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Final(?) Cut on LMM Requirements References: <034BEFD03799D411A59F00508BDF7546013DBDEE@esealnt448.al.sw.ericsson.se> <3AF02963.BC75BF87@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Charlie, I found your reference to host routes rather odd. I think that HMIPv6 does not have host routes maybe expect at the MAP, however regreg6 seems to have host routes in routers. Can you please shed some light onto this? "Charles E. Perkins" wrote: > Hello folks, > > I'm finding it difficult to keep up with all the discussion, > but the following two items stand out: > > > 5. LMM shall scale to support millions of nodes. > > (Comment had been that this was too broad but only other suggestion > > was: > > "LMM shall scale so that the number of LMM agents scale linearly or > > sublinearly with the number of deployed subnets, not the number of > > mobiles." Unless there is more support for the revision we'll stay > > with the original) > > I think the original is better, unless someone can demonstrate that > it is actually possible to achieve the suggested linear or sublinear > growth rate. > > > 10. LMM should support autoconfig. > > Part of the problem of LMM is to figure out what the mobility > routing agents are doing, and where they are to be located. > If LMM involves host routes, then another part of the problem > will be to manage the distribution of the host routes. A third > part of the problem will be to find ways for the mobility routing > agents to be able to discover their interrelationships (e.g., > how they fit in a hierarchy or mesh, perhaps). > > These problems do not all have to be solved at the same time, > and therefore not all in the same draft. So, for instance, > one scheme for the distribution of host routes could be compatible > with multiple schemes for autoconfiguration. I'd even suggest > that manual configuration is acceptable until we have some > experience with testing and deployment of some scheme. However, > this is not at all to say that autoconfiguration schemes are > not of interest. It's just that we can go a long way towards > solving LMM problems without the necessary requirement for > autoconfiguration. > > As an example, I think it would be very reasonable to have > a Proposed Standard for LMM possibly months or even a year > before having a Proposed Standard for LMM autoconfiguration. > Look at the example of Router Renumbering for IPv6. On the > other hand, if we have both ready sooner, so much the better! > > Regards, > Charlie P. Regards, --behcet From owner-mobile-ip@sunroof.eng.sun.com Thu May 3 15:54:41 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06525 for ; Thu, 3 May 2001 15:54:40 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02233; Thu, 3 May 2001 12:54:25 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA29249; Thu, 3 May 2001 12:53:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43JosIM007116 for ; Thu, 3 May 2001 12:50:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f43JorMo007115 for mobile-ip-dist; Thu, 3 May 2001 12:50:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43JodIM007108 for ; Thu, 3 May 2001 12:50:41 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA29401 for ; Thu, 3 May 2001 12:50:36 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA22310 for ; Thu, 3 May 2001 14:21:45 -0600 (MDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f43JoPN17353 for ; Thu, 3 May 2001 21:50:25 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu May 03 21:50:23 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 3 May 2001 21:45:35 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBDF1@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" , Basavaraj.Patil@nokia.com Cc: carl.williams@eng.sun.com Subject: RE: [mobile-ip] LMM Requirements Date: Thu, 3 May 2001 21:50:14 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: James, > The problem is, as I mentioned in my response to Juergin, that there > are certain business models that would be harmed from not optimizing signalling > when LMM domains are small. Suppose there are multiple small wireless > providers in an area, and they all want to do optimized signalling > in their domain, but they are peering with a larger ISP who would > like to set up an LMM domain to allow customers of the smaller providers > to switch LMM domains without requiring any global CoA signalling > change. If the protocol doesn't support this, then it becomes difficult. > => This can also be done if you place the LMM in the interconnecting ISP. Obviously the same amount of state is kept regardless. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu May 3 16:56:04 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09699 for ; Thu, 3 May 2001 16:56:03 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA27519; Thu, 3 May 2001 13:55:54 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA13288; Thu, 3 May 2001 13:55:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43KnfIM007202 for ; Thu, 3 May 2001 13:49:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f43Knf2u007201 for mobile-ip-dist; Thu, 3 May 2001 13:49:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43KmNIM007194 for ; Thu, 3 May 2001 13:49:27 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA02766 for ; Thu, 3 May 2001 13:48:21 -0700 (PDT) Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id NAA03361 for ; Thu, 3 May 2001 13:48:20 -0700 (PDT) Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id QAA13637; Thu, 3 May 2001 16:48:15 -0400 Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Thu, 3 May 2001 16:48:04 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 May 2001 16:48:08 -0400 Message-ID: From: "Muhammad Jaseemuddin" To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] FHv6: some comments Date: Thu, 3 May 2001 16:48:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D412.5AF06E20" X-Orig: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C0D412.5AF06E20 Content-Type: text/plain Hi: I have following comments on FastHandoverv6 (FHv6) draft. 1. Page 3, first paragraph: The mobile node sends a Fast Binding Update using its newly formed COA as the last message before it executes the handover. If the handover here means layer2 handover (before loss of layer 2 connection to the old AR) then how can mobile node use newCOA at the old subnet to send Fast Binding Update (if thats what use means). Perhaps what it should state is that the mobile can use oldCOA as the source address but include newCOA in alternate COA option of F-BU. 2. Section 4.3.1 on F-BU is pretty much a cut and paste from Mobile IPv6 draft. 3. Section 4.3.2 on F-BACK, last sentence of the first paragraph: there is no A-bit definedd for F-BU. Either it is a legacy of Mobile IPv6 or A-bit definition is missing in F-BU. 4. Section 3.1.2: HI-HACK exchange happens before old AR sends PrRtAdv to the MN. Now, through out the draft it is maintmained that the MN cannot use newCOA before receiving F-BACK. Since this is a stateful case and old AR has received newCOA from the new AR and no new message exchange happens between new AR and old AR sending F-BACK, there seems to be no need for mobile to wait for F-BACK before sending packets through the new AR. Cheers, Muhammad Jaseemuddin Wireless Technology Lab Nortel Networks email: jaseem@nortelnetworks.com Phone: 613 765-7520 (ESN 395) Fax: 613 763-2686 ------_=_NextPart_001_01C0D412.5AF06E20 Content-Type: text/html Content-Transfer-Encoding: quoted-printable FHv6: some comments

Hi:

 I have following comments on = FastHandoverv6 (FHv6) draft.

1. Page 3, first paragraph:
    The mobile node sends a Fast Binding = Update using its newly formed
  COA as the last message = before it executes the handover. 

  If the handover here means layer2 handover (before loss = of layer 2 connection to the old AR) then how can mobile node use = newCOA at the old subnet to send Fast Binding Update (if thats what use = means). Perhaps what it should state is that the mobile can use oldCOA = as the source address but include newCOA in alternate COA option of = F-BU.

2. Section 4.3.1 on F-BU is pretty = much a cut and paste from Mobile IPv6 draft.

3. Section 4.3.2 on F-BACK, last = sentence of the first paragraph: there is no A-bit definedd for F-BU. = Either it is a legacy of Mobile IPv6 or A-bit definition is missing in = F-BU.

4. Section 3.1.2: HI-HACK exchange = happens before old AR sends PrRtAdv to the MN. Now, through out the = draft it is maintmained that the MN cannot use newCOA before receiving = F-BACK. Since this is a stateful case and old AR has received newCOA = from the new AR and no new message exchange happens between new AR and = old AR sending F-BACK, there seems to be no need for mobile to wait for = F-BACK before sending packets through the new AR.

Cheers,
Muhammad Jaseemuddin    =        =20
Wireless Technology = Lab        
Nortel = Networks
email:   = jaseem@nortelnetworks.com
Phone:  613 = 765-7520 (ESN 395)
Fax:      613 763-2686

------_=_NextPart_001_01C0D412.5AF06E20-- From owner-mobile-ip@sunroof.eng.sun.com Thu May 3 18:10:27 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11587 for ; Thu, 3 May 2001 18:10:26 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA25241; Thu, 3 May 2001 15:09:48 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA00918; Thu, 3 May 2001 15:09:30 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43M7iIM007334 for ; Thu, 3 May 2001 15:07:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f43M7inR007333 for mobile-ip-dist; Thu, 3 May 2001 15:07:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43M7ZIM007326 for ; Thu, 3 May 2001 15:07:35 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA22035 for ; Thu, 3 May 2001 15:07:36 -0700 (PDT) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20516 for ; Thu, 3 May 2001 15:07:35 -0700 (PDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2650.21) id <2MX5GCQC>; Thu, 3 May 2001 18:07:34 -0400 Message-ID: From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] FHv6: some comments Date: Thu, 3 May 2001 18:07:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Muhammad, Comments below... -----Original Message----- From: Muhammad Jaseemuddin [mailto:jaseem@nortelnetworks.com] Sent: Thursday, May 03, 2001 9:48 PM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] FHv6: some comments Hi: I have following comments on FastHandoverv6 (FHv6) draft. 1. Page 3, first paragraph: The mobile node sends a Fast Binding Update using its newly formed COA as the last message before it executes the handover. If the handover here means layer2 handover (before loss of layer 2 connection to the old AR) then how can mobile node use newCOA at the old subnet to send Fast Binding Update (if thats what use means). Perhaps what it should state is that the mobile can use oldCOA as the source address but include newCOA in alternate COA option of F-BU. GT> Correct me if I am wrong but that is also how the normal BUs work...i.e.: when you send a BU you use the newCOA as source address....we do the same with the F-BU...I think this is OK? 2. Section 4.3.1 on F-BU is pretty much a cut and paste from Mobile IPv6 draft. GT> It is intentionaly very similar...the BU fields we re-use have the same semantics and thus the same description...I think that is a good think... 3. Section 4.3.2 on F-BACK, last sentence of the first paragraph: there is no A-bit definedd for F-BU. Either it is a legacy of Mobile IPv6 or A-bit definition is missing in F-BU. GT> Thanks...initially we had the A-flag but in the end we decided that the F-BACK should be mandatory and thus the A-flag does not make sense...the above escaped the deletion of this.....I will fix it. 4. Section 3.1.2: HI-HACK exchange happens before old AR sends PrRtAdv to the MN. Now, through out the draft it is maintmained that the MN cannot use newCOA before receiving F-BACK. Since this is a stateful case and old AR has received newCOA from the new AR and no new message exchange happens between new AR and old AR sending F-BACK, there seems to be no need for mobile to wait for F-BACK before sending packets through the new AR. GT> HI-HACK only allocates an address...remember that until the F-BU has been received by the oldAR no routing change is taking place (i.e.: newCOA is not yet in use). The fact that this is a stateful case does not change the above....i.e: the oldAR may still reject the F-BU and thus the mobile node MUST NOT use it until the FBACK is being received... Thanks George From owner-mobile-ip@sunroof.eng.sun.com Thu May 3 19:54:32 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15422 for ; Thu, 3 May 2001 19:54:31 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA05211; Thu, 3 May 2001 16:53:31 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA24456; Thu, 3 May 2001 16:53:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43NpwIM007457 for ; Thu, 3 May 2001 16:51:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f43NpwX4007456 for mobile-ip-dist; Thu, 3 May 2001 16:51:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43NpnIM007449 for ; Thu, 3 May 2001 16:51:50 -0700 (PDT) Received: from locked (locked.Eng.Sun.COM [129.146.85.189]) by jurassic.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with SMTP id f43NpcHD228631; Thu, 3 May 2001 16:51:39 -0700 (PDT) Message-Id: <200105032351.f43NpcHD228631@jurassic.eng.sun.com> Date: Thu, 3 May 2001 16:50:30 -0700 (PDT) From: Mohan Parthasarathy Subject: RE: [mobile-ip] FHv6: some comments To: mobile-ip@sunroof.eng.sun.com, G.Tsirtsis@flarion.com Cc: jaseem@nortelnetworks.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: cRE1pzfa3ibkA4Lj3UC6Jw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > -----Original Message----- > From: Muhammad Jaseemuddin [mailto:jaseem@nortelnetworks.com] > Sent: Thursday, May 03, 2001 9:48 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] FHv6: some comments > > > Hi: > I have following comments on FastHandoverv6 (FHv6) draft. > 1. Page 3, first paragraph: > The mobile node sends a Fast Binding Update using its newly formed > COA as the last message before it executes the handover. > If the handover here means layer2 handover (before loss of layer 2 > connection to the old AR) then how can mobile node use newCOA at the old > subnet to send Fast Binding Update (if thats what use means). Perhaps what > it should state is that the mobile can use oldCOA as the source address but > include newCOA in alternate COA option of F-BU. > > > GT> Correct me if I am wrong but that is also how the normal BUs > work...i.e.: when you send a BU you use the newCOA as source address....we > do the same with the F-BU...I think this is OK? > > How about ingress filtering ? The normal BUs are sent after moving to the new link to the new access router. Isn't F-BU sent to the old Access router ? Are you assuming that the old Access router will not filter this packet with the new care of address ? -mohan > 2. Section 4.3.1 on F-BU is pretty much a cut and paste from Mobile IPv6 > draft. > > GT> It is intentionaly very similar...the BU fields we re-use have the same > semantics and thus the same description...I think that is a good think... > > > 3. Section 4.3.2 on F-BACK, last sentence of the first paragraph: there is > no A-bit definedd for F-BU. Either it is a legacy of Mobile IPv6 or A-bit > definition is missing in F-BU. > > GT> Thanks...initially we had the A-flag but in the end we decided that the > F-BACK should be mandatory and thus the A-flag does not make sense...the > above escaped the deletion of this.....I will fix it. > > 4. Section 3.1.2: HI-HACK exchange happens before old AR sends PrRtAdv to > the MN. Now, through out the draft it is maintmained that the MN cannot use > newCOA before receiving F-BACK. Since this is a stateful case and old AR has > received newCOA from the new AR and no new message exchange happens between > new AR and old AR sending F-BACK, there seems to be no need for mobile to > wait for F-BACK before sending packets through the new AR. > > GT> HI-HACK only allocates an address...remember that until the F-BU has > been received by the oldAR no routing change is taking place (i.e.: newCOA > is not yet in use). The fact that this is a stateful case does not change > the above....i.e: the oldAR may still reject the F-BU and thus the mobile > node MUST NOT use it until the FBACK is being received... > > > Thanks > > George From owner-mobile-ip@sunroof.eng.sun.com Thu May 3 20:58:51 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16404 for ; Thu, 3 May 2001 20:58:51 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA22922; Thu, 3 May 2001 17:52:51 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA26131; Thu, 3 May 2001 17:52:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f440omIM007521 for ; Thu, 3 May 2001 17:50:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f440omf3007520 for mobile-ip-dist; Thu, 3 May 2001 17:50:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f440odIM007513 for ; Thu, 3 May 2001 17:50:39 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA01256 for ; Thu, 3 May 2001 17:50:39 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA18069 for ; Thu, 3 May 2001 17:50:38 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f440ocn00909 for ; Thu, 3 May 2001 17:50:38 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AFC16707; Thu, 3 May 2001 17:50:36 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA15054; Thu, 3 May 2001 17:50:36 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15089.64732.632979.535443@thomasm-u1.cisco.com> Date: Thu, 3 May 2001 17:50:36 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] some comments on the FMIP draft In-Reply-To: <7B5C0390ACE7D211BC9C0008C7EABA2B0321394D@daeis07nok> References: <7B5C0390ACE7D211BC9C0008C7EABA2B0321394D@daeis07nok> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit 1) This generally needs a pass at spelling and de-Frenchifying George's grammar :-) 2) It appears that the mobile node gates the flow of packets toward its new attachment point in the tunnel by issuing the Fast BU. Further, it looks like the new AR is supposed to buffer packets in flight toward MN until it receives a Fast Neighbor Advertisement. Why can't the OldAR do the buffering and not involve the NewAR at all? Ie: MN->ARold: I'm moving to ARnew, please buffer until I'm done (ie RS) ARold->MN: OK, here's the new prefix (ie, RA) [attaches to ARnew in whatever way is appropriate] MN->ARold: I'm here, start sending (ie, BU) ARold->MN: OK, here they come (BU_ACK) The advantage here is that the NewAR doesn't have to be involved, nor do we need any new neighbor advertisement (ie, F-NA). 3) As I've said before, it would be nice to decouple the need to do the HI/HACK from the rest of this draft. The mobile node should be able to just ask the old access router to buffer its packets while it's in transition. In fact, this has the positive side effect if the oldAR doesn't know anything about the newAR, the mobile node can still register on the newAR as if it were just booting up, and when it's ready, send the BU to the oldAR to start flowing the buffered packets. Another benefit is that if, for some reason, the MN can't attach to the ARnew, it can abandon the handoff and still get the buffers from ARold (assuming it is still in range, but if not you're really hosed anyway). 4) I don't think anything prevents the MN from going through normal DAD procedures on the new AR. If we eliminate the need for the newAR to do the buffering, we can make the HI/HACK completely optional. 5) Is the FBU/FBACK really a different kind of BU? It looks the same as a normal BU. That would actually be rather nice if it were the same since we're probably need to consider the security aspects of them, and it would be nice to have exactly one kind of BU to modify if necessary. Same goes for HMIP as well. Probably enough for now From owner-mobile-ip@sunroof.eng.sun.com Thu May 3 21:07:49 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA16513 for ; Thu, 3 May 2001 21:07:48 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA25181; Thu, 3 May 2001 18:07:35 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA28772; Thu, 3 May 2001 18:06:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f4414VIM007562 for ; Thu, 3 May 2001 18:04:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f4414VL7007561 for mobile-ip-dist; Thu, 3 May 2001 18:04:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f4414MIM007554 for ; Thu, 3 May 2001 18:04:22 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA28373 for ; Thu, 3 May 2001 18:04:22 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA19675 for ; Thu, 3 May 2001 18:04:21 -0700 (PDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f4414KO14686 for ; Fri, 4 May 2001 03:04:20 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri May 04 03:04:19 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 4 May 2001 02:59:31 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBDFB@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] some comments on the FMIP draft Date: Fri, 4 May 2001 03:04:18 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > 3) As I've said before, it would be nice to decouple > the need to do the HI/HACK from the rest of this > draft. The mobile node should be able to just > ask the old access router to buffer its packets > while it's in transition. In fact, this has the > positive side effect if the oldAR doesn't know > anything about the newAR, > => I agree with you. But when we discussed the alternative (MN performs DAD in parallel with sending and receiving packets) we found that it may not work in all cases. Also there were some open issues with ND. I would prefer that approach (my technical bias) if it can work. So if you think it can work when considering it in detail, I don't see why not. > the mobile node can > still register on the newAR > => What do you mean by the "MN registers with the new AR" ? This is not MIPv6. This is a MIPv4 scenario. > as if it were just > booting up, and when it's ready, send the BU > to the oldAR to start flowing the buffered > packets. Another benefit is that if, for some > reason, the MN can't attach to the ARnew, it > can abandon the handoff and still get the > buffers from ARold (assuming it is still > in range, but if not you're really hosed > anyway). > => Doesn't sound like a real time friendly approach though. > 4) I don't think anything prevents the MN from > going through normal DAD procedures on the > new AR. If we eliminate the need for the newAR > to do the buffering, we can make the HI/HACK > completely optional. > => See above. > 5) Is the FBU/FBACK really a different kind of BU? > It looks the same as a normal BU. That would > actually be rather nice if it were the same > since we're probably need to consider the > security aspects of them, and it would be nice > to have exactly one kind of BU to modify if > necessary. Same goes for HMIP as well. > => It would be the same from a security poin of view. I don't see why not. Same for HMIPv6. The F-BU will include the M flag to ensire coexistence with HMIPv6. The reason for having a different type is the HI/HACK messages. We need to know if the BU should trigger HI/HACK or not. Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri May 4 06:24:50 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA07914 for ; Fri, 4 May 2001 06:24:49 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA07961; Fri, 4 May 2001 03:24:08 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA18917; Fri, 4 May 2001 03:23:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44AMcIM008130 for ; Fri, 4 May 2001 03:22:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f44AMbtf008129 for mobile-ip-dist; Fri, 4 May 2001 03:22:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44AMNIM008122 for ; Fri, 4 May 2001 03:22:24 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA18787 for ; Fri, 4 May 2001 03:22:23 -0700 (PDT) Received: from p-mail1.cnet.fr (p-mail1.rd.francetelecom.fr [193.49.124.31]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id DAA15641 for ; Fri, 4 May 2001 03:22:22 -0700 (PDT) Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Fri, 4 May 2001 12:22:19 +0200 Received: from francetelecom.com (p-dico.rd.francetelecom.fr [139.100.18.135]) by p-grive.rd.francetelecom.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KD74DYYG; Fri, 4 May 2001 12:22:15 +0200 Message-ID: <3AF28270.4D6ECB36@francetelecom.com> Date: Fri, 04 May 2001 12:20:32 +0200 From: Jean-Michel COMBES Organization: France =?iso-8859-1?Q?T=E9l=E9com?= R&D X-Mailer: Mozilla 4.7 [fr] (WinNT; U) X-Accept-Language: fr MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Authenticating BU and PKI References: <3AE6F2DB.88661142@crm.mot.com> <3AED5196.4771F69@nomadiclab.com> <3AED6D36.26EEA17B@francetelecom.com> <3AEE4E79.46F6C879@nomadiclab.com> <3AEFE6D0.92446410@francetelecom.com> <3AEFEC8D.4DC8F389@nomadiclab.com> <3AF01543.ECA45B63@francetelecom.com> <3AF0473B.3C6E73E1@nomadiclab.com> <3AF148E1.9CA23364@francetelecom.com> <3AF14ED6.3A168BDE@crm.mot.com> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by mercury.Sun.COM id DAA07961 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA07914 Alexis Olivereau a écrit : > Jean-Michel COMBES wrote: > > > > JMC : > > agree ... but sending MN's certificate doesn't need to have a SA. The > > certificate is signed and so CN can verify information authenticity. > > > > Then the CN needs a PKI to check and use the certificate, so here we are > with the same problem again... JMC : ... of course, if using PKI is a problem JMC. > > > Alexis -- France Telecom R&D - DTL/SSR Jean-Michel COMBES, Internet/Intranet Security E-Mail : jeanmichel.combes@francetelecom.com Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19 PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214 From owner-mobile-ip@sunroof.eng.sun.com Fri May 4 07:35:20 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09260 for ; Fri, 4 May 2001 07:35:19 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA14822; Fri, 4 May 2001 04:35:06 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA03154; Fri, 4 May 2001 04:35:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44BXqIM008286 for ; Fri, 4 May 2001 04:33:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f44BXp1w008285 for mobile-ip-dist; Fri, 4 May 2001 04:33:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44BXhIM008278 for ; Fri, 4 May 2001 04:33:43 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA03091 for ; Fri, 4 May 2001 04:33:42 -0700 (PDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA04499 for ; Fri, 4 May 2001 04:33:42 -0700 (PDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate4.mot.com (motgate4 2.1) with ESMTP id EAA21206 for ; Fri, 4 May 2001 04:33:42 -0700 (MST)] Received: [from m-il06-r4.mot.com (m-il06-r4.mot.com [129.188.137.196]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id EAA13022 for ; Fri, 4 May 2001 04:33:41 -0700 (MST)] Received: from [140.101.173.9] by m-il06-r4.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Fri, 4 May 2001 04:33:40 -0700 Received: (from root@localhost) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) id NAA02093 for mobile-ip@sunroof.eng.sun.com.DELIVER; Fri, 4 May 2001 13:33:38 +0200 (METDST) Received: from crm.mot.com (durga.crm.mot.com [140.101.173.45]) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) with ESMTP id NAA02060 for ; Fri, 4 May 2001 13:33:38 +0200 (METDST) Message-Id: <3AF29390.B44D5BF1@crm.mot.com> Date: Fri, 04 May 2001 13:33:36 +0200 From: Damien Routier Organization: Centre de Recherche de Motorola - Paris X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Authenticating BU and PKI References: <3AE6F2DB.88661142@crm.mot.com> <3AED5196.4771F69@nomadiclab.com> <3AED6D36.26EEA17B@francetelecom.com> <3AEE4E79.46F6C879@nomadiclab.com> <3AEFE6D0.92446410@francetelecom.com> <3AEFEC8D.4DC8F389@nomadiclab.com> <3AF01543.ECA45B63@francetelecom.com> <3AF0473B.3C6E73E1@nomadiclab.com> <3AF148E1.9CA23364@francetelecom.com> <3AF14ED6.3A168BDE@crm.mot.com> <3AF28270.4D6ECB36@francetelecom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > > JMC : > > > agree ... but sending MN's certificate doesn't need to have a SA. The > > > certificate is signed and so CN can verify information authenticity. > > > > > > > Then the CN needs a PKI to check and use the certificate, so here we are > > with the same problem again... > > JMC : > ... of course, if using PKI is a problem > > JMC. I think that using a PKI is a problem since a new certificate must be published each time a MN gets a new CoA and the CA/RA must check that the CoA is rightfully claimed before publishing the certificate am i completly wrong ? Damien Routier Motorola Research Center - Paris From owner-mobile-ip@sunroof.eng.sun.com Fri May 4 08:26:38 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10608 for ; Fri, 4 May 2001 08:26:37 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA06036; Fri, 4 May 2001 05:26:26 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA29311; Fri, 4 May 2001 05:26:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44CP4IM008358 for ; Fri, 4 May 2001 05:25:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f44CP4rX008357 for mobile-ip-dist; Fri, 4 May 2001 05:25:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44COrIM008350 for ; Fri, 4 May 2001 05:24:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA18819 for ; Fri, 4 May 2001 05:24:54 -0700 (PDT) Received: from tml-gw.tml.hut.fi (tml.hut.fi [130.233.44.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA20381 for ; Fri, 4 May 2001 06:57:14 -0600 (MDT) Received: (from smap@localhost) by tml-gw.tml.hut.fi (8.8.7/8.8.7) id PAA19793 for ; Fri, 4 May 2001 15:24:20 +0300 Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0) id xma019786; Fri, 4 May 01 15:24:00 +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 f44COVr25017 for ; Fri, 4 May 2001 15:24:31 +0300 (EEST) Received: from localhost (lpetande@localhost) by morphine.tml.hut.fi (8.11.3/8.11.3) with ESMTP id f44CNTi29074 for ; Fri, 4 May 2001 15:23:29 +0300 (EET DST) X-Authentication-Warning: morphine.tml.hut.fi: lpetande owned process doing -bs Date: Fri, 4 May 2001 15:23:29 +0300 (EET DST) From: Lars Henrik Petander To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Authenticating BU and PKI In-Reply-To: <3AF29390.B44D5BF1@crm.mot.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Fri, 4 May 2001, Damien Routier wrote: > I think that using a PKI is a problem since a new certificate must be > published each time a MN gets a new CoA and the CA/RA must check that > the CoA is rightfully claimed before publishing the certificate > > am i completly wrong ? Partly, as you would normally want to prove the ownership of the home addresss and the certificate would bind the home address or FQDN to a public key. You would need a new certificate only in the case of renumbering or changing your domain name. Of course in the case of a previous router acting as a temporary HA for the old CoA, you would still need to prove the ownership of your previous CoA. Regards, Henrik Petander > > Damien Routier > Motorola Research Center - Paris > From owner-mobile-ip@sunroof.eng.sun.com Fri May 4 08:42:09 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA11069 for ; Fri, 4 May 2001 08:42:08 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA13802; Fri, 4 May 2001 05:41:55 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA27465; Fri, 4 May 2001 05:41:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44CeXIM008386 for ; Fri, 4 May 2001 05:40:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f44CeXQU008385 for mobile-ip-dist; Fri, 4 May 2001 05:40:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44CeOIM008378 for ; Fri, 4 May 2001 05:40:24 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA19803 for ; Fri, 4 May 2001 05:40:25 -0700 (PDT) Received: from p-mail2.cnet.fr (p-mail2.rd.francetelecom.fr [193.49.124.32]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id HAA26416 for ; Fri, 4 May 2001 07:12:45 -0600 (MDT) Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Fri, 4 May 2001 14:40:22 +0200 Received: from francetelecom.com (p-dico.rd.francetelecom.fr [139.100.18.135]) by p-grive.rd.francetelecom.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KD74DZA7; Fri, 4 May 2001 14:40:18 +0200 Message-ID: <3AF2A2CB.B5E4D037@francetelecom.com> Date: Fri, 04 May 2001 14:38:35 +0200 From: Jean-Michel COMBES Organization: France =?iso-8859-1?Q?T=E9l=E9com?= R&D X-Mailer: Mozilla 4.7 [fr] (WinNT; U) X-Accept-Language: fr MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Authenticating BU and PKI References: <3AE6F2DB.88661142@crm.mot.com> <3AED5196.4771F69@nomadiclab.com> <3AED6D36.26EEA17B@francetelecom.com> <3AEE4E79.46F6C879@nomadiclab.com> <3AEFE6D0.92446410@francetelecom.com> <3AEFEC8D.4DC8F389@nomadiclab.com> <3AF01543.ECA45B63@francetelecom.com> <3AF0473B.3C6E73E1@nomadiclab.com> <3AF148E1.9CA23364@francetelecom.com> <3AF14ED6.3A168BDE@crm.mot.com> <3AF28270.4D6ECB36@francetelecom.com> <3AF29390.B44D5BF1@crm.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > > > > > Then the CN needs a PKI to check and use the certificate, so here we are > > > with the same problem again... > > > > JMC : > > ... of course, if using PKI is a problem > > > > JMC. > > I think that using a PKI is a problem since a new certificate must be > published each time a MN gets a new CoA and the CA/RA must check that > the CoA is rightfully claimed before publishing the certificate JMC: No, if the certificate contains the Home Address and not a Care-of Address. > > > am i completly wrong ? > > Damien Routier > Motorola Research Center - Paris -- France Telecom R&D - DTL/SSR Jean-Michel COMBES, Internet/Intranet Security E-Mail : jeanmichel.combes@francetelecom.com Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19 PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214 From owner-mobile-ip@sunroof.eng.sun.com Fri May 4 09:46:57 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12361 for ; Fri, 4 May 2001 09:46:57 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA03578; Fri, 4 May 2001 06:46:43 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA03569; Fri, 4 May 2001 06:46:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44DiHIM008543 for ; Fri, 4 May 2001 06:44:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f44DiHSW008542 for mobile-ip-dist; Fri, 4 May 2001 06:44:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44Di8IM008535 for ; Fri, 4 May 2001 06:44:09 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA08284 for ; Fri, 4 May 2001 06:44:09 -0700 (PDT) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA10810 for ; Fri, 4 May 2001 06:44:08 -0700 (PDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2650.21) id <2MX5GCZX>; Fri, 4 May 2001 09:44:06 -0400 Message-ID: From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] some comments on the FMIP draft Date: Fri, 4 May 2001 09:44:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Friday, May 04, 2001 1:51 AM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] some comments on the FMIP draft 1) This generally needs a pass at spelling and de-Frenchifying George's grammar :-) GT> I do not ming that you think I can not spell....but calling me French is going too far ;-) ...maybe the draft actually looked "all Greek to you" which would be a fair comment :) Spelling suggestions are welcome.... I think Hesham covered the rest.... George From owner-mobile-ip@sunroof.eng.sun.com Fri May 4 10:05:17 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12708 for ; Fri, 4 May 2001 10:05:17 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA10966; Fri, 4 May 2001 07:04:58 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA27169; Fri, 4 May 2001 07:04:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44E2ZIM008618 for ; Fri, 4 May 2001 07:02:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f44E2ZSN008617 for mobile-ip-dist; Fri, 4 May 2001 07:02:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44E2PIM008610 for ; Fri, 4 May 2001 07:02:25 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA05281 for ; Fri, 4 May 2001 07:02:26 -0700 (PDT) Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id HAA03913 for ; Fri, 4 May 2001 07:02:25 -0700 (PDT) Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id KAA21971; Fri, 4 May 2001 10:02:21 -0400 Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Fri, 4 May 2001 10:02:08 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 May 2001 10:02:12 -0400 Message-ID: From: "Muhammad Jaseemuddin" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] FHv6: some comments Date: Fri, 4 May 2001 10:02:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D4A2.D08C25D0" X-Orig: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C0D4A2.D08C25D0 Content-Type: text/plain; charset="iso-8859-1" Thanks George for your response. > -----Original Message----- > From: George Tsirtsis [SMTP:G.Tsirtsis@flarion.com] > Sent: Thursday, May 03, 2001 6:08 PM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] FHv6: some comments > > Hi Muhammad, > > Comments below... > > -----Original Message----- > From: Muhammad Jaseemuddin [mailto:jaseem@nortelnetworks.com] > Sent: Thursday, May 03, 2001 9:48 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] FHv6: some comments > > > Hi: > I have following comments on FastHandoverv6 (FHv6) draft. > 1. Page 3, first paragraph: > The mobile node sends a Fast Binding Update using its newly formed > COA as the last message before it executes the handover. > If the handover here means layer2 handover (before loss of layer 2 > connection to the old AR) then how can mobile node use newCOA at the old > subnet to send Fast Binding Update (if thats what use means). Perhaps what > it should state is that the mobile can use oldCOA as the source address > but > include newCOA in alternate COA option of F-BU. > > > GT> Correct me if I am wrong but that is also how the normal BUs > work...i.e.: when you send a BU you use the newCOA as source address....we > do the same with the F-BU...I think this is OK? > [MJ] As Mohan also pointed out, the newCOA can be used only from the new subnet as a source address. But, the draft describes the case where the MN sends F-BU from the old subnet to the old AR. Hence, in this case it must not use newCOA. If the ingress filtering is set in the AR (I am saying if because ingress filtering has become a thorny issue) then the packet will be droped. And also it doesn't make sense, because newCOA is valid only on new subnet in this situation where MN acquires new COA every time it changes subnet. > 2. Section 4.3.1 on F-BU is pretty much a cut and paste from Mobile IPv6 > draft. > > GT> It is intentionaly very similar...the BU fields we re-use have the > same > semantics and thus the same description...I think that is a good think... > [MJ] But, how about dangling references, for example reference to section 9.3 that is not in the draft. > 3. Section 4.3.2 on F-BACK, last sentence of the first paragraph: there is > no A-bit definedd for F-BU. Either it is a legacy of Mobile IPv6 or A-bit > definition is missing in F-BU. > > GT> Thanks...initially we had the A-flag but in the end we decided that > the > F-BACK should be mandatory and thus the A-flag does not make sense...the > above escaped the deletion of this.....I will fix it. > > 4. Section 3.1.2: HI-HACK exchange happens before old AR sends PrRtAdv to > the MN. Now, through out the draft it is maintmained that the MN cannot > use > newCOA before receiving F-BACK. Since this is a stateful case and old AR > has > received newCOA from the new AR and no new message exchange happens > between > new AR and old AR sending F-BACK, there seems to be no need for mobile to > wait for F-BACK before sending packets through the new AR. > > GT> HI-HACK only allocates an address...remember that until the F-BU has > been received by the oldAR no routing change is taking place (i.e.: newCOA > is not yet in use). The fact that this is a stateful case does not change > the above....i.e: the oldAR may still reject the F-BU and thus the mobile > node MUST NOT use it until the FBACK is being received... > [MJ] I understand it because of consistency reasons. Can we think of any reason why old AR would deny MN to use new COA at the new AR. Consider the following facts: 1. According to FH draft (and Mobile IP principle) mobile ultimately decides about the handover, hence old AR waits for F-BU before bicasting. In the above case mobile has already sent a positive decision. 2. New COA is controlled by the new AR. 3. No additional exchange of messages happen between the old and new AR, hence presumably no change of status of new AR would affect the F-BACK. 4. Now, only some event at old AR can trigger a F-BACK that would deny MN using new COA. First of all its not very clear what those events could be? It is plausible that old AR would like to abort handover at this late stage for some x,y reasons. But, the draft allows MN to use old COA interim at the new subnet before receiving F-BACK with no assurance of packet delivery (and this because of ingress filtering). Why not in this case allowing MN to use new COA? > > Thanks > > George > - Muhammad Jaseemuddin ------_=_NextPart_001_01C0D4A2.D08C25D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] FHv6: some comments

Thanks George for = your response.

    -----Original Message-----
    From:   George Tsirtsis = [SMTP:G.Tsirtsis@flarion.com]
    Sent:   Thursday, May 03, 2001 6:08 PM
    To:     'mobile-ip@sunroof.eng.sun.com'
    Subject:       = RE: [mobile-ip] FHv6: some = comments

    Hi Muhammad,

    Comments below...

    -----Original Message-----
    From: Muhammad Jaseemuddin = [mailto:jaseem@nortelnetworks.c= om]
    Sent: Thursday, May 03, 2001 9:48 = PM
    To: = mobile-ip@sunroof.eng.sun.com
    Subject: [mobile-ip] FHv6: some = comments


    Hi:
     I have following comments on = FastHandoverv6 (FHv6) draft.
    1. Page 3, first paragraph:
        The mobile node = sends a Fast Binding Update using its newly formed
      COA as the last message before = it executes the handover. 
      If the handover here means = layer2 handover (before loss of layer 2
    connection to the old AR) then how = can mobile node use newCOA at the old
    subnet to send Fast Binding Update = (if thats what use means). Perhaps what
    it should state is that the mobile = can use oldCOA as the source address but
    include newCOA in alternate COA = option of F-BU.


    GT> Correct me if I am wrong but = that is also how the normal BUs
    work...i.e.: when you send a BU you = use the newCOA as source address....we
    do the same with the F-BU...I think = this is OK?

    [MJ]  As Mohan also pointed out, the newCOA can be = used only from the new subnet as a source address. But, the draft = describes the case where the MN sends F-BU from the old subnet to the = old AR. Hence, in this case it must not use newCOA. If the ingress = filtering is set in the AR (I am saying if because ingress filtering = has become a thorny issue) then the packet will be droped. And also it = doesn't make sense, because newCOA is valid only on new subnet in this = situation where MN acquires new COA every time it changes = subnet.

    2. Section 4.3.1 on F-BU is pretty = much a cut and  paste from Mobile IPv6
    draft.

    GT> It is intentionaly very = similar...the BU fields we re-use have the same
    semantics and thus the same = description...I think that is a good think...

    [MJ]  But, how about dangling references, for = example reference to section 9.3 that is not in the draft.

    3. Section 4.3.2 on F-BACK, last = sentence of the first paragraph: there is
    no A-bit definedd for F-BU. Either it = is a legacy of Mobile IPv6 or A-bit
    definition is missing in F-BU.

    GT> Thanks...initially we had the = A-flag but in the end we decided that the
    F-BACK should be mandatory and thus = the A-flag does not make sense...the
    above escaped the deletion of = this.....I will fix it.

    4. Section 3.1.2: HI-HACK exchange = happens before old AR sends PrRtAdv to
    the MN. Now, through out the draft it = is maintmained that the MN cannot use
    newCOA before receiving F-BACK. Since = this is a stateful case and old AR has
    received newCOA from the new AR and = no new message exchange happens between
    new AR and old AR sending F-BACK, = there seems to be no need for mobile to
    wait for F-BACK before sending = packets through the new AR.

    GT> HI-HACK only allocates an = address...remember that until the F-BU has
    been received by the oldAR no routing = change is taking place (i.e.: newCOA
    is not yet in use). The fact that = this is a stateful case does not change
    the above....i.e: the oldAR may still = reject the F-BU and thus the mobile
    node MUST NOT use it until the FBACK = is being received...

    [MJ]  I understand it because of consistency = reasons. Can we think of any reason why old AR would deny MN to use new = COA at the new AR. Consider the following facts:

    1. According to FH = draft (and Mobile IP principle) mobile ultimately decides about the = handover, hence old AR waits for F-BU before bicasting. In the above = case mobile has already sent a positive decision.

    2. New COA is = controlled by the new AR.

    3. No additional = exchange of messages happen between the old and new AR, hence = presumably no change of status of new AR would affect the = F-BACK.

    4. Now, only some = event at old AR can trigger a F-BACK that would deny MN using new = COA.

    First of all its not = very clear what those events could be? It is plausible that old AR = would like to abort handover at this late stage for some x,y reasons. = But, the draft allows MN to use old COA interim at the new subnet = before receiving F-BACK with no assurance of packet delivery (and this = because of ingress filtering). Why not in this case allowing MN to use = new COA?

     
    Thanks

    George

    - Muhammad = Jaseemuddin

------_=_NextPart_001_01C0D4A2.D08C25D0-- From owner-mobile-ip@sunroof.eng.sun.com Fri May 4 10:42:43 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13493 for ; Fri, 4 May 2001 10:42:42 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA29637; Fri, 4 May 2001 07:42:33 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA22529; Fri, 4 May 2001 07:42:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44Ef1IM008682 for ; Fri, 4 May 2001 07:41:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f44Ef1LP008681 for mobile-ip-dist; Fri, 4 May 2001 07:41:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44EeqIM008674 for ; Fri, 4 May 2001 07:40:52 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA20524 for ; Fri, 4 May 2001 07:40:52 -0700 (PDT) Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id HAA12111 for ; Fri, 4 May 2001 07:40:51 -0700 (PDT) Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id KAA27463; Fri, 4 May 2001 10:40:47 -0400 Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 4 May 2001 10:40:32 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 May 2001 10:40:36 -0400 Message-ID: From: "Muhammad Jaseemuddin" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] some comments on the FMIP draft Date: Fri, 4 May 2001 10:39:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D4A8.06B45650" X-Orig: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C0D4A8.06B45650 Content-Type: text/plain > -----Original Message----- > From: Hesham Soliman (ERA) [SMTP:Hesham.Soliman@era.ericsson.se] > Sent: Thursday, May 03, 2001 9:04 PM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] some comments on the FMIP draft > > > 3) As I've said before, it would be nice to decouple > > the need to do the HI/HACK from the rest of this > > draft. The mobile node should be able to just > > ask the old access router to buffer its packets > > while it's in transition. In fact, this has the > > positive side effect if the oldAR doesn't know > > anything about the newAR, > > > => I agree with you. But when we discussed the > alternative (MN performs DAD in parallel with > sending and receiving packets) we found that > it may not work in all cases. Also there were > some open issues with ND. I would prefer > that approach (my technical bias) if it > can work. So if you think it can work when > considering it in detail, I don't see why not. > > > the mobile node can > > still register on the newAR > > > => What do you mean by the "MN > registers with the new AR" ? > This is not MIPv6. This is a MIPv4 > scenario. > > > as if it were just > > booting up, and when it's ready, send the BU > > to the oldAR to start flowing the buffered > > packets. Another benefit is that if, for some > > reason, the MN can't attach to the ARnew, it > > can abandon the handoff and still get the > > buffers from ARold (assuming it is still > > in range, but if not you're really hosed > > anyway). > > > => Doesn't sound like a real time friendly > approach though. > [MJ] It seems will increase the handover latency. It may be a good approach if the two ARs belong to two different ADs, but most likely MIPv6 will be used there. > > 4) I don't think anything prevents the MN from > > going through normal DAD procedures on the > > new AR. If we eliminate the need for the newAR > > to do the buffering, we can make the HI/HACK > > completely optional. > > > => See above. > > > 5) Is the FBU/FBACK really a different kind of BU? > > It looks the same as a normal BU. That would > > actually be rather nice if it were the same > > since we're probably need to consider the > > security aspects of them, and it would be nice > > to have exactly one kind of BU to modify if > > necessary. Same goes for HMIP as well. > > > => It would be the same from a security > poin of view. I don't see why not. Same > for HMIPv6. The F-BU will include the > M flag to ensire coexistence with HMIPv6. > > The reason for having a different type is > the HI/HACK messages. We need to know > if the BU should trigger HI/HACK or not. > [MJ] Hesham, this point is not clear. I don't think that as the draft stands today there is no scenario described where Bu is triggering HI/HACK? or may be I have missed some subtle issues. I will appreciate your response. Don't you think that F-BU may not have the same security requirement as BU if it is used within LMM? I think we should review Fast Handover draft in light of new LMM understanding and requirements. > Hesham > - Muhamma Jaseemuddin ------_=_NextPart_001_01C0D4A8.06B45650 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] some comments on the FMIP draft

    -----Original Message-----
    From:   Hesham Soliman (ERA) = [SMTP:Hesham.Soliman@era.ericsson.se]
    Sent:   Thursday, May 03, 2001 9:04 PM
    To:     'mobile-ip@sunroof.eng.sun.com'
    Subject:       = RE: [mobile-ip] some comments on the = FMIP draft

    > 3) As I've said before, it would = be nice to decouple
    >    the need to do = the HI/HACK from the rest of this
    >    draft. The = mobile node should be able to just
    >    ask the old = access router to buffer its packets
    >    while it's in = transition. In fact, this has the
    >    positive side = effect if the oldAR doesn't know
    >    anything about = the newAR,
    >
            =3D> I agree with you. But when we discussed the =
            alternative (MN performs DAD in parallel with
            sending and receiving packets) we found that
            it may not work in all cases. Also there were
            some open issues with ND. I would prefer
            that approach (my technical bias) if it
            can work. So if you think it can work when
            considering it in detail, I don't see why not.

    > the mobile node can
    >    still register = on the newAR
    >
            =3D> What do you mean by the "MN
            registers with the new AR" ?
            This is not MIPv6. This is a MIPv4
            scenario.

    > as if it were just
    >    booting up, = and when it's ready, send the BU
    >    to the oldAR = to start flowing the buffered
    >    packets. = Another benefit is that if, for some
    >    reason, the MN = can't attach to the ARnew, it
    >    can abandon = the handoff and still get the
    >    buffers from = ARold (assuming it is still
    >    in range, but = if not you're really hosed
    >    = anyway).
    >
            =3D> Doesn't sound like a real time friendly
            approach though.

    [MJ]  It seems will increase the handover latency. = It may be a good approach if the two ARs belong to two different ADs, = but most likely MIPv6 will be used there.

    > 4) I don't think anything = prevents the MN from
    >    going through = normal DAD procedures on the
    >    new AR. If we = eliminate the need for the newAR
    >    to do the = buffering, we can make the HI/HACK
    >    completely = optional.
    >
            =3D> See above.

    > 5) Is the FBU/FBACK really a = different kind of BU?
    >    It looks the = same as a normal BU. That would
    >    actually be = rather nice if it were the same
    >    since we're = probably need to consider the
    >    security = aspects of them, and it would be nice
    >    to have = exactly one kind of BU to modify if
    >    necessary. = Same goes for HMIP as well.
    >
            =3D> It would be the same from a security
            poin of view. I don't see why not. Same
            for HMIPv6. The F-BU will include the
            M flag to ensire coexistence with HMIPv6.

            The reason for having a different type is
            the HI/HACK messages. We need to know
            if the BU should trigger HI/HACK or not.

    [MJ]  Hesham, this point is not clear. I don't think = that as the draft stands today there is no scenario described where Bu = is triggering HI/HACK? or may be I have missed some subtle issues. I = will appreciate your response.

    Don't you think that = F-BU may not have the same security requirement as BU if it is used = within LMM? I think we should review Fast Handover draft in light of = new LMM understanding and requirements.

            Hesham

    - Muhamma = Jaseemuddin

------_=_NextPart_001_01C0D4A8.06B45650-- From owner-mobile-ip@sunroof.eng.sun.com Fri May 4 11:40:29 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14675 for ; Fri, 4 May 2001 11:40:28 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA14518; Fri, 4 May 2001 08:40:19 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA25128; Fri, 4 May 2001 08:40:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44FcgIM008752 for ; Fri, 4 May 2001 08:38:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f44FcgtR008751 for mobile-ip-dist; Fri, 4 May 2001 08:38:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44FcYIM008744 for ; Fri, 4 May 2001 08:38:34 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id IAA25839 for ; Fri, 4 May 2001 08:38:34 -0700 (PDT) Message-Id: <200105041538.IAA25839@heliopolis.eng.sun.com> Date: Fri, 4 May 2001 08:38:34 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] some comments on the FMIP draft To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: amyMjXCOiRjbM4EXF52asQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: >> 3) As I've said before, it would be nice to decouple >> the need to do the HI/HACK from the rest of this >> draft. The mobile node should be able to just >> ask the old access router to buffer its packets >> while it's in transition. In fact, this has the >> positive side effect if the oldAR doesn't know >> anything about the newAR, >> > => I agree with you. But when we discussed the > alternative (MN performs DAD in parallel with > sending and receiving packets) we found that > it may not work in all cases. Also there were > some open issues with ND. I would prefer > that approach (my technical bias) if it > can work. So if you think it can work when > considering it in detail, I don't see why not. > One of the problems with requiring signalling from the MN after L2 has indicated handoff is imminent is that, depending on the particulars of the radio link protocol, the signalling has a much higher probability of being dropped or corrupted. The reason that handoff typically occurs is because there is a drop in the radio signal quality or power below what the radio protocol deems sufficient for low error rate communication having the contracted quality of service from the mobile node to the current base station. We went through this discussion once several months ago on the IPv4 design team. I don't know whether it surfaced in the IPv6 discussion at all. Because this may not necessarily be the case for all radio protocols (for example, a nanocell protocol), the IPv4 design team decided to offer the choice of either having the L3 handoff signalling originate from the mobile node or having the network do the L3 handoff signalling. The IPv6 design team chose to combine the two techniques and require both in all cases. IMHO, the need for low latency handoff is poorly served by this design, because it requires more signalling than if the two techniques were separated, but I won't try to second guess the IPv6 design team without more carefully reading the draft. In any case, I don't think it would be wise to eliminate the network assisted part of the handoff. This would assure that the protocol would work poorly for radio protocols where degraded radio quality of service accompanies an L2 handoff decision, because the MN would be forced to retransmit if packet loss occured. jak From owner-mobile-ip@sunroof.eng.sun.com Fri May 4 11:58:32 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15141 for ; Fri, 4 May 2001 11:58:32 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA29925; Fri, 4 May 2001 08:58:23 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA28688; Fri, 4 May 2001 08:58:16 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44FusIM008779 for ; Fri, 4 May 2001 08:56:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f44FusYS008778 for mobile-ip-dist; Fri, 4 May 2001 08:56:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44FujIM008771 for ; Fri, 4 May 2001 08:56:45 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA28373 for ; Fri, 4 May 2001 08:56:45 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA27331 for ; Fri, 4 May 2001 08:56:45 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f44FvCa29068 for ; Fri, 4 May 2001 08:57:12 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AFC24581; Fri, 4 May 2001 08:56:44 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA15279; Fri, 4 May 2001 08:56:43 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15090.53563.708822.501296@thomasm-u1.cisco.com> Date: Fri, 4 May 2001 08:56:43 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] some comments on the FMIP draft In-Reply-To: <200105041538.IAA25839@heliopolis.eng.sun.com> References: <200105041538.IAA25839@heliopolis.eng.sun.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I didn't ask for network assisted handoff to be removed, and I didn't change the number or location in time of the pre-handoff messages from MN<->ARold. All I asked is for the buffering to be done on ARold instead of ARnew (a trivial change, I think) and making the HI/HACK optional if the MN is willing to take its chances on the new AR of doing DAD in a timely fashion. Also: one other thing that folks are missing in the current draft is that the arrival of MN on AR and then sending the F-NA is a security hazard unless MN can cryptographically prove that it is the same node on on ARold that is pressing the "go" button. There would need to be some sort of identity that is transfered in the HI/HACK and a new security association at ARnew in order to prevent this attack. If you let ARold buffer the packets, you don't run into this hazard (and time sink) because ARold could have demanded credentials well in advance to determine the legitimacy of the BU. Mike James Kempf writes: > >> 3) As I've said before, it would be nice to decouple > >> the need to do the HI/HACK from the rest of this > >> draft. The mobile node should be able to just > >> ask the old access router to buffer its packets > >> while it's in transition. In fact, this has the > >> positive side effect if the oldAR doesn't know > >> anything about the newAR, > >> > > => I agree with you. But when we discussed the > > alternative (MN performs DAD in parallel with > > sending and receiving packets) we found that > > it may not work in all cases. Also there were > > some open issues with ND. I would prefer > > that approach (my technical bias) if it > > can work. So if you think it can work when > > considering it in detail, I don't see why not. > > > > > One of the problems with requiring signalling from the MN after L2 has indicated > handoff is imminent is that, depending on the particulars of the radio link > protocol, the signalling has a much higher probability of being dropped or > corrupted. The reason that handoff typically occurs is because there > is a drop in the radio signal quality or power below what the radio protocol > deems sufficient for low error rate communication having the contracted > quality of service from the mobile node to the current base station. > We went through this discussion once several months ago on the IPv4 design team. > I don't know whether it surfaced in the IPv6 discussion at all. > > Because this may not necessarily be the case for all radio protocols (for > example, a nanocell protocol), the IPv4 design team decided to offer > the choice of either having the L3 handoff signalling > originate from the mobile node or having the network do the L3 handoff > signalling. The IPv6 design team chose to combine the two techniques and require > both in all cases. IMHO, the need for low latency handoff is poorly > served by this design, because it requires more signalling than if > the two techniques were separated, but I won't try to second guess > the IPv6 design team without more carefully reading the draft. > > In any case, I don't think it would be wise to eliminate the network assisted > part of the handoff. This would assure that the protocol would work > poorly for radio protocols where degraded radio quality of service > accompanies an L2 handoff decision, because the MN would be forced > to retransmit if packet loss occured. > > jak > > > > From owner-mobile-ip@sunroof.eng.sun.com Fri May 4 12:01:27 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15327 for ; Fri, 4 May 2001 12:01:26 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02524; Fri, 4 May 2001 09:01:18 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA29184; Fri, 4 May 2001 09:01:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44FxaIM008806 for ; Fri, 4 May 2001 08:59:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f44Fxa7m008805 for mobile-ip-dist; Fri, 4 May 2001 08:59:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44FxNIM008798 for ; Fri, 4 May 2001 08:59:23 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA28867 for ; Fri, 4 May 2001 08:59:23 -0700 (PDT) Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00736 for ; Fri, 4 May 2001 08:59:22 -0700 (PDT) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id KAA25215 for ; Fri, 4 May 2001 10:59:22 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f44FxLC27352 for ; Fri, 4 May 2001 10:59:21 -0500 (CDT) Message-ID: <3AF2C36A.E6A631EA@usa.alcatel.com> Date: Fri, 04 May 2001 10:57:46 -0400 From: Behcet Sarikaya X-Mailer: Mozilla 4.76 [en]C-CCK-MCD BDPjm-Sony3 (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] some comments on the FMIP draft References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi George, Are there any proof of concept studies on your draft? George Tsirtsis wrote: > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Friday, May 04, 2001 1:51 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] some comments on the FMIP draft > > 1) This generally needs a pass at spelling and de-Frenchifying > George's grammar :-) > > GT> I do not ming that you think I can not spell....but calling me French > is going too far ;-) ...maybe the draft actually looked "all Greek to you" > which would be a fair comment :) > > Spelling suggestions are welcome.... > > I think Hesham covered the rest.... > George Regards, -- Behcet From owner-mobile-ip@sunroof.eng.sun.com Fri May 4 12:15:27 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15740 for ; Fri, 4 May 2001 12:15:26 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13828; Fri, 4 May 2001 09:15:18 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA16666; Fri, 4 May 2001 09:15:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44GDCIM008856 for ; Fri, 4 May 2001 09:13:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f44GDCEl008855 for mobile-ip-dist; Fri, 4 May 2001 09:13:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44GD4IM008848 for ; Fri, 4 May 2001 09:13:04 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id JAA27082 for ; Fri, 4 May 2001 09:13:04 -0700 (PDT) Message-Id: <200105041613.JAA27082@heliopolis.eng.sun.com> Date: Fri, 4 May 2001 09:13:04 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] some comments on the FMIP draft To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 7spzYYXNUY92ekaiYG1wrg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Mike, >I didn't ask for network assisted handoff to be >removed, and I didn't change the number or >location in time of the pre-handoff messages from >MN<->ARold. All I asked is for the buffering to be >done on ARold instead of ARnew (a trivial change, >I think) and making the HI/HACK optional if the MN >is willing to take its chances on the new AR of >doing DAD in a timely fashion. > Sure, but what I'm saying is that I think the MN signalling pre-L2 handoff should be made optional as well if the link layer can't support it. That's how the IPv4 design works. With regard to the buffering, I need to take a look at the spec more closely, but in general I think buffering on newAR is more likely to reduce the gap for real time traffic. I've talked to people who have done some experiements with buffering in IPv4 and buffering on the old Foreign Agent resulted in a noticable gap in real time traffic. Buffering is problematic in any case for real time traffic, and anything that offers the opportunity of delays will add to the delay budget and increase the liklihood that there is a noticable gap. Buffering on oldAR (in a bicasting/edge tunnel situation) makes sense for smoothing during ping-ponging however. Or am I misinterpreting your intent somehow here? jak From owner-mobile-ip@sunroof.eng.sun.com Fri May 4 12:15:41 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15763 for ; Fri, 4 May 2001 12:15:39 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14132; Fri, 4 May 2001 09:15:31 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA06650; Fri, 4 May 2001 09:15:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44GEEIM008866 for ; Fri, 4 May 2001 09:14:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f44GEEHc008865 for mobile-ip-dist; Fri, 4 May 2001 09:14:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44GE5IM008858 for ; Fri, 4 May 2001 09:14:05 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA07140 for ; Fri, 4 May 2001 09:14:05 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA08187 for ; Fri, 4 May 2001 09:14:03 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f44GEUa10023 for ; Fri, 4 May 2001 09:14:30 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AFC24973; Fri, 4 May 2001 09:14:02 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA15282; Fri, 4 May 2001 09:14:00 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15090.54600.716333.50866@thomasm-u1.cisco.com> Date: Fri, 4 May 2001 09:14:00 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] some comments on the FMIP draft In-Reply-To: <034BEFD03799D411A59F00508BDF7546013DBDFB@esealnt448.al.sw.ericsson.se> References: <034BEFD03799D411A59F00508BDF7546013DBDFB@esealnt448.al.sw.ericsson.se> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hesham Soliman (ERA) writes: > => I agree with you. But when we discussed the > alternative (MN performs DAD in parallel with > sending and receiving packets) we found that > it may not work in all cases. Also there were > some open issues with ND. I would prefer > that approach (my technical bias) if it > can work. So if you think it can work when > considering it in detail, I don't see why not. Can you outline some of the problems? > > > the mobile node can > > still register on the newAR > > > => What do you mean by the "MN > registers with the new AR" ? > This is not MIPv6. This is a MIPv4 > scenario. Sorry, I didn't mean that in the mipv4 sense. I meant, the MN attaches, possibly requiring authentication via, say, PPP/CHAP or BURP or 802.1x... > > as if it were just > > booting up, and when it's ready, send the BU > > to the oldAR to start flowing the buffered > > packets. Another benefit is that if, for some > > reason, the MN can't attach to the ARnew, it > > can abandon the handoff and still get the > > buffers from ARold (assuming it is still > > in range, but if not you're really hosed > > anyway). > > > => Doesn't sound like a real time friendly > approach though. No, of course not. I view this in %*! happens sense, as in if the MN tries to move to some place it finds out was a mistake. If the packets were buffered back at ARold, it could potentially minimize some of its loss. Not a huge benefit, I'll agree, but it sort of plays off of the old "bird in the hand is worth two in bush" principal :-) > > 5) Is the FBU/FBACK really a different kind of BU? > > It looks the same as a normal BU. That would > > actually be rather nice if it were the same > > since we're probably need to consider the > > security aspects of them, and it would be nice > > to have exactly one kind of BU to modify if > > necessary. Same goes for HMIP as well. > > > => It would be the same from a security > poin of view. I don't see why not. Same > for HMIPv6. The F-BU will include the > M flag to ensire coexistence with HMIPv6. > > The reason for having a different type is > the HI/HACK messages. We need to know > if the BU should trigger HI/HACK or not. Could this not be done with a flag in the RS? As far as I can tell, what I'm proposing would require the following flags: Router Solicit (and RA, I suspect): BUFFER: buffer the packets until you see a Binding Update HANDOVER: execute the HI/HACK BU: nothing special since it executes once the MN arrives BACK: nothing special since it's just a BU F-NA: deprecate since it's not necessary Two new flags in the RS and RA seems a lot cleaner in my mind than 3 new messages. Mike From owner-mobile-ip@sunroof.eng.sun.com Fri May 4 12:31:20 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16266 for ; Fri, 4 May 2001 12:31:20 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA27080; Fri, 4 May 2001 09:31:12 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04581; Fri, 4 May 2001 09:31:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44GTEIM008924 for ; Fri, 4 May 2001 09:29:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f44GTDCl008923 for mobile-ip-dist; Fri, 4 May 2001 09:29:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44GT5IM008916 for ; Fri, 4 May 2001 09:29:05 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03998 for ; Fri, 4 May 2001 09:29:05 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25210 for ; Fri, 4 May 2001 09:29:04 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f44GT9Q22673 for ; Fri, 4 May 2001 09:29:10 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AFC25290; Fri, 4 May 2001 09:29:03 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA15291; Fri, 4 May 2001 09:29:03 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15090.55503.106651.319071@thomasm-u1.cisco.com> Date: Fri, 4 May 2001 09:29:03 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] some comments on the FMIP draft In-Reply-To: <200105041613.JAA27082@heliopolis.eng.sun.com> References: <200105041613.JAA27082@heliopolis.eng.sun.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit James Kempf writes: > Sure, but what I'm saying is that I think the MN signalling > pre-L2 handoff should be made optional as well if the link > layer can't support it. That's how the IPv4 design works. Sure. But I haven't proposed anything different there than a couple of new flags. I think that the draft supports what you're after though, and my proposal wouldn't change that. > With regard to the buffering, I need to take a look at > the spec more closely, but in general I think buffering > on newAR is more likely to reduce the gap for real time > traffic. I've talked to people who have done some experiements with > buffering in IPv4 and buffering on the old Foreign Agent resulted > in a noticable gap in real time traffic. Buffering is problematic > in any case for real time traffic, and anything that offers > the opportunity of delays will add to the delay budget and > increase the liklihood that there is a noticable gap. Buffering > on oldAR (in a bicasting/edge tunnel situation) makes sense > for smoothing during ping-ponging however. Buffering isn't the only problem. The forward tunnel is going to change the delay characteristics for the jitter buffers too. If the two AR's are topologically distance and you have a short playback delays, the problem will, in fact, persist until the jitter buffer adapts. From that standpoint, I think it's probably a wash where the buffering is done. > Or am I misinterpreting your intent somehow here? Nope. Mike From owner-mobile-ip@sunroof.eng.sun.com Fri May 4 13:15:29 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17244 for ; Fri, 4 May 2001 13:15:28 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01202; Fri, 4 May 2001 10:15:16 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA01780; Fri, 4 May 2001 10:15:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44HBmIM009008 for ; Fri, 4 May 2001 10:11:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f44HBlfb009006 for mobile-ip-dist; Fri, 4 May 2001 10:11:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44HBIIM008999 for ; Fri, 4 May 2001 10:11:19 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA00855 for ; Fri, 4 May 2001 10:11:17 -0700 (PDT) From: Satish_Amara@3com.com Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15718 for ; Fri, 4 May 2001 10:11:17 -0700 (PDT) Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f44H9Y322866 for ; Fri, 4 May 2001 10:09:34 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104]) by opal.3com.com (Switch-2.1.1/Switch-2.1.0) with SMTP id f44HBGk26957 for ; Fri, 4 May 2001 10:11:16 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256A42.005E66A8 ; Fri, 4 May 2001 10:11:06 -0700 X-Lotus-FromDomain: 3COM To: mobile-ip@sunroof.eng.sun.com Message-ID: <88256A42.005E62C2.00@hqoutbound.ops.3com.com> Date: Fri, 4 May 2001 12:11:08 -0500 Subject: [mobile-ip] Mobile-IP and MPLS Integration Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi, I have a question regarding LSP tunnel establishment between Ingress LER of CN and FA-LER of MN in section 3.4.2 . RFC. http://search.ietf.org/internet-drafts/draft-choi-mobileip-ldpext-01.txt (MPLS-based Mobile IP Route Optimization Scenario.) Also, LSP tunnel between HA-LER and FA-LER, is not possible if care of address is of type co-located care-of address. As both the binding and registration messages doesn't contain address of FA . One solution to the above problem is to mention the FA address(LER) in registration message and binding update when care of address is of type co-located. Thanks, Satish Amara From owner-mobile-ip@sunroof.eng.sun.com Fri May 4 13:33:06 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17629 for ; Fri, 4 May 2001 13:33:05 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA21829; Fri, 4 May 2001 10:32:55 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA20095; Fri, 4 May 2001 10:32:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44HV2IM009102 for ; Fri, 4 May 2001 10:31:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f44HV0FD009101 for mobile-ip-dist; Fri, 4 May 2001 10:31:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44HUIIM009087 for ; Fri, 4 May 2001 10:30:20 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA24719 for ; Fri, 4 May 2001 10:30:17 -0700 (PDT) Received: from ws130.nomadiclab.com (ws130.nomadiclab.com [195.165.196.130]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA26387 for ; Fri, 4 May 2001 10:30:16 -0700 (PDT) Received: from ws34.nomadiclab.com (ws34.nomadiclab.com [195.165.196.34]) by ws130.nomadiclab.com (Postfix) with ESMTP id F300E72504 for ; Fri, 4 May 2001 20:30:14 +0300 (EEST) Received: from nomadiclab.com (localhost [127.0.0.1]) by ws34.nomadiclab.com (Postfix) with ESMTP id 725C4BA2F for ; Fri, 4 May 2001 20:30:14 +0300 (EEST) Message-ID: <3AF2E640.9F89C464@nomadiclab.com> Date: Fri, 04 May 2001 18:26:24 +0100 From: Pekka Nikander X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en,fi MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Authenticating BU and PKI References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Lars Henrik Petander wrote: > > On Fri, 4 May 2001, Damien Routier wrote: > > > I think that using a PKI is a problem since a new certificate must be > > published each time a MN gets a new CoA and the CA/RA must check that > > the CoA is rightfully claimed before publishing the certificate > > > > am i completly wrong ? > > Partly, as you would normally want to prove the ownership of the home > addresss and the certificate would bind the home address or FQDN > to a public key. You would need a new certificate only in the case of > renumbering or changing your domain name. Of course in the case of a > previous router acting as a temporary HA for the old CoA, you would still > need to prove the ownership of your previous CoA. There is one more complication. It is not enough that the certificate contains the Home Address. It is also necessary that issuing the CA can be trusted to state the home address right, i.e. that the CA is _authorized_ to issue certificates that contain that particular home address. Determining whether the CA is indeed authorized or not is not necessarily that easy. Basically, the CA must inherit its authority from the ultimate authority, IANA. Thus, IANA should act as the root CA certifying other CAs. A FQDN would do only if we had fully secure reverse DNS, and we don't. On the other hand, if we had fully secure reverse DNS, we wouldn't need the separate certificates since we could use the secure reverse DNS to look up the key based on the home address. Why a secure forward DNS is not enough is left for an exercise to the reader. --Pekka Nikander From owner-mobile-ip@sunroof.eng.sun.com Fri May 4 13:44:10 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17892 for ; Fri, 4 May 2001 13:44:09 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA27289; Fri, 4 May 2001 10:44:01 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA08341; Fri, 4 May 2001 10:43:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44HeqIM009153 for ; Fri, 4 May 2001 10:40:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f44HepqO009151 for mobile-ip-dist; Fri, 4 May 2001 10:40:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44HeEIM009141 for ; Fri, 4 May 2001 10:40:18 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07553 for ; Fri, 4 May 2001 10:40:07 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21008 for ; Fri, 4 May 2001 10:40:06 -0700 (PDT) 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 KAA27519 for ; Fri, 4 May 2001 10:40:06 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f44He2r07170 for ; Fri, 4 May 2001 10:40:02 -0700 X-mProtect: Fri, 4 May 2001 10:40:02 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdM04y6C; Fri, 04 May 2001 10:39:36 PDT Message-ID: <3AF2E95A.1E15AFCE@iprg.nokia.com> Date: Fri, 04 May 2001 10:39:38 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] some comments on the FMIP draft References: <200105041538.IAA25839@heliopolis.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Jim, > >> 3) As I've said before, it would be nice to decouple > >> the need to do the HI/HACK from the rest of this > >> draft. The mobile node should be able to just > >> ask the old access router to buffer its packets > >> while it's in transition. In fact, this has the > >> positive side effect if the oldAR doesn't know > >> anything about the newAR, Yes, the mobile node should be able to ask the oldAR to buffer its packets. This should be able to be done at any time. However, it's not precisely a fast handover issue, and so I don't believe it belongs in the fast handover draft. > One of the problems with requiring signalling from the MN after L2 has indicated > handoff is imminent is that, depending on the particulars of the radio link > protocol, the signalling has a much higher probability of being dropped or > corrupted. The reason that handoff typically occurs is because there > is a drop in the radio signal quality or power below what the radio protocol > deems sufficient for low error rate communication having the contracted > quality of service from the mobile node to the current base station. > We went through this discussion once several months ago on the IPv4 design team. > I don't know whether it surfaced in the IPv6 discussion at all. Any signaling that occurs after the L2 handoff indication is either taken to be (i) highly unreliable or (ii) received by the new access router. The error-prone nature of the wireless link was a constant factor in our discussion, leading us to choose solutions that were robust against errors in every situation, weird or not, that we could think of. For instance, even though we thought it was quite unlikely for IPv6 interface identifiers to collide, we still made the protocol to handle that case. Every message over the air is assumed to be unreliable since the air link is itself considered to be unreliable. There is no assumption that layer 2 guarantees delivery of anything. To this point, we also tried to minimize signaling over the air. > Because this may not necessarily be the case for all radio protocols (for > example, a nanocell protocol), the IPv4 design team decided to offer > the choice of either having the L3 handoff signalling > originate from the mobile node or having the network do the L3 handoff > signalling. The IPv6 design team chose to combine the two techniques and require > both in all cases. IMHO, the need for low latency handoff is poorly > served by this design, because it requires more signalling than if > the two techniques were separated, but I won't try to second guess > the IPv6 design team without more carefully reading the draft. I do not understand this point. We did try to minimize the signaling over the air, and if you can find a way to do it with less, that would very interesting. The step we did not take was to specify every possible way of putting multiple signals in the same packet over the air. Do you think we could get by with less if we had separate variants for network-controlled vs. mobile controlled? Otherwise, what did you mean by "combine the two techniques"? Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Fri May 4 13:56:30 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18046 for ; Fri, 4 May 2001 13:56:29 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA04025; Fri, 4 May 2001 10:56:20 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11039; Fri, 4 May 2001 10:56:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44Hs2IM009271 for ; Fri, 4 May 2001 10:54:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f44Hs23H009270 for mobile-ip-dist; Fri, 4 May 2001 10:54:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44HrhIM009237 for ; Fri, 4 May 2001 10:53:44 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA00791 for ; Fri, 4 May 2001 10:53:43 -0700 (PDT) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA02297 for ; Fri, 4 May 2001 12:26:57 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2650.21) id <2MX5GDHB>; Fri, 4 May 2001 13:53:41 -0400 Message-ID: From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] some comments on the FMIP draft Date: Fri, 4 May 2001 13:53:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Friday, May 04, 2001 5:29 PM To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] some comments on the FMIP draft ... > With regard to the buffering, I need to take a look at > the spec more closely, but in general I think buffering > on newAR is more likely to reduce the gap for real time > traffic. I've talked to people who have done some experiements with > buffering in IPv4 and buffering on the old Foreign Agent resulted > in a noticable gap in real time traffic. Buffering is problematic > in any case for real time traffic, and anything that offers > the opportunity of delays will add to the delay budget and > increase the liklihood that there is a noticable gap. Buffering > on oldAR (in a bicasting/edge tunnel situation) makes sense > for smoothing during ping-ponging however. Buffering isn't the only problem. The forward tunnel is going to change the delay characteristics for the jitter buffers too. If the two AR's are topologically distance and you have a short playback delays, the problem will, in fact, persist until the jitter buffer adapts. From that standpoint, I think it's probably a wash where the buffering is done. GT> I think I mostly agree with your points here...the only case were buffering in the newAR is useful is the case were the MN manages to send an FBU at the oldAR before the handoff...in this case the oldAR may go ahead and start forwarding packets to the newCOA of the MN...This packets can now be buffered at the newAR and be delivered to the MN as soon as it connects to the newAR...You have to admit that it does not get faster than that...and we wanted to allow this to happen... GT> Also buffering is a difficult subject ...and while we (design team) recognized it to be important we did not think we could solve this at the same time...The problem is that the MN may or may not request buffering, the network may or may not want to provide the requested buffering ....while not all applications would gain from buffering during handoff....there is a lot to this....and it needs to be resolved but not as part of this draft I think... Thanks George From owner-mobile-ip@sunroof.eng.sun.com Fri May 4 14:45:35 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18983 for ; Fri, 4 May 2001 14:45:34 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09972; Fri, 4 May 2001 11:45:26 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13318; Fri, 4 May 2001 11:45:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44IhlIM009451 for ; Fri, 4 May 2001 11:43:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f44IhlDo009450 for mobile-ip-dist; Fri, 4 May 2001 11:43:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44IhgIM009443 for ; Fri, 4 May 2001 11:43:43 -0700 (PDT) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA28069 for ; Fri, 4 May 2001 14:43:42 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id OAA01305 for mobile-ip@sunroof.eng.sun.com; Fri, 4 May 2001 14:43:56 -0400 (EDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f440hWIM007489 for ; Thu, 3 May 2001 17:43:32 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA00032 for ; Thu, 3 May 2001 17:43:32 -0700 (PDT) Received: from ritchie.cas.McMaster.CA (ritchie.cas.McMaster.CA [130.113.68.10]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA01768 for ; Thu, 3 May 2001 17:43:32 -0700 (PDT) Received: from birkhoff.cas.McMaster.CA (birkhoff.cas.McMaster.CA [130.113.68.8]) by ritchie.cas.McMaster.CA (8.9.3+Sun/8.9.3) with ESMTP id UAA05657 for ; Thu, 3 May 2001 20:43:26 -0400 (EDT) Received: from localhost (tourayy@localhost) by birkhoff.cas.McMaster.CA (8.9.3+Sun/8.9.3) with ESMTP id UAA21353 for ; Thu, 3 May 2001 20:43:26 -0400 (EDT) X-Authentication-Warning: birkhoff.cas.McMaster.CA: tourayy owned process doing -bs Date: Thu, 3 May 2001 20:43:26 -0400 (EDT) From: Yusupha Touray To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Fast Handover v6 Question In-Reply-To: <200104271044.GAA21030@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: To the authors The fast handover for MIPv6 states that when the Mobile node moves to the new Access Router it MUST NOT use its new care-of address as a source address unless it receives a F- BACK from its old Access Router. Consider then the scenario where the mobile node attaches to the new access router but does not receive a F-BACK. The draft says that the mobile node should resend the binding update. In this case then, what address does the mobile node use as the source address of the binding update it re-sends to its old access router? Does it still use it old care-of address? If it does, what about ingress filtering at the new access router? Yusupha From owner-mobile-ip@sunroof.eng.sun.com Fri May 4 15:25:40 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19529 for ; Fri, 4 May 2001 15:25:39 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08058; Fri, 4 May 2001 12:25:27 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA21703; Fri, 4 May 2001 12:24:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44JNAIM009545 for ; Fri, 4 May 2001 12:23:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f44JN94f009544 for mobile-ip-dist; Fri, 4 May 2001 12:23:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44JN0IM009537 for ; Fri, 4 May 2001 12:23:01 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA19575 for ; Fri, 4 May 2001 12:23:00 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA13258 for ; Fri, 4 May 2001 13:56:46 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f44J9Gf06095 for ; Fri, 4 May 2001 12:21:13 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AFC30335; Fri, 4 May 2001 12:10:40 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA15304; Fri, 4 May 2001 12:10:40 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15090.65199.927523.803553@thomasm-u1.cisco.com> Date: Fri, 4 May 2001 12:10:39 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] some comments on the FMIP draft In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit George Tsirtsis writes: > From: Michael Thomas [mailto:mat@cisco.com] > Buffering isn't the only problem. The forward tunnel > is going to change the delay characteristics for > the jitter buffers too. If the two AR's are > topologically distance and you have a short > playback delays, the problem will, in fact, > persist until the jitter buffer adapts. From > that standpoint, I think it's probably a wash > where the buffering is done. > > GT> I think I mostly agree with your points here...the only case were > buffering in the newAR is useful is the case were the MN manages to send an > FBU at the oldAR before the handoff...in this case the oldAR may go ahead > and start forwarding packets to the newCOA of the MN...This packets can now > be buffered at the newAR and be delivered to the MN as soon as it connects > to the newAR...You have to admit that it does not get faster than that...and > we wanted to allow this to happen... Yes, faster, but the question is it faster that actually makes a difference in reality. Playback delay with jitter buffers need to be able to smooth the entire set of glitches that might happen to get acceptible voice quality (sorry to be so VoIP-centric here), and the difference of, oh say, an extra 10ms with, say, an 80ms playback delay may not be terribly significant. > GT> Also buffering is a difficult subject ...and while we (design team) > recognized it to be important we did not think we could solve this at the > same time...The problem is that the MN may or may not request buffering, the > network may or may not want to provide the requested buffering ....while not > all applications would gain from buffering during handoff....there is a lot > to this....and it needs to be resolved but not as part of this draft I > think... Yup. I'm just trying to be constructive within the design criteria you-all are claiming is important. Mike From owner-mobile-ip@sunroof.eng.sun.com Fri May 4 15:28:03 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19558 for ; Fri, 4 May 2001 15:28:02 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA15192; Fri, 4 May 2001 12:27:51 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA20468; Fri, 4 May 2001 12:27:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44JQNIM009567 for ; Fri, 4 May 2001 12:26:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f44JQNJQ009566 for mobile-ip-dist; Fri, 4 May 2001 12:26:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44JQEIM009559 for ; Fri, 4 May 2001 12:26:14 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA22103 for ; Fri, 4 May 2001 12:26:14 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA14861 for ; Fri, 4 May 2001 14:00:02 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f44JQCn23856 for ; Fri, 4 May 2001 12:26:12 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AFC30760; Fri, 4 May 2001 12:26:10 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA15310; Fri, 4 May 2001 12:26:10 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15091.594.131775.425631@thomasm-u1.cisco.com> Date: Fri, 4 May 2001 12:26:10 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] some comments on the FMIP draft In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit George Tsirtsis writes: > > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Friday, May 04, 2001 1:51 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] some comments on the FMIP draft > > > 1) This generally needs a pass at spelling and de-Frenchifying > George's grammar :-) > > GT> I do not ming that you think I can not spell....but calling me French > is going too far ;-) ...maybe the draft actually looked "all Greek to you" > which would be a fair comment :) A thousand pardons! As my punishment, I'll volunteer to do what I was commenting on :-) Mike From owner-mobile-ip@sunroof.eng.sun.com Fri May 4 15:52:34 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19808 for ; Fri, 4 May 2001 15:52:33 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA24564; Fri, 4 May 2001 12:52:20 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA27049; Fri, 4 May 2001 12:51:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44JmkIM009621 for ; Fri, 4 May 2001 12:48:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f44Jmkqs009620 for mobile-ip-dist; Fri, 4 May 2001 12:48:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44JmbIM009613 for ; Fri, 4 May 2001 12:48:37 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA26217 for ; Fri, 4 May 2001 12:48:32 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA09969 for ; Fri, 4 May 2001 12:48:32 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f44JmaQ19663 for ; Fri, 4 May 2001 12:48:36 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AFC31248; Fri, 4 May 2001 12:48:29 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA15315; Fri, 4 May 2001 12:48:29 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15091.1932.845728.619528@thomasm-u1.cisco.com> Date: Fri, 4 May 2001 12:48:28 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] some comments on the FMIP draft In-Reply-To: <3AF2E95A.1E15AFCE@iprg.nokia.com> References: <200105041538.IAA25839@heliopolis.eng.sun.com> <3AF2E95A.1E15AFCE@iprg.nokia.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Charles E. Perkins writes: > Hello Jim, > > > >> 3) As I've said before, it would be nice to decouple > > >> the need to do the HI/HACK from the rest of this > > >> draft. The mobile node should be able to just > > >> ask the old access router to buffer its packets > > >> while it's in transition. In fact, this has the > > >> positive side effect if the oldAR doesn't know > > >> anything about the newAR, > > Yes, the mobile node should be able to ask the oldAR to > buffer its packets. This should be able to be done at > any time. However, it's not precisely a fast handover > issue, and so I don't believe it belongs in the fast > handover draft. I think this makes an argument for decoupling, no? As far as I can tell, there were three major things that FMIP tried to accomplish: 1) Forward tunnel establishment from the old AR to the MN 2) Buffer of packets while in transition 3) Address Assignment either statefully, or through auto conf (with the requisite DAD) (1) can use normal MIP semantics, obviously (2) if the mobile node can request buffering at whichever router will accommodate it, we can allow this to be an implementation decision (3) can either be done through the normal autoconf, or HI/HACK method. From my reading, it seems that DAD delays might still happen if ARnew isn't able to provide proxy functionality, so this entire part of the draft seems orthogonal to the fast goals (as in, probably shouldn't use an L2 that you want fast handovers on which can't do fast DAD). As such, this looks like it, too, can be decoupled. > The error-prone nature of the wireless link was a constant factor > in our discussion, leading us to choose solutions that were robust > against errors in every situation, weird or not, that we could think > of. For instance, even though we thought it was quite unlikely > for IPv6 interface identifiers to collide, we still made the protocol > to handle that case. Every message over the air is assumed to be > unreliable since the air link is itself considered to be unreliable. > There is no assumption that layer 2 guarantees delivery of anything. > To this point, we also tried to minimize signaling over the air. Just to be clear, you're not assuming that what I proposed requires more air time, right? As far as I can tell, it doesn't. Mike From owner-mobile-ip@sunroof.eng.sun.com Fri May 4 19:31:38 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22370 for ; Fri, 4 May 2001 19:31:37 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA06950; Fri, 4 May 2001 16:31:26 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA12718; Fri, 4 May 2001 16:31:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44NTWIM009812 for ; Fri, 4 May 2001 16:29:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f44NTWoR009811 for mobile-ip-dist; Fri, 4 May 2001 16:29:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44NTOIM009804 for ; Fri, 4 May 2001 16:29:24 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA12811 for ; Fri, 4 May 2001 16:29:20 -0700 (PDT) From: Franck.Le@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA00522 for ; Fri, 4 May 2001 18:04:41 -0600 (MDT) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f44NVYw10989 for ; Fri, 4 May 2001 18:31:44 -0500 (CDT) Received: from daebh02nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 4 May 2001 18:29:04 -0500 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Fri, 4 May 2001 18:29:04 -0500 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B028DC7BC@daeis07nok> To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Proposed changes to draft-ietf-mobileip-aaa-key-0 4.txt Date: Fri, 4 May 2001 18:29:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Pat, It seems that some time ago, you mentioned that you were redefining the extensions for the key distribution between the MN and the AAAh: the key distribution will not be based on long term key encryption anymore but on taking a random number as an input. To the question "Did anyone contribute proposed text?", we replied that we suggested such a mechanism in the following internet draft http://search.ietf.org/internet-drafts/draft-le-mobileip-keydistribution-00. txt, and another approach based on Diffie Hellman is also described. We suggested that the key distribution extensions should allow both methods; and in addition we also proposed that the key distribution extension should allow a mechanism such as the Temporary Shared Key concept to be used: http://search.ietf.org/internet-drafts/draft-le-mobileip-sharedsecret-00.txt Please Pat, what is the current situation of this extension definition ? Best Regards, Franck LE -----Original Message----- From: ext Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] Sent: 11 April, 2001 6:54 PM To: Charles E. Perkins Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Proposed changes to draft-ietf-mobileip-aaa-key-04.txt >I don't mind the change, but if the encoding is cryptographically >strong, it doesn't increase the security by any appreciable amount. Well, not passing a key is certainly harder to break than having a session key pass to the mobile, which can be intercepted (or at least monitored), and perhaps eventually attacked. If a key is derived, then the only way a session key can be cracked is by collecting lots of packets that were authenticated from the key, and attempting a brute force attack. The crypto-folks here much prefer keys to be derived, and want to re-use this scheme for their networks, if we can make the appropriate changes. >> I just had a meeting with the 3GPP2 AHAG WG chair (the group that does all >> cellular security), and they have concerns in regards to the above mentioned >> draft. Instead of having the I-D define that the keys be returned to the >> mobile node, they would prefer that a random value be sent, and have the >> mobile node derive the session key based on a known algorithm, such as: >> >> MD5(MN-AAA Secret + NAI + Random Value) > >Presumably '+' is concatenation. yes > I reckon MD5 should be HMAC_MD5, >and the input data should have the secret appended also after the >random value. oh, well if we want prefix+suffix, then yes, but hmac-hd5 doesn't really need that. In fact, we could even support SHA-1 as well. > Also, so that the algorithm will work with IP addresses >when NAIs are not available, we should allow the identification >bitstring to be the appropriate IP address. sure. > >Did anyone contribute proposed text? As soon as I get back from vacation I will. Of course, I want to make sure that no one objects to this change before I propose any text. PatC From owner-mobile-ip@sunroof.eng.sun.com Fri May 4 22:15:20 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA24714 for ; Fri, 4 May 2001 22:15:20 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA23039; Fri, 4 May 2001 19:15:05 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA09617; Fri, 4 May 2001 19:14:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f452C8IM009879 for ; Fri, 4 May 2001 19:12:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f452C8ri009878 for mobile-ip-dist; Fri, 4 May 2001 19:12:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f452BsIM009871 for ; Fri, 4 May 2001 19:11:54 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA02075 for ; Fri, 4 May 2001 19:11:49 -0700 (PDT) Received: from mail.edu.cn ([202.202.32.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA13127 for ; Fri, 4 May 2001 19:06:33 -0700 (PDT) Received: from tanghong ([202.202.41.21]) by mail.edu.cn (8.9.1b+Sun/8.9.1) with SMTP id KAA23275 for ; Sat, 5 May 2001 10:04:39 +0800 (CST) Message-ID: <002501c0d507$7f8fed00$1529caca@cqupt.edu.cn> From: "tang" To: References: <5F03ACA2F76DD411B8BC00508BE3B4D7EA2E93@esemont203.gbg.edt.ericsson.se> Subject: [mobile-ip] Thank you,Simon Aladdin Date: Sat, 5 May 2001 10:02:34 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f452BtIM009872 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit From owner-mobile-ip@sunroof.eng.sun.com Sun May 6 18:12:11 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14286 for ; Sun, 6 May 2001 18:12:10 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA28319; Sun, 6 May 2001 15:10:26 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA18772; Sun, 6 May 2001 15:10:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f46M8YIM011443 for ; Sun, 6 May 2001 15:08:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f46M8X3d011442 for mobile-ip-dist; Sun, 6 May 2001 15:08:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f46M8OIM011435 for ; Sun, 6 May 2001 15:08:24 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA18674 for ; Sun, 6 May 2001 15:08:24 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA22355 for ; Sun, 6 May 2001 15:08:22 -0700 (PDT) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f46M8MO26248 for ; Mon, 7 May 2001 00:08:22 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Mon May 07 00:08:21 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Mon, 7 May 2001 00:08:21 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBE06@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] some comments on the FMIP draft Date: Mon, 7 May 2001 00:08:21 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Mike, > > => I agree with you. But when we discussed the > > alternative (MN performs DAD in parallel with > > sending and receiving packets) we found that > > it may not work in all cases. Also there were > > some open issues with ND. I would prefer > > that approach (my technical bias) if it > > can work. So if you think it can work when > > considering it in detail, I don't see why not. > > Can you outline some of the problems? > => This is going back a long way now, but from memory ND mandates that the O flag is sent in Neighbour advertisements. If there is a collision in addresses the MN will overwrite someone else's entry in the Neighbour Cache (unless you use security). Of course back then we hadn't discussed creating a new type for the NA. But maybe that would solve it. Some people in the team also wanted to avoid ND when the MN first moves. So they wanted the nAR to have all the MN's info and that was one of the main reasons for HI/HAck. I am one of the people who has always wanted it to be optional or removed and proposed doing DAD in parallel. I don't know what others in the WG think. > > > as if it were just > > > booting up, and when it's ready, send the BU > > > to the oldAR to start flowing the buffered > > > packets. Another benefit is that if, for some > > > reason, the MN can't attach to the ARnew, it > > > can abandon the handoff and still get the > > > buffers from ARold (assuming it is still > > > in range, but if not you're really hosed > > > anyway). > > > > > => Doesn't sound like a real time friendly > > approach though. > > No, of course not. I view this in %*! happens sense, > as in if the MN tries to move to some place it finds > out was a mistake. If the packets were buffered back > at ARold, it could potentially minimize some of its > loss. Not a huge benefit, I'll agree, but it sort of > plays off of the old "bird in the hand is worth two in > bush" principal :-) > => Sure. I don't think buffering will solve the problem but if we have to do it then it should be done in the old AR. Currently the draft doesn't support the MN to request buffering. > > > 5) Is the FBU/FBACK really a different kind of BU? > > > It looks the same as a normal BU. That would > > > actually be rather nice if it were the same > > > since we're probably need to consider the > > > security aspects of them, and it would be nice > > > to have exactly one kind of BU to modify if > > > necessary. Same goes for HMIP as well. > > > > > => It would be the same from a security > > poin of view. I don't see why not. Same > > for HMIPv6. The F-BU will include the > > M flag to ensire coexistence with HMIPv6. > > > > The reason for having a different type is > > the HI/HACK messages. We need to know > > if the BU should trigger HI/HACK or not. > > Could this not be done with a flag in the RS? > As far as I can tell, what I'm proposing would > require the following flags: > > Router Solicit (and RA, I suspect): > > BUFFER: buffer the packets until you see a Binding Update > HANDOVER: execute the HI/HACK > > BU: nothing special since it executes once the MN arrives > BACK: nothing special since it's just a BU > F-NA: deprecate since it's not necessary > > Two new flags in the RS and RA seems a lot cleaner in > my mind than 3 new messages. > => Yup. That is if buffering should be supported at all. Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon May 7 06:49:13 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA05758 for ; Mon, 7 May 2001 06:49:13 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA06761; Mon, 7 May 2001 03:49:05 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA07324; Mon, 7 May 2001 03:48:55 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f47AkeIM011977 for ; Mon, 7 May 2001 03:46:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f47Akecl011976 for mobile-ip-dist; Mon, 7 May 2001 03:46:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f47AkTIM011969 for ; Mon, 7 May 2001 03:46:30 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA07137 for ; Mon, 7 May 2001 03:46:29 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA17069 for ; Mon, 7 May 2001 03:46:25 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05442; Mon, 7 May 2001 06:46:23 -0400 (EDT) Message-Id: <200105071046.GAA05442@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-gnaie-03.txt Date: Mon, 07 May 2001 06:46:23 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --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 : Generalized NAI (GNAIE) Extension Author(s) : M. Khalil, E. Qaddoura, H. Akhtar, P. Calhoun Filename : draft-ietf-mobileip-gnaie-03.txt Pages : 6 Date : 04-May-01 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-ietf-mobileip-gnaie-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-gnaie-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-gnaie-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: <20010504122208.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-gnaie-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-gnaie-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010504122208.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Mon May 7 10:31:19 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13068 for ; Mon, 7 May 2001 10:31:18 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA15362; Mon, 7 May 2001 07:31:12 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA22174; Mon, 7 May 2001 07:31:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f47ESEIM012225 for ; Mon, 7 May 2001 07:28:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f47ESD4M012224 for mobile-ip-dist; Mon, 7 May 2001 07:28:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f47ERmIM012215 for ; Mon, 7 May 2001 07:27:49 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA21732 for ; Mon, 7 May 2001 07:27:47 -0700 (PDT) Received: from sirius.ctr.columbia.edu (sirius.ctr.columbia.edu [128.59.64.60]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA22896 for ; Mon, 7 May 2001 09:17:05 -0600 (MDT) Received: from SWEETPEA (sweetpea.comet.columbia.edu [128.59.65.202]) by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with SMTP id KAA29338 for ; Mon, 7 May 2001 10:27:45 -0400 (EDT) From: "Andrew T. Campbell" To: Subject: [mobile-ip] SIGCOMM CCR Special Issue on Wireless Extensions to the Internet Date: Mon, 7 May 2001 10:26:44 -0700 Message-ID: <000201c0d71a$e3a02a20$ca413b80@SWEETPEA> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Call for Papers ACM SIGCOMM Computer Communication Review http://www.acm.org/sigcomm/ccr/ Special Issue on Wireless Extensions to the Internet http://comet.columbia.edu/~campbell/ccr.htm Over the last several years there has been considerable interest in wireless extensions to the Internet from Industry and academia. The October 2001 issue of Computer Communication Review will be a special issue on wireless extensions to the Internet. The goal of the special issue is to present recent developments in wireless IP networks. We are soliciting full research papers, survey articles and work-in-progress on the following broad set of wireless IP topics: o Extensions to Mobile IP o Micro-Mobility Protocols o Wireless IP QOS o IP-based 3G Networks o Wireless LANs, PANs, MANETs, and Sensor Networks o TCP Performance over Wireless Networks o New Mobile and Wireless Applications o Mobile IP Telephony o Service-Enabled Wireless IP Gateways The submission details are as follows: Papers due: May 15, 2001. Authors notified: August 15, 2001. Camera ready due: September 15, 2001. Publication date: October 2001. All papers should be submitted electronically in PDF or Postscript form to the first guest editor listed below: Andrew T. Campbell Department of Electrical Engineering 1312 Seeley W. Mudd Bldg. Columbia University New York, NY 10027-6699 Email: campbell@comet.columbia.edu http://comet.columbia.edu/~campbell/ Mischa Schwartz Department of Electrical Engineering 1312 Seeley W. Mudd Bldg. Columbia University New York, NY 10027-6699 Email: schwartz@comet.columbia.edu http://www.ee.columbia.edu/people/schwartz.php3 From owner-mobile-ip@sunroof.eng.sun.com Mon May 7 12:07:55 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15375 for ; Mon, 7 May 2001 12:07:54 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA07912; Mon, 7 May 2001 09:07:49 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA17013; Mon, 7 May 2001 09:07:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f47G5aIM012361 for ; Mon, 7 May 2001 09:05:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f47G5ZGG012360 for mobile-ip-dist; Mon, 7 May 2001 09:05:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f47G5QIM012353 for ; Mon, 7 May 2001 09:05:27 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA16567 for ; Mon, 7 May 2001 09:05:26 -0700 (PDT) Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05497 for ; Mon, 7 May 2001 09:05:24 -0700 (PDT) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id LAA17457 for ; Mon, 7 May 2001 11:05:24 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f47G5MC18294 for ; Mon, 7 May 2001 11:05:23 -0500 (CDT) Message-ID: <3AF6B94E.50E76DF4@usa.alcatel.com> Date: Mon, 07 May 2001 11:03:43 -0400 From: Behcet Sarikaya X-Mailer: Mozilla 4.76 [en]C-CCK-MCD BDPjm-Sony3 (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] LMM References: <200105041538.IAA25839@heliopolis.eng.sun.com> <3AF2E95A.1E15AFCE@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Charlie, A host route is a routing table entry or "soft-state" as they call it in HAWAII, one entry per mobile host, and binding cache entry is also soft-state information associating MN address with its care-of address. In HMIP, at the MAP binding cache entries are functionally equivalent to host routes and the packets are tunneled to MN's latest address. Intermediate routers (routers between MAP and AR) do not keep binding cache entry/ host route for each MN, therefore normal IP routing is used. In case of regreg6 each intermediate regreg6 router keeps an entry per MN downstream, i.e. host routes. "Charles E. Perkins" wrote: Subject: Re: [mobile-ip] Final(?) Cut on LMM Requirements Date: Thu, 03 May 2001 12:37:53 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center To: Behcet Sarikaya References: 1 , 2 , 3 Hello Behcet, I'll have to get back to you on this. In the meantime, what is the difference between a host route and a binding cache entry? Regards, Charlie P. Behcet Sarikaya wrote: > > Hi Charlie, > I found your reference to host routes rather odd. > I think that HMIPv6 does not have host routes > maybe expect at the MAP, however regreg6 seems to > have host routes in routers. > Can you please shed some light onto this? > > "Charles E. Perkins" wrote: > > > Hello folks, > > > > I'm finding it difficult to keep up with all the discussion, > > but the following two items stand out: > > > > > 5. LMM shall scale to support millions of nodes. > > > (Comment had been that this was too broad but only other suggestion > > > was: > > > "LMM shall scale so that the number of LMM agents scale linearly or > > > sublinearly with the number of deployed subnets, not the number of > > > mobiles." Unless there is more support for the revision we'll stay > > > with the original) > > > > I think the original is better, unless someone can demonstrate that > > it is actually possible to achieve the suggested linear or sublinear > > growth rate. > > > > > 10. LMM should support autoconfig. > > > > Part of the problem of LMM is to figure out what the mobility > > routing agents are doing, and where they are to be located. > > If LMM involves host routes, then another part of the problem > > will be to manage the distribution of the host routes. A third > > part of the problem will be to find ways for the mobility routing > > agents to be able to discover their interrelationships (e.g., > > how they fit in a hierarchy or mesh, perhaps). > > > > These problems do not all have to be solved at the same time, > > and therefore not all in the same draft. So, for instance, > > one scheme for the distribution of host routes could be compatible > > with multiple schemes for autoconfiguration. I'd even suggest > > that manual configuration is acceptable until we have some > > experience with testing and deployment of some scheme. However, > > this is not at all to say that autoconfiguration schemes are > > not of interest. It's just that we can go a long way towards > > solving LMM problems without the necessary requirement for > > autoconfiguration. > > > > As an example, I think it would be very reasonable to have > > a Proposed Standard for LMM possibly months or even a year > > before having a Proposed Standard for LMM autoconfiguration. > > Look at the example of Router Renumbering for IPv6. On the > > other hand, if we have both ready sooner, so much the better! > > > > Regards, > > Charlie P. Regards, -- Behcet From owner-mobile-ip@sunroof.eng.sun.com Mon May 7 15:01:20 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19306 for ; Mon, 7 May 2001 15:01:19 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA13053; Mon, 7 May 2001 12:01:12 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA25758; Mon, 7 May 2001 12:01:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f47IxFIM012594 for ; Mon, 7 May 2001 11:59:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f47IxEuj012593 for mobile-ip-dist; Mon, 7 May 2001 11:59:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f47Ix6IM012586 for ; Mon, 7 May 2001 11:59:06 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA29123 for ; Mon, 7 May 2001 11:59:01 -0700 (PDT) Received: from idcpa4.pa.interdigital.com ([12.32.197.142]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA16159 for ; Mon, 7 May 2001 13:50:20 -0600 (MDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Mon, 7 May 2001 14:58:01 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] fast handover Date: Mon, 7 May 2001 14:57:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Just wanted to clarify that F-BU sent to the oldAR is to set up a "temporary" tunnel for forwarding packets to newAR, i.e. lasting until after handover is complete? Thus, the lifetime of this tunnel should be short is duration. Is there any guidelines at this point on how this parameter is to be set? -Sharif From owner-mobile-ip@sunroof.eng.sun.com Mon May 7 15:19:15 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19775 for ; Mon, 7 May 2001 15:19:15 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01315; Mon, 7 May 2001 12:19:06 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA00171; Mon, 7 May 2001 12:18:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f47JH1IM012621 for ; Mon, 7 May 2001 12:17:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f47JH0H0012620 for mobile-ip-dist; Mon, 7 May 2001 12:17:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f47JGpIM012613 for ; Mon, 7 May 2001 12:16:51 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA03537 for ; Mon, 7 May 2001 12:16:51 -0700 (PDT) Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA23134 for ; Mon, 7 May 2001 12:16:46 -0700 (PDT) Received: by zcamail05.zca.compaq.com (Postfix, from userid 12345) id 5667BF3E; Mon, 7 May 2001 12:19:38 -0700 (PDT) Received: from exctay-gh03.tay.cpqcorp.net (exctay-gh03.tay.cpqcorp.net [16.103.129.53]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id C1748EA1 for ; Mon, 7 May 2001 12:19:37 -0700 (PDT) Received: by exctay-gh03.tay.cpqcorp.net with Internet Mail Service (5.5.2652.78) id ; Mon, 7 May 2001 15:16:45 -0400 Message-ID: <88BD5A70CA8BFA4CA15D0ED053E49D691466D0@tayexc14.americas.cpqcorp.net> From: "Powell, Ken" To: "'dbj@cs.rice.edu'" , "'charliep@iprg.nokia.com'" Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] draft-ietf-mobileip-ipv6-13 comments Date: Mon, 7 May 2001 15:16:42 -0400 X-Mailer: Internet Mail Service (5.5.2652.78) Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Dave, Charlie, I reviewed draft-ietf-mobileip-ipv6-13 while checking T.J.'s proposal, and discussed my concerns with Vlad Yasevich, Brian Haley, and Greg Colburn here at Compaq. The following items apply specifically to draft 13. I'll send comments on T.J.'s proposal separately. Ken Section 4.6 Conceptual Data Structures I don't understand why the following Binding Cache field exists: > - The time at which a Binding Request was last sent for this > entry, as needed to implement the rate limiting restriction > for sending Binding Requests. I could find two reasons to send a Binding Request: o When a binding cache entry is about to time-out (see Section 8.6). There is no suggestion that the correspondent node should retransmit the binding request if the mobile node does not respond. o When sending a Router Advertisement (see Section 9.8.3). In this case, the Router Advertisement with Binding Request does get retransmitted and rate-limiting applies. Was this Binding Cache field intended to support the rate limiting restriction on the router advertisements? Section 5.6 ICMP Home Agent Address Discovery Request Message What does the mobile node specify in the home address field if it doesn't have a home address, like upon initialization? Should it use the unspecified address in this case? Section 6.2 Modified Prefix Information Option Format > In a solicited Router Advertisement, a router MUST include at least > one Prefix Information option with the Router Address (R) bit set. > Neighbor Discovery specifies that, if including all options in a > Router Advertisement causes the size of the Advertisement to exceed > the link MTU, multiple Advertisements can be sent, each containing > a subset of the options [17]. In this case, at least one of these > multiple Advertisements being sent instead of a single larger > solicited Advertisement, MUST include a Prefix Information option > with the Router Address (R) bit set. Why are these MUST requirements applied to all routers instead of just home agents? There is nothing in Neighbor Discovery or this spec that relies on this information from IPv6 routers that are not home agents. We can see how such information could support applications outside the scope of ND and Mobility, but this doesn't warrant an unconditional mandate. We would prefer to see something like: + In a solicited Router Advertisement, a home agent MUST and all + other routers SHOULD include at least one Prefix Information + option with the Router Address (R) bit set.... Section 7.2 Requirements for All IPv6 Routers Should this section list the new requirements from section 6.2? + - all routers SHOULD include at least one prefix with the R bit + set and with it's full IP address in its router advertisements. Section 9.2 Dynamic Home Agent Address Discovery > - For each entry in this home agents ... > ... The selected global IP address for each home > agent to include in forming the Home Agent Addresses field in the > Reply message MUST be the global IP address of the respective > home agent sharing a prefix with the mobile node's home address > as indicated in the Home Address option in the Request message; During initialization, the mobile node may not have a home address when it performs home agent address discovery. Assuming the mobile node sent the unspecified address instead, what global IP addresses does the home agent select? Perhaps it could select IP addresses that share a prefix with the destination address from the Home Agent Address Discovery Request packet's IPv6 header instead. Same problem in the fourth rule for constructing the Home Agent Addresses Field: > ... The selected global IP address for each home > agent to include in forming the Home Agent Addresses field in the > Reply message MUST be the global IP address of the respective > home agent sharing a prefix with the mobile node's home address > as indicated in the Home Address option in the Request message; Section 9.5 Intercepting Packets for a Mobile Node > - The home agent examines the value of the Prefix Length field > in the new "home registration" Binding Cache entry. If this > value is zero, the following step is carried out only for the > individual home address specified for this binding. If, instead, > this field is nonzero, then the following step is carried out > for each address for the mobile node formed from the interface > identifier in the mobile node's home address in this binding > (the remaining low-order bits in the address after the indicated > subnet prefix), together with each one of the subnet prefixes > currently considered by the home agent to be on-link ... ============== The home agent should forward messages considered by other routers on the home network to be on-link as well. In other words, we think the home agent should use the aggregate list of home network prefixes for this. > - For each specific IP address for the mobile node determined > in the first step above, the home agent multicasts onto the > home link (to the all-nodes multicast address) a Neighbor > Advertisement message [17] on behalf of the mobile node, to > advertise the home agent's own link-layer address for this IP > address. > > All fields in each such Neighbor Advertisement message 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], with > the following exceptions: > > * The Target Address in the Neighbor Advertisement message MUST > be set to the specific IP address for the mobile node. Does the home agent set the Neighbor Advertisement source IP address to its own link-local address as opposed to the mobile node's link-local address? > While a node is serving as a home agent for some mobile node (it > still has a "home registration" entry for this mobile node in its > Binding Cache), the home agent uses IPv6 Neighbor Discovery [17] > to intercept unicast packets on the home link addressed the mobile > node's home address. In order to intercept packets in this way, > the home agent MUST act as a proxy for this mobile node to reply to > any received Neighbor Solicitation messages for it. When a home > agent receives a Neighbor Solicitation message, it MUST check if the > Target Address specified in the message matches the home address > of any mobile node for which it has a Binding Cache entry marked > as a "home registration". This check MUST include all possible > home addresses for the mobile node, based on the subnet prefixes > currently considered to be on-link by the home agent ... ================= The home agent probably should use the aggregate list of prefixes for this as well? Section 9.6 Tunneling Intercepted Packets to a Mobile Node > Tunneling of multicast packets to a mobile node follows similar > limitations to those defined above for unicast packets addressed to > the mobile node's link-local and site-local addresses. Multicast > packets addressed to a multicast address with link-local scope [9], > to which the mobile node is subscribed, MUST NOT be tunneled > to the mobile node; such packets SHOULD be silently discarded > (after delivering to other local multicast recipients). Multicast > packets addressed to a multicast address with scope larger > than link-local but smaller than global (e.g., site-local and > organization-local) [9], to which the mobile node is subscribed, > SHOULD be tunneled to the mobile node by default, but this behavior > MUST be configurable to disable it; this default behavior might > change at some point in the future as the definition of these > scopes become better defined in IPv6. This spec does not explain how a home agent determines what multicast addresses to forward to a mobile node. Host systems normally send Multicast Listener Discovery (MLD) messages to attached routers to join/leave multicast groups. The rules for doing this between mobile node and home agent are undefined. The text above and in section 10.19 indicates a bi-directional tunnel could be used to support this. There is no clear definition of how to set up such a tunnel. What addresses are used for tunnel source and destination? Would the tunnel have its own link local and global interface addresses? Will it carry MLD traffic specifically for the mobile node? What other traffic should such a tunnel between a mobile node and the home agent carry? IMHO we should not try to solve the multicast tunneling issues now. Instead, descriptions of tunneling multicast traffic should be removed from the spec and left for future work. Perhaps the spec could say something like: + It may be possible to tunnel multicast traffic between + a mobile node and it's home agent to extend the range of + a multicast zone. The rules for setting up such tunnels and + for identifying which traffic to forward is beyond the scope + of this spec. Section 9.8.2 Sending Changed Prefix Information to the Mobile Node T.J. Kniveton proposed numerous changes to this section. I couldn't split my comments between the two versions easily. Our comments on T.J.'s work will cover items that apply to this version as well. 9.8.3. Sending Mobile Prefix Advertisements to the Mobile Node > The home agent SHOULD periodically continue to retransmit this > tunneled packet to the mobile node, until it is acknowledged by > the receipt from the mobile node of a Binding Update matching > the Binding Request in the packet (i.e., with matching Sequence > Number). A Binding Update matches a Binding Request if it specifies > a binding for the mobile node to which the Binding Request was sent > and contains a Unique Identifier Sub-Option matching the unique > identifier sent in the Unique Identifier Sub-Option in the Binding > Request. At what rate should this retransmission occur? Once per INITIAL_BINDACK timeout? How many router advertisements should the home agent send before it gives up? Should retransmissions stop if the mobile node's binding is deleted? Section 10.16 Sending Tunneled Router Solicitations T.J. Kniveton proposed numerous changes to this section. I couldn't split my comments between the two versions easily. Our comments on T.J.'s work will cover items that apply to this version as well. Section 10.19 Routing Multicast Packets > Alternatively, a mobile node MAY join multicast groups via a > bi-directional tunnel to its home agent. The mobile node tunnels its > multicast group membership control packets to its home agent, and the > home agent forwards multicast packets down the tunnel to the mobile > node. > > A mobile node that wishes to send packets to a multicast group > also has two options: (1) send directly on the foreign link being > visited; or (2) send via a tunnel to its home agent. Because > multicast routing in general depends upon the Source Address used in > the IPv6 header of the multicast packet, a mobile node that tunnels a > multicast packet to its home agent MUST use its home address as the > IPv6 Source Address of the inner multicast packet. Same concern with multicast messages as for section 9.6. We think this spec should describe option (1) and leave option (2) as beyond scope for now. Section 10.20 Returning Home > ..... > In addition, when returning home prior to the expiration of a current > binding for its home address, and configuring its home address on its > network interface on its home link, the mobile node MUST NOT perform > Duplicate Address Detection on its own home address, in order to > avoid confusion or conflict with its home agent's use of the same > address. ..... Could a mobile node perform DAD if it had knowledge of the home agent's link layer address? It could work as follows: 1) the mobile node runs DAD when it moves to any new physical link; 2) if this happens on the home link, the home agent will respond with a neighbor advertisement defending the mobile node's address; 3) the mobile node recognizes the home agent's link layer address in the neighbor solicit and thus determines it moved home; 4) the mobile node immediately sends a binding update to the home agent to delete the binding (no neighbor solicit needed); 5) the home agent responds with a binding ack to signal that the binding is deleted and the home agent is no longer defending the mobile node's home address; 6) The mobile node runs DAD again; 7) Communication proceeds as normal. 11. Protocol Constants > HomeRtrAdvInterval 1,000 seconds This is the maximum interval between periodic router advertisements from the home agent to the mobile node. Given that advertisements are acknowledged and the periodic advertisements are primarily a fail-safe feature, would it be reasonable to increase this to something like 36000 seconds (1 hour) to further overhead? From owner-mobile-ip@sunroof.eng.sun.com Mon May 7 15:43:31 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20510 for ; Mon, 7 May 2001 15:43:30 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA02206; Mon, 7 May 2001 12:43:26 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA19768; Mon, 7 May 2001 12:42:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f47JZGIM012660 for ; Mon, 7 May 2001 12:35:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f47JZ4Cp012659 for mobile-ip-dist; Mon, 7 May 2001 12:35:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f47JYRIM012652 for ; Mon, 7 May 2001 12:34:29 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA03407 for ; Mon, 7 May 2001 12:34:25 -0700 (PDT) Received: from web13306.mail.yahoo.com (web13306.mail.yahoo.com [216.136.175.42]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id MAA13237 for ; Mon, 7 May 2001 12:34:24 -0700 (PDT) Message-ID: <20010507193424.98516.qmail@web13306.mail.yahoo.com> Received: from [149.112.99.151] by web13306.mail.yahoo.com; Mon, 07 May 2001 12:34:24 PDT Date: Mon, 7 May 2001 12:34:24 -0700 (PDT) From: Ash h Subject: Re: [mobile-ip] Mobile-IP and MPLS Integration To: mobile-ip@sunroof.eng.sun.com In-Reply-To: <88256A42.005E62C2.00@hqoutbound.ops.3com.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1714636915-989264064=:96876" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --0-1714636915-989264064=:96876 Content-Type: text/plain; charset=us-ascii Why do you think that the co-located care-of-addr should be treated differently? If the COA is conveyed to the Ingress LER all that it needs to do is to establish a tunnel [LSP] to that address. The mobile node should be capable of understanding the Label Map Request. If not then I don't know how the FA's address will help, since the tunnel is expected to terminate at the MN but gets terminated at the FA and the FA doesn't know what it should do with the datagram after decapsulation. Correct me. Satish_Amara@3com.com wrote: Hi, I have a question regarding LSP tunnel establishment between Ingress LER of CN and FA-LER of MN in section 3.4.2 . RFC. http://search.ietf.org/internet-drafts/draft-choi-mobileip-ldpext-01.txt (MPLS-based Mobile IP Route Optimization Scenario.) Also, LSP tunnel between HA-LER and FA-LER, is not possible if care of address is of type co-located care-of address. As both the binding and registration messages doesn't contain address of FA . One solution to the above problem is to mention the FA address(LER) in registration message and binding update when care of address is of type co-located. Thanks, Satish Amara --------------------------------- Do You Yahoo!? Yahoo! Auctions - Click and bid on cool stuff like Dave Matthews Band Tickets & more! --0-1714636915-989264064=:96876 Content-Type: text/html; charset=us-ascii

Why do you think that the co-located care-of-addr should be treated differently? If the COA is conveyed to the Ingress LER all that it needs to do is to establish a tunnel [LSP] to that address. The mobile node should be capable of understanding the Label Map Request. If not then I don't know how the FA's address will help, since the tunnel is expected to terminate at the MN but gets terminated at the FA and the FA doesn't know what it should do with the datagram after decapsulation. Correct me.

  Satish_Amara@3com.com wrote:


Hi,
I have a question regarding LSP tunnel establishment between Ingress LER
of CN and FA-LER of MN in
section 3.4.2 . RFC.
http://search.ietf.org/internet-drafts/draft-choi-mobileip-ldpext-01.txt
(MPLS-based Mobile IP Route Optimization Scenario.) Also, LSP tunnel between
HA-LER and
FA-LER, is not possible if care of address is of type co-located care-of
address. As both the binding and
registration messages doesn't contain address of FA . One solution to the above
problem
is to mention the FA address(LER) in registration message and binding update
when care of address is of
type co-located.

Thanks,
Satish Amara

Do You Yahoo!?
Yahoo! Auctions - Click and bid on cool stuff like Dave Matthews Band Tickets & more! --0-1714636915-989264064=:96876-- From owner-mobile-ip@sunroof.eng.sun.com Mon May 7 16:35:34 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21836 for ; Mon, 7 May 2001 16:35:34 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA27143; Mon, 7 May 2001 13:35:19 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA16008; Mon, 7 May 2001 13:35:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f47KXjIM012723 for ; Mon, 7 May 2001 13:33:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f47KXjrI012722 for mobile-ip-dist; Mon, 7 May 2001 13:33:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f47KXaIM012715 for ; Mon, 7 May 2001 13:33:36 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA18511 for ; Mon, 7 May 2001 13:33:35 -0700 (PDT) Received: from zrc2s03g.us.nortel.com ([47.103.122.66]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA13064 for ; Mon, 7 May 2001 13:33:35 -0700 (PDT) Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id PAA20652 for ; Mon, 7 May 2001 15:34:09 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Mon, 7 May 2001 15:33:28 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 7 May 2001 15:33:04 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E43021EF0C9@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] LMM Requirements Date: Mon, 7 May 2001 15:32:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D734.D98A61D0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C0D734.D98A61D0 Content-Type: text/plain; charset="iso-8859-1" Raj, In regards to this, I believe it might be better to make them both sentences. " 1. Is support for multilevel hierarchies a requirement for LMM? 2. A single level of hierarchy is sufficient as the requirements for LMM can be met by engineering the network right. " ------_=_NextPart_001_01C0D734.D98A61D0 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] LMM Requirements

Raj,


In regards to this, I believe it might be better to make them both sentences.

"
1. Is support for multilevel hierarchies a requirement for LMM?
2. A single level of hierarchy is sufficient as the requirements for
LMM can be met by engineering the network right.
"


------_=_NextPart_001_01C0D734.D98A61D0-- From owner-mobile-ip@sunroof.eng.sun.com Mon May 7 16:44:00 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22019 for ; Mon, 7 May 2001 16:44:00 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA01848; Mon, 7 May 2001 13:43:55 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA18152; Mon, 7 May 2001 13:43:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f47KgOIM012760 for ; Mon, 7 May 2001 13:42:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f47KgNWR012759 for mobile-ip-dist; Mon, 7 May 2001 13:42:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f47KgEIM012752 for ; Mon, 7 May 2001 13:42:15 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA20227 for ; Mon, 7 May 2001 13:42:14 -0700 (PDT) Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA14742 for ; Mon, 7 May 2001 13:42:13 -0700 (PDT) Received: by zcamail05.zca.compaq.com (Postfix, from userid 12345) id C4CB09A8; Mon, 7 May 2001 13:45:03 -0700 (PDT) Received: from exctay-gh03.tay.cpqcorp.net (exctay-gh03.tay.cpqcorp.net [16.103.129.53]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id 4FF7C887 for ; Mon, 7 May 2001 13:45:03 -0700 (PDT) Received: by exctay-gh03.tay.cpqcorp.net with Internet Mail Service (5.5.2652.78) id ; Mon, 7 May 2001 16:42:10 -0400 Message-ID: <88BD5A70CA8BFA4CA15D0ED053E49D692457C7@tayexc14.americas.cpqcorp.net> From: "Powell, Ken" To: "'T.J. Kniveton'" Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Mobile Prefix Advertisements Date: Mon, 7 May 2001 16:42:00 -0400 X-Mailer: Internet Mail Service (5.5.2652.78) Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi T.J., I reviewed your proposed changes to draft-ietf-mobileip-ipv6-13 (the version with new ICMP msg types), and discussed some of my concerns with Vlad Yasevich, Brian Haley, and Greg Colburn here at Compaq. We are still working through Section 9.8.2. I thought it worth sending the comments up to that point for now. We'll send more along later as we work our way through them. I changed some line-breaks in pasted text for readability. I understand my mail system tends to chop lines longer than 72 characters. Ken Section 4.5 New IPv6 ICMP Messages Should this section mention the new ICMP Mobile Prefix Solicitation and ICMP Mobile Prefix Advertisement messages? Section 5.8 ICMP Mobile Prefix Solicitation Message Format Will the Destination Option extension header with a Home Address option normally be included? The exception would be during mobile node initialization when the mobile node does not have a home address yet. 5.9 ICMP Mobile Prefix Advertisement Message Format > Destination Address > If a Mobile Prefix Solicitation was sent, the Source > Address field from that packet. If the Mobile Prefix Solicitation contained a home address option, should the should this Destination Address be set to the mobile node's home address? > For unsolicited > message, the mobile node's home address or care-of > address may be used. I don't think the home agent should send an unsolicited MPA message to the mobile node's care-of address. Unsolicited messages should only be sent when there is a valid home registration, and in that case, sending to the home address seems the best approach. Always doing so would probably make it easier for the mobile node to associate the advertisement with a particular home network. This message header should include a reserved field to align the remaining prefix options on a 64-bit boundary. > The Prefix Information option is defined in Section > 4.6.2 of [17]. The home agent MAY use the modified > option described in this draft to convey other home > agents' global addresses as well as their prefixes. Section 9.8.1 indicates the home agent clears global address information of other routers when building the aggregate prefix list. It also calls this a SHOULD requirement. Therefore, I think this statement should be changed to: + The Prefix Information Option is defined in + Section 4.6.2 of [17] with modifications defined + in Section 6.2 of this specification. The home + agent uses this option to send an aggregate + list of home network prefixes as defined in + Section 9.8.1." It may be helpful to allow the Source Link Layer Address option on the Mobile Prefix Advertisement message. As section 10.20 points out, the home agent's link layer address can be very handy to know before returning home. I think you should also allow the Advertisement Interval Option to support processing defined in Section 10.16. 9.8.1. Building Aggregate List of Home Network Prefixes > A mobile node on a remote network SHOULD autoconfigure all of > the global IP addresses, which it would autoconfigure if it were > attached to its home network, that are served by home agents. ============================== What does this underlined phrase mean? > To support this, the home agent monitors prefixes advertised on > the home link by itself and other home agents, and passes the ... ===================== Why limit this to prefixes from other home agents only? Why not use prefixes from any router? > - Check Router Advertisements which contain an H bit (from other > home agents) for valid prefixes that are not yet in the > aggregate list, and if they are usable for autoconfiguration > (A bit set, and prefix length less than 80 bits) add them and > preserve the L flag value. Clear the R flag and zero the > interface-id portion of the Same question on home agent advertisement restriction. Why not use prefixes from all routers on the home subnet? I noticed you added an interesting optimization of filtering out any prefixes not used for autoconfiguration. This seems like a reasonable thing to do. The mobile node ignores this info when off link, and will rediscover all it needs soon after moving home. Should this same filter be used to restrict which prefixes from the home agent's AdvPrefixList are copied to the aggregate list? I don't understand the test for "length less than 80 bits". I assume that a node cannot autoconfigure to prefixes with different lengths on the same link. The specific length allowed is defined in the "IPv6 over foo" spec (where "foo" is a link type like "ethernet"). Perhaps change this test to "the prefix length is valid for address autoconfiguration on the home subnet". > ..... It may > be possible to construct an aggregate list by combining information > contained in the home agent's AdvPrefixList and its Home Agent List > used for Dynamic Home Agent Address Discovery (section 10.7). I don't think this will work. Only prefixes with the "R" bit set are added to the home agent's list. There is no guarantee that all prefixes with an "A" bit set will also have the "R" bit set. In addition, this does not account for prefixes advertised by routers not acting as home agents. 9.8.2 Sending Changed Prefix Information to the Mobile Node I have multiple concerns in this section. I wish we had a proposal ready to fix these, but that's not so easy. 1) There is a requirement at the end of section 9.8.3 to send all prefixes periodically. This is necessary to avoid eventual expiration of prefixes that don't change on the mobile node. Between this section, and 9.8.3, I'm confused about when all prefixes get sent as opposed to just sending changes. 2) I don't fully understand what your trying to do with the following MAY requirements: > MUST: > - The valid or preferred lifetime or the state of the flags > changes for the prefix of the mobile node's registered home > address changes > - The mobile node requests the information with a Router > Solicitation (see section 10.16). > > MAY: > - A new prefix is added to the aggregate list > - The valid or preferred lifetime or the state of the flags > changes for a prefix which is not used in any binding cache > entry for this mobile node It looks like its addressing a problem I've been wondering about. A mobile node with multiple home addresses could either - establish a single binding with a non-zero prefix length to cover all its home addresses, or - establish multiple bindings each with a zero prefix length to cover a single home address. In the latter case, how does the home agent recognize that a single node has multiple bindings? The home agent shouldn't send duplicate home prefix advertisements to the mobile node. One way to fix this for the home agent to only send prefix information that is applicable to a specific binding. If the prefix length of the binding is zero, send information only for the home address's prefix. If the prefix length is non-zero, send information for all addresses in the aggregate list. 3) There may be a problem if the scheduling algorithm causes the home agent to transmit a home prefix advertisement to all mobile nodes at the same time. There probably should be a requirement to avoid this. Perhaps the scheduling of prefix advertisements should be done independently for each home registration? From owner-mobile-ip@sunroof.eng.sun.com Mon May 7 16:56:06 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22210 for ; Mon, 7 May 2001 16:56:06 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA08270; Mon, 7 May 2001 13:56:00 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA06685; Mon, 7 May 2001 13:55:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f47KsSIM012796 for ; Mon, 7 May 2001 13:54:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f47KsSU2012795 for mobile-ip-dist; Mon, 7 May 2001 13:54:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f47KsJIM012788 for ; Mon, 7 May 2001 13:54:19 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA20682 for ; Mon, 7 May 2001 13:54:18 -0700 (PDT) Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA19193 for ; Mon, 7 May 2001 15:46:01 -0600 (MDT) Received: by zcamail05.zca.compaq.com (Postfix, from userid 12345) id 7158BC63; Mon, 7 May 2001 13:57:05 -0700 (PDT) Received: from exctay-gh03.tay.cpqcorp.net (exctay-gh03.tay.cpqcorp.net [16.103.129.53]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id 29D22F35 for ; Mon, 7 May 2001 13:57:05 -0700 (PDT) Received: by exctay-gh03.tay.cpqcorp.net with Internet Mail Service (5.5.2652.78) id ; Mon, 7 May 2001 16:54:12 -0400 Message-ID: <88BD5A70CA8BFA4CA15D0ED053E49D692457CD@tayexc14.americas.cpqcorp.net> From: "Powell, Ken" To: "'T.J. Kniveton'" , "'dbj@cs.rice.edu'" , "'charliep@iprg.nokia.com'" Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Mobile Prefix Advertisements ... additional thoug ht Date: Mon, 7 May 2001 16:54:05 -0400 X-Mailer: Internet Mail Service (5.5.2652.78) Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I've been wondering about the coupling between mobile prefix solicitation/advertisement and binding request/ update/ack. Specifically: - Section 9.8.2 describes how a binding update could trigger a mobile prefix advertisement - Section 9.8.3 describes how a binding request/update is used to acknowledge the mobile prefix advertisement This leads me to consider the following exchange: mobile node <--> home agent =========================== --> binding update w/ ack bit set (destination option processing on home agent handles processes binding update and sends binding ack, then signals ICMP mobile prefix handler to check for pending advertisements) <-- binding ack <-- mobile prefix advertisement w/ binding request --> binding update w/ ack bit set <-- binding ack It seems we could simplify the exchange rules by adding an ICMP mobile prefix ack message that could be used to replace the final binding request/update/ack exchange. --> binding update w/ ack bit set <-- binding ack <-- mobile prefix advertisement --> mobile prefix ack Ken From owner-mobile-ip@sunroof.eng.sun.com Mon May 7 16:58:29 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22245 for ; Mon, 7 May 2001 16:58:28 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA09696; Mon, 7 May 2001 13:58:17 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA23502; Mon, 7 May 2001 13:57:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f47KtbIM012806 for ; Mon, 7 May 2001 13:55:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f47KtaE2012805 for mobile-ip-dist; Mon, 7 May 2001 13:55:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f47KtQIM012798 for ; Mon, 7 May 2001 13:55:26 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA22913 for ; Mon, 7 May 2001 13:55:25 -0700 (PDT) From: Satish_Amara@3com.com Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA24391 for ; Mon, 7 May 2001 13:55:25 -0700 (PDT) Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f47Krf306102 for ; Mon, 7 May 2001 13:53:41 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104]) by opal.3com.com (Switch-2.1.1/Switch-2.1.0) with SMTP id f47KtOk16015 for ; Mon, 7 May 2001 13:55:24 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256A45.0072ED13 ; Mon, 7 May 2001 13:55:17 -0700 X-Lotus-FromDomain: 3COM To: mobile-ip@sunroof.eng.sun.com Message-ID: <88256A45.0072E929.00@hqoutbound.ops.3com.com> Date: Mon, 7 May 2001 15:38:57 -0500 Subject: Re: [mobile-ip] Mobile-IP and MPLS Integration Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=I8g3RRZlZC5LLq7Gnvc0FFJAWjuADVIMo2iPU5PDlzXliHpdEx8wjaPa" Content-Disposition: inline Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --0__=I8g3RRZlZC5LLq7Gnvc0FFJAWjuADVIMo2iPU5PDlzXliHpdEx8wjaPa Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hi, Please see for my comments. Ash h on 05/07/2001 02:34:24 PM Please respond to mobile-ip@sunroof.eng.sun.com Sent by: Ash h To: mobile-ip@sunroof.eng.sun.com cc: (Satish Amara/MW/US/3Com) Subject: Re: [mobile-ip] Mobile-IP and MPLS Integration Why do you think that the co-located care-of-addr should be treated differently? If the COA is conveyed to the Ingress LER all that it needs to do is to establish a tunnel [LSP] to that address. The mobile node should be capable of understanding the Label Map Request. If not then I don't know how the FA's address will help, since the tunnel is expected to terminate at the MN but gets terminated at the FA and the FA doesn't know what it should do with the datagram after decapsulation. Correct me. >>I am assuming mobile nodes doesn't support MPLS as MPLS is still "core networks technology". FA would handle the packet in similar way as it did when COA is of type foreign agent. >>Also, let say we want to use MPLS for fast forwarding and QOS and not to eliminate IP tunnel. In this case, we probably want to fast switch packet from Ingress(HA) to Egress(FA). Thanks, Satish Satish_Amara@3com.com wrote: Hi, I have a question regarding LSP tunnel establishment between Ingress LER of CN and FA-LER of MN in section 3.4.2 . RFC. http://search.ietf.org/internet-drafts/draft-choi-mobileip-ldpext-01.txt (MPLS-based Mobile IP Route Optimization Scenario.) Also, LSP tunnel between HA-LER and FA-LER, is not possible if care of address is of type co-located care-of address. As both the binding and registration messages doesn't contain address of FA . One solution to the above problem is to mention the FA address(LER) in registration message and binding update when care of address is of type co-located. Thanks, Satish Amara --------------------------------- Do You Yahoo!? Yahoo! Auctions - Click and bid on cool stuff like Dave Matthews Band Tickets & more! --0__=I8g3RRZlZC5LLq7Gnvc0FFJAWjuADVIMo2iPU5PDlzXliHpdEx8wjaPa Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PFA+IFdoeSBkbyB5b3UgdGhpbmsgdGhhdCB0aGUgY28tbG9jYXRlZCBjYXJlLW9mLWFkZHIgc2hv dWxkIGJlIHRyZWF0ZWQgZGlmZmVyZW50bHk/Jm5ic3A7SWYmbmJzcDt0aGUgQ09BIGlzIGNvbnZl eWVkIHRvIHRoZSBJbmdyZXNzIExFUiBhbGwgdGhhdCBpdCBuZWVkcyB0byBkbyBpcyB0byBlc3Rh Ymxpc2ggYSB0dW5uZWwgW0xTUF0gdG8gdGhhdCBhZGRyZXNzLiBUaGUgbW9iaWxlIG5vZGUgc2hv dWxkIGJlIGNhcGFibGUgb2YgdW5kZXJzdGFuZGluZyB0aGUgTGFiZWwgTWFwIFJlcXVlc3QuJm5i c3A7SWYgbm90IHRoZW4gSSBkb24ndCBrbm93IGhvdyB0aGUgRkEncyBhZGRyZXNzIHdpbGwgaGVs cCwgc2luY2UgdGhlIHR1bm5lbCBpcyBleHBlY3RlZCB0byB0ZXJtaW5hdGUgYXQgdGhlIE1OIGJ1 dCZuYnNwO2dldHMgdGVybWluYXRlZCBhdCB0aGUgRkEgYW5kIHRoZSBGQSBkb2Vzbid0IGtub3cg d2hhdCBpdCBzaG91bGQgZG8gd2l0aCB0aGUgZGF0YWdyYW0gYWZ0ZXIgZGVjYXBzdWxhdGlvbi4g Q29ycmVjdCBtZS48QlI+PC9QPg0KPFA+Jm5ic3A7IDxCPjxJPlNhdGlzaF9BbWFyYUAzY29tLmNv bTwvST48L0I+IHdyb3RlOiA8QlI+DQo8QkxPQ0tRVU9URSBzdHlsZT0iQk9SREVSLUxFRlQ6ICMx MDEwZmYgMnB4IHNvbGlkOyBNQVJHSU4tTEVGVDogNXB4OyBQQURESU5HLUxFRlQ6IDVweCI+PEJS PkhpLDxCUj5JIGhhdmUgYSBxdWVzdGlvbiByZWdhcmRpbmcgTFNQIHR1bm5lbCBlc3RhYmxpc2ht ZW50IGJldHdlZW4gSW5ncmVzcyBMRVI8QlI+b2YgQ04gYW5kIEZBLUxFUiBvZiBNTiBpbjxCUj5z ZWN0aW9uIDMuNC4yIC4gUkZDLjxCUj5odHRwOi8vc2VhcmNoLmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC1jaG9pLW1vYmlsZWlwLWxkcGV4dC0wMS50eHQ8QlI+KE1QTFMtYmFzZWQgTW9i aWxlIElQIFJvdXRlIE9wdGltaXphdGlvbiBTY2VuYXJpby4pIEFsc28sIExTUCB0dW5uZWwgYmV0 d2VlbjxCUj5IQS1MRVIgYW5kPEJSPkZBLUxFUiwgaXMgbm90IHBvc3NpYmxlIGlmIGNhcmUgb2Yg YWRkcmVzcyBpcyBvZiB0eXBlIGNvLWxvY2F0ZWQgY2FyZS1vZjxCUj5hZGRyZXNzLiBBcyBib3Ro IHRoZSBiaW5kaW5nIGFuZDxCUj5yZWdpc3RyYXRpb24gbWVzc2FnZXMgZG9lc24ndCBjb250YWlu IGFkZHJlc3Mgb2YgRkEgLiBPbmUgc29sdXRpb24gdG8gdGhlIGFib3ZlPEJSPnByb2JsZW08QlI+ aXMgdG8gbWVudGlvbiB0aGUgRkEgYWRkcmVzcyhMRVIpIGluIHJlZ2lzdHJhdGlvbiBtZXNzYWdl IGFuZCBiaW5kaW5nIHVwZGF0ZTxCUj53aGVuIGNhcmUgb2YgYWRkcmVzcyBpcyBvZjxCUj50eXBl IGNvLWxvY2F0ZWQuPEJSPjxCUj5UaGFua3MsPEJSPlNhdGlzaCBBbWFyYTxCUj48QlI+PC9CTE9D S1FVT1RFPjxwPjxociBzaXplPTE+PGI+RG8gWW91IFlhaG9vIT88L2I+PGJyPg0KPGEgaHJlZj0i aHR0cDovL2F1Y3Rpb25zLnlhaG9vLmNvbS8iPllhaG9vISBBdWN0aW9uczwvYT4gLSBDbGljayBh bmQgYmlkIG9uIGNvb2wgc3R1ZmYgbGlrZSA8YSBocmVmPSJodHRwOi8vdXNlci5hdWN0aW9ucy55 YWhvby5jb20vc2hvdy9hdWN0aW9ucz91c2VySUQ9ZGF2ZV9tYXR0aGV3c19iYW5kX3RpY2tldHMm dT0lM2FkYXZlX21hdHRoZXdzX2JhbmRfdGlja2V0cyI+RGF2ZSBNYXR0aGV3cyBCYW5kIFRpY2tl dHM8L2E+ICYgPGEgaHJlZj0iaHR0cDovL2F1Y3Rpb25zLnlhaG9vLmNvbSI+bW9yZSE8L2E+DQo= --0__=I8g3RRZlZC5LLq7Gnvc0FFJAWjuADVIMo2iPU5PDlzXliHpdEx8wjaPa-- From owner-mobile-ip@sunroof.eng.sun.com Mon May 7 17:02:22 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22295 for ; Mon, 7 May 2001 17:02:21 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA25009; Mon, 7 May 2001 14:02:10 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA07978; Mon, 7 May 2001 14:01:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f47L0hIM012836 for ; Mon, 7 May 2001 14:00:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f47L0gF7012835 for mobile-ip-dist; Mon, 7 May 2001 14:00:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f47L0XIM012828 for ; Mon, 7 May 2001 14:00:33 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA22006 for ; Mon, 7 May 2001 14:00:33 -0700 (PDT) Received: from zrc2s03g.us.nortel.com ([47.103.122.66]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA25878 for ; Mon, 7 May 2001 14:00:31 -0700 (PDT) Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id QAA00494 for ; Mon, 7 May 2001 16:01:11 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Mon, 7 May 2001 16:00:52 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 7 May 2001 16:00:26 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E43021EF139@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] re: Questions about Route Optimization in MIPv4 Date: Mon, 7 May 2001 16:00:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D738.B9EB9B60" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C0D738.B9EB9B60 Content-Type: text/plain; charset="iso-8859-1" Hyun, I've added some more references and comments below. I've also decided to go ASCII. ------ original ----- From: hspark@etri.re.kr [mailto:hspark@etri.re.kr] Sent: Monday, April 30, 2001 9:29 PM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Questions about Route Optimization in MIPv4 Hello, All ... I have some questions about Route Optimization in MIP... It is somewhat an old story... In IMHP (Internet Mobile Host Protocol), the origin of Route Optimization in MIP, there is a notion of "Cache Agent" that is a intermediate router capable of caching a binding for MN... Why was "Cache Agent" excluded from Route Optimization in MIP I-D when adopted by WG ? [Morrow, Glenn ] I do not know why. I'd like to know too. It seems to me that the cache is better suited to be implemented on a purpose-built device than a web server for the majority of Internet Traffic. [Hyun Seo] I agree with you... As you stated, if a "Cache Agent" or "Correspondent Agent" (the name is not a problem) realizable, [GM2] I don't care about the name either. To refresh other people's memory, here is a link to one of the IMHP papers from 1994: http://citeseer.nj.nec.com/perkins94imhp.html Please refer to section 7.2 for the discussion of intermediate caching agents. This paper suggested the use of snooping for the indication mechanism. It seems to me that CAs would add a great deal of value to MIP, especially for deployment and location-private route-optmization. [Hyun Seo] it is possible to provide route optimization without requiring any change to CNs in the Internet... [GM2] Yes, indeed; no one knows if the CN supports route optimization or not anyway. I really don't expect that a user on an MN - halfway in the middle of some application, is going to be able or, for that matter, want to have to push a magic button saying "try to optimize the route". Or it is now O.K. to give away my location to this node. This is common sense ergonomics. I don't think people like maintaining lists of people and nodes that it is O.K. to do route optimization with either. [Hyun Seo] And security association for authentication of Binding Update message is efficiently managed... [GM2 ] Yes, indeed again. 5000% agreement. [Hyun Seo] But I think the problem is "HOW" to make "Cache Agent" realizable... IMHO, there is no perfect solution for that yet... [GM2] Please expand. It will require change - that's for sure. [Hyun Seo] lmk draft is a good candidate, but NOT every router in the present Internet does processing IP router alert option... [GM2] Right - but routing protocols can convey whether domains and network portions do support such things. In this manner, each router knows if the next hop and "domain" supports something or not and can behave accordingly. With the router alerts and routing protocols, you get controlled deployability and proxied security associations. Also routers typically get upgraded on a set of controlled schedules with soak periods, etc.. In many cases (consumer internet access) there is no method for a provider to control the downstream clients' software. In the large enterprise, control lists could store the capabilities of hosts - but what a pain for the administrators. [Hyun Seo] And there are some security concerns over "intercepting Binding Update or Reg. Request midway"... [GM2] Yes, there are some tough engineering choices to make. It seems to me that you have to trust something or someone. If the goal is to meet a requirement of location-private route-optimization, you don't want to trust the CN's anyway. That leaves only routers and service providers. This is the assumption about the security associations in the lmk proposal. [GM2] Binding updates are route updates after all. Why not trust routers? We trust routers to route our traffic and maintain routes correctly already. We also trust them to not spike off our traffic to somone else. Why not use their existing security associations to our advantage. Local mobility management will greatly increase the scalability. The interior routers of an administrative domain can ignore the alerts. Only the local hops close to the mobile, inderdomain hops and the last hop have to pay attention to the alerts. Tunneling can also be used over interior spans depending on the implementation of the alerts and policy. The use of routers for security seems to fit in nicely with the existing social contract that exists between the users of hosts and the providers of the network. The SA's are there - might as well use them to our advantage. [GM2] If a domain does not support the function it can reply back to the MN indicating this. [GM2] I must say I am very open to other proposals trying to solve these functional issues. [Hyun Seo] Am I right ? [GM2] I may not understand. Please elaborate on the exact concerns so we can work together to arrive at an acceptable solution. [Hyun Seo] I think R+A burdens intermediate routers with bulky datagram discrimination (Is it IP or IP2 ?)... [GM2] There has to be some kind of indication. It would be very nice to create a new hop by hop option (I think we refer to it as "edge alert" in the lmk draft) that would only be passed and processed on the slow path based upon information in the RIP, RPIB, FIB for a particular ingress or egress interface. [GM2] But really the same thing can be done today even with the existing router alert. I.e. the router alert has an indication of the protocol which caused the alert in the option. It seems to me that packet engines could be smart enough to take a look at the protocol and determine based upon FIB, RPIB, RIB information whether they should slow path this particular alert or not. It is an implementation issue, though. Some existing hardware may not be able to do this slow/fast path discrimination. There is also the tunneling method similar to how RSVP handles it which can be employed to short circuit these intermediates not capable of the discrimination. This tunneling would also allow deployment of a set of custom SA's which could easily be agreed and administered via routing policy for a consortium of operators such as cellular and their corresponding infrastructure suppliers. [GM2] I personally favor the discrimination to leverage the existing SA's between domains but the tunneling of alerts similar to RSVP with arbitrary SA's could be done as well. These signals can be encrypted between hops to allow for more privacy, too. It seems to me that more slow path processing MIPs are pretty cheap with Moore's law and all that. Most commercial router architectures allow for offboarding of this processing already. [GM2] I believe a there are some other folks working on a far more flexible protocol for doing alerts for the NSIS work. Hopefully this new work will deal with these security issues as well; I'm not sure if they have signed up to all I'm making this out to be yet, though. It will be up to them. [Hyun Seo] Does anyone have another nice approach ? [GM2] While mobility is just one application, I can see other uses for a more flexible and scalable alerting and SA infrastructure as this convergence occurs. I would recommend focusing these changes towards the NSIS effort. -- SNIP ---- [Hyun Seo] I found not a exact match but some helpful documents... IP Mobility Support with IP-Squred(IP2) Encapsulation Technique, by K. Okanoue and T. Ohsawa (IEICE Trans. Commun. Vol.E-80B, No.8) It was an internet-draft and it contains R+A notion... http://search.ieice.org/1997/pdf/b081198.pdf [GM2] Interesting intersection of concepts. It suggests to use a more standard method of snooping for the indication. I'm not sure about the indication method used when dealing with IPSEC tunnels, VPNs etc.. It doesn't appear to deal with the fact that a CN may have multiple routes in an out of a given subnet. The paper may have just been leaving these details out to get the basic points across, though. I'd like to see how this work has progressed. This paper at least shows in mathematical terms the advantage of having a C-A close to CN in terms of route updates. I found it very helpful. Thanks, Glenn ------_=_NextPart_001_01C0D738.B9EB9B60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [mobile-ip] re: Questions about Route Optimization in = MIPv4

Hyun,
I've added some more references and comments below. =
I've also decided to go ASCII.

------ original -----
From: hspark@etri.re.kr [mailto:hspark@etri.re.kr]
Sent: Monday, April 30, 2001 9:29 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Questions about Route = Optimization in MIPv4

Hello, All ...

I have some questions about Route Optimization in = MIP...
It is somewhat an old story...

In IMHP (Internet Mobile Host Protocol), the origin = of Route Optimization in MIP,
there is a notion of "Cache Agent" that is = a intermediate router capable of caching a binding for MN...
Why was "Cache Agent" excluded from Route = Optimization in MIP I-D when adopted by WG ? 

[Morrow, Glenn ]
I do not know why. I'd like to know too.  It = seems to me that the cache is  better suited to be implemented on = a purpose-built device than a web server for the majority of Internet = Traffic.

[Hyun Seo]
I agree with you...
As you stated, if a "Cache Agent" or = "Correspondent Agent" (the name is not a problem) realizable, =

[GM2]
I don't care about the name either.
To refresh other people's memory, here is a link to = one of the IMHP papers from 1994:
http://citeseer.nj.nec.com/perkins94imhp.html
Please refer to section 7.2 for the discussion of = intermediate caching agents. This paper suggested the use of snooping = for the indication mechanism. It seems to me that CAs would add a great = deal of value to MIP, especially for deployment and location-private = route-optmization.

[Hyun Seo]
it is possible to provide route optimization without = requiring any change to CNs in the Internet... 

[GM2] Yes, indeed; no one knows if the CN supports = route optimization or not anyway. I really don't expect that a user on = an MN - halfway in the middle of some application, is going to be able = or, for that matter, want to have to push a magic button saying = "try to optimize the route". Or it is now O.K. to give away = my location to this node. This is common sense ergonomics. I don't = think people like maintaining lists of people and nodes that it is O.K. = to do route optimization with either.

[Hyun Seo]
And security association for authentication of = Binding Update message is efficiently managed...

[GM2 ]  Yes, indeed again. 5000% = agreement.

[Hyun Seo]
But I think the problem is "HOW" to make = "Cache Agent" realizable...
IMHO, there is no perfect solution for that = yet...

[GM2] 
Please expand. It will require change - that's for = sure.

[Hyun Seo]
lmk draft is a good candidate, but NOT every router = in the present Internet does processing IP router alert = option...

[GM2]
Right - but routing protocols can convey whether = domains and network portions do support such things. In this manner, = each router knows if the next hop and "domain" supports = something or not and can behave accordingly. With the router alerts and = routing protocols, you get controlled deployability and proxied = security associations. Also routers typically get upgraded on a set of = controlled schedules with soak periods, etc.. In many cases (consumer = internet access) there is no method for a provider to control  the = downstream clients' software. In the large enterprise, control lists = could store the capabilities of hosts - but what a pain for the = administrators.

[Hyun Seo]
And there are some security concerns over = "intercepting Binding Update or Reg. Request  = midway"...

[GM2] 
Yes, there are some tough engineering choices to = make. It seems to me that you have to trust something or someone. If = the goal is to meet a requirement of location-private = route-optimization, you don't want to trust the CN's anyway. That = leaves only routers and service providers.  This is the assumption = about the security associations in the lmk proposal.

[GM2]
Binding updates are route updates after all. Why not = trust routers?  We trust routers to route our traffic and maintain = routes correctly already. We also trust them to not spike off our = traffic to somone else. Why not use their existing security = associations to our advantage. Local mobility management will greatly = increase the scalability. The interior routers of an administrative = domain can ignore the alerts. Only the local hops close to the mobile, = inderdomain hops and the last hop have to pay attention to the alerts. = Tunneling can also be used over interior spans depending on the = implementation of the alerts and policy. The use of routers for = security seems to fit in nicely with the existing social contract that = exists between the users of hosts and the providers of the network. The = SA's are there - might as well use them to our advantage.

[GM2]
If a domain does not support the function it can = reply back to the MN indicating this.
[GM2]
I must say I am very open to other proposals trying = to solve these functional issues.

[Hyun Seo]
Am I right ?


[GM2] 
I may not understand. Please elaborate on the exact = concerns so we can work together to arrive at an acceptable = solution.

[Hyun Seo]
I think R+A burdens intermediate routers with bulky = datagram discrimination (Is it IP or IP2 ?)...

[GM2] 
There has to be some kind of indication. It would be = very nice to create a new hop by hop option  (I think we refer to = it as "edge alert" in the lmk draft) that would only be = passed and processed on the slow path based upon information in the = RIP, RPIB, FIB for a particular ingress or egress interface. =

[GM2]
But really the same thing can be done today even = with the existing router alert. I.e. the router alert has an indication = of the protocol which caused the alert in the option. It seems to me = that packet engines could be smart enough to take a look at the = protocol and determine based upon FIB, RPIB, RIB information whether = they should slow path this particular alert or not. It is an = implementation issue, though. Some existing hardware may not be able to = do this slow/fast path discrimination. There is also the tunneling = method similar to how RSVP handles it which can be employed to short = circuit these intermediates not capable of the discrimination. This = tunneling would also allow deployment of a set of custom SA's which = could easily be agreed and administered via routing policy for a = consortium of operators such as cellular and their corresponding = infrastructure suppliers.

[GM2]
I personally favor the discrimination to leverage = the existing SA's between domains but the tunneling of alerts similar = to RSVP with arbitrary SA's could be done as well. These signals can be = encrypted between hops to allow for more privacy, too. It seems to me = that more slow path processing MIPs are pretty cheap with Moore's law = and all that. Most commercial router architectures allow for = offboarding of this processing already.

[GM2]
I believe a there are some other folks working on a = far more flexible protocol for  doing alerts for the NSIS work. = Hopefully this new work will deal with these security issues as well; = I'm not sure if they have signed up to all I'm making this out to be = yet, though. It will be up to them.

[Hyun Seo]
Does anyone have another nice approach ?

[GM2]  While mobility is just one application, I = can see other uses for a more flexible and scalable alerting and SA = infrastructure as this convergence occurs. I would recommend focusing = these changes towards the NSIS effort. 

-- SNIP ----

[Hyun Seo] I found not a exact match but some helpful = documents... 

IP Mobility Support with IP-Squred(IP2) Encapsulation = Technique, by K. Okanoue and T. Ohsawa (IEICE Trans. Commun. Vol.E-80B, = No.8)

It was an internet-draft and it contains R+A = notion...

http://search.ieice.org/1997/pdf/b081198.pdf =


[GM2]
Interesting intersection of concepts. It suggests to = use a more standard method of snooping for the indication. I'm not sure = about the indication method used when dealing with IPSEC tunnels, VPNs = etc..   It doesn't appear to deal with the fact that a CN may = have multiple routes in an out of a given subnet. The paper may have = just been leaving these details out to get the basic points across, = though. I'd like to see how this work has progressed. This paper at = least shows in mathematical terms the advantage of having a C-A close = to CN in terms of route updates.

 
I found it very helpful.
 
Thanks,
 
Glenn
 

------_=_NextPart_001_01C0D738.B9EB9B60-- From owner-mobile-ip@sunroof.eng.sun.com Mon May 7 17:28:23 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22756 for ; Mon, 7 May 2001 17:28:22 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA24242; Mon, 7 May 2001 14:28:16 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA04098; Mon, 7 May 2001 14:28:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f47LQbIM012871 for ; Mon, 7 May 2001 14:26:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f47LQakS012870 for mobile-ip-dist; Mon, 7 May 2001 14:26:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f47LQSIM012863 for ; Mon, 7 May 2001 14:26:28 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA28753 for ; Mon, 7 May 2001 14:26:25 -0700 (PDT) Received: from web13305.mail.yahoo.com (web13305.mail.yahoo.com [216.136.175.41]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA10926 for ; Mon, 7 May 2001 14:26:24 -0700 (PDT) Message-ID: <20010507212624.9879.qmail@web13305.mail.yahoo.com> Received: from [149.112.99.151] by web13305.mail.yahoo.com; Mon, 07 May 2001 14:26:24 PDT Date: Mon, 7 May 2001 14:26:24 -0700 (PDT) From: Ash h Subject: Re: [mobile-ip] Mobile-IP and MPLS Integration To: mobile-ip@sunroof.eng.sun.com In-Reply-To: <88256A45.0072E929.00@hqoutbound.ops.3com.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1681692777-989270784=:9430" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --0-1681692777-989270784=:9430 Content-Type: text/plain; charset=us-ascii I guess we are concurring with the fact that the COA must be that of the FA and never that of the MN since MN may not participate in MPLS. Hence the FA should not allow colocated COA if it is in its capacity and instead use the FA COA to terminate the LSP. Thus the need to carry the FA address in a different field may not be necessary[ COA = FA's addr]. I don't think this will hamper any semantics assigned to the LSP (viz QOS, VPN etc). Satish_Amara@3com.com wrote: Hi, Please see for my comments. Ash h on 05/07/2001 02:34:24 PM Please respond to mobile-ip@sunroof.eng.sun.com Sent by: Ash h To: mobile-ip@sunroof.eng.sun.com cc: (Satish Amara/MW/US/3Com) Subject: Re: [mobile-ip] Mobile-IP and MPLS Integration Why do you think that the co-located care-of-addr should be treated differently? If the COA is conveyed to the Ingress LER all that it needs to do is to establish a tunnel [LSP] to that address. The mobile node should be capable of understanding the Label Map Request. If not then I don't know how the FA's address will help, since the tunnel is expected to terminate at the MN but gets terminated at the FA and the FA doesn't know what it should do with the datagram after decapsulation. Correct me. >>I am assuming mobile nodes doesn't support MPLS as MPLS is still "core networks technology". FA would handle the packet in similar way as it did when COA is of type foreign agent. >>Also, let say we want to use MPLS for fast forwarding and QOS and not to eliminate IP tunnel. In this case, we probably want to fast switch packet from Ingress(HA) to Egress(FA). Thanks, Satish Satish_Amara@3com.com wrote: Hi, I have a question regarding LSP tunnel establishment between Ingress LER of CN and FA-LER of MN in section 3.4.2 . RFC. http://search.ietf.org/internet-drafts/draft-choi-mobileip-ldpext-01.txt (MPLS-based Mobile IP Route Optimization Scenario.) Also, LSP tunnel between HA-LER and FA-LER, is not possible if care of address is of type co-located care-of address. As both the binding and registration messages doesn't contain address of FA . One solution to the above problem is to mention the FA address(LER) in registration message and binding update when care of address is of type co-located. Thanks, Satish Amara --------------------------------- Do You Yahoo!? Yahoo! Auctions - Click and bid on cool stuff like Dave Matthews Band Tickets & more! Why do you think that the co-located care-of-addr should be treated differently? If the COA is conveyed to the Ingress LER all that it needs to do is to establish a tunnel [LSP] to that address. The mobile node should be capable of understanding the Label Map Request. If not then I don't know how the FA's address will help, since the tunnel is expected to terminate at the MN but gets terminated at the FA and the FA doesn't know what it should do with the datagram after decapsulation. Correct me. Satish_Amara@3com.com wrote: Hi, I have a question regarding LSP tunnel establishment between Ingress LER of CN and FA-LER of MN in section 3.4.2 . RFC. http://search.ietf.org/internet-drafts/draft-choi-mobileip-ldpext-01.txt (MPLS-based Mobile IP Route Optimization Scenario.) Also, LSP tunnel between HA-LER and FA-LER, is not possible if care of address is of type co-located care-of address. As both the binding and registration messages doesn't contain address of FA . One solution to the above problem is to mention the FA address(LER) in registration message and binding update when care of address is of type co-located. Thanks, Satish Amara --------------------------------- Do You Yahoo!? Yahoo! Auctions - Click and bid on cool stuff like Dave Matthews Band Tickets & more! --------------------------------- Do You Yahoo!? Yahoo! Auctions - Click and bid on cool stuff like Dave Matthews Band Tickets & more! --0-1681692777-989270784=:9430 Content-Type: text/html; charset=us-ascii

   I guess we are concurring with the fact that the COA must be that of the FA and never that of the MN since MN may not participate in MPLS. Hence the FA should not allow colocated COA if it is in its capacity and instead use the FA COA to terminate the LSP. Thus the need to carry the FA address in a different field may not be necessary[ COA = FA's addr]. I don't think this will hamper any semantics assigned to the LSP (viz QOS, VPN etc).

  Satish_Amara@3com.com wrote:



Hi,
Please see for my comments.




Ash h on 05/07/2001 02:34:24 PM

Please respond to mobile-ip@sunroof.eng.sun.com

Sent by: Ash h


To: mobile-ip@sunroof.eng.sun.com
cc: (Satish Amara/MW/US/3Com)
Subject: Re: [mobile-ip] Mobile-IP and MPLS Integration




Why do you think that the co-located care-of-addr should be treated
differently? If the COA is conveyed to the Ingress LER all that it needs to do
is to establish a tunnel [LSP] to that address. The mobile node should be
capable of understanding the Label Map Request. If not then I don't know how the
FA's address will help, since the tunnel is expected to terminate at the MN but
gets terminated at the FA and the FA doesn't know what it should do with the
datagram after decapsulation. Correct me.

>>I! ! ! ! am assuming mobile nodes doesn't support MPLS as MPLS is still "core
networks technology". FA would handle
the packet in similar way as it did when COA is of type foreign agent.

>>Also, let say we want to use MPLS for fast forwarding and QOS and not to
eliminate IP tunnel. In this case, we
probably want to fast switch packet from Ingress(HA) to Egress(FA).

Thanks,
Satish


Satish_Amara@3com.com wrote:

Hi,
I have a question regarding LSP tunnel establishment between Ingress LER
of CN and FA-LER of MN in
section 3.4.2 . RFC.
http://search.ietf.org/internet-drafts/draft-choi-mobileip-ldpext-01.txt
(MPLS-based Mobile IP Route Optimization Scenario.) Also, LSP tunnel between
HA-LER and
FA-LER, is not possible if care of address is of type co-located care-of
address. As both the binding and
registration messages doesn't contain address of FA . One solution to the above
problem
is to mention the FA a! ! ! ! ddress(LER) in registration message and binding update
when care of address is of
type co-located.

Thanks,
Satish Amara



---------------------------------
Do You Yahoo!?
Yahoo! Auctions - Click and bid on cool stuff like Dave Matthews Band Tickets &
more!

Why do you think that the co-located care-of-addr should be treated differently? If the COA is conveyed to the Ingress LER all that it needs to do is to establish a tunnel [LSP] to that address. The mobile node should be capable of understanding the Label Map Request. If not then I don't know how the FA's address will help, since the tunnel is expected to terminate at the MN but gets terminated at the FA and the FA doesn't know what it should do with the datagram after decapsulation. Correct me.


  Satish_Amara@3com.com wrote:


Hi,
I have a question regarding LSP tunnel establishment between Ingress LER
of CN and FA-LER of MN in
section 3.4.2 . RFC.
http://search.ietf.org/internet-drafts/draft-choi-mobileip-ldpext-01.txt
(MPLS-based Mobile IP Route Optimization Scenario.) Also, LSP tunnel between
HA-LER and
FA-LER, is not possible if care of address is of type co-located care-of
address. As both the binding and
registration messages doesn't contain address of FA . One solution to the above
problem
is to mention the FA address(LER) in registration message and binding update
when care of address is of
type co-located.

Thanks,
Satish Amara




Do You Yahoo!?
Yahoo! Auctions - Click and bid on cool stuff like Dave Matthews Band Tickets & more!

Do You Yahoo!?
Yahoo! Auctions - Click and bid on cool stuff like Dave Matthews Band Tickets & more! --0-1681692777-989270784=:9430-- From owner-mobile-ip@sunroof.eng.sun.com Mon May 7 19:13:38 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24207 for ; Mon, 7 May 2001 19:13:37 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA08174; Mon, 7 May 2001 16:13:19 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA19721; Mon, 7 May 2001 16:13:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f47NBmIM012986 for ; Mon, 7 May 2001 16:11:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f47NBmoV012985 for mobile-ip-dist; Mon, 7 May 2001 16:11:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f47NBdIM012978 for ; Mon, 7 May 2001 16:11:39 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA04973 for ; Mon, 7 May 2001 16:11:40 -0700 (PDT) Received: from web13302.mail.yahoo.com (web13302.mail.yahoo.com [216.136.175.38]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id QAA04765 for ; Mon, 7 May 2001 16:11:39 -0700 (PDT) Message-ID: <20010507230155.37743.qmail@web13302.mail.yahoo.com> Received: from [149.112.99.151] by web13302.mail.yahoo.com; Mon, 07 May 2001 16:01:55 PDT Date: Mon, 7 May 2001 16:01:55 -0700 (PDT) From: Ash h Subject: Re: [mobile-ip] Mobile-IP and MPLS Integration To: Satish_Amara@3com.com Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: <88256A45.0078CA3D.00@hqoutbound.ops.3com.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1804289383-989276515=:37622" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --0-1804289383-989276515=:37622 Content-Type: text/plain; charset=us-ascii The problem that I sense in using the FA addr in the Binding/Registration Req is at the point where the decapulation is to occur. If the LSP terminates at the FA then would the FA not have to re encapsulate the datagram using the MN's colocated COA before fwding it to the MN? This is because the MN would expect itself to be the tunnel terminator. How would one solve this? Satish_Amara@3com.com wrote: Hi, I am trying to solve the integration problem when MN nodes wants to use colocated COA but's doesn't have MPLS functionality. One scenario is the mobile node may want to use new address for new sessions but want to use old address for current sessions. Thanks, Satish Satish Amara Ash h on 05/07/2001 04:26:24 PM Please respond to mobile-ip@sunroof.eng.sun.com Sent by: Ash h To: mobile-ip@sunroof.eng.sun.com cc: (Satish Amara/MW/US/3Com) Subject: Re: [mobile-ip] Mobile-IP and MPLS Integration I guess we are concurring with the fact that the COA must be that of the FA and never that of the MN since MN may not participate in MPLS. Hence the FA should not allow colocated COA if it is in its capacity and instead use the FA COA to terminate the LSP. Thus the need to carry the FA address in a different field may not be necessary[ COA = FA's addr]. I don't think this will hamper any semantics assigned to the LSP (viz QOS, VPN etc). Satish_Amara@3com.com wrote: Hi, Please see for my comments. Ash h on 05/07/2001 02:34:24 PM Please respond to mobile-ip@sunroof.eng.sun.com Sent by: Ash h To: mobile-ip@sunroof.eng.sun.com cc: (Satish Amara/MW/US/3Com) Subject: Re: [mobile-ip] Mobile-IP and MPLS Integration Why do you think that the co-located care-of-addr should be treated differently? If the COA is conveyed to the Ingress LER all that it needs to do is to establish a tunnel [LSP] to that address. The mobile node should be capable of understanding the Label Map Request. If not then I don't know how the FA's address will help, since the tunnel is expected to terminate at the MN but gets terminated at the FA and the FA doesn't know what it should do with the datagram after decapsulation. Correct me. >>I am assuming mobile nodes doesn't support MPLS as MPLS is still "core networks technology". FA would handle the packet in similar way as it did when COA is of type foreign agent. >>Also, let say we want to use MPLS for fast forwarding and QOS and not to eliminate IP tunnel. In this case, we probably want to fast switch packet from Ingress(HA) to Egress(FA). Thanks, Satish Satish_Amara@3com.com wrote: Hi, I have a question regarding LSP tunnel establishment between Ingress LER of CN and FA-LER of MN in section 3.4.2 . RFC. http://search.ietf.org/internet-drafts/draft-choi-mobileip-ldpext-01.txt (MPLS-based Mobile IP Route Optimization Scenario.) Also, LSP tunnel between HA-LER and FA-LER, is not possible if care of address is of type co-located care-of address. As both the binding and registration messages doesn't contain address of FA . One solution to the above problem is to mention the FA address(LER) in registration message and binding update when care of address is of type co-located. Thanks, Satish Amara --------------------------------- Do You Yahoo!? Yahoo! Auctions - Click and bid on cool stuff like Dave Matthews Band Tickets & more! Why do you think that the co-located care-of-addr should be treated differently? If the COA is conveyed to the Ingress LER all that it needs to do is to establish a tunnel [LSP] to that address. The mobile node should be capable of understanding the Label Map Request. If not then I don't know how the FA's address will help, since the tunnel is expected to terminate at the MN but gets terminated at the FA and the FA doesn't know what it should do with the datagram after decapsulation. Correct me. Satish_Amara@3com.com wrote: Hi, I have a question regarding LSP tunnel establishment between Ingress LER of CN and FA-LER of MN in section 3.4.2 . RFC. http://search.ietf.org/internet-drafts/draft-choi-mobileip-ldpext-01.txt (MPLS-based Mobile IP Route Optimization Scenario.) Also, LSP tunnel between HA-LER and FA-LER, is not possible if care of address is of type co-located care-of address. As both the binding and registration messages doesn't contain address of FA . One solution to the above problem is to mention the FA address(LER) in registration message and binding update when care of address is of type co-located. Thanks, Satish Amara --------------------------------- Do You Yahoo!? Yahoo! Auctions - Click and bid on cool stuff like Dave Matthews Band Tickets & more! --------------------------------- Do You Yahoo!? Yahoo! Auctions - Click and bid on cool stuff like Dave Matthews Band Tickets & more! I guess we are concurring with the fact that the COA must be that of the FA and never that of the MN since MN may not participate in MPLS. Hence the FA should not allow colocated COA if it is in its capacity and instead use the FA COA to terminate the LSP. Thus the need to carry the FA address in a different field may not be necessary[ COA = FA's addr]. I don't think this will hamper any semantics assigned to the LSP (viz QOS, VPN etc). Satish_Amara@3com.com wrote: Hi, Please see for my comments. Ash h on 05/07/2001 02:34:24 PM Please respond to mobile-ip@sunroof.eng.sun.com Sent by: Ash h To: mobile-ip@sunroof.eng.sun.com cc: (Satish Amara/MW/US/3Com) Subject: Re: [mobile-ip] Mobile-IP and MPLS Integration Why do you think that the co-located care-of-addr should be treated differently? If the COA is conveyed to the Ingress LER all that it needs to do is to establish a tunnel [LSP] to that address. The mobile node should be capable of understanding the Label Map Request. If not then I don't know how the FA's address will help, since the tunnel is expected to terminate at the MN but gets terminated at the FA and the FA doesn't know what it should do with the datagram after decapsulation. Correct me. >>! ;I! ! ! ! am assuming mobile nodes doesn't support MPLS as MPLS is still "core networks technology". FA would handle the packet in similar way as it did when COA is of type foreign agent. >>Also, let say we want to use MPLS for fast forwarding and QOS and not to eliminate IP tunnel. In this case, we probably want to fast switch packet from Ingress(HA) to Egress(FA). Thanks, Satish Satish_Amara@3com.com wrote: Hi, I have a question regarding LSP tunnel establishment between Ingress LER of CN and FA-LER of MN in section 3.4.2 . RFC. http://search.ietf.org/internet-drafts/draft-choi-mobileip-ldpext-01.txt (MPLS-based Mobile IP Route Optimization Scenario.) Also, LSP tunnel between HA-LER and FA-LER, is not possible if care of address is of type co-located care-of address. As both the binding and registration messages doesn't contain address of FA . One solution to the above problem is to mention the FA! a! ! ! ! ddress(LER) in registration message and binding update when care of address is of type co-located. Thanks, Satish Amara --------------------------------- Do You Yahoo!? Yahoo! Auctions - Click and bid on cool stuff like Dave Matthews Band Tickets & more! Why do you think that the co-located care-of-addr should be treated differently? If the COA is conveyed to the Ingress LER all that it needs to do is to establish a tunnel [LSP] to that address. The mobile node should be capable of understanding the Label Map Request. If not then I don't know how the FA's address will help, since the tunnel is expected to terminate at the MN but gets terminated at the FA and the FA doesn't know what it should do with the datagram after decapsulation. Correct me. Satish_Amara@3com.com wrote: Hi, I have a question regarding LSP tunnel establishment between Ingress LER of CN and FA-LER of MN in section 3.4.2 . RFC. http://search.ietf.org/internet-drafts/draft-choi-mobileip-ldpext-01.txt (MPLS-based Mobile IP Route Optimization Scenario.) Also, LSP tunnel between HA-LER and FA-LER, is not possible if care of address is of type co-located care-of address. As both the binding and registration messages doesn't contain address of FA . One solution to the above problem is to mention the FA address(LER) in registration message and binding update when care of address is of type co-located. Thanks, Satish Amara --------------------------------- Do You Yahoo!? Yahoo! Auctions - Click and bid on cool stuff like Dave Matthews Band Tickets & more! --------------------------------- Do You Yahoo!? Yahoo! Auctions - Click and bid on cool stuff like Dave Matthews Band Tickets & more! --------------------------------- Do You Yahoo!? Yahoo! Auctions - Click and bid on cool stuff like Dave Matthews Band Tickets & more! --0-1804289383-989276515=:37622 Content-Type: text/html; charset=us-ascii

The problem that I sense in using the FA addr in the Binding/Registration Req is at the point where the decapulation is to occur. If the LSP terminates at the FA then would the FA not have to re encapsulate the datagram using the MN's colocated COA before fwding it to the MN? This is because the MN would expect itself to be the tunnel terminator. How would one solve this?

  Satish_Amara@3com.com wrote:



Hi,
I am trying to solve the integration problem when MN nodes wants to use
colocated COA but's doesn't have MPLS functionality. One scenario is the mobile
node may want to use new address for new sessions but want to use old address
for current sessions.

Thanks,
Satish

Satish Amara




Ash h on 05/07/2001 04:26:24 PM

Please respond to mobile-ip@sunroof.eng.sun.com

Sent by: Ash h


To: mobile-ip@sunroof.eng.sun.com
cc: (Satish Amara/MW/US/3Com)
Subject: Re: [mobile-ip] Mobile-IP and MPLS Integration






I guess we are concurring with the fact that the COA must be that of the FA
and never that of the MN since MN may not participate in MPLS. Hence the FA
should not allow colocated COA if it is in its capacity and instead use the FA
COA to te! ! ! ! rminate the LSP. Thus the need to carry the FA address in a different
field may not be necessary[ COA = FA's addr]. I don't think this will hamper any
semantics assigned to the LSP (viz QOS, VPN etc).


Satish_Amara@3com.com wrote:


Hi,
Please see for my comments.




Ash h on 05/07/2001 02:34:24 PM

Please respond to mobile-ip@sunroof.eng.sun.com

Sent by: Ash h


To: mobile-ip@sunroof.eng.sun.com
cc: (Satish Amara/MW/US/3Com)
Subject: Re: [mobile-ip] Mobile-IP and MPLS Integration




Why do you think that the co-located care-of-addr should be treated
differently? If the COA is conveyed to the Ingress LER all that it needs to do
is to establish a tunnel [LSP] to that address. The mobile node should be
capable of understanding the Label Map Request. If not then I don't know how the
FA's address will help, since the tunnel is expected to terminate at the MN but
gets terminated a! ! ! ! t the FA and the FA doesn't know what it should do with the
datagram after decapsulation. Correct me.

>>I am assuming mobile nodes doesn't support MPLS as MPLS is still "core
networks technology". FA would handle
the packet in similar way as it did when COA is of type foreign agent.

>>Also, let say we want to use MPLS for fast forwarding and QOS and not to
eliminate IP tunnel. In this case, we
probably want to fast switch packet from Ingress(HA) to Egress(FA).

Thanks,
Satish


Satish_Amara@3com.com wrote:

Hi,
I have a question regarding LSP tunnel establishment between Ingress LER
of CN and FA-LER of MN in
section 3.4.2 . RFC.
http://search.ietf.org/internet-drafts/draft-choi-mobileip-ldpext-01.txt
(MPLS-based Mobile IP Route Optimization Scenario.) Also, LSP tunnel between
HA-LER and
FA-LER, is not possible if care of address is of type co-located care-of
address. As both the binding an! ! ! ! d
registration messages doesn't contain address of FA . One solution to the above
problem
is to mention the FA address(LER) in registration message and binding update
when care of address is of
type co-located.

Thanks,
Satish Amara



---------------------------------
Do You Yahoo!?
Yahoo! Auctions - Click and bid on cool stuff like Dave Matthews Band Tickets &
more!


Why do you think that the co-located care-of-addr should be treated differently?
If the COA is conveyed to the Ingress LER all that it needs to do is to
establish a tunnel [LSP] to that address. The mobile node should be capable of
understanding the Label Map Request. If not then I don't know how the FA's
address will help, since the tunnel is expected to terminate at the MN but gets
terminated at the FA and the FA doesn't know what it should do with the datagram
after decapsulation. Correct me.



Satish_Amara@3com.com wrot! ! ! ! e:


Hi,
I have a question regarding LSP tunnel establishment between Ingress LER
of CN and FA-LER of MN in
section 3.4.2 . RFC.
http://search.ietf.org/internet-drafts/draft-choi-mobileip-ldpext-01.txt
(MPLS-based Mobile IP Route Optimization Scenario.) Also, LSP tunnel between
HA-LER and
FA-LER, is not possible if care of address is of type co-located care-of
address. As both the binding and
registration messages doesn't contain address of FA . One solution to the above
problem
is to mention the FA address(LER) in registration message and binding update
when care of address is of
type co-located.

Thanks,
Satish Amara





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

Do You Yahoo!?
Yahoo! Auctions - Click and bid on cool stuff like Dave Matthews Band Tickets &
more!

---------------------------------
Do You Yahoo!?
Yahoo! Auctions - Click and bid on cool stuff like Dave Matthews Band ! ! ! ! Tickets &
more!


   I guess we are concurring with the fact that the COA must be that of the FA and never that of the MN since MN may not participate in MPLS. Hence the FA should not allow colocated COA if it is in its capacity and instead use the FA COA to terminate the LSP. Thus the need to carry the FA address in a different field may not be necessary[ COA = FA's addr]. I don't think this will hamper any semantics assigned to the LSP (viz QOS, VPN etc).


  Satish_Amara@3com.com wrote:



Hi,
Please see for my comments.




Ash h on 05/07/2001 02:34:24 PM

Please respond to mobile-ip@sunroof.eng.sun.com

Sent by: Ash h


To: mobile-ip@sunroof.eng.sun.com
cc: (Satish Amara/MW/US/3Com)
Subject: Re: [mobile-ip] Mobile-IP and MPLS Integration




Why do you think that the co-located care-of-addr should be treated
differently? If the COA is conveyed to the Ingress LER all that it needs to do
is to establish a tunnel [LSP] to that address. The mobile node should be
capable of understanding the Label Map Request. If not then I don't know how the
FA's address will help, since the tunnel is expected to terminate at the MN but
gets terminated at the FA and the FA doesn't know what it should do with the
datagram after decapsulation. Correct me.

>>!! ! ! ! ;I! ! ! ! am assuming mobile nodes doesn't support MPLS as MPLS is still "core
networks technology". FA would handle
the packet in similar way as it did when COA is of type foreign agent.

>>Also, let say we want to use MPLS for fast forwarding and QOS and not to
eliminate IP tunnel. In this case, we
probably want to fast switch packet from Ingress(HA) to Egress(FA).

Thanks,
Satish


Satish_Amara@3com.com wrote:

Hi,
I have a question regarding LSP tunnel establishment between Ingress LER
of CN and FA-LER of MN in
section 3.4.2 . RFC.
http://search.ietf.org/internet-drafts/draft-choi-mobileip-ldpext-01.txt
(MPLS-based Mobile IP Route Optimization Scenario.) Also, LSP tunnel between
HA-LER and
FA-LER, is not possible if care of address is of type co-located care-of
address. As both the binding and
registration messages doesn't contain address of FA . One solution to the above
problem
is to mentio! ! ! ! n the FA! a! ! ! ! ddress(LER) in registration message and binding update
when care of address is of
type co-located.

Thanks,
Satish Amara



---------------------------------
Do You Yahoo!?
Yahoo! Auctions - Click and bid on cool stuff like Dave Matthews Band Tickets &
more!


Why do you think that the co-located care-of-addr should be treated differently? If the COA is conveyed to the Ingress LER all that it needs to do is to establish a tunnel [LSP] to that address. The mobile node should be capable of understanding the Label Map Request. If not then I don't know how the FA's address will help, since the tunnel is expected to terminate at the MN but gets terminated at the FA and the FA doesn't know what it should do with the datagram after decapsulation. Correct me.



  Satish_Amara@3com.com wrote:



Hi,
I have a question regarding LSP tunnel establishment between Ingress LER
of CN and FA-LER of MN in
section 3.4.2 . RFC.
http://search.ietf.org/internet-drafts/draft-choi-mobileip-ldpext-01.txt
(MPLS-based Mobile IP Route Optimization Scenario.) Also, LSP tunnel between
HA-LER and
FA-LER, is not possible if care of address is of type co-located care-of
address. As both the binding and
registration messages doesn't contain address of FA . One solution to the above
problem
is to mention the FA address(LER) in registration message and binding update
when care of address is of
type co-located.

Thanks,
Satish Amara







Do You Yahoo!?
Yahoo! Auctions - Click and bid on cool stuff like Dave Matthews Band Tickets & more!



Do You Yahoo!?
Yahoo! Auctions - Click and bid on cool stuff like Dave Matthews Band Tickets & more!

Do You Yahoo!?
Yahoo! Auctions - Click and bid on cool stuff like Dave Matthews Band Tickets & more! --0-1804289383-989276515=:37622-- From owner-mobile-ip@sunroof.eng.sun.com Mon May 7 23:00:19 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA29058 for ; Mon, 7 May 2001 23:00:19 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA06840; Mon, 7 May 2001 20:00:12 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA05734; Mon, 7 May 2001 20:00:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f482wwIM013256 for ; Mon, 7 May 2001 19:58:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f482wvho013255 for mobile-ip-dist; Mon, 7 May 2001 19:58:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.89.31] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f482wnIM013248 for ; Mon, 7 May 2001 19:58:49 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with SMTP id f482wfHD874338 for ; Mon, 7 May 2001 19:58:41 -0700 (PDT) Message-Id: <200105080258.f482wfHD874338@jurassic.eng.sun.com> Date: Mon, 7 May 2001 19:58:49 -0700 (PDT) From: Alper Yegin Subject: RE: [mobile-ip] some comments on the FMIP draft To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: U+qiIYRgeeWvQzs7sqcu1g== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: ... > Also: one other thing that folks are missing in > the current draft is that the arrival of MN on AR > and then sending the F-NA is a security hazard > unless MN can cryptographically prove that it is > the same node on on ARold that is pressing the > "go" button. There would need to be some sort of > identity that is transfered in the HI/HACK and > a new security association at ARnew in order to > prevent this attack. But at that level (bad guy on the link) network is already vulnerable to other kind of attacks. For example even after handoff is over, bad guy can overwrite the neighbor cache on newAR and steal rest of the traffic. Maybe secure ND is the solution. alper > > If you let ARold buffer the packets, you don't run > into this hazard (and time sink) because ARold > could have demanded credentials well in advance to > determine the legitimacy of the BU. > > Mike > > James Kempf writes: > > >> 3) As I've said before, it would be nice to decouple > > >> the need to do the HI/HACK from the rest of this > > >> draft. The mobile node should be able to just > > >> ask the old access router to buffer its packets > > >> while it's in transition. In fact, this has the > > >> positive side effect if the oldAR doesn't know > > >> anything about the newAR, > > >> > > > => I agree with you. But when we discussed the > > > alternative (MN performs DAD in parallel with > > > sending and receiving packets) we found that > > > it may not work in all cases. Also there were > > > some open issues with ND. I would prefer > > > that approach (my technical bias) if it > > > can work. So if you think it can work when > > > considering it in detail, I don't see why not. > > > > > > > > > One of the problems with requiring signalling from the MN after L2 has indicated > > handoff is imminent is that, depending on the particulars of the radio link > > protocol, the signalling has a much higher probability of being dropped or > > corrupted. The reason that handoff typically occurs is because there > > is a drop in the radio signal quality or power below what the radio protocol > > deems sufficient for low error rate communication having the contracted > > quality of service from the mobile node to the current base station. > > We went through this discussion once several months ago on the IPv4 design team. > > I don't know whether it surfaced in the IPv6 discussion at all. > > > > Because this may not necessarily be the case for all radio protocols (for > > example, a nanocell protocol), the IPv4 design team decided to offer > > the choice of either having the L3 handoff signalling > > originate from the mobile node or having the network do the L3 handoff > > signalling. The IPv6 design team chose to combine the two techniques and require > > both in all cases. IMHO, the need for low latency handoff is poorly > > served by this design, because it requires more signalling than if > > the two techniques were separated, but I won't try to second guess > > the IPv6 design team without more carefully reading the draft. > > > > In any case, I don't think it would be wise to eliminate the network assisted > > part of the handoff. This would assure that the protocol would work > > poorly for radio protocols where degraded radio quality of service > > accompanies an L2 handoff decision, because the MN would be forced > > to retransmit if packet loss occured. > > > > jak > > > > > > > > alper From owner-mobile-ip@sunroof.eng.sun.com Mon May 7 23:04:49 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA29102 for ; Mon, 7 May 2001 23:04:48 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA08689; Mon, 7 May 2001 20:04:44 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA06141; Mon, 7 May 2001 20:04:40 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f4833hIM013301 for ; Mon, 7 May 2001 20:03:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f4833gAL013300 for mobile-ip-dist; Mon, 7 May 2001 20:03:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f4833YIM013293 for ; Mon, 7 May 2001 20:03:34 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with SMTP id f4833NHD876068 for ; Mon, 7 May 2001 20:03:24 -0700 (PDT) Message-Id: <200105080303.f4833NHD876068@jurassic.eng.sun.com> Date: Mon, 7 May 2001 20:03:31 -0700 (PDT) From: Alper Yegin Subject: RE: [mobile-ip] some comments on the FMIP draft To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: B4tsCMxXMQrCfYRuyrkiJg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: ... > > > 5) Is the FBU/FBACK really a different kind of BU? > > > It looks the same as a normal BU. That would > > > actually be rather nice if it were the same > > > since we're probably need to consider the > > > security aspects of them, and it would be nice > > > to have exactly one kind of BU to modify if > > > necessary. Same goes for HMIP as well. > > > > > => It would be the same from a security > > poin of view. I don't see why not. Same > > for HMIPv6. The F-BU will include the > > M flag to ensire coexistence with HMIPv6. > > > > The reason for having a different type is > > the HI/HACK messages. We need to know > > if the BU should trigger HI/HACK or not. > > > [MJ] Hesham, this point is not clear. I don't think that as the > draft stands today there is no scenario described where Bu is triggering > HI/HACK? or may be I have missed some subtle issues. I will appreciate your > response. Regular BU changes the routing as soon as it's received. But F-BU cannot change routing by itself. The receiving newAR also needs to wait for a successful HACK. And on top of this, if the L2 supports, newAR might even wait for "MN detached" signal from its L2 to start tunneling packets to newCoA. Therefore F-BU is really different than BU. alper From owner-mobile-ip@sunroof.eng.sun.com Tue May 8 10:49:35 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25595 for ; Tue, 8 May 2001 10:49:34 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA28620; Tue, 8 May 2001 07:49:25 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA18170; Tue, 8 May 2001 07:49:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f48Em2IM013859 for ; Tue, 8 May 2001 07:48:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f48Em2hV013858 for mobile-ip-dist; Tue, 8 May 2001 07:48:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f48ElrIM013851 for ; Tue, 8 May 2001 07:47:54 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA27437 for ; Tue, 8 May 2001 07:47:54 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA21712 for ; Tue, 8 May 2001 07:47:52 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f48Elun24028 for ; Tue, 8 May 2001 07:47:56 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AFH24436; Tue, 8 May 2001 07:47:49 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA00682; Tue, 8 May 2001 07:47:49 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15096.1813.235794.276494@thomasm-u1.cisco.com> Date: Tue, 8 May 2001 07:47:49 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] some comments on the FMIP draft In-Reply-To: <200105080303.f4833NHD876068@jurassic.eng.sun.com> References: <200105080303.f4833NHD876068@jurassic.eng.sun.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Alper Yegin writes: > > [MJ] Hesham, this point is not clear. I don't think that as the > > draft stands today there is no scenario described where Bu is triggering > > HI/HACK? or may be I have missed some subtle issues. I will appreciate your > > response. > > Regular BU changes the routing as soon as it's received. But F-BU cannot change > routing by itself. The receiving newAR also needs to wait for a successful HACK. > And on top of this, if the L2 supports, newAR might even wait for "MN detached" > signal from its L2 to start tunneling packets to newCoA. I thought the scenario was: MN ARold ARnew RS------------> HI----------> <--------HACK <------------RA BU------------> <--------BU_ACK Ie, MN knows everything it needs to know once it gets the RA and ARnew is ready. > Therefore F-BU is really different than BU. Even with the above said, I don't see why this requires that F-BU be a different BU though. Why couldn't there just be a flag in the BU which explicitly controls this behavior? Mike From owner-mobile-ip@sunroof.eng.sun.com Tue May 8 13:21:37 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02340 for ; Tue, 8 May 2001 13:21:37 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA24162; Tue, 8 May 2001 10:20:05 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA04426; Tue, 8 May 2001 10:19:52 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f48HHtIM014227 for ; Tue, 8 May 2001 10:17:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f48HHs3n014226 for mobile-ip-dist; Tue, 8 May 2001 10:17:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f48HHgIM014210 for ; Tue, 8 May 2001 10:17:42 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA27805 for ; Tue, 8 May 2001 10:17:42 -0700 (PDT) Received: from zrc2s03g.us.nortel.com ([47.103.122.66]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02684 for ; Tue, 8 May 2001 10:17:37 -0700 (PDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id MAA06494 for ; Tue, 8 May 2001 12:18:17 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Tue, 8 May 2001 12:12:01 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 May 2001 12:17:26 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E430225B0C8@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: mobile-ip] Multiple flows with single NAI Date: Tue, 8 May 2001 12:17:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D7E2.BF6964F0" X-Orig: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C0D7E2.BF6964F0 Content-Type: text/plain; charset="iso-8859-1" Madhavi, I'm saying that layer 3 in general doesn't solve the more complex user mobility functions and so the NAI used in MIP should probably not be used as a user identifier. For instance, how could an HA (router) discriminate between devices to tunnel the packet to? The NAI does not exist in every IP packet that comes in. The HA also does not know when to multi-cast to a set of devices or try one device at a time. Nor does it know which devices are appropriate for the communication or not. There certainly are not any standardized extensions to MIP for these functions; although, I really wouldn't even try to go there. The solution leads to a sniffing HA. I guess for single device communications you could use it as a user id. But this will only work for a limited set of application functionality in the long term. I would recommend using it as an (network-layer provider) subscription id for authentication. A user id and the more complex applications of user mobility is a layer 5 and above problem set. Glenn -----Original Message----- From: Madhavi Subbarao [mailto:msubbara@cisco.com] Sent: Wednesday, May 02, 2001 3:56 PM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: mobile-ip] Multiple flows with single NAI Hi Glenn, Sorry for the delayed response... On Tue, May 01, 2001 at 11:19:29AM -0500, Glenn Morrow wrote: > Madhavi, > > > Are you thinking of the NAI as a: > > subscription identifier > user identifier > Equipment identifier? As a user identifier. The NAI identifies the user, not the device. > It seems to me that each device might have different home > addresses. Yes, actually that's what we are saying. Each device will have a different home address...authentication is based on NAI (as is currently). The HA authorizes the (NAI, IP address) combination. > The key > can be a bit more complex than just an NAI into a database/directory used > for any purpose. I'm afraid I didn't catch your point. Are you saying that you can't still authenticate based on NAI? Please elaborate... Regards, Madhavi > -----Original Message----- > From: Madhavi Subbarao [mailto:msubbara@cisco.com] > Sent: Monday, April 30, 2001 6:53 PM > To: mobile-ip@sunroof.eng.sun.com > Cc: Madhavi W Subbarao > Subject: [mobile-ip] Multiple flows with single NAI > > > Hi All, > > For viable deployment of MIP, it seems necessary to support single NAI > with multiple static IP flows. For example, if a user opens a MIP > session on his laptop and then wants another MIP session on his phone, > he couldn't do that now with a single NAI . Now when an HA receives > an RRQ with NAI and homeIP#2, but it already has a binding for NAI > and homeIP#1, the binding gets 'overwritten'. Hence, only one MIP > flow can be supported per NAI. Theoretically, we can say to use > multiple NAIs, but practically, it's not possible. Many service providers > do not want to create multiple NAIs and user records for multiple > devices/applications or instances of the mobile user. > > While it seems natural then to allow multiple static IPs for the same NAI > (dynamic IPs also, but that needs another level of identification), > neither RFC2002 nor RFC2974 outline the behavior that should be > followed by the various entities. The specs certainly do not preclude > the above, but clarity in behavior is needed. > > We believe this is a simple, yet important issue for deployment and would > like feedback from the WG. > > We've submitted a draft that addresses the above. > http://search.ietf.org/internet-drafts/draft-subbarao-mobileip-multipleip-00 > .txt > > Thanks, > Madhavi ------_=_NextPart_001_01C0D7E2.BF6964F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Re: mobile-ip] Multiple flows with single = NAI

Madhavi,

I'm saying that layer 3 in general doesn't solve the = more complex user mobility functions and so the NAI used in MIP should = probably not be used as a user identifier.

For instance, how could an HA (router) discriminate = between devices to tunnel the packet to? The NAI does not exist in = every IP packet that comes in.

The HA also does not know when to multi-cast to a set = of devices or try one device at a time. Nor does it know which devices = are appropriate for the communication or not.

There certainly are not any standardized extensions = to MIP for these functions; although, I really wouldn't even try to go = there. The solution leads to a sniffing HA.

I guess for single device communications you could = use it as a user id. But this will only work for a limited set of = application functionality in the long term.

I would recommend using it as an (network-layer = provider) subscription id for authentication.

A user id and the more complex applications of user = mobility is a layer 5 and above problem set.


Glenn

-----Original Message-----
From: Madhavi Subbarao [mailto:msubbara@cisco.com]=
Sent: Wednesday, May 02, 2001 3:56 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Re: mobile-ip] Multiple flows = with single NAI


Hi Glenn,

Sorry for the delayed response...

On Tue, May 01, 2001 at 11:19:29AM -0500, Glenn = Morrow wrote:
> Madhavi,
>
>
> Are you thinking of the NAI as a:
>
> subscription identifier
> user identifier
> Equipment identifier?

As a user identifier.  The NAI identifies the = user, not the device.

> It seems to me that each device might have = different home
> addresses.

Yes, actually that's what we are saying.  Each = device will have a
different home address...authentication is based on = NAI (as is currently).
The HA authorizes the (NAI, IP address) = combination.

> The key
> can be a bit more complex than just an NAI into = a database/directory used
> for any purpose.

I'm afraid I didn't catch your point.  Are you = saying that you can't
still authenticate based on NAI?  Please = elaborate...

Regards,
Madhavi

> -----Original Message-----
> From: Madhavi Subbarao [mailto:msubbara@cisco.com]=
> Sent: Monday, April 30, 2001 6:53 PM
> To: mobile-ip@sunroof.eng.sun.com
> Cc: Madhavi W Subbarao
> Subject: [mobile-ip] Multiple flows with single = NAI
>
>
> Hi All,
>
> For viable deployment of MIP, it seems = necessary to support single NAI
> with multiple static IP flows.  For = example, if a user opens a MIP
> session on his laptop and then wants another = MIP session on his phone,
> he couldn't do that now with a single NAI = .  Now when an HA receives
> an RRQ with NAI and homeIP#2, but it already = has a binding for NAI
> and homeIP#1, the binding gets = 'overwritten'.  Hence, only one MIP
> flow can be supported per NAI.  = Theoretically, we can say to use
> multiple NAIs, but practically, it's not = possible.  Many service providers
> do not want to create multiple NAIs and user = records for multiple
> devices/applications or instances of the mobile = user.
>
> While it seems natural then to allow multiple = static IPs for the same NAI
> (dynamic IPs also, but that needs another level = of identification),
> neither RFC2002 nor RFC2974 outline the = behavior that should be
> followed by the various entities.  The = specs certainly do not preclude
> the above, but clarity in behavior is = needed.
>
> We believe this is a simple, yet important = issue for deployment and would
> like feedback from the WG.
>
> We've submitted a draft that addresses the = above.
> http://search.ietf.org/internet-drafts/draft-subbarao-= mobileip-multipleip-00
> .txt
>
> Thanks,
> Madhavi

------_=_NextPart_001_01C0D7E2.BF6964F0-- From owner-mobile-ip@sunroof.eng.sun.com Tue May 8 16:06:49 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06432 for ; Tue, 8 May 2001 16:06:48 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA22181; Tue, 8 May 2001 13:06:43 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA27292; Tue, 8 May 2001 13:06:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f48K3vIM014487 for ; Tue, 8 May 2001 13:03:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f48K3uP8014486 for mobile-ip-dist; Tue, 8 May 2001 13:03:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f48K3lIM014479 for ; Tue, 8 May 2001 13:03:47 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA13249 for ; Tue, 8 May 2001 13:03:46 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA25731 for ; Tue, 8 May 2001 14:03:47 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f48K3kQ22120 for ; Tue, 8 May 2001 13:03:47 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AFI01230; Tue, 8 May 2001 13:03:39 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA00736; Tue, 8 May 2001 13:03:39 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15096.20763.40327.479967@thomasm-u1.cisco.com> Date: Tue, 8 May 2001 13:03:39 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] a few more FMIP comments X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit 1) ESP friendliness: currently there is text in the draft which speaks of AH headers, but nothing about ESP headers. We should make the language neutral as well as fix any dependencies on AH itself (beyond the BU's which is a seperable issue). This may require source addresses to be carried in the router solicit/advertizements itself, rather than expecting them to come from outer IP header. Frankly, this is just good modular design. 2) I have a question as to whether anybody considered combining the Proxy Router Solicit functionality with the binding update for the mobile initiated handoff. Considering the mobile is probably moving out of range, this seems like it's a pretty critical time and the fewer messages required, the better. As a strawman couldn't we do something like: MN oldAR newAR BU+XOFF+RS-------> [HI---------------->] [<--------------HACK] <---------BUACK+RA Where XOFF is the buffer bit (to stop packets from flowing) and RS and RA are the pertinent parts of the Fast MIP solicit/advert payloads? Mike From owner-mobile-ip@sunroof.eng.sun.com Wed May 9 00:48:30 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA15805 for ; Wed, 9 May 2001 00:48:29 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA24153; Tue, 8 May 2001 21:48:20 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA27765; Tue, 8 May 2001 21:48:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f494kSC15277 for mobile-ip-dist; Tue, 8 May 2001 21:46:28 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31] (may be forged)) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f494kK415270 for ; Tue, 8 May 2001 21:46:20 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with SMTP id f494kJu107839 for ; Tue, 8 May 2001 21:46:19 -0700 (PDT) Message-Id: <200105090446.f494kJu107839@jurassic.eng.sun.com> Date: Tue, 8 May 2001 21:46:19 -0700 (PDT) From: Alper Yegin Subject: RE: [mobile-ip] some comments on the FMIP draft To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: zgYATTYgyhS6EabdpeiWQg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Alper Yegin writes: > > > [MJ] Hesham, this point is not clear. I don't think that as the > > > draft stands today there is no scenario described where Bu is triggering > > > HI/HACK? or may be I have missed some subtle issues. I will appreciate your > > > response. > > > > Regular BU changes the routing as soon as it's received. But F-BU cannot change > > routing by itself. The receiving newAR also needs to wait for a successful HACK. > > And on top of this, if the L2 supports, newAR might even wait for "MN detached" > > signal from its L2 to start tunneling packets to newCoA. > > I thought the scenario was: > > MN ARold ARnew > > RS------------> > HI----------> > <--------HACK > <------------RA > BU------------> > <--------BU_ACK > > Ie, MN knows everything it needs to know once > it gets the RA and ARnew is ready. Check out the figure in 3.1.1. HACK may arrive after BU arrives at newAR. > > > Therefore F-BU is really different than BU. > > Even with the above said, I don't see why this > requires that F-BU be a different BU > though. Why couldn't there just be a flag in > the BU which explicitly controls this behavior? I remember discussing this, but can't remember why we chose a new type. Maybe other members of the design team can comment on this. > > Mike alper From owner-mobile-ip@sunroof.eng.sun.com Wed May 9 03:32:02 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01344 for ; Wed, 9 May 2001 03:32:01 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA09082; Wed, 9 May 2001 00:31:53 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA21543; Wed, 9 May 2001 00:31:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f497Swa15403 for mobile-ip-dist; Wed, 9 May 2001 00:28:58 -0700 (PDT) Received: from bebop.france (bebop.France.Sun.COM [129.157.174.15] (may be forged)) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f497Sm415396 for ; Wed, 9 May 2001 00:28:49 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.france (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id JAA06479; Wed, 9 May 2001 09:28:44 +0200 (MET DST) Date: Wed, 9 May 2001 09:20:09 +0200 (CEST) From: Erik Nordmark Subject: Re: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L ocalized Mobility Management Requirement s) To: =?iso-8859-1?Q?Tom_Weckstr=F6m?= Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com, Basavaraj.Patil@nokia.com In-Reply-To: "Your message with ID" <3AEAE70B.2AA1F23F@cc.hut.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Tom, > Consider you have one level hierarhy with one "element" (I call those > FAs, but they may be called something else in some of the recent drafts > I have not read) in the highest level and N FAs on the lowest level. > Now, let us assume that considering only signaling, this system can > handle k MNs simultaneously. Those MNs are handling, e.g. VoIP calls and > are moving fast, e.g. on a highway. So, with all the VoIP call data and > localized mobility management signaling of the k MobileNodes, the > highest FA is fully employed. Good example since it raises an interesting question. The highest FA could be fully utilized for multiple reasons: 1. running out of processing power to handle the rate of binding updates 2. running out of memory to store the state for the bindings 3. running out of bandwidth on its network interfaces for all the traffic to (and from?) the MNs If you add a hierarchy of LMMs below this box and have the box continue to serve the same number of MNs you can improve #1 but it doesn't change #2 or #3. If you instead of a hierarchy add N equal LMM agents at the top level (e.g., with each MN in the domain randomly selecting which LMM agent to use) then you can address scaling along all of the above axis. So it all depends along what axis you think the agent will max out first. Erik From owner-mobile-ip@sunroof.eng.sun.com Wed May 9 04:34:50 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA01910 for ; Wed, 9 May 2001 04:34:49 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA15391; Wed, 9 May 2001 01:34:41 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA26768; Wed, 9 May 2001 01:34:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f498Wdc15597 for mobile-ip-dist; Wed, 9 May 2001 01:32:39 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f498WT415590 for ; Wed, 9 May 2001 01:32:30 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA15994 for ; Wed, 9 May 2001 01:32:29 -0700 (PDT) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA09237 for ; Wed, 9 May 2001 01:32:28 -0700 (PDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2650.21) id <2MX5GF5W>; Wed, 9 May 2001 04:32:27 -0400 Message-ID: From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] fast handover Date: Wed, 9 May 2001 04:32:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I had been droped off the list for some reason and had to re-register... I will try to catch up on a few e-mails that I managed to get from other people.. Sharif, The temporary tunnel should indeed have short lifetime...It is up to oldAR to set and should be in the order of at least a couple of RTT between the MN and its Home Agent...of course you can let it leave for a bit longer to be on the safe side...no harm will be done other than state at the oldAR.... George -----Original Message----- From: Shahrier, Sharif M. [mailto:Sharif.Shahrier@InterDigital.com] Sent: Monday, May 07, 2001 2:58 PM To: 'mobile-ip@sunroof.eng.sun.com' Subject: [mobile-ip] fast handover Just wanted to clarify that F-BU sent to the oldAR is to set up a "temporary" tunnel for forwarding packets to newAR, i.e. lasting until after handover is complete? Thus, the lifetime of this tunnel should be short is duration. Is there any guidelines at this point on how this parameter is to be set? -Sharif From owner-mobile-ip@sunroof.eng.sun.com Wed May 9 04:56:32 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02178 for ; Wed, 9 May 2001 04:56:31 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA21211; Wed, 9 May 2001 01:56:21 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA26829; Wed, 9 May 2001 01:56:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f498stD15647 for mobile-ip-dist; Wed, 9 May 2001 01:54:55 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f498sk415640 for ; Wed, 9 May 2001 01:54:47 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA28171 for ; Wed, 9 May 2001 01:54:46 -0700 (PDT) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA20403 for ; Wed, 9 May 2001 01:54:44 -0700 (PDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2650.21) id <2MX5GF59>; Wed, 9 May 2001 04:54:44 -0400 Message-ID: From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] some comments on the FMIP draft Date: Wed, 9 May 2001 04:54:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Mike, -As I said I have lost a number of e-mails so apologies if this is already out of context- The scenario you describe is only one of the possible ones...Here is another one... MN ARold ARnew RS------------> <------------RA HI----------> BU------------> <--------HACK <--------BU_ACK The oldAR can send the RA to the MN before it receives the HACK (which saves a bit of time...). The MN will send the F-BU immediately and the possibly move...The oldAR in this case SHOULD NOT change routing before it receives the HACK (which will validate the forwarding address for the MN...) We also discussed at length the issue of how to identify the F-BU (I had to check the archive for this...)...We actually examined weather a normal BU can be identified as F-BU from what state the oldAR has on the source...(has it sent a PrRtAdv to it or not...etc) but we realized that that was not enough and we decided to go for a flag. Then there was some concern about using up valuable BU Flags (there are only a few left) when we have a big code space available to us and that I think was the reason of a new type...F-BU... George -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Tuesday, May 08, 2001 10:48 AM To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] some comments on the FMIP draft Alper Yegin writes: > > [MJ] Hesham, this point is not clear. I don't think that as the > > draft stands today there is no scenario described where Bu is triggering > > HI/HACK? or may be I have missed some subtle issues. I will appreciate your > > response. > > Regular BU changes the routing as soon as it's received. But F-BU cannot change > routing by itself. The receiving newAR also needs to wait for a successful HACK. > And on top of this, if the L2 supports, newAR might even wait for "MN detached" > signal from its L2 to start tunneling packets to newCoA. I thought the scenario was: MN ARold ARnew RS------------> HI----------> <--------HACK <------------RA BU------------> <--------BU_ACK Ie, MN knows everything it needs to know once it gets the RA and ARnew is ready. > Therefore F-BU is really different than BU. Even with the above said, I don't see why this requires that F-BU be a different BU though. Why couldn't there just be a flag in the BU which explicitly controls this behavior? Mike From owner-mobile-ip@sunroof.eng.sun.com Wed May 9 05:26:05 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA02552 for ; Wed, 9 May 2001 05:26:05 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA06552; Wed, 9 May 2001 02:25:53 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA14353; Wed, 9 May 2001 02:25:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f499OVa15690 for mobile-ip-dist; Wed, 9 May 2001 02:24:31 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f499OM415683 for ; Wed, 9 May 2001 02:24:23 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA14272 for ; Wed, 9 May 2001 02:24:22 -0700 (PDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA05797 for ; Wed, 9 May 2001 02:24:20 -0700 (PDT) Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by ebene.inrialpes.fr (8.9.3+Sun/8.8.6) with ESMTP id LAA16626 for ; Wed, 9 May 2001 11:23:20 +0200 (MEST) Message-ID: <3AF90C9C.D276F9D1@inrialpes.fr> Date: Wed, 09 May 2001 11:23:40 +0200 From: Claude Castelluccia X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Authenticating BU and PKI References: Content-Type: multipart/alternative; boundary="------------E0A022AE52C0F0F03C546AAB" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------E0A022AE52C0F0F03C546AAB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Henrik, As explained in http://www.inrialpes.fr/planete/people/ccastel/draft-montenegro-sucv-00.txt, it might also be useful to prove the ownership of the CoA... regards, Claude. Lars Henrik Petander wrote: > On Fri, 4 May 2001, Damien Routier wrote: > > > I think that using a PKI is a problem since a new certificate must be > > published each time a MN gets a new CoA and the CA/RA must check that > > the CoA is rightfully claimed before publishing the certificate > > > > am i completly wrong ? > > Partly, as you would normally want to prove the ownership of the home > addresss and the certificate would bind the home address or FQDN > to a public key. You would need a new certificate only in the case of > renumbering or changing your domain name. Of course in the case of a > previous router acting as a temporary HA for the old CoA, you would still > need to prove the ownership of your previous CoA. > > Regards, > > Henrik Petander > > > > > Damien Routier > > Motorola Research Center - Paris > > -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------E0A022AE52C0F0F03C546AAB Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
Hello Henrik,

As explained in  http://www.inrialpes.fr/planete/people/ccastel/draft-montenegro-sucv-00.txt,
it might also be useful to prove the ownership of the CoA...

regards,
Claude.

Lars Henrik Petander wrote:

On Fri, 4 May 2001, Damien Routier wrote:

> I think that using a PKI is a problem since a new certificate must be
> published each time a MN gets a new CoA and the CA/RA must check that
> the CoA is rightfully claimed before publishing the certificate
>
> am i completly wrong ?

Partly, as you would normally want to prove the ownership of the home
addresss and the certificate would bind the home address or FQDN
to a public key. You would need a new certificate only in the case of
renumbering or changing your domain name. Of course in the case of a
previous router acting as a temporary HA for the old CoA, you would still
need to prove the ownership of your previous CoA.

Regards,

Henrik Petander

>
> Damien Routier
> Motorola Research Center - Paris
>

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  --------------E0A022AE52C0F0F03C546AAB-- From owner-mobile-ip@sunroof.eng.sun.com Wed May 9 10:23:48 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08202 for ; Wed, 9 May 2001 10:23:47 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA14285; Wed, 9 May 2001 07:22:51 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA26169; Wed, 9 May 2001 07:22:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f49EKtN16307 for mobile-ip-dist; Wed, 9 May 2001 07:20:55 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f49EKi416300 for ; Wed, 9 May 2001 07:20:45 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA23625 for ; Wed, 9 May 2001 07:20:45 -0700 (PDT) Received: from idcpa4.pa.interdigital.com ([12.32.197.142]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA09572 for ; Wed, 9 May 2001 07:20:43 -0700 (PDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 May 2001 10:19:46 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Mobile-IP and MPLS Integration Date: Wed, 9 May 2001 10:19:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D893.1897FD60" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C0D893.1897FD60 Content-Type: text/plain; charset="iso-8859-1" Is there a current internet draft on this. Could someone please send me the reference. -Sharif -----Original Message----- From: Ash h [mailto:aschwinn@yahoo.com] Sent: Monday, May 07, 2001 5:26 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile-IP and MPLS Integration I guess we are concurring with the fact that the COA must be that of the FA and never that of the MN since MN may not participate in MPLS. Hence the FA should not allow colocated COA if it is in its capacity and instead use the FA COA to terminate the LSP. Thus the need to carry the FA address in a different field may not be necessary[ COA = FA's addr]. I don't think this will hamper any semantics assigned to the LSP (viz QOS, VPN etc). Satish_Amara@3com.com wrote: Hi, Please see for my comments. Ash h on 05/07/2001 02:34:24 PM Please respond to mobile-ip@sunroof.eng.sun.com Sent by: Ash h To: mobile-ip@sunroof.eng.sun.com cc: (Satish Amara/MW/US/3Com) Subject: Re: [mobile-ip] Mobile-IP and MPLS Integration Why do you think that the co-located care-of-addr should be treated differently? If the COA is conveyed to the Ingress LER all that it needs to do is to establish a tunnel [LSP] to that address. The mobile node should be capable of understanding the Label Map Request. If not then I don't know how the FA's address will help, since the tunnel is expected to terminate at the MN but gets terminated at the FA and the FA doesn't know what it should do with the datagram after decapsulation. Correct me. >>I! ! ! ! am assuming mobile nodes doesn't support MPLS as MPLS is still "core networks technology". FA would handle the packet in similar way as it did when COA is of type foreign agent. >>Also, let say we want to use MPLS for fast forwarding and QOS and not to eliminate IP tunnel. In this case, we probably want to fast switch packet from Ingress(HA) to Egress(FA). Thanks, Satish Satish_Amara@3com.com wrote: Hi, I have a question regarding LSP tunnel establishment between Ingress LER of CN and FA-LER of MN in section 3.4.2 . RFC. http://search.ietf.org/internet-drafts/draft-choi-mobileip-ldpext-01.txt (MPLS-based Mobile IP Route Optimization Scenario.) Also, LSP tunnel between HA-LER and FA-LER, is not possible if care of address is of type co-located care-of address. As both the binding and registration messages doesn't contain address of FA . One solution to the above problem is to mention the FA a! ! ! ! ddress(LER) in registration message and binding update when care of address is of type co-located. Thanks, Satish Amara --------------------------------- Do You Yahoo!? Yahoo! Auctions - Click and bid on cool stuff like Dave Matthews Band Tickets & more! Why do you think that the co-located care-of-addr should be treated differently? If the COA is conveyed to the Ingress LER all that it needs to do is to establish a tunnel [LSP] to that address. The mobile node should be capable of understanding the Label Map Request. If not then I don't know how the FA's address will help, since the tunnel is expected to terminate at the MN but gets terminated at the FA and the FA doesn't know what it should do with the datagram after decapsulation. Correct me. Satish_Amara@3com.com wrote: Hi, I have a question regarding LSP tunnel establishment between Ingress LER of CN and FA-LER of MN in section 3.4.2 . RFC. http://search.ietf.org/internet-drafts/draft-choi-mobileip-ldpext-01.txt (MPLS-based Mobile IP Route Optimization Scenario.) Also, LSP tunnel between HA-LER and FA-LER, is not possible if care of address is of type co-located care-of address. As both the binding and registration messages doesn't contain address of FA . One solution to the above problem is to mention the FA address(LER) in registration message and binding update when care of address is of type co-located. Thanks, Satish Amara _____ Do You Yahoo!? Yahoo! Auctions - Click and bid on cool stuff like Dave Matthews Band Tickets & more! _____ Do You Yahoo!? Yahoo! Auctions - Click and bid on cool stuff like Dave Matthews Band Tickets & more! ------_=_NextPart_001_01C0D893.1897FD60 Content-Type: text/html; charset="iso-8859-1"
Is there a current internet draft on this. Could someone please send me the reference.
 
-Sharif
-----Original Message-----
From: Ash h [mailto:aschwinn@yahoo.com]
Sent: Monday, May 07, 2001 5:26 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Mobile-IP and MPLS Integration

   I guess we are concurring with the fact that the COA must be that of the FA and never that of the MN since MN may not participate in MPLS. Hence the FA should not allow colocated COA if it is in its capacity and instead use the FA COA to terminate the LSP. Thus the need to carry the FA address in a different field may not be necessary[ COA = FA's addr]. I don't think this will hamper any semantics assigned to the LSP (viz QOS, VPN etc).

  Satish_Amara@3com.com wrote:



Hi,
Please see for my comments.




Ash h on 05/07/2001 02:34:24 PM

Please respond to mobile-ip@sunroof.eng.sun.com

Sent by: Ash h


To: mobile-ip@sunroof.eng.sun.com
cc: (Satish Amara/MW/US/3Com)
Subject: Re: [mobile-ip] Mobile-IP and MPLS Integration




Why do you think that the co-located care-of-addr should be treated
differently? If the COA is conveyed to the Ingress LER all that it needs to do
is to establish a tunnel [LSP] to that address. The mobile node should be
capable of understanding the Label Map Request. If not then I don't know how the
FA's address will help, since the tunnel is expected to terminate at the MN but
gets terminated at the FA and the FA doesn't know what it should do with the
datagram after decapsulation. Correct me.

>>I! ! ! ! am assuming mobile nodes doesn't support MPLS as MPLS is still "core
networks technology". FA would handle
the packet in similar way as it did when COA is of type foreign agent.

>>Also, let say we want to use MPLS for fast forwarding and QOS and not to
eliminate IP tunnel. In this case, we
probably want to fast switch packet from Ingress(HA) to Egress(FA).

Thanks,
Satish


Satish_Amara@3com.com wrote:

Hi,
I have a question regarding LSP tunnel establishment between Ingress LER
of CN and FA-LER of MN in
section 3.4.2 . RFC.
http://search.ietf.org/internet-drafts/draft-choi-mobileip-ldpext-01.txt
(MPLS-based Mobile IP Route Optimization Scenario.) Also, LSP tunnel between
HA-LER and
FA-LER, is not possible if care of address is of type co-located care-of
address. As both the binding and
registration messages doesn't contain address of FA . One solution to the above
problem
is to mention the FA a! ! ! ! ddress(LER) in registration message and binding update
when care of address is of
type co-located.

Thanks,
Satish Amara



---------------------------------
Do You Yahoo!?
Yahoo! Auctions - Click and bid on cool stuff like Dave Matthews Band Tickets &
more!

Why do you think that the co-located care-of-addr should be treated differently? If the COA is conveyed to the Ingress LER all that it needs to do is to establish a tunnel [LSP] to that address. The mobile node should be capable of understanding the Label Map Request. If not then I don't know how the FA's address will help, since the tunnel is expected to terminate at the MN but gets terminated at the FA and the FA doesn't know what it should do with the datagram after decapsulation. Correct me.


  Satish_Amara@3com.com wrote:


Hi,
I have a question regarding LSP tunnel establishment between Ingress LER
of CN and FA-LER of MN in
section 3.4.2 . RFC.
http://search.ietf.org/internet-drafts/draft-choi-mobileip-ldpext-01.txt
(MPLS-based Mobile IP Route Optimization Scenario.) Also, LSP tunnel between
HA-LER and
FA-LER, is not possible if care of address is of type co-located care-of
address. As both the binding and
registration messages doesn't contain address of FA . One solution to the above
problem
is to mention the FA address(LER) in registration message and binding update
when care of address is of
type co-located.

Thanks,
Satish Amara




Do You Yahoo!?
Yahoo! Auctions - Click and bid on cool stuff like Dave Matthews Band Tickets & more!

Do You Yahoo!?
Yahoo! Auctions - Click and bid on cool stuff like Dave Matthews Band Tickets & more!
------_=_NextPart_001_01C0D893.1897FD60-- From owner-mobile-ip@sunroof.eng.sun.com Wed May 9 11:04:48 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10491 for ; Wed, 9 May 2001 11:04:47 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA28560; Wed, 9 May 2001 08:04:31 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA23593; Wed, 9 May 2001 08:04:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f49F2tJ16385 for mobile-ip-dist; Wed, 9 May 2001 08:02:55 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f49F2k416378 for ; Wed, 9 May 2001 08:02:47 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA23156 for ; Wed, 9 May 2001 08:02:42 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id IAA01436 for ; Wed, 9 May 2001 08:02:42 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA22004; Wed, 9 May 2001 11:02:41 -0400 Date: Wed, 9 May 2001 11:02:41 -0400 (EDT) From: Jim Bound To: mobile-ip@sunroof.eng.sun.com Subject: Re: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L ocalized Mobility Management Requirement s) In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Erik,, > Good example since it raises an interesting question. > The highest FA could be fully utilized for multiple reasons: > 1. running out of processing power to handle the rate of binding updates > 2. running out of memory to store the state for the bindings > 3. running out of bandwidth on its network interfaces for all > the traffic to (and from?) the MNs > If you add a hierarchy of LMMs below this box and have the box continue to > serve the same number of MNs you can improve #1 but it doesn't change > #2 or #3. #2 and #3 in a hierarchial model is a funciton of implementation and we know how to fix that out here in vendor land. I can build co-located router-switch-gateway/server to solve number 2 with bookoo RAM, 200 port at a cheap port density, and terabytes of aggregated thru-put. Problem #1 should be the focus of how we design LMM not 2 and 3 IMO. > If you instead of a hierarchy add N equal LMM agents at the top level > (e.g., with each MN in the domain randomly selecting which LMM agent to use) > then you can address scaling along all of the above axis. But there are 3 axises in my view only one being call flows for when I need access to the top LMM axis and I would argue that it can be designed without having to go to that axis for most cases. Likewise the network for which MNs will need to operate are 4 dimensional because of the signaling plane and reducing that plane for traffic and distributed it b definition assists scalability. Which is the critical problem to solve for Mobile IP replacing the existing bearer services for wireless. > So it all depends along what axis you think the agent will max out first. Without hiearchy it will always be the top tier and I think we can do better than that. /jim From owner-mobile-ip@sunroof.eng.sun.com Wed May 9 16:33:34 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23970 for ; Wed, 9 May 2001 16:33:33 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA12617; Wed, 9 May 2001 13:33:10 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA17570; Wed, 9 May 2001 13:32:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f49KUqj16974 for mobile-ip-dist; Wed, 9 May 2001 13:30:52 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f49KUg416967 for ; Wed, 9 May 2001 13:30:43 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA00322; Wed, 9 May 2001 13:30:41 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA17229; Wed, 9 May 2001 13:30:40 -0700 (PDT) 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 NAA23450; Wed, 9 May 2001 13:30:18 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f49KUHN22226; Wed, 9 May 2001 13:30:17 -0700 X-mProtect: Wed, 9 May 2001 13:30:17 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdlf6385; Wed, 09 May 2001 13:30:00 PDT Message-ID: <3AF9A8CB.8F7B92A5@iprg.nokia.com> Date: Wed, 09 May 2001 13:30:03 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: mobile-ip@sunroof.eng.sun.com, "Tom =?iso-8859-1?Q?Weckstr=F6m?=" Subject: Re: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L ocalized Mobility Management Requirement s) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Erik, > The highest FA could be fully utilized for multiple reasons: > 1. running out of processing power to handle the rate of binding updates > 2. running out of memory to store the state for the bindings > 3. running out of bandwidth on its network interfaces for all > the traffic to (and from?) the MNs > > If you add a hierarchy of LMMs below this box and have the box continue to > serve the same number of MNs you can improve #1 but it doesn't change > #2 or #3. > If you instead of a hierarchy add N equal LMM agents at the top level > (e.g., with each MN in the domain randomly selecting which LMM agent to use) > then you can address scaling along all of the above axis. > > So it all depends along what axis you think the agent will max out first. I think the main reasons for intermediate levels are: - Shorter signaling paths -- fewer chances for congestion and delays, fewer nodes to process the control messages, and (O.K. maybe not huge) better average performance -- but probably more consistent performance - Natural fit to hierarchical network architectures ---- Backbone/Core Network/IP RAN at least, and possibly in some situations one (or rarely two) more levels of hierarchy. Besides that, since the multi-level hierarchy doesn't have to be so much more complicated anyway, I don't understand why you are arguing against it. It seems like an obvious improvement. I read most of the arguments supporting the single-level structure to be "Well, we don't really need that improvement" or "Well, we can program around that". But why should we have to botch the obvious network architecture in order to support something only marginally easier (if at all!) to implement, and get lower performance as a reward? Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Wed May 9 16:52:59 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24618 for ; Wed, 9 May 2001 16:52:59 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA04976; Wed, 9 May 2001 13:52:45 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA12254; Wed, 9 May 2001 13:51:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f49Kmut17101 for mobile-ip-dist; Wed, 9 May 2001 13:48:56 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f49Kmd417094 for ; Wed, 9 May 2001 13:48:39 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA20538 for ; Wed, 9 May 2001 13:48:38 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA26763 for ; Wed, 9 May 2001 13:48:37 -0700 (PDT) Received: from msubbara-u10.cisco.com (msubbara-u10.cisco.com [64.102.66.20]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f49Kmb915865 for ; Wed, 9 May 2001 13:48:37 -0700 (PDT) Received: (msubbara@localhost) by msubbara-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA24064 for mobile-ip@sunroof.eng.sun.com; Wed, 9 May 2001 16:47:59 -0400 (EDT) Date: Wed, 9 May 2001 16:47:59 -0400 From: Madhavi Subbarao To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: mobile-ip] Re: mobile-ip] Multiple flows with single NAI Message-ID: <20010509164759.B24054@cisco.com> References: <85AA7486A2C1D411BCA20000F8073E430225B0C8@crchy271.us.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <85AA7486A2C1D411BCA20000F8073E430225B0C8@crchy271.us.nortel.com>; from gmorrow@nortelnetworks.com on Tue, May 08, 2001 at 12:17:24PM -0500 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Glenn, On Tue, May 08, 2001 at 12:17:24PM -0500, Glenn Morrow wrote: > Madhavi, > > I'm saying that layer 3 in general doesn't solve the more complex user > mobility functions and so the NAI used in MIP should probably not be used as > a user identifier. > > For instance, how could an HA (router) discriminate between devices to > tunnel the packet to? The NAI does not exist in every IP packet that comes > in. True...every IP packet does not have an NAI. However, the HA can distinguish between different MN bindings using the tuple (NAI, IP address). The draft we propose outlines the behavior for NAI and multiple STATIC IP addresses...(NAI, IP address) is used as the 'identifier' at the HA. There is no need for the HA to multicast or sniff. We are thinking of the NAI as an identifier for the USER behind the device...if that makes sense. It's analogous to what you describe below as a 'subscription id', so I think we are on the same page. Since NAI identifies and authenticates the USER, it shouldn't matter which device the USER is coming in on. Moreover, the USER shouldn't be constrained to use only a single device. -Madhavi > > The HA also does not know when to multi-cast to a set of devices or try one > device at a time. Nor does it know which devices are appropriate for the > communication or not. > > There certainly are not any standardized extensions to MIP for these > functions; although, I really wouldn't even try to go there. The solution > leads to a sniffing HA. > > I guess for single device communications you could use it as a user id. But > this will only work for a limited set of application functionality in the > long term. > > I would recommend using it as an (network-layer provider) subscription id > for authentication. > > A user id and the more complex applications of user mobility is a layer 5 > and above problem set. > > > Glenn > > -----Original Message----- > From: Madhavi Subbarao [mailto:msubbara@cisco.com] > Sent: Wednesday, May 02, 2001 3:56 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] Re: mobile-ip] Multiple flows with single NAI > > > Hi Glenn, > > Sorry for the delayed response... > > On Tue, May 01, 2001 at 11:19:29AM -0500, Glenn Morrow wrote: > > Madhavi, > > > > > > Are you thinking of the NAI as a: > > > > subscription identifier > > user identifier > > Equipment identifier? > > As a user identifier. The NAI identifies the user, not the device. > > > It seems to me that each device might have different home > > addresses. > > Yes, actually that's what we are saying. Each device will have a > different home address...authentication is based on NAI (as is currently). > The HA authorizes the (NAI, IP address) combination. > > > The key > > can be a bit more complex than just an NAI into a database/directory used > > for any purpose. > > I'm afraid I didn't catch your point. Are you saying that you can't > still authenticate based on NAI? Please elaborate... > > Regards, > Madhavi > > > -----Original Message----- > > From: Madhavi Subbarao [mailto:msubbara@cisco.com] > > Sent: Monday, April 30, 2001 6:53 PM > > To: mobile-ip@sunroof.eng.sun.com > > Cc: Madhavi W Subbarao > > Subject: [mobile-ip] Multiple flows with single NAI > > > > > > Hi All, > > > > For viable deployment of MIP, it seems necessary to support single NAI > > with multiple static IP flows. For example, if a user opens a MIP > > session on his laptop and then wants another MIP session on his phone, > > he couldn't do that now with a single NAI . Now when an HA receives > > an RRQ with NAI and homeIP#2, but it already has a binding for NAI > > and homeIP#1, the binding gets 'overwritten'. Hence, only one MIP > > flow can be supported per NAI. Theoretically, we can say to use > > multiple NAIs, but practically, it's not possible. Many service providers > > do not want to create multiple NAIs and user records for multiple > > devices/applications or instances of the mobile user. > > > > While it seems natural then to allow multiple static IPs for the same NAI > > (dynamic IPs also, but that needs another level of identification), > > neither RFC2002 nor RFC2974 outline the behavior that should be > > followed by the various entities. The specs certainly do not preclude > > the above, but clarity in behavior is needed. > > > > We believe this is a simple, yet important issue for deployment and would > > like feedback from the WG. > > > > We've submitted a draft that addresses the above. > > > http://search.ietf.org/internet-drafts/draft-subbarao-mobileip-multipleip-00 > > .txt > > > > Thanks, > > Madhavi From owner-mobile-ip@sunroof.eng.sun.com Wed May 9 18:15:29 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27147 for ; Wed, 9 May 2001 18:15:29 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA00710; Wed, 9 May 2001 15:15:14 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA11661; Wed, 9 May 2001 15:15:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f49MDLT17381 for mobile-ip-dist; Wed, 9 May 2001 15:13:21 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f49MDB417370 for ; Wed, 9 May 2001 15:13:11 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA11070 for ; Wed, 9 May 2001 15:13:07 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA29088 for ; Wed, 9 May 2001 15:13:05 -0700 (PDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f49MD4N29869 for ; Thu, 10 May 2001 00:13:05 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Thu May 10 00:13:03 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 10 May 2001 00:13:02 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBE1A@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" , Erik Nordmark Cc: =?ISO-8859-1?Q?Tom_Weckstr=F6m?= Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L ocalized Mobility Management Requirement s) Date: Thu, 10 May 2001 00:13:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Charlie, Just a couple of minor comments / questoins below. > > The highest FA could be fully utilized for multiple reasons: > > 1. running out of processing power to handle the rate of binding updates > > 2. running out of memory to store the state for the bindings > > 3. running out of bandwidth on its network interfaces for all > > the traffic to (and from?) the MNs > > > > If you add a hierarchy of LMMs below this box and have the box continue to > > serve the same number of MNs you can improve #1 but it doesn't change > > #2 or #3. > > If you instead of a hierarchy add N equal LMM agents at the top level > > (e.g., with each MN in the domain randomly selecting which LMM agent to use) > > then you can address scaling along all of the above axis. > > > > So it all depends along what axis you think the agent will max out first. > > I think the main reasons for intermediate levels are: > > - Shorter signaling paths -- fewer chances for congestion and delays, > fewer nodes to process the control messages, and (O.K. maybe not huge) > better average performance -- but probably more consistent performance > => The argument thus far has been whether there is any significant improvement (in delays) that could outweigh the introduced complexity within the network. So far I haven't seen an argument to prove that there is such _significant_benefit. > - Natural fit to hierarchical network architectures > => There is hierarchy of a routers within the Internet today, but do they all need to be mobile aware ? That is not a trivial conclusion. The routing within a hierarchy of routers is handled by standard routing protocols. I don't think MIP is needed for this task. > ---- Backbone/Core Network/IP RAN at least, > => I don't know if there are any RAN standards that require this. However, if in future open RANs are standardised then the argument is the same whether a network is a RAN or not. > But why should we have to botch the > obvious network architecture in order to support something only marginally > easier (if at all!) to implement > => To avoid multiple single point of failiures and keeping unnecessary state within the network. The solution is not so trivial IMO. There are several downfalls to consider. Robustness is only one, Security is another, network availability is another one. All that amounts to cost. Regards, Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed May 9 18:27:07 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27664 for ; Wed, 9 May 2001 18:27:06 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA18639; Wed, 9 May 2001 15:26:59 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA27376; Wed, 9 May 2001 15:26:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f49MP6I17417 for mobile-ip-dist; Wed, 9 May 2001 15:25:06 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f49MOv417410 for ; Wed, 9 May 2001 15:24:58 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id PAA11436; Wed, 9 May 2001 15:24:57 -0700 (PDT) Message-Id: <200105092224.PAA11436@heliopolis.eng.sun.com> Date: Wed, 9 May 2001 15:24:58 -0700 (PDT) From: James Kempf Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L ocalized Mobility Management Requirement s) To: mobile-ip@sunroof.eng.sun.com, Erik.Nordmark@eng.sun.com Cc: tweckstr@cc.hut.fi MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: /OBJYxqK8bIzbV2ejXdGAw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Hesham, > => To avoid multiple single point of failiures and keeping unnecessary > state within the network. The solution is not so trivial IMO. > There are several downfalls to consider. Robustness is only one, > Security is another, network availability is another one. All that > amounts to cost. > This is an interesting comment. Normally in network design, one tries to avoid *single* points of failure. Multiple points of failure provide redundency, which helps improve reliability Are you proposing that a design based on a single point of failure is better? jak From owner-mobile-ip@sunroof.eng.sun.com Wed May 9 18:28:52 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27725 for ; Wed, 9 May 2001 18:28:51 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11236; Wed, 9 May 2001 15:28:45 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA27753; Wed, 9 May 2001 15:28:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f49MRJS17435 for mobile-ip-dist; Wed, 9 May 2001 15:27:19 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f49MRA417428 for ; Wed, 9 May 2001 15:27:10 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA08631 for ; Wed, 9 May 2001 15:27:05 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id QAA02339 for ; Wed, 9 May 2001 16:27:08 -0600 (MDT) Received: (qmail 30487 invoked by uid 500); 9 May 2001 22:11:24 -0000 Date: Wed, 9 May 2001 15:11:24 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] New AAA Keys I-D is available Message-ID: <20010509151124.R12425@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: All, The new version of the AAA keys I-D has been sent to the secretariat. This version includes the comments that were received during a bar meeting in Minn. It also addresses some security concerns that I have received from two independent people (one being the security WG chair of another SDO). I would appreciate comments, and believe that the document is ready for a last call. As usual, a preview of the spec can be retrieved at http://www.diameter.org/draft-ietf-mobileip-aaa-key-05.txt. Thanks, PatC From owner-mobile-ip@sunroof.eng.sun.com Wed May 9 18:45:51 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28151 for ; Wed, 9 May 2001 18:45:50 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA26992; Wed, 9 May 2001 15:45:45 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA18521; Wed, 9 May 2001 15:45:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f49Mhoo17497 for mobile-ip-dist; Wed, 9 May 2001 15:43:50 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f49Mhf417490 for ; Wed, 9 May 2001 15:43:41 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA12520 for ; Wed, 9 May 2001 15:43:42 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA09995 for ; Wed, 9 May 2001 16:43:46 -0600 (MDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Wed, 9 May 2001 18:37:18 -0400 Message-ID: From: Mukesh Sharma To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: mobile-ip] Re: mobile-ip] Multiple flows with single NAI Date: Wed, 9 May 2001 18:37:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Madhavi, > -----Original Message----- > From: Madhavi Subbarao [mailto:msubbara@cisco.com] > Sent: Wednesday, May 09, 2001 4:48 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] Re: mobile-ip] Re: mobile-ip] Multiple flows with > single NAI > > > True...every IP packet does not have an NAI. However, the HA can > distinguish between different MN bindings using the tuple > (NAI, IP address). The draft we propose outlines the behavior for NAI > and multiple STATIC IP addresses...(NAI, IP address) is used as the > 'identifier' at the HA. There is no need for the HA to multicast or > sniff. We are thinking of the NAI as an identifier for the USER > behind the device...if that makes sense. It's analogous to what you > describe below as a 'subscription id', so I think we are on the same > page. > > Since NAI identifies and authenticates the USER, it shouldn't matter > which device the USER is coming in on. Moreover, the USER shouldn't > be constrained to use only a single device. > > -Madhavi I can see from the email (also the title of the draft) that you did put emphasis on STATIC IP addresses. Any reason why Dynamic IP addresses were not considered. I think that is also one of the possible case to be looked upon. As I think this model will fail if Dynamic addresses are considered. Or for it to work there is additional work needed at Mobile station, FA and HA. - Sharma From owner-mobile-ip@sunroof.eng.sun.com Wed May 9 19:51:31 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29437 for ; Wed, 9 May 2001 19:51:30 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA20745; Wed, 9 May 2001 16:51:19 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA02384; Wed, 9 May 2001 16:51:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f49NnMt17687 for mobile-ip-dist; Wed, 9 May 2001 16:49:22 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f49NnA417680 for ; Wed, 9 May 2001 16:49:10 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA25679 for ; Wed, 9 May 2001 16:49:10 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA02220 for ; Wed, 9 May 2001 16:49:08 -0700 (PDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f49Nn6N13347 for ; Thu, 10 May 2001 01:49:07 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Thu May 10 01:49:05 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 10 May 2001 01:49:04 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBE1E@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" , Erik.Nordmark@eng.sun.com Cc: tweckstr@cc.hut.fi Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L ocalized Mobility Management Requirement s) Date: Thu, 10 May 2001 01:49:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi James, > > => To avoid multiple single point of failiures and keeping unnecessary > > state within the network. The solution is not so trivial IMO. > > There are several downfalls to consider. Robustness is only one, > > Security is another, network availability is another one. All that > > amounts to cost. > > > > This is an interesting comment. Normally in network design, one tries > to avoid *single* points of failure. Multiple points of failure > provide redundency, which helps improve reliability > > Are you proposing that a design based on a single point of failure > is better? > => No of course not, I said multiple single points of failure. You can make one redundant for a cost, you can make three redundant for a much higher cost. So the goal is obviously to minimise the number of single points of failure. More clearly one is better than two and two is better than 3. Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed May 9 21:58:38 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA01882 for ; Wed, 9 May 2001 21:58:38 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA23376; Wed, 9 May 2001 18:58:27 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA26886; Wed, 9 May 2001 18:58:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4A1tBm17854 for mobile-ip-dist; Wed, 9 May 2001 18:55:11 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4A1t2417847 for ; Wed, 9 May 2001 18:55:03 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA26627 for ; Wed, 9 May 2001 18:55:02 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id SAA21625 for ; Wed, 9 May 2001 18:54:59 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA07344; Wed, 9 May 2001 21:54:59 -0400 Date: Wed, 9 May 2001 21:54:58 -0400 (EDT) From: Jim Bound To: "'mobile-ip@sunroof.eng.sun.com'" Cc: Erik Nordmark , =?ISO-8859-1?Q?Tom_Weckstr=F6m?= Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L ocalized Mobility Management Requirement s) In-Reply-To: <034BEFD03799D411A59F00508BDF7546013DBE1A@esealnt448.al.sw.ericsson.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Hesham, > => To avoid multiple single point of failiures and keeping unnecessary > state within the network. The solution is not so trivial IMO. > There are several downfalls to consider. Robustness is only one, > Security is another, network availability is another one. All that > amounts to cost. > Your argument above is that the implementation is too complex not that the idea of hierarchy is not valid. I have heard this from Erik too. From one implementor to the other I don't agree at all. I cannot see why your or Erick do not want to permit the ability tomorrow to distributed the problems at hand to LMMs in a hierarchy. I "think" what your saying is that this working group should support forcing forever that the network principles of hierarchy cannot be used for Mobile IP. Will it cost more is a good and important question. Yes it will. And one of our jobs as engineers is keep cost in mind with any solution (a practice that is not followed widely in our community of late) and if the only solution a hierarchial approach could implement was multiple levels of hiearchy then I would agree. But 1 level can be implemented which is no hiearchy and that is the least cost. But if a vendor and user want to spend more money and use the principles of LMM with hierarchy then they would not be able to with your view. To understand your view better are you and Erik (Erik can speak for himself of course) saying that you want to prohibit LMM hierarchy forever for Mobile IP LMMs. Just to get exactly where people are coming from in the most direct manner. thanks /jim From owner-mobile-ip@sunroof.eng.sun.com Wed May 9 22:34:34 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA03126 for ; Wed, 9 May 2001 22:34:34 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA15554; Wed, 9 May 2001 19:34:16 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA19605; Wed, 9 May 2001 19:34:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4A2WUt17896 for mobile-ip-dist; Wed, 9 May 2001 19:32:30 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4A2WL417889 for ; Wed, 9 May 2001 19:32:21 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA19420 for ; Wed, 9 May 2001 19:32:21 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA14851 for ; Wed, 9 May 2001 19:32:19 -0700 (PDT) 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 TAA23394; Wed, 9 May 2001 19:32:19 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f4A2WIL09214; Wed, 9 May 2001 19:32:18 -0700 X-mProtect: Wed, 9 May 2001 19:32:18 -0700 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdmQ4ca3; Wed, 09 May 2001 19:32:11 PDT Message-ID: <3AF9FDA5.4E178F76@iprg.nokia.com> Date: Wed, 09 May 2001 19:32:05 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (EPA)" CC: mobile-ip@sunroof.eng.sun.com Subject: Re: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised Localized Mobility Management Requirement s) References: <034BEFD03799D411A59F00508BDF7546013DBE1A@esealnt448.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Hesham, Here are my comments. After reading my last note, perhaps some of the wording was too vigorous -- I got carried away. > > I think the main reasons for intermediate levels are: > > > > - Shorter signaling paths -- fewer chances for congestion and delays, > > fewer nodes to process the control messages, and (O.K. maybe not huge) > > better average performance -- but probably more consistent performance > > > => The argument thus far has been whether there is any significant > improvement (in delays) that could outweigh the introduced > complexity within the network. So far I haven't seen an argument > to prove that there is such _significant_benefit. There is obviously some benefit. Any time you can put fewer processing nodes in the middle of the signaling path, you will get improved performance, surely at least by having less jitter. I am worried that mistakes at this basic level will have ramifications for future handling of video/multimedia streams, and various other QoS (especially delay-oriented) reservations. Plus it seems to stand out as the right thing to do. Whether the performance gain is significant probably depends on the particular network architecture. As has been noted, restricting the number of levels introduces a new requirement to figure out how high or low to place the LMM agents. Having multiple levels of hierarchy eliminates that particular design requirement, because of the next main point -- that enabling multiple levels allows us to adapt better to the natural design of networks. > > - Natural fit to hierarchical network architectures > > > => There is hierarchy of a routers within the Internet today, > but do they all need to be mobile aware ? That is not > a trivial conclusion. The routing within a hierarchy of > routers is handled by standard routing protocols. > I don't think MIP is needed for this task. Nobody is saying that all the routers have to be mobile aware. Only the LMM agents have to be aware, and not all routers are expected to be LMM agents. > > ---- Backbone/Core Network/IP RAN at least, > > > => I don't know if there are any RAN standards > that require this. However, if in future open RANs > are standardised then the argument is the same > whether a network is a RAN or not. It is very likely that we'll eventually have open RAN. To me, it's clear that a RAN should be a collection of IP routable networks. Do you say otherwise? If your argument is that we don't have IP RAN, so we don't need leveled LMMs, then I believe that is a very short-sighted argument. > > But why should we have to botch the > > obvious network architecture in order to support something only marginally > > easier (if at all!) to implement > > > => To avoid multiple single point of failiures and keeping unnecessary > state within the network. The solution is not so trivial IMO. > There are several downfalls to consider. Robustness is only one, > Security is another, network availability is another one. All that > amounts to cost. First, we should get the LMM agent architecture right. Security will not add any particular penalty here. Network availability and robustness are the same in this context. That requirement can be met by some protocol that resolves node failures (a routing protocol). Whether it's a modification to OSPF, or a manet, or something in-between, is a problem we can solve in due time. Getting the LMM architecture wrong, though, is not so easily corrected. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Wed May 9 23:18:13 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA03665 for ; Wed, 9 May 2001 23:18:12 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA08818; Wed, 9 May 2001 20:17:00 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA04669; Wed, 9 May 2001 20:16:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4A3F7H17940 for mobile-ip-dist; Wed, 9 May 2001 20:15:07 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4A3Ev417933 for ; Wed, 9 May 2001 20:14:58 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA18063 for ; Wed, 9 May 2001 20:14:57 -0700 (PDT) Received: from mail.icu.ac.kr (mail.icu.ac.kr [210.107.128.31]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA18904 for ; Wed, 9 May 2001 20:14:55 -0700 (PDT) Received: from twum (v35-168.icu.ac.kr [210.107.135.168]) by mail.icu.ac.kr (8.11.0/8.11.0) with SMTP id f4A3Brw00557; Thu, 10 May 2001 12:11:53 +0900 (KST) Message-ID: <014f01c0d8ff$6edcfb50$a8876bd2@twum> From: "Tai-Won Um" To: , Cc: "Jun Kyun Choi" References: Subject: Re: [mobile-ip] Mobile-IP and MPLS Integration Date: Thu, 10 May 2001 12:15:15 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_014C_01C0D94A.DE99C2C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_014C_01C0D94A.DE99C2C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGVsbG8gU2hhcmlmLA0KDQpQbGVhc2UgdGFrZSBhIGxvb2sgYXQgdGhlIGRyYWZ0IGF0IGh0dHA6 Ly9zZWFyY2guaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWNob2ktbW9iaWxlaXAtbGRw ZXh0LTAxLnR4dCAuIEkgdGhpbmsgdGhpcyB3aWxsIGV4cGxhaW4gaG93IHRvIGJ1aWxkIHRoZSBs YXJnZS1zY2FsZSBNb2JpbGUgSVAgbmV0d29yayB0aHJvdWdoIHRoZSBNUExTIG5ldHdvcmsuICBB bmQgdGhlIGRyYWZ0IGF0IGh0dHA6Ly9zZWFyY2guaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWNob2ktbW9iaWxlaXAtaXB2Ni1tcGxzLTAwLnR4dCBwcm9wb3NlcyBob3cgdG8gYnVpbGQg dGhlIGxhcmdlLXNjYWxlIG1vYmlsZSBJUHY2IG5ldHdvcmsgYWxvbmcgd2l0aCB0aGUgTVBMUyBu ZXR3b3JrLg0KDQpUaGFua3MNCg0KVGFpLVdvbiBVbSANCiAgLS0tLS0gT3JpZ2luYWwgTWVzc2Fn ZSAtLS0tLSANCiAgRnJvbTogU2hhaHJpZXIsIFNoYXJpZiBNLiANCiAgVG86ICdtb2JpbGUtaXBA c3Vucm9vZi5lbmcuc3VuLmNvbScgDQogIFNlbnQ6IFdlZG5lc2RheSwgTWF5IDA5LCAyMDAxIDEx OjE5IFBNDQogIFN1YmplY3Q6IFJFOiBbbW9iaWxlLWlwXSBNb2JpbGUtSVAgYW5kIE1QTFMgSW50 ZWdyYXRpb24NCg0KDQogIElzIHRoZXJlIGEgY3VycmVudCBpbnRlcm5ldCBkcmFmdCBvbiB0aGlz LiBDb3VsZCBzb21lb25lIHBsZWFzZSBzZW5kIG1lIHRoZSByZWZlcmVuY2UuDQogICANCiAgLVNo YXJpZg0KICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAgRnJvbTogQXNoIGggW21h aWx0bzphc2Nod2lubkB5YWhvby5jb21dDQogICAgU2VudDogTW9uZGF5LCBNYXkgMDcsIDIwMDEg NToyNiBQTQ0KICAgIFRvOiBtb2JpbGUtaXBAc3Vucm9vZi5lbmcuc3VuLmNvbQ0KICAgIFN1Ympl Y3Q6IFJlOiBbbW9iaWxlLWlwXSBNb2JpbGUtSVAgYW5kIE1QTFMgSW50ZWdyYXRpb24NCg0KDQoN CiAgICAgICBJIGd1ZXNzIHdlIGFyZSBjb25jdXJyaW5nIHdpdGggdGhlIGZhY3QgdGhhdCB0aGUg Q09BIG11c3QgYmUgdGhhdCBvZiB0aGUgRkEgYW5kIG5ldmVyIHRoYXQgb2YgdGhlIE1OIHNpbmNl IE1OIG1heSBub3QgcGFydGljaXBhdGUgaW4gTVBMUy4gSGVuY2UgdGhlIEZBIHNob3VsZCBub3Qg YWxsb3cgY29sb2NhdGVkIENPQSBpZiBpdCBpcyBpbiBpdHMgY2FwYWNpdHkgYW5kIGluc3RlYWQg dXNlIHRoZSBGQSBDT0EgdG8gdGVybWluYXRlIHRoZSBMU1AuIFRodXMgdGhlIG5lZWQgdG8gY2Fy cnkgdGhlIEZBIGFkZHJlc3MgaW4gYSBkaWZmZXJlbnQgZmllbGQgbWF5IG5vdCBiZSBuZWNlc3Nh cnlbIENPQSA9IEZBJ3MgYWRkcl0uIEkgZG9uJ3QgdGhpbmsgdGhpcyB3aWxsIGhhbXBlciBhbnkg c2VtYW50aWNzIGFzc2lnbmVkIHRvIHRoZSBMU1AgKHZpeiBRT1MsIFZQTiBldGMpLg0KDQoNCiAg ICAgIFNhdGlzaF9BbWFyYUAzY29tLmNvbSB3cm90ZTogDQoNCg0KDQoNCiAgICAgIEhpLA0KICAg ICAgUGxlYXNlIHNlZSBmb3IgbXkgY29tbWVudHMuDQoNCg0KDQoNCiAgICAgIEFzaCBoIG9uIDA1 LzA3LzIwMDEgMDI6MzQ6MjQgUE0NCg0KICAgICAgUGxlYXNlIHJlc3BvbmQgdG8gbW9iaWxlLWlw QHN1bnJvb2YuZW5nLnN1bi5jb20NCg0KICAgICAgU2VudCBieTogQXNoIGggDQoNCg0KICAgICAg VG86IG1vYmlsZS1pcEBzdW5yb29mLmVuZy5zdW4uY29tDQogICAgICBjYzogKFNhdGlzaCBBbWFy YS9NVy9VUy8zQ29tKQ0KICAgICAgU3ViamVjdDogUmU6IFttb2JpbGUtaXBdIE1vYmlsZS1JUCBh bmQgTVBMUyBJbnRlZ3JhdGlvbg0KDQoNCg0KDQogICAgICBXaHkgZG8geW91IHRoaW5rIHRoYXQg dGhlIGNvLWxvY2F0ZWQgY2FyZS1vZi1hZGRyIHNob3VsZCBiZSB0cmVhdGVkDQogICAgICBkaWZm ZXJlbnRseT8gSWYgdGhlIENPQSBpcyBjb252ZXllZCB0byB0aGUgSW5ncmVzcyBMRVIgYWxsIHRo YXQgaXQgbmVlZHMgdG8gZG8NCiAgICAgIGlzIHRvIGVzdGFibGlzaCBhIHR1bm5lbCBbTFNQXSB0 byB0aGF0IGFkZHJlc3MuIFRoZSBtb2JpbGUgbm9kZSBzaG91bGQgYmUNCiAgICAgIGNhcGFibGUg b2YgdW5kZXJzdGFuZGluZyB0aGUgTGFiZWwgTWFwIFJlcXVlc3QuIElmIG5vdCB0aGVuIEkgZG9u J3Qga25vdyBob3cgdGhlDQogICAgICBGQSdzIGFkZHJlc3Mgd2lsbCBoZWxwLCBzaW5jZSB0aGUg dHVubmVsIGlzIGV4cGVjdGVkIHRvIHRlcm1pbmF0ZSBhdCB0aGUgTU4gYnV0DQogICAgICBnZXRz IHRlcm1pbmF0ZWQgYXQgdGhlIEZBIGFuZCB0aGUgRkEgZG9lc24ndCBrbm93IHdoYXQgaXQgc2hv dWxkIGRvIHdpdGggdGhlDQogICAgICBkYXRhZ3JhbSBhZnRlciBkZWNhcHN1bGF0aW9uLiBDb3Jy ZWN0IG1lLg0KDQogICAgICA+PkkhICEgISAhIGFtIGFzc3VtaW5nIG1vYmlsZSBub2RlcyBkb2Vz bid0IHN1cHBvcnQgTVBMUyBhcyBNUExTIGlzIHN0aWxsICJjb3JlDQogICAgICBuZXR3b3JrcyB0 ZWNobm9sb2d5Ii4gRkEgd291bGQgaGFuZGxlDQogICAgICB0aGUgcGFja2V0IGluIHNpbWlsYXIg d2F5IGFzIGl0IGRpZCB3aGVuIENPQSBpcyBvZiB0eXBlIGZvcmVpZ24gYWdlbnQuDQoNCiAgICAg ID4+QWxzbywgbGV0IHNheSB3ZSB3YW50IHRvIHVzZSBNUExTIGZvciBmYXN0IGZvcndhcmRpbmcg YW5kIFFPUyBhbmQgbm90IHRvDQogICAgICBlbGltaW5hdGUgSVAgdHVubmVsLiBJbiB0aGlzIGNh c2UsIHdlDQogICAgICBwcm9iYWJseSB3YW50IHRvIGZhc3Qgc3dpdGNoIHBhY2tldCBmcm9tIElu Z3Jlc3MoSEEpIHRvIEVncmVzcyhGQSkuDQoNCiAgICAgIFRoYW5rcywNCiAgICAgIFNhdGlzaA0K DQoNCiAgICAgIFNhdGlzaF9BbWFyYUAzY29tLmNvbSB3cm90ZToNCg0KICAgICAgSGksDQogICAg ICBJIGhhdmUgYSBxdWVzdGlvbiByZWdhcmRpbmcgTFNQIHR1bm5lbCBlc3RhYmxpc2htZW50IGJl dHdlZW4gSW5ncmVzcyBMRVINCiAgICAgIG9mIENOIGFuZCBGQS1MRVIgb2YgTU4gaW4NCiAgICAg IHNlY3Rpb24gMy40LjIgLiBSRkMuDQogICAgICBodHRwOi8vc2VhcmNoLmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy9kcmFmdC1jaG9pLW1vYmlsZWlwLWxkcGV4dC0wMS50eHQNCiAgICAgIChNUExT LWJhc2VkIE1vYmlsZSBJUCBSb3V0ZSBPcHRpbWl6YXRpb24gU2NlbmFyaW8uKSBBbHNvLCBMU1Ag dHVubmVsIGJldHdlZW4NCiAgICAgIEhBLUxFUiBhbmQNCiAgICAgIEZBLUxFUiwgaXMgbm90IHBv c3NpYmxlIGlmIGNhcmUgb2YgYWRkcmVzcyBpcyBvZiB0eXBlIGNvLWxvY2F0ZWQgY2FyZS1vZg0K ICAgICAgYWRkcmVzcy4gQXMgYm90aCB0aGUgYmluZGluZyBhbmQNCiAgICAgIHJlZ2lzdHJhdGlv biBtZXNzYWdlcyBkb2Vzbid0IGNvbnRhaW4gYWRkcmVzcyBvZiBGQSAuIE9uZSBzb2x1dGlvbiB0 byB0aGUgYWJvdmUNCiAgICAgIHByb2JsZW0NCiAgICAgIGlzIHRvIG1lbnRpb24gdGhlIEZBIGEh ICEgISAhIGRkcmVzcyhMRVIpIGluIHJlZ2lzdHJhdGlvbiBtZXNzYWdlIGFuZCBiaW5kaW5nIHVw ZGF0ZQ0KICAgICAgd2hlbiBjYXJlIG9mIGFkZHJlc3MgaXMgb2YNCiAgICAgIHR5cGUgY28tbG9j YXRlZC4NCg0KICAgICAgVGhhbmtzLA0KICAgICAgU2F0aXNoIEFtYXJhDQoNCg0KDQogICAgICAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICAgIERvIFlvdSBZYWhvbyE/DQog ICAgICBZYWhvbyEgQXVjdGlvbnMgLSBDbGljayBhbmQgYmlkIG9uIGNvb2wgc3R1ZmYgbGlrZSBE YXZlIE1hdHRoZXdzIEJhbmQgVGlja2V0cyAmDQogICAgICBtb3JlIQ0KDQoNCiAgICAgIFdoeSBk byB5b3UgdGhpbmsgdGhhdCB0aGUgY28tbG9jYXRlZCBjYXJlLW9mLWFkZHIgc2hvdWxkIGJlIHRy ZWF0ZWQgZGlmZmVyZW50bHk/IElmIHRoZSBDT0EgaXMgY29udmV5ZWQgdG8gdGhlIEluZ3Jlc3Mg TEVSIGFsbCB0aGF0IGl0IG5lZWRzIHRvIGRvIGlzIHRvIGVzdGFibGlzaCBhIHR1bm5lbCBbTFNQ XSB0byB0aGF0IGFkZHJlc3MuIFRoZSBtb2JpbGUgbm9kZSBzaG91bGQgYmUgY2FwYWJsZSBvZiB1 bmRlcnN0YW5kaW5nIHRoZSBMYWJlbCBNYXAgUmVxdWVzdC4gSWYgbm90IHRoZW4gSSBkb24ndCBr bm93IGhvdyB0aGUgRkEncyBhZGRyZXNzIHdpbGwgaGVscCwgc2luY2UgdGhlIHR1bm5lbCBpcyBl eHBlY3RlZCB0byB0ZXJtaW5hdGUgYXQgdGhlIE1OIGJ1dCBnZXRzIHRlcm1pbmF0ZWQgYXQgdGhl IEZBIGFuZCB0aGUgRkEgZG9lc24ndCBrbm93IHdoYXQgaXQgc2hvdWxkIGRvIHdpdGggdGhlIGRh dGFncmFtIGFmdGVyIGRlY2Fwc3VsYXRpb24uIENvcnJlY3QgbWUuDQoNCg0KDQoNCiAgICAgICAg U2F0aXNoX0FtYXJhQDNjb20uY29tIHdyb3RlOiANCg0KDQoNCg0KICAgICAgICBIaSwNCiAgICAg ICAgSSBoYXZlIGEgcXVlc3Rpb24gcmVnYXJkaW5nIExTUCB0dW5uZWwgZXN0YWJsaXNobWVudCBi ZXR3ZWVuIEluZ3Jlc3MgTEVSDQogICAgICAgIG9mIENOIGFuZCBGQS1MRVIgb2YgTU4gaW4NCiAg ICAgICAgc2VjdGlvbiAzLjQuMiAuIFJGQy4NCiAgICAgICAgaHR0cDovL3NlYXJjaC5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtY2hvaS1tb2JpbGVpcC1sZHBleHQtMDEudHh0DQogICAg ICAgIChNUExTLWJhc2VkIE1vYmlsZSBJUCBSb3V0ZSBPcHRpbWl6YXRpb24gU2NlbmFyaW8uKSBB bHNvLCBMU1AgdHVubmVsIGJldHdlZW4NCiAgICAgICAgSEEtTEVSIGFuZA0KICAgICAgICBGQS1M RVIsIGlzIG5vdCBwb3NzaWJsZSBpZiBjYXJlIG9mIGFkZHJlc3MgaXMgb2YgdHlwZSBjby1sb2Nh dGVkIGNhcmUtb2YNCiAgICAgICAgYWRkcmVzcy4gQXMgYm90aCB0aGUgYmluZGluZyBhbmQNCiAg ICAgICAgcmVnaXN0cmF0aW9uIG1lc3NhZ2VzIGRvZXNuJ3QgY29udGFpbiBhZGRyZXNzIG9mIEZB IC4gT25lIHNvbHV0aW9uIHRvIHRoZSBhYm92ZQ0KICAgICAgICBwcm9ibGVtDQogICAgICAgIGlz IHRvIG1lbnRpb24gdGhlIEZBIGFkZHJlc3MoTEVSKSBpbiByZWdpc3RyYXRpb24gbWVzc2FnZSBh bmQgYmluZGluZyB1cGRhdGUNCiAgICAgICAgd2hlbiBjYXJlIG9mIGFkZHJlc3MgaXMgb2YNCiAg ICAgICAgdHlwZSBjby1sb2NhdGVkLg0KDQogICAgICAgIFRoYW5rcywNCiAgICAgICAgU2F0aXNo IEFtYXJhDQoNCg0KDQoNCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KICAgICAgRG8gWW91 IFlhaG9vIT8NCiAgICAgIFlhaG9vISBBdWN0aW9ucyAtIENsaWNrIGFuZCBiaWQgb24gY29vbCBz dHVmZiBsaWtlIERhdmUgTWF0dGhld3MgQmFuZCBUaWNrZXRzICYgbW9yZSEgDQoNCg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KICAgIERvIFlvdSBZYWhvbyE/DQogICAgWWFob28hIEF1Y3Rpb25zIC0g Q2xpY2sgYW5kIGJpZCBvbiBjb29sIHN0dWZmIGxpa2UgRGF2ZSBNYXR0aGV3cyBCYW5kIFRpY2tl dHMgJiBtb3JlIQ0K ------=_NextPart_000_014C_01C0D94A.DE99C2C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlz by04ODU5LTEiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDUuMDAuMjkyMC4wIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFEPg0K PEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBmYWNlPSYjNDQ0MDQ7JiM0NzU0ODsg c2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICYjNDgxNDg7JiM1 MzQ2MTs7IEZPTlQtU0laRTogMTBwdDsgbXNvLWJpZGktZm9udC1zaXplOiAxMi4wcHQ7IG1zby1o YW5zaS1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1iaWRpLWZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWZvbnQta2VybmluZzogMS4wcHQ7IG1zby1hbnNpLWxh bmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPOyBtc28tYmlkaS1sYW5ndWFn ZTogQVItU0EiPkhlbGxvIA0KU2hhcmlmLDxCUj48QlI+UGxlYXNlIHRha2UgYSBsb29rIGF0IHRo ZSZuYnNwO2RyYWZ0IGF0IDxBIA0KaHJlZj0iaHR0cDovL3NlYXJjaC5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtY2hvaS1tb2JpbGVpcC1sZHBleHQtMDEudHh0Ij5odHRwOi8vc2VhcmNo LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1jaG9pLW1vYmlsZWlwLWxkcGV4dC0wMS50 eHQ8L0E+PC9TUEFOPjxTUEFOIA0KbGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULUZBTUlMWTogJ1Rp bWVzIE5ldyBSb21hbic7IEZPTlQtU0laRTogMTBwdDsgbXNvLWJpZGktZm9udC1zaXplOiAxMi4w cHQ7IG1zby1mb250LWtlcm5pbmc6IDEuMHB0OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1z by1mYXJlYXN0LWxhbmd1YWdlOiBLTzsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBOyBtc28tYXNj aWktZm9udC1mYW1pbHk6ICYjNDgxNDg7JiM1MzQ2MTs7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OiAmIzQ4MTQ4OyYjNTM0NjE7Ij4mbmJzcDs8Rk9OVCANCmZhY2U9JiM0ODE0ODsmIzUzNDYxOz4u PC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAmIzQ4 MTQ4OyYjNTM0NjE7OyBGT05ULVNJWkU6IDEwcHQ7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTIuMHB0 OyBtc28taGFuc2ktZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYmlkaS1mb250 LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1mb250LWtlcm5pbmc6IDEuMHB0OyBtc28t YW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTzsgbXNvLWJpZGkt bGFuZ3VhZ2U6IEFSLVNBIj4gDQpJIHRoaW5rIHRoaXMgd2lsbCBleHBsYWluIGhvdyB0byBidWls ZCB0aGUgbGFyZ2Utc2NhbGUgTW9iaWxlIElQJm5ic3A7bmV0d29yayANCnRocm91Z2ggdGhlIE1Q TFMgbmV0d29yay4mbmJzcDs8L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULUZB TUlMWTogJ1RpbWVzIE5ldyBSb21hbic7IEZPTlQtU0laRTogMTBwdDsgbXNvLWJpZGktZm9udC1z aXplOiAxMi4wcHQ7IG1zby1mb250LWtlcm5pbmc6IDEuMHB0OyBtc28tYW5zaS1sYW5ndWFnZTog RU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTzsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNB OyBtc28tYXNjaWktZm9udC1mYW1pbHk6ICYjNDgxNDg7JiM1MzQ2MTs7IG1zby1mYXJlYXN0LWZv bnQtZmFtaWx5OiAmIzQ4MTQ4OyYjNTM0NjE7Ij4mbmJzcDs8Rk9OVCANCmZhY2U9JiM0ODE0ODsm IzUzNDYxOz5BbmQgdGhlIGRyYWZ0IGF0IDxBIA0KaHJlZj0iaHR0cDovL3NlYXJjaC5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtY2hvaS1tb2JpbGVpcC1pcHY2LW1wbHMtMDAudHh0Ij5o dHRwOi8vc2VhcmNoLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1jaG9pLW1vYmlsZWlw LWlwdjYtbXBscy0wMC50eHQ8L0E+Jm5ic3A7cHJvcG9zZXMgDQpob3cgdG8gYnVpbGQgdGhlIGxh cmdlLXNjYWxlIG1vYmlsZSBJUHY2Jm5ic3A7bmV0d29yayBhbG9uZyB3aXRoIHRoZSBNUExTIA0K bmV0d29yay48L0ZPTlQ+PC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzQ0 NDA0OyYjNDc1NDg7IHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtRkFNSUxZ OiAnVGltZXMgTmV3IFJvbWFuJzsgRk9OVC1TSVpFOiAxMHB0OyBtc28tYmlkaS1mb250LXNpemU6 IDEyLjBwdDsgbXNvLWZvbnQta2VybmluZzogMS4wcHQ7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1V UzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0E7IG1z by1hc2NpaS1mb250LWZhbWlseTogJiM0ODE0ODsmIzUzNDYxOzsgbXNvLWZhcmVhc3QtZm9udC1m YW1pbHk6ICYjNDgxNDg7JiM1MzQ2MTsiPjxGT05UIA0KZmFjZT0mIzQ4MTQ4OyYjNTM0NjE7Pjwv Rk9OVD48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjNDQ0MDQ7 JiM0NzU0ODsgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdU aW1lcyBOZXcgUm9tYW4nOyBGT05ULVNJWkU6IDEwcHQ7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTIu MHB0OyBtc28tZm9udC1rZXJuaW5nOiAxLjBwdDsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBt c28tZmFyZWFzdC1sYW5ndWFnZTogS087IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQTsgbXNvLWFz Y2lpLWZvbnQtZmFtaWx5OiAmIzQ4MTQ4OyYjNTM0NjE7OyBtc28tZmFyZWFzdC1mb250LWZhbWls eTogJiM0ODE0ODsmIzUzNDYxOyI+VGhhbmtzPC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgZmFjZT0mIzQ0NDA0OyYjNDc1NDg7IHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9 IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJzsgRk9OVC1TSVpFOiAxMHB0OyBtc28tYmlk aS1mb250LXNpemU6IDEyLjBwdDsgbXNvLWZvbnQta2VybmluZzogMS4wcHQ7IG1zby1hbnNpLWxh bmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPOyBtc28tYmlkaS1sYW5ndWFn ZTogQVItU0E7IG1zby1hc2NpaS1mb250LWZhbWlseTogJiM0ODE0ODsmIzUzNDYxOzsgbXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6ICYjNDgxNDg7JiM1MzQ2MTsiPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7 PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiM0NDQwNDsmIzQ3NTQ4OyBzaXplPTI+PFNQQU4gbGFu Zz1FTi1VUyANCnN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbic7IEZPTlQtU0la RTogMTBwdDsgbXNvLWJpZGktZm9udC1zaXplOiAxMi4wcHQ7IG1zby1mb250LWtlcm5pbmc6IDEu MHB0OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTzsg bXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBOyBtc28tYXNjaWktZm9udC1mYW1pbHk6ICYjNDgxNDg7 JiM1MzQ2MTs7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAmIzQ4MTQ4OyYjNTM0NjE7Ij48Rk9O VCANCmZhY2U9JiM0ODE0ODsmIzUzNDYxOz5UYWktV29uIFVtPC9GT05UPiZuYnNwOzwvU1BBTj48 L0ZPTlQ+PC9ESVY+DQo8QkxPQ0tRVU9URSANCnN0eWxlPSJCT1JERVItTEVGVDogIzAwMDAwMCAy cHggc29saWQ7IE1BUkdJTi1MRUZUOiA1cHg7IE1BUkdJTi1SSUdIVDogMHB4OyBQQURESU5HLUxF RlQ6IDVweDsgUEFERElORy1SSUdIVDogMHB4Ij4NCiAgPERJViBzdHlsZT0iRk9OVDogMTBwdCAm IzQ0NDA0OyYjNDc1NDg7Ij4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvRElWPg0KICA8 RElWIA0KICBzdHlsZT0iQkFDS0dST1VORDogI2U0ZTRlNDsgRk9OVDogMTBwdCAmIzQ0NDA0OyYj NDc1NDg7OyBmb250LWNvbG9yOiBibGFjayI+PEI+RnJvbTo8L0I+IDxBIA0KICBocmVmPSJtYWls dG86U2hhcmlmLlNoYWhyaWVyQEludGVyRGlnaXRhbC5jb20iIA0KICB0aXRsZT1TaGFyaWYuU2hh aHJpZXJASW50ZXJEaWdpdGFsLmNvbT5TaGFocmllciwgU2hhcmlmIE0uPC9BPiA8L0RJVj4NCiAg PERJViBzdHlsZT0iRk9OVDogMTBwdCAmIzQ0NDA0OyYjNDc1NDg7Ij48Qj5Ubzo8L0I+IDxBIA0K ICBocmVmPSJtYWlsdG86J21vYmlsZS1pcEBzdW5yb29mLmVuZy5zdW4uY29tJyIgDQogIHRpdGxl PW1vYmlsZS1pcEBzdW5yb29mLmVuZy5zdW4uY29tPidtb2JpbGUtaXBAc3Vucm9vZi5lbmcuc3Vu LmNvbSc8L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiAxMHB0ICYjNDQ0MDQ7JiM0NzU0 ODsiPjxCPlNlbnQ6PC9CPiBXZWRuZXNkYXksIE1heSAwOSwgMjAwMSAxMToxOSBQTTwvRElWPg0K ICA8RElWIHN0eWxlPSJGT05UOiAxMHB0ICYjNDQ0MDQ7JiM0NzU0ODsiPjxCPlN1YmplY3Q6PC9C PiBSRTogW21vYmlsZS1pcF0gTW9iaWxlLUlQIGFuZCBNUExTIA0KICBJbnRlZ3JhdGlvbjwvRElW Pg0KICA8RElWPjxCUj48L0RJVj4NCiAgPERJVj48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJp YWwgc2l6ZT0yPjxTUEFOIGNsYXNzPTM2MjE0MjExNC0wOTA1MjAwMT5JcyANCiAgdGhlcmUgYSBj dXJyZW50IGludGVybmV0IGRyYWZ0IG9uIHRoaXMuIENvdWxkIHNvbWVvbmUgcGxlYXNlIHNlbmQg bWUgdGhlIA0KICByZWZlcmVuY2UuPC9TUEFOPjwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBj b2xvcj0jMDAwMGZmIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KICBjbGFzcz0zNjIxNDIxMTQt MDkwNTIwMDE+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgPERJVj48Rk9OVCBjb2xvcj0j MDAwMGZmIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KICBjbGFzcz0zNjIxNDIxMTQtMDkwNTIw MDE+LVNoYXJpZjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogIDxCTE9DS1FVT1RFPg0KICAgIDxESVYg YWxpZ249bGVmdCBjbGFzcz1PdXRsb29rTWVzc2FnZUhlYWRlciBkaXI9bHRyPjxGT05UIGZhY2U9 VGFob21hIA0KICAgIHNpemU9Mj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxCUj48Qj5Gcm9t OjwvQj4gQXNoIGggWzxBIA0KICAgIGhyZWY9Im1haWx0bzphc2Nod2lubkB5YWhvby5jb20iPm1h aWx0bzphc2Nod2lubkB5YWhvby5jb208L0E+XTxCUj48Qj5TZW50OjwvQj4gDQogICAgTW9uZGF5 LCBNYXkgMDcsIDIwMDEgNToyNiBQTTxCUj48Qj5Ubzo8L0I+IDxBIA0KICAgIGhyZWY9Im1haWx0 bzptb2JpbGUtaXBAc3Vucm9vZi5lbmcuc3VuLmNvbSI+bW9iaWxlLWlwQHN1bnJvb2YuZW5nLnN1 bi5jb208L0E+PEJSPjxCPlN1YmplY3Q6PC9CPiANCiAgICBSZTogW21vYmlsZS1pcF0gTW9iaWxl LUlQIGFuZCBNUExTIEludGVncmF0aW9uPEJSPjxCUj48L0RJVj48L0ZPTlQ+DQogICAgPFA+PC9Q Pg0KICAgIDxQPiZuYnNwOyZuYnNwOyBJIGd1ZXNzIHdlIGFyZSBjb25jdXJyaW5nIHdpdGggdGhl IGZhY3QgdGhhdCB0aGUgQ09BIG11c3QgYmUgDQogICAgdGhhdCBvZiB0aGUgRkEgYW5kIG5ldmVy IHRoYXQgb2YgdGhlIE1OIHNpbmNlIE1OIG1heSBub3QgcGFydGljaXBhdGUgaW4gDQogICAgTVBM Uy4gSGVuY2UgdGhlIEZBJm5ic3A7c2hvdWxkIG5vdCBhbGxvdyBjb2xvY2F0ZWQgQ09BIGlmIGl0 IGlzIGluIGl0cyANCiAgICBjYXBhY2l0eSBhbmQgaW5zdGVhZCB1c2UgdGhlIEZBIENPQSB0byB0 ZXJtaW5hdGUgdGhlIExTUC4gVGh1cyB0aGUgbmVlZCB0byANCiAgICBjYXJyeSB0aGUgRkEgYWRk cmVzcyBpbiBhIGRpZmZlcmVudCBmaWVsZCBtYXkgbm90IGJlIG5lY2Vzc2FyeVsgQ09BID0gRkEn cyANCiAgICBhZGRyXS4gSSBkb24ndCB0aGluayB0aGlzIHdpbGwgaGFtcGVyIGFueSBzZW1hbnRp Y3MgYXNzaWduZWQgdG8gdGhlIExTUCAodml6IA0KICAgIFFPUywgVlBOIGV0YykuPEJSPjwvUD4N CiAgICA8UD4mbmJzcDsgPEI+PEk+U2F0aXNoX0FtYXJhQDNjb20uY29tPC9JPjwvQj4gd3JvdGU6 IDxCUj4NCiAgICA8QkxPQ0tRVU9URSANCiAgICBzdHlsZT0iQk9SREVSLUxFRlQ6ICMxMDEwZmYg MnB4IHNvbGlkOyBNQVJHSU4tTEVGVDogNXB4OyBQQURESU5HLUxFRlQ6IDVweCI+PEJSPjxCUj5I aSw8QlI+UGxlYXNlIA0KICAgICAgc2VlIGZvciBteSBjb21tZW50cy48QlI+PEJSPjxCUj48QlI+ PEJSPkFzaCBoIDxBU0NIV0lOTkBZQUhPTy5DT00+b24gDQogICAgICAwNS8wNy8yMDAxIDAyOjM0 OjI0IFBNPEJSPjxCUj5QbGVhc2UgcmVzcG9uZCB0byANCiAgICAgIG1vYmlsZS1pcEBzdW5yb29m LmVuZy5zdW4uY29tPEJSPjxCUj5TZW50IGJ5OiBBc2ggaCANCiAgICAgIDxBU0NIV0lOTkBZQUhP Ty5DT00+PEJSPjxCUj48QlI+VG86IG1vYmlsZS1pcEBzdW5yb29mLmVuZy5zdW4uY29tPEJSPmNj OiANCiAgICAgIChTYXRpc2ggQW1hcmEvTVcvVVMvM0NvbSk8QlI+U3ViamVjdDogUmU6IFttb2Jp bGUtaXBdIE1vYmlsZS1JUCBhbmQgTVBMUyANCiAgICAgIEludGVncmF0aW9uPEJSPjxCUj48QlI+ PEJSPjxCUj5XaHkgZG8geW91IHRoaW5rIHRoYXQgdGhlIGNvLWxvY2F0ZWQgDQogICAgICBjYXJl LW9mLWFkZHIgc2hvdWxkIGJlIHRyZWF0ZWQ8QlI+ZGlmZmVyZW50bHk/IElmIHRoZSBDT0EgaXMg Y29udmV5ZWQgdG8gDQogICAgICB0aGUgSW5ncmVzcyBMRVIgYWxsIHRoYXQgaXQgbmVlZHMgdG8g ZG88QlI+aXMgdG8gZXN0YWJsaXNoIGEgdHVubmVsIFtMU1BdIA0KICAgICAgdG8gdGhhdCBhZGRy ZXNzLiBUaGUgbW9iaWxlIG5vZGUgc2hvdWxkIGJlPEJSPmNhcGFibGUgb2YgdW5kZXJzdGFuZGlu ZyB0aGUgDQogICAgICBMYWJlbCBNYXAgUmVxdWVzdC4gSWYgbm90IHRoZW4gSSBkb24ndCBrbm93 IGhvdyB0aGU8QlI+RkEncyBhZGRyZXNzIHdpbGwgDQogICAgICBoZWxwLCBzaW5jZSB0aGUgdHVu bmVsIGlzIGV4cGVjdGVkIHRvIHRlcm1pbmF0ZSBhdCB0aGUgTU4gYnV0PEJSPmdldHMgDQogICAg ICB0ZXJtaW5hdGVkIGF0IHRoZSBGQSBhbmQgdGhlIEZBIGRvZXNuJ3Qga25vdyB3aGF0IGl0IHNo b3VsZCBkbyB3aXRoIA0KICAgICAgdGhlPEJSPmRhdGFncmFtIGFmdGVyIGRlY2Fwc3VsYXRpb24u IENvcnJlY3QgbWUuPEJSPjxCUj4mZ3Q7Jmd0O0khICEgISAhIA0KICAgICAgYW0gYXNzdW1pbmcg bW9iaWxlIG5vZGVzIGRvZXNuJ3Qgc3VwcG9ydCBNUExTIGFzIE1QTFMgaXMgc3RpbGwgDQogICAg ICAiY29yZTxCUj5uZXR3b3JrcyB0ZWNobm9sb2d5Ii4gRkEgd291bGQgaGFuZGxlPEJSPnRoZSBw YWNrZXQgaW4gc2ltaWxhciANCiAgICAgIHdheSBhcyBpdCBkaWQgd2hlbiBDT0EgaXMgb2YgdHlw ZSBmb3JlaWduIGFnZW50LjxCUj48QlI+Jmd0OyZndDtBbHNvLCBsZXQgDQogICAgICBzYXkgd2Ug d2FudCB0byB1c2UgTVBMUyBmb3IgZmFzdCBmb3J3YXJkaW5nIGFuZCBRT1MgYW5kIG5vdCANCiAg ICAgIHRvPEJSPmVsaW1pbmF0ZSBJUCB0dW5uZWwuIEluIHRoaXMgY2FzZSwgd2U8QlI+cHJvYmFi bHkgd2FudCB0byBmYXN0IA0KICAgICAgc3dpdGNoIHBhY2tldCBmcm9tIEluZ3Jlc3MoSEEpIHRv IA0KICAgICAgRWdyZXNzKEZBKS48QlI+PEJSPlRoYW5rcyw8QlI+U2F0aXNoPEJSPjxCUj48QlI+ U2F0aXNoX0FtYXJhQDNjb20uY29tIA0KICAgICAgd3JvdGU6PEJSPjxCUj5IaSw8QlI+SSBoYXZl IGEgcXVlc3Rpb24gcmVnYXJkaW5nIExTUCB0dW5uZWwgZXN0YWJsaXNobWVudCANCiAgICAgIGJl dHdlZW4gSW5ncmVzcyBMRVI8QlI+b2YgQ04gYW5kIEZBLUxFUiBvZiBNTiBpbjxCUj5zZWN0aW9u IDMuNC4yIC4gDQogICAgICBSRkMuPEJSPmh0dHA6Ly9zZWFyY2guaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LWNob2ktbW9iaWxlaXAtbGRwZXh0LTAxLnR4dDxCUj4oTVBMUy1iYXNlZCAN CiAgICAgIE1vYmlsZSBJUCBSb3V0ZSBPcHRpbWl6YXRpb24gU2NlbmFyaW8uKSBBbHNvLCBMU1Ag dHVubmVsIGJldHdlZW48QlI+SEEtTEVSIA0KICAgICAgYW5kPEJSPkZBLUxFUiwgaXMgbm90IHBv c3NpYmxlIGlmIGNhcmUgb2YgYWRkcmVzcyBpcyBvZiB0eXBlIGNvLWxvY2F0ZWQgDQogICAgICBj YXJlLW9mPEJSPmFkZHJlc3MuIEFzIGJvdGggdGhlIGJpbmRpbmcgYW5kPEJSPnJlZ2lzdHJhdGlv biBtZXNzYWdlcyANCiAgICAgIGRvZXNuJ3QgY29udGFpbiBhZGRyZXNzIG9mIEZBIC4gT25lIHNv bHV0aW9uIHRvIHRoZSBhYm92ZTxCUj5wcm9ibGVtPEJSPmlzIA0KICAgICAgdG8gbWVudGlvbiB0 aGUgRkEgYSEgISAhICEgZGRyZXNzKExFUikgaW4gcmVnaXN0cmF0aW9uIG1lc3NhZ2UgYW5kIGJp bmRpbmcgDQogICAgICB1cGRhdGU8QlI+d2hlbiBjYXJlIG9mIGFkZHJlc3MgaXMgb2Y8QlI+dHlw ZSANCiAgICAgIGNvLWxvY2F0ZWQuPEJSPjxCUj5UaGFua3MsPEJSPlNhdGlzaCANCiAgICAgIEFt YXJhPEJSPjxCUj48QlI+PEJSPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxCUj5E byBZb3UgDQogICAgICBZYWhvbyE/PEJSPllhaG9vISBBdWN0aW9ucyAtIENsaWNrIGFuZCBiaWQg b24gY29vbCBzdHVmZiBsaWtlIERhdmUgDQogICAgICBNYXR0aGV3cyBCYW5kIFRpY2tldHMgJmFt cDs8QlI+bW9yZSE8QlI+PEJSPg0KICAgICAgPFA+V2h5IGRvIHlvdSB0aGluayB0aGF0IHRoZSBj by1sb2NhdGVkIGNhcmUtb2YtYWRkciBzaG91bGQgYmUgdHJlYXRlZCANCiAgICAgIGRpZmZlcmVu dGx5PyZuYnNwO0lmJm5ic3A7dGhlIENPQSBpcyBjb252ZXllZCB0byB0aGUgSW5ncmVzcyBMRVIg YWxsIHRoYXQgDQogICAgICBpdCBuZWVkcyB0byBkbyBpcyB0byBlc3RhYmxpc2ggYSB0dW5uZWwg W0xTUF0gdG8gdGhhdCBhZGRyZXNzLiBUaGUgbW9iaWxlIA0KICAgICAgbm9kZSBzaG91bGQgYmUg Y2FwYWJsZSBvZiB1bmRlcnN0YW5kaW5nIHRoZSBMYWJlbCBNYXAgUmVxdWVzdC4mbmJzcDtJZiBu b3QgDQogICAgICB0aGVuIEkgZG9uJ3Qga25vdyBob3cgdGhlIEZBJ3MgYWRkcmVzcyB3aWxsIGhl bHAsIHNpbmNlIHRoZSB0dW5uZWwgaXMgDQogICAgICBleHBlY3RlZCB0byB0ZXJtaW5hdGUgYXQg dGhlIE1OIGJ1dCZuYnNwO2dldHMgdGVybWluYXRlZCBhdCB0aGUgRkEgYW5kIHRoZSANCiAgICAg IEZBIGRvZXNuJ3Qga25vdyB3aGF0IGl0IHNob3VsZCBkbyB3aXRoIHRoZSBkYXRhZ3JhbSBhZnRl ciBkZWNhcHN1bGF0aW9uLiANCiAgICAgIENvcnJlY3QgbWUuPEJSPjwvUD48QlI+DQogICAgICA8 UD4mbmJzcDsgPEI+PEk+U2F0aXNoX0FtYXJhQDNjb20uY29tPC9JPjwvQj4gd3JvdGU6IDxCUj48 QlI+DQogICAgICA8QkxPQ0tRVU9URSANCiAgICAgIHN0eWxlPSJCT1JERVItTEVGVDogIzEwMTBm ZiAycHggc29saWQ7IE1BUkdJTi1MRUZUOiA1cHg7IFBBRERJTkctTEVGVDogNXB4Ij48QlI+SGks PEJSPkkgDQogICAgICAgIGhhdmUgYSBxdWVzdGlvbiByZWdhcmRpbmcgTFNQIHR1bm5lbCBlc3Rh Ymxpc2htZW50IGJldHdlZW4gSW5ncmVzcyANCiAgICAgICAgTEVSPEJSPm9mIENOIGFuZCBGQS1M RVIgb2YgTU4gaW48QlI+c2VjdGlvbiAzLjQuMiAuIA0KICAgICAgICBSRkMuPEJSPmh0dHA6Ly9z ZWFyY2guaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWNob2ktbW9iaWxlaXAtbGRwZXh0 LTAxLnR4dDxCUj4oTVBMUy1iYXNlZCANCiAgICAgICAgTW9iaWxlIElQIFJvdXRlIE9wdGltaXph dGlvbiBTY2VuYXJpby4pIEFsc28sIExTUCB0dW5uZWwgDQogICAgICAgIGJldHdlZW48QlI+SEEt TEVSIGFuZDxCUj5GQS1MRVIsIGlzIG5vdCBwb3NzaWJsZSBpZiBjYXJlIG9mIGFkZHJlc3MgaXMg DQogICAgICAgIG9mIHR5cGUgY28tbG9jYXRlZCBjYXJlLW9mPEJSPmFkZHJlc3MuIEFzIGJvdGgg dGhlIGJpbmRpbmcgDQogICAgICAgIGFuZDxCUj5yZWdpc3RyYXRpb24gbWVzc2FnZXMgZG9lc24n dCBjb250YWluIGFkZHJlc3Mgb2YgRkEgLiBPbmUgDQogICAgICAgIHNvbHV0aW9uIHRvIHRoZSBh Ym92ZTxCUj5wcm9ibGVtPEJSPmlzIHRvIG1lbnRpb24gdGhlIEZBIGFkZHJlc3MoTEVSKSBpbiAN CiAgICAgICAgcmVnaXN0cmF0aW9uIG1lc3NhZ2UgYW5kIGJpbmRpbmcgdXBkYXRlPEJSPndoZW4g Y2FyZSBvZiBhZGRyZXNzIGlzIA0KICAgICAgICBvZjxCUj50eXBlIGNvLWxvY2F0ZWQuPEJSPjxC Uj5UaGFua3MsPEJSPlNhdGlzaCANCiAgICAgIEFtYXJhPEJSPjxCUj48L0JMT0NLUVVPVEU+PEJS Pg0KICAgICAgPFA+PEJSPg0KICAgICAgPEhSIFNJWkU9MT4NCiAgICAgIDxCUj48Qj5EbyBZb3Ug WWFob28hPzwvQj48QlI+PEEgaHJlZj0iaHR0cDovL2F1Y3Rpb25zLnlhaG9vLmNvbS8iPllhaG9v ISANCiAgICAgIEF1Y3Rpb25zPC9BPiAtIENsaWNrIGFuZCBiaWQgb24gY29vbCBzdHVmZiBsaWtl IDxBIA0KICAgICAgaHJlZj0iaHR0cDovL3VzZXIuYXVjdGlvbnMueWFob28uY29tL3Nob3cvYXVj dGlvbnM/dXNlcklEPWRhdmVfbWF0dGhld3NfYmFuZF90aWNrZXRzJmFtcDt1PSUzYWRhdmVfbWF0 dGhld3NfYmFuZF90aWNrZXRzIj5EYXZlIA0KICAgICAgTWF0dGhld3MgQmFuZCBUaWNrZXRzPC9B PiAmYW1wOyA8QSANCiAgICAgIGhyZWY9Imh0dHA6Ly9hdWN0aW9ucy55YWhvby5jb20vIj5tb3Jl ITwvQT4gPC9CTE9DS1FVT1RFPg0KICAgIDxQPg0KICAgIDxIUiBTSVpFPTE+DQogICAgPEI+RG8g WW91IFlhaG9vIT88L0I+PEJSPjxBIGhyZWY9Imh0dHA6Ly9hdWN0aW9ucy55YWhvby5jb20vIj5Z YWhvbyEgDQogICAgQXVjdGlvbnM8L0E+IC0gQ2xpY2sgYW5kIGJpZCBvbiBjb29sIHN0dWZmIGxp a2UgPEEgDQogICAgaHJlZj0iaHR0cDovL3VzZXIuYXVjdGlvbnMueWFob28uY29tL3Nob3cvYXVj dGlvbnM/dXNlcklEPWRhdmVfbWF0dGhld3NfYmFuZF90aWNrZXRzJmFtcDt1PSUzYWRhdmVfbWF0 dGhld3NfYmFuZF90aWNrZXRzIj5EYXZlIA0KICAgIE1hdHRoZXdzIEJhbmQgVGlja2V0czwvQT4g JmFtcDsgPEEgDQogIGhyZWY9Imh0dHA6Ly9hdWN0aW9ucy55YWhvby5jb20iPm1vcmUhPC9BPjwv QkxPQ0tRVU9URT48L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_014C_01C0D94A.DE99C2C0-- From owner-mobile-ip@sunroof.eng.sun.com Thu May 10 02:17:46 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA19878 for ; Thu, 10 May 2001 02:17:46 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA09358; Wed, 9 May 2001 23:17:38 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA09256; Wed, 9 May 2001 23:17:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4A6FIU18385 for mobile-ip-dist; Wed, 9 May 2001 23:15:18 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4A6F9418378 for ; Wed, 9 May 2001 23:15:10 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA14972; Wed, 9 May 2001 23:15:10 -0700 (PDT) Received: from tiku.hut.fi (tiku.hut.fi [130.233.228.86]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA07157; Wed, 9 May 2001 23:15:08 -0700 (PDT) Received: from gamma.hut.fi (tweckstr@gamma.hut.fi [130.233.224.52]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id JAA00213; Thu, 10 May 2001 09:15:06 +0300 (EET DST) Date: Thu, 10 May 2001 09:14:58 +0300 (EET DST) From: =?ISO-8859-1?Q?Tom_Weckstr=F6m?= To: Erik Nordmark cc: =?iso-8859-1?Q?Tom_Weckstr=F6m?= , mobile-ip@sunroof.eng.sun.com, Basavaraj.Patil@nokia.com Subject: Re: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L ocalized Mobility Management Requirement s) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by patan.sun.com id XAA09358 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA19878 Erik, Very good points. I agree. For fast handoffs (increasing speed on the highway), #1 may be very important, while #2 is most important for scalability in the number of MNs and #3 is most important for high throughput of data. I think a good protocol should not make too much assumptions on what problem types (within the area of localized mobility management) the users of the protocol are trying to solve. The optimal protocol would then allow the deployment to be N LMMs in a row or N+m+n agents in a three level hierarchy. If the solution even allowed transparent clustering in the hierarchy's root, then I would be rather happy. :-) Regards, Tom On Wed, 9 May 2001, Erik Nordmark wrote: Erik.N > Erik.N >Tom, Erik.N > Erik.N >> Consider you have one level hierarhy with one "element" (I call those Erik.N >> FAs, but they may be called something else in some of the recent drafts Erik.N >> I have not read) in the highest level and N FAs on the lowest level. Erik.N >> Now, let us assume that considering only signaling, this system can Erik.N >> handle k MNs simultaneously. Those MNs are handling, e.g. VoIP calls and Erik.N >> are moving fast, e.g. on a highway. So, with all the VoIP call data and Erik.N >> localized mobility management signaling of the k MobileNodes, the Erik.N >> highest FA is fully employed. Erik.N > Erik.N >Good example since it raises an interesting question. Erik.N >The highest FA could be fully utilized for multiple reasons: Erik.N >1. running out of processing power to handle the rate of binding updates Erik.N >2. running out of memory to store the state for the bindings Erik.N >3. running out of bandwidth on its network interfaces for all Erik.N > the traffic to (and from?) the MNs Erik.N > Erik.N >If you add a hierarchy of LMMs below this box and have the box continue to Erik.N >serve the same number of MNs you can improve #1 but it doesn't change Erik.N >#2 or #3. Erik.N >If you instead of a hierarchy add N equal LMM agents at the top level Erik.N >(e.g., with each MN in the domain randomly selecting which LMM agent to use) Erik.N >then you can address scaling along all of the above axis. Erik.N > Erik.N >So it all depends along what axis you think the agent will max out first. Erik.N > Erik.N > Erik Erik.N > -- Tom Weckström Dynamics group Helsinki University of Technology dynamics@cs.hut.fi http://www.cs.hut.fi/Research/Dynamics/ From owner-mobile-ip@sunroof.eng.sun.com Thu May 10 04:38:17 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21077 for ; Thu, 10 May 2001 04:38:17 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA12127; Thu, 10 May 2001 01:38:03 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA17007; Thu, 10 May 2001 01:37:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4A8aCu18532 for mobile-ip-dist; Thu, 10 May 2001 01:36:12 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4A8a3418525 for ; Thu, 10 May 2001 01:36:03 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA02185 for ; Thu, 10 May 2001 01:36:02 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA11219 for ; Thu, 10 May 2001 01:36:00 -0700 (PDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f4A8ZuN13872 for ; Thu, 10 May 2001 10:36:00 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Thu May 10 10:35:39 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 10 May 2001 10:35:50 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBE1F@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Cc: Erik Nordmark , =?ISO-8859-1?Q?Tom_Wecks?= =?ISO-8859-1?Q?tr=F6m?= Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L ocalized Mobility Management Requirement s) Date: Thu, 10 May 2001 10:35:40 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Jim, > > => To avoid multiple single point of failiures and keeping unnecessary > > state within the network. The solution is not so trivial IMO. > > There are several downfalls to consider. Robustness is only one, > > Security is another, network availability is another one. All that > > amounts to cost. > > > > Your argument above is that the implementation is too complex not that > the idea of hierarchy is not valid. I have heard this from Erik too. > From one implementor to the other I don't agree at all. I cannot see why > your or Erick do not want to permit the ability tomorrow to distributed > the problems at hand to LMMs in a hierarchy. > => First of all it's not just me an Erik. Others can speak for themelves of course, but several people have expressed similar opinions. The discussion is not limited to the "today" time frame in any way. In fact the discussion has been quite abstract, conceptual and constructive. Just some background here, we have another draft that just went through a WG last call (RegRegv4) and it does the exact same thing. This requirement never came up. So since it just came up suddenly I think it is important to understand whether: - There is anything specific to be considered for v6 - If the need is justified. > I "think" what your saying > is that this working group should support forcing forever that the network > principles of hierarchy cannot be used for Mobile IP. > => We can't control "forever", we can only design a protocol as we think it will be deployed. And to reiterate, the current protocol is extremely simple that I find it very hard to see how it can't be extended in future should the need arise. Of course the same can be done now, multi-level hierarchy can be optimised (it is already supported), but again every requirement must be justified. > Will it cost more is a good and important question. Yes it will. And one > of our jobs as engineers is keep cost in mind with any solution (a > practice that is not followed widely in our community of late) and if the > only solution a hierarchial approach could implement was multiple levels > of hiearchy then I would agree. But 1 level can be implemented which is > no hiearchy and that is the least cost. But if a vendor and user want to > spend more money and use the principles of LMM with hierarchy then they > would not be able to with your view. > > To understand your view better are you and Erik (Erik can speak for > himself of course) saying that you want to prohibit LMM hierarchy forever > for Mobile IP LMMs. > => I don't think anyone can be so sure about "forever", I'm certainly not. But we can't just put everything we can think of "just in case". This can also make the design unusable and unrealistic. Regards, Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu May 10 04:58:40 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21198 for ; Thu, 10 May 2001 04:58:39 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA24853; Thu, 10 May 2001 01:58:34 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA27873; Thu, 10 May 2001 01:58:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4A8u5d18588 for mobile-ip-dist; Thu, 10 May 2001 01:56:05 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4A8tu418581 for ; Thu, 10 May 2001 01:55:56 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA03324 for ; Thu, 10 May 2001 01:55:56 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA16473 for ; Thu, 10 May 2001 02:55:59 -0600 (MDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f4A8trN06518 for ; Thu, 10 May 2001 10:55:53 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu May 10 10:55:42 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 10 May 2001 10:50:58 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBE21@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised Localized Mobility Management Requirement s) Date: Thu, 10 May 2001 10:55:50 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Charlie, > > => The argument thus far has been whether there is any significant > > improvement (in delays) that could outweigh the introduced > > complexity within the network. So far I haven't seen an argument > > to prove that there is such _significant_benefit. > > There is obviously some benefit. Any time you can put fewer > processing nodes in the middle of the signaling path, you will > get improved performance, surely at least by having less jitter. > I am worried that mistakes at this basic level will have ramifications > for future handling of video/multimedia streams, and various other > QoS (especially delay-oriented) reservations. > => There is one benefit (point 1 in Erik's mail) in certain cases and there are some obvious disadvantages. The point is whether this one benefit outweighs the disadvantages. Also Gopal sent a nice summary that related to your point above about signalling reduction. Processing a signal in more than one level will in fact add more delays. Unless forwarding a packet somehow takes longer than procssing it, but that's clearly not true. > Plus it seems to stand out as the right thing to do. > => Well .... "stand out" is in the eye of the beholder :) It was never a requirement for v4. There is nothing different here. > Whether the > performance gain is significant probably depends on the particular > network architecture. As has been noted, restricting the number > of levels introduces a new requirement to figure out how high or > low to place the LMM agents. > => You need to do that anyway. We can't short circuit network engineering. If you have multi-level LMMs you need to know where to put each level to minimise the amount of times a BU is processed on multiple levels, which would in fact make a multi-level LMM scenario slower than a single one. > > > ---- Backbone/Core Network/IP RAN at least, > > > > > => I don't know if there are any RAN standards > > that require this. However, if in future open RANs > > are standardised then the argument is the same > > whether a network is a RAN or not. > > It is very likely that we'll eventually have open RAN. > To me, it's clear that a RAN should be a collection of > IP routable networks. Do you say otherwise? > => No, but the discussion so far hasn't distinguished between open or closed RANs. We're discussing the concept regardless of the architecture of what kind of network it's in. What makes an open RAN so different that it requires this ? In fact for an open RAN the delays over the air are so high that no significant gain is perceived in reducing the forwarding delays over the wire. Have I missed something ? > If your argument is that we don't have IP RAN, so we > don't need leveled LMMs, then I believe that is a very > short-sighted argument. > => No that was not my argument. I don't see how open RANs are so special. In fact if anything it is a living proof of my argument that delays on the wire are insignificant. > > > But why should we have to botch the > > > obvious network architecture in order to support something only marginally > > > easier (if at all!) to implement > > > > > => To avoid multiple single point of failiures and keeping unnecessary > > state within the network. The solution is not so trivial IMO. > > There are several downfalls to consider. Robustness is only one, > > Security is another, network availability is another one. All that > > amounts to cost. > > First, we should get the LMM agent architecture right. Security will > not add any particular penalty here. Network availability and robustness > are the same in this context. > > => Well it is clear (at least to me) that once we start looking at the solution on a lower level of detail (not even implementation but simply protocol design) we will see that it _is_ very complex. Robustness will certainly become an issue. > That requirement can be met by some > protocol that resolves node failures (a routing protocol). Whether > it's a modification to OSPF, or a manet, or something in-between, > is a problem we can solve in due time. > => This also implies that just to get LMM right we need a few more protocols to make it work. And I do foresee that also if this requirement is placed. Hence, the need to have some very concrete justifications. Regards, Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu May 10 09:10:23 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25194 for ; Thu, 10 May 2001 09:10:22 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA02991; Thu, 10 May 2001 06:09:59 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA06949; Thu, 10 May 2001 06:09:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4AD84W18797 for mobile-ip-dist; Thu, 10 May 2001 06:08:04 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4AD7u418790 for ; Thu, 10 May 2001 06:07:56 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id GAA23189; Thu, 10 May 2001 06:07:56 -0700 (PDT) Message-Id: <200105101307.GAA23189@heliopolis.eng.sun.com> Date: Thu, 10 May 2001 06:07:56 -0700 (PDT) From: James Kempf Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L ocalized Mobility Management Requirement s) To: mobile-ip@sunroof.eng.sun.com, Erik.Nordmark@eng.sun.com Cc: tweckstr@cc.hut.fi MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: rNS7nRnQf2EByyzfhQAgkQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > => No of course not, I said multiple single points of failure. > You can make one redundant for a cost, you can make three > redundant for a much higher cost. > So the goal is obviously to minimise the number of single points > of failure. More clearly one is better than two and two is better > than 3. > Maybe I'm missing something but I still don't see the difference. What is the difference between multiple single points of failure and multiple points of failure? As for cost, it is true that redundency comes at a cost, but that is a network engineering issue. If a deployment wants to pay the cost, it is up to them. If they don't, then they don't. But if the design does not have redundency in it, then even if a network operator wants to have redundency, they can't, no matter how much they pay. jak From owner-mobile-ip@sunroof.eng.sun.com Thu May 10 09:21:40 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25633 for ; Thu, 10 May 2001 09:21:38 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA07724; Thu, 10 May 2001 06:21:25 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA16121; Thu, 10 May 2001 06:21:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4ADJHT18827 for mobile-ip-dist; Thu, 10 May 2001 06:19:17 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4ADJ8418820 for ; Thu, 10 May 2001 06:19:09 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA07896 for ; Thu, 10 May 2001 06:19:09 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id GAA03950 for ; Thu, 10 May 2001 06:19:07 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA06051; Thu, 10 May 2001 09:19:08 -0400 Date: Thu, 10 May 2001 09:19:08 -0400 (EDT) From: Jim Bound To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L ocalized Mobility Management Requirement s) In-Reply-To: <034BEFD03799D411A59F00508BDF7546013DBE1F@esealnt448.al.sw.ericsson.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Hesham, > Hi Jim, > > > > => To avoid multiple single point of failiures and keeping unnecessary > > > state within the network. The solution is not so trivial IMO. > > > There are several downfalls to consider. Robustness is only one, > > > Security is another, network availability is another one. All that > > > amounts to cost. > > > > > > > Your argument above is that the implementation is too complex not that > > the idea of hierarchy is not valid. I have heard this from Erik too. > > From one implementor to the other I don't agree at all. I cannot see why > > your or Erick do not want to permit the ability tomorrow to distributed > > the problems at hand to LMMs in a hierarchy. > > > => First of all it's not just me an Erik. Others can speak for > themelves of course, but several people have expressed > similar opinions. The discussion is not limited to the > "today" time frame in any way. In fact the discussion has > been quite abstract, conceptual and constructive. I agree sorry about just saying you and Erik but I know you guys best. This is definitely constructive I think. > Just some background here, we have another draft that > just went through a WG last call (RegRegv4) and it does > the exact same thing. This requirement never came up. > So since it just came up suddenly I think it is important > to understand whether: > > - There is anything specific to be considered for v6 Not specific. But generally all protocol work in the IETF need to be aware of the scoping of IPv6 addresses in the sense will they affect protocol operation. Also a new IPv4 protocol that can think transition to IPv6 for deployment would be wise and not do anything to hinder that eventuality but at the same time not negatively impact the performance of the IPv4 stack would be wonderful or a router code base for fast path. > - If the need is justified. Always an axiom IMO. > > > I "think" what your saying > > is that this working group should support forcing forever that the network > > principles of hierarchy cannot be used for Mobile IP. > > > => We can't control "forever", we can only design a protocol > as we think it will be deployed. And to reiterate, the current > protocol is extremely simple that I find it very hard to > see how it can't be extended in future should the need arise. > Of course the same can be done now, multi-level hierarchy > can be optimised (it is already supported), but again > every requirement must be justified. That is a fair response. If a first iteration of a spec does not prevent evolution to other models thats a good spec. The issue is then if people want it now. > > Will it cost more is a good and important question. Yes it will. And one > > of our jobs as engineers is keep cost in mind with any solution (a > > practice that is not followed widely in our community of late) and if the > > only solution a hierarchial approach could implement was multiple levels > > of hiearchy then I would agree. But 1 level can be implemented which is > > no hiearchy and that is the least cost. But if a vendor and user want to > > spend more money and use the principles of LMM with hierarchy then they > > would not be able to with your view. > > > > To understand your view better are you and Erik (Erik can speak for > > himself of course) saying that you want to prohibit LMM hierarchy forever > > for Mobile IP LMMs. > > > => I don't think anyone can be so sure about "forever", I'm certainly > not. But we can't just put everything we can think of "just in case". > This can also make the design unusable and unrealistic. > I understand and not advocating the kitchen sink approach as that is really bad design. But as you I have real MIPv4 deployment going on with real customers (3GGP2 and IMT-2000) and just the other day I saw a customer scenario where multiple LMM levels of hiearchy could apply and would reduce the signal delay at a local level. They don't know about LMM abstraction but they do want to reduce the scalability problems locally at a cell remote from the Packet Data Switching Node (PDSN) and not duplicate the entire PDSN when roaming under the same domain of RAN administration. regards, /jim From owner-mobile-ip@sunroof.eng.sun.com Thu May 10 10:48:58 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29235 for ; Thu, 10 May 2001 10:48:54 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA12718; Thu, 10 May 2001 07:48:41 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA20864; Thu, 10 May 2001 07:48:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4AEktV18892 for mobile-ip-dist; Thu, 10 May 2001 07:46:55 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4AEkk418885 for ; Thu, 10 May 2001 07:46:46 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA20591 for ; Thu, 10 May 2001 07:46:46 -0700 (PDT) Received: from zrc2s03g.us.nortel.com ([47.103.122.66]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA21053 for ; Thu, 10 May 2001 08:46:49 -0600 (MDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id JAA11201 for ; Thu, 10 May 2001 09:47:26 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Thu, 10 May 2001 09:40:43 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 May 2001 09:46:07 -0500 Message-ID: From: "Haseeb Akhtar" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] RE: Multiple flows with single NAI Date: Thu, 10 May 2001 09:46:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D95F.F34ACCE0" X-Orig: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C0D95F.F34ACCE0 Content-Type: text/plain; charset="iso-8859-1" > > > -----Original Message----- > > From: Madhavi Subbarao [mailto:msubbara@cisco.com] > > Sent: Wednesday, May 09, 2001 4:48 PM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: [mobile-ip] Re: mobile-ip] Re: mobile-ip] Multiple > flows with > > single NAI > > > > > > True...every IP packet does not have an NAI. However, the HA can > > distinguish between different MN bindings using the tuple > > (NAI, IP address). The draft we propose outlines the > behavior for NAI > > and multiple STATIC IP addresses...(NAI, IP address) is used as the > > 'identifier' at the HA. There is no need for the HA to multicast or > > sniff. We are thinking of the NAI as an identifier for the USER > > behind the device...if that makes sense. It's analogous to what you > > describe below as a 'subscription id', so I think we are on the same > > page. > > Agreed. The solution, however, needs to account for the user's preference of the devices. For example, if the user has turned on both device A (a laptop) and device B (a pager), the user should be able to dictate whether the data would flow to, a. both devices b. only to device A c. only to device B The HA needs to add the preference to the tuple (NAI, IP address of device, preference) that would decide the number of destination address (COAs) the data packet needs to be forwarded. > > Since NAI identifies and authenticates the USER, it shouldn't matter > > which device the USER is coming in on. Moreover, the USER shouldn't > > be constrained to use only a single device. > > > > -Madhavi > > I can see from the email (also the title of the draft) that > you did put > emphasis on STATIC IP addresses. Any reason why Dynamic IP > addresses were > not considered. I think that is also one of the possible case > to be looked > upon. As I think this model will fail if Dynamic addresses > are considered. > Or for it to work there is additional work needed at Mobile > station, FA and > HA. > > - Sharma The use of dynamic IP address would be transparent to the HA. That is, there is no difference between using static or dynamic address. > Haseeb ------_=_NextPart_001_01C0D95F.F34ACCE0 Content-Type: text/html; charset="iso-8859-1" RE: Multiple flows with single NAI

>
> > -----Original Message-----
> > From: Madhavi Subbarao [mailto:msubbara@cisco.com]
> > Sent: Wednesday, May 09, 2001 4:48 PM
> > To: mobile-ip@sunroof.eng.sun.com
> > Subject: [mobile-ip] Re: mobile-ip] Re: mobile-ip] Multiple
> flows with
> > single NAI
> >
> >
> > True...every IP packet does not have an NAI.  However, the HA can
> > distinguish between different MN bindings using the tuple
> > (NAI, IP address).  The draft we propose outlines the
> behavior for NAI
> > and multiple STATIC IP addresses...(NAI, IP address) is used as the
> > 'identifier' at the HA.  There is no need for the HA to multicast or
> > sniff.  We are thinking of the NAI as an identifier for the USER
> > behind the device...if that makes sense.  It's analogous to what you
> > describe below as a 'subscription id', so I think we are on the same
> > page.
> >
Agreed.

The solution, however, needs to account for the user's preference of the
devices. For example, if the user has turned on both device A (a laptop) and
device B (a pager), the user should be able to dictate whether the data
would flow to,
 a. both devices
 b. only to device A
 c. only to device B

The HA needs to add the preference to the tuple (NAI, IP address of device,
preference) that would decide the number of destination address (COAs) the
data packet needs to be forwarded.

> > Since NAI identifies and authenticates the USER, it shouldn't matter
> > which device the USER is coming in on.  Moreover, the USER shouldn't
> > be constrained to use only a single device.
> >
> > -Madhavi
>
> I can see from the email (also the title of the draft) that
> you did put
> emphasis on STATIC IP addresses. Any reason why Dynamic IP
> addresses were
> not considered. I think that is also one of the possible case
> to be looked
> upon. As I think this model will fail if Dynamic addresses
> are considered.
> Or for it to work there is additional work needed at Mobile
> station, FA and
> HA.
>
> - Sharma

The use of dynamic IP address would be transparent to the HA. That is,
there is no difference between using static or dynamic address.
>

Haseeb

------_=_NextPart_001_01C0D95F.F34ACCE0-- From owner-mobile-ip@sunroof.eng.sun.com Thu May 10 12:03:07 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01473 for ; Thu, 10 May 2001 12:03:02 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA27478; Thu, 10 May 2001 09:02:34 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA07263; Thu, 10 May 2001 09:02:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4AG0lL19055 for mobile-ip-dist; Thu, 10 May 2001 09:00:47 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4AG0d419048 for ; Thu, 10 May 2001 09:00:39 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA06747 for ; Thu, 10 May 2001 09:00:38 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25196 for ; Thu, 10 May 2001 09:00:37 -0700 (PDT) Received: from msubbara-u10.cisco.com (msubbara-u10.cisco.com [64.102.66.20]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f4AG0Zd04585 for ; Thu, 10 May 2001 09:00:36 -0700 (PDT) Received: (msubbara@localhost) by msubbara-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA25150 for mobile-ip@sunroof.eng.sun.com; Thu, 10 May 2001 12:00:02 -0400 (EDT) Date: Thu, 10 May 2001 12:00:02 -0400 From: Madhavi Subbarao To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: mobile-ip] Re: mobile-ip] Re: mobile-ip] Multiple flows with single NAI Message-ID: <20010510120002.A25146@cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from msharma@megisto.com on Wed, May 09, 2001 at 06:37:17PM -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Sharma, On Wed, May 09, 2001 at 06:37:17PM -0400, Mukesh Sharma wrote: > Hi Madhavi, > > > -----Original Message----- > > From: Madhavi Subbarao [mailto:msubbara@cisco.com] > > Sent: Wednesday, May 09, 2001 4:48 PM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: [mobile-ip] Re: mobile-ip] Re: mobile-ip] Multiple flows with > > single NAI > > > > > > True...every IP packet does not have an NAI. However, the HA can > > distinguish between different MN bindings using the tuple > > (NAI, IP address). The draft we propose outlines the behavior for NAI > > and multiple STATIC IP addresses...(NAI, IP address) is used as the > > 'identifier' at the HA. There is no need for the HA to multicast or > > sniff. We are thinking of the NAI as an identifier for the USER > > behind the device...if that makes sense. It's analogous to what you > > describe below as a 'subscription id', so I think we are on the same > > page. > > > > Since NAI identifies and authenticates the USER, it shouldn't matter > > which device the USER is coming in on. Moreover, the USER shouldn't > > be constrained to use only a single device. > > > > -Madhavi > > I can see from the email (also the title of the draft) that you did put > emphasis on STATIC IP addresses. Any reason why Dynamic IP addresses were > not considered. I think that is also one of the possible case to be looked > upon. As I think this model will fail if Dynamic addresses are considered. > Or for it to work there is additional work needed at Mobile station, FA and > HA. Yes, this draft is specific to Static IP addresses. We will be submitting another draft detailing the behavior for Dynamic IP address allocation with a single NAI. At first glance, it might seem similar, but infact there are other issues. Another level of abstraction is needed to distinguish between different MIP 'flows'. For example, if a USER is registering on two different devices, the RRQ's would look the same... (NAI, 0.0.0.0 as the home address). But, when introducing another level of identification, additional measures need to be taken to ensure no security hole is being introduced. Thanks, Madhavi > - Sharma From owner-mobile-ip@sunroof.eng.sun.com Thu May 10 12:22:55 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02092 for ; Thu, 10 May 2001 12:22:53 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA25771; Thu, 10 May 2001 09:20:36 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA20192; Thu, 10 May 2001 09:17:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4AGFGS19121 for mobile-ip-dist; Thu, 10 May 2001 09:15:16 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4AGF8419114 for ; Thu, 10 May 2001 09:15:08 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA09682 for ; Thu, 10 May 2001 09:15:07 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA18156 for ; Thu, 10 May 2001 10:15:10 -0600 (MDT) Received: from msubbara-u10.cisco.com (msubbara-u10.cisco.com [64.102.66.20]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f4AGF5926254 for ; Thu, 10 May 2001 09:15:05 -0700 (PDT) Received: (msubbara@localhost) by msubbara-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA25164 for mobile-ip@sunroof.eng.sun.com; Thu, 10 May 2001 12:14:30 -0400 (EDT) Date: Thu, 10 May 2001 12:14:30 -0400 From: Madhavi Subbarao To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: mobile-ip] RE: Multiple flows with single NAI Message-ID: <20010510121430.B25146@cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from haseeb@nortelnetworks.com on Thu, May 10, 2001 at 09:46:09AM -0500 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Haseeb, On Thu, May 10, 2001 at 09:46:09AM -0500, Haseeb Akhtar wrote: > > > > > -----Original Message----- > > > From: Madhavi Subbarao [mailto:msubbara@cisco.com] > > > Sent: Wednesday, May 09, 2001 4:48 PM > > > To: mobile-ip@sunroof.eng.sun.com > > > Subject: [mobile-ip] Re: mobile-ip] Re: mobile-ip] Multiple > > flows with > > > single NAI > > > > > > > > > True...every IP packet does not have an NAI. However, the HA can > > > distinguish between different MN bindings using the tuple > > > (NAI, IP address). The draft we propose outlines the > > behavior for NAI > > > and multiple STATIC IP addresses...(NAI, IP address) is used as the > > > 'identifier' at the HA. There is no need for the HA to multicast or > > > sniff. We are thinking of the NAI as an identifier for the USER > > > behind the device...if that makes sense. It's analogous to what you > > > describe below as a 'subscription id', so I think we are on the same > > > page. > > > > Agreed. Great...so we are in sync. > The solution, however, needs to account for the user's preference of the > devices. For example, if the user has turned on both device A (a laptop) and > device B (a pager), the user should be able to dictate whether the data > would flow to, > a. both devices > b. only to device A > c. only to device B > > The HA needs to add the preference to the tuple (NAI, IP address of device, > preference) that would decide the number of destination address (COAs) the > data packet needs to be forwarded. Interesting idea. I was envisioning each (NAI, IP address) pair as a separate 'flow' and thus, data would only be sent to that device. We weren't introducing anything new to the standard, just clarification of behavior of the different entities. Haseeb, have a look at our draft and let me know what you had in mind for incorporating the preference model. It seems to me that to support this, more than a bit flag would be needed...say you have another device C, then more permutations are introduced. So, we'll have to see the tradeoff between value and complexity. > > > Since NAI identifies and authenticates the USER, it shouldn't matter > > > which device the USER is coming in on. Moreover, the USER shouldn't > > > be constrained to use only a single device. > > > > > > -Madhavi > > > > I can see from the email (also the title of the draft) that > > you did put > > emphasis on STATIC IP addresses. Any reason why Dynamic IP > > addresses were > > not considered. I think that is also one of the possible case > > to be looked > > upon. As I think this model will fail if Dynamic addresses > > are considered. > > Or for it to work there is additional work needed at Mobile > > station, FA and > > HA. > > > > - Sharma > > The use of dynamic IP address would be transparent to the HA. That is, > there is no difference between using static or dynamic address. Actually, there is a difference. Please see my response to Sharma on this thread. Thanks, Madhavi > > Haseeb From owner-mobile-ip@sunroof.eng.sun.com Thu May 10 13:29:29 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04360 for ; Thu, 10 May 2001 13:29:28 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA26043; Thu, 10 May 2001 10:29:13 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA08155; Thu, 10 May 2001 10:28:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4AHR5319221 for mobile-ip-dist; Thu, 10 May 2001 10:27:05 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4AHQu419214 for ; Thu, 10 May 2001 10:26:57 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA27143 for ; Thu, 10 May 2001 10:26:55 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23499 for ; Thu, 10 May 2001 10:26:53 -0700 (PDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 May 2001 13:20:29 -0400 Message-ID: From: Mukesh Sharma To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: mobile-ip] Re: mobile-ip] Re: mobile-ip] Mult iple flows with single NAI Date: Thu, 10 May 2001 13:20:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > -----Original Message----- > From: Madhavi Subbarao [mailto:msubbara@cisco.com] > Sent: Thursday, May 10, 2001 12:00 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] Re: mobile-ip] Re: mobile-ip] Re: mobile-ip] > Multiple flows with single NAI > > Yes, this draft is specific to Static IP addresses. We will be > submitting another draft detailing the behavior for Dynamic IP address > allocation with a single NAI. At first glance, it might seem > similar, but > infact there are other issues. Another level of abstraction is needed > to distinguish between different MIP 'flows'. For example, if a USER > is registering on two different devices, the RRQ's would look > the same... > (NAI, 0.0.0.0 as the home address). But, when introducing > another level of identification, additional measures need to be taken > to ensure no security hole is being introduced. > > Thanks, > Madhavi > That was the point I was making, need another level of abstraction for it to work at all the levels including the FA and HA. Plus at FA, how will FA know that if Mobile station is sending multiple requests or just retrying. Sharma From owner-mobile-ip@sunroof.eng.sun.com Thu May 10 13:49:34 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04829 for ; Thu, 10 May 2001 13:49:33 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14791; Thu, 10 May 2001 10:49:10 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09273; Thu, 10 May 2001 08:45:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4AFgpv18989 for mobile-ip-dist; Thu, 10 May 2001 08:42:51 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4AFgg418982 for ; Thu, 10 May 2001 08:42:42 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08843 for ; Thu, 10 May 2001 08:42:42 -0700 (PDT) Received: from idcpa4.pa.interdigital.com ([12.32.197.142]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA07067 for ; Thu, 10 May 2001 08:42:40 -0700 (PDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 May 2001 11:41:45 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Incorporating NAT-boxes into MIPv4 Date: Thu, 10 May 2001 11:41:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D967.B3A97520" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C0D967.B3A97520 Content-Type: text/plain; charset="iso-8859-1" I was wondering if anyone was working on incorporating NAT-boxes into MIPv4? I would be grateful if you can get in contact. -Sharif ------_=_NextPart_001_01C0D967.B3A97520 Content-Type: text/html; charset="iso-8859-1"
I was wondering if anyone was working on incorporating NAT-boxes into MIPv4? I would be grateful if you can get in contact.
 
-Sharif
------_=_NextPart_001_01C0D967.B3A97520-- From owner-mobile-ip@sunroof.eng.sun.com Thu May 10 16:13:04 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07506 for ; Thu, 10 May 2001 16:13:03 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA21752; Thu, 10 May 2001 13:12:48 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA14263; Thu, 10 May 2001 13:12:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4AK7v219641 for mobile-ip-dist; Thu, 10 May 2001 13:07:57 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4AK7k419634 for ; Thu, 10 May 2001 13:07:48 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA12971; Thu, 10 May 2001 13:07:44 -0700 (PDT) Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA12295; Thu, 10 May 2001 13:07:41 -0700 (PDT) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id PAA23022; Thu, 10 May 2001 15:07:08 -0500 (CDT) Received: from alhambra.aud.alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f4AK77T13623; Thu, 10 May 2001 15:07:07 -0500 (CDT) Message-ID: <001901c0d98f$8797d800$1062fb80@aud.alcatel.com> From: "Vinod Kumar Choyi" To: , "Erik Nordmark" Cc: , =?iso-8859-1?Q?Tom_Weckstr=F6m?= References: <3AF9A8CB.8F7B92A5@iprg.nokia.com> Subject: Re: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L ocalized Mobility Management Requirement s) Date: Thu, 10 May 2001 15:26:43 -0500 Organization: Alcatel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by patan.sun.com id NAA21752 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA07506 Hello charles, comments below ----- Original Message ----- From: Charles E. Perkins To: Erik Nordmark Cc: ; Tom Weckström Sent: Wednesday, May 09, 2001 3:30 PM Subject: Re: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L ocalized Mobility Management Requirement s) > Hello Erik, > > > The highest FA could be fully utilized for multiple reasons: > > 1. running out of processing power to handle the rate of binding updates > > 2. running out of memory to store the state for the bindings > > 3. running out of bandwidth on its network interfaces for all > > the traffic to (and from?) the MNs > > > > If you add a hierarchy of LMMs below this box and have the box continue to > > serve the same number of MNs you can improve #1 but it doesn't change > > #2 or #3. > > If you instead of a hierarchy add N equal LMM agents at the top level > > (e.g., with each MN in the domain randomly selecting which LMM agent to use) > > then you can address scaling along all of the above axis. > > > > So it all depends along what axis you think the agent will max out first. > > I think the main reasons for intermediate levels are: > > - Shorter signaling paths -- fewer chances for congestion and delays, > fewer nodes to process the control messages, and (O.K. maybe not huge) > better average performance -- but probably more consistent performance Agreed, shorter signaling paths and therefore some advantage, but data packets adrressed to MN have to be encapsulated and decapsulated or by some other means from one higher LMM agent to a lower LMM agent and so on (depending upon how many levels). The delay that occurs at LMM agents for this forwarding from one agent to another could be large depending upon the levels again. > > - Natural fit to hierarchical network architectures > ---- Backbone/Core Network/IP RAN at least, and possibly in some > situations one (or rarely two) more levels of hierarchy. > > Besides that, since the multi-level hierarchy doesn't have to be so much > more complicated anyway, I don't understand why you are arguing against it. > It seems like an obvious improvement. I read most of the arguments supporting > the single-level structure to be "Well, we don't really need that improvement" > or "Well, we can program around that". But why should we have to botch the > obvious network architecture in order to support something only marginally > easier (if at all!) to implement, and get lower performance as a reward? > > Regards, > Charlie P. We should not be debating about the levels of hierarchy IMO instead focus more on the INTERACTION and signalling between LMM agents. regards vinod From owner-mobile-ip@sunroof.eng.sun.com Thu May 10 17:14:44 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA08447 for ; Thu, 10 May 2001 17:14:43 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA12755; Thu, 10 May 2001 14:14:32 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA24555; Thu, 10 May 2001 14:13:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4ALBtO19954 for mobile-ip-dist; Thu, 10 May 2001 14:11:55 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4ALBk419947 for ; Thu, 10 May 2001 14:11:46 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA28844 for ; Thu, 10 May 2001 14:11:37 -0700 (PDT) Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA10530 for ; Thu, 10 May 2001 14:11:28 -0700 (PDT) Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id RAA24446; Thu, 10 May 2001 17:11:23 -0400 Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 10 May 2001 17:11:07 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 May 2001 17:11:09 -0400 Message-ID: From: "Muhammad Jaseemuddin" To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] CFP: SPECIAL SESSION ON RESOURCE MANAGEMENT FOR WIRELESS MULTIMED IA Date: Thu, 10 May 2001 17:11:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D995.BC0F07B0" X-Orig: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C0D995.BC0F07B0 Content-Type: text/plain SPECIAL SESSION ON RESOURCE MANAGEMENT FOR WIRELESS MULTIMEDIA IFIP/IEEE International Conference on Management of Multimedia Networks and Services (IFIP/IEEE MMNS2001) October 29- November 1, 2001, Chicago, Illinois, USA http://www.mnlab.cs.depaul.edu/mmns2001 Broadband wireless multimedia services are becoming very popular. This special session will focus on architectures and techniques for supporting QoS in future wireless multimedia networks. The session is looking for original contributions in this demanding area that address issues related to both networking and wireless systems. This includes integration of personal wireless multimedia into the Internet, efficient resource management techniques in wireless access netowrks that consider internet QoS models, the limited resources in wireless systems, such as spectrum resource and transmitter power, mobility management, bandwidth allocation, location and handoff procedures, channel access and assignment, call admission control, and end-to-end adaptive control for wireless multimedia. You can submit papers on-line using the keyword SPECIAL SESSION ON RESOURCE MANAGEMENT FOR WIRELESS MULTIMEDIA either to the conference website or to jaseem@nortelnetworks.com. The deadline for paper submission for this special session is May 31, 2001. For questions about this special session, please contact: Muhammad Jaseemuddin Nortel Networks P.O. Box 3511 Station C Ottawa, ON K1Y 4H7 Canada Tel: +1 613 765-7520 Email: jaseem@nortelnetworks.com ------_=_NextPart_001_01C0D995.BC0F07B0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable CFP: SPECIAL SESSION ON RESOURCE MANAGEMENT FOR WIRELESS = MULTIMEDIA

SPECIAL SESSION ON RESOURCE = MANAGEMENT FOR WIRELESS MULTIMEDIA
IFIP/IEEE International = Conference on Management of Multimedia Networks and Services (IFIP/IEEE = MMNS2001)
October 29- November 1, 2001, = Chicago, Illinois, USA
http://www.mnlab.cs.depaul.edu/mmns2001=

Broadband wireless multimedia = services are becoming very popular. This special session will focus on = architectures and techniques for supporting QoS in future wireless = multimedia networks. The session is looking for original contributions = in this demanding area that address issues related to both networking = and wireless systems. This includes integration of personal wireless = multimedia into the Internet, efficient resource management techniques = in wireless access netowrks that consider internet QoS models, the = limited resources in wireless systems, such as spectrum resource and = transmitter power, mobility management, bandwidth allocation, location = and handoff procedures, channel access and assignment, call admission = control, and end-to-end adaptive control for wireless multimedia. =

You can submit papers on-line = using the keyword SPECIAL SESSION ON RESOURCE MANAGEMENT FOR WIRELESS = MULTIMEDIA either to the conference website or to = jaseem@nortelnetworks.com. The deadline for paper submission for this = special session is May 31, 2001. For questions  about this special = session, please contact:

Muhammad Jaseemuddin
Nortel Networks
P.O. Box 3511 Station C
Ottawa, ON K1Y 4H7
Canada
Tel: +1 613 765-7520
Email: = jaseem@nortelnetworks.com

------_=_NextPart_001_01C0D995.BC0F07B0-- From owner-mobile-ip@sunroof.eng.sun.com Thu May 10 17:37:26 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA08670 for ; Thu, 10 May 2001 17:37:25 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA00171; Thu, 10 May 2001 14:37:11 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA04516; Thu, 10 May 2001 14:34:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4ALWiZ20048 for mobile-ip-dist; Thu, 10 May 2001 14:32:44 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4ALWa420041 for ; Thu, 10 May 2001 14:32:36 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA04088 for ; Thu, 10 May 2001 14:32:36 -0700 (PDT) Received: from web14206.mail.yahoo.com (web14206.mail.yahoo.com [216.136.173.70]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA03722 for ; Thu, 10 May 2001 14:32:36 -0700 (PDT) Message-ID: <20010510213235.29927.qmail@web14206.mail.yahoo.com> Received: from [47.82.25.189] by web14206.mail.yahoo.com; Thu, 10 May 2001 14:32:35 PDT Date: Thu, 10 May 2001 14:32:35 -0700 (PDT) From: Praveen Muley Subject: Re: [mobile-ip] Requirements Draft for Mobile IP QoS - Invitation to Volunteer To: mobile-ip@sunroof.eng.sun.com In-Reply-To: <3AE7FE8C.7A911FA9@crm.mot.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Hemant, I would also like to volunteer for it. Would like have more information. Looking forward to hear from you. Thanks, Praveen Nortel Networks ( IP services division) --- Christophe Janneteau wrote: > Hi Hemant, > > Could you please add me to the list. > > Thanks, > Christophe Janneteau. > Motorola Labs- Paris > > Hemant Chaskar wrote: > > > > Hi all: > > > > I have been asked by the Mobile IP WG chairs to > serve as an editor for the > > QoS requirements draft that the WG intends to > create. The solution space for > > these requirements may be discussed by the > to-be-born NSIS WG. Please let me > > know if anyone would be interested in working on > this draft with me. Thanks. > > > > Hemant Chaskar > > Nokia > > > > >From: Phil Roberts Reply-To: > mobile-ip@sunroof.eng.sun.com To: > > >"'mobile-ip@sunroof.eng.sun.com'" Subject: > [mobile-ip] QoS work item Date: > > >Tue, 3 Apr 2001 10:38:39 -0400 > > > > > >Based on the discussion we had earlier and that > it seems fairly definite > > >that a new working group will be formed to > address mobile QoS (among other > > >things) it seems that our task now is to produce > a requirements draft that > > >will be input to this working group, something > akin to what we did for AAA. > > >We'll be setting up a mailing list and letting > folks know about it in a > > >couple of days. > > > > > >From the outset I want to emphasize that our goal > will be to produce a set > > >of requirements and NOT to stray into the > solution space. Solutions can be > > >discussed in this soon to be formed working > group. > > > > > >Phil > > > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at http://explorer.msn.com __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ From owner-mobile-ip@sunroof.eng.sun.com Thu May 10 17:59:38 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA08976 for ; Thu, 10 May 2001 17:59:37 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16741; Thu, 10 May 2001 14:59:30 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA05241; Thu, 10 May 2001 14:59:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4ALvQY20131 for mobile-ip-dist; Thu, 10 May 2001 14:57:26 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4ALvG420124 for ; Thu, 10 May 2001 14:57:16 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA10848 for ; Thu, 10 May 2001 14:57:16 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02100 for ; Thu, 10 May 2001 14:57:16 -0700 (PDT) Received: from msubbara-u10.cisco.com (msubbara-u10.cisco.com [64.102.66.20]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f4ALvEd25289 for ; Thu, 10 May 2001 14:57:14 -0700 (PDT) Received: (msubbara@localhost) by msubbara-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA25624 for mobile-ip@sunroof.eng.sun.com; Thu, 10 May 2001 17:56:40 -0400 (EDT) Date: Thu, 10 May 2001 17:56:40 -0400 From: Madhavi Subbarao To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: mobile-ip] Re: mobile-ip] Re: mobile-ip] Re: mobile-ip] Mult iple flows with single NAI Message-ID: <20010510175640.A25620@cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from msharma@megisto.com on Thu, May 10, 2001 at 01:20:29PM -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Sharma, On Thu, May 10, 2001 at 01:20:29PM -0400, Mukesh Sharma wrote: > > > -----Original Message----- > > From: Madhavi Subbarao [mailto:msubbara@cisco.com] > > Sent: Thursday, May 10, 2001 12:00 PM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: [mobile-ip] Re: mobile-ip] Re: mobile-ip] Re: mobile-ip] > > Multiple flows with single NAI > > > > Yes, this draft is specific to Static IP addresses. We will be > > submitting another draft detailing the behavior for Dynamic IP address > > allocation with a single NAI. At first glance, it might seem > > similar, but > > infact there are other issues. Another level of abstraction is needed > > to distinguish between different MIP 'flows'. For example, if a USER > > is registering on two different devices, the RRQ's would look > > the same... > > (NAI, 0.0.0.0 as the home address). But, when introducing > > another level of identification, additional measures need to be taken > > to ensure no security hole is being introduced. > > > > Thanks, > > Madhavi > > > > That was the point I was making, need another level of abstraction for it to > work at all the levels including the FA and HA. Plus at FA, how will FA know > that if Mobile station is sending multiple requests or just retrying. We were thinking along the lines of a Binding ID...an ID to identify the particular binding/flow using a single NAI. The FA and HA will then use the (NAI, Binding ID) as the identifier to distinguish the different bindings/flows. We've been debating on what form the Binding ID should take... - globally unique - can be used directly as the ClientID to a DHCP/DNS server...(but, how do you ensure uniqueness). - index - tied to NAI for interpretation (requires some sort of Binding ID management on the MN to know which indices have been used, etc.) - index-marker - again, tied to NAI for interpretation, but each device uses a particular index-marker, and the HA does a mapping of this index-marker and authorizes the Binding ID. Note that HA would still have to authorize the Binding ID because it's not possible to authenticate based on NAI and identify based on something else...opens up security holes. Then, ClientIDs would have to be some combination of the NAI and Binding ID. Thoughts? -Madhavi > Sharma From owner-mobile-ip@sunroof.eng.sun.com Thu May 10 18:27:23 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA09260 for ; Thu, 10 May 2001 18:27:23 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA15518; Thu, 10 May 2001 15:27:04 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA11603; Thu, 10 May 2001 15:26:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4AMOFS20173 for mobile-ip-dist; Thu, 10 May 2001 15:24:15 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4AMO6420166 for ; Thu, 10 May 2001 15:24:06 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA17690 for ; Thu, 10 May 2001 15:24:06 -0700 (PDT) Received: from zrc2s03g.us.nortel.com ([47.103.122.66]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA27902 for ; Thu, 10 May 2001 16:24:09 -0600 (MDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id RAA12975 for ; Thu, 10 May 2001 17:24:46 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Thu, 10 May 2001 17:11:02 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 May 2001 17:16:28 -0500 Message-ID: From: "Haseeb Akhtar" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Mult iple flows with single NAI Date: Thu, 10 May 2001 17:16:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D99E.DAFDCC20" X-Orig: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C0D99E.DAFDCC20 Content-Type: text/plain; charset="iso-8859-1" Hello, What is needed is an NAI extension of the device to be sent to the HA along with the user's NAI to be sent in the RRQ. The user's home address 0.0.0.0 can then easily be related with the particular device that the user is trying to use. The GNAIE (Generalized NAI Extension) format can be used to define the NAI of the device. Regards, Haseeb > -----Original Message----- > From: Mukesh Sharma [mailto:msharma@MEGISTO.com] > Sent: Thursday, May 10, 2001 12:20 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] Re: mobile-ip] Re: mobile-ip] Re: mobile-ip] > Mult iple flows with single NAI > > > > > -----Original Message----- > > From: Madhavi Subbarao [mailto:msubbara@cisco.com] > > Sent: Thursday, May 10, 2001 12:00 PM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: [mobile-ip] Re: mobile-ip] Re: mobile-ip] Re: mobile-ip] > > Multiple flows with single NAI > > > > Yes, this draft is specific to Static IP addresses. We will be > > submitting another draft detailing the behavior for Dynamic > IP address > > allocation with a single NAI. At first glance, it might seem > > similar, but > > infact there are other issues. Another level of > abstraction is needed > > to distinguish between different MIP 'flows'. For example, > if a USER > > is registering on two different devices, the RRQ's would look > > the same... > > (NAI, 0.0.0.0 as the home address). But, when introducing > > another level of identification, additional measures need > to be taken > > to ensure no security hole is being introduced. > > > > Thanks, > > Madhavi > > > > That was the point I was making, need another level of > abstraction for it to > work at all the levels including the FA and HA. Plus at FA, > how will FA know > that if Mobile station is sending multiple requests or just retrying. > > Sharma > ------_=_NextPart_001_01C0D99E.DAFDCC20 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Mult iple flows with single NAI

Hello,

What is needed is an NAI extension of the device to be sent
to the HA along with the user's NAI to be sent in the RRQ.

The user's home address 0.0.0.0 can then easily be related
with the particular device that the user is trying to use.

The GNAIE (Generalized NAI Extension) format can be used to
define the NAI of the device.

Regards,

Haseeb

> -----Original Message-----
> From: Mukesh Sharma [mailto:msharma@MEGISTO.com]
> Sent: Thursday, May 10, 2001 12:20 PM
> To: mobile-ip@sunroof.eng.sun.com
> Subject: RE: [mobile-ip] Re: mobile-ip] Re: mobile-ip] Re: mobile-ip]
> Mult iple flows with single NAI
>
>
>
> > -----Original Message-----
> > From: Madhavi Subbarao [mailto:msubbara@cisco.com]
> > Sent: Thursday, May 10, 2001 12:00 PM
> > To: mobile-ip@sunroof.eng.sun.com
> > Subject: [mobile-ip] Re: mobile-ip] Re: mobile-ip] Re: mobile-ip]
> > Multiple flows with single NAI
> >
> > Yes, this draft is specific to Static IP addresses.  We will be
> > submitting another draft detailing the behavior for Dynamic
> IP address
> > allocation with a single NAI.  At first glance, it might seem
> > similar, but
> > infact there are other issues.  Another level of
> abstraction is needed
> > to distinguish between different MIP 'flows'.  For example,
> if a USER
> > is registering on two different devices, the RRQ's would look
> > the same...
> > (NAI, 0.0.0.0 as the home address).  But, when introducing
> > another level of identification, additional measures need
> to be taken
> > to ensure no security hole is being introduced.
> >
> > Thanks,
> > Madhavi
> >
>
> That was the point I was making, need another level of
> abstraction for it to
> work at all the levels including the FA and HA. Plus at FA,
> how will FA know
> that if Mobile station is sending multiple requests or just retrying.
>
> Sharma
>

 

------_=_NextPart_001_01C0D99E.DAFDCC20-- From owner-mobile-ip@sunroof.eng.sun.com Thu May 10 18:35:15 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA09458 for ; Thu, 10 May 2001 18:35:14 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA18289; Thu, 10 May 2001 15:33:47 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA24176; Thu, 10 May 2001 15:33:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4AMVfA20217 for mobile-ip-dist; Thu, 10 May 2001 15:31:41 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4AMVW420210 for ; Thu, 10 May 2001 15:31:32 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA18918 for ; Thu, 10 May 2001 15:31:32 -0700 (PDT) Received: from zrc2s03g.us.nortel.com ([47.103.122.66]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA01150 for ; Thu, 10 May 2001 16:31:32 -0600 (MDT) Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id RAA14575 for ; Thu, 10 May 2001 17:32:09 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Thu, 10 May 2001 17:31:40 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 May 2001 17:31:13 -0500 Message-ID: From: "Haseeb Akhtar" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Multiple flows with single NAI Date: Thu, 10 May 2001 17:31:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D9A0.E9BD0E90" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C0D9A0.E9BD0E90 Content-Type: text/plain; charset="iso-8859-1" Madhavi, > We were thinking along the lines of a Binding ID...an ID to identify > the particular binding/flow using a single NAI. The FA and HA > will then use the (NAI, Binding ID) as the identifier to distinguish > the different bindings/flows. > > We've been debating on what form the Binding ID should take... > - globally unique - can be used directly as the ClientID to a DHCP/DNS > server...(but, how do you ensure uniqueness). > - index - tied to NAI for interpretation (requires some sort of > Binding ID management on the MN to know which indices have been used, > etc.) > - index-marker - again, tied to NAI for interpretation, but each > device uses a particular index-marker, and the HA does a mapping of > this index-marker and authorizes the Binding ID. Why does FA has to do anything different? The HA will have the tuple of (USER NAI, DEVICE NAI, IP Address, COA) to tunnel the data to the COA of the devices tied to that particular NAI. The FA will just de-tunnel and forward the packet to the device. > > -Madhavi > Haseeb > ------_=_NextPart_001_01C0D9A0.E9BD0E90 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Multiple flows with single NAI

Madhavi,

> We were thinking along the lines of a Binding ID...an ID to identify
> the particular binding/flow using a single NAI.  The FA and HA
> will then use the (NAI, Binding ID) as the identifier to distinguish
> the different bindings/flows.
>
> We've been debating on what form the Binding ID should take...
> - globally unique - can be used directly as the ClientID to a DHCP/DNS
> server...(but, how do you ensure uniqueness).
> - index - tied to NAI for interpretation (requires some sort of
> Binding ID management on the MN to know which indices have been used,
> etc.)
> - index-marker - again, tied to NAI for interpretation, but each
> device uses a particular index-marker, and the HA does a mapping of
> this index-marker and authorizes the Binding ID.

Why does FA has to do anything different? The HA will have the tuple
of (USER NAI, DEVICE NAI, IP Address, COA) to tunnel the data to the COA
of the devices tied to that particular NAI.

The FA will just de-tunnel and forward the packet to the device.

>
> -Madhavi
>

Haseeb

>

------_=_NextPart_001_01C0D9A0.E9BD0E90-- From owner-mobile-ip@sunroof.eng.sun.com Thu May 10 22:05:45 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA12787 for ; Thu, 10 May 2001 22:05:44 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA20423; Thu, 10 May 2001 19:05:31 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA27540; Thu, 10 May 2001 19:05:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4B22kc20464 for mobile-ip-dist; Thu, 10 May 2001 19:02:46 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4B22X420457 for ; Thu, 10 May 2001 19:02:34 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA27301 for ; Thu, 10 May 2001 19:02:32 -0700 (PDT) Received: from mail.icu.ac.kr (mail.icu.ac.kr [210.107.128.31]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA00895 for ; Thu, 10 May 2001 20:02:31 -0600 (MDT) Received: from jkchoi (v33-170.icu.ac.kr [210.107.133.170]) by mail.icu.ac.kr (8.11.0/8.11.0) with SMTP id f4B1xFB08346 for ; Fri, 11 May 2001 10:59:16 +0900 (KST) Message-ID: <001701c0d9be$8072e180$aa856bd2@jkchoi> From: "Jun Kyun Choi" To: References: Subject: Re: [mobile-ip] Mobile-IP and MPLS Integration Date: Fri, 11 May 2001 11:02:57 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01C0DA09.EF53A0D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C0DA09.EF53A0D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SSByZWFkIHRoZSBkaXNjdXNzaW9uIHJlbGF0aW5nIHRvIG15IGRyYWZ0IGF0IHRoaXMgdGltZS4g VGhlIHByb3Bvc2VkIGRyYWZ0IGlzIG9ubHkgY29uY2VybmVkIHdpdGggdGhlIGJhY2tib25lIG5l dHdvcmsgdXNpbmcgTVBMUy4NCkl0IG1lYW5zIHRoYXQgdGhlIHJlLWVuY2Fwc3VsYXRpb24gYmV0 d2VlbiBNTiBhbmQgRkEgaXMgb3V0IG9mIHNjb3BlIGluIHRoaXMgZHJhZnQuDQpJIGd1ZXNzIHRo YXQgdGhlcmUgbWF5IGJlIGEgbnVtYmVyIG9mIG1vYmlsZSBhZ2VudHMgaW5zaWRlIGhvbWUgbmV0 d29yayBvciBmb3JlaWduIG5ldHdvcmsuIFRoZXkgY2FuIGhlbHAgdG8gZW5jYXBzdWxhdGUgZnJv bSBNTiB0byBGQS9MRVIgDQppZiBpdCBpcyBuZWVkZWQuDQoNCkp1biBLeXVuIENob2kNCg0KDQo= ------=_NextPart_000_0014_01C0DA09.EF53A0D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlz by04ODU5LTEiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDUuMDAuMjkyMC4wIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFEPg0K PEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBmYWNlPSYjNDQ0MDQ7JiM0NzU0ODsg c2l6ZT0yPkkgcmVhZCB0aGUgZGlzY3Vzc2lvbiByZWxhdGluZyB0byBteSBkcmFmdCBhdCB0aGlz IA0KdGltZS4gVGhlIHByb3Bvc2VkIGRyYWZ0IGlzIG9ubHkgY29uY2VybmVkIHdpdGggdGhlIGJh Y2tib25lIG5ldHdvcmsgdXNpbmcgDQpNUExTLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFj ZT0mIzQ0NDA0OyYjNDc1NDg7IHNpemU9Mj5JdCBtZWFucyB0aGF0IHRoZSZuYnNwO3JlLWVuY2Fw c3VsYXRpb24gYmV0d2VlbiBNTiBhbmQgDQpGQSBpcyBvdXQgb2Ygc2NvcGUgaW4gdGhpcyBkcmFm dC48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiM0NDQwNDsmIzQ3NTQ4OyBzaXplPTI+ SSBndWVzcyB0aGF0Jm5ic3A7dGhlcmUgbWF5IGJlIGEgbnVtYmVyIG9mIG1vYmlsZSANCmFnZW50 cyBpbnNpZGUgaG9tZSBuZXR3b3JrIG9yIGZvcmVpZ24gbmV0d29yay4gVGhleSBjYW4gaGVscCB0 byBlbmNhcHN1bGF0ZSBmcm9tIA0KTU4gdG8gRkEvTEVSIDwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgZmFjZT0mIzQ0NDA0OyYjNDc1NDg7IHNpemU9Mj5pZiBpdCBpcyBuZWVkZWQuPC9GT05UPjwv RElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+SnVuIEt5dW4gQ2hvaTxCUj48L0RJVj4NCjxE SVY+Jm5ic3A7PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0014_01C0DA09.EF53A0D0-- From owner-mobile-ip@sunroof.eng.sun.com Fri May 11 03:04:36 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01513 for ; Fri, 11 May 2001 03:04:35 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA14139; Fri, 11 May 2001 00:04:25 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA22467; Fri, 11 May 2001 00:04:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4B72WX20786 for mobile-ip-dist; Fri, 11 May 2001 00:02:32 -0700 (PDT) Received: from bebop.france (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4B72I420771 for ; Fri, 11 May 2001 00:02:18 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.france (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id JAA21149; Fri, 11 May 2001 09:02:17 +0200 (MET DST) Date: Thu, 10 May 2001 21:29:50 +0200 (CEST) From: Erik Nordmark Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L ocalized Mobility Management Requirement s) To: mobile-ip@sunroof.eng.sun.com Cc: Erik Nordmark , =?iso-8859-1?Q?Tom_Weckstr=F6m?= In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > To understand your view better are you and Erik (Erik can speak for > himself of course) saying that you want to prohibit LMM hierarchy forever > for Mobile IP LMMs. Just to get exactly where people are coming from in > the most direct manner. My message just before this one on the same topic can be summarized as: I believe we either need a rich LMM solution (which has the same properties as IP routing today - IP routing doesn't assume a hierarchical topology) or we don't need any LMM solution at all. Erik From owner-mobile-ip@sunroof.eng.sun.com Fri May 11 03:04:39 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01524 for ; Fri, 11 May 2001 03:04:38 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA14149; Fri, 11 May 2001 00:04:26 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA22466; Fri, 11 May 2001 00:04:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4B72bw20787 for mobile-ip-dist; Fri, 11 May 2001 00:02:38 -0700 (PDT) Received: from bebop.france (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4B72N420779 for ; Fri, 11 May 2001 00:02:23 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.france (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id JAA21145; Fri, 11 May 2001 09:02:17 +0200 (MET DST) Date: Thu, 10 May 2001 21:26:37 +0200 (CEST) From: Erik Nordmark Subject: Re: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L ocalized Mobility Management Requirement s) To: "Charles E. Perkins" Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com, =?iso-8859-1?Q?Tom_Weckstr=F6m?= In-Reply-To: "Your message with ID" <3AF9A8CB.8F7B92A5@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Besides that, since the multi-level hierarchy doesn't have to be so much > more complicated anyway, I don't understand why you are arguing against it. Charlie, I'm not arguing agaist it - I'm trying to understand the detailed technical arguments for and against it and I'm frustrated because I the arguments are thin on technical aspects like numbers showing performace differences. I have some high-level concerns around LMM in general and hierarachical LMM in particular based on the observation that any LMM scheme essientially builds an overlay routing structure on top of regular IP routing. 1. The interaction between failure detection done by the IP routing protocol (OSPF and IS-IS) and the LMM agents is likely to be operationally difficult. Assuming there are multiple LMM agents with IP routers in between them. When a link or a router fails the IGP will try to detect this and route around it. But in parallel (and indepedently of this) you'll need the LMM agents to detect failures (to detect when an LMM agent fail or the path between LMM agents fail). Assuming you'd like to detect and recover from all such failures (links, routers, LMM agents) quickly you will have independent failure detection operating at two different layers - how do you prevent them working against eachother? If you don't do this then the LMM agents might decide to reconfigure the LMM hiearachy paths just before the routers have routed around the failure i.e. the LMM reconfig was not necessary. A possible way to avoid this is to not have any regular IP routers in the picture i.e. all IP forwarding in the sub-cloud is done by LMM agents. I don't know how paletable that would be. Another way to mitigate this issue would be to make sure that the time constants for the two layers are orders of magnitude apart. For instance, if the IGP is configured to route around a failure in 100 milliseconds and the LMM agents will not consider there being a failure until more than 100 millseconds have passed, you'd be fine. But in that case the LMM agents might not be able to detect and recover from an LMM agent failure in less than a few seconds. Would that be good enough? If there were no LMM agents the routing would be restored in 100 millseconds. 2. I think there is some experience indicating that protocols that have been designed assuming a hierarchical topology are far from future proof. One example being EGP which assumed a hierarchical relationship between autonomous systems which was replaced by BGP which has no such assumption. I fear the same risk here - the assumption that there is a hierarchy might prove invalid as both the topology of these networks evolve (driven by the cost of wired connectivity and the traffic patterns) and as the business relationships between operators evolve (which might drive a desire to optimize across different groupings of operators as Jim Kempf has pointed out). If folks take the above two concerns to heart I suspect that the LMM schemes would look quite different than what we've seen so far. Erik From owner-mobile-ip@sunroof.eng.sun.com Fri May 11 08:50:12 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06966 for ; Fri, 11 May 2001 08:50:12 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA00476; Fri, 11 May 2001 05:49:44 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA18538; Fri, 11 May 2001 05:49:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4BCmES21246 for mobile-ip-dist; Fri, 11 May 2001 05:48:14 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4BCm5421239 for ; Fri, 11 May 2001 05:48:05 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA12311 for ; Fri, 11 May 2001 05:48:06 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id FAA29699 for ; Fri, 11 May 2001 05:48:04 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA05745; Fri, 11 May 2001 08:48:05 -0400 Date: Fri, 11 May 2001 08:48:05 -0400 (EDT) From: Jim Bound To: mobile-ip@sunroof.eng.sun.com Cc: Erik Nordmark , =?iso-8859-1?Q?Tom_Weckstr=F6m?= Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L ocalized Mobility Management Requirement s) In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I agree Erik. I need to go look at all the mail again. My impression too in my input is that while at the lower LMMs there would never be reason to use LMMs at higher level but only adjacent LMMs. That the CoA at each hierarchy would not have to reported to the above levels. Even the home agent would not have to be notified of temporary CoAs as they only appl to the LMM level in the hiearchy one is operating in as Mobile Terminal. The Mobile Terminal would have a CoA that would in fact work anywhere in the hierarchy at any level. The temp CoAs are for that LMM level only. Hence, I pretty much ignored the routing issues you stated to Charlie. But if a CN sent a packet to the global CoA (for lack of better wording now) all your routing issues become relevant to the Mobile Terminal being found at say 3 levels deep in the LMM hierarchy for routing updates. I believe supporting LMM hierarchy should demonstrate routing updates will work. But this is not something I for one can figure out in 1 or 2 days. I will go look at it as others. But this will take some thought. Good come back and catch....................... /jim On Thu, 10 May 2001, Erik Nordmark wrote: > > To understand your view better are you and Erik (Erik can speak for > > himself of course) saying that you want to prohibit LMM hierarchy forever > > for Mobile IP LMMs. Just to get exactly where people are coming from in > > the most direct manner. > > My message just before this one on the same topic can be summarized as: > I believe we either need a rich LMM solution (which has the same properties > as IP routing today - IP routing doesn't assume a hierarchical topology) > or we don't need any LMM solution at all. > > Erik > From owner-mobile-ip@sunroof.eng.sun.com Fri May 11 09:54:34 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09742 for ; Fri, 11 May 2001 09:54:34 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA11840; Fri, 11 May 2001 06:54:02 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA25464; Fri, 11 May 2001 06:53:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4BDpvZ21329 for mobile-ip-dist; Fri, 11 May 2001 06:51:57 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4BDpl421322 for ; Fri, 11 May 2001 06:51:47 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA23560 for ; Fri, 11 May 2001 06:51:47 -0700 (PDT) Received: from idcpa4.pa.interdigital.com ([12.32.197.142]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA19238 for ; Fri, 11 May 2001 07:51:52 -0600 (MDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 May 2001 09:50:49 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'henrik@levkowetz.com'" Cc: "'mobile-ip@sunroof.eng.sun.com'" , "'nat@ietf.org'" Subject: RE: [mobile-ip] Incorporating NAT-boxes into MIPv4 Date: Fri, 11 May 2001 09:50:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DA21.5E9F5490" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C0DA21.5E9F5490 Content-Type: text/plain; charset="iso-8859-1" [Shahrier, Sharif M.] Henrik, I have a simple question on basic NAT, i.e. without port number mappings. Suppose there are two networks A and B, each has NAT-A and NAT-B respectively. Assum initially that both NAT tables are empty. Host on A wants to send a packet to a host on B. Source address is replaced by global address of A and destination adress contains global address of B. An entry is made on NAT-A so that packets coming back with the global destination address; NAT-A can replace it with the local host address. That is fine. My question is When network B initially receives the first packet, how can NAT-B replace ITS global destination address on packet with the specific address of a local host. Remember both tables were initally empty. Hence, if mutiple hosts in B were to map to this public address, how can NAT-B unambiguously translate this global address and send it to the correct host. One obviously solution be to use port mappings to decide the correct host. Is this what is normally used or is there some other solutions as well? I have checked a copuple of RFCs and numerous articles, but I did not see this explained. I would greatly appreciate it if you or someone on the list can send me an explaination. Thanks. Sharif ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- ---------------------- Sharif, I'm currently working on a solution to traversing NAT (specifically, NAPT) boxes for MIPv4, on behalf of the company I work for, ipUnplugged. Our first implementation uses MIP vendor-specific extensions, and I plan to post a draft with full details as soon as the solution has been implemented and tested in practice -- well ahead of 51st IETF. Best, Henrik -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Shahrier, Sharif M. Sent: Thursday, May 10, 2001 5:42 PM To: 'mobile-ip@sunroof.eng.sun.com' Subject: [mobile-ip] Incorporating NAT-boxes into MIPv4 I was wondering if anyone was working on incorporating NAT-boxes into MIPv4? I would be grateful if you can get in contact. -Sharif ------_=_NextPart_001_01C0DA21.5E9F5490 Content-Type: text/html; charset="iso-8859-1"

[Shahrier, Sharif M.] 
 
Henrik,
 
        I have a simple question on basic NAT, i.e. without port number mappings. Suppose there are two networks A and B,
        each has NAT-A and NAT-B respectively. Assum initially that both NAT tables are empty.
        Host on A wants to send a packet to a host on B. Source address is replaced by global address of A and destination
        adress contains global address of B. An entry is made on NAT-A so that packets coming back with the global destination
        address; NAT-A can replace it with the local host address. That is fine.
 
        My question is When network B initially receives the first packet, how can NAT-B replace ITS global destination address on
        packet with the specific address of a local host. Remember both tables were initally empty. Hence, if mutiple hosts in B were
        to map to this public address, how can NAT-B unambiguously translate this global address and send it to the correct host.
        One obviously solution be to use port mappings to decide the correct host. Is this what is normally used or is there some other
        solutions as well?
 
        I have checked a copuple of RFCs and numerous articles, but I did not see this explained.
 
        I would greatly appreciate it if you or someone on the list can send me an explaination. Thanks.
 
Sharif
 
 
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 
 Sharif,
 
    I'm currently working on a solution to traversing NAT (specifically, NAPT) boxes for MIPv4, on behalf of
the company I work for, ipUnplugged.  Our first implementation uses MIP vendor-specific extensions, and
I plan to post a draft with full details as soon as the solution has been implemented and tested in practice
-- well ahead of 51st IETF.
 
    Best,
        Henrik
-----Original Message-----
From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Shahrier, Sharif M.
Sent: Thursday, May 10, 2001 5:42 PM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: [mobile-ip] Incorporating NAT-boxes into MIPv4

I was wondering if anyone was working on incorporating NAT-boxes into MIPv4? I would be grateful if you can get in contact.
 
-Sharif
------_=_NextPart_001_01C0DA21.5E9F5490-- From owner-mobile-ip@sunroof.eng.sun.com Fri May 11 09:55:55 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09861 for ; Fri, 11 May 2001 09:55:55 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA12330; Fri, 11 May 2001 06:55:25 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA24153; Fri, 11 May 2001 06:54:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4BDqeN21340 for mobile-ip-dist; Fri, 11 May 2001 06:52:40 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4BDqQ421333 for ; Fri, 11 May 2001 06:52:27 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA25302 for ; Fri, 11 May 2001 06:52:27 -0700 (PDT) Received: from mailgw.local.ipunplugged.com ([213.88.134.217]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA19552 for ; Fri, 11 May 2001 07:52:30 -0600 (MDT) Received: from Gioconda (a28.local.ipunplugged.com [192.168.4.198]) by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with ESMTP id PAA28305 for ; Fri, 11 May 2001 15:53:06 +0200 From: "Henrik Levkowetz" To: Subject: RE: [mobile-ip] Incorporating NAT-boxes into MIPv4 Date: Fri, 11 May 2001 15:52:16 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0030_01C0DA32.5A4B5400" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0030_01C0DA32.5A4B5400 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sharif, I'm currently working on a solution to traversing NAT (specifically, NAPT) boxes for MIPv4, on behalf of the company I work for, ipUnplugged. Our first implementation uses MIP vendor-specific extensions, and I plan to post a draft with full details as soon as the solution has been implemented and tested in practice -- well ahead of 51st IETF. Best, Henrik -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Shahrier, Sharif M. Sent: Thursday, May 10, 2001 5:42 PM To: 'mobile-ip@sunroof.eng.sun.com' Subject: [mobile-ip] Incorporating NAT-boxes into MIPv4 I was wondering if anyone was working on incorporating NAT-boxes into MIPv4? I would be grateful if you can get in contact. -Sharif ------=_NextPart_000_0030_01C0DA32.5A4B5400 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Sharif,
 
    I'm currently working on a solution to = traversing NAT=20 (specifically, NAPT) boxes for MIPv4, on behalf of
the=20 company I work for, ipUnplugged.  Our first implementation uses MIP = vendor-specific extensions, and
I plan=20 to post a draft with full details as soon as the solution has been = implemented=20 and tested in practice
--=20 well ahead of 51st IETF.
 
    Best,
       =20 Henrik
-----Original Message-----
From:=20 owner-mobile-ip@sunroof.eng.sun.com=20 [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of = Shahrier,=20 Sharif M.
Sent: Thursday, May 10, 2001 5:42 PM
To: = 'mobile-ip@sunroof.eng.sun.com'
Subject: [mobile-ip] = Incorporating=20 NAT-boxes into MIPv4

I=20 was wondering if anyone was working on incorporating NAT-boxes into = MIPv4? I=20 would be grateful if you can get in contact.
 
-Sharif
------=_NextPart_000_0030_01C0DA32.5A4B5400-- From owner-mobile-ip@sunroof.eng.sun.com Fri May 11 10:12:47 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10593 for ; Fri, 11 May 2001 10:12:46 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA26040; Fri, 11 May 2001 07:12:29 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA05352; Fri, 11 May 2001 07:12:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4BEAOA21393 for mobile-ip-dist; Fri, 11 May 2001 07:10:24 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4BEAF421386 for ; Fri, 11 May 2001 07:10:15 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA27836 for ; Fri, 11 May 2001 07:10:15 -0700 (PDT) Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA27656 for ; Fri, 11 May 2001 08:10:18 -0600 (MDT) Received: from auemail1.firewall.lucent.com (localhost [127.0.0.1]) by auemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4BEACo11326 for ; Fri, 11 May 2001 10:10:12 -0400 (EDT) Received: from alcmail.micro.lucent.com (h128-94-18-195.lucent.com [128.94.18.195]) by auemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4BEABJ11306 for ; Fri, 11 May 2001 10:10:11 -0400 (EDT) Received: from PAI820RyanChen by alcmail.micro.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id KAA29723; Fri, 11 May 2001 10:10:09 -0400 (EDT) Message-ID: <00bc01c0da24$3055c8a0$242b5e80@PAI820RyanChen> From: "Yu \(Ryan\) Chen" To: Subject: [mobile-ip] a question about BU Date: Fri, 11 May 2001 10:10:38 -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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, I am interested in route optimization of MIP. How ever, I got a question and asked help for clarification. I understand that the BU message are sent to CN when the MN changes its location. My question is: Can CN resume any open TCP connection immediately at the new IP address of MN with some mechanism or it has to rely on the previous FA to keep the old TCP connection open. In other word, is route optimization effective on existing TCP connections or only new connections? Thanks in advance for any help. Ryan From owner-mobile-ip@sunroof.eng.sun.com Fri May 11 10:19:28 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10848 for ; Fri, 11 May 2001 10:19:28 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA01013; Fri, 11 May 2001 07:19:16 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA06258; Fri, 11 May 2001 07:19:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4BEHm221419 for mobile-ip-dist; Fri, 11 May 2001 07:17:48 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4BEHd421412 for ; Fri, 11 May 2001 07:17:40 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA00231 for ; Fri, 11 May 2001 07:17:40 -0700 (PDT) Received: from idcpa4.pa.interdigital.com ([12.32.197.142]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA29815 for ; Fri, 11 May 2001 07:17:37 -0700 (PDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 May 2001 10:16:41 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Mobile-IP and MPLS Integration Date: Fri, 11 May 2001 10:16:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DA24.FC5DD6E0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C0DA24.FC5DD6E0 Content-Type: text/plain; charset="iso-8859-1" I am only concerned with fast scheme for AAA evaluation. The major isssues are OSPF/MPLS, encapsulation of IP header is also out of the scope in my work -Sharif -----Original Message----- From: Jun Kyun Choi [mailto:jkchoi@icu.ac.kr] Sent: Thursday, May 10, 2001 10:03 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile-IP and MPLS Integration I read the discussion relating to my draft at this time. The proposed draft is only concerned with the backbone network using MPLS. It means that the re-encapsulation between MN and FA is out of scope in this draft. I guess that there may be a number of mobile agents inside home network or foreign network. They can help to encapsulate from MN to FA/LER if it is needed. Jun Kyun Choi ------_=_NextPart_001_01C0DA24.FC5DD6E0 Content-Type: text/html; charset="iso-8859-1"
        I am only concerned with fast scheme for AAA evaluation. The major isssues are OSPF/MPLS, encapsulation of IP header is also
        out of the scope in my work
 
        -Sharif
-----Original Message-----
From: Jun Kyun Choi [mailto:jkchoi@icu.ac.kr]
Sent: Thursday, May 10, 2001 10:03 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Mobile-IP and MPLS Integration

I read the discussion relating to my draft at this time. The proposed draft is only concerned with the backbone network using MPLS.
It means that the re-encapsulation between MN and FA is out of scope in this draft.
I guess that there may be a number of mobile agents inside home network or foreign network. They can help to encapsulate from MN to FA/LER
if it is needed.
 
Jun Kyun Choi
 
------_=_NextPart_001_01C0DA24.FC5DD6E0-- From owner-mobile-ip@sunroof.eng.sun.com Fri May 11 10:34:01 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11345 for ; Fri, 11 May 2001 10:34:01 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA11717; Fri, 11 May 2001 07:33:40 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA01053; Fri, 11 May 2001 07:33:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4BEViP21478 for mobile-ip-dist; Fri, 11 May 2001 07:31:44 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4BEVY421467 for ; Fri, 11 May 2001 07:31:35 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA24535 for ; Fri, 11 May 2001 07:31:35 -0700 (PDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA29526 for ; Fri, 11 May 2001 07:31:33 -0700 (PDT) Received: from inrialpes.fr (galibier.inrialpes.fr [194.199.24.97]) by ebene.inrialpes.fr (8.9.3+Sun/8.8.6) with ESMTP id QAA27189 for ; Fri, 11 May 2001 16:30:29 +0200 (MEST) Message-ID: <3AFBF7C4.A2EE465E@inrialpes.fr> Date: Fri, 11 May 2001 16:31:32 +0200 From: Thierry Ernst Organization: INRIA Rhone-Alpes X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] a question about BU References: <00bc01c0da24$3055c8a0$242b5e80@PAI820RyanChen> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > I am interested in route optimization of MIP. How ever, I got a question and > asked help for clarification. > I understand that the BU message are sent to CN when the MN changes its > location. My question is: Can CN resume any open TCP connection immediately > at the new IP address of MN with some mechanism or it has to rely on the > previous FA to keep the old TCP connection open. In other word, is route > optimization effective on existing TCP connections or only new connections? The CN does not need to resume the TCP connection. The MN has two active addresses: the home address used as an identifier and the careof address used for routing. The careof address is transparent to TCP which always uses the home address in the TCP header. The IP header re-route the packet to the MN's careof address (source routing via MN's careof address). Active TCP connections are not broken. This is what for MIP has been designed this way. Hope this helps, Thierry From owner-mobile-ip@sunroof.eng.sun.com Fri May 11 10:36:09 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11396 for ; Fri, 11 May 2001 10:36:09 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA13751; Fri, 11 May 2001 07:35:53 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA08650; Fri, 11 May 2001 07:35:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4BEYKK21496 for mobile-ip-dist; Fri, 11 May 2001 07:34:20 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4BEYB421489 for ; Fri, 11 May 2001 07:34:11 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA24966 for ; Fri, 11 May 2001 07:34:11 -0700 (PDT) Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA10581 for ; Fri, 11 May 2001 08:34:16 -0600 (MDT) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id JAA00964 for ; Fri, 11 May 2001 09:34:09 -0500 (CDT) Received: from ssd.usa.alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f4BEY8T14361 for ; Fri, 11 May 2001 09:34:08 -0500 (CDT) Received: from sun3102.ssd.usa.alcatel.com (sun3102.ssd.usa.alcatel.com [143.209.154.235]) by ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f4BEY4113461 for ; Fri, 11 May 2001 09:34:04 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by sun3102.ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f4BEY4V12466 for ; Fri, 11 May 2001 09:34:04 -0500 (CDT) Message-ID: <3AFBF85C.6084947F@usa.alcatel.com> Date: Fri, 11 May 2001 09:34:04 -0500 From: Xiaofeng Xu X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] a question about BU References: <00bc01c0da24$3055c8a0$242b5e80@PAI820RyanChen> Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit If the TCP connection is built on MN's home address, the BU won't affect it, but will bind it to new CoA. "Yu (Ryan) Chen" wrote: > Hi, > I am interested in route optimization of MIP. How ever, I got a question and > asked help for clarification. > I understand that the BU message are sent to CN when the MN changes its > location. My question is: Can CN resume any open TCP connection immediately > at the new IP address of MN with some mechanism or it has to rely on the > previous FA to keep the old TCP connection open. In other word, is route > optimization effective on existing TCP connections or only new connections? > > Thanks in advance for any help. > Ryan From owner-mobile-ip@sunroof.eng.sun.com Fri May 11 11:52:55 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13729 for ; Fri, 11 May 2001 11:52:54 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA22568; Fri, 11 May 2001 08:52:47 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08406; Fri, 11 May 2001 08:52:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4BFp3R21576 for mobile-ip-dist; Fri, 11 May 2001 08:51:04 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4BFos421569 for ; Fri, 11 May 2001 08:50:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA21192 for ; Fri, 11 May 2001 08:50:54 -0700 (PDT) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA23293 for ; Fri, 11 May 2001 09:50:43 -0600 (MDT) Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4BFoVd17093 for ; Fri, 11 May 2001 11:50:31 -0400 (EDT) Received: from alcmail.micro.lucent.com (h128-94-18-195.lucent.com [128.94.18.195]) by hoemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4BFoV217084 for ; Fri, 11 May 2001 11:50:31 -0400 (EDT) Received: from PAI820RyanChen by alcmail.micro.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id LAA15487; Fri, 11 May 2001 11:50:29 -0400 (EDT) Message-ID: <014d01c0da32$34dc59d0$242b5e80@PAI820RyanChen> From: "Yu \(Ryan\) Chen" To: References: <00bc01c0da24$3055c8a0$242b5e80@PAI820RyanChen> <3AFBF7C4.A2EE465E@inrialpes.fr> Subject: Re: [mobile-ip] a question about BU Date: Fri, 11 May 2001 11:51:09 -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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thanks for all the replies. However, it seems that I didn't state the question clear enough. As we know, route optimization is proposed to solve the triangle routing problem of MIP. Sure CN need not break existing TCP connections if it use the home address to connect with MN. but then any existing connections will not benefit from BU, am I right? There are actually two case: 1. The TCP connection is based on home address of MN, then no additional effort needed for open connetions. 2. The TCP connection is based on previous COA of MN, then the previous FA should forward datagrams to new COA to keep open connections. However, both of above cases still suffer from triangle routing problem. So my question is: suppose the CN received a BU, no matter its connection with MN based on home address or previous COA, is there some way that the CN could use the new COA for any existing TCP connections but not either break them or routing via HA or previous FA? I know TCP connections are based on peer IP and ports and it looks like impossible. So if it is impossible, is that mean BU only benefit new connections of MN? Best regards, Ryan ----- Original Message ----- From: "Thierry Ernst" To: Sent: Friday, May 11, 2001 10:31 AM Subject: Re: [mobile-ip] a question about BU > > I am interested in route optimization of MIP. How ever, I got a question and > > asked help for clarification. > > I understand that the BU message are sent to CN when the MN changes its > > location. My question is: Can CN resume any open TCP connection immediately > > at the new IP address of MN with some mechanism or it has to rely on the > > previous FA to keep the old TCP connection open. In other word, is route > > optimization effective on existing TCP connections or only new connections? > > The CN does not need to resume the TCP connection. The MN has two > active addresses: the home address used as an identifier and the careof > address used for routing. The careof address is transparent to TCP > which always uses the home address in the TCP header. > > The IP header re-route the packet to the MN's careof address (source > routing via MN's careof address). > > Active TCP connections are not broken. This is what for MIP has been > designed this way. > > > Hope this helps, > Thierry > From owner-mobile-ip@sunroof.eng.sun.com Fri May 11 11:57:57 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13926 for ; Fri, 11 May 2001 11:57:56 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA26737; Fri, 11 May 2001 08:57:39 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA22645; Fri, 11 May 2001 08:57:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4BFuOb21614 for mobile-ip-dist; Fri, 11 May 2001 08:56:24 -0700 (PDT) Received: from bebop.france (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4BFuF421607 for ; Fri, 11 May 2001 08:56:15 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.france (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id RAA12150 for ; Fri, 11 May 2001 17:56:13 +0200 (MET DST) Date: Fri, 11 May 2001 17:56:12 +0200 (CEST) From: Erik Nordmark Subject: Re: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L ocalized Mobility Management Requirement s) To: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Jim, > #2 and #3 in a hierarchial model is a funciton of implementation and we > know how to fix that out here in vendor land. I can build co-located > router-switch-gateway/server to solve number 2 with bookoo RAM, 200 port > at a cheap port density, and terabytes of aggregated thru-put. > > Problem #1 should be the focus of how we design LMM not 2 and 3 IMO. But just like we can add memory and network ports to a router-switch-gateway/server we can add CPUs to improve processing capacity. Sure, in all 3 cases there are likely to be some hard limits imposed by the actual box (number of slots; amount of power etc). So my question was really intended to explore whether there are numbers that indicate that we'll hit one of the three limiting factors before the others so that we can make sure that an LMM scheme solves the right problem. > > If you instead of a hierarchy add N equal LMM agents at the top level > > (e.g., with each MN in the domain randomly selecting which LMM agent to use) > > then you can address scaling along all of the above axis. > > But there are 3 axises in my view only one being call flows for when I > need access to the top LMM axis and I would argue that it can be designed > without having to go to that axis for most cases. > > Likewise the network for which MNs will need to operate are 4 dimensional > because of the signaling plane and reducing that plane for traffic and > distributed it b definition assists scalability. Which is the critical > problem to solve for Mobile IP replacing the existing bearer services for > wireless. I agree that you need scalability here. But it is hard because something in the network need to track all the visiting mobiles. Perhaps this state can be partitioned (in the database sense) over N different parallel LMM agents. Erik From owner-mobile-ip@sunroof.eng.sun.com Fri May 11 12:16:39 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14436 for ; Fri, 11 May 2001 12:16:39 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA12531; Fri, 11 May 2001 09:16:31 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13075; Fri, 11 May 2001 09:16:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4BGER721691 for mobile-ip-dist; Fri, 11 May 2001 09:14:27 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4BGEJ421684 for ; Fri, 11 May 2001 09:14:19 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25859 for ; Fri, 11 May 2001 09:14:14 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10696 for ; Fri, 11 May 2001 09:14:09 -0700 (PDT) Received: from msubbara-u10.cisco.com (msubbara-u10.cisco.com [64.102.66.20]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f4BGE7d11771 for ; Fri, 11 May 2001 09:14:07 -0700 (PDT) Received: (msubbara@localhost) by msubbara-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA26320 for mobile-ip@sunroof.eng.sun.com; Fri, 11 May 2001 12:13:33 -0400 (EDT) Date: Fri, 11 May 2001 12:13:33 -0400 From: Madhavi Subbarao To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: mobile-ip] Multiple flows with single NAI Message-ID: <20010511121333.A26309@cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from haseeb@nortelnetworks.com on Thu, May 10, 2001 at 05:31:10PM -0500 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Haseeb, On Thu, May 10, 2001 at 05:31:10PM -0500, Haseeb Akhtar wrote: > Madhavi, > > > We were thinking along the lines of a Binding ID...an ID to identify > > the particular binding/flow using a single NAI. The FA and HA > > will then use the (NAI, Binding ID) as the identifier to distinguish > > the different bindings/flows. > > > > We've been debating on what form the Binding ID should take... > > - globally unique - can be used directly as the ClientID to a DHCP/DNS > > server...(but, how do you ensure uniqueness). > > - index - tied to NAI for interpretation (requires some sort of > > Binding ID management on the MN to know which indices have been used, > > etc.) > > - index-marker - again, tied to NAI for interpretation, but each > > device uses a particular index-marker, and the HA does a mapping of > > this index-marker and authorizes the Binding ID. > > Why does FA has to do anything different? The HA will have the tuple > of (USER NAI, DEVICE NAI, IP Address, COA) to tunnel the data to the COA > of the devices tied to that particular NAI. The FA should maintain pending registrations by (USER NAI, Binding ID)...because it cannot rely just on NAI for identification anymore. > The FA will just de-tunnel and forward the packet to the device. Yes, this stays the same. Basically, the change is in identifying a MIP flow. -Madhavi > > > > > -Madhavi > > > > Haseeb > > > From owner-mobile-ip@sunroof.eng.sun.com Fri May 11 12:23:49 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14620 for ; Fri, 11 May 2001 12:23:48 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA17909; Fri, 11 May 2001 09:23:29 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25823; Fri, 11 May 2001 09:23:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4BGL0R21717 for mobile-ip-dist; Fri, 11 May 2001 09:21:00 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4BGKq421710 for ; Fri, 11 May 2001 09:20:52 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25258 for ; Fri, 11 May 2001 09:20:51 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA15974 for ; Fri, 11 May 2001 09:20:49 -0700 (PDT) Received: (qmail 10854 invoked by uid 500); 11 May 2001 16:10:13 -0000 Date: Fri, 11 May 2001 09:10:12 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: mobile-ip] Multiple flows with single NAI Message-ID: <20010511091012.F10188@charizard.diameter.org> References: <20010511121333.A26309@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010511121333.A26309@cisco.com>; from msubbara@cisco.com on Fri, May 11, 2001 at 12:13:33PM -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Fri, May 11, 2001 at 12:13:33PM -0400, Madhavi Subbarao wrote: > > The FA should maintain pending registrations by > (USER NAI, Binding ID)...because it cannot rely just on NAI for > identification anymore. I've been disconnected from this thread since it began, but have one question that may have already been asked. Why can't a device have a single NAI per binding? This seems like a simple approach, and doesn't require any protocol changes. PatC From owner-mobile-ip@sunroof.eng.sun.com Fri May 11 12:27:55 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14733 for ; Fri, 11 May 2001 12:27:54 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA20056; Fri, 11 May 2001 09:27:45 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA26747; Fri, 11 May 2001 09:27:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4BGPD921776 for mobile-ip-dist; Fri, 11 May 2001 09:25:13 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4BGP4421765 for ; Fri, 11 May 2001 09:25:04 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28559 for ; Fri, 11 May 2001 09:25:04 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA02185 for ; Fri, 11 May 2001 09:25:03 -0700 (PDT) Received: from msubbara-u10.cisco.com (msubbara-u10.cisco.com [64.102.66.20]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f4BGP1d18073 for ; Fri, 11 May 2001 09:25:01 -0700 (PDT) Received: (msubbara@localhost) by msubbara-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA26329 for mobile-ip@sunroof.eng.sun.com; Fri, 11 May 2001 12:24:27 -0400 (EDT) Date: Fri, 11 May 2001 12:24:27 -0400 From: Madhavi Subbarao To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: mobile-ip] Mult iple flows with single NAI Message-ID: <20010511122427.B26309@cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from haseeb@nortelnetworks.com on Thu, May 10, 2001 at 05:16:26PM -0500 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Haseeb, On Thu, May 10, 2001 at 05:16:26PM -0500, Haseeb Akhtar wrote: > Hello, > > What is needed is an NAI extension of the device to be sent > to the HA along with the user's NAI to be sent in the RRQ. > > The user's home address 0.0.0.0 can then easily be related > with the particular device that the user is trying to use. Exactly our thoughts! We submitted a draft on this a while back, which we need to revise now. I'm still pondering on the format of the Binding ID. http://search.ietf.org/internet-drafts/draft-subbarao-mobileip-bindingid-00.txt > The GNAIE (Generalized NAI Extension) format can be used to > define the NAI of the device. Actually, that's what we wanted to do initially. I communicated with Mohamed about this, but it seems that the GNAIE is necessarily a 'skippable' extension. In this case, the Binding/Device ID must be 'not skippable' else it leads to ambiguity. So, we were following the 'not skippable' MIER format. -Madhavi > > Regards, > > Haseeb > > > -----Original Message----- > > From: Mukesh Sharma [mailto:msharma@MEGISTO.com] > > Sent: Thursday, May 10, 2001 12:20 PM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: RE: [mobile-ip] Re: mobile-ip] Re: mobile-ip] Re: mobile-ip] > > Mult iple flows with single NAI > > > > > > > > > -----Original Message----- > > > From: Madhavi Subbarao [mailto:msubbara@cisco.com] > > > Sent: Thursday, May 10, 2001 12:00 PM > > > To: mobile-ip@sunroof.eng.sun.com > > > Subject: [mobile-ip] Re: mobile-ip] Re: mobile-ip] Re: mobile-ip] > > > Multiple flows with single NAI > > > > > > Yes, this draft is specific to Static IP addresses. We will be > > > submitting another draft detailing the behavior for Dynamic > > IP address > > > allocation with a single NAI. At first glance, it might seem > > > similar, but > > > infact there are other issues. Another level of > > abstraction is needed > > > to distinguish between different MIP 'flows'. For example, > > if a USER > > > is registering on two different devices, the RRQ's would look > > > the same... > > > (NAI, 0.0.0.0 as the home address). But, when introducing > > > another level of identification, additional measures need > > to be taken > > > to ensure no security hole is being introduced. > > > > > > Thanks, > > > Madhavi > > > > > > > That was the point I was making, need another level of > > abstraction for it to > > work at all the levels including the FA and HA. Plus at FA, > > how will FA know > > that if Mobile station is sending multiple requests or just retrying. > > > > Sharma > > > > > From owner-mobile-ip@sunroof.eng.sun.com Fri May 11 13:13:45 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15777 for ; Fri, 11 May 2001 13:13:45 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA13851; Fri, 11 May 2001 10:13:37 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09557; Fri, 11 May 2001 10:13:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4BHBmS21859 for mobile-ip-dist; Fri, 11 May 2001 10:11:48 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4BHBd421852 for ; Fri, 11 May 2001 10:11:39 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09186 for ; Fri, 11 May 2001 10:11:39 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA26933 for ; Fri, 11 May 2001 10:11:38 -0700 (PDT) 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 KAA00419 for ; Fri, 11 May 2001 10:11:38 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f4BHBZf24373 for ; Fri, 11 May 2001 10:11:35 -0700 X-mProtect: Fri, 11 May 2001 10:11:35 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdGym3G6; Fri, 11 May 2001 10:11:29 PDT Message-ID: <3AFC1D44.7E83DCB9@iprg.nokia.com> Date: Fri, 11 May 2001 10:11:32 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] a question about BU References: <00bc01c0da24$3055c8a0$242b5e80@PAI820RyanChen> <3AFBF7C4.A2EE465E@inrialpes.fr> <014d01c0da32$34dc59d0$242b5e80@PAI820RyanChen> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello again Ryan, > As we know, route optimization is proposed to solve the triangle routing > problem of MIP. Sure CN need not break existing TCP connections if it use > the home address to connect with MN. but then any existing connections will > not benefit from BU, am I right? No, this isn't right, because all TCP connections (that you wish to keep, anyway) should be based on the home address. > There are actually two case: > 1. The TCP connection is based on home address of MN, then no additional > effort needed for open connetions. This should be all of the cases of interest. > 2. The TCP connection is based on previous COA of MN, then the previous FA > should forward datagrams to new COA to keep open connections. If a node has TCP protocol control blocks based on the care-of address, then that should amount to a policy determination that the TCP connection does not have to survive reconnection. > However, both of above cases still suffer from triangle routing problem. Case (1) should not have the problem, because even though IP uses the care-of address (thus avoiding triangle routing), TCP uses the home address (thus avoiding broken connections). > So my question is: suppose the CN received a BU, no matter its connection > with MN based on home address or previous COA, is there some way that the CN > could use the new COA for any existing TCP connections but not either break > them or routing via HA or previous FA? I know TCP connections are based on > peer IP and ports and it looks like impossible. > So if it is impossible, is that mean BU only benefit new connections of MN? It is possible to let TCP use the home address and to let IP use the care-of address. Then the Binding Update will benefit all connections of the mobile node. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Fri May 11 13:55:26 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17143 for ; Fri, 11 May 2001 13:55:26 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA03641; Fri, 11 May 2001 10:55:02 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA18205; Fri, 11 May 2001 10:54:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4BHrVI21935 for mobile-ip-dist; Fri, 11 May 2001 10:53:31 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4BHrK421928 for ; Fri, 11 May 2001 10:53:20 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA17908 for ; Fri, 11 May 2001 10:53:19 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA17836 for ; Fri, 11 May 2001 10:53:19 -0700 (PDT) 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 KAA03772 for ; Fri, 11 May 2001 10:53:18 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f4BHrFS24313 for ; Fri, 11 May 2001 10:53:15 -0700 X-mProtect: Fri, 11 May 2001 10:53:15 -0700 Nokia Silicon Valley Messaging Protection Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdzYsUBi; Fri, 11 May 2001 10:53:03 PDT Message-ID: <3AFC2701.C17BF797@iprg.nokia.com> Date: Fri, 11 May 2001 10:53:06 -0700 From: Theo Pagtzis Organization: UCL/NOKIA X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386) X-Accept-Language: el, en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L ocalized Mobility Management Requirement s) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Erik, > I have some high-level concerns around LMM in general and hierarachical > LMM in particular based on the observation that any LMM scheme > essientially builds an overlay routing structure on top of regular > IP routing. > > 1. The interaction between failure detection done by the IP routing protocol > (OSPF and IS-IS) and the LMM agents is likely to be operationally difficult. > Assuming there are multiple LMM agents with IP routers in between them. > When a link or a router fails the IGP will try to detect this and route > around it. But in parallel (and indepedently of this) you'll need > the LMM agents to detect failures (to detect when an LMM agent fail or the > path between LMM agents fail). > Assuming you'd like to detect and recover from all such failures (links, > routers, LMM agents) quickly you will have independent failure > detection operating at two different layers - how do you prevent them > working against eachother? If you don't do this then the LMM agents > might decide to reconfigure the LMM hiearachy paths just before the > routers have routed around the failure i.e. the LMM reconfig was not > necessary. The main point here is to consider which should kick in first. I would expect that dynamic routing would heal itself slower than LMM routing since MN dictate how fast the heal should be effected not the routers themselves. Thus the LMM healing would have effected the next hop LMM which need not be the next hop AR supported by the dynamic routing healing. I cannot see that the two would work against each other. Consider: a,b are LMM aware routers and of course at the same time ARs (if they are not AR simultaneously then all the better!!!) a.1 | a-------------1---------b |____|___2 | |_____3 | |___________| 'a' fails and a.1 is an LMM-aware router that can recover from failure. If a.1 is an AR it would have known the best IP path anyway so dynamic routing would have done its work to provide the Shortest path towards b. If a.1 is aware of the LMM hierarchy it can work out who to send to ...that is b...and thus the packet would still be enroute to b without conflicting routing goals.. so I would like to see a scenario that you can have conflicting interests from the LMM-aware routing hierarchy and dynamic routing. I personaly believe there is _no_ such issue. By the way the worst that can happen is suboptimal dynamic route provision which takes a little longer to get optimal upon LMM-aware routing healing, but that is what dynamic routing can give on a need to have basis unless we could push that. Also we must assume that failure of an LMM and the failure of an AR is either 1) atomic 2) decoupled If it is atomic the recovering LMM-aware router (a.1) would have already established paths (maybe not superoptimal depending when the dynamic routing comes up in action) if it is decoupled then the failure of the LMM agent does not imply failure of dynamic routing. It would just start LMM routing from a different point. > > > A possible way to avoid this is to not have any regular IP routers in > the picture i.e. all IP forwarding in the sub-cloud is done by LMM > agents. I don't know how paletable that would be. I don't think we need to go that far... > > > Another way to mitigate this issue would be to make sure > that the time constants for the two > layers are orders of magnitude apart. For instance, if the IGP > is configured to route around a failure in 100 milliseconds and > the LMM agents will not consider there being a failure until more > than 100 millseconds have passed, you'd be fine. But in that case the > LMM agents might not be able to detect and recover from an LMM agent failure > in less than a few seconds. Would that be good enough? If there were > no LMM agents the routing would be restored in 100 millseconds. Now just a minute... we are not talking about IGP failures here !!!! If IGP fails then tough...it is not a problem of the LMM routing hierarchy nor has it create it...It is a problem for the IGP people to solve how fast the routing should come back..No LMM scheme would be able to do anything here anyway... So we want to talk how fast would the LMM-aware router would be able to recover from the previous LMM failure. I want to support the following "a hell lot faster than any dynamic underlying routing protocol." How...? lets write a draft... :)) Why ? Because this is one of the reasons for having the LMM-aware routing (of course amongst others) fast healing...not another slow one.... Now of course if there were no LMM agents then of course the routing would be restored in 100 msec. But in this case we wouldn't have LMM extensions, would we? (No LMM agents == core MIPv6) evaluates to true... and I think this is not the point of having requirements for LMM protocols.. So I think that the above point is invalid... > > > 2. I think there is some experience indicating that protocols that have > been designed assuming a hierarchical topology are far from future proof. This is a bit vague since I cannot relate the folloing statement to the specific issue at hand. > > One example being EGP which assumed a hierarchical relationship between > autonomous systems which was replaced by BGP which has no such assumption. Why did they replace it? Because of the original assumption about hierarchical relationship? How did such assumption impede the operation of EGP so as to be replaced with BGP (if the assumption had to do anything with the replacement in the first place???) ? And why should that relate to whether LMM encompass multi-level hierarchies. If the hierarchy can shring to just a depth of one it is just using the very basic LMM semantics.. Theo UCL/ Mobile Systems From owner-mobile-ip@sunroof.eng.sun.com Fri May 11 14:07:41 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17411 for ; Fri, 11 May 2001 14:07:40 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12159; Fri, 11 May 2001 11:07:28 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA22336; Fri, 11 May 2001 11:07:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4BI5oN21968 for mobile-ip-dist; Fri, 11 May 2001 11:05:50 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4BI5f421961 for ; Fri, 11 May 2001 11:05:42 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA20514 for ; Fri, 11 May 2001 11:05:41 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA20841 for ; Fri, 11 May 2001 11:05:40 -0700 (PDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Fri, 11 May 2001 13:59:15 -0400 Message-ID: From: Mukesh Sharma To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Mult iple flows with single NAI Date: Fri, 11 May 2001 13:59:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Madhavi, > -----Original Message----- > From: Madhavi Subbarao [mailto:msubbara@cisco.com] > Sent: Thursday, May 10, 2001 5:57 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] Re: mobile-ip] Re: mobile-ip] Re: mobile-ip] Re: > mobile-ip] Mult iple flows with single NAI > > We were thinking along the lines of a Binding ID...an ID to identify > the particular binding/flow using a single NAI. The FA and HA > will then use the (NAI, Binding ID) as the identifier to distinguish > the different bindings/flows. If you are thinking on the lines of Binding ID, then the draft (draft-subbarao-mobileip-multipleip-00.txt) of static IP address, where you are using the IP address as binding doesn't make sense. It does describe the problem though. We can have a single solution for both static and dynamic case. Only we need to define a single and unique Binding ID as a means which along with NAI can be used to identify a MIP flow. > We've been debating on what form the Binding ID should take... > - globally unique - can be used directly as the ClientID to a DHCP/DNS > server...(but, how do you ensure uniqueness). > - index - tied to NAI for interpretation (requires some sort of > Binding ID management on the MN to know which indices have been used, > etc.) > - index-marker - again, tied to NAI for interpretation, but each > device uses a particular index-marker, and the HA does a mapping of > this index-marker and authorizes the Binding ID. NAI of the device (as pointed out by Haseeb) along with some index which is managed by the MS (point 2 of yours) - needed to differenciate multiple MIP sessions from the same device - should make the binding ID and should be sent in RRQ. > Note that HA would still have to authorize the Binding ID > because it's not possible to authenticate based on NAI and identify > based on something else...opens up security holes. If the Binding ID is unique, for authorization only NAI should be enough. I am not sure why do you think that Binding ID need to be authorized by the HA. If it is not unique, then we have other problems to worry about - identify MIP flow at HA/FA again. Sharma From owner-mobile-ip@sunroof.eng.sun.com Fri May 11 14:23:58 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17690 for ; Fri, 11 May 2001 14:23:56 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA24626; Fri, 11 May 2001 11:23:38 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA23367; Fri, 11 May 2001 11:23:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4BIL1c22032 for mobile-ip-dist; Fri, 11 May 2001 11:21:01 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4BIKq422025 for ; Fri, 11 May 2001 11:20:52 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA12383 for ; Fri, 11 May 2001 11:20:47 -0700 (PDT) Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA03073 for ; Fri, 11 May 2001 11:20:45 -0700 (PDT) Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4BIKjd09801 for ; Fri, 11 May 2001 14:20:45 -0400 (EDT) Received: from alcmail.micro.lucent.com (h128-94-18-195.lucent.com [128.94.18.195]) by ihemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4BIKi509793 for ; Fri, 11 May 2001 14:20:44 -0400 (EDT) Received: from PAI820RyanChen by alcmail.micro.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id OAA06612; Fri, 11 May 2001 14:20:42 -0400 (EDT) Message-ID: <01eb01c0da47$30ee9850$242b5e80@PAI820RyanChen> From: "Yu \(Ryan\) Chen" To: References: <00bc01c0da24$3055c8a0$242b5e80@PAI820RyanChen> <3AFBF7C4.A2EE465E@inrialpes.fr> <014d01c0da32$34dc59d0$242b5e80@PAI820RyanChen> <3AFC1D44.7E83DCB9@iprg.nokia.com> Subject: Re: [mobile-ip] a question about BU Date: Fri, 11 May 2001 14:21:26 -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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, Charlie, Thank you for the help. I refered to the route optimization draft again and I see what made me confused. So actually the CN tunnels the following datagrams to the MN itself instead of sending it to the HA after it receives BU message. Am I right? If it is right, BU relieves the triangle routing problem but will require the capability of IP encapsulation on CN, doesn't it? BR, Ryan ----- Original Message ----- From: "Charles E. Perkins" To: Sent: Friday, May 11, 2001 1:11 PM Subject: Re: [mobile-ip] a question about BU > Hello again Ryan, > > > As we know, route optimization is proposed to solve the triangle routing > > problem of MIP. Sure CN need not break existing TCP connections if it use > > the home address to connect with MN. but then any existing connections will > > not benefit from BU, am I right? > > No, this isn't right, because all TCP connections (that you wish to > keep, anyway) should be based on the home address. > > > There are actually two case: > > 1. The TCP connection is based on home address of MN, then no additional > > effort needed for open connetions. > > This should be all of the cases of interest. > > > 2. The TCP connection is based on previous COA of MN, then the previous FA > > should forward datagrams to new COA to keep open connections. > > If a node has TCP protocol control blocks based on the care-of address, > then that should amount to a policy determination that the TCP connection > does not have to survive reconnection. > > > However, both of above cases still suffer from triangle routing problem. > > Case (1) should not have the problem, because even though IP uses the > care-of address (thus avoiding triangle routing), TCP uses the home > address (thus avoiding broken connections). > > So my question is: suppose the CN received a BU, no matter its connection > > with MN based on home address or previous COA, is there some way that the CN > > could use the new COA for any existing TCP connections but not either break > > them or routing via HA or previous FA? I know TCP connections are based on > > peer IP and ports and it looks like impossible. > > So if it is impossible, is that mean BU only benefit new connections of MN? > > It is possible to let TCP use the home address and to let IP use the > care-of address. Then the Binding Update will benefit all connections > of the mobile node. > > Regards, > Charlie P. > From owner-mobile-ip@sunroof.eng.sun.com Fri May 11 14:40:51 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18007 for ; Fri, 11 May 2001 14:40:51 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA25194; Fri, 11 May 2001 11:40:44 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA16629; Fri, 11 May 2001 11:40:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4BId0R22118 for mobile-ip-dist; Fri, 11 May 2001 11:39:00 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4BIcp422111 for ; Fri, 11 May 2001 11:38:52 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA16305 for ; Fri, 11 May 2001 11:38:51 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06058 for ; Fri, 11 May 2001 11:38:50 -0700 (PDT) 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 LAA08421 for ; Fri, 11 May 2001 11:38:50 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f4BIcm707907 for ; Fri, 11 May 2001 11:38:48 -0700 X-mProtect: Fri, 11 May 2001 11:38:48 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdxZOrtd; Fri, 11 May 2001 11:38:35 PDT Message-ID: <3AFC31AC.B8693868@iprg.nokia.com> Date: Fri, 11 May 2001 11:38:36 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] a question about BU References: <00bc01c0da24$3055c8a0$242b5e80@PAI820RyanChen> <3AFBF7C4.A2EE465E@inrialpes.fr> <014d01c0da32$34dc59d0$242b5e80@PAI820RyanChen> <3AFC1D44.7E83DCB9@iprg.nokia.com> <01eb01c0da47$30ee9850$242b5e80@PAI820RyanChen> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Ryan, > Thank you for the help. I refered to the route optimization draft again and > I see what made me confused. So actually the CN tunnels the following > datagrams to the MN > itself instead of sending it to the HA after it receives BU message. Am I > right? Yes, this is correct. > If it is right, BU relieves the triangle routing problem but will require > the capability of IP encapsulation on CN, doesn't it? Yes, the correspondent node has to be able to do encapsulation in order to accept the Binding Update. If you can suggest some improved wording to make this clearer in the Route Optimization specification, that would be useful to avoid any similar confusion for future readers. Would at least a statement somewhere in the specification to say that correspondents have to at least do encapsulation would be helpful? Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Fri May 11 15:29:47 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18758 for ; Fri, 11 May 2001 15:29:46 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10060; Fri, 11 May 2001 12:29:24 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA28369; Fri, 11 May 2001 12:29:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4BJRgY22206 for mobile-ip-dist; Fri, 11 May 2001 12:27:42 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4BJRX422199 for ; Fri, 11 May 2001 12:27:33 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA28109 for ; Fri, 11 May 2001 12:27:32 -0700 (PDT) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA18005 for ; Fri, 11 May 2001 13:27:36 -0600 (MDT) Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4BJRTP17694 for ; Fri, 11 May 2001 15:27:29 -0400 (EDT) Received: from alcmail.micro.lucent.com (h128-94-18-195.lucent.com [128.94.18.195]) by auemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4BJRSO17649 for ; Fri, 11 May 2001 15:27:28 -0400 (EDT) Received: from PAI820RyanChen by alcmail.micro.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id PAA15181; Fri, 11 May 2001 15:27:19 -0400 (EDT) Message-ID: <021401c0da50$7e5f7d80$242b5e80@PAI820RyanChen> From: "Yu \(Ryan\) Chen" To: References: <00bc01c0da24$3055c8a0$242b5e80@PAI820RyanChen> <3AFBF7C4.A2EE465E@inrialpes.fr> <014d01c0da32$34dc59d0$242b5e80@PAI820RyanChen> <3AFC1D44.7E83DCB9@iprg.nokia.com> Subject: Re: [mobile-ip] a question about BU Date: Fri, 11 May 2001 15:28:01 -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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Charlie, In section 3.1 of the draft, it says: " When sending an IP datagram, if the sending node has a binding cache entry for the destination node, it SHOULD tunnel the datagram to the mobile node's care-of address using the encapsulation techniques used by home agents, and described in [9, 10, 3, 4]. " I would recommend to add: "Note the sending node should not send the datagram to the MN's COA directly unless it does not need maintain any open connections." To many applications does not require mobility support, for example, applications based on UDP, it may be useful to let the CN use the new COA directly. However, it may be out of the scope of the draft. BTW, return to my original question, is there a way that CN could send the datagrams to the new COA directly instead of tunneling without breaking open TCP connections? It seems to me that it requires tearing TCP layer from IP layer. Any comments? Cheers, Ryan ----- Original Message ----- From: "Charles E. Perkins" To: Sent: Friday, May 11, 2001 1:11 PM Subject: Re: [mobile-ip] a question about BU > Hello again Ryan, > > > As we know, route optimization is proposed to solve the triangle routing > > problem of MIP. Sure CN need not break existing TCP connections if it use > > the home address to connect with MN. but then any existing connections will > > not benefit from BU, am I right? > > No, this isn't right, because all TCP connections (that you wish to > keep, anyway) should be based on the home address. > > > There are actually two case: > > 1. The TCP connection is based on home address of MN, then no additional > > effort needed for open connetions. > > This should be all of the cases of interest. > > > 2. The TCP connection is based on previous COA of MN, then the previous FA > > should forward datagrams to new COA to keep open connections. > > If a node has TCP protocol control blocks based on the care-of address, > then that should amount to a policy determination that the TCP connection > does not have to survive reconnection. > > > However, both of above cases still suffer from triangle routing problem. > > Case (1) should not have the problem, because even though IP uses the > care-of address (thus avoiding triangle routing), TCP uses the home > address (thus avoiding broken connections). > > > So my question is: suppose the CN received a BU, no matter its connection > > with MN based on home address or previous COA, is there some way that the CN > > could use the new COA for any existing TCP connections but not either break > > them or routing via HA or previous FA? I know TCP connections are based on > > peer IP and ports and it looks like impossible. > > So if it is impossible, is that mean BU only benefit new connections of MN? > > It is possible to let TCP use the home address and to let IP use the > care-of address. Then the Binding Update will benefit all connections > of the mobile node. > > Regards, > Charlie P. > From owner-mobile-ip@sunroof.eng.sun.com Fri May 11 15:45:06 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19156 for ; Fri, 11 May 2001 15:45:05 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA23638; Fri, 11 May 2001 12:44:56 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA11008; Fri, 11 May 2001 12:43:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4BJfh422238 for mobile-ip-dist; Fri, 11 May 2001 12:41:43 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4BJfY422231 for ; Fri, 11 May 2001 12:41:34 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA09009 for ; Fri, 11 May 2001 12:41:33 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA18932 for ; Fri, 11 May 2001 12:41:31 -0700 (PDT) Received: from msubbara-u10.cisco.com (msubbara-u10.cisco.com [64.102.66.20]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f4BJfa924014 for ; Fri, 11 May 2001 12:41:36 -0700 (PDT) Received: (msubbara@localhost) by msubbara-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA26472 for mobile-ip@sunroof.eng.sun.com; Fri, 11 May 2001 15:40:56 -0400 (EDT) Date: Fri, 11 May 2001 15:40:56 -0400 From: Madhavi Subbarao To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: mobile-ip] Mult iple flows with single NAI Message-ID: <20010511154056.A26467@cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from msharma@megisto.com on Fri, May 11, 2001 at 01:59:14PM -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Sharma, On Fri, May 11, 2001 at 01:59:14PM -0400, Mukesh Sharma wrote: > Madhavi, > > > -----Original Message----- > > From: Madhavi Subbarao [mailto:msubbara@cisco.com] > > Sent: Thursday, May 10, 2001 5:57 PM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: [mobile-ip] Re: mobile-ip] Re: mobile-ip] Re: mobile-ip] Re: > > mobile-ip] Mult iple flows with single NAI > > > > We were thinking along the lines of a Binding ID...an ID to identify > > the particular binding/flow using a single NAI. The FA and HA > > will then use the (NAI, Binding ID) as the identifier to distinguish > > the different bindings/flows. > > If you are thinking on the lines of Binding ID, then the draft > (draft-subbarao-mobileip-multipleip-00.txt) of static IP address, where you > are using the IP address as binding doesn't make sense. It does describe the We are thinking of Binding ID for the dynamic case. As I mentioned before, draft-subbarao-mobileip-mulitpleip-00.txt is for the static IP address case and just clarifies behavior. So, it does make sense. > problem though. We can have a single solution for both static and dynamic > case. The solutions for both cases will be different. The static case does not require any change to the standards, just clarification. The solution for the dynamic case will require modifications. Maybe at the end, we can merge the two drafts, but to say that there is a single solution is not accurate. >Only we need to define a single and unique Binding ID as a means which > along with NAI can be used to identify a MIP flow. Oh, are you suggesting a Binding ID for the static case also? I don't think you need to do this. > > We've been debating on what form the Binding ID should take... > > - globally unique - can be used directly as the ClientID to a DHCP/DNS > > server...(but, how do you ensure uniqueness). > > - index - tied to NAI for interpretation (requires some sort of > > Binding ID management on the MN to know which indices have been used, > > etc.) > > - index-marker - again, tied to NAI for interpretation, but each > > device uses a particular index-marker, and the HA does a mapping of > > this index-marker and authorizes the Binding ID. > > NAI of the device (as pointed out by Haseeb) along with some index which is > managed by the MS (point 2 of yours) - needed to differenciate multiple MIP > sessions from the same device - should make the binding ID and should be > sent in RRQ. Yes, that is the intention...to send the Binding/Device ID in the RRQ, authenticated by the MHAE. > > Note that HA would still have to authorize the Binding ID > > because it's not possible to authenticate based on NAI and identify > > based on something else...opens up security holes. > > If the Binding ID is unique, for authorization only NAI should be enough. I > am not sure why do you think that Binding ID need to be authorized by the > HA. If it is not unique, then we have other problems to worry about - > identify MIP flow at HA/FA again. If there is no authorization, the HA will authenticate based on NAI, and then just take the Binding ID as part of the identifier. But, the Binding ID can be spoofed by another MN say. I ran this by some security folks, and that's the feedback that I received. I like the Binding ID being unique, but how do we guarantee that? -Madhavi > > Sharma > From owner-mobile-ip@sunroof.eng.sun.com Fri May 11 15:47:38 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19187 for ; Fri, 11 May 2001 15:47:38 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA22516; Fri, 11 May 2001 12:47:27 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA10853; Fri, 11 May 2001 12:47:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4BJk1d22256 for mobile-ip-dist; Fri, 11 May 2001 12:46:01 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4BJjq422249 for ; Fri, 11 May 2001 12:45:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA09710 for ; Fri, 11 May 2001 12:45:51 -0700 (PDT) From: Jack_Fijolek@3com.com Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA26143 for ; Fri, 11 May 2001 13:45:56 -0600 (MDT) Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4BJi4J11495 for ; Fri, 11 May 2001 12:44:04 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104]) by opal.3com.com (Switch-2.1.1/Switch-2.1.0) with SMTP id f4BJjnv22947 for ; Fri, 11 May 2001 12:45:49 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256A49.006C8C2D ; Fri, 11 May 2001 12:45:37 -0700 X-Lotus-FromDomain: 3COM To: mobile-ip@sunroof.eng.sun.com Message-ID: <88256A49.006C8A86.00@hqoutbound.ops.3com.com> Date: Fri, 11 May 2001 14:46:12 -0500 Subject: Re: [mobile-ip] Re: mobile-ip] Multiple flows with single NAI Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: >On Fri, May 11, 2001 at 12:13:33PM -0400, Madhavi Subbarao wrote: >> >> The FA should maintain pending registrations by >> (USER NAI, Binding ID)...because it cannot rely just on NAI for >> identification anymore. > >I've been disconnected from this thread since it began, but have one >question that may have already been asked. > >Why can't a device have a single NAI per binding? This seems like a >simple approach, and doesn't require any protocol changes. > >PatC OK with me, are we done here? Jack From owner-mobile-ip@sunroof.eng.sun.com Fri May 11 16:18:57 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19790 for ; Fri, 11 May 2001 16:18:57 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA06917; Fri, 11 May 2001 13:18:47 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA17298; Fri, 11 May 2001 13:18:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4BKFVP22298 for mobile-ip-dist; Fri, 11 May 2001 13:15:31 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4BKFM422291 for ; Fri, 11 May 2001 13:15:22 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA15112 for ; Fri, 11 May 2001 13:15:21 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA16297 for ; Fri, 11 May 2001 13:15:21 -0700 (PDT) Received: from msubbara-u10.cisco.com (msubbara-u10.cisco.com [64.102.66.20]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f4BKFP913285 for ; Fri, 11 May 2001 13:15:25 -0700 (PDT) Received: (msubbara@localhost) by msubbara-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA26537 for mobile-ip@sunroof.eng.sun.com; Fri, 11 May 2001 16:14:45 -0400 (EDT) Date: Fri, 11 May 2001 16:14:45 -0400 From: Madhavi Subbarao To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: mobile-ip] Re: mobile-ip] Multiple flows with single NAI Message-ID: <20010511161445.B26513@cisco.com> References: <20010511121333.A26309@cisco.com> <20010511091012.F10188@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010511091012.F10188@charizard.diameter.org>; from pcalhoun@diameter.org on Fri, May 11, 2001 at 09:10:12AM -0700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Pat, On Fri, May 11, 2001 at 09:10:12AM -0700, Pat Calhoun wrote: > On Fri, May 11, 2001 at 12:13:33PM -0400, Madhavi Subbarao wrote: > > > > The FA should maintain pending registrations by > > (USER NAI, Binding ID)...because it cannot rely just on NAI for > > identification anymore. > > I've been disconnected from this thread since it began, but have one > question that may have already been asked. > > Why can't a device have a single NAI per binding? This seems like a > simple approach, and doesn't require any protocol changes. Yes, theoretically you can assign different NAI's per device/binding. But, realistically, many service providers don't want to issue multiple NAIs and maintain all of the management that comes along with it. In fact, this deployment issue was brought to light by Sprint. -Madhavi > > PatC From owner-mobile-ip@sunroof.eng.sun.com Fri May 11 16:33:32 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20132 for ; Fri, 11 May 2001 16:33:31 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA12905; Fri, 11 May 2001 13:33:26 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA19158; Fri, 11 May 2001 13:33:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4BKV8g22343 for mobile-ip-dist; Fri, 11 May 2001 13:31:08 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4BKV0422336 for ; Fri, 11 May 2001 13:31:00 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA19972 for ; Fri, 11 May 2001 13:30:59 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA04488 for ; Fri, 11 May 2001 13:30:58 -0700 (PDT) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f4BKV0U24717 for ; Fri, 11 May 2001 13:31:02 -0700 (PDT) Received: from cisco.com (kleung-dsl4.cisco.com [10.19.54.5]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id AAL00710 (AUTH kleung); Fri, 11 May 2001 13:30:52 -0700 (PDT) Message-ID: <3AFC4A8F.14E03143@cisco.com> Date: Fri, 11 May 2001 13:24:47 -0700 From: Kent Leung Organization: Cisco Systems X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: mobile-ip] Multiple flows with single NAI References: <20010511121333.A26309@cisco.com> <20010511091012.F10188@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Pat. I can understand why the question. We asked the same question when the issue first appeared about a year and a half ago. It would be nice and simple to support a single NAI per binding. But wireless service providers such as Sprint asked for support of multiple bindings per NAI. That's why we originally came out with the dynamic mechanism to support this. But some service providers couldn't even wait for that, and wanted a static mechanism as well. So seems like the demand from service providers is there. They wanted separation of function, NAI for authentication and Binding ID for address mapping. Kent Pat Calhoun wrote: > On Fri, May 11, 2001 at 12:13:33PM -0400, Madhavi Subbarao wrote: > > > > The FA should maintain pending registrations by > > (USER NAI, Binding ID)...because it cannot rely just on NAI for > > identification anymore. > > I've been disconnected from this thread since it began, but have one > question that may have already been asked. > > Why can't a device have a single NAI per binding? This seems like a > simple approach, and doesn't require any protocol changes. > > PatC From owner-mobile-ip@sunroof.eng.sun.com Fri May 11 17:21:58 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20870 for ; Fri, 11 May 2001 17:21:57 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA01667; Fri, 11 May 2001 14:21:38 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA29226; Fri, 11 May 2001 14:21:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4BLJ1n22497 for mobile-ip-dist; Fri, 11 May 2001 14:19:01 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4BLIq422490 for ; Fri, 11 May 2001 14:18:52 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA28561 for ; Fri, 11 May 2001 14:18:18 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA12710 for ; Fri, 11 May 2001 15:18:13 -0600 (MDT) Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f4BLI5d13600 for ; Fri, 11 May 2001 14:18:05 -0700 (PDT) Received: from GDOMMETY-W2K2.cisco.com (dhcp-171-70-57-78.cisco.com [171.70.57.78]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id AAQ06455; Fri, 11 May 2001 14:18:04 -0700 (PDT) Message-Id: <4.3.2.7.2.20010511140452.022c8438@mira-sjcm-3.cisco.com> X-Sender: gdommety@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 11 May 2001 14:20:02 -0700 To: mobile-ip@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com From: Gopal Dommety Subject: Re: [mobile-ip] Re: mobile-ip] Multiple flows with single NAI In-Reply-To: <20010511091012.F10188@charizard.diameter.org> References: <20010511121333.A26309@cisco.com> <20010511121333.A26309@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: At 09:10 AM 5/11/2001 -0700, Pat Calhoun wrote: >On Fri, May 11, 2001 at 12:13:33PM -0400, Madhavi Subbarao wrote: > > > > The FA should maintain pending registrations by > > (USER NAI, Binding ID)...because it cannot rely just on NAI for > > identification anymore. > >I've been disconnected from this thread since it began, but have one >question that may have already been asked. > >Why can't a device have a single NAI per binding? This seems like a >simple approach, and doesn't require any protocol changes. Pat, What the operators want is to be able to have a single NAI and allow multiple devices to be on the network at the same time based on that NAI. Basically the same security Key, and possibly accounting will be used for all of the devices. In order to distinguish one device from another during registration/address allocation, we need the Binding ID. One way of solving the problem is , as you suggested, by using different NAIs. The reason that the operators do not want to do that is that of operations, management, and billing. Since all these devices are with the same account, they want to have one NAI, one Key, and billing etc. This operator request is similar to that of in the dial-up world of having multiple sessions. In that space people use the NAS Port to be able to distinguish (I am sure you are aware of the ugliness of this solution). Thanks Gopal >PatC From owner-mobile-ip@sunroof.eng.sun.com Fri May 11 17:41:32 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21166 for ; Fri, 11 May 2001 17:41:32 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10139; Fri, 11 May 2001 14:41:25 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA06624; Fri, 11 May 2001 14:41:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4BLdlc22546 for mobile-ip-dist; Fri, 11 May 2001 14:39:47 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4BLda422539 for ; Fri, 11 May 2001 14:39:36 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA06220 for ; Fri, 11 May 2001 14:39:37 -0700 (PDT) From: Internet-Drafts@ietf.org Received: from china.com (TCE-E-7-182-12.bta.net.cn [202.106.182.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA08524 for ; Fri, 11 May 2001 14:39:34 -0700 (PDT) Received: from china.com([10.1.7.101]) by china.com(AIMC 2.9.5.1) with SMTP id jm43afc6f62; Sat, 12 May 2001 05:39:38 +0800 Received: from loki.ietf.org([132.151.1.177]) by china.com(AIMC 2.9.5.1) with SMTP id jm123afbb4dc; Fri, 11 May 2001 14:38:08 +0800 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA06387 for ietf-123-outbound.02@ietf.org; Mon, 7 May 2001 07:35:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA06016 for ; Mon, 7 May 2001 06:46:28 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05442; Mon, 7 May 2001 06:46:23 -0400 (EDT) Message-Id: <200105071046.GAA05442@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-gnaie-03.txt Date: Mon, 07 May 2001 06:46:23 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --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 : Generalized NAI (GNAIE) Extension Author(s) : M. Khalil, E. Qaddoura, H. Akhtar, P. Calhoun Filename : draft-ietf-mobileip-gnaie-03.txt Pages : 6 Date : 04-May-01 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-ietf-mobileip-gnaie-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-gnaie-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-gnaie-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: <20010504122208.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-gnaie-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-gnaie-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010504122208.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Fri May 11 23:07:29 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA27071 for ; Fri, 11 May 2001 23:07:28 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA17079; Fri, 11 May 2001 20:07:19 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA11146; Fri, 11 May 2001 20:07:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4C35oU22834 for mobile-ip-dist; Fri, 11 May 2001 20:05:50 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4C35d422827 for ; Fri, 11 May 2001 20:05:40 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA11095 for ; Fri, 11 May 2001 20:05:38 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id UAA09894 for ; Fri, 11 May 2001 20:05:37 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA08728; Fri, 11 May 2001 23:05:37 -0400 Date: Fri, 11 May 2001 23:05:37 -0400 (EDT) From: Jim Bound To: mobile-ip@sunroof.eng.sun.com Subject: Re: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L ocalized Mobility Management Requirement s) In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: ACK Erik I agree with your come back for measurability and scalability. If we an determine the cost to do one or the other that will tell us a lot. /jim On Fri, 11 May 2001, Erik Nordmark wrote: > Jim, > > > #2 and #3 in a hierarchial model is a funciton of implementation and we > > know how to fix that out here in vendor land. I can build co-located > > router-switch-gateway/server to solve number 2 with bookoo RAM, 200 port > > at a cheap port density, and terabytes of aggregated thru-put. > > > > Problem #1 should be the focus of how we design LMM not 2 and 3 IMO. > > But just like we can add memory and network ports to a > router-switch-gateway/server we can add CPUs to improve processing capacity. > Sure, in all 3 cases there are likely to be some hard limits > imposed by the actual box (number of slots; amount of power etc). > > So my question was really intended to explore whether there are numbers > that indicate that we'll hit one of the three limiting factors before the > others so that we can make sure that an LMM scheme solves the right > problem. > > > > If you instead of a hierarchy add N equal LMM agents at the top level > > > (e.g., with each MN in the domain randomly selecting which LMM agent to use) > > > then you can address scaling along all of the above axis. > > > > But there are 3 axises in my view only one being call flows for when I > > need access to the top LMM axis and I would argue that it can be designed > > without having to go to that axis for most cases. > > > > Likewise the network for which MNs will need to operate are 4 dimensional > > because of the signaling plane and reducing that plane for traffic and > > distributed it b definition assists scalability. Which is the critical > > problem to solve for Mobile IP replacing the existing bearer services for > > wireless. > > I agree that you need scalability here. But it is hard because > something in the network need to track all the visiting mobiles. > Perhaps this state can be partitioned (in the database sense) over N > different parallel LMM agents. > > Erik > > From owner-mobile-ip@sunroof.eng.sun.com Sat May 12 00:30:52 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA28220 for ; Sat, 12 May 2001 00:30:51 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA22801; Fri, 11 May 2001 21:30:46 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA27091; Fri, 11 May 2001 21:30:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4C4TIn23007 for mobile-ip-dist; Fri, 11 May 2001 21:29:18 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4C4Sr423000 for ; Fri, 11 May 2001 21:28:54 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA26862 for ; Fri, 11 May 2001 21:28:52 -0700 (PDT) Received: from ws130.nomadiclab.com (ws130.nomadiclab.com [195.165.196.130]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA26042 for ; Fri, 11 May 2001 22:28:58 -0600 (MDT) Received: from ws34.nomadiclab.com (ws34.nomadiclab.com [195.165.196.34]) by ws130.nomadiclab.com (Postfix) with ESMTP id 0504172504 for ; Sat, 12 May 2001 07:28:40 +0300 (EEST) Received: from nomadiclab.com (localhost [127.0.0.1]) by ws34.nomadiclab.com (Postfix) with ESMTP id 6D0B3BA2F for ; Sat, 12 May 2001 07:28:40 +0300 (EEST) Message-ID: <3AFCBB38.823E83BA@nomadiclab.com> Date: Sat, 12 May 2001 05:25:28 +0100 From: Pekka Nikander X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en,fi MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] a question about BU References: <00bc01c0da24$3055c8a0$242b5e80@PAI820RyanChen> <3AFBF7C4.A2EE465E@inrialpes.fr> <014d01c0da32$34dc59d0$242b5e80@PAI820RyanChen> <3AFC1D44.7E83DCB9@iprg.nokia.com> <021401c0da50$7e5f7d80$242b5e80@PAI820RyanChen> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > BTW, return to my original question, is there a way that CN could send the > datagrams to the new COA directly instead of tunneling without breaking > open TCP connections? Homeless Mobile IPv6 proposes one such extension for Mobile IPv6. See draft-nikander-mobileip-homelessv6-01.txt. I am not aware of any work that would be applicable to IPv4. --Pekka Nikander From owner-mobile-ip@sunroof.eng.sun.com Sat May 12 21:23:39 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21957 for ; Sat, 12 May 2001 21:23:39 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA00243; Sat, 12 May 2001 18:22:27 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA24521; Sat, 12 May 2001 18:22:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4D1KvZ23597 for mobile-ip-dist; Sat, 12 May 2001 18:20:57 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4D1Kn423590 for ; Sat, 12 May 2001 18:20:49 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA24233 for ; Sat, 12 May 2001 18:20:48 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id TAA05747 for ; Sat, 12 May 2001 19:20:54 -0600 (MDT) Received: (qmail 16922 invoked by uid 500); 13 May 2001 01:10:05 -0000 Date: Sat, 12 May 2001 18:10:05 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Proposed changes to draft-ietf-mobileip-aaa-key-0 4.txt Message-ID: <20010512181005.A10188@charizard.diameter.org> References: <7B5C0390ACE7D211BC9C0008C7EABA2B028DC7BC@daeis07nok> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <7B5C0390ACE7D211BC9C0008C7EABA2B028DC7BC@daeis07nok>; from Franck.Le@nokia.com on Fri, May 04, 2001 at 06:29:03PM -0500 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Fri, May 04, 2001 at 06:29:03PM -0500, Franck.Le@nokia.com wrote: > Hello Pat, > > It seems that some time ago, you mentioned that you were redefining the > extensions for the key distribution between the MN and the AAAh: the key > distribution will not be based on long term key encryption anymore but on > taking a random number as an input. > > To the question "Did anyone contribute proposed text?", we replied that we > suggested such a mechanism in the following internet draft > http://search.ietf.org/internet-drafts/draft-le-mobileip-keydistribution-00. > txt, and another approach based on Diffie Hellman is also described. > We suggested that the key distribution extensions should allow both methods; > and in addition we also proposed that the key distribution extension should > allow a mechanism such as the Temporary Shared Key concept to be used: > http://search.ietf.org/internet-drafts/draft-le-mobileip-sharedsecret-00.txt > > Please Pat, what is the current situation of this extension definition ? Somehow I originally missed this e-mail. As far as I can tell from a (admitedly quick) read over the specs you pointed out, these two I-Ds are specifically for Mobile IPv6. Could I ask that you look over the latest AAA-Keys (for V4), and provide input. I believe that I need to rename the spec so it is obvious it is only for Mobile IPv4. Thanks, PatC From owner-mobile-ip@sunroof.eng.sun.com Sun May 13 12:25:22 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12449 for ; Sun, 13 May 2001 12:25:21 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA29760; Sun, 13 May 2001 09:25:11 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA18539; Sun, 13 May 2001 09:24:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4DGMxH24246 for mobile-ip-dist; Sun, 13 May 2001 09:23:00 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4DGMo424239 for ; Sun, 13 May 2001 09:22:50 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24677 for ; Sun, 13 May 2001 09:22:50 -0700 (PDT) Received: from artemis.shef.ac.uk (artemis.shef.ac.uk [143.167.2.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA29405 for ; Sun, 13 May 2001 09:22:44 -0700 (PDT) Received: from [143.167.1.9] (helo=mailhub1.shef.ac.uk) by artemis.shef.ac.uk with esmtp (Exim 3.22 #4) id 14yydd-0004vK-00; Sun, 13 May 2001 17:22:33 +0100 Received: from ridingwood.shef.ac.uk ([143.167.59.249]) by mailhub1.shef.ac.uk with esmtp (Exim 3.22 #3) id 14yydd-0002iu-00; Sun, 13 May 2001 17:22:33 +0100 Received: from RIDINGWOOD/SpoolDir by ridingwood.shef.ac.uk (Mercury 1.48); 13 May 01 17:22:34 +0100 Received: from SpoolDir by RIDINGWOOD (Mercury 1.48); 13 May 01 17:22:29 +0100 Received: from borg (143.167.251.49) by ridingwood.shef.ac.uk (Mercury 1.48); 13 May 01 17:22:23 +0100 Message-ID: <007c01c0dbbf$b0f31110$31fba78f@borg> From: "cny" To: "Henrik Levkowetz" , "Shahrier, Sharif M." Cc: , References: Subject: Re: [NAT] RE: [mobile-ip] Incorporating NAT-boxes into MIPv4 Date: Sun, 13 May 2001 17:16:31 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0079_01C0DBD0.74699190" 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-Scanner: exiscan@artemis *14yydd-0004vK-00* http://duncanthrax.net/exiscan/ Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0079_01C0DBD0.74699190 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Shahrier and Henrik I am also working on this, in the same case, I am writing=20 the draft as well as waiting to finished the implementations. If we can finished in time, If possible we can demo it=20 in the coming IETF meeting. Chern Nam Yap ----- Original Message -----=20 From: Shahrier, Sharif M.=20 To: 'henrik@levkowetz.com'=20 Cc: 'mobile-ip@sunroof.eng.sun.com' ; 'nat@ietf.org'=20 Sent: Friday, May 11, 2001 3:50 PM Subject: [NAT] RE: [mobile-ip] Incorporating NAT-boxes into MIPv4 [Shahrier, Sharif M.]=20 Henrik, I have a simple question on basic NAT, i.e. without port = number mappings. Suppose there are two networks A and B, each has NAT-A and NAT-B respectively. Assum initially that = both NAT tables are empty.=20 Host on A wants to send a packet to a host on B. Source = address is replaced by global address of A and destination=20 adress contains global address of B. An entry is made on = NAT-A so that packets coming back with the global destination=20 address; NAT-A can replace it with the local host address. = That is fine. My question is When network B initially receives the first = packet, how can NAT-B replace ITS global destination address on=20 packet with the specific address of a local host. Remember = both tables were initally empty. Hence, if mutiple hosts in B were to map to this public address, how can NAT-B unambiguously = translate this global address and send it to the correct host. One obviously solution be to use port mappings to decide the = correct host. Is this what is normally used or is there some other=20 solutions as well? I have checked a copuple of RFCs and numerous articles, but = I did not see this explained. I would greatly appreciate it if you or someone on the list = can send me an explaination. Thanks. Sharif = -------------------------------------------------------------------------= -------------------------------------------------------------------------= ---------------------------- Sharif, I'm currently working on a solution to traversing NAT = (specifically, NAPT) boxes for MIPv4, on behalf of the company I work for, ipUnplugged. Our first implementation uses = MIP vendor-specific extensions, and I plan to post a draft with full details as soon as the solution has = been implemented and tested in practice -- well ahead of 51st IETF. Best, Henrik -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com = [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Shahrier, = Sharif M. Sent: Thursday, May 10, 2001 5:42 PM To: 'mobile-ip@sunroof.eng.sun.com' Subject: [mobile-ip] Incorporating NAT-boxes into MIPv4 I was wondering if anyone was working on incorporating NAT-boxes = into MIPv4? I would be grateful if you can get in contact. -Sharif ------=_NextPart_000_0079_01C0DBD0.74699190 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Shahrier and Henrik
 
I am also working on = this, in the same case, I am = writing=20
the draft as well as=20 waiting to finished the implementations.
 
If we can finished in time, If=20 possible we can demo it
in the coming IETF = meeting.
 
Chern Nam Yap
 
 
----- Original Message -----
From:=20 Shahrier, Sharif = M.
Cc: 'mobile-ip@sunroof.eng.su= n.com'=20 ; 'nat@ietf.org'
Sent: Friday, May 11, 2001 3:50 = PM
Subject: [NAT] RE: [mobile-ip]=20 Incorporating NAT-boxes into MIPv4

[Shahrier,=20 Sharif M.] 
 
Henrik,
 
        I = have a=20 simple question on basic NAT, i.e. without port number mappings. = Suppose=20 there are two networks A and = B,
        = each has=20 NAT-A and NAT-B respectively. Assum initially that both NAT tables = are=20 empty.
        = Host on=20 A wants to send a packet to a host on B. Source address is replaced = by=20 global address of A and destination=20
        = adress=20 contains global address of B. An entry is made on NAT-A so that = packets=20 coming back with the global destination=20
        = address;=20 NAT-A can replace it with the local host address. That is=20 fine.
 
        My = question is When network B initially receives the first packet, how = can=20 NAT-B replace ITS global destination address on=20
        = packet=20 with the specific address of a local host. Remember both tables were = initally empty. Hence, if mutiple hosts in B=20 were
        to = map=20 to this public address, how can NAT-B unambiguously translate this = global=20 address and send it to the correct=20 host.
        = One=20 obviously solution be to use port mappings to decide the correct = host. Is=20 this what is normally used or is there some other=20
       =20 solutions as well?
 
        I = have=20 checked a copuple of RFCs and numerous articles, but I did not see = this=20 explained.
 
        I = would=20 greatly appreciate it if you or someone on the list can send me an=20 explaination. Thanks.
 
Sharif
 
 
----------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------
 
 Sharif,
 
    I'm currently working on a solution to = traversing NAT=20 (specifically, NAPT) boxes for MIPv4, on behalf = of
the company I work for, ipUnplugged.  Our first = implementation=20 uses MIP vendor-specific extensions, and
I=20 plan to post a draft with full details as soon as the solution has = been=20 implemented and tested in practice
--=20 well ahead of 51st IETF.
 
    Best,
        = Henrik
-----Original Message-----
From:=20 owner-mobile-ip@sunroof.eng.sun.com=20 [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of = Shahrier,=20 Sharif M.
Sent: Thursday, May 10, 2001 5:42 = PM
To:=20 'mobile-ip@sunroof.eng.sun.com'
Subject: [mobile-ip]=20 Incorporating NAT-boxes into MIPv4

I was wondering if anyone was working = on=20 incorporating NAT-boxes into MIPv4? I would be grateful if you can = get in=20 contact.
 
-Sharif
------=_NextPart_000_0079_01C0DBD0.74699190-- From owner-mobile-ip@sunroof.eng.sun.com Mon May 14 04:02:00 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA05254 for ; Mon, 14 May 2001 04:01:59 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA15022; Mon, 14 May 2001 01:01:21 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA15596; Mon, 14 May 2001 01:01:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4E7wsj25022 for mobile-ip-dist; Mon, 14 May 2001 00:58:54 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4E7wk425015 for ; Mon, 14 May 2001 00:58:46 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA08459 for ; Mon, 14 May 2001 00:58:47 -0700 (PDT) Received: from p-mail1.cnet.fr (p-mail1.rd.francetelecom.fr [193.49.124.31]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id AAA17592 for ; Mon, 14 May 2001 00:58:45 -0700 (PDT) Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Mon, 14 May 2001 09:58:33 +0200 Message-ID: <91A311FF6A85D3118DDF0060080C3D82010DCD85@lat3721.rd.francetelecom.fr> From: KASSI-LAHLOU Mohammed FTRD/DMI/CAE To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] a question about BU Date: Mon, 14 May 2001 09:58:12 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f4E7wk425016 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by mercury.Sun.COM id BAA15022 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA05254 Ryan, It seems to me that for ongoing connection with an IP address it is necessary to use MobileIP to keep this connection but for new connection it is possible to use the new CoA directly and that is what we proposed in the following draft: http://www.ietf.org/internet-drafts/draft-kassi-mobileip-dmi-00.txt. Kassi -----Message d'origine----- De : Yu (Ryan) Chen [mailto:yuc3@eecs.lehigh.edu] Envoyé : vendredi 11 mai 2001 21:28 À : mobile-ip@sunroof.eng.sun.com Objet : Re: [mobile-ip] a question about BU Charlie, In section 3.1 of the draft, it says: " When sending an IP datagram, if the sending node has a binding cache entry for the destination node, it SHOULD tunnel the datagram to the mobile node's care-of address using the encapsulation techniques used by home agents, and described in [9, 10, 3, 4]. " I would recommend to add: "Note the sending node should not send the datagram to the MN's COA directly unless it does not need maintain any open connections." To many applications does not require mobility support, for example, applications based on UDP, it may be useful to let the CN use the new COA directly. However, it may be out of the scope of the draft. BTW, return to my original question, is there a way that CN could send the datagrams to the new COA directly instead of tunneling without breaking open TCP connections? It seems to me that it requires tearing TCP layer from IP layer. Any comments? Cheers, Ryan ----- Original Message ----- From: "Charles E. Perkins" To: Sent: Friday, May 11, 2001 1:11 PM Subject: Re: [mobile-ip] a question about BU > Hello again Ryan, > > > As we know, route optimization is proposed to solve the triangle routing > > problem of MIP. Sure CN need not break existing TCP connections if it use > > the home address to connect with MN. but then any existing connections will > > not benefit from BU, am I right? > > No, this isn't right, because all TCP connections (that you wish to > keep, anyway) should be based on the home address. > > > There are actually two case: > > 1. The TCP connection is based on home address of MN, then no additional > > effort needed for open connetions. > > This should be all of the cases of interest. > > > 2. The TCP connection is based on previous COA of MN, then the previous FA > > should forward datagrams to new COA to keep open connections. > > If a node has TCP protocol control blocks based on the care-of address, > then that should amount to a policy determination that the TCP connection > does not have to survive reconnection. > > > However, both of above cases still suffer from triangle routing problem. > > Case (1) should not have the problem, because even though IP uses the > care-of address (thus avoiding triangle routing), TCP uses the home > address (thus avoiding broken connections). > > > So my question is: suppose the CN received a BU, no matter its connection > > with MN based on home address or previous COA, is there some way that the CN > > could use the new COA for any existing TCP connections but not either break > > them or routing via HA or previous FA? I know TCP connections are based on > > peer IP and ports and it looks like impossible. > > So if it is impossible, is that mean BU only benefit new connections of MN? > > It is possible to let TCP use the home address and to let IP use the > care-of address. Then the Binding Update will benefit all connections > of the mobile node. > > Regards, > Charlie P. > From owner-mobile-ip@sunroof.eng.sun.com Mon May 14 05:16:36 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA05773 for ; Mon, 14 May 2001 05:16:35 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA05941; Mon, 14 May 2001 02:16:30 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA20668; Mon, 14 May 2001 02:16:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4E9EZm25179 for mobile-ip-dist; Mon, 14 May 2001 02:14:35 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4E9EQ425172 for ; Mon, 14 May 2001 02:14:26 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA25788 for ; Mon, 14 May 2001 02:14:25 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA03107 for ; Mon, 14 May 2001 02:14:23 -0700 (PDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f4E9ENN16168 for ; Mon, 14 May 2001 11:14:23 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon May 14 11:14:23 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 14 May 2001 11:09:24 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBE40@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] a few more FMIP comments Date: Mon, 14 May 2001 11:14:17 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Mike, I haven't seen any reply to this. > 1) ESP friendliness: currently there is text in the > draft which speaks of AH headers, but nothing about > ESP headers. We should make the language neutral > as well as fix any dependencies on AH itself (beyond > the BU's which is a seperable issue). This may > require source addresses to be carried in the > router solicit/advertizements itself, rather > than expecting them to come from outer IP > header. Frankly, this is just good modular > design. > => There is not much in the MIPv6 draft either, so why should this be different. > 2) I have a question as to whether anybody > considered combining the Proxy Router > Solicit functionality with the binding > update for the mobile initiated handoff. > Considering the mobile is probably moving > out of range, this seems like it's a > pretty critical time and the fewer > messages required, the better. As a > => A BU to where ? unless you get the proxy RA you don't know where you're going so what do you bind the address to ? If you mean just a BU that says "buffer packets", then this is not what the BU is used for and there are no semantics for that. Do you think it should be used that way ? > MN oldAR newAR > > BU+XOFF+RS-------> > [HI---------------->] > [<--------------HACK] > <---------BUACK+RA > => You'll need another BU though to tell the old AR where you are ? > Where XOFF is the buffer bit (to stop packets > from flowing) and RS and RA are the pertinent > parts of the Fast MIP solicit/advert payloads? > Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon May 14 10:39:01 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13788 for ; Mon, 14 May 2001 10:39:00 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA07931; Mon, 14 May 2001 07:38:11 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA25987; Mon, 14 May 2001 07:38:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4EEal225434 for mobile-ip-dist; Mon, 14 May 2001 07:36:47 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4EEac425427 for ; Mon, 14 May 2001 07:36:39 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA18719 for ; Mon, 14 May 2001 07:36:38 -0700 (PDT) Received: from zrc2s03g.us.nortel.com ([47.103.122.66]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA07090 for ; Mon, 14 May 2001 08:36:45 -0600 (MDT) Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id JAA16935 for ; Mon, 14 May 2001 09:37:23 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Mon, 14 May 2001 09:36:33 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 May 2001 09:35:53 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E43023081D1@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [NAT] RE: [mobile-ip] Incorporating NAT-boxes into MIPv4 Date: Mon, 14 May 2001 09:35:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DC83.28524280" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C0DC83.28524280 Content-Type: text/plain; charset="iso-8859-1" We proposed to use a router alert to signal the routers on both ends: http://search.ietf.org/internet-drafts/draft-lmk-mobileip-intercepting-updat e-01.txt This was designed to be compatible with even port NATs. We refer to the double NAT technique as zero-byte-overhead tunneling (ZBOT). Hope this helps, Glenn -----Original Message----- From: cny [mailto:cny@dcs.shef.ac.uk] Sent: Sunday, May 13, 2001 10:17 AM To: Henrik Levkowetz; Shahrier, Sharif M. Cc: nat; mobile-ip Subject: Re: [NAT] RE: [mobile-ip] Incorporating NAT-boxes into MIPv4 Hi Shahrier and Henrik I am also working on this, in the same case, I am writing the draft as well as waiting to finished the implementations. If we can finished in time, If possible we can demo it in the coming IETF meeting. Chern Nam Yap ----- Original Message ----- From: Shahrier, Sharif M. To: 'henrik@levkowetz.com' Cc: 'mobile-ip@sunroof.eng.sun.com' ; 'nat@ietf.org' Sent: Friday, May 11, 2001 3:50 PM Subject: [NAT] RE: [mobile-ip] Incorporating NAT-boxes into MIPv4 [Shahrier, Sharif M.] Henrik, I have a simple question on basic NAT, i.e. without port number mappings. Suppose there are two networks A and B, each has NAT-A and NAT-B respectively. Assum initially that both NAT tables are empty. Host on A wants to send a packet to a host on B. Source address is replaced by global address of A and destination adress contains global address of B. An entry is made on NAT-A so that packets coming back with the global destination address; NAT-A can replace it with the local host address. That is fine. My question is When network B initially receives the first packet, how can NAT-B replace ITS global destination address on packet with the specific address of a local host. Remember both tables were initally empty. Hence, if mutiple hosts in B were to map to this public address, how can NAT-B unambiguously translate this global address and send it to the correct host. One obviously solution be to use port mappings to decide the correct host. Is this what is normally used or is there some other solutions as well? I have checked a copuple of RFCs and numerous articles, but I did not see this explained. I would greatly appreciate it if you or someone on the list can send me an explaination. Thanks. Sharif ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- ---------------------- Sharif, I'm currently working on a solution to traversing NAT (specifically, NAPT) boxes for MIPv4, on behalf of the company I work for, ipUnplugged. Our first implementation uses MIP vendor-specific extensions, and I plan to post a draft with full details as soon as the solution has been implemented and tested in practice -- well ahead of 51st IETF. Best, Henrik -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Shahrier, Sharif M. Sent: Thursday, May 10, 2001 5:42 PM To: 'mobile-ip@sunroof.eng.sun.com' Subject: [mobile-ip] Incorporating NAT-boxes into MIPv4 I was wondering if anyone was working on incorporating NAT-boxes into MIPv4? I would be grateful if you can get in contact. -Sharif ------_=_NextPart_001_01C0DC83.28524280 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
We=20 proposed to use a router alert to signal the routers on both=20 ends:
 
 http://search.ietf.org/internet-drafts/draft-lmk-m= obileip-intercepting-update-01.txt
 
This=20 was designed to be compatible with even port NATs. We refer to the = double=20 NAT technique as zero-byte-overhead tunneling = (ZBOT).
 
Hope=20 this helps,
 
Glenn
-----Original Message-----
From: cny=20 [mailto:cny@dcs.shef.ac.uk]
Sent: Sunday, May 13, 2001 = 10:17=20 AM
To: Henrik Levkowetz; Shahrier, Sharif M.
Cc: = nat;=20 mobile-ip
Subject: Re: [NAT] RE: [mobile-ip] Incorporating = NAT-boxes=20 into MIPv4

Hi Shahrier and Henrik
 
I am also working on = this, in the = same case, I am=20 writing
the draft as well=20 as waiting to finished the implementations.
 
If we can finished in time, If=20 possible we can demo it
in the coming IETF = meeting.
 
Chern Nam Yap
 
 
----- Original Message -----
From:=20 Shahrier, Sharif M. =
To: 'henrik@levkowetz.com'
Cc: 'mobile-ip@sunroof.eng.sun.com' ; 'nat@ietf.org'
Sent: Friday, May 11, 2001 = 3:50=20 PM
Subject: [NAT] RE: = [mobile-ip]=20 Incorporating NAT-boxes into MIPv4


[Shahrier,=20 Sharif M.] 
 
Henrik,
 
        I = have=20 a simple question on basic NAT, i.e. without port number = mappings. Suppose=20 there are two networks A and = B,
        = each=20 has NAT-A and NAT-B respectively. Assum initially that both NAT = tables are=20 empty.
        = Host=20 on A wants to send a packet to a host on B. Source address is = replaced by=20 global address of A and destination=20
        = adress=20 contains global address of B. An entry is made on NAT-A so that = packets=20 coming back with the global destination=20
       =20 address; NAT-A can replace it with the local host address. That = is=20 fine.
 
        = My=20 question is When network B initially receives the first packet, = how can=20 NAT-B replace ITS global destination address on=20
        = packet=20 with the specific address of a local host. Remember both tables = were=20 initally empty. Hence, if mutiple hosts in B=20 were
        = to map=20 to this public address, how can NAT-B unambiguously translate = this global=20 address and send it to the correct=20 host.
        = One=20 obviously solution be to use port mappings to decide the correct = host. Is=20 this what is normally used or is there some other=20
       =20 solutions as well?
 
        I = have=20 checked a copuple of RFCs and numerous articles, but I did not = see this=20 explained.
 
        I = would greatly appreciate it if you or someone on the list can = send me an=20 explaination. Thanks.
 
Sharif
 
 
---------------------------------------------= ------------------------------------------------------------------------= ---------------------------------------------------------<= /DIV>
 
 Sharif,
 
    I'm currently working on a solution to = traversing NAT=20 (specifically, NAPT) boxes for MIPv4, on behalf = of
the company I work for, ipUnplugged.  Our first = implementation=20 uses MIP vendor-specific extensions, and
I plan to post a draft with full details as soon as the = solution=20 has been implemented and tested in practice
-- well ahead of 51st IETF.
 
    Best,
        = Henrik
-----Original Message-----
From:=20 owner-mobile-ip@sunroof.eng.sun.com=20 [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of=20 Shahrier, Sharif M.
Sent: Thursday, May 10, 2001 = 5:42=20 PM
To: = 'mobile-ip@sunroof.eng.sun.com'
Subject:=20 [mobile-ip] Incorporating NAT-boxes into = MIPv4

I was wondering if anyone was = working on=20 incorporating NAT-boxes into MIPv4? I would be grateful if you = can get=20 in contact.
 
-Sharif
------_=_NextPart_001_01C0DC83.28524280-- From owner-mobile-ip@sunroof.eng.sun.com Mon May 14 11:28:23 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15170 for ; Mon, 14 May 2001 11:28:22 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA27839; Mon, 14 May 2001 08:27:54 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA24722; Mon, 14 May 2001 08:27:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4EFQ6j25532 for mobile-ip-dist; Mon, 14 May 2001 08:26:06 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4EFPv425525 for ; Mon, 14 May 2001 08:25:57 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA22974 for ; Mon, 14 May 2001 08:25:56 -0700 (PDT) Received: from zrc2s03g.us.nortel.com ([47.103.122.66]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19554 for ; Mon, 14 May 2001 08:25:55 -0700 (PDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id KAA01027 for ; Mon, 14 May 2001 10:16:42 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Mon, 14 May 2001 10:10:11 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 May 2001 10:15:09 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E43023082A8@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: mobile-ip] Multiple flows with single NAI Date: Mon, 14 May 2001 10:15:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DC88.A6ACA850" X-Orig: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C0DC88.A6ACA850 Content-Type: text/plain; charset="iso-8859-1" There is nothing wrong with allowing multiple devices to use the same NAI. I wouldn't call it a user address, though. I would call it a subscription identifier. I know this could be construed as a semantics thing but user address just brings up the wrong concoction of what it should really be used for. NAI is a generic definition that can be used to identify almost anything. MIP specifications need to be explicit in what fields which use the NAI form mean and in what context, IMO. On PAT's question about each device having it's own NAIs - you can. But if you enforce this (i.e. no two devices can use the same NAI) then you've essentially begun using the NAI as a device identifier. Perhaps we need a device identifier which uses the NAI form, as well, to allow the HAs to blacklist known fraudulent devices? Maybe we need more than one field, (user, subscription, device) that use the NAI form? I wouldn't define user in MIP because there are simply some user mobility functions that can't be solved at layer 3 - again the wrong concoction. Another option would be to do something like user.subscription.device@whatever.com but then you get into coupled business models i.e. the application provider must be the network service provider or have a special directory updating arrangement etc.. - not exactly the WWW-way. Glenn -----Original Message----- From: Gopal Dommety [mailto:gdommety@cisco.com] Sent: Friday, May 11, 2001 4:20 PM To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: mobile-ip] Multiple flows with single NAI At 09:10 AM 5/11/2001 -0700, Pat Calhoun wrote: >On Fri, May 11, 2001 at 12:13:33PM -0400, Madhavi Subbarao wrote: > > > > The FA should maintain pending registrations by > > (USER NAI, Binding ID)...because it cannot rely just on NAI for > > identification anymore. > >I've been disconnected from this thread since it began, but have one >question that may have already been asked. > >Why can't a device have a single NAI per binding? This seems like a >simple approach, and doesn't require any protocol changes. Pat, What the operators want is to be able to have a single NAI and allow multiple devices to be on the network at the same time based on that NAI. Basically the same security Key, and possibly accounting will be used for all of the devices. In order to distinguish one device from another during registration/address allocation, we need the Binding ID. One way of solving the problem is , as you suggested, by using different NAIs. The reason that the operators do not want to do that is that of operations, management, and billing. Since all these devices are with the same account, they want to have one NAI, one Key, and billing etc. This operator request is similar to that of in the dial-up world of having multiple sessions. In that space people use the NAS Port to be able to distinguish (I am sure you are aware of the ugliness of this solution). Thanks Gopal >PatC ------_=_NextPart_001_01C0DC88.A6ACA850 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Re: mobile-ip] Multiple flows with single = NAI

There is nothing wrong with allowing multiple devices = to use the same NAI. I wouldn't call it a user address, though. I would = call it a subscription identifier. I know this could be construed as a = semantics thing but user address just brings up the wrong concoction of = what it should really be used for.

NAI is a generic definition that can be used to = identify almost anything. MIP specifications need to be explicit in = what fields which use the NAI form mean and in what context, IMO.  =

On PAT's question about each device having it's own = NAIs - you can. But if you enforce this (i.e. no two devices can use = the same NAI) then you've essentially begun using the NAI as a device = identifier.

Perhaps we need a device identifier which uses the = NAI form, as well, to allow the HAs to blacklist known fraudulent = devices?

Maybe we need more than one field, (user, = subscription, device) that use the NAI form?

I wouldn't define user in MIP because there are = simply some user mobility functions that can't be solved at layer 3 - = again the wrong concoction.

Another option would be to do something like = user.subscription.device@whatever.com but then you get into coupled = business models i.e. the application provider must be the network = service provider or have a special directory updating arrangement etc.. = - not exactly the WWW-way.

 

Glenn


-----Original Message-----
From: Gopal Dommety [mailto:gdommety@cisco.com]=
Sent: Friday, May 11, 2001 4:20 PM
To: mobile-ip@sunroof.eng.sun.com; = mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Re: mobile-ip] Multiple = flows with single NAI


At 09:10 AM 5/11/2001 -0700, Pat Calhoun = wrote:
>On Fri, May 11, 2001 at 12:13:33PM -0400, = Madhavi Subbarao wrote:
> >
> > The FA should maintain pending = registrations by
> > (USER NAI, Binding ID)...because it cannot = rely just on NAI for
> > identification anymore.
>
>I've been disconnected from this thread since it = began, but have one
>question that may have already been = asked.
>
>Why can't a device have a single NAI per = binding? This seems like a
>simple approach, and doesn't require any = protocol changes.

Pat,

What the operators want is to be able to have a = single NAI and allow
multiple devices to
be on the network at the same time based on that = NAI. Basically the same
security Key, and
possibly accounting will be used for all of the = devices. In order to
distinguish one  device from
another during registration/address allocation, we = need the Binding ID.

One way of solving the problem is , as you suggested, = by using different
NAIs. The reason that the operators
do not want to do that is that of  operations, = management, and billing.
Since all these devices are with the
same account, they want to have one NAI, one Key, = and billing etc.

This operator request is similar to that of in the = dial-up world of having
multiple sessions. In that space people
use the NAS Port to be able to distinguish (I am = sure you are aware of the
ugliness of this solution).

Thanks
Gopal



>PatC

------_=_NextPart_001_01C0DC88.A6ACA850-- From owner-mobile-ip@sunroof.eng.sun.com Mon May 14 11:38:00 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15432 for ; Mon, 14 May 2001 11:37:59 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA03397; Mon, 14 May 2001 08:37:34 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA26830; Mon, 14 May 2001 08:36:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4EFZ5H25582 for mobile-ip-dist; Mon, 14 May 2001 08:35:05 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4EFYu425575 for ; Mon, 14 May 2001 08:34:56 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA25703 for ; Mon, 14 May 2001 08:34:55 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA10979 for ; Mon, 14 May 2001 08:33:33 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f4EFT5922413 for ; Mon, 14 May 2001 08:29:05 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AFU00112; Mon, 14 May 2001 08:29:04 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA02812; Mon, 14 May 2001 08:29:03 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15103.63935.726819.837528@thomasm-u1.cisco.com> Date: Mon, 14 May 2001 08:29:03 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] a few more FMIP comments In-Reply-To: <034BEFD03799D411A59F00508BDF7546013DBE40@esealnt448.al.sw.ericsson.se> References: <034BEFD03799D411A59F00508BDF7546013DBE40@esealnt448.al.sw.ericsson.se> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hesham Soliman (ERA) writes: > > 1) ESP friendliness: currently there is text in the > > draft which speaks of AH headers, but nothing about > > ESP headers. We should make the language neutral > > as well as fix any dependencies on AH itself (beyond > > the BU's which is a seperable issue). This may > > require source addresses to be carried in the > > router solicit/advertizements itself, rather > > than expecting them to come from outer IP > > header. Frankly, this is just good modular > > design. > > > => There is not much in the MIPv6 draft either, so > why should this be different. Well, unless there is some specific reason to specify AH, it should just say "IPsec protected" or something like that. If that's a comment against the -13 draft as well, so much the better. > > 2) I have a question as to whether anybody > > considered combining the Proxy Router > > Solicit functionality with the binding > > update for the mobile initiated handoff. > > Considering the mobile is probably moving > > out of range, this seems like it's a > > pretty critical time and the fewer > > messages required, the better. As a > > > => A BU to where ? unless you get the proxy > RA you don't know where you're going > so what do you bind the address to ? Correct. It would require that the BU be able to have a mode which allows ARold to pick the new CoA (possibly by the HI/HACK). It could transport the picked address back in the Alternate CoA in the BU. It would sort of be like a DHCP request :-) > If you mean just a BU that says "buffer packets", > then this is not what the BU is used for > and there are no semantics for that. Actually, after it assigned the address it would be a normal BU: the XOFF bit would operate independently. This could be used, for example, with CT and where you have the ability to tune two radios. > Do you think it should be used that way ? It does seem that combining the functionality gives better on-the-air messaging. As I said earlier, the number of messages right before it hands over, is probably an important thing to consider, less being better. If the modularity isn't *too* awful, it would seem worth it, IMO. Mike From owner-mobile-ip@sunroof.eng.sun.com Mon May 14 12:06:52 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16340 for ; Mon, 14 May 2001 12:06:52 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA20199; Mon, 14 May 2001 09:06:39 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13912; Mon, 14 May 2001 09:06:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4EG4o625646 for mobile-ip-dist; Mon, 14 May 2001 09:04:50 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4EG4g425639 for ; Mon, 14 May 2001 09:04:42 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13363 for ; Mon, 14 May 2001 09:04:41 -0700 (PDT) From: Jack_Fijolek@3com.com Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA07369 for ; Mon, 14 May 2001 09:04:41 -0700 (PDT) Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4EG2rB22836 for ; Mon, 14 May 2001 09:02:53 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104]) by opal.3com.com (Switch-2.1.1/Switch-2.1.0) with SMTP id f4EG4ev26664 for ; Mon, 14 May 2001 09:04:40 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256A4C.00584CD0 ; Mon, 14 May 2001 09:04:28 -0700 X-Lotus-FromDomain: 3COM To: mobile-ip@sunroof.eng.sun.com Message-ID: <88256A4C.00584B84.00@hqoutbound.ops.3com.com> Date: Mon, 14 May 2001 11:04:50 -0500 Subject: RE: [mobile-ip] Re: mobile-ip] Multiple flows with single NAI Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=K1Ph26Gnmox11SzIN6wtpG3PLnQweVfGdQis2lQQHiQE8dqnSs8TIuGk" Content-Disposition: inline Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --0__=K1Ph26Gnmox11SzIN6wtpG3PLnQweVfGdQis2lQQHiQE8dqnSs8TIuGk Content-type: text/plain; charset=us-ascii Content-Disposition: inline I think this feature easily becomes a business model discussion on a user-IP identifier level more than on a device level, per se. An ISP could be able to "sell" IP addresses to a user on a per deviceIP basis with either; a single NAI and multiple devices "behind it", and/or, by a unique NAI per client deviceIP. IMHO, an NAI per deviceIP adds a demographic context onto a deviceIP that could be lost in the other case: That a specific IP address is identifiable as parents-work@whatever.com, impressionable-teen@whatever.com, rugrat@whatever.com, parents-leisure@whatever.com may be a desirable "WWW-way" model. Jack "Glenn Morrow" on 05/14/2001 10:15:03 AM Please respond to mobile-ip@sunroof.eng.sun.com Sent by: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com cc: (Jack Fijolek/MW/US/3Com) Subject: RE: [mobile-ip] Re: mobile-ip] Multiple flows with single NAI There is nothing wrong with allowing multiple devices to use the same NAI. I wouldn't call it a user address, though. I would call it a subscription identifier. I know this could be construed as a semantics thing but user address just brings up the wrong concoction of what it should really be used for. NAI is a generic definition that can be used to identify almost anything. MIP specifications need to be explicit in what fields which use the NAI form mean and in what context, IMO. On PAT's question about each device having it's own NAIs - you can. But if you enforce this (i.e. no two devices can use the same NAI) then you've essentially begun using the NAI as a device identifier. Perhaps we need a device identifier which uses the NAI form, as well, to allow the HAs to blacklist known fraudulent devices? Maybe we need more than one field, (user, subscription, device) that use the NAI form? I wouldn't define user in MIP because there are simply some user mobility functions that can't be solved at layer 3 - again the wrong concoction. Another option would be to do something like user.subscription.device@whatever.com but then you get into coupled business models i.e. the application provider must be the network service provider or have a special directory updating arrangement etc.. - not exactly the WWW-way. Glenn -----Original Message----- From: Gopal Dommety [mailto:gdommety@cisco.com] Sent: Friday, May 11, 2001 4:20 PM To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: mobile-ip] Multiple flows with single NAI At 09:10 AM 5/11/2001 -0700, Pat Calhoun wrote: >On Fri, May 11, 2001 at 12:13:33PM -0400, Madhavi Subbarao wrote: > > > > The FA should maintain pending registrations by > > (USER NAI, Binding ID)...because it cannot rely just on NAI for > > identification anymore. > >I've been disconnected from this thread since it began, but have one >question that may have already been asked. > >Why can't a device have a single NAI per binding? This seems like a >simple approach, and doesn't require any protocol changes. Pat, What the operators want is to be able to have a single NAI and allow multiple devices to be on the network at the same time based on that NAI. Basically the same security Key, and possibly accounting will be used for all of the devices. In order to distinguish one device from another during registration/address allocation, we need the Binding ID. One way of solving the problem is , as you suggested, by using different NAIs. The reason that the operators do not want to do that is that of operations, management, and billing. Since all these devices are with the same account, they want to have one NAI, one Key, and billing etc. This operator request is similar to that of in the dial-up world of having multiple sessions. In that space people use the NAS Port to be able to distinguish (I am sure you are aware of the ugliness of this solution). Thanks Gopal >PatC --0__=K1Ph26Gnmox11SzIN6wtpG3PLnQweVfGdQis2lQQHiQE8dqnSs8TIuGk Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1NC41OSI+DQo8VElUTEU+UkU6IFtt b2JpbGUtaXBdIFJlOiBtb2JpbGUtaXBdIE11bHRpcGxlIGZsb3dzIHdpdGggc2luZ2xlIE5BSTwv VElUTEU+DQo8L0hFQUQ+DQo8Qk9EWT4NCg0KPFA+PEZPTlQgU0laRT0yPlRoZXJlIGlzIG5vdGhp bmcgd3Jvbmcgd2l0aCBhbGxvd2luZyBtdWx0aXBsZSBkZXZpY2VzIHRvIHVzZSB0aGUgc2FtZSBO QUkuIEkgd291bGRuJ3QgY2FsbCBpdCBhIHVzZXIgYWRkcmVzcywgdGhvdWdoLiBJIHdvdWxkIGNh bGwgaXQgYSBzdWJzY3JpcHRpb24gaWRlbnRpZmllci4gSSBrbm93IHRoaXMgY291bGQgYmUgY29u c3RydWVkIGFzIGEgc2VtYW50aWNzIHRoaW5nIGJ1dCB1c2VyIGFkZHJlc3MganVzdCBicmluZ3Mg dXAgdGhlIHdyb25nIGNvbmNvY3Rpb24gb2Ygd2hhdCBpdCBzaG91bGQgcmVhbGx5IGJlIHVzZWQg Zm9yLiA8L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+TkFJIGlzIGEgZ2VuZXJpYyBkZWZp bml0aW9uIHRoYXQgY2FuIGJlIHVzZWQgdG8gaWRlbnRpZnkgYWxtb3N0IGFueXRoaW5nLiBNSVAg c3BlY2lmaWNhdGlvbnMgbmVlZCB0byBiZSBleHBsaWNpdCBpbiB3aGF0IGZpZWxkcyB3aGljaCB1 c2UgdGhlIE5BSSBmb3JtIG1lYW4gYW5kIGluIHdoYXQgY29udGV4dCwgSU1PLiZuYnNwOyA8L0ZP TlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+T24gUEFUJ3MgcXVlc3Rpb24gYWJvdXQgZWFjaCBk ZXZpY2UgaGF2aW5nIGl0J3Mgb3duIE5BSXMgLSB5b3UgY2FuLiBCdXQgaWYgeW91IGVuZm9yY2Ug dGhpcyAoaS5lLiBubyB0d28gZGV2aWNlcyBjYW4gdXNlIHRoZSBzYW1lIE5BSSkgdGhlbiB5b3Un dmUgZXNzZW50aWFsbHkgYmVndW4gdXNpbmcgdGhlIE5BSSBhcyBhIGRldmljZSBpZGVudGlmaWVy LiA8L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+UGVyaGFwcyB3ZSBuZWVkIGEgZGV2aWNl IGlkZW50aWZpZXIgd2hpY2ggdXNlcyB0aGUgTkFJIGZvcm0sIGFzIHdlbGwsIHRvIGFsbG93IHRo ZSBIQXMgdG8gYmxhY2tsaXN0IGtub3duIGZyYXVkdWxlbnQgZGV2aWNlcz88L0ZPTlQ+PC9QPg0K DQo8UD48Rk9OVCBTSVpFPTI+TWF5YmUgd2UgbmVlZCBtb3JlIHRoYW4gb25lIGZpZWxkLCAodXNl ciwgc3Vic2NyaXB0aW9uLCBkZXZpY2UpIHRoYXQgdXNlIHRoZSBOQUkgZm9ybT88L0ZPTlQ+DQo8 L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5JIHdvdWxkbid0IGRlZmluZSB1c2VyIGluIE1JUCBiZWNh dXNlIHRoZXJlIGFyZSBzaW1wbHkgc29tZSB1c2VyIG1vYmlsaXR5IGZ1bmN0aW9ucyB0aGF0IGNh bid0IGJlIHNvbHZlZCBhdCBsYXllciAzIC0gYWdhaW4gdGhlIHdyb25nIGNvbmNvY3Rpb24uPC9G T05UPjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPkFub3RoZXIgb3B0aW9uIHdvdWxkIGJlIHRvIGRv IHNvbWV0aGluZyBsaWtlIHVzZXIuc3Vic2NyaXB0aW9uLmRldmljZUB3aGF0ZXZlci5jb20gYnV0 IHRoZW4geW91IGdldCBpbnRvIGNvdXBsZWQgYnVzaW5lc3MgbW9kZWxzIGkuZS4gdGhlIGFwcGxp Y2F0aW9uIHByb3ZpZGVyIG11c3QgYmUgdGhlIG5ldHdvcmsgc2VydmljZSBwcm92aWRlciBvciBo YXZlIGEgc3BlY2lhbCBkaXJlY3RvcnkgdXBkYXRpbmcgYXJyYW5nZW1lbnQgZXRjLi4gLSBub3Qg ZXhhY3RseSB0aGUgV1dXLXdheS48L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+Jm5ic3A7 IDwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPkdsZW5uPC9GT05UPg0KPC9QPg0KPEJS Pg0KDQo8UD48Rk9OVCBTSVpFPTI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08L0ZPTlQ+DQo8 QlI+PEZPTlQgU0laRT0yPkZyb206IEdvcGFsIERvbW1ldHkgWzxBIEhSRUY9Im1haWx0bzpnZG9t bWV0eUBjaXNjby5jb20iPm1haWx0bzpnZG9tbWV0eUBjaXNjby5jb208L0E+XTwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+U2VudDogRnJpZGF5LCBNYXkgMTEsIDIwMDEgNDoyMCBQTTwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+VG86IG1vYmlsZS1pcEBzdW5yb29mLmVuZy5zdW4uY29tOyBtb2Jp bGUtaXBAc3Vucm9vZi5lbmcuc3VuLmNvbTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+U3ViamVj dDogUmU6IFttb2JpbGUtaXBdIFJlOiBtb2JpbGUtaXBdIE11bHRpcGxlIGZsb3dzIHdpdGggc2lu Z2xlIE5BSTwvRk9OVD4NCjwvUD4NCjxCUj4NCg0KPFA+PEZPTlQgU0laRT0yPkF0IDA5OjEwIEFN IDUvMTEvMjAwMSAtMDcwMCwgUGF0IENhbGhvdW4gd3JvdGU6PC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9Mj4mZ3Q7T24gRnJpLCBNYXkgMTEsIDIwMDEgYXQgMTI6MTM6MzNQTSAtMDQwMCwgTWFkaGF2 aSBTdWJiYXJhbyB3cm90ZTo8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OzwvRk9O VD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IFRoZSBGQSBzaG91bGQgbWFpbnRhaW4gcGVu ZGluZyByZWdpc3RyYXRpb25zIGJ5PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsg KFVTRVIgTkFJLCBCaW5kaW5nIElEKS4uLmJlY2F1c2UgaXQgY2Fubm90IHJlbHkganVzdCBvbiBO QUkgZm9yPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgaWRlbnRpZmljYXRpb24g YW55bW9yZS48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDs8L0ZPTlQ+DQo8QlI+PEZPTlQg U0laRT0yPiZndDtJJ3ZlIGJlZW4gZGlzY29ubmVjdGVkIGZyb20gdGhpcyB0aHJlYWQgc2luY2Ug aXQgYmVnYW4sIGJ1dCBoYXZlIG9uZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0O3F1ZXN0 aW9uIHRoYXQgbWF5IGhhdmUgYWxyZWFkeSBiZWVuIGFza2VkLjwvRk9OVD4NCjxCUj48Rk9OVCBT SVpFPTI+Jmd0OzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0O1doeSBjYW4ndCBhIGRldmlj ZSBoYXZlIGEgc2luZ2xlIE5BSSBwZXIgYmluZGluZz8gVGhpcyBzZWVtcyBsaWtlIGE8L0ZPTlQ+ DQo8QlI+PEZPTlQgU0laRT0yPiZndDtzaW1wbGUgYXBwcm9hY2gsIGFuZCBkb2Vzbid0IHJlcXVp cmUgYW55IHByb3RvY29sIGNoYW5nZXMuPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+ UGF0LDwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPldoYXQgdGhlIG9wZXJhdG9ycyB3 YW50IGlzIHRvIGJlIGFibGUgdG8gaGF2ZSBhIHNpbmdsZSBOQUkgYW5kIGFsbG93IDwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+bXVsdGlwbGUgZGV2aWNlcyB0bzwvRk9OVD4NCjxCUj48Rk9OVCBT SVpFPTI+YmUgb24gdGhlIG5ldHdvcmsgYXQgdGhlIHNhbWUgdGltZSBiYXNlZCBvbiB0aGF0IE5B SS4gQmFzaWNhbGx5IHRoZSBzYW1lIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+c2VjdXJpdHkg S2V5LCBhbmQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnBvc3NpYmx5IGFjY291bnRpbmcgd2ls bCBiZSB1c2VkIGZvciBhbGwgb2YgdGhlIGRldmljZXMuIEluIG9yZGVyIHRvIDwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+ZGlzdGluZ3Vpc2ggb25lJm5ic3A7IGRldmljZSBmcm9tPC9GT05UPg0K PEJSPjxGT05UIFNJWkU9Mj5hbm90aGVyIGR1cmluZyByZWdpc3RyYXRpb24vYWRkcmVzcyBhbGxv Y2F0aW9uLCB3ZSBuZWVkIHRoZSBCaW5kaW5nIElELjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQg U0laRT0yPk9uZSB3YXkgb2Ygc29sdmluZyB0aGUgcHJvYmxlbSBpcyAsIGFzIHlvdSBzdWdnZXN0 ZWQsIGJ5IHVzaW5nIGRpZmZlcmVudCA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPk5BSXMuIFRo ZSByZWFzb24gdGhhdCB0aGUgb3BlcmF0b3JzPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5kbyBu b3Qgd2FudCB0byBkbyB0aGF0IGlzIHRoYXQgb2YmbmJzcDsgb3BlcmF0aW9ucywgbWFuYWdlbWVu dCwgYW5kIGJpbGxpbmcuIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+U2luY2UgYWxsIHRoZXNl IGRldmljZXMgYXJlIHdpdGggdGhlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5zYW1lIGFjY291 bnQsIHRoZXkgd2FudCB0byBoYXZlIG9uZSBOQUksIG9uZSBLZXksIGFuZCBiaWxsaW5nIGV0Yy48 L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5UaGlzIG9wZXJhdG9yIHJlcXVlc3QgaXMg c2ltaWxhciB0byB0aGF0IG9mIGluIHRoZSBkaWFsLXVwIHdvcmxkIG9mIGhhdmluZyA8L0ZPTlQ+ DQo8QlI+PEZPTlQgU0laRT0yPm11bHRpcGxlIHNlc3Npb25zLiBJbiB0aGF0IHNwYWNlIHBlb3Bs ZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+dXNlIHRoZSBOQVMgUG9ydCB0byBiZSBhYmxlIHRv IGRpc3Rpbmd1aXNoIChJIGFtIHN1cmUgeW91IGFyZSBhd2FyZSBvZiB0aGUgPC9GT05UPg0KPEJS PjxGT05UIFNJWkU9Mj51Z2xpbmVzcyBvZiB0aGlzIHNvbHV0aW9uKS48L0ZPTlQ+DQo8L1A+DQoN CjxQPjxGT05UIFNJWkU9Mj5UaGFua3M8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPkdvcGFsPC9G T05UPg0KPC9QPg0KPEJSPg0KPEJSPg0KDQo8UD48Rk9OVCBTSVpFPTI+Jmd0O1BhdEM8L0ZPTlQ+ DQo8L1A+DQoNCjwvQk9EWT4NCjwvSFRNTD4NCg== --0__=K1Ph26Gnmox11SzIN6wtpG3PLnQweVfGdQis2lQQHiQE8dqnSs8TIuGk-- From owner-mobile-ip@sunroof.eng.sun.com Mon May 14 12:56:20 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17956 for ; Mon, 14 May 2001 12:56:19 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16663; Mon, 14 May 2001 09:55:57 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA19240; Mon, 14 May 2001 09:55:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4EGs3G25762 for mobile-ip-dist; Mon, 14 May 2001 09:54:03 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4EGrs425755 for ; Mon, 14 May 2001 09:53:54 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA26773 for ; Mon, 14 May 2001 09:53:53 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA03341 for ; Mon, 14 May 2001 10:54:01 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f4EGrkU20676 for ; Mon, 14 May 2001 09:53:47 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AFU01933; Mon, 14 May 2001 09:53:39 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA02821; Mon, 14 May 2001 09:53:29 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15104.3465.261445.445947@thomasm-u1.cisco.com> Date: Mon, 14 May 2001 09:53:29 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] host routes in the fast mipv6 draft X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I notice that there is provision for installation of host routes in ARnew if there is a problem with the IP address the MN wants to use. Two comments: 1) This should not be host route specific since there's now provision for moving prefixes 2) I don't see how this can work as stated. Since there's no communication with the intermediate routers before the join point, MN's traffic will go to ARold first. That implies that there would need to be route to MN on ARold as well as ARnew. If that's what was intended, it should be clarified. Also: it seems a little vague on when the route should be deleted, and how the two routers would synchronize. I generally question where this requirement came from. It seems like it toes the micro mobility IRTF line pretty strongly. Would there be much harm from just omitting this? It doesn't seem to be part of the central mission of FMIP. Mike From owner-mobile-ip@sunroof.eng.sun.com Mon May 14 14:18:36 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20374 for ; Mon, 14 May 2001 14:18:35 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA06235; Mon, 14 May 2001 11:18:11 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA15472; Mon, 14 May 2001 11:17:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4EIEw425858 for mobile-ip-dist; Mon, 14 May 2001 11:14:58 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4EIEo425851 for ; Mon, 14 May 2001 11:14:50 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA14532 for ; Mon, 14 May 2001 11:14:49 -0700 (PDT) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA15412 for ; Mon, 14 May 2001 11:14:44 -0700 (PDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2650.21) id <2MX5GJ83>; Mon, 14 May 2001 14:14:31 -0400 Message-ID: From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] host routes in the fast mipv6 draft Date: Mon, 14 May 2001 14:14:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Monday, May 14, 2001 5:53 PM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] host routes in the fast mipv6 draft I notice that there is provision for installation of host routes in ARnew if there is a problem with the IP address the MN wants to use. Two comments: 1) This should not be host route specific since there's now provision for moving prefixes GT> True enough...we should change that. 2) I don't see how this can work as stated. Since there's no communication with the intermediate routers before the join point, MN's traffic will go to ARold first. That implies that there would need to be route to MN on ARold as well as ARnew. If that's what was intended, it should be clarified. Also: it seems a little vague on when the route should be deleted, and how the two routers would synchronize. I generally question where this requirement came from. It seems like it toes the micro mobility IRTF line pretty strongly. Would there be much harm from just omitting this? It doesn't seem to be part of the central mission of FMIP. GT> I think you are missing something here...The host route is used when the MN needs to use its oldCOA at the newAR. In this case the oldAR needs to tunnel packets with destination oldCOA to the newAR. The host route (for oldCOA) is not to be installed anywhere but the newAR...The newAR needs a route in its routing table pointing towards its wireless interface for the MN so when packets get tunneled to it (from oldAR), the newAR is able to delivere them to the MN over the air rather than send them back to the oldAR... NOTE: This has nothing to do with micromobility (and/or any of its denominations) I this clearer? George From owner-mobile-ip@sunroof.eng.sun.com Mon May 14 16:33:31 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23979 for ; Mon, 14 May 2001 16:33:31 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01055; Mon, 14 May 2001 13:33:19 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA25390; Mon, 14 May 2001 13:32:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4EKV9W26324 for mobile-ip-dist; Mon, 14 May 2001 13:31:09 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4EKV0426317 for ; Mon, 14 May 2001 13:31:01 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA15642 for ; Mon, 14 May 2001 13:30:55 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA27656 for ; Mon, 14 May 2001 13:30:53 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f4EKUrd09585 for ; Mon, 14 May 2001 13:30:53 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AFW04801; Mon, 14 May 2001 13:30:53 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA02837; Mon, 14 May 2001 13:30:52 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15104.16508.834630.1068@thomasm-u1.cisco.com> Date: Mon, 14 May 2001 13:30:52 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] host routes in the fast mipv6 draft In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit George Tsirtsis writes: > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Monday, May 14, 2001 5:53 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] host routes in the fast mipv6 draft > > > I notice that there is provision for installation > of host routes in ARnew if there is a problem with > the IP address the MN wants to use. Two comments: > > 1) This should not be host route specific since > there's now provision for moving prefixes > > GT> True enough...we should change that. > > 2) I don't see how this can work as stated. Since > there's no communication with the intermediate > routers before the join point, MN's traffic > will go to ARold first. That implies that there > would need to be route to MN on ARold as well > as ARnew. If that's what was intended, it > should be clarified. Also: it seems a little > vague on when the route should be deleted, > and how the two routers would synchronize. > > I generally question where this requirement > came from. It seems like it toes the micro > mobility IRTF line pretty strongly. Would > there be much harm from just omitting this? > It doesn't seem to be part of the central > mission of FMIP. > > > GT> I think you are missing something here...The host route is used when the > MN needs to use its oldCOA at the newAR. In this case the oldAR needs to > tunnel packets with destination oldCOA to the newAR. The host route (for > oldCOA) is not to be installed anywhere but the newAR...The newAR needs a > route in its routing table pointing towards its wireless interface for the > MN so when packets get tunneled to it (from oldAR), the newAR is able to > delivere them to the MN over the air rather than send them back to the > oldAR... > NOTE: This has nothing to do with micromobility (and/or any of its > denominations) > I this clearer? Nope, I'm really confused now :-) Did you actually mean a tunnel between ARold and ARnew? I didn't see that anywhere. The normal forward tunnel is between ARold and MN, afterall. In either case, however, ARold needs to place the route in its database as well as ARnew. Otherwise, it will keep routing the packets out the old (wireless) interface as normal, which is obviously not what you'd want. I think this is what you're trying to say above, but you should probably make it clear about the side effect on ARold as well. Mike From owner-mobile-ip@sunroof.eng.sun.com Mon May 14 17:51:22 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25412 for ; Mon, 14 May 2001 17:51:22 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA09061; Mon, 14 May 2001 14:50:57 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA00150; Mon, 14 May 2001 14:42:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4ELeQJ26515 for mobile-ip-dist; Mon, 14 May 2001 14:40:26 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4ELeI426508 for ; Mon, 14 May 2001 14:40:18 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id OAA14556 for ; Mon, 14 May 2001 14:40:18 -0700 (PDT) Message-Id: <200105142140.OAA14556@heliopolis.eng.sun.com> Date: Mon, 14 May 2001 14:40:18 -0700 (PDT) From: James Kempf Subject: [mobile-ip] Times for Low-Latency IPv6 Handoff To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: kaNbMFdZqh5hqT3ErVxtuQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: As an interesting exercise, I went through some calculations about how long an IPv6 low latency handoff would take in some of the scenerios described in draft-ietf-mobileip-fast-mipv6-01.txt. I looked at the following cases: - Network determined, stateless with the following two subcases: - F-BU/F-BACK received before handoff - F-BU/F-BACK received after handoff - Network deterimed, stateful - Mobile determined, with the following two subcases: - F-BU/F-BACK received before handoff - F-BU/F-BACK received after handoff I also made the following assumptions: - Prior to handoff, the header compressor on the old AR is "hot" enough to compress the basic 40 byte IPv6 header down to 1 byte, but after handoff, the header compressor is "cold" and so the full IPv6 header needs to be sent. Currently, there is some debate about whether the compressor could be partially restarted on the new AR using context transfer, so this could introduce an additional optimization and also a potential area of timing uncertainty involving the context transfer time itself. - The BU/BACK pair completes on either side of the handoff. In actuality, it may span the handoff and Section 3.3 may come into play if the MN doesn't get a BACK back (so to speak) fast enough. Or, an additional BU may need to be sent. I view the assumptions made here as being fairly optimistic, since over the air signalling after L2 has indicated that handover is pending is likely to be subject to a considerably higher error rate due to deteriorating radio conditions in the old cell and not-yet improved radio conditions in the new. - The radio link layer is using its lowest bit rate for signalling. This assumption is based on either using a multiplexed common channel for signalling, in which case the MN would have to share the channel with other MNs in the cell, or using a dedicated channel but not wanting to charge the user much or nothing at all, and therefore not wanting to use a higher bandwidth. Of course, this will be radio-specific, but it seems like a good assumption for cellular systems. The value I used was 7.5 kbps (940 bytes/sec), which is the minimum for a wCDMA dedicated channel from Holma and Toskala, "WCDMA for UMTS", Wiley, 2000. - The wired link ARs use Ethernet (48 bit MAC address link layer) and the wireless link is using 15 byte IMSIs (International Mobile Station Identifiers) sent as ASCII digits. - The MN can neither send or receive traffic on the new AR until the old AR has confirmed the new CoA via a F-BACK. Here's the results. Network Determined, Stateless ----------------------------- As near as I can tell, the following messages get exchanged over the air: PrRtAdv, F-BU, F-BACK. Sizes of these are: hdr msg lnkAddrOpt prxLnkAddrOpt newCoA Total PrRtAdv 1 8 9 9 24 51 F-BU before 1 10 11 F-BU after 40 10 50 F-BACK before 1 9 10 F-BACK after 40 9 49 Total over the air sizes: F-BU/F-BACK before: 51 + 11 + 10 = 72 bytes F-BU/F-BACK after: 51 + 50 + 49 = 150 bytes Times: F-BU/F-BACK before: 72 bytes / 940 bytes/sec = 0.077 sec = 77 msec. F-BU/F-BACK after: 150 bytes/ 940 bytes/sec = 0.160 sec = 160 msec. However, total handoff time will consist of the above plus a nondeterministic amount of time involved in L2 handoff and the amount of processing time required on new AR to perform DAD and process the HI/HACK pair. Perhaps one could use the maximum of L2 handover time and HI/HACK processing time as an estimate to add to the above. Network Determined, Stateful ---------------------------- Messages exchanged over the air- PrRtAdv prior to handoff. Byte counts the same as the above. No F-BU/F-BACK needed, so the only over the air message required is the PrRtAdv. Total over the air size: PrRtAdv size: 51 bytes Time: 51 bytes/ 940 bytes/sec = 0.054 sec = 54 msec. L2 handover time needs to be added. Mobile Determined ----------------- Messages exchanged over the air: RtSolPr, PrRtAdv, F-BU, F-BACK. Byte counts for PrRtAdv and F-BU/F-BACK the same as above. RtSolPr sent by MN is done prior to L2 handoff. hdr RtSolPr MNlnkAddrOpt newAttPtLnkOpt Total RtSolPr 1 8 18 9 36 Total over the air sizes: F-BU/F-BACK before: 36 + 51 + 18 + 10 = 115 bytes F-BU/F-BACK after: 36 + 51 + 50 + 49 = 186 bytes Times: F-BU/F-BACK before: 115 bytes/ 940 bytes/sec. = 0.122 sec = 122 ms F-BU/F-BACK after: 198 bytes/ 940 bytes/sec. = 0.198 sec = 198 ms Again, the maximum of L2 handoff time and HI/HACK processing time would need to be included. Conclusions ----------- What conclusions to draw? These time range from respectible (55 ms for network determined, stateful) to the clearly questionable (198 ms for mobile determined, F-BU/F-BACK sent after). The ITU recommends 300 ms maximum for delay before the user notices with real time voice traffic. Depending on the amount of time required for the L2 handover, the HI/HACK processing time, and any time required to send buffered traffic to the MN if buffering is used on the old AR, the mobile determined, F-BU/F-BACK sent after case could easily exceed the ITU guideline, as almost 2/3 of the noticable delay time is taken up by the L3 handoff. The others require less L3 handoff time, but only the network determined, stateless, F-BU/F-BACK before and the network determined, stateful are less than or equal to about 1/4 of the ITU guideline. Clearly, header compression on the new AR could help a lot. IPv6 headers are big, and if there were some way the header compressors on MN and new AR could be jump started prior to handoff, the 40 byte header overhead could be eliminated. Alternatively, if the link layer can guarantee that the F-BU/F-BACK occurs before the L2 handoff, the header overhead won't occur. Using a higher bandwidth channel could help also. Please send any comments or corrections (in case my math is wrong). jak From owner-mobile-ip@sunroof.eng.sun.com Mon May 14 21:03:30 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA28107 for ; Mon, 14 May 2001 21:03:30 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA05864; Mon, 14 May 2001 18:03:23 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA23810; Mon, 14 May 2001 18:03:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4F11m426956 for mobile-ip-dist; Mon, 14 May 2001 18:01:49 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4F11e426949 for ; Mon, 14 May 2001 18:01:40 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with SMTP id f4F11eu360360 for ; Mon, 14 May 2001 18:01:40 -0700 (PDT) Message-Id: <200105150101.f4F11eu360360@jurassic.eng.sun.com> Date: Mon, 14 May 2001 18:01:40 -0700 (PDT) From: Alper Yegin Subject: RE: [mobile-ip] host routes in the fast mipv6 draft To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 77zQWMYAG0Ujl3ZKzXMgDg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > GT> I think you are missing something here...The host route is used when the > > MN needs to use its oldCOA at the newAR. In this case the oldAR needs to > > tunnel packets with destination oldCOA to the newAR. The host route (for > > oldCOA) is not to be installed anywhere but the newAR...The newAR needs a > > route in its routing table pointing towards its wireless interface for the > > MN so when packets get tunneled to it (from oldAR), the newAR is able to > > delivere them to the MN over the air rather than send them back to the > > oldAR... > > NOTE: This has nothing to do with micromobility (and/or any of its > > denominations) > > > I this clearer? > > Nope, I'm really confused now :-) > > Did you actually mean a tunnel between ARold > and ARnew? I didn't see that anywhere. The > normal forward tunnel is between ARold and MN, > afterall. > > In either case, however, ARold needs > to place the route in its database as well as > ARnew. Otherwise, it will keep routing the > packets out the old (wireless) interface as > normal, which is obviously not what you'd want. Whether packets destined to oldCoA are tunneled to newCoA or newAR, there needs to be a state on oldAR. Something like "send all packets destined to oldCoA through tunnel100". In one case tunnel100's end point will be newCoA, in other newAR. > I think this is what you're trying to say > above, but you should probably make it clear > about the side effect on ARold as well. This is the usual thing that happens with "forwarding from previous care-of address". > > Mike > alper From owner-mobile-ip@sunroof.eng.sun.com Tue May 15 04:55:24 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA19115 for ; Tue, 15 May 2001 04:55:23 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA13299; Tue, 15 May 2001 01:55:02 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA01963; Tue, 15 May 2001 01:54:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4F8rUC27360 for mobile-ip-dist; Tue, 15 May 2001 01:53:30 -0700 (PDT) Received: from bebop.france (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4F8rL427353 for ; Tue, 15 May 2001 01:53:21 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.france (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id KAA28755; Tue, 15 May 2001 10:53:18 +0200 (MET DST) Date: Tue, 15 May 2001 10:53:01 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] Times for Low-Latency IPv6 Handoff To: mobile-ip@sunroof.eng.sun.com Cc: James.Kempf@Sun.COM In-Reply-To: "Your message with ID" <200105142140.OAA14556@heliopolis.eng.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Jim, > However, total handoff time will consist of the above plus a > nondeterministic amount of time involved in L2 handoff and the > amount of processing time required on new AR to perform DAD and > process the HI/HACK pair. Perhaps one could use the maximum > of L2 handover time and HI/HACK processing time as an estimate > to add to the above. Your times assume that there is no added latency per packet imposed e.g. by waiting for the right timeslot. Since I know nothing about the actual radio channels I don't know if this might be an issue. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue May 15 06:32:15 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA19839 for ; Tue, 15 May 2001 06:32:14 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA14992; Tue, 15 May 2001 03:31:49 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA01001; Tue, 15 May 2001 03:31:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4FATK127461 for mobile-ip-dist; Tue, 15 May 2001 03:29:20 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4FATB427454 for ; Tue, 15 May 2001 03:29:12 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA00796 for ; Tue, 15 May 2001 03:29:11 -0700 (PDT) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA08949 for ; Tue, 15 May 2001 04:29:18 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2650.21) id <2MX5GKSV>; Tue, 15 May 2001 06:29:06 -0400 Message-ID: From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] host routes in the fast mipv6 draft Date: Tue, 15 May 2001 06:29:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Mike, Just to clarify one thing... In MIPv6 tunnels from Home Agents or oldARs terminate at the MN because the address used to terminate the tunnel is the MN's current COA derived from the prefix of the router the MN is currently attached to (=> the attendant router already has a route for the COA towards the wireless interface) In the Fast-MIPv6 draft we also allow the oldAR to forward packets to the MN when its newCOA is still ambiguous. To do this the oldAR needs to send packets to the MN's oldCOA but this address belongs to the oldAR itself so it needs to be encapsulated to another address. In the absence of a valid newCOA for the MN we encapsulate the packets using the newAR's address for tunnel termination. Tunneled packets will go to the newAR where they will be decapsulated. Now note that the inside header's Destination Address is oldCOA and that is why a host route is needed at the newAR... Any better? George -----Original Message----- From: Alper Yegin [mailto:Alper.Yegin@eng.sun.com] Sent: Tuesday, May 15, 2001 2:02 AM To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] host routes in the fast mipv6 draft > > GT> I think you are missing something here...The host route is used when the > > MN needs to use its oldCOA at the newAR. In this case the oldAR needs to > > tunnel packets with destination oldCOA to the newAR. The host route (for > > oldCOA) is not to be installed anywhere but the newAR...The newAR needs a > > route in its routing table pointing towards its wireless interface for the > > MN so when packets get tunneled to it (from oldAR), the newAR is able to > > delivere them to the MN over the air rather than send them back to the > > oldAR... > > NOTE: This has nothing to do with micromobility (and/or any of its > > denominations) > > > I this clearer? > > Nope, I'm really confused now :-) > > Did you actually mean a tunnel between ARold > and ARnew? I didn't see that anywhere. The > normal forward tunnel is between ARold and MN, > afterall. > > In either case, however, ARold needs > to place the route in its database as well as > ARnew. Otherwise, it will keep routing the > packets out the old (wireless) interface as > normal, which is obviously not what you'd want. Whether packets destined to oldCoA are tunneled to newCoA or newAR, there needs to be a state on oldAR. Something like "send all packets destined to oldCoA through tunnel100". In one case tunnel100's end point will be newCoA, in other newAR. > I think this is what you're trying to say > above, but you should probably make it clear > about the side effect on ARold as well. This is the usual thing that happens with "forwarding from previous care-of address". > > Mike > alper From owner-mobile-ip@sunroof.eng.sun.com Tue May 15 10:56:25 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29368 for ; Tue, 15 May 2001 10:56:24 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA27400; Tue, 15 May 2001 07:55:26 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA09355; Tue, 15 May 2001 07:55:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4FErg127805 for mobile-ip-dist; Tue, 15 May 2001 07:53:42 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4FErX427798 for ; Tue, 15 May 2001 07:53:34 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11658 for ; Tue, 15 May 2001 07:53:34 -0700 (PDT) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA25237 for ; Tue, 15 May 2001 07:53:32 -0700 (PDT) Received: from hoemail1.firewall.lucent.com (localhost [127.0.0.1]) by hoemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4FEmVg27745 for ; Tue, 15 May 2001 10:48:31 -0400 (EDT) Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by hoemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4FEmVH27737 for ; Tue, 15 May 2001 10:48:31 -0400 (EDT) Received: by IL0015EXCH001H with Internet Mail Service (5.5.2650.21) id ; Tue, 15 May 2001 09:49:41 -0500 Message-ID: From: "Dolan, Michael F (Mike)" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Times for Low-Latency IPv6 Handoff Date: Tue, 15 May 2001 09:48:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Another important factor that must be considered is whether the individual handoff schemes will be able to support handoff cancellation and handoff failure. Handoff cancellation is the decision at L2 to cancel a handoff that has been initiated. Handoff failure is the attempt at L2 to move the MN to a new L2 access point, but failure by the MN to reach the new L2 access point. The MN then returns to the old L2 access point for continued connectivity. Both handoff cancellation and handoff failure must be accomodated, since they are already supported in existing radio access network protocols. Have a good day, Mike mfdolan@lucent.com -----Original Message----- From: James Kempf [mailto:James.Kempf@Sun.COM] Sent: Monday, May 14, 2001 4:40 PM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Times for Low-Latency IPv6 Handoff As an interesting exercise, I went through some calculations about how long an IPv6 low latency handoff would take in some of the scenerios described in draft-ietf-mobileip-fast-mipv6-01.txt. I looked at the following cases: - Network determined, stateless with the following two subcases: - F-BU/F-BACK received before handoff - F-BU/F-BACK received after handoff - Network deterimed, stateful - Mobile determined, with the following two subcases: - F-BU/F-BACK received before handoff - F-BU/F-BACK received after handoff I also made the following assumptions: - Prior to handoff, the header compressor on the old AR is "hot" enough to compress the basic 40 byte IPv6 header down to 1 byte, but after handoff, the header compressor is "cold" and so the full IPv6 header needs to be sent. Currently, there is some debate about whether the compressor could be partially restarted on the new AR using context transfer, so this could introduce an additional optimization and also a potential area of timing uncertainty involving the context transfer time itself. - The BU/BACK pair completes on either side of the handoff. In actuality, it may span the handoff and Section 3.3 may come into play if the MN doesn't get a BACK back (so to speak) fast enough. Or, an additional BU may need to be sent. I view the assumptions made here as being fairly optimistic, since over the air signalling after L2 has indicated that handover is pending is likely to be subject to a considerably higher error rate due to deteriorating radio conditions in the old cell and not-yet improved radio conditions in the new. - The radio link layer is using its lowest bit rate for signalling. This assumption is based on either using a multiplexed common channel for signalling, in which case the MN would have to share the channel with other MNs in the cell, or using a dedicated channel but not wanting to charge the user much or nothing at all, and therefore not wanting to use a higher bandwidth. Of course, this will be radio-specific, but it seems like a good assumption for cellular systems. The value I used was 7.5 kbps (940 bytes/sec), which is the minimum for a wCDMA dedicated channel from Holma and Toskala, "WCDMA for UMTS", Wiley, 2000. - The wired link ARs use Ethernet (48 bit MAC address link layer) and the wireless link is using 15 byte IMSIs (International Mobile Station Identifiers) sent as ASCII digits. - The MN can neither send or receive traffic on the new AR until the old AR has confirmed the new CoA via a F-BACK. Here's the results. Network Determined, Stateless ----------------------------- As near as I can tell, the following messages get exchanged over the air: PrRtAdv, F-BU, F-BACK. Sizes of these are: hdr msg lnkAddrOpt prxLnkAddrOpt newCoA Total PrRtAdv 1 8 9 9 24 51 F-BU before 1 10 11 F-BU after 40 10 50 F-BACK before 1 9 10 F-BACK after 40 9 49 Total over the air sizes: F-BU/F-BACK before: 51 + 11 + 10 = 72 bytes F-BU/F-BACK after: 51 + 50 + 49 = 150 bytes Times: F-BU/F-BACK before: 72 bytes / 940 bytes/sec = 0.077 sec = 77 msec. F-BU/F-BACK after: 150 bytes/ 940 bytes/sec = 0.160 sec = 160 msec. However, total handoff time will consist of the above plus a nondeterministic amount of time involved in L2 handoff and the amount of processing time required on new AR to perform DAD and process the HI/HACK pair. Perhaps one could use the maximum of L2 handover time and HI/HACK processing time as an estimate to add to the above. Network Determined, Stateful ---------------------------- Messages exchanged over the air- PrRtAdv prior to handoff. Byte counts the same as the above. No F-BU/F-BACK needed, so the only over the air message required is the PrRtAdv. Total over the air size: PrRtAdv size: 51 bytes Time: 51 bytes/ 940 bytes/sec = 0.054 sec = 54 msec. L2 handover time needs to be added. Mobile Determined ----------------- Messages exchanged over the air: RtSolPr, PrRtAdv, F-BU, F-BACK. Byte counts for PrRtAdv and F-BU/F-BACK the same as above. RtSolPr sent by MN is done prior to L2 handoff. hdr RtSolPr MNlnkAddrOpt newAttPtLnkOpt Total RtSolPr 1 8 18 9 36 Total over the air sizes: F-BU/F-BACK before: 36 + 51 + 18 + 10 = 115 bytes F-BU/F-BACK after: 36 + 51 + 50 + 49 = 186 bytes Times: F-BU/F-BACK before: 115 bytes/ 940 bytes/sec. = 0.122 sec = 122 ms F-BU/F-BACK after: 198 bytes/ 940 bytes/sec. = 0.198 sec = 198 ms Again, the maximum of L2 handoff time and HI/HACK processing time would need to be included. Conclusions ----------- What conclusions to draw? These time range from respectible (55 ms for network determined, stateful) to the clearly questionable (198 ms for mobile determined, F-BU/F-BACK sent after). The ITU recommends 300 ms maximum for delay before the user notices with real time voice traffic. Depending on the amount of time required for the L2 handover, the HI/HACK processing time, and any time required to send buffered traffic to the MN if buffering is used on the old AR, the mobile determined, F-BU/F-BACK sent after case could easily exceed the ITU guideline, as almost 2/3 of the noticable delay time is taken up by the L3 handoff. The others require less L3 handoff time, but only the network determined, stateless, F-BU/F-BACK before and the network determined, stateful are less than or equal to about 1/4 of the ITU guideline. Clearly, header compression on the new AR could help a lot. IPv6 headers are big, and if there were some way the header compressors on MN and new AR could be jump started prior to handoff, the 40 byte header overhead could be eliminated. Alternatively, if the link layer can guarantee that the F-BU/F-BACK occurs before the L2 handoff, the header overhead won't occur. Using a higher bandwidth channel could help also. Please send any comments or corrections (in case my math is wrong). jak From owner-mobile-ip@sunroof.eng.sun.com Tue May 15 11:51:07 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00850 for ; Tue, 15 May 2001 11:51:06 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA11559; Tue, 15 May 2001 08:50:41 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA07781; Tue, 15 May 2001 08:50:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4FFmA527893 for mobile-ip-dist; Tue, 15 May 2001 08:48:10 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4FFm1427886 for ; Tue, 15 May 2001 08:48:02 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id IAA03915; Tue, 15 May 2001 08:48:02 -0700 (PDT) Message-Id: <200105151548.IAA03915@heliopolis.eng.sun.com> Date: Tue, 15 May 2001 08:48:02 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Times for Low-Latency IPv6 Handoff To: mobile-ip@sunroof.eng.sun.com, Erik.Nordmark@eng.sun.com Cc: James.Kempf@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: qXvsDreSetJwPwUosZwREw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Erik, >> However, total handoff time will consist of the above plus a >> nondeterministic amount of time involved in L2 handoff and the >> amount of processing time required on new AR to perform DAD and >> process the HI/HACK pair. Perhaps one could use the maximum >> of L2 handover time and HI/HACK processing time as an estimate >> to add to the above. > >Your times assume that there is no added latency per packet imposed >e.g. by waiting for the right timeslot. >Since I know nothing about the actual radio channels I don't know >if this might be an issue. > CDMA doesn't use time slots. Walsh codes generating a particular spreading pattern are used to differentiate multiple senders/receivers, rather than assigning particular time slots. Except for wCDMA TDD (time division duplex) mode, in which the sender and receiver share the same bandwith and must duplex on it, and I don't believe that anybody is planning on deploying that in the near future. Normal wCDMA and cdma2000 use FDD, frequency division duplex, in which there are separate spectrum bands used for uplink and downlink traffic. GSM (TDMA) does use time slots, but I think the user throughput rates would include that. The number I used was for user throughput. jak From owner-mobile-ip@sunroof.eng.sun.com Tue May 15 12:34:02 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02367 for ; Tue, 15 May 2001 12:34:01 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA27052; Tue, 15 May 2001 09:33:28 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03289; Tue, 15 May 2001 09:33:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4FGVUM28000 for mobile-ip-dist; Tue, 15 May 2001 09:31:30 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4FGVL427993 for ; Tue, 15 May 2001 09:31:22 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA17210 for ; Tue, 15 May 2001 09:31:12 -0700 (PDT) Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA22215 for ; Tue, 15 May 2001 10:31:09 -0600 (MDT) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id LAA16118 for ; Tue, 15 May 2001 11:30:56 -0500 (CDT) Received: from ssd.usa.alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f4FGUuC23546 for ; Tue, 15 May 2001 11:30:56 -0500 (CDT) Received: from sun3102.ssd.usa.alcatel.com (sun3102.ssd.usa.alcatel.com [143.209.154.235]) by ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f4FGU4104376 for ; Tue, 15 May 2001 11:30:11 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by sun3102.ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f4FGU4V18573 for ; Tue, 15 May 2001 11:30:04 -0500 (CDT) Message-ID: <3B01598C.D33C4CA5@usa.alcatel.com> Date: Tue, 15 May 2001 11:30:04 -0500 From: Xiaofeng Xu X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Times for Low-Latency IPv6 Handoff References: <200105142140.OAA14556@heliopolis.eng.sun.com> Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Jak, See comments below. Xiaofeng James Kempf wrote: > > > - The radio link layer is using its lowest bit rate for signalling. > This assumption is based on either using a multiplexed common > channel for signalling, in which case the MN would have to share > the channel with other MNs in the cell, or using a dedicated > channel but not wanting to charge the user much or nothing at > all, and therefore not wanting to use a higher bandwidth. Of > course, this will be radio-specific, but it seems like a good > assumption for cellular systems. The value I used was 7.5 kbps > (940 bytes/sec), which is the minimum for a wCDMA dedicated channel > from Holma and Toskala, "WCDMA for UMTS", Wiley, 2000. > > xfxu: The handoff at mobile IP layer should be treated as traffic in stead of signalling from L2 point of view, while the L2 handoff is performed on signalling channel. From owner-mobile-ip@sunroof.eng.sun.com Tue May 15 12:43:09 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02568 for ; Tue, 15 May 2001 12:43:09 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19811; Tue, 15 May 2001 09:42:43 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA19516; Tue, 15 May 2001 09:42:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4FGf2D28052 for mobile-ip-dist; Tue, 15 May 2001 09:41:02 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4FGes428045 for ; Tue, 15 May 2001 09:40:54 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id JAA05994 for ; Tue, 15 May 2001 09:40:54 -0700 (PDT) Message-Id: <200105151640.JAA05994@heliopolis.eng.sun.com> Date: Tue, 15 May 2001 09:40:54 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Times for Low-Latency IPv6 Handoff To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Lv8zRMLJ+Sx+V4sCyOq8VA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Xiaofeng, >> >> >> - The radio link layer is using its lowest bit rate for signalling. >> This assumption is based on either using a multiplexed common >> channel for signalling, in which case the MN would have to share >> the channel with other MNs in the cell, or using a dedicated >> channel but not wanting to charge the user much or nothing at >> all, and therefore not wanting to use a higher bandwidth. Of >> course, this will be radio-specific, but it seems like a good >> assumption for cellular systems. The value I used was 7.5 kbps >> (940 bytes/sec), which is the minimum for a wCDMA dedicated channel >> from Holma and Toskala, "WCDMA for UMTS", Wiley, 2000. >> >> > >xfxu: The handoff at mobile IP layer should be treated as traffic in stead of >signalling from L2 point of view, while the L2 handoff is performed on >signalling channel. > Thanx for the comment. The throughput number here is for user data throughput so it does, in fact, reflect throughput on a traffic channel and not on a signalling channel. My comments on using a signalling channel were meant to reflect a future evolution in which mobile IP is more tightly integrated into the radio control, i.e. the all IP network. Today, the mobile IP signalling would be done on a traffic channel, as you indicate. jak From owner-mobile-ip@sunroof.eng.sun.com Tue May 15 13:46:46 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03841 for ; Tue, 15 May 2001 13:46:45 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA20554; Tue, 15 May 2001 10:43:37 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA17488; Tue, 15 May 2001 10:38:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4FHbBP28174 for mobile-ip-dist; Tue, 15 May 2001 10:37:11 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4FHb2428167 for ; Tue, 15 May 2001 10:37:02 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA16799 for ; Tue, 15 May 2001 10:36:58 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23665 for ; Tue, 15 May 2001 10:36:53 -0700 (PDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f4FHahN18695 for ; Tue, 15 May 2001 19:36:43 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue May 15 19:36:43 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 15 May 2001 19:31:43 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBE54@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Times for Low-Latency IPv6 Handoff Date: Tue, 15 May 2001 19:36:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Another important factor that must be considered is whether the individual > handoff schemes will be able to support handoff cancellation and handoff > failure. > > Handoff cancellation is the decision at L2 to cancel a handoff that has been > initiated. > > Handoff failure is the attempt at L2 to move the MN to a new L2 access > point, but failure by the MN to reach the new L2 access point. The MN then > returns to the old L2 access point for continued connectivity. > > Both handoff cancellation and handoff failure must be accomodated, since > they are already supported in existing radio access network protocols. > => Absolutely. Unfortunately this is not supported in the current Fast Handoffs draft. It is however supported in the V4 low latency draft by use of simultaneous bindings. Regards, Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue May 15 14:06:08 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04156 for ; Tue, 15 May 2001 14:06:06 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA06286; Tue, 15 May 2001 11:05:46 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA23254; Tue, 15 May 2001 11:01:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4FI0E828268 for mobile-ip-dist; Tue, 15 May 2001 11:00:14 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4FI04428261 for ; Tue, 15 May 2001 11:00:04 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA25743 for ; Tue, 15 May 2001 11:00:03 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA27818 for ; Tue, 15 May 2001 11:00:02 -0700 (PDT) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f4FI01O00283 for ; Tue, 15 May 2001 20:00:01 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Tue May 15 20:00:01 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 15 May 2001 19:55:00 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBE59@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Times for Low-Latency IPv6 Handoff Date: Tue, 15 May 2001 19:59:58 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > > > > > - The radio link layer is using its lowest bit rate for signalling. > > This assumption is based on either using a multiplexed common > > channel for signalling, in which case the MN would have to share > > the channel with other MNs in the cell, or using a dedicated > > channel but not wanting to charge the user much or nothing at > > all, and therefore not wanting to use a higher bandwidth. Of > > course, this will be radio-specific, but it seems like a good > > assumption for cellular systems. The value I used was 7.5 kbps > > (940 bytes/sec), which is the minimum for a wCDMA dedicated channel > > from Holma and Toskala, "WCDMA for UMTS", Wiley, 2000. > > > > > > xfxu: The handoff at mobile IP layer should be treated as traffic in stead of > signalling from L2 point of view, while the L2 handoff is performed on > signalling channel. > => Why ? This is really an implementation issue that is up to the system designers and should not relate to the protocol. Having said that I do see benefits in integarating the signalling of the MIP handover into the signalling channels. I don't see why this can't be done. Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue May 15 14:28:51 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04684 for ; Tue, 15 May 2001 14:28:50 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05866; Tue, 15 May 2001 11:28:27 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA00108; Tue, 15 May 2001 11:28:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4FIQ7X28336 for mobile-ip-dist; Tue, 15 May 2001 11:26:07 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4FIPw428329 for ; Tue, 15 May 2001 11:25:58 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA14526 for ; Tue, 15 May 2001 11:25:57 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA22455 for ; Tue, 15 May 2001 11:25:55 -0700 (PDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f4FIPsO04783 for ; Tue, 15 May 2001 20:25:54 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Tue May 15 20:25:53 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 15 May 2001 20:20:53 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBE5D@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] a few more FMIP comments Date: Tue, 15 May 2001 20:25:52 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > > 1) ESP friendliness: currently there is text in the > > > draft which speaks of AH headers, but nothing about > > > ESP headers. We should make the language neutral > > > as well as fix any dependencies on AH itself (beyond > > > the BU's which is a seperable issue). This may > > > require source addresses to be carried in the > > > router solicit/advertizements itself, rather > > > than expecting them to come from outer IP > > > header. Frankly, this is just good modular > > > design. > > > > > => There is not much in the MIPv6 draft either, so > > why should this be different. > > Well, unless there is some specific reason to specify AH, > it should just say "IPsec protected" or something like > that. If that's a comment against the -13 draft as well, > so much the better. > => Wait a minute :) we already discussed this before San Diego and the consensus was that we should only mention AH. Francis Dupont had several reasons back then that we should at least revisit before reissuing the comments. > > > 2) I have a question as to whether anybody > > > considered combining the Proxy Router > > > Solicit functionality with the binding > > > update for the mobile initiated handoff. > > > Considering the mobile is probably moving > > > out of range, this seems like it's a > > > pretty critical time and the fewer > > > messages required, the better. As a > > > > > => A BU to where ? unless you get the proxy > > RA you don't know where you're going > > so what do you bind the address to ? > > Correct. It would require that the BU be able to > have a mode which allows ARold to pick the new > CoA (possibly by the HI/HACK). It could transport > the picked address back in the Alternate CoA in > the BU. It would sort of be like a DHCP request :-) > => Yes but the semantics of the BU do not allow that. what you're describing really isn't a "binding" in anyway, so I'm not sure if it should be a BU. > > Do you think it should be used that way ? > > It does seem that combining the functionality > gives better on-the-air messaging. As I said earlier, > the number of messages right before it hands over, > => Not really. It's the same amount of information, just sent in larger packets. So the problems are the same. Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue May 15 14:38:32 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04888 for ; Tue, 15 May 2001 14:38:31 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17282; Tue, 15 May 2001 11:37:55 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA18486; Tue, 15 May 2001 11:36:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4FIVs928372 for mobile-ip-dist; Tue, 15 May 2001 11:31:54 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4FIVO428365 for ; Tue, 15 May 2001 11:31:25 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA03711 for ; Tue, 15 May 2001 11:31:15 -0700 (PDT) Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA19003 for ; Tue, 15 May 2001 12:31:14 -0600 (MDT) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id NAA23517 for ; Tue, 15 May 2001 13:30:58 -0500 (CDT) Received: from ssd.usa.alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f4FIUvT18954 for ; Tue, 15 May 2001 13:30:57 -0500 (CDT) Received: from sun3102.ssd.usa.alcatel.com (sun3102.ssd.usa.alcatel.com [143.209.154.235]) by ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f4FIUO117903 for ; Tue, 15 May 2001 13:30:24 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by sun3102.ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f4FIUOV18595 for ; Tue, 15 May 2001 13:30:24 -0500 (CDT) Message-ID: <3B0175C0.956BFD80@usa.alcatel.com> Date: Tue, 15 May 2001 13:30:24 -0500 From: Xiaofeng Xu X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Times for Low-Latency IPv6 Handoff References: <034BEFD03799D411A59F00508BDF7546013DBE59@esealnt448.al.sw.ericsson.se> Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Hesham Soliman (ERA)" wrote: > > > > > > > > > - The radio link layer is using its lowest bit rate for signalling. > > > This assumption is based on either using a multiplexed common > > > channel for signalling, in which case the MN would have to share > > > the channel with other MNs in the cell, or using a dedicated > > > channel but not wanting to charge the user much or nothing at > > > all, and therefore not wanting to use a higher bandwidth. Of > > > course, this will be radio-specific, but it seems like a good > > > assumption for cellular systems. The value I used was 7.5 kbps > > > (940 bytes/sec), which is the minimum for a wCDMA dedicated channel > > > from Holma and Toskala, "WCDMA for UMTS", Wiley, 2000. > > > > > > > > > > xfxu: The handoff at mobile IP layer should be treated as traffic in stead of > > signalling from L2 point of view, while the L2 handoff is performed on > > signalling channel. > > > => Why ? This is really an implementation issue that is up > to the system designers and should not relate to the protocol. > Having said that I do see benefits in integarating the > signalling of the MIP handover into the signalling channels. > I don't see why this can't be done. > > Hesham xfxu: you are mixing L3 signalling with L2 signalling. Logically don't do that. From owner-mobile-ip@sunroof.eng.sun.com Tue May 15 14:40:46 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04933 for ; Tue, 15 May 2001 14:40:44 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19511; Tue, 15 May 2001 11:39:54 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA05817; Tue, 15 May 2001 11:39:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4FIXRI28389 for mobile-ip-dist; Tue, 15 May 2001 11:33:27 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4FIX7428382 for ; Tue, 15 May 2001 11:33:08 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA16397 for ; Tue, 15 May 2001 11:33:04 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11557 for ; Tue, 15 May 2001 11:33:02 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f4FIVXt20575 for ; Tue, 15 May 2001 11:31:35 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AFY01144; Tue, 15 May 2001 11:32:59 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA03156; Tue, 15 May 2001 11:32:59 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15105.30299.450033.687185@thomasm-u1.cisco.com> Date: Tue, 15 May 2001 11:32:59 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Times for Low-Latency IPv6 Handoff In-Reply-To: <200105142140.OAA14556@heliopolis.eng.sun.com> References: <200105142140.OAA14556@heliopolis.eng.sun.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit James Kempf writes: [nice analysis deleted] > What conclusions to draw? These time range from respectible (55 ms > for network determined, stateful) to the clearly questionable (198 ms for > mobile determined, F-BU/F-BACK sent after). The ITU recommends 300 ms > maximum for delay before the user notices with real time voice traffic. > Depending on the amount of time required for the L2 handover, the HI/HACK > processing time, and any time required to send buffered traffic to > the MN if buffering is used on the old AR, the mobile determined, F-BU/F-BACK > sent after case could easily exceed the ITU guideline, as almost 2/3 > of the noticable delay time is taken up by the L3 handoff. The others > require less L3 handoff time, but only the network determined, stateless, > F-BU/F-BACK before and the network determined, stateful are less than > or equal to about 1/4 of the ITU guideline. This sort of gets back to my point earlier that it may worth combining the functionality of the RtSolPr with the BU itself. > Clearly, header compression on the new AR could help a lot. IPv6 headers > are big, and if there were some way the header compressors on MN and new AR > could be jump started prior to handoff, the 40 byte header overhead could be > eliminated. Alternatively, if the link layer can guarantee that > the F-BU/F-BACK occurs before the L2 handoff, the header overhead won't > occur. Using a higher bandwidth channel could help also. I'm not entirely sure I believe this... in general if the BU doesn't happen on the old AR, you're already in trouble. How much more trouble the lack of compression causes doesn't seem like it's all *that* significant[*]. If you had to put energy into something here, making this situation less likely would certainly be better. [*] it obviously should be pointed out that the significance is mainly an attribute of your 9600 baud connection. In an all-IP universe, that would probably not be a good assumption. Whether it's significant given the messy details of our current mixed IP/TDM universe isn't as clear... the current techology is clearly not all that IP friendly, so I'm not sure how much weight I'd place on the here and now if IP carriage is more valued going forward. Mike From owner-mobile-ip@sunroof.eng.sun.com Tue May 15 14:52:28 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05097 for ; Tue, 15 May 2001 14:52:26 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03950; Tue, 15 May 2001 11:51:46 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA05736; Tue, 15 May 2001 11:51:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4FInXC28538 for mobile-ip-dist; Tue, 15 May 2001 11:49:33 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4FInO428531 for ; Tue, 15 May 2001 11:49:24 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08432 for ; Tue, 15 May 2001 11:49:23 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA29160 for ; Tue, 15 May 2001 12:48:46 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f4FIj8d00880 for ; Tue, 15 May 2001 11:45:08 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AFY01611; Tue, 15 May 2001 11:45:08 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA03161; Tue, 15 May 2001 11:45:07 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15105.31027.709815.127309@thomasm-u1.cisco.com> Date: Tue, 15 May 2001 11:45:07 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] a few more FMIP comments In-Reply-To: <034BEFD03799D411A59F00508BDF7546013DBE5D@esealnt448.al.sw.ericsson.se> References: <034BEFD03799D411A59F00508BDF7546013DBE5D@esealnt448.al.sw.ericsson.se> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hesham Soliman (ERA) writes: > > Well, unless there is some specific reason to specify AH, > > it should just say "IPsec protected" or something like > > that. If that's a comment against the -13 draft as well, > > so much the better. > > > => Wait a minute :) we already discussed this before > San Diego and the consensus was that we should only > mention AH. Francis Dupont had several reasons > back then that we should at least revisit before > reissuing the comments. You're talking about the -13 draft here, I assume. If I recall correctly at San Diego, there was some discussion (I think I even instigated some of it), but I don't recall that there was a resolution. I think that I've got all of the cases covered in my ESP draft now and will submit it, so hopefully Francis can chime in if I forgot something. > > Correct. It would require that the BU be able to > > have a mode which allows ARold to pick the new > > CoA (possibly by the HI/HACK). It could transport > > the picked address back in the Alternate CoA in > > the BU. It would sort of be like a DHCP request :-) > > > => Yes but the semantics of the BU do not allow > that. what you're describing really isn't a "binding" > in anyway, so I'm not sure if it should be a BU. Yes, I agree it's sort of messy, but this is one of the problems that modularity poses when you need to be fast. I'll see if I can't come up with some reasons why this isn't a generally useful mechanism for BU's so that it doesn't look like a hack. > > It does seem that combining the functionality > > gives better on-the-air messaging. As I said earlier, > > the number of messages right before it hands over, > > > => Not really. It's the same amount of information, > just sent in larger packets. So the problems are > the same. Possibly, but that depends on whether you can get L2 blocking. If not, you might have to wait for a second transmission opportunity. Jim's analysis is pertinent here, I think. The answer to the L2 blocking question is probably the right thing to find out now, and then plug it back into Jim's model. Mike From owner-mobile-ip@sunroof.eng.sun.com Tue May 15 16:04:32 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06040 for ; Tue, 15 May 2001 16:04:31 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA23906; Tue, 15 May 2001 13:04:08 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA07759; Tue, 15 May 2001 13:03:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4FK1LF28699 for mobile-ip-dist; Tue, 15 May 2001 13:01:21 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4FK1C428692 for ; Tue, 15 May 2001 13:01:12 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA05743 for ; Tue, 15 May 2001 13:01:11 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA20232 for ; Tue, 15 May 2001 13:01:06 -0700 (PDT) Received: from msubbara-u10.cisco.com (msubbara-u10.cisco.com [64.102.66.20]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f4FK16927665 for ; Tue, 15 May 2001 13:01:06 -0700 (PDT) Received: (msubbara@localhost) by msubbara-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA01945 for mobile-ip@sunroof.eng.sun.com; Tue, 15 May 2001 16:00:28 -0400 (EDT) Date: Tue, 15 May 2001 16:00:28 -0400 From: Madhavi Subbarao To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: mobile-ip] Re: mobile-ip] Multiple flows with single NAI Message-ID: <20010515160028.C1910@cisco.com> References: <85AA7486A2C1D411BCA20000F8073E43023082A8@crchy271.us.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <85AA7486A2C1D411BCA20000F8073E43023082A8@crchy271.us.nortel.com>; from gmorrow@nortelnetworks.com on Mon, May 14, 2001 at 10:15:03AM -0500 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Mon, May 14, 2001 at 10:15:03AM -0500, Glenn Morrow wrote: > There is nothing wrong with allowing multiple devices to use the same NAI. I > wouldn't call it a user address, though. I would call it a subscription > identifier. I know this could be construed as a semantics thing but user > address just brings up the wrong concoction of what it should really be used > for. Agreed. We are interpreting the NAI in the same way as you describe for 'subsription ID'. > > NAI is a generic definition that can be used to identify almost anything. > MIP specifications need to be explicit in what fields which use the NAI form > mean and in what context, IMO. > > On PAT's question about each device having it's own NAIs - you can. But if > you enforce this (i.e. no two devices can use the same NAI) then you've > essentially begun using the NAI as a device identifier. Exactly. The idea is to keep the NAI as a user/subscription ID and authenticate based on the NAI as usual, and then identify the devices based on another ID...Device/Binding ID. > Perhaps we need a device identifier which uses the NAI form, as well, to > allow the HAs to blacklist known fraudulent devices? Well, the Device/Binding ID could indeed be a 'globally' unique identifier similar to the NAI form (although I'm not sure how you guarantee uniqueness). As I mentioned on another email in this thread, there are several choices on how to define the Device/Binding ID. Glenn, did you have any thoughts on those formats? > Maybe we need more than one field, (user, subscription, device) that use the > NAI form? Subscription ID = NAI as is today, Device ID = Device/Binding ID to be defined...so what's 'User ID'? Why you feel we need another level of identification? > I wouldn't define user in MIP because there are simply some user mobility > functions that can't be solved at layer 3 - again the wrong concoction. > > Another option would be to do something like > user.subscription.device@whatever.com but then you get into coupled business > models i.e. the application provider must be the network service provider or > have a special directory updating arrangement etc.. - not exactly the > WWW-way. I'm not sure we need to get that detailed or coupled. -Madhavi > > Glenn > > > -----Original Message----- > From: Gopal Dommety [mailto:gdommety@cisco.com] > Sent: Friday, May 11, 2001 4:20 PM > To: mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Re: mobile-ip] Multiple flows with single NAI > > > At 09:10 AM 5/11/2001 -0700, Pat Calhoun wrote: > >On Fri, May 11, 2001 at 12:13:33PM -0400, Madhavi Subbarao wrote: > > > > > > The FA should maintain pending registrations by > > > (USER NAI, Binding ID)...because it cannot rely just on NAI for > > > identification anymore. > > > >I've been disconnected from this thread since it began, but have one > >question that may have already been asked. > > > >Why can't a device have a single NAI per binding? This seems like a > >simple approach, and doesn't require any protocol changes. > > Pat, > > What the operators want is to be able to have a single NAI and allow > multiple devices to > be on the network at the same time based on that NAI. Basically the same > security Key, and > possibly accounting will be used for all of the devices. In order to > distinguish one device from > another during registration/address allocation, we need the Binding ID. > > One way of solving the problem is , as you suggested, by using different > NAIs. The reason that the operators > do not want to do that is that of operations, management, and billing. > Since all these devices are with the > same account, they want to have one NAI, one Key, and billing etc. > > This operator request is similar to that of in the dial-up world of having > multiple sessions. In that space people > use the NAS Port to be able to distinguish (I am sure you are aware of the > ugliness of this solution). > > Thanks > Gopal > > > > >PatC > From owner-mobile-ip@sunroof.eng.sun.com Tue May 15 16:36:27 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06434 for ; Tue, 15 May 2001 16:36:26 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01444; Tue, 15 May 2001 13:36:10 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA14478; Tue, 15 May 2001 13:34:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4FKWda28775 for mobile-ip-dist; Tue, 15 May 2001 13:32:39 -0700 (PDT) Received: from centralmail1.Central.Sun.COM (centralmail1.Central.Sun.COM [129.147.62.10]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4FKWU428768 for ; Tue, 15 May 2001 13:32:30 -0700 (PDT) Received: from sr-uita01-01.Central.Sun.COM (sr-uita01-01.Central.Sun.COM [129.153.224.5]) by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA23399 for ; Tue, 15 May 2001 14:32:28 -0600 (MDT) Received: (from glass@localhost) by sr-uita01-01.Central.Sun.COM (8.10.2+Sun/8.10.2) id f4FKWRK21039 for mobile-ip@sunroof.eng.sun.com; Tue, 15 May 2001 15:32:27 -0500 (CDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4ECbu425327 for ; Mon, 14 May 2001 05:37:57 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA24722 for ; Mon, 14 May 2001 05:37:56 -0700 (PDT) Received: from david.ttt.bme.hu (david.ttt.bme.hu [152.66.246.102]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA29827 for ; Mon, 14 May 2001 05:37:55 -0700 (PDT) Received: from ttt-atm.ttt.bme.hu (ttt-atm.ttt.bme.hu [152.66.246.81]) by david.ttt.bme.hu (8.9.1/8.9.1) with ESMTP id OAA20994; Mon, 14 May 2001 14:37:43 +0200 (MET DST) Received: from TTT-ATM/SpoolDir by ttt-atm.ttt.bme.hu (Mercury 1.48); 14 May 01 14:44:43 +0100 Received: from SpoolDir by TTT-ATM (Mercury 1.48); 14 May 01 14:44:14 +0100 Received: from ttt-atm.ttt.bme.hu (152.66.246.28) by ttt-atm.ttt.bme.hu (Mercury 1.48) with ESMTP; 14 May 01 14:43:46 +0100 Message-ID: <3AFFD29F.3C59A90E@ttt-atm.ttt.bme.hu> Date: Mon, 14 May 2001 14:42:07 +0200 From: Sandor Molnar Organization: Technical University of Budapest X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: manet@itd.nrl.navy.mil, mobile-ip@sunroof.eng.sun.com, te-wg@ops.ietf.org, diffserv@ietf.org, ippm@advanced.org Subject: [mobile-ip] MONET cfp on Performance Evaluation of Qos Architectures in Mobile Networks Content-Type: multipart/mixed; boundary="------------24A067880866993C333B344C" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. --------------24A067880866993C333B344C Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by patan.sun.com id NAA01444 Content-Transfer-Encoding: quoted-printable Our apologies, if you receive multiple copies of this CfP. --------------------------------------------------------------------- CALL FOR PAPERS Special Issue of the Journal on Special Topics in Mobile Networking and Applications (MONET) on Performance Evaluation of Qos Architectures in Mobile Networks GUEST EDITORS Dr. S=E1ndor Moln=E1r High Speed Networks Laboratory Dept. of Telecommunication and Telematics Budapest University of Technology and Economics P=E1zm=E1ny P=E9ter s. 1/D, H-1117 Budapest, Hungary Phone: +36 1 463 3889 Fax: +36 1 463 3107 Email: molnar@ttt-atm.ttt.bme.hu Dr. Kin K. Leung AT&T Labs, Room 5A-1D35 200 South Laurel Avenue Middletown, NJ 07748, U.S.A. phone: 732-420-9041 fax: 732-368-9426 email: kkleung@research.att.com OVERVIEW: Future mobile networks are being designed for carrying multimedia calls, including voice and bursty data transmission. Many studies have predicted a large increase of customer demands for the mobile services and applications in the near future. To meet these demands with adequate Quality of Services (QoS), we must devise efficient network and service architectures. In contrast to the wired networks, there is not enough understanding or availability of traffic characteristics, measurements, performance analysis and models for mobile networks. However, such understanding of teletraffic issues is vital for designing and dimensioning efficient mobile networks. These networks will incorporate different networking technologies, control algorithms and versatile services. How to guarantee the required QoS of mobile services as expected by customers, using present and future technologies, presents a real challenge for mobile-network researchers. SCOPE: This special issue will concentrate on the performance evaluation of different architectures supporting QoS in mobile networks, and the traffic issues and performance models in such environments. Areas of interest include but are not limited to * Performance evaluation of wireless ATM, wireless LANs, wireless Internet and Intranet mobile IP and nomadic communications next generation mobile systems, UMTS and IMT-2000 mobile multimedia and mobile personal communication * Resource management, dynamic channel and bandwidth assignment * Quality of Service and Service Level Guarantees in mobile systems * Admission Control in mobile networks * Models of mobile user traffic generation * Traffic measurements and analysis of mobile networks * Traffic models in mobile networks * Mobility management protocols and performance * Internetworking of wireless and wired networks for QoS PUBLICATION SCHEDULE: MANUSCRIPT DUE: October 31, 2001=20 ACCEPTANCE NOTIFICATION: March 29, 2002=20 FINAL MANUSCRIPT DUE: May 31, 2002=20 SUBMISSION GUIDELINES: Authors should submit an electronic postscript or pdf copy of their papers to both guest editors (molnar@ttt-atm.ttt.bme.hu, kkleung@research.att.com) by the due date. Submissions should be limited to 20 double space pages excluding figures, graphs and illustrations.=20 If email submission is impossible, then three (3) copies of the paper should be sent by the due date to each of the co-guest editors. For more information visit: http://www.wkap.nl/kaphtml.htm/MONECFP4 --------------24A067880866993C333B344C Content-Type: text/x-vcard; charset=us-ascii; name="molnar.vcf" Content-Description: Card for Sandor Molnar Content-Disposition: attachment; filename="molnar.vcf" X-MIME-Autoconverted: from 8bit to quoted-printable by patan.sun.com id NAA01444 Content-Transfer-Encoding: quoted-printable begin:vcard=20 n:Moln=E1r;S=E1ndor tel;fax:+ 36 1 463 3107 tel;work:+ 36 1 463 3889 x-mozilla-html:FALSE url:http://hsnlab.ttt.bme.hu/~molnar org:Budapest University of Technology and Economics;Department of Telecom= munications and Telematics adr:;;P=E1zm=E1ny P=E9ter s=E9t=E1ny 1/D;Budapest;;H-1117;Hungary version:2.1 email;internet:molnar@ttt-atm.ttt.bme.hu title:Assistant Professor x-mozilla-cpt:;-1 fn:Dr. S=E1ndor Moln=E1r end:vcard --------------24A067880866993C333B344C-- From owner-mobile-ip@sunroof.eng.sun.com Tue May 15 16:57:10 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06961 for ; Tue, 15 May 2001 16:57:09 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA07672; Tue, 15 May 2001 13:56:33 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA18646; Tue, 15 May 2001 13:52:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4FKoKs28858 for mobile-ip-dist; Tue, 15 May 2001 13:50:20 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4FKoB428851 for ; Tue, 15 May 2001 13:50:11 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA06272 for ; Tue, 15 May 2001 13:50:10 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06897 for ; Tue, 15 May 2001 13:50:09 -0700 (PDT) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f4FKo8O26366 for ; Tue, 15 May 2001 22:50:08 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Tue May 15 22:50:08 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 15 May 2001 22:50:08 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBE61@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Times for Low-Latency IPv6 Handoff Date: Tue, 15 May 2001 22:50:07 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > > > - The radio link layer is using its lowest bit rate for signalling. > > > > This assumption is based on either using a multiplexed common > > > > channel for signalling, in which case the MN would have to share > > > > the channel with other MNs in the cell, or using a dedicated > > > > channel but not wanting to charge the user much or nothing at > > > > all, and therefore not wanting to use a higher bandwidth. Of > > > > course, this will be radio-specific, but it seems like a good > > > > assumption for cellular systems. The value I used was 7.5 kbps > > > > (940 bytes/sec), which is the minimum for a wCDMA dedicated channel > > > > from Holma and Toskala, "WCDMA for UMTS", Wiley, 2000. > > > > > > > > > > > > > > xfxu: The handoff at mobile IP layer should be treated as traffic in stead of > > > signalling from L2 point of view, while the L2 handoff is performed on > > > signalling channel. > > > > > => Why ? This is really an implementation issue that is up > > to the system designers and should not relate to the protocol. > > Having said that I do see benefits in integarating the > > signalling of the MIP handover into the signalling channels. > > I don't see why this can't be done. > > > > Hesham > > xfxu: you are mixing L3 signalling with L2 signalling. > => No I'm not mixing L2 and L3 signalling. I'm sending L3 signalling on a different channel. > Logically don't do that. > => Logically ? why ? Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue May 15 17:15:20 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07330 for ; Tue, 15 May 2001 17:15:20 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA21337; Tue, 15 May 2001 14:14:59 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA12408; Tue, 15 May 2001 14:14:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4FLCoe28935 for mobile-ip-dist; Tue, 15 May 2001 14:12:50 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4FLCg428928 for ; Tue, 15 May 2001 14:12:42 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA11874 for ; Tue, 15 May 2001 14:12:38 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA17205 for ; Tue, 15 May 2001 15:12:46 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f4FLCY920304 for ; Tue, 15 May 2001 14:12:34 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AFY05987; Tue, 15 May 2001 14:12:33 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA03213; Tue, 15 May 2001 14:12:33 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15105.39873.498301.14350@thomasm-u1.cisco.com> Date: Tue, 15 May 2001 14:12:33 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] host routes in the fast mipv6 draft In-Reply-To: <200105150101.f4F11eu360360@jurassic.eng.sun.com> References: <200105150101.f4F11eu360360@jurassic.eng.sun.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Alper Yegin writes: > > In either case, however, ARold needs > > to place the route in its database as well as > > ARnew. Otherwise, it will keep routing the > > packets out the old (wireless) interface as > > normal, which is obviously not what you'd want. > > Whether packets destined to oldCoA are tunneled to newCoA or newAR, there needs > to be a state on oldAR. Something like "send all packets destined to oldCoA > through tunnel100". In one case tunnel100's end point will be newCoA, in other > newAR. Alper, Understand that I wasn't on the design team, so I'm looking at this sort of like an outside reader would look at it. I didn't see where/how the tunnel would be terminated on ARnew in the draft. Did I miss something? This would be new functionality in ipv6 since it sounds like it's mimicing v4 FA functionality. Mike From owner-mobile-ip@sunroof.eng.sun.com Tue May 15 17:17:14 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07360 for ; Tue, 15 May 2001 17:17:13 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA23036; Tue, 15 May 2001 14:17:10 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA08830; Tue, 15 May 2001 14:17:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4FLEqr28960 for mobile-ip-dist; Tue, 15 May 2001 14:14:52 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4FLEW428953 for ; Tue, 15 May 2001 14:14:33 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA08331 for ; Tue, 15 May 2001 14:14:32 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA07890 for ; Tue, 15 May 2001 14:14:27 -0700 (PDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f4FLEPN23228 for ; Tue, 15 May 2001 23:14:25 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Tue May 15 23:14:24 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 15 May 2001 23:14:25 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBE62@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Times for Low-Latency IPv6 Handoff Date: Tue, 15 May 2001 23:14:24 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: James, A couple of comments below. > - The radio link layer is using its lowest bit rate for signalling. > This assumption is based on either using a multiplexed common > channel for signalling, in which case the MN would have to share > the channel with other MNs in the cell, or using a dedicated > channel but not wanting to charge the user much or nothing at > all, and therefore not wanting to use a higher bandwidth. Of > course, this will be radio-specific, but it seems like a good > assumption for cellular systems. The value I used was 7.5 kbps > (940 bytes/sec), which is the minimum for a wCDMA dedicated channel > from Holma and Toskala, "WCDMA for UMTS", Wiley, 2000. > => I thought the WCDMA specs says 15kbps (uplink) for a DPDCH (Dedicated Physical Data CHannel). Did you divide by 2 for a reason ? > > However, total handoff time will consist of the above plus a > nondeterministic amount of time involved in L2 handoff > => Not necessarily. They could happen simultaneously. There is also the L2 delays over the air that should be added. That is the big delay I believe. > and the > amount of processing time required on new AR to perform DAD and > process the HI/HACK pair. > => your figures are based on WCDMA. In this case there is no DAD. Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue May 15 17:28:44 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07563 for ; Tue, 15 May 2001 17:28:43 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA03708; Tue, 15 May 2001 14:28:33 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA25797; Tue, 15 May 2001 14:27:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4FLNnf29028 for mobile-ip-dist; Tue, 15 May 2001 14:23:49 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4FLNV429021 for ; Tue, 15 May 2001 14:23:31 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id OAA16592 for ; Tue, 15 May 2001 14:23:31 -0700 (PDT) Message-Id: <200105152123.OAA16592@heliopolis.eng.sun.com> Date: Tue, 15 May 2001 14:23:31 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] host routes in the fast mipv6 draft To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: sL1FBtsyli7oJCjmn6rjAg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Mike & Alper, > >Alper Yegin writes: > > > In either case, however, ARold needs > > > to place the route in its database as well as > > > ARnew. Otherwise, it will keep routing the > > > packets out the old (wireless) interface as > > > normal, which is obviously not what you'd want. > > > > Whether packets destined to oldCoA are tunneled to newCoA or newAR, there needs > > to be a state on oldAR. Something like "send all packets destined to oldCoA > > through tunnel100". In one case tunnel100's end point will be newCoA, in other > > newAR. > >Alper, > >Understand that I wasn't on the design team, so >I'm looking at this sort of like an outside reader >would look at it. I didn't see where/how the >tunnel would be terminated on ARnew in the draft. >Did I miss something? This would be new >functionality in ipv6 since it sounds like it's >mimicing v4 FA functionality. > The draft is very unclear about how and when tunnels are set up. The term "host route" is used to refer to a tunnel being set up. I've actually never heard the term host route used in this fashion. Typically, a host route means "even though the dest address doesn't match the subnet structure topologically, route the packet this way." With a tunnel, the dest address will always be topologically correct. jak From owner-mobile-ip@sunroof.eng.sun.com Tue May 15 17:32:29 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07633 for ; Tue, 15 May 2001 17:32:28 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA03759; Tue, 15 May 2001 14:31:43 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA15737; Tue, 15 May 2001 14:29:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4FLQaI29048 for mobile-ip-dist; Tue, 15 May 2001 14:26:36 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4FLQ4429041 for ; Tue, 15 May 2001 14:26:05 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id OAA16647 for ; Tue, 15 May 2001 14:26:05 -0700 (PDT) Message-Id: <200105152126.OAA16647@heliopolis.eng.sun.com> Date: Tue, 15 May 2001 14:26:05 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] Times for Low-Latency IPv6 Handoff To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: DjSConOCHGRtXjM3tGk1BQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Hesham, > There is also the L2 delays over the air that should be > added. That is the big delay I believe. > I'm not sure I understand what you mean. Do you mean the amount of time during handoff in which the mobile is listening to the pilot and exchanging frames at L2 before it decides that the signal quality is high enough to declare that L2 handoff is complete? At which point it would start sending user L3 traffic again? Or do you mean something else? jak From owner-mobile-ip@sunroof.eng.sun.com Tue May 15 17:39:49 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07730 for ; Tue, 15 May 2001 17:39:48 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA09313; Tue, 15 May 2001 14:39:35 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA28076; Tue, 15 May 2001 14:37:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4FLa0k29174 for mobile-ip-dist; Tue, 15 May 2001 14:36:00 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4FLZp429167 for ; Tue, 15 May 2001 14:35:51 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA13084 for ; Tue, 15 May 2001 14:35:52 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA26587 for ; Tue, 15 May 2001 14:35:49 -0700 (PDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f4FLZjO02639 for ; Tue, 15 May 2001 23:35:45 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Tue May 15 23:35:44 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 15 May 2001 23:35:45 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBE65@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Times for Low-Latency IPv6 Handoff Date: Tue, 15 May 2001 23:35:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi James, > > There is also the L2 delays over the air that should be > > added. That is the big delay I believe. > > > > I'm not sure I understand what you mean. Do you mean the amount of > time during handoff in which the mobile is listening to the pilot and > exchanging frames at L2 before it decides that the signal quality > is high enough to declare that L2 handoff is complete? At which > point it would start sending user L3 traffic again? Or do you > mean something else? > => Sorry, I wasn't very clear. I meant that you calculated the transmission delay (no of bits / bit rate), but there is also the delays in coding and sending the data over the air and getting an Ack (on the radio level). I suspect that is it comparable with the transmission delay based on the worste case scenario. Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue May 15 17:50:43 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07955 for ; Tue, 15 May 2001 17:50:42 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA17266; Tue, 15 May 2001 14:50:42 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA21219; Tue, 15 May 2001 14:50:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4FLmwi29279 for mobile-ip-dist; Tue, 15 May 2001 14:48:58 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4FLml429272 for ; Tue, 15 May 2001 14:48:50 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id OAA17507 for ; Tue, 15 May 2001 14:48:48 -0700 (PDT) Message-Id: <200105152148.OAA17507@heliopolis.eng.sun.com> Date: Tue, 15 May 2001 14:48:48 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] Times for Low-Latency IPv6 Handoff To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: dWE3cDwgRF3l0XlIbCPCBg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Hesham, >> > => Sorry, I wasn't very clear. I meant that you calculated > the transmission delay (no of bits / bit rate), but there > is also the delays in coding and sending the data over > the air and getting an Ack (on the radio level). I suspect > that is it comparable with the transmission delay based > on the worste case scenario. > Actually, I used the user data throughput numbers from Holma and Toskala, on pg. 90 for half rate coding at various spreading factors and channel rates. I presume they've included coding, spreading, and Ack delay in the user data figures. jak From owner-mobile-ip@sunroof.eng.sun.com Tue May 15 18:49:03 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA08599 for ; Tue, 15 May 2001 18:49:02 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA29301; Tue, 15 May 2001 15:48:58 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA05114; Tue, 15 May 2001 15:48:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4FMl7s29385 for mobile-ip-dist; Tue, 15 May 2001 15:47:07 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4FMkx429378 for ; Tue, 15 May 2001 15:46:59 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA13794 for ; Tue, 15 May 2001 15:47:00 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02835 for ; Tue, 15 May 2001 15:46:57 -0700 (PDT) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f4FMl5g20479 for ; Tue, 15 May 2001 17:47:05 -0500 (CDT) Received: from daebh01nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 15 May 2001 17:46:58 -0500 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Tue, 15 May 2001 17:46:57 -0500 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B03213A19@daeis07nok> To: mobile-ip@sunroof.eng.sun.com Subject: FW: [mobile-ip] Times for Low-Latency IPv6 Handoff Date: Tue, 15 May 2001 17:46:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Forwarding to list since he is not registered. > -----Original Message----- > From: Kularatna Shavantha (NET-TDMA/Dallas) > Sent: Tuesday, May 15, 2001 12:39 PM > To: Patil Basavaraj (NET/Dallas) > Subject: RE: [mobile-ip] Times for Low-Latency IPv6 Handoff > > > Hi Raj > > At least on the downlink the signaling channel is > 3.4k. Hence the time for each of the messages roughly > double. But, this not a problem as in UMTS DCH multiplexes > speech and signaling together. Hence, the above 3.4k is > accounted while full rate AMR max (12.2K) is there. Since > both are simultaneous there should not be any interruption of > speech service while the signaling is exchanged. This normally > not the case in TDMA case where speech is interrupted by handoff > messages. > > Cheers, > > Sha. > > > > >> -----Original Message----- > >> From: ext James Kempf [mailto:James.Kempf@Sun.COM] > >> Sent: Monday, May 14, 2001 4:40 PM > >> To: mobile-ip@sunroof.eng.sun.com > >> Subject: [mobile-ip] Times for Low-Latency IPv6 Handoff > >> > >> > >> As an interesting exercise, I went through some calculations > >about how > >> long an IPv6 low latency handoff would take in some of the > scenerios > >> described in draft-ietf-mobileip-fast-mipv6-01.txt. I looked at the > >> following cases: > >> > >> - Network determined, stateless with the following two subcases: > >> - F-BU/F-BACK received before handoff > >> - F-BU/F-BACK received after handoff > >> > >> - Network deterimed, stateful > >> > >> - Mobile determined, with the following two subcases: > >> - F-BU/F-BACK received before handoff > >> - F-BU/F-BACK received after handoff > >> > >> I also made the following assumptions: > >> > >> - Prior to handoff, the header compressor on the old AR is > >> "hot" enough to compress the basic 40 byte IPv6 header down > >> to 1 byte, but after handoff, the header compressor is "cold" > >> and so the full IPv6 header needs to be sent. Currently, there > >> is some debate about whether the compressor could be partially > >> restarted on the new AR using context transfer, so this could > >> introduce an additional optimization and also a potential > >> area of timing uncertainty involving the context transfer > >> time itself. > >> > >> - The BU/BACK pair completes on either side of the handoff. > >> In actuality, it may span the handoff and Section 3.3 may > >> come into play if the MN doesn't get a BACK back (so to > >> speak) fast enough. Or, an additional BU may need to be sent. > >> I view the assumptions made here as being fairly optimistic, > >> since over the air signalling after L2 has indicated that > >> handover is pending is likely to be subject to a considerably > >> higher error rate due to deteriorating radio conditions in > >> the old cell and not-yet improved radio conditions in the new. > >> > >> - The radio link layer is using its lowest bit rate for > >> signalling. > >> This assumption is based on either using a multiplexed common > >> channel for signalling, in which case the MN would have to share > >> the channel with other MNs in the cell, or using a dedicated > >> channel but not wanting to charge the user much or nothing at > >> all, and therefore not wanting to use a higher bandwidth. Of > >> course, this will be radio-specific, but it seems like a good > >> assumption for cellular systems. The value I used was 7.5 kbps > >> (940 bytes/sec), which is the minimum for a wCDMA > >> dedicated channel > >> from Holma and Toskala, "WCDMA for UMTS", Wiley, 2000. > >> > >> - The wired link ARs use Ethernet (48 bit MAC address link > >> layer) and the wireless link is using 15 byte IMSIs > >> (International > >> Mobile Station Identifiers) sent as ASCII digits. > >> > >> - The MN can neither send or receive traffic on the new AR until > >> the old AR has confirmed the new CoA via a F-BACK. > >> > >> Here's the results. > >> > >> Network Determined, Stateless > >> ----------------------------- > >> > >> As near as I can tell, the following messages get > exchanged over the > >> air: PrRtAdv, F-BU, F-BACK. > >> > >> Sizes of these are: > >> > >> hdr msg lnkAddrOpt prxLnkAddrOpt > newCoA Total > >> > >> PrRtAdv 1 8 9 9 24 > 51 > >> > >> F-BU > >> before 1 10 > 11 > >> > >> F-BU > >> after 40 10 > 50 > >> > >> F-BACK > >> before 1 9 > >> 10 > >> > >> F-BACK > >> after 40 9 > 49 > >> > >> Total over the air sizes: > >> > >> F-BU/F-BACK before: 51 + 11 + 10 = 72 bytes > >> F-BU/F-BACK after: 51 + 50 + 49 = 150 bytes > >> > >> Times: > >> > >> F-BU/F-BACK before: 72 bytes / 940 bytes/sec = 0.077 sec = 77 msec. > >> F-BU/F-BACK after: 150 bytes/ 940 bytes/sec = 0.160 sec = > 160 msec. > >> > >> However, total handoff time will consist of the above plus a > >> nondeterministic amount of time involved in L2 handoff and the > >> amount of processing time required on new AR to perform DAD and > >> process the HI/HACK pair. Perhaps one could use the maximum > >> of L2 handover time and HI/HACK processing time as an estimate > >> to add to the above. > >> > >> Network Determined, Stateful > >> ---------------------------- > >> > >> Messages exchanged over the air- PrRtAdv prior to handoff. > >> > >> Byte counts the same as the above. No F-BU/F-BACK needed, so the > >> only over the air message required is the PrRtAdv. > >> > >> Total over the air size: > >> > >> PrRtAdv size: 51 bytes > >> > >> Time: > >> > >> 51 bytes/ 940 bytes/sec = 0.054 sec = 54 msec. > >> > >> L2 handover time needs to be added. > >> > >> Mobile Determined > >> ----------------- > >> > >> Messages exchanged over the air: RtSolPr, PrRtAdv, F-BU, F-BACK. > >> > >> Byte counts for PrRtAdv and F-BU/F-BACK the same as above. RtSolPr > >> sent by MN is done prior to L2 handoff. > >> > >> hdr RtSolPr MNlnkAddrOpt newAttPtLnkOpt > >> Total > >> > >> RtSolPr 1 8 18 9 > >> 36 > >> > >> Total over the air sizes: > >> > >> F-BU/F-BACK before: 36 + 51 + 18 + 10 = 115 bytes > >> F-BU/F-BACK after: 36 + 51 + 50 + 49 = 186 bytes > >> > >> Times: > >> > >> F-BU/F-BACK before: 115 bytes/ 940 bytes/sec. = 0.122 sec = 122 ms > >> F-BU/F-BACK after: 198 bytes/ 940 bytes/sec. = 0.198 sec = 198 ms > >> > >> Again, the maximum of L2 handoff time and HI/HACK processing time > >> would need to be included. > >> > >> Conclusions > >> ----------- > >> > >> What conclusions to draw? These time range from respectible (55 ms > >> for network determined, stateful) to the clearly questionable > >> (198 ms for > >> mobile determined, F-BU/F-BACK sent after). The ITU > recommends 300 ms > >> maximum for delay before the user notices with real time > >> voice traffic. > >> Depending on the amount of time required for the L2 handover, > >> the HI/HACK > >> processing time, and any time required to send buffered traffic to > >> the MN if buffering is used on the old AR, the mobile > >> determined, F-BU/F-BACK > >> sent after case could easily exceed the ITU guideline, as > almost 2/3 > >> of the noticable delay time is taken up by the L3 handoff. > The others > >> require less L3 handoff time, but only the network > >> determined, stateless, > >> F-BU/F-BACK before and the network determined, stateful > are less than > >> or equal to about 1/4 of the ITU guideline. > >> > >> Clearly, header compression on the new AR could help a lot. > >> IPv6 headers > >> are big, and if there were some way the header compressors on > >> MN and new AR > >> could be jump started prior to handoff, the 40 byte header > >> overhead could be > >> eliminated. Alternatively, if the link layer can guarantee that > >> the F-BU/F-BACK occurs before the L2 handoff, the header > >> overhead won't > >> occur. Using a higher bandwidth channel could help also. > >> > >> Please send any comments or corrections (in case my math is wrong). > >> > >> jak > >> > >> > >> > >> > > > From owner-mobile-ip@sunroof.eng.sun.com Tue May 15 19:05:27 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA08917 for ; Tue, 15 May 2001 19:05:26 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA21702; Tue, 15 May 2001 16:05:21 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA18441; Tue, 15 May 2001 16:05:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4FN3hT29447 for mobile-ip-dist; Tue, 15 May 2001 16:03:43 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4FN3Y429440 for ; Tue, 15 May 2001 16:03:35 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id QAA20117 for ; Tue, 15 May 2001 16:03:35 -0700 (PDT) Message-Id: <200105152303.QAA20117@heliopolis.eng.sun.com> Date: Tue, 15 May 2001 16:03:35 -0700 (PDT) From: James Kempf Subject: Re: FW: [mobile-ip] Times for Low-Latency IPv6 Handoff To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: +yE7g83zn46SO48TaS2YMg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Raj, >> >> At least on the downlink the signaling channel is >> 3.4k. Hence the time for each of the messages roughly >> double. But, this not a problem as in UMTS DCH multiplexes >> speech and signaling together. Hence, the above 3.4k is >> accounted while full rate AMR max (12.2K) is there. Since >> both are simultaneous there should not be any interruption of >> speech service while the signaling is exchanged. This normally >> not the case in TDMA case where speech is interrupted by handoff >> messages. >> As somebody noted this morning, currently MIP signalling is run over a traffic channel, not a signalling channel. So this would mean that the user data traffic would need to be interrupted to send across the MIP signalling. IP signalling can't currently get the same kind of parallelism that the wCDMA/UTRAN signalling can. If it were possible to do the MIP signalling on a signalling channel, one could get the kind of parallelism described here, though the a data rate of 3.4k would lengthen the handoff even more. However, as far as I can tell (and the draft is a bit murky on this point), the current design of the IPv6 fast handoff doesn't seem to allow the MN to continue send/receive traffic on its old CoA while at the newAR, so parallelism would not buy anything. The MN would still have to stop sending/receiving on the old CoA and only start on the new after the F-BU/F-BACK is complete. jak From owner-mobile-ip@sunroof.eng.sun.com Tue May 15 19:46:22 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA09815 for ; Tue, 15 May 2001 19:46:22 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA01724; Tue, 15 May 2001 16:46:19 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA17679; Tue, 15 May 2001 16:46:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4FNinW29521 for mobile-ip-dist; Tue, 15 May 2001 16:44:49 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4FNif429514 for ; Tue, 15 May 2001 16:44:41 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA11902 for ; Tue, 15 May 2001 16:44:41 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA00246 for ; Tue, 15 May 2001 16:44:40 -0700 (PDT) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f4FNlKw05369 for ; Tue, 15 May 2001 18:47:20 -0500 (CDT) Received: from daebh02nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 15 May 2001 18:44:40 -0500 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Tue, 15 May 2001 18:44:40 -0500 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B03213A1F@daeis07nok> To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Times for Low-Latency IPv6 Handoff Date: Tue, 15 May 2001 18:44:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > >> > > => Sorry, I wasn't very clear. I meant that you calculated > > the transmission delay (no of bits / bit rate), but there > > is also the delays in coding and sending the data over > > the air and getting an Ack (on the radio level). I suspect > > that is it comparable with the transmission delay based > > on the worste case scenario. > > > > Actually, I used the user data throughput numbers from Holma and > Toskala, on pg. 90 for half rate coding at various spreading factors > and channel rates. I presume they've included coding, spreading, > and Ack delay in the user data figures. > > jak > James, you used the numbers specified for the uplink and applied the same for the downlink. The downlink data rates are different and are specified on page 96 (table 6.3). So the downlink data rate would be 1-3 Kbps (375 bytes/sec). Should'nt you take that into consideration as well. -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Wed May 16 04:39:56 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA01386 for ; Wed, 16 May 2001 04:39:55 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA23082; Wed, 16 May 2001 01:39:28 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA22191; Wed, 16 May 2001 01:37:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4G8a5200016 for mobile-ip-dist; Wed, 16 May 2001 01:36:05 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4G8Zt400009 for ; Wed, 16 May 2001 01:35:55 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA22102 for ; Wed, 16 May 2001 01:35:54 -0700 (PDT) From: inge.gronbak@telenor.com Received: from bdr-osl-25-005.oslo.telenor.no (BDR-OSL-25-005.telenor.no [134.47.108.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id BAA19488 for ; Wed, 16 May 2001 01:35:51 -0700 (PDT) Received: from 134.47.108.96 by bdr-osl-25-005.oslo.telenor.no (InterScan E-Mail VirusWall NT); Wed, 16 May 2001 10:37:34 +0200 (W. Europe Daylight Time) Received: by BDR-OSL-24-201 with Internet Mail Service (5.5.2653.19) id ; Wed, 16 May 2001 10:37:33 +0200 Message-ID: <7923615E38B1D21187EE0008C70DA9C8AA4969@fou-kj-21-001.nta.no> To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] NAI/need for identifiers Date: Wed, 16 May 2001 10:35:32 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f4G8Zu400010 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by patan.sun.com id BAA23082 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA01386 HI, (My first mail on an IETF list so I know I have done something wrong.) This is a cry of confusion from an employee of a "large" Norwegian operator. Could you please explain to me how the NAI, other identifiers and the IP address are used to meet the following requirements (which I jotted down very quickly): The required separate identifiers for service provisioning are as follows: · Subscription · User · Terminal · Session All four are required, and it is yet unclear to me how this is solved. These identifiers are needed to accommodate e.g. security and the following three levels of mobility: User mobility (i.e. the user can freely move between different terminals as long as authorised to do so) Terminal mobility (i.e. the terminal is allowed to change access point/point of attachment within the given level of authorisation) Service mobility (i.e. a authorised user may access, possibly personalised, services from any point of attachment) The identifiers are also required to allow operators to maintain the following bindings: · Session <-> terminal (e.g. for charging record) · Terminal <-> user <-> subscription · Terminal <-> subscription (i.e. computer to "computer" communications) · User <-> services For reasons of number portability and competition it has to be possible to change the subscription without changing any of the other identifiers. It also has to be possible for users (and terminals) to be member of more subscriptions at the same time. (I.e. the above bindings or relations are many to many.) Inge -------------------------------------------- Inge Grønbæk Telenor FoU Postboks 83, 2027 Kjeller, Norway Phone (DDI): (+47) 63 84 88 57, (mobile): (+47) 91 88 17 77. Telefax.: (+47) 63 81 00 76. E-mail: inge.gronbak@telenor.com From owner-mobile-ip@sunroof.eng.sun.com Wed May 16 10:11:07 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09679 for ; Wed, 16 May 2001 10:11:07 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA25473; Wed, 16 May 2001 07:11:02 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA19078; Wed, 16 May 2001 07:10:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4GE7ub00326 for mobile-ip-dist; Wed, 16 May 2001 07:07:56 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4GE7l400319 for ; Wed, 16 May 2001 07:07:47 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA15265 for ; Wed, 16 May 2001 07:07:47 -0700 (PDT) Received: from zrc2s03g.us.nortel.com ([47.103.122.66]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA19805 for ; Wed, 16 May 2001 07:07:46 -0700 (PDT) Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id JAA06942 for ; Wed, 16 May 2001 09:08:20 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Wed, 16 May 2001 09:07:32 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 16 May 2001 09:07:05 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E430237A959@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] NAI/need for identifiers Date: Wed, 16 May 2001 09:07:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DE11.7B699060" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C0DE11.7B699060 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 100% Correct - the proper way of thinking about this is derived from = these requirements. Thanks for making these points. Glenn -----Original Message----- From: inge.gronbak@telenor.com [mailto:inge.gronbak@telenor.com] Sent: Wednesday, May 16, 2001 3:36 AM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] NAI/need for identifiers HI, (My first mail on an IETF list so I know I have done something = wrong.) This is a cry of confusion from an employee of a "large" Norwegian = operator. Could you please explain to me how the NAI, other identifiers and the = IP address are used to meet the following requirements (which I jotted = down very quickly): The required separate identifiers for service provisioning are as = follows: =B7 Subscription =B7 User =B7 Terminal =B7 Session All four are required, and it is yet unclear to me how this is solved. = These identifiers are needed to accommodate e.g. security and the following = three levels of mobility: User mobility (i.e. the user can freely move between different = terminals as long as authorised to do so) Terminal mobility (i.e. the terminal is allowed to change access = point/point of attachment within the given level of authorisation) Service mobility (i.e. a authorised user may access, possibly = personalised, services from any point of attachment) The identifiers are also required to allow operators to maintain the following bindings: =B7 Session <-> terminal (e.g. for charging record) =B7 Terminal <-> user <-> subscription =B7 Terminal <-> subscription (i.e. computer to "computer" communications) =B7 User <-> services For reasons of number portability and competition it has to be possible = to change the subscription without changing any of the other identifiers. = It also has to be possible for users (and terminals) to be member of more subscriptions at the same time. (I.e. the above bindings or relations = are many to many.) Inge -------------------------------------------- Inge Gr=F8nb=E6k Telenor FoU Postboks 83, 2027 Kjeller, Norway Phone (DDI): (+47) 63 84 88 57, (mobile): (+47) 91 88 17 77. Telefax.: (+47) 63 81 00 76. E-mail: inge.gronbak@telenor.com ------_=_NextPart_001_01C0DE11.7B699060 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] NAI/need for identifiers

100% Correct - the proper way of thinking about this = is derived from these requirements. Thanks for making these = points.

Glenn

-----Original Message-----
From: inge.gronbak@telenor.com [mailto:inge.gronbak@telenor.com= ]
Sent: Wednesday, May 16, 2001 3:36 AM
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] NAI/need for identifiers


HI, (My first mail on an IETF list so I know I have = done something wrong.)

This is a cry of confusion from an employee of a = "large" Norwegian operator.

Could you please explain to me how the NAI, other = identifiers and the IP
address are used to  meet the following = requirements (which I jotted down
very quickly):

The required separate identifiers for service = provisioning are as follows:
=B7       = Subscription
=B7       User
=B7       = Terminal
=B7       = Session
All four are required, and it is yet unclear to me = how this is solved. These
identifiers are needed to accommodate e.g. security = and the following three
levels of mobility:
User mobility (i.e. the user can freely move between = different terminals as
long as authorised to do so)
Terminal mobility (i.e. the terminal is allowed to = change access point/point
of attachment within the given level of = authorisation)
Service mobility (i.e. a authorised user may access, = possibly personalised,
services from any point of attachment)
The identifiers are also required to allow operators = to maintain the
following bindings:
=B7       Session = <-> terminal (e.g. for charging record)
=B7       Terminal = <-> user <-> subscription
=B7       Terminal = <-> subscription (i.e. computer to "computer"
communications)
=B7       User = <-> services

For reasons of number portability and competition it = has to be possible to
change the subscription without changing any of the = other identifiers. It
also has to be possible for users (and terminals) to = be member of more
subscriptions at the same time. (I.e. the above = bindings or relations are
many to many.)

Inge
--------------------------------------------
Inge Gr=F8nb=E6k
Telenor FoU
Postboks 83,
2027 Kjeller, Norway
Phone (DDI): (+47) 63 84 88 57,
(mobile): (+47) 91 88 17 77.
Telefax.: (+47) 63 81 00 76.
E-mail: inge.gronbak@telenor.com

------_=_NextPart_001_01C0DE11.7B699060-- From owner-mobile-ip@sunroof.eng.sun.com Wed May 16 10:15:10 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09776 for ; Wed, 16 May 2001 10:15:09 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA13903; Wed, 16 May 2001 07:14:35 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA19840; Wed, 16 May 2001 07:13:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4GEC7K00356 for mobile-ip-dist; Wed, 16 May 2001 07:12:07 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4GEBv400345 for ; Wed, 16 May 2001 07:11:57 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA15952 for ; Wed, 16 May 2001 07:11:58 -0700 (PDT) Received: from zrc2s03g.us.nortel.com ([47.103.122.66]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA04419 for ; Wed, 16 May 2001 07:11:57 -0700 (PDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id JAA08570 for ; Wed, 16 May 2001 09:12:46 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Wed, 16 May 2001 09:06:10 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 16 May 2001 09:11:39 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E430237A969@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] host routes in the fast mipv6 draft Date: Wed, 16 May 2001 09:11:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DE12.1C9FB4A0" X-Orig: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C0DE12.1C9FB4A0 Content-Type: text/plain; charset="iso-8859-1" James, Is there some RFC that defines host route in this manner? My definition would have been a route entry in a route table of a router for a single IP address. -----Original Message----- From: James Kempf [mailto:James.Kempf@Sun.COM] Sent: Tuesday, May 15, 2001 4:24 PM To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] host routes in the fast mipv6 draft Mike & Alper, > >Alper Yegin writes: > > > In either case, however, ARold needs > > > to place the route in its database as well as > > > ARnew. Otherwise, it will keep routing the > > > packets out the old (wireless) interface as > > > normal, which is obviously not what you'd want. > > > > Whether packets destined to oldCoA are tunneled to newCoA or newAR, there needs > > to be a state on oldAR. Something like "send all packets destined to oldCoA > > through tunnel100". In one case tunnel100's end point will be newCoA, in other > > newAR. > >Alper, > >Understand that I wasn't on the design team, so >I'm looking at this sort of like an outside reader >would look at it. I didn't see where/how the >tunnel would be terminated on ARnew in the draft. >Did I miss something? This would be new >functionality in ipv6 since it sounds like it's >mimicing v4 FA functionality. > The draft is very unclear about how and when tunnels are set up. The term "host route" is used to refer to a tunnel being set up. I've actually never heard the term host route used in this fashion. Typically, a host route means "even though the dest address doesn't match the subnet structure topologically, route the packet this way." With a tunnel, the dest address will always be topologically correct. jak ------_=_NextPart_001_01C0DE12.1C9FB4A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] host routes in the fast mipv6 draft

James,

Is there some RFC that defines host route in this = manner? My definition would have been a route entry in a route table of = a router for a single IP address.

-----Original Message-----
From: James Kempf [mailto:James.Kempf@Sun.COM]
Sent: Tuesday, May 15, 2001 4:24 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] host routes in the fast = mipv6 draft


Mike & Alper,

>
>Alper Yegin writes:
> > >    In either case, = however, ARold needs
> > >    to place the route = in its database as well as
> > >    ARnew. Otherwise, = it will keep routing the
> > >    packets out the old = (wireless) interface as
> > >    normal, which is = obviously not what you'd want.
> >
> > Whether packets destined to oldCoA are = tunneled to newCoA or newAR, there
needs
> > to be a state on oldAR. Something like = "send all packets destined to oldCoA
> > through tunnel100". In one case = tunnel100's end point will be newCoA, in
other
> > newAR.
>
>Alper,
>
>Understand that I wasn't on the design team, = so
>I'm looking at this sort of like an outside = reader
>would look at it. I didn't see where/how = the
>tunnel would be terminated on ARnew in the = draft.
>Did I miss something? This would be new
>functionality in ipv6 since it sounds like = it's
>mimicing v4 FA functionality.
>

The draft is very unclear about how and when tunnels = are set up.
The term "host route" is used to refer to = a tunnel being set up.
I've actually never heard the term host route used = in this fashion.
Typically, a host route means "even though the = dest address doesn't
match the subnet structure topologically, route the = packet this way."
With a tunnel, the dest address will always be = topologically correct.

        =         jak

------_=_NextPart_001_01C0DE12.1C9FB4A0-- From owner-mobile-ip@sunroof.eng.sun.com Wed May 16 10:37:21 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10387 for ; Wed, 16 May 2001 10:37:20 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA27945; Wed, 16 May 2001 07:35:37 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA23481; Wed, 16 May 2001 07:34:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4GEVpu00451 for mobile-ip-dist; Wed, 16 May 2001 07:31:51 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4GEVg400444 for ; Wed, 16 May 2001 07:31:42 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA16097 for ; Wed, 16 May 2001 07:31:38 -0700 (PDT) Received: from zrc2s03g.us.nortel.com ([47.103.122.66]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA26524 for ; Wed, 16 May 2001 08:31:24 -0600 (MDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id JAA15142 for ; Wed, 16 May 2001 09:30:01 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Wed, 16 May 2001 09:23:29 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 16 May 2001 09:28:58 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E430237A9ED@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: mobile-ip] Re: mobile-ip] Multiple flows with single NAI Date: Wed, 16 May 2001 09:28:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DE14.89AAD3C0" X-Orig: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C0DE14.89AAD3C0 Content-Type: text/plain; charset="iso-8859-1" GM] Below -----Original Message----- From: Madhavi Subbarao [mailto:msubbara@cisco.com] Sent: Tuesday, May 15, 2001 3:00 PM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: mobile-ip] Re: mobile-ip] Multiple flows with single NAI On Mon, May 14, 2001 at 10:15:03AM -0500, Glenn Morrow wrote: > There is nothing wrong with allowing multiple devices to use the same NAI. I > wouldn't call it a user address, though. I would call it a subscription > identifier. I know this could be construed as a semantics thing but user > address just brings up the wrong concoction of what it should really be used > for. Agreed. We are interpreting the NAI in the same way as you describe for 'subsription ID'. GM] Excellent - now if we can just get people to stop calling it user. > > NAI is a generic definition that can be used to identify almost anything. > MIP specifications need to be explicit in what fields which use the NAI form > mean and in what context, IMO. > > On PAT's question about each device having it's own NAIs - you can. But if > you enforce this (i.e. no two devices can use the same NAI) then you've > essentially begun using the NAI as a device identifier. Exactly. The idea is to keep the NAI as a user/subscription ID and authenticate based on the NAI as usual, and then identify the devices based on another ID...Device/Binding ID. > Perhaps we need a device identifier which uses the NAI form, as well, to > allow the HAs to blacklist known fraudulent devices? Well, the Device/Binding ID could indeed be a 'globally' unique identifier similar to the NAI form (although I'm not sure how you guarantee uniqueness). As I mentioned on another email in this thread, there are several choices on how to define the Device/Binding ID. Glenn, did you have any thoughts on those formats? GM] Yes - identify the MAC technology and vendor that does with a level of certainty guarantee uniqueness ex. imei.umts, eid.cdma-2k, ether-address.ieee802xxx, etc.. > Maybe we need more than one field, (user, subscription, device) that use the > NAI form? Subscription ID = NAI as is today, Device ID = Device/Binding ID to be defined...so what's 'User ID'? Why you feel we need another level of identification? GM] I don't believe we should use the term user and associate "user id" in any way with a node mobility solution - subscription and device are what it should be concerned with. I'm glad you agree. I was just saying that if some belligerents can't seem to figure out that user-id in MIP is the wrong thing and they must include a user id then please at least make it separate. > I wouldn't define user in MIP because there are simply some user mobility > functions that can't be solved at layer 3 - again the wrong concoction. > > Another option would be to do something like > user.subscription.device@whatever.com but then you get into coupled business > models i.e. the application provider must be the network service provider or > have a special directory updating arrangement etc.. - not exactly the > WWW-way. I'm not sure we need to get that detailed or coupled. GM] Again we agree. Thanks, Glenn ------_=_NextPart_001_01C0DE14.89AAD3C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Re: mobile-ip] Re: mobile-ip] Multiple flows = with single NAI

GM] Below

-----Original Message-----
From: Madhavi Subbarao [mailto:msubbara@cisco.com]=
Sent: Tuesday, May 15, 2001 3:00 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Re: mobile-ip] Re: mobile-ip] = Multiple flows with
single NAI


On Mon, May 14, 2001 at 10:15:03AM -0500, Glenn = Morrow wrote:
> There is nothing wrong with allowing multiple = devices to use the same NAI. I
> wouldn't call it a user address, though. I = would call it a subscription
> identifier. I know this could be construed as a = semantics thing but user
> address just brings up the wrong concoction of = what it should really be used
> for.

Agreed.  We are interpreting the NAI in the same = way as you describe
for 'subsription ID'.

GM] Excellent - now if we can just get people to stop = calling it user.

>
> NAI is a generic definition that can be used to = identify almost anything.
> MIP specifications need to be explicit in what = fields which use the NAI form
> mean and in what context, IMO. 
>
> On PAT's question about each device having it's = own NAIs - you can. But if
> you enforce this (i.e. no two devices can use = the same NAI) then you've
> essentially begun using the NAI as a device = identifier.

Exactly.  The idea is to keep the NAI as a = user/subscription ID and
authenticate based on the NAI as usual, and then = identify the devices
based on another ID...Device/Binding ID.

> Perhaps we need a device identifier which uses = the NAI form, as well, to
> allow the HAs to blacklist known fraudulent = devices?

Well, the Device/Binding ID could indeed be a = 'globally' unique
identifier similar to the NAI form (although I'm not = sure how you
guarantee uniqueness).   As I mentioned on = another email in this
thread, there are several choices on how to define = the Device/Binding
ID.  Glenn, did you have any thoughts on those = formats? 

GM] Yes - identify the MAC technology and vendor that = does with a level of certainty guarantee uniqueness ex.  = imei.umts, eid.cdma-2k, ether-address.ieee802xxx, etc..

> Maybe we need more than one field, (user, = subscription, device) that use the
> NAI form?

Subscription ID =3D NAI as is today, Device ID =3D = Device/Binding ID to be
defined...so what's 'User ID'?  Why you feel we = need another level of
identification?

GM] I don't believe we should use the term user and = associate "user id" in any way with a node mobility solution = - subscription and device are what it should be concerned with. I'm = glad you agree. I was just saying that if some belligerents can't seem = to figure out that user-id in MIP is the wrong thing and they must = include a user id then please at least make it separate.



> I wouldn't define user in MIP because there are = simply some user mobility
> functions that can't be solved at layer 3 - = again the wrong concoction.
>
> Another option would be to do something = like
> user.subscription.device@whatever.com but then = you get into coupled business
> models i.e. the application provider must be = the network service provider or
> have a special directory updating arrangement = etc.. - not exactly the
> WWW-way.

I'm not sure we need to get that detailed or = coupled.

GM] Again we agree.

Thanks,

Glenn

------_=_NextPart_001_01C0DE14.89AAD3C0-- From owner-mobile-ip@sunroof.eng.sun.com Wed May 16 11:23:58 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11283 for ; Wed, 16 May 2001 11:23:57 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA28962; Wed, 16 May 2001 08:23:42 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09818; Wed, 16 May 2001 08:23:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4GFM0g00619 for mobile-ip-dist; Wed, 16 May 2001 08:22:00 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4GFLq400612 for ; Wed, 16 May 2001 08:21:52 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA25145 for ; Wed, 16 May 2001 08:21:52 -0700 (PDT) From: Jack_Fijolek@3com.com Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA26164 for ; Wed, 16 May 2001 08:21:50 -0700 (PDT) Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4GFJlb11819; Wed, 16 May 2001 08:19:47 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104]) by opal.3com.com (Switch-2.1.1/Switch-2.1.0) with SMTP id f4GFLXn01371; Wed, 16 May 2001 08:21:33 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256A4E.00545ACC ; Wed, 16 May 2001 08:21:22 -0700 X-Lotus-FromDomain: 3COM To: inge.gronbak@telenor.com cc: mobile-ip@sunroof.eng.sun.com Message-ID: <88256A4E.005458D7.00@hqoutbound.ops.3com.com> Date: Wed, 16 May 2001 10:21:58 -0500 Subject: Re: [mobile-ip] NAI/need for identifiers Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=RzsCbKTUgUhllDj1AdiweHiq3b76P0wsEdDq2su8ugL62CvnkApXQMvw" Content-Disposition: inline Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --0__=RzsCbKTUgUhllDj1AdiweHiq3b76P0wsEdDq2su8ugL62CvnkApXQMvw Content-type: text/plain; charset=us-ascii Content-Disposition: inline Inge, Thanks for the service providers perspective. Can you explain a little further how you physically see this connection used by your customers? For example, I have worked to requirements of multiple simultaneous terminals behind a single subscription ID in a bridging and gateway end customer environments with consumer access devices like cable, DSL or BWA (fixed wireless) modems. The subscriber's access connection is fixed but there can be a subscriber Ethernet or USB LAN behind it with one "modem" gating all transmission of LAN-ISP subscriber data. In those access technologies there are also internal PC modems with multiple simultaneous sessions on a single terminal. In all cases, there is still a concept of primary access terminal or connection device. My question is, as a service provider, do you see this market offering portable gateways that have some well-defined customer interface like 10/100 Ethernet or USB? If so, should there be a requirement for the portable gateway device to have bridging or forwarding characteristics? Should a primary connection device pass any attached device's data transparently? Should it frame the traffic? Should all devices make their own framed connection? Jack inge.gronbak@telenor.com on 05/16/2001 03:35:32 AM Please respond to mobile-ip@sunroof.eng.sun.com Sent by: inge.gronbak@telenor.com To: mobile-ip@sunroof.eng.sun.com cc: (Jack Fijolek/MW/US/3Com) Subject: [mobile-ip] NAI/need for identifiers --0__=RzsCbKTUgUhllDj1AdiweHiq3b76P0wsEdDq2su8ugL62CvnkApXQMvw Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable HI, (My first mail on an IETF list so I know I have done something wron= g.) This is a cry of confusion from an employee of a "large" Norwegian oper= ator. Could you please explain to me how the NAI, other identifiers and the I= P address are used to meet the following requirements (which I jotted do= wn very quickly): The required separate identifiers for service provisioning are as follo= ws: =B7 Subscription =B7 User =B7 Terminal =B7 Session All four are required, and it is yet unclear to me how this is solved. = These identifiers are needed to accommodate e.g. security and the following t= hree levels of mobility: User mobility (i.e. the user can freely move between different terminal= s as long as authorised to do so) Terminal mobility (i.e. the terminal is allowed to change access point/= point of attachment within the given level of authorisation) Service mobility (i.e. a authorised user may access, possibly personali= sed, services from any point of attachment) The identifiers are also required to allow operators to maintain the following bindings: =B7 Session <-> terminal (e.g. for charging record) =B7 Terminal <-> user <-> subscription =B7 Terminal <-> subscription (i.e. computer to "computer" communications) =B7 User <-> services For reasons of number portability and competition it has to be possible= to change the subscription without changing any of the other identifiers. = It also has to be possible for users (and terminals) to be member of more subscriptions at the same time. (I.e. the above bindings or relations a= re many to many.) Inge -------------------------------------------- Inge Gr=F8nb=E6k Telenor FoU Postboks 83, 2027 Kjeller, Norway Phone (DDI): (+47) 63 84 88 57, (mobile): (+47) 91 88 17 77. Telefax.: (+47) 63 81 00 76. E-mail: inge.gronbak@telenor.com = --0__=RzsCbKTUgUhllDj1AdiweHiq3b76P0wsEdDq2su8ugL62CvnkApXQMvw-- From owner-mobile-ip@sunroof.eng.sun.com Wed May 16 11:47:12 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12083 for ; Wed, 16 May 2001 11:47:07 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01467; Wed, 16 May 2001 08:47:07 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA00376; Wed, 16 May 2001 08:46:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4GFjQv00661 for mobile-ip-dist; Wed, 16 May 2001 08:45:26 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4GFjI400654 for ; Wed, 16 May 2001 08:45:18 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id IAA05001 for ; Wed, 16 May 2001 08:45:18 -0700 (PDT) Message-Id: <200105161545.IAA05001@heliopolis.eng.sun.com> Date: Wed, 16 May 2001 08:45:18 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] Times for Low-Latency IPv6 Handoff To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 8aqgnRay7nK1pf+tI/nBCA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Raj, >> >> >James, you used the numbers specified for the uplink and applied >the same for the downlink. The downlink data rates are different and >are specified on page 96 (table 6.3). So the downlink data rate would >be 1-3 Kbps (375 bytes/sec). Should'nt you take that into consideration >as well. > Thanx for pointing this out to me. I should use different rates for the uplink and the downlink. There are a couple other points that occured to me where I think I will need some clarification from the authors of draft-ietf-mobileip-fast-mipv6-01.txt. The draft is not clear on these, or at least I couldn't figure it out from reading the draft. They are: - On pg. 9, Figure 2 shows stateful CoA configuration without the F-BU/F-BACK that is required for stateless. In my calculations, I assumed that the F-BU/F-BACK are not needed for stateful. However, I don't see how the MN can tell whether a PrRtAdv is the result of stateless or stateful address provisioning. There are no flags or distinctive options that differentiate the two. Consequently, I suspect that the F-BU/F-BACK would be necessary for stateful CoA configuration as well. Can the authors confirm? - It was unclear to me after reading the draft how F-NA and NA are used, why the new F-NA was introduced, and whether the MN can get packets before exchanging an acknowledged NA or F-NA to the newAR. Section 5.3 seems to imply that the F-NA can be sent by the MN if it wants to start sending packets right away prior to receiving the F-BACK, but other parts of the draft say that the F-BACK is the gating factor. Can the authors of the draft confirm whether or not an acknowledged F-NA or NA is required before the MN can start sending packets through newAR? As soon as I get clarification from the authors on these points, I'll update the calculations and repost them. jak From owner-mobile-ip@sunroof.eng.sun.com Wed May 16 11:51:41 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12233 for ; Wed, 16 May 2001 11:51:41 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA07105; Wed, 16 May 2001 08:51:29 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA01263; Wed, 16 May 2001 08:50:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4GFnHR00691 for mobile-ip-dist; Wed, 16 May 2001 08:49:17 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4GFn8400684 for ; Wed, 16 May 2001 08:49:08 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA29504 for ; Wed, 16 May 2001 08:49:08 -0700 (PDT) Received: from zrc2s03g.us.nortel.com ([47.103.122.66]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA05996 for ; Wed, 16 May 2001 08:49:07 -0700 (PDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id KAA17003 for ; Wed, 16 May 2001 10:49:56 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Wed, 16 May 2001 10:43:15 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 16 May 2001 10:48:45 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E43023DB890@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] NAI/need for identifiers Date: Wed, 16 May 2001 10:48:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DE1F.AEEC5450" X-Orig: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C0DE1F.AEEC5450 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable GM] Here is my shot at an answer: -----Original Message----- From: inge.gronbak@telenor.com [mailto:inge.gronbak@telenor.com] Sent: Wednesday, May 16, 2001 3:36 AM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] NAI/need for identifiers HI, (My first mail on an IETF list so I know I have done something = wrong.) This is a cry of confusion from an employee of a "large" Norwegian = operator. GM] I believe this confusion has been caused by the choice of = terminology in some of the MIP standards. Could you please explain to me how the NAI, other identifiers and the = IP address are used to meet the following requirements (which I jotted = down very quickly): The required separate identifiers for service provisioning are as = follows: =B7 Subscription GM] We need a separate id for subscription. The NAI can be used as a = general format to represent the subscription. =B7 User GM] This concept is for applications such as: SIP,H.323,IM, etc.. A = network layer-based node mobility solution can not solve the more complex user mobility functions. =B7 Terminal GM] The MAC address identifies the node or NIC of the node. The mobile = may have many IP addresses (both multiple home and COAs). We need another explicit field to indicate the MAC address and MAC technology for blacklisting. I would use a generic term such as device. =B7 Session GM] The binding id can serve as the session for the network layer = service. The applications will also have separate session ids. All four are required, and it is yet unclear to me how this is solved. = These identifiers are needed to accommodate e.g. security and the following = three levels of mobility: User mobility (i.e. the user can freely move between different = terminals as long as authorised to do so) Terminal mobility (i.e. the terminal is allowed to change access = point/point of attachment within the given level of authorisation) Service mobility (i.e. a authorised user may access, possibly = personalised, services from any point of attachment) GM] We have to be careful here. The service parameters related to the functions of the network layer (ex max default bandwidth) need to be = handled in a node mobility solution. There is a little work to do at the = network layer for this. I would call this network layer service mobility. GM]The service information related to applications should be conveyed = with the application. It must be noted that the applications must be able to override the default service information of the network layer. This = means that some application to network layer interface must be developed to provide this override and correlation for accounting. I would call this application layer service mobility. The session belongs in this = interface. The identifiers are also required to allow operators to maintain the following bindings: =B7 Session <-> terminal (e.g. for charging record) =B7 Terminal <-> user <-> subscription =B7 Terminal <-> subscription (i.e. computer to "computer" communications) =B7 User <-> services For reasons of number portability and competition it has to be possible = to change the subscription without changing any of the other identifiers. GM] Yes, indeed. Thank You. I try to generalize this with the term = provider portability or mobility. Another aspect of this is when an employee = changes employers yet wishes to keep the same user identifiers and device. The subscriber (person who pays - in this case the employer) changes. This functionality can also be handled via the decoupling of subscription as well. It also has to be possible for users (and terminals) to be member of = more subscriptions at the same time. (I.e. the above bindings or relations = are many to many.) GM] Yes, indeed. Thank You. GM] I would like to add one more - the subscription(s) for the network service may be different from the application service. They can also be = the same. GM] Once again, Thank You for bringing up these points. Glenn ------_=_NextPart_001_01C0DE1F.AEEC5450 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] NAI/need for identifiers

GM] Here is my shot at an answer:

-----Original Message-----
From: inge.gronbak@telenor.com [mailto:inge.gronbak@telenor.com= ]
Sent: Wednesday, May 16, 2001 3:36 AM
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] NAI/need for identifiers


HI, (My first mail on an IETF list so I know I have = done something wrong.)

This is a cry of confusion from an employee of a = "large" Norwegian operator.

GM] I believe this confusion has been caused by the = choice of terminology in some of the MIP standards.

Could you please explain to me how the NAI, other = identifiers and the IP
address are used to  meet the following = requirements (which I jotted down
very quickly):

The required separate identifiers for service = provisioning are as follows:

=B7       = Subscription

GM] We need a separate id for subscription. The NAI = can be used as a general format to represent the subscription.

=B7       User

GM] This concept is for applications such as: = SIP,H.323,IM, etc.. A network layer-based node mobility solution can = not solve the more complex user mobility functions.

=B7       = Terminal

GM] The MAC address identifies the node or NIC of the = node. The mobile may have many IP addresses (both multiple home and = COAs). We need another explicit field to indicate the MAC address and = MAC technology for blacklisting. I would use a generic term such as = device.

=B7       = Session

GM] The binding id can serve as the session for the = network layer  service. The applications will also have separate = session ids.

All four are required, and it is yet unclear to me = how this is solved. These
identifiers are needed to accommodate e.g. security = and the following three
levels of mobility:
User mobility (i.e. the user can freely move between = different terminals as
long as authorised to do so)
Terminal mobility (i.e. the terminal is allowed to = change access point/point
of attachment within the given level of = authorisation)
Service mobility (i.e. a authorised user may access, = possibly personalised,
services from any point of attachment)

GM] We have to be careful here. The service = parameters related to the functions of the network layer (ex max = default bandwidth) need to be handled in a node mobility solution. = There is a little work to do at the network layer for this. I would = call this network layer service mobility.

GM]The service information related to applications = should be conveyed with the application. It must be noted that the = applications must be able to override the default service information = of the network layer. This means that some application to network layer = interface must be developed to provide this override and correlation = for accounting. I would call this application layer service mobility. = The session belongs in this interface.

The identifiers are also required to allow operators = to maintain the
following bindings:
=B7       Session = <-> terminal (e.g. for charging record)
=B7       Terminal = <-> user <-> subscription
=B7       Terminal = <-> subscription (i.e. computer to "computer"
communications)
=B7       User = <-> services

For reasons of number portability and competition it = has to be possible to change the subscription without changing any of = the other identifiers.

GM] Yes, indeed. Thank You. I try to generalize this = with the term provider portability or mobility. Another aspect of this = is when an employee changes employers yet wishes to keep the same user = identifiers and device. The subscriber (person who pays - in this case = the employer) changes. This functionality can also be handled via the = decoupling of subscription as well.


It also has to be possible for users (and terminals) = to be member of more
subscriptions at the same time. (I.e. the above = bindings or relations are
many to many.)

GM] Yes, indeed. Thank You.

GM] I would like to add one more - the = subscription(s) for the network service may be different from the = application service. They can also be the same.

GM] Once again, Thank You for bringing up these = points.

Glenn

------_=_NextPart_001_01C0DE1F.AEEC5450-- From owner-mobile-ip@sunroof.eng.sun.com Wed May 16 12:04:50 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12559 for ; Wed, 16 May 2001 12:04:49 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA16050; Wed, 16 May 2001 09:04:35 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA02703; Wed, 16 May 2001 09:04:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4GG1uC00775 for mobile-ip-dist; Wed, 16 May 2001 09:01:56 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4GG1f400760 for ; Wed, 16 May 2001 09:01:41 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA09640 for ; Wed, 16 May 2001 09:01:40 -0700 (PDT) Received: from mercury.ukc.ac.uk (mercury.ukc.ac.uk [129.12.21.10]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08048 for ; Wed, 16 May 2001 09:01:39 -0700 (PDT) Received: from pelican.ukc.ac.uk ([129.12.200.26]) by mercury.ukc.ac.uk with esmtp (Exim 3.22 #4) id 1503k0-0002AZ-00; Wed, 16 May 2001 17:01:36 +0100 Received: from pccomm4.ukc.ac.uk ([129.12.50.119] helo=ukc.ac.uk) by pelican.ukc.ac.uk with esmtp (Exim 3.22 #3) id 1503k2-0002dJ-00; Wed, 16 May 2001 17:01:38 +0100 Message-ID: <3B02A462.2398AB6D@ukc.ac.uk> Date: Wed, 16 May 2001 17:01:38 +0100 From: Kumarendra Sivarajah X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: [mobile-ip] Mobile IP Streaming Audio/Video Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi I would like to enquire if anyone has information or carried out research on Streaming Audio/Video with Mobile IP. I'd be appreciable if you can provide me with papers or relevant information. Thanks, INdran -- /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \ Kumarendra Sivarajah (INdran) / / Electronics Engineering Laboratory \ \ University of Kent at Canterbury / / Telephone(Office): +44 (0)1227 823257 \ \ Telephone(Mobile): +44 (0)7765 007016 / \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ From owner-mobile-ip@sunroof.eng.sun.com Wed May 16 12:06:26 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12604 for ; Wed, 16 May 2001 12:06:24 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA27642; Wed, 16 May 2001 09:06:22 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA10745; Wed, 16 May 2001 09:05:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4GG2YG00789 for mobile-ip-dist; Wed, 16 May 2001 09:02:34 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4GG2I400782 for ; Wed, 16 May 2001 09:02:18 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03494 for ; Wed, 16 May 2001 09:02:18 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08798 for ; Wed, 16 May 2001 09:02:17 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f4GG2NU22657 for ; Wed, 16 May 2001 09:02:24 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AFY20741; Wed, 16 May 2001 09:02:16 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA03509; Wed, 16 May 2001 09:02:11 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15106.42115.83067.130623@thomasm-u1.cisco.com> Date: Wed, 16 May 2001 09:02:11 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] host routes in the fast mipv6 draft In-Reply-To: <200105152123.OAA16592@heliopolis.eng.sun.com> References: <200105152123.OAA16592@heliopolis.eng.sun.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit James Kempf writes: > Mike & Alper, > > > > >Alper Yegin writes: > > > > In either case, however, ARold needs > > > > to place the route in its database as well as > > > > ARnew. Otherwise, it will keep routing the > > > > packets out the old (wireless) interface as > > > > normal, which is obviously not what you'd want. > > > > > > Whether packets destined to oldCoA are tunneled to newCoA or newAR, there > needs > > > to be a state on oldAR. Something like "send all packets destined to oldCoA > > > through tunnel100". In one case tunnel100's end point will be newCoA, in > other > > > newAR. > > > >Alper, > > > >Understand that I wasn't on the design team, so > >I'm looking at this sort of like an outside reader > >would look at it. I didn't see where/how the > >tunnel would be terminated on ARnew in the draft. > >Did I miss something? This would be new > >functionality in ipv6 since it sounds like it's > >mimicing v4 FA functionality. > > > > The draft is very unclear about how and when tunnels are set up. > The term "host route" is used to refer to a tunnel being set up. > I've actually never heard the term host route used in this fashion. > Typically, a host route means "even though the dest address doesn't > match the subnet structure topologically, route the packet this way." > With a tunnel, the dest address will always be topologically correct. Jim, There seems to be something of a mythology surrounding the phrase "host routes" that I don't think they deserve. A host route is nothing more than a subnet with a /32 or /128 (v4, v6) subnet mask. They aren't treated by routers any differently beyond that (ie, they still use the longest prefix match algorithm). Also: there's nothing which says that prefixes must be strictly hierarchical; indeed that is far from the reality of the current net with its 70k+ prefixes advertised by BGP and growing. There is some valid concern about the scalability of small subnets -- host routes being the pathological case, but a huge number of /64's or even /48's wouldn't be good for the net if they didn't aggregate either. Within a confined bounds, however, it's mainly the size of the interior router's routing table you're willing to populate, as well as the signaling overhead and convergence times of your network that need to be considered. Disaggregated small subnets (especially for v6 /64's, say) would have all of the same considerations though. Mike From owner-mobile-ip@sunroof.eng.sun.com Wed May 16 12:12:22 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12834 for ; Wed, 16 May 2001 12:12:22 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA03554; Wed, 16 May 2001 09:10:56 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA18520; Wed, 16 May 2001 09:10:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4GG9A500873 for mobile-ip-dist; Wed, 16 May 2001 09:09:10 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4GG91400866 for ; Wed, 16 May 2001 09:09:01 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id JAA05952 for ; Wed, 16 May 2001 09:09:01 -0700 (PDT) Message-Id: <200105161609.JAA05952@heliopolis.eng.sun.com> Date: Wed, 16 May 2001 09:09:01 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] host routes in the fast mipv6 draft To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: J1t2dzyj3ZvpvQwlfVNovw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Glenn, Not that I know of. I'm taking the definition from Radia Perlman's "Interconnections" second edition. jak >From: "Glenn Morrow" >To: mobile-ip@sunroof.eng.sun.com >Subject: RE: [mobile-ip] host routes in the fast mipv6 draft >Date: Wed, 16 May 2001 09:11:33 -0500 > >James, > >Is there some RFC that defines host route in this manner? My definition >would have been a route entry in a route table of a router for a single IP >address. > >-----Original Message----- >From: James Kempf [mailto:James.Kempf@Sun.COM] >Sent: Tuesday, May 15, 2001 4:24 PM >To: mobile-ip@sunroof.eng.sun.com >Subject: RE: [mobile-ip] host routes in the fast mipv6 draft > > >Mike & Alper, > >> >>Alper Yegin writes: >> > > In either case, however, ARold needs >> > > to place the route in its database as well as >> > > ARnew. Otherwise, it will keep routing the >> > > packets out the old (wireless) interface as >> > > normal, which is obviously not what you'd want. >> > >> > Whether packets destined to oldCoA are tunneled to newCoA or newAR, >there >needs >> > to be a state on oldAR. Something like "send all packets destined to >oldCoA >> > through tunnel100". In one case tunnel100's end point will be newCoA, in > >other >> > newAR. >> >>Alper, >> >>Understand that I wasn't on the design team, so >>I'm looking at this sort of like an outside reader >>would look at it. I didn't see where/how the >>tunnel would be terminated on ARnew in the draft. >>Did I miss something? This would be new >>functionality in ipv6 since it sounds like it's >>mimicing v4 FA functionality. >> > >The draft is very unclear about how and when tunnels are set up. >The term "host route" is used to refer to a tunnel being set up. >I've actually never heard the term host route used in this fashion. >Typically, a host route means "even though the dest address doesn't >match the subnet structure topologically, route the packet this way." >With a tunnel, the dest address will always be topologically correct. > > jak > From owner-mobile-ip@sunroof.eng.sun.com Wed May 16 12:20:28 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13088 for ; Wed, 16 May 2001 12:20:28 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA24102; Wed, 16 May 2001 09:17:02 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA05667; Wed, 16 May 2001 09:13:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4GGCSL00911 for mobile-ip-dist; Wed, 16 May 2001 09:12:28 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4GGCJ400904 for ; Wed, 16 May 2001 09:12:19 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA19033 for ; Wed, 16 May 2001 09:12:19 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA20247 for ; Wed, 16 May 2001 09:12:18 -0700 (PDT) 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 JAA28139 for ; Wed, 16 May 2001 09:12:18 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f4GGCFX02124 for ; Wed, 16 May 2001 09:12:15 -0700 X-mProtect: Wed, 16 May 2001 09:12:15 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpd0eZNGK; Wed, 16 May 2001 09:12:12 PDT Message-ID: <3B02A6DE.FC2ECEF3@iprg.nokia.com> Date: Wed, 16 May 2001 09:12:14 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] NAI/need for identifiers References: <7923615E38B1D21187EE0008C70DA9C8AA4969@fou-kj-21-001.nta.no> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by mercury.Sun.COM id JAA24102 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA13088 Hello Inge, > This is a cry of confusion from an employee of a "large" Norwegian operator. You're not the only one experiencing confusion. In fact, maybe a lot of people including myself are confused. I'll at least give my tentative answers. But before that, I'd like to suggest that Mobile IP, as a protocol, should be considered to be a protocol that deals (solely) with terminal mobility. I think that trying to extend Mobile IP, for example, to handle service provisioning based on subscriber profiles, would be a mistake. We might wish to add a QoS descriptor to the Registration Request, but that would be about as far as it could go. Responding to needs expressed by 3G standards groups, the mobile-ip working group standardized a way to use NAI in Registration Request messages when the mobile node didn't have a home address, and to enable some authorization procedures. In my opinion, this should not be stretched to replace the node's IP address by its NAI. I would instead hope that the IP address be the basis for the protocol. A lot of this was technically driven by the perceived lack of IPv4 addresses. It is quite possible to imagine that the NAI would be completely unnecessary for mobility management for IPv6. Whether or not the IP address should be used for subscriber management, or user mobility, is another question. I don't even know if the mobile-ip working group is the right place for the discussion. It certainly doesn't seem to be an issue for a group in the routing area of the IETF, which mobile-ip is. I would think that the whole discussion fits better as a discussion about database or policy management, than figuring out where to send packets. So now you know my frame of mind for the following guesses at answers. > Could you please explain to me how the NAI, other identifiers and the IP > address are used to meet the following requirements (which I jotted down > very quickly): > > The required separate identifiers for service provisioning are as follows: > · Subscription Could be NAI > · User Could be NAI > · Terminal Should be IP address > · Session NAI is not sufficient for this, and from the discussion I don't think that IP address is the right handle either. > All four are required, and it is yet unclear to me how this is solved. These > identifiers are needed to accommodate e.g. security and the following three > levels of mobility: > User mobility (i.e. the user can freely move between different terminals as > long as authorised to do so) > Terminal mobility (i.e. the terminal is allowed to change access point/point > of attachment within the given level of authorisation) > Service mobility (i.e. a authorised user may access, possibly personalised, > services from any point of attachment) > The identifiers are also required to allow operators to maintain the > following bindings: > · Session <-> terminal (e.g. for charging record) > · Terminal <-> user <-> subscription > · Terminal <-> subscription (i.e. computer to "computer" > communications) > · User <-> services I think that these bindings SHOULD NOT be part of the protocols under consideration within the [mobile-ip] working group. Maybe they belong in the [aaa] working group. Maybe there will be some effects within the context-transfer subgroup of [seamoby], because these look like pieces of context that might follow a device around as it carries out the necessary operations for seamless mobility. But I would think that the way the bindings are created and managed is, in the main, something that works at the application level. Maybe there will be some signaling from the protocol stack to the application when something changes the execution context for the application. That's a lot different than making the management of these bindings into a routing-area protocol item. > For reasons of number portability and competition it has to be possible to > change the subscription without changing any of the other identifiers. It > also has to be possible for users (and terminals) to be member of more > subscriptions at the same time. (I.e. the above bindings or relations are > many to many.) These true statements reinforce my earlier suggestions about how the bindings should be managed, which again should be at the application level. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Wed May 16 12:23:43 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13226 for ; Wed, 16 May 2001 12:23:42 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA26928; Wed, 16 May 2001 09:21:15 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA20368; Wed, 16 May 2001 09:17:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4GGGQD00949 for mobile-ip-dist; Wed, 16 May 2001 09:16:26 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4GGGG400938 for ; Wed, 16 May 2001 09:16:16 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA19892 for ; Wed, 16 May 2001 09:16:08 -0700 (PDT) Received: from zrc2s03g.us.nortel.com ([47.103.122.66]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA16818 for ; Wed, 16 May 2001 10:16:09 -0600 (MDT) Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id LAA26176 for ; Wed, 16 May 2001 11:16:41 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Wed, 16 May 2001 11:16:03 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 16 May 2001 11:15:37 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E43023DB91E@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] NAI/need for identifiers Date: Wed, 16 May 2001 11:15:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DE23.6D9B9BB0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C0DE23.6D9B9BB0 Content-Type: text/plain; charset="iso-8859-1" Are you asking if there is a market for a mobile L2 hub/switch or router? -----Original Message----- From: Jack_Fijolek@3com.com [mailto:Jack_Fijolek@3com.com] Sent: Wednesday, May 16, 2001 10:22 AM To: inge.gronbak@telenor.com Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] NAI/need for identifiers Inge, Thanks for the service providers perspective. Can you explain a little further how you physically see this connection used by your customers? For example, I have worked to requirements of multiple simultaneous terminals behind a single subscription ID in a bridging and gateway end customer environments with consumer access devices like cable, DSL or BWA (fixed wireless) modems. The subscriber's access connection is fixed but there can be a subscriber Ethernet or USB LAN behind it with one "modem" gating all transmission of LAN-ISP subscriber data. In those access technologies there are also internal PC modems with multiple simultaneous sessions on a single terminal. In all cases, there is still a concept of primary access terminal or connection device. My question is, as a service provider, do you see this market offering portable gateways that have some well-defined customer interface like 10/100 Ethernet or USB? If so, should there be a requirement for the portable gateway device to have bridging or forwarding characteristics? Should a primary connection device pass any attached device's data transparently? Should it frame the traffic? Should all devices make their own framed connection? Jack inge.gronbak@telenor.com on 05/16/2001 03:35:32 AM Please respond to mobile-ip@sunroof.eng.sun.com Sent by: inge.gronbak@telenor.com To: mobile-ip@sunroof.eng.sun.com cc: (Jack Fijolek/MW/US/3Com) Subject: [mobile-ip] NAI/need for identifiers ------_=_NextPart_001_01C0DE23.6D9B9BB0 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] NAI/need for identifiers

Are you asking if there is a market for a mobile L2 hub/switch or router?

-----Original Message-----
From: Jack_Fijolek@3com.com [mailto:Jack_Fijolek@3com.com]
Sent: Wednesday, May 16, 2001 10:22 AM
To: inge.gronbak@telenor.com
Cc: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] NAI/need for identifiers





Inge,
Thanks for the service providers  perspective. Can you explain a little further
how you physically see this connection used by your customers?

For example, I have worked to requirements of multiple simultaneous terminals
behind a single subscription ID  in a bridging and gateway end customer
environments with consumer access devices like cable, DSL or BWA (fixed
wireless) modems. The subscriber's access connection is fixed but there can be a
subscriber Ethernet or USB LAN behind it with one "modem" gating all
transmission of LAN-ISP subscriber data. In those access technologies there are
also internal PC modems with multiple simultaneous sessions on a single
terminal. In all cases, there is still a concept of primary access terminal or
connection device.

My question is, as a service provider, do you see this market offering portable
gateways that have some well-defined customer interface like 10/100 Ethernet or
USB? If so, should there be a requirement for the portable gateway device to
have bridging or forwarding characteristics? Should a primary connection device
pass any attached device's data transparently? Should it frame the traffic?
Should all devices make their own framed connection?
Jack




inge.gronbak@telenor.com on 05/16/2001 03:35:32 AM

Please respond to mobile-ip@sunroof.eng.sun.com

Sent by:  inge.gronbak@telenor.com


To:   mobile-ip@sunroof.eng.sun.com
cc:    (Jack Fijolek/MW/US/3Com)
Subject:  [mobile-ip] NAI/need for identifiers


------_=_NextPart_001_01C0DE23.6D9B9BB0-- From owner-mobile-ip@sunroof.eng.sun.com Wed May 16 12:25:56 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13274 for ; Wed, 16 May 2001 12:25:55 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23496; Wed, 16 May 2001 09:25:46 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA07958; Wed, 16 May 2001 09:25:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4GGNxI01015 for mobile-ip-dist; Wed, 16 May 2001 09:23:59 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4GGNo401004 for ; Wed, 16 May 2001 09:23:50 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA21538 for ; Wed, 16 May 2001 09:23:44 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA20522 for ; Wed, 16 May 2001 09:23:42 -0700 (PDT) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f4GGNjQ22835 for ; Wed, 16 May 2001 11:23:45 -0500 (CDT) Received: from daebh01nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 16 May 2001 11:23:31 -0500 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Wed, 16 May 2001 11:23:31 -0500 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B03213A35@daeis07nok> To: mobile-ip@sunroof.eng.sun.com Cc: James.Kempf@Sun.COM Subject: RE: FW: [mobile-ip] Times for Low-Latency IPv6 Handoff Date: Wed, 16 May 2001 11:23:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: James, >>Hi Raj, > >>> >>> At least on the downlink the signaling channel is >>> 3.4k. Hence the time for each of the messages roughly >>> double. But, this not a problem as in UMTS DCH multiplexes >>> speech and signaling together. Hence, the above 3.4k is >>> accounted while full rate AMR max (12.2K) is there. Since >>> both are simultaneous there should not be any interruption of >>> speech service while the signaling is exchanged. This normally >>> not the case in TDMA case where speech is interrupted by handoff >>> messages. >>> > >As somebody noted this morning, currently MIP signalling is run >over a traffic channel, not a signalling channel. So this would >mean that the user data traffic would need to be interrupted to >send across the MIP signalling. IP signalling can't currently get the >same kind of parallelism that the wCDMA/UTRAN signalling can. > If the traffic is real-time data, the traffic channel consists of signaling and RT bearer simultaneously. So at the transport layer (DCH) consists of 3.4 Kbps for signaling as well as 12.4 for AMR (max data rate). So the MIP signaling should be carried over the 3.4 kbps channel and as a result will not interrupt the traffic. So if you look at section 6.2.1 (Harri's book) at paragraphs 1 & 2, you will realize that. >If it were possible to do the MIP signalling on a signalling channel, >one could get the kind of parallelism described here, You actually can get that parallelism via the multiplexing feature of DCH. >though the >a data rate of 3.4k would lengthen the handoff even more. However, >as far as I can tell (and the draft is a bit murky on this point), >the current design of the IPv6 fast handoff doesn't seem to allow >the MN to continue send/receive traffic on its old CoA while >at the newAR, The current draft does allow this. What I mean is that the MN can continue to use it's old COA at the new AP, if it did not receive an ACK from the handoff signaling. >so parallelism would not buy anything. The MN would >still have to stop sending/receiving on the old CoA and only >start on the new after the F-BU/F-BACK is complete. > > jak Basavaraj/Shavantha From owner-mobile-ip@sunroof.eng.sun.com Wed May 16 12:39:06 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13649 for ; Wed, 16 May 2001 12:39:05 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10968; Wed, 16 May 2001 09:38:48 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24845; Wed, 16 May 2001 09:38:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4GGafB01117 for mobile-ip-dist; Wed, 16 May 2001 09:36:41 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4GGaW401110 for ; Wed, 16 May 2001 09:36:33 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id JAA06977; Wed, 16 May 2001 09:36:32 -0700 (PDT) Message-Id: <200105161636.JAA06977@heliopolis.eng.sun.com> Date: Wed, 16 May 2001 09:36:32 -0700 (PDT) From: James Kempf Subject: RE: FW: [mobile-ip] Times for Low-Latency IPv6 Handoff To: mobile-ip@sunroof.eng.sun.com, Basavaraj.Patil@nokia.com Cc: James.Kempf@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: xjX06C2qr9Av0ZPayRvvoQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Raj, >If the traffic is real-time data, the traffic channel consists of >signaling and RT bearer simultaneously. So at the transport layer >(DCH) consists of 3.4 Kbps for signaling as well as 12.4 for AMR (max >data rate). So the MIP signaling should be carried over the 3.4 kbps >channel and as a result will not interrupt the traffic. So if you >look at section 6.2.1 (Harri's book) at paragraphs 1 & 2, you will >realize that. > Interesting, thanx. Looks like it is possible to multiplex signalling and real time data on a single logical channel that maps to multiple physical channels. However, it is still not clear from this whether the signalling is restricted to NBAP/wCDMA signalling or whether IP signalling would work. In principle, I think it *could* be done if it isn't currently. Of course, there would need to be some way to distinguish which IP packets were signalling and which not (probably by port number?). >>If it were possible to do the MIP signalling on a signalling channel, >>one could get the kind of parallelism described here, > >You actually can get that parallelism via the multiplexing feature of >DCH. Agreed. >The current draft does allow this. What I mean is that the MN can >continue to use it's old COA at the new AP, if it did not receive an >ACK from the handoff signaling. > Section 5.2 on pg. 33 of draft-ietf-mobileip-fast-mipv6-01.txt talks about a unidirectional tunnel from old AR to new AR but nothing about a reverse tunnel. If there is no reverse tunnel in place, new AR can drop MN's packets with the old CoA because old CoA is not topologically correct in new AR's subnet, if egress filtering is on (as I would expect it to be, to prevent bogus MN from establishing service). Consequently, old AR forwards packets to new AR, who buffers them, but the real time stream still stalls because MN can't get any packets out. Also, it is furthermore unclear whether new AR is allowed to send packets to MN prior to MN sending a Neighbor Advertisement or Fast Neighbor Advertisment to new AR. Exactly how and when NA or F-NA is used seemed also somewhat murky to me. It is not shown on the timing diagrams for the protocol, for example, though it is discussed in Section 5.3. jak From owner-mobile-ip@sunroof.eng.sun.com Wed May 16 12:52:51 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13924 for ; Wed, 16 May 2001 12:52:50 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28156; Wed, 16 May 2001 09:51:46 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28576; Wed, 16 May 2001 09:51:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4GGnTS01172 for mobile-ip-dist; Wed, 16 May 2001 09:49:30 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4GGnL401165 for ; Wed, 16 May 2001 09:49:21 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA12806 for ; Wed, 16 May 2001 09:49:20 -0700 (PDT) Received: from prserv.net (out1.prserv.net [32.97.166.31] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA10384 for ; Wed, 16 May 2001 10:49:22 -0600 (MDT) Received: from [32.100.5.243] (slip129-37-43-7.il.us.prserv.net[129.37.43.7]) by prserv.net (out1) with ESMTP id <2001051616471520105d4gine>; Wed, 16 May 2001 16:47:15 +0000 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="============_-1222090804==_ma============" X-Sender: ahmrphd@pop3.attglobal.net Message-Id: In-Reply-To: <7923615E38B1D21187EE0008C70DA9C8AA4969@fou-kj-21-001.nta.no> Date: Wed, 16 May 2001 09:47:18 -0700 To: mobile-ip@sunroof.eng.sun.com From: Arthur Ross Subject: Re: [mobile-ip] NAI/need for identifiers Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --============_-1222090804==_ma============ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 1:35 -0700 05/16/2001, inge.gronbak@telenor.com wrote: > >This is a cry of confusion from an employee of a "large" Norwegian operator= =2E > >Could you please explain to me how the NAI, other identifiers and the IP >address are used to meet the following requirements (which I jotted down >very quickly): > >The required separate identifiers for service provisioning are as follows: >=B7 Subscription >=B7 User >=B7 Terminal >=B7 Session >All four are required, and it is yet unclear to me how this is solved. Thes= e >identifiers are needed to accommodate e.g. security and the following three >levels of mobility: [snip] Once again, this thread is nibbling around the edges of a much larger, very important discussion. My apologies to those of you who have already seen this from my prior posting to the SEAMOBY list, but it is germane to this thread too. We talk at great length about hosts, mobile nodes, etc., but the notion of "host" or "node" is getting fuzzy. Originally [ARPANET] "hosts" were big computers that filled rooms, had squads of people caring for & feeding them, and the protocols were designed with that implicit mindset. But nowadays, when the embodiments of the "hosts" may cost just pennies, may be flyspeck-sized, and may be found in all sorts of non-traditional, often low-tech kinds of places/things, the concepts need revision. My strong feeling is that the questions to be addressed should be things lik= e: * What are the entities that are the endpoints of the communication? When the address space is large enough [IPv6] to give every cell of every hu= man being and every grain of sand on earth its own IP address, perhaps the model and uses of it need to be re-thought. * What is MEANT by "mobility"? Or alternatively what is it that is moving= ? I can envision many possible answers/opinions. * How are those endpoints identified for various purposes? A major exampl= e: paging - IP address, as in MIP, is [perhaps] meaningful for routing purposes, but meaningless in the application context. One could envisio= n a concept whereby there are various "views" of the endpoint space applicable for different sorts of applications (e.g. routing, logical, name-based, geographic, organizational hierarchy, demographic group, etc.). In this light, paging/addressing might be viewed/implemented as a kind of distributed database query. * What is the nature of the "identity" associated with, say, individual humans, that provides the basis/data for authentication? I'm thinking of something like a great-grandson of the SIM card concept, for example [... or maybe you will begin every session with a request to "spit in t= he little spitoon" on your laptop for the DNA analysis that authenticates the session. ;-) ]. * Is a broader concept of the "addressable individual" needed? [I have in mind functional pseudo-persons, associated with business & organization roles, databases of various kinds, etc.] * Is a "discovery" functionality needed? I.e. a generic method for exposi= ng the internal structure of subnets and/or databases? I.e. a way of creat= ing the local streetmap of an unfamiliar neighborhood? This might be especially important if the "mobile" entities have internal, time-varying structur= e [think, for a simple example, of folks in vehicles on the highway, each potentially with his PDA, phone, medical monitoring device, plus the "smart car" itself, etc., all of which are communicating through a wireless gateway of some kind; just such things are currently under development]. * What are the business and regulatory models? Giant electro-political hot potato, but very important, IMHO. The regulatory folks need to clea= n up their act if the mythical "wireless Internet" is to be anything othe= r than hype and snake oil. I have in mind here a complete re-think of the spectrum license auction notion. I personally believe that auctioning the ether was, and still i= s, a bad idea, not in the long term public interest. The pro-auction argument is that real estate-like ownership is a prerequisite if investors are going to pony up the huge capital expenditures needed to build the "next generation" networks. The fallacy here, IMHO, is the PSTN-centric mindset. If what you are talking about is universal, readily-available wirless IP service, starting from a telephone network is very obviously a bad way of doing it. IMHO wireless IP access should be viewed, for regulatory purposes, as more like a public utilit= y than the proverbial "walled garden" for which the owner charges at the tollbooth. You could make a lot of money by letting someone charge for = the air we breathe too, but in neither case is it good public policy. There are many aspects to this, and many ways of pulling it off, as I have tried to convince the FCC for some time now. * What replaces the "walled garden" wireless air interfaces? Good questio= n. I have some opinions as to what it MIGHT be, but other opinions may [read: "undoubtedly will"] differ. This will be, I hope, the subject of this new "wireless internet" discussion group. --============_-1222090804==_ma============ Content-Type: text/enriched; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 1:35 -0700 05/16/2001, inge.gronbak@telenor.com wrote: > >This is a cry of confusion from an employee of a "large" Norwegian operator. > >Could you please explain to me how the NAI, other identifiers and the IP >address are used to meet the following requirements (which I jotted down >very quickly): > >The required separate identifiers for service provisioning are as follows: >=B7 Subscription >=B7 User >=B7 Terminal >=B7 Session >All four are required, and it is yet unclear to me how this is solved. These >identifiers are needed to accommodate e.g. security and the following three >levels of mobility: [snip] Once again, this thread is nibbling around the edges of a much larger, very important discussion.=20 My apologies to those of you who have already seen this from my prior posting to the SEAMOBY list, but it is germane to this thread too. < We talk at great length about hosts, mobile nodes, etc., but the notion of "host" or "node" is getting fuzzy. Originally [ARPANET] "hosts" were big computers that filled rooms, had squads of people caring for & feeding them, and the protocols were designed with that implicit mindset. But nowadays, when the embodiments of the "hosts" may cost just pennies, may be flyspeck-sized, and may be found in all sorts of non-traditional, often low-tech kinds of places/things, the concepts need revision. My strong feeling is that the questions to be addressed should be things like: * What are the entities that are the endpoints of the communication? When the address space is large enough [IPv6] to give every cell of every human being and every grain of sand on earth its own IP address, perhaps the model and uses of it need to be re-thought. * What is MEANT by "mobility"? Or alternatively what is it that is moving? I can envision many possible answers/opinions. * How are those endpoints identified for various purposes? A major example: paging - IP address, as in MIP, is [perhaps] meaningful for routing purposes, but meaningless in the application context. One could envision a concept whereby there are various "views" of the endpoint space applicable for different sorts of applications (e.g. routing, logical, name-based, geographic, organizational hierarchy, demographic group, etc.). In this light, paging/addressing might be viewed/implemented as a kind of distributed database query. * What is the nature of the "identity" associated with, say, individual humans, that provides the basis/data for authentication? I'm thinking of something like a great-grandson of the SIM card concept, for example [... or maybe you will begin every session with a request to "spit in the little spitoon" on your laptop for the DNA analysis that authenticates the session. ;-) ]. * Is a broader concept of the "addressable individual" needed? [I have in mind functional pseudo-persons, associated with business & organization roles, databases of various kinds, etc.] * Is a "discovery" functionality needed? I.e. a generic method for exposing the internal structure of subnets and/or databases? I.e. a way of creating the local streetmap of an unfamiliar neighborhood? This might be especially important if the "mobile" entities have internal, time-varying structure [think, for a simple example, of folks in vehicles on the highway, each potentially with his PDA, phone, medical monitoring device, plus the "smart car" itself, etc., all of which are communicating through a wireless gateway of some kind; just such things are currently under development]. * What are the business and regulatory models? Giant electro-political hot potato, but very important, IMHO. The regulatory folks need to clean up their act if the mythical "wireless Internet" is to be anything other than hype and snake oil.=20 I have in mind here a complete re-think of the spectrum license auction notion. I personally believe that auctioning the ether was, and still is, a bad idea, not in the long term public interest. The pro-auction argument is that real estate-like ownership is a prerequisite if investors are going to pony up the huge capital expenditures needed to build the "next generation" networks. The fallacy here, IMHO, is the PSTN-centric mindset. If what you are talking about is universal, readily-available wirless IP service, starting from a telephone network is very obviously a bad way of doing it. IMHO wireless IP access should be viewed, for regulatory purposes, as more like a public utility than the proverbial "walled garden" for which the owner charges at the tollbooth. You could make a lot of money by letting someone charge for the air we breathe too, but in neither case is it good public policy. There are many aspects to this, and many ways of pulling it off, as I have tried to convince the FCC for some time now. * What replaces the "walled garden" wireless air interfaces? Good question. I have some opinions as to what it MIGHT be, but other opinions may [read: "undoubtedly will"] differ. This will be, I hope, the subject of this new "wireless internet" discussion group. < --============_-1222090804==_ma============-- From owner-mobile-ip@sunroof.eng.sun.com Wed May 16 14:17:15 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16072 for ; Wed, 16 May 2001 14:17:14 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA11056; Wed, 16 May 2001 11:15:20 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA22385; Wed, 16 May 2001 11:14:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4GID1D01510 for mobile-ip-dist; Wed, 16 May 2001 11:13:01 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4GICq401503 for ; Wed, 16 May 2001 11:12:52 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08917 for ; Wed, 16 May 2001 11:12:51 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05457 for ; Wed, 16 May 2001 11:12:51 -0700 (PDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Wed, 16 May 2001 14:06:14 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Cc: Phil Roberts Subject: [mobile-ip] MIP v6 update Date: Wed, 16 May 2001 14:06:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: We've been getting some questions recently about the current status of the MIP v6 work. The WG chairs have been working with the IESG and IAB to come up with a set of requirements to satisfy concerns about the security of the MIP v6 protocol. The security folks suggested that it would help to understand the requirements better if there was a threat model against which it could be evaluated. So the chairs and a few ADs are currently putting together a start to the threat model as well. We hope to update the working group soon with a draft threat model and requirements statement. In the interim if the WG has thoughts on particular kinds of threats that need to be evaluated, discussion on the mailing list is encouraged. Pekka Nikander posted the start of a threat analysis back on March 19. Folks are encouraged to look for threats that he didn't already mention. From owner-mobile-ip@sunroof.eng.sun.com Wed May 16 14:36:41 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16424 for ; Wed, 16 May 2001 14:36:40 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA23499; Wed, 16 May 2001 11:34:45 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28018; Wed, 16 May 2001 11:34:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4GIWNL01642 for mobile-ip-dist; Wed, 16 May 2001 11:32:23 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4GIWE401635 for ; Wed, 16 May 2001 11:32:14 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA09424 for ; Wed, 16 May 2001 11:32:09 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA12763 for ; Wed, 16 May 2001 11:32:07 -0700 (PDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Wed, 16 May 2001 14:25:29 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] NAI/need ... RANT Date: Wed, 16 May 2001 14:25:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DE35.957DE464" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C0DE35.957DE464 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 thanks for helping inge understand some issues. I don't really = want to see another RANT thread started on this mailing list. Perhaps it would = be appropriate to discuss it on the wireless interest mailing list Phil N. = set up. I think he said it was in part intended for such purposes. =20 Phil =20 -----Original Message----- From: Arthur Ross [mailto:a.ross@ieee.org] Sent: Wednesday, May 16, 2001 12:47 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] NAI/need for identifiers At 1:35 -0700 05/16/2001, inge.gronbak@telenor.com wrote:=20 >=20 >This is a cry of confusion from an employee of a "large" Norwegian operator.=20 >=20 >Could you please explain to me how the NAI, other identifiers and the = IP=20 >address are used to meet the following requirements (which I jotted = down=20 >very quickly):=20 >=20 >The required separate identifiers for service provisioning are as = follows:=20 >=B7 Subscription=20 >=B7 User=20 >=B7 Terminal=20 >=B7 Session=20 >All four are required, and it is yet unclear to me how this is solved. These=20 >identifiers are needed to accommodate e.g. security and the following = three >levels of mobility:=20 [snip]=20 Once again, this thread is nibbling around the edges of a much larger, = very important discussion.=20 My apologies to those of you who have already seen this from my prior posting to the SEAMOBY list, but it is germane to this thread too.=20 =20 We talk at great length about hosts, mobile nodes, etc., but the notion = of "host" or "node" is getting fuzzy. Originally [ARPANET] "hosts" were = big=20 computers that filled rooms, had squads of people caring for & feeding = them, and the protocols were designed with that implicit mindset. But = nowadays, when the=20 embodiments of the "hosts" may cost just pennies, may be = flyspeck-sized, and may=20 be found in all sorts of non-traditional, often low-tech kinds of places/things,=20 the concepts need revision.=20 My strong feeling is that the questions to be addressed should be = things like:=20 * What are the entities that are the endpoints of the communication? = When=20 the address space is large enough [IPv6] to give every cell of every = human=20 being and every grain of sand on earth its own IP address, perhaps the=20 model and uses of it need to be re-thought.=20 * What is MEANT by "mobility"? Or alternatively what is it that is = moving?=20 I can envision many possible answers/opinions.=20 * How are those endpoints identified for various purposes? A major = example:=20 paging - IP address, as in MIP, is [perhaps] meaningful for routing=20 purposes, but meaningless in the application context. One could = envision=20 a concept whereby there are various "views" of the endpoint space=20 applicable for different sorts of applications (e.g. routing, logical,=20 name-based, geographic, organizational hierarchy, demographic group,=20 etc.). In this light, paging/addressing might be viewed/implemented=20 as a kind of distributed database query.=20 * What is the nature of the "identity" associated with, say, individual = humans, that provides the basis/data for authentication? I'm thinking=20 of something like a great-grandson of the SIM card concept, for example = [... or maybe you will begin every session with a request to "spit in = the=20 little spitoon" on your laptop for the DNA analysis that authenticates=20 the session. ;-) ].=20 * Is a broader concept of the "addressable individual" needed? [I have = in=20 mind functional pseudo-persons, associated with business & organization = roles, databases of various kinds, etc.]=20 * Is a "discovery" functionality needed? I.e. a generic method for = exposing=20 the internal structure of subnets and/or databases? I.e. a way of = creating=20 the local streetmap of an unfamiliar neighborhood? This might be = especially=20 important if the "mobile" entities have internal, time-varying = structure=20 [think, for a simple example, of folks in vehicles on the highway, each = potentially with his PDA, phone, medical monitoring device, plus the=20 "smart car" itself, etc., all of which are communicating through a=20 wireless gateway of some kind; just such things are currently under=20 development].=20 * What are the business and regulatory models? Giant electro-political=20 hot potato, but very important, IMHO. The regulatory folks need to = clean=20 up their act if the mythical "wireless Internet" is to be anything = other=20 than hype and snake oil.=20 I have in mind here a complete re-think of the spectrum license auction = notion. I personally believe that auctioning the ether was, and still = is,=20 a bad idea, not in the long term public interest. The pro-auction=20 argument is that real estate-like ownership is a prerequisite if=20 investors are going to pony up the huge capital expenditures needed to=20 build the "next generation" networks. The fallacy here, IMHO, is the=20 PSTN-centric mindset. If what you are talking about is universal,=20 readily-available wirless IP service, starting from a telephone network = is very obviously a bad way of doing it. IMHO wireless IP access=20 should be viewed, for regulatory purposes, as more like a public = utility=20 than the proverbial "walled garden" for which the owner charges at the=20 tollbooth. You could make a lot of money by letting someone charge for = the=20 air we breathe too, but in neither case is it good public policy.=20 There are many aspects to this, and many ways of pulling it off, as I=20 have tried to convince the FCC for some time now.=20 * What replaces the "walled garden" wireless air interfaces? Good = question.=20 I have some opinions as to what it MIGHT be, but other opinions may=20 [read: "undoubtedly will"] differ. This will be, I hope, the subject of = this new "wireless internet" discussion group.=20 =20 ------_=_NextPart_001_01C0DE35.957DE464 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
    thanks for helping inge understand some = issues. =20 I don't really want to see another RANT thread started on this mailing=20 list.  Perhaps it would be appropriate to discuss it on the = wireless=20 interest mailing list Phil N. set up.  I think he said it was in = part=20 intended for such purposes.
 
Phil
 
-----Original Message-----
From: Arthur Ross=20 [mailto:a.ross@ieee.org]
Sent: Wednesday, May 16, 2001 = 12:47=20 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: = [mobile-ip] NAI/need for identifiers

At 1:35 -0700 05/16/2001, inge.gronbak@telenor.com wrote:

>

>This is a cry of confusion from an employee of a "large" = Norwegian=20 operator.

>

>Could you please explain to me how the NAI, other identifiers = and the=20 IP

>address are used to meet the following requirements (which I = jotted=20 down

>very quickly):

>

>The required separate identifiers for service provisioning are = as=20 follows:

>=B7      Subscription

>=B7      User

>=B7      Terminal

>=B7      Session

>All four are required, and it is yet unclear to me how this is = solved.=20 These

>identifiers are needed to accommodate e.g. security and the = following=20 three

>levels of mobility:


[snip]


Once again, this thread is nibbling around the edges of a much = larger, very=20 important discussion.


My apologies to those of you who have already seen this from my = prior=20 posting to the SEAMOBY list, but it is germane to this thread too. =


<RANT>


We talk at great length about hosts, mobile nodes, etc., but the = notion of=20 "host" or "node" is getting fuzzy. Originally [ARPANET] "hosts" were = big

computers that filled rooms, had squads of people caring for & = feeding=20 them, and the protocols were designed with that implicit mindset. But = nowadays, when the

embodiments of the "hosts" may cost just pennies, may be = flyspeck-sized,=20 and may

be found in all sorts of non-traditional, often low-tech kinds of=20 places/things,

the concepts need revision.


My strong feeling is that the questions to be addressed should be = things=20 like:


* What are the entities that are the endpoints of the = communication?=20 When

the address space is large enough [IPv6] to give every cell of = every human=20

being and every grain of sand on earth its own IP address, perhaps = the

model and uses of it need to be re-thought.


* What is MEANT by "mobility"? Or alternatively what is = it=20 that is moving?

I can envision many possible answers/opinions.


* How are those endpoints identified for various purposes? = A major=20 example:

paging - IP address, as in MIP, is [perhaps] meaningful for = routing

purposes, but meaningless in the application context. One could = envision=20

a concept whereby there are various "views" of the endpoint space =

applicable for different sorts of applications (e.g. routing, = logical,

name-based, geographic, organizational hierarchy, demographic = group,

etc.). In this light, paging/addressing might be = viewed/implemented

as a kind of distributed database query.


* What is the nature of the "identity" associated with, = say,=20 individual

humans, that provides the basis/data for authentication? I'm = thinking

of something like a great-grandson of the SIM card concept, for = example=20

[... or maybe you will begin every session with a request to "spit = in the=20

little spitoon" on your laptop for the DNA analysis that = authenticates

the session. ;-) ].


* Is a broader concept of the "addressable individual" = needed? [I=20 have in

mind functional pseudo-persons, associated with business & = organization=20

roles, databases of various kinds, etc.]


* Is a "discovery" functionality needed? I.e. a generic = method for=20 exposing

the internal structure of subnets and/or databases? I.e. a way of = creating=20

the local streetmap of an unfamiliar neighborhood? This might be = especially=20

important if the "mobile" entities have internal, time-varying = structure=20

[think, for a simple example, of folks in vehicles on the highway, = each=20

potentially with his PDA, phone, medical monitoring device, plus = the

"smart car" itself, etc., all of which are communicating through a =

wireless gateway of some kind; just such things are currently = under

development].


* What are the business and regulatory models? Giant=20 electro-political

hot potato, but very important, IMHO. The regulatory folks need to = clean=20

up their act if the mythical "wireless Internet" is to be anything = other=20

than hype and snake oil.


I have in mind here a complete re-think of the spectrum license = auction=20

notion. I personally believe that auctioning the ether was, and = still is,=20

a bad idea, not in the long term public interest. The pro-auction =

argument is that real estate-like ownership is a prerequisite if =

investors are going to pony up the huge capital expenditures = needed to

build the "next generation" networks. The fallacy here, IMHO, is = the

PSTN-centric mindset. If what you are talking about is universal, =

readily-available wirless IP service, starting from a telephone = network=20

is very obviously a bad way of doing it. IMHO wireless IP access =

should be viewed, for regulatory purposes, as more like a public = utility=20

than the proverbial "walled garden" for which the owner charges at = the

tollbooth. You could make a lot of money by letting someone charge = for the=20

air we breathe too, but in neither case is it good public policy. =


There are many aspects to this, and many ways of pulling it off, = as I

have tried to convince the FCC for some time now.


* What replaces the "walled garden" wireless air = interfaces? Good=20 question.

I have some opinions as to what it MIGHT be, but other opinions = may

[read: "undoubtedly will"] differ. This will be, I hope, the = subject of=20

this new "wireless internet" discussion group.


</RANT>

------_=_NextPart_001_01C0DE35.957DE464-- From owner-mobile-ip@sunroof.eng.sun.com Wed May 16 14:39:10 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16473 for ; Wed, 16 May 2001 14:39:09 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA26125; Wed, 16 May 2001 11:39:13 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA22477; Wed, 16 May 2001 11:32:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4GITwg01607 for mobile-ip-dist; Wed, 16 May 2001 11:29:58 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4GITo401600 for ; Wed, 16 May 2001 11:29:50 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA26478 for ; Wed, 16 May 2001 11:29:49 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21788 for ; Wed, 16 May 2001 11:29:49 -0700 (PDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Wed, 16 May 2001 14:23:12 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] NAI/need for identifiers Date: Wed, 16 May 2001 14:23:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f4GITp401601 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by mercury.Sun.COM id LAA26125 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA16473 Hi Inge, questions and comments inline. Hope they help. Phil > -----Original Message----- > From: inge.gronbak@telenor.com [mailto:inge.gronbak@telenor.com] > Sent: Wednesday, May 16, 2001 4:36 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] NAI/need for identifiers > > > HI, (My first mail on an IETF list so I know I have done > something wrong.) No, it's a fine first attempt. I'm not sure this mailing list is the correct place to discuss all of these issues, but I'm not sure where to suggest you take them. > > This is a cry of confusion from an employee of a "large" > Norwegian operator. > > Could you please explain to me how the NAI, other identifiers > and the IP > address are used to meet the following requirements (which I > jotted down > very quickly): Could you let us know where these requirements come from? Are these requirements for services your company wants to provide or from some SDO or from your own ideas about the way services should be provided? > > The required separate identifiers for service provisioning > are as follows: > · Subscription > · User > · Terminal > · Session > All four are required, and it is yet unclear to me how this > is solved. These > identifiers are needed to accommodate e.g. security and the > following three > levels of mobility: > User mobility (i.e. the user can freely move between > different terminals as > long as authorised to do so) > Terminal mobility (i.e. the terminal is allowed to change > access point/point > of attachment within the given level of authorisation) > Service mobility (i.e. a authorised user may access, possibly > personalised, > services from any point of attachment) > The identifiers are also required to allow operators to maintain the > following bindings: > · Session <-> terminal (e.g. for charging record) > · Terminal <-> user <-> subscription > · Terminal <-> subscription (i.e. computer to "computer" > communications) > · User <-> services > > For reasons of number portability and competition it has to > be possible to > change the subscription without changing any of the other > identifiers. It > also has to be possible for users (and terminals) to be member of more > subscriptions at the same time. (I.e. the above bindings or > relations are > many to many.) I'm not sure I understand everything you want to do, but I think it's safe to say that MIP is a solution for terminal mobility. It is a protocol for delivering packets to the correct destination when that destination is moving. You asked about the use of the NAI. The NAI extension is there to allow users to identify themselves for the purpose of AAA authorization (and also home address assignment). It's not currently within our charter to tackle issues such as user to device bindings and service provisioning and it would probably be hard to convince me that this work would belong in this working group. > > Inge > -------------------------------------------- > Inge Grønbæk > Telenor FoU > Postboks 83, > 2027 Kjeller, Norway > Phone (DDI): (+47) 63 84 88 57, > (mobile): (+47) 91 88 17 77. > Telefax.: (+47) 63 81 00 76. > E-mail: inge.gronbak@telenor.com > From owner-mobile-ip@sunroof.eng.sun.com Wed May 16 17:15:18 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19432 for ; Wed, 16 May 2001 17:15:18 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06687; Wed, 16 May 2001 14:15:11 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA00085; Wed, 16 May 2001 14:13:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4GLBV402035 for mobile-ip-dist; Wed, 16 May 2001 14:11:31 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4GLBM402028 for ; Wed, 16 May 2001 14:11:22 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA15964 for ; Wed, 16 May 2001 14:11:21 -0700 (PDT) From: Jack_Fijolek@3com.com Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05382 for ; Wed, 16 May 2001 14:11:21 -0700 (PDT) Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4GL9Yb20878; Wed, 16 May 2001 14:09:34 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104]) by opal.3com.com (Switch-2.1.1/Switch-2.1.0) with SMTP id f4GLBKi13218; Wed, 16 May 2001 14:11:20 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256A4E.00745E1F ; Wed, 16 May 2001 14:11:02 -0700 X-Lotus-FromDomain: 3COM To: gmorrow@nortelnetworks.com cc: mobile-ip@sunroof.eng.sun.com Message-ID: <88256A4E.00745B99.00@hqoutbound.ops.3com.com> Date: Wed, 16 May 2001 16:11:11 -0500 Subject: RE: [mobile-ip] NAI/need for identifiers Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=St5HvdKdxzI7oRJguu5lg24rx3rhMZdMygail7jdUOAfQ6pxkJ2HfmNu" Content-Disposition: inline Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --0__=St5HvdKdxzI7oRJguu5lg24rx3rhMZdMygail7jdUOAfQ6pxkJ2HfmNu Content-type: text/plain; charset=us-ascii Content-Disposition: inline Glenn, IMHO, the requirements implied support for multiple "simultaneously active" terminal devices per mobile subscriber at the same location. I am trying to understand the bounds on the physical connection support being asked for. Jack "Glenn Morrow" on 05/16/2001 11:15:31 AM Please respond to mobile-ip@sunroof.eng.sun.com Sent by: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com cc: (Jack Fijolek/MW/US/3Com) Subject: RE: [mobile-ip] NAI/need for identifiers Are you asking if there is a market for a mobile L2 hub/switch or router? -----Original Message----- From: Jack_Fijolek@3com.com [mailto:Jack_Fijolek@3com.com] Sent: Wednesday, May 16, 2001 10:22 AM To: inge.gronbak@telenor.com Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] NAI/need for identifiers Inge, Thanks for the service providers perspective. Can you explain a little further how you physically see this connection used by your customers? For example, I have worked to requirements of multiple simultaneous terminals behind a single subscription ID in a bridging and gateway end customer environments with consumer access devices like cable, DSL or BWA (fixed wireless) modems. The subscriber's access connection is fixed but there can be a subscriber Ethernet or USB LAN behind it with one "modem" gating all transmission of LAN-ISP subscriber data. In those access technologies there are also internal PC modems with multiple simultaneous sessions on a single terminal. In all cases, there is still a concept of primary access terminal or connection device. My question is, as a service provider, do you see this market offering portable gateways that have some well-defined customer interface like 10/100 Ethernet or USB? If so, should there be a requirement for the portable gateway device to have bridging or forwarding characteristics? Should a primary connection device pass any attached device's data transparently? Should it frame the traffic? Should all devices make their own framed connection? Jack inge.gronbak@telenor.com on 05/16/2001 03:35:32 AM Please respond to mobile-ip@sunroof.eng.sun.com Sent by: inge.gronbak@telenor.com To: mobile-ip@sunroof.eng.sun.com cc: (Jack Fijolek/MW/US/3Com) Subject: [mobile-ip] NAI/need for identifiers --0__=St5HvdKdxzI7oRJguu5lg24rx3rhMZdMygail7jdUOAfQ6pxkJ2HfmNu Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1NC41OSI+DQo8VElUTEU+UkU6IFtt b2JpbGUtaXBdIE5BSS9uZWVkIGZvciBpZGVudGlmaWVyczwvVElUTEU+DQo8L0hFQUQ+DQo8Qk9E WT4NCg0KPFA+PEZPTlQgU0laRT0yPkFyZSB5b3UgYXNraW5nIGlmIHRoZXJlIGlzIGEgbWFya2V0 IGZvciBhIG1vYmlsZSBMMiBodWIvc3dpdGNoIG9yIHJvdXRlcj88L0ZPTlQ+DQo8L1A+DQoNCjxQ PjxGT05UIFNJWkU9Mj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvRk9OVD4NCjxCUj48Rk9O VCBTSVpFPTI+RnJvbTogSmFja19GaWpvbGVrQDNjb20uY29tIFs8QSBIUkVGPSJtYWlsdG86SmFj a19GaWpvbGVrQDNjb20uY29tIj5tYWlsdG86SmFja19GaWpvbGVrQDNjb20uY29tPC9BPl08L0ZP TlQ+DQo8QlI+PEZPTlQgU0laRT0yPlNlbnQ6IFdlZG5lc2RheSwgTWF5IDE2LCAyMDAxIDEwOjIy IEFNPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5UbzogaW5nZS5ncm9uYmFrQHRlbGVub3IuY29t PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5DYzogbW9iaWxlLWlwQHN1bnJvb2YuZW5nLnN1bi5j b208L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPlN1YmplY3Q6IFJlOiBbbW9iaWxlLWlwXSBOQUkv bmVlZCBmb3IgaWRlbnRpZmllcnM8L0ZPTlQ+DQo8L1A+DQo8QlI+DQo8QlI+DQo8QlI+DQo8QlI+ DQoNCjxQPjxGT05UIFNJWkU9Mj5JbmdlLDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+VGhhbmtz IGZvciB0aGUgc2VydmljZSBwcm92aWRlcnMmbmJzcDsgcGVyc3BlY3RpdmUuIENhbiB5b3UgZXhw bGFpbiBhIGxpdHRsZSBmdXJ0aGVyPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5ob3cgeW91IHBo eXNpY2FsbHkgc2VlIHRoaXMgY29ubmVjdGlvbiB1c2VkIGJ5IHlvdXIgY3VzdG9tZXJzPzwvRk9O VD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPkZvciBleGFtcGxlLCBJIGhhdmUgd29ya2VkIHRv IHJlcXVpcmVtZW50cyBvZiBtdWx0aXBsZSBzaW11bHRhbmVvdXMgdGVybWluYWxzPC9GT05UPg0K PEJSPjxGT05UIFNJWkU9Mj5iZWhpbmQgYSBzaW5nbGUgc3Vic2NyaXB0aW9uIElEJm5ic3A7IGlu IGEgYnJpZGdpbmcgYW5kIGdhdGV3YXkgZW5kIGN1c3RvbWVyPC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9Mj5lbnZpcm9ubWVudHMgd2l0aCBjb25zdW1lciBhY2Nlc3MgZGV2aWNlcyBsaWtlIGNhYmxl LCBEU0wgb3IgQldBIChmaXhlZDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+d2lyZWxlc3MpIG1v ZGVtcy4gVGhlIHN1YnNjcmliZXIncyBhY2Nlc3MgY29ubmVjdGlvbiBpcyBmaXhlZCBidXQgdGhl cmUgY2FuIGJlIGE8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnN1YnNjcmliZXIgRXRoZXJuZXQg b3IgVVNCIExBTiBiZWhpbmQgaXQgd2l0aCBvbmUgJnF1b3Q7bW9kZW0mcXVvdDsgZ2F0aW5nIGFs bDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+dHJhbnNtaXNzaW9uIG9mIExBTi1JU1Agc3Vic2Ny aWJlciBkYXRhLiBJbiB0aG9zZSBhY2Nlc3MgdGVjaG5vbG9naWVzIHRoZXJlIGFyZTwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+YWxzbyBpbnRlcm5hbCBQQyBtb2RlbXMgd2l0aCBtdWx0aXBsZSBz aW11bHRhbmVvdXMgc2Vzc2lvbnMgb24gYSBzaW5nbGU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y PnRlcm1pbmFsLiBJbiBhbGwgY2FzZXMsIHRoZXJlIGlzIHN0aWxsIGEgY29uY2VwdCBvZiBwcmlt YXJ5IGFjY2VzcyB0ZXJtaW5hbCBvcjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Y29ubmVjdGlv biBkZXZpY2UuPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+TXkgcXVlc3Rpb24gaXMs IGFzIGEgc2VydmljZSBwcm92aWRlciwgZG8geW91IHNlZSB0aGlzIG1hcmtldCBvZmZlcmluZyBw b3J0YWJsZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Z2F0ZXdheXMgdGhhdCBoYXZlIHNvbWUg d2VsbC1kZWZpbmVkIGN1c3RvbWVyIGludGVyZmFjZSBsaWtlIDEwLzEwMCBFdGhlcm5ldCBvcjwv Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+VVNCPyBJZiBzbywgc2hvdWxkIHRoZXJlIGJlIGEgcmVx dWlyZW1lbnQgZm9yIHRoZSBwb3J0YWJsZSBnYXRld2F5IGRldmljZSB0bzwvRk9OVD4NCjxCUj48 Rk9OVCBTSVpFPTI+aGF2ZSBicmlkZ2luZyBvciBmb3J3YXJkaW5nIGNoYXJhY3RlcmlzdGljcz8g U2hvdWxkIGEgcHJpbWFyeSBjb25uZWN0aW9uIGRldmljZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF PTI+cGFzcyBhbnkgYXR0YWNoZWQgZGV2aWNlJ3MgZGF0YSB0cmFuc3BhcmVudGx5PyBTaG91bGQg aXQgZnJhbWUgdGhlIHRyYWZmaWM/PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5TaG91bGQgYWxs IGRldmljZXMgbWFrZSB0aGVpciBvd24gZnJhbWVkIGNvbm5lY3Rpb24/PC9GT05UPg0KPEJSPjxG T05UIFNJWkU9Mj5KYWNrPC9GT05UPg0KPC9QPg0KPEJSPg0KPEJSPg0KPEJSPg0KDQo8UD48Rk9O VCBTSVpFPTI+aW5nZS5ncm9uYmFrQHRlbGVub3IuY29tIG9uIDA1LzE2LzIwMDEgMDM6MzU6MzIg QU08L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5QbGVhc2UgcmVzcG9uZCB0byBtb2Jp bGUtaXBAc3Vucm9vZi5lbmcuc3VuLmNvbTwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0y PlNlbnQgYnk6Jm5ic3A7IGluZ2UuZ3JvbmJha0B0ZWxlbm9yLmNvbTwvRk9OVD4NCjwvUD4NCjxC Uj4NCg0KPFA+PEZPTlQgU0laRT0yPlRvOiZuYnNwOyZuYnNwOyBtb2JpbGUtaXBAc3Vucm9vZi5l bmcuc3VuLmNvbTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Y2M6Jm5ic3A7Jm5ic3A7Jm5ic3A7 IChKYWNrIEZpam9sZWsvTVcvVVMvM0NvbSk8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPlN1Ympl Y3Q6Jm5ic3A7IFttb2JpbGUtaXBdIE5BSS9uZWVkIGZvciBpZGVudGlmaWVyczwvRk9OVD4NCjwv UD4NCjxCUj4NCg0KPC9CT0RZPg0KPC9IVE1MPg0K --0__=St5HvdKdxzI7oRJguu5lg24rx3rhMZdMygail7jdUOAfQ6pxkJ2HfmNu-- From owner-mobile-ip@sunroof.eng.sun.com Thu May 17 07:02:13 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA13411 for ; Thu, 17 May 2001 07:02:13 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA12559; Thu, 17 May 2001 04:02:07 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA08437; Thu, 17 May 2001 04:01:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4HB05103266 for mobile-ip-dist; Thu, 17 May 2001 04:00:05 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4HAxl403259 for ; Thu, 17 May 2001 03:59:48 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA14819 for ; Thu, 17 May 2001 03:59:46 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA10226 for ; Thu, 17 May 2001 03:59:44 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13308; Thu, 17 May 2001 06:59:34 -0400 (EDT) Message-Id: <200105171059.GAA13308@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-lowlatency-handoffs-v4-01.txt Date: Thu, 17 May 2001 06:59:33 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --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 : Low latency Handoffs in Mobile IPv4 Author(s) : K. Malki et al. Filename : draft-ietf-mobileip-lowlatency-handoffs-v4-01.txt Pages : 45 Date : 16-May-01 Mobile IPv4 describes how a Mobile Node can perform IP-layer handoffs between subnets served by different Foreign Agents. In certain cases, the latency involved in these handoffs can be above the threshold required for the support of delay-sensitive or real-time services. The aim of this document is to present two methods to achieve low- latency Mobile IP handoffs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-lowlatency-handoffs-v4-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-lowlatency-handoffs-v4-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-lowlatency-handoffs-v4-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: <20010516123205.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-lowlatency-handoffs-v4-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-lowlatency-handoffs-v4-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010516123205.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Thu May 17 08:33:59 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA15637 for ; Thu, 17 May 2001 08:33:58 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA29318; Thu, 17 May 2001 05:33:56 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA21003; Thu, 17 May 2001 05:33:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4HCVwZ03358 for mobile-ip-dist; Thu, 17 May 2001 05:31:58 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4HCVn403351 for ; Thu, 17 May 2001 05:31:50 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA03330 for ; Thu, 17 May 2001 05:31:50 -0700 (PDT) Received: from quicksilver.ukc.ac.uk (quicksilver.ukc.ac.uk [129.12.21.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA27140 for ; Thu, 17 May 2001 05:31:48 -0700 (PDT) Received: from pelican.ukc.ac.uk ([129.12.200.26]) by quicksilver.ukc.ac.uk with esmtp (Exim 3.22 #4) id 150MpB-0005Ta-00 for mobile-ip@sunroof.eng.sun.com; Thu, 17 May 2001 13:24:13 +0100 Received: from pccomm4.ukc.ac.uk ([129.12.50.119] helo=ukc.ac.uk) by pelican.ukc.ac.uk with esmtp (Exim 3.22 #3) id 150MpE-0001Ga-00 for mobile-ip@sunroof.eng.sun.com; Thu, 17 May 2001 13:24:16 +0100 Message-ID: <3B03C2F0.913F9F55@ukc.ac.uk> Date: Thu, 17 May 2001 13:24:16 +0100 From: Kumarendra Sivarajah X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "mobile-ip@sunroof.eng.sun.com" Subject: [mobile-ip] Mobile IP QoS Requirements for Video/Audio Conferencing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, Does anyone have information on the requirements for IP QoS for Multimedia Application(video/audio) in Mobile IP, or at least where can I find them Thanks in advance, INdran -- /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \ Kumarendra Sivarajah (INdran) / / Electronics Engineering Laboratory \ \ University of Kent at Canterbury / / Telephone(Office): +44 (0)1227 823257 \ \ Telephone(Mobile): +44 (0)7765 007016 / \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ From owner-mobile-ip@sunroof.eng.sun.com Thu May 17 10:27:49 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18299 for ; Thu, 17 May 2001 10:27:48 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA21211; Thu, 17 May 2001 07:27:42 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA25819; Thu, 17 May 2001 07:27:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4HEPPr03492 for mobile-ip-dist; Thu, 17 May 2001 07:25:25 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4HEPG403485 for ; Thu, 17 May 2001 07:25:16 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA24138 for ; Thu, 17 May 2001 07:25:15 -0700 (PDT) Received: from zrc2s03g.nortelnetworks.com ([47.103.122.66]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA21915 for ; Thu, 17 May 2001 07:25:14 -0700 (PDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.nortelnetworks.com (8.9.3+Sun/8.9.1) with ESMTP id JAA02913 for ; Thu, 17 May 2001 09:25:49 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Thu, 17 May 2001 09:19:09 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 17 May 2001 09:24:40 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E43023DC193@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] NAI/need for identifiers Date: Thu, 17 May 2001 09:24:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DEDD.1A351900" X-Orig: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C0DEDD.1A351900 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Arthur, you really should do that informational draft. I think Inge is trying to help with some real requirements. -----Original Message----- From: Arthur Ross [mailto:a.ross@ieee.org] Sent: Wednesday, May 16, 2001 11:47 AM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] NAI/need for identifiers At 1:35 -0700 05/16/2001, inge.gronbak@telenor.com wrote:=20 >=20 >This is a cry of confusion from an employee of a "large" Norwegian operator.=20 >=20 >Could you please explain to me how the NAI, other identifiers and the = IP=20 >address are used to meet the following requirements (which I jotted = down=20 >very quickly):=20 >=20 >The required separate identifiers for service provisioning are as = follows:=20 >=B7 Subscription=20 >=B7 User=20 >=B7 Terminal=20 >=B7 Session=20 >All four are required, and it is yet unclear to me how this is solved. These=20 >identifiers are needed to accommodate e.g. security and the following = three >levels of mobility:=20 [snip]=20 Once again, this thread is nibbling around the edges of a much larger, = very important discussion.=20 My apologies to those of you who have already seen this from my prior posting to the SEAMOBY list, but it is germane to this thread too.=20 =20 We talk at great length about hosts, mobile nodes, etc., but the notion = of "host" or "node" is getting fuzzy. Originally [ARPANET] "hosts" were = big=20 computers that filled rooms, had squads of people caring for & feeding = them, and the protocols were designed with that implicit mindset. But = nowadays, when the=20 embodiments of the "hosts" may cost just pennies, may be = flyspeck-sized, and may=20 be found in all sorts of non-traditional, often low-tech kinds of places/things,=20 the concepts need revision.=20 My strong feeling is that the questions to be addressed should be = things like:=20 * What are the entities that are the endpoints of the communication? = When=20 the address space is large enough [IPv6] to give every cell of every = human=20 being and every grain of sand on earth its own IP address, perhaps the=20 model and uses of it need to be re-thought.=20 * What is MEANT by "mobility"? Or alternatively what is it that is = moving?=20 I can envision many possible answers/opinions.=20 * How are those endpoints identified for various purposes? A major = example:=20 paging - IP address, as in MIP, is [perhaps] meaningful for routing=20 purposes, but meaningless in the application context. One could = envision=20 a concept whereby there are various "views" of the endpoint space=20 applicable for different sorts of applications (e.g. routing, logical,=20 name-based, geographic, organizational hierarchy, demographic group,=20 etc.). In this light, paging/addressing might be viewed/implemented=20 as a kind of distributed database query.=20 * What is the nature of the "identity" associated with, say, individual = humans, that provides the basis/data for authentication? I'm thinking=20 of something like a great-grandson of the SIM card concept, for example = [... or maybe you will begin every session with a request to "spit in = the=20 little spitoon" on your laptop for the DNA analysis that authenticates=20 the session. ;-) ].=20 * Is a broader concept of the "addressable individual" needed? [I have = in=20 mind functional pseudo-persons, associated with business & organization = roles, databases of various kinds, etc.]=20 * Is a "discovery" functionality needed? I.e. a generic method for = exposing=20 the internal structure of subnets and/or databases? I.e. a way of = creating=20 the local streetmap of an unfamiliar neighborhood? This might be = especially=20 important if the "mobile" entities have internal, time-varying = structure=20 [think, for a simple example, of folks in vehicles on the highway, each = potentially with his PDA, phone, medical monitoring device, plus the=20 "smart car" itself, etc., all of which are communicating through a=20 wireless gateway of some kind; just such things are currently under=20 development].=20 * What are the business and regulatory models? Giant electro-political=20 hot potato, but very important, IMHO. The regulatory folks need to = clean=20 up their act if the mythical "wireless Internet" is to be anything = other=20 than hype and snake oil.=20 I have in mind here a complete re-think of the spectrum license auction = notion. I personally believe that auctioning the ether was, and still = is,=20 a bad idea, not in the long term public interest. The pro-auction=20 argument is that real estate-like ownership is a prerequisite if=20 investors are going to pony up the huge capital expenditures needed to=20 build the "next generation" networks. The fallacy here, IMHO, is the=20 PSTN-centric mindset. If what you are talking about is universal,=20 readily-available wirless IP service, starting from a telephone network = is very obviously a bad way of doing it. IMHO wireless IP access=20 should be viewed, for regulatory purposes, as more like a public = utility=20 than the proverbial "walled garden" for which the owner charges at the=20 tollbooth. You could make a lot of money by letting someone charge for = the=20 air we breathe too, but in neither case is it good public policy.=20 There are many aspects to this, and many ways of pulling it off, as I=20 have tried to convince the FCC for some time now.=20 * What replaces the "walled garden" wireless air interfaces? Good = question.=20 I have some opinions as to what it MIGHT be, but other opinions may=20 [read: "undoubtedly will"] differ. This will be, I hope, the subject of = this new "wireless internet" discussion group.=20 =20 ------_=_NextPart_001_01C0DEDD.1A351900 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Arthur, you really should do that = informational draft.=20 I think Inge is trying to help with some real=20 requirements.
-----Original Message-----
From: Arthur Ross=20 [mailto:a.ross@ieee.org]
Sent: Wednesday, May 16, 2001 = 11:47=20 AM
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: = [mobile-ip] NAI/need for identifiers

At 1:35 -0700 05/16/2001, inge.gronbak@telenor.com wrote:

>

>This is a cry of confusion from an employee of a "large" = Norwegian=20 operator.

>

>Could you please explain to me how the NAI, other identifiers = and the=20 IP

>address are used to meet the following requirements (which I = jotted=20 down

>very quickly):

>

>The required separate identifiers for service provisioning are = as=20 follows:

>=B7      Subscription

>=B7      User

>=B7      Terminal

>=B7      Session

>All four are required, and it is yet unclear to me how this is = solved.=20 These

>identifiers are needed to accommodate e.g. security and the = following=20 three

>levels of mobility:


[snip]


Once again, this thread is nibbling around the edges of a much = larger, very=20 important discussion.


My apologies to those of you who have already seen this from my = prior=20 posting to the SEAMOBY list, but it is germane to this thread too. =


<RANT>


We talk at great length about hosts, mobile nodes, etc., but the = notion of=20 "host" or "node" is getting fuzzy. Originally [ARPANET] "hosts" were = big

computers that filled rooms, had squads of people caring for & = feeding=20 them, and the protocols were designed with that implicit mindset. But = nowadays, when the

embodiments of the "hosts" may cost just pennies, may be = flyspeck-sized,=20 and may

be found in all sorts of non-traditional, often low-tech kinds of=20 places/things,

the concepts need revision.


My strong feeling is that the questions to be addressed should be = things=20 like:


* What are the entities that are the endpoints of the = communication?=20 When

the address space is large enough [IPv6] to give every cell of = every human=20

being and every grain of sand on earth its own IP address, perhaps = the

model and uses of it need to be re-thought.


* What is MEANT by "mobility"? Or alternatively what is = it=20 that is moving?

I can envision many possible answers/opinions.


* How are those endpoints identified for various purposes? = A major=20 example:

paging - IP address, as in MIP, is [perhaps] meaningful for = routing

purposes, but meaningless in the application context. One could = envision=20

a concept whereby there are various "views" of the endpoint space =

applicable for different sorts of applications (e.g. routing, = logical,

name-based, geographic, organizational hierarchy, demographic = group,

etc.). In this light, paging/addressing might be = viewed/implemented

as a kind of distributed database query.


* What is the nature of the "identity" associated with, = say,=20 individual

humans, that provides the basis/data for authentication? I'm = thinking

of something like a great-grandson of the SIM card concept, for = example=20

[... or maybe you will begin every session with a request to "spit = in the=20

little spitoon" on your laptop for the DNA analysis that = authenticates

the session. ;-) ].


* Is a broader concept of the "addressable individual" = needed? [I=20 have in

mind functional pseudo-persons, associated with business & = organization=20

roles, databases of various kinds, etc.]


* Is a "discovery" functionality needed? I.e. a generic = method for=20 exposing

the internal structure of subnets and/or databases? I.e. a way of = creating=20

the local streetmap of an unfamiliar neighborhood? This might be = especially=20

important if the "mobile" entities have internal, time-varying = structure=20

[think, for a simple example, of folks in vehicles on the highway, = each=20

potentially with his PDA, phone, medical monitoring device, plus = the

"smart car" itself, etc., all of which are communicating through a =

wireless gateway of some kind; just such things are currently = under

development].


* What are the business and regulatory models? Giant=20 electro-political

hot potato, but very important, IMHO. The regulatory folks need to = clean=20

up their act if the mythical "wireless Internet" is to be anything = other=20

than hype and snake oil.


I have in mind here a complete re-think of the spectrum license = auction=20

notion. I personally believe that auctioning the ether was, and = still is,=20

a bad idea, not in the long term public interest. The pro-auction =

argument is that real estate-like ownership is a prerequisite if =

investors are going to pony up the huge capital expenditures = needed to

build the "next generation" networks. The fallacy here, IMHO, is = the

PSTN-centric mindset. If what you are talking about is universal, =

readily-available wirless IP service, starting from a telephone = network=20

is very obviously a bad way of doing it. IMHO wireless IP access =

should be viewed, for regulatory purposes, as more like a public = utility=20

than the proverbial "walled garden" for which the owner charges at = the

tollbooth. You could make a lot of money by letting someone charge = for the=20

air we breathe too, but in neither case is it good public policy. =


There are many aspects to this, and many ways of pulling it off, = as I

have tried to convince the FCC for some time now.


* What replaces the "walled garden" wireless air = interfaces? Good=20 question.

I have some opinions as to what it MIGHT be, but other opinions = may

[read: "undoubtedly will"] differ. This will be, I hope, the = subject of=20

this new "wireless internet" discussion group.


</RANT>

------_=_NextPart_001_01C0DEDD.1A351900-- From owner-mobile-ip@sunroof.eng.sun.com Thu May 17 15:30:07 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25475 for ; Thu, 17 May 2001 15:30:06 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA16740; Thu, 17 May 2001 12:30:04 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA23599; Thu, 17 May 2001 12:29:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4HJS1f04023 for mobile-ip-dist; Thu, 17 May 2001 12:28:01 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4HJRr404016 for ; Thu, 17 May 2001 12:27:53 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with SMTP id f4HJRmu133774 for ; Thu, 17 May 2001 12:27:49 -0700 (PDT) Message-Id: <200105171927.f4HJRmu133774@jurassic.eng.sun.com> Date: Thu, 17 May 2001 12:27:47 -0700 (PDT) From: Alper Yegin Subject: RE: [mobile-ip] host routes in the fast mipv6 draft To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: G/TxZ8akB2C+C2mrvUoFFg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Alper, > > Understand that I wasn't on the design team, so > I'm looking at this sort of like an outside reader > would look at it. I didn't see where/how the > tunnel would be terminated on ARnew in the draft. > Did I miss something? This would be new > functionality in ipv6 since it sounds like it's > mimicing v4 FA functionality. > > Mike Mike, (sorry for late response.) We have the following mentions of this tunnel. Section 2: ... If the new care-of-address is rejected by the new access router, the old access router sets up a temporary tunnel to forward packets destined for the mobile to the old care-of-address which will be temporarily hosted on the new access router. ... If no valid new care-of-address is determined, the new access router will record the old care-of-address, de-tunnel the packets received in the tunnel from the old access router and deliver them to the mobile node. Although it's implicitely mentioned here, we can do a better job and explicitely talk about tunnel end points. And yes, I understand you are an outside reader, and your comments are very welcome. It would be hard for us tho catch this kind of improvements. alper From owner-mobile-ip@sunroof.eng.sun.com Thu May 17 15:40:40 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25702 for ; Thu, 17 May 2001 15:40:39 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA22278; Thu, 17 May 2001 12:40:46 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA02489; Thu, 17 May 2001 12:37:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4HJYdJ04064 for mobile-ip-dist; Thu, 17 May 2001 12:34:39 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4HJYV404057 for ; Thu, 17 May 2001 12:34:31 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with SMTP id f4HJYTu134946 for ; Thu, 17 May 2001 12:34:29 -0700 (PDT) Message-Id: <200105171934.f4HJYTu134946@jurassic.eng.sun.com> Date: Thu, 17 May 2001 12:34:29 -0700 (PDT) From: Alper Yegin Subject: RE: [mobile-ip] host routes in the fast mipv6 draft To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: TnmDYGQknEZ2w/+jW+QlUQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Jim, > The draft is very unclear about how and when tunnels are set up. > The term "host route" is used to refer to a tunnel being set up. That shouldn't be the case. As George explained out earlier, host routes are created on the newAR, to point to MN's oldCoA. They are not used on oldAR, or for tunnels. If you can point us where draft says or implies so, we can fix it. alper > I've actually never heard the term host route used in this fashion. > Typically, a host route means "even though the dest address doesn't > match the subnet structure topologically, route the packet this way." > With a tunnel, the dest address will always be topologically correct. > > jak > alper From owner-mobile-ip@sunroof.eng.sun.com Thu May 17 16:12:30 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26264 for ; Thu, 17 May 2001 16:12:30 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA06103; Thu, 17 May 2001 13:12:34 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04605; Thu, 17 May 2001 09:04:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4HG2Zg03569 for mobile-ip-dist; Thu, 17 May 2001 09:02:35 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4HG2Q403562 for ; Thu, 17 May 2001 09:02:26 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA09494 for ; Thu, 17 May 2001 09:02:16 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA19947; Thu, 17 May 2001 09:02:14 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f4HG2Dd28938; Thu, 17 May 2001 09:02:13 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AFY45009; Thu, 17 May 2001 09:02:11 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA03893; Thu, 17 May 2001 09:02:11 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15107.62978.963925.414934@thomasm-u1.cisco.com> Date: Thu, 17 May 2001 09:02:10 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Cc: Basavaraj.Patil@nokia.com, James.Kempf@Sun.COM Subject: RE: FW: [mobile-ip] Times for Low-Latency IPv6 Handoff In-Reply-To: <200105161636.JAA06977@heliopolis.eng.sun.com> References: <200105161636.JAA06977@heliopolis.eng.sun.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit James Kempf writes: > Hi Raj, > > > >If the traffic is real-time data, the traffic channel consists of > >signaling and RT bearer simultaneously. So at the transport layer > >(DCH) consists of 3.4 Kbps for signaling as well as 12.4 for AMR (max > >data rate). So the MIP signaling should be carried over the 3.4 kbps > >channel and as a result will not interrupt the traffic. So if you > >look at section 6.2.1 (Harri's book) at paragraphs 1 & 2, you will > >realize that. > > > > Interesting, thanx. Looks like it is possible to multiplex signalling > and real time data on a single logical channel that maps to multiple > physical channels. However, it is still not clear from this whether the > signalling is restricted to NBAP/wCDMA signalling or whether IP > signalling would work. In principle, I think it *could* be done if > it isn't currently. Of course, there would need to be some way to distinguish > which IP packets were signalling and which not (probably by port number?). Er, uh, why couldn't this be done with normal IP and L2'ism? If the L2 provided a transport vehicle for IP datagrams, all of the normal ways of building an interface would apply, I'd think. In fact, I can't imagine why you'd want to distinguish "signaling" packets. You'd want to use normal QoS mechanisms (diff/intserv), I'd think, and let the application decide what it wants to prioritize, and the gateway decides how to police. Mike From owner-mobile-ip@sunroof.eng.sun.com Thu May 17 17:12:19 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27229 for ; Thu, 17 May 2001 17:12:19 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA03157; Thu, 17 May 2001 14:12:18 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA16577; Thu, 17 May 2001 14:12:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4HLAVI04210 for mobile-ip-dist; Thu, 17 May 2001 14:10:31 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4HLAM404203 for ; Thu, 17 May 2001 14:10:23 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA03806 for ; Thu, 17 May 2001 14:10:21 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA23808 for ; Thu, 17 May 2001 15:10:19 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f4HLAO904069 for ; Thu, 17 May 2001 14:10:24 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AFY54591; Thu, 17 May 2001 14:10:19 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA03949; Thu, 17 May 2001 14:10:19 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15108.15931.226445.452275@thomasm-u1.cisco.com> Date: Thu, 17 May 2001 14:10:19 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] host routes in the fast mipv6 draft In-Reply-To: <200105171934.f4HJYTu134946@jurassic.eng.sun.com> References: <200105171934.f4HJYTu134946@jurassic.eng.sun.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Alper Yegin writes: > Jim, > > > The draft is very unclear about how and when tunnels are set up. > > The term "host route" is used to refer to a tunnel being set up. > > That shouldn't be the case. As George explained out earlier, host routes are > created on the newAR, to point to MN's oldCoA. They are not used on oldAR, or > for tunnels. If you can point us where draft says or implies so, we can fix it. Alper, I don't see how this can possibly work unless the route is also installed on ARold. Otherwise it forward it out the wireless interface as usual. As I've said before, I'm sort of worried about how this interacts with other routing protocols, and especially how it converges when the routes are deleted. What would happen, for example, if the host route were propogated by OSPF while the tunnel was up? Mike From owner-mobile-ip@sunroof.eng.sun.com Thu May 17 21:08:59 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA29702 for ; Thu, 17 May 2001 21:08:59 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA28366; Thu, 17 May 2001 18:06:52 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA13269; Thu, 17 May 2001 18:06:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4I15Cq04653 for mobile-ip-dist; Thu, 17 May 2001 18:05:12 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31] (may be forged)) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4I154M04646 for ; Thu, 17 May 2001 18:05:04 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with SMTP id f4I154W213939 for ; Thu, 17 May 2001 18:05:04 -0700 (PDT) Message-Id: <200105180105.f4I154W213939@jurassic.eng.sun.com> Date: Thu, 17 May 2001 18:05:04 -0700 (PDT) From: Alper Yegin Subject: RE: [mobile-ip] host routes in the fast mipv6 draft To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: UrWTcto6krFxhHAbslDY2w== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Alper Yegin writes: > > Jim, > > > > > The draft is very unclear about how and when tunnels are set up. > > > The term "host route" is used to refer to a tunnel being set up. > > > > That shouldn't be the case. As George explained out earlier, host routes are > > created on the newAR, to point to MN's oldCoA. They are not used on oldAR, or > > for tunnels. If you can point us where draft says or implies so, we can fix it. Mike, > > Alper, > > I don't see how this can possibly work unless the > route is also installed on ARold. Otherwise it > forward it out the wireless interface as usual. I should be clear on this. [I thought Jim was referring to host routes on newAR]. Yes, a host route is created on the oldAR, that points to the tunnel created. So, packets whose destination address is oldCoA will be forwarded to this tunnel per this host route. This is what happens when we "forward from a previous care-of address". Also same story on Home Agent for home addresses. And if the tunnel end point is not newCoA but newAR, then another host route is created on the newAR to deliver packets to MN at it's topologically incorrect oldCoA address (attached to a link on newAR). > > As I've said before, I'm sort of worried about how > this interacts with other routing protocols, and > especially how it converges when the routes are > deleted. What would happen, for example, if the > host route were propogated by OSPF while the > tunnel was up? This must be preventable. Otherwise same OSPF might also propogate the host routes (for home addresses) on the Home Agent. alper From owner-mobile-ip@sunroof.eng.sun.com Thu May 17 21:23:51 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA29827 for ; Thu, 17 May 2001 21:23:51 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA11562; Thu, 17 May 2001 19:21:49 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA23804; Thu, 17 May 2001 18:21:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4I1K9G04695 for mobile-ip-dist; Thu, 17 May 2001 18:20:09 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31] (may be forged)) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4I1JvM04688 for ; Thu, 17 May 2001 18:19:57 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with SMTP id f4I1JsW216588; Thu, 17 May 2001 18:19:54 -0700 (PDT) Message-Id: <200105180119.f4I1JsW216588@jurassic.eng.sun.com> Date: Thu, 17 May 2001 18:19:54 -0700 (PDT) From: Alper Yegin Subject: RE: FW: [mobile-ip] Times for Low-Latency IPv6 Handoff To: mobile-ip@sunroof.eng.sun.com, Basavaraj.Patil@nokia.com Cc: James.Kempf@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 05vU68zj2Zk2J1XeD5ApXA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > >The current draft does allow this. What I mean is that the MN can > >continue to use it's old COA at the new AP, if it did not receive an > >ACK from the handoff signaling. > > > > > Section 5.2 on pg. 33 of draft-ietf-mobileip-fast-mipv6-01.txt talks about a > unidirectional tunnel from old AR to new AR but nothing about a reverse tunnel. > If there is no reverse tunnel in place, new AR can drop MN's packets > with the old CoA because old CoA is not topologically correct > in new AR's subnet, if egress filtering is on (as I would expect > it to be, to prevent bogus MN from establishing service). Consequently, > old AR forwards packets to new AR, who buffers them, but the real time > stream still stalls because MN can't get any packets out. The solution is clearly to make the tunnel bi-directional. I remember this as our decision, but other authors would correct me if I'm wrong. Yes, we should clarify this on the draft. > > Also, it is furthermore unclear whether new AR is allowed to send packets > to MN prior to MN sending a Neighbor Advertisement or Fast Neighbor > Advertisment to new AR. Exactly how and when NA or F-NA is used seemed > also somewhat murky to me. It is not shown on the timing diagrams > for the protocol, for example, though it is discussed in Section 5.3. Figure 1. in section 3.1.1 shows F-NA in the diagram, but what it's missing is to show this is sent after "Connect"ing to the new link. So, as soon as MN attaches to new link, it can send this F-NA to newAR. > > jak > alper From owner-mobile-ip@sunroof.eng.sun.com Thu May 17 23:08:52 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA03836 for ; Thu, 17 May 2001 23:08:52 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA27519; Thu, 17 May 2001 20:08:19 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA29795; Thu, 17 May 2001 20:08:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4I36HL04801 for mobile-ip-dist; Thu, 17 May 2001 20:06:17 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4I366M04794 for ; Thu, 17 May 2001 20:06:06 -0700 (PDT) Received: from awe171-106 (awe195-62.AWE.Sun.COM [192.29.195.62]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id UAA26662; Thu, 17 May 2001 20:06:05 -0700 (PDT) Message-Id: <200105180306.UAA26662@heliopolis.eng.sun.com> Date: Thu, 17 May 2001 18:58:12 -0700 (PDT) From: kempf Subject: RE: FW: [mobile-ip] Times for Low-Latency IPv6 Handoff To: mobile-ip@sunroof.eng.sun.com, mat@cisco.com Cc: Basavaraj.Patil@nokia.com, James.Kempf@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 40Rm0Wk0jDOEUjPVlx4emg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 i86pc i386 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Mike, >Er, uh, why couldn't this be done with normal IP >and L2'ism? If the L2 provided a transport >vehicle for IP datagrams, all of the normal ways >of building an interface would apply, I'd >think. In fact, I can't imagine why you'd want to >distinguish "signaling" packets. You'd want to use >normal QoS mechanisms (diff/intserv), I'd think, >and let the application decide what it wants to >prioritize, and the gateway decides how to police. > The problem is that unlike wired systems, there are actually several (I think 15 in wCDMA) channels that can be used. Each channel corresponds to a different chunk of spectrum or a different configuration of Walsh codes. The mobile and BTS can send and receive on multiple channels at once, so you could conceive of doing all your handoff signalling on one channel while the voice traffic was still flowing over the data channel. It's kind of like having 15 interface cards on the back of your workstation, with 15 wires going out of them. On top of that, as Raj mentioned in his email, the logical DCH channel on the downlink actually consists of a physical realtime data channel that is currently used exclusively for voice frames and a signalling channel that is used for 3.5Kbps signalling. So applications just write to the logical channel and presumably the MAC layer on the phone sorts out which physical channel to use. I agree that it could get complicated trying to figure out how to send IP signalling over a special signalling channels rather than just sending it as standard IP datagram traffic, and while I think it could, in principle, be done, it is probably impractical. I'm curious what 3GPP will do when they start using SIP phones, since they will need to deal with this issue. IMHO, this may be an example of a case where radio protocols better engineered for IP might make sense, as you've mentioned in the past, though most mobile operators don't seem too interested in that right now. jak From owner-mobile-ip@sunroof.eng.sun.com Thu May 17 23:21:29 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA03950 for ; Thu, 17 May 2001 23:21:28 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA29872; Thu, 17 May 2001 20:21:05 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA18867; Thu, 17 May 2001 20:20:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4I3HUR04829 for mobile-ip-dist; Thu, 17 May 2001 20:17:30 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4I3HDM04822 for ; Thu, 17 May 2001 20:17:14 -0700 (PDT) Received: from awe171-106 (awe195-62.AWE.Sun.COM [192.29.195.62]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id UAA26755 for ; Thu, 17 May 2001 20:17:12 -0700 (PDT) Message-Id: <200105180317.UAA26755@heliopolis.eng.sun.com> Date: Thu, 17 May 2001 19:09:19 -0700 (PDT) From: kempf Subject: RE: [mobile-ip] host routes in the fast mipv6 draft To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Osa6q+C4yujrBhyXtomBAg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 i86pc i386 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Alper, As I mentioned in my reply to Raj about the timing, I think newAR needs to arrange a reverse tunnel back to oldAR, otherwise, the real time stream may stall because the mobile's packets may not get out. If they have the oldCoA as the dest addr, they will not be topologically correct at oldAR and so oldAR may drop them if egress filtering is on. Also, if there is a forward and reverse tunnel from oldAR to newAR, I'm curious why MN needs to do a BU/BACK back to oldAR? The mobile will be getting its packets, why should oldAR have to know, except to break down the tunnel, and it could be informed by newAR just as soon as the Neighbor Advert is received. This would save one round trip over the air for the mobile. jak >Date: Thu, 17 May 2001 12:34:29 -0700 (PDT) >From: Alper Yegin >Subject: RE: [mobile-ip] host routes in the fast mipv6 draft >To: mobile-ip@sunroof.eng.sun.com >Content-MD5: TnmDYGQknEZ2w/+jW+QlUQ== >List-Owner: > >Jim, > >> The draft is very unclear about how and when tunnels are set up. >> The term "host route" is used to refer to a tunnel being set up. > >That shouldn't be the case. As George explained out earlier, host routes are >created on the newAR, to point to MN's oldCoA. They are not used on oldAR, or >for tunnels. If you can point us where draft says or implies so, we can fix it. > >alper > > >> I've actually never heard the term host route used in this fashion. >> Typically, a host route means "even though the dest address doesn't >> match the subnet structure topologically, route the packet this way." >> With a tunnel, the dest address will always be topologically correct. > > > >> >> jak >> > >alper > From owner-mobile-ip@sunroof.eng.sun.com Thu May 17 23:24:11 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA04023 for ; Thu, 17 May 2001 23:24:11 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA05155; Thu, 17 May 2001 21:23:40 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA06445; Thu, 17 May 2001 20:23:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4I3Kxc04851 for mobile-ip-dist; Thu, 17 May 2001 20:20:59 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4I3KTM04840 for ; Thu, 17 May 2001 20:20:30 -0700 (PDT) Received: from awe171-106 (awe195-62.AWE.Sun.COM [192.29.195.62]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id UAA26782 for ; Thu, 17 May 2001 20:20:28 -0700 (PDT) Message-Id: <200105180320.UAA26782@heliopolis.eng.sun.com> Date: Thu, 17 May 2001 19:12:35 -0700 (PDT) From: kempf Subject: RE: [mobile-ip] host routes in the fast mipv6 draft To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: XaxWOVWgYfcE8DIxUA+CEQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 i86pc i386 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: >I don't see how this can possibly work unless the >route is also installed on ARold. Otherwise it >forward it out the wireless interface as usual. > >As I've said before, I'm sort of worried about how >this interacts with other routing protocols, and >especially how it converges when the routes are >deleted. What would happen, for example, if the >host route were propogated by OSPF while the >tunnel was up? > I have to agree with Mike here. I don't see the need for a host route if there's a tunnel set up. jak From owner-mobile-ip@sunroof.eng.sun.com Fri May 18 06:57:53 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA22068 for ; Fri, 18 May 2001 06:57:52 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA00056; Fri, 18 May 2001 04:57:20 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA29073; Fri, 18 May 2001 03:57:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4IAtoG06869 for mobile-ip-dist; Fri, 18 May 2001 03:55:50 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4IAtXM06862 for ; Fri, 18 May 2001 03:55:33 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA15285 for ; Fri, 18 May 2001 03:55:31 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA25476 for ; Fri, 18 May 2001 04:55:40 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21791; Fri, 18 May 2001 06:54:53 -0400 (EDT) Message-Id: <200105181054.GAA21791@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-aaa-key-05.txt Date: Fri, 18 May 2001 06:54:52 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --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 : AAA Registration Keys for Mobile IP Author(s) : C. Perkins, P. Calhoun Filename : draft-ietf-mobileip-aaa-key-05.txt Pages : 14 Date : 17-May-01 AAA servers, such as RADIUS and DIAMETER, are in use within the Internet today to provide authentication and authorization services for dial-up computers. Mobile IP requires strong authentication between the mobile node and its home agent. When the mobile node shares a security association with its home AAA server, however, it is possible to use that security association to create derivative security associations between the mobile node and its home agent, and again between the mobile node and the foreign agent currently offering connectivity to the mobile node. This document specifies extensions to the Mobile IP Registration Reply packet that can be used to create such security information at the mobile node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-aaa-key-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-aaa-key-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-aaa-key-05.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: <20010517101033.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-aaa-key-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-aaa-key-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010517101033.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Fri May 18 06:59:48 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA22131 for ; Fri, 18 May 2001 06:59:48 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA29982; Fri, 18 May 2001 04:57:09 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA16454; Fri, 18 May 2001 03:57:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4IAtNS06860 for mobile-ip-dist; Fri, 18 May 2001 03:55:23 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4IAtCM06853 for ; Fri, 18 May 2001 03:55:13 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA28979 for ; Fri, 18 May 2001 03:55:11 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA00488 for ; Fri, 18 May 2001 03:55:09 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21810; Fri, 18 May 2001 06:54:58 -0400 (EDT) Message-Id: <200105181054.GAA21810@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-3gwireless-ext-06.txt Date: Fri, 18 May 2001 06:54:57 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --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 Based Micro Mobility Management Protocol in The Third Generation Wireless Network Author(s) : Y. Xu et al. Filename : draft-ietf-mobileip-3gwireless-ext-06.txt Pages : 16 Date : 17-May-01 This document defines extensions to the Mobile IP protocol [1] to allow mobility management for the interface between a radio network and a packet data network in the third generation cdma2000 network. Mobile IP requires link layer connectivity between the Mobile Node and the Foreign Agent. This draft proposes a protocol for achieving this when the physical layer terminating at a point distant from the FA. In particular, this protocol applies to cdma2000 networks where the physical layer terminates at a Radio Network Node (RNN) and the FA resides inside a separate Packet Data Serving Node (PDSN). The PDSN is responsible for establishing, maintaining, and terminating the link layer to the Mobile Node. A RNN is responsible for relaying the link layer protocol between a Mobile Node and its corresponding PDSN. The interface between the RNN and the PDSN is called the RP interface. This interface requires mobility management for handling handoff from one RNN to another without interrupting end to end communication. It also requires the support of the link layer protocol encapsulation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-3gwireless-ext-06.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-3gwireless-ext-06.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-3gwireless-ext-06.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: <20010517101048.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-3gwireless-ext-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-3gwireless-ext-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010517101048.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Fri May 18 12:57:06 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01344 for ; Fri, 18 May 2001 12:57:06 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15146; Fri, 18 May 2001 10:55:09 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA09549; Fri, 18 May 2001 09:54:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4IGqcp07358 for mobile-ip-dist; Fri, 18 May 2001 09:52:38 -0700 (PDT) Received: from centralmail1.Central.Sun.COM (centralmail1.Central.Sun.COM [129.147.62.10]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4IGqXM07351 for ; Fri, 18 May 2001 09:52:34 -0700 (PDT) Received: from sr-uita01-01.Central.Sun.COM (sr-uita01-01.Central.Sun.COM [129.153.224.5]) by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07068 for ; Fri, 18 May 2001 10:52:33 -0600 (MDT) Received: (from glass@localhost) by sr-uita01-01.Central.Sun.COM (8.10.2+Sun/8.10.2) id f4IGqWW19974 for mobile-ip@sunroof.eng.sun.com; Fri, 18 May 2001 11:52:32 -0500 (CDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4IDT2M07150 for ; Fri, 18 May 2001 06:29:03 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA28914 for ; Fri, 18 May 2001 06:29:02 -0700 (PDT) Received: from cpq-bp-exchange.iirltd.co.uk (groupwise.iirltd.co.uk [193.133.64.177]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA08132 for ; Fri, 18 May 2001 06:29:02 -0700 (PDT) Received: by CPQ-BP-EXCHANGE.iir_london with Internet Mail Service (5.5.2653.19) id ; Fri, 18 May 2001 14:28:28 +0100 Message-ID: From: Claire Tranah To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] The Path to 4G Mobile Date: Fri, 18 May 2001 14:28:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Thanks to everyone who submitted papers for The Path to 4G Mobile. The complete programme for the meeting can now be found at www.4gnetworks.net Kind Regards Claire Tranah - IIR Telecoms Conference Producer - IIR Telecoms From owner-mobile-ip@sunroof.eng.sun.com Fri May 18 19:19:07 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18947 for ; Fri, 18 May 2001 19:19:06 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA00593; Fri, 18 May 2001 16:14:52 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA24840; Fri, 18 May 2001 16:14:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4INDGU08001 for mobile-ip-dist; Fri, 18 May 2001 16:13:16 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4IND7M07994 for ; Fri, 18 May 2001 16:13:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA12541 for ; Fri, 18 May 2001 16:13:07 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA19060 for ; Fri, 18 May 2001 17:13:19 -0600 (MDT) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f4IND4O10401 for ; Sat, 19 May 2001 01:13:04 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Sat May 19 01:13:03 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Sat, 19 May 2001 01:08:00 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBE6A@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" , Basavaraj.Patil@nokia.com Subject: RE: FW: [mobile-ip] Times for Low-Latency IPv6 Handoff Date: Sat, 19 May 2001 01:13:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi James, > >The current draft does allow this. What I mean is that the MN can > >continue to use it's old COA at the new AP, if it did not receive an > >ACK from the handoff signaling. > > > > > Section 5.2 on pg. 33 of draft-ietf-mobileip-fast-mipv6-01.txt talks about a > unidirectional tunnel from old AR to new AR but nothing about a reverse tunnel. > If there is no reverse tunnel in place, new AR can drop MN's packets > with the old CoA because old CoA is not topologically correct > in new AR's subnet, if egress filtering is on (as I would expect > it to be, to prevent bogus MN from establishing service). . > => In the case you're referring to the tunnel is terminated in the new AR. A host route exists in the new AR. So it seems quite reasonable that egress filtering will not be done on a host that is already allowed to exist on the subnet (by virtue of the host route). Maybe some text is needed in the draft for this. Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri May 18 19:41:17 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19482 for ; Fri, 18 May 2001 19:41:17 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA11900; Fri, 18 May 2001 17:39:40 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA27229; Fri, 18 May 2001 16:39:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4INc8N08055 for mobile-ip-dist; Fri, 18 May 2001 16:38:08 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4INbtM08048 for ; Fri, 18 May 2001 16:37:55 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA14034 for ; Fri, 18 May 2001 16:37:54 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA24528 for ; Fri, 18 May 2001 16:37:52 -0700 (PDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f4INbpN19055 for ; Sat, 19 May 2001 01:37:51 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Sat May 19 01:37:50 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Sat, 19 May 2001 01:37:50 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBE6E@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" , Basavaraj.Patil@nokia.com Cc: James.Kempf@Sun.COM Subject: RE: FW: [mobile-ip] Times for Low-Latency IPv6 Handoff Date: Sat, 19 May 2001 01:37:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Alper, > > If there is no reverse tunnel in place, new AR can drop MN's packets > > with the old CoA because old CoA is not topologically correct > > in new AR's subnet, if egress filtering is on (as I would expect > > it to be, to prevent bogus MN from establishing service). Consequently, > > old AR forwards packets to new AR, who buffers them, but the real time > > stream still stalls because MN can't get any packets out. > > The solution is clearly to make the tunnel bi-directional. I remember this as > our decision, but other authors would correct me if I'm wrong. Yes, we should > clarify this on the draft. > => I'm not sure if I'm missing something here but how does a bi-directional tunnel help ? The src address for outgoing packets will still be the old CoA. Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri May 18 20:40:25 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20539 for ; Fri, 18 May 2001 20:40:25 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA23567; Fri, 18 May 2001 17:38:53 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA10680; Fri, 18 May 2001 17:38:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4J0bQj08104 for mobile-ip-dist; Fri, 18 May 2001 17:37:26 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.87.31] (may be forged)) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4J0bHM08097 for ; Fri, 18 May 2001 17:37:17 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with SMTP id f4J0bHW495843 for ; Fri, 18 May 2001 17:37:17 -0700 (PDT) Message-Id: <200105190037.f4J0bHW495843@jurassic.eng.sun.com> Date: Fri, 18 May 2001 17:37:17 -0700 (PDT) From: Alper Yegin Subject: RE: FW: [mobile-ip] Times for Low-Latency IPv6 Handoff To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 363ndjer4m4bF4SuQnDIxQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Alper, > > > > If there is no reverse tunnel in place, new AR can drop MN's packets > > > with the old CoA because old CoA is not topologically correct > > > in new AR's subnet, if egress filtering is on (as I would expect > > > it to be, to prevent bogus MN from establishing service). Consequently, > > > old AR forwards packets to new AR, who buffers them, but the real time > > > stream still stalls because MN can't get any packets out. > > > > The solution is clearly to make the tunnel bi-directional. I remember this as > > our decision, but other authors would correct me if I'm wrong. Yes, we should > > clarify this on the draft. > > > => I'm not sure if I'm missing something here but how does > a bi-directional tunnel help ? The src address for outgoing > packets will still be the old CoA. Hesham, As you pointed in your previous e-mail, as newAR keeps state about MN and knows it's using oldCoA, it can selectively let those packets go by. (yes, we need to clarify this on the draft). Also, oldAR might be more than one hop away from newAR, in which case bi-directional tunnel will encapsualte packets with topologically incorrect source address and they won't be ingress-filtered by intermediate routers. (this is for packets sent by MN). alper From owner-mobile-ip@sunroof.eng.sun.com Fri May 18 21:16:05 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20920 for ; Fri, 18 May 2001 21:16:04 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA01268; Fri, 18 May 2001 18:13:31 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA20967; Fri, 18 May 2001 18:11:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4J19rW08162 for mobile-ip-dist; Fri, 18 May 2001 18:09:53 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4J19iM08155 for ; Fri, 18 May 2001 18:09:45 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with SMTP id f4J19iW499770 for ; Fri, 18 May 2001 18:09:44 -0700 (PDT) Message-Id: <200105190109.f4J19iW499770@jurassic.eng.sun.com> Date: Fri, 18 May 2001 18:09:44 -0700 (PDT) From: Alper Yegin Subject: RE: [mobile-ip] host routes in the fast mipv6 draft To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: MRDN4lMromQUBKWafT7jRg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Jim, > Alper, > > As I mentioned in my reply to Raj about the timing, I think newAR needs > to arrange a reverse tunnel back to oldAR, otherwise, the real time > stream may stall because the mobile's packets may not get out. If > they have the oldCoA as the dest addr, they will not be topologically > correct at oldAR and so oldAR may drop them if egress filtering is on. > > Also, if there is a forward and reverse tunnel from oldAR to newAR, I'm > curious why MN needs to do a BU/BACK back to oldAR? Which BU/Back is this? This is not the F-BU/F-Back that was exchanged before this tunnel gets created. ?? > The mobile will > be getting its packets, why should oldAR have to know, except to break > down the tunnel, and it could be informed by newAR just as soon as > the Neighbor Advert is received. This would save one round trip > over the air for the mobile. > > jak alper > > > > >Date: Thu, 17 May 2001 12:34:29 -0700 (PDT) > >From: Alper Yegin > >Subject: RE: [mobile-ip] host routes in the fast mipv6 draft > >To: mobile-ip@sunroof.eng.sun.com > >Content-MD5: TnmDYGQknEZ2w/+jW+QlUQ== > >List-Owner: > > > >Jim, > > > >> The draft is very unclear about how and when tunnels are set up. > >> The term "host route" is used to refer to a tunnel being set up. > > > >That shouldn't be the case. As George explained out earlier, host routes are > >created on the newAR, to point to MN's oldCoA. They are not used on oldAR, or > >for tunnels. If you can point us where draft says or implies so, we can fix it. > > > >alper > > > > > >> I've actually never heard the term host route used in this fashion. > >> Typically, a host route means "even though the dest address doesn't > >> match the subnet structure topologically, route the packet this way." > >> With a tunnel, the dest address will always be topologically correct. > > > > > > > >> > >> jak > >> > > > >alper > > > alper From owner-mobile-ip@sunroof.eng.sun.com Fri May 18 21:45:31 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA22182 for ; Fri, 18 May 2001 21:45:30 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA06472; Fri, 18 May 2001 18:42:58 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA07417; Fri, 18 May 2001 18:40:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4J1be808220 for mobile-ip-dist; Fri, 18 May 2001 18:37:40 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4J1bVM08213 for ; Fri, 18 May 2001 18:37:32 -0700 (PDT) Received: from awe171-106 (awe195-158.AWE.Sun.COM [192.29.195.158]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id SAA24586 for ; Fri, 18 May 2001 18:37:31 -0700 (PDT) Message-Id: <200105190137.SAA24586@heliopolis.eng.sun.com> Date: Fri, 18 May 2001 17:29:37 -0700 (PDT) From: kempf Subject: RE: [mobile-ip] host routes in the fast mipv6 draft To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: F3EAXhH6JfRuix2gW/cpPA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 i86pc i386 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Alper, >>> >> Also, if there is a forward and reverse tunnel from oldAR to newAR, I'm >> curious why MN needs to do a BU/BACK back to oldAR? > >Which BU/Back is this? This is not the F-BU/F-Back that was exchanged before >this tunnel gets created. ?? > The F-BU/F-BACK can occur either before or after the L2 handover. If the tunnel isn't created until the F-BU/F-BACK is exchanged, there is no point in creating it. I thought the point of the tunnel was so that MN can use old CoA until the F-BU/F-BACK completes. But since MN already knows is new CoA (via the RtAdv), and since it can send and receive packets using its old CoA via a bidirectional tunnel through old AR, what is the point of the F-BU/F-BACK? jak From owner-mobile-ip@sunroof.eng.sun.com Sun May 20 18:33:15 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13557 for ; Sun, 20 May 2001 18:33:15 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA19428; Sun, 20 May 2001 16:31:37 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA02169; Sun, 20 May 2001 15:31:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4KMTsj09972 for mobile-ip-dist; Sun, 20 May 2001 15:29:54 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4KMTjM09965 for ; Sun, 20 May 2001 15:29:45 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA02401 for ; Sun, 20 May 2001 15:29:45 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA25041 for ; Sun, 20 May 2001 16:29:57 -0600 (MDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f4KMTcN28405 for ; Mon, 21 May 2001 00:29:39 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon May 21 00:29:38 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Mon, 21 May 2001 00:29:38 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBE76@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: FW: [mobile-ip] Times for Low-Latency IPv6 Handoff Date: Mon, 21 May 2001 00:29:37 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Alper, > Also, oldAR might be more than one hop away from newAR, in which case > bi-directional tunnel will encapsualte packets with topologically incorrect > source address and they won't be ingress-filtered by intermediate routers. (this > is for packets sent by MN). > => Ok I misinterprested your first mail and thought you meant a tunnel starting from the MN. That sounds ok. Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon May 21 13:49:58 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15045 for ; Mon, 21 May 2001 13:49:56 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12017; Mon, 21 May 2001 11:48:15 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07490; Mon, 21 May 2001 10:48:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4LHk6X11064 for mobile-ip-dist; Mon, 21 May 2001 10:46:06 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4LHjvM11057 for ; Mon, 21 May 2001 10:45:58 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA24452 for ; Mon, 21 May 2001 10:45:58 -0700 (PDT) Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA21476 for ; Mon, 21 May 2001 10:45:57 -0700 (PDT) Received: by zcamail05.zca.compaq.com (Postfix, from userid 12345) id 630A9454; Mon, 21 May 2001 10:48:51 -0700 (PDT) Received: from exctay-gh03.tay.cpqcorp.net (exctay-gh03.tay.cpqcorp.net [16.103.129.53]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id D130D80B for ; Mon, 21 May 2001 10:48:50 -0700 (PDT) Received: by exctay-gh03.tay.cpqcorp.net with Internet Mail Service (5.5.2652.78) id ; Mon, 21 May 2001 13:45:47 -0400 Message-ID: <88BD5A70CA8BFA4CA15D0ED053E49D695094C7@tayexc14.americas.cpqcorp.net> From: "Powell, Ken" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] draft-ietf-mobileip-ipv6-13: Trade-off in Mobile Prefix advertise ments Date: Mon, 21 May 2001 13:45:42 -0400 X-Mailer: Internet Mail Service (5.5.2652.78) Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Vlad Yasevich and I were looking at the implementation impacts of draft-ietf-mobileip-ipv6-13 section 9.8.2. This section requires a home agent implementation build a list of changed prefixes and schedule an advertisement with just the changes when home network prefix information changes. In addition, section 9.8.3 requires that the changed prefixes be retransmitted until acked by a mobile node. This processing to support lists of changed prefixes will have to be performed independently for each mobile node, with perhaps thousands of mobile nodes on some home agents. We understand that the reason for sending only the changed prefix information instead of all prefix information is to reduce the connection costs for the mobile nodes on expensive wireless networks. Does the expected network cost savings justify the algorithm complexity that will be necessary to meet this requirement? We assume most home networks will have only 1 prefix, 2 during renumbering events. It will probably be very rare for any home network to have more than 4 prefixes even with multihoming. The prefix information on production networks are likely to change very infrequently. I expect no more than a few times in any given year. Do these assumptions sound correct? If so, we don't see how sending the unchanged prefixes will add any noticeable cost to the mobile node's connection. Ken From owner-mobile-ip@sunroof.eng.sun.com Mon May 21 13:56:51 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15209 for ; Mon, 21 May 2001 13:56:50 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19468; Mon, 21 May 2001 11:55:49 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA22036; Mon, 21 May 2001 10:55:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4LHrBL11095 for mobile-ip-dist; Mon, 21 May 2001 10:53:11 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4LHr2M11088 for ; Mon, 21 May 2001 10:53:02 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA27072 for ; Mon, 21 May 2001 10:53:02 -0700 (PDT) Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA25898 for ; Mon, 21 May 2001 10:52:59 -0700 (PDT) Received: by zcamail05.zca.compaq.com (Postfix, from userid 12345) id 8FA02867; Mon, 21 May 2001 10:55:59 -0700 (PDT) Received: from exctay-gh03.tay.cpqcorp.net (exctay-gh03.tay.cpqcorp.net [16.103.129.53]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id 0C41CAD2 for ; Mon, 21 May 2001 10:55:59 -0700 (PDT) Received: by exctay-gh03.tay.cpqcorp.net with Internet Mail Service (5.5.2652.78) id ; Mon, 21 May 2001 13:52:55 -0400 Message-ID: <88BD5A70CA8BFA4CA15D0ED053E49D69067D70@tayexc14.americas.cpqcorp.net> From: "Powell, Ken" To: "'T.J. Kniveton'" , "'dbj@cs.rice.edu'" , "'charliep@iprg.nokia.com'" Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Mobile Prefix Advertisements (more comments) Date: Mon, 21 May 2001 13:52:47 -0400 X-Mailer: Internet Mail Service (5.5.2652.78) Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi T.J., Vlad Yasevich, Brian Haley, Greg Colburn and I finished our discussion of your proposal. This is the remainder of our comments. Many comments also apply to draft-ietf-mobileip-ipv6-13 without your changes as well. Ken Powell Compaq Computer Corporation 5.8 Mobile Prefix Solicitation Message Format My comments to section 9.8.2 below request that only the prefixes that match a particular home registration be sent to the mobile node in Mobile Prefix Advertisements. If the binding has a zero prefix length, only the specific prefix for the mobile node's home address would be sent. For a bindings with a non-zero prefix length, all prefixes in the aggregate list would be sent. This left a problem, what prefixes do we send in response to a Router Solicitation? I think the home agent should use the same prefix selection logic, but the mobile node needs a way to override this behavior to support initialization. One option is to add a flag to the Mobile Prefix Solicitation Message: + Send All Prefixes flag + + If clear, the home agent replies by sending only the prefixes + that match the mobile nodes home registration as defined in + section 9.8.2. If set, the home agent will send all prefixes + for the home network as defined in section 9.8.1. No prefixes + will be sent if this flag is clear and the mobile node does + not yet have a home registration. 9.8.2 Sending Changed Prefix Information to the Mobile Node Due to the number of comments on this section, I'm including the entire text with ">" marks, and slicing in the comments where they apply. > A home agent serving a mobile node will schedule the delivery > of new prefix information to that mobile node when any of the > following conditions occur: Can the following list of MUST and MAY requirements be merged into the algorithm for sending prefix information below? > MUST: > - The valid or preferred lifetime or the state of the flags > changes for the prefix of the mobile node's registered home > address changes > - The mobile node requests the information with a Router > Solicitation (see section 10.16). > > MAY: > - A new prefix is added to the aggregate list Why is this a MAY instead of MUST? Is it to cover the case where a home registration has a zero prefix length? > - The valid or preferred lifetime or the state of the flags > changes for a prefix which is not used in any binding cache > entry for this mobile node I don't understand what your trying to do with this last MAY requirement. It looks like its addressing a problem I've been wondering about. A mobile node with multiple home addresses could either o establish a single binding with a non-zero prefix length to cover all its home addresses, or o establish multiple bindings each with a zero prefix length to cover a single home address. In the latter case, how does the home agent recognize that a single node has multiple bindings? I believe the home agent should avoid sending duplicate home prefix advertisements to the mobile node. One way to fix this is to have the home agent to only send prefix information that is applicable to a specific binding. Is that what your additional requirement was after? If so, I agree with the intent, but believe more detail is needed. Perhaps a statement like the following would help at the start of this section: + A home agent normally sends only the prefixes that match + a mobile node's home registration to the mobile node. A + match exists if the home registration's home address + contains a prefix or if the home registration's prefix + length field is non-zero. Each home registration entry + in the binding cache MUST be treated as if it were + created for a separate mobile node. > The home agent uses the following algorithm to determine when to > send prefix information to the mobile node. There is a requirement at the end of section 9.8.3 to send all prefixes periodically. I think that requirement should be folded into this section to avoid confusion between the two sections. + - Send a Home Agent Prefix Advertisement periodically to prevent + non-decrementing prefixes from expiring on the mobile node. + Calculate the interval between each successive transmission + independently as rand()*HomeRtrAdvInterval seconds; > - If a mobile node sends a solicitation, answer right away. If the proposal for the Send All Prefixes flag is accepted, the following text should be added here: + If the Send All Prefixes flag in the solicitation was set, + include all prefixes from the aggregate list in the advertisement. > - If a prefix changes state in a way that causes a mobile node's > address to go deprecated, send an advertisement right away. I believe the algorithm for RAND_ADV_DELAY covers this situation. It will cause an advertisement to be sent right away if a change causes an address to go deprecated. Can we remove this special case from here simplify the text? > - For any existing prefix, if the mobile node's binding expires > before the advertised Preferred Lifetime, do not schedule the > advertisement. The mobile node will get the revised information > in its next Binding Acknowledgement. This is covered in the RAND_ADV_DELAY scheduling algorithm below. Can we remove it from here to simplify the text? > - If a prefix is added, or if it changes in any way that does not > ============= > cause the mobile node's address to go deprecated, ensure that a > ================================================ > transmission is scheduled at time RAND_ADV_DELAY in the future. Same comment as before, do we need the special case text that is underlined? Also, this probably should be qualified to be more precise. + - If a prefix in the aggregate list that matches the mobile node's + home registration is added or its information changes, ensure that + a transmission is scheduled at time RAND_ADV_DELAY in the future. > - If a prefix advertisement is scheduled, and a Binding Update > arrives, perform that advertisement and include the information > in a Router Advertisement that has the Binding Acknowledgement as > ==================== > a Destination Option. Remove the future scheduled advertisement. Did you mean Mobile Prefix Advertisement here? Is it really necessary to send the Binding Acknowledgement in the same message as the Mobile Prefix Advertisement? I suspect this will be awkward to implement given that Binding Acknowledgements are probably handled in the kernel and Mobile Prefix Advertisements in a daemon. The 3rd rule in this list says "do not schedule the advertisement" if a binding update is expected before the prefix becomes deprecated. The 5th rule says to send an advertisement if "a prefix advertisement is scheduled". Any change that satisfies 3rd rule will never be sent. Perhaps this last rule should say: + - If there are any unacknowledged changes to prefix information + when a Binding Update arrives for the home registration, send + a Mobile Prefix Advertisement to the mobile node immediately. + If an advertisement was previously scheduled for the changes, + cancel it. Should the following be added here for completeness? + - If a home registration expires, cancel any scheduled + advertisements to the mobile node. > The home agent uses the following algorithm to compute > RAND_ADV_DELAY, the offset from the current time for the > scheduled transmission. > > If there is a transmission already scheduled, then > > if the current RAND_ADV_DELAY would cause another > transmission BEFORE the Preferred Lifetime of the > mobile node's home address derived from the prefix whose > advertisement information has changed, then > > add the new information to be transmitted to the > existing scheduled transmission -- return. > > otherwise, > > continue with the following computation, and add the > data from the existing scheduled transmission to the > newly scheduled transmission, deleting the previously > scheduled transmission event. I understood that the reason for sending only the changed prefix information instead of all prefix information is to reduce the connection costs for the mobile nodes on expensive wireless networks. We don't believe the cost savings for this extra complexity will be significant. We would prefer this to be an optional feature. > If the mobile node's binding expires after the Preferred Lifetime, > then compute The indentation following this text could be interpreted to mean we still need to compute RAND_ADV_DELAY even when the IF condition here is false. As an alternative, perhaps a rewording of this IF clause combined with text from above would be helpful. + If the mobile node's binding expires before the Preferred Lifetime, + then return. The mobile node will get the revised information + with its next Binding Acknowledgement. Otherwise, continue with the + following computation: > MAX_SCHEDULE_DELAY == > min (MAX_PFX_ADV_DELAY, Preferred Lifetime) > > for the newly advertised Preferred Lifetime. > Then compute RAND_ADV_DELAY = > MinRtrAdvInt + rand()*(MAX_SCHEDULE_DELAY - MinRtrAdvInt) There may be a problem overwhelming system or network resources if the scheduling algorithm causes the home agent to transmit a home prefix advertisement to all mobile nodes at the same time. The spec should allow a mechanism to avoid this. + A home agent SHOULD perform scheduling of advertisements + described in this section independently for each home + registration in the binding cache to avoid a burst of + advertisements being sent to all mobile nodes at the same time. + In addition, a home agent MAY throttle transmission of + advertisements to prevent overwhelming local resources when + the rules above require immediate transmission of advertisements + to large numbers of mobile nodes. Section 9.8.3 Sending Mobile Prefix Advertisements to the Mobile Node > - When the advertisement was triggered by network renumbering, the > advertisement MUST include a Binding Request destination option. I agree with your intent of not requesting ACKs for every advertisement, but I don't think the term "triggered by network renumbering" catches all the important situations. How does the following sound? + The advertisement MUST include a Binding Request destination + option if this is the first advertisement sent for a home + registration or if there was a change in prefix information + since the last acknowledged advertisement was sent to the + mobile node for the home registration. > The home agent SHOULD periodically continue to retransmit this > tunneled packet to the mobile node, until it is acknowledged by ======== The term "tunneled" was removed elsewhere in section 9.8. Should it be removed here too? > [Delete this paragraph? This is also too much.] > Whenever a mobile node has a valid binding on a network other > than its home network, the home agent MUST send a Mobile Prefix > Advertisement with all prefixes in the aggregate list to the > mobile node at least once per HomeRtrAdvInterval seconds, and > upon receipt of a valid Router Solicitation from the mobile > node. I have no idea what "a network other than its home network" means, but I think a requirement to periodically transmit all prefixes is needed because home addresses on mobile nodes still have a finite lifetime that will expire unless periodically updated. As I stated above, I think this requirement fits better in section 9.8.2. Section 10.16 Sending Mobile Prefix Solicitations > The mobile node SHOULD send a Solicitation to the home agent > when its home address will become invalid within MaxRtrAdvInterval > seconds, where this value is acquired in a previous Router > Advertisement from the home agent. ... ====== ============= Should this be Mobile Prefix Advertisement? > If the mobile node does not have a valid home address available for > use as the IP source address, it MAY use its care-of address, [but > there will not be a security association between the Home Agent and > the care-of address for the corresponding Advertisement to be > authenticated.] We think some kind of security association will be needed here. Section 10.17 Receiving Mobile Prefix Advertisements > - The Source Address of the IP packet carrying the Router > Advertisement is ..... ====== ============= Should this be Mobile Prefix Advertisement? > Since the advertisement contains a Binding Request option, the mobile > node SHOULD return a Binding Update, which will be viewed by the home > agent as an acknowledgement of the corresponding Mobile Prefix > Advertisement, which it can cease retransmitting. Should this paragraph start with "If the advertisement contains..."? The Binding Request option does not always need to be included with a Mobile Prefix Advertisement. Appendix A: Remote Home Address Configuration I noticed you didn't attempt to fix this part. How about: Delete: > A mobile node MAY generate a temporary home address using the > following information: > > - the subnet prefix from the home network's mobile agent anycast > address, and > > - 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 stateful (DHCPv6) address autoconfiguration runs. Your new Mobile Prefix Solicit/Advertisement exchange capability between the mobile node's care-of address and home agent makes this hack unnecessary. Change steps 5 through 9 to: + 5. Select the most preferred home agent and establish a security + association between the mobile node's current care-of address + and the home agent for temporary use during initialization only. + + 6. Send a Home Prefix Solicitation message with the Request All + Prefixes flag set to the home agent from the mobile node's + care-of address. + + 7. Receive a Home Prefix Advertisement message from the home agent, + follow stateless address autoconfiguration rules to configure + home addresses for prefixes received. + + 8. Create a security association between the mobile node's home + address and the home agent. + + 9. Send a binding update(s) to the home agent to register the + mobile node's home addresses. + + 10. Receive binding acknowledgement(s) then begin normal + communications. From owner-mobile-ip@sunroof.eng.sun.com Mon May 21 16:26:04 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17811 for ; Mon, 21 May 2001 16:26:03 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA28767; Mon, 21 May 2001 14:25:45 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA02040; Mon, 21 May 2001 13:25:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4LKNYA11369 for mobile-ip-dist; Mon, 21 May 2001 13:23:34 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4LKNPM11362 for ; Mon, 21 May 2001 13:23:25 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA27350 for ; Mon, 21 May 2001 13:23:24 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA27388 for ; Mon, 21 May 2001 13:23:23 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f4LKNM918957 for ; Mon, 21 May 2001 13:23:22 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AGV03572; Mon, 21 May 2001 13:23:21 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA05199; Mon, 21 May 2001 13:23:21 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15113.31033.527027.123389@thomasm-u1.cisco.com> Date: Mon, 21 May 2001 13:23:21 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] host routes in the fast mipv6 draft In-Reply-To: <200105180105.f4I154W213939@jurassic.eng.sun.com> References: <200105180105.f4I154W213939@jurassic.eng.sun.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Alper Yegin writes: > > As I've said before, I'm sort of worried about how > > this interacts with other routing protocols, and > > especially how it converges when the routes are > > deleted. What would happen, for example, if the > > host route were propogated by OSPF while the > > tunnel was up? > > This must be preventable. Otherwise same OSPF might also propogate the host > routes (for home addresses) on the Home Agent. This is why I'm worried about this feature of the FMIP draft altogether as I don't get the impression that the ideas are fully baked. You say that it must be prevented, but in fact, if it were propogated it would produce least cost routing, and bypass ARold altogether. Under normal circumstances, that would be a Good Thing. Also: I generally think that this is going into the same design territory that got moved into the IRTF for the micro mobility work. I think there's more at stake here than meets the eye. Mike From owner-mobile-ip@sunroof.eng.sun.com Tue May 22 14:17:29 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28897 for ; Tue, 22 May 2001 14:17:27 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA29252; Tue, 22 May 2001 11:16:04 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA29253; Tue, 22 May 2001 11:12:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4MHqdE12890 for mobile-ip-dist; Tue, 22 May 2001 10:52:39 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31] (may be forged)) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4MHqUM12883 for ; Tue, 22 May 2001 10:52:30 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with SMTP id f4MHqTW145141 for ; Tue, 22 May 2001 10:52:29 -0700 (PDT) Message-Id: <200105221752.f4MHqTW145141@jurassic.eng.sun.com> Date: Tue, 22 May 2001 10:52:30 -0700 (PDT) From: Alper Yegin Subject: RE: [mobile-ip] host routes in the fast mipv6 draft To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Q4wvQf4HuO5IFRaiLrkUPg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Jim, > >> Also, if there is a forward and reverse tunnel from oldAR to newAR, I'm > >> curious why MN needs to do a BU/BACK back to oldAR? > > > >Which BU/Back is this? This is not the F-BU/F-Back that was exchanged before > >this tunnel gets created. ?? > > > > The F-BU/F-BACK can occur either before or after the L2 handover. If > the tunnel isn't created until the F-BU/F-BACK is exchanged, there > is no point in creating it. I thought the point of the tunnel was > so that MN can use old CoA until the F-BU/F-BACK completes. But since Basically this tunnel accomplishes "forwarding from previous care-of address". It's not created until oldAR receives a F-BU, and a HACK. Depending on whether newCoA is valid or not, this tunnel's end point becomes either newAR or newCoA. Through this tunnel, packets destined to oldCoA are either shuttled to newAR or MN at its new point of attachment. In the former case, newAR needs to have a host route to deliver packets to MN. > MN already knows is new CoA (via the RtAdv), and since it can send > and receive packets using its old CoA via a bidirectional tunnel > through old AR, what is the point of the F-BU/F-BACK? Until F-BU is received by oldAR, there's no tunnel. Only if MN doesn't receive F-BACK, then it sends another F-BU after attaching to new link. Otherwise, F-BU is sent to oldAR while MN is still attached to old link. I hope this clarifies... alper > > jak > alper From owner-mobile-ip@sunroof.eng.sun.com Tue May 22 14:19:46 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29042 for ; Tue, 22 May 2001 14:19:44 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA27932; Tue, 22 May 2001 12:19:30 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08157; Tue, 22 May 2001 11:18:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4MI1Hf12907 for mobile-ip-dist; Tue, 22 May 2001 11:01:17 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4MI17M12900 for ; Tue, 22 May 2001 11:01:08 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with SMTP id f4MI15W147404 for ; Tue, 22 May 2001 11:01:06 -0700 (PDT) Message-Id: <200105221801.f4MI15W147404@jurassic.eng.sun.com> Date: Tue, 22 May 2001 11:01:05 -0700 (PDT) From: Alper Yegin Subject: RE: [mobile-ip] host routes in the fast mipv6 draft To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: X141IEDZJi+N4u7DGBDj3Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Mike, > > > As I've said before, I'm sort of worried about how > > > this interacts with other routing protocols, and > > > especially how it converges when the routes are > > > deleted. What would happen, for example, if the > > > host route were propogated by OSPF while the > > > tunnel was up? > > > > This must be preventable. Otherwise same OSPF might also propogate the host > > routes (for home addresses) on the Home Agent. > > This is why I'm worried about this feature of the > FMIP draft altogether as I don't get the impression > that the ideas are fully baked. You say that it > must be prevented, but in fact, if it were propogated I'm trying to point out that the potential problem you are saying is not specific to FMIP. If there's such a problem, it'll also hit base Mobile IPv6, as there are host routes on the Home Agent for each mobile node that's away from home (pointing to respective tunnels). > it would produce least cost routing, and bypass > ARold altogether. Under normal circumstances, > that would be a Good Thing. > > Also: I generally think that this is going > into the same design territory that got moved > into the IRTF for the micro mobility work. I > think there's more at stake here than meets > the eye. Are you saying this becase there is one (oldCoA -> tunnel) and sometimes two (oldCoA -> newlink) host routes? Note that these are "temporary" host routes used to establish forwarding from previous care-of address. alper From owner-mobile-ip@sunroof.eng.sun.com Thu May 24 12:13:50 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16437 for ; Thu, 24 May 2001 12:13:49 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA04025; Thu, 24 May 2001 10:13:36 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13516; Thu, 24 May 2001 09:13:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4OGBZZ02525 for mobile-ip-dist; Thu, 24 May 2001 09:11:35 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4OGBVe02518 for ; Thu, 24 May 2001 09:11:32 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id JAA26901 for ; Thu, 24 May 2001 09:11:35 -0700 (PDT) Message-Id: <200105241611.JAA26901@heliopolis.eng.sun.com> Date: Thu, 24 May 2001 09:11:35 -0700 (PDT) From: James Kempf Subject: [mobile-ip] Timings for FMIPv4 and FMIPv6 To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 2gEegGek9d70FdvnHAbnzw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I revisited the MIPv6 handoff timings I calculated last week based on comments on the list and a rereading of the spec (draft-ietf-mobileip-fast-mipv6-01.txt). In addition, I calculated the same figures for the MIPv4 low latency techniques describe in draft-ietf-mobileip-lowlatencyhandoffs-v4-01.txt, which was posted last week. The results are presented in a comparison table at the end of this note. Bandwith of Radio Connection ---------------------------- While the number of bytes in the messages exchanges is fixed and known, one of the major sources of uncertainty in the calculations is the actual bandwidth available over the air for IP signalling. The calculations assume that the exchange of bytes over the air is the controlling factor at L3 for when the MN stops getting packets at oldAR and starts getting them again at newAR. The actual time required between when the MN stops getting packets at the oldAR and when the packet flow restarts at the newAR is important because it determines whether the user will perceive a pause or other distortion in a real time stream during the handover. Therefore, I think it is worthwhile as an indication of whether a particular handoff technique will have more or less of a probability of presenting the user with a perceptible delay. The threshold of preception is a 300 ms delay, according to the ITU, and this value includes both IP signalling and L2 signalling, so any L3 signalling delay figures must be weighed by the fact that there will be an L2 delay during handover as well. In the original calculations, I used 7.5 kbps (960 bytes/sec). wCDMA actually uses a rate of 3 kpbs for signalling over the DCCH signalling channel. Currently, it is not possible to do IP signalling over the DCCH signalling channel in wCDMA. While this could be changed, it seems more likely that any mobile IP signalling in the immediate future will go over a traffic channel. The DPCCH traffic channel has a variable bit rate on a per frame basis between 0 and 2.1 mpbs, and the rate can differ in the uplink and downlink directions. Using a traffic channel has an advantage in that the data rate is higher and can be throttled up or down, but a disadvantage in that any real time bearer traffic will be delayed until the signalling traffic is sent or received. The other disadvantage is that using a higher data rate is expensive. Note that if it were possible to do IP signalling over the DCCH signalling channel, it might be possible to achieve a higher degree of parallelism even given the lower data rate, since DCCH signalling and DPCCH traffic can flow simultaneously. In order to take advantage of the multiple data rates, I calculated each handoff using data rates of 7.5 kbps (960 bytes/sec), 9.6 kbps (1200 bytes/sec), and 15 kbps (1875 bytes/sec). Modifications in the Calculation -------------------------------- Correspondence on the list and a careful re-reading of the spec established that the assumptions I made about the exchange of messages were incorrect. The MN does not have to receive a F-BACK before it can start sending traffic, the only constraint is that oldAR cannot forward any traffic to the MN through newAR until it receives a F-BU (pg. 5). This is true for all cases. In addition, the MN cannot send or receive any packets until it does an NA or, at the very least, an F-NA to newAR. So the new calculations replace the F-BU received by the MN with an F-NA sent by the MN. The MN does not have to receive a RtAdv as a response to the F-NA before it can send packets, it can send them using oCoA (pg. 11). The previous calculations also assumed that network assisted, stateful handoff did not require a F-BU/F-BACK exchange with oldAR. These assumptions were based on Fig. 2, pg. 9, which shows no such exchange. But a rereading of the spec and correspondence on the list established that Fig. 2 is incomplete, and it must essentially be grafted onto Fig. 1 for completeness. Since the message exchanges in both Fig. 1 and Fig. 2 are the same, with the exception that the PrRtAdv in Fig. 2 is delayed until the HI/HACK is exchanged, I've left off the network assisted, stateful case in this calculation. The HI/HACK exchange will likely add a delay in the millisecond to submillisecond range, depending on the amount of time it takes newAR to allocate a new CoA, which is insignificant compared to the air interface delay. The message exchanges are designed for the fastest possible case in which the MN can start exchanging real time packets after a handoff . In some cases, this means that the oldAR or MN are not using the new CoA, but rather, that a bidirectional edge tunnel is available between oldAR and newAR (or oldFA and newFA) to forward packets through newAR to MN. Eventually, MN will confirm its new CoA through newAR and can begin to use it as well, but until that happens, it can still continue a real time stream. Finally, the original calculation neglected the 8 byte UDP header for the post-handoff messages. The pre-handoff messages have both the IP and UDP headers removed by header compression. Other Assumptions ----------------- The other assumptions remain the same for both the MIPv6 and MIPv4 case. These are stated here: - Prior to handoff, the header compressor on the old AR is "hot" enough to compress the basic 48 byte IPv6 + UPD header and 28 byte IPv4 + UPD header down to 1 byte, but after handoff, the header compressor is "cold" and so the full IP + UDP header needs to be sent. Currently, there is some debate about whether the compressor could be partially restarted on the new AR using context transfer, so this could introduce an additional optimization and also a potential area of timing uncertainty involving the context transfer time itself. - The wired link ARs use Ethernet (48 bit MAC address link layer) and the wireless link is using 15 byte IMSIs (International Mobile Station Identifiers) sent as ASCII digits. Calculated Message Exchanges ---------------------------- The following table gives the message exchanges that were calculated and the final configuration when real time traffic starts again after handoff, indicating which CoA is used by the MN and newAR. The parenthesized (old) and (new) after the message name indicated whether the message is sent through the oldAR or newAR (or oldFA or newFA). Sequence Name Message Sequence Size Final Configuration ------------- ---------------- ----- ------------------- FMIPv6 Network Full BU PrRtAdv(old) 51 oCoA (FMIPv6-NFB) F-BU (old) 11 -------> F-BACK (old) 10 MN <------ newAR F-NA (new) 106 nCoA ---------------------- Total 178 FMIPv6 Network New BU PrRtAdv(old) 51 oCoA (FMIPv6-NNB) F-BU(new) 58 -------> F-NA(new) 106 MN <------- newAR ---------------------- oCoA Total 215 FMIPv6 Network Old BU PrRtAdv(old) 51 oCoA (FMIPv6-NOB) F-BU(old) 11 -------> F-NA(new) 106 MN <------- newAR --------------------- oCoA Total 168 FMIPv6 Mobile Full BU RtSolPrxy(old) 36 same as FMIPv6-NFB (FMIPv6-MFB) PrRtAdv(old) 51 F-BU(old) 11 F-BACK(old) 10 F-NA(new) 106 ---------------------- Total 214 FMIPv6 Mobile New BU RtSolPrxy(old) 36 same as FMIPv6-NNB (FMIPv6-MNB) PrRtAdv(old) 51 F-BU(new) 58 F-NA(new) 106 ---------------------- Total 251 FMIPv6 Mobile Old BU RtSolPrxy(old) 36 same as FMIPv6-NOB (FMIPv6-MOB) PrRtAdv(old) 51 F-BU(old) 11 F-NA(new) 106 ---------------------- Total 204 FMIPv4 PRE Old Network PrRtAdv(old) 33 nCoA (FMIPv4-PON) HA Reg(old) 29 --------> ---------------------- MN <-------- newFA Total 62 nCoA FMIPv4 PRE Old Mobile RtSol nCoA (FMIPv4-POM) w. Link Ind(old) 27 ---------> PrRtAdv(old) 33 MN <-------- newFA HA reg(old) 29 nCoA ---------------------- Total 89 FMIPv4 PRE New Network PrRtAdv(old) 33 same as FMIPv4-PON (FMIPv4-PNN) HA Reg(new) 37 ---------------------- Total 70 FMIPv4 PRE New Mobile RtSol same as FMIPv4-POM (FMIPv4-PNM) w. Link Ind(old) 27 PrRtAdv(old) 33 HA reg(new) 37 ---------------------- Total 97 POST oCoA ---------> MN <--------- newFA oCoA L3 Handoff Latency ------------------ The following table gives handoff latencies for the message exchanges in the previous table. The exchanges are indicated by their abbreviations, i.e. FMIPv6-NFB stands for Fast MIPv6 Network Full Binding update. The rows are sorted by time, from the lowest latency to the highest latency. Message Xchange 940 bytes/sec 1200 bytes/sec 1875 bytes/sec (7.5 kbps) (9.6 kbps) (15 kbps) --------------- ------------- -------------- -------------- POST 0 0 0 FMIPv4-PON 65 51 33 FMIPv4-PNN 74 58 37 FMIPv4-POM 94 74 47 FMIPv4-PNM 103 81 51 FMIPv6-NOB 178 140 89 FMIPv6-NFB 189 148 94 FMIPv6-MOB 217 170 108 FMIPv6-MFB 227 178 114 FMIPv6-NNB 228 179 114 FMIPv6-MNB 267 209 134 Comments -------- I'd like to keep comments in a separate thread, so I'll post another message with interpretations and suggestions. Acknowledgements ---------------- Thanx to Raj Patil of Nokia for researching wCDMA data rates, and Alper Yegin of Sun for guiding me through the mysteries of draft-ietf-mobileip-fast-mipv6-01.txt. From owner-mobile-ip@sunroof.eng.sun.com Thu May 24 14:06:48 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18276 for ; Thu, 24 May 2001 14:06:48 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA17500; Thu, 24 May 2001 11:06:48 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA11914; Thu, 24 May 2001 11:06:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4OI4RA02670 for mobile-ip-dist; Thu, 24 May 2001 11:04:27 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4OI4Ne02663 for ; Thu, 24 May 2001 11:04:24 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA17293 for ; Thu, 24 May 2001 11:04:29 -0700 (PDT) Received: from zrc2s03g.nortelnetworks.com ([47.103.122.66]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA25478 for ; Thu, 24 May 2001 12:04:48 -0600 (MDT) Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zrc2s03g.nortelnetworks.com (8.9.3+Sun/8.9.1) with ESMTP id NAA17697 for ; Thu, 24 May 2001 13:05:23 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Thu, 24 May 2001 13:04:40 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 May 2001 13:04:07 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E430255D543@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Test Date: Thu, 24 May 2001 13:04:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0E47B.EA490C20" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C0E47B.EA490C20 Content-Type: text/plain; charset="iso-8859-1" Test ------_=_NextPart_001_01C0E47B.EA490C20 Content-Type: text/html; charset="iso-8859-1" Test

Test

------_=_NextPart_001_01C0E47B.EA490C20-- From owner-mobile-ip@sunroof.eng.sun.com Thu May 24 21:50:12 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA24655 for ; Thu, 24 May 2001 21:50:11 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA05092; Thu, 24 May 2001 19:50:16 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA22591; Thu, 24 May 2001 18:48:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4P1l2O03755 for mobile-ip-dist; Thu, 24 May 2001 18:47:02 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4P1kxe03748 for ; Thu, 24 May 2001 18:46:59 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA22068 for ; Thu, 24 May 2001 18:47:00 -0700 (PDT) From: pan.peisheng@mail.zte.com.cn Received: from ns.zhongxing.com ([202.103.147.131]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA14727 for ; Thu, 24 May 2001 18:46:35 -0700 (PDT) Received: from ntepmdx (unverified [10.30.1.249]) by ns.zhongxing.com (Rockliffe SMTPRA 4.2.4) with ESMTP id for ; Fri, 25 May 2001 09:53:53 +0800 Subject: reply: [mobile-ip] Test To: mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.1 (Intl) 16 July 1999 Message-ID: Date: Thu, 24 May 2001 09:37:10 +0800 X-MIMETrack: Serialize by Router on notes_svr7/zte_ltd(Release 5.0.4 |June 8, 2000) at 2001-05-25 09:45:32 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: OK! Test From owner-mobile-ip@sunroof.eng.sun.com Thu May 24 22:51:42 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA26267 for ; Thu, 24 May 2001 22:51:41 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA01802; Thu, 24 May 2001 20:51:36 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA19887; Thu, 24 May 2001 19:50:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4P2nLq03891 for mobile-ip-dist; Thu, 24 May 2001 19:49:21 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4P2nIe03884 for ; Thu, 24 May 2001 19:49:18 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA29571 for ; Thu, 24 May 2001 19:49:24 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA00744 for ; Thu, 24 May 2001 20:49:22 -0600 (MDT) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f4P2nM805204 for ; Thu, 24 May 2001 21:49:23 -0500 (CDT) Received: from daebh02nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 24 May 2001 21:49:23 -0500 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Thu, 24 May 2001 21:49:23 -0500 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B03213B01@daeis07nok> To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Timeslot requests for IETF51 Date: Thu, 24 May 2001 21:49:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Resending it as I did not see it on the list.... Hello, If you would like to obtain a timeslot for presentations at the London IETF (IETF51 5-10 August 2001), please send your requests to either Phil or me. Please include the title of the I-D, time required, and also some reasons why the I-D is important for consideration by the Mobile IP WG. The deadline for receiving requests for timeslots is : July 30th, 2001 -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Thu May 24 23:05:43 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA26386 for ; Thu, 24 May 2001 23:05:42 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA13799; Thu, 24 May 2001 20:05:48 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA21343; Thu, 24 May 2001 20:04:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4P33J403931 for mobile-ip-dist; Thu, 24 May 2001 20:03:19 -0700 (PDT) Received: from purol.East.Sun.COM (purol.East.Sun.COM [129.148.9.11]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4P33Ge03924 for ; Thu, 24 May 2001 20:03:16 -0700 (PDT) Received: from purol.East.Sun.COM (esun1as-be.Central.Sun.COM [129.147.34.142]) by purol.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA00005 for ; Thu, 24 May 2001 23:03:18 -0400 (EDT) From: Steven Glass - Solaris Software Message-Id: <200105250303.XAA00005@purol.East.Sun.COM> Date: Thu, 24 May 2001 17:04:38 -0400 To: Subject: Re: [mobile-ip] Timeslot requests for IETF51 X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Registration Revocation (incorporating some ideas with Cisco). Maybe DHCP or Security issues (choose zero or one). One more request - please, no meeting Friday morning! Cheers, Steve From owner-mobile-ip@sunroof.eng.sun.com Thu May 24 23:11:13 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA26453 for ; Thu, 24 May 2001 23:11:12 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA09665; Thu, 24 May 2001 21:11:16 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA21994; Thu, 24 May 2001 20:09:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4P39ER03956 for mobile-ip-dist; Thu, 24 May 2001 20:09:14 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4P39Ae03949 for ; Thu, 24 May 2001 20:09:10 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA27278 for ; Thu, 24 May 2001 20:09:16 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA19618 for ; Thu, 24 May 2001 20:09:11 -0700 (PDT) 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 UAA01906; Thu, 24 May 2001 20:09:10 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f4P397m08851; Thu, 24 May 2001 20:09:07 -0700 X-mProtect: Thu, 24 May 2001 20:09:07 -0700 Nokia Silicon Valley Messaging Protection Received: from tkniveto.iprg.nokia.com (205.226.2.111, claiming to be "Kniveton.com") by darkstar.iprg.nokia.com(P1.5 smtpdnIsXYf; Thu, 24 May 2001 20:09:05 PDT Message-ID: <3B0DCCD4.3616B2ED@Kniveton.com> Date: Thu, 24 May 2001 20:09:08 -0700 From: "T.J. Kniveton" Organization: NOKIA Research X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Powell, Ken" CC: "'dbj@cs.rice.edu'" , "'charliep@iprg.nokia.com'" , "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Mobile Prefix Advertisements (more comments) References: <88BD5A70CA8BFA4CA15D0ED053E49D69067D70@tayexc14.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Powell, Ken" wrote: > > Hi T.J., > > Vlad Yasevich, Brian Haley, Greg Colburn and I > finished our discussion of your proposal. This is the > remainder of our comments. Many comments also apply > to draft-ietf-mobileip-ipv6-13 without your changes > as well. Thanks for your efforts! I will try and make some brief and immediate comments, and please see my note at the end of the message as well. > > Ken Powell > Compaq Computer Corporation > > 5.8 Mobile Prefix Solicitation Message Format > > My comments to section 9.8.2 below request that only the prefixes > that match a particular home registration be sent to the mobile > node in Mobile Prefix Advertisements. If the binding has a zero > prefix length, only the specific prefix for the mobile node's > home address would be sent. For a bindings with a non-zero prefix > length, all prefixes in the aggregate list would be sent. > > This left a problem, what prefixes do we send in response to a > Router Solicitation? I think the home agent should use the Did you mean Mobile Prefix Solicitation here, or did you really mean Router Solicitation? > same prefix selection logic, but the mobile node needs a way to > override this behavior to support initialization. One option is > to add a flag to the Mobile Prefix Solicitation Message: > > + Send All Prefixes flag > + > + If clear, the home agent replies by sending only the prefixes > + that match the mobile nodes home registration as defined in > + section 9.8.2. If set, the home agent will send all prefixes > + for the home network as defined in section 9.8.1. No prefixes > + will be sent if this flag is clear and the mobile node does > + not yet have a home registration. When the mobile node is initializing, the home agent would not have a home registration to refer to for prefix length. It seems to me that in the case where the mobile node specifically requests prefixes, it is probably best to give it all the prefixes on the home link served by home agents. Can you elaborate on the benefits and functionality allowed by a "Send All Prefixes flag," aside from some posssible reduction in M.P.A. length? > > 9.8.2 Sending Changed Prefix Information to the Mobile Node > > Due to the number of comments on this section, I'm including > the entire text with ">" marks, and slicing in the comments > where they apply. > > > A home agent serving a mobile node will schedule the delivery > > of new prefix information to that mobile node when any of the > > following conditions occur: > > Can the following list of MUST and MAY requirements be merged > into the algorithm for sending prefix information below? > > > MUST: > > - The valid or preferred lifetime or the state of the flags > > changes for the prefix of the mobile node's registered home > > address changes > > - The mobile node requests the information with a Router > > Solicitation (see section 10.16). > > > > MAY: > > - A new prefix is added to the aggregate list > > Why is this a MAY instead of MUST? Is it to cover the case > where a home registration has a zero prefix length? It is a may because I do not see it as essential for a mobile node, which already has a home registration and presumably can use its configured home address, to be able to configure additional home addresses as the prefixes become available on the home network. It may be possible to imagine a situation where the mobile node *would* want to immediately use these addresses, but it doesn't seem important enough to schedule a new M.P.A. just for this purpose. > > > - The valid or preferred lifetime or the state of the flags > > changes for a prefix which is not used in any binding cache > > entry for this mobile node > > I don't understand what your trying to do with this > last MAY requirement. It looks like its addressing a > problem I've been wondering about. A mobile node with > multiple home addresses could either > > o establish a single binding with a non-zero prefix > length to cover all its home addresses, or > > o establish multiple bindings each with a zero prefix > length to cover a single home address. Couldn't it establish multiple bindings, each with a non-zero prefix length? That would be what I would expect to happen, since the key is the home address, not the care-of address. That is to say, it would seem valid to have multiple home addresses each registered (and prefix length noted), pointing to the same care-of address. > > In the latter case, how does the home agent recognize > that a single node has multiple bindings? I believe the > home agent should avoid sending duplicate home prefix > advertisements to the mobile node. Ah, I see what you're getting at. Well, I would first try to sort by the care-of address; however, the mobile node could have a different care-of address for each home address as well. In that case, it seems much harder to tell when multiple bindings are the same machine. However, I do not think that registering a zero prefix length would be the best solution at this time. > > One way to fix this is to have the home agent to only > send prefix information that is applicable to a specific > binding. Is that what your additional requirement was > after? If so, I agree with the intent, but believe more > detail is needed. Perhaps a statement like the following > would help at the start of this section: > > + A home agent normally sends only the prefixes that match > + a mobile node's home registration to the mobile node. A > + match exists if the home registration's home address > + contains a prefix or if the home registration's prefix > + length field is non-zero. Each home registration entry > + in the binding cache MUST be treated as if it were > + created for a separate mobile node. I thought this was clear from the text - perhaps it is clearer in the newer revision. Let's follow this up further. > > > The home agent uses the following algorithm to determine when to > > send prefix information to the mobile node. > > There is a requirement at the end of section 9.8.3 to send all > prefixes periodically. I think that requirement should be folded > into this section to avoid confusion between the two sections. Yes, this has changed in the next version. > > + - Send a Home Agent Prefix Advertisement periodically to prevent > + non-decrementing prefixes from expiring on the mobile node. > + Calculate the interval between each successive transmission > + independently as rand()*HomeRtrAdvInterval seconds; > > > - If a mobile node sends a solicitation, answer right away. > > If the proposal for the Send All Prefixes flag is accepted, > the following text should be added here: > > + If the Send All Prefixes flag in the solicitation was set, > + include all prefixes from the aggregate list in the advertisement. > > > - If a prefix changes state in a way that causes a mobile node's > > address to go deprecated, send an advertisement right away. > > I believe the algorithm for RAND_ADV_DELAY covers this situation. > It will cause an advertisement to be sent right away if a change > causes an address to go deprecated. Can we remove this special > case from here simplify the text? Good idea. > > > - For any existing prefix, if the mobile node's binding expires > > before the advertised Preferred Lifetime, do not schedule the > > advertisement. The mobile node will get the revised information > > in its next Binding Acknowledgement. > > This is covered in the RAND_ADV_DELAY scheduling algorithm below. > Can we remove it from here to simplify the text? > > > - If a prefix is added, or if it changes in any way that does not > > ============= > > cause the mobile node's address to go deprecated, ensure that a > > ================================================ > > transmission is scheduled at time RAND_ADV_DELAY in the future. > > Same comment as before, do we need the special case text that is > underlined? Also, this probably should be qualified to be more > precise. > > + - If a prefix in the aggregate list that matches the mobile node's > + home registration is added or its information changes, ensure that > + a transmission is scheduled at time RAND_ADV_DELAY in the future. It's not clear to me how a prefix could be *added* that matches the mobile node's home registration - wouldn't it have to be in the list for the home registration to be accepted initially? > > > - If a prefix advertisement is scheduled, and a Binding Update > > arrives, perform that advertisement and include the information > > in a Router Advertisement that has the Binding Acknowledgement as > > ==================== > > a Destination Option. Remove the future scheduled advertisement. > > Did you mean Mobile Prefix Advertisement here? Yes, there seems to be some intermixing of the terms, but I assure you that I did a query-replace in draft 14 :) > > Is it really necessary to send the Binding Acknowledgement in the > same message as the Mobile Prefix Advertisement? I suspect this > will be awkward to implement given that Binding Acknowledgements are > probably handled in the kernel and Mobile Prefix Advertisements > in a daemon. I guess it depends on the implementation - it should be possible for the kernel to grab the binding ack off the packet before it gets to user space, no? > > The 3rd rule in this list says "do not schedule the advertisement" > if a binding update is expected before the prefix becomes > deprecated. The 5th rule says to send an advertisement if "a > prefix advertisement is scheduled". Any change that satisfies > 3rd rule will never be sent. Perhaps this last rule should say: > > + - If there are any unacknowledged changes to prefix information > + when a Binding Update arrives for the home registration, send > + a Mobile Prefix Advertisement to the mobile node immediately. > + If an advertisement was previously scheduled for the changes, > + cancel it. > > Should the following be added here for completeness? > > + - If a home registration expires, cancel any scheduled > + advertisements to the mobile node. Good points. > > > The home agent uses the following algorithm to compute > > RAND_ADV_DELAY, the offset from the current time for the > > scheduled transmission. > > > > If there is a transmission already scheduled, then > > > > if the current RAND_ADV_DELAY would cause another > > transmission BEFORE the Preferred Lifetime of the > > mobile node's home address derived from the prefix whose > > advertisement information has changed, then > > > > add the new information to be transmitted to the > > existing scheduled transmission -- return. > > > > otherwise, > > > > continue with the following computation, and add the > > data from the existing scheduled transmission to the > > newly scheduled transmission, deleting the previously > > scheduled transmission event. > > I understood that the reason for sending only the changed prefix > information instead of all prefix information is to reduce the > connection costs for the mobile nodes on expensive wireless > networks. We don't believe the cost savings for this extra > complexity will be significant. We would prefer this to be an > optional feature. I would tend to agree with you. > > > If the mobile node's binding expires after the Preferred Lifetime, > > then compute > > The indentation following this text could be interpreted to mean > we still need to compute RAND_ADV_DELAY even when the IF condition > here is false. As an alternative, perhaps a rewording of this IF > clause combined with text from above would be helpful. > > + If the mobile node's binding expires before the Preferred Lifetime, > + then return. The mobile node will get the revised information > + with its next Binding Acknowledgement. Otherwise, continue with the > + following computation: > > > MAX_SCHEDULE_DELAY == > > min (MAX_PFX_ADV_DELAY, Preferred Lifetime) > > > > for the newly advertised Preferred Lifetime. > > Then compute RAND_ADV_DELAY = > > MinRtrAdvInt + rand()*(MAX_SCHEDULE_DELAY - MinRtrAdvInt) > > There may be a problem overwhelming system or network resources > if the scheduling algorithm causes the home agent to transmit a > home prefix advertisement to all mobile nodes at the same time. > The spec should allow a mechanism to avoid this. Yes, even with rewording this, there are conditions which could trigger similar unwanted flooding. We need to think of ways to avoid this. > > + A home agent SHOULD perform scheduling of advertisements > + described in this section independently for each home > + registration in the binding cache to avoid a burst of > + advertisements being sent to all mobile nodes at the same time. > + In addition, a home agent MAY throttle transmission of > + advertisements to prevent overwhelming local resources when > + the rules above require immediate transmission of advertisements > + to large numbers of mobile nodes. Sounds like a good start. > > Section 9.8.3 Sending Mobile Prefix Advertisements to the Mobile Node > > > - When the advertisement was triggered by network renumbering, the > > advertisement MUST include a Binding Request destination option. > > I agree with your intent of not requesting ACKs for > every advertisement, but I don't think the term "triggered > by network renumbering" catches all the important situations. > How does the following sound? > > + The advertisement MUST include a Binding Request destination > + option if this is the first advertisement sent for a home > + registration or if there was a change in prefix information > + since the last acknowledged advertisement was sent to the > + mobile node for the home registration. > > > The home agent SHOULD periodically continue to retransmit this > > tunneled packet to the mobile node, until it is acknowledged by > ======== > > The term "tunneled" was removed elsewhere in section 9.8. > Should it be removed here too? I believe it was. > > > [Delete this paragraph? This is also too much.] > > Whenever a mobile node has a valid binding on a network other > > than its home network, the home agent MUST send a Mobile Prefix > > Advertisement with all prefixes in the aggregate list to the > > mobile node at least once per HomeRtrAdvInterval seconds, and > > upon receipt of a valid Router Solicitation from the mobile > > node. > > I have no idea what "a network other than its home network" > means, but I think a requirement to periodically transmit > all prefixes is needed because home addresses on mobile nodes > still have a finite lifetime that will expire unless > periodically updated. As I stated above, I think this requirement > fits better in section 9.8.2. > > Section 10.16 Sending Mobile Prefix Solicitations > > > The mobile node SHOULD send a Solicitation to the home agent > > when its home address will become invalid within MaxRtrAdvInterval > > seconds, where this value is acquired in a previous Router > > Advertisement from the home agent. ... ====== > ============= > > Should this be Mobile Prefix Advertisement? > > > If the mobile node does not have a valid home address available for > > use as the IP source address, it MAY use its care-of address, [but > > there will not be a security association between the Home Agent and > > the care-of address for the corresponding Advertisement to be > > authenticated.] > > We think some kind of security association will be needed here. Yes, the security issues are probably the most unresolved, and I have left room in draft 14 for a security association based on IPsec to continue to exist, but I have many question marks on this issue. > > Section 10.17 Receiving Mobile Prefix Advertisements > > > - The Source Address of the IP packet carrying the Router > > Advertisement is ..... ====== > ============= > > Should this be Mobile Prefix Advertisement? I believe the version of the document you are working with did not have all the terminology fleshed out. > > > Since the advertisement contains a Binding Request option, the mobile > > node SHOULD return a Binding Update, which will be viewed by the home > > agent as an acknowledgement of the corresponding Mobile Prefix > > Advertisement, which it can cease retransmitting. > > Should this paragraph start with "If the advertisement contains..."? > The Binding Request option does not always need to be included with > a Mobile Prefix Advertisement. > > Appendix A: Remote Home Address Configuration > > I noticed you didn't attempt to fix this part. How about: Hmm, I was hoping you wouldn't notice ;) > > Delete: > > > A mobile node MAY generate a temporary home address using the > > following information: > > > > - the subnet prefix from the home network's mobile agent anycast > > address, and > > > > - 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 stateful (DHCPv6) address autoconfiguration runs. > > Your new Mobile Prefix Solicit/Advertisement exchange capability > between the mobile node's care-of address and home agent makes this > hack unnecessary. > > Change steps 5 through 9 to: > > + 5. Select the most preferred home agent and establish a security > + association between the mobile node's current care-of address > + and the home agent for temporary use during initialization only. > + > + 6. Send a Home Prefix Solicitation message with the Request All > + Prefixes flag set to the home agent from the mobile node's > + care-of address. > + > + 7. Receive a Home Prefix Advertisement message from the home agent, > + follow stateless address autoconfiguration rules to configure > + home addresses for prefixes received. > + > + 8. Create a security association between the mobile node's home > + address and the home agent. > + > + 9. Send a binding update(s) to the home agent to register the > + mobile node's home addresses. > + > + 10. Receive binding acknowledgement(s) then begin normal > + communications. This looks good. Thanks for all of your comments. Since there were some more changes, which I alluded to, between the time I sent you the text version you made comments on, and the updated (but not yet 14) draft Charlie posted a link to yesterday, it might be best if we compare your comments to that. It would be ideal for us to just talk about this face to face, since there are some difficult issues which are hard to fully discuss via e-mail. I'd like to also point out (to everyone) that this section, or at least as it relates to renumbering, and the changes I made to it are still in what I would call a "research" stage; that is to say, there is room for change before it will be mature and fully usable. So let's continue to improve it and comments are still welcome even after draft 14 is submitted. Thanks, -- T.J. Kniveton NOKIA Research From owner-mobile-ip@sunroof.eng.sun.com Thu May 24 23:26:03 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA26505 for ; Thu, 24 May 2001 23:26:02 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA23082; Thu, 24 May 2001 20:31:40 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA17788; Thu, 24 May 2001 19:30:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4P2TJw03813 for mobile-ip-dist; Thu, 24 May 2001 19:29:19 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4P2TFe03806 for ; Thu, 24 May 2001 19:29:15 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA22817 for ; Thu, 24 May 2001 19:29:21 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA21721 for ; Thu, 24 May 2001 20:29:19 -0600 (MDT) 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 TAA00789 for ; Thu, 24 May 2001 19:29:15 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f4P2TBB19375 for ; Thu, 24 May 2001 19:29:11 -0700 X-mProtect: Thu, 24 May 2001 19:29:11 -0700 Nokia Silicon Valley Messaging Protection Received: from tkniveto.iprg.nokia.com (205.226.2.111, claiming to be "Kniveton.com") by darkstar.iprg.nokia.com(P1.5 smtpdcOKwNo; Thu, 24 May 2001 19:29:10 PDT Message-ID: <3B0DC379.A3241CB2@Kniveton.com> Date: Thu, 24 May 2001 19:29:13 -0700 From: "T.J. Kniveton" Organization: NOKIA Research X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] draft-ietf-mobileip-ipv6-13: Trade-off in Mobile Prefix advertisements References: <88BD5A70CA8BFA4CA15D0ED053E49D695094C7@tayexc14.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thanks for your comments on the prefix issues, Ken. I must admit that I have been a bit slow to respond to mailing list mail- I've been serving on a jury which keeps me away from computers for most of the day. It looks like you are commenting on Draft 13 of the Mobile IPv6 spec here, and of course the Mobile Prefix Advertisements do not exist until version 14, so it's a little difficult to comment on how they relate, but I'll try to do so in a general way: In draft 13, there was a lot of rules for how to process prefix changes and disseminate this information to mobile nodes while away from home. When I made changes to the draft, I tried to simplify these rules, since they require a fair bit of processing and state as you noted. It was not straight-forward to fully get rid of this, but I did try to reduce it. Do you have a specific problem with the changed set of requirements, or is it more of a problem with draft 13? -TJ "Powell, Ken" wrote: > > Vlad Yasevich and I were looking at the implementation impacts > of draft-ietf-mobileip-ipv6-13 section 9.8.2. This section > requires a home agent implementation build a list of changed > prefixes and schedule an advertisement with just the changes > when home network prefix information changes. In addition, > section 9.8.3 requires that the changed prefixes be retransmitted > until acked by a mobile node. This processing to support lists > of changed prefixes will have to be performed independently for > each mobile node, with perhaps thousands of mobile nodes on some > home agents. > > We understand that the reason for sending only the changed prefix > information instead of all prefix information is to reduce the > connection costs for the mobile nodes on expensive wireless > networks. Does the expected network cost savings justify the > algorithm complexity that will be necessary to meet this > requirement? > > We assume most home networks will have only 1 prefix, 2 during > renumbering events. It will probably be very rare for any home > network to have more than 4 prefixes even with multihoming. > The prefix information on production networks are likely to change > very infrequently. I expect no more than a few times in any given > year. Do these assumptions sound correct? If so, we don't see how > sending the unchanged prefixes will add any noticeable cost to the > mobile node's connection. > > Ken -- T.J. Kniveton NOKIA Research From owner-mobile-ip@sunroof.eng.sun.com Fri May 25 03:24:37 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA13171 for ; Fri, 25 May 2001 03:24:37 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA14908; Fri, 25 May 2001 01:24:39 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA19662; Fri, 25 May 2001 00:24:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4P7MtB04110 for mobile-ip-dist; Fri, 25 May 2001 00:22:55 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4P7Mqe04103 for ; Fri, 25 May 2001 00:22:52 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA19585 for ; Fri, 25 May 2001 00:22:58 -0700 (PDT) Received: from mail.icu.ac.kr (mail.icu.ac.kr [210.107.128.31]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA14228 for ; Fri, 25 May 2001 01:22:56 -0600 (MDT) Received: from jkchoi (v33-170.icu.ac.kr [210.107.133.170]) by mail.icu.ac.kr (8.11.0/8.11.0) with SMTP id f4P7JgI24100 for ; Fri, 25 May 2001 16:19:42 +0900 (KST) Message-ID: <003e01c0e4eb$93833170$aa856bd2@jkchoi> From: "Jun Kyun Choi" To: References: <7B5C0390ACE7D211BC9C0008C7EABA2B03213B01@daeis07nok> Subject: Re: [mobile-ip] Timeslot requests for IETF51 Date: Fri, 25 May 2001 16:23:20 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f4P7Mqe04104 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit I would like to request to present Mobility Support using MPLS Technology for IETF 51 meeting. It will be based on the and . The current drafts will be updated before the London meeting Jun Kyun Choi Information & Communication University 58-4 Hwa Ahm Dong, Yusong, Taejon Korea 305-732 Tel) +82-42-866-6122, 011-397-1427 Fax) +82-42-866-6110 ----- Original Message ----- From: To: Sent: Friday, May 25, 2001 11:49 AM Subject: [mobile-ip] Timeslot requests for IETF51 > Resending it as I did not see it on the list.... > > Hello, > > If you would like to obtain a timeslot for presentations at the London IETF > (IETF51 5-10 August 2001), please send your requests to either Phil or me. > Please include the title of the I-D, time required, and also some reasons > why > the I-D is important for consideration by the Mobile IP WG. The deadline for > receiving requests for timeslots is : July 30th, 2001 > > -Basavaraj > > > > > From owner-mobile-ip@sunroof.eng.sun.com Fri May 25 09:05:54 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17067 for ; Fri, 25 May 2001 09:05:53 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA20561; Fri, 25 May 2001 07:05:45 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA16323; Fri, 25 May 2001 06:05:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4PD4i904484 for mobile-ip-dist; Fri, 25 May 2001 06:04:44 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4PD4fe04477 for ; Fri, 25 May 2001 06:04:41 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA16230 for ; Fri, 25 May 2001 06:04:43 -0700 (PDT) Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA20665 for ; Fri, 25 May 2001 06:04:43 -0700 (PDT) Received: by zcamail05.zca.compaq.com (Postfix, from userid 12345) id A777A85B; Fri, 25 May 2001 06:07:46 -0700 (PDT) Received: from exctay-gh03.tay.cpqcorp.net (exctay-gh03.tay.cpqcorp.net [16.103.129.53]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id 5128F80F for ; Fri, 25 May 2001 06:07:46 -0700 (PDT) Received: by exctay-gh03.tay.cpqcorp.net with Internet Mail Service (5.5.2652.78) id ; Fri, 25 May 2001 09:04:41 -0400 Message-ID: <88BD5A70CA8BFA4CA15D0ED053E49D69509565@tayexc14.americas.cpqcorp.net> From: "Powell, Ken" To: "'mobile-ip@sunroof.eng.sun.com'" Cc: "'T.J. Kniveton'" Subject: RE: [mobile-ip] draft-ietf-mobileip-ipv6-13: Trade-off in Mobile Prefix advertisements Date: Fri, 25 May 2001 09:04:31 -0400 X-Mailer: Internet Mail Service (5.5.2652.78) Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Your right, this comment applies more to draft 13. I see how using the term Mobile Prefix Advertisement instead of draft 13's router advertisement does cause confusion. Sorry about that. Ken > -----Original Message----- > From: T.J. Kniveton [mailto:TJ@Kniveton.com] > Sent: Thursday, May 24, 2001 10:29 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] draft-ietf-mobileip-ipv6-13: Trade-off in > Mobile Prefix advertisements > > > Thanks for your comments on the prefix issues, Ken. I must > admit that I > have been a bit slow to respond to mailing list mail- I've > been serving > on a jury which keeps me away from computers for most of the day. > > It looks like you are commenting on Draft 13 of the Mobile IPv6 spec > here, and of course the Mobile Prefix Advertisements do not > exist until > version 14, so it's a little difficult to comment on how they relate, > but I'll try to do so in a general way: > > In draft 13, there was a lot of rules for how to process > prefix changes > and disseminate this information to mobile nodes while away from home. > When I made changes to the draft, I tried to simplify these > rules, since > they require a fair bit of processing and state as you noted. > It was not > straight-forward to fully get rid of this, but I did try to reduce it. > > Do you have a specific problem with the changed set of > requirements, or > is it more of a problem with draft 13? > > -TJ > > "Powell, Ken" wrote: > > > > Vlad Yasevich and I were looking at the implementation impacts > > of draft-ietf-mobileip-ipv6-13 section 9.8.2. This section > > requires a home agent implementation build a list of changed > > prefixes and schedule an advertisement with just the changes > > when home network prefix information changes. In addition, > > section 9.8.3 requires that the changed prefixes be retransmitted > > until acked by a mobile node. This processing to support lists > > of changed prefixes will have to be performed independently for > > each mobile node, with perhaps thousands of mobile nodes on some > > home agents. > > > > We understand that the reason for sending only the changed prefix > > information instead of all prefix information is to reduce the > > connection costs for the mobile nodes on expensive wireless > > networks. Does the expected network cost savings justify the > > algorithm complexity that will be necessary to meet this > > requirement? > > > > We assume most home networks will have only 1 prefix, 2 during > > renumbering events. It will probably be very rare for any home > > network to have more than 4 prefixes even with multihoming. > > The prefix information on production networks are likely to change > > very infrequently. I expect no more than a few times in any given > > year. Do these assumptions sound correct? If so, we don't see how > > sending the unchanged prefixes will add any noticeable cost to the > > mobile node's connection. > > > > Ken > > -- > T.J. Kniveton > NOKIA Research > From owner-mobile-ip@sunroof.eng.sun.com Fri May 25 13:23:31 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21831 for ; Fri, 25 May 2001 13:23:30 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10446; Fri, 25 May 2001 11:23:24 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA19833; Fri, 25 May 2001 10:23:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4PHMDS04859 for mobile-ip-dist; Fri, 25 May 2001 10:22:13 -0700 (PDT) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4PHMBe04852 for ; Fri, 25 May 2001 10:22:11 -0700 (PDT) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA07869 for ; Fri, 25 May 2001 13:22:16 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id NAA06758 for mobile-ip@sunroof.eng.sun.com; Fri, 25 May 2001 13:22:33 -0400 (EDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4P8ree04195 for ; Fri, 25 May 2001 01:53:40 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA02585 for ; Fri, 25 May 2001 01:53:47 -0700 (PDT) Received: from mail.n016.co.kr ([203.229.169.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA24939 for ; Fri, 25 May 2001 02:53:45 -0600 (MDT) Received: from freenet.ktf.co.kr (freenet.ktf.co.kr [203.229.169.83]) by mail.n016.co.kr (v3smtp 8.11.3 Copyright (c) 1998-2001 Sendmail, Inc. All rights reserved. Copyright (c) 1988, 1993 The Regents of the University of California. All rights reserved./8.11.1) with ESMTP id f4P8oSQ23643; Fri, 25 May 2001 17:50:28 +0900 (KST) Received: from words ([10.6.10.174]) by freenet.ktf.co.kr (8.9.3/8.9.3) with SMTP id RAA25691; Fri, 25 May 2001 17:51:20 +0900 (KST) Message-ID: <00c601c0e4f8$a10733c0$ae0a060a@n016.co.kr> From: "Jiwoong Lee" To: Cc: Subject: [mobile-ip] [Q] Sending a packet to a BUed MN Date: Fri, 25 May 2001 17:56:46 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 8bit 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 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit All, MobileIPv6 recommneds the use of a routing header to send a packet to a Binding update requested mobile node. Because the document does not specify the use of routing header type, the correspondent node SHOULD be able to generate a different kind of routing header type which is NOT zero. I guess this statement is omitted intentionally. But why ? And what if the correspondent node wants loose source routing that is not for Mobile IP routing optimization and direct forwarding to the mobile node ? I believe section 8.9 of Mobile IPv6-13 should be reinforced tightly. Thank you for your upcoming answers including futurama. :> Jiwoong From owner-mobile-ip@sunroof.eng.sun.com Fri May 25 13:41:30 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22095 for ; Fri, 25 May 2001 13:41:29 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA17945; Fri, 25 May 2001 10:41:15 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA24107; Fri, 25 May 2001 10:41:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4PHe0504907 for mobile-ip-dist; Fri, 25 May 2001 10:40:00 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4PHdve04900 for ; Fri, 25 May 2001 10:39:57 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA03601 for ; Fri, 25 May 2001 10:40:03 -0700 (PDT) Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA25870 for ; Fri, 25 May 2001 11:40:00 -0600 (MDT) Received: by zcamail05.zca.compaq.com (Postfix, from userid 12345) id 818F1F90; Fri, 25 May 2001 10:43:04 -0700 (PDT) Received: from exctay-gh03.tay.cpqcorp.net (exctay-gh03.tay.cpqcorp.net [16.103.129.53]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id 32676C27 for ; Fri, 25 May 2001 10:43:03 -0700 (PDT) Received: by exctay-gh03.tay.cpqcorp.net with Internet Mail Service (5.5.2652.78) id ; Fri, 25 May 2001 13:39:58 -0400 Message-ID: <88BD5A70CA8BFA4CA15D0ED053E49D6950956A@tayexc14.americas.cpqcorp.net> From: "Powell, Ken" To: "'T.J. Kniveton'" Cc: "'dbj@cs.rice.edu'" , "'charliep@iprg.nokia.com'" , "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Mobile Prefix Advertisements (more comments) Date: Fri, 25 May 2001 13:39:46 -0400 X-Mailer: Internet Mail Service (5.5.2652.78) Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi T.J., > -----Original Message----- > From: T.J. Kniveton [mailto:TJ@Kniveton.com] > Sent: Thursday, May 24, 2001 11:09 PM > To: Powell, Ken > Cc: 'dbj@cs.rice.edu'; 'charliep@iprg.nokia.com'; > 'mobile-ip@sunroof.eng.sun.com' > Subject: Re: [mobile-ip] Mobile Prefix Advertisements (more comments) > > > "Powell, Ken" wrote: > > > > Hi T.J., > > > > Vlad Yasevich, Brian Haley, Greg Colburn and I > > finished our discussion of your proposal. This is the > > remainder of our comments. Many comments also apply > > to draft-ietf-mobileip-ipv6-13 without your changes > > as well. > > Thanks for your efforts! I will try and make some brief and immediate > comments, and please see my note at the end of the message as well. OK > > > > > Ken Powell > > Compaq Computer Corporation > > > > 5.8 Mobile Prefix Solicitation Message Format > > > > My comments to section 9.8.2 below request that only the prefixes > > that match a particular home registration be sent to the mobile > > node in Mobile Prefix Advertisements. If the binding has a zero > > prefix length, only the specific prefix for the mobile node's > > home address would be sent. For a bindings with a non-zero prefix > > length, all prefixes in the aggregate list would be sent. > > > > This left a problem, what prefixes do we send in response to a > > Router Solicitation? I think the home agent should use the > > Did you mean Mobile Prefix Solicitation here, or did you really mean > Router Solicitation? Oops, I meant Mobile Prefix Solicitation. > > > same prefix selection logic, but the mobile node needs a way to > > override this behavior to support initialization. One option is > > to add a flag to the Mobile Prefix Solicitation Message: > > > > + Send All Prefixes flag > > + > > + If clear, the home agent replies by sending only the prefixes > > + that match the mobile nodes home registration as defined in > > + section 9.8.2. If set, the home agent will send all prefixes > > + for the home network as defined in section 9.8.1. No prefixes > > + will be sent if this flag is clear and the mobile node does > > + not yet have a home registration. > > When the mobile node is initializing, the home agent would not have a > home registration to refer to for prefix length. It seems to > me that in > the case where the mobile node specifically requests prefixes, it is > probably best to give it all the prefixes on the home link served by > home agents. Can you elaborate on the benefits and > functionality allowed > by a "Send All Prefixes flag," aside from some posssible reduction in > M.P.A. length? I was thinking of a case where the mobile node detects that a home address is about to expire. It may be useful to send a Home Prefix Solicitation to get the current lifetime for that address. I agree that we don't need this flag. An alternative would be to send all prefixes in the aggregate list upon receipt of a home prefix solicitation, regardless of how (or if) the home registration was set up. This means that the mobile node might get some unnecessary junk at times, but it probably wouldn't be much. > > > > > 9.8.2 Sending Changed Prefix Information to the Mobile Node > > > > Due to the number of comments on this section, I'm including > > the entire text with ">" marks, and slicing in the comments > > where they apply. > > > > > A home agent serving a mobile node will schedule the delivery > > > of new prefix information to that mobile node when any of the > > > following conditions occur: > > > > Can the following list of MUST and MAY requirements be merged > > into the algorithm for sending prefix information below? > > > > > MUST: > > > - The valid or preferred lifetime or the state of the flags > > > changes for the prefix of the mobile node's registered home > > > address changes > > > - The mobile node requests the information with a Router > > > Solicitation (see section 10.16). > > > > > > MAY: > > > - A new prefix is added to the aggregate list > > > > Why is this a MAY instead of MUST? Is it to cover the case > > where a home registration has a zero prefix length? > > It is a may because I do not see it as essential for a mobile node, > which already has a home registration and presumably can use its > configured home address, to be able to configure additional home > addresses as the prefixes become available on the home network. It may > be possible to imagine a situation where the mobile node > *would* want to > immediately use these addresses, but it doesn't seem > important enough to > schedule a new M.P.A. just for this purpose. I disagree. I believe that when the home agent accepts a home registration with a non-zero prefix length, it must provide all prefix changes from the home network to the mobile node. Some mobile nodes may rely on this information and the home agent cannot predict which ones. For example, another node may get the mobile node's new address relatively quickly, perhaps through an A6 record in DNS, and try to initiate a connection to the mobile node. I agree that the timing for sending some changes can be delayed, but I don't think that it should be dependent on the prefix being used for the registered home address. That said, I think it would be reasonable for support of non-zero prefix lengths to be optional on home agents that are targeted at specific environments. For example, a home agent that only supports a mechanism for forwarding from a previous care-of address as described in section 10.9 wouldn't need to pass any other prefix information on to the mobile node. Any home agent that supports a mobile node's permanent home address on networks configured with stateless address autoconfiguration probably MUST support the non-zero prefix length. > > > > > > - The valid or preferred lifetime or the state of the flags > > > changes for a prefix which is not used in any binding cache > > > entry for this mobile node > > > > I don't understand what your trying to do with this > > last MAY requirement. It looks like its addressing a > > problem I've been wondering about. A mobile node with > > multiple home addresses could either > > > > o establish a single binding with a non-zero prefix > > length to cover all its home addresses, or > > > > o establish multiple bindings each with a zero prefix > > length to cover a single home address. > > Couldn't it establish multiple bindings, each with a non-zero prefix > length? That would be what I would expect to happen, since the key is > the home address, not the care-of address. That is to say, it > would seem > valid to have multiple home addresses each registered (and > prefix length > noted), pointing to the same care-of address. Good point, but establishing multiple bindings should be the exception rather than the common case to reduce overhead. The mobile node should select one address to be its registered home address. During renumbering events and possibly other occasions, a mobile node may need to change the address it uses for a home registration. It makes sense to allow both the old and the new home registration to exist at the same time to support a smooth transition. I assume the home agent may forward any message addressed to any of the mobile node's home addresses to either care-of address in this situation? > > > > > In the latter case, how does the home agent recognize > > that a single node has multiple bindings? I believe the > > home agent should avoid sending duplicate home prefix > > advertisements to the mobile node. > > Ah, I see what you're getting at. Well, I would first try to > sort by the > care-of address; I think we should leave the door open for multiple nodes to share the same care-of address. Such a capability may prove handy for some future requirement. Therefore, I think it would be a mistake to assume two bindings with the same care-of address apply to the same node. > however, the mobile node could have a > different care-of > address for each home address as well. In that case, it seems much > harder to tell when multiple bindings are the same machine. However, I > do not think that registering a zero prefix length would be the best > solution at this time. I agree for the mobile node's permanent home network. However, section 10.9 "Establishing Forwarding from a Previous Care-of Address" describes a situation where the mobile node sets up its old care-of address as a temporary home address. I see no reason to use a non-zero prefix length with the temporary home addresses. > > > > > One way to fix this is to have the home agent to only > > send prefix information that is applicable to a specific > > binding. Is that what your additional requirement was > > after? If so, I agree with the intent, but believe more > > detail is needed. Perhaps a statement like the following > > would help at the start of this section: > > > > + A home agent normally sends only the prefixes that match > > + a mobile node's home registration to the mobile node. A > > + match exists if the home registration's home address > > + contains a prefix or if the home registration's prefix > > + length field is non-zero. Each home registration entry > > + in the binding cache MUST be treated as if it were > > + created for a separate mobile node. > > I thought this was clear from the text - perhaps it is clearer in the > newer revision. Let's follow this up further. OK > > > > > - For any existing prefix, if the mobile node's binding expires > > > before the advertised Preferred Lifetime, do not schedule the > > > advertisement. The mobile node will get the revised > information > > > in its next Binding Acknowledgement. > > > > This is covered in the RAND_ADV_DELAY scheduling algorithm below. > > Can we remove it from here to simplify the text? > > > > > - If a prefix is added, or if it changes in any way that does not > > > ============= > > > cause the mobile node's address to go deprecated, ensure that a > > > ================================================ > > > transmission is scheduled at time RAND_ADV_DELAY in the future. > > > > Same comment as before, do we need the special case text that is > > underlined? Also, this probably should be qualified to be more > > precise. > > > > + - If a prefix in the aggregate list that matches the > mobile node's > > + home registration is added or its information changes, > ensure that > > + a transmission is scheduled at time RAND_ADV_DELAY in > the future. > > It's not clear to me how a prefix could be *added* that matches the > mobile node's home registration - wouldn't it have to be in > the list for > the home registration to be accepted initially? I defined "match" as "A match exists if the home registration's home address contains a prefix or if the home registration's prefix length field is non-zero." Therefore, this particular case would happen when there is a non-zero prefix length on the home registration and some router advertises a new prefix on the home network. > > > > > > - If a prefix advertisement is scheduled, and a Binding Update > > > arrives, perform that advertisement and include the information > > > in a Router Advertisement that has the Binding > Acknowledgement as > > > ==================== > > > a Destination Option. Remove the future scheduled > advertisement. > > > > Did you mean Mobile Prefix Advertisement here? > Yes, there seems to be some intermixing of the terms, but I assure you > that I did a query-replace in draft 14 :) > > > > > Is it really necessary to send the Binding Acknowledgement in the > > same message as the Mobile Prefix Advertisement? I suspect this > > will be awkward to implement given that Binding > Acknowledgements are > > probably handled in the kernel and Mobile Prefix Advertisements > > in a daemon. > > I guess it depends on the implementation - it should be > possible for the > kernel to grab the binding ack off the packet before it gets to user > space, no? I was more concerned about the send side on the home agent. I envision implementing binding option processing in the kernel and home prefix message handling in a daemon. When the binding update arrives on the home agent, it is processed in the kernel. The kernel could easily send a binding ack immediately and signal the daemon that an update arrived. The daemon then performs its mobile prefix processing and sends the mobile prefix advertisement independently if needed. The part that gets awkward is the requirement for the kernel to synchronize sending the ack with the daemon's home prefix advertisement. I see no reason to send the ack on the advertisement other than to reduce message overhead. The ack could be piggybacked on any message sent to the mobile node. > > > > > If the mobile node's binding expires after the Preferred > Lifetime, > > > then compute > > > > The indentation following this text could be interpreted to mean > > we still need to compute RAND_ADV_DELAY even when the IF > condition > > here is false. As an alternative, perhaps a rewording of this IF > > clause combined with text from above would be helpful. > > > > + If the mobile node's binding expires before the > Preferred Lifetime, > > + then return. The mobile node will get the revised information > > + with its next Binding Acknowledgement. Otherwise, > continue with the > > + following computation: > > > > > MAX_SCHEDULE_DELAY == > > > min (MAX_PFX_ADV_DELAY, Preferred Lifetime) > > > > > > for the newly advertised Preferred Lifetime. > > > Then compute RAND_ADV_DELAY = > > > MinRtrAdvInt + rand()*(MAX_SCHEDULE_DELAY - MinRtrAdvInt) > > > > There may be a problem overwhelming system or network resources > > if the scheduling algorithm causes the home agent to transmit a > > home prefix advertisement to all mobile nodes at the same time. > > The spec should allow a mechanism to avoid this. > > Yes, even with rewording this, there are conditions which > could trigger > similar unwanted flooding. We need to think of ways to avoid this. > > > > > + A home agent SHOULD perform scheduling of advertisements > > + described in this section independently for each home > > + registration in the binding cache to avoid a burst of > > + advertisements being sent to all mobile nodes at the same time. > > + In addition, a home agent MAY throttle transmission of > > + advertisements to prevent overwhelming local resources when > > + the rules above require immediate transmission of advertisements > > + to large numbers of mobile nodes. > > Sounds like a good start. We intentionally left the mechanisms vague. We figured the requirements will probably be driven more by the capabilities of each implementation and their intended environments than by anything else. > > > > > [Delete this paragraph? This is also too much.] > > > Whenever a mobile node has a valid binding on a network other > > > than its home network, the home agent MUST send a Mobile Prefix > > > Advertisement with all prefixes in the aggregate list to the > > > mobile node at least once per HomeRtrAdvInterval seconds, and > > > upon receipt of a valid Router Solicitation from the mobile > > > node. > > > > I have no idea what "a network other than its home network" > > means, but I think a requirement to periodically transmit > > all prefixes is needed because home addresses on mobile nodes > > still have a finite lifetime that will expire unless > > periodically updated. As I stated above, I think this requirement > > fits better in section 9.8.2. > > > > Section 10.16 Sending Mobile Prefix Solicitations > > > > > The mobile node SHOULD send a Solicitation to the home agent > > > when its home address will become invalid within > MaxRtrAdvInterval > > > seconds, where this value is acquired in a previous Router > > > Advertisement from the home agent. ... ====== > > ============= > > > > Should this be Mobile Prefix Advertisement? > > > > > If the mobile node does not have a valid home address > available for > > > use as the IP source address, it MAY use its care-of > address, [but > > > there will not be a security association between the > Home Agent and > > > the care-of address for the corresponding Advertisement to be > > > authenticated.] > > > > We think some kind of security association will be needed here. > > Yes, the security issues are probably the most unresolved, and I have > left room in draft 14 for a security association based on IPsec to > continue to exist, but I have many question marks on this issue. Same here. > > > > > Section 10.17 Receiving Mobile Prefix Advertisements > > > > > - The Source Address of the IP packet carrying the Router > > > Advertisement is ..... ====== > > ============= > > > > Should this be Mobile Prefix Advertisement? > > I believe the version of the document you are working with > did not have > all the terminology fleshed out. Ya, I'm not surprised that you cleaned up a few things since I grabbed your changes. It's been quite a while. > This looks good. Thanks for all of your comments. Since there > were some > more changes, which I alluded to, between the time I sent you the text > version you made comments on, and the updated (but not yet 14) draft > Charlie posted a link to yesterday, it might be best if we > compare your > comments to that. Did you post the changes at the same location as before? > > It would be ideal for us to just talk about this face to face, since > there are some difficult issues which are hard to fully discuss via > e-mail. I'd like to also point out (to everyone) that this section, or > at least as it relates to renumbering, and the changes I made > to it are > still in what I would call a "research" stage; that is to > say, there is > room for change before it will be mature and fully usable. So let's > continue to improve it and comments are still welcome even after draft > 14 is submitted. > > Thanks, > > -- > T.J. Kniveton > NOKIA Research > From owner-mobile-ip@sunroof.eng.sun.com Mon May 28 06:39:25 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA02875 for ; Mon, 28 May 2001 06:39:24 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA24323; Mon, 28 May 2001 04:39:33 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA25075; Mon, 28 May 2001 03:39:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4SAc2g07155 for mobile-ip-dist; Mon, 28 May 2001 03:38:02 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4SAbxe07148 for ; Mon, 28 May 2001 03:37:59 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA26935 for ; Mon, 28 May 2001 03:38:05 -0700 (PDT) Received: from netdns.netas.com.tr ([195.142.217.254]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA23026 for ; Mon, 28 May 2001 04:37:58 -0600 (MDT) Received: from netas.com.tr (47.165.145.36 [47.165.145.36]) by netdns.netas.com.tr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KW3GY2BZ; Mon, 28 May 2001 13:36:24 +0300 Message-ID: <3B122BB0.E1DADB5@netas.com.tr> Date: Mon, 28 May 2001 13:42:57 +0300 From: Oner Tekin X-Mailer: Mozilla 4.61 [en] (X11; U; HP-UX B.10.20 9000/712) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Mobile IPv6 simulation tool? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, Do you know any simulator which supports to MobileIPv6? Thanks in advance. Best regards. Oner Tekin. From owner-mobile-ip@sunroof.eng.sun.com Mon May 28 06:55:10 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA03077 for ; Mon, 28 May 2001 06:55:10 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA21454; Mon, 28 May 2001 03:55:18 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA25618; Mon, 28 May 2001 03:55:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4SArjn07184 for mobile-ip-dist; Mon, 28 May 2001 03:53:45 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4SArfe07177 for ; Mon, 28 May 2001 03:53:41 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA02430 for ; Mon, 28 May 2001 03:53:47 -0700 (PDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA28792 for ; Mon, 28 May 2001 03:53:46 -0700 (PDT) Received: from inrialpes.fr (galibier.inrialpes.fr [194.199.24.97]) by ebene.inrialpes.fr (8.9.3+Sun/8.8.6) with ESMTP id MAA23658; Mon, 28 May 2001 12:52:19 +0200 (MEST) Message-ID: <3B122E38.AFAF5EE2@inrialpes.fr> Date: Mon, 28 May 2001 12:53:44 +0200 From: Thierry Ernst Organization: INRIA Rhone-Alpes X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com, Oner Tekin Subject: Re: [mobile-ip] Mobile IPv6 simulation tool? References: <3B122BB0.E1DADB5@netas.com.tr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Oner Tekin wrote: > Do you know any simulator which supports to MobileIPv6? I do have one. We have (MOTORLA Labs and INRIA Rhone Alpes Project PLANETE) have developped NS-2.1b6 extensions to support Mobile IPv6 - it is not yet contributed to the NS distribution suite, but we will do it very recently. Please contact me if you are interested. Thierry. -- * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) * and MOTOROLA Labs Paris * http://www.inrialpes.fr/planete/people/ernst/Welcome.html From owner-mobile-ip@sunroof.eng.sun.com Mon May 28 09:38:03 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04519 for ; Mon, 28 May 2001 09:38:02 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAB05392; Mon, 28 May 2001 07:38:15 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA12669; Mon, 28 May 2001 06:38:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4SDZ7S07296 for mobile-ip-dist; Mon, 28 May 2001 06:35:07 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4SDZ3e07289 for ; Mon, 28 May 2001 06:35:03 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA02960 for ; Mon, 28 May 2001 06:34:41 -0700 (PDT) Received: from mercury.ukc.ac.uk (mercury.ukc.ac.uk [129.12.21.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA02733 for ; Mon, 28 May 2001 06:34:29 -0700 (PDT) Received: from pelican.ukc.ac.uk ([129.12.200.26]) by mercury.ukc.ac.uk with esmtp (Exim 3.22 #4) id 154NA7-0005Y3-00; Mon, 28 May 2001 14:34:23 +0100 Received: from pccomm4.ukc.ac.uk ([129.12.50.119] helo=ukc.ac.uk) by pelican.ukc.ac.uk with esmtp (Exim 3.22 #3) id 154NAC-0001wn-00; Mon, 28 May 2001 14:34:28 +0100 Message-ID: <3B1253E3.559F51FC@ukc.ac.uk> Date: Mon, 28 May 2001 14:34:27 +0100 From: Kumarendra Sivarajah X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "mobile-ip@sunroof.eng.sun.com" , ipng Subject: [mobile-ip] Books on QoS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, Can someone suggest me a good book for measuring QoS in an IP network. Else a webpage with good resources. Thanks INdran -- /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \ Kumarendra Sivarajah (INdran) / / Electronics Engineering Laboratory \ \ University of Kent at Canterbury / / Telephone(Office): +44 (0)1227 823257 \ \ Telephone(Mobile): +44 (0)7765 007016 / \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ From owner-mobile-ip@sunroof.eng.sun.com Mon May 28 11:53:48 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05525 for ; Mon, 28 May 2001 11:53:48 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00658; Mon, 28 May 2001 09:54:03 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA20607; Mon, 28 May 2001 08:53:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4SFqtq07390 for mobile-ip-dist; Mon, 28 May 2001 08:52:55 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4SFqpe07383 for ; Mon, 28 May 2001 08:52:51 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA20521 for ; Mon, 28 May 2001 08:52:58 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA08871 for ; Mon, 28 May 2001 08:52:58 -0700 (PDT) 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 IAA17991 for ; Mon, 28 May 2001 08:52:58 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f4SFqrW30515 for ; Mon, 28 May 2001 08:52:53 -0700 X-mProtect: Mon, 28 May 2001 08:52:53 -0700 Nokia Silicon Valley Messaging Protection Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdRrPplY; Mon, 28 May 2001 08:52:50 PDT Message-ID: <3B127454.614D172C@iprg.nokia.com> Date: Mon, 28 May 2001 08:52:52 -0700 From: Theo Pagtzis Organization: UCL/NOKIA X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386) X-Accept-Language: el, en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile IPv6 simulation tool? References: <3B122BB0.E1DADB5@netas.com.tr> <3B122E38.AFAF5EE2@inrialpes.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thierry Ernst wrote: > Oner Tekin wrote: > > Do you know any simulator which supports to MobileIPv6? > > I do have one. > We have (MOTORLA Labs and INRIA Rhone Alpes Project PLANETE) have > developped NS-2.1b6 extensions to support Mobile IPv6 - it is not yet > contributed to the NS distribution suite, but we will do it very > recently. > > Please contact me if you are interested. > > Thierry. > > -- > * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 > * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) > * and MOTOROLA Labs Paris > * http://www.inrialpes.fr/planete/people/ernst/Welcome.html Hi Thierry, I would also be interested in this. Would it be possible to get hold of such a copy? Thanks Theo From owner-mobile-ip@sunroof.eng.sun.com Mon May 28 20:42:14 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08365 for ; Mon, 28 May 2001 20:42:13 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA27145; Mon, 28 May 2001 18:42:27 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA10352; Mon, 28 May 2001 17:42:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4T0fK807767 for mobile-ip-dist; Mon, 28 May 2001 17:41:20 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4T0fFe07760 for ; Mon, 28 May 2001 17:41:15 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA05583 for ; Mon, 28 May 2001 17:41:23 -0700 (PDT) Received: from mail.n016.co.kr ([203.229.169.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA17510 for ; Mon, 28 May 2001 18:41:44 -0600 (MDT) Received: from freenet.ktf.co.kr (freenet.ktf.co.kr [203.229.169.83]) by mail.n016.co.kr (v3smtp 8.11.3 Copyright (c) 1998-2001 Sendmail, Inc. All rights reserved. Copyright (c) 1988, 1993 The Regents of the University of California. All rights reserved./8.11.1) with ESMTP id f4T0bMQ26903 for ; Tue, 29 May 2001 09:37:23 +0900 (KST) Received: from words ([10.6.10.174]) by freenet.ktf.co.kr (8.9.3/8.9.3) with SMTP id JAA27987 for ; Tue, 29 May 2001 09:38:18 +0900 (KST) Message-ID: <00dd01c0e7d8$745bcf60$ae0a060a@n016.co.kr> From: "Jiwoong Lee" To: Subject: [mobile-ip] MN's packet reception Date: Tue, 29 May 2001 09:44:01 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 8bit 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 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit All, Becasue CN's requirement to use Binding Cache when it sends a packet to MN is "SHOULD", the corresponding possibilities in which a MN receives a packet while away from home also should be described legitimately. A MN MAY receive a packet addressed to its home address, which is sent by a CN that DOES have a Binding Cache entry for the MN, if the CN does NOT like to use Routing Header. Jiwoong -- 8.9. Sending Packets to a Mobile Node Before sending any packet, the sending node SHOULD examine its Binding Cache for an entry for the destination address to which the packet is being sent. If the sending node has a Binding Cache entry for this address, the sending node SHOULD use a Routing header to route the packet to this mobile node (the destination node) by way of the care-of address in the binding recorded in that Binding Cache entry. ... 10.3. Receiving Packets While Away from Home While away from home, a mobile node will receive packets addressed to its home address, by one of three methods: - Packets sent by a correspondent node that does not have a Binding Cache entry for the mobile node, will be sent by the correspondent node in the same way as any normal IP packet. Such packets will then be intercepted by the mobile node's home agent, encapsulated using IPv6 encapsulation [4], and tunneled to the mobile node's primary care-of address. ... From owner-mobile-ip@sunroof.eng.sun.com Tue May 29 00:41:14 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA11760 for ; Tue, 29 May 2001 00:41:13 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA22152; Mon, 28 May 2001 22:41:23 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA22945; Mon, 28 May 2001 21:41:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4T4eIL07933 for mobile-ip-dist; Mon, 28 May 2001 21:40:18 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4T4eEe07926 for ; Mon, 28 May 2001 21:40:15 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA28634 for ; Mon, 28 May 2001 21:40:23 -0700 (PDT) Received: from mail.ict.ac.cn ([159.226.39.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id WAA18071 for ; Mon, 28 May 2001 22:40:47 -0600 (MDT) Received: (qmail 4484 invoked from network); 29 May 2001 04:35:27 -0000 Received: from unknown (HELO ken) (159.226.39.72) by 159.226.39.4 with SMTP; 29 May 2001 04:35:27 -0000 Message-ID: <002e01c0e7f9$f5fa7a00$4827e29f@ken> From: "ken" To: References: <3B122BB0.E1DADB5@netas.com.tr> <3B122E38.AFAF5EE2@inrialpes.fr> <3B127454.614D172C@iprg.nokia.com> Subject: Re: [mobile-ip] Mobile IPv6 simulation tool? Date: Tue, 29 May 2001 12:43:39 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f4T4eFe07927 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit mamahuhu ----- Original Message ----- From: "Theo Pagtzis" To: Sent: Monday, May 28, 2001 11:52 PM Subject: Re: [mobile-ip] Mobile IPv6 simulation tool? > Thierry Ernst wrote: > > > Oner Tekin wrote: > > > Do you know any simulator which supports to MobileIPv6? > > > > I do have one. > > We have (MOTORLA Labs and INRIA Rhone Alpes Project PLANETE) have > > developped NS-2.1b6 extensions to support Mobile IPv6 - it is not yet > > contributed to the NS distribution suite, but we will do it very > > recently. > > > > Please contact me if you are interested. > > > > Thierry. > > > > -- > > * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 > > * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) > > * and MOTOROLA Labs Paris > > * http://www.inrialpes.fr/planete/people/ernst/Welcome.html > > Hi Thierry, > > I would also be interested in this. Would it be possible to get hold > of such a copy? > > Thanks > > > Theo > > > From owner-mobile-ip@sunroof.eng.sun.com Tue May 29 15:24:11 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09643 for ; Tue, 29 May 2001 15:24:10 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA08334; Tue, 29 May 2001 13:24:24 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA15183; Tue, 29 May 2001 12:24:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4TJNBQ09012 for mobile-ip-dist; Tue, 29 May 2001 12:23:11 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4TJN8e09005 for ; Tue, 29 May 2001 12:23:08 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA10339 for ; Tue, 29 May 2001 12:23:11 -0700 (PDT) Received: from exch-connector.netcomsystems.com ([12.9.24.195]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21559 for ; Tue, 29 May 2001 12:23:10 -0700 (PDT) Received: by exch-connector.netcomsystems.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 May 2001 12:23:10 -0700 Message-ID: <9384475DFC05D2118F9C00805F6F26310637A31F@exchange1.netcomsystems.com> From: "Mason, Brian" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Mobile IPv6 simulation tool? Date: Tue, 29 May 2001 12:23:07 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I am not sure what type of simulator you are looking for but Spirent has a MIPv4 application that simulates 500 mobile nodes to a Mobile IP network and does measurements such as registration time, registration capacity, frame loss and handover time and we are working on a MIPv6 application to do the same type of simulation. The MIPv6 is in alpha format but if you are interested we could try to work something out. Let me know if you are interested, Brian ----- Original Message ----- From: "Theo Pagtzis" To: Sent: Monday, May 28, 2001 11:52 PM Subject: Re: [mobile-ip] Mobile IPv6 simulation tool? > Thierry Ernst wrote: > > > Oner Tekin wrote: > > > Do you know any simulator which supports to MobileIPv6? > > > > I do have one. > > We have (MOTORLA Labs and INRIA Rhone Alpes Project PLANETE) have > > developped NS-2.1b6 extensions to support Mobile IPv6 - it is not yet > > contributed to the NS distribution suite, but we will do it very > > recently. > > > > Please contact me if you are interested. > > > > Thierry. > > > > -- > > * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 > > * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) > > * and MOTOROLA Labs Paris > > * http://www.inrialpes.fr/planete/people/ernst/Welcome.html > > Hi Thierry, > > I would also be interested in this. Would it be possible to get hold > of such a copy? > > Thanks > > > Theo > > > From owner-mobile-ip@sunroof.eng.sun.com Tue May 29 17:51:19 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11770 for ; Tue, 29 May 2001 17:51:18 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA13523; Tue, 29 May 2001 15:51:33 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA23112; Tue, 29 May 2001 14:51:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4TLmrC09526 for mobile-ip-dist; Tue, 29 May 2001 14:48:53 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4TLmme09519; Tue, 29 May 2001 14:48:49 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA26579; Tue, 29 May 2001 14:48:42 -0700 (PDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA16608; Tue, 29 May 2001 14:48:40 -0700 (PDT) Received: from inrialpes.fr (galibier.inrialpes.fr [194.199.24.97]) by ebene.inrialpes.fr (8.9.3+Sun/8.8.6) with ESMTP id XAA08453; Tue, 29 May 2001 23:47:12 +0200 (MEST) Message-ID: <3B141937.CF8A72CA@inrialpes.fr> Date: Tue, 29 May 2001 23:48:39 +0200 From: Thierry Ernst Organization: INRIA Rhone-Alpes X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com, Mobile IP Subject: [mobile-ip] Re: [Q] Routing header References: <001d01c0e3e7$fcbd7880$ae0a060a@n016.co.kr> <20010525065204O.kimai@flab.fujitsu.co.jp> <009f01c0e4f2$c69a6680$ae0a060a@n016.co.kr> <15124.160.67957.34034@thomasm-u1.cisco.com> <15124.4243.705476.836130@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi all, I have cc to the MIP WG because I think this discussion falls in its interest. Michael Thomas wrote: > Steve Deering writes: > > At 1:03 PM -0700 5/29/01, Michael Thomas wrote: > > > Where there is ambiguity, however, is in the host's construction > > > of the routing header. Consider the situation where you have a > > > mobile host behind a mobile router, each of which send binding > > > updates to a correspondent node. How does the correspondent > > > node know which order to put the routing headers in? > > > > Mike, > > > > You'll have to spend more time educating me on the details of the > > scenario you have in mind. I would hope and expect that some > > encapsulation/decapsulation is going on at the mobile router, > > in which case you might have one routing header as part of the > > inner (encapsulated) packet, and one routing header as part of > > the outer (encapsulating) packet, > > I don't think there are any answers for this at > within mipv6. This case was never really considered so far in any of the MIP specs. There is no answer to this specific case for the reason that mobile networks are not explicitly addressed in any of the WG specs (indeed, HMIPv6 which is a WG item does have a word about this and in this case the CN wouldn't endup with 2 BUs). > > which is a different case than > > having multiple routing headers in a single extension-header > > chain. I was assuming the question applied to the latter case, > > though the semantics of encapsulation case is also obvious. > > This is mostly a mipv6 issue, but suppose you have: > > MN------->MR------------------------>CN > > When the mobile node moves, it sends a BU to the CN. > When the mobile router moves, it too sends a BU to the CN. This is only your scenario. You could think of any scenario you want. Anyway, this is something I have already raised in the MIP WG and this is presumably a case where MIPv6 would fail. > The CN now has a binding entry for both the mobile node > and the mobile router in its cache. Now if this > is going to work at all (which I think is the $64 > "if") CN would need to construct a packet like: But, first, why should the CN get two BUs ? The CN is not a CN for the MR. Unless you refer to my draft http://www.inrialpes.fr/planete/people/ernst/Documents/draft-ernst-mobileip-v6-network.txt which proposes that the MR be in charge of all the mobility management of the mobile network. But this is just a proposition, and it mainly focus on the case where the nodes behind the router wired and fixed nodes, not mobile nodes. Then, your issue is rather a proposal for a solution, and it would be better if you could first specify your solution, this would highly highlight the issue you are trying to discuss. > > IP: dst=CoA(mr); RH: dst=CoA(mn); RH: dst=Home(mn); > > to prevent the packet from going through the > home agent of either the MN or MR. > > Yet, MN and MR might know nothing about each > other (the general case, I'd think) and CN > doesn't have any clue about the far end > topology either. It just has two binding > entries in its binding cache with no way > to correlate them, let alone set the proper > ordering. > > > In the absence of such specs, the Routing header contents will just > > continue to be provided manually, as in source-routed pings and > > traceroutes. > > Yes, I should make it clear that this isn't a > ipng ambiguity. > > Mike > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) * and MOTOROLA Labs Paris * http://www.inrialpes.fr/planete/people/ernst/Welcome.html From owner-mobile-ip@sunroof.eng.sun.com Tue May 29 17:56:19 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11857 for ; Tue, 29 May 2001 17:56:18 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA18043; Tue, 29 May 2001 15:56:33 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA24398; Tue, 29 May 2001 14:55:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4TLssX09574 for mobile-ip-dist; Tue, 29 May 2001 14:54:54 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4TLsoe09567; Tue, 29 May 2001 14:54:50 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA20042; Tue, 29 May 2001 14:54:57 -0700 (PDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA14306; Tue, 29 May 2001 15:55:21 -0600 (MDT) Received: from inrialpes.fr (galibier.inrialpes.fr [194.199.24.97]) by ebene.inrialpes.fr (8.9.3+Sun/8.8.6) with ESMTP id XAA08553; Tue, 29 May 2001 23:53:26 +0200 (MEST) Message-ID: <3B141AAD.FCB0F4D6@inrialpes.fr> Date: Tue, 29 May 2001 23:54:53 +0200 From: Thierry Ernst Organization: INRIA Rhone-Alpes X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 CC: ipng@sunroof.eng.sun.com, Mobile IP Subject: [mobile-ip] Re: [Q] Routing header References: <001d01c0e3e7$fcbd7880$ae0a060a@n016.co.kr> <20010525065204O.kimai@flab.fujitsu.co.jp> <009f01c0e4f2$c69a6680$ae0a060a@n016.co.kr> <15124.160.67957.34034@thomasm-u1.cisco.com> <15124.4243.705476.836130@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Steve Deering wrote: > Last time I looked, the Mobile IPv6 spec dealt with mobile hosts only, > not mobile routers. If that's still true, it's unsurprising that > it doesn't handle your scenario -- that would be the responsibility > of a (future) Mobile IPv6 Router spec. Steve, you are perfectly right - mobile routers and networks is not yet a MIP WG item and the charter has never pretended to address this issue. May be it's time for it now. What does the MIP WG think about this ? Any vote for it to be included in the charter for the next meeting ? > Presumably, to make this work, the BU from the mobile router to the CN > would have to include the address prefix(es) reachable via the mobile > router (i.e., the mobile subnet or larger aggregate that the mobile > router is supposed to serve). With that info, the CN would be able to > tell that the mobile host address falls within the address block served > by the mobile router, and could build the necessary header chain. This is basically what my draft is proposing. And in this case, the MIPv6 spec needs redefine the "CN Operation". (all is in the draft http://www.inrialpes.fr/planete/people/ernst/Documents/draft-ernst-mobileip-v6-network.txt) But there is an authorization issue that needs to be addressed as everyone knows. Thierry. -- * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) * and MOTOROLA Labs Paris * http://www.inrialpes.fr/planete/people/ernst/Welcome.html From owner-mobile-ip@sunroof.eng.sun.com Tue May 29 18:56:12 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12383 for ; Tue, 29 May 2001 18:56:12 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA22565; Tue, 29 May 2001 15:56:20 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA14918; Tue, 29 May 2001 15:55:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4TMsgT09777 for mobile-ip-dist; Tue, 29 May 2001 15:54:42 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4TMroe09758; Tue, 29 May 2001 15:53:50 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA10283; Tue, 29 May 2001 15:53:57 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA01587; Tue, 29 May 2001 16:53:55 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f4TMrvU02329; Tue, 29 May 2001 15:53:57 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AHF08488; Tue, 29 May 2001 15:53:53 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA07604; Tue, 29 May 2001 15:53:53 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15124.10369.456683.719389@thomasm-u1.cisco.com> Date: Tue, 29 May 2001 15:53:53 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Cc: ipng@sunroof.eng.sun.com Subject: [mobile-ip] Re: [Q] Routing header In-Reply-To: <3B141937.CF8A72CA@inrialpes.fr> References: <001d01c0e3e7$fcbd7880$ae0a060a@n016.co.kr> <20010525065204O.kimai@flab.fujitsu.co.jp> <009f01c0e4f2$c69a6680$ae0a060a@n016.co.kr> <15124.160.67957.34034@thomasm-u1.cisco.com> <15124.4243.705476.836130@thomasm-u1.cisco.com> <3B141937.CF8A72CA@inrialpes.fr> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thierry Ernst writes: > > This is mostly a mipv6 issue, but suppose you have: > > > > MN------->MR------------------------>CN > > > > When the mobile node moves, it sends a BU to the CN. > > When the mobile router moves, it too sends a BU to the CN. > > This is only your scenario. You could think of any scenario you want. > Anyway, this is something I have already raised in the MIP WG and this > is presumably a case where MIPv6 would fail. I'm aware that this is only my scenario, but this is what I think a naive implementation would do. Ie, the mobile router would think it's supposed to send a BU when it see something come in from its home agent tunnel interface, the MN (or another MR) would think it's supposed to send a BU... > > The CN now has a binding entry for both the mobile node > > and the mobile router in its cache. Now if this > > is going to work at all (which I think is the $64 > > "if") CN would need to construct a packet like: > > But, first, why should the CN get two BUs ? The CN is not a CN for the > MR. If the MR subtends a prefix and can send a BU which is legal in -13 as you know, it would send a BU when it sees the packet on the HA interface. Otherwise, you'd have triangular routing at the MR. Unless you refer to my draft > http://www.inrialpes.fr/planete/people/ernst/Documents/draft-ernst-mobileip-v6-network.txt > which proposes that the MR be in charge of all the mobility management > of the mobile network. Well, I think that we probably need to look at the induction from 1 to n otherwise the diagrams keep getting harder to parse each time we have to go through this :-) > Then, your issue is rather a proposal for a solution, and it would be > better if you could first specify your solution, this would highly > highlight the issue you are trying to discuss. I'm not trying to propose anything, actually. I'm just pointing out that the current set of drafts won't work as they are currently stated to more than one level of mobility. Mike From owner-mobile-ip@sunroof.eng.sun.com Wed May 30 02:06:21 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA28567 for ; Wed, 30 May 2001 02:06:20 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA17304; Wed, 30 May 2001 00:06:32 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA10771; Tue, 29 May 2001 23:06:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4U65BC10184 for mobile-ip-dist; Tue, 29 May 2001 23:05:11 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4U657e10177; Tue, 29 May 2001 23:05:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA01902; Tue, 29 May 2001 23:05:14 -0700 (PDT) Received: from mail.n016.co.kr ([203.229.169.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA05321; Wed, 30 May 2001 00:05:37 -0600 (MDT) Received: from freenet.ktf.co.kr (freenet.ktf.co.kr [203.229.169.83]) by mail.n016.co.kr (v3smtp 8.11.3 Copyright (c) 1998-2001 Sendmail, Inc. All rights reserved. Copyright (c) 1988, 1993 The Regents of the University of California. All rights reserved./8.11.1) with ESMTP id f4U5xRQ21750; Wed, 30 May 2001 14:59:27 +0900 (KST) Received: from words ([10.6.10.174]) by freenet.ktf.co.kr (8.9.3/8.9.3) with SMTP id PAA01664; Wed, 30 May 2001 15:00:24 +0900 (KST) Message-ID: <005e01c0e8ce$9f962c60$ae0a060a@n016.co.kr> From: "Jiwoong Lee" To: Cc: References: <00dd01c0e7d8$745bcf60$ae0a060a@n016.co.kr> Subject: Re: [mobile-ip] MN's packet reception Date: Wed, 30 May 2001 15:06:10 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 8bit 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 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit All In addtion to the original mail, I suggest to remove the last subordinate clause (*) starting with "as if.." of the below paragraph in MobileIPv6-13, because [1] Generic Packet Tunneling in IPv6 spec does not state that kind of statement and [2] the MN's BU condition (#) seems to be outof accord with (*), perhaps from the view point of implementation. comment please. Jiwoong For packets received by either the first or last of these three methods, the mobile node SHOULD send a Binding Update to the original sender of the packet, as described in Section 10.8, subject to the rate limiting defined in Section 10.11. The mobile node SHOULD also process the received packet in the manner defined for IPv6 encapsulation [4], which will result in the encapsulated (inner) packet being processed normally by upper-layer protocols within the mobile node, (*)as if it had been addressed (only) to the mobile node's home address. and In addition, when a mobile node receives a packet for which the mobile node can deduce that the original sender of the packet has no Binding Cache entry for the mobile node, or for which the mobile node can deduce that the original sender of the packet has an out-of-date care-of address for the mobile node in its Binding Cache, the mobile node SHOULD return a Binding Update to the sender giving its current care-of address (subject to the rate limiting defined in Section 10.11). In particular, the mobile node SHOULD return a Binding Update in response to receiving a packet that meets all of the following tests: (#) - The packet was tunneled using IPv6 encapsulation. ... ----- Original Message ----- From: "Jiwoong Lee" To: Sent: Tuesday, May 29, 2001 9:44 AM Subject: [mobile-ip] MN's packet reception > All, > > Becasue CN's requirement to use Binding Cache when it sends > a packet to MN is "SHOULD", the corresponding possibilities > in which a MN receives a packet while away from home also > should be described legitimately. > > A MN MAY receive a packet > addressed to its home address, which is sent by a CN that DOES > have a Binding Cache entry for the MN, if the CN does NOT like > to use Routing Header. > > Jiwoong > -- > > > 8.9. Sending Packets to a Mobile Node > > Before sending any packet, the sending node SHOULD examine its > Binding Cache for an entry for the destination address to which the > packet is being sent. If the sending node has a Binding Cache entry > for this address, the sending node SHOULD use a Routing header to > route the packet to this mobile node (the destination node) by way > of the care-of address in the binding recorded in that Binding Cache > entry. ... > > > 10.3. Receiving Packets While Away from Home > > While away from home, a mobile node will receive packets addressed to > its home address, by one of three methods: > > - Packets sent by a correspondent node that does not have a > Binding Cache entry for the mobile node, will be sent by the > correspondent node in the same way as any normal IP packet. Such > packets will then be intercepted by the mobile node's home agent, > encapsulated using IPv6 encapsulation [4], and tunneled to the > mobile node's primary care-of address. ... From owner-mobile-ip@sunroof.eng.sun.com Wed May 30 03:10:26 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA02979 for ; Wed, 30 May 2001 03:10:26 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA12384; Wed, 30 May 2001 00:10:43 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA07956; Wed, 30 May 2001 00:10:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4U796410332 for mobile-ip-dist; Wed, 30 May 2001 00:09:06 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4U793e10325 for ; Wed, 30 May 2001 00:09:03 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA07832 for ; Wed, 30 May 2001 00:09:11 -0700 (PDT) Received: from p-mail1.cnet.fr (p-mail1.rd.francetelecom.fr [193.49.124.31]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id BAA29018 for ; Wed, 30 May 2001 01:09:35 -0600 (MDT) Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Wed, 30 May 2001 09:08:54 +0200 Message-ID: <91A311FF6A85D3118DDF0060080C3D820193162F@lat3721.rd.francetelecom.fr> From: AUVRAY Sebastien FTRD/DMI/CAE To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Mobile IPv6 simulation tool? Date: Wed, 30 May 2001 09:08:32 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f4U793e10326 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by mercury.Sun.COM id AAA12384 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA02979 Hello, We are interested to try your type of simulator for Mobile IPv4. We work with a Linux-based Mobile IP S/W. If you think that we can try your tool, give me more information how download your files. Thanks a lot, Sebastien Auvray -----Message d'origine----- De : Mason, Brian [mailto:brian.mason@spirentcom.com] Envoyé : mardi 29 mai 2001 21:23 À : 'mobile-ip@sunroof.eng.sun.com' Objet : RE: [mobile-ip] Mobile IPv6 simulation tool? I am not sure what type of simulator you are looking for but Spirent has a MIPv4 application that simulates 500 mobile nodes to a Mobile IP network and does measurements such as registration time, registration capacity, frame loss and handover time and we are working on a MIPv6 application to do the same type of simulation. The MIPv6 is in alpha format but if you are interested we could try to work something out. Let me know if you are interested, Brian ----- Original Message ----- From: "Theo Pagtzis" To: Sent: Monday, May 28, 2001 11:52 PM Subject: Re: [mobile-ip] Mobile IPv6 simulation tool? > Thierry Ernst wrote: > > > Oner Tekin wrote: > > > Do you know any simulator which supports to MobileIPv6? > > > > I do have one. > > We have (MOTORLA Labs and INRIA Rhone Alpes Project PLANETE) have > > developped NS-2.1b6 extensions to support Mobile IPv6 - it is not yet > > contributed to the NS distribution suite, but we will do it very > > recently. > > > > Please contact me if you are interested. > > > > Thierry. > > > > -- > > * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 > > * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) > > * and MOTOROLA Labs Paris > > * http://www.inrialpes.fr/planete/people/ernst/Welcome.html > > Hi Thierry, > > I would also be interested in this. Would it be possible to get hold > of such a copy? > > Thanks > > > Theo > > > From owner-mobile-ip@sunroof.eng.sun.com Wed May 30 08:08:19 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06997 for ; Wed, 30 May 2001 08:08:18 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA29604; Wed, 30 May 2001 06:08:30 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA02859; Wed, 30 May 2001 05:08:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4UC7HN10669 for mobile-ip-dist; Wed, 30 May 2001 05:07:17 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4UC7De10662 for ; Wed, 30 May 2001 05:07:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA02794 for ; Wed, 30 May 2001 05:07:20 -0700 (PDT) From: fritsche@iabg.de Received: from iabgfw.iabg.de (iabgfw.iabg.de [194.139.245.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA29745 for ; Wed, 30 May 2001 06:07:45 -0600 (MDT) Received: by iabgfw.iabg.de; id OAA23238; Wed, 30 May 2001 14:07:16 +0200 (MET DST) Received: from unknown(10.255.255.2) by iabgfw.iabg.de via smap (V5.5) id xma023226; Wed, 30 May 01 14:07:08 +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 ; Wed, 30 May 2001 14:07:07 +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 OAA22429 for ; Wed, 30 May 2001 14:07:07 +0200 (MET DST) Received: from ziegenlippe (ziegenlippe.iabg.de [10.15.0.185]) by iabgdns.iabg.de (8.8.8+Sun/8.8.8) with SMTP id OAA04533 for ; Wed, 30 May 2001 14:07:06 +0200 (MET DST) Message-Id: <200105301207.OAA04533@iabgdns.iabg.de> Comments: Authenticated sender is To: mobile-ip@sunroof.eng.sun.com Date: Wed, 30 May 2001 14:07:06 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: [mobile-ip] Re: [Q] Routing header In-reply-to: <3B141AAD.FCB0F4D6@inrialpes.fr> X-mailer: Pegasus Mail for Win32 (v2.54DE) Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > Steve Deering wrote: > > > Last time I looked, the Mobile IPv6 spec dealt with mobile hosts only, > > not mobile routers. If that's still true, it's unsurprising that > > it doesn't handle your scenario -- that would be the responsibility > > of a (future) Mobile IPv6 Router spec. > > Steve, you are perfectly right - mobile routers and networks is not yet > a MIP WG item and the charter has never pretended to address this > issue. May be it's time for it now. What does the MIP WG think about > this ? Any vote for it to be included in the charter for the next > meeting ? > > > Presumably, to make this work, the BU from the mobile router to the CN > > would have to include the address prefix(es) reachable via the mobile > > router (i.e., the mobile subnet or larger aggregate that the mobile > > router is supposed to serve). With that info, the CN would be able to > > tell that the mobile host address falls within the address block served > > by the mobile router, and could build the necessary header chain. > > This is basically what my draft is proposing. And in this case, the > MIPv6 spec needs redefine the "CN Operation". > (all is in the draft > http://www.inrialpes.fr/planete/people/ernst/Documents/draft-ernst-mobileip-v6-network.txt) > > But there is an authorization issue that needs to be addressed as > everyone knows. I also have another issue in mind. Usually mobile nodes as described in MIPv6 get an address assigned (c/o address), which is valid and routable at their actual temporary Internet access point. Reading your draft, if a MR roams with the attached mobile network, the MR will get assigned a valid, routable c/o address at the new access point, while nodes of the mobile subnets keep their permanent static address (except if they are MNs, what you excluded for the first step). If one of the hosts at the mobile subnet now sends out some packets, it would use its permanent static IP address as source address, and therefore face the problem of ingress filtering (except the MR does some encapsulation work, but I havn't seen something like that in the draft). Wolfgang > Thierry. > > > -- > * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 > * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) > * and MOTOROLA Labs Paris > * http://www.inrialpes.fr/planete/people/ernst/Welcome.html > ########################################################## ## Wolfgang Fritsche ## Project Manager ## ## IABG ## Department for Communication Networks ## Einsteinstr. 20 ## 85521 Ottobrunn ## Germany ## ## Phone: +49 89 6088 2897 ## Fax: +49 89 6088 2845 ## E-Mail: fritsche@iabg.de ## Web: www.ipv6.iabg.de, www.iabg.de ########################################################## From owner-mobile-ip@sunroof.eng.sun.com Wed May 30 12:52:58 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17533 for ; Wed, 30 May 2001 12:52:57 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01067; Wed, 30 May 2001 10:50:34 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24423; Wed, 30 May 2001 09:50:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4UGn9w10899 for mobile-ip-dist; Wed, 30 May 2001 09:49:09 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4UGn5e10892 for ; Wed, 30 May 2001 09:49:05 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24979 for ; Wed, 30 May 2001 09:49:13 -0700 (PDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29506 for ; Wed, 30 May 2001 10:49:11 -0600 (MDT) Received: from inrialpes.fr (galibier.inrialpes.fr [194.199.24.97]) by ebene.inrialpes.fr (8.9.3+Sun/8.8.6) with ESMTP id SAA02239 for ; Wed, 30 May 2001 18:47:43 +0200 (MEST) Message-ID: <3B152486.45E1A067@inrialpes.fr> Date: Wed, 30 May 2001 18:49:10 +0200 From: Thierry Ernst Organization: INRIA Rhone-Alpes X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Mobile IP Subject: [mobile-ip] MIPv6: Ping-pong between ARs ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi all, I have a question regarding section "10.9 Establishing forwarding from a previous coa" in the MIPv6 spec. MN has a COAa on foreing link La Then, MN visits foreign link Lb and has COAb The specs says that MN may send a BU (COAa -> COAb) to a HAa on foreign link La Then, MN goes back to link La, and sends a BU (COAb -> COAa) to a HAb on foreign link Lb What happens if the entry in HAa has not yet expired ? Any packet sent to COAa or COAb enters a routing loop, right ? Or am I missing something ? If this is right: - what is the experience gained from the implementations ? - Does some implementations establish forwarding from the previous care-of address ? - How is this routing loop fixed ? - Is section 10.9 going to be amended to address this issue ? Thanks, Thierry. -- * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) * and MOTOROLA Labs Paris * http://www.inrialpes.fr/planete/people/ernst/Welcome.html From owner-mobile-ip@sunroof.eng.sun.com Wed May 30 14:47:01 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21223 for ; Wed, 30 May 2001 14:46:58 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA12561; Wed, 30 May 2001 12:45:39 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA22259; Wed, 30 May 2001 11:44:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4UIgsF11126 for mobile-ip-dist; Wed, 30 May 2001 11:42:54 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31] (may be forged)) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4UIgoe11119 for ; Wed, 30 May 2001 11:42:50 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with SMTP id f4UIh0N242503 for ; Wed, 30 May 2001 11:43:00 -0700 (PDT) Message-Id: <200105301843.f4UIh0N242503@jurassic.eng.sun.com> Date: Wed, 30 May 2001 11:42:57 -0700 (PDT) From: Alper Yegin Subject: Re: [mobile-ip] MIPv6: Ping-pong between ARs ? To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: jWx2YCL8VSTCrOlkbfWPqA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Hi all, > > I have a question regarding section "10.9 Establishing forwarding from a > previous coa" in the MIPv6 spec. > > MN has a COAa on foreing link La > Then, MN visits foreign link Lb and has COAb > The specs says that MN may send a BU (COAa -> COAb) to a HAa on foreign > link La > Then, MN goes back to link La, and sends a BU (COAb -> COAa) to a HAb on > foreign link Lb (not that spec says this, but logically) MN should first send a deregistration to HAa, so that it stops tunneling packets to CoAb, but instead forwards them directly to MN which is on-link now. After then, MN can send a BU to HAb to get it's traffic tunneled to CoAa. And it should do this only if Mn had sent a BU to HA or CNs using its new CoA, CoAb. Otherwise, deregistration sent to HAa should be sufficient. alper > > What happens if the entry in HAa has not yet expired ? Any packet sent > to COAa or COAb enters a routing loop, right ? Or am I missing > something ? > > If this is right: > - what is the experience gained from the implementations ? > - Does some implementations establish forwarding from the previous > care-of address ? > - How is this routing loop fixed ? > - Is section 10.9 going to be amended to address this issue ? > > > Thanks, > Thierry. > > > -- > * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 > * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) > * and MOTOROLA Labs Paris > * http://www.inrialpes.fr/planete/people/ernst/Welcome.html alper From owner-mobile-ip@sunroof.eng.sun.com Wed May 30 15:55:02 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22842 for ; Wed, 30 May 2001 15:55:01 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA14085; Wed, 30 May 2001 12:53:56 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA07319; Wed, 30 May 2001 12:52:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4UJm9f11223 for mobile-ip-dist; Wed, 30 May 2001 12:48:09 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4UJm3e11216 for ; Wed, 30 May 2001 12:48:05 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA07945 for ; Wed, 30 May 2001 12:47:55 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA16628 for ; Wed, 30 May 2001 13:48:18 -0600 (MDT) 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 f4UJlpN11270 for ; Wed, 30 May 2001 21:47:52 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id VAA05784; Wed, 30 May 2001 21:47:50 +0200 Message-ID: <3B154E20.89D6FD80@era.ericsson.se> Date: Wed, 30 May 2001 21:46:40 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] MIPv6: Ping-pong between ARs ? References: <200105301843.f4UIh0N242503@jurassic.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Alper Yegin wrote: > > > Hi all, > > > > I have a question regarding section "10.9 Establishing forwarding from a > > previous coa" in the MIPv6 spec. > > > > MN has a COAa on foreing link La > > Then, MN visits foreign link Lb and has COAb > > The specs says that MN may send a BU (COAa -> COAb) to a HAa on foreign > > link La > > Then, MN goes back to link La, and sends a BU (COAb -> COAa) to a HAb on > > foreign link Lb > > (not that spec says this, but logically) MN should first send a deregistration > to HAa, so that it stops tunneling packets to CoAb, but instead forwards them > directly to MN which is on-link now. > > After then, MN can send a BU to HAb to get it's traffic tunneled to CoAa. And it > should do this only if Mn had sent a BU to HA or CNs using its new CoA, CoAb. > Otherwise, deregistration sent to HAa should be sufficient. > > alper > Also, when MN turns back to link La, it should do a DAD check for COAa. HAa is defending that, so the MN must use the same complicated rules for de-registering that temporary home address as with ordinary home addresses. Our (Ericsson) implementation creates a temporary home address out of COAa with a short lifetime. It lives it's own life independent of the ordinary home address. La is considered the home link by this temporary home address and thus de-registration will take place. COAb is of course treated the same way. /Mattias From owner-mobile-ip@sunroof.eng.sun.com Wed May 30 17:41:56 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25345 for ; Wed, 30 May 2001 17:41:53 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA04958; Wed, 30 May 2001 15:40:34 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA08130; Wed, 30 May 2001 14:39:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4ULccW11470 for mobile-ip-dist; Wed, 30 May 2001 14:38:38 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4ULcZe11463 for ; Wed, 30 May 2001 14:38:35 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA07728 for ; Wed, 30 May 2001 14:38:43 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA03542 for ; Wed, 30 May 2001 15:38:41 -0600 (MDT) 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 OAA15269 for ; Wed, 30 May 2001 14:38:42 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f4ULca819935 for ; Wed, 30 May 2001 14:38:36 -0700 X-mProtect: Wed, 30 May 2001 14:38:36 -0700 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdbJCRwO; Wed, 30 May 2001 14:35:38 PDT Message-ID: <3B1567A8.C17D10CA@iprg.nokia.com> Date: Wed, 30 May 2001 14:35:36 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] MIPv6: Ping-pong between ARs ? References: <3B152486.45E1A067@inrialpes.fr> Content-Type: multipart/mixed; boundary="------------2C0D317FF0D5E7771D10053F" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. --------------2C0D317FF0D5E7771D10053F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit hi Thierry, the MN cannot use 'CoAa' for sending any packet as long as HAa is defending 'CoAa'. the MN cannot sent the second BU till it deregisters 'CoAa' when it comes back to La from Lb. whether the MN does this deregistration or not, HAa should take care not to create a neighbor cache entry for CoAa when it has a binding cache entry for CoAa. vijay Thierry Ernst wrote: > > Hi all, > > I have a question regarding section "10.9 Establishing forwarding from a > previous coa" in the MIPv6 spec. > > MN has a COAa on foreing link La > Then, MN visits foreign link Lb and has COAb > The specs says that MN may send a BU (COAa -> COAb) to a HAa on foreign > link La > Then, MN goes back to link La, and sends a BU (COAb -> COAa) to a HAb on > foreign link Lb > > What happens if the entry in HAa has not yet expired ? Any packet sent > to COAa or COAb enters a routing loop, right ? Or am I missing > something ? > > If this is right: > - what is the experience gained from the implementations ? > - Does some implementations establish forwarding from the previous > care-of address ? > - How is this routing loop fixed ? > - Is section 10.9 going to be amended to address this issue ? > > Thanks, > Thierry. > > -- > * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 > * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) > * and MOTOROLA Labs Paris > * http://www.inrialpes.fr/planete/people/ernst/Welcome.html --------------2C0D317FF0D5E7771D10053F Content-Type: text/x-vcard; charset=us-ascii; name="vijayd.vcf" Content-Description: Card for Vijay Devarapalli Content-Disposition: attachment; filename="vijayd.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Devarapalli;Vijay tel;cell:(650) 302 8629 tel;work:(650) 625 2320 x-mozilla-html:FALSE org:Nokia Research Center version:2.1 email;internet:vijayd@iprg.nokia.com title:Research Enginner adr;quoted-printable:;;313 Fairchild Drive=0D=0A;Mountain View;CA;95051;USA x-mozilla-cpt:;-12992 fn:Vijay Devarapalli end:vcard --------------2C0D317FF0D5E7771D10053F-- From owner-mobile-ip@sunroof.eng.sun.com Wed May 30 17:58:44 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25794 for ; Wed, 30 May 2001 17:58:43 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA10087; Wed, 30 May 2001 14:56:05 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA12140; Wed, 30 May 2001 14:54:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4ULrIj11515 for mobile-ip-dist; Wed, 30 May 2001 14:53:18 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4ULrFe11508 for ; Wed, 30 May 2001 14:53:15 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA04770 for ; Wed, 30 May 2001 14:53:22 -0700 (PDT) Received: from mailhub1.shef.ac.uk (mailhub1.shef.ac.uk [143.167.1.9]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14597 for ; Wed, 30 May 2001 15:53:20 -0600 (MDT) Received: from ridingwood.shef.ac.uk ([143.167.59.249]) by mailhub1.shef.ac.uk with esmtp (Exim 3.22 #3) id 155Du4-00042v-00; Wed, 30 May 2001 22:53:20 +0100 Received: from RIDINGWOOD/SpoolDir by ridingwood.shef.ac.uk (Mercury 1.48); 30 May 01 22:53:21 +0100 Received: from SpoolDir by RIDINGWOOD (Mercury 1.48); 30 May 01 22:53:14 +0100 Received: from borg (143.167.251.80) by ridingwood.shef.ac.uk (Mercury 1.48); 30 May 01 22:53:12 +0100 Message-ID: <004e01c0e94a$ed7e1a10$50fba78f@borg> From: "cny" To: , "Oner Tekin" References: <3B122BB0.E1DADB5@netas.com.tr> <3B122E38.AFAF5EE2@inrialpes.fr> Subject: Re: [mobile-ip] Mobile IPv6 simulation tool? Date: Wed, 30 May 2001 22:55:58 +0200 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 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Thierry I am also very interested in this as well. Cheers Man Chern Nam Yap ----- Original Message ----- From: "Thierry Ernst" To: ; "Oner Tekin" Sent: Monday, May 28, 2001 12:53 PM Subject: Re: [mobile-ip] Mobile IPv6 simulation tool? > Oner Tekin wrote: > > Do you know any simulator which supports to MobileIPv6? > > I do have one. > We have (MOTORLA Labs and INRIA Rhone Alpes Project PLANETE) have > developped NS-2.1b6 extensions to support Mobile IPv6 - it is not yet > contributed to the NS distribution suite, but we will do it very > recently. > > Please contact me if you are interested. > > > Thierry. > > > -- > * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 > * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) > * and MOTOROLA Labs Paris > * http://www.inrialpes.fr/planete/people/ernst/Welcome.html From owner-mobile-ip@sunroof.eng.sun.com Wed May 30 18:08:19 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26025 for ; Wed, 30 May 2001 18:08:19 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA15244; Wed, 30 May 2001 15:07:17 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA15666; Wed, 30 May 2001 15:06:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4UM5ej11564 for mobile-ip-dist; Wed, 30 May 2001 15:05:40 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4UM5ae11557 for ; Wed, 30 May 2001 15:05:37 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA13212 for ; Wed, 30 May 2001 15:05:43 -0700 (PDT) Received: from mailhub1.shef.ac.uk (mailhub1.shef.ac.uk [143.167.1.9]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14679 for ; Wed, 30 May 2001 15:05:42 -0700 (PDT) Received: from ridingwood.shef.ac.uk ([143.167.59.249]) by mailhub1.shef.ac.uk with esmtp (Exim 3.22 #3) id 155E61-00046I-00 for mobile-ip@sunroof.eng.sun.com; Wed, 30 May 2001 23:05:41 +0100 Received: from RIDINGWOOD/SpoolDir by ridingwood.shef.ac.uk (Mercury 1.48); 30 May 01 23:05:42 +0100 Received: from SpoolDir by RIDINGWOOD (Mercury 1.48); 30 May 01 23:05:39 +0100 Received: from borg (143.167.251.80) by ridingwood.shef.ac.uk (Mercury 1.48); 30 May 01 23:05:32 +0100 Message-ID: <004f01c0e94c$a6a71d10$50fba78f@borg> From: "cny" To: References: <7B5C0390ACE7D211BC9C0008C7EABA2B03213B01@daeis07nok> Subject: Re: [mobile-ip] Timeslot requests for IETF 51 Date: Wed, 30 May 2001 23:08:18 +0200 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 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi 1) Would MIPQoS have another call for time slot (Only specifically for MIPQoS only), or it would be incorporated in this. 2) How session are there altogether and how long it would be? 3) What is the major topic of discussion this time round? 4) Would be there any other close meetings before the actual one? 5)Would there be a strict control for how long each person would be given to plug their notebook into the projector? Thanks and Best Regards Chern Nam Yap ----- Original Message ----- From: To: Sent: Friday, May 25, 2001 4:49 AM Subject: [mobile-ip] Timeslot requests for IETF51 > Resending it as I did not see it on the list.... > > Hello, > > If you would like to obtain a timeslot for presentations at the London IETF > (IETF51 5-10 August 2001), please send your requests to either Phil or me. > Please include the title of the I-D, time required, and also some reasons > why > the I-D is important for consideration by the Mobile IP WG. The deadline for > receiving requests for timeslots is : July 30th, 2001 > > -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Wed May 30 19:35:34 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27443 for ; Wed, 30 May 2001 19:35:33 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA17813; Wed, 30 May 2001 16:33:58 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA04330; Wed, 30 May 2001 16:33:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4UNVoP11818 for mobile-ip-dist; Wed, 30 May 2001 16:31:50 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4UNVke11811 for ; Wed, 30 May 2001 16:31:46 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA05678 for ; Wed, 30 May 2001 16:31:53 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA21980 for ; Wed, 30 May 2001 16:31:52 -0700 (PDT) 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 QAA24744 for ; Wed, 30 May 2001 16:31:51 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f4UNVoI05779 for ; Wed, 30 May 2001 16:31:50 -0700 X-mProtect: Wed, 30 May 2001 16:31:50 -0700 Nokia Silicon Valley Messaging Protection Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdkLLzN1; Wed, 30 May 2001 16:29:18 PDT Message-ID: <3B15824D.9123C39D@iprg.nokia.com> Date: Wed, 30 May 2001 16:29:17 -0700 From: Theo Pagtzis Organization: UCL/NOKIA X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386) X-Accept-Language: el, en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Which one to trade off?? References: <7B5C0390ACE7D211BC9C0008C7EABA2B03213B01@daeis07nok> <004f01c0e94c$a6a71d10$50fba78f@borg> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi all, I wanted to know your view on this. There are two Router campuses (1) says I want to do all the processing on my own because if I give something out I may not get back a response. Hope not to reach my limits (technology growth takes care of that at a good pace). (2) says I want to distribute the processing and hope that I get back a response because if I keep doing it on my own, I will reach my limit soon. Don't care about distribution cost and error assuming Ethernet. The problem is that I may not get back a response and will have to repeat the darn thing. If you have to give up one...which one would you give up... Answer of the sort it depends on what you do...is the wrong answer for now... Theo UCL/ Mobile Systems From owner-mobile-ip@sunroof.eng.sun.com Thu May 31 04:51:21 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA18797 for ; Thu, 31 May 2001 04:51:21 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA16721; Thu, 31 May 2001 01:50:29 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA16080; Thu, 31 May 2001 01:50:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4V8n6i12398 for mobile-ip-dist; Thu, 31 May 2001 01:49:06 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4V8n3e12391 for ; Thu, 31 May 2001 01:49:03 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA13711 for ; Thu, 31 May 2001 01:49:11 -0700 (PDT) Received: from p-mail1.cnet.fr (p-mail1.rd.francetelecom.fr [193.49.124.31]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id BAA19267 for ; Thu, 31 May 2001 01:49:09 -0700 (PDT) Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Thu, 31 May 2001 10:48:50 +0200 Message-ID: <91A311FF6A85D3118DDF0060080C3D8201EAEA58@lat3721.rd.francetelecom.fr> From: BELOEIL Luc FTRD/DMI/CAE To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] MIPv6: Ping-pong between ARs ? Date: Thu, 31 May 2001 10:48:33 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi all, I agree that the draft is not clear enough about that point. From my point of view : As the HAa acts as a standard-HA wih the MN, when the MN discovers that it came back on the same link as HAa, the MN must send a Bu to HAa with a lifetime set to the value 0. I reminds you that such behaviours are cleary described in draft-kassi-mobileip-dmi-00.txt, where the concept of temporary HA is extended. > Vijay Devarapalli wrote: > > > hi Thierry, > > the MN cannot use 'CoAa' for sending any packet as long as > HAa is defending 'CoAa'. the MN cannot sent the second BU till > it deregisters 'CoAa' when it comes back to La from Lb. > > whether the MN does this deregistration or not, HAa should take > care not to create a neighbor cache entry for CoAa when it has a > binding cache entry for CoAa. > > vijay > > Thierry Ernst wrote: > > > > Hi all, > > > > I have a question regarding section "10.9 Establishing > forwarding from a > > previous coa" in the MIPv6 spec. > > > > MN has a COAa on foreing link La > > Then, MN visits foreign link Lb and has COAb > > The specs says that MN may send a BU (COAa -> COAb) to a > HAa on foreign > > link La > > Then, MN goes back to link La, and sends a BU (COAb -> > COAa) to a HAb on > > foreign link Lb > > > > What happens if the entry in HAa has not yet expired ? Any > packet sent > > to COAa or COAb enters a routing loop, right ? Or am I missing > > something ? > > > > If this is right: > > - what is the experience gained from the implementations ? > > - Does some implementations establish forwarding from the previous > > care-of address ? > > - How is this routing loop fixed ? > > - Is section 10.9 going to be amended to address this issue ? > > > > Thanks, > > Thierry. > > > > -- > > * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 > > * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) > > * and MOTOROLA Labs Paris > > * http://www.inrialpes.fr/planete/people/ernst/Welcome.html > From owner-mobile-ip@sunroof.eng.sun.com Thu May 31 07:57:40 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA21016 for ; Thu, 31 May 2001 07:57:39 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA05531; Thu, 31 May 2001 04:55:26 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA00789; Thu, 31 May 2001 04:55:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4VBsFO12625 for mobile-ip-dist; Thu, 31 May 2001 04:54:15 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4VBrWe12610; Thu, 31 May 2001 04:53:32 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA22562; Thu, 31 May 2001 04:53:39 -0700 (PDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA07270; Thu, 31 May 2001 04:53:38 -0700 (PDT) Received: from inrialpes.fr (galibier.inrialpes.fr [194.199.24.97]) by ebene.inrialpes.fr (8.9.3+Sun/8.8.6) with ESMTP id NAA21118; Thu, 31 May 2001 13:52:07 +0200 (MEST) Message-ID: <3B1630C0.A8A1CE8A@inrialpes.fr> Date: Thu, 31 May 2001 13:53:36 +0200 From: Thierry Ernst Organization: INRIA Rhone-Alpes X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Mobile IP , ipng@sunroof.eng.sun.com Subject: [mobile-ip] Re: [Q] Routing header References: <001d01c0e3e7$fcbd7880$ae0a060a@n016.co.kr> <20010525065204O.kimai@flab.fujitsu.co.jp> <009f01c0e4f2$c69a6680$ae0a060a@n016.co.kr> <15124.160.67957.34034@thomasm-u1.cisco.com> <15124.4243.705476.836130@thomasm-u1.cisco.com> <3B141937.CF8A72CA@inrialpes.fr> <15124.10369.456683.719389@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Michael Thomas wrote: > I'm aware that this is only my scenario, but this is > what I think a naive implementation would do. Ie, > the mobile router would think it's supposed to send > a BU when it see something come in from its home agent > tunnel interface, the MN (or another MR) would > think it's supposed to send a BU... I agree that a MN behind the MR is supposed to send a BU, but I disagree that the MR "is supposed to" do it as well. First, the MR is not the final destination of the packet. Second, if you think about a naive implementation, MR would send a BU to the sender that appears in the inner header in the encapsulated packet, i.e. the CN of MN "behind" MR. And what would contain the BU ? A binding between the MR's home address and its COA. This does not give much usefuk information to the CN. You would end up with a cache at the CN containing: MR home address -> MR coa MN home address -> MN coa CN uses MR's coa if it ever want to communicate with MR directly (very unlikely) CN uses MN's coa for packets it wants to send to the MN. No problem at the CN, although your datagram is going to be routed via the MR's HA (because MN's coa has the same prefix has the MR's home address. The issue is that the HA does not know how to redirect (same reason as explained in my draft) Then, the issue your are describing (including two addresses in the routing header) would not happen with a naive implementation of MRs. If any proposal would advocate such use of the routing header, I think it should also describe how this should be done. > If the MR subtends a prefix and can send a BU > which is legal in -13 as you know, it would Sorry, I don't catch you here. Could you refine ? > send a BU when it sees the packet on the HA > interface. Otherwise, you'd have triangular > routing at the MR. > > I'm not trying to propose anything, actually. I'm just > pointing out that the current set of drafts won't > work as they are currently stated to more than > one level of mobility. This is right, but this is not the purpose of any existing draft to address more than one level of mobility. More than one level of mobility needs it's own set of drafts. Thierry. -- * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) * and MOTOROLA Labs Paris * http://www.inrialpes.fr/planete/people/ernst/Welcome.html From owner-mobile-ip@sunroof.eng.sun.com Thu May 31 08:04:08 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA21191 for ; Thu, 31 May 2001 08:04:08 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA24482; Thu, 31 May 2001 06:01:36 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA01387; Thu, 31 May 2001 05:01:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4VC0Zo12666 for mobile-ip-dist; Thu, 31 May 2001 05:00:35 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4VC0We12659 for ; Thu, 31 May 2001 05:00:32 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA02703 for ; Thu, 31 May 2001 05:00:39 -0700 (PDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA22028 for ; Thu, 31 May 2001 06:01:04 -0600 (MDT) Received: from inrialpes.fr (galibier.inrialpes.fr [194.199.24.97]) by ebene.inrialpes.fr (8.9.3+Sun/8.8.6) with ESMTP id NAA21329 for ; Thu, 31 May 2001 13:59:08 +0200 (MEST) Message-ID: <3B163265.7F3EFF27@inrialpes.fr> Date: Thu, 31 May 2001 14:00:37 +0200 From: Thierry Ernst Organization: INRIA Rhone-Alpes X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: [Q] Routing header References: <200105301207.OAA04533@iabgdns.iabg.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Wolfgang, fritsche@iabg.de wrote: > > This is basically what my draft is proposing. And in this case, the > > MIPv6 spec needs redefine the "CN Operation". > > (all is in the draft > > http://www.inrialpes.fr/planete/people/ernst/Documents/draft-ernst-mobileip-v6-network.txt) > > > > But there is an authorization issue that needs to be addressed as > > everyone knows. > > I also have another issue in mind. Usually mobile nodes as > described in MIPv6 get an address assigned (c/o address), which is > valid and routable at their actual temporary Internet access point. > > Reading your draft, if a MR roams with the attached mobile network, > the MR will get assigned a valid, routable c/o address at the new > access point, while nodes of the mobile subnets keep their permanent > static address (except if they are MNs, what you excluded for the > first step). If one of the hosts at the mobile subnet now sends out > some packets, it would use its permanent static IP address as source > address, and therefore face the problem of ingress filtering (except > the MR does some encapsulation work, but I havn't seen something like > that in the draft). OK, I will add a section in my revise draft. I am not sure that IPv6 routers should perform ingress filtering (recent discussions did not give me a concrete answer ...) ; otherwise my idea is that MR would indeed encapsulate all outgoing packets. Thanks to have pointed this out. Thierry. -- * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) * and MOTOROLA Labs Paris * http://www.inrialpes.fr/planete/people/ernst/Welcome.html From owner-mobile-ip@sunroof.eng.sun.com Thu May 31 08:44:42 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA22573 for ; Thu, 31 May 2001 08:44:41 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA16997; Thu, 31 May 2001 06:43:34 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA06295; Thu, 31 May 2001 05:43:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4VCgLm12728 for mobile-ip-dist; Thu, 31 May 2001 05:42:21 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4VCgIe12721; Thu, 31 May 2001 05:42:18 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA06176; Thu, 31 May 2001 05:42:25 -0700 (PDT) From: fritsche@iabg.de Received: from iabgfw.iabg.de (iabgfw.iabg.de [194.139.245.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA16267; Thu, 31 May 2001 06:42:23 -0600 (MDT) Received: by iabgfw.iabg.de; id OAA11494; Thu, 31 May 2001 14:42:21 +0200 (MET DST) Received: from unknown(10.255.255.2) by iabgfw.iabg.de via smap (V5.5) id xma011473; Thu, 31 May 01 14:41:37 +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; Thu, 31 May 2001 14:41:36 +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 OAA04189; Thu, 31 May 2001 14:41:36 +0200 (MET DST) Received: from ziegenlippe (ziegenlippe.iabg.de [10.15.0.185]) by iabgdns.iabg.de (8.8.8+Sun/8.8.8) with SMTP id OAA13308; Thu, 31 May 2001 14:41:31 +0200 (MET DST) Message-Id: <200105311241.OAA13308@iabgdns.iabg.de> Comments: Authenticated sender is To: thierry.ernst@inrialpes.fr Date: Thu, 31 May 2001 14:41:31 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: [mobile-ip] Re: [Q] Routing header CC: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: <3B163265.7F3EFF27@inrialpes.fr> X-mailer: Pegasus Mail for Win32 (v2.54DE) Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > Hi Wolfgang, > > > fritsche@iabg.de wrote: > > > This is basically what my draft is proposing. And in this case, the > > > MIPv6 spec needs redefine the "CN Operation". > > > (all is in the draft > > > http://www.inrialpes.fr/planete/people/ernst/Documents/draft-ernst-mobileip-v6-network.txt) > > > > > > But there is an authorization issue that needs to be addressed as > > > everyone knows. > > > > I also have another issue in mind. Usually mobile nodes as > > described in MIPv6 get an address assigned (c/o address), which is > > valid and routable at their actual temporary Internet access point. > > > > Reading your draft, if a MR roams with the attached mobile network, > > the MR will get assigned a valid, routable c/o address at the new > > access point, while nodes of the mobile subnets keep their permanent > > static address (except if they are MNs, what you excluded for the > > first step). If one of the hosts at the mobile subnet now sends out > > some packets, it would use its permanent static IP address as source > > address, and therefore face the problem of ingress filtering (except > > the MR does some encapsulation work, but I havn't seen something like > > that in the draft). > > OK, I will add a section in my revise draft. > > I am not sure that IPv6 routers should perform ingress filtering (recent > discussions did not give me a concrete answer ...) ; otherwise my idea > is that MR would indeed encapsulate all outgoing packets. At least if you have a look in the MIPv6 draft, chapter 2, support for coexistence with ingress filtering is pointed out as one benefit of MIPv6 compared to MIPv4, so there seems to be no reason for stopping ingress filtering in IPv6. Encapsulation could work around this problem, but you have to investigate the influence of this encapsulation to authentication, firewalls, and overhead added to narrow band links. > Thanks to have pointed this out. > Thierry. > > > -- > * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 > * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) > * and MOTOROLA Labs Paris > * http://www.inrialpes.fr/planete/people/ernst/Welcome.html > Wolfgang ########################################################## ## Wolfgang Fritsche ## Project Manager ## ## IABG ## Department for Communication Networks ## Einsteinstr. 20 ## 85521 Ottobrunn ## Germany ## ## Phone: +49 89 6088 2897 ## Fax: +49 89 6088 2845 ## E-Mail: fritsche@iabg.de ## Web: www.ipv6.iabg.de, www.iabg.de ########################################################## From owner-mobile-ip@sunroof.eng.sun.com Thu May 31 09:57:11 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25306 for ; Thu, 31 May 2001 09:57:10 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA04779; Thu, 31 May 2001 07:56:01 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA12555; Thu, 31 May 2001 06:55:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4VDsTD12872 for mobile-ip-dist; Thu, 31 May 2001 06:54:29 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4VDsQe12865 for ; Thu, 31 May 2001 06:54:26 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA18033 for ; Thu, 31 May 2001 06:54:34 -0700 (PDT) Received: from p-mail2.cnet.fr (p-mail2.rd.francetelecom.fr [193.49.124.32]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id GAA26953 for ; Thu, 31 May 2001 06:54:33 -0700 (PDT) Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Thu, 31 May 2001 15:54:14 +0200 Message-ID: <91A311FF6A85D3118DDF0060080C3D8201EAEA5F@lat3721.rd.francetelecom.fr> From: BELOEIL Luc FTRD/DMI/CAE To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Re: [Q] Routing header Date: Thu, 31 May 2001 15:53:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f4VDsQe12866 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by patan.sun.com id HAA04779 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA25306 As far as I understand the problem, I'm not sure that sending BU-like message to all CN is a pretty good solution here for some reasons (I hope I understodd well your point): 1- from the nodes inside the mobile network (= inside-nodes): inside-nodes could send BU-like to their Correspondent nodes outside the Mobile Network so that their correspondents could update their Routing Header towards them. That solution supposes the nodes inside the Mobile Network are aware of Mobile network movements. But, in that situation all inside-nodes become Mobile Node, which generate a lot of BU traffic. 2- Moreover nodes inside the Mobile Network could prefer not be Mobile Node. The movement should be transparent for them to my mind. I see some other solutions : - from the Mobile Router point of view: a Home Agent of the Mobile Router could modify Routing Header of packets that should reach the mobile network, but that raises strong security issues. -> wrong choice - the Mobile Router could use a bidirectional tunnel with its Home Agent. But encapsulation technics should be avoid in IPv6, souldn't they ? -> wrong choice - as all a sub-network moves, the route to that sub-network could be update in all the network in using the Routing Protocols. But how longwill it take to converge ? -> seems painful to acheive. - all along the path from the previous point of attachment of the MR to the new point of attachment of the MR, the routes to the mobile network could be update. In that solution when a router receives a BU from a mobile Router it could update its route to the mobile network and then forward the BU towards the Home Agent of the Mobile Router. So the mobility is transparent to all nodes of the mobiles network and there no need to send lots of BU to all CN that communicates with inside-nodes. But the route between the MR and its HA could be unoptimized (that path between two points can change from one packet to another, if the path is assymetric...). -> there are optimization issues Finally, what is the best to do ??? ====> updating only Binding Caches of the CN which needs to communicate with inside-nodes or ====> updating route to the mobile network I think my solutions answer to the second choice. I am not sure it's the best choice, but that gives ideas, I hope. my 0.2% Luc > From : fritsche@iabg.de [mailto:fritsche@iabg.de] > > > > Steve Deering wrote: > > > > > Last time I looked, the Mobile IPv6 spec dealt with > mobile hosts only, > > > not mobile routers. If that's still true, it's unsurprising that > > > it doesn't handle your scenario -- that would be the > responsibility > > > of a (future) Mobile IPv6 Router spec. > > > > Steve, you are perfectly right - mobile routers and > networks is not yet > > a MIP WG item and the charter has never pretended to address this > > issue. May be it's time for it now. What does the MIP WG > think about > > this ? Any vote for it to be included in the charter for the next > > meeting ? > > > > > Presumably, to make this work, the BU from the mobile > router to the CN > > > would have to include the address prefix(es) reachable > via the mobile > > > router (i.e., the mobile subnet or larger aggregate that > the mobile > > > router is supposed to serve). With that info, the CN > would be able to > > > tell that the mobile host address falls within the > address block served > > > by the mobile router, and could build the necessary header chain. > > > > This is basically what my draft is proposing. And in this case, the > > MIPv6 spec needs redefine the "CN Operation". > > (all is in the draft > > > http://www.inrialpes.fr/planete/people/ernst/Documents/draft-e > rnst-mobileip-v6-network.txt) > > > > But there is an authorization issue that needs to be addressed as > > everyone knows. > > I also have another issue in mind. Usually mobile nodes as > described in MIPv6 get an address assigned (c/o address), which is > valid and routable at their actual temporary Internet access point. > > Reading your draft, if a MR roams with the attached mobile network, > the MR will get assigned a valid, routable c/o address at the new > access point, while nodes of the mobile subnets keep their permanent > static address (except if they are MNs, what you excluded for the > first step). If one of the hosts at the mobile subnet now sends out > some packets, it would use its permanent static IP address as source > address, and therefore face the problem of ingress filtering (except > the MR does some encapsulation work, but I havn't seen something like > that in the draft). > > Wolfgang > > > Thierry. > > From owner-mobile-ip@sunroof.eng.sun.com Thu May 31 13:03:05 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02196 for ; Thu, 31 May 2001 13:03:04 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21446; Thu, 31 May 2001 11:00:50 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA17411; Thu, 31 May 2001 10:00:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4VGxJh13036 for mobile-ip-dist; Thu, 31 May 2001 09:59:19 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4VGxFe13029; Thu, 31 May 2001 09:59:15 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA02414; Thu, 31 May 2001 09:59:23 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA26056; Thu, 31 May 2001 09:59:22 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f4VGxHU23861; Thu, 31 May 2001 09:59:17 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AHF44762; Thu, 31 May 2001 09:59:13 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA08199; Thu, 31 May 2001 09:59:13 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15126.30816.817322.866277@thomasm-u1.cisco.com> Date: Thu, 31 May 2001 09:59:12 -0700 (PDT) To: Thierry Ernst Cc: Mobile IP , ipng@sunroof.eng.sun.com Subject: [mobile-ip] Re: [Q] Routing header In-Reply-To: <3B1630C0.A8A1CE8A@inrialpes.fr> References: <001d01c0e3e7$fcbd7880$ae0a060a@n016.co.kr> <20010525065204O.kimai@flab.fujitsu.co.jp> <009f01c0e4f2$c69a6680$ae0a060a@n016.co.kr> <15124.160.67957.34034@thomasm-u1.cisco.com> <15124.4243.705476.836130@thomasm-u1.cisco.com> <3B141937.CF8A72CA@inrialpes.fr> <15124.10369.456683.719389@thomasm-u1.cisco.com> <3B1630C0.A8A1CE8A@inrialpes.fr> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thierry Ernst writes: > Michael Thomas wrote: > > I'm aware that this is only my scenario, but this is > > what I think a naive implementation would do. Ie, > > the mobile router would think it's supposed to send > > a BU when it see something come in from its home agent > > tunnel interface, the MN (or another MR) would > > think it's supposed to send a BU... > > I agree that a MN behind the MR is supposed to send a BU, but I disagree > that the MR "is supposed to" do it as well. If this is true, what is the purpose of putting a subnet prefix into the BU at all? How does the MR (ignoring MN for the moment) eliminate triangular routing through its HA? Surely the purpose of adding the prefix wasn't just to say that MN was reachable at a range of IP addresses. > First, the MR is not the > final destination of the packet. Second, if you think about a naive > implementation, MR would send a BU to the sender that appears in the > inner header in the encapsulated packet, i.e. the CN of MN "behind" > MR. And what would contain the BU ? A binding between the MR's home > address and its COA. This does not give much usefuk information to the > CN. Remember it's the MR's home _prefix_, not address. That's what my reference to the -13 draft was about below. > Then, the issue your are describing (including two addresses in the > routing header) would not happen with a naive implementation of MRs. > If any proposal would advocate such use of the routing header, I think > it should also describe how this should be done. I think the problem here is that the addition of prefix to the BU is not sufficient to support mobile routers, and as such it's open to interpretation what the implementation should do. While I generally like the addition of subnet prefix to BU's (mainly because it treats BU's like the routing updates that they are), it may actually be better to get the MIP WG to take the whole subject of MR's up as working group item and delete it till then because it may unfairly prejudice the final outcome. Mike From owner-mobile-ip@sunroof.eng.sun.com Thu May 31 14:00:07 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04110 for ; Thu, 31 May 2001 14:00:06 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19324; Thu, 31 May 2001 11:58:38 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA03234; Thu, 31 May 2001 10:58:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4VHuXn13222 for mobile-ip-dist; Thu, 31 May 2001 10:56:33 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4VHtwe13207; Thu, 31 May 2001 10:55:58 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA19790; Thu, 31 May 2001 10:56:07 -0700 (PDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA06827; Thu, 31 May 2001 11:56:33 -0600 (MDT) Received: from inrialpes.fr (galibier.inrialpes.fr [194.199.24.97]) by ebene.inrialpes.fr (8.9.3+Sun/8.8.6) with ESMTP id TAA02332; Thu, 31 May 2001 19:54:34 +0200 (MEST) Message-ID: <3B1685B4.834E1CCA@inrialpes.fr> Date: Thu, 31 May 2001 19:56:04 +0200 From: Thierry Ernst Organization: INRIA Rhone-Alpes X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Mobile IP CC: ipng@sunroof.eng.sun.com Subject: [mobile-ip] Re: [Q] Routing header References: <001d01c0e3e7$fcbd7880$ae0a060a@n016.co.kr> <20010525065204O.kimai@flab.fujitsu.co.jp> <009f01c0e4f2$c69a6680$ae0a060a@n016.co.kr> <15124.160.67957.34034@thomasm-u1.cisco.com> <15124.4243.705476.836130@thomasm-u1.cisco.com> <3B141937.CF8A72CA@inrialpes.fr> <15124.10369.456683.719389@thomasm-u1.cisco.com> <3B1630C0.A8A1CE8A@inrialpes.fr> <15126.30816.817322.866277@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Michael Thomas wrote: > > I agree that a MN behind the MR is supposed to send a BU, but I disagree > > that the MR "is supposed to" do it as well. > > If this is true, what is the purpose of putting a subnet prefix > into the BU at all? How does the MR (ignoring MN for the moment) > eliminate triangular routing through its HA? Surely the purpose > of adding the prefix wasn't just to say that MN was reachable > at a range of IP addresses. > > > First, the MR is not the > > final destination of the packet. Second, if you think about a naive > > implementation, MR would send a BU to the sender that appears in the > > inner header in the encapsulated packet, i.e. the CN of MN "behind" > > MR. And what would contain the BU ? A binding between the MR's home > > address and its COA. This does not give much usefuk information to the > > CN. > > Remember it's the MR's home _prefix_, not address. That's > what my reference to the -13 draft was about below. Mickael, You might probably not read the mipv6-13 draft correctly. The purpose of the home_prefix in the MIPv6 spec. is for the Home Agent to defend ALL home addresses of the MN on the home link (link local, site local, global), not for support of Mobile Routers. This has ab-so-lu-te-ly nothing to do with the Mobile Router case. If it has, may be I should rather going to grew vegetables or follow English lessons (don't know which one would be the best though :-) The prefix you are refering to is therefore included by the MN to inform its HA (not its CNs) [remember the 'H' bit that stands for 'Home Registration" ?] about the size of the prefix, not to manage mobile routers and networks. In addition, whatever the mobile (host or router), a binding is ALWAYS established between the 128-bits Home Address of the mobile and it's 128-bits Careof Address. The only place were is mentioned a binding between a prefix and a 128-bits address is my draft. Otherwise, the contribution of my draft would be pointless. Why should I introduce a new sub option if there is already all we need in the MIPv6-13 draft ? > > Then, the issue your are describing (including two addresses in the > > routing header) would not happen with a naive implementation of MRs. > > If any proposal would advocate such use of the routing header, I think > > it should also describe how this should be done. > > I think the problem here is that the addition of prefix > to the BU is not sufficient to support mobile routers, > and as such it's open to interpretation what the > implementation should do. IMHO, there is nothing to miss-interpret since the addition of prefix in the BU is not in the MIPv6-13 draft. What may be miss-interpreted by implementation is redirection at the HA of packets intended to nodes behind the MR (problem described in my draft - sorry, I always refer to my draft, but I do not want to explain everything in each email and this is clearly described there) On the other hand, I advocate that my draft may be miss-intrepreted, but this is only version-1 and I clearly stated that my proposal does not consider MN behind the MR (BTW, I did state this exaclty for the reason you were describing at the beginning of this thread - what would the CN do with 2 BUs, one from MN, and one from MR) > While I generally like the addition of subnet prefix > to BU's (mainly because it treats BU's like the routing > updates that they are), it may actually be better to > get the MIP WG to take the whole subject of MR's up > as working group item This is exactly what many people already want (to list just a few of them Hesham Soliman, Francis Dupont, Claude Castelluccia, Glenn Morrow, and may others). May be I should ask for it more explictly. > and delete it till then because > it may unfairly prejudice the final outcome. And delete it ? Sorry, I do not understand. (may be I should really take English lessons then :-) There is a problem with mobile routers because this special case has never been considered seriously (or not at all) in any of the existing MIP WG specs. My interpretation is that implementers should only implement the MIP WG drafts for hosts. Another set of specs. is required for mobile routers. Thierry.