From owner-mobile-ip@sunroof.eng.sun.com Sun Apr 1 13:06:53 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25971 for ; Sun, 1 Apr 2001 13:06:52 -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 KAA22645; Sun, 1 Apr 2001 10:06:30 -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 KAA28602; Sun, 1 Apr 2001 10:06:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f31H4kIm017700 for ; Sun, 1 Apr 2001 10:04:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f31H4kFQ017699 for mobile-ip-dist; Sun, 1 Apr 2001 10:04: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f31H4bIm017692 for ; Sun, 1 Apr 2001 10:04:37 -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 KAA28910 for ; Sun, 1 Apr 2001 10:04:37 -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 KAA22263 for ; Sun, 1 Apr 2001 10:04:35 -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 f31H4YI02917 for ; Sun, 1 Apr 2001 19:04:34 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Sun Apr 01 19:04:34 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Sun, 1 Apr 2001 19:03:08 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBD0A@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Multiple tunnels over unoptimized route packets f or Extended mode Date: Sun, 1 Apr 2001 19:04:32 +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: > > Basic mode provides some features that Extended mode > > doesn't. For example location privacy is one of the major advantages. > > location privacy for who ? > > the MN with respect to the visiting domain (1) > or > => No. > the MN with respect to the world. ?????? (2) > => Yes. > (2) the MN with respect to the world is definetely not hidden. Remember that upstream > you send packet with your src addr as the LCoA as the egress filtering won't let you out. > Also you do not specify anywhere that upstream data packets have the source addr as the > RCoA, and you know very well why. > => I suggest you read rev 3 of the draft which was sent to the list before IETF. If you're new to the list and didn't get it then you'll see it soon on the WG page after submission. The MN can certainly send packets with RCOA provided the network administrators allow it. This is explained in rev 3 which is currently on Claud's page and will be on the MIP WG page this week. > > > > > I need not emphasize further as negative point of Basic mode, that the generation of > > > multiple RCoA for MN so as to sustain unique representation of the MN in the visited > > > domain, while you have a unique Home Addr already at hand (but you don't divulge that > > > to the MAP - I wonder why???) is also bound to find problems: > > > > > > 1) by the management of MANY RCoA for no apparent reason > > > > > => Where does MANY come from ? Only one is needed. > > or does MANY = MANY MNs ? If so how is it different > > in the HA case. > > ok back to the spec. The basic mode mentions that an MN is receiving the MAPs prefix and > creates a CoA. This is the RCoA that is sent back for DAD to the MAP. I can only assume > that each MN will create a different RCoA in Basic mode, since this is the entry in the > home addr option B-Cache of the MAP. THAT MUST BE UNIQUE and thus one per MN. That implies > if X is the number of registering MNs with THAT MAP then X will be the number of > DIFFERENT RCoAs in the B-Cache of THAT MAP. This is of course unless all MNs conspire and > produce one RCoA but then the B-Cache in that MAP is useless.... > => Did you see my last sentence ? How is this different from what an HA has to do ? > > > > > > > 2) DAD checks by the hunderds for no apparent reason > > > > > => hundreds ? where does a hundred come from ? > > You mean hundreds of MNs ? Actually there > > maybe hundreds of thousands ! But the same goes > > for the HA. > > > > According to the above reasoning you will have as many DADs as RCoAs for the X number of > MNs registering under that MAP. > => Did you see my last sentence ? How is it different from what an HA has to do ? > > > > > If however the Basic mode is destined for fixed MAPs then, all I am crying out loud > > > is that when route unoptimized packets leaving from the MN's HA (when that HA has not > > > received a BU from the MN because it awaits its MR/MAP to get its own LCoA in the > > > mean time) > > > > > => Let me get this right. You're saying the MN's HA already has a binding > > for the MN. This binding was based on the MN's previous location (before > > it appeared on the MR's subnet) Correct ? > > No the binding in the MN's HA maintain (at that moment in time) the last IP address (the > last LCoA) of the MR/MAP before it flew off. > => So the HA has a binding for an address that is no longer valid. Ie. can not be used to reach the MN. So the MN is unreachable. But somehow what you say above contradicts what you say below "That is the thing I am not talking about upstream packets (the MN is still waiting on the MR/MAP/HMIPv6) to get its own LCoA and attach on a subnet. so no BU to it HA yet..." > > If the MN doesn't / can't send another BU to its HA because it doesn't > > have the MR/MAP's address or because the MR disappeared (ie. no > > connectivity) then packets from its HA will be delivered to the old > > address, ie. lost. > > > > Nooooooooope.... remember that in extende mode you have given to the MN's HA the IP > address of the MR/MAP in that MR/MAP home domain. > => If I understand your scenario, you're assuming there is another MAP (fixed). In that case that's the address you give to the HA NOT the MR's LCoA. If the MR disappeared, then the "further" MAP will not be able to route packets to the MN unless it gets another BU. > Now the MR/MAP has flown off. So as far as the protocol is concerned the MR/MAP is just > another HMIPv6 node. So what does that node do. It provides to its HA (that is the > MR/MAP's HA) its latest binding. > => No it doesn't have to be the MR's HA. Unless the MN's HA = MR's HA. > This MUST be a RCoA since it registers with fixed MAP. So > the HA of the MR/MAP/HMIPv6 node will now intercept all packets that come on its IP > address. That includes all packets that arrive tunneled from the MN's HA according that > the aformentioned binding. That is the old IP address of the MR/MAP as the alt-CoA for the > MN BEFORE the MR/MAP/HMIPv6 node flew off !!!!!!!!!!!! > => I think (I'm trying very hard to understand what you're saying) that you're assuming that the MN sends a BU to its HA including the MR's Home address (ie. the MR's address that is on the MN's side). This is not what the draft says. It says that the MN binds it's home address to the "further" MAP's address (in its HA BU) , and the MR's LCoA is used with that further MAP. More on the address later. So: HA_BU (Home_address, RCoA) RCoA is the "further" MAP's address in the extended mode case or the address on the "further" MAP's subnet in Basic mode. MAP_BU (MR's LCoA, Home address (Extended mode) or RCoA in Basic mode) The MAP_BU is the BU sent to the "further" MAP. If there is no "further" MAP upstream, then the MR is essentially like an FA and the MR's LCoA is sent directly to the HA. So based on this, the packets addressed to the MN can NOT be received by the MR's HA, unless the MR's HA = MN HA. The MN's HA will tunnel packets to the CoA in its Binding Cache. That CoA is NOT the MR's Home address. It is either, the RCoA (if a further MAP exists) or the MR's CoA if no other (further) MAPs exist. OK ? > > > > > towards the MN, AND the MR is away but the BU from the MN has not reached the MN's> > > > HA (MR/MAP has not got yet its own LCoA), then the MR/MAP's HA will have to> > > > intercept the packet and tunnel it to the RCoA > > > > > => How does the MR's HA do that ? How can it even receive the > > MN's packets ? > > That is the thing I am not talking about upstream packets (the MN is still waiting on the > MR/MAP/HMIPv6) to get its own LCoA and attach on a subnet. so no BU to it HA yet... > => As I said above, this is the opposite of what you said earlier. > > If the MR's HA is the same as the MN's HA then the MN isn't > > reachable and it doesn't even know that it > > moved because it is still receiving its Home RA. > > > > I did not say such a thing in the slightest...wrong turn here... both HAs are different > and defend different addr > => Then the MR's HA should never receive the MN's traffic. > The MN's HA is intercepting packets at that time for the MN's home address. But in > extended mode it has to destine them to the MR/MAP/HMIPv6 node IP address (remember?) > The MR/MAP/HMIPv6's HA is intercepting packets that arrive to the IP addr of that> > MR/MAP/HMIPv6 node...Guess what these are (since it is a router)...they are (among others) > packets that arrive tunneled to the IP addr of the MR/MAP/HMIPv6.....see? > => I don't know how much more I have to say to explain that the MR's HA will NOT receive _the_MN's traffic. Where does the draft say that ? Pick that part of the draft and send it to the list. If you can find it we'lll change it to reflect what I just told you. If the MN sends the BUs I showed above, and then the MR (MAP) disappears then it has to update the fixed MAP with a new LCoA. Otherwise it's not reachable. > > Packets from the CN to the MN will be tunnelled by the MN's > > HA to the CoA in the Binding Cache. If there is no entry > > there is no tunnelling. If there is an entry that is no longer > > valid (because the MN moved) the HA will comtinue tunnelling > > to that CoA in the Binding Cache regardless, until it's > > given a new CoA. I really can't see how the scenario you're > > describing is possible. > > > Yes but what is the > CoA......????????????????????????????????????????????????????????????????????????? > the IP addr of the MR/MAP/HMIPv6 node...so the packet will arrive somewhere and will be > encapsulated again as soon as the HA for that MR/MAP/HMIPv6 intercepts them... > => NO. It's the LCoA of the MR. The one advertised in its MAP option. The one it formed from the RA received from the visited AR or the local DHCP server. The one that belongs to the visited domain and not the Home domain. That one. Therefore packets can never be sent to the MR's HA, unless it is the same HA as the MN's. Which, as you said, is not the scenario you're describing. > Basic assumption here....all nodes have a HA when moving.... even MR/MAP/HMIPv6 > nodes...... > > > So you just said it but did not continue here....please move your thoughts on that > scenario...I think you do see it ..... :))))))) => :)))))... Yes I do see that what you described is not what we said in the draft. Perhaps someone else has managed to understand what you're saying differently, that is if they understood it at all. If so I'd love to hear what they understood. > If you still cannot see the scenario...I seriously suspicious here....just to make it a > little more fun...I think you need to take off the Ericsson hat (understandable), again > with all due respect....and put your research engineer hat on > => The only hats I try to keep on when I answer your mails are my sanity hat and the "filter irrelevant comments" hat. But you seem to be trying hard to remove both of them. I suggest you stick to the draft and not get this list into discussions about my company or my hats. It's not fun or interesting or relevant. Hesham From owner-mobile-ip@sunroof.eng.sun.com Sun Apr 1 13:15:13 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27698 for ; Sun, 1 Apr 2001 13:15: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 KAA24377; Sun, 1 Apr 2001 10:15: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 KAA26204; Sun, 1 Apr 2001 10:15:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f31HE1Im017737 for ; Sun, 1 Apr 2001 10:14:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f31HE0P3017736 for mobile-ip-dist; Sun, 1 Apr 2001 10:14: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.Beta5+Sun/8.12.0.Beta5) with ESMTP id f31HDpIm017729 for ; Sun, 1 Apr 2001 10:13: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 KAA18311 for ; Sun, 1 Apr 2001 10:13:52 -0700 (PDT) Received: from c007.snv.cp.net (c007-h008.c007.snv.cp.net [209.228.33.214]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA22879 for ; Sun, 1 Apr 2001 10:13:51 -0700 (PDT) Received: (cpmta 26746 invoked from network); 1 Apr 2001 10:13:50 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.214) with SMTP; 1 Apr 2001 10:13:50 -0700 X-Sent: 1 Apr 2001 17:13:50 GMT Message-ID: <003001c0bace$c99e54c0$6501a8c0@philneum> From: "Phil Neumiller" To: Subject: [mobile-ip] some comments on draft-ietf-mobileip-fast-mipv6-00.txt Date: Sun, 1 Apr 2001 12:11:20 -0500 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 Hello MIPv6rs, I know these comments are REALLY late. Sorry about that, just catching up on life lately. 0). Who is the intended audience for MIPv6? I might be nice to state that in the draft like "MIPv6 solves the problem of fast handoff for ___intended recipient____. 1). In the abstract the term "more quickly" is vague. The SeaMoby micro-mobility work was moved to the IRTF largely because it could not quantify its boundaries with MIP, and to be fair the MIP WG has not done its homework here either. I hope that the first thing the IRTF looks at with respect to SeaMoby micro-mobility is what the MIP limitations are, i.e..a. how fast is "fast" handover in the general, average, worse case work load models, and how "local" is local mobility exactly? 2). In the abstract the same vagueness applies to "minimize the time"? 2.1). I guess this is related to question 0. Is this work targeted at sytems that will use CDMA link layers? I know that MIP try's to be L2 agnostic but then again there is a matter of maturing too, is it targeted directly at i.e. 3GPP, 3GPP2? If it is then the rest of my comments questions below apply. If not, they can be pretty much ignored. 3). In section 1 paragraph 4 of the introduction I quote the following: "Situations where the mobile node would be expected to acquire this information from advertisements from the new access router while still maintaining layer-2 connectivity with the previous access router are excluded from consideration in this specification." I find this quite puzzling. Wouldn't this very situation allow for the fastest of all possible handovers, make-before-break, i.e..a. soft-handover, which will be endemic to all 3GPP and 3GPP2 systems? 4). In section 2, I quote the first paragraph "The aim of this protocol is to enable the MN to configure a newCOA before it moves to a newAR in a way that can use this newCOA immediately at connection with newAR." I find this quite puzzling also. If we are assuming 3GPP, or 3GPP2 the handset will have many handoff candidates and many active ARs at any moment (depending on how you do things [of course I dropped out of those standards so long ago that I need to be updated]). At least in theory, the mobile should be able to prepare a new home in several different newAR homes i.e. analogous to the CDMA candidate list, recall that a CDMA mobile has pilot searchers running all the time and remains in active connectivity with several cells. This is where OBAST, and my CNP work came from which leads to being "clueful" about where to hand-off to. You don't just want to pick any old AR. The MN probably has been tracking stats on several pilots for awhile and these ARs have been "watching the MN" with smart antennas trained on it etc, there is cell breathing, load shedding all kinds of stuff the AR/AP knows that MN doesn't know . This is why its important for an "anchor" concept to exist but I am getting off on a rant, and you can read the paper if your interested in July 2000 ACM SIGMOBILE MCCR. 5). In section 2, "mimal interuption" suffers from vagueness too. What packets get dropped and why and under what circumstances? 6). In section 2, the MN initiates the fast handover with sol for proxy. The details on this are sketchy. I think some requirements are needed. In CDMA this an area that is incredibly complexity since TADD, TDROP timers are used to avoid ping-ponging on the seam and adjust power control etc. Is the idea that when the link layer has handled the incredible complexity of establishing a wireless link on a seam (debounced it and whatnot) that only then a subnet boundary cross is checked? Also, it is quite likely in 3G that soft-handovers across subnet boundaries will be common. When you look at the Nextel system people can drive up and down the coast doing MIPv4 handoffs while downloading mp3 files the whole time with gnutella. 7). The network determined handover case would in theory not be needed as often (and this in general a good idea to move intelligence out to the edge if possible) if the mobile simply had more handover choices. This gets back to my arguments on the SeaMoby list about context transfer being coupled with HO request messages being sent to a whole set of HO candidates rather than blindly sending the HO request to one candidate. For CDMA in 3G, the MN *will* have knowledge of several handoff targets, its time for MIPv6 to take advantages of this, and A). perform make-before break handovers becuse they are infinitely *FAST* B). perform "enlightened" handovers (not blind faith) (i.e. use contract bids to select best candidate and perform context transport simultaneously (not over the air but over the big I when desirable) C). read the OBAST paper :-) :-) sorry for the ad.. :-) 8). Another problem I have with this whole draft is the dreaded SDU. Yes we need to bring it up. The selection distribution unit. Perhaps you guys that are engrossed in the 3GPP, 3GPP2 standards can say what it is called these days. I am quite mist still be one. The fast handover technique in this draft does not work and has completely non-deterministic behavior when the SDU functionallity and location/latency is not factored in. If you have an SDU way up stream some where in some operators farm, the fast handover latency is going to be determined by the round trip latency through that box. BTW, that is another reason Peter, Randy I put the SDU (along with the RNC) in the BTS in OBAST (works great for MANETs too Charlie!) [peer-to-peer SDUs? peer-to-peer RNCs? Naaww, it'll never work]. :-) :-) Best regards, Phil From owner-mobile-ip@sunroof.eng.sun.com Sun Apr 1 13:21:28 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28984 for ; Sun, 1 Apr 2001 13:21:27 -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 KAA25776; Sun, 1 Apr 2001 10:21: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 KAA18716; Sun, 1 Apr 2001 10:21:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f31HK6Im017763 for ; Sun, 1 Apr 2001 10:20:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f31HK6mt017762 for mobile-ip-dist; Sun, 1 Apr 2001 10:20: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.Beta5+Sun/8.12.0.Beta5) with ESMTP id f31HJvIm017755 for ; Sun, 1 Apr 2001 10:19:57 -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 KAA18542 for ; Sun, 1 Apr 2001 10:19:57 -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 LAA16612 for ; Sun, 1 Apr 2001 11:19:55 -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 f31HJss05877 for ; Sun, 1 Apr 2001 19:19:54 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Sun Apr 01 19:19:54 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Sun, 1 Apr 2001 19:18:28 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBD0B@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Samita Chakrabarti'" Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] RE: [rohc] RE: Restarting Compressor on Mobile IP v6 Handover Date: Sun, 1 Apr 2001 19:19:53 +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: Samita, > > > I guess MIP list is cross-listed because HMIPv6 is relying on rohc to > > > provide header compression support, which involves context initialization, > > > which in turn could be avoided during handovers using context relocation! > > > > > => No, I disagree. IP_deployment_in cellular networks relies > > on ROHC. MIPv4/v6 in general relies on ROHC to be deployed > > in cellular networks. This is the reality. If you're sending complete > > IP headers in a VOIP call, then I'll just stick to my GSM phone. > > > But the fact is that HMIPv6 draft is making an assumption that ROHC is a > pre-requisite to implement HMIPV6 support. > => Where does the draft make this assumption ? Is it because packets are tunnelled ? If so then MIPv4 and MIPv6 are making that assumption. > So, from your above statement, it is clear that hmipv6 is only targeting > cellular systems that will have ROHC or rfc2507 HC implemented. > => I don't understand how that conclusion is drawn. Fixed lines also use header comprssion. ANY narrow-band link will use it. In other words, wherever BW is scarce some form of header compression is needed. > BTW, HMIPV6 draft talks about hierarchical networks in general, why do you > assume that ROHC will be implemented in all hierarchical networks. > => I'm not assuming it, I'm assuming some form of HC will be done if network administrators want to save BW. Not just for (H)MIPv6 but for IP in general. > There > may be small scale wireless networks which may not have header compression > at the access points. > => Sure. > Also, in regular netwroks, if I have a choice of saving > 40 bytes, why don't I do that ? > => Sure you can. But you'll only do so if you use your proposal and make sure MNs don't use a HA, ie. MUST use HMIPv6 and route optimisation. Also you'd have to make sure that no other prtocols (that use tunnelling) are allowed. That's might be possible, I didn't say it's not possible. All I said was that we're trying to scope this draft and get it done and I suggested that you have it in another draft. What's wrong with that ? In fact that's what the RR authors did and their Reg-fwd draft is separated from the main draft and includes the same idea you proposed. So I don't see why it couldn't be done for HMIPv6. > The third mode proposal is not complex at all > and it does only destination address substitution once at MAP and once at MN, > mobileIpv6 is doing similar mechanism at end nodes with homeaddress option. > So may be 10-15 lines of additional code. > => That's fine, I never said it can't be done, what I suggested was to put it in another draft. I don't think there is anything wrong with that. The entire HMIPv6 (basic mode) was implemented in 300 lines, but we didn't suggest putting it the MIPv6 draft. Hesham From owner-mobile-ip@sunroof.eng.sun.com Sun Apr 1 22:21:21 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22988 for ; Sun, 1 Apr 2001 22:21:21 -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 TAA20440; Sun, 1 Apr 2001 19:20: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 TAA26073; Sun, 1 Apr 2001 19:20:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f322JSIm018069 for ; Sun, 1 Apr 2001 19:19:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f322JSwq018068 for mobile-ip-dist; Sun, 1 Apr 2001 19:19: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f322JIIm018061 for ; Sun, 1 Apr 2001 19:19:19 -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 TAA11782 for ; Sun, 1 Apr 2001 19:19:15 -0700 (PDT) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA15670 for ; Sun, 1 Apr 2001 19:19:14 -0700 (PDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Sun, 1 Apr 2001 20:43:41 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 1 Apr 2001 20:43:28 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E4301B90F41@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Multiple tunnels over unoptimized route packets f or Extended mode Date: Sun, 1 Apr 2001 20:43:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0BB16.50093830" Sender: owner-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_01C0BB16.50093830 Content-Type: text/plain; charset="iso-8859-1" Hesham, Do you really think that you could convince a customer that you are really providing them location privacy. If I were that customer, I would not be convinced. I think that is everyone's point. Thanks, Glenn > > Basic mode provides some features that Extended mode > > doesn't. For example location privacy is one of the major advantages. > ------_=_NextPart_001_01C0BB16.50093830 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Multiple tunnels over unoptimized route packets = f or Extended mode

Hesham,

Do you really think that you could convince a = customer that you are really providing them location privacy. If I were = that customer, I would not be convinced. I think that is everyone's = point.

Thanks,

Glenn

> > Basic mode provides some features that = Extended mode
> = >         doesn't. For = example location privacy is one of the major advantages.
>

------_=_NextPart_001_01C0BB16.50093830-- From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 2 03:27:33 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA02118 for ; Mon, 2 Apr 2001 03:27: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 AAA26327; Mon, 2 Apr 2001 00:27:08 -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 AAA15924; Mon, 2 Apr 2001 00:27:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f327PmIm018321 for ; Mon, 2 Apr 2001 00:25:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f327PlEi018320 for mobile-ip-dist; Mon, 2 Apr 2001 00:25: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f327PcIm018313 for ; Mon, 2 Apr 2001 00:25:38 -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 AAA12910 for ; Mon, 2 Apr 2001 00:25:39 -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 AAA25614 for ; Mon, 2 Apr 2001 00:25:38 -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 f327Pas08565 for ; Mon, 2 Apr 2001 09:25:37 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Mon Apr 02 09:25:36 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Apr 2001 09:21:18 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBD0F@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Multiple tunnels over unoptimized route packets f or Extended mode Date: Mon, 2 Apr 2001 09:25:31 +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: Glenn, > Do you really think that you could convince a customer that you are really providing them location privacy. > If I were that customer, I would not be convinced. > => Well, up until this mail I thought there is some location privacy support in the draft. However if there is a better way of doing it, we're happy to consider it. I thought we discussed this before IETF and found that it was difficult to achieve complete location privacy with optimal routing ? Could you elaborate on why you're not convinced ? > I think that is everyone's point. > => Everyone ? The only feedback I got until Minneapolis was that (from the people that talked to me in private) Basic mode provided some nice features for hiding the LCoA. So I don't know who everyone is. It's very difficult when people make general statements like these without explaining reasons and / or alternatives. I'd appreciate some elaboration. Thanks, Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 2 05:49:37 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA21542 for ; Mon, 2 Apr 2001 05:49:36 -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 CAA01755; Mon, 2 Apr 2001 02:49: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 CAA26173; Mon, 2 Apr 2001 02:49:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f329lwIm018442 for ; Mon, 2 Apr 2001 02:47:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f329lvjM018441 for mobile-ip-dist; Mon, 2 Apr 2001 02:47: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f329lmIm018434 for ; Mon, 2 Apr 2001 02:47: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 CAA26056 for ; Mon, 2 Apr 2001 02:47:48 -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 DAA25256 for ; Mon, 2 Apr 2001 03:47:47 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2650.21) id ; Mon, 2 Apr 2001 05:47:46 -0400 Message-ID: From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] some comments on draft-ietf-mobileip-fast-mipv6-0 0.txt Date: Mon, 2 Apr 2001 05:47:42 -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: Phil, see comments below... -----Original Message----- From: Phil Neumiller [mailto:neumiller@telocity.com] Sent: Sunday, April 01, 2001 1:11 PM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] some comments on draft-ietf-mobileip-fast-mipv6-00.txt Hello MIPv6rs, I know these comments are REALLY late. Sorry about that, just catching up on life lately. GT> That is OK Phil comments are always welcome... 0). Who is the intended audience for MIPv6? I might be nice to state that in the draft like "MIPv6 solves the problem of fast handoff for ___intended recipient____. GT> Well,...the Internet? the people who implement MIPv6? what exactly do you suggest? 1). In the abstract the term "more quickly" is vague. The SeaMoby micro-mobility work was moved to the IRTF largely because it could not quantify its boundaries with MIP, and to be fair the MIP WG has not done its homework here either. I hope that the first thing the IRTF looks at with respect to SeaMoby micro-mobility is what the MIP limitations are, i.e..a. how fast is "fast" handover in the general, average, worse case work load models, and how "local" is local mobility exactly? GT> Phil, what you describe is a bit too academic for me...the idea was to do it as fast as possible...(without assuming make before break). 2). In the abstract the same vagueness applies to "minimize the time"? GT> Again "minimize" means as fast as possible...the details will depend on the link layer used....i.e.: we can not put a number on it.... 2.1). I guess this is related to question 0. Is this work targeted at sytems that will use CDMA link layers? I know that MIP try's to be L2 agnostic but then again there is a matter of maturing too, is it targeted directly at i.e. 3GPP, 3GPP2? If it is then the rest of my comments questions below apply. If not, they can be pretty much ignored 3). In section 1 paragraph 4 of the introduction I quote the following: "Situations where the mobile node would be expected to acquire this information from advertisements from the new access router while still maintaining layer-2 connectivity with the previous access router are excluded from consideration in this specification." I find this quite puzzling. Wouldn't this very situation allow for the fastest of all possible handovers, make-before-break, i.e..a. soft-handover, which will be endemic to all 3GPP and 3GPP2 systems? GT> No, the focus of the draft is on break-before-make link layers...Even a break before make mobile can scan the air for better signals from alternative base stations (i.e.: PHY layer often is make before break)....As long as these base stations (or more general Access Points) can be identified with a hardware address our proposal can be applied (no make before break capability assumed here). After comments from the mailing list we are clarifying this in the next version of the draft. 4). In section 2, I quote the first paragraph "The aim of this protocol is to enable the MN to configure a newCOA before it moves to a newAR in a way that can use this newCOA immediately at connection with newAR." I find this quite puzzling also. If we are assuming 3GPP, or 3GPP2 the handset will have many handoff candidates and many active ARs at any moment (depending on how you do things [of course I dropped out of those standards so long ago that I need to be updated]). At least in theory, the mobile should be able to prepare a new home in several different newAR homes i.e. analogous to the CDMA candidate list, recall that a CDMA mobile has pilot searchers running all the time and remains in active connectivity with several cells. This is where OBAST, and my CNP work came from which leads to being "clueful" about where to hand-off to. You don't just want to pick any old AR. GT> That is why the process of learning about newCOA (from potential new ARs) is separate from the actual Routing change...you can actually learn a number of newCOAs and only select one (especially in Mobile Determined handover) The MN probably has been tracking stats on several pilots for awhile and these ARs have been "watching the MN" with smart antennas trained on it etc, there is cell breathing, load shedding all kinds of stuff the AR/AP knows that MN doesn't know . This is why its important for an "anchor" concept to exist but I am getting off on a rant, and you can read the paper if your interested in July 2000 ACM SIGMOBILE MCCR. GT> The idea of Anchor can be applied in parallel to this proposal, as well hierarchical/regional mobile ip....I personally do not think any of these mechanisms are any good but we definitely took them into account and are allowed in combination with this proposal. 5). In section 2, "mimal interuption" suffers from vagueness too. What packets get dropped and why and under what circumstances? GT> hopefully none, if everything works as intended and if ARs buffer appropriately...."zero packet loss" was not a target in this work but we did the best we could to ensure that it can be done... 6). In section 2, the MN initiates the fast handover with sol for proxy. The details on this are sketchy. I think some requirements are needed. In CDMA this an area that is incredibly complexity since TADD, TDROP timers are used to avoid ping-ponging on the seam and adjust power control etc. Is the idea that when the link layer has handled the incredible complexity of establishing a wireless link on a seam (debounced it and whatnot) that only then a subnet boundary cross is checked? Also, it is quite likely in 3G that soft-handovers across subnet boundaries will be common. When you look at the Nextel system people can drive up and down the coast doing MIPv4 handoffs while downloading mp3 files the whole time with gnutella. GT> We are adding a section on link layer triggers which may make you feel better about this...We clearly are not going to even try to describe how you apply this to a CDMA system although the design team has enough people working on CDMA so thinks have been thought through in that respect....After a point, however, it becomes implementation dependent.... 7). The network determined handover case would in theory not be needed as often (and this in general a good idea to move intelligence out to the edge if possible) if the mobile simply had more handover choices. This gets back to my arguments on the SeaMoby list about context transfer being coupled with HO request messages being sent to a whole set of HO candidates rather than blindly sending the HO request to one candidate. For CDMA in 3G, the MN *will* have knowledge of several handoff targets, its time for MIPv6 to take advantages of this, and A). perform make-before break handovers becuse they are infinitely *FAST* B). perform "enlightened" handovers (not blind faith) (i.e. use contract bids to select best candidate and perform context transport simultaneously (not over the air but over the big I when desirable) C). read the OBAST paper :-) :-) sorry for the ad.. :-) GT> Phil, fast handovers are easy....I know since I implement one :) The draft attempted to provide solutions that can improve break before make handovers....In any case I have the feeling that the proposal can be applied in the scenarios you describe....i.e.: takes advantage of prior knowledge (of potentially multiple) alternative access points.... 8). Another problem I have with this whole draft is the dreaded SDU. Yes we need to bring it up. The selection distribution unit. Perhaps you guys that are engrossed in the 3GPP, 3GPP2 standards can say what it is called these days. I am quite mist still be one. The fast handover technique in this draft does not work and has completely non-deterministic behavior when the SDU functionallity and location/latency is not factored in. If you have an SDU way up stream some where in some operators farm, the fast handover latency is going to be determined by the round trip latency through that box. BTW, that is another reason Peter, Randy I put the SDU (along with the RNC) in the BTS in OBAST (works great for MANETs too Charlie!) [peer-to-peer SDUs? peer-to-peer RNCs? Naaww, it'll never work]. :-) :-) GT> Well, if a certain link layer suffers from massive latencies due to some "box" or another...that is too bad...I guess we need to find a better link layer ;) Thanks George P.S: BTW, we (the design team) are working on a new version of the draft...should be with you in a week or so... From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 2 07:17:43 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA00428 for ; Mon, 2 Apr 2001 07:17: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 EAA26490; Mon, 2 Apr 2001 04:17: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 EAA02785; Mon, 2 Apr 2001 04:17:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f32BG1Im018551 for ; Mon, 2 Apr 2001 04:16:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f32BG0YL018550 for mobile-ip-dist; Mon, 2 Apr 2001 04:16: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.Beta5+Sun/8.12.0.Beta5) with ESMTP id f32BFoIm018543 for ; Mon, 2 Apr 2001 04:15:50 -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 EAA29117 for ; Mon, 2 Apr 2001 04:15:38 -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 EAA18097 for ; Mon, 2 Apr 2001 04:15:35 -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 HAA29975; Mon, 2 Apr 2001 07:15:34 -0400 (EDT) Message-Id: <200104021115.HAA29975@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-mkhalil-mobileip-ipv6-sap-00.txt Date: Mon, 02 Apr 2001 07:15:34 -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. Title : Dynamic Security Association Establishment Protcol For IPv6 Author(s) : M. Khalil, H. Akhtar, E. Qaddoura Filename : draft-mkhalil-mobileip-ipv6-sap-00.txt Pages : 14 Date : 30-Mar-01 A protocol is proposed to allow a fast establishment of Security Association between the Mobile Node (MN) and Correspondent Node (CN). Once this Security Association is established, it can be used to authenticate any Binding Update between the MN and the CN. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mkhalil-mobileip-ipv6-sap-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-mkhalil-mobileip-ipv6-sap-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-mkhalil-mobileip-ipv6-sap-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010330135717.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mkhalil-mobileip-ipv6-sap-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-mkhalil-mobileip-ipv6-sap-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010330135717.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 2 08:20:04 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04247 for ; Mon, 2 Apr 2001 08:20: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 FAA17092; Mon, 2 Apr 2001 05:19: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 FAA03602; Mon, 2 Apr 2001 05:19:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f32CIKIm018636 for ; Mon, 2 Apr 2001 05:18:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f32CIK1F018635 for mobile-ip-dist; Mon, 2 Apr 2001 05:18: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f32CIBIm018628 for ; Mon, 2 Apr 2001 05:18: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 FAA20009 for ; Mon, 2 Apr 2001 05:18:10 -0700 (PDT) Received: from c007.snv.cp.net (c007-h015.c007.snv.cp.net [209.228.33.222]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id FAA16171 for ; Mon, 2 Apr 2001 05:18:09 -0700 (PDT) Received: (cpmta 3227 invoked from network); 2 Apr 2001 05:18:08 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.222) with SMTP; 2 Apr 2001 05:18:08 -0700 X-Sent: 2 Apr 2001 12:18:08 GMT Message-ID: <001701c0bb6e$d29746e0$6501a8c0@philneum> From: "Phil Neumiller" To: References: <200104021115.HAA29975@ietf.org> Subject: [mobile-ip] comments on draft-mkhalil-mobileip-ipv6-sap-00.txt Date: Mon, 2 Apr 2001 07:16:55 -0500 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 Hello, 1). This draft belongs in the security working area of the IETF. 2). The MIP group is not qualified to make a security assesment of this draft. 3). Why should the security association between an MN and a CN be all that much different from other types of clients and servers and peers that run on the Internet? Why enmesh the security terminology with MIP terminology? (cohesion is still a bad design choice after all these years). Build a generalized solution for the Internet that MIP can use. 4). In the Abstract, How fast is "fast"? What is the baseline? 5). Can't a security association be used for all sorts of other good stuff besides MIP binding updates (related to 2 above). 6). As for the rest of the draft, I saw no references to the specific Diffie Hellman work you were applying, no references to patents you were using (expired or not), I saw one vague reference to some of Charlie's work, I am supposed to believe that this work will lead to something cryptographically secure? I believe this type of work needs to be reviewed in the MIP WG after it goes through some severe scrutiny in the security area where there are domain experts in security. Most people in the MIP WG want mobile security in the worse way, but are not security domain experts. Best Regards, Phil From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 2 09:25:14 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07771 for ; Mon, 2 Apr 2001 09:25:13 -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 GAA09486; Mon, 2 Apr 2001 06:24: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 GAA08160; Mon, 2 Apr 2001 06:24:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f32DN6Im018684 for ; Mon, 2 Apr 2001 06:23:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f32DN6sK018683 for mobile-ip-dist; Mon, 2 Apr 2001 06:23: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.Beta5+Sun/8.12.0.Beta5) with ESMTP id f32DMvIm018676 for ; Mon, 2 Apr 2001 06:22:57 -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 GAA11429 for ; Mon, 2 Apr 2001 06:22:57 -0700 (PDT) Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA19958 for ; Mon, 2 Apr 2001 06:22:52 -0700 (PDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Mon, 2 Apr 2001 08:16:09 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Apr 2001 08:21:19 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E4301B90FE8@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Multiple tunnels over unoptimized route packets f or Extended mode Date: Mon, 2 Apr 2001 08:21:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0BB77.CAB1B4C0" 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_01C0BB77.CAB1B4C0 Content-Type: text/plain; charset="iso-8859-1" Hesham, You probably did not get any feedback publicly at the WG meeting because people at the MICs were quite plentiful and focused more on other issues of the draft - time ran out. As I recall, you have received numerous comments on the mailing list about it. This constitutes feedback. As for alternatives, I suggest you look to what could be done at a router close to the CN. People seem to trust routers to route their packets, perhaps they should also trust them to hide their location. Hope this helps, Glenn -----Original Message----- From: Hesham Soliman (ERA) [mailto:Hesham.Soliman@era.ericsson.se] Sent: Monday, April 02, 2001 2:26 AM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] Multiple tunnels over unoptimized route packets f or Extended mode Glenn, > Do you really think that you could convince a customer that you are really providing them location privacy. > If I were that customer, I would not be convinced. > => Well, up until this mail I thought there is some location privacy support in the draft. However if there is a better way of doing it, we're happy to consider it. I thought we discussed this before IETF and found that it was difficult to achieve complete location privacy with optimal routing ? Could you elaborate on why you're not convinced ? > I think that is everyone's point. > => Everyone ? The only feedback I got until Minneapolis was that (from the people that talked to me in private) Basic mode provided some nice features for hiding the LCoA. So I don't know who everyone is. It's very difficult when people make general statements like these without explaining reasons and / or alternatives. I'd appreciate some elaboration. Thanks, Hesham ------_=_NextPart_001_01C0BB77.CAB1B4C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Multiple tunnels over unoptimized route packets = f or Extended mode

Hesham,

You probably did not get any feedback publicly at the = WG meeting because people at the MICs were quite plentiful and focused = more on other issues of the draft - time ran out. As I recall, you have = received numerous comments on the mailing list about it. This = constitutes feedback. As for alternatives, I suggest you look to what = could be done at a router close to the CN. People seem to trust routers = to route their packets, perhaps they should also trust them to hide = their location.

Hope this helps,

Glenn

-----Original Message-----
From: Hesham Soliman (ERA) [mailto:Hesham.Soliman@era= .ericsson.se]
Sent: Monday, April 02, 2001 2:26 AM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: [mobile-ip] Multiple tunnels over = unoptimized route packets
f or Extended mode


Glenn,

> Do you really think that you could convince a = customer that you are really providing them location privacy.
> If I were that customer, I would not be = convinced.
>
        =3D> = Well, up until this mail I thought there is some location
        privacy = support in the draft. However if there is a better
        way of = doing it, we're happy to consider it. I thought
        we = discussed this before IETF and found that it was difficult
        to = achieve complete location privacy with optimal routing ?
        Could you = elaborate on why you're not convinced ?

> I think that is everyone's point.
>
        =3D> = Everyone ? The only feedback I got until Minneapolis
        was that = (from the people that talked to me in private)
        Basic = mode provided some nice features for
        hiding = the LCoA. So I don't know who everyone
        is. =
        It's very = difficult when people make general statements
        like = these without explaining reasons and / or alternatives.
        I'd = appreciate some elaboration.

        Thanks,
        Hesham




------_=_NextPart_001_01C0BB77.CAB1B4C0-- From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 2 10:53:25 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13224 for ; Mon, 2 Apr 2001 10:53:24 -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 HAA02170; Mon, 2 Apr 2001 07:52:42 -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 HAA20745; Mon, 2 Apr 2001 07:52:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f32EpXIm018879 for ; Mon, 2 Apr 2001 07:51:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f32EpWP8018878 for mobile-ip-dist; Mon, 2 Apr 2001 07:51: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f32EpIIm018871 for ; Mon, 2 Apr 2001 07:51:18 -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 HAA24090 for ; Mon, 2 Apr 2001 07:51:18 -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 HAA13906 for ; Mon, 2 Apr 2001 07:51:17 -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 f32EpFs22364 for ; Mon, 2 Apr 2001 16:51:16 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Mon Apr 02 16:49:46 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Apr 2001 16:51:14 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBD1D@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Multiple tunnels over unoptimized route packets f or Extended mode Date: Mon, 2 Apr 2001 16:51:05 +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: Glenn, > As I recall, you have received numerous comments on the mailing list about it. > => The only one I remember was from you. Another from James saying that he liked Basic mode because of this feature. That's all I know of on the location privacy comments. > This constitutes feedback. As for alternatives, I suggest you look to what could be done at a router close to the CN. People seem to trust routers to route their packets, perhaps they should also trust them to hide their location. > => I'd love to get more cycles, but if people think it's interesting then I guess it'll come naturally. We've done the best we could given the requirements (min changes to MIPv6). If something better comes out, then people will vote for it. Thanks, Hesham > -----Original Message----- > From: Hesham Soliman (ERA) [ ] > Sent: Monday, April 02, 2001 2:26 AM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] Multiple tunnels over unoptimized route packets > f or Extended mode > > > Glenn, > > > Do you really think that you could convince a customer that you are really providing them location privacy. > > If I were that customer, I would not be convinced. > > > => Well, up until this mail I thought there is some location > privacy support in the draft. However if there is a better > way of doing it, we're happy to consider it. I thought > we discussed this before IETF and found that it was difficult > to achieve complete location privacy with optimal routing ? > Could you elaborate on why you're not convinced ? > > > I think that is everyone's point. > > > => Everyone ? The only feedback I got until Minneapolis > was that (from the people that talked to me in private) > Basic mode provided some nice features for > hiding the LCoA. So I don't know who everyone > is. > It's very difficult when people make general statements > like these without explaining reasons and / or alternatives. > I'd appreciate some elaboration. > > Thanks, > Hesham > > > > From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 2 10:54:16 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13312 for ; Mon, 2 Apr 2001 10:54: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 HAA02171; Mon, 2 Apr 2001 07:52: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 HAA24444; Mon, 2 Apr 2001 07:52:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f32EomIm018869 for ; Mon, 2 Apr 2001 07:50:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f32EomcN018868 for mobile-ip-dist; Mon, 2 Apr 2001 07: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f32EodIm018861 for ; Mon, 2 Apr 2001 07:50:39 -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 HAA23931 for ; Mon, 2 Apr 2001 07:50:39 -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 HAA00100 for ; Mon, 2 Apr 2001 07:50: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 HAA16101; Mon, 2 Apr 2001 07:50:37 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f32EoZr05180; Mon, 2 Apr 2001 07:50:35 -0700 X-mProtect: Mon, 2 Apr 2001 07:50: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(WTS.12.69) smtpdKlt9h3; Mon, 02 Apr 2001 07:50:19 PDT Message-ID: <3AC891AD.AB047119@iprg.nokia.com> Date: Mon, 02 Apr 2001 07:50:21 -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: Phil Neumiller CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] comments on draft-mkhalil-mobileip-ipv6-sap-00.txt References: <200104021115.HAA29975@ietf.org> <001701c0bb6e$d29746e0$6501a8c0@philneum> 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 Phil, I haven't read MK's draft, but some of your points are at odds with recent events, at least to my understanding. > 2). The MIP group is not qualified to make a security assesment of this draft. Who else has the time or charter to do it? > 3). Why should the security association between an MN and a CN be all > that much different from other types of clients and servers and peers > that run on the Internet? Why enmesh the security terminology with > MIP terminology? (cohesion is still a bad design choice after all these > years). Build a generalized solution for the Internet that MIP can use. Unfortunately, we've just been made very aware that Binding Updates _cannot_ use any generalized IPsec solution. This is a very long subject, but the very short version is that existing implementations cannot do the right thing according to the way they look up entries in their SPDs. > 5). Can't a security association be used for all sorts of other good stuff besides > MIP binding updates (related to 2 above). Apparently not! > I believe this type of work needs to be reviewed in the MIP WG after it > goes through some severe scrutiny in the security area where there > are domain experts in security. Most people in the MIP WG want > mobile security in the worse way, but are not security domain experts. But we have some examples to work from. For instance, RFC 2002 has enough security to make Mobile IPv4 work. I think after the current round of fulfilling IESG design requirements, we'll have a couple of other useful tools in the closet. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 2 12:38:29 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19320 for ; Mon, 2 Apr 2001 12:38:28 -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 JAA13015; Mon, 2 Apr 2001 09:38:01 -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 JAA09896; Mon, 2 Apr 2001 09:37:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f32GaQIm019151 for ; Mon, 2 Apr 2001 09:36:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f32GaPFM019150 for mobile-ip-dist; Mon, 2 Apr 2001 09:36: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.Beta5+Sun/8.12.0.Beta5) with ESMTP id f32GaGIm019143 for ; Mon, 2 Apr 2001 09:36:16 -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 JAA09472 for ; Mon, 2 Apr 2001 09:36:16 -0700 (PDT) Received: from c007.snv.cp.net (c007-h008.c007.snv.cp.net [209.228.33.214]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA20508 for ; Mon, 2 Apr 2001 10:36:15 -0600 (MDT) Received: (cpmta 22267 invoked from network); 2 Apr 2001 09:34:12 -0700 Received: from unknown (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.214) with SMTP; 2 Apr 2001 09:34:12 -0700 X-Sent: 2 Apr 2001 16:34:12 GMT Message-ID: <005701c0bb92$98ca7bc0$6501a8c0@philneum> From: "Phil Neumiller" To: "Haseeb Akhtar" , References: Subject: Re: [mobile-ip] comments on draft-mkhalil-mobileip-ipv6-sap-00.tx t Date: Mon, 2 Apr 2001 11:33:00 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0053_01C0BB68.ABE55420" 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: This is a multi-part message in MIME format. ------=_NextPart_000_0053_01C0BB68.ABE55420 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: [mobile-ip] comments on draft-mkhalil-mobileip-ipv6-sap-00.txtHello Haseeb, Some comments below. ----- Original Message ----- From: Haseeb Akhtar To: 'mobile-ip@sunroof.eng.sun.com' Cc: 'Phil Neumiller' Subject: RE: [mobile-ip] comments on draft-mkhalil-mobileip-ipv6-sap-00.tx t Comments below. -----Original Message----- From: Phil Neumiller [mailto:neumiller@telocity.com] To: mobile-ip 1). This draft belongs in the security working area of the IETF. 2). The MIP group is not qualified to make a security assesment of this draft. => I will let the co-chairs/AD decide that. As far as we know, the WG is looking In the IETF, the chairs are to guage the WG consensus on issues not make decisions like this. => for a security solution for IPv6. The IESG also has specifically requested => for such in the mailing list. A lot of discussions for last few days, => too, has been around this very topic. This is good. Which list are your referring to BTW? 3). Why should the security association between an MN and a CN be all that much different from other types of clients and servers and peers that run on the Internet? Why enmesh the security terminology with MIP terminology? (cohesion is still a bad design choice after all these years). Build a generalized solution for the Internet that MIP can use. => Since this is MIP WG and we are particularly concerned about a problem => that involves CN and MN and this interface happens to use Binding Update / => Binding Request etc. That is fine. What I suggest is that use your draft as a requirements document and feed it to the security working group and let them work on solutions. The MIP WG is not qualified to perform crypt-analysis and build crypto-graphically strong systems nor is it chartred to do so. This is a waist of everybodies time on this list. 4). In the Abstract, How fast is "fast"? What is the baseline? => Phil, if you feel comfortable, we can take out the reference to "fast" from => the draft in the next revision. Our objective was to propose a baseline solution => to the security problems of IPv6. On less you have some kind of baseline its a marketing term. 5). Can't a security association be used for all sorts of other good stuff besides MIP binding updates (related to 2 above). => Of course, it can. The main question, however, does the proposed scheme satisfy => dissatisfy the requirements of this WG. What are the requirements of this WG? Where are those documented? 6). As for the rest of the draft, I saw no references to the specific Diffie Hellman work you were applying, no references to patents you were using (expired or not), I saw one vague reference to some of Charlie's work, I am supposed to believe that this work will lead to something cryptographically secure? => That is an oversight. We will include all the references in the next version. => I'm not aware of any patent that needed to be used. Any help in this regard => will be appreciated. Diffie Hellman public key exchange was patented and the rites were owned by RSA part of pkix and some of these patents expired a few years back. I am very surprised by your question and again, I believe this work belongs in a security WG. I believe this type of work needs to be reviewed in the MIP WG after it goes through some severe scrutiny in the security area where there are domain experts in security. => Agreed. Good then, could the name of the draft be changed to "req" for requirements. This is the way the AAA work in the MIP WG is proceeding. Most people in the MIP WG want mobile security in the worse way, but are not security domain experts. Best Regards, Phil ------=_NextPart_000_0053_01C0BB68.ABE55420 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] comments on = draft-mkhalil-mobileip-ipv6-sap-00.txt
Hello Haseeb,
 
Some comments below.
 
----- Original Message -----=20
From: Haseeb=20 Akhtar
Subject: RE: [mobile-ip] comments on=20 draft-mkhalil-mobileip-ipv6-sap-00.tx t

Comments below.

-----Original Message-----
From: Phil=20 Neumiller [mailto:neumiller@telocity.com]= =20
To: mobile-ip
1).  = This draft=20 belongs in the security working area of the IETF.

2).  The MIP group is not qualified to make a = security=20 assesment of this draft.

=3D> I will let the co-chairs/AD decide that. As = far as we=20 know, the WG is looking

 

In the IETF, the chairs are to guage the WG consensus = on issues=20 not make

decisions like this.


=3D> for a security solution for IPv6. The IESG also has = specifically=20 requested
=3D> for such in the mailing = list. A lot of=20 discussions for last few days,
=3D> too, = has been=20 around this very topic.

This is good.  Which list are your referring to=20 BTW?

3).  Why should the security association between = an MN and=20 a CN be all
       that=20 much different from other types of clients and servers and peers=20
       that run on the=20 Internet?  Why enmesh the security terminology with =
       MIP terminology?  = (cohesion is=20 still a bad design choice after all these
        years).  Build = a=20 generalized solution for the Internet that MIP can use.

=3D> Since this is MIP WG and we are particularly = concerned=20 about a problem
=3D> that involves CN and = MN and this=20 interface happens to use Binding Update /
=3D> Binding=20 Request etc.

That is fine.  What I suggest is that use your = draft as a=20 requirements document

and feed it to the security working group and let them = work on=20 solutions.  The

MIP WG is not qualified to perform crypt-analysis and = build=20 crypto-graphically

strong systems nor is it chartred to do so.  This = is a=20 waist of everybodies time

on this list.

4).  In the Abstract,  How fast is = "fast"?  What=20 is the baseline?

=3D> Phil, if you feel comfortable, we can take out = the=20 reference to "fast" from
=3D> the draft in = the next=20 revision. Our objective was to propose a baseline solution =
=3D> to the security problems of IPv6.

On less you have some kind of baseline its a marketing = term.

5).  Can't a security association be used for all = sorts of=20 other good stuff besides
       MIP binding updates = (related to 2=20 above).

=3D> Of course, it can. The main question, however, = does the=20 proposed scheme satisfy
=3D> dissatisfy the = requirements of this WG.

What are the requirements of this WG?  Where are = those=20 documented?

6).  As for the rest of the draft, I saw no = references to=20 the specific Diffie Hellman
       work you were applying, no = references to patents you were using (expired
       or not), I saw one vague = reference=20 to some of Charlie's work, I am
       supposed to believe that = this work=20 will lead to something cryptographically
       secure?

=3D> That is an oversight. We will include all the = references=20 in the next version.
=3D> I'm not aware of = any patent=20 that needed to be used. Any help in this regard
=3D>=20 will be appreciated.

Diffie Hellman public key exchange was patented and = the rites=20 were

owned by RSA part of pkix and some of these patents = expired a=20 few years back.

I am very surprised by your question and again, I = believe this=20 work belongs in

a security WG.

       I believe this = type of work=20 needs to be reviewed in the MIP WG after it
       goes through some severe = scrutiny in=20 the security area where there
       are domain experts in=20 security. 

=3D> Agreed.

Good then, could the name of the draft be changed to = "req" for=20 requirements.

This is the way the AAA work in the MIP WG is=20 proceeding.

       Most people in = the MIP WG=20 want
       = mobile=20 security in the worse way, but are not security domain experts. =


Best Regards,

Phil

 

------=_NextPart_000_0053_01C0BB68.ABE55420-- From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 2 12:40:58 2001 Received: from saturn.sun.com ([192.9.25.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19543 for ; Mon, 2 Apr 2001 12:40:58 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06975; Mon, 2 Apr 2001 09:29: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 JAA28176; Mon, 2 Apr 2001 09:02:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f32G1dIm019066 for ; Mon, 2 Apr 2001 09:01:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f32G1cuP019065 for mobile-ip-dist; Mon, 2 Apr 2001 09:01: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.Beta5+Sun/8.12.0.Beta5) with ESMTP id f32G1TIm019058 for ; Mon, 2 Apr 2001 09:01: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 JAA09562 for ; Mon, 2 Apr 2001 09:01:29 -0700 (PDT) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA01447 for ; Mon, 2 Apr 2001 09:01:27 -0700 (PDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Mon, 2 Apr 2001 10:22:15 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Apr 2001 10:21:57 -0500 Message-ID: From: "Haseeb Akhtar" To: "'mobile-ip@sunroof.eng.sun.com'" Cc: "'Phil Neumiller'" Subject: RE: [mobile-ip] comments on draft-mkhalil-mobileip-ipv6-sap-00.tx t Date: Mon, 2 Apr 2001 10:21:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0BB88.A1E21AB0" Sender: owner-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_01C0BB88.A1E21AB0 Content-Type: text/plain; charset="iso-8859-1" Comments below. -----Original Message----- From: Phil Neumiller [mailto:neumiller@telocity.com] Sent: Monday, April 02, 2001 7:17 AM To: mobile-ip Subject: [mobile-ip] comments on draft-mkhalil-mobileip-ipv6-sap-00.txt Hello, 1). This draft belongs in the security working area of the IETF. 2). The MIP group is not qualified to make a security assesment of this draft. => I will let the co-chairs/AD decide that. As far as we know, the WG is looking => for a security solution for IPv6. The IESG also has specifically requested => for such in the mailing list. A lot of discussions for last few days, => too, has been around this very topic. 3). Why should the security association between an MN and a CN be all that much different from other types of clients and servers and peers that run on the Internet? Why enmesh the security terminology with MIP terminology? (cohesion is still a bad design choice after all these years). Build a generalized solution for the Internet that MIP can use. => Since this is MIP WG and we are particularly concerned about a problem => that involves CN and MN and this interface happens to use Binding Update / => Binding Request etc. 4). In the Abstract, How fast is "fast"? What is the baseline? => Phil, if you feel comfortable, we can take out the reference to "fast" from => the draft in the next revision. Our objective was to propose a baseline solution => to the security problems of IPv6. 5). Can't a security association be used for all sorts of other good stuff besides MIP binding updates (related to 2 above). => Of course, it can. The main question, however, does the proposed scheme satisfy => dissatisfy the requirements of this WG. 6). As for the rest of the draft, I saw no references to the specific Diffie Hellman work you were applying, no references to patents you were using (expired or not), I saw one vague reference to some of Charlie's work, I am supposed to believe that this work will lead to something cryptographically secure? => That is an oversight. We will include all the references in the next version. => I'm not aware of any patent that needed to be used. Any help in this regard => will be appreciated. I believe this type of work needs to be reviewed in the MIP WG after it goes through some severe scrutiny in the security area where there are domain experts in security. => Agreed. Most people in the MIP WG want mobile security in the worse way, but are not security domain experts. => We try to address the problems that are part of this WG. Best Regards, Phil => Regards, => Haseeb ------_=_NextPart_001_01C0BB88.A1E21AB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] comments on = draft-mkhalil-mobileip-ipv6-sap-00.txt

Comments below.

-----Original Message-----
From: Phil Neumiller [mailto:neumiller@telocity.com= ]
Sent: Monday, April 02, 2001 7:17 AM
To: mobile-ip
Subject: [mobile-ip] comments on = draft-mkhalil-mobileip-ipv6-sap-00.txt


Hello,

1).  This draft belongs in the security working = area of the IETF.

2).  The MIP group is not qualified to make a = security assesment of this draft.

=3D> I will let the co-chairs/AD decide that. As = far as we know, the WG is looking
=3D> for a security solution for IPv6. The IESG = also has specifically requested
=3D> for such in the mailing list. A lot of = discussions for last few days,
=3D> too, has been around this very topic.

3).  Why should the security association between = an MN and a CN be all
       that much = different from other types of clients and servers and peers
       that run on the = Internet?  Why enmesh the security terminology with
       MIP = terminology?  (cohesion is still a bad design choice after all = these
        = years).  Build a generalized solution for the Internet that MIP = can use.

=3D> Since this is MIP WG and we are particularly = concerned about a problem
=3D> that involves CN and MN and this interface = happens to use Binding Update /
=3D> Binding Request etc.

4).  In the Abstract,  How fast is = "fast"?  What is the baseline?

=3D> Phil, if you feel comfortable, we can take = out the reference to "fast" from
=3D> the draft in the next revision. Our = objective was to propose a baseline solution
=3D> to the security problems of IPv6.

5).  Can't a security association be used for = all sorts of other good stuff besides
       MIP binding = updates (related to 2 above).

=3D> Of course, it can. The main question, = however, does the proposed scheme satisfy
=3D> dissatisfy the requirements of this = WG.

6).  As for the rest of the draft, I saw no = references to the specific Diffie Hellman
       work you were = applying, no references to patents you were using (expired
       or not), I saw = one vague reference to some of Charlie's work, I am
       supposed to = believe that this work will lead to something cryptographically
       secure?

=3D> That is an oversight. We will include all the = references in the next version.
=3D> I'm not aware of any patent that needed to = be used. Any help in this regard
=3D> will be appreciated.

       I believe this = type of work needs to be reviewed in the MIP WG after it
       goes through = some severe scrutiny in the security area where there
       are domain = experts in security. 

=3D> Agreed.

       Most people in = the MIP WG want
       mobile security = in the worse way, but are not security domain experts.

=3D> We try to address the problems that are part = of this WG.


Best Regards,

Phil

=3D> Regards,

=3D> Haseeb

------_=_NextPart_001_01C0BB88.A1E21AB0-- From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 2 12:53:01 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20224 for ; Mon, 2 Apr 2001 12:53: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 JAA21101; Mon, 2 Apr 2001 09:39: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 JAA18592; Mon, 2 Apr 2001 09:39:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f32GbPIm019163 for ; Mon, 2 Apr 2001 09:37:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f32GbOjh019162 for mobile-ip-dist; Mon, 2 Apr 2001 09:37:24 -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.Beta5+Sun/8.12.0.Beta5) with ESMTP id f32GbAIm019155 for ; Mon, 2 Apr 2001 09:37:10 -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 JAA28951 for ; Mon, 2 Apr 2001 09:37:10 -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 JAA22642 for ; Mon, 2 Apr 2001 09:37: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 JAA24419 for ; Mon, 2 Apr 2001 09:34:04 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f32GY3k01061 for ; Mon, 2 Apr 2001 09:34:03 -0700 X-mProtect: Mon, 2 Apr 2001 09:34:03 -0700 Nokia Silicon Valley Messaging Protection Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "cs.ucl.ac.uk") by darkstar.iprg.nokia.com(WTS.12.69) smtpdDJ9LKi; Mon, 02 Apr 2001 09:33:44 PDT Message-ID: <3AC8A9E8.D0FF602D@cs.ucl.ac.uk> Date: Mon, 02 Apr 2001 09:33:44 -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] Multiple tunnels over unoptimized route packets f or Extended mode References: <034BEFD03799D411A59F00508BDF7546013DBD0A@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 > Hi Hesham, > > > (2) the MN with respect to the world is definetely not hidden. Remember that upstream > > you send packet with your src addr as the LCoA as the egress filtering won't let you out. > > Also you do not specify anywhere that upstream data packets have the source addr as the > > RCoA, and you know very well why. > > > => I suggest you read rev 3 of the draft which was sent to the list > before IETF. If you're new to the list and didn't get it then > you'll see it soon on the WG page after submission. I could do without your patronizing style about revisions on drafts. It seems that every other week you like to invalidate your previous draft and then call people 'newcomers' because Claude may have a new version out. It does not give much credibility to the draft to rush out some draft before the deadline only to say "we have corrected some problem" a week after (pretty serious if you ask me) and then have a new version that often. Please spare me with this kind of style please? This is BTW bad form of elaboration... > > > The MN can certainly send packets with RCOA > provided the network administrators allow it. > This is explained in rev 3 which is currently > on Claud's page and will be on the MIP WG > page this week. > ok..this is a very good assumption...It is like saying in the future pigs will fly provided that they are allocated some wings by god...you expect to convince the community with that???? > > > > > > > > I need not emphasize further as negative point of Basic mode, that the generation of > > > > multiple RCoA for MN so as to sustain unique representation of the MN in the visited > > > > domain, while you have a unique Home Addr already at hand (but you don't divulge that > > > > to the MAP - I wonder why???) is also bound to find problems: > > > > > > > > 1) by the management of MANY RCoA for no apparent reason > > > > > > > => Where does MANY come from ? Only one is needed. > > > or does MANY = MANY MNs ? If so how is it different > > > in the HA case. > > > > ok back to the spec. The basic mode mentions that an MN is receiving the MAPs prefix and > > creates a CoA. This is the RCoA that is sent back for DAD to the MAP. I can only assume > > that each MN will create a different RCoA in Basic mode, since this is the entry in the > > home addr option B-Cache of the MAP. THAT MUST BE UNIQUE and thus one per MN. That implies > > if X is the number of registering MNs with THAT MAP then X will be the number of > > DIFFERENT RCoAs in the B-Cache of THAT MAP. This is of course unless all MNs conspire and > > produce one RCoA but then the B-Cache in that MAP is useless.... > > > => Did you see my last sentence ? How is this different > from what an HA has to do ? > I think I saw your last sentence pretty well thanks VERY much. The question is can you read my comments or do you stop past the second sentence.....Well it is pretty different. When you have to manage on top of the B-Cache an extra set of RCoAs and do same amount of times DAD then it gives just a tiny bit more work to the box. But that doesn't bother you at all..does it...when it comes to count by the millions at the VISITED domain (since the home domain will only contribute a small portion to that , i.e. aggregation of contributing MN from the distributed home domain...then perhaps you will see what I mean...but then it will be too late .... > > > > > > > > > > > 2) DAD checks by the hunderds for no apparent reason > > > > > > > => hundreds ? where does a hundred come from ? > > > You mean hundreds of MNs ? Actually there > > > maybe hundreds of thousands ! But the same goes > > > for the HA. > > > > > > > According to the above reasoning you will have as many DADs as RCoAs for the X number of > > MNs registering under that MAP. > > > => Did you see my last sentence ? How is it different > from what an HA has to do ? > > > > > > > > If however the Basic mode is destined for fixed MAPs then, all I am crying out loud > > > > is that when route unoptimized packets leaving from the MN's HA (when that HA has not > > > > received a BU from the MN because it awaits its MR/MAP to get its own LCoA in the > > > > mean time) > > > > > > > => Let me get this right. You're saying the MN's HA already has a binding > > > for the MN. This binding was based on the MN's previous location (before > > > it appeared on the MR's subnet) Correct ? > > > > No the binding in the MN's HA maintain (at that moment in time) the last IP address (the > > last LCoA) of the MR/MAP before it flew off. > > > => So the HA has a binding for an address that is no longer > valid. Ie. can not be used to reach the MN. So the MN > is unreachable. > But somehow what you say above contradicts what you say > below "That is the thing I am not talking about upstream packets > (the MN is still waiting on the MR/MAP/HMIPv6) to get its own LCoA > and attach on a subnet. so no BU to it HA yet..." Yes...you got that right...the MN is unreachable BUT the packet is destined to the IP addr of the MR/MAP...which is away...what would you expect the HA of the MR/MAP to do??? > > > > If the MN doesn't / can't send another BU to its HA because it doesn't > > > have the MR/MAP's address or because the MR disappeared (ie. no > > > connectivity) then packets from its HA will be delivered to the old > > > address, ie. lost. > > > > > > > Nooooooooope.... remember that in extende mode you have given to the MN's HA the IP > > address of the MR/MAP in that MR/MAP home domain. > > > => If I understand your scenario, you're assuming there is another > MAP (fixed). In that case that's the address you give to the HA > NOT the MR's LCoA. > If the MR disappeared, then the "further" MAP will not be able to > route packets to the MN unless it gets another BU. If you do that then you are breaking your assumption about distance on the RT advert and the MAP options. Shortest distance is what gets picked by the MN > > > > Now the MR/MAP has flown off. So as far as the protocol is concerned the MR/MAP is just > > another HMIPv6 node. So what does that node do. It provides to its HA (that is the > > MR/MAP's HA) its latest binding. > > > => No it doesn't have to be the MR's HA. Unless the MN's > HA = MR's HA. If the MR does not provide its RCoA to its HA then what does it provide to it? nothing???? this breaks basic mobility....if it happens... > > > > This MUST be a RCoA since it registers with fixed MAP. So > > the HA of the MR/MAP/HMIPv6 node will now intercept all packets that come on its IP > > address. That includes all packets that arrive tunneled from the MN's HA according that > > the aformentioned binding. That is the old IP address of the MR/MAP as the alt-CoA for the > > MN BEFORE the MR/MAP/HMIPv6 node flew off !!!!!!!!!!!! > > > => I think (I'm trying very hard to understand what you're saying) that > you're assuming that the MN sends a BU to its HA including the > MR's Home address (ie. the MR's address that is on the MN's side). > This is not what the draft says. It says that the MN binds > it's home address to the "further" MAP's address (in its HA > BU) , and the MR's LCoA is used with that further MAP. > More on the address later. > > So: > HA_BU (Home_address, RCoA) RCoA is the "further" MAP's address in > the extended mode case or the address on the "further" MAP's subnet > in Basic mode. Yes but this "further" contradicts what you specify as the MAP option with the shortest distance will get picked up by the MN. I am saying that be cause if you have 3 fixed MAP one below the other then you do not have any measure to pick the "further" one that you say...it can be ANY of the above the first one. If you are not clear in the spec on that I have to assume the shortest one wins.... > > MAP_BU (MR's LCoA, Home address (Extended mode) or RCoA in Basic mode) > The MAP_BU is the BU sent to the "further" MAP. If there is > no "further" MAP upstream, then the MR is essentially like an FA and > the MR's LCoA is sent directly to the HA. No...there are two things that MUST be done here as far as the MR/MAP is concerned (much like any HMIPv6 node) 1. register with a fixed MAP. This is the MAP_BU that you mentioned. Fine 2. Send a BU back to its HA to inform it where it is. HOW ABOUT THAT???? > > > So based on this, the packets addressed to the MN can NOT > be received by the MR's HA, unless the MR's HA = MN HA. No no no no no....the packets sent by the HA of the MN were originally tunneled to the alt-CoA of the MN. But what was it at the time ???? It was the IP addr (LCoA) of the MR/MAP before it flew of... As a result because the MR/MAP has gone away the packets MUST be intercepted naturally (base mobility here) by the HA of the MR/MAP.... > > > The MN's HA will tunnel packets to the CoA in its Binding > Cache. That CoA is NOT the MR's Home address. > It is either, the RCoA (if a further MAP exists) or the MR's > CoA if no other (further) MAPs exist. OK ? Right ...there are no other further MAPs, so it is MR's LCoA...but this it's home addr at the home domain...so what more natural for any packets that arrive to that address when the MR is not there to be intercepted and retunneled by its HA......???????? > > > > => Then the MR's HA should never receive the MN's traffic. > It is not that MR's HA will receive MN's traffic but it will have to intercept it and retunnel to the RCoA of the MR.... > => I don't know how much more I have to say to explain that > the MR's HA will NOT receive _the_MN's traffic. > Where does the draft say that ? > Pick that part of the draft and send it to the list. If you can find it > we'lll change it to reflect what I just told you. It does not say it....but it does not have to ....it is natural logic as soon as the MR goes away and packets are coming to its LCoA at its home domain... > > > If the MN sends the BUs I showed above, and then the MR > (MAP) disappears then it has to update the fixed MAP > with a new LCoA. Otherwise it's not reachable. > > > > Packets from the CN to the MN will be tunnelled by the MN's > > > HA to the CoA in the Binding Cache. If there is no entry > > > there is no tunnelling. If there is an entry that is no longer > > > valid (because the MN moved) the HA will comtinue tunnelling > > > to that CoA in the Binding Cache regardless, until it's > > > given a new CoA. I really can't see how the scenario you're > > > describing is possible. > > > > > > Yes but what is the > > CoA......????????????????????????????????????????????????????????????????????????? > > the IP addr of the MR/MAP/HMIPv6 node...so the packet will arrive somewhere and will be > > encapsulated again as soon as the HA for that MR/MAP/HMIPv6 intercepts them... > > > => NO. It's the LCoA of the MR.The one advertised in its > MAP option. The one it formed from the RA received from > the visited AR or the local DHCP server. > The one that belongs to the visited domain and not the > Home domain. That one. Yes and I agreee TOTALY with you...what is that LCoA at the home domain of the MR...????? > > > Therefore packets can never be sent to the MR's HA, unless > it is the same HA as the MN's. Which, as you said, is not the > scenario you're describing. Theo UCL / Mobile Systems From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 2 12:56:43 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20456 for ; Mon, 2 Apr 2001 12:56:42 -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 JAA28738; Mon, 2 Apr 2001 09:56: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 JAA23086; Mon, 2 Apr 2001 09:55:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f32Gs2Im019318 for ; Mon, 2 Apr 2001 09:54:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f32Gs2xI019317 for mobile-ip-dist; Mon, 2 Apr 2001 09: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f32GrrIm019310 for ; Mon, 2 Apr 2001 09:53:53 -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 JAA03655 for ; Mon, 2 Apr 2001 09:53:53 -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 JAA26750 for ; Mon, 2 Apr 2001 09:53:52 -0700 (PDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Mon, 2 Apr 2001 12:48:40 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] I-D ACTION:draft-mkhalil-mobileip-ipv6-sap-00.txt Date: Mon, 2 Apr 2001 12:48:37 -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 folks, Raj and I have been working with the IESG on how to go forward with securing MIP v6 binding updates. We expect to have a statement for the working group by the end of the day. Phil > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Monday, April 02, 2001 7:16 AM > Cc: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] I-D ACTION:draft-mkhalil-mobileip-ipv6-sap-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Dynamic Security Association > Establishment Protcol For > IPv6 > Author(s) : M. Khalil, H. Akhtar, E. Qaddoura > Filename : draft-mkhalil-mobileip-ipv6-sap-00.txt > Pages : 14 > Date : 30-Mar-01 > > A protocol is proposed to allow a fast establishment of Security > Association between the Mobile Node (MN) and Correspondent Node (CN). > Once this Security Association is established, it can be used to > authenticate any Binding Update between the MN and the CN. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mkhalil-mobileip-ipv 6-sap-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-mkhalil-mobileip-ipv6-sap-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-mkhalil-mobileip-ipv6-sap-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 2 12:57:25 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20527 for ; Mon, 2 Apr 2001 12:57: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 JAA29938; Mon, 2 Apr 2001 09:57: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 JAA04721; Mon, 2 Apr 2001 09:57:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f32GtcIm019328 for ; Mon, 2 Apr 2001 09:55:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f32GtcSP019327 for mobile-ip-dist; Mon, 2 Apr 2001 09:55: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f32GtSIm019320 for ; Mon, 2 Apr 2001 09:55:28 -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 JAA04098 for ; Mon, 2 Apr 2001 09:55:28 -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 JAA28232 for ; Mon, 2 Apr 2001 09:55:27 -0700 (PDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Mon, 2 Apr 2001 12:50:15 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] comments on draft-mkhalil-mobileip-ipv6-sap-00.tx t Date: Mon, 2 Apr 2001 12:50:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0BB94.FD9986E8" Sender: owner-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_01C0BB94.FD9986E8 Content-Type: text/plain; charset="iso-8859-1" Before you go too far down the road debating what should and shouldn't (or will and won't) be done by this working group, it might be better to wait on the statement we're working on about how to proceed with securing MIP v6 binding updates which should be out by the end of the day. -----Original Message----- From: Phil Neumiller [mailto:neumiller@telocity.com] Sent: Monday, April 02, 2001 12:33 PM To: Haseeb Akhtar; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] comments on draft-mkhalil-mobileip-ipv6-sap-00.tx t Hello Haseeb, Some comments below. ----- Original Message ----- From: Haseeb Akhtar To: 'mobile-ip@sunroof.eng.sun.com' Cc: 'Phil Neumiller' Subject: RE: [mobile-ip] comments on draft-mkhalil-mobileip-ipv6-sap-00.tx t Comments below. -----Original Message----- From: Phil Neumiller [ mailto:neumiller@telocity.com ] To: mobile-ip 1). This draft belongs in the security working area of the IETF. 2). The MIP group is not qualified to make a security assesment of this draft. => I will let the co-chairs/AD decide that. As far as we know, the WG is looking In the IETF, the chairs are to guage the WG consensus on issues not make decisions like this. => for a security solution for IPv6. The IESG also has specifically requested => for such in the mailing list. A lot of discussions for last few days, => too, has been around this very topic. This is good. Which list are your referring to BTW? 3). Why should the security association between an MN and a CN be all that much different from other types of clients and servers and peers that run on the Internet? Why enmesh the security terminology with MIP terminology? (cohesion is still a bad design choice after all these years). Build a generalized solution for the Internet that MIP can use. => Since this is MIP WG and we are particularly concerned about a problem => that involves CN and MN and this interface happens to use Binding Update / => Binding Request etc. That is fine. What I suggest is that use your draft as a requirements document and feed it to the security working group and let them work on solutions. The MIP WG is not qualified to perform crypt-analysis and build crypto-graphically strong systems nor is it chartred to do so. This is a waist of everybodies time on this list. 4). In the Abstract, How fast is "fast"? What is the baseline? => Phil, if you feel comfortable, we can take out the reference to "fast" from => the draft in the next revision. Our objective was to propose a baseline solution => to the security problems of IPv6. On less you have some kind of baseline its a marketing term. 5). Can't a security association be used for all sorts of other good stuff besides MIP binding updates (related to 2 above). => Of course, it can. The main question, however, does the proposed scheme satisfy => dissatisfy the requirements of this WG. What are the requirements of this WG? Where are those documented? 6). As for the rest of the draft, I saw no references to the specific Diffie Hellman work you were applying, no references to patents you were using (expired or not), I saw one vague reference to some of Charlie's work, I am supposed to believe that this work will lead to something cryptographically secure? => That is an oversight. We will include all the references in the next version. => I'm not aware of any patent that needed to be used. Any help in this regard => will be appreciated. Diffie Hellman public key exchange was patented and the rites were owned by RSA part of pkix and some of these patents expired a few years back. I am very surprised by your question and again, I believe this work belongs in a security WG. I believe this type of work needs to be reviewed in the MIP WG after it goes through some severe scrutiny in the security area where there are domain experts in security. => Agreed. Good then, could the name of the draft be changed to "req" for requirements. This is the way the AAA work in the MIP WG is proceeding. Most people in the MIP WG want mobile security in the worse way, but are not security domain experts. Best Regards, Phil ------_=_NextPart_001_01C0BB94.FD9986E8 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] comments on draft-mkhalil-mobileip-ipv6-sap-00.txt
 
Before you go too far down the road debating what should and shouldn't (or will and won't) be done by this working group, it might be better to wait on the statement we're working on about how to proceed with securing MIP v6 binding updates which should be out by the end of the day.
 
 
-----Original Message-----
From: Phil Neumiller [mailto:neumiller@telocity.com]
Sent: Monday, April 02, 2001 12:33 PM
To: Haseeb Akhtar; mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] comments on draft-mkhalil-mobileip-ipv6-sap-00.tx t

Hello Haseeb,
 
Some comments below.
 
----- Original Message -----
Subject: RE: [mobile-ip] comments on draft-mkhalil-mobileip-ipv6-sap-00.tx t

Comments below.

-----Original Message-----
From: Phil Neumiller [mailto:neumiller@telocity.com]
To: mobile-ip
1).  This draft belongs in the security working area of the IETF.

2).  The MIP group is not qualified to make a security assesment of this draft.

=> I will let the co-chairs/AD decide that. As far as we know, the WG is looking

 

In the IETF, the chairs are to guage the WG consensus on issues not make

decisions like this.


=> for a security solution for IPv6. The IESG also has specifically requested
=> for such in the mailing list. A lot of discussions for last few days,
=> too, has been around this very topic.

This is good.  Which list are your referring to BTW?

3).  Why should the security association between an MN and a CN be all
       that much different from other types of clients and servers and peers
       that run on the Internet?  Why enmesh the security terminology with
       MIP terminology?  (cohesion is still a bad design choice after all these
        years).  Build a generalized solution for the Internet that MIP can use.

=> Since this is MIP WG and we are particularly concerned about a problem
=> that involves CN and MN and this interface happens to use Binding Update /
=> Binding Request etc.

That is fine.  What I suggest is that use your draft as a requirements document

and feed it to the security working group and let them work on solutions.  The

MIP WG is not qualified to perform crypt-analysis and build crypto-graphically

strong systems nor is it chartred to do so.  This is a waist of everybodies time

on this list.

4).  In the Abstract,  How fast is "fast"?  What is the baseline?

=> Phil, if you feel comfortable, we can take out the reference to "fast" from
=> the draft in the next revision. Our objective was to propose a baseline solution
=> to the security problems of IPv6.

On less you have some kind of baseline its a marketing term.

5).  Can't a security association be used for all sorts of other good stuff besides
       MIP binding updates (related to 2 above).

=> Of course, it can. The main question, however, does the proposed scheme satisfy
=> dissatisfy the requirements of this WG.

What are the requirements of this WG?  Where are those documented?

6).  As for the rest of the draft, I saw no references to the specific Diffie Hellman
       work you were applying, no references to patents you were using (expired
       or not), I saw one vague reference to some of Charlie's work, I am
       supposed to believe that this work will lead to something cryptographically
       secure?

=> That is an oversight. We will include all the references in the next version.
=> I'm not aware of any patent that needed to be used. Any help in this regard
=> will be appreciated.

Diffie Hellman public key exchange was patented and the rites were

owned by RSA part of pkix and some of these patents expired a few years back.

I am very surprised by your question and again, I believe this work belongs in

a security WG.

       I believe this type of work needs to be reviewed in the MIP WG after it
       goes through some severe scrutiny in the security area where there
       are domain experts in security. 

=> Agreed.

Good then, could the name of the draft be changed to "req" for requirements.

This is the way the AAA work in the MIP WG is proceeding.

       Most people in the MIP WG want
       mobile security in the worse way, but are not security domain experts.


Best Regards,

Phil

 

------_=_NextPart_001_01C0BB94.FD9986E8-- From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 2 14:58:03 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26191 for ; Mon, 2 Apr 2001 14:58:02 -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 LAA12482; Mon, 2 Apr 2001 11:57:28 -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 LAA05156; Mon, 2 Apr 2001 11:57:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f32ItrIm019556 for ; Mon, 2 Apr 2001 11:55:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f32ItqBI019555 for mobile-ip-dist; Mon, 2 Apr 2001 11:55:52 -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.Beta5+Sun/8.12.0.Beta5) with ESMTP id f32IthIm019548 for ; Mon, 2 Apr 2001 11:55:43 -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 LAA04754 for ; Mon, 2 Apr 2001 11:55:42 -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 LAA27472 for ; Mon, 2 Apr 2001 11:55:42 -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.9.3/8.9.1) with ESMTP id LAA12162 for ; Mon, 2 Apr 2001 11:55:46 -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 ADK04077; Mon, 2 Apr 2001 11:55:41 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA04660; Mon, 2 Apr 2001 11:55:41 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15048.52013.547909.706787@thomasm-u1.cisco.com> Date: Mon, 2 Apr 2001 11:55:41 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Multiple tunnels over unoptimized route packets f or Extended mode In-Reply-To: <034BEFD03799D411A59F00508BDF7546013DBD0F@esealnt448.al.sw.ericsson.se> References: <034BEFD03799D411A59F00508BDF7546013DBD0F@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, Location privacy is only as good as the weakest link. I'm somewhat doubtful that mobile IP is that link; it's much more likely to be the applications running on top. For calling privacy, for example, we've been through this many times and it all really boils down to if you want to do it right, you need an application layer anonymizer. For SIP, that means doing a back to back UA, for email, that mean anonymous remailers, etc, etc. Anything less is probably not going to cut it, especially if you have to meet legal tests. Mike Hesham Soliman (ERA) writes: > Glenn, > > > Do you really think that you could convince a customer that you are really providing them location privacy. > > If I were that customer, I would not be convinced. > > > => Well, up until this mail I thought there is some location > privacy support in the draft. However if there is a better > way of doing it, we're happy to consider it. I thought > we discussed this before IETF and found that it was difficult > to achieve complete location privacy with optimal routing ? > Could you elaborate on why you're not convinced ? > > > I think that is everyone's point. > > > => Everyone ? The only feedback I got until Minneapolis > was that (from the people that talked to me in private) > Basic mode provided some nice features for > hiding the LCoA. So I don't know who everyone > is. > It's very difficult when people make general statements > like these without explaining reasons and / or alternatives. > I'd appreciate some elaboration. > > Thanks, > Hesham > > > > From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 2 15:19:58 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26586 for ; Mon, 2 Apr 2001 15:19: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 MAA28988; Mon, 2 Apr 2001 12:19: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 MAA21793; Mon, 2 Apr 2001 12:19:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f32JHpIm019658 for ; Mon, 2 Apr 2001 12:17:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f32JHpN3019657 for mobile-ip-dist; Mon, 2 Apr 2001 12:17: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f32JHgIm019650 for ; Mon, 2 Apr 2001 12:17: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 MAA09395 for ; Mon, 2 Apr 2001 12:17:41 -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 MAA08386 for ; Mon, 2 Apr 2001 12:17:41 -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.9.3/8.9.1) with ESMTP id MAA28941; Mon, 2 Apr 2001 12:17:45 -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 ADK04686; Mon, 2 Apr 2001 12:17:39 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA04663; Mon, 2 Apr 2001 12:17:39 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15048.53331.374562.46083@thomasm-u1.cisco.com> Date: Mon, 2 Apr 2001 12:17:39 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Cc: Phil Neumiller Subject: Re: [mobile-ip] comments on draft-mkhalil-mobileip-ipv6-sap-00.txt In-Reply-To: <3AC891AD.AB047119@iprg.nokia.com> References: <200104021115.HAA29975@ietf.org> <001701c0bb6e$d29746e0$6501a8c0@philneum> <3AC891AD.AB047119@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: > > 3). Why should the security association between an MN and a CN be all > > that much different from other types of clients and servers and peers > > that run on the Internet? Why enmesh the security terminology with > > MIP terminology? (cohesion is still a bad design choice after all these > > years). Build a generalized solution for the Internet that MIP can use. > > Unfortunately, we've just been made very aware that Binding Updates _cannot_ > use any generalized IPsec solution. This is a very long subject, but the > very short version is that existing implementations cannot do the right > thing according to the way they look up entries in their SPDs. I don't think that's what has been said at all. There are three overall problems with IPsec in the mipv6 draft that I know about: 1) Use of AH for a destination option is a little dodgy. I believe that was Bill Sommerfeld's comment. However, using ESP/NULL for a BU which wasn't destination option (ie, just make it a separate ICMP, say) wouldn't be problematic on that front. 2) For the general anonymous browsing kind of problem which is the general case for MN->CN communication, the implications of global PKI's inherent for key exchange are... daunting to say the least, and quite possibly undesirable even if possible. A more decentralized approach would be better if possible 3) There are performance implications for large servers, both in round trips and CPU complexity using IKE (or even KINK) that we'd like to have a way to opt-out if possible. To some degree this is a cop out and only postpones when we won't be placing packets over insecure links, but it's also today's reality. I'm sort of ambivalent on this point. That said, I still think it would be very useful to still salvage the ability to use IPsec for BU's (mostly by fixing (1)). For the other considerations, we're going to need something different. Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 2 15:42:29 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27411 for ; Mon, 2 Apr 2001 15:42: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 MAA05425; Mon, 2 Apr 2001 12:41: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 MAA14010; Mon, 2 Apr 2001 12:41:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f32JcZIm019730 for ; Mon, 2 Apr 2001 12:38:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f32JcYxX019729 for mobile-ip-dist; Mon, 2 Apr 2001 12:38:34 -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.Beta5+Sun/8.12.0.Beta5) with ESMTP id f32JcPIm019722 for ; Mon, 2 Apr 2001 12:38: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 MAA25704 for ; Mon, 2 Apr 2001 12:38:25 -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 MAA06500 for ; Mon, 2 Apr 2001 12:38:23 -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.9.3/8.9.1) with ESMTP id MAA15266 for ; Mon, 2 Apr 2001 12:37:04 -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 ADK05144; Mon, 2 Apr 2001 12:37:42 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA04667; Mon, 2 Apr 2001 12:37:41 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15048.54533.814800.760267@thomasm-u1.cisco.com> Date: Mon, 2 Apr 2001 12:37:41 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] more comments on draft-mkhalil-mobileip-ipv6-sap-00.txt In-Reply-To: <15048.53331.374562.46083@thomasm-u1.cisco.com> References: <200104021115.HAA29975@ietf.org> <001701c0bb6e$d29746e0$6501a8c0@philneum> <3AC891AD.AB047119@iprg.nokia.com> <15048.53331.374562.46083@thomasm-u1.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 In general, anything that requires upfront public key operations needs to consider the possibility of make-work DoS attacks. If I can send you an unauthenticated message with little or no work which causes you to expend a lot of work, then I have a very nice attack amplification mechanism. There has been considerable debate about this in IPsec and to my knowledge is still not resolved. My perception is that IKE, in fact, still has it wrong (I believe that it's generally accepted that photurus got it right, and that son-of-ike should fix this problem). I do not claim to understand this space very well -- the solution seems to involve puzzles and other odd creatures -- but I do know that any MIPv6 solution for BU's MUST contend with this problem. Avoidance, IMO, is the best way to contend with it. Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 2 16:03:12 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28310 for ; Mon, 2 Apr 2001 16:03: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 NAA00027; Mon, 2 Apr 2001 13:02: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 NAA00341; Mon, 2 Apr 2001 13:02:52 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f32JwxIm019799 for ; Mon, 2 Apr 2001 12:58:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f32JwxbF019798 for mobile-ip-dist; Mon, 2 Apr 2001 12:58: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f32JwjIm019791 for ; Mon, 2 Apr 2001 12:58:50 -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 MAA29425 for ; Mon, 2 Apr 2001 12:58:43 -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 MAA26995 for ; Mon, 2 Apr 2001 12:58:38 -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 f32Jwbs08463 for ; Mon, 2 Apr 2001 21:58:37 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Mon Apr 02 21:58:37 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Apr 2001 21:54:19 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBD21@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Location privacy Date: Mon, 2 Apr 2001 21:58:35 +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, We're providing location privacy based on the routeable address of the MN. Granted you can do some other tricks, but eventually the CN will address the MN. That is the fact that you can't hide. Unless of course we start using ALGs. Have I missed something ? Hesham > -----Original Message----- > From: Michael Thomas [SMTP:mat@cisco.com] > Sent: Tuesday, 3 April 2001 4:56 > To: mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] Multiple tunnels over unoptimized route packets f or Extended mode > > Hesham, > > Location privacy is only as good as the weakest > link. I'm somewhat doubtful that mobile IP is that > link; it's much more likely to be the applications > running on top. For calling privacy, for example, > we've been through this many times and it all > really boils down to if you want to do it right, > you need an application layer anonymizer. For SIP, > that means doing a back to back UA, for email, > that mean anonymous remailers, etc, etc. Anything > less is probably not going to cut it, especially > if you have to meet legal tests. > > Mike > > Hesham Soliman (ERA) writes: > > Glenn, > > > > > Do you really think that you could convince a customer that you are really providing them location privacy. > > > If I were that customer, I would not be convinced. > > > > > => Well, up until this mail I thought there is some location > > privacy support in the draft. However if there is a better > > way of doing it, we're happy to consider it. I thought > > we discussed this before IETF and found that it was difficult > > to achieve complete location privacy with optimal routing ? > > Could you elaborate on why you're not convinced ? > > > > > I think that is everyone's point. > > > > > => Everyone ? The only feedback I got until Minneapolis > > was that (from the people that talked to me in private) > > Basic mode provided some nice features for > > hiding the LCoA. So I don't know who everyone > > is. > > It's very difficult when people make general statements > > like these without explaining reasons and / or alternatives. > > I'd appreciate some elaboration. > > > > Thanks, > > Hesham > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 2 16:03:38 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28333 for ; Mon, 2 Apr 2001 16:03: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 NAA29967; Mon, 2 Apr 2001 13:02: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 NAA28278; Mon, 2 Apr 2001 13:02:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f32K0NIm019809 for ; Mon, 2 Apr 2001 13:00:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f32K0M3b019808 for mobile-ip-dist; Mon, 2 Apr 2001 13:00: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f32K0DIm019801 for ; Mon, 2 Apr 2001 13:00: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 NAA29775 for ; Mon, 2 Apr 2001 13:00:12 -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 OAA11133 for ; Mon, 2 Apr 2001 14:00:05 -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 f32K04I00719 for ; Mon, 2 Apr 2001 22:00:05 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Mon Apr 02 22:00:04 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Apr 2001 21:55:46 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBD22@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Multiple tunnels over unoptimized route packets f or Extended mode Date: Mon, 2 Apr 2001 22:00: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: Theo, ------------------ RCoA = 3ffe:11:7:1::2 /128 | MAP |------------------------------- |----------------| ------------------- | AR | |----------------| | | | LCoA = 3ffe:11:7:3::1 /128 ------------------- | MR(MAP) | |----------------| | Home prefix = 2ff1:1:7:9:/64 | | MN LCoA = 2ff1:1:7:9::2 /128 ------------------ | MN | |----------------| The MR's LCoA in the visited domain is 3ffe:11:7:3::1 /128 . This is what the MR/MAP advertises to the MN. HA_BU (MN's Home_ADDR, 3ffe:11:7:3::1) MAP_BU (RCoA, 3ffe:11:7:3::1) 1. If there is no "further" MAP (for the sake of simplicity) then the MN's HA will tunnel to the MR _directly_. 2. If the MR is actually at home, then it will _not_ advertise its MAP option with the T flag set since the address given to the MN will be topologically correct and the MN will be reachable through normal routing. Is that the scenario you were thinking of ? 3. If the MR was at home (as in 2) and then moved somewhere else (with the MN) then it will advertise the LCoA which is NOT the Home address. The MN will send a BU to the HA ( if outside the MAP domain) or further MAP (if still inside the MAP domain) and update the MAP/HA Binding Cache. If you've been following the discussions on Mobile Networks then you'd know that there is no clear definition today on how the MR updates the HA with an entire prefix. To summarise, if there is a further MAP then packets will be routed directly to the MN (if the MR is at home) or to the MR (if it is in a visited network). If it was at home then moved, the packets will be routed to the MR's LCoA based on a BU from the MN which is triggered by the MR's MAP option informing the MN that it moved. I can't explain it in any more detail. Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 2 16:09:49 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28599 for ; Mon, 2 Apr 2001 16:09: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 NAA17966; Mon, 2 Apr 2001 13:07: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 NAA07594; Mon, 2 Apr 2001 13:07:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f32K4rIm019878 for ; Mon, 2 Apr 2001 13:04:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f32K4rT8019877 for mobile-ip-dist; Mon, 2 Apr 2001 13:04: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f32K4eIm019859 for ; Mon, 2 Apr 2001 13:04:41 -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 NAA18122 for ; Mon, 2 Apr 2001 13:04:23 -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 NAA29567 for ; Mon, 2 Apr 2001 13:04:22 -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 f32K4LI01653 for ; Mon, 2 Apr 2001 22:04:21 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Mon Apr 02 22:04:21 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Apr 2001 22:04:20 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBD23@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Cc: Phil Neumiller Subject: RE: [mobile-ip] comments on draft-mkhalil-mobileip-ipv6-sap-00.tx t Date: Mon, 2 Apr 2001 22:04:19 +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). Why should the security association between an MN and a CN be all > > > that much different from other types of clients and servers and peers > > > that run on the Internet? Why enmesh the security terminology with > > > MIP terminology? (cohesion is still a bad design choice after all these > > > years). Build a generalized solution for the Internet that MIP can use. > > > > Unfortunately, we've just been made very aware that Binding Updates _cannot_ > > use any generalized IPsec solution. This is a very long subject, but the > > very short version is that existing implementations cannot do the right > > thing according to the way they look up entries in their SPDs. > > I don't think that's what has been said at all. > There are three overall problems with IPsec in the > mipv6 draft that I know about: > > 1) Use of AH for a destination option is a little > dodgy. I believe that was Bill Sommerfeld's > comment. However, using ESP/NULL for a BU > which wasn't destination option (ie, just > make it a separate ICMP, say) wouldn't be > problematic on that front. > > 2) For the general anonymous browsing kind of > problem which is the general case for MN->CN > communication, the implications of global > PKI's inherent for key exchange > are... daunting to say the least, and quite > possibly undesirable even if possible. A > more decentralized approach would be better > if possible > > 3) There are performance implications for large > servers, both in round trips and CPU > complexity using IKE (or even KINK) that > we'd like to have a way to opt-out if > possible. To some degree this is a cop > out and only postpones when we won't be > placing packets over insecure links, but > it's also today's reality. I'm sort of > ambivalent on this point. > > That said, I still think it would be very > useful to still salvage the ability to use > IPsec for BU's (mostly by fixing (1)). For the > other considerations, we're going to need > something different. > => That's my understanding too. I think the SPD issue is definitely solvable. The major issue is the key exchange and the use of PKI. Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 2 17:41:35 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02132 for ; Mon, 2 Apr 2001 17:41: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 OAA15810; Mon, 2 Apr 2001 14:41: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 OAA22770; Mon, 2 Apr 2001 14:41:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f32LdQIm020033 for ; Mon, 2 Apr 2001 14:39:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f32LdPEH020032 for mobile-ip-dist; Mon, 2 Apr 2001 14:39: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.Beta5+Sun/8.12.0.Beta5) with ESMTP id f32LdGIm020025 for ; Mon, 2 Apr 2001 14:39:16 -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 OAA22399 for ; Mon, 2 Apr 2001 14:39:17 -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 OAA11772 for ; Mon, 2 Apr 2001 14:39: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 OAA01194 for ; Mon, 2 Apr 2001 14:39:16 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f32LdD510430 for ; Mon, 2 Apr 2001 14:39:13 -0700 X-mProtect: Mon, 2 Apr 2001 14:39:13 -0700 Nokia Silicon Valley Messaging Protection Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "cs.ucl.ac.uk") by darkstar.iprg.nokia.com(WTS.12.69) smtpdCONxVb; Mon, 02 Apr 2001 14:37:17 PDT Message-ID: <3AC8F10E.66A65DE1@cs.ucl.ac.uk> Date: Mon, 02 Apr 2001 14:37:18 -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] Multiple tunnels over unoptimized route packets f or Extended mode References: <034BEFD03799D411A59F00508BDF7546013DBD22@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 "Hesham Soliman (ERA)" wrote: > ------------------ RCoA = 3ffe:11:7:1::2 /128 > | MAP |------------------------------- > |----------------| > > > ------------------- > | AR | > |----------------| > | > | > | LCoA = 3ffe:11:7:3::1 /128 > ------------------- > | MR(MAP) | > |----------------| > | Home prefix = 2ff1:1:7:9:/64 > | > | MN LCoA = 2ff1:1:7:9::2 /128 > ------------------ > | MN | > |----------------| > > The MR's LCoA in the visited domain is 3ffe:11:7:3::1 /128 . > This is what the MR/MAP advertises to the MN. > > HA_BU (MN's Home_ADDR, 3ffe:11:7:3::1) > MAP_BU (RCoA, 3ffe:11:7:3::1) ok... so the MR needs to do: 0) MR gets an LCoA 1) MAP registration (MAP_BU) 2) MR_HA_BU to its own HA this is MR_HA_BU (MR Home Addr, 3ffe:11:7:1::2) now let us wonder what happens if the MR_HA_BU arrives __before__ the HA_BU....?? I think this is a very possible case.... This is the case that I have been talking about... and that can get worse if the MR (vehicle) changes too often is MAP point... I cannot imagine that the fixed MAP works in extended mode for the MR...simply because the MR is just another HMIPv6 node. The spec does not explicitly state how a fixed MAP is to react if the MN that registers with its is an MR. Also the distance metric is not specified so that the selection criterion for an MR and the MN (which to me behave the same) is concretely effected. At the moment the "FURTHER MAP" means nothing to me as an implementor...it could be any of them in the next 3-4 MAPs available. What would the distance metric be for that particular case? Also if you (the spec) opts for extended mode for fixed MAP then the spec needs to differentiate what are the cases that the Basic mode is needed... > > > 1. If there is no "further" MAP (for the sake of simplicity) > then the MN's HA will tunnel to the MR _directly_. If there is no further MAP then we have base mobility for the MR case and that will be the end of the discussion. > > 2. If the MR is actually at home, then it will _not_ advertise > its MAP option with the T flag set since the address > given to the MN will be topologically correct and the MN > will be reachable through normal routing. Is that the scenario > you were thinking of ? > nope.. if the MR is at home then the thing is solved ages ago.. > > 3. If the MR was at home (as in 2) and then moved > somewhere else (with the MN) then it will advertise > the LCoA which is NOT the Home address. yes I agree 101% on that.. > The MN > will send a BU to the HA ( if outside the MAP domain) > or further MAP (if still inside the MAP domain) and update > the MAP/HA Binding Cache. > yes the question is who will arrive first the HA_BU or the MR_HA_BU. when you are out of the MAP domain..you want to registrer with the domain first before you want to send anything back home. And to register with the domain, the latter needs to register first..... > > If you've been following the discussions on Mobile Networks > then you'd know that there is no clear definition today > on how the MR updates the HA with an entire prefix. > Well if the MR is away from home I expect it to act as an HMIPv6 MN when it comes to registering with its own HA. > > To summarise, if there is a further MAP then packets > will be routed directly to the MN (if the MR is at home) > or to the MR (if it is in a visited network). > If it was at home then moved, the packets will be routed > to the MR's LCoA based on a BU from the MN which > is triggered by the MR's MAP option informing the MN > that it moved. > yes but until that MR's MAP gets sorted with a domain and a MAP registration I cannot see how are you going to send packets upstream..from the MN that is.. Theo UCL/ Mobile Systems From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 2 17:42:10 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02162 for ; Mon, 2 Apr 2001 17:42:09 -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 OAA16294; Mon, 2 Apr 2001 14:41:51 -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 OAA12574; Mon, 2 Apr 2001 14:41:40 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f32LeEIm020043 for ; Mon, 2 Apr 2001 14:40:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f32LeDtg020042 for mobile-ip-dist; Mon, 2 Apr 2001 14:40: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f32Le1Im020035 for ; Mon, 2 Apr 2001 14:40:01 -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 OAA00615 for ; Mon, 2 Apr 2001 14:40:02 -0700 (PDT) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA16857 for ; Mon, 2 Apr 2001 14:40:01 -0700 (PDT) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Mon Apr 2 17:39:38 EDT 2001 Received: from blhothuelpc (thuelpc [135.180.240.114]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id RAA26526; Mon, 2 Apr 2001 17:39:47 -0400 (EDT) From: "Sandy Thuel" To: Cc: Subject: [mobile-ip] dynamic home addressing as a WG item?? Date: Mon, 2 Apr 2001 17:37:08 -0400 Message-ID: <006101c0bbbd$1184e8f0$72f0b487@dnrc.belllabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-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 Folks, As most of you know, there are two current drafts dealing with the issue of how to dynamically configure the home address of a mobile node using DHCP. These are: the DHCP proxy draft by Steve Glass and the Transient Tunneling draft by Sandy Thuel, et al. Since we didn't get a chance to present the new drafts at IETF50 in MN, we want to elicit feedback from you on the mailing list in the hope of expediting our progress on this issue. Although the DHCP proxy and Transient Tunneling drafts address the same problem, there are several key differences at the core of these mechanisms. Instead of comparing/contrasting them, it is far more useful to get feedback from you on the following key questions: 1) What is the real value of DHCP options to mobile nodes? 2) How important is it to minimize the power-up configuration latency of a mobile node? 3) How feasible do you think it is to require changes on Mobile IP home agents to provide a new service (e.g., DHCP proxy service support)? 4) How do you feel about the idea of adding DHCP-specific extensions to Mobile IP? All of us can stand to benefit from a serious discussion on these issues. PLEASE take a few minutes to offer your perspectives/comments on these questions, even if all you have to say is that you don't care. Thanks! Sandy Thuel From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 2 18:58:51 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03336 for ; Mon, 2 Apr 2001 18:58: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 PAA12316; Mon, 2 Apr 2001 15:58: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 PAA29202; Mon, 2 Apr 2001 15:58:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f32MupIm020193 for ; Mon, 2 Apr 2001 15:56:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f32MupQf020192 for mobile-ip-dist; Mon, 2 Apr 2001 15:56: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.Beta5+Sun/8.12.0.Beta5) with ESMTP id f32MugIm020185 for ; Mon, 2 Apr 2001 15:56:43 -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 PAA08843 for ; Mon, 2 Apr 2001 15:56:43 -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 PAA09567 for ; Mon, 2 Apr 2001 15:56:42 -0700 (PDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Mon, 2 Apr 2001 18:51:29 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Mobile IP v6 next steps Date: Mon, 2 Apr 2001 18:51:27 -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 WG chairs have been working with the IESG to progress the work on the MIPv6 draft. Thomas and Erik have agreed to shepherd this draft through the IESG process. The goal is to produce a solution for securing binding updates, update the draft to incorporate that solution, and progress the draft through the IESG to Proposed Standard very quickly, certainly before the 51st IETF in London if at all possible. The process for achieving this is becoming clear. Based on discussions generated around the rejection of the current draft due to the concerns about securing binding updates, some members of the IESG and the IAB and the working group chairs have begun refining the requirements that should be satisfied to provide a reasonable level of security for Mobile IP v6. This will be the set of requirements to form the basis of the IESG's approval of that part of the Mobile IP v6 spec and will be shared as soon as there is good consensus. All proposals for securing Mobile IP v6 specs will be measured against this set of requirements. Then a group of security experts and implementers will put together a solution that meets all the requirements, and the draft editor will update the draft to include this solution in the Mobile IP v6 spec. The draft will then go through working group and a new IETF last call as normal and the draft will be sent to the IESG for approval. From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 2 20:55:41 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05120 for ; Mon, 2 Apr 2001 20:55:40 -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 RAA15314; Mon, 2 Apr 2001 17:55: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 RAA10599; Mon, 2 Apr 2001 17:55:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f330r4Im020391 for ; Mon, 2 Apr 2001 17:53:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f330r3ZY020390 for mobile-ip-dist; Mon, 2 Apr 2001 17:53: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f330qsIm020383 for ; Mon, 2 Apr 2001 17:52:55 -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 RAA06265 for ; Mon, 2 Apr 2001 17:52:54 -0700 (PDT) Received: from c007.snv.cp.net (c007-h011.c007.snv.cp.net [209.228.33.217]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id RAA03266 for ; Mon, 2 Apr 2001 17:52:54 -0700 (PDT) Received: (cpmta 11962 invoked from network); 2 Apr 2001 17:52:53 -0700 Received: from unknown (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.217) with SMTP; 2 Apr 2001 17:52:53 -0700 X-Sent: 3 Apr 2001 00:52:53 GMT Message-ID: <017101c0bbd8$4270e980$6501a8c0@philneum> From: "Phil Neumiller" To: Cc: References: <006101c0bbbd$1184e8f0$72f0b487@dnrc.belllabs.com> Subject: Some comments on: [mobile-ip] dynamic home addressing as a WG item?? Date: Mon, 2 Apr 2001 19:51:39 -0500 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: Hi Sandy, Some comments below (this is so long that you might want to get a beverage). ----- Original Message ----- From: "Sandy Thuel" To: Cc: > Hi Folks, > > > 1) What is the real value of DHCP options to mobile > nodes? I guess I would even go a step further and question what is the real value of DHCP itself to mobile nodes? In the short term, it appears to be of quite high value. However... In my K-mart crystal ball (kind of cracked and fuzzy) I see lots of cheap wireless devices that will be used to living in MANETs *or* in infrastructures in the future. I see this big train wreck of who gets to pick the mobile's IP address coming. I suppose, if its a Windows type of box, it will be UPnP, if its Bluetooth type of device, well um, we need to wait until the BT SIG releases the next spec, if its an 802.11b device, I don' know of *any* commercial MANETs on 802.11 (know of some in labs!), if its a 3G device I am not sure yet but, I am pretty sure you can rule out DHCP on a CDMA radio!..., then we have zeroconf in there too along with SLP, Jini, and all kinds of other stuff trying to figure out what the heck is going on and what the IP addr and COA is (did I forget to mention ou friend MIP acting as an MN). If it starts out as a MANET MN and wants to hand up to being a full fledged up routable fixed citizen like in a docking station I don't know what the best answer is currently. Thank goodness we don't have micro-mobility to worry about anymore!!! At least for now... In the current home or enterprise WLAN/WPAN markets the sheer simplicity of DHCP brings joy to many people's hearts. However, in my crystal ball I see a darker future of sheer chaos. DHCP is basically founded upon a client server model, an anachronism in today's SAN infested B2B IP planet that is rapidly going peer-2-peer, as fast as you can say gnutella (that's April 2001 for Napster). So what are we left with? Burning IEEE MAC addresses into the foreheads of everywireless device and doing RARPs? MANET addressing (a matter with its own set of controversies)? Or a host of other jihads that I am sure could be enumerated (please don't). > 2) How important is it to minimize the power-up > configuration latency of a mobile node? Are you are saying that DHCP would be a signficant portion of this? What proportion? Do you have a guess? Do you have analysis or measurements? Would it be milliseconds, seconds? Depending on the link layer used, power up configuration has a huge standard deviation all on its own. Of course we must add DHCP latency onto that directly. > > 3) How feasible do you think it is to > require changes on Mobile IP home agents > to provide a new service (e.g., DHCP proxy > service support)? Would need to be done in FAs too (for MIPv4)? > > 4) How do you feel about the idea of adding > DHCP-specific extensions to Mobile IP NO. This is *EVIL*, and a very terrible idea. I never want to see these words again! :-) No really, this is probably not necessary. At least in the protocol sense. Could this not be done by some clever spoofing inside an AR where the DHCP server spoofs the FA/HA but hands out the actual address? I know this is kind of an implementor's hack, but to change MIP enmeshes something so systemic as DHCP with something so systemic with MIP and it makes me say want to say YUCK really loud. I actually prefer the coding hack to the design hack! When I re-read my comments I find they are of extremely limited use (low S/N ratio) so in summary let me give you my recommendation (worth about 2 cents these days): 1). We must figure out who wins the "I assign the address to the MN battle" in all possible scenarios including handoffs from MANETS (infrastructure-less) to MIP supported networks and handins and outs of zeroconf/DHCP/slp/UPnP/(MIP ^ MANET) supported subnets [do all the logical permutations]. 2). Who is asking for DHCP support now, i.e. who is the IETF customer for this work? Based on this, is this work justified or will it substantially improve routing configuration to/of mobile devices in the global Internet for the long term. My fear is that DHCP may become a thing of the past and things like BURP will open more doors to our future by allowing non-local secure authentication (which normally preceeds configuration) but we will see. Best regards, Phil From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 2 21:50:05 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA06992 for ; Mon, 2 Apr 2001 21:50: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 SAA07863; Mon, 2 Apr 2001 18:49:48 -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 SAA10293; Mon, 2 Apr 2001 18:49:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f331lrIm020497 for ; Mon, 2 Apr 2001 18:47:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f331lrN6020496 for mobile-ip-dist; Mon, 2 Apr 2001 18:47: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 jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f331lhIm020489 for ; Mon, 2 Apr 2001 18:47:43 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.0.Beta6+Sun/8.12.0.Beta6) with SMTP id f331lfWI102310; Mon, 2 Apr 2001 18:47:42 -0700 (PDT) Message-Id: <200104030147.f331lfWI102310@jurassic.eng.sun.com> Date: Mon, 2 Apr 2001 18:48:44 -0700 (PDT) From: Samita Chakrabarti Subject: [mobile-ip] Request to add an error code in RFC2794(NAI) To: pcalhoun@eng.sun.com, charliep@iprg.nokia.com Cc: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 1GurgdEb9vXJRW0sSvO+3A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 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: Hello, We have encountered an operator's scenario where home-agent has a bad behavior and assigns duplicate home-addr to multiple mobile nodes visiting the same FA. Now the question is how would the FA communicate this wrong behavior to MN ? The existing error codes in rfc2794 do not cover this particular case. Also it's possible that a ill-behaving HA may allocate addresses like 255.255.255.255 or 0.0.0.0 etc. We think it will be good idea to have a specific error code to cover this case. So, we are proposing an additional error code in rfc2794 for this purpose: INVALID_HOMEADDR 100 (Invalid homeaddress assignment) Thanks, -Samita From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 3 06:38:51 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA25731 for ; Tue, 3 Apr 2001 06:38:51 -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 DAA02455; Tue, 3 Apr 2001 03:38: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 DAA05054; Tue, 3 Apr 2001 03:38:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33AaXIm021025 for ; Tue, 3 Apr 2001 03:36:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f33AaWGD021024 for mobile-ip-dist; Tue, 3 Apr 2001 03:36: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.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33AaNIm021017 for ; Tue, 3 Apr 2001 03:36:23 -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 DAA27512 for ; Tue, 3 Apr 2001 03:36:22 -0700 (PDT) Received: from c007.snv.cp.net (c007-h012.c007.snv.cp.net [209.228.33.219]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id EAA14815 for ; Tue, 3 Apr 2001 04:36:21 -0600 (MDT) Received: (cpmta 21293 invoked from network); 3 Apr 2001 03:36:20 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.219) with SMTP; 3 Apr 2001 03:36:20 -0700 X-Sent: 3 Apr 2001 10:36:20 GMT Message-ID: <020f01c0bc29$c3e63960$6501a8c0@philneum> From: "Phil Neumiller" To: References: Subject: Re: [mobile-ip] Mobile IP v6 next steps Date: Tue, 3 Apr 2001 05:35:06 -0500 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: Some comments below. ----- Original Message ----- From: "Phil Roberts" To: Sent: Monday, April 02, 2001 5:51 PM Subject: [mobile-ip] Mobile IP v6 next steps > The WG chairs have been working with the IESG to progress the work on the > MIPv6 draft. Thomas and Erik have agreed to shepherd this draft through the > IESG process. The goal is to produce a solution for securing binding > updates, update the draft to incorporate that solution, and progress the > draft through the IESG to Proposed Standard very quickly, certainly before > the 51st IETF in London if at all possible. 1). There is an old adage, "haste makes waste". I find this to be particularly true of security software. It typically takes years to get the kinks worked out. Why is it that the 51st IETF is such a magical date? > The process for achieving this is becoming clear. Based on discussions > generated around the rejection of the current draft due to the concerns > about securing binding updates, some members of the IESG and the IAB and the > working group chairs have begun refining the requirements that should be > satisfied to provide a reasonable level of security for Mobile IP v6. This > will be the set of requirements to form the basis of the IESG's approval of > that part of the Mobile IP v6 spec and will be shared as soon as there is > good consensus. All proposals for securing Mobile IP v6 specs will be > measured against this set of requirements. 2). This sounds pretty good. I guess I wonder if a joint security area / MIP WG design team might not have been a better choice of a team for the formulation of the requirements draft though. > Then a group of security experts and implementers will put together a > solution that meets all the requirements, and the draft editor will update > the draft to include this solution in the Mobile IP v6 spec. The draft will > then go through working group and a new IETF last call as normal and the > draft will be sent to the IESG for approval. 3). This is where I imagine that old cartoon "then a miracle happens". In my limited experience (once started a failed security software venture in the early 90s (midnight engineering)), security software is very VERY hard, especially if *new* requirements have to be met. It is difficult enough to harden security software when a known secure algorithm (I mean stuff that has beem crypto-analyzed by lots of experts) is used let alone to introduce a new one with new requirements and expect it to be cryptographically secure. It seems a bit unclear to me how the MIP WG is to accomplish this and all its other work by IETF 51 without some kind of super human capabilities. Best Regards, -pdn From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 3 07:52:52 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27228 for ; Tue, 3 Apr 2001 07:52:52 -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 EAA04082; Tue, 3 Apr 2001 04:52: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 EAA02597; Tue, 3 Apr 2001 04:52:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33Bp2Im021247 for ; Tue, 3 Apr 2001 04:51:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f33Bp1LI021246 for mobile-ip-dist; Tue, 3 Apr 2001 04:51: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33BopIm021239 for ; Tue, 3 Apr 2001 04:50:51 -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 EAA10033 for ; Tue, 3 Apr 2001 04:50:49 -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 FAA09422 for ; Tue, 3 Apr 2001 05:50:48 -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 HAA26802; Tue, 3 Apr 2001 07:50:46 -0400 (EDT) Message-Id: <200104031150.HAA26802@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-mier-06.txt Date: Tue, 03 Apr 2001 07:50:46 -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 Extensions Rationalization (MIER) Author(s) : M. Khalil, R. Narayanan, H. Akhtar, E. Qaddoura Filename : draft-ietf-mobileip-mier-06.txt Pages : 8 Date : 02-Apr-01 It is in the interest of the Mobile IP WG to conserve the usage of the type field since we see many drafts proposing new extensions for Mobile IP. Therefore there is a real need to find ways to limit the usage of the type field in the extensions structure. MIER describes a new extension structure to Mobile IP to make the extensions far more extensible. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mier-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-mier-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-mier-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: <20010402124408.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-mier-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-mier-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010402124408.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 3 10:46:22 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02932 for ; Tue, 3 Apr 2001 10: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 HAA27020; Tue, 3 Apr 2001 07:45:32 -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 HAA29682; Tue, 3 Apr 2001 07:45:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33Ei7Im021536 for ; Tue, 3 Apr 2001 07:44:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f33Ei6jj021535 for mobile-ip-dist; Tue, 3 Apr 2001 07:44: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33EhvIm021528 for ; Tue, 3 Apr 2001 07:43:58 -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 HAA29422 for ; Tue, 3 Apr 2001 07:43:57 -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 HAA25609 for ; Tue, 3 Apr 2001 07:43:57 -0700 (PDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Tue, 3 Apr 2001 10:38:42 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] QoS work item Date: Tue, 3 Apr 2001 10:38:39 -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: 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 From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 3 10:53:38 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03236 for ; Tue, 3 Apr 2001 10:53: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 HAA19989; Tue, 3 Apr 2001 07:51: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 HAA00515; Tue, 3 Apr 2001 07:51:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33EnmIm021610 for ; Tue, 3 Apr 2001 07:49:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f33EnmVl021609 for mobile-ip-dist; Tue, 3 Apr 2001 07:49: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.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33EneIm021602 for ; Tue, 3 Apr 2001 07:49:40 -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 HAA00569 for ; Tue, 3 Apr 2001 07:49:40 -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 IAA05721 for ; Tue, 3 Apr 2001 08:49:39 -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 f33EnWg01669 for ; Tue, 3 Apr 2001 09:49:42 -0500 (CDT) Received: from daebh02nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 3 Apr 2001 09:49:26 -0500 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Tue, 3 Apr 2001 09:49:26 -0500 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B03213750@daeis07nok> To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Multiple tunnels over unoptimized route packets f or Extended mode Date: Tue, 3 Apr 2001 09:49: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: Hesham, I do not believe location privacy should be one of the focal points of HMIPv6. I think the key thing to be accomplished with HMIPv6 is the ability to reduce signaling to CNs and HA whenever a MN moves (and changes it's COA) and to some extent (*maybe*) provide a local entity in the serving network to authorize the MN access to the network. -Basavaraj > -----Original Message----- > From: ext Michael Thomas [mailto:mat@cisco.com] > Sent: Monday, April 02, 2001 1:56 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] Multiple tunnels over unoptimized > route packets > f or Extended mode > > > Hesham, > > Location privacy is only as good as the weakest > link. I'm somewhat doubtful that mobile IP is that > link; it's much more likely to be the applications > running on top. For calling privacy, for example, > we've been through this many times and it all > really boils down to if you want to do it right, > you need an application layer anonymizer. For SIP, > that means doing a back to back UA, for email, > that mean anonymous remailers, etc, etc. Anything > less is probably not going to cut it, especially > if you have to meet legal tests. > > Mike > > Hesham Soliman (ERA) writes: > > Glenn, > > > > > Do you really think that you could convince a customer > that you are really providing them location privacy. > > > If I were that customer, I would not be convinced. > > > > > => Well, up until this mail I thought there is some location > > privacy support in the draft. However if there is a better > > way of doing it, we're happy to consider it. I thought > > we discussed this before IETF and found that it was difficult > > to achieve complete location privacy with optimal routing ? > > Could you elaborate on why you're not convinced ? > > > > > I think that is everyone's point. > > > > > => Everyone ? The only feedback I got until Minneapolis > > was that (from the people that talked to me in private) > > Basic mode provided some nice features for > > hiding the LCoA. So I don't know who everyone > > is. > > It's very difficult when people make general statements > > like these without explaining reasons and / or alternatives. > > I'd appreciate some elaboration. > > > > Thanks, > > Hesham > > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 3 11:33:49 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04558 for ; Tue, 3 Apr 2001 11:33: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 IAA11617; Tue, 3 Apr 2001 08:33: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 IAA14513; Tue, 3 Apr 2001 08:33:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33FW6Im021862 for ; Tue, 3 Apr 2001 08:32:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f33FW6lM021861 for mobile-ip-dist; Tue, 3 Apr 2001 08:32: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33FVsIm021851 for ; Tue, 3 Apr 2001 08:31:54 -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 IAA07554 for ; Tue, 3 Apr 2001 08:31:54 -0700 (PDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA04415 for ; Tue, 3 Apr 2001 08:31:51 -0700 (PDT) Received: from marvel.research.telcordia.com (marvel [192.4.16.140]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id f33FVjO11278 for ; Tue, 3 Apr 2001 11:31:45 -0400 (EDT) Received: from research.telcordia.com (localhost [127.0.0.1]) by marvel.research.telcordia.com (8.8.8/8.8.8) with ESMTP id LAA21725 for ; Tue, 3 Apr 2001 11:31:45 -0400 (EDT) Message-ID: <3AC9ECE0.96955280@research.telcordia.com> Date: Tue, 03 Apr 2001 11:31:44 -0400 From: Subir Das 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] Location privacy References: <034BEFD03799D411A59F00508BDF7546013DBD30@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 Hesham, > > > > and to some extent (*maybe*) provide > > a local entity in the serving network to authorize the MN access to > > the network. > > > => Can we say that such authorisation is done by virtue > of the BU to the MAP ? Would that be satisfactory ? > I'm just trying to avoid integrating AAA into MIP. Just curious, cann't you do this via BURP? Thanks, Subir From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 3 11:45:44 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04928 for ; Tue, 3 Apr 2001 11:45: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 IAA12062; Tue, 3 Apr 2001 08:39: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 IAA00713; Tue, 3 Apr 2001 08:07:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33F6MIm021710 for ; Tue, 3 Apr 2001 08:06:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f33F6LBZ021709 for mobile-ip-dist; Tue, 3 Apr 2001 08:06: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33F6CIm021702 for ; Tue, 3 Apr 2001 08:06: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 IAA00306 for ; Tue, 3 Apr 2001 08:06:12 -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 IAA15513 for ; Tue, 3 Apr 2001 08:06:11 -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 f33F69I01691 for ; Tue, 3 Apr 2001 17:06:09 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Apr 03 17:06:08 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Apr 2001 17:06:07 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBD30@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Location privacy Date: Tue, 3 Apr 2001 17:06:03 +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 Raj, > I do not believe location privacy should be one of the focal points > of HMIPv6. I think the key thing to be accomplished with HMIPv6 > is the ability to reduce signaling to CNs and HA whenever a MN > moves (and changes it's COA) > => Sounds good. Actually that's what we wanted as well, but, the solution we came up with gave us location privacy for free. So I agree that it shouln't be the focal point and that HMIPv6 should not be the optimal location privacy solution. It would be good if someone started looking into a more optimal way of doing it. > and to some extent (*maybe*) provide > a local entity in the serving network to authorize the MN access to > the network. > => Can we say that such authorisation is done by virtue of the BU to the MAP ? Would that be satisfactory ? I'm just trying to avoid integrating AAA into MIP. Thanks, Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 3 11:47:23 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04999 for ; Tue, 3 Apr 2001 11:47:23 -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 IAA12220; Tue, 3 Apr 2001 08:39:55 -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 IAA08201; Tue, 3 Apr 2001 08:32:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33FUhIm021846 for ; Tue, 3 Apr 2001 08:30:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f33FUhJT021845 for mobile-ip-dist; Tue, 3 Apr 2001 08:30:43 -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.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33FUSIm021823 for ; Tue, 3 Apr 2001 08:30:29 -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 IAA13905 for ; Tue, 3 Apr 2001 08:30:29 -0700 (PDT) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA03405 for ; Tue, 3 Apr 2001 08:30:27 -0700 (PDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Tue, 3 Apr 2001 10:24:06 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Apr 2001 10:23:52 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E4301C02895@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Location privacy Date: Tue, 3 Apr 2001 10:23:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0BC52.111DF510" Sender: owner-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_01C0BC52.111DF510 Content-Type: text/plain; charset="iso-8859-1" Hesham, You have correctly identified the issue. You have not missed something. Glenn -----Original Message----- From: Hesham Soliman (ERA) [mailto:Hesham.Soliman@era.ericsson.se] Sent: Monday, April 02, 2001 2:59 PM To: 'mobile-ip@sunroof.eng.sun.com' Subject: [mobile-ip] Location privacy Mike, We're providing location privacy based on the routeable address of the MN. Granted you can do some other tricks, but eventually the CN will address the MN. That is the fact that you can't hide. Unless of course we start using ALGs. Have I missed something ? Hesham > -----Original Message----- > From: Michael Thomas [SMTP:mat@cisco.com] > Sent: Tuesday, 3 April 2001 4:56 > To: mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] Multiple tunnels over unoptimized route packets f or Extended mode > > Hesham, > > Location privacy is only as good as the weakest > link. I'm somewhat doubtful that mobile IP is that > link; it's much more likely to be the applications > running on top. For calling privacy, for example, > we've been through this many times and it all > really boils down to if you want to do it right, > you need an application layer anonymizer. For SIP, > that means doing a back to back UA, for email, > that mean anonymous remailers, etc, etc. Anything > less is probably not going to cut it, especially > if you have to meet legal tests. > > Mike > > Hesham Soliman (ERA) writes: > > Glenn, > > > > > Do you really think that you could convince a customer that you are really providing them location privacy. > > > If I were that customer, I would not be convinced. > > > > > => Well, up until this mail I thought there is some location > > privacy support in the draft. However if there is a better > > way of doing it, we're happy to consider it. I thought > > we discussed this before IETF and found that it was difficult > > to achieve complete location privacy with optimal routing ? > > Could you elaborate on why you're not convinced ? > > > > > I think that is everyone's point. > > > > > => Everyone ? The only feedback I got until Minneapolis > > was that (from the people that talked to me in private) > > Basic mode provided some nice features for > > hiding the LCoA. So I don't know who everyone > > is. > > It's very difficult when people make general statements > > like these without explaining reasons and / or alternatives. > > I'd appreciate some elaboration. > > > > Thanks, > > Hesham > > > > > > > > ------_=_NextPart_001_01C0BC52.111DF510 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Location privacy

Hesham,

You have correctly identified the issue. You have not = missed something.

Glenn

-----Original Message-----
From: Hesham Soliman (ERA) [mailto:Hesham.Soliman@era= .ericsson.se]
Sent: Monday, April 02, 2001 2:59 PM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: [mobile-ip] Location privacy


Mike,

We're providing location privacy based on the
routeable address of the MN.
Granted you can do some other tricks, but = eventually
the CN will address the MN. That is the fact
that you can't hide. Unless of course we = start
using ALGs.
Have I missed something ?

Hesham


> -----Original Message-----
> From: Michael Thomas = [SMTP:mat@cisco.com]
> Sent: Tuesday, 3 April 2001 4:56
> To:   = mobile-ip@sunroof.eng.sun.com
> Subject:      RE: = [mobile-ip] Multiple tunnels over unoptimized route packets = f       or Extended mode
>
> Hesham,
>
> Location privacy is only as good as the = weakest
> link. I'm somewhat doubtful that mobile IP is = that
> link; it's much more likely to be the = applications
> running on top. For calling privacy, for = example,
> we've been through this many times and it = all
> really boils down to if you want to do it = right,
> you need an application layer anonymizer. For = SIP,
> that means doing a back to back UA, for = email,
> that mean anonymous remailers, etc, etc. = Anything
> less is probably not going to cut it, = especially
> if you have to meet legal tests.
>
>       =     Mike
>
> Hesham Soliman  (ERA) writes:
>  > Glenn,
>  >
>  > > Do you really think that you = could convince a customer that you are really providing them location = privacy.
>  > > If I were that customer, I = would not be convinced.
>  > >
>  >    =3D> Well, up until = this mail I thought there is some location
>  >    privacy support in the = draft. However if there is a better
>  >    way of doing it, we're = happy to consider it. I thought
>  >    we discussed this = before IETF and found that it was difficult
>  >    to achieve complete = location privacy with optimal routing ?
>  >    Could you elaborate on = why you're not convinced ?
>  >
>  > > I think that is everyone's = point.
>  > >
>  >    =3D> Everyone ? The = only feedback I got until Minneapolis
>  >    was that (from the = people that talked to me in private)
>  >    Basic mode provided = some nice features for
>  >    hiding the LCoA. So I = don't know who everyone
>  >    is.
>  >    It's very difficult = when people make general statements
>  >    like these without = explaining reasons and / or alternatives.
>  >    I'd appreciate some = elaboration.
>  >
>  >    Thanks,
>  >    Hesham
>  >
>  >
>  >
>  >

------_=_NextPart_001_01C0BC52.111DF510-- From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 3 12:00:41 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05467 for ; Tue, 3 Apr 2001 12:00:40 -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 IAA28819; Tue, 3 Apr 2001 08:53: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 IAA11941; Tue, 3 Apr 2001 08:53:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33FpwIm022017 for ; Tue, 3 Apr 2001 08:51:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f33FpvsW022016 for mobile-ip-dist; Tue, 3 Apr 2001 08:51: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33FpnIm022009 for ; Tue, 3 Apr 2001 08:51: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 IAA08233 for ; Tue, 3 Apr 2001 08:51:49 -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 JAA16193 for ; Tue, 3 Apr 2001 09:51:47 -0600 (MDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Tue, 3 Apr 2001 11:46:33 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] MIP v6 Regional Registration - identifying requirements Date: Tue, 3 Apr 2001 11:46:30 -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 think I've finally caught up on all the mail about regional registrations for MIP v6 and HMIP. There seems to be significant concerns about the task to be accomplished and the specific approach that is specified in the HMIP draft. A short list of concerns include worries about introducing single points of failure, whether or not multiple levels of hierarchy are needed, the amount of signaling and tunneling overhead that is implied, the relevance of load balancing and the particular metrics in the HMIP draft, and the clarity of the description in the draft. The participants in the working group have apparently been thinking a lot about what is actually needed for a regionalized registration scheme since we adopted HMIP as a working group draft. It seems appropriate at this time to have some discussion about what the requirements for regional registration actually are, then to figure out what to do about the draft we've chosen as a working group draft. Here's a short list of requirements drawn from comments received over the last month or so and from the HMIP draft that the working group participants can use as a basis for discussion. Please understand that this is not the list of requirements I believe are needed but a list of things I've assembled from drafts and comments on the discussion. Let's take this list and try to identify the requirements that everyone agrees to and then have some discussion about the contentious ones. Requirements not on this list are also welcome for discussion. And reducing or modifying items I've listed is also open to discussion. 1) Regional registration shall be introduced to minimize the signaling traffic to the home agent or correspondent nodes for intra-domain mobility 2) Regional registration shall not introduce new overhead on links between the mobile and the regional registration agents 3) Connectivity to the mobiles shall not be interrupted in the presence of the failure of regional registration agents 4) Regional registration shall scale to support millions of nodes in a visited network 5) Regional registration shall be secure against malicious behavior from visiting mobiles 6) Regional registration shall allow multiple levels of hierarchy 7) Regional registration shall support fast handoffs 8) Regional registration shall not require changes to the mobile node, the home agent, or correspondent nodes 9) Regional registration shall not introduce host routes in routing tables From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 3 13:27:05 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09194 for ; Tue, 3 Apr 2001 13:27:04 -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 KAA11800; Tue, 3 Apr 2001 10:26: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 KAA11237; Tue, 3 Apr 2001 10:26:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33HOKIm022190 for ; Tue, 3 Apr 2001 10:24:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f33HOJuf022189 for mobile-ip-dist; Tue, 3 Apr 2001 10:24: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33HOBIm022182 for ; Tue, 3 Apr 2001 10:24:11 -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 KAA29378 for ; Tue, 3 Apr 2001 10:24:10 -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 LAA13385 for ; Tue, 3 Apr 2001 11:24:09 -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 f33HQ6w15688 for ; Tue, 3 Apr 2001 12:26:16 -0500 (CDT) Received: from daebh01nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 3 Apr 2001 12:23:57 -0500 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Tue, 3 Apr 2001 12:23:57 -0500 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B03213754@daeis07nok> To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Location privacy Date: Tue, 3 Apr 2001 12:23:57 -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: Hesham, > > Hi Raj, > > > I do not believe location privacy should be one of the focal points > > of HMIPv6. I think the key thing to be accomplished with HMIPv6 > > is the ability to reduce signaling to CNs and HA whenever a MN > > moves (and changes it's COA) > > > => Sounds good. Actually that's what we wanted as well, > but, the solution we came up with gave us location > privacy for free. So I agree that it shouln't be the > focal point and that HMIPv6 should not be the optimal > location privacy solution. It would be good if someone > started looking into a more optimal way of doing it. > Location privacy is something that MAY need attention on it's own and for now, I'm not too worried about it. > > and to some extent (*maybe*) provide > > a local entity in the serving network to authorize the MN access to > > the network. > > > => Can we say that such authorisation is done by virtue > of the BU to the MAP ? Would that be satisfactory ? > I'm just trying to avoid integrating AAA into MIP. > That's what I meant in my statement. I am not trying to integrate AAA into MIP in any way. > > Thanks, > Hesham > -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 3 13:32:19 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09382 for ; Tue, 3 Apr 2001 13:32: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 KAA27436; Tue, 3 Apr 2001 10:31: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 KAA12645; Tue, 3 Apr 2001 10:31:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33HTxIm022261 for ; Tue, 3 Apr 2001 10:29:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f33HTxpv022260 for mobile-ip-dist; Tue, 3 Apr 2001 10:29: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33HTnIm022253 for ; Tue, 3 Apr 2001 10:29: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 KAA00880 for ; Tue, 3 Apr 2001 10:29:49 -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 KAA25805 for ; Tue, 3 Apr 2001 10:29:48 -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 KAA21139 for ; Tue, 3 Apr 2001 10:29:48 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f33HThU27637 for ; Tue, 3 Apr 2001 10:29:43 -0700 X-mProtect: Tue, 3 Apr 2001 10:29:43 -0700 Nokia Silicon Valley Messaging Protection Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "cs.ucl.ac.uk") by darkstar.iprg.nokia.com(WTS.12.69) smtpdaWGaiH; Tue, 03 Apr 2001 10:23:09 PDT Message-ID: <3ACA06FF.34675192@cs.ucl.ac.uk> Date: Tue, 03 Apr 2001 10:23:11 -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] Location privacy References: <034BEFD03799D411A59F00508BDF7546013DBD30@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 "Hesham Soliman (ERA)" wrote: > Hi Raj, > > > I do not believe location privacy should be one of the focal points > > of HMIPv6. I think the key thing to be accomplished with HMIPv6 > > is the ability to reduce signaling to CNs and HA whenever a MN > > moves (and changes it's COA) > > > => Sounds good. Actually that's what we wanted as well, > but, the solution we came up with gave us location > privacy for free. So I agree that it shouln't be the > focal point and that HMIPv6 should not be the optimal > location privacy solution. It would be good if someone > started looking into a more optimal way of doing it. > > > and to some extent (*maybe*) provide > > a local entity in the serving network to authorize the MN access to > > the network. > > > => Can we say that such authorisation is done by virtue > of the BU to the MAP ? Would that be satisfactory ? > I'm just trying to avoid integrating AAA into MIP. > > Thanks, > Hesham Further to the above discussion we need to clearly distinguish on what constitutes location privacy Are we looking location privacy WRT 1) the visiting domain and the current location of the MN 2) the world and the current location of the MN 3) the visiting domain and the home location of the MN Currently my interpretation of the HMIPv6 draft allows only in Basic Mode to avoid devulging the home addr of the MN to the visiting domain. This is case (3) since in Basic mode you sustain uniqueness of reference on a per MN unique RCoA as created by the MAP prefix. I have explicitly expresses my concern that this would bring up (scaling angle on) millions of new RCoAs for management and DAD verification on the MAP box or at the very least to the MAP domain. Extended mode does not do that as it uses the Home address of the MN as a uniqueness ref key in the B- Cache of the MAP AND uses a unique RCoA for ALL MN...so a single RCoA seems to work in extended but not wanted in Basic mode....WHY.......????? As far as (2) is concerned...CNs can find the current location of the MN in no time if the source addr is the LCoA of the MN. I have heard the argument that the RCoA may be allowed in the src addr in upstream data packets from the MN. I believe that this argument is completely unsound since egress filtering is more that expected to be found in ISPs. If the assumption is NOT then we will have a bad time trying to convince ISP to do switch off egress filtering if egress filtering is on and you still want the RCoA on, you MUST go through a specific route to the filter that understand the RCoA (say the visiting domain). That to me seems like an upstream routing hierarchy with specific upstream routes...I am confident that such has been a no-no from both hierarchical schemes. (1) simply will never happen since the MN has to register with the mobility agent (MAP or GMA) Theo UCL / Mobile Systems From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 3 14:02:52 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10885 for ; Tue, 3 Apr 2001 14:02: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 LAA24333; Tue, 3 Apr 2001 11:01: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 LAA09746; Tue, 3 Apr 2001 11:01:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33I0LIm022360 for ; Tue, 3 Apr 2001 11:00:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f33I0KKR022359 for mobile-ip-dist; Tue, 3 Apr 2001 11:00: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.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33I0BIm022352 for ; Tue, 3 Apr 2001 11:00:11 -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 LAA14604 for ; Tue, 3 Apr 2001 11:00:10 -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 LAA22663 for ; Tue, 3 Apr 2001 11:00:10 -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.9.3/8.9.1) with ESMTP id LAA29583 for ; Tue, 3 Apr 2001 11:00: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 ADL14946; Tue, 3 Apr 2001 11:00:08 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA04933; Tue, 3 Apr 2001 11:00:03 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15050.4003.607576.374007@thomasm-u1.cisco.com> Date: Tue, 3 Apr 2001 11:00:03 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Authorization in F/H MIP In-Reply-To: <034BEFD03799D411A59F00508BDF7546013DBD30@esealnt448.al.sw.ericsson.se> References: <034BEFD03799D411A59F00508BDF7546013DBD30@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 Note that this is applicable to any of [A-Z]MIP's Hesham Soliman (ERA) asks: > > and to some extent (*maybe*) provide > > a local entity in the serving network to authorize the MN access to > > the network. > > > => Can we say that such authorisation is done by virtue > of the BU to the MAP ? Would that be satisfactory ? > I'm just trying to avoid integrating AAA into MIP. I don't think so. Any time you request services from a node, that request may need to be both authenticated and authorized. A BU can be sufficient so long as the shared key establishment implies authorization for the use of the service. If it doesn't, then you need other ways to authorize the request including classic AAA. Given the typical NAS model, I'd expect there will be a lot of desire to use AAA. Mike From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 3 14:23:08 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11732 for ; Tue, 3 Apr 2001 14:23:07 -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 LAA12177; Tue, 3 Apr 2001 11:22: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 LAA26212; Tue, 3 Apr 2001 11:22:38 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33ILAIm022447 for ; Tue, 3 Apr 2001 11:21:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f33IL9ph022446 for mobile-ip-dist; Tue, 3 Apr 2001 11:21: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33IL0Im022439 for ; Tue, 3 Apr 2001 11:21:00 -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 LAA21042 for ; Tue, 3 Apr 2001 11:20:59 -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 MAA19687 for ; Tue, 3 Apr 2001 12:20:57 -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 f33IKus04878 for ; Tue, 3 Apr 2001 20:20:56 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Tue Apr 03 20:20:55 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Apr 2001 20:16:36 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBD35@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Location privacy Date: Tue, 3 Apr 2001 20:20:54 +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: Subir > > > and to some extent (*maybe*) provide > > > a local entity in the serving network to authorize the MN access to > > > the network. > > > > > => Can we say that such authorisation is done by virtue > > of the BU to the MAP ? Would that be satisfactory ? > > I'm just trying to avoid integrating AAA into MIP. > > Just curious, cann't you do this via BURP? > => That's exactly what I meant. Regards, Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 3 14:34:59 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12301 for ; Tue, 3 Apr 2001 14:34:59 -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 LAA22177; Tue, 3 Apr 2001 11:34:30 -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 LAA23894; Tue, 3 Apr 2001 11:34:16 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33IWKIm022534 for ; Tue, 3 Apr 2001 11:32:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f33IWJ6n022533 for mobile-ip-dist; Tue, 3 Apr 2001 11:32: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.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33IWBIm022526 for ; Tue, 3 Apr 2001 11:32: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 LAA20334 for ; Tue, 3 Apr 2001 11:32:10 -0700 (PDT) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id LAA20233 for ; Tue, 3 Apr 2001 11:32:09 -0700 (PDT) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by crufty; Tue Apr 3 14:29:46 EDT 2001 Received: from king.research.bell-labs.com ([135.1.152.1]) by scummy; Tue Apr 3 14:31:52 EDT 2001 Received: from notmafia.research.bell-labs.com.research.bell-labs.com (notmafia [135.1.152.230]) by king.research.bell-labs.com (Postfix) with SMTP id EEEBA5701F; Tue, 3 Apr 2001 13:31:51 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Pete McCann To: kempf@heliopolis.eng.sun.com Cc: mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover In-Reply-To: <8572CF1E2A95D211A1190008C7EAA2460213BB7A@daeis05nok> References: <8572CF1E2A95D211A1190008C7EAA2460213BB7A@daeis05nok> X-Mailer: VM 6.33 under Emacs 19.34.2 Message-Id: <20010403183152.EEEBA5701F@king.research.bell-labs.com> Date: Tue, 3 Apr 2001 13:31:52 -0500 (CDT) Sender: owner-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 think there is a simpler solution to this problem that most people are overlooking. It should be possible to keep the compressor/decompressor state at the old access router and to tunnel the already-compressed packets to and from the new access router. Then the MN and new access router can renegotiate header compression state from scratch and take as long as they want to do so, because the MN is still getting service in the meantime. Someone earlier asked about support for ROHC on IP tunnels and I think this would be a good application for that. We are trying to move the mountain to Mohammed and I don't see why we can't do the reverse instead. -Pete From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 3 15:05:41 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13543 for ; Tue, 3 Apr 2001 15:05:40 -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 MAA16294; Tue, 3 Apr 2001 12:05:06 -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 MAA27752; Tue, 3 Apr 2001 12:04:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33J3BIm022666 for ; Tue, 3 Apr 2001 12:03:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f33J3AsG022665 for mobile-ip-dist; Tue, 3 Apr 2001 12:03: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.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33J31Im022658 for ; Tue, 3 Apr 2001 12:03: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 MAA07282 for ; Tue, 3 Apr 2001 12:03:01 -0700 (PDT) Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA16081 for ; Tue, 3 Apr 2001 12:02:59 -0700 (PDT) Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA11836 for ; Tue, 3 Apr 2001 15:02:57 -0400 (EDT) Received: from nwmail.wh.lucent.com (h135-5-40-100.lucent.com [135.5.40.100]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id PAA11832 for ; Tue, 3 Apr 2001 15:02:57 -0400 (EDT) Received: by nwmail.wh.lucent.com (SMI-8.6/EMS-1.5 sol2) id PAA29627; Tue, 3 Apr 2001 15:02:55 -0400 Received: from lucent.com by nwmail.wh.lucent.com (SMI-8.6/EMS-1.5 sol2) id PAA29624; Tue, 3 Apr 2001 15:02:55 -0400 Message-ID: <3ACA1E5F.8408016A@lucent.com> Date: Tue, 03 Apr 2001 15:02:55 -0400 From: Erik Anderlind X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover References: <8572CF1E2A95D211A1190008C7EAA2460213BB7A@daeis05nok> <20010403183152.EEEBA5701F@king.research.bell-labs.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 Pete, Pete McCann wrote: > > Hi, > > I think there is a simpler solution to this problem that most people > are overlooking. > > It should be possible to keep the compressor/decompressor state at the > old access router and to tunnel the already-compressed packets to and > from the new access router. Then the MN and new access router can > renegotiate header compression state from scratch and take as long as > they want to do so, because the MN is still getting service in the > meantime. > The problem with your proposal is that the decompressor requires that all packets are received in order. You have now placed a requirement on the tunnel that it delivers packets in order. This sounds complicated and prone to increasing end-end delay. Finding the IP address of the old access router and establishing security also are issuse, although they seem like general context switch problem. ...Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 3 15:16:48 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13925 for ; Tue, 3 Apr 2001 15:16: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 MAA23150; Tue, 3 Apr 2001 12:13:36 -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 MAA09687; Tue, 3 Apr 2001 12:13:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33JCBIm022804 for ; Tue, 3 Apr 2001 12:12:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f33JCAwA022803 for mobile-ip-dist; Tue, 3 Apr 2001 12:12: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.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33JC1Im022796 for ; Tue, 3 Apr 2001 12:12: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 MAA03232 for ; Tue, 3 Apr 2001 12:12:00 -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 MAA21954 for ; Tue, 3 Apr 2001 12:11:58 -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 f33JBvs23487 for ; Tue, 3 Apr 2001 21:11:57 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Tue Apr 03 21:11:57 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Apr 2001 21:07:38 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBD36@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Mobile Netwoks in MIPv6 Date: Tue, 3 Apr 2001 21:11:56 +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 Thierry, One other issue you might want to consider in your draft is the case where the MR sends a BU that covers the entire prefix but another MN (with a Home address on the MR's subnet) sends a BU for its location which may be different from the MR's location. I guess it would be easy enough if the HA does a search on the longest Home address match to avoid the confusion in this case. Is that a feasible scenario ? I haven't read your draft for sometime now so maybe it's already covered ? Cheers, Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 3 15:24:08 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14225 for ; Tue, 3 Apr 2001 15:24:08 -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 MAA14088; Tue, 3 Apr 2001 12:23: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 MAA29653; Tue, 3 Apr 2001 12:23:38 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33JMKIm022889 for ; Tue, 3 Apr 2001 12:22:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f33JMKJT022888 for mobile-ip-dist; Tue, 3 Apr 2001 12:22: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.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33JMBIm022881 for ; Tue, 3 Apr 2001 12:22:11 -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 MAA05727 for ; Tue, 3 Apr 2001 12:22:10 -0700 (PDT) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id MAA12849 for ; Tue, 3 Apr 2001 12:22:09 -0700 (PDT) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Tue Apr 3 15:19:00 EDT 2001 Received: from blhothuelpc (thuelpc [135.180.240.114]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id PAA07243; Tue, 3 Apr 2001 15:21:17 -0400 (EDT) From: "Sandy Thuel" To: "Phil Neumiller" , Subject: RE: Some comments on: [mobile-ip] dynamic home addressing as a WG item?? Date: Tue, 3 Apr 2001 15:18:38 -0400 Message-ID: <007701c0bc72$e2e47310$72f0b487@dnrc.belllabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <017101c0bbd8$4270e980$6501a8c0@philneum> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-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 Phil, Thanks for taking the time to offer your perspectives on DHCP! See my comments in-line. > > 1) What is the real value of DHCP options to mobile > > nodes? > > I guess I would even go a step further and question > what is the real value of DHCP itself to mobile nodes? > In the short term, it appears to be of quite high value. > > However... > You're absolutely right in that this meta-question needs to be answered at large. With the proliferation of different devices and address allocation mechanisms that promises to be around in the foreseeable future, it is really unclear what will emerge as the king address/configuration allocator. However, given its current entrenchment, I believe that DHCP will continue to play an important role for some time to come. As a result, enabling its use for mobile IP nodes should not be overlooked. > I am pretty sure you can rule out DHCP on a > CDMA radio!... Not necessarily! Some cellular operators in 3GPP2 are looking into using DHCP. The competition here is IPCP(PPP), which typically does the address allocation. But PPP is unfriendly to mobility, which has opened the door for some to consider a MobileIP/DHCP solution. > > > 2) How important is it to minimize the power-up > > configuration latency of a mobile node? > > Are you are saying that DHCP would be a signficant > portion of this? What proportion? Do you have a guess? > Do you have analysis or measurements? Would it be milliseconds, > seconds? Depending on the link layer used, power up > configuration has a huge standard deviation all on its own. > Of course we must add DHCP latency onto that directly. We and others have taken DHCP latency measurements and have found them to be in the ballpark of 100-300 msec. (after some much-needed optimizations to enhance the performance of DHCP - e.g., taking the time-consuming address conflict checking step out of critical path at both the server and the client). This assumes RTT between server and client is negligible (say on the order of 1 msec.). However, if the RTT between the DHCP client and server is large, the 2 RTT's involved in a client-server transaction dominates the configuration latency and can push it into the seconds scale. The question is how much of a latency is too much? How much is OK? > > > > > 3) How feasible do you think it is to > > require changes on Mobile IP home agents > > to provide a new service (e.g., DHCP proxy > > service support)? > > Would need to be done in FAs too (for MIPv4)? Although I can envision putting a DHCP proxy client service on FA's, that would eliminate the key benefit of offering proxy services at the HA: reducing the RTT between the proxy DHCP client and server. > > > > > 4) How do you feel about the idea of adding > > DHCP-specific extensions to Mobile IP > > NO. This is *EVIL*, and a very terrible idea. We're in complete agreement here. > > When I re-read my comments I find they are of extremely > limited use (low S/N ratio) so in summary let me give you > my recommendation (worth about 2 cents these days): > > 1). We must figure out who wins the "I assign the address > to the MN battle" in all possible scenarios including > handoffs from MANETS (infrastructure-less) to > MIP supported networks and handins and outs of > zeroconf/DHCP/slp/UPnP/(MIP ^ MANET) supported > subnets [do all the logical permutations]. > > 2). Who is asking for DHCP support now, i.e. who is the > IETF customer for this work? Based on this, is this > work justified or will it substantially improve routing > configuration to/of mobile devices in the global Internet > for the long term. > > My fear is that DHCP may become a thing of the past and > things like BURP will open more doors to our future by > allowing non-local secure authentication (which normally > preceeds configuration) but we will see. I agree someone has to figure out these different issues you've raised but am not sure that the mobileip WG is the one to do so. What we do know is that DHCP is heavily used now and that we should leverage its use for configuring mobile nodes (while it's around). If some other handy-dandy configuration protocol becomes prevalent and popular in the future, we can think about how to make it work for mobile IP nodes then. Regards, Sandy From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 3 15:43:47 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14823 for ; Tue, 3 Apr 2001 15:43:47 -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 MAA15597; Tue, 3 Apr 2001 12:41: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 MAA03385; Tue, 3 Apr 2001 12:41:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33JaPIm022975 for ; Tue, 3 Apr 2001 12:36:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f33JaPdd022974 for mobile-ip-dist; Tue, 3 Apr 2001 12:36: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33JaDIm022967 for ; Tue, 3 Apr 2001 12:36:16 -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 MAA14542 for ; Tue, 3 Apr 2001 12:36:13 -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 MAA21217 for ; Tue, 3 Apr 2001 12:36:13 -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.9.3/8.9.1) with ESMTP id MAA12916 for ; Tue, 3 Apr 2001 12:36: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 ADL17779; Tue, 3 Apr 2001 12:36:11 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA04943; Tue, 3 Apr 2001 12:36:11 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15050.9771.32224.337730@thomasm-u1.cisco.com> Date: Tue, 3 Apr 2001 12:36:11 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Mobile Netwoks in MIPv6 In-Reply-To: <034BEFD03799D411A59F00508BDF7546013DBD36@esealnt448.al.sw.ericsson.se> References: <034BEFD03799D411A59F00508BDF7546013DBD36@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 Isn't it always the case that a mobile node behind a mobile router, that the mobile router must be the mobile host's home agent? If the mobile router moves, wouldn't that cause the mobile host's BU to the other home agent to become stale? Mike Hesham Soliman (ERA) writes: > > Hello Thierry, > > One other issue you might want to consider in your draft > is the case where the MR sends a BU that covers the entire > prefix but another MN (with a Home address on the MR's > subnet) sends a BU for its location which may be different > from the MR's location. > > I guess it would be easy enough if the HA does a search > on the longest Home address match to avoid the confusion > in this case. > > Is that a feasible scenario ? I haven't read your draft for sometime > now so maybe it's already covered ? > > Cheers, > Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 3 16:29:31 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15835 for ; Tue, 3 Apr 2001 16:29: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 NAA14733; Tue, 3 Apr 2001 13:28: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 NAA14487; Tue, 3 Apr 2001 13:28:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33KRaIm023099 for ; Tue, 3 Apr 2001 13:27:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f33KRa23023098 for mobile-ip-dist; Tue, 3 Apr 2001 13:27: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.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33KRLIm023091 for ; Tue, 3 Apr 2001 13:27:22 -0700 (PDT) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA14217; Tue, 3 Apr 2001 13:27:20 -0700 (PDT) Received: from darius (darius [10.6.84.105]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id NAA13351; Tue, 3 Apr 2001 13:27:17 -0700 (PDT) Date: Tue, 3 Apr 2001 13:27:16 -0700 (PDT) From: Patrice Calhoun Subject: [mobile-ip] Re: Request to add an error code in RFC2794(NAI) To: Samita Chakrabarti Cc: pcalhoun@eng.sun.com, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200104030147.f331lfWI102310@jurassic.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: > We have encountered an operator's scenario where home-agent has > a bad behavior and assigns duplicate home-addr to multiple > mobile nodes visiting the same FA. Now the question is > how would the FA communicate this wrong behavior to MN ? > The existing error codes in rfc2794 do not cover this particular > case. Also it's possible that a ill-behaving HA may allocate > addresses like 255.255.255.255 or 0.0.0.0 etc. Indeed that is a good question. So MN1 registers and gets 10.1.1.1. Now MN2 registers and gets the same address (10.1.1.1). When the registration reply is received on the FA, it detects that the HA is broken (well, it *thinks* it is broken, but it MAY have rebooted and lost all of its state, hence the duplicate address). The issue, as I understand it is that you want to communicate this particular error to the mobile, correct? > > We think it will be good idea to have a specific error code > to cover this case. So, we are proposing an additional error code > in rfc2794 for this purpose: > > INVALID_HOMEADDR 100 (Invalid homeaddress assignment) I believe that I understand the problem, but let us keep in mind that this error code is to protect against bad behavior, right? For that reason, I feel uncomfortable having a new error code, because doing so sort-of implies that it is ok to be broken. There are plentry of other ways an HA can be broken, and there is no specific error code to cover that case, such as: (e.g. NO_MORE_MEMORY_TO_ALLOCATE_VISITOR_ENTRY 666) :) :) So, why would this one specific error be different? Do others feel this is something that needs to be specified? Chairs, would adding a new error code to RFC 2794 require that it re-cycle back to proposed standard? Thanks, PatC From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 3 16:37:09 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16049 for ; Tue, 3 Apr 2001 16:37:09 -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 NAA18825; Tue, 3 Apr 2001 13:36: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 NAA16662; Tue, 3 Apr 2001 13:36:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33KZ0Im023167 for ; Tue, 3 Apr 2001 13:35:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f33KZ0dc023166 for mobile-ip-dist; Tue, 3 Apr 2001 13:35: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.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33KYpIm023159 for ; Tue, 3 Apr 2001 13:34:51 -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 NAA18459 for ; Tue, 3 Apr 2001 13:34:49 -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 OAA01373 for ; Tue, 3 Apr 2001 14:34:48 -0600 (MDT) 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 f33KYks19222 for ; Tue, 3 Apr 2001 22:34:46 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Tue Apr 03 22:34:53 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Apr 2001 22:30:27 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBD38@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Mobile Netwoks in MIPv6 Date: Tue, 3 Apr 2001 22:34:45 +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: > Isn't it always the case that a mobile node behind a > mobile router, that the mobile router must be the > mobile host's home agent? > => Well, don't think so. It may be the case but there is no need to require it. > If the mobile router moves, > wouldn't that cause the mobile host's BU to the > other home agent to become stale? > => Not if the other mobile updates its HA with a new location. I mean if you just rely on the MR updating its HA, that would still work but doesn't really give you route optmisation. Plus the MN may go somewhere else, ie. leave the MR's subnet. Hesham > Hesham Soliman (ERA) writes: > > > > Hello Thierry, > > > > One other issue you might want to consider in your draft > > is the case where the MR sends a BU that covers the entire > > prefix but another MN (with a Home address on the MR's > > subnet) sends a BU for its location which may be different > > from the MR's location. > > > > I guess it would be easy enough if the HA does a search > > on the longest Home address match to avoid the confusion > > in this case. > > > > Is that a feasible scenario ? I haven't read your draft for sometime > > now so maybe it's already covered ? > > > > Cheers, > > Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 3 16:57:44 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16821 for ; Tue, 3 Apr 2001 16:57:44 -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 NAA28351; Tue, 3 Apr 2001 13:56: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 NAA01493; Tue, 3 Apr 2001 13:56:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33KrtIm023247 for ; Tue, 3 Apr 2001 13:53:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f33KrsVv023246 for mobile-ip-dist; Tue, 3 Apr 2001 13:53: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 jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33KrkIm023239 for ; Tue, 3 Apr 2001 13:53:46 -0700 (PDT) Received: from locked (locked.Eng.Sun.COM [129.146.85.189]) by jurassic.eng.sun.com (8.12.0.Beta6+Sun/8.12.0.Beta6) with SMTP id f33KriWI249954; Tue, 3 Apr 2001 13:53:44 -0700 (PDT) Message-Id: <200104032053.f33KriWI249954@jurassic.eng.sun.com> Date: Tue, 3 Apr 2001 13:52:29 -0700 (PDT) From: Mohan Parthasarathy Subject: RE: [mobile-ip] Mobile Netwoks in MIPv6 To: Hesham.Soliman@era.ericsson.se Cc: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: lHH4nw8iEbu7y1PG/JCcYQ== 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: > > > Hello Thierry, > > One other issue you might want to consider in your draft Do we really need another draft ? From the discussions we had, it looked like some clarifications are sufficient. At least the mail from Mattias explained this clearly i guess. > is the case where the MR sends a BU that covers the entire > prefix but another MN (with a Home address on the MR's > subnet) sends a BU for its location which may be different > from the MR's location. > > I guess it would be easy enough if the HA does a search > on the longest Home address match to avoid the confusion > in this case. > This case can be easily covered in the above clarification. -mohan > Is that a feasible scenario ? I haven't read your draft for sometime > now so maybe it's already covered ? > > Cheers, > Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 3 17:01:30 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16986 for ; Tue, 3 Apr 2001 17:01: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 OAA00788; Tue, 3 Apr 2001 14:00: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 OAA04394; Tue, 3 Apr 2001 14:00:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33KxPIm023320 for ; Tue, 3 Apr 2001 13:59:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f33KxPlS023319 for mobile-ip-dist; Tue, 3 Apr 2001 13:59: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 jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33KxFIm023309 for ; Tue, 3 Apr 2001 13:59:16 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.0.Beta6+Sun/8.12.0.Beta6) with SMTP id f33KxCWI251018; Tue, 3 Apr 2001 13:59:12 -0700 (PDT) Message-Id: <200104032059.f33KxCWI251018@jurassic.eng.sun.com> Date: Tue, 3 Apr 2001 14:00:16 -0700 (PDT) From: Samita Chakrabarti Subject: [mobile-ip] Re: Request to add an error code in RFC2794(NAI) To: Pat.Calhoun@eng.sun.com Cc: charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: jvHKvTru5NbkXaeaWIp/tA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 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: > > Indeed that is a good question. So MN1 registers and gets 10.1.1.1. Now MN2 > registers and gets the same address (10.1.1.1). When the registration reply is > received on the FA, it detects that the HA is broken (well, it *thinks* it is > broken, but it MAY have rebooted and lost all of its state, hence the > duplicate address). The issue, as I understand it is that you want to > communicate this particular error to the mobile, correct? > Correct. Currently, FA cannot communicate to HA directly about this wrong behavior. So, if it gets communicated to MN properly, MN may choose to use a different HA. > So, why would this one specific error be different? Only reason, I can think of that MN would know that there's something wrong with this HA, it may decide to use another HA. If there is any other existing error code in rfc2002-bis which can clearly communicate this problem to MN, I am okey with that too, but could not find an appropriate one. "Administratively prohibited 65" is one alternative, if it makes sense. -Samita From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 3 17:23:19 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17467 for ; Tue, 3 Apr 2001 17:23:18 -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 OAA09847; Tue, 3 Apr 2001 14:21: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 OAA07275; Tue, 3 Apr 2001 14:20:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33LIdIm023478 for ; Tue, 3 Apr 2001 14:18:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f33LIddW023477 for mobile-ip-dist; Tue, 3 Apr 2001 14:18: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33LITIm023470 for ; Tue, 3 Apr 2001 14:18:30 -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 OAA28067 for ; Tue, 3 Apr 2001 14:18:30 -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 PAA23443 for ; Tue, 3 Apr 2001 15:18:29 -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.9.3/8.9.1) with ESMTP id OAA01054 for ; Tue, 3 Apr 2001 14:17:11 -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 ADL20848; Tue, 3 Apr 2001 14:18:24 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA04963; Tue, 3 Apr 2001 14:18:24 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15050.15903.982330.131130@thomasm-u1.cisco.com> Date: Tue, 3 Apr 2001 14:18:23 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Mobile Netwoks in MIPv6 In-Reply-To: <034BEFD03799D411A59F00508BDF7546013DBD38@esealnt448.al.sw.ericsson.se> References: <034BEFD03799D411A59F00508BDF7546013DBD38@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: > > Isn't it always the case that a mobile node behind a > > mobile router, that the mobile router must be the > > mobile host's home agent? > > > => Well, don't think so. It may be the case but there is no > need to require it. > > > If the mobile router moves, > > wouldn't that cause the mobile host's BU to the > > other home agent to become stale? > > > => Not if the other mobile updates its HA with a > new location. Yes, I knew I should have drawn this out first. But how does the mobile node know that the mobile router moved? > I mean if you just rely on the MR > updating its HA, that would still work but > doesn't really give you route optmisation. Isn't the real implication here that route optimization is the responsibility of that which actually moves? Ie, if the MR moves, it needs to send BU's to CN's. If the MN moves, it too needs send route optimizations? Ie, that this entire problem is recursive? That's sure what my drawing looked like unless we do something really different. Mike From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 3 17:30:29 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17663 for ; Tue, 3 Apr 2001 17:30: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 OAA13973; Tue, 3 Apr 2001 14:29:46 -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 OAA09339; Tue, 3 Apr 2001 14:29:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33LRVIm023608 for ; Tue, 3 Apr 2001 14:27:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f33LRVK8023607 for mobile-ip-dist; Tue, 3 Apr 2001 14:27: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33LRDIm023591 for ; Tue, 3 Apr 2001 14:27:13 -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 OAA00611 for ; Tue, 3 Apr 2001 14:27:14 -0700 (PDT) From: rajeev.koodli@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 PAA27290 for ; Tue, 3 Apr 2001 15:26:23 -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 f33LQGg14806 for ; Tue, 3 Apr 2001 16:26:26 -0500 (CDT) Received: from daebh01nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 3 Apr 2001 16:26:12 -0500 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Tue, 3 Apr 2001 16:26:12 -0500 Message-ID: To: mccap@research.bell-labs.com, kempf@heliopolis.eng.sun.com Cc: mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Tue, 3 Apr 2001 16:26:11 -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: Hi, How does this avoid the core problem of context _re-initialization_ ? You would still need to send IR packets (to new access router over the air interface) subsequent to handover in order to start a new context.. Anchoring it at the previous router may buy you some time, but not the bits. I reckon anchoring will bring its own set of problems. Regards, -Rajeev > -----Original Message----- > From: ext Pete McCann [mailto:mccap@research.bell-labs.com] > Sent: Tuesday, April 03, 2001 11:32 AM > To: kempf@heliopolis.Eng.Sun.COM > Cc: mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se; > seamoby@diameter.org > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile > IPv6 Handover > > > > Hi, > > I think there is a simpler solution to this problem that most people > are overlooking. > > It should be possible to keep the compressor/decompressor state at the > old access router and to tunnel the already-compressed packets to and > from the new access router. Then the MN and new access router can > renegotiate header compression state from scratch and take as long as > they want to do so, because the MN is still getting service in the > meantime. > > Someone earlier asked about support for ROHC on IP tunnels and I think > this would be a good application for that. > > We are trying to move the mountain to Mohammed and I don't see why we > can't do the reverse instead. > > -Pete > > > --- > Mailing list for Robust Header Compression WG > Archive: http://www.cdt.luth.se/rohc/ > From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 3 18:32:38 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19072 for ; Tue, 3 Apr 2001 18:32:37 -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 PAA13089; Tue, 3 Apr 2001 15:32: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 PAA19054; Tue, 3 Apr 2001 15:32:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33MUcIm024178 for ; Tue, 3 Apr 2001 15:30:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f33MUbjA024177 for mobile-ip-dist; Tue, 3 Apr 2001 15:30: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33MUFIm024163 for ; Tue, 3 Apr 2001 15:30: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 PAA17251 for ; Tue, 3 Apr 2001 15:30:16 -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 QAA00754 for ; Tue, 3 Apr 2001 16:30:05 -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 f33MU8g21267 for ; Tue, 3 Apr 2001 17:30:08 -0500 (CDT) Received: from daebh01nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 3 Apr 2001 17:30:04 -0500 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Tue, 3 Apr 2001 17:30:04 -0500 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B03213764@daeis07nok> To: mobile-ip@sunroof.eng.sun.com, Samita.Chakrabarti@eng.sun.com Cc: pcalhoun@eng.sun.com, charliep@iprg.nokia.com Subject: RE: [mobile-ip] Re: Request to add an error code in RFC2794(NAI) Date: Tue, 3 Apr 2001 17:30:04 -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: >> Samita: > > We have encountered an operator's scenario where home-agent has > > a bad behavior and assigns duplicate home-addr to multiple > > mobile nodes visiting the same FA. Now the question is > > how would the FA communicate this wrong behavior to MN ? > > The existing error codes in rfc2794 do not cover this particular > > case. Also it's possible that a ill-behaving HA may allocate > > addresses like 255.255.255.255 or 0.0.0.0 etc. > Pat: > Indeed that is a good question. So MN1 registers and gets > 10.1.1.1. Now MN2 > registers and gets the same address (10.1.1.1). When the > registration reply is > received on the FA, it detects that the HA is broken (well, > it *thinks* it is > broken, but it MAY have rebooted and lost all of its state, hence the > duplicate address). The issue, as I understand it is that you want to > communicate this particular error to the mobile, correct? > > > > > We think it will be good idea to have a specific error code > > to cover this case. So, we are proposing an additional error code > > in rfc2794 for this purpose: > > > > INVALID_HOMEADDR 100 (Invalid homeaddress assignment) > > I believe that I understand the problem, but let us keep in > mind that this > error code is to protect against bad behavior, right? For > that reason, I feel > uncomfortable having a new error code, because doing so > sort-of implies that > it is ok to be broken. There are plentry of other ways an HA > can be broken, > and there is no specific error code to cover that case, such as: > > (e.g. NO_MORE_MEMORY_TO_ALLOCATE_VISITOR_ENTRY > 666) :) :) > > So, why would this one specific error be different? > > Do others feel this is something that needs to be specified? > Not if you do not have to. > Chairs, would adding a new error code to RFC 2794 require > that it re-cycle > back to proposed standard? > Adding new error code(s) to cover various scenarios will definitely cause the RFC to be recycled (IMO). But I need to check to see the process and see if adding error codes will cause that. > Thanks, > > PatC > From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 3 18:42:37 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19298 for ; Tue, 3 Apr 2001 18:42: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 PAA12034; Tue, 3 Apr 2001 15:42: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 PAA21884; Tue, 3 Apr 2001 15:42:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33MemIm024262 for ; Tue, 3 Apr 2001 15:40:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f33MemQ3024261 for mobile-ip-dist; Tue, 3 Apr 2001 15:40: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33MebIm024254 for ; Tue, 3 Apr 2001 15:40:37 -0700 (PDT) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA28600; Tue, 3 Apr 2001 15:40:34 -0700 (PDT) Received: from darius (darius [10.6.84.105]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id PAA15697; Tue, 3 Apr 2001 15:40:32 -0700 (PDT) Date: Tue, 3 Apr 2001 15:40:30 -0700 (PDT) From: Patrice Calhoun Subject: RE: [mobile-ip] Re: Request to add an error code in RFC2794(NAI) To: Basavaraj.Patil@nokia.com Cc: mobile-ip@sunroof.eng.sun.com, Samita.Chakrabarti@eng.sun.com, pcalhoun@eng.sun.com, charliep@iprg.nokia.com In-Reply-To: "Your message with ID" <7B5C0390ACE7D211BC9C0008C7EABA2B03213764@daeis07nok> 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: > > > > Do others feel this is something that needs to be specified? > > > > Not if you do not have to. Then I would opt for 64 (reason unspecified). A mobile node can always try another Home Agent, if it wishes to (although, this is easier said than done). > > > Chairs, would adding a new error code to RFC 2794 require > > that it re-cycle > > back to proposed standard? > > > > Adding new error code(s) to cover various scenarios will definitely cause > the RFC to be recycled (IMO). But I need to check to see the process and see > if adding error codes will cause that. Which simply adds more reluctance on my part to change the RFC. PatC From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 3 20:32:31 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20998 for ; Tue, 3 Apr 2001 20:32:30 -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 RAA23029; Tue, 3 Apr 2001 17:32:09 -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 RAA21606; Tue, 3 Apr 2001 17:32:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f340UCIm024474 for ; Tue, 3 Apr 2001 17:30:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f340UCFu024473 for mobile-ip-dist; Tue, 3 Apr 2001 17:30: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f340U2Im024466 for ; Tue, 3 Apr 2001 17:30:03 -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 RAA21359 for ; Tue, 3 Apr 2001 17:30:02 -0700 (PDT) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id RAA21595 for ; Tue, 3 Apr 2001 17:30:01 -0700 (PDT) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Tue Apr 3 20:29:40 EDT 2001 Received: from king.research.bell-labs.com ([135.1.152.1]) by scummy; Tue Apr 3 20:29:38 EDT 2001 Received: from notmafia.research.bell-labs.com.research.bell-labs.com (notmafia [135.1.152.230]) by king.research.bell-labs.com (Postfix) with SMTP id 9D6C25701F; Tue, 3 Apr 2001 19:29:37 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Pete McCann To: rajeev.koodli@nokia.com Cc: kempf@heliopolis.eng.sun.com, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover In-Reply-To: References: X-Mailer: VM 6.33 under Emacs 19.34.2 Message-Id: <20010404002937.9D6C25701F@king.research.bell-labs.com> Date: Tue, 3 Apr 2001 19:29:37 -0500 (CDT) Sender: owner-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 Yes, you would need to re-initialize the context over the air, but I don't think the bandwidth usage is high enough to matter. In a wide-area cellular environment IP handoffs will be relatively infrequent. The important consideration is the "glitch" experienced in voice traffic at handoff time, and this can be minimized by temporarily anchoring the compressor. -Pete rajeev.koodli@nokia.com (rk) writes: rk> Hi, rk> How does this avoid the core problem of context rk> _re-initialization_ ? You would still need to send IR packets (to rk> new access router over the air interface) subsequent to handover rk> in order to start a new context.. Anchoring it at the previous rk> router may buy you some time, but not the bits. I reckon rk> anchoring will bring its own set of problems. rk> Regards, rk> -Rajeev >> -----Original Message----- >> From: ext Pete McCann [mailto:mccap@research.bell-labs.com] >> Sent: Tuesday, April 03, 2001 11:32 AM >> To: kempf@heliopolis.Eng.Sun.COM >> Cc: mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se; >> seamoby@diameter.org >> Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile >> IPv6 Handover >> >> >> >> Hi, >> >> I think there is a simpler solution to this problem that most people >> are overlooking. >> >> It should be possible to keep the compressor/decompressor state at the >> old access router and to tunnel the already-compressed packets to and >> from the new access router. Then the MN and new access router can >> renegotiate header compression state from scratch and take as long as >> they want to do so, because the MN is still getting service in the >> meantime. >> >> Someone earlier asked about support for ROHC on IP tunnels and I think >> this would be a good application for that. >> >> We are trying to move the mountain to Mohammed and I don't see why we >> can't do the reverse instead. >> >> -Pete >> >> >> --- >> Mailing list for Robust Header Compression WG >> Archive: http://www.cdt.luth.se/rohc/ >> rk> --- rk> Mailing list for Robust Header Compression WG rk> Archive: http://www.cdt.luth.se/rohc/ From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 3 21:00:58 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21319 for ; Tue, 3 Apr 2001 21:00: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 SAA02392; Tue, 3 Apr 2001 18:00:32 -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 SAA22114; Tue, 3 Apr 2001 18:00:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f340xAIm024559 for ; Tue, 3 Apr 2001 17:59:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f340xAqE024558 for mobile-ip-dist; Tue, 3 Apr 2001 17:59: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.Beta5+Sun/8.12.0.Beta5) with ESMTP id f340wxIm024551 for ; Tue, 3 Apr 2001 17:58:59 -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 RAA24659 for ; Tue, 3 Apr 2001 17:58:59 -0700 (PDT) From: rajeev.koodli@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 SAA08105 for ; Tue, 3 Apr 2001 18:58:48 -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 f340wog28529 for ; Tue, 3 Apr 2001 19:58:50 -0500 (CDT) Received: from daebh01nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 3 Apr 2001 19:58:46 -0500 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Tue, 3 Apr 2001 19:58:46 -0500 Message-ID: To: mccap@research.bell-labs.com, rajeev.koodli@nokia.com Cc: kempf@heliopolis.eng.sun.com, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Tue, 3 Apr 2001 19:58:45 -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: > -----Original Message----- > From: ext Pete McCann [mailto:mccap@research.bell-labs.com] > Sent: Tuesday, April 03, 2001 5:30 PM > To: rajeev.koodli@nokia.com > Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > rohc@cdt.luth.se; seamoby@diameter.org > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile > IPv6 Handover > > > > > Yes, you would need to re-initialize the context over the air, but I > don't think the bandwidth usage is high enough to matter. In a > wide-area cellular environment IP handoffs will be relatively > infrequent. The important consideration is the "glitch" experienced > in voice traffic at handoff time, and this can be minimized by > temporarily anchoring the compressor. > I don't agree with you comments that you could ignore bandwidth usage and assume infrequent handovers. a> 84 bytes of IPv6/UDP/RTP headers with Mobile-IPv6 Home Address option for a voice payload of 20 - 30 bytes. Several such packets sent per each stream. b> With fast user mobility, each BTS/AP being a router, I can imagine frequent handovers. In any case, context relocation addresses a>, does not assume infrequent handovers, as well as attempts to provide "glitch-free" voice. When the context is already present at the target router before the MN starts sending compressed packets, the application should not see the glitch. I know there is work to be done here, so let's try to focus on that! Regards, -Rajeev > -Pete > > rajeev.koodli@nokia.com (rk) writes: > > rk> Hi, > > rk> How does this avoid the core problem of context > rk> _re-initialization_ ? You would still need to send IR packets (to > rk> new access router over the air interface) subsequent to handover > rk> in order to start a new context.. Anchoring it at the previous > rk> router may buy you some time, but not the bits. I reckon > rk> anchoring will bring its own set of problems. > > rk> Regards, > > rk> -Rajeev > > > >> -----Original Message----- > >> From: ext Pete McCann [mailto:mccap@research.bell-labs.com] > >> Sent: Tuesday, April 03, 2001 11:32 AM > >> To: kempf@heliopolis.Eng.Sun.COM > >> Cc: mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se; > >> seamoby@diameter.org > >> Subject: RE: [seamoby] RE: [rohc] RE: Restarting > Compressor on Mobile > >> IPv6 Handover > >> > >> > >> > >> Hi, > >> > >> I think there is a simpler solution to this problem that > most people > >> are overlooking. > >> > >> It should be possible to keep the compressor/decompressor > state at the > >> old access router and to tunnel the already-compressed > packets to and > >> from the new access router. Then the MN and new access router can > >> renegotiate header compression state from scratch and take > as long as > >> they want to do so, because the MN is still getting service in the > >> meantime. > >> > >> Someone earlier asked about support for ROHC on IP tunnels > and I think > >> this would be a good application for that. > >> > >> We are trying to move the mountain to Mohammed and I don't > see why we > >> can't do the reverse instead. > >> > >> -Pete > >> > >> > >> --- > >> Mailing list for Robust Header Compression WG > >> Archive: http://www.cdt.luth.se/rohc/ > >> > rk> --- > rk> Mailing list for Robust Header Compression WG > rk> Archive: http://www.cdt.luth.se/rohc/ > From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 3 21:45:15 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA22850 for ; Tue, 3 Apr 2001 21:45:15 -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 SAA13359; Tue, 3 Apr 2001 18:44: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 SAA03890; Tue, 3 Apr 2001 18:44:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f341eLIm024739 for ; Tue, 3 Apr 2001 18:40:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f341eKcL024738 for mobile-ip-dist; Tue, 3 Apr 2001 18:40: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f341e7Im024731 for ; Tue, 3 Apr 2001 18:40:08 -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 SAA27538 for ; Tue, 3 Apr 2001 18:40:01 -0700 (PDT) From: rajeev.koodli@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 TAA23574 for ; Tue, 3 Apr 2001 19:40:00 -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 f341drg00044 for ; Tue, 3 Apr 2001 20:40:03 -0500 (CDT) Received: from daebh02nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 3 Apr 2001 20:39:49 -0500 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Tue, 3 Apr 2001 20:39:49 -0500 Message-ID: To: tmima@cisco.com, mccap@research.bell-labs.com Cc: kempf@heliopolis.eng.sun.com, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Tue, 3 Apr 2001 20:39:49 -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 Tmima, some comments below. Regards, -Rajeev > -----Original Message----- > From: ext Tmima Koren [mailto:tmima@cisco.com] > Sent: Tuesday, April 03, 2001 6:19 PM > To: rajeev.koodli@nokia.com; mccap@research.bell-labs.com; > rajeev.koodli@nokia.com > Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > rohc@cdt.luth.se; seamoby@diameter.org > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile > IPv6 Handover > > > I wonder if it's possible to do both: > The new router sends a request for context transfer, but continues to > forward the compressed packets to the old router, AND queues > a copy of the > packets he forwarded. Once he receives the context, the new > router applies > the necessary changes to the context from the queued packets. Now his > context is good and he can continue decompressing. > Tmima > It may be possible to do both, perhaps should not be necessary. One of the requirements for seamoby will be to meet a fast response time requirement that would mean that the context has to be present at the new router when compressed packets arrive. In your proposal, I also see the need for synchronizing (more than one) compressed buffered packets with the context that arrives later. This may be non-trivial. Regards, -Rajeev > At 07:58 PM 4/3/2001 -0500, rajeev.koodli@nokia.com wrote: > > > -----Original Message----- > > > From: ext Pete McCann [mailto:mccap@research.bell-labs.com] > > > Sent: Tuesday, April 03, 2001 5:30 PM > > > To: rajeev.koodli@nokia.com > > > Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > > > rohc@cdt.luth.se; seamoby@diameter.org > > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting > Compressor on Mobile > > > IPv6 Handover > > > > > > > > > > > > > > > Yes, you would need to re-initialize the context over the > air, but I > > > don't think the bandwidth usage is high enough to matter. In a > > > wide-area cellular environment IP handoffs will be relatively > > > infrequent. The important consideration is the "glitch" > experienced > > > in voice traffic at handoff time, and this can be minimized by > > > temporarily anchoring the compressor. > > > > > > >I don't agree with you comments that you could ignore > bandwidth usage and > >assume infrequent handovers. > > > >a> 84 bytes of IPv6/UDP/RTP headers with Mobile-IPv6 Home > Address option for > >a voice payload of 20 - 30 bytes. Several such packets sent > per each stream. > > > >b> With fast user mobility, each BTS/AP being a router, I can imagine > >frequent handovers. > > > >In any case, context relocation addresses a>, does not > assume infrequent > >handovers, as well as attempts to provide "glitch-free" > voice. When the > >context is already present at the target router before the > MN starts sending > >compressed packets, the application should not see the glitch. > >I know there is work to be done here, so let's try to focus on that! > > > >Regards, > > > >-Rajeev > > > > > > > -Pete > > > > > > rajeev.koodli@nokia.com (rk) writes: > > > > > > rk> Hi, > > > > > > rk> How does this avoid the core problem of context > > > rk> _re-initialization_ ? You would still need to send IR > packets (to > > > rk> new access router over the air interface) subsequent > to handover > > > rk> in order to start a new context.. Anchoring it at > the previous > > > rk> router may buy you some time, but not the bits. I reckon > > > rk> anchoring will bring its own set of problems. > > > > > > rk> Regards, > > > > > > rk> -Rajeev > > > > > > > > > >> -----Original Message----- > > > >> From: ext Pete McCann [mailto:mccap@research.bell-labs.com] > > > >> Sent: Tuesday, April 03, 2001 11:32 AM > > > >> To: kempf@heliopolis.Eng.Sun.COM > > > >> Cc: mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se; > > > >> seamoby@diameter.org > > > >> Subject: RE: [seamoby] RE: [rohc] RE: Restarting > > > Compressor on Mobile > > > >> IPv6 Handover > > > >> > > > >> > > > >> > > > >> Hi, > > > >> > > > >> I think there is a simpler solution to this problem that > > > most people > > > >> are overlooking. > > > >> > > > >> It should be possible to keep the compressor/decompressor > > > state at the > > > >> old access router and to tunnel the already-compressed > > > packets to and > > > >> from the new access router. Then the MN and new > access router can > > > >> renegotiate header compression state from scratch and take > > > as long as > > > >> they want to do so, because the MN is still getting > service in the > > > >> meantime. > > > >> > > > >> Someone earlier asked about support for ROHC on IP tunnels > > > and I think > > > >> this would be a good application for that. > > > >> > > > >> We are trying to move the mountain to Mohammed and I don't > > > see why we > > > >> can't do the reverse instead. > > > >> > > > >> -Pete > > > >> > > > >> > > > >> --- > > > >> Mailing list for Robust Header Compression WG > > > >> Archive: http://www.cdt.luth.se/rohc/ > > > >> > > > rk> --- > > > rk> Mailing list for Robust Header Compression WG > > > rk> Archive: http://www.cdt.luth.se/rohc/ > > > > From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 4 00:41:22 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA26230 for ; Wed, 4 Apr 2001 00:41: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 VAA13998; Tue, 3 Apr 2001 21:40:40 -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 VAA22777; Tue, 3 Apr 2001 21:40:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f344dJIm024917 for ; Tue, 3 Apr 2001 21:39:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f344dI7o024916 for mobile-ip-dist; Tue, 3 Apr 2001 21:39:18 -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.Beta5+Sun/8.12.0.Beta5) with ESMTP id f344dAIm024909 for ; Tue, 3 Apr 2001 21:39:10 -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 VAA10581 for ; Tue, 3 Apr 2001 21:39:09 -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 WAA21132 for ; Tue, 3 Apr 2001 22:39:08 -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 f344dAg02814 for ; Tue, 3 Apr 2001 23:39:10 -0500 (CDT) Received: from daebh01nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 3 Apr 2001 23:39:06 -0500 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Tue, 3 Apr 2001 23:39:06 -0500 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B03B82811@daeis07nok> To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] IETF 50 - WG meeting minutes Date: Tue, 3 Apr 2001 23:39:04 -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: Thanks to David Frascone for providing the meeting minutes of the Mobile IP WG meeting at IETF50. Thursday, March 22nd 2001 - 9:00 AM - 11.30 AM ---------------------------------------------- Basavaraj: >> Agenda bashing: Modifications to the published agenda. Steve Glass unable to make it to this meeting. WG mailing list has been moved to a new server hosted by Sun. Archives are in the process of being transferred. Steve Glass has agreed to administer the list. >> WG Doc status: New RFCs: 2034 (Obsoletes 2344) - Reverse Tunneling RFC 2035 Vendor specific extensions Drafts: mobileip-ipv6. Blocked by IESG for security concerns. 2002bis passed last call. mobileip-gnaie - In IESG bin. Drafts in Limbo: mobileip-mier. Drafts that have completed last call: mobileip-optim reg-tunnel 3gwireless-ext Drafts going to WG last call mobileip-key-aaa New WG documents glass-mobileip-reg-revok mobileip-lowlatency-handoffs-v4 mobileip-fast-mipv6 >> Milestone Review >> IESG Security concerns with MIPv6 Thomas Narten has sent out the IESG statement to the Mobile IP mailing list which notes the issues identified w.r.t security for the Mobile IPv6 spec. 9:14 - Jeff Schiller - Security and Mobile IPv6 ------------------------------------------------ Discussed the security issues from the perspective of scalability and the way IPSec is used in Mobile IP. How can we tell the difference between legitimate updates and attackers. IPSEC/AH? It's an authentication protocol. Can't it be used? Bottom line: IPSEC is not a good fit for a situation where you want to protect some packets, but not all packets. IPSEC has a policy database to determine whether to send the packet encrypted or authenticated. It's an all or nothing type of approach. Other bad things with IPSEC: KEY negotiation requires several handshakes State No protection against man in the middle Requires PKI based on IP addresses And, it is not ready now . . . No telling how long it will take to build a PKI architecture. IPSEC is used today to build VPNs. In them, the admins usually set up a private PKI. But, how do you do a PKI on the scale of the internet? Minimal Requirements for Security: No security exposures beyond today's IPv4 But, why not do it better? Man in the middle attack "ok" if launched by an attacker in the path. Protecting against this is very hard. We eventually have to solve this problem when wireless takes off. PBK: One approach Purpose Built Keys. End point creates public key pair and EID. EID is hash of public key. Fixed length, reasonably short. Send the EID to the correspondent node. Correspondent node ACKs. EIDs and keys change to provide privacy Once EIDs are known, then you can authenticate any packet you want by signing the update with the private key, and transmitting the public key in the update. Since the EID has already been sent, then the binding update can be verified, and the EID can be checked by hashing the public key. HIP (Host Identity) Similar in ways to PBK. Designed to solve a more broad problem. Is an architectural shift. Can be made to solve the binding update. . . Security AD hat on: No solution is particularly favored. Security requirements must be met. Punting security is not an option. IESG position: See AD position :) For the extended debate and questions, please look at section A1 of these minutes. Connectathon Report: --------------------- Alper Yegin: What Connectathon is . . . 14 mobile ip participants 9 ipv6 6 mobileip v4 3 test suites for v6 1 suite for v4 IPv6 8 correspondent nodes 6 HAs 4 nodes IPv4 6 agents 3 nodes Observations: Specifications on movement detection need to be looked at. Different interfaces of the same router can have the same MAC address, therefore some link-local address. Sending Binding Update Acknowledgment. What if the COA was invalid or multicast or unspecified. HA address discovery. We don't need to send the home address since it's the same as the destination address. Someone: There was an agreement on the list to remove that . . Timing issues with BUs - can be fixed in implementations. ICMPs can delete binding cache (destinations unreachable) Attackers can forge these, and delete all the binding cache entries. Deregistering of Care-Of-Address. Carl Williams: Only had one participant implement IPv4 route optimization. Observations: Might need a blurb that the FA may check the existence of the MN_HA Auth extension. FA could override an error created by the HA. if the FA_HA authenti- cation is invalid, and the Home Agent was already returning an error. Charlie: I don't know if there's anything to be done. One implementation upon error would set the lifetime to zero. Reverse Tunneling Private addressing - the RFC was not clear that the private address support was mandatory, since it was in the appendix. Basavaraj: Samita is working on a draft that clarifies this. Should Failed registration replies contain the challenge? Pat will fix the text How does the FA track the challenge sent to MNs that solicit for advertisements? Final coments: Issues with agent solicitation. Dynamic home address allocation -- Who should give out the addresses? AAA or HA? Handoff Discussions ------------------- >>George Tsirtsis(IPv6 fast handoff): We have made changes to the design team draft. We have a new type called fast binding update. The other change is that there is a new type for advertisements. Michael Thomas: Is this the fast v6 handoff? Brought up an issue on the seamoby list. What you are in fact doing is context transfer. You're loosing flexibility on fast mobility. There may be cases where you don't want the routers know about each other. If the problem is solved already, why Someone: Your objection is to the transfer. Design team guy (DT): The only purpose of the ICMP is to get the COA of the mobile. Michael Thomas (MT): It is moving the state. What is being positive here is a vessel for what seamoby should be doing. Basavaraj: The packet *could* be used for context transfer. But, we're not doing context transfer. MT: But now, we'll have two different messages sent to move a mobile node. Eric Nordmark: Charter issues are not a good use of our time here. Next steps - Face to face meeting . . . as soon as next week. Discuss ping-pong, bucketing, resolve comments from mailing list, release a new version. Someone: As soon as the MN gets a new layer2, it should be able to send packets right away. Currently to rely on the neighbor advertisement adds a round trip time. George: We are looking into some optimizations. Someone: If mobile node has packets to send, then it needs to be able to send them. Even though it can't receive yet. (Until the update is finished) MT: There are three things going on. I think it would be very useful to decompose them so that you can choose to do any of the three, but not be required to do all three. George: It is very tightly coupled. Gopal: The messages are not tightly coupled . . . . or maybe they are. >>Karim: Low latency handoffs in ipv4 Compilation of the fast and pro-active handoffs. Current draft is just the combination. There are new comments from Monday design team meeting. Requirements: Decrease L3 handoff disruption. Limit dependencies on L2s. Two methods: Network Assisted Mobile and Network controlled (NAMONIC) Network Initiated, mobile Terminated (NIMOT) Work ongoing trying to get the two methods more integrated. Planed additions: rewrite intro include L2 trigger chart Make methods independent of Regional registrations move RR application into new section. move bicasting to new section NAMONIC Mobile Initiated: new extensions to (Proxy) Router solicitation to include L2 ID (eg. AP ID) Michael Thomas: It would be nice if the terminology between the IPv6 and IPv4 were the same. Jim: I think the terms should be the same, but don't merge v4 and v6 hand off documents. Gopal: I don't think there is any need for hierarchical stuff in this draft. Design Team(DT): This is to make IPv4 handoff faster. Gopal: A proxy registration will also make it fast. DT: Take it to list. Someone: Hierarchical MIP helps you with the handoff? Is that what you said? DT: It *could* help reduce the latency. Someone: It doesn't go any faster than basic fast handoff Pat: We didn't put hierarchical in the draft to make it faster, we did it to show that it could coexist. Someone else: In bicasting, it is assumed that you know the new COA, right? Mikael Dagermark: E-mail archive website doesn't work. Phil: It's being worked on. Someone: Are design teams closed? Phil: Yes. Pat: I don't think the V4 group is closed .. . don't even think it exists anymore. Phil: take it to the list >> Youngjune Gwon L3 triggering. L3 triggering provides the mobile with the best next future agent to send a solicitation to. L3 process may be independent of L2 information. Why use this? Access L2 diversity (WLAN, RAN, etc) Changes in L1/L2 affect L3 minimally . . faster deployment Inter-access technology handoffs Useful if L2 triggers not possible. Operational Summary Network layer mobility prediction L3 per packet latency prediction access point selection - next agent selected - Architectural assumptions Latency must be measured between MN and BTS MN is able to listen to different Base stations simultaneously L3 signaling is essential .. . L2 signaling is even better. Multi L3 links to BTSs Multiple L3 entries possible for same L2 link. L3MP - Latency prediction - Access point selection. Latency measurement Router advertisement packet Simpler packet format using ICMP timestamp (ping) IPHeader with agents ipaddress authentication (optional) Discussion at end of this report in section A3 Improving network renumbering in MIPv6 -------------------------------------- TJ Kniveton Today's situation Draft 13 shows how to renumber There were some issues . . . we're going to present our solutions: Tunneled router solicititaions are sent from the HA to the MN when the MN is autoconfiguring. Problems: Bootstrap - The MN is autoconfiguring itself. MN should not use unspecified address - Hard to form security association. Problems: Efficiency - Encap. seems to be a way to get around the TTL issue. Excessive info is sent to mobile node. Encap not necessary. Available Options Bootstrap Issue Relax neighbor discovery TTL rule. create a new rule for processing unicast. or Create new ICMP types for mobile router solicitation and router advertisement. Recommendation Create a new ICMP type Other issues like flag cleanup, redefining and simplifying rules for prefix inclusion, and simplified rewording are also recommended. Michael Thomas (MT): These sort of things (tunneling) security really does matter. You need to not ignore the security issues. [ed: TJ was flippant about the auth header being left off of his diagram] TJ: agreed. Charlie P: Maybe it is advisable to not use AH, but include auth data fields. (from previous sec. problems with AH) MT: The situation between the HA and MN is not the same problem of the MN to the Correspondent Node. Charlie: I think we agree that the MN and HA already have a sec. assoc. I was just saying that we won't be using the bit format of AH TJ: There is a broader issue with bootstrap. If a mn boots up on a foreign network, how does it know it's HA? HMIPv6 ------ Hesham Soliman Motivation / Requirements Reduce mobile ip signaling load improve mobile ip handoff delay location privacy route optimization for mobile networks minimal impacts on mipv6 and or ipv6 reliability (robust routing) scalability Changes from last revision Introduced load balancing additional support for location privacy an optimization to allow the MN to encapsulate the HA BU into the MAP's BU General editorials Load balancing If across access technologies, a new sub option goes to the MAP and requests that a particular connection go to the other net. Maybe even per-packet load balancing could be useful. We put it in, but we believe that it's not a good idea. Detailed discussion in section A2. >>Two more scheduled timeslots had to be cancelled as the time allocated for the WG ran out. The other two slots were: 1. Dynamic configuration of Mobile hosts (Sandy Thuel) 2. QoS Discussion (Hemant Chaskar) ============================================================================ A1: Security in MIPv6 discussion -------------------------------- Questions: The larger problem is address ownership. Charlie: Likes minimal requirement :) We should meet minimal as soon as possible. Other requirements are extremely difficult to meet. Especially when three parties are involved. Whatever we come up with we need to be fast and simple. Any key establishment we set up might be vulnerable to man in the middle. Jeff: Agrees with Charlie in general. But, it's up to the WG to pick a proposal. We want something that can be implemented by every correspondent node, and is easy to implement. Jeff: Minimal requirements have a problem because we're saying a man in the middle attack is ok. Today this is the minimal requirement. In another year, it might not be the minimal requirement. There are a number of ways of doing it, and they all have advantages and disadvantages. We need to find AN answer that meets the requirement, and go with it. Jeff: But, if we pick one, and it turns out to be vulnerable, we might not be able to fix millions of devices who's algorithms might be in ROM. My *oops* e-mail has an approach that meets the minimum requirements and only uses MD5. AH comment: AH doesn't do what we want to do because we'd have to do it on every packet, only the ones with binding updates on them. I thought the SPI told you how to carry out the authentication. So, what's the problem? Maybe we just need to slightly change AH to pick out the right association and use only authenticate the proper question. Jeff: That is not a discussion for this working group. If you receive a packet with no AH header, how do you know if you can accept it based on IPSEC. One could fix that, but it would not be soon. (See previous comments on "timely") Someone: What's required now is a design team. That design team should include implementers, not just abstract architecture people. We need your view on what IPSEC does. How do we not misuse AH again? This is FUBAR and should not have happened. Could we do a mock last call on the rest of IPv6, we need the spec on the market. 3gpp is waiting on it. Phil: It's already gone through last call. It's just waiting on security. Moskowitz: HIP will allow for man in the middle protection if one of the parties is not anonymous. So, if the MN knows the HA, then it can be avoided. Francis: Allowing for man in the middle attack makes the minimal requirements too easy. The problem of PKI is difficult problem. Perhaps we want too strong security. It's easy to avoid the man in the middle attack . . . . hard to understand. Jeff: To guard against man in the middle you only have to authenticate strongly one side. Perhaps you should strongly authenticate the correspondent node, and put his public key into DNS. If DNS security is deployed, then we get a security upgrade, and it's protects against man in the middle. Michael Thomas: Authorization is not the same as Authentication. Even if we could authenticate, it does not say who is allowed to have a particular address. Jeff: If we're not careful, we could get into a case of diminishing returns. In practice traffic re-routing is not a problem. Why would you want to send your traffic somewhere else. There is a problem if you can say "send that guys' traffic to me" Michael: The schemes that are floating around require a reachability test. What I don't understand about PPK draft is, "What are the public keys giving you beyond what the reachability gives you?" What's the difference between that and symmetric keys. Jeff: Correspondents don't have to store large numbers of secrets. Michael: So, basically it's a memory vs cpu issue. Jeff: And, the mobile node doesn't have to keep state. Someone: I have no expertise in key exchange/generation, but I'm curious about the AH problem. Someone else: I'm not a fan of triangular routing. I want to make sure no one has called into question the security between home agent and mobile node. We need to get this right. Don't rush it, even if 3gpp needs it now. They can live with triangular routes until we solve this problem right. Phil: From now on, only questions specific to this point, not ways to solve the problem. Someone: The requirements are the same ones that we had for IPv4. But, barely good enough security was considered no longer secure enough for route optimization. So, now suddenly, it's ok again? Jeff: I can't comment on the history. If I had it my way, I'd want something much stronger than this, but I'm willing to compromise. Someone: Mobileip is out there. It's been through several last calls. Jeff: We need to move forward. Why rehash the past. Someone: But, why is the IESG doing this now? Maybe that's our fault, maybe IPSEC's fault. But, we need to do it right this time. Not do all the machinications and at the last minute get held up again. Jeff: The IESG is VERY busy. Let's not try to design process to deal with a point solution, because tomorrows problem will be different. Gabriel: I like the PPK basic idea. What I think would make it even stronger would be to do the homework. HIP has been working for over a year. We need to do a little bit more architecture to him (and not solve the point problem) so that mobile IP and other protocols could leverage it. If you do the homework on PPK, you'll probably end up with something very much like hip. Someone: I think cookies are sufficient. Charlie: There are two possible ways to get done. one is to put out a ipv6 spec that doesn't require AH any more, but requires some kind of binding key. Then, release another draft on how to come up with the binding key. That way, IPv6 can go through last call, and the security will not hold it up. Jeff: To see if security is secure, you have to do an analysis. Charlie: But, I wasn't talking about the algorithm, I want . Jeff: What I want is for it to be secure. Charlie: But, what you do is put out a draft, and then decide how to make a binding key later. Jeff: I think you have to have a complete solution. IPSEC guy from sun: There were some comments as to whether AA was appropriate, or IPSEC was appropriate. Most implementations made tradeoffs for simplicity. Adding complexity there is not something we're interested in doing. So, not authenticating binding updates is not good enough Phil: We will be setting up a design team. A2: HMIPv6 Discussion ---------------------- Michael Thomas: Using terms like "Mobile Routers" is not a good idea, unless you consider hosts behind them, and mobile routers behind mobile routers. Hesham Soliman (HS): Leaving that part out doesn't bother me. Someone: Increasing robustness creates delay. HS: Solution should be as robust as possible. . Someone: In the presence of fast handoffs, this does not provide any improvements in delay. HS: Agreed. Jim: Charlie sent good comments to the list. I think that the load balancing really needs to go. It is dangerous. In general it needs some editorial work. There are lots of ideas in here, and probably needs to be cleaned. HS: I think that the comment about load balancing should not be used with TCP can be removed. Jim: There are two requirements that I didn't see there: Signaling and per packet overhead must be reduced. And, arbitrary levels of hierarchy must be possible. HS: overhead was to be solved with header compression. We'll take that to the list. Jim: I don't know of any evidence that header compression will work on mip packets. . .not that it won't, but it needs to be studied before we rely on it. Jim and HS - go offline. Someone: If you're making a routing decision on a packet or port, then it's a Layer four switch. Changing that policy dynamically (what you're suggesting) is not routing . . it's embedding single points of failure in the network. Someone else: I agree that any level of hierarchy is bad. I want to raise a couple of issues about scalability. I fyou're using only one layer of hierarchy, your signaling the one route you choose. And if you change the route you register with all the corresponding nodes. So, this means that in the design you specified you support only one box, and you overload other functionalities like bicasting and load balancing. HS: So, the issue is using one box? I haven't seen any other proposal that uses more than one box. Charlie: I don't like having two modes of attaching a coa. the coa in the map, vs the coa in a little source route. I don't think the mn should have an address on a network that he knows nothing about. So, my proposal is that the basic mode be removed, and the extended go forward. One other note is that the draft talks about too much. It doesn't need to talk about configuring the routing network, load balancing, smooth handovers, aaa, etc HS: We just mention them, we don't discuss them. phil: There is a lot of feedback about the draft. We need to take this to the list, and decide what really belongs in the draft. Samita: will take her comments off line. phil: Did not get to dynamic configuration, qos, and agenda. A3 : draft-gwon-mobileip-l3mp-mipv4-00.txt) ------------------------------------------- Similar to other handoffs, except it is triggered by L3 predictions. Jim: This is not independent of the L2 access technology. All this is doing is sending a beacon. RFC2002 says that it is ok to beacon. The reason we have fast handoff discussions is because this is not fast enough. This is not L2 independent. In 802.11 you can not choose access points, you don't have control over it. This will not work on a wireless lan. Alper: How can you map L3 latency to L2? Youngjune Gwon (YG): All that we want to do is perform a L3 hand off based on L3 variables, such as latency. Alper: So, your L3 tells L2 to handoff now? YG: That's possible Alper: The beacons have to be fast, or this won't work. YG: that's right. someone: I think you're describing a basic implementation of MIP. I think if you have a draft, it needs to show how it normally doesn't work with MIP. Michael Thomas: I don't see what you're trying to do here that is not already supported by mobile ip. Can you clarify what problem you're trying to solve here that is not already solved. Basavaraj: There may be ideas here that would be of interest to the design team. Someone else: Are you talking about latency between the mobile and the routers. Have you considered multipath in your latency? Phil: Take it outside . . . Discussion curtailed as it was felt that this work was not in the current scope of the Mobile IP WG. From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 5 17:49:30 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15319 for ; Thu, 5 Apr 2001 17:49:29 -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 OAA24845; Thu, 5 Apr 2001 14:48: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 OAA03244; Thu, 5 Apr 2001 14:48:40 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta7) with ESMTP id f35LlFsv027568 for ; Thu, 5 Apr 2001 14:47:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta7) id f35LlE6d027567 for mobile-ip-dist; Thu, 5 Apr 2001 14:47: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.Beta5+Sun/8.12.0.Beta7) with ESMTP id f35Ll5sv027560 for ; Thu, 5 Apr 2001 14:47:06 -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 OAA19611 for ; Thu, 5 Apr 2001 14:47:06 -0700 (PDT) Received: from hotmail.com (f248.law7.hotmail.com [216.33.237.248]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA18697 for ; Thu, 5 Apr 2001 14:47:06 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 5 Apr 2001 14:47:05 -0700 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Thu, 05 Apr 2001 21:47:05 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Requirements Draft for Mobile IP QoS - Invitation to Volunteer Date: Thu, 05 Apr 2001 21:47:05 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 05 Apr 2001 21:47:05.0861 (UTC) FILETIME=[F4E6F350:01C0BE19] Sender: owner-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 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 From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 5 19:19:41 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA16421 for ; Thu, 5 Apr 2001 19:19:41 -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 QAA15525; Thu, 5 Apr 2001 16:19:15 -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 QAA23352; Thu, 5 Apr 2001 16:19:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f35NGpK9027924 for ; Thu, 5 Apr 2001 16:16:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f35NGpdB027923 for mobile-ip-dist; Thu, 5 Apr 2001 16:16: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f35NGgK9027916 for ; Thu, 5 Apr 2001 16:16:42 -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 QAA20467 for ; Thu, 5 Apr 2001 16:16:42 -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 QAA00694 for ; Thu, 5 Apr 2001 16:16:41 -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 QAA04858 for ; Thu, 5 Apr 2001 16:16:40 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f35NGdK19619 for ; Thu, 5 Apr 2001 16:16:39 -0700 X-mProtect: Thu, 5 Apr 2001 16:16:39 -0700 Nokia Silicon Valley Messaging Protection Received: from mvdhcp14166.americas.nokia.com (172.18.141.66, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdhlpvpS; Thu, 05 Apr 2001 16:16:09 PDT Message-ID: <3ACCFC93.239BC9CB@iprg.nokia.com> Date: Thu, 05 Apr 2001 16:15:32 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Requirements Draft for Mobile IP QoS - Invitation to Volunteer 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 Hey Hemant, count me in! -Rajeev 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 From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 5 21:27:14 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17483 for ; Thu, 5 Apr 2001 21:27: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 SAA23201; Thu, 5 Apr 2001 18:24: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 SAA16775; Thu, 5 Apr 2001 18:23:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f361MAK9028317 for ; Thu, 5 Apr 2001 18:22:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f361MAJn028316 for mobile-ip-dist; Thu, 5 Apr 2001 18:22: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 jurassic.eng.sun.com (jurassic [129.146.87.31] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f361LxK9028309 for ; Thu, 5 Apr 2001 18:21:59 -0700 (PDT) Received: from antley (antley.Eng.Sun.COM [129.146.86.225]) by jurassic.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with SMTP id f361LtCq832494; Thu, 5 Apr 2001 18:21:56 -0700 (PDT) Message-Id: <200104060121.f361LtCq832494@jurassic.eng.sun.com> Date: Thu, 5 Apr 2001 18:16:51 -0700 (PDT) From: Carl Williams Subject: [mobile-ip] Testing of the Mobile IP alias - don't respond. To: mobile-ip@sunroof.eng.sun.com Cc: carlw@jurassic.Eng.Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: q7SuoquEzii1viL8tvFw2Q== 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: Testing of the mobile-ip@sunroof alias. Please don't respond. Having problems earlier. Carl From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 05:11:38 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06631 for ; Fri, 6 Apr 2001 05:11: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 CAA13491; Fri, 6 Apr 2001 02:09:58 -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 CAA18563; Fri, 6 Apr 2001 02:09:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3698eK9028592 for ; Fri, 6 Apr 2001 02:08:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3698efq028591 for mobile-ip-dist; Fri, 6 Apr 2001 02:08: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3698UK9028584 for ; Fri, 6 Apr 2001 02:08:30 -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 CAA18472 for ; Fri, 6 Apr 2001 02:08:30 -0700 (PDT) From: chunan.li@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA06412 for ; Fri, 6 Apr 2001 03:08:28 -0600 (MDT) Received: from esvir06nok.ntc.nokia.com (esvir06nokt.ntc.nokia.com [172.21.143.38]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3698PS16687 for ; Fri, 6 Apr 2001 12:08:29 +0300 (EET DST) Received: from esebh01nok.ntc.nokia.com (unverified) by esvir06nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 6 Apr 2001 12:08:20 +0300 Received: by esebh01nok.ntc.nokia.com with Internet Mail Service (5.5.2652.78) id ; Fri, 6 Apr 2001 12:07:18 +0300 Message-ID: To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Requirements Draft for Mobile IP QoS - Invitation to Volunteer Date: Fri, 6 Apr 2001 11:55:20 +0300 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: Hi Hemant If possible, count me in please! ChunAn Li ---------------------------------------------------------------------------- --------------- IP Specialist Advanced Internet Technologies Group Communication Systems Lab, Nokia Research Center H1, No.11 He Ping Li Dong Jie, Beijing 100013, China Tel: +86 10 84229922 Ext.2642 Fax: +86 10 84222439 Mobile: +86 13601028331 E-mail: chunan.li@nokia.com -----Original Message----- From: ext Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Friday, April 06, 2001 7:16 AM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Requirements Draft for Mobile IP QoS - Invitation to Volunteer Hey Hemant, count me in! -Rajeev 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 From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 06:13:21 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA07053 for ; Fri, 6 Apr 2001 06:13: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 DAA13236; Fri, 6 Apr 2001 03:12: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 DAA15896; Fri, 6 Apr 2001 03:12:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36ABaK9028677 for ; Fri, 6 Apr 2001 03:11:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36ABZsD028676 for mobile-ip-dist; Fri, 6 Apr 2001 03:11: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36ABRK9028669 for ; Fri, 6 Apr 2001 03:11:27 -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 DAA04945 for ; Fri, 6 Apr 2001 03:11:26 -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 DAA08447 for ; Fri, 6 Apr 2001 03:11:24 -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 MAA08741 for ; Fri, 6 Apr 2001 12:11:08 +0200 (MEST) Message-ID: <3ACD9612.6B294697@inrialpes.fr> Date: Fri, 06 Apr 2001 12:10:26 +0200 From: Thierry Ernst Organization: INRIA Rhone-Alpes 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: [mobile-ip] Archives and mailing list troubles (again ?) 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 Dear everyone, I don't know if everyone has experienced problems in posting and receiving emails yesterday, but some have, apparently not all. This is quite annoying since no one knows where to find the archives to check what has been discussed. Archives at Nortel Networks are broken since beginning of February and if there is a new site, who knows where ? Then, if there are archives, could we please know where and could we indicate this on the Mobile IP WG charter web page ? If there are none, could we set them quickly, and could someone kindly put on the web all the mails posted from wednesday up to now and indicate url or ftp to the Mobile IP list ? Thanks very much, Thierry. From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 06:31:04 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA07188 for ; Fri, 6 Apr 2001 06:31:04 -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 DAA20381; Fri, 6 Apr 2001 03:30:23 -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 DAA10284; Fri, 6 Apr 2001 03:30:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36ASWK9028749 for ; Fri, 6 Apr 2001 03:28:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36ASWtZ028748 for mobile-ip-dist; Fri, 6 Apr 2001 03:28: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36ASLK9028741 for ; Fri, 6 Apr 2001 03:28:21 -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 DAA05885 for ; Fri, 6 Apr 2001 03:28:20 -0700 (PDT) Received: from east.isi.edu (east.isi.edu [38.245.76.2]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA09941 for ; Fri, 6 Apr 2001 03:28:20 -0700 (PDT) Received: from maia.east.isi.edu (maia.east.isi.edu [38.245.76.14]) by east.isi.edu (8.9.2/8.9.2) with SMTP id GAA03020 for ; Fri, 6 Apr 2001 06:28:12 -0400 (EDT) Posted-Date: Fri, 06 Apr 2001 06:32:56 -0400 Message-Id: <10104061032.AA27801@maia.east.isi.edu> Received: from LOCALHOST.east.isi.edu by maia.east.isi.edu (4.1/4.0.3-6) id ; Fri, 6 Apr 01 06:32:56 EDT To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Archives and mailing list troubles (again ?) In-Reply-To: Your message of Fri, 06 Apr 2001 12:10:26 +0200. <3ACD9612.6B294697@inrialpes.fr> Date: Fri, 06 Apr 2001 06:32:56 -0400 From: Allison Mankin Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Thierry Ernst wrote: > Archives at Nortel Networks are broken since > beginning of February and if there is a new site, who knows where ? It's a not too well-known fact that there are also archives for working groups on the IETF server - mobileip's are up to date there - ftp://ftp.ietf.org/ietf-mail-archive/mobileip/ for all (back to 1992 :) ftp://ftp.ietf.org/ietf-mail-archive/mobileip/current for this month ftp://ftp.ietf.org/ietf-mail-archive/mobileip/2001-03.mail etc. for prev. From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 07:42:58 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07671 for ; Fri, 6 Apr 2001 07:42: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 EAA23432; Fri, 6 Apr 2001 04:42: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 EAA21273; Fri, 6 Apr 2001 04:42:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36Bf1K9028903 for ; Fri, 6 Apr 2001 04:41:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36Bf0le028902 for mobile-ip-dist; Fri, 6 Apr 2001 04:41: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36BepK9028895 for ; Fri, 6 Apr 2001 04:40:52 -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 EAA28320 for ; Fri, 6 Apr 2001 04:40:51 -0700 (PDT) Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA11624 for ; Fri, 6 Apr 2001 04:40:46 -0700 (PDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Fri, 6 Apr 2001 06:32:47 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Apr 2001 06:38:00 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E4301C6F418@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Requirements Draft for Mobile IP QoS - Invitation to Volunteer Date: Fri, 6 Apr 2001 06:37:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0BE8E.08067BD0" 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_01C0BE8E.08067BD0 Content-Type: text/plain; charset="iso-8859-1" Hemant, Count me in as well. Glenn -----Original Message----- From: Hemant Chaskar [mailto:hchaskar@hotmail.com] Sent: Thursday, April 05, 2001 4:47 PM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Requirements Draft for Mobile IP QoS - Invitation to Volunteer 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 ------_=_NextPart_001_01C0BE8E.08067BD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Requirements Draft for Mobile IP QoS - = Invitation to Volunteer

Hemant,

Count me in as well.

Glenn

-----Original Message-----
From: Hemant Chaskar [mailto:hchaskar@hotmail.com]
Sent: Thursday, April 05, 2001 4:47 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Requirements Draft for Mobile = IP QoS - Invitation
to Volunteer


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

------_=_NextPart_001_01C0BE8E.08067BD0-- From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 07:57:50 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07794 for ; Fri, 6 Apr 2001 07:57: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 EAA04359; Fri, 6 Apr 2001 04:56: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 EAA15510; Fri, 6 Apr 2001 04:56:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36BtDK9028979 for ; Fri, 6 Apr 2001 04:55:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36BtDP3028978 for mobile-ip-dist; Fri, 6 Apr 2001 04:55: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36Bt4K9028971 for ; Fri, 6 Apr 2001 04:55:04 -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 EAA29285 for ; Fri, 6 Apr 2001 04:55:03 -0700 (PDT) Received: from atlsnmx1.nextel.com (atlsnmx1.nextel.com [167.20.198.200]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA17881 for ; Fri, 6 Apr 2001 04:55:02 -0700 (PDT) Received: from atlntgw02.nextel.com (atlntgw02.nextel.com [10.8.79.186]) by atlsnmx1.nextel.com (8.8.8+Sun/8.8.6) with ESMTP id HAA08037 for ; Fri, 6 Apr 2001 07:55:02 -0400 (EDT) Received: by atlntgw02.nextel.com with Internet Mail Service (5.5.2650.21) id <2GY2P0RZ>; Fri, 6 Apr 2001 07:55:33 -0400 Message-ID: <020A5EC56F3FD411B5230008C716D0858685CF@nhqntex01.nextel.com> From: "Martin, David P" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Requirements Draft for Mobile IP QoS - Invitation to Volunteer Date: Fri, 6 Apr 2001 07:50:06 -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 Hemant, I'd like to help out as well Dave >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 owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 08:27:13 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07997 for ; Fri, 6 Apr 2001 08:27: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 FAA15120; Fri, 6 Apr 2001 05:26: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 FAA02055; Fri, 6 Apr 2001 05:26:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36CNnK9029054 for ; Fri, 6 Apr 2001 05:23:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36CNn8J029053 for mobile-ip-dist; Fri, 6 Apr 2001 05:23: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36CNeK9029046 for ; Fri, 6 Apr 2001 05:23:41 -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 FAA24262 for ; Fri, 6 Apr 2001 05:23:39 -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 FAA00871 for ; Fri, 6 Apr 2001 05:23:39 -0700 (PDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Fri, 6 Apr 2001 08:18:19 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Archives and mailing list troubles (again ?) Date: Fri, 6 Apr 2001 08:18: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: Hi Thierry, as you know we moved from a server at Nortel to a server at Sun earlier. The new messages are being archived but the archives are not available yet. The plan is to move the old archives and bring them up along with the archives of new messages. Phil > -----Original Message----- > From: Thierry Ernst [mailto:thierry.ernst@inrialpes.fr] > Sent: Friday, April 06, 2001 6:10 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] Archives and mailing list troubles (again ?) > > > Dear everyone, > > I don't know if everyone has experienced problems in posting and > receiving emails yesterday, but some have, apparently not > all. This is > quite annoying since no one knows where to find the archives to check > what has been discussed. Archives at Nortel Networks are > broken since > beginning of February and if there is a new site, who knows where ? > > Then, if there are archives, could we please know where and could we > indicate this on the Mobile IP WG charter web page ? > > If there are none, could we set them quickly, and could someone kindly > put on the web all the mails posted from wednesday up to now and > indicate url or ftp to the Mobile IP list ? > > > Thanks very much, > Thierry. > From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 08:42:49 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08116 for ; Fri, 6 Apr 2001 08:42: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 FAA17456; Fri, 6 Apr 2001 05:41:49 -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 FAA15707; Fri, 6 Apr 2001 05:41:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36CeSK9029141 for ; Fri, 6 Apr 2001 05:40:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36CeRZC029140 for mobile-ip-dist; Fri, 6 Apr 2001 05:40:27 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36CeJK9029133 for ; Fri, 6 Apr 2001 05:40: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 FAA03438 for ; Fri, 6 Apr 2001 05:40:20 -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 GAA23853 for ; Fri, 6 Apr 2001 06:40:19 -0600 (MDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Fri, 6 Apr 2001 08:34:59 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] location privacy Date: Fri, 6 Apr 2001 08:34:57 -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: This and the next post I sent the last couple of days and never saw show up on the list. If you saw them, sorry for the duplicates. Hi, we have a charter item to "address location privacy." We'd like to gather some information about what the working group thinks the extent of the work on location privacy in this working group should be. It MUST in some serious way be connected with the Mobile IP protocol. There will be in the Apps area very soon a location privacy working group so we have to realize that this working group will not be the place to resolve all issues relating to location privacy. Phil From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 08:45:24 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08174 for ; Fri, 6 Apr 2001 08:45:23 -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 FAA24916; Fri, 6 Apr 2001 05:43:40 -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 FAA19575; Fri, 6 Apr 2001 05:43:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36CfxK9029156 for ; Fri, 6 Apr 2001 05:41:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36CfwZV029154 for mobile-ip-dist; Fri, 6 Apr 2001 05:41: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36CfmK9029146 for ; Fri, 6 Apr 2001 05:41:49 -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 FAA15719 for ; Fri, 6 Apr 2001 05:41:49 -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 FAA23624 for ; Fri, 6 Apr 2001 05:41:49 -0700 (PDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Fri, 6 Apr 2001 08:36:29 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Re: Request to add an error code in RFC2794(NAI) Date: Fri, 6 Apr 2001 08:36:28 -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: Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] > Sent: Tuesday, April 03, 2001 4:27 PM > To: Samita Chakrabarti > Cc: pcalhoun@eng.sun.com; charliep@iprg.nokia.com; > mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] Re: Request to add an error code in RFC2794(NAI) > > > > We have encountered an operator's scenario where home-agent has > > a bad behavior and assigns duplicate home-addr to multiple > > mobile nodes visiting the same FA. Now the question is > > how would the FA communicate this wrong behavior to MN ? > > The existing error codes in rfc2794 do not cover this particular > > case. Also it's possible that a ill-behaving HA may allocate > > addresses like 255.255.255.255 or 0.0.0.0 etc. > > Indeed that is a good question. So MN1 registers and gets > 10.1.1.1. Now MN2 > registers and gets the same address (10.1.1.1). When the > registration reply is > received on the FA, it detects that the HA is broken (well, > it *thinks* it is > broken, but it MAY have rebooted and lost all of its state, hence the > duplicate address). The issue, as I understand it is that you want to > communicate this particular error to the mobile, correct? > > > > > We think it will be good idea to have a specific error code > > to cover this case. So, we are proposing an additional error code > > in rfc2794 for this purpose: > > > > INVALID_HOMEADDR 100 (Invalid homeaddress assignment) > > I believe that I understand the problem, but let us keep in > mind that this > error code is to protect against bad behavior, right? For > that reason, I feel > uncomfortable having a new error code, because doing so > sort-of implies that > it is ok to be broken. There are plentry of other ways an HA > can be broken, > and there is no specific error code to cover that case, such as: > > (e.g. NO_MORE_MEMORY_TO_ALLOCATE_VISITOR_ENTRY > 666) :) :) > > So, why would this one specific error be different? > > Do others feel this is something that needs to be specified? > > Chairs, would adding a new error code to RFC 2794 require > that it re-cycle > back to proposed standard? > > Thanks, > > PatC > The following is the relevant text from 2026: "A specification may be (indeed, is likely to be) revised as it advances through the standards track. At each stage, the IESG shall determine the scope and significance of the revision to the specification, and, if necessary and appropriate, modify the recommended action. Minor revisions are expected, but a significant revision may require that the specification accumulate more experience at its current maturity level before progressing. Finally, if the specification has been changed very significantly, the IESG may recommend that the revision be treated as a new document, re- entering the standards track at the beginning. Change of status shall result in republication of the specification as an RFC, except in the rare case that there have been no changes at all in the specification since the last publication. Generally, desired changes will be "batched" for incorporation at the next level in the standards track. However, deferral of changes to the next standards action on the specification will not always be possible or desirable; for example, an important typographical error, or a technical error that does not represent a change in overall function of the specification, may need to be corrected immediately. In such cases, the IESG or RFC Editor may be asked to republish the RFC (with a new number) with corrections, and this will not reset the minimum time-at-level clock." Of course it would be up to the IESG to figure out whether such a change was so specific as to require a new iteration. But in general, we've got quite a few RFCs we'd like to advance along the standards track as time and experience develops. How about the following? Let's start a draft of implementation experiences with the Mobile IP set of protocols and track the items we'd like to update. We can track experience, errors, nonimplemented features, etc. There is a precedent in OSPF for example: http://www.ietf.org/rfc/rfc1246.txt From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 08:46:12 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08194 for ; Fri, 6 Apr 2001 08:46:12 -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 FAA18593; Fri, 6 Apr 2001 05:45: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 FAA03892; Fri, 6 Apr 2001 05:45:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36ChxK9029197 for ; Fri, 6 Apr 2001 05:43:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36Chwun029196 for mobile-ip-dist; Fri, 6 Apr 2001 05:43: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36ChnK9029189 for ; Fri, 6 Apr 2001 05:43:49 -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 FAA25755 for ; Fri, 6 Apr 2001 05:43:50 -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 GAA25476 for ; Fri, 6 Apr 2001 06:43:49 -0600 (MDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Fri, 6 Apr 2001 08:38:29 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] IPv6 Regional Registration - identifying requirements Date: Fri, 6 Apr 2001 08:38:24 -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 think I've finally caught up on all the mail about regional registrations for MIP v6 and HMIP. There seems to be significant concerns about the task to be accomplished and the specific approach that is specified in the HMIP draft. A short list of concerns include worries about introducing single points of failure, whether or not multiple levels of hierarchy are needed, the amount of signaling and tunneling overhead that is implied, the relevance of load balancing and the particular metrics in the HMIP draft, and the clarity of the description in the draft. The participants in the working group have apparently been thinking a lot about what is actually needed for a regionalized registration scheme since we adopted HMIP as a working group draft. It seems appropriate at this time to have some discussion about what the requirements for regional registration actually are, then to figure out what to do about the draft we've chosen as a working group draft. Here's a short list of requirements drawn from comments received over the last month or so and from the HMIP draft that the working group participants can use as a basis for discussion. Please understand that this is not the list of requirements I believe are needed but a list of things I've assembled from drafts and comments on the discussion. Let's take this list and try to identify the requirements that everyone agrees to and then have some discussion about the contentious ones. Requirements not on this list are also welcome for discussion. And reducing or modifying items I've listed is also open to discussion. 1) Regional registration shall be introduced to minimize the signaling traffic to the home agent or correspondent nodes for intra-domain mobility 2) Regional registration shall not introduce new overhead on links between the mobile and the regional registration agents 3) Connectivity to the mobiles shall not be interrupted in the presence of the failure of regional registration agents 4) Regional registration shall scale to support millions of nodes in a visited network 5) Regional registration shall be secure against malicious behavior from visiting mobiles 6) Regional registration shall allow multiple levels of hierarchy 7) Regional registration shall support fast handoffs 8) Regional registration shall not require changes to the mobile node, the home agent, or correspondent nodes 9) Regional registration shall not introduce host routes in routing tables From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 08:55:30 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08391 for ; Fri, 6 Apr 2001 08:55: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 FAA01962; Fri, 6 Apr 2001 05:54: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 FAA26647; Fri, 6 Apr 2001 05:54:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36CrYK9029272 for ; Fri, 6 Apr 2001 05:53:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36CrYeT029271 for mobile-ip-dist; Fri, 6 Apr 2001 05:53:34 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36CrPK9029264 for ; Fri, 6 Apr 2001 05:53:25 -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 FAA16963 for ; Fri, 6 Apr 2001 05:53:26 -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 FAA20549 for ; Fri, 6 Apr 2001 05:53:17 -0700 (PDT) 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 f36CrGI12803 for ; Fri, 6 Apr 2001 14:53:16 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id OAA25961; Fri, 6 Apr 2001 14:53:15 +0200 Message-ID: <3ACDBC66.AA6BB313@era.ericsson.se> Date: Fri, 06 Apr 2001 14:53:58 +0200 From: Mattias Pettersson Organization: Ericsson Radio Systems AB X-Mailer: Mozilla 4.75 [en] (Win95; U) X-Accept-Language: en, sv MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: Hesham.Soliman@era.ericsson.se Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6 References: <200104032053.f33KriWI249954@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 Mohan Parthasarathy wrote: > Do we really need another draft ? From the discussions we had, > it looked like some clarifications are sufficient. At least > the mail from Mattias explained this clearly i guess. I questioned if the MR must tell the HA what prefixes are behind the MR and mentioned that this must be known by the HA (and also the BRs) by other means (which we haven't figured out yet...). The MN still needs to tell CNs about the prefixes, so the draft makes sense. /Mattias From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 08:56:47 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08421 for ; Fri, 6 Apr 2001 08:56: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 FAA02893; Fri, 6 Apr 2001 05:56: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 FAA17204; Fri, 6 Apr 2001 05:56:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36CsqK9029288 for ; Fri, 6 Apr 2001 05:54:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36CsqI8029287 for mobile-ip-dist; Fri, 6 Apr 2001 05:54:52 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36CsdK9029277 for ; Fri, 6 Apr 2001 05:54: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 FAA17090 for ; Fri, 6 Apr 2001 05:54:40 -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 FAA01839 for ; Fri, 6 Apr 2001 05:54:39 -0700 (PDT) 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 f36CscI13861 for ; Fri, 6 Apr 2001 14:54:38 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id OAA26039; Fri, 6 Apr 2001 14:54:37 +0200 Message-ID: <3ACDBCB8.C5E29762@era.ericsson.se> Date: Fri, 06 Apr 2001 14:55:20 +0200 From: Mattias Pettersson Organization: Ericsson Radio Systems AB X-Mailer: Mozilla 4.75 [en] (Win95; U) X-Accept-Language: en, sv MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6 References: <034BEFD03799D411A59F00508BDF7546013DBD38@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 [Manual resend...] "Hesham Soliman (ERA)" wrote: > > > Isn't it always the case that a mobile node behind a > > mobile router, that the mobile router must be the > > mobile host's home agent? > > > => Well, don't think so. It may be the case but there is no > need to require it. Sorry Hesham, but why will the MN use HA as its home agent? In the old figure, HA was on link P1, and MN is only on link P2. I can't see that HA could act as a home agent for any MN execpt MR on link P2. Ok, I assume that we have the two independent routing entries in the HA as I was talking about earlier. /Mattias From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 09:11:34 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08625 for ; Fri, 6 Apr 2001 09:11: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 GAA11864; Fri, 6 Apr 2001 06:10:38 -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 GAA28899; Fri, 6 Apr 2001 06:10:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36D9PK9029428 for ; Fri, 6 Apr 2001 06:09:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36D9PsP029427 for mobile-ip-dist; Fri, 6 Apr 2001 06:09: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36D9EK9029413 for ; Fri, 6 Apr 2001 06:09:14 -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 GAA18577 for ; Fri, 6 Apr 2001 06:09:15 -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 GAA28789 for ; Fri, 6 Apr 2001 06:09:14 -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 PAA13407 for ; Fri, 6 Apr 2001 15:08:58 +0200 (MEST) Message-ID: <3ACDBFC1.F3E5121A@inrialpes.fr> Date: Fri, 06 Apr 2001 15:08:17 +0200 From: Thierry Ernst Organization: INRIA Rhone-Alpes 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] Mobile Netwoks in MIPv6 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 - yet another repost from Wednesday] > > Isn't it always the case that a mobile node behind a > > mobile router, that the mobile router must be the > > mobile host's home agent? > > > => Well, don't think so. It may be the case but there is no > need to require it. Agree. > > If the mobile router moves, > > wouldn't that cause the mobile host's BU to the > > other home agent to become stale? > > > => Not if the other mobile updates its HA with a > new location. I mean if you just rely on the MR > updating its HA, that would still work but > doesn't really give you route optmisation. Right. > Plus the MN may go somewhere else, > ie. leave the MR's subnet. This is yet another issue. Thierry. From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 09:13:25 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08667 for ; Fri, 6 Apr 2001 09:13:25 -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 GAA26720; Fri, 6 Apr 2001 06:08: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 GAA06347; Fri, 6 Apr 2001 06:08:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36D7YK9029375 for ; Fri, 6 Apr 2001 06:07:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36D7XQX029374 for mobile-ip-dist; Fri, 6 Apr 2001 06:07: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36D7NK9029367 for ; Fri, 6 Apr 2001 06:07:23 -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 GAA18376 for ; Fri, 6 Apr 2001 06:07:24 -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 GAA20333 for ; Fri, 6 Apr 2001 06:07:23 -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 PAA13334 for ; Fri, 6 Apr 2001 15:07:08 +0200 (MEST) Message-ID: <3ACDBF53.66A4279D@inrialpes.fr> Date: Fri, 06 Apr 2001 15:06:27 +0200 From: Thierry Ernst Organization: INRIA Rhone-Alpes 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] Mobile Netwoks in MIPv6 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 if you received this twice - mailing list was apparently broken Thursday] Hi Hesham, all, > Hesham: > Hello Thierry, > > One other issue you might want to consider in your draft > is the case where the MR sends a BU that covers the entire > prefix but another MN (with a Home address on the MR's > subnet) sends a BU for its location which may be different > from the MR's location. I have already been thinking about this but I did not include it in my draft. My draft does cover the case where the MR moves without its attached nodes, neither when a MN attaches to the mobile network. Sounds like it's time for the new revision to cover it. > I guess it would be easy enough if the HA does a search > on the longest Home address match to avoid the confusion > in this case. It depends where is the HA and what is the MN's care-of address. > Is that a feasible scenario ? I haven't read your draft for sometime > now so maybe it's already covered ? I will add a section in my draft, then we could discuss about it. Unfortunately, I do not have the time to write a new version right now, but this will be done by July and will address other issues. Cheers, 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/ From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 09:14:20 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08683 for ; Fri, 6 Apr 2001 09:14: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 GAA28715; Fri, 6 Apr 2001 06:13: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 GAA06742; Fri, 6 Apr 2001 06:12:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36DBCK9029475 for ; Fri, 6 Apr 2001 06:11:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36DBCcI029474 for mobile-ip-dist; Fri, 6 Apr 2001 06:11: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36DB0K9029460 for ; Fri, 6 Apr 2001 06:11:01 -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 GAA28983 for ; Fri, 6 Apr 2001 06:11:02 -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 GAA29786 for ; Fri, 6 Apr 2001 06:11:00 -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 PAA13476 for ; Fri, 6 Apr 2001 15:10:44 +0200 (MEST) Message-ID: <3ACDC02B.FCAF9A6B@inrialpes.fr> Date: Fri, 06 Apr 2001 15:10:03 +0200 From: Thierry Ernst Organization: INRIA Rhone-Alpes 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] Mobile Netwoks in MIPv6 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 [yet another repost - not the same ...] > Do we really need another draft ? What do you mean by another draft ? There is already one (http://www.inrialpes.fr/planete/people/ernst/Documents/draft-ernst-mobileip-v6-network.txt), my guess it that you may say that there is no need for a draft dealing with mobile_networks issues other than the MIPv6 draft (?) > From the discussions we had, > it looked like some clarifications are sufficient. At least > the mail from Mattias explained this clearly i guess. I think we need a draft dealing about mobile networks independently of the MIPv6 draft. MIPv6 addresses general issues, mobile routers and networks have their own. -- * 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/ From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 09:14:56 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08703 for ; Fri, 6 Apr 2001 09:14: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 GAA29031; Fri, 6 Apr 2001 06:14:15 -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 GAA22467; Fri, 6 Apr 2001 06:13:57 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36DCHK9029498 for ; Fri, 6 Apr 2001 06:12:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36DCHIi029496 for mobile-ip-dist; Fri, 6 Apr 2001 06:12: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36DC4K9029485 for ; Fri, 6 Apr 2001 06:12:04 -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 GAA22099 for ; Fri, 6 Apr 2001 06:12:05 -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 GAA22122 for ; Fri, 6 Apr 2001 06:12:03 -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 PAA13505 for ; Fri, 6 Apr 2001 15:11:48 +0200 (MEST) Message-ID: <3ACDC06B.9C6881E4@inrialpes.fr> Date: Fri, 06 Apr 2001 15:11:07 +0200 From: Thierry Ernst Organization: INRIA Rhone-Alpes 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] Mobile Netwoks in MIPv6 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 [last repost !] Mohan Parthasarathy wrote: > I never said anything about prefixes appearing out of thin air. > I think the spec is not clear enough. So, just having the > routing information for all the prefixes behind MR is not > sufficient. > Look at the steps involved : > > 1) MR moves to the foreign link and asks HA to defend for its home > address. > > 2) Packet from some CN goes toward HA. Reading 9.5 and 9.6 sections > of the draft says that it will encapsulate only for packets > destined to the MR's home address. Any packet for which MR > is the router, it will try to send it to MR. Hhmm MR itself is > not home. So should it encapsualte ? But it is not defending > for those addresses. > > I agree that we can clarify the existing draft rather than having > another draft. I would agree if encapsulation by HA to the MR would be the sole issue. But I guess the most recent emails have clarified that there (many) other issues to address, and this deserves an indepent draft IMHO. 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/ From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 09:15:18 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08727 for ; Fri, 6 Apr 2001 09:15: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 GAA26011; Fri, 6 Apr 2001 06:07: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 GAA18342; Fri, 6 Apr 2001 06:07:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36D5hK9029362 for ; Fri, 6 Apr 2001 06:05:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36D5gBC029361 for mobile-ip-dist; Fri, 6 Apr 2001 06:05: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36D5XK9029354 for ; Fri, 6 Apr 2001 06:05: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 GAA21372 for ; Fri, 6 Apr 2001 06:05:34 -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 HAA07298 for ; Fri, 6 Apr 2001 07:05:33 -0600 (MDT) 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 PAA13285 for ; Fri, 6 Apr 2001 15:05:18 +0200 (MEST) Message-ID: <3ACDBEE4.786C1C47@inrialpes.fr> Date: Fri, 06 Apr 2001 15:04:36 +0200 From: Thierry Ernst Organization: INRIA Rhone-Alpes 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] Mobile Netwoks in MIPv6 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 if you received this twice - mailing list was apparently broken Thursday] Hi, What I see in this thread is a lot of questions raised by some people ("how does ...", "why ...", "could you ..."), and other people trying to answer whereas the problem is not stated. How could one reply to a question if it's not based on some technical solution ? How would a MN knows that the MR it is attached to has moved ? => I don't know - this depends of the solution we propose to handle MR Is the MR the Home Agent of the MN that attaches the MR ? => I don't know - this depends of the solution we propose to handle MR Do nodes behind the MR need to get a COA ? => I don't know - this depends of the solution we propose to handle MR and so on. We don't have the solution to those questions now. It's therefore useless to answer those questions if it's not based on some concrete propositions. My draft is trying to answer some of the questions, not all (for sure I can add new sections in the draft, but I voluntary kept the things as simple as possible in order to raise the issue - now that the issue is raised and that people seem to agree that there are issues to address, I might consider to extend my draft to address the other issues I have been thinking of for quite a few months now), then I would only reply to concerns about my proposition. I will submit a revision of my draft by July. BTW, my proposition does not only says how to redirect packets from the HA to the MR (some people might argue this is not issue - well, at least we need clarifications in the MIPv6 draft), it also says how to perform route optimization between the CN and the MR. 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/ From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 09:24:34 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08821 for ; Fri, 6 Apr 2001 09:24: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 GAA00935; Fri, 6 Apr 2001 06:20:23 -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 GAA07495; Fri, 6 Apr 2001 06:20:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36DJ7K9029609 for ; Fri, 6 Apr 2001 06:19:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36DJ6Ad029608 for mobile-ip-dist; Fri, 6 Apr 2001 06:19: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36DIvK9029601 for ; Fri, 6 Apr 2001 06:18:58 -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 GAA07358 for ; Fri, 6 Apr 2001 06:18:58 -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 HAA14704 for ; Fri, 6 Apr 2001 07:18:58 -0600 (MDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Apr 2001 09:18:03 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'mobile-ip@sunroof.eng.sun.com'" Cc: "'hchaskar@hotmail.com'" , "Kiernan, Brian G." , "Shahrier, Sharif M." Subject: RE: [mobile-ip] Requirements Draft for Mobile IP QoS - Invitation to Volunteer Date: Fri, 6 Apr 2001 09:17:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0BE9B.FFF9E770" Sender: owner-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_01C0BE9B.FFF9E770 Content-Type: text/plain; charset="iso-8859-1" Hemant, Could you please add me to the group, and keep me informed. Thanks. Sharif -----Original Message----- From: Glenn Morrow [mailto:gmorrow@nortelnetworks.com] Sent: Friday, April 06, 2001 7:38 AM To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Requirements Draft for Mobile IP QoS - Invitation to Volunteer Hemant, Count me in as well. Glenn -----Original Message----- From: Hemant Chaskar [ mailto:hchaskar@hotmail.com ] Sent: Thursday, April 05, 2001 4:47 PM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Requirements Draft for Mobile IP QoS - Invitation to Volunteer 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 ------_=_NextPart_001_01C0BE9B.FFF9E770 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Requirements Draft for Mobile IP QoS - Invitation to Volunteer
Hemant,
 
        Could you please add me to the group, and keep me informed.
        Thanks.
 
Sharif
-----Original Message-----
From: Glenn Morrow [mailto:gmorrow@nortelnetworks.com]
Sent: Friday, April 06, 2001 7:38 AM
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Requirements Draft for Mobile IP QoS - Invitation to Volunteer

Hemant,

Count me in as well.

Glenn

-----Original Message-----
From: Hemant Chaskar [mailto:hchaskar@hotmail.com]
Sent: Thursday, April 05, 2001 4:47 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Requirements Draft for Mobile IP QoS - Invitation
to Volunteer


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

------_=_NextPart_001_01C0BE9B.FFF9E770-- From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 10:25:03 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10129 for ; Fri, 6 Apr 2001 10:25:02 -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 HAA23280; Fri, 6 Apr 2001 07:18: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 HAA28273; Fri, 6 Apr 2001 07:18:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36EHGK9029747 for ; Fri, 6 Apr 2001 07:17:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36EHGVC029746 for mobile-ip-dist; Fri, 6 Apr 2001 07:17: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36EH7K9029739 for ; Fri, 6 Apr 2001 07:17:07 -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 HAA13265 for ; Fri, 6 Apr 2001 07:17:08 -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 HAA20160 for ; Fri, 6 Apr 2001 07:17:06 -0700 (PDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Apr 2001 10:16:07 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Security protocols in MIPv6 Date: Fri, 6 Apr 2001 10:16:06 -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: Are there any design teams to be formed for "security protocols in MIPv6"? Thanks. Sharif. From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 10:36:20 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10568 for ; Fri, 6 Apr 2001 10:36: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 HAA11785; Fri, 6 Apr 2001 07:35:22 -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 HAA15341; Fri, 6 Apr 2001 07:35:16 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36EY0K9029822 for ; Fri, 6 Apr 2001 07:34:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36EXxnc029821 for mobile-ip-dist; Fri, 6 Apr 2001 07:33: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36EXpK9029814 for ; Fri, 6 Apr 2001 07:33:51 -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 HAA04726 for ; Fri, 6 Apr 2001 07:33:51 -0700 (PDT) Received: from web11207.mail.yahoo.com (web11207.mail.yahoo.com [216.136.131.189]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id IAA01255 for ; Fri, 6 Apr 2001 08:33:51 -0600 (MDT) Message-ID: <20010406143350.46943.qmail@web11207.mail.yahoo.com> Received: from [47.230.0.42] by web11207.mail.yahoo.com; Fri, 06 Apr 2001 07:33:50 PDT Date: Fri, 6 Apr 2001 07:33:50 -0700 (PDT) From: Kory Keith Subject: [mobile-ip] Question about Registration Replies and RFC2002bis 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: Sorry if this is a repost, but I never saw it on the board.... In RFC 2002bis, it clearly states that the MN should send 0.0.0.0 as it source address in the IP field of the Registration Request when requesting a Dynamic Home Address. (3.6.1.1). My question is about 3.7.2.3 where it states the following: IP Destination Address Copied from the IP Source Address of the Registration Request. If I read this correctly, the Foreign Agent is meant to send the Registration Reply to the MN with a destination address of 0.0.0.0 in the IP header. How can this be valid when 0.0.0.0 is a reserved address in the IP standard and should not be used as a destination address?? Kory Keith __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 10:46:25 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10856 for ; Fri, 6 Apr 2001 10:46: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 HAA18529; Fri, 6 Apr 2001 07:43: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 HAA03657; Fri, 6 Apr 2001 07:43:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36Eg7K9029876 for ; Fri, 6 Apr 2001 07:42:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36Eg7mK029875 for mobile-ip-dist; Fri, 6 Apr 2001 07:42: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36EfwK9029866 for ; Fri, 6 Apr 2001 07:41:58 -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 HAA06029 for ; Fri, 6 Apr 2001 07:41:58 -0700 (PDT) Received: from c007.snv.cp.net (c007-h012.c007.snv.cp.net [209.228.33.219]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id HAA23615 for ; Fri, 6 Apr 2001 07:41:58 -0700 (PDT) Received: (cpmta 24215 invoked from network); 6 Apr 2001 07:41:57 -0700 Received: from unknown (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.219) with SMTP; 6 Apr 2001 07:41:57 -0700 X-Sent: 6 Apr 2001 14:41:57 GMT Message-ID: <01f301c0bea7$99eaed60$6501a8c0@philneum> From: "Phil Neumiller" To: References: Subject: Re: [mobile-ip] Security protocols in MIPv6 Date: Fri, 6 Apr 2001 09:41:01 -0500 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: I also sent a message to this "effect" but it never came out. Is the MIP list server not sendng out messages sometimes? I agree that the security work should be handled like the QoS and AAA only requirements should be done in the MIP WG. -pdn ----- Original Message ----- From: "Shahrier, Sharif M." To: Sent: Friday, April 06, 2001 9:16 AM Subject: RE: [mobile-ip] Security protocols in MIPv6 > Are there any design teams to be formed for "security protocols in MIPv6"? > > Thanks. > > Sharif. > > From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 10:51:27 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11000 for ; Fri, 6 Apr 2001 10:51:26 -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 HAA24342; Fri, 6 Apr 2001 07:50: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 HAA12734; Fri, 6 Apr 2001 07:50:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36EmqK9029923 for ; Fri, 6 Apr 2001 07:48:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36EmqSj029922 for mobile-ip-dist; Fri, 6 Apr 2001 07:48:52 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36EmhK9029915 for ; Fri, 6 Apr 2001 07:48:43 -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 HAA12523 for ; Fri, 6 Apr 2001 07:48:44 -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 HAA23022 for ; Fri, 6 Apr 2001 07:48:43 -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.9.3/8.9.1) with ESMTP id HAA17566 for ; Fri, 6 Apr 2001 07:48: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 ADQ04863; Fri, 6 Apr 2001 07:48:41 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA05856; Fri, 6 Apr 2001 07:48:41 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15053.55112.966988.945188@thomasm-u1.cisco.com> Date: Fri, 6 Apr 2001 07:48:40 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Requirements Draft for Mobile IP QoS - Invitation to Volunteer In-Reply-To: <020A5EC56F3FD411B5230008C716D0858685CF@nhqntex01.nextel.com> References: <020A5EC56F3FD411B5230008C716D0858685CF@nhqntex01.nextel.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 You can count me in, and I believe that Fred Baker replied earlier that he wanted to participate. Mike Martin, David P writes: > Hi Hemant, > I'd like to help out as well > Dave > > > >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 owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 11:58:08 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12948 for ; Fri, 6 Apr 2001 11:58:02 -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 IAA04893; Fri, 6 Apr 2001 08:54: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 IAA19392; Fri, 6 Apr 2001 08:53:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36FqGK9000114 for ; Fri, 6 Apr 2001 08:52:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36FqFIm000113 for mobile-ip-dist; Fri, 6 Apr 2001 08:52: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36Fq6K9000106 for ; Fri, 6 Apr 2001 08:52:07 -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 IAA26825 for ; Fri, 6 Apr 2001 08:52:07 -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 IAA06160 for ; Fri, 6 Apr 2001 08:52:05 -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.9.3/8.9.1) with ESMTP id IAA23422 for ; Fri, 6 Apr 2001 08:52:07 -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 ADQ05775; Fri, 6 Apr 2001 08:52:02 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA05883; Fri, 6 Apr 2001 08:52:01 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15053.58913.722549.842387@thomasm-u1.cisco.com> Date: Fri, 6 Apr 2001 08:52:01 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6 In-Reply-To: <3ACDBFC1.F3E5121A@inrialpes.fr> References: <3ACDBFC1.F3E5121A@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: > > > If the mobile router moves, > > > wouldn't that cause the mobile host's BU to the > > > other home agent to become stale? > > > > > => Not if the other mobile updates its HA with a > > new location. I mean if you just rely on the MR > > updating its HA, that would still work but > > doesn't really give you route optmisation. > > Right. Yes, but how does the MN behind the MR *know* that MR changed its CoA? A related question: if it's just a non-mobile host behind a mobile router, what causes those hosts to change their home address destination option? In fact, how did they know that they needed to use it in the first place? There are some pretty deep and fundamental questions lurking here. Namely, is mobility transparent to non-mobile hosts and if so, why? We also need to consider what this means in the face of renumbering which in many respects is mobility (flattening) in disguise. Mike From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 12:07:45 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13221 for ; Fri, 6 Apr 2001 12:07:44 -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 JAA09860; Fri, 6 Apr 2001 09:05: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 IAA14788; Fri, 6 Apr 2001 08:28:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36FRJK9000047 for ; Fri, 6 Apr 2001 08:27:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36FRIQB000046 for mobile-ip-dist; Fri, 6 Apr 2001 08:27:18 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36FR9K9000039 for ; Fri, 6 Apr 2001 08:27:10 -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 IAA14467 for ; Fri, 6 Apr 2001 08:27:10 -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 IAA26509 for ; Fri, 6 Apr 2001 08:27:10 -0700 (PDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Fri, 6 Apr 2001 11:21:49 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Security protocols in MIPv6 Date: Fri, 6 Apr 2001 11:21:41 -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, I sent the following at the start of the week. Perhaps it didn't get through, but I saw it, and some responses to it, but I'll repost in case not everyone did. Sorry for the dup for others. The list server has been down some this week. We'll see whether we can get a diagnosis on it early next week. The WG chairs have been working with the IESG to progress the work on the MIPv6 draft. Thomas and Erik have agreed to shepherd this draft through the IESG process. The goal is to produce a solution for securing binding updates, update the draft to incorporate that solution, and progress the draft through the IESG to Proposed Standard very quickly, certainly before the 51st IETF in London if at all possible. The process for achieving this is becoming clear. Based on discussions generated around the rejection of the current draft due to the concerns about securing binding updates, some members of the IESG and the IAB and the working group chairs have begun refining the requirements that should be satisfied to provide a reasonable level of security for Mobile IP v6. This will be the set of requirements to form the basis of the IESG's approval of that part of the Mobile IP v6 spec and will be shared as soon as there is good consensus. All proposals for securing Mobile IP v6 specs will be measured against this set of requirements. Then a group of security experts and implementers will put together a solution that meets all the requirements, and the draft editor will update the draft to include this solution in the Mobile IP v6 spec. The draft will then go through working group and a new IETF last call as normal and the draft will be sent to the IESG for approval. > -----Original Message----- > From: Shahrier, Sharif M. [mailto:Sharif.Shahrier@InterDigital.com] > Sent: Friday, April 06, 2001 10:16 AM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] Security protocols in MIPv6 > > > Are there any design teams to be formed for "security > protocols in MIPv6"? > > Thanks. > > Sharif. > From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 12:14:35 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13481 for ; Fri, 6 Apr 2001 12:14: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 JAA13900; Fri, 6 Apr 2001 09:13: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 JAA29167; Fri, 6 Apr 2001 09:05:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36G3jK9000204 for ; Fri, 6 Apr 2001 09:03:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36G3j7q000202 for mobile-ip-dist; Fri, 6 Apr 2001 09:03: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36G3ZK9000193 for ; Fri, 6 Apr 2001 09:03:36 -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 JAA21165 for ; Fri, 6 Apr 2001 09:03:36 -0700 (PDT) Received: from c007.snv.cp.net (c007-h008.c007.snv.cp.net [209.228.33.214]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA04039 for ; Fri, 6 Apr 2001 09:03:35 -0700 (PDT) Received: (cpmta 22127 invoked from network); 6 Apr 2001 09:03:27 -0700 Received: from unknown (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.214) with SMTP; 6 Apr 2001 09:03:27 -0700 X-Sent: 6 Apr 2001 16:03:27 GMT Message-ID: <02aa01c0beb2$fcba5560$6501a8c0@philneum> From: "Phil Neumiller" To: , , , , Cc: , , , References: <8572CF1E2A95D211A1190008C7EAA2460272091B@daeis05nok> Subject: [mobile-ip] Re: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Fri, 6 Apr 2001 11:02:30 -0500 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: I think Gary is right. How is the compression relevant if it is acting simply as a router? ----- Original Message ----- From: To: ; ; ; ; Cc: ; ; ; Sent: Friday, April 06, 2001 10:52 AM Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover > Hi Gary, > > No this is not bicasting. The path taken by the packets (during the context > establishment at the new compressor/decompressor) is as follows: > > > -------> Old compressor/decompressor ----------> New compressor/decompressor > -------------> MN > > <------ Old compressor/decompressor <---------- New compressor/decompressor > <------------- MN > > Khiem From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 12:18:09 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13532 for ; Fri, 6 Apr 2001 12:18:08 -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 JAA14820; Fri, 6 Apr 2001 09:15: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 JAA21330; Fri, 6 Apr 2001 09:14:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36GCcK9000346 for ; Fri, 6 Apr 2001 09:12:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36GCbpK000345 for mobile-ip-dist; Fri, 6 Apr 2001 09:12: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36GCSK9000338 for ; Fri, 6 Apr 2001 09:12:29 -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 JAA21099 for ; Fri, 6 Apr 2001 09:12:29 -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 JAA21873 for ; Fri, 6 Apr 2001 09:12:28 -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 SAA18721 for ; Fri, 6 Apr 2001 18:12:11 +0200 (MEST) Message-ID: <3ACDEAB3.9E5ABDE9@inrialpes.fr> Date: Fri, 06 Apr 2001 18:11:31 +0200 From: Thierry Ernst Organization: INRIA Rhone-Alpes 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] Mobile Netwoks in MIPv6 References: <3ACDBFC1.F3E5121A@inrialpes.fr> <15053.58913.722549.842387@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: > > Thierry Ernst writes: > > > > If the mobile router moves, > > > > wouldn't that cause the mobile host's BU to the > > > > other home agent to become stale? > > > > > > > => Not if the other mobile updates its HA with a > > > new location. I mean if you just rely on the MR > > > updating its HA, that would still work but > > > doesn't really give you route optmisation. > > > > Right. > > Yes, but how does the MN behind the MR *know* that > MR changed its CoA? Why should he ? > > A related question: if it's just a non-mobile host > behind a mobile router, what causes those hosts > to change their home address destination option? > In fact, how did they know that they needed to > use it in the first place? Who ever said that the non-mobile host behind MR change their home address ? One of my point is that mobility of MR should be transparent to all hosts behind the MR. I thinks it makes sense. > > There are some pretty deep and fundamental questions > lurking here. Namely, is mobility transparent to > non-mobile hosts and if so, why? We also need to > consider what this means in the face of > renumbering which in many respects is mobility > (flattening) in disguise. Renumbering is not to happen at a rate as important as mobility, then it's not the same issues. From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 12:19:21 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13612 for ; Fri, 6 Apr 2001 12:19:20 -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 JAA13221; Fri, 6 Apr 2001 09:12:11 -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 JAA22115; Fri, 6 Apr 2001 09:08:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36G7NK9000285 for ; Fri, 6 Apr 2001 09:07:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36G7NBa000284 for mobile-ip-dist; Fri, 6 Apr 2001 09:07: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36G7CK9000274 for ; Fri, 6 Apr 2001 09:07:12 -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 JAA20360; Fri, 6 Apr 2001 09:07:13 -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 JAA14451; Fri, 6 Apr 2001 09:06:28 -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.9.3/8.9.1) with ESMTP id JAA02112; Fri, 6 Apr 2001 09:05: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 ADQ06034; Fri, 6 Apr 2001 09:04:59 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA05886; Fri, 6 Apr 2001 09:04:59 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15053.59691.250834.778697@thomasm-u1.cisco.com> Date: Fri, 6 Apr 2001 09:04:59 -0700 (PDT) To: khiem.le@nokia.com Cc: gkenward@nortelnetworks.com, tmima@cisco.com, mccap@research.bell-labs.com, rajeev.koodli@nokia.com, kempf@heliopolis.eng.sun.com, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover In-Reply-To: <8572CF1E2A95D211A1190008C7EAA2460272091B@daeis05nok> References: <8572CF1E2A95D211A1190008C7EAA2460272091B@daeis05nok> 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 Can somebody explain to me how this has any possible applicability if you are using FMIP during the transition? FMIP requires a new tunnel for which there will be no compression state in the old access router. All of these interactions with MIP, FMIP, HMIP etc, etc make it look to me like this is a losing situation. It may be the better part of valor to say that fast/smooth handoffs are inherently more bandwidth consumptive and that one of the casualties is header compression state in the mean time. Trying to extend a point to point L2 compression mechanism across an arbitrary internet is just *bizzare*. L2TP is bad enough. Mike khiem.le@nokia.com writes: > Hi Gary, > > No this is not bicasting. The path taken by the packets (during the context > establishment at the new compressor/decompressor) is as follows: > > > -------> Old compressor/decompressor ----------> New compressor/decompressor > -------------> MN > > <------ Old compressor/decompressor <---------- New compressor/decompressor > <------------- MN > > Khiem > > -----Original Message----- > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] > Sent: Wednesday, April 04, 2001 8:47 AM > To: 'khiem.le@nokia.com'; tmima@cisco.com; mccap@research.bell-labs.com; > rajeev.koodli@nokia.com > Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > rohc@cdt.luth.se; seamoby@diameter.org > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 > Handover > > > > Many real time context synchronization problems can be solved > through "bi-casting", which is, I believe, the essence of what you > describe. > > Gary > > > -----Original Message----- > > From: khiem.le@nokia.com [ mailto:khiem.le@nokia.com > ] > > Sent: Wednesday, April 04, 2001 12:16 AM > > To: tmima@cisco.com; rajeev.koodli@nokia.com; > > mccap@research.bell-labs.com; rajeev.koodli@nokia.com > > Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > > rohc@cdt.luth.se; seamoby@diameter.org > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile > > IPv6 Handover > > > > > > Hello Tmima, > > > > Your idea is very similar to the one I had some time ago (refer to > > http://www.cdt.luth.se/robhc/msg01274.html > ). > > > > Essentially the idea is to relax the timing constraints and > > allow some time > > to establish the context at the new compressor/decompressor. > > During that > > context establishment time, the packets transit through the new > > compressor/decompressor, but also transit through the old > > which continues to > > do compression/decompression. Once the context is > > established, the new can > > take over the compression/decompression process. > > > > The old compressor/decompressor helps the new compressor/decompressor > > establish its context by sending some context information. > > One way (as you > > described, correct me if I am wrong) is to take a snapshot of > > the context > > and send it. To maintain context synchronization between the > > old and new, > > the new may do some update of the received context snapshot > > to account for > > the fact that the context may have been updated by the old > > after it took the > > snapshot. However, the problem is that packets may be lost > > when sent from > > the old to the new. So the new may do a context update based > > on packet j, > > but that update was not done by the old, since packet j was > > never received > > by the old. One way to solve this problem is to modify the > > mechanism to send > > the context information from old to new. Instead of sending a context > > snapshot, the old sends the context-related information in > > pieces, so the > > new can gradually build up its context. This corresponds to the > > Relocation-deferred-after-Link-Switching (RDLS)scheme in > > http://www.cdt.luth.se/robhc/msg01274.html > . You can look at > > it for details. > > > > The case where the old takes a snapshot of its context and > > sends to the new > > for immediate transfer of compression/decompression role > > corresponds to > > Relocation-concurrent-with-Link-Switching (RCLS). > > > > RDLS addresses the timing problem in a very reliable manner, > > but is more > > complex than RCLS. It also requires a higher capacity > > connection between the > > old and new. So each approach has its pros and cons. > > > > In any case, I believe the context transfer (whether RCLS or RDLS) is > > doable, and the advantages over brute force reinitialization over the > > wireless link outweigh the costs. > > > > Khiem > > > > > -----Original Message----- > > > From: ext Tmima Koren [ mailto:tmima@cisco.com > ] > > > Sent: Tuesday, April 03, 2001 8:19 PM > > > To: rajeev.koodli@nokia.com; mccap@research.bell-labs.com; > > > rajeev.koodli@nokia.com > > > Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > > > rohc@cdt.luth.se; seamoby@diameter.org > > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor > > on Mobile > > > IPv6 Handover > > > > > > > > > I wonder if it's possible to do both: > > > The new router sends a request for context transfer, but > > continues to > > > forward the compressed packets to the old router, AND queues > > > a copy of the > > > packets he forwarded. Once he receives the context, the new > > > router applies > > > the necessary changes to the context from the queued > > packets. Now his > > > context is good and he can continue decompressing. > > > Tmima > > > > > > At 07:58 PM 4/3/2001 -0500, rajeev.koodli@nokia.com wrote: > > > > > -----Original Message----- > > > > > From: ext Pete McCann [ mailto:mccap@research.bell-labs.com > ] > > > > > Sent: Tuesday, April 03, 2001 5:30 PM > > > > > To: rajeev.koodli@nokia.com > > > > > Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > > > > > rohc@cdt.luth.se; seamoby@diameter.org > > > > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting > > > Compressor on Mobile > > > > > IPv6 Handover > > > > > > > > > > > > > > > > > > > > > > > > > Yes, you would need to re-initialize the context over the > > > air, but I > > > > > don't think the bandwidth usage is high enough to matter. In a > > > > > wide-area cellular environment IP handoffs will be relatively > > > > > infrequent. The important consideration is the "glitch" > > > experienced > > > > > in voice traffic at handoff time, and this can be minimized by > > > > > temporarily anchoring the compressor. > > > > > > > > > > > > >I don't agree with you comments that you could ignore > > > bandwidth usage and > > > >assume infrequent handovers. > > > > > > > >a> 84 bytes of IPv6/UDP/RTP headers with Mobile-IPv6 Home > > > Address option for > > > >a voice payload of 20 - 30 bytes. Several such packets sent > > > per each stream. > > > > > > > >b> With fast user mobility, each BTS/AP being a router, I > > can imagine > > > >frequent handovers. > > > > > > > >In any case, context relocation addresses a>, does not > > > assume infrequent > > > >handovers, as well as attempts to provide "glitch-free" > > > voice. When the > > > >context is already present at the target router before the > > > MN starts sending > > > >compressed packets, the application should not see the glitch. > > > >I know there is work to be done here, so let's try to > > focus on that! > > > > > > > >Regards, > > > > > > > >-Rajeev > > > > > > > > > > > > > -Pete > > > > > > > > > > rajeev.koodli@nokia.com (rk) writes: > > > > > > > > > > rk> Hi, > > > > > > > > > > rk> How does this avoid the core problem of context > > > > > rk> _re-initialization_ ? You would still need to send IR > > > packets (to > > > > > rk> new access router over the air interface) subsequent > > > to handover > > > > > rk> in order to start a new context.. Anchoring it at > > > the previous > > > > > rk> router may buy you some time, but not the bits. I reckon > > > > > rk> anchoring will bring its own set of problems. > > > > > > > > > > rk> Regards, > > > > > > > > > > rk> -Rajeev > > > > > > > > > > > > > > > >> -----Original Message----- > > > > > >> From: ext Pete McCann [ mailto:mccap@research.bell-labs.com > ] > > > > > >> Sent: Tuesday, April 03, 2001 11:32 AM > > > > > >> To: kempf@heliopolis.Eng.Sun.COM > > > > > >> Cc: mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se; > > > > > >> seamoby@diameter.org > > > > > >> Subject: RE: [seamoby] RE: [rohc] RE: Restarting > > > > > Compressor on Mobile > > > > > >> IPv6 Handover > > > > > >> > > > > > >> > > > > > >> > > > > > >> Hi, > > > > > >> > > > > > >> I think there is a simpler solution to this problem that > > > > > most people > > > > > >> are overlooking. > > > > > >> > > > > > >> It should be possible to keep the compressor/decompressor > > > > > state at the > > > > > >> old access router and to tunnel the already-compressed > > > > > packets to and > > > > > >> from the new access router. Then the MN and new > > > access router can > > > > > >> renegotiate header compression state from scratch and take > > > > > as long as > > > > > >> they want to do so, because the MN is still getting > > > service in the > > > > > >> meantime. > > > > > >> > > > > > >> Someone earlier asked about support for ROHC on IP tunnels > > > > > and I think > > > > > >> this would be a good application for that. > > > > > >> > > > > > >> We are trying to move the mountain to Mohammed and I don't > > > > > see why we > > > > > >> can't do the reverse instead. > > > > > >> > > > > > >> -Pete > > > > > >> > > > > > >> > > > > > >> --- > > > > > >> Mailing list for Robust Header Compression WG > > > > > >> Archive: http://www.cdt.luth.se/rohc/ > > > > > > >> > > > > > rk> --- > > > > > rk> Mailing list for Robust Header Compression WG > > > > > rk> Archive: http://www.cdt.luth.se/rohc/ > > > > > > > > > > > > --- > > > Mailing list for Robust Header Compression WG > > > Archive: http://www.cdt.luth.se/rohc/ > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 12:30:41 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13829 for ; Fri, 6 Apr 2001 12:30: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 JAA25151; Fri, 6 Apr 2001 09:27: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 JAA25345; Fri, 6 Apr 2001 09:27:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36GPiK9000408 for ; Fri, 6 Apr 2001 09:25:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36GPiwu000407 for mobile-ip-dist; Fri, 6 Apr 2001 09:25: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36GPZK9000400 for ; Fri, 6 Apr 2001 09:25:35 -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 JAA02962 for ; Fri, 6 Apr 2001 09:25:35 -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 JAA29107 for ; Fri, 6 Apr 2001 09:25:35 -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.9.3/8.9.1) with ESMTP id JAA26010 for ; Fri, 6 Apr 2001 09:25: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 ADQ06435; Fri, 6 Apr 2001 09:25:33 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA05890; Fri, 6 Apr 2001 09:25:33 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15053.60925.641884.938683@thomasm-u1.cisco.com> Date: Fri, 6 Apr 2001 09:25:33 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6 In-Reply-To: <3ACDEAB3.9E5ABDE9@inrialpes.fr> References: <3ACDBFC1.F3E5121A@inrialpes.fr> <15053.58913.722549.842387@thomasm-u1.cisco.com> <3ACDEAB3.9E5ABDE9@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: > > Yes, but how does the MN behind the MR *know* that > > MR changed its CoA? > > Why should he ? If you want an optimized route, MN needs to know send a BU to CN as well. > > A related question: if it's just a non-mobile host > > behind a mobile router, what causes those hosts > > to change their home address destination option? > > In fact, how did they know that they needed to > > use it in the first place? > > Who ever said that the non-mobile host behind MR change their home > address ? If a host behind a MR doesn't know about its mobility, it will place its home address into the source address in the IP header. This could cause it to fail RPF checks just like MN's. This is the problem. The overall solution is not clear. > One of my point is that mobility of MR should be transparent to all > hosts behind the MR. I thinks it makes sense. There are tradeoffs which need to be weighed. I too favor transparency, but it is not clear whether that is, in fact, the right answer. > > There are some pretty deep and fundamental questions > > lurking here. Namely, is mobility transparent to > > non-mobile hosts and if so, why? We also need to > > consider what this means in the face of > > renumbering which in many respects is mobility > > (flattening) in disguise. > > Renumbering is not to happen at a rate as important as mobility, then > it's not the same issues. All I'm saying is that renumbering and mobility are related at a fundamental level and need to be considered together. Mike From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 12:41:40 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14114 for ; Fri, 6 Apr 2001 12:41: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 JAA08059; Fri, 6 Apr 2001 09:40: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 JAA06327; Fri, 6 Apr 2001 09:40:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36Gd3K9000475 for ; Fri, 6 Apr 2001 09:39:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36Gd2Kf000474 for mobile-ip-dist; Fri, 6 Apr 2001 09:39: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36GcrK9000464 for ; Fri, 6 Apr 2001 09:38:53 -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 JAA25898 for ; Fri, 6 Apr 2001 09:38:53 -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 JAA06374 for ; Fri, 6 Apr 2001 09:38:52 -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.9.3/8.9.1) with ESMTP id JAA24295; Fri, 6 Apr 2001 09:38:54 -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 ADQ06771; Fri, 6 Apr 2001 09:38:49 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA05893; Fri, 6 Apr 2001 09:38:49 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15053.61721.423033.904286@thomasm-u1.cisco.com> Date: Fri, 6 Apr 2001 09:38:49 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Cc: Hesham.Soliman@era.ericsson.se Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6 In-Reply-To: <3ACDBC66.AA6BB313@era.ericsson.se> References: <200104032053.f33KriWI249954@jurassic.eng.sun.com> <3ACDBC66.AA6BB313@era.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 Mattias Pettersson writes: > Mohan Parthasarathy wrote: > > > Do we really need another draft ? From the discussions we had, > > it looked like some clarifications are sufficient. At least > > the mail from Mattias explained this clearly i guess. > > I questioned if the MR must tell the HA what prefixes are behind the MR > and mentioned that this must be known by the HA (and also the BRs) by > other means (which we haven't figured out yet...). Mattias, Are you talking about prefixes that are not part of the home subnet prefix the MR subtends? If so, wouldn't that be handled by a normal routing protocol like OSPF? > The MN still needs to tell CNs about the prefixes, so the draft makes > sense. I think we need to be very careful here. What does this mean from a security statndpoint? What authorized this? This may be no different than the current MIP situation, but I wouldn't count on that without testing the assumption thoroughly. Also: does this mean that the MR needs to create flow based information for the static hosts behind it? That seems to be the implication. Will this scale well for large MR's such as on a plane or aircraft carriers? Mike From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 13:04:36 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14532 for ; Fri, 6 Apr 2001 13:04: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 KAA27274; Fri, 6 Apr 2001 10:02: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 KAA03109; Fri, 6 Apr 2001 10:02:41 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36H19K9000597 for ; Fri, 6 Apr 2001 10:01:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36H19DW000596 for mobile-ip-dist; Fri, 6 Apr 2001 10:01: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 jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36H10K9000589 for ; Fri, 6 Apr 2001 10:01:01 -0700 (PDT) Received: from locked (locked.Eng.Sun.COM [129.146.85.189]) by jurassic.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with SMTP id f36H0xCq985936; Fri, 6 Apr 2001 10:00:59 -0700 (PDT) Message-Id: <200104061700.f36H0xCq985936@jurassic.eng.sun.com> Date: Fri, 6 Apr 2001 09:59:43 -0700 (PDT) From: Mohan Parthasarathy Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6 To: mat@cisco.com Cc: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 5biGQqEVch9t9GtjMhOQfQ== 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: > > Thierry Ernst writes: > > > > If the mobile router moves, > > > > wouldn't that cause the mobile host's BU to the > > > > other home agent to become stale? > > > > > > > => Not if the other mobile updates its HA with a > > > new location. I mean if you just rely on the MR > > > updating its HA, that would still work but > > > doesn't really give you route optmisation. > > > > Right. > > Yes, but how does the MN behind the MR *know* that > MR changed its CoA? > > A related question: if it's just a non-mobile host > behind a mobile router, what causes those hosts > to change their home address destination option? > In fact, how did they know that they needed to > use it in the first place? > Doesn't this imply that MR should get a new prefix everytime it moves so that the MNs can configure a new care of address ? -mohan > There are some pretty deep and fundamental questions > lurking here. Namely, is mobility transparent to > non-mobile hosts and if so, why? We also need to > consider what this means in the face of > renumbering which in many respects is mobility > (flattening) in disguise. > > Mike From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 13:10:36 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14728 for ; Fri, 6 Apr 2001 13:10: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 JAA03528; Fri, 6 Apr 2001 09:52:18 -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 JAA09233; Fri, 6 Apr 2001 09:50:10 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36GmnK9000522 for ; Fri, 6 Apr 2001 09:48:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36GmnbQ000521 for mobile-ip-dist; Fri, 6 Apr 2001 09:48: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 jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36GmeK9000514 for ; Fri, 6 Apr 2001 09:48:41 -0700 (PDT) Received: from locked (locked.Eng.Sun.COM [129.146.85.189]) by jurassic.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with SMTP id f36GmeCq983767; Fri, 6 Apr 2001 09:48:40 -0700 (PDT) Message-Id: <200104061648.f36GmeCq983767@jurassic.eng.sun.com> Date: Fri, 6 Apr 2001 09:47:23 -0700 (PDT) From: Mohan Parthasarathy Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6 To: mobile-ip@sunroof.eng.sun.com Cc: Hesham.Soliman@era.ericsson.se MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: KJ9/ZMbEhnsAww81tYYcYg== 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: > > Mohan Parthasarathy wrote: > > > Do we really need another draft ? From the discussions we had, > > it looked like some clarifications are sufficient. At least > > the mail from Mattias explained this clearly i guess. > > I questioned if the MR must tell the HA what prefixes are behind the MR > and mentioned that this must be known by the HA (and also the BRs) by > other means (which we haven't figured out yet...). > Are you saying the reachability advertised by the routing protocols is not sufficient i.e how did it work when the MR was home ? Home Agent is yet another router. Are we saying that tunneling the reachability information is not optimal ? -mohan > The MN still needs to tell CNs about the prefixes, so the draft makes > sense. > > /Mattias From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 13:40:56 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15320 for ; Fri, 6 Apr 2001 13:40: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 KAA00473; Fri, 6 Apr 2001 10:40: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 KAA21219; Fri, 6 Apr 2001 10:40:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36HclK9000766 for ; Fri, 6 Apr 2001 10:38:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36Hckp1000765 for mobile-ip-dist; Fri, 6 Apr 2001 10:38: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36HcbK9000755 for ; Fri, 6 Apr 2001 10:38: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 KAA20926 for ; Fri, 6 Apr 2001 10:38:37 -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 KAA10049 for ; Fri, 6 Apr 2001 10:38:36 -0700 (PDT) Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA00230; Fri, 6 Apr 2001 10:38:58 -0700 (PDT) Message-Id: <5.0.2.1.2.20010406103642.03003d28@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 06 Apr 2001 10:37:11 -0700 To: mobile-ip@sunroof.eng.sun.com From: Fred Baker Subject: Re: [mobile-ip] Requirements Draft for Mobile IP QoS - Invitation to Volunteer Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: <3ACCFC93.239BC9CB@iprg.nokia.com> References: 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 04:15 PM 4/5/2001 -0700, Rajeev Koodli wrote: > > 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. I seem to have misplaced the original email, but I'd be willing to contribute. From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 13:51:31 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15585 for ; Fri, 6 Apr 2001 13:51:30 -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 KAA25021; Fri, 6 Apr 2001 10:35: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 KAA09714; Fri, 6 Apr 2001 10:34:10 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36HWbK9000703 for ; Fri, 6 Apr 2001 10:32:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36HWb0A000702 for mobile-ip-dist; Fri, 6 Apr 2001 10:32: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36HWQK9000695 for ; Fri, 6 Apr 2001 10:32: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 KAA10133 for ; Fri, 6 Apr 2001 10:32:26 -0700 (PDT) From: rajeev.koodli@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA07061 for ; Fri, 6 Apr 2001 10:32:26 -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 f36HWTg07068 for ; Fri, 6 Apr 2001 12:32:29 -0500 (CDT) Received: from daebh02nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 6 Apr 2001 12:32:24 -0500 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Fri, 6 Apr 2001 12:32:24 -0500 Message-ID: To: mat@cisco.com, khiem.le@nokia.com Cc: gkenward@nortelnetworks.com, tmima@cisco.com, mccap@research.bell-labs.com, rajeev.koodli@nokia.com, kempf@heliopolis.eng.sun.com, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Fri, 6 Apr 2001 12:32: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: Hello, > -----Original Message----- > From: ext Michael Thomas [mailto:mat@cisco.com] > Sent: Friday, April 06, 2001 9:05 AM > To: khiem.le@nokia.com > Cc: gkenward@nortelnetworks.com; tmima@cisco.com; > mccap@research.bell-labs.com; rajeev.koodli@nokia.com; > kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > rohc@cdt.luth.se; seamoby@diameter.org > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile > IPv6 Handover > > > > Can somebody explain to me how this has any > possible applicability if you are using FMIP > during the transition? FMIP requires a new tunnel > for which there will be no compression state in > the old access router. > If there is no compression state at the old router, why would you try to relocate it ? > All of these interactions with MIP, FMIP, HMIP > etc, etc make it look to me like this is a losing > situation. It may be the better part of valor to > say that fast/smooth handoffs are inherently more > bandwidth consumptive and that one of the > casualties is header compression state in the mean > time. Can you justify your claim above ? >Trying to extend a point to point L2 > compression mechanism across an arbitrary internet > is just *bizzare*. L2TP is bad enough. > You are compressing IP and transport headers! This should work on ANY link. That's why you try to CT header compression state. Get it ? Regards, -Rajeev > Mike > > khiem.le@nokia.com writes: > > Hi Gary, > > > > No this is not bicasting. The path taken by the packets > (during the context > > establishment at the new compressor/decompressor) is as follows: > > > > > > -------> Old compressor/decompressor ----------> New > compressor/decompressor > > -------------> MN > > > > <------ Old compressor/decompressor <---------- New > compressor/decompressor > > <------------- MN > > > > Khiem > > > > -----Original Message----- > > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] > > Sent: Wednesday, April 04, 2001 8:47 AM > > To: 'khiem.le@nokia.com'; tmima@cisco.com; > mccap@research.bell-labs.com; > > rajeev.koodli@nokia.com > > Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > > rohc@cdt.luth.se; seamoby@diameter.org > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting > Compressor on Mobile IPv6 > > Handover > > > > > > > > Many real time context synchronization problems can be solved > > through "bi-casting", which is, I believe, the essence of what you > > describe. > > > > Gary > > > > > -----Original Message----- > > > From: khiem.le@nokia.com [ mailto:khiem.le@nokia.com > > ] > > > Sent: Wednesday, April 04, 2001 12:16 AM > > > To: tmima@cisco.com; rajeev.koodli@nokia.com; > > > mccap@research.bell-labs.com; rajeev.koodli@nokia.com > > > Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > > > rohc@cdt.luth.se; seamoby@diameter.org > > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting > Compressor on Mobile > > > IPv6 Handover > > > > > > > > > Hello Tmima, > > > > > > Your idea is very similar to the one I had some time ago > (refer to > > > http://www.cdt.luth.se/robhc/msg01274.html > > ). > > > > > > Essentially the idea is to relax the timing constraints and > > > allow some time > > > to establish the context at the new compressor/decompressor. > > > During that > > > context establishment time, the packets transit through the new > > > compressor/decompressor, but also transit through the old > > > which continues to > > > do compression/decompression. Once the context is > > > established, the new can > > > take over the compression/decompression process. > > > > > > The old compressor/decompressor helps the new > compressor/decompressor > > > establish its context by sending some context information. > > > One way (as you > > > described, correct me if I am wrong) is to take a snapshot of > > > the context > > > and send it. To maintain context synchronization between the > > > old and new, > > > the new may do some update of the received context snapshot > > > to account for > > > the fact that the context may have been updated by the old > > > after it took the > > > snapshot. However, the problem is that packets may be lost > > > when sent from > > > the old to the new. So the new may do a context update based > > > on packet j, > > > but that update was not done by the old, since packet j was > > > never received > > > by the old. One way to solve this problem is to modify the > > > mechanism to send > > > the context information from old to new. Instead of > sending a context > > > snapshot, the old sends the context-related information in > > > pieces, so the > > > new can gradually build up its context. This corresponds to the > > > Relocation-deferred-after-Link-Switching (RDLS)scheme in > > > http://www.cdt.luth.se/robhc/msg01274.html > > . You can look at > > > it for details. > > > > > > The case where the old takes a snapshot of its context and > > > sends to the new > > > for immediate transfer of compression/decompression role > > > corresponds to > > > Relocation-concurrent-with-Link-Switching (RCLS). > > > > > > RDLS addresses the timing problem in a very reliable manner, > > > but is more > > > complex than RCLS. It also requires a higher capacity > > > connection between the > > > old and new. So each approach has its pros and cons. > > > > > > In any case, I believe the context transfer (whether > RCLS or RDLS) is > > > doable, and the advantages over brute force > reinitialization over the > > > wireless link outweigh the costs. > > > > > > Khiem > > > > > > > -----Original Message----- > > > > From: ext Tmima Koren [ mailto:tmima@cisco.com > > > ] > > > > Sent: Tuesday, April 03, 2001 8:19 PM > > > > To: rajeev.koodli@nokia.com; mccap@research.bell-labs.com; > > > > rajeev.koodli@nokia.com > > > > Cc: kempf@heliopolis.Eng.Sun.COM; > mobile-ip@sunroof.eng.sun.com; > > > > rohc@cdt.luth.se; seamoby@diameter.org > > > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor > > > on Mobile > > > > IPv6 Handover > > > > > > > > > > > > I wonder if it's possible to do both: > > > > The new router sends a request for context transfer, but > > > continues to > > > > forward the compressed packets to the old router, AND queues > > > > a copy of the > > > > packets he forwarded. Once he receives the context, the new > > > > router applies > > > > the necessary changes to the context from the queued > > > packets. Now his > > > > context is good and he can continue decompressing. > > > > Tmima > > > > > > > > At 07:58 PM 4/3/2001 -0500, rajeev.koodli@nokia.com wrote: > > > > > > -----Original Message----- > > > > > > From: ext Pete McCann [ mailto:mccap@research.bell-labs.com > > ] > > > > > > Sent: Tuesday, April 03, 2001 5:30 PM > > > > > > To: rajeev.koodli@nokia.com > > > > > > Cc: kempf@heliopolis.Eng.Sun.COM; > mobile-ip@sunroof.eng.sun.com; > > > > > > rohc@cdt.luth.se; seamoby@diameter.org > > > > > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting > > > > Compressor on Mobile > > > > > > IPv6 Handover > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, you would need to re-initialize the context over the > > > > air, but I > > > > > > don't think the bandwidth usage is high enough to > matter. In a > > > > > > wide-area cellular environment IP handoffs will be > relatively > > > > > > infrequent. The important consideration is the "glitch" > > > > experienced > > > > > > in voice traffic at handoff time, and this can be > minimized by > > > > > > temporarily anchoring the compressor. > > > > > > > > > > > > > > > >I don't agree with you comments that you could ignore > > > > bandwidth usage and > > > > >assume infrequent handovers. > > > > > > > > > >a> 84 bytes of IPv6/UDP/RTP headers with Mobile-IPv6 Home > > > > Address option for > > > > >a voice payload of 20 - 30 bytes. Several such packets sent > > > > per each stream. > > > > > > > > > >b> With fast user mobility, each BTS/AP being a router, I > > > can imagine > > > > >frequent handovers. > > > > > > > > > >In any case, context relocation addresses a>, does not > > > > assume infrequent > > > > >handovers, as well as attempts to provide "glitch-free" > > > > voice. When the > > > > >context is already present at the target router before the > > > > MN starts sending > > > > >compressed packets, the application should not see > the glitch. > > > > >I know there is work to be done here, so let's try to > > > focus on that! > > > > > > > > > >Regards, > > > > > > > > > >-Rajeev > > > > > > > > > > > > > > > > -Pete > > > > > > > > > > > > rajeev.koodli@nokia.com (rk) writes: > > > > > > > > > > > > rk> Hi, > > > > > > > > > > > > rk> How does this avoid the core problem of context > > > > > > rk> _re-initialization_ ? You would still need to send IR > > > > packets (to > > > > > > rk> new access router over the air interface) subsequent > > > > to handover > > > > > > rk> in order to start a new context.. Anchoring it at > > > > the previous > > > > > > rk> router may buy you some time, but not the > bits. I reckon > > > > > > rk> anchoring will bring its own set of problems. > > > > > > > > > > > > rk> Regards, > > > > > > > > > > > > rk> -Rajeev > > > > > > > > > > > > > > > > > > >> -----Original Message----- > > > > > > >> From: ext Pete McCann [ mailto:mccap@research.bell-labs.com > ] > > > > > >> Sent: Tuesday, April 03, 2001 11:32 AM > > > > > >> To: kempf@heliopolis.Eng.Sun.COM > > > > > >> Cc: mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se; > > > > > >> seamoby@diameter.org > > > > > >> Subject: RE: [seamoby] RE: [rohc] RE: Restarting > > > > > Compressor on Mobile > > > > > >> IPv6 Handover > > > > > >> > > > > > >> > > > > > >> > > > > > >> Hi, > > > > > >> > > > > > >> I think there is a simpler solution to this problem that > > > > > most people > > > > > >> are overlooking. > > > > > >> > > > > > >> It should be possible to keep the compressor/decompressor > > > > > state at the > > > > > >> old access router and to tunnel the already-compressed > > > > > packets to and > > > > > >> from the new access router. Then the MN and new > > > access router can > > > > > >> renegotiate header compression state from scratch and take > > > > > as long as > > > > > >> they want to do so, because the MN is still getting > > > service in the > > > > > >> meantime. > > > > > >> > > > > > >> Someone earlier asked about support for ROHC on IP tunnels > > > > > and I think > > > > > >> this would be a good application for that. > > > > > >> > > > > > >> We are trying to move the mountain to Mohammed and I don't > > > > > see why we > > > > > >> can't do the reverse instead. > > > > > >> > > > > > >> -Pete > > > > > >> > > > > > >> > > > > > >> --- > > > > > >> Mailing list for Robust Header Compression WG > > > > > >> Archive: http://www.cdt.luth.se/rohc/ > > > > > > >> > > > > > rk> --- > > > > > rk> Mailing list for Robust Header Compression WG > > > > > rk> Archive: http://www.cdt.luth.se/rohc/ > > > > > > > > > > > > --- > > > Mailing list for Robust Header Compression WG > > > Archive: http://www.cdt.luth.se/rohc/ > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 13:56:06 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15753 for ; Fri, 6 Apr 2001 13:56: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 KAA04324; Fri, 6 Apr 2001 10:54: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 KAA14011; Fri, 6 Apr 2001 10:49:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36Hm5K9000843 for ; Fri, 6 Apr 2001 10:48:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36Hm536000842 for mobile-ip-dist; Fri, 6 Apr 2001 10:48:05 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36HltK9000835 for ; Fri, 6 Apr 2001 10:47:56 -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 KAA23037; Fri, 6 Apr 2001 10:47:55 -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 KAA13024; Fri, 6 Apr 2001 10:47:10 -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.9.3/8.9.1) with ESMTP id KAA07101; Fri, 6 Apr 2001 10:46:07 -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 ADQ08695; Fri, 6 Apr 2001 10:46:01 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA05908; Fri, 6 Apr 2001 10:46:00 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15054.216.855827.88928@thomasm-u1.cisco.com> Date: Fri, 6 Apr 2001 10:46:00 -0700 (PDT) To: Cc: mat@cisco.com, khiem.le@nokia.com, gkenward@nortelnetworks.com, tmima@cisco.com, mccap@research.bell-labs.com, kempf@heliopolis.eng.sun.com, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover 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 rajeev.koodli@nokia.com writes: > > From: ext Michael Thomas [mailto:mat@cisco.com] > > Can somebody explain to me how this has any > > possible applicability if you are using FMIP > > during the transition? FMIP requires a new tunnel > > for which there will be no compression state in > > the old access router. > > > > If there is no compression state at the old router, why would you try to > relocate it ? There's compression state there, but not the compression state that matters: when I'm receiving packets from the old AR during the FMIP transition time, there will be a *new* IP header appended toward the MN. This is because those packets will have to be tunneled to the MN. This means that it is a *new* compression context, not an old existing one. > > All of these interactions with MIP, FMIP, HMIP > > etc, etc make it look to me like this is a losing > > situation. It may be the better part of valor to > > say that fast/smooth handoffs are inherently more > > bandwidth consumptive and that one of the > > casualties is header compression state in the mean > > time. > > Can you justify your claim above ? I can't prove negatives. I'm afraid that it is your place to prove that context transfer of header compression state in the face of all of these extenuating circumstances is still worthwhile. > >Trying to extend a point to point L2 > > compression mechanism across an arbitrary internet > > is just *bizzare*. L2TP is bad enough. > > > > You are compressing IP and transport headers! This should work on ANY link. > That's why you try to CT header compression state. Get it ? Oh sure, I get it... I "get" VoMPLS too, but that doesn't make it any less bizarre. Mike From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 14:07:42 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15971 for ; Fri, 6 Apr 2001 14:07: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 LAA08037; Fri, 6 Apr 2001 11:02: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 KAA17631; Fri, 6 Apr 2001 10:26:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36HP0K9000673 for ; Fri, 6 Apr 2001 10:25:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36HP0RN000672 for mobile-ip-dist; Fri, 6 Apr 2001 10:25: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36HOpK9000665 for ; Fri, 6 Apr 2001 10:24:51 -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 KAA08022 for ; Fri, 6 Apr 2001 10:24:51 -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 KAA17630 for ; Fri, 6 Apr 2001 10:24:50 -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 TAA19960 for ; Fri, 6 Apr 2001 19:24:31 +0200 (MEST) Message-ID: <3ACDFBA5.3655D603@inrialpes.fr> Date: Fri, 06 Apr 2001 19:23:49 +0200 From: Thierry Ernst Organization: INRIA Rhone-Alpes 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] Mobile Netwoks in MIPv6 References: <3ACDBFC1.F3E5121A@inrialpes.fr> <15053.58913.722549.842387@thomasm-u1.cisco.com> <3ACDEAB3.9E5ABDE9@inrialpes.fr> <15053.60925.641884.938683@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 > If you want an optimized route, MN needs to know > send a BU to CN as well. Not necessarily. It depends on the solution adopted to support MR. The MN can tell its CNs it is located in the mobile network whereas the MR can tell them where is the MR. > If a host behind a MR doesn't know about its > mobility, it will place its home address into > the source address in the IP header. This > could cause it to fail RPF checks just like > MN's. Then the MR can encapsulate the packet to the CN. > This is the problem. The overall solution is > not clear. Agree, but as already said, the draft does not pretend to solve to whole issues. It addresses one of the issue and is meant to open the debate. If there is a debate, this means there is something that needs to be fixed. Then, from your last sentence, I guess you agree that Mobile Routers and Networks need to be addressed in a separate draft. This is a good point. > > One of my point is that mobility of MR should be transparent to all > > hosts behind the MR. I thinks it makes sense. > > There are tradeoffs which need to be weighed. I > too favor transparency, but it is not clear > whether that is, in fact, the right answer. I agree. I have weighed it and I came to the idea that transparency is an important constraint. My solution is to keep mobility transparent to the nodes behind the routers; this is surely not the only solution, but this is the one I favor. > All I'm saying is that renumbering and mobility > are related at a fundamental level and need to > be considered together. I agree to this point and won't be against the idea that someone writes something about this to clarify. Thierry. From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 14:17:57 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16366 for ; Fri, 6 Apr 2001 14:17:56 -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 LAA14520; Fri, 6 Apr 2001 11:16:42 -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 LAA01099; Fri, 6 Apr 2001 11:16:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36IEOK9000998 for ; Fri, 6 Apr 2001 11:14:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36IEO8B000997 for mobile-ip-dist; Fri, 6 Apr 2001 11:14:24 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36IEDK9000990 for ; Fri, 6 Apr 2001 11:14:13 -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 LAA28357 for ; Fri, 6 Apr 2001 11:14:13 -0700 (PDT) From: rajeev.koodli@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA27636 for ; Fri, 6 Apr 2001 11:14:03 -0700 (PDT) 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 f36IDHg13390 for ; Fri, 6 Apr 2001 13:13:17 -0500 (CDT) Received: from daebh01nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 6 Apr 2001 13:13:13 -0500 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Fri, 6 Apr 2001 13:13:13 -0500 Message-ID: To: mat@cisco.com, rajeev.koodli@nokia.com Cc: khiem.le@nokia.com, gkenward@nortelnetworks.com, tmima@cisco.com, mccap@research.bell-labs.com, kempf@heliopolis.eng.sun.com, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Fri, 6 Apr 2001 13:13:11 -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: > > > rajeev.koodli@nokia.com writes: > > > From: ext Michael Thomas [mailto:mat@cisco.com] > > > > Can somebody explain to me how this has any > > > possible applicability if you are using FMIP > > > during the transition? FMIP requires a new tunnel > > > for which there will be no compression state in > > > the old access router. > > > > > > > If there is no compression state at the old router, why > would you try to > > relocate it ? > > There's compression state there, but not the > compression state that matters: when I'm > receiving packets from the old AR during the > FMIP transition time, there will be a *new* > IP header appended toward the MN. This is > because those packets will have to be tunneled to the > MN. This means that it is a *new* compression > context, not an old existing one. > I don't have sufficient details to comment.. > > > All of these interactions with MIP, FMIP, HMIP > > > etc, etc make it look to me like this is a losing > > > situation. It may be the better part of valor to > > > say that fast/smooth handoffs are inherently more > > > bandwidth consumptive and that one of the > > > casualties is header compression state in the mean > > > time. > > > > Can you justify your claim above ? > > I can't prove negatives. I'm afraid that it > is your place to prove that context transfer > of header compression state in the face of all > of these extenuating circumstances is still > worthwhile. > You can't justify your claims. So, before you raise issues (related/unrelated), try to make an effort to understand the work done by others. As far as I am concerned, how about all the e-mail discussion during the last two weeks ? Please take a look! > > >Trying to extend a point to point L2 > > > compression mechanism across an arbitrary internet > > > is just *bizzare*. L2TP is bad enough. > > > > > > > You are compressing IP and transport headers! This should > work on ANY link. > > That's why you try to CT header compression state. Get it ? > > Oh sure, I get it... I "get" VoMPLS too, but > that doesn't make it any less bizarre. > If you got it, you would probably re-think! If you were to re-think and understand the issues, you would probably question yourself what's bizarre, and then write. -Rajeev > Mike > From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 14:34:06 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16700 for ; Fri, 6 Apr 2001 14:34:05 -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 LAA13406; Fri, 6 Apr 2001 11:32: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 LAA22408; Fri, 6 Apr 2001 11:32:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36IULK9001080 for ; Fri, 6 Apr 2001 11:30:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36IUKQf001079 for mobile-ip-dist; Fri, 6 Apr 2001 11:30: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36IUBK9001072 for ; Fri, 6 Apr 2001 11:30:11 -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 LAA01850 for ; Fri, 6 Apr 2001 11:30:10 -0700 (PDT) Received: from zcars04e.nortelnetworks.com (zcars04e.nortelnetworks.com [47.129.242.56]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA25741 for ; Fri, 6 Apr 2001 12:30:07 -0600 (MDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Fri, 6 Apr 2001 14:29:33 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Apr 2001 14:29:33 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C12576A@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'khiem.le@nokia.com'" , tmima@cisco.com, mccap@research.bell-labs.com, rajeev.koodli@nokia.com Cc: kempf@heliopolis.eng.sun.com, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Fri, 6 Apr 2001 14:29:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0BEC7.86C264F0" 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_01C0BEC7.86C264F0 Content-Type: text/plain; charset="iso-8859-1" Khiem: You are right, it is not bicasting. I misunderstood. However, the approach is the same, with the complication that now you have a triangular route to clean up. Is there an advantage? Gary > -----Original Message----- > From: khiem.le@nokia.com [mailto:khiem.le@nokia.com] > Sent: Friday, April 06, 2001 11:53 AM > To: Kenward, Gary [WDLN2:AN10:EXCH]; khiem.le@nokia.com; > tmima@cisco.com; mccap@research.bell-labs.com; rajeev.koodli@nokia.com > Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > rohc@cdt.luth.se; seamoby@diameter.org > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile > IPv6 Handover > > > Hi Gary, > > No this is not bicasting. The path taken by the packets > (during the context > establishment at the new compressor/decompressor) is as follows: > > > -------> Old compressor/decompressor ----------> New > compressor/decompressor > -------------> MN > > <------ Old compressor/decompressor <---------- New > compressor/decompressor > <------------- MN > > Khiem > > -----Original Message----- > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] > Sent: Wednesday, April 04, 2001 8:47 AM > To: 'khiem.le@nokia.com'; tmima@cisco.com; > mccap@research.bell-labs.com; > rajeev.koodli@nokia.com > Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > rohc@cdt.luth.se; seamoby@diameter.org > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor > on Mobile IPv6 > Handover > > > > Many real time context synchronization problems can be solved > through "bi-casting", which is, I believe, the essence of what you > describe. > > Gary > > > -----Original Message----- > > From: khiem.le@nokia.com [ mailto:khiem.le@nokia.com > ] > > Sent: Wednesday, April 04, 2001 12:16 AM > > To: tmima@cisco.com; rajeev.koodli@nokia.com; > > mccap@research.bell-labs.com; rajeev.koodli@nokia.com > > Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > > rohc@cdt.luth.se; seamoby@diameter.org > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor > on Mobile > > IPv6 Handover > > > > > > Hello Tmima, > > > > Your idea is very similar to the one I had some time ago (refer to > > http://www.cdt.luth.se/robhc/msg01274.html > ). > > > > Essentially the idea is to relax the timing constraints and > > allow some time > > to establish the context at the new compressor/decompressor. > > During that > > context establishment time, the packets transit through the new > > compressor/decompressor, but also transit through the old > > which continues to > > do compression/decompression. Once the context is > > established, the new can > > take over the compression/decompression process. > > > > The old compressor/decompressor helps the new > compressor/decompressor > > establish its context by sending some context information. > > One way (as you > > described, correct me if I am wrong) is to take a snapshot of > > the context > > and send it. To maintain context synchronization between the > > old and new, > > the new may do some update of the received context snapshot > > to account for > > the fact that the context may have been updated by the old > > after it took the > > snapshot. However, the problem is that packets may be lost > > when sent from > > the old to the new. So the new may do a context update based > > on packet j, > > but that update was not done by the old, since packet j was > > never received > > by the old. One way to solve this problem is to modify the > > mechanism to send > > the context information from old to new. Instead of sending > a context > > snapshot, the old sends the context-related information in > > pieces, so the > > new can gradually build up its context. This corresponds to the > > Relocation-deferred-after-Link-Switching (RDLS)scheme in > > http://www.cdt.luth.se/robhc/msg01274.html > . You can look at > > it for details. > > > > The case where the old takes a snapshot of its context and > > sends to the new > > for immediate transfer of compression/decompression role > > corresponds to > > Relocation-concurrent-with-Link-Switching (RCLS). > > > > RDLS addresses the timing problem in a very reliable manner, > > but is more > > complex than RCLS. It also requires a higher capacity > > connection between the > > old and new. So each approach has its pros and cons. > > > > In any case, I believe the context transfer (whether RCLS > or RDLS) is > > doable, and the advantages over brute force > reinitialization over the > > wireless link outweigh the costs. > > > > Khiem > > > > > -----Original Message----- > > > From: ext Tmima Koren [ mailto:tmima@cisco.com > > ] > > > Sent: Tuesday, April 03, 2001 8:19 PM > > > To: rajeev.koodli@nokia.com; mccap@research.bell-labs.com; > > > rajeev.koodli@nokia.com > > > Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > > > rohc@cdt.luth.se; seamoby@diameter.org > > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor > > on Mobile > > > IPv6 Handover > > > > > > > > > I wonder if it's possible to do both: > > > The new router sends a request for context transfer, but > > continues to > > > forward the compressed packets to the old router, AND queues > > > a copy of the > > > packets he forwarded. Once he receives the context, the new > > > router applies > > > the necessary changes to the context from the queued > > packets. Now his > > > context is good and he can continue decompressing. > > > Tmima > > > > > > At 07:58 PM 4/3/2001 -0500, rajeev.koodli@nokia.com wrote: > > > > > -----Original Message----- > > > > > From: ext Pete McCann [ mailto:mccap@research.bell-labs.com > ] > > > > > Sent: Tuesday, April 03, 2001 5:30 PM > > > > > To: rajeev.koodli@nokia.com > > > > > Cc: kempf@heliopolis.Eng.Sun.COM; > mobile-ip@sunroof.eng.sun.com; > > > > > rohc@cdt.luth.se; seamoby@diameter.org > > > > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting > > > Compressor on Mobile > > > > > IPv6 Handover > > > > > > > > > > > > > > > > > > > > > > > > > Yes, you would need to re-initialize the context over the > > > air, but I > > > > > don't think the bandwidth usage is high enough to > matter. In a > > > > > wide-area cellular environment IP handoffs will be relatively > > > > > infrequent. The important consideration is the "glitch" > > > experienced > > > > > in voice traffic at handoff time, and this can be > minimized by > > > > > temporarily anchoring the compressor. > > > > > > > > > > > > >I don't agree with you comments that you could ignore > > > bandwidth usage and > > > >assume infrequent handovers. > > > > > > > >a> 84 bytes of IPv6/UDP/RTP headers with Mobile-IPv6 Home > > > Address option for > > > >a voice payload of 20 - 30 bytes. Several such packets sent > > > per each stream. > > > > > > > >b> With fast user mobility, each BTS/AP being a router, I > > can imagine > > > >frequent handovers. > > > > > > > >In any case, context relocation addresses a>, does not > > > assume infrequent > > > >handovers, as well as attempts to provide "glitch-free" > > > voice. When the > > > >context is already present at the target router before the > > > MN starts sending > > > >compressed packets, the application should not see the glitch. > > > >I know there is work to be done here, so let's try to > > focus on that! > > > > > > > >Regards, > > > > > > > >-Rajeev > > > > > > > > > > > > > -Pete > > > > > > > > > > rajeev.koodli@nokia.com (rk) writes: > > > > > > > > > > rk> Hi, > > > > > > > > > > rk> How does this avoid the core problem of context > > > > > rk> _re-initialization_ ? You would still need to send IR > > > packets (to > > > > > rk> new access router over the air interface) subsequent > > > to handover > > > > > rk> in order to start a new context.. Anchoring it at > > > the previous > > > > > rk> router may buy you some time, but not the bits. I reckon > > > > > rk> anchoring will bring its own set of problems. > > > > > > > > > > rk> Regards, > > > > > > > > > > rk> -Rajeev > > > > > > > > > > > > > > > >> -----Original Message----- > > > > > >> From: ext Pete McCann [ mailto:mccap@research.bell-labs.com > ] > > > > > >> Sent: Tuesday, April 03, 2001 11:32 AM > > > > > >> To: kempf@heliopolis.Eng.Sun.COM > > > > > >> Cc: mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se; > > > > > >> seamoby@diameter.org > > > > > >> Subject: RE: [seamoby] RE: [rohc] RE: Restarting > > > > > Compressor on Mobile > > > > > >> IPv6 Handover > > > > > >> > > > > > >> > > > > > >> > > > > > >> Hi, > > > > > >> > > > > > >> I think there is a simpler solution to this problem that > > > > > most people > > > > > >> are overlooking. > > > > > >> > > > > > >> It should be possible to keep the compressor/decompressor > > > > > state at the > > > > > >> old access router and to tunnel the already-compressed > > > > > packets to and > > > > > >> from the new access router. Then the MN and new > > > access router can > > > > > >> renegotiate header compression state from scratch and take > > > > > as long as > > > > > >> they want to do so, because the MN is still getting > > > service in the > > > > > >> meantime. > > > > > >> > > > > > >> Someone earlier asked about support for ROHC on IP tunnels > > > > > and I think > > > > > >> this would be a good application for that. > > > > > >> > > > > > >> We are trying to move the mountain to Mohammed and I don't > > > > > see why we > > > > > >> can't do the reverse instead. > > > > > >> > > > > > >> -Pete > > > > > >> > > > > > >> > > > > > >> --- > > > > > >> Mailing list for Robust Header Compression WG > > > > > >> Archive: http://www.cdt.luth.se/rohc/ > > > > > > >> > > > > > rk> --- > > > > > rk> Mailing list for Robust Header Compression WG > > > > > rk> Archive: http://www.cdt.luth.se/rohc/ > > > > > > > > > > > > --- > > > Mailing list for Robust Header Compression WG > > > Archive: http://www.cdt.luth.se/rohc/ > > > ------_=_NextPart_001_01C0BEC7.86C264F0 Content-Type: text/html; charset="iso-8859-1" RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover

Khiem:

  You are right, it is not bicasting. I misunderstood. However, the approach is
the same, with the complication that now you have a triangular route to clean
up. Is there an advantage?

Gary

> -----Original Message-----
> From: khiem.le@nokia.com [mailto:khiem.le@nokia.com]
> Sent: Friday, April 06, 2001 11:53 AM
> To: Kenward, Gary [WDLN2:AN10:EXCH]; khiem.le@nokia.com;
> tmima@cisco.com; mccap@research.bell-labs.com; rajeev.koodli@nokia.com
> Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com;
> rohc@cdt.luth.se; seamoby@diameter.org
> Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile
> IPv6 Handover
>
>
> Hi Gary,
> 
> No this is not bicasting. The path taken by the packets
> (during the context
> establishment at the new compressor/decompressor) is as follows:
> 
> 
> -------> Old compressor/decompressor ----------> New
> compressor/decompressor
> -------------> MN
> 
> <------ Old compressor/decompressor <---------- New
> compressor/decompressor
> <------------- MN
> 
> Khiem
>
> -----Original Message-----
> From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com]
> Sent: Wednesday, April 04, 2001 8:47 AM
> To: 'khiem.le@nokia.com'; tmima@cisco.com;
> mccap@research.bell-labs.com;
> rajeev.koodli@nokia.com
> Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com;
> rohc@cdt.luth.se; seamoby@diameter.org
> Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor
> on Mobile IPv6
> Handover
>
>
>
> Many real time context synchronization problems can be solved
> through "bi-casting", which is, I believe, the essence of what you
> describe.
>
> Gary
>
> > -----Original Message-----
> > From: khiem.le@nokia.com [ mailto:khiem.le@nokia.com
> <mailto:khiem.le@nokia.com> ]
> > Sent: Wednesday, April 04, 2001 12:16 AM
> > To: tmima@cisco.com; rajeev.koodli@nokia.com;
> > mccap@research.bell-labs.com; rajeev.koodli@nokia.com
> > Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com;
> > rohc@cdt.luth.se; seamoby@diameter.org
> > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor
> on Mobile
> > IPv6 Handover
> >
> >
> > Hello Tmima,
> >
> > Your idea is very similar to the one I had some time ago (refer to
> > http://www.cdt.luth.se/robhc/msg01274.html
> <http://www.cdt.luth.se/robhc/msg01274.html> ).
> >
> > Essentially the idea is to relax the timing constraints and
> > allow some time
> > to establish the context at the new compressor/decompressor.
> > During that
> > context establishment time, the packets transit through the new
> > compressor/decompressor, but also transit through the old
> > which continues to
> > do compression/decompression. Once the context is
> > established, the new can
> > take over the compression/decompression process.
> >
> > The old compressor/decompressor helps the new
> compressor/decompressor
> > establish its context by sending some context information.
> > One way (as you
> > described, correct me if I am wrong) is to take a snapshot of
> > the context
> > and send it. To maintain context synchronization between the
> > old and new,
> > the new may do some update of the received context snapshot
> > to account for
> > the fact that the context may have been updated by the old
> > after it took the
> > snapshot. However, the problem is that packets may be lost
> > when sent from
> > the old to the new. So the new may do a context update based
> > on packet j,
> > but that update was not done by the old, since packet j was
> > never received
> > by the old. One way to solve this problem is to modify the
> > mechanism to send
> > the context information from old to new. Instead of sending
> a context
> > snapshot, the old sends the context-related information in
> > pieces, so the
> > new can gradually build up its context. This corresponds to the
> > Relocation-deferred-after-Link-Switching (RDLS)scheme in
> > http://www.cdt.luth.se/robhc/msg01274.html
> <http://www.cdt.luth.se/robhc/msg01274.html> . You can look at
> > it for details.
> >
> > The case where the old takes a snapshot of its context and
> > sends to the new
> > for immediate transfer of compression/decompression role
> > corresponds to
> > Relocation-concurrent-with-Link-Switching (RCLS).
> >
> > RDLS addresses the timing problem in a very reliable manner,
> > but is more
> > complex than RCLS. It also requires a higher capacity
> > connection between the
> > old and new. So each approach has its pros and cons.
> >
> > In any case, I believe the context transfer (whether RCLS
> or RDLS) is
> > doable, and the advantages over brute force
> reinitialization over the
> > wireless link outweigh the costs.
> >
> > Khiem
> >
> > > -----Original Message-----
> > > From: ext Tmima Koren [ mailto:tmima@cisco.com
> <mailto:tmima@cisco.com>
> ]
> > > Sent: Tuesday, April 03, 2001 8:19 PM
> > > To: rajeev.koodli@nokia.com; mccap@research.bell-labs.com;
> > > rajeev.koodli@nokia.com
> > > Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com;
> > > rohc@cdt.luth.se; seamoby@diameter.org
> > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor
> > on Mobile
> > > IPv6 Handover
> > >
> > >
> > > I wonder if it's possible to do both:
> > > The new router sends a request for context transfer, but
> > continues to
> > > forward the compressed packets to the old router, AND queues
> > > a copy of the
> > > packets he forwarded. Once he receives the context, the new
> > > router applies
> > > the necessary changes to the context from the queued
> > packets. Now his
> > > context is good and he can continue decompressing.
> > > Tmima
> > >
> > > At 07:58 PM 4/3/2001 -0500, rajeev.koodli@nokia.com wrote:
> > > > > -----Original Message-----
> > > > > From: ext Pete McCann [ mailto:mccap@research.bell-labs.com
> <mailto:mccap@research.bell-labs.com> ]
> > > > > Sent: Tuesday, April 03, 2001 5:30 PM
> > > > > To: rajeev.koodli@nokia.com
> > > > > Cc: kempf@heliopolis.Eng.Sun.COM;
> mobile-ip@sunroof.eng.sun.com;
> > > > > rohc@cdt.luth.se; seamoby@diameter.org
> > > > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting
> > > Compressor on Mobile
> > > > > IPv6 Handover
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Yes, you would need to re-initialize the context over the
> > > air, but I
> > > > > don't think the bandwidth usage is high enough to
> matter.  In a
> > > > > wide-area cellular environment IP handoffs will be relatively
> > > > > infrequent.  The important consideration is the "glitch"
> > > experienced
> > > > > in voice traffic at handoff time, and this can be
> minimized by
> > > > > temporarily anchoring the compressor.
> > > > >
> > > >
> > > >I don't agree with you comments that you could ignore
> > > bandwidth usage and
> > > >assume infrequent handovers.
> > > >
> > > >a> 84 bytes of IPv6/UDP/RTP headers with Mobile-IPv6 Home
> > > Address option for
> > > >a voice payload of 20 - 30 bytes. Several such packets sent
> > > per each stream.
> > > >
> > > >b> With fast user mobility, each BTS/AP being a router, I
> > can imagine
> > > >frequent handovers.
> > > >
> > > >In any case, context relocation addresses a>, does not
> > > assume infrequent
> > > >handovers, as well as attempts to provide "glitch-free"
> > > voice. When the
> > > >context is already present at the target router before the
> > > MN starts sending
> > > >compressed packets, the application should not see the glitch.
> > > >I know there is work to be done here, so let's try to
> > focus on that!
> > > >
> > > >Regards,
> > > >
> > > >-Rajeev
> > > >
> > > >
> > > > > -Pete
> > > > >
> > > > > rajeev.koodli@nokia.com (rk) writes:
> > > > >
> > > > > rk> Hi,
> > > > >
> > > > > rk> How does this avoid the core problem of context
> > > > > rk> _re-initialization_ ? You would still need to send IR
> > > packets (to
> > > > > rk> new access router over the air interface) subsequent
> > > to handover
> > > > > rk> in order to start a new context..  Anchoring it at
> > > the previous
> > > > > rk> router may buy you some time, but not the bits.  I reckon
> > > > > rk> anchoring will bring its own set of problems.
> > > > >
> > > > > rk> Regards,
> > > > >
> > > > > rk> -Rajeev
> > > > >
> > > > >
> > > > > >> -----Original Message-----
> > > > > >> From: ext Pete McCann [ mailto:mccap@research.bell-labs.com
> <mailto:mccap@research.bell-labs.com> ]
> > > > > >> Sent: Tuesday, April 03, 2001 11:32 AM
> > > > > >> To: kempf@heliopolis.Eng.Sun.COM
> > > > > >> Cc: mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se;
> > > > > >> seamoby@diameter.org
> > > > > >> Subject: RE: [seamoby] RE: [rohc] RE: Restarting
> > > > > Compressor on Mobile
> > > > > >> IPv6 Handover
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> Hi,
> > > > > >>
> > > > > >> I think there is a simpler solution to this problem that
> > > > > most people
> > > > > >> are overlooking.
> > > > > >>
> > > > > >> It should be possible to keep the compressor/decompressor
> > > > > state at the
> > > > > >> old access router and to tunnel the already-compressed
> > > > > packets to and
> > > > > >> from the new access router.  Then the MN and new
> > > access router can
> > > > > >> renegotiate header compression state from scratch and take
> > > > > as long as
> > > > > >> they want to do so, because the MN is still getting
> > > service in the
> > > > > >> meantime.
> > > > > >>
> > > > > >> Someone earlier asked about support for ROHC on IP tunnels
> > > > > and I think
> > > > > >> this would be a good application for that.
> > > > > >>
> > > > > >> We are trying to move the mountain to Mohammed and I don't
> > > > > see why we
> > > > > >> can't do the reverse instead.
> > > > > >>
> > > > > >> -Pete
> > > > > >>
> > > > > >>
> > > > > >> ---
> > > > > >> Mailing list for Robust Header Compression WG
> > > > > >> Archive: http://www.cdt.luth.se/rohc/
> <http://www.cdt.luth.se/rohc/> 
> > > > > >>
> > > > > rk> ---
> > > > > rk> Mailing list for Robust Header Compression WG
> > > > > rk> Archive: http://www.cdt.luth.se/rohc/
> <http://www.cdt.luth.se/rohc/> 
> > > > >
> > >
> > > ---
> > > Mailing list for Robust Header Compression WG
> > > Archive: http://www.cdt.luth.se/rohc/
<http://www.cdt.luth.se/rohc/> 
> >
>

------_=_NextPart_001_01C0BEC7.86C264F0-- From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 16:23:25 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19495 for ; Fri, 6 Apr 2001 16:23: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 NAA02402; Fri, 6 Apr 2001 13:22: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 NAA25625; Fri, 6 Apr 2001 13:22:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36KKGK9001261 for ; Fri, 6 Apr 2001 13:20:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36KKGKZ001260 for mobile-ip-dist; Fri, 6 Apr 2001 13:20: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36KK5K9001253 for ; Fri, 6 Apr 2001 13:20:05 -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 NAA19301; Fri, 6 Apr 2001 13:20:04 -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 NAA11644; Fri, 6 Apr 2001 13:19:33 -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.9.3/8.9.1) with ESMTP id NAA03814; Fri, 6 Apr 2001 13:18: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 ADQ12759; Fri, 6 Apr 2001 13:19:29 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA05928; Fri, 6 Apr 2001 13:19:29 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15054.9424.968727.865645@thomasm-u1.cisco.com> Date: Fri, 6 Apr 2001 13:19:28 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Cc: mat@cisco.com, rajeev.koodli@nokia.com, khiem.le@nokia.com, gkenward@nortelnetworks.com, tmima@cisco.com, mccap@research.bell-labs.com, kempf@heliopolis.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover 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 rajeev.koodli@nokia.com writes: > > > > From: ext Michael Thomas [mailto:mat@cisco.com] > > > If there is no compression state at the old router, why > > would you try to > > > relocate it ? > > > > There's compression state there, but not the > > compression state that matters: when I'm > > receiving packets from the old AR during the > > FMIP transition time, there will be a *new* > > IP header appended toward the MN. This is > > because those packets will have to be tunneled to the > > MN. This means that it is a *new* compression > > context, not an old existing one. > > > I don't have sufficient details to comment.. and then this: > You can't justify your claims. So, before you raise issues > (related/unrelated), try to make an effort to understand the work done by > others. I don't know what you would like me to do. I've brought up an issue, and you've brushed it aside assumedly as irrelevant. I've been paying attention to this thread, and as far I can tell, nobody has answered my question. Also: you are also telling me that I have to prove negatives of the form "tell me why we _shouldn't_ do XYZ." That is a logical fallacy. You may not like my message, but it does not give you free reign to ignore reality. It is in nobody's interest to design a protocol that does not work in the areas where it would be most useful. Mike From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 17:02:24 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20164 for ; Fri, 6 Apr 2001 17:02:23 -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 OAA16944; Fri, 6 Apr 2001 14:01: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 OAA23364; Fri, 6 Apr 2001 14:01:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36Kx1K9001359 for ; Fri, 6 Apr 2001 13:59:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36Kx0Pm001358 for mobile-ip-dist; Fri, 6 Apr 2001 13:59: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36KwpK9001351 for ; Fri, 6 Apr 2001 13:58:51 -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 NAA22848 for ; Fri, 6 Apr 2001 13:58:50 -0700 (PDT) Received: from rajma.kniveton.com (adsl-63-197-0-77.dsl.snfc21.pacbell.net [63.197.0.77]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA07048 for ; Fri, 6 Apr 2001 13:58:49 -0700 (PDT) Received: from Kniveton.com (eldorado.kniveton.com [192.168.1.70]) by rajma.kniveton.com (8.11.1/8.11.1) with ESMTP id f36KwiP33362 for ; Fri, 6 Apr 2001 13:58:45 -0700 (PDT) Message-ID: <3ACE9071.A24EF754@Kniveton.com> Date: Fri, 06 Apr 2001 20:58:42 -0700 From: "T.J. Kniveton" Organization: NOKIA Research X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6 References: <3ACDBFC1.F3E5121A@inrialpes.fr> <15053.58913.722549.842387@thomasm-u1.cisco.com> <3ACDEAB3.9E5ABDE9@inrialpes.fr> <3ACE016F.C744FDA5@cs.ucl.ac.uk> 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 Theo has done a good job of summing it up here. Network renumbering would be perfect for this situation, but it was never designed for this. Although it could probably be made to work if you could control all the implementations of nodes behind the MR, in practice it would be a hairy situation, especially because renumbering has a 95% chance of closing all open connections from each machine, and destroying a lot of application state. If handoffs occur frequently, the nodes would be almost unusable. Thus, we should probably point in one of the other directions under discussion. Another possibility is for the MR to muck with the IP headers of forwarded packets from the prefix, putting the MR's CoA in the From field, and inserting a home address option with the other node's address (original Src addr). Ugly but I think it would work. This would cause triangular routing of course. -- T.J. Kniveton NOKIA Research Theo Pagtzis wrote: > Thierry, > > Having looked in detail the issue of mobile routers in HMIP > > I need to agree on some common understanding and expand further.. > > We have the situation of a mobile node that moves. That MN has multiple > interfaces. One of this interfaces is attached to a visiting link (gets > connected to the world), obtains a CoA by whatever extensions. The rest > of its interfaces serve routing of packets for different attached > subnets with (for this discussion) fixed nodes. > > The MN will be alternatively described as a Mobile Router (MR). > > Now when the MR is moving as the PoA for an aircraft and its nodes > inside, what would happen is that the interface attaching to the world > will obtain a CoA. > > Now that CoA has a prefix. This prefix most probably complies with the > prefix aggregation scheme of IPv6 for that domain. > > That implies to me that when an MR attaches to a new PoA it must trigger > RENUMBERING to its all of the rest of its interfaces (excluding the one > that got the CoA). The reason? all interfaces must comply with the same > prefix; otherwise the border router will not know how to route packets > to the old prefix, which by the way would routed by the OLD border > router. > > That implies to me that : > > movement of the MR will trigger network renumbering for all > attached subnets behind that MR simply because of the router/prefix > aggregation requirement. This is by the way one of the strong points of > IPv6 for network renumbering per domain. > > The renumbering to the attached subnets under the MR, will also > trigger a change of the current CoA for all hosts (fixed or mobile > inside the vehicle). That will bring the entire branch (vehicle) inline > with the prefix of the visiting domain of the MR. That means to me that > a movement of an MR will diffuse as a ghost movement of an host > underneath it. > > Movement of the MR in effect triggers a ghost handoff of the MN. Why > ghost? The host did not move a single bit but had to change its prefix. > The semantics of the BU are not decoupling movement of a MN from > movement of the whole domain (or subdomain which in this case is a > vehicle). The BU sent out will signal the change of the previous (p)CoA > to a new (n)CoA. As such for the CNs this will look like a movement of > the MN. > > To this point I would like to differentiate between two dimensions of > movement. > > 1) apparent (what I have discussed above) > 2) actual (the MN does decide to move within the aircraft/spaceship > (see babylon 5 :) here things complicate a lot. This is so because as if > the renumbering was not enough, the MN will have to send an extra BU per > actual local movement. Here a hierarchical scheme should save the > day...(I am studying which) > > The question that remains here is > > 1) is renumbering fast enough to effect the semantics of a handoff > (that is potentially seamless). If not, renumbering will bring us to > square one for seamlessness... > 2) an MN has no direct means of discovering that a net renumbering > is required so that it can solicit and as a result speed it up. So if we > rely on timeouts and intervals here the handoff is not that fast... > > Instead of renumbering I would like to ask whether it is possible to ask > the routing engine on the border router to transfer routing state for > the attached subnets under the MR. Would that mean effectively host > routes for the MR (implicit for the subnets underneath it?). > > From the perspective of route/prefix aggregation this should go > immediately down the drain in my view but I wanted to erify that with > someone before excluding it from the solution space. The reason is that > for transient routind state (the vehichle and thus MR, will move soon to > another domain so what is the point to aggregate here ..) (yes we want > to shrink the routing table, but we could allow for a temporal > inflation..couldn't we) > > In terms of security I think renumbering should be pretty safe since it > is effected locally and does not diffuse upstream. Only from the MR and > below. > > Theo > > UCL/ Mobile Systems > > Thierry Ernst wrote: > > > Michael Thomas wrote: > > > > > > Thierry Ernst writes: > > > > > > If the mobile router moves, > > > > > > wouldn't that cause the mobile host's BU to the > > > > > > other home agent to become stale? > > > > > > > > > > > => Not if the other mobile updates its HA with a > > > > > new location. I mean if you just rely on the MR > > > > > updating its HA, that would still work but > > > > > doesn't really give you route optmisation. > > > > > > > > Right. > > > > > > Yes, but how does the MN behind the MR *know* that > > > MR changed its CoA? > > > > Why should he ? > > > > > > > > A related question: if it's just a non-mobile host > > > behind a mobile router, what causes those hosts > > > to change their home address destination option? > > > In fact, how did they know that they needed to > > > use it in the first place? > > > > Who ever said that the non-mobile host behind MR change their home > > address ? > > > > One of my point is that mobility of MR should be transparent to all > > hosts behind the MR. I thinks it makes sense. > > > > > > > > There are some pretty deep and fundamental questions > > > lurking here. Namely, is mobility transparent to > > > non-mobile hosts and if so, why? We also need to > > > consider what this means in the face of > > > renumbering which in many respects is mobility > > > (flattening) in disguise. > > > > Renumbering is not to happen at a rate as important as mobility, then > > it's not the same issues. From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 17:08:14 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20363 for ; Fri, 6 Apr 2001 17:08:13 -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 OAA22337; Fri, 6 Apr 2001 14:07: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 OAA28475; Fri, 6 Apr 2001 14:07:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36L5sK9001410 for ; Fri, 6 Apr 2001 14:05:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36L5rvG001409 for mobile-ip-dist; Fri, 6 Apr 2001 14:05: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36L5iK9001402 for ; Fri, 6 Apr 2001 14:05:44 -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 OAA24305 for ; Fri, 6 Apr 2001 14:05:43 -0700 (PDT) Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA13468 for ; Fri, 6 Apr 2001 14:05:42 -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 QAA21040 for ; Fri, 6 Apr 2001 16:05:00 -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 f36L3ho25620 for ; Fri, 6 Apr 2001 16:03:43 -0500 (CDT) Message-ID: <3ACE20E0.8B15B2AB@usa.alcatel.com> Date: Fri, 06 Apr 2001 16:02:41 -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] Requirements Draft for Mobile IP QoS - Invitation to Volunteer 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 Hemant, you can count me in as well. 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 -- Behcet Alcatel From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 17:08:27 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20375 for ; Fri, 6 Apr 2001 17:08: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 OAA21109; Fri, 6 Apr 2001 14:06:03 -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 OAA28129; Fri, 6 Apr 2001 14:05:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36L4XK9001397 for ; Fri, 6 Apr 2001 14:04:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36L4Xb7001396 for mobile-ip-dist; Fri, 6 Apr 2001 14:04: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36L4NK9001386 for ; Fri, 6 Apr 2001 14:04:23 -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 OAA24033 for ; Fri, 6 Apr 2001 14:04:22 -0700 (PDT) Received: from c007.snv.cp.net (c007-h012.c007.snv.cp.net [209.228.33.219]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA17894 for ; Fri, 6 Apr 2001 14:03:43 -0700 (PDT) Received: (cpmta 15962 invoked from network); 6 Apr 2001 14:03:41 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.219) with SMTP; 6 Apr 2001 14:03:41 -0700 X-Sent: 6 Apr 2001 21:03:41 GMT Message-ID: <001c01c0bedc$eedfc9a0$6501a8c0@philneum> From: "Phil Neumiller" To: , , Cc: , , , , , , References: <8572CF1E2A95D211A1190008C7EAA24602720924@daeis05nok> Subject: [mobile-ip] Re: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Fri, 6 Apr 2001 16:02:45 -0500 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: This arguments seems completely bogus to me or I am missing something really fundamental here. Are not both 3GPP and 3GPP2 CDMA? This whole discussion falls apart and dies on the floor than. ----- Original Message ----- From: > There have been many mails pointing out the merit of doing header > compression context transfer. To repeat them: > continued, seamless compression/decompression, higher compression > efficiency, and minimization of degradation on the user media. This last > point is the most important in my mind. At this stage, the link technologies > where header compression is going to be used are primarily cellular links. 1). Based on what evidence? So far we have WAP, iMode, and iDen. Are you ignoring other possible edge and infrastructure technologies like wirelesss PANs, WLANs, ad hoc networks for any particular reason? > In the cellular environment, handoffs (or handovers) are events that happen > in normal operation, and therefore a very significant design effort is spent > to minimize the impact of HO on performance. In particular, one wants to > minimize the duration of the break. In post-modern cellular systems there is no break! Wake up! Qualcomm won the war a long time ago, I just can't get it why you guys are still in this "break" mind set. 3GPP and 3GPP2 use CDMA!!!! ITS MAKE BEFORE BREAK. THE SOONER PEOPLE START LEARNING HOW TO DEAL WITH IP PACKETS OVER CDMA w/ soft handover THE SOONER the MIP list will finally mature to where it needs to be (i.e. like OBAST :-)!!! > if brute force header compression reinitialization is done, one would have to send > certain number of 40-60 > byte or more IR headers, instead of the usual 1 byte header. This big > bandwidth demand surge will put a strain on the link. Please quantify this purported bandwidth demand surge and it origination. > Some links will cope > with it by blanking out the user data to make room to carry the IR headers. > When such blanking takes place, the user media (voice, etc.) will be > unavoidably affected. Yes but why would we use MIPv6 over TDMA systems? I just don't get this argument at all???? >The impairment caused by the handoff is thus extended, > compared to the case where header compression is not present. What it impairment, its a SOFT handoff? > > In the current and 3G cellular technologies, the break is about 100-150 > msec, without header compression. The break will be 0 ms in 3G systems (only when a hard handover is forced) is that what you are designing for the error leg cases? Again this argument seems rediculously TDMA. I feel like Rip Van Winkle, did I wake up and everything went back to TDMA? Why are we discussing this with reference to IPv6 handovers?? Regards, Phil From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 17:47:22 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21122 for ; Fri, 6 Apr 2001 17:47:21 -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 OAA09023; Fri, 6 Apr 2001 14:45: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 OAA11370; Fri, 6 Apr 2001 14:45:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36LhEK9001591 for ; Fri, 6 Apr 2001 14:43:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36LhEWq001590 for mobile-ip-dist; Fri, 6 Apr 2001 14:43: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36Lh4K9001583 for ; Fri, 6 Apr 2001 14:43:04 -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 OAA05833 for ; Fri, 6 Apr 2001 14:43:05 -0700 (PDT) Received: from c007.snv.cp.net (c007-h008.c007.snv.cp.net [209.228.33.214]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id PAA08819 for ; Fri, 6 Apr 2001 15:43:04 -0600 (MDT) Received: (cpmta 6975 invoked from network); 6 Apr 2001 14:43:03 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.214) with SMTP; 6 Apr 2001 14:43:03 -0700 X-Sent: 6 Apr 2001 21:43:03 GMT Message-ID: <004601c0bee2$6ea57f40$6501a8c0@philneum> From: "Phil Neumiller" To: , , Cc: , , , , , , References: <8572CF1E2A95D211A1190008C7EAA24602720927@daeis05nok> Subject: [mobile-ip] Re: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Fri, 6 Apr 2001 16:42:07 -0500 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: OK, now I am really confused. Typically (in my previous experience) with some very large cariers like Sprint, Verizon, etc, Hard handoffs were about 5-10% of ALL handoffs. Why is there no interest/concern about the soft case WHICH HAS NOT YET BEEN RESOLVED (i.e. the other 90%)?????????? Regards, Phil From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 17:48:15 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21149 for ; Fri, 6 Apr 2001 17:48: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 OAA10415; Fri, 6 Apr 2001 14:47:30 -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 OAA02885; Fri, 6 Apr 2001 14:47:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36LjHK9001601 for ; Fri, 6 Apr 2001 14:45:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36LjGNZ001600 for mobile-ip-dist; Fri, 6 Apr 2001 14:45: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36Lj5K9001593 for ; Fri, 6 Apr 2001 14:45:05 -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 OAA02462 for ; Fri, 6 Apr 2001 14:45:06 -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 PAA09507 for ; Fri, 6 Apr 2001 15:45:05 -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.9.3/8.9.1) with ESMTP id OAA20935 for ; Fri, 6 Apr 2001 14:43: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 ADR00440; Fri, 6 Apr 2001 14:44:52 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA05936; Fri, 6 Apr 2001 14:44:51 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15054.14547.723345.748012@thomasm-u1.cisco.com> Date: Fri, 6 Apr 2001 14:44:51 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6 In-Reply-To: <3ACE9071.A24EF754@Kniveton.com> References: <3ACDBFC1.F3E5121A@inrialpes.fr> <15053.58913.722549.842387@thomasm-u1.cisco.com> <3ACDEAB3.9E5ABDE9@inrialpes.fr> <3ACE016F.C744FDA5@cs.ucl.ac.uk> <3ACE9071.A24EF754@Kniveton.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 Where I always get stuck on this merry-go-round is with updating DNS (or anything else that has long term name/address bindings). Simply put, DNS is not a real time database and anything that wants to push it in that direction is pretty well doomed, at least in my opinion. I'm not saying that we should give up here -- Dave Oran and I have gone back and forth many times about this -- we just need to go into this with our eyes wide open; there's definitely no free lunch in these parts. Mike T.J. Kniveton writes: > Theo has done a good job of summing it up here. Network renumbering would be > perfect for this situation, but it was never designed for this. Although it > could probably be made to work if you could control all the implementations > of nodes behind the MR, in practice it would be a hairy situation, > especially because renumbering has a 95% chance of closing all open > connections from each machine, and destroying a lot of application state. If > handoffs occur frequently, the nodes would be almost unusable. Thus, we > should probably point in one of the other directions under discussion. > > Another possibility is for the MR to muck with the IP headers of forwarded > packets from the prefix, putting the MR's CoA in the From field, and > inserting a home address option with the other node's address (original Src > addr). Ugly but I think it would work. This would cause triangular routing > of course. > > -- > T.J. Kniveton > NOKIA Research > > Theo Pagtzis wrote: > > > Thierry, > > > > Having looked in detail the issue of mobile routers in HMIP > > > > I need to agree on some common understanding and expand further.. > > > > We have the situation of a mobile node that moves. That MN has multiple > > interfaces. One of this interfaces is attached to a visiting link (gets > > connected to the world), obtains a CoA by whatever extensions. The rest > > of its interfaces serve routing of packets for different attached > > subnets with (for this discussion) fixed nodes. > > > > The MN will be alternatively described as a Mobile Router (MR). > > > > Now when the MR is moving as the PoA for an aircraft and its nodes > > inside, what would happen is that the interface attaching to the world > > will obtain a CoA. > > > > Now that CoA has a prefix. This prefix most probably complies with the > > prefix aggregation scheme of IPv6 for that domain. > > > > That implies to me that when an MR attaches to a new PoA it must trigger > > RENUMBERING to its all of the rest of its interfaces (excluding the one > > that got the CoA). The reason? all interfaces must comply with the same > > prefix; otherwise the border router will not know how to route packets > > to the old prefix, which by the way would routed by the OLD border > > router. > > > > That implies to me that : > > > > movement of the MR will trigger network renumbering for all > > attached subnets behind that MR simply because of the router/prefix > > aggregation requirement. This is by the way one of the strong points of > > IPv6 for network renumbering per domain. > > > > The renumbering to the attached subnets under the MR, will also > > trigger a change of the current CoA for all hosts (fixed or mobile > > inside the vehicle). That will bring the entire branch (vehicle) inline > > with the prefix of the visiting domain of the MR. That means to me that > > a movement of an MR will diffuse as a ghost movement of an host > > underneath it. > > > > Movement of the MR in effect triggers a ghost handoff of the MN. Why > > ghost? The host did not move a single bit but had to change its prefix. > > The semantics of the BU are not decoupling movement of a MN from > > movement of the whole domain (or subdomain which in this case is a > > vehicle). The BU sent out will signal the change of the previous (p)CoA > > to a new (n)CoA. As such for the CNs this will look like a movement of > > the MN. > > > > To this point I would like to differentiate between two dimensions of > > movement. > > > > 1) apparent (what I have discussed above) > > 2) actual (the MN does decide to move within the aircraft/spaceship > > (see babylon 5 :) here things complicate a lot. This is so because as if > > the renumbering was not enough, the MN will have to send an extra BU per > > actual local movement. Here a hierarchical scheme should save the > > day...(I am studying which) > > > > The question that remains here is > > > > 1) is renumbering fast enough to effect the semantics of a handoff > > (that is potentially seamless). If not, renumbering will bring us to > > square one for seamlessness... > > 2) an MN has no direct means of discovering that a net renumbering > > is required so that it can solicit and as a result speed it up. So if we > > rely on timeouts and intervals here the handoff is not that fast... > > > > Instead of renumbering I would like to ask whether it is possible to ask > > the routing engine on the border router to transfer routing state for > > the attached subnets under the MR. Would that mean effectively host > > routes for the MR (implicit for the subnets underneath it?). > > > > From the perspective of route/prefix aggregation this should go > > immediately down the drain in my view but I wanted to erify that with > > someone before excluding it from the solution space. The reason is that > > for transient routind state (the vehichle and thus MR, will move soon to > > another domain so what is the point to aggregate here ..) (yes we want > > to shrink the routing table, but we could allow for a temporal > > inflation..couldn't we) > > > > In terms of security I think renumbering should be pretty safe since it > > is effected locally and does not diffuse upstream. Only from the MR and > > below. > > > > Theo > > > > UCL/ Mobile Systems > > > > Thierry Ernst wrote: > > > > > Michael Thomas wrote: > > > > > > > > Thierry Ernst writes: > > > > > > > If the mobile router moves, > > > > > > > wouldn't that cause the mobile host's BU to the > > > > > > > other home agent to become stale? > > > > > > > > > > > > > => Not if the other mobile updates its HA with a > > > > > > new location. I mean if you just rely on the MR > > > > > > updating its HA, that would still work but > > > > > > doesn't really give you route optmisation. > > > > > > > > > > Right. > > > > > > > > Yes, but how does the MN behind the MR *know* that > > > > MR changed its CoA? > > > > > > Why should he ? > > > > > > > > > > > A related question: if it's just a non-mobile host > > > > behind a mobile router, what causes those hosts > > > > to change their home address destination option? > > > > In fact, how did they know that they needed to > > > > use it in the first place? > > > > > > Who ever said that the non-mobile host behind MR change their home > > > address ? > > > > > > One of my point is that mobility of MR should be transparent to all > > > hosts behind the MR. I thinks it makes sense. > > > > > > > > > > > There are some pretty deep and fundamental questions > > > > lurking here. Namely, is mobility transparent to > > > > non-mobile hosts and if so, why? We also need to > > > > consider what this means in the face of > > > > renumbering which in many respects is mobility > > > > (flattening) in disguise. > > > > > > Renumbering is not to happen at a rate as important as mobility, then > > > it's not the same issues. > From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 17:49:05 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21211 for ; Fri, 6 Apr 2001 17:49:05 -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 OAA10481; Fri, 6 Apr 2001 14:48:04 -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 OAA02971; Fri, 6 Apr 2001 14:47:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36LjkK9001614 for ; Fri, 6 Apr 2001 14:45:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36Ljktt001613 for mobile-ip-dist; Fri, 6 Apr 2001 14:45: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36LjTK9001606 for ; Fri, 6 Apr 2001 14:45:29 -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 OAA06250 for ; Fri, 6 Apr 2001 14:45:30 -0700 (PDT) Received: from c007.snv.cp.net (c007-h015.c007.snv.cp.net [209.228.33.222]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA16152 for ; Fri, 6 Apr 2001 14:45:28 -0700 (PDT) Received: (cpmta 17856 invoked from network); 6 Apr 2001 14:45:26 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.222) with SMTP; 6 Apr 2001 14:45:26 -0700 X-Sent: 6 Apr 2001 21:45:26 GMT Message-ID: <004e01c0bee2$c3edc5c0$6501a8c0@philneum> From: "Phil Neumiller" To: , , Cc: , , , , , , References: <8572CF1E2A95D211A1190008C7EAA24602720927@daeis05nok> Subject: [mobile-ip] Re: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Fri, 6 Apr 2001 16:44:30 -0500 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: The problem is this is crossposted across MIP, SeaMoby, and ROCH. Drop the crossposting its confusing the issues. I missed the hard handoff specific context, but I was just reading SeaMoby and did not see that part. -Phil From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 17:58:31 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21425 for ; Fri, 6 Apr 2001 17:58:30 -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 OAA20421; Fri, 6 Apr 2001 14:57: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 OAA14025; Fri, 6 Apr 2001 14:57:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36LsvK9001752 for ; Fri, 6 Apr 2001 14:54:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36LsuZE001751 for mobile-ip-dist; Fri, 6 Apr 2001 14:54: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36LsjK9001744 for ; Fri, 6 Apr 2001 14:54:46 -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 OAA14242 for ; Fri, 6 Apr 2001 14:54:46 -0700 (PDT) From: rajeev.koodli@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 OAA18899 for ; Fri, 6 Apr 2001 14:54:46 -0700 (PDT) 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 f36Lsng21491 for ; Fri, 6 Apr 2001 16:54:49 -0500 (CDT) Received: from daebh01nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 6 Apr 2001 16:54:10 -0500 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Fri, 6 Apr 2001 16:54:10 -0500 Message-ID: To: neumiller@telocity.com, khiem.le@nokia.com, rajeev.koodli@nokia.com, mat@cisco.com Cc: gkenward@nortelnetworks.com, tmima@cisco.com, mccap@research.bell-labs.com, kempf@heliopolis.eng.sun.com, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Fri, 6 Apr 2001 16:54:08 -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 Phil, > > > OK, now I am really confused. Typically (in my previous experience) > with some very large cariers like Sprint, Verizon, etc, Hard handoffs > were about 5-10% of ALL handoffs. > > Why is there no interest/concern about the soft case WHICH HAS > NOT YET BEEN RESOLVED (i.e. the other 90%)?????????? > I am no CDMA/TDMA expert, but, it appears to me that even with soft handover, you still have the issue with context initialization, which I believe is the crux here. When you have soft handover, would you re-initialize context on the new BTS/AR, or would you relocate it from old BTS/AR to the new one ? Regards, -Rajeev > Regards, > > Phil > > From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 17:59:29 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21437 for ; Fri, 6 Apr 2001 17:59: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 OAA02941; Fri, 6 Apr 2001 14:18: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 OAA06062; Fri, 6 Apr 2001 14:18:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36LGUK9001502 for ; Fri, 6 Apr 2001 14:16:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36LGTpr001501 for mobile-ip-dist; Fri, 6 Apr 2001 14:16: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36LGKK9001494 for ; Fri, 6 Apr 2001 14:16: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 OAA26436; Fri, 6 Apr 2001 14:16:21 -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 OAA24400; Fri, 6 Apr 2001 14:16: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.9.3/8.9.1) with ESMTP id OAA22004; Fri, 6 Apr 2001 14:15:41 -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 ADQ14141; Fri, 6 Apr 2001 14:15:17 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA05932; Fri, 6 Apr 2001 14:15:17 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15054.12773.346957.945689@thomasm-u1.cisco.com> Date: Fri, 6 Apr 2001 14:15:17 -0700 (PDT) To: Cc: rajeev.koodli@nokia.com, mat@cisco.com, gkenward@nortelnetworks.com, tmima@cisco.com, mccap@research.bell-labs.com, kempf@heliopolis.eng.sun.com, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover In-Reply-To: <8572CF1E2A95D211A1190008C7EAA24602720924@daeis05nok> References: <8572CF1E2A95D211A1190008C7EAA24602720924@daeis05nok> 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 Kheim, I sorry to be so argumentative here, but I'm sure I could come up with a long laundry list of the benefits of quantum teleportation too. What obviously must be done beyond wanting such a thing is to see: o if it can be done at all o whether it would still be a benefit once we had done it. For example, if we could do quantum teleportation but the only way we could figure out how to teleport a person resulted in them dying, I'm sure you'd agree that we ought to reevaluate the benefits. All I'm asking here is how CT would interact with FMIP. I believe that FMIP is very likely to be a very important part of handoffs and as such, I would like to know whether CT for header compression state will help, hinder or be of no benefit at all. From what I can tell, there is indeed a problem and it is not clear whether there is a solution, or whether the solution would be worse than the original problem given the high likelihood of race conditions, etc. Mike khiem.le@nokia.com writes: > Hi, > > I have been too busy to comment on all these mails, but I just want to say a > couple of things. > > I'm afraid that it > > is your place to prove that context transfer > > of header compression state in the face of all > > of these extenuating circumstances is still > > worthwhile. > > There have been many mails pointing out the merit of doing header > compression context transfer. To repeat them: > continued, seamless compression/decompression, higher compression > efficiency, and minimization of degradation on the user media. This last > point is the most important in my mind. At this stage, the link technologies > where header compression is going to be used are primarily cellular links. > In the cellular environment, handoffs (or handovers) are events that happen > in normal operation, and therefore a very significant design effort is spent > to minimize the impact of HO on performance. In particular, one wants to > minimize the duration of the break. If brute force header compression > reinitialization is done, one would have to send a certain number of 40-60 > byte or more IR headers, instead of the usual 1 byte header. This big > bandwidth demand surge will put a strain on the link. Some links will cope > with it by blanking out the user data to make room to carry the IR headers. > When such blanking takes place, the user media (voice, etc.) will be > unavoidably affected. The impairment caused by the handoff is thus extended, > compared to the case where header compression is not present. > > In the current and 3G cellular technologies, the break is about 100-150 > msec, without header compression. This already translates into the loss of > 5-6 20 msec packets. If some IR headers have to be sent by blanking out the > user data, the break will be significantly longer. For example, if 3 (an > optimistic value) IR headers are sent, the resulting break is increased to > 8-9 packets worth. > > I also want to point out that minimization of the break will help in > futureproofness. Applications that will be introduced in the future may be > even more sensitive to the break (or the threshold for user perceived > degradation may be lower) than the currently known ones. For example, if a > packet is generated every 10 msec, the number of packets affected will be > doubled. > > The only way to minimize the break is to do header compression context > transfer. > > > Khiem > > -----Original Message----- > > From: Koodli Rajeev (NRC/MtView) > > Sent: Friday, April 06, 2001 1:13 PM > > To: 'ext Michael Thomas'; Koodli Rajeev (NRC/MtView) > > Cc: Le Khiem (NRC/Dallas); gkenward@nortelnetworks.com; > > tmima@cisco.com; > > mccap@research.bell-labs.com; kempf@heliopolis.Eng.Sun.COM; > > mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se; seamoby@diameter.org > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile > > IPv6 Handover > > > > > > > > > > > > > rajeev.koodli@nokia.com writes: > > > > > From: ext Michael Thomas [mailto:mat@cisco.com] > > > > > > > > Can somebody explain to me how this has any > > > > > possible applicability if you are using FMIP > > > > > during the transition? FMIP requires a new tunnel > > > > > for which there will be no compression state in > > > > > the old access router. > > > > > > > > > > > > > If there is no compression state at the old router, why > > > would you try to > > > > relocate it ? > > > > > > There's compression state there, but not the > > > compression state that matters: when I'm > > > receiving packets from the old AR during the > > > FMIP transition time, there will be a *new* > > > IP header appended toward the MN. This is > > > because those packets will have to be tunneled to the > > > MN. This means that it is a *new* compression > > > context, not an old existing one. > > > > > I don't have sufficient details to comment.. > > > > > > > All of these interactions with MIP, FMIP, HMIP > > > > > etc, etc make it look to me like this is a losing > > > > > situation. It may be the better part of valor to > > > > > say that fast/smooth handoffs are inherently more > > > > > bandwidth consumptive and that one of the > > > > > casualties is header compression state in the mean > > > > > time. > > > > > > > > Can you justify your claim above ? > > > > > > I can't prove negatives. I'm afraid that it > > > is your place to prove that context transfer > > > of header compression state in the face of all > > > of these extenuating circumstances is still > > > worthwhile. > > > > > > > You can't justify your claims. So, before you raise issues > > (related/unrelated), try to make an effort to understand the > > work done by others. > > > > As far as I am concerned, how about all the e-mail discussion > > during the last two weeks ? Please take a look! > > > > > > >Trying to extend a point to point L2 > > > > > compression mechanism across an arbitrary internet > > > > > is just *bizzare*. L2TP is bad enough. > > > > > > > > > > > > > You are compressing IP and transport headers! This should > > > work on ANY link. > > > > That's why you try to CT header compression state. Get it ? > > > > > > Oh sure, I get it... I "get" VoMPLS too, but > > > that doesn't make it any less bizarre. > > > > > > > If you got it, you would probably re-think! If you were to > > re-think and understand the issues, you would probably > > question yourself what's bizarre, and then write. > > > > -Rajeev > > > > > Mike > > > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 18:03:25 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21540 for ; Fri, 6 Apr 2001 18:03:25 -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 PAA21766; Fri, 6 Apr 2001 15:02: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 PAA09798; Fri, 6 Apr 2001 15:02:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36M0dK9001861 for ; Fri, 6 Apr 2001 15:00:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36M0dnm001860 for mobile-ip-dist; Fri, 6 Apr 2001 15:00: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36M0UK9001853 for ; Fri, 6 Apr 2001 15:00:30 -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 PAA09329 for ; Fri, 6 Apr 2001 15:00:26 -0700 (PDT) Received: from c007.snv.cp.net (c007-h000.c007.snv.cp.net [209.228.33.206]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id QAA18443 for ; Fri, 6 Apr 2001 16:00:24 -0600 (MDT) Received: (cpmta 7511 invoked from network); 6 Apr 2001 15:00:23 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.206) with SMTP; 6 Apr 2001 15:00:23 -0700 X-Sent: 6 Apr 2001 22:00:23 GMT Message-ID: <007801c0bee4$da79a500$6501a8c0@philneum> From: "Phil Neumiller" To: , , Cc: , , , , , , References: Subject: [mobile-ip] Re: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Fri, 6 Apr 2001 16:59:27 -0500 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: Thanks for understanding Rajeev. This is the appropriate question to focus on (i.e. the lion share of the handoffs for VOICE) will be soft and I think we can all agree to that. > > I am no CDMA/TDMA expert, but, it appears to me that even with soft > handover, you still have the issue with context initialization, which I > believe is the crux here. When you have soft handover, would you > re-initialize context on the new BTS/AR, or would you relocate it from old > BTS/AR to the new one ? This is absolutely the correct question to ask. Now here is where things get ugly. This context has to be done post selection (i.e. after all macro-diversity legs have been compbined with maximal ratio combining in a CDMA system). THIS MEANS THE CONTEXT CAN NOT RESIDE ON THE BTS/AR AT ALL UNLESS YOU PUT THE SDU in the BTS/AR like OBAST!!! NOTE TO SELF: [I think I am either winning this argument or flipping my wig or both at the same time..] Again, thanks for understanding Rajeev, Phil From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 18:39:57 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22340 for ; Fri, 6 Apr 2001 18:39: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 PAA14821; Fri, 6 Apr 2001 15:35: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 PAA14584; Fri, 6 Apr 2001 15:35:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36MX0K9001970 for ; Fri, 6 Apr 2001 15:33:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36MWxYP001969 for mobile-ip-dist; Fri, 6 Apr 2001 15:32: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36MWmK9001962 for ; Fri, 6 Apr 2001 15:32: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 PAA22364 for ; Fri, 6 Apr 2001 15:32:49 -0700 (PDT) From: rajeev.koodli@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA12802 for ; Fri, 6 Apr 2001 15:32:48 -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 f36MWpg24357 for ; Fri, 6 Apr 2001 17:32:51 -0500 (CDT) Received: from daebh02nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 6 Apr 2001 17:32:46 -0500 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Fri, 6 Apr 2001 17:32:46 -0500 Message-ID: To: mat@cisco.com, mobile-ip@sunroof.eng.sun.com Cc: rajeev.koodli@nokia.com, khiem.le@nokia.com, gkenward@nortelnetworks.com, tmima@cisco.com, mccap@research.bell-labs.com, kempf@heliopolis.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: RE: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compresso r on Mobile IPv6 Handover Date: Fri, 6 Apr 2001 17:32:45 -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: Hi, > > > rajeev.koodli@nokia.com writes: > > > > > From: ext Michael Thomas [mailto:mat@cisco.com] > > > > If there is no compression state at the old router, why > > > would you try to > > > > relocate it ? > > > > > > There's compression state there, but not the > > > compression state that matters: when I'm > > > receiving packets from the old AR during the > > > FMIP transition time, there will be a *new* > > > IP header appended toward the MN. This is > > > because those packets will have to be tunneled to the > > > MN. This means that it is a *new* compression > > > context, not an old existing one. > > > > > I don't have sufficient details to comment.. > > and then this: > > > You can't justify your claims. So, before you raise issues > > (related/unrelated), try to make an effort to understand > the work done by > > others. > > I don't know what you would like me to do. I've > brought up an issue, and you've brushed it > aside assumedly as irrelevant. I've been paying > attention to this thread, and as far I can > tell, nobody has answered my question. > I was not meaning to brush aside your issue, I was simply saying I didn't have sufficient details in your e-mail. Let me try to address your issue based on my understanding of your point above. Let's assume that context has been relocated from old AR to the new AR. The new AR receives a packet tunneled to the MN. The new AR can now compress the inner packet. What you do with the outer IP packet ? You could only send required fields, e.g., you can compress src and dst addresses (32 bytes in IPv6). What you need is an rohc packet format that indicates that this is a packet belonging to an old context with *some* new information (such as the Next Header field being IPv6). This *indication* bit should provide the logic to demultiplex into the correct (existing) context. This is solution space, and needs work. I hope we can focus on requirements. BTW, what is FMIP ? :-) > Also: you are also telling me that I have to > prove negatives of the form "tell me why we > _shouldn't_ do XYZ." That is a logical fallacy. > You may not like my message, but it does not > give you free reign to ignore reality. It is > in nobody's interest to design a protocol > that does not work in the areas where it would > be most useful. > > I don't wish to work on a protocol knowing that it is not going to be useful. At this point however, my apprehensions, if any, are unnecessary. -Rajeev Mike > From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 19:11:44 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22927 for ; Fri, 6 Apr 2001 19:11:43 -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 QAA04802; Fri, 6 Apr 2001 16:10:59 -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 QAA22959; Fri, 6 Apr 2001 16:10:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36N87K9002043 for ; Fri, 6 Apr 2001 16:08:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36N86CL002042 for mobile-ip-dist; Fri, 6 Apr 2001 16:08: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.Eng.Sun.COM [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36N7vK9002035 for ; Fri, 6 Apr 2001 16:07:57 -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 QAA26126 for ; Fri, 6 Apr 2001 16:07:52 -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 QAA02211 for ; Fri, 6 Apr 2001 16:07: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 QAA16274 for ; Fri, 6 Apr 2001 16:07:52 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f36N7mt19137 for ; Fri, 6 Apr 2001 16:07:48 -0700 X-mProtect: Fri, 6 Apr 2001 16:07:48 -0700 Nokia Silicon Valley Messaging Protection Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "cs.ucl.ac.uk") by darkstar.iprg.nokia.com(WTS.12.69) smtpdsF4M0T; Fri, 06 Apr 2001 16:02:54 PDT Message-ID: <3ACE4B1F.D0E35E7A@cs.ucl.ac.uk> Date: Fri, 06 Apr 2001 16:02:55 -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 Netwoks in MIPv6 References: <3ACDBFC1.F3E5121A@inrialpes.fr> <15053.58913.722549.842387@thomasm-u1.cisco.com> <3ACDEAB3.9E5ABDE9@inrialpes.fr> <3ACE016F.C744FDA5@cs.ucl.ac.uk> <3ACE9071.A24EF754@Kniveton.com> <15054.14547.723345.748012@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: > Where I always get stuck on this merry-go-round is > with updating DNS (or anything else that has long > term name/address bindings). Simply put, DNS is > not a real time database and anything that wants > to push it in that direction is pretty well > doomed, at least in my opinion. I surely would not consider mere DNS updates as a solution to the renumbering issue I have discussed this with people but don't know how this is received. First we must differentiate between home-domain renumbering visited-domain renumbering or what I call island renumbering. This is the case for MRs In the home domain renumbering my solution would be to enable some peristent state for dual prefix so that when an MN is away from home, its old prefix would sustain for sometime (till it gets back or till it become reasonably stationary since we wouldn not like to interfere with the handoff process. I assumed that renumbering here does not happen on a daily basis. The above is mainly to sustain interception of packets destined to the home addr of the MN in the critical periods before the new home prefix could be conveyed back to the MN at a suitable timing. This need probably be coupled with an explicit renumbering notification back to the MN informing it that the prefix is not what it used to be...however it is important (in my thinking) not to enforce renumbering at a time that it may be difficult for the MN (harsh fading conditions for instance). The notification could carry the prefix as perceived by the HA. The MN before or with the next BU should inform the HA about its current Home address that ideally should be the a renumbered one. If the MN could not do that then it MUST be expected to do that within the next 3 BUs or within a lifetime that the persistent state would indeed persist. Beyond that it is the responsibility of the MN (as with everything in life) to comply with the protocol and stay in touch with home. In the second case, "island renumbering" my perception is that the MN behind an MR should not have to worry about renumbering on its own. It should be the MR that would need to update its home prefix according to the above suggestion. If the above was in effect AND any subnets underneath it had the same prefix then they should all comply within some amount of time... Here, for fixed nodes we could have the case of aggregate persistence in intercepting packets for the fixed hosts underneath the MR. Of course if the MNs underneath the MR happened to be visiting themselves then it MUST not be their home addr that must get renumbered but the CoA. So to sum up for island renumbering both apparent and actual MNs are renumbering their CoA (i.e. another BU coming up) for home domain renumbering and movement of the MR apparent MNs (ie fixed hosts moving with the MR) are renumbering _twice_ once their home addr (that is new home prefix) (a BU coming out for the update of the B-Cache) once their LCoA (that is new visited-domain prefix to comply with route aggregation of the domain) (another BU coming out....) (actual MNs (i.e. mobile hosts that visited the home net of the MR ) need have only their LCoA renumbered. That means 2 BU in that visiting domain. One for the initial acquisition of the LCoA and one for the new one due to visited domain renumbering. > > > I'm not saying that we should give up here -- Dave > Oran and I have gone back and forth many times > about this -- we just need to go into this with > our eyes wide open; there's definitely no free > lunch in these parts. > I don't think that anybody can claim that there is such thing as free lunch since the movement of the router and potential home renumbering are pretty major tasks...in terms of routing state validity... Theo UCL / Mobile Systems > > Mike > > T.J. Kniveton writes: > > Theo has done a good job of summing it up here. Network renumbering would be > > perfect for this situation, but it was never designed for this. Although it > > could probably be made to work if you could control all the implementations > > of nodes behind the MR, in practice it would be a hairy situation, > > especially because renumbering has a 95% chance of closing all open > > connections from each machine, and destroying a lot of application state. If > > handoffs occur frequently, the nodes would be almost unusable. Thus, we > > should probably point in one of the other directions under discussion. > > > > Another possibility is for the MR to muck with the IP headers of forwarded > > packets from the prefix, putting the MR's CoA in the From field, and > > inserting a home address option with the other node's address (original Src > > addr). Ugly but I think it would work. This would cause triangular routing > > of course. > > > > -- > > T.J. Kniveton > > NOKIA Research > > > > Theo Pagtzis wrote: > > > > > Thierry, > > > > > > Having looked in detail the issue of mobile routers in HMIP > > > > > > I need to agree on some common understanding and expand further.. > > > > > > We have the situation of a mobile node that moves. That MN has multiple > > > interfaces. One of this interfaces is attached to a visiting link (gets > > > connected to the world), obtains a CoA by whatever extensions. The rest > > > of its interfaces serve routing of packets for different attached > > > subnets with (for this discussion) fixed nodes. > > > > > > The MN will be alternatively described as a Mobile Router (MR). > > > > > > Now when the MR is moving as the PoA for an aircraft and its nodes > > > inside, what would happen is that the interface attaching to the world > > > will obtain a CoA. > > > > > > Now that CoA has a prefix. This prefix most probably complies with the > > > prefix aggregation scheme of IPv6 for that domain. > > > > > > That implies to me that when an MR attaches to a new PoA it must trigger > > > RENUMBERING to its all of the rest of its interfaces (excluding the one > > > that got the CoA). The reason? all interfaces must comply with the same > > > prefix; otherwise the border router will not know how to route packets > > > to the old prefix, which by the way would routed by the OLD border > > > router. > > > > > > That implies to me that : > > > > > > movement of the MR will trigger network renumbering for all > > > attached subnets behind that MR simply because of the router/prefix > > > aggregation requirement. This is by the way one of the strong points of > > > IPv6 for network renumbering per domain. > > > > > > The renumbering to the attached subnets under the MR, will also > > > trigger a change of the current CoA for all hosts (fixed or mobile > > > inside the vehicle). That will bring the entire branch (vehicle) inline > > > with the prefix of the visiting domain of the MR. That means to me that > > > a movement of an MR will diffuse as a ghost movement of an host > > > underneath it. > > > > > > Movement of the MR in effect triggers a ghost handoff of the MN. Why > > > ghost? The host did not move a single bit but had to change its prefix. > > > The semantics of the BU are not decoupling movement of a MN from > > > movement of the whole domain (or subdomain which in this case is a > > > vehicle). The BU sent out will signal the change of the previous (p)CoA > > > to a new (n)CoA. As such for the CNs this will look like a movement of > > > the MN. > > > > > > To this point I would like to differentiate between two dimensions of > > > movement. > > > > > > 1) apparent (what I have discussed above) > > > 2) actual (the MN does decide to move within the aircraft/spaceship > > > (see babylon 5 :) here things complicate a lot. This is so because as if > > > the renumbering was not enough, the MN will have to send an extra BU per > > > actual local movement. Here a hierarchical scheme should save the > > > day...(I am studying which) > > > > > > The question that remains here is > > > > > > 1) is renumbering fast enough to effect the semantics of a handoff > > > (that is potentially seamless). If not, renumbering will bring us to > > > square one for seamlessness... > > > 2) an MN has no direct means of discovering that a net renumbering > > > is required so that it can solicit and as a result speed it up. So if we > > > rely on timeouts and intervals here the handoff is not that fast... > > > > > > Instead of renumbering I would like to ask whether it is possible to ask > > > the routing engine on the border router to transfer routing state for > > > the attached subnets under the MR. Would that mean effectively host > > > routes for the MR (implicit for the subnets underneath it?). > > > > > > From the perspective of route/prefix aggregation this should go > > > immediately down the drain in my view but I wanted to erify that with > > > someone before excluding it from the solution space. The reason is that > > > for transient routind state (the vehichle and thus MR, will move soon to > > > another domain so what is the point to aggregate here ..) (yes we want > > > to shrink the routing table, but we could allow for a temporal > > > inflation..couldn't we) > > > > > > In terms of security I think renumbering should be pretty safe since it > > > is effected locally and does not diffuse upstream. Only from the MR and > > > below. > > > > > > Theo > > > > > > UCL/ Mobile Systems > > > > > > Thierry Ernst wrote: > > > > > > > Michael Thomas wrote: > > > > > > > > > > Thierry Ernst writes: > > > > > > > > If the mobile router moves, > > > > > > > > wouldn't that cause the mobile host's BU to the > > > > > > > > other home agent to become stale? > > > > > > > > > > > > > > > => Not if the other mobile updates its HA with a > > > > > > > new location. I mean if you just rely on the MR > > > > > > > updating its HA, that would still work but > > > > > > > doesn't really give you route optmisation. > > > > > > > > > > > > Right. > > > > > > > > > > Yes, but how does the MN behind the MR *know* that > > > > > MR changed its CoA? > > > > > > > > Why should he ? > > > > > > > > > > > > > > A related question: if it's just a non-mobile host > > > > > behind a mobile router, what causes those hosts > > > > > to change their home address destination option? > > > > > In fact, how did they know that they needed to > > > > > use it in the first place? > > > > > > > > Who ever said that the non-mobile host behind MR change their home > > > > address ? > > > > > > > > One of my point is that mobility of MR should be transparent to all > > > > hosts behind the MR. I thinks it makes sense. > > > > > > > > > > > > > > There are some pretty deep and fundamental questions > > > > > lurking here. Namely, is mobility transparent to > > > > > non-mobile hosts and if so, why? We also need to > > > > > consider what this means in the face of > > > > > renumbering which in many respects is mobility > > > > > (flattening) in disguise. > > > > > > > > Renumbering is not to happen at a rate as important as mobility, then > > > > it's not the same issues. > > From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 19:30:25 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA23116 for ; Fri, 6 Apr 2001 19:30: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 QAA13762; Fri, 6 Apr 2001 16:29: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 QAA00050; Fri, 6 Apr 2001 16:29:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36NQrK9002109 for ; Fri, 6 Apr 2001 16:26:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36NQr18002108 for mobile-ip-dist; Fri, 6 Apr 2001 16:26: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36NQhK9002101 for ; Fri, 6 Apr 2001 16:26:44 -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 QAA03150 for ; Fri, 6 Apr 2001 16:26:44 -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 QAA12382 for ; Fri, 6 Apr 2001 16:26:43 -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 QAA18317 for ; Fri, 6 Apr 2001 16:26:43 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f36NQc416468 for ; Fri, 6 Apr 2001 16:26:38 -0700 X-mProtect: Fri, 6 Apr 2001 16:26:38 -0700 Nokia Silicon Valley Messaging Protection Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "cs.ucl.ac.uk") by darkstar.iprg.nokia.com(WTS.12.69) smtpd9mRxDI; Fri, 06 Apr 2001 16:25:47 PDT Message-ID: <3ACE507D.7CA02B51@cs.ucl.ac.uk> Date: Fri, 06 Apr 2001 16:25:49 -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 Netwoks in MIPv6 References: <3ACDBFC1.F3E5121A@inrialpes.fr> <15053.58913.722549.842387@thomasm-u1.cisco.com> <3ACDEAB3.9E5ABDE9@inrialpes.fr> <3ACE016F.C744FDA5@cs.ucl.ac.uk> <3ACE9071.A24EF754@Kniveton.com> <15054.14547.723345.748012@thomasm-u1.cisco.com> <3ACE4B1F.D0E 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 > Correction... "....that there is _NOT_ such thing as free lunch..." Theo > > > I'm not saying that we should give up here -- Dave > > Oran and I have gone back and forth many times > > about this -- we just need to go into this with > > our eyes wide open; there's definitely no free > > lunch in these parts. > > > > I don't think that anybody can claim that there is such thing as free lunch since > the movement of the router and potential home renumbering are pretty major > tasks...in terms of routing state validity... > > Theo > > UCL / Mobile Systems > > > > > Mike > > > > T.J. Kniveton writes: > > > Theo has done a good job of summing it up here. Network renumbering would be > > > perfect for this situation, but it was never designed for this. Although it > > > could probably be made to work if you could control all the implementations > > > of nodes behind the MR, in practice it would be a hairy situation, > > > especially because renumbering has a 95% chance of closing all open > > > connections from each machine, and destroying a lot of application state. If > > > handoffs occur frequently, the nodes would be almost unusable. Thus, we > > > should probably point in one of the other directions under discussion. > > > > > > Another possibility is for the MR to muck with the IP headers of forwarded > > > packets from the prefix, putting the MR's CoA in the From field, and > > > inserting a home address option with the other node's address (original Src > > > addr). Ugly but I think it would work. This would cause triangular routing > > > of course. > > > > > > -- > > > T.J. Kniveton > > > NOKIA Research > > > > > > Theo Pagtzis wrote: > > > > > > > Thierry, > > > > > > > > Having looked in detail the issue of mobile routers in HMIP > > > > > > > > I need to agree on some common understanding and expand further.. > > > > > > > > We have the situation of a mobile node that moves. That MN has multiple > > > > interfaces. One of this interfaces is attached to a visiting link (gets > > > > connected to the world), obtains a CoA by whatever extensions. The rest > > > > of its interfaces serve routing of packets for different attached > > > > subnets with (for this discussion) fixed nodes. > > > > > > > > The MN will be alternatively described as a Mobile Router (MR). > > > > > > > > Now when the MR is moving as the PoA for an aircraft and its nodes > > > > inside, what would happen is that the interface attaching to the world > > > > will obtain a CoA. > > > > > > > > Now that CoA has a prefix. This prefix most probably complies with the > > > > prefix aggregation scheme of IPv6 for that domain. > > > > > > > > That implies to me that when an MR attaches to a new PoA it must trigger > > > > RENUMBERING to its all of the rest of its interfaces (excluding the one > > > > that got the CoA). The reason? all interfaces must comply with the same > > > > prefix; otherwise the border router will not know how to route packets > > > > to the old prefix, which by the way would routed by the OLD border > > > > router. > > > > > > > > That implies to me that : > > > > > > > > movement of the MR will trigger network renumbering for all > > > > attached subnets behind that MR simply because of the router/prefix > > > > aggregation requirement. This is by the way one of the strong points of > > > > IPv6 for network renumbering per domain. > > > > > > > > The renumbering to the attached subnets under the MR, will also > > > > trigger a change of the current CoA for all hosts (fixed or mobile > > > > inside the vehicle). That will bring the entire branch (vehicle) inline > > > > with the prefix of the visiting domain of the MR. That means to me that > > > > a movement of an MR will diffuse as a ghost movement of an host > > > > underneath it. > > > > > > > > Movement of the MR in effect triggers a ghost handoff of the MN. Why > > > > ghost? The host did not move a single bit but had to change its prefix. > > > > The semantics of the BU are not decoupling movement of a MN from > > > > movement of the whole domain (or subdomain which in this case is a > > > > vehicle). The BU sent out will signal the change of the previous (p)CoA > > > > to a new (n)CoA. As such for the CNs this will look like a movement of > > > > the MN. > > > > > > > > To this point I would like to differentiate between two dimensions of > > > > movement. > > > > > > > > 1) apparent (what I have discussed above) > > > > 2) actual (the MN does decide to move within the aircraft/spaceship > > > > (see babylon 5 :) here things complicate a lot. This is so because as if > > > > the renumbering was not enough, the MN will have to send an extra BU per > > > > actual local movement. Here a hierarchical scheme should save the > > > > day...(I am studying which) > > > > > > > > The question that remains here is > > > > > > > > 1) is renumbering fast enough to effect the semantics of a handoff > > > > (that is potentially seamless). If not, renumbering will bring us to > > > > square one for seamlessness... > > > > 2) an MN has no direct means of discovering that a net renumbering > > > > is required so that it can solicit and as a result speed it up. So if we > > > > rely on timeouts and intervals here the handoff is not that fast... > > > > > > > > Instead of renumbering I would like to ask whether it is possible to ask > > > > the routing engine on the border router to transfer routing state for > > > > the attached subnets under the MR. Would that mean effectively host > > > > routes for the MR (implicit for the subnets underneath it?). > > > > > > > > From the perspective of route/prefix aggregation this should go > > > > immediately down the drain in my view but I wanted to erify that with > > > > someone before excluding it from the solution space. The reason is that > > > > for transient routind state (the vehichle and thus MR, will move soon to > > > > another domain so what is the point to aggregate here ..) (yes we want > > > > to shrink the routing table, but we could allow for a temporal > > > > inflation..couldn't we) > > > > > > > > In terms of security I think renumbering should be pretty safe since it > > > > is effected locally and does not diffuse upstream. Only from the MR and > > > > below. > > > > > > > > Theo > > > > > > > > UCL/ Mobile Systems > > > > > > > > Thierry Ernst wrote: > > > > > > > > > Michael Thomas wrote: > > > > > > > > > > > > Thierry Ernst writes: > > > > > > > > > If the mobile router moves, > > > > > > > > > wouldn't that cause the mobile host's BU to the > > > > > > > > > other home agent to become stale? > > > > > > > > > > > > > > > > > => Not if the other mobile updates its HA with a > > > > > > > > new location. I mean if you just rely on the MR > > > > > > > > updating its HA, that would still work but > > > > > > > > doesn't really give you route optmisation. > > > > > > > > > > > > > > Right. > > > > > > > > > > > > Yes, but how does the MN behind the MR *know* that > > > > > > MR changed its CoA? > > > > > > > > > > Why should he ? > > > > > > > > > > > > > > > > > A related question: if it's just a non-mobile host > > > > > > behind a mobile router, what causes those hosts > > > > > > to change their home address destination option? > > > > > > In fact, how did they know that they needed to > > > > > > use it in the first place? > > > > > > > > > > Who ever said that the non-mobile host behind MR change their home > > > > > address ? > > > > > > > > > > One of my point is that mobility of MR should be transparent to all > > > > > hosts behind the MR. I thinks it makes sense. > > > > > > > > > > > > > > > > > There are some pretty deep and fundamental questions > > > > > > lurking here. Namely, is mobility transparent to > > > > > > non-mobile hosts and if so, why? We also need to > > > > > > consider what this means in the face of > > > > > > renumbering which in many respects is mobility > > > > > > (flattening) in disguise. > > > > > > > > > > Renumbering is not to happen at a rate as important as mobility, then > > > > > it's not the same issues. > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 20:48:52 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA23861 for ; Fri, 6 Apr 2001 20:48: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 KAA02905; Fri, 6 Apr 2001 10:51: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 KAA13719; Fri, 6 Apr 2001 10:51:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36HnfK9000863 for ; Fri, 6 Apr 2001 10:49:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36Hnft8000861 for mobile-ip-dist; Fri, 6 Apr 2001 10: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36HnRK9000852 for ; Fri, 6 Apr 2001 10:49:27 -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 KAA24714 for ; Fri, 6 Apr 2001 10:49:27 -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 KAA14134 for ; Fri, 6 Apr 2001 10:49:23 -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 KAA13808 for ; Fri, 6 Apr 2001 10:49:21 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f36HnKj02593 for ; Fri, 6 Apr 2001 10:49:20 -0700 X-mProtect: Fri, 6 Apr 2001 10:49:20 -0700 Nokia Silicon Valley Messaging Protection Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "cs.ucl.ac.uk") by darkstar.iprg.nokia.com(WTS.12.69) smtpdxljW4V; Fri, 06 Apr 2001 10:48:31 PDT Message-ID: <3ACE016F.C744FDA5@cs.ucl.ac.uk> Date: Fri, 06 Apr 2001 10:48:31 -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 Netwoks in MIPv6 References: <3ACDBFC1.F3E5121A@inrialpes.fr> <15053.58913.722549.842387@thomasm-u1.cisco.com> <3ACDEAB3.9E5ABDE9@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, Having looked in detail the issue of mobile routers in HMIP I need to agree on some common understanding and expand further.. We have the situation of a mobile node that moves. That MN has multiple interfaces. One of this interfaces is attached to a visiting link (gets connected to the world), obtains a CoA by whatever extensions. The rest of its interfaces serve routing of packets for different attached subnets with (for this discussion) fixed nodes. The MN will be alternatively described as a Mobile Router (MR). Now when the MR is moving as the PoA for an aircraft and its nodes inside, what would happen is that the interface attaching to the world will obtain a CoA. Now that CoA has a prefix. This prefix most probably complies with the prefix aggregation scheme of IPv6 for that domain. That implies to me that when an MR attaches to a new PoA it must trigger RENUMBERING to its all of the rest of its interfaces (excluding the one that got the CoA). The reason? all interfaces must comply with the same prefix; otherwise the border router will not know how to route packets to the old prefix, which by the way would routed by the OLD border router. That implies to me that : movement of the MR will trigger network renumbering for all attached subnets behind that MR simply because of the router/prefix aggregation requirement. This is by the way one of the strong points of IPv6 for network renumbering per domain. The renumbering to the attached subnets under the MR, will also trigger a change of the current CoA for all hosts (fixed or mobile inside the vehicle). That will bring the entire branch (vehicle) inline with the prefix of the visiting domain of the MR. That means to me that a movement of an MR will diffuse as a ghost movement of an host underneath it. Movement of the MR in effect triggers a ghost handoff of the MN. Why ghost? The host did not move a single bit but had to change its prefix. The semantics of the BU are not decoupling movement of a MN from movement of the whole domain (or subdomain which in this case is a vehicle). The BU sent out will signal the change of the previous (p)CoA to a new (n)CoA. As such for the CNs this will look like a movement of the MN. To this point I would like to differentiate between two dimensions of movement. 1) apparent (what I have discussed above) 2) actual (the MN does decide to move within the aircraft/spaceship (see babylon 5 :) here things complicate a lot. This is so because as if the renumbering was not enough, the MN will have to send an extra BU per actual local movement. Here a hierarchical scheme should save the day...(I am studying which) The question that remains here is 1) is renumbering fast enough to effect the semantics of a handoff (that is potentially seamless). If not, renumbering will bring us to square one for seamlessness... 2) an MN has no direct means of discovering that a net renumbering is required so that it can solicit and as a result speed it up. So if we rely on timeouts and intervals here the handoff is not that fast... Instead of renumbering I would like to ask whether it is possible to ask the routing engine on the border router to transfer routing state for the attached subnets under the MR. Would that mean effectively host routes for the MR (implicit for the subnets underneath it?). From the perspective of route/prefix aggregation this should go immediately down the drain in my view but I wanted to erify that with someone before excluding it from the solution space. The reason is that for transient routind state (the vehichle and thus MR, will move soon to another domain so what is the point to aggregate here ..) (yes we want to shrink the routing table, but we could allow for a temporal inflation..couldn't we) In terms of security I think renumbering should be pretty safe since it is effected locally and does not diffuse upstream. Only from the MR and below. Theo UCL/ Mobile Systems Thierry Ernst wrote: > Michael Thomas wrote: > > > > Thierry Ernst writes: > > > > > If the mobile router moves, > > > > > wouldn't that cause the mobile host's BU to the > > > > > other home agent to become stale? > > > > > > > > > => Not if the other mobile updates its HA with a > > > > new location. I mean if you just rely on the MR > > > > updating its HA, that would still work but > > > > doesn't really give you route optmisation. > > > > > > Right. > > > > Yes, but how does the MN behind the MR *know* that > > MR changed its CoA? > > Why should he ? > > > > > A related question: if it's just a non-mobile host > > behind a mobile router, what causes those hosts > > to change their home address destination option? > > In fact, how did they know that they needed to > > use it in the first place? > > Who ever said that the non-mobile host behind MR change their home > address ? > > One of my point is that mobility of MR should be transparent to all > hosts behind the MR. I thinks it makes sense. > > > > > There are some pretty deep and fundamental questions > > lurking here. Namely, is mobility transparent to > > non-mobile hosts and if so, why? We also need to > > consider what this means in the face of > > renumbering which in many respects is mobility > > (flattening) in disguise. > > Renumbering is not to happen at a rate as important as mobility, then > it's not the same issues. From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 21:22:09 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA24114 for ; Fri, 6 Apr 2001 21:22:08 -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 SAA22801; Fri, 6 Apr 2001 18:20: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 SAA13741; Fri, 6 Apr 2001 18:19:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f371FBK9002255 for ; Fri, 6 Apr 2001 18:15:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f371FBFo002254 for mobile-ip-dist; Fri, 6 Apr 2001 18:15:11 -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.87.31] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f371F2K9002247 for ; Fri, 6 Apr 2001 18:15:02 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with SMTP id f371F1Cq178579; Fri, 6 Apr 2001 18:15:02 -0700 (PDT) Message-Id: <200104070115.f371F1Cq178579@jurassic.eng.sun.com> Date: Fri, 6 Apr 2001 18:12:30 -0700 (PDT) From: Alper Yegin Subject: [mobile-ip] Mobile IPv6 spec issues from Connectathon 2001 To: dbj@cs.rice.edu, charliep@iprg.nokia.com Cc: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: sq6axuflJNFK1ou9PzqaKQ== 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: This message didn't show up on the mailing list. Resending... ------------- Begin Forwarded Message ------------- For the second year Connectathon covered testing both Mobile IPv4 and Mobile IPv6 protocols. During the event, Mobile IP participants got together to discuss specification related issues. We came up with a number of them, which was outlined in the Connectathon presentation given by Carl Williams and myself at IETF 50. Here's a recapture of Mobile IPv6 spec issues, for those who weren't at the IETF meeting (in case they have comments), and for the Mobile IPv6 draft authors to incorporate these into the next revision of the draft. Cheers, Alper Yegin [1] Movement detection (section 10.4) ... Instead, a mobile node SHOULD consider receipt of any IPv6 packets from its current default router as an indication that it is still reachable from the router. Both packets from the router's IP address and (IPv6) packets from its link-layer address (e.g., those forwarded but not originated by the router) SHOULD be considered. Draft suggests that receiving packets from a node with same link-layer address and IP address as current default router means that mobile node is still attached to the same link. BUT, different interfaces of the same router can have the same MAC address, therefore same link-local address but advertise different prefixes. In this case, mobile node would fail to detect movement if it only looks at the source MAC and IP address of packets. Therefore draft should not suggest a match on source MAC address and IP address is sufficient. [2] Sending binding acknowledgement for failed binding updates (section 5.2) Rather, the care-of address used by this node in sending the packet containing the Binding Acknowledgement MUST be copied from the care-of address received in the rejected Binding Update; ... Draft says receiving node MUST send a binding acknowledgement for failed binding updates. It also says the care-of address MUST be copied from the failed binding update. BUT in the case care-of address is an invalid address such as multicast or unspecified address, such an address should not be used as the care-of address in binding acknowledgement. Draft can be updated to say: - If we have received this binding update as a home agent, we MUST not send a binding acknowledgement - If we have received this binding update as a correspondent node, we MUST send the binding acknowledgement to home address (or not send at all?) [3] Home agent address discovery request message (section 5.6) Home Agent Address Discovery Request Message includes the Home Address field. This information is used by the receiving home agent to return the list of home agents matching the prefix of the mobile node. This request packet is sent to "Mobile IPv6 Home-Agents" anycast address for its own home subnet prefix. The receiving home agent can figure out the prefix of the mobile node just by looking at the destination address of the request packet. Therefore Home Address field in the request message is not needed in the draft. [4] ICMPs can delete binding cache (section 8.8) If the correspondent node receives persistent ICMP Destination Unreachable messages after sending packets to a mobile node based on an entry in its Binding Cache, the correspondent node SHOULD delete this Binding Cache entry. The only way binding cache entries can be deleted is through binding updates and persistent ICMP unreachables. The former is required to be authenticated, but not the latter. The draft should have a proper warning about this, as unauthenticated ICMP messages can be used for DoS attacks. [5] Deregistering a care-of address (section 8.5) The draft says that binding acknowledgement MUST be sent using a routing header in the same way as any other packet sent to a mobile node using a care-of address. BUT, what should be the care-of address used in the case this was a deregistration? Draft should specify that it MUST be the care-of address used in the triggering binding update. (similarly, draft already specifies that for failed binding updates case). ------------- End Forwarded Message ------------- From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 6 21:48:49 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA25273 for ; Fri, 6 Apr 2001 21:48:49 -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 SAA01880; Fri, 6 Apr 2001 18:46:50 -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 SAA28604; Fri, 6 Apr 2001 18:46:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f371inK9002384 for ; Fri, 6 Apr 2001 18:44:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f371inU7002383 for mobile-ip-dist; Fri, 6 Apr 2001 18:44: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f371idK9002376 for ; Fri, 6 Apr 2001 18:44:40 -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 SAA28212 for ; Fri, 6 Apr 2001 18:44:39 -0700 (PDT) Received: from c007.snv.cp.net (c007-h000.c007.snv.cp.net [209.228.33.206]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id TAA29895 for ; Fri, 6 Apr 2001 19:44:39 -0600 (MDT) Received: (cpmta 17780 invoked from network); 6 Apr 2001 18:44:37 -0700 Received: from unknown (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.206) with SMTP; 6 Apr 2001 18:44:37 -0700 X-Sent: 7 Apr 2001 01:44:37 GMT Message-ID: <005601c0bf04$2e81b240$6501a8c0@philneum> From: "Phil Neumiller" To: , , , "James Kempf" Cc: , , , , , References: <8572CF1E2A95D211A1190008C7EAA24602720927@daeis05nok> <5.0.0.25.1.20010407101802.00a149a0@localhost> Subject: [mobile-ip] Re: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Fri, 6 Apr 2001 20:43:43 -0500 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: Jim, and (really long threaders) These are clearly excellent details James, but I would be willing to bet $2.00 that none of what you state below is in an I-D of any sort, and this has probably lead to an incredible amount of confusion and wasted bandwidth on the MIP list. I have not kept up with these standards as you know, I was familiar with them at one time. I made some additional comments below on your 3GPP update which I really appreciated. ----- Original Message ----- From: "James Kempf" To: "Phil Neumiller" ; ; ; Cc: ; ; ; ; ; Sent: Friday, April 06, 2001 8:28 PM Subject: Re: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover > Phil, > > I think this discussion may be a case of misunderstanding about what is > done where. > > Header compression seems of most value on what in 3GPP speak is called > the nonaccess stratum. This is the packets that applications at the top of > the mobile's stack sees, and these are the bits that go out over the air. > These packets never see soft handoff, because they are segmented into > radio frames by the time soft handoff occurs. The compression must > be done before the packets are stuffed into radio frames. > OK this is the mobile side and I believe we were talking about the BTS/AR side in this thread. > In the so-called access stratum, header compression may be used to > remove header overhead on slow links so that the real time requirements > of CDMA radio access can be met. There isn't an issue with moving context > because the SDU is at a centrallly located point so when a soft handoff > leg needs to be added, the SDU can take care of it. The only time > there may be an issue is when the SDU itself gets relocated (called > SRNS relocation in 3GPP speak). This is a fairly rare event, but > would need to be handled in an IP RAN design. Oh, I see, very interesting. The difference here with OBAST is that the so called SRNS is a bit more frequent since the "virtual" SDU is following the mobile throgh the "sea" of moby (I mean BTSs). I guess that even between what 3GPP dis and what OBAST did the original thread was still bogus, and that was my point. Seems that the arguments were being based strictly on hard HO and no description of the soft case. One question is the SRNS operation "soft" in the 3GPP design (because it was in OBAST of course!). Thanks, Phil From owner-mobile-ip@sunroof.eng.sun.com Sat Apr 7 10:51:45 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14831 for ; Sat, 7 Apr 2001 10:51:44 -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; Sat, 7 Apr 2001 07:51: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 HAA02211; Sat, 7 Apr 2001 07:51:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f37EmqK9003100 for ; Sat, 7 Apr 2001 07:48:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f37Emqa9003099 for mobile-ip-dist; Sat, 7 Apr 2001 07:48:52 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f37EmfK9003092 for ; Sat, 7 Apr 2001 07:48:41 -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 HAA00997 for ; Sat, 7 Apr 2001 07:48:41 -0700 (PDT) Received: from prserv.net (out2.prserv.net [32.97.166.32] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA21229 for ; Sat, 7 Apr 2001 07:48:41 -0700 (PDT) Received: from attglobal.net (slip-32-103-39-111.il.us.prserv.net[32.103.39.111]) by prserv.net (out2) with SMTP id <2001040714483920200t88gke>; Sat, 7 Apr 2001 14:48:40 +0000 Message-ID: <3ACF28C6.1BCA13E4@attglobal.net> Date: Sat, 07 Apr 2001 09:48:38 -0500 From: Sebastian Thalanany X-Mailer: Mozilla 4.08 [en] (WinNT; I) MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com, gdommety@cisco.com CC: kleung@cisco.com Subject: [mobile-ip] CVSE type number in RFC3025 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 Gopal, There seems to be a discrepancy between the value assigned for the CVSE-TYPE-NUMBER in RFC 3025 and in IANA. The difference in the assigned value was found to be as follows: CVSE-TYPE-NUMBER = 37 in RFC3025 CVSE-TYPE-NUMBER = 38 in IANA (Under Mobile IP numbers) The 3GPP2 IOS standard is using a value of 38. Please clarify. Thanks. Regards, Sebastian From owner-mobile-ip@sunroof.eng.sun.com Sat Apr 7 12:38:20 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15822 for ; Sat, 7 Apr 2001 12:38:20 -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 JAA17055; Sat, 7 Apr 2001 09:38: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 JAA11571; Sat, 7 Apr 2001 09:38:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f37Ga1K9003257 for ; Sat, 7 Apr 2001 09:36:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f37Ga0CA003256 for mobile-ip-dist; Sat, 7 Apr 2001 09:36: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f37GZqK9003249 for ; Sat, 7 Apr 2001 09:35:52 -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 JAA14359 for ; Sat, 7 Apr 2001 09:35:52 -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 JAA07550 for ; Sat, 7 Apr 2001 09:35:50 -0700 (PDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f37GZns02730 for ; Sat, 7 Apr 2001 18:35:49 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id SAA01708; Sat, 7 Apr 2001 18:35:47 +0200 Message-ID: <3ACF32BB.C71333A9@era.ericsson.se> Date: Sat, 07 Apr 2001 17:31:07 +0200 From: Mattias Pettersson X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6 References: <3ACDBFC1.F3E5121A@inrialpes.fr> <15053.58913.722549.842387@thomasm-u1.cisco.com> <3ACDEAB3.9E5ABDE9@inrialpes.fr> <3ACE016F.C744FDA5@cs.ucl.ac.uk> 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 Theo Pagtzis wrote: > > Thierry, > > Having looked in detail the issue of mobile routers in HMIP > [...] > Now when the MR is moving as the PoA for an aircraft and its nodes > inside, what would happen is that the interface attaching to the world > will obtain a CoA. I fully agree. > > Now that CoA has a prefix. This prefix most probably complies with the > prefix aggregation scheme of IPv6 for that domain. Sure. > > That implies to me that when an MR attaches to a new PoA it must trigger > RENUMBERING to its all of the rest of its interfaces (excluding the one > that got the CoA). The reason? all interfaces must comply with the same > prefix; otherwise the border router will not know how to route packets > to the old prefix, which by the way would routed by the OLD border > router. > > That implies to me that : > > movement of the MR will trigger network renumbering for all > attached subnets behind that MR simply because of the router/prefix > aggregation requirement. This is by the way one of the strong points of > IPv6 for network renumbering per domain. I fear that you go slightly too fast here. Before we move on, if we discuss further along this line, the MR needs a topologically correct prefix for the mobile network it is serving. I guess we both agree on that. Since the COA for the upper interface of the MR belongs to P1 (in accordance to Thierry's earlier figure) and P1 has prefix length (usually /64), MR needs a new prefix to use for the mobile network. This requires prefix delegation, e.g. draft-haberman-ipngwg-auto-prefix-00.txt. In this way, MR can get all the prefixes it needs for the mobile networks it is serving. Next it needs to run a routing protocol between itself and the delegating router so that packets can reach the nodes behind the MR, this is also mentioned in the draft above. Hopefully, if the MR moves within one domain for a while, and moves between ARs that all belong to the same aggregated prefix (NLA or whatever), it could keep on using the same delegated prefix(es) for the entire stay in this domain. This assumes that the domain runs some internal routing protocol. Whenever the MR moves to a new AR, it will keep the prefixes it got earlier, but it will propagate routing updates for the delegated prefixes to all routers within the domain. This will not be significantly heavier on the internal routing since there is no or little aggregation within one domain, and if there is, punching holes in routing tables like this is no big deal as long as the number of prefixes used in the domain isn't huge. Ok, now the MR can go on and initiate renumbering of the mobile networks it serves. > > The renumbering to the attached subnets under the MR, will also > trigger a change of the current CoA for all hosts (fixed or mobile > inside the vehicle). That will bring the entire branch (vehicle) inline > with the prefix of the visiting domain of the MR. That means to me that > a movement of an MR will diffuse as a ghost movement of an host > underneath it. > > Movement of the MR in effect triggers a ghost handoff of the MN. Why > ghost? The host did not move a single bit but had to change its prefix. > The semantics of the BU are not decoupling movement of a MN from > movement of the whole domain (or subdomain which in this case is a > vehicle). The BU sent out will signal the change of the previous (p)CoA > to a new (n)CoA. As such for the CNs this will look like a movement of > the MN. > > To this point I would like to differentiate between two dimensions of > movement. > > 1) apparent (what I have discussed above) > 2) actual (the MN does decide to move within the aircraft/spaceship > (see babylon 5 :) here things complicate a lot. This is so because as if > the renumbering was not enough, the MN will have to send an extra BU per > actual local movement. Here a hierarchical scheme should save the > day...(I am studying which) > > The question that remains here is > > 1) is renumbering fast enough to effect the semantics of a handoff > (that is potentially seamless). If not, renumbering will bring us to > square one for seamlessness... > 2) an MN has no direct means of discovering that a net renumbering > is required so that it can solicit and as a result speed it up. So if we > rely on timeouts and intervals here the handoff is not that fast... > I'm afraid it will be trickier to move seamless for every new feature we want to add to Mobile IP. > Instead of renumbering I would like to ask whether it is possible to ask > the routing engine on the border router to transfer routing state for > the attached subnets under the MR. Would that mean effectively host > routes for the MR (implicit for the subnets underneath it?). > > >From the perspective of route/prefix aggregation this should go > immediately down the drain in my view but I wanted to erify that with > someone before excluding it from the solution space. The reason is that > for transient routind state (the vehichle and thus MR, will move soon to > another domain so what is the point to aggregate here ..) (yes we want > to shrink the routing table, but we could allow for a temporal > inflation..couldn't we) Please see my comments above. Mobility is statistically quite local, so I guess it's fair to assume that the MR probably stays within the domain next time it moves. /Mattias From owner-mobile-ip@sunroof.eng.sun.com Sat Apr 7 12:54:17 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16050 for ; Sat, 7 Apr 2001 12:54:16 -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 JAA10931; Sat, 7 Apr 2001 09:53:54 -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 JAA02344; Sat, 7 Apr 2001 09:53:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f37GpNK9003331 for ; Sat, 7 Apr 2001 09:51:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f37GpNpP003330 for mobile-ip-dist; Sat, 7 Apr 2001 09:51: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f37GpEK9003323 for ; Sat, 7 Apr 2001 09:51:14 -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 JAA12299 for ; Sat, 7 Apr 2001 09:51:14 -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 JAA21284 for ; Sat, 7 Apr 2001 09:51:12 -0700 (PDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f37GpBs06022 for ; Sat, 7 Apr 2001 18:51:11 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id SAA02032; Sat, 7 Apr 2001 18:51:10 +0200 Message-ID: <3ACF32BB.C71333A9@era.ericsson.se> Date: Sat, 07 Apr 2001 17:31:07 +0200 From: Mattias Pettersson X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6 References: <3ACDBFC1.F3E5121A@inrialpes.fr> <15053.58913.722549.842387@thomasm-u1.cisco.com> <3ACDEAB3.9E5ABDE9@inrialpes.fr> <3ACE016F.C744FDA5@cs.ucl.ac.uk> 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 Theo Pagtzis wrote: > > Thierry, > > Having looked in detail the issue of mobile routers in HMIP > [...] > Now when the MR is moving as the PoA for an aircraft and its nodes > inside, what would happen is that the interface attaching to the world > will obtain a CoA. I fully agree. > > Now that CoA has a prefix. This prefix most probably complies with the > prefix aggregation scheme of IPv6 for that domain. Sure. > > That implies to me that when an MR attaches to a new PoA it must trigger > RENUMBERING to its all of the rest of its interfaces (excluding the one > that got the CoA). The reason? all interfaces must comply with the same > prefix; otherwise the border router will not know how to route packets > to the old prefix, which by the way would routed by the OLD border > router. > > That implies to me that : > > movement of the MR will trigger network renumbering for all > attached subnets behind that MR simply because of the router/prefix > aggregation requirement. This is by the way one of the strong points of > IPv6 for network renumbering per domain. I fear that you go slightly too fast here. Before we move on, if we discuss further along this line, the MR needs a topologically correct prefix for the mobile network it is serving. I guess we both agree on that. Since the COA for the upper interface of the MR belongs to P1 (in accordance to Thierry's earlier figure) and P1 has prefix length (usually /64), MR needs a new prefix to use for the mobile network. This requires prefix delegation, e.g. draft-haberman-ipngwg-auto-prefix-00.txt. In this way, MR can get all the prefixes it needs for the mobile networks it is serving. Next it needs to run a routing protocol between itself and the delegating router so that packets can reach the nodes behind the MR, this is also mentioned in the draft above. Hopefully, if the MR moves within one domain for a while, and moves between ARs that all belong to the same aggregated prefix (NLA or whatever), it could keep on using the same delegated prefix(es) for the entire stay in this domain. This assumes that the domain runs some internal routing protocol. Whenever the MR moves to a new AR, it will keep the prefixes it got earlier, but it will propagate routing updates for the delegated prefixes to all routers within the domain. This will not be significantly heavier on the internal routing since there is no or little aggregation within one domain, and if there is, punching holes in routing tables like this is no big deal as long as the number of prefixes used in the domain isn't huge. Ok, now the MR can go on and initiate renumbering of the mobile networks it serves. > > The renumbering to the attached subnets under the MR, will also > trigger a change of the current CoA for all hosts (fixed or mobile > inside the vehicle). That will bring the entire branch (vehicle) inline > with the prefix of the visiting domain of the MR. That means to me that > a movement of an MR will diffuse as a ghost movement of an host > underneath it. > > Movement of the MR in effect triggers a ghost handoff of the MN. Why > ghost? The host did not move a single bit but had to change its prefix. > The semantics of the BU are not decoupling movement of a MN from > movement of the whole domain (or subdomain which in this case is a > vehicle). The BU sent out will signal the change of the previous (p)CoA > to a new (n)CoA. As such for the CNs this will look like a movement of > the MN. > > To this point I would like to differentiate between two dimensions of > movement. > > 1) apparent (what I have discussed above) > 2) actual (the MN does decide to move within the aircraft/spaceship > (see babylon 5 :) here things complicate a lot. This is so because as if > the renumbering was not enough, the MN will have to send an extra BU per > actual local movement. Here a hierarchical scheme should save the > day...(I am studying which) > > The question that remains here is > > 1) is renumbering fast enough to effect the semantics of a handoff > (that is potentially seamless). If not, renumbering will bring us to > square one for seamlessness... > 2) an MN has no direct means of discovering that a net renumbering > is required so that it can solicit and as a result speed it up. So if we > rely on timeouts and intervals here the handoff is not that fast... > I'm afraid it will be trickier to move seamless for every new feature we want to add to Mobile IP. > Instead of renumbering I would like to ask whether it is possible to ask > the routing engine on the border router to transfer routing state for > the attached subnets under the MR. Would that mean effectively host > routes for the MR (implicit for the subnets underneath it?). > > >From the perspective of route/prefix aggregation this should go > immediately down the drain in my view but I wanted to erify that with > someone before excluding it from the solution space. The reason is that > for transient routind state (the vehichle and thus MR, will move soon to > another domain so what is the point to aggregate here ..) (yes we want > to shrink the routing table, but we could allow for a temporal > inflation..couldn't we) Please see my comments above. Mobility is statistically quite local, so I guess it's fair to assume that the MR probably stays within the domain next time it moves. /Mattias From owner-mobile-ip@sunroof.eng.sun.com Sat Apr 7 12:58:30 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16104 for ; Sat, 7 Apr 2001 12:58: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 JAA18606; Sat, 7 Apr 2001 09:58: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 JAA16477; Sat, 7 Apr 2001 09:58:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f37GvRK9003397 for ; Sat, 7 Apr 2001 09:57:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f37GvQhd003396 for mobile-ip-dist; Sat, 7 Apr 2001 09:57: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f37GvHK9003389 for ; Sat, 7 Apr 2001 09:57:18 -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 JAA12597 for ; Sat, 7 Apr 2001 09:57:18 -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 JAA28450 for ; Sat, 7 Apr 2001 09:57:16 -0700 (PDT) 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 f37GvFI23917 for ; Sat, 7 Apr 2001 18:57:16 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id SAA02217; Sat, 7 Apr 2001 18:57:14 +0200 Message-ID: <3ACF32BB.C71333A9@era.ericsson.se> Date: Sat, 07 Apr 2001 17:31:07 +0200 From: Mattias Pettersson X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6 References: <3ACDBFC1.F3E5121A@inrialpes.fr> <15053.58913.722549.842387@thomasm-u1.cisco.com> <3ACDEAB3.9E5ABDE9@inrialpes.fr> <3ACE016F.C744FDA5@cs.ucl.ac.uk> 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 Theo Pagtzis wrote: > > Thierry, > > Having looked in detail the issue of mobile routers in HMIP > [...] > Now when the MR is moving as the PoA for an aircraft and its nodes > inside, what would happen is that the interface attaching to the world > will obtain a CoA. I fully agree. > > Now that CoA has a prefix. This prefix most probably complies with the > prefix aggregation scheme of IPv6 for that domain. Sure. > > That implies to me that when an MR attaches to a new PoA it must trigger > RENUMBERING to its all of the rest of its interfaces (excluding the one > that got the CoA). The reason? all interfaces must comply with the same > prefix; otherwise the border router will not know how to route packets > to the old prefix, which by the way would routed by the OLD border > router. > > That implies to me that : > > movement of the MR will trigger network renumbering for all > attached subnets behind that MR simply because of the router/prefix > aggregation requirement. This is by the way one of the strong points of > IPv6 for network renumbering per domain. I fear that you go slightly too fast here. Before we move on, if we discuss further along this line, the MR needs a topologically correct prefix for the mobile network it is serving. I guess we both agree on that. Since the COA for the upper interface of the MR belongs to P1 (in accordance to Thierry's earlier figure) and P1 has prefix length (usually /64), MR needs a new prefix to use for the mobile network. This requires prefix delegation, e.g. draft-haberman-ipngwg-auto-prefix-00.txt. In this way, MR can get all the prefixes it needs for the mobile networks it is serving. Next it needs to run a routing protocol between itself and the delegating router so that packets can reach the nodes behind the MR, this is also mentioned in the draft above. Hopefully, if the MR moves within one domain for a while, and moves between ARs that all belong to the same aggregated prefix (NLA or whatever), it could keep on using the same delegated prefix(es) for the entire stay in this domain. This assumes that the domain runs some internal routing protocol. Whenever the MR moves to a new AR, it will keep the prefixes it got earlier, but it will propagate routing updates for the delegated prefixes to all routers within the domain. This will not be significantly heavier on the internal routing since there is no or little aggregation within one domain, and if there is, punching holes in routing tables like this is no big deal as long as the number of prefixes used in the domain isn't huge. Ok, now the MR can go on and initiate renumbering of the mobile networks it serves. > > The renumbering to the attached subnets under the MR, will also > trigger a change of the current CoA for all hosts (fixed or mobile > inside the vehicle). That will bring the entire branch (vehicle) inline > with the prefix of the visiting domain of the MR. That means to me that > a movement of an MR will diffuse as a ghost movement of an host > underneath it. > > Movement of the MR in effect triggers a ghost handoff of the MN. Why > ghost? The host did not move a single bit but had to change its prefix. > The semantics of the BU are not decoupling movement of a MN from > movement of the whole domain (or subdomain which in this case is a > vehicle). The BU sent out will signal the change of the previous (p)CoA > to a new (n)CoA. As such for the CNs this will look like a movement of > the MN. > > To this point I would like to differentiate between two dimensions of > movement. > > 1) apparent (what I have discussed above) > 2) actual (the MN does decide to move within the aircraft/spaceship > (see babylon 5 :) here things complicate a lot. This is so because as if > the renumbering was not enough, the MN will have to send an extra BU per > actual local movement. Here a hierarchical scheme should save the > day...(I am studying which) > > The question that remains here is > > 1) is renumbering fast enough to effect the semantics of a handoff > (that is potentially seamless). If not, renumbering will bring us to > square one for seamlessness... > 2) an MN has no direct means of discovering that a net renumbering > is required so that it can solicit and as a result speed it up. So if we > rely on timeouts and intervals here the handoff is not that fast... > I'm afraid it will be trickier to move seamless for every new feature we want to add to Mobile IP. > Instead of renumbering I would like to ask whether it is possible to ask > the routing engine on the border router to transfer routing state for > the attached subnets under the MR. Would that mean effectively host > routes for the MR (implicit for the subnets underneath it?). > > >From the perspective of route/prefix aggregation this should go > immediately down the drain in my view but I wanted to erify that with > someone before excluding it from the solution space. The reason is that > for transient routind state (the vehichle and thus MR, will move soon to > another domain so what is the point to aggregate here ..) (yes we want > to shrink the routing table, but we could allow for a temporal > inflation..couldn't we) Please see my comments above. Mobility is statistically quite local, so I guess it's fair to assume that the MR probably stays within the domain next time it moves. /Mattias From owner-mobile-ip@sunroof.eng.sun.com Sat Apr 7 13:02:00 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16198 for ; Sat, 7 Apr 2001 13:01: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 KAA19045; Sat, 7 Apr 2001 10:01:59 -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 KAA02971; Sat, 7 Apr 2001 10:01:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f37H0jK9003453 for ; Sat, 7 Apr 2001 10:00:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f37H0iY7003452 for mobile-ip-dist; Sat, 7 Apr 2001 10:00: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f37H0ZK9003442 for ; Sat, 7 Apr 2001 10:00: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 KAA12809 for ; Sat, 7 Apr 2001 10:00:35 -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 KAA12234 for ; Sat, 7 Apr 2001 10:00:34 -0700 (PDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f37H0Xs08108 for ; Sat, 7 Apr 2001 19:00:33 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id TAA02274; Sat, 7 Apr 2001 19:00:31 +0200 Message-ID: <3ACF32BB.C71333A9@era.ericsson.se> Date: Sat, 07 Apr 2001 17:31:07 +0200 From: Mattias Pettersson X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6 References: <3ACDBFC1.F3E5121A@inrialpes.fr> <15053.58913.722549.842387@thomasm-u1.cisco.com> <3ACDEAB3.9E5ABDE9@inrialpes.fr> <3ACE016F.C744FDA5@cs.ucl.ac.uk> 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 Theo Pagtzis wrote: > > Thierry, > > Having looked in detail the issue of mobile routers in HMIP > [...] > Now when the MR is moving as the PoA for an aircraft and its nodes > inside, what would happen is that the interface attaching to the world > will obtain a CoA. I fully agree. > > Now that CoA has a prefix. This prefix most probably complies with the > prefix aggregation scheme of IPv6 for that domain. Sure. > > That implies to me that when an MR attaches to a new PoA it must trigger > RENUMBERING to its all of the rest of its interfaces (excluding the one > that got the CoA). The reason? all interfaces must comply with the same > prefix; otherwise the border router will not know how to route packets > to the old prefix, which by the way would routed by the OLD border > router. > > That implies to me that : > > movement of the MR will trigger network renumbering for all > attached subnets behind that MR simply because of the router/prefix > aggregation requirement. This is by the way one of the strong points of > IPv6 for network renumbering per domain. I fear that you go slightly too fast here. Before we move on, if we discuss further along this line, the MR needs a topologically correct prefix for the mobile network it is serving. I guess we both agree on that. Since the COA for the upper interface of the MR belongs to P1 (in accordance to Thierry's earlier figure) and P1 has prefix length (usually /64), MR needs a new prefix to use for the mobile network. This requires prefix delegation, e.g. draft-haberman-ipngwg-auto-prefix-00.txt. In this way, MR can get all the prefixes it needs for the mobile networks it is serving. Next it needs to run a routing protocol between itself and the delegating router so that packets can reach the nodes behind the MR, this is also mentioned in the draft above. Hopefully, if the MR moves within one domain for a while, and moves between ARs that all belong to the same aggregated prefix (NLA or whatever), it could keep on using the same delegated prefix(es) for the entire stay in this domain. This assumes that the domain runs some internal routing protocol. Whenever the MR moves to a new AR, it will keep the prefixes it got earlier, but it will propagate routing updates for the delegated prefixes to all routers within the domain. This will not be significantly heavier on the internal routing since there is no or little aggregation within one domain, and if there is, punching holes in routing tables like this is no big deal as long as the number of prefixes used in the domain isn't huge. Ok, now the MR can go on and initiate renumbering of the mobile networks it serves. > > The renumbering to the attached subnets under the MR, will also > trigger a change of the current CoA for all hosts (fixed or mobile > inside the vehicle). That will bring the entire branch (vehicle) inline > with the prefix of the visiting domain of the MR. That means to me that > a movement of an MR will diffuse as a ghost movement of an host > underneath it. > > Movement of the MR in effect triggers a ghost handoff of the MN. Why > ghost? The host did not move a single bit but had to change its prefix. > The semantics of the BU are not decoupling movement of a MN from > movement of the whole domain (or subdomain which in this case is a > vehicle). The BU sent out will signal the change of the previous (p)CoA > to a new (n)CoA. As such for the CNs this will look like a movement of > the MN. > > To this point I would like to differentiate between two dimensions of > movement. > > 1) apparent (what I have discussed above) > 2) actual (the MN does decide to move within the aircraft/spaceship > (see babylon 5 :) here things complicate a lot. This is so because as if > the renumbering was not enough, the MN will have to send an extra BU per > actual local movement. Here a hierarchical scheme should save the > day...(I am studying which) > > The question that remains here is > > 1) is renumbering fast enough to effect the semantics of a handoff > (that is potentially seamless). If not, renumbering will bring us to > square one for seamlessness... > 2) an MN has no direct means of discovering that a net renumbering > is required so that it can solicit and as a result speed it up. So if we > rely on timeouts and intervals here the handoff is not that fast... > I'm afraid it will be trickier to move seamless for every new feature we want to add to Mobile IP. > Instead of renumbering I would like to ask whether it is possible to ask > the routing engine on the border router to transfer routing state for > the attached subnets under the MR. Would that mean effectively host > routes for the MR (implicit for the subnets underneath it?). > > >From the perspective of route/prefix aggregation this should go > immediately down the drain in my view but I wanted to erify that with > someone before excluding it from the solution space. The reason is that > for transient routind state (the vehichle and thus MR, will move soon to > another domain so what is the point to aggregate here ..) (yes we want > to shrink the routing table, but we could allow for a temporal > inflation..couldn't we) Please see my comments above. Mobility is statistically quite local, so I guess it's fair to assume that the MR probably stays within the domain next time it moves. /Mattias From owner-mobile-ip@sunroof.eng.sun.com Sat Apr 7 13:05:40 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16256 for ; Sat, 7 Apr 2001 13:05: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 KAA13298; Sat, 7 Apr 2001 10:05: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 KAA13253; Sat, 7 Apr 2001 10:05:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f37H3OK9003497 for ; Sat, 7 Apr 2001 10:03:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f37H3NEc003496 for mobile-ip-dist; Sat, 7 Apr 2001 10:03: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f37H3EK9003488 for ; Sat, 7 Apr 2001 10:03:15 -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 KAA03060 for ; Sat, 7 Apr 2001 10:03:14 -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 KAA29383 for ; Sat, 7 Apr 2001 10:03:13 -0700 (PDT) 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 f37H3CI25293 for ; Sat, 7 Apr 2001 19:03:12 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id TAA02369; Sat, 7 Apr 2001 19:03:11 +0200 Message-ID: <3ACF32BB.C71333A9@era.ericsson.se> Date: Sat, 07 Apr 2001 17:31:07 +0200 From: Mattias Pettersson X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6 References: <3ACDBFC1.F3E5121A@inrialpes.fr> <15053.58913.722549.842387@thomasm-u1.cisco.com> <3ACDEAB3.9E5ABDE9@inrialpes.fr> <3ACE016F.C744FDA5@cs.ucl.ac.uk> 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 Theo Pagtzis wrote: > > Thierry, > > Having looked in detail the issue of mobile routers in HMIP > [...] > Now when the MR is moving as the PoA for an aircraft and its nodes > inside, what would happen is that the interface attaching to the world > will obtain a CoA. I fully agree. > > Now that CoA has a prefix. This prefix most probably complies with the > prefix aggregation scheme of IPv6 for that domain. Sure. > > That implies to me that when an MR attaches to a new PoA it must trigger > RENUMBERING to its all of the rest of its interfaces (excluding the one > that got the CoA). The reason? all interfaces must comply with the same > prefix; otherwise the border router will not know how to route packets > to the old prefix, which by the way would routed by the OLD border > router. > > That implies to me that : > > movement of the MR will trigger network renumbering for all > attached subnets behind that MR simply because of the router/prefix > aggregation requirement. This is by the way one of the strong points of > IPv6 for network renumbering per domain. I fear that you go slightly too fast here. Before we move on, if we discuss further along this line, the MR needs a topologically correct prefix for the mobile network it is serving. I guess we both agree on that. Since the COA for the upper interface of the MR belongs to P1 (in accordance to Thierry's earlier figure) and P1 has prefix length (usually /64), MR needs a new prefix to use for the mobile network. This requires prefix delegation, e.g. draft-haberman-ipngwg-auto-prefix-00.txt. In this way, MR can get all the prefixes it needs for the mobile networks it is serving. Next it needs to run a routing protocol between itself and the delegating router so that packets can reach the nodes behind the MR, this is also mentioned in the draft above. Hopefully, if the MR moves within one domain for a while, and moves between ARs that all belong to the same aggregated prefix (NLA or whatever), it could keep on using the same delegated prefix(es) for the entire stay in this domain. This assumes that the domain runs some internal routing protocol. Whenever the MR moves to a new AR, it will keep the prefixes it got earlier, but it will propagate routing updates for the delegated prefixes to all routers within the domain. This will not be significantly heavier on the internal routing since there is no or little aggregation within one domain, and if there is, punching holes in routing tables like this is no big deal as long as the number of prefixes used in the domain isn't huge. Ok, now the MR can go on and initiate renumbering of the mobile networks it serves. > > The renumbering to the attached subnets under the MR, will also > trigger a change of the current CoA for all hosts (fixed or mobile > inside the vehicle). That will bring the entire branch (vehicle) inline > with the prefix of the visiting domain of the MR. That means to me that > a movement of an MR will diffuse as a ghost movement of an host > underneath it. > > Movement of the MR in effect triggers a ghost handoff of the MN. Why > ghost? The host did not move a single bit but had to change its prefix. > The semantics of the BU are not decoupling movement of a MN from > movement of the whole domain (or subdomain which in this case is a > vehicle). The BU sent out will signal the change of the previous (p)CoA > to a new (n)CoA. As such for the CNs this will look like a movement of > the MN. > > To this point I would like to differentiate between two dimensions of > movement. > > 1) apparent (what I have discussed above) > 2) actual (the MN does decide to move within the aircraft/spaceship > (see babylon 5 :) here things complicate a lot. This is so because as if > the renumbering was not enough, the MN will have to send an extra BU per > actual local movement. Here a hierarchical scheme should save the > day...(I am studying which) > > The question that remains here is > > 1) is renumbering fast enough to effect the semantics of a handoff > (that is potentially seamless). If not, renumbering will bring us to > square one for seamlessness... > 2) an MN has no direct means of discovering that a net renumbering > is required so that it can solicit and as a result speed it up. So if we > rely on timeouts and intervals here the handoff is not that fast... > I'm afraid it will be trickier to move seamless for every new feature we want to add to Mobile IP. > Instead of renumbering I would like to ask whether it is possible to ask > the routing engine on the border router to transfer routing state for > the attached subnets under the MR. Would that mean effectively host > routes for the MR (implicit for the subnets underneath it?). > > >From the perspective of route/prefix aggregation this should go > immediately down the drain in my view but I wanted to erify that with > someone before excluding it from the solution space. The reason is that > for transient routind state (the vehichle and thus MR, will move soon to > another domain so what is the point to aggregate here ..) (yes we want > to shrink the routing table, but we could allow for a temporal > inflation..couldn't we) Please see my comments above. Mobility is statistically quite local, so I guess it's fair to assume that the MR probably stays within the domain next time it moves. /Mattias From owner-mobile-ip@sunroof.eng.sun.com Sat Apr 7 13:07:14 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16293 for ; Sat, 7 Apr 2001 13:07: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 KAA13750; Sat, 7 Apr 2001 10:07:09 -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 KAA03402; Sat, 7 Apr 2001 10:07:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f37H55K9003519 for ; Sat, 7 Apr 2001 10:05:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f37H54SD003518 for mobile-ip-dist; Sat, 7 Apr 2001 10:05: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f37H4rK9003511 for ; Sat, 7 Apr 2001 10:04:53 -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 KAA11190 for ; Sat, 7 Apr 2001 10:04:47 -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 LAA19786 for ; Sat, 7 Apr 2001 11:04:45 -0600 (MDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f37H4is08986 for ; Sat, 7 Apr 2001 19:04:44 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id TAA02408; Sat, 7 Apr 2001 19:04:42 +0200 Message-ID: <3ACF32BB.C71333A9@era.ericsson.se> Date: Sat, 07 Apr 2001 17:31:07 +0200 From: Mattias Pettersson X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6 References: <3ACDBFC1.F3E5121A@inrialpes.fr> <15053.58913.722549.842387@thomasm-u1.cisco.com> <3ACDEAB3.9E5ABDE9@inrialpes.fr> <3ACE016F.C744FDA5@cs.ucl.ac.uk> 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 Theo Pagtzis wrote: > > Thierry, > > Having looked in detail the issue of mobile routers in HMIP > [...] > Now when the MR is moving as the PoA for an aircraft and its nodes > inside, what would happen is that the interface attaching to the world > will obtain a CoA. I fully agree. > > Now that CoA has a prefix. This prefix most probably complies with the > prefix aggregation scheme of IPv6 for that domain. Sure. > > That implies to me that when an MR attaches to a new PoA it must trigger > RENUMBERING to its all of the rest of its interfaces (excluding the one > that got the CoA). The reason? all interfaces must comply with the same > prefix; otherwise the border router will not know how to route packets > to the old prefix, which by the way would routed by the OLD border > router. > > That implies to me that : > > movement of the MR will trigger network renumbering for all > attached subnets behind that MR simply because of the router/prefix > aggregation requirement. This is by the way one of the strong points of > IPv6 for network renumbering per domain. I fear that you go slightly too fast here. Before we move on, if we discuss further along this line, the MR needs a topologically correct prefix for the mobile network it is serving. I guess we both agree on that. Since the COA for the upper interface of the MR belongs to P1 (in accordance to Thierry's earlier figure) and P1 has prefix length (usually /64), MR needs a new prefix to use for the mobile network. This requires prefix delegation, e.g. draft-haberman-ipngwg-auto-prefix-00.txt. In this way, MR can get all the prefixes it needs for the mobile networks it is serving. Next it needs to run a routing protocol between itself and the delegating router so that packets can reach the nodes behind the MR, this is also mentioned in the draft above. Hopefully, if the MR moves within one domain for a while, and moves between ARs that all belong to the same aggregated prefix (NLA or whatever), it could keep on using the same delegated prefix(es) for the entire stay in this domain. This assumes that the domain runs some internal routing protocol. Whenever the MR moves to a new AR, it will keep the prefixes it got earlier, but it will propagate routing updates for the delegated prefixes to all routers within the domain. This will not be significantly heavier on the internal routing since there is no or little aggregation within one domain, and if there is, punching holes in routing tables like this is no big deal as long as the number of prefixes used in the domain isn't huge. Ok, now the MR can go on and initiate renumbering of the mobile networks it serves. > > The renumbering to the attached subnets under the MR, will also > trigger a change of the current CoA for all hosts (fixed or mobile > inside the vehicle). That will bring the entire branch (vehicle) inline > with the prefix of the visiting domain of the MR. That means to me that > a movement of an MR will diffuse as a ghost movement of an host > underneath it. > > Movement of the MR in effect triggers a ghost handoff of the MN. Why > ghost? The host did not move a single bit but had to change its prefix. > The semantics of the BU are not decoupling movement of a MN from > movement of the whole domain (or subdomain which in this case is a > vehicle). The BU sent out will signal the change of the previous (p)CoA > to a new (n)CoA. As such for the CNs this will look like a movement of > the MN. > > To this point I would like to differentiate between two dimensions of > movement. > > 1) apparent (what I have discussed above) > 2) actual (the MN does decide to move within the aircraft/spaceship > (see babylon 5 :) here things complicate a lot. This is so because as if > the renumbering was not enough, the MN will have to send an extra BU per > actual local movement. Here a hierarchical scheme should save the > day...(I am studying which) > > The question that remains here is > > 1) is renumbering fast enough to effect the semantics of a handoff > (that is potentially seamless). If not, renumbering will bring us to > square one for seamlessness... > 2) an MN has no direct means of discovering that a net renumbering > is required so that it can solicit and as a result speed it up. So if we > rely on timeouts and intervals here the handoff is not that fast... > I'm afraid it will be trickier to move seamless for every new feature we want to add to Mobile IP. > Instead of renumbering I would like to ask whether it is possible to ask > the routing engine on the border router to transfer routing state for > the attached subnets under the MR. Would that mean effectively host > routes for the MR (implicit for the subnets underneath it?). > > >From the perspective of route/prefix aggregation this should go > immediately down the drain in my view but I wanted to erify that with > someone before excluding it from the solution space. The reason is that > for transient routind state (the vehichle and thus MR, will move soon to > another domain so what is the point to aggregate here ..) (yes we want > to shrink the routing table, but we could allow for a temporal > inflation..couldn't we) Please see my comments above. Mobility is statistically quite local, so I guess it's fair to assume that the MR probably stays within the domain next time it moves. /Mattias From owner-mobile-ip@sunroof.eng.sun.com Sat Apr 7 13:07:44 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16317 for ; Sat, 7 Apr 2001 13:07:44 -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 KAA19794; Sat, 7 Apr 2001 10:07: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 KAA13487; Sat, 7 Apr 2001 10:07:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f37H66K9003538 for ; Sat, 7 Apr 2001 10:06:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f37H65gY003537 for mobile-ip-dist; Sat, 7 Apr 2001 10:06:05 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f37H5pK9003530 for ; Sat, 7 Apr 2001 10:05:51 -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 KAA13308 for ; Sat, 7 Apr 2001 10:05:51 -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 LAA20218 for ; Sat, 7 Apr 2001 11:05:49 -0600 (MDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f37H5ms09302 for ; Sat, 7 Apr 2001 19:05:48 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id TAA02418; Sat, 7 Apr 2001 19:05:46 +0200 Message-ID: <3ACF32BB.C71333A9@era.ericsson.se> Date: Sat, 07 Apr 2001 17:31:07 +0200 From: Mattias Pettersson X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6 References: <3ACDBFC1.F3E5121A@inrialpes.fr> <15053.58913.722549.842387@thomasm-u1.cisco.com> <3ACDEAB3.9E5ABDE9@inrialpes.fr> <3ACE016F.C744FDA5@cs.ucl.ac.uk> 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 Theo Pagtzis wrote: > > Thierry, > > Having looked in detail the issue of mobile routers in HMIP > [...] > Now when the MR is moving as the PoA for an aircraft and its nodes > inside, what would happen is that the interface attaching to the world > will obtain a CoA. I fully agree. > > Now that CoA has a prefix. This prefix most probably complies with the > prefix aggregation scheme of IPv6 for that domain. Sure. > > That implies to me that when an MR attaches to a new PoA it must trigger > RENUMBERING to its all of the rest of its interfaces (excluding the one > that got the CoA). The reason? all interfaces must comply with the same > prefix; otherwise the border router will not know how to route packets > to the old prefix, which by the way would routed by the OLD border > router. > > That implies to me that : > > movement of the MR will trigger network renumbering for all > attached subnets behind that MR simply because of the router/prefix > aggregation requirement. This is by the way one of the strong points of > IPv6 for network renumbering per domain. I fear that you go slightly too fast here. Before we move on, if we discuss further along this line, the MR needs a topologically correct prefix for the mobile network it is serving. I guess we both agree on that. Since the COA for the upper interface of the MR belongs to P1 (in accordance to Thierry's earlier figure) and P1 has prefix length (usually /64), MR needs a new prefix to use for the mobile network. This requires prefix delegation, e.g. draft-haberman-ipngwg-auto-prefix-00.txt. In this way, MR can get all the prefixes it needs for the mobile networks it is serving. Next it needs to run a routing protocol between itself and the delegating router so that packets can reach the nodes behind the MR, this is also mentioned in the draft above. Hopefully, if the MR moves within one domain for a while, and moves between ARs that all belong to the same aggregated prefix (NLA or whatever), it could keep on using the same delegated prefix(es) for the entire stay in this domain. This assumes that the domain runs some internal routing protocol. Whenever the MR moves to a new AR, it will keep the prefixes it got earlier, but it will propagate routing updates for the delegated prefixes to all routers within the domain. This will not be significantly heavier on the internal routing since there is no or little aggregation within one domain, and if there is, punching holes in routing tables like this is no big deal as long as the number of prefixes used in the domain isn't huge. Ok, now the MR can go on and initiate renumbering of the mobile networks it serves. > > The renumbering to the attached subnets under the MR, will also > trigger a change of the current CoA for all hosts (fixed or mobile > inside the vehicle). That will bring the entire branch (vehicle) inline > with the prefix of the visiting domain of the MR. That means to me that > a movement of an MR will diffuse as a ghost movement of an host > underneath it. > > Movement of the MR in effect triggers a ghost handoff of the MN. Why > ghost? The host did not move a single bit but had to change its prefix. > The semantics of the BU are not decoupling movement of a MN from > movement of the whole domain (or subdomain which in this case is a > vehicle). The BU sent out will signal the change of the previous (p)CoA > to a new (n)CoA. As such for the CNs this will look like a movement of > the MN. > > To this point I would like to differentiate between two dimensions of > movement. > > 1) apparent (what I have discussed above) > 2) actual (the MN does decide to move within the aircraft/spaceship > (see babylon 5 :) here things complicate a lot. This is so because as if > the renumbering was not enough, the MN will have to send an extra BU per > actual local movement. Here a hierarchical scheme should save the > day...(I am studying which) > > The question that remains here is > > 1) is renumbering fast enough to effect the semantics of a handoff > (that is potentially seamless). If not, renumbering will bring us to > square one for seamlessness... > 2) an MN has no direct means of discovering that a net renumbering > is required so that it can solicit and as a result speed it up. So if we > rely on timeouts and intervals here the handoff is not that fast... > I'm afraid it will be trickier to move seamless for every new feature we want to add to Mobile IP. > Instead of renumbering I would like to ask whether it is possible to ask > the routing engine on the border router to transfer routing state for > the attached subnets under the MR. Would that mean effectively host > routes for the MR (implicit for the subnets underneath it?). > > >From the perspective of route/prefix aggregation this should go > immediately down the drain in my view but I wanted to erify that with > someone before excluding it from the solution space. The reason is that > for transient routind state (the vehichle and thus MR, will move soon to > another domain so what is the point to aggregate here ..) (yes we want > to shrink the routing table, but we could allow for a temporal > inflation..couldn't we) Please see my comments above. Mobility is statistically quite local, so I guess it's fair to assume that the MR probably stays within the domain next time it moves. /Mattias From owner-mobile-ip@sunroof.eng.sun.com Sat Apr 7 13:09:14 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16377 for ; Sat, 7 Apr 2001 13:09: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 KAA14334; Sat, 7 Apr 2001 10:09: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 KAA03649; Sat, 7 Apr 2001 10:09:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f37H7SK9003604 for ; Sat, 7 Apr 2001 10:07:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f37H7RW9003603 for mobile-ip-dist; Sat, 7 Apr 2001 10:07:27 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f37H7EK9003593 for ; Sat, 7 Apr 2001 10:07:14 -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 KAA11614 for ; Sat, 7 Apr 2001 10:07:14 -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 LAA20686 for ; Sat, 7 Apr 2001 11:07:12 -0600 (MDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f37H7Bs09627 for ; Sat, 7 Apr 2001 19:07:11 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id TAA02495; Sat, 7 Apr 2001 19:07:09 +0200 Message-ID: <3ACF32BB.C71333A9@era.ericsson.se> Date: Sat, 07 Apr 2001 17:31:07 +0200 From: Mattias Pettersson X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6 References: <3ACDBFC1.F3E5121A@inrialpes.fr> <15053.58913.722549.842387@thomasm-u1.cisco.com> <3ACDEAB3.9E5ABDE9@inrialpes.fr> <3ACE016F.C744FDA5@cs.ucl.ac.uk> 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 Theo Pagtzis wrote: > > Thierry, > > Having looked in detail the issue of mobile routers in HMIP > [...] > Now when the MR is moving as the PoA for an aircraft and its nodes > inside, what would happen is that the interface attaching to the world > will obtain a CoA. I fully agree. > > Now that CoA has a prefix. This prefix most probably complies with the > prefix aggregation scheme of IPv6 for that domain. Sure. > > That implies to me that when an MR attaches to a new PoA it must trigger > RENUMBERING to its all of the rest of its interfaces (excluding the one > that got the CoA). The reason? all interfaces must comply with the same > prefix; otherwise the border router will not know how to route packets > to the old prefix, which by the way would routed by the OLD border > router. > > That implies to me that : > > movement of the MR will trigger network renumbering for all > attached subnets behind that MR simply because of the router/prefix > aggregation requirement. This is by the way one of the strong points of > IPv6 for network renumbering per domain. I fear that you go slightly too fast here. Before we move on, if we discuss further along this line, the MR needs a topologically correct prefix for the mobile network it is serving. I guess we both agree on that. Since the COA for the upper interface of the MR belongs to P1 (in accordance to Thierry's earlier figure) and P1 has prefix length (usually /64), MR needs a new prefix to use for the mobile network. This requires prefix delegation, e.g. draft-haberman-ipngwg-auto-prefix-00.txt. In this way, MR can get all the prefixes it needs for the mobile networks it is serving. Next it needs to run a routing protocol between itself and the delegating router so that packets can reach the nodes behind the MR, this is also mentioned in the draft above. Hopefully, if the MR moves within one domain for a while, and moves between ARs that all belong to the same aggregated prefix (NLA or whatever), it could keep on using the same delegated prefix(es) for the entire stay in this domain. This assumes that the domain runs some internal routing protocol. Whenever the MR moves to a new AR, it will keep the prefixes it got earlier, but it will propagate routing updates for the delegated prefixes to all routers within the domain. This will not be significantly heavier on the internal routing since there is no or little aggregation within one domain, and if there is, punching holes in routing tables like this is no big deal as long as the number of prefixes used in the domain isn't huge. Ok, now the MR can go on and initiate renumbering of the mobile networks it serves. > > The renumbering to the attached subnets under the MR, will also > trigger a change of the current CoA for all hosts (fixed or mobile > inside the vehicle). That will bring the entire branch (vehicle) inline > with the prefix of the visiting domain of the MR. That means to me that > a movement of an MR will diffuse as a ghost movement of an host > underneath it. > > Movement of the MR in effect triggers a ghost handoff of the MN. Why > ghost? The host did not move a single bit but had to change its prefix. > The semantics of the BU are not decoupling movement of a MN from > movement of the whole domain (or subdomain which in this case is a > vehicle). The BU sent out will signal the change of the previous (p)CoA > to a new (n)CoA. As such for the CNs this will look like a movement of > the MN. > > To this point I would like to differentiate between two dimensions of > movement. > > 1) apparent (what I have discussed above) > 2) actual (the MN does decide to move within the aircraft/spaceship > (see babylon 5 :) here things complicate a lot. This is so because as if > the renumbering was not enough, the MN will have to send an extra BU per > actual local movement. Here a hierarchical scheme should save the > day...(I am studying which) > > The question that remains here is > > 1) is renumbering fast enough to effect the semantics of a handoff > (that is potentially seamless). If not, renumbering will bring us to > square one for seamlessness... > 2) an MN has no direct means of discovering that a net renumbering > is required so that it can solicit and as a result speed it up. So if we > rely on timeouts and intervals here the handoff is not that fast... > I'm afraid it will be trickier to move seamless for every new feature we want to add to Mobile IP. > Instead of renumbering I would like to ask whether it is possible to ask > the routing engine on the border router to transfer routing state for > the attached subnets under the MR. Would that mean effectively host > routes for the MR (implicit for the subnets underneath it?). > > >From the perspective of route/prefix aggregation this should go > immediately down the drain in my view but I wanted to erify that with > someone before excluding it from the solution space. The reason is that > for transient routind state (the vehichle and thus MR, will move soon to > another domain so what is the point to aggregate here ..) (yes we want > to shrink the routing table, but we could allow for a temporal > inflation..couldn't we) Please see my comments above. Mobility is statistically quite local, so I guess it's fair to assume that the MR probably stays within the domain next time it moves. /Mattias From owner-mobile-ip@sunroof.eng.sun.com Sat Apr 7 13:11:17 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16411 for ; Sat, 7 Apr 2001 13:11:16 -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 KAA14685; Sat, 7 Apr 2001 10:10: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 KAA13732; Sat, 7 Apr 2001 10:10:41 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f37H93K9003675 for ; Sat, 7 Apr 2001 10:09:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f37H92Mt003672 for mobile-ip-dist; Sat, 7 Apr 2001 10:09: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f37H8kK9003652 for ; Sat, 7 Apr 2001 10:08:46 -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 KAA03621 for ; Sat, 7 Apr 2001 10:08:46 -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 KAA00374 for ; Sat, 7 Apr 2001 10:08:44 -0700 (PDT) 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 f37H8hI26645 for ; Sat, 7 Apr 2001 19:08:44 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id TAA02523; Sat, 7 Apr 2001 19:08:42 +0200 Message-ID: <3ACF32BB.C71333A9@era.ericsson.se> Date: Sat, 07 Apr 2001 17:31:07 +0200 From: Mattias Pettersson X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6 References: <3ACDBFC1.F3E5121A@inrialpes.fr> <15053.58913.722549.842387@thomasm-u1.cisco.com> <3ACDEAB3.9E5ABDE9@inrialpes.fr> <3ACE016F.C744FDA5@cs.ucl.ac.uk> 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 Theo Pagtzis wrote: > > Thierry, > > Having looked in detail the issue of mobile routers in HMIP > [...] > Now when the MR is moving as the PoA for an aircraft and its nodes > inside, what would happen is that the interface attaching to the world > will obtain a CoA. I fully agree. > > Now that CoA has a prefix. This prefix most probably complies with the > prefix aggregation scheme of IPv6 for that domain. Sure. > > That implies to me that when an MR attaches to a new PoA it must trigger > RENUMBERING to its all of the rest of its interfaces (excluding the one > that got the CoA). The reason? all interfaces must comply with the same > prefix; otherwise the border router will not know how to route packets > to the old prefix, which by the way would routed by the OLD border > router. > > That implies to me that : > > movement of the MR will trigger network renumbering for all > attached subnets behind that MR simply because of the router/prefix > aggregation requirement. This is by the way one of the strong points of > IPv6 for network renumbering per domain. I fear that you go slightly too fast here. Before we move on, if we discuss further along this line, the MR needs a topologically correct prefix for the mobile network it is serving. I guess we both agree on that. Since the COA for the upper interface of the MR belongs to P1 (in accordance to Thierry's earlier figure) and P1 has prefix length (usually /64), MR needs a new prefix to use for the mobile network. This requires prefix delegation, e.g. draft-haberman-ipngwg-auto-prefix-00.txt. In this way, MR can get all the prefixes it needs for the mobile networks it is serving. Next it needs to run a routing protocol between itself and the delegating router so that packets can reach the nodes behind the MR, this is also mentioned in the draft above. Hopefully, if the MR moves within one domain for a while, and moves between ARs that all belong to the same aggregated prefix (NLA or whatever), it could keep on using the same delegated prefix(es) for the entire stay in this domain. This assumes that the domain runs some internal routing protocol. Whenever the MR moves to a new AR, it will keep the prefixes it got earlier, but it will propagate routing updates for the delegated prefixes to all routers within the domain. This will not be significantly heavier on the internal routing since there is no or little aggregation within one domain, and if there is, punching holes in routing tables like this is no big deal as long as the number of prefixes used in the domain isn't huge. Ok, now the MR can go on and initiate renumbering of the mobile networks it serves. > > The renumbering to the attached subnets under the MR, will also > trigger a change of the current CoA for all hosts (fixed or mobile > inside the vehicle). That will bring the entire branch (vehicle) inline > with the prefix of the visiting domain of the MR. That means to me that > a movement of an MR will diffuse as a ghost movement of an host > underneath it. > > Movement of the MR in effect triggers a ghost handoff of the MN. Why > ghost? The host did not move a single bit but had to change its prefix. > The semantics of the BU are not decoupling movement of a MN from > movement of the whole domain (or subdomain which in this case is a > vehicle). The BU sent out will signal the change of the previous (p)CoA > to a new (n)CoA. As such for the CNs this will look like a movement of > the MN. > > To this point I would like to differentiate between two dimensions of > movement. > > 1) apparent (what I have discussed above) > 2) actual (the MN does decide to move within the aircraft/spaceship > (see babylon 5 :) here things complicate a lot. This is so because as if > the renumbering was not enough, the MN will have to send an extra BU per > actual local movement. Here a hierarchical scheme should save the > day...(I am studying which) > > The question that remains here is > > 1) is renumbering fast enough to effect the semantics of a handoff > (that is potentially seamless). If not, renumbering will bring us to > square one for seamlessness... > 2) an MN has no direct means of discovering that a net renumbering > is required so that it can solicit and as a result speed it up. So if we > rely on timeouts and intervals here the handoff is not that fast... > I'm afraid it will be trickier to move seamless for every new feature we want to add to Mobile IP. > Instead of renumbering I would like to ask whether it is possible to ask > the routing engine on the border router to transfer routing state for > the attached subnets under the MR. Would that mean effectively host > routes for the MR (implicit for the subnets underneath it?). > > >From the perspective of route/prefix aggregation this should go > immediately down the drain in my view but I wanted to erify that with > someone before excluding it from the solution space. The reason is that > for transient routind state (the vehichle and thus MR, will move soon to > another domain so what is the point to aggregate here ..) (yes we want > to shrink the routing table, but we could allow for a temporal > inflation..couldn't we) Please see my comments above. Mobility is statistically quite local, so I guess it's fair to assume that the MR probably stays within the domain next time it moves. /Mattias From owner-mobile-ip@sunroof.eng.sun.com Sat Apr 7 13:12:39 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16449 for ; Sat, 7 Apr 2001 13:12:39 -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 KAA20495; Sat, 7 Apr 2001 10:11:20 -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 KAA11887; Sat, 7 Apr 2001 10:11:17 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f37H9kK9003713 for ; Sat, 7 Apr 2001 10:09:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f37H9j9V003712 for mobile-ip-dist; Sat, 7 Apr 2001 10:09: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f37H9LK9003685 for ; Sat, 7 Apr 2001 10:09: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 KAA03666 for ; Sat, 7 Apr 2001 10:09:21 -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 KAA24760 for ; Sat, 7 Apr 2001 10:09:18 -0700 (PDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f37H9Hs10009 for ; Sat, 7 Apr 2001 19:09:17 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id TAA02558; Sat, 7 Apr 2001 19:09:16 +0200 Message-ID: <3ACF32BB.C71333A9@era.ericsson.se> Date: Sat, 07 Apr 2001 17:31:07 +0200 From: Mattias Pettersson X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6 References: <3ACDBFC1.F3E5121A@inrialpes.fr> <15053.58913.722549.842387@thomasm-u1.cisco.com> <3ACDEAB3.9E5ABDE9@inrialpes.fr> <3ACE016F.C744FDA5@cs.ucl.ac.uk> 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 Theo Pagtzis wrote: > > Thierry, > > Having looked in detail the issue of mobile routers in HMIP > [...] > Now when the MR is moving as the PoA for an aircraft and its nodes > inside, what would happen is that the interface attaching to the world > will obtain a CoA. I fully agree. > > Now that CoA has a prefix. This prefix most probably complies with the > prefix aggregation scheme of IPv6 for that domain. Sure. > > That implies to me that when an MR attaches to a new PoA it must trigger > RENUMBERING to its all of the rest of its interfaces (excluding the one > that got the CoA). The reason? all interfaces must comply with the same > prefix; otherwise the border router will not know how to route packets > to the old prefix, which by the way would routed by the OLD border > router. > > That implies to me that : > > movement of the MR will trigger network renumbering for all > attached subnets behind that MR simply because of the router/prefix > aggregation requirement. This is by the way one of the strong points of > IPv6 for network renumbering per domain. I fear that you go slightly too fast here. Before we move on, if we discuss further along this line, the MR needs a topologically correct prefix for the mobile network it is serving. I guess we both agree on that. Since the COA for the upper interface of the MR belongs to P1 (in accordance to Thierry's earlier figure) and P1 has prefix length (usually /64), MR needs a new prefix to use for the mobile network. This requires prefix delegation, e.g. draft-haberman-ipngwg-auto-prefix-00.txt. In this way, MR can get all the prefixes it needs for the mobile networks it is serving. Next it needs to run a routing protocol between itself and the delegating router so that packets can reach the nodes behind the MR, this is also mentioned in the draft above. Hopefully, if the MR moves within one domain for a while, and moves between ARs that all belong to the same aggregated prefix (NLA or whatever), it could keep on using the same delegated prefix(es) for the entire stay in this domain. This assumes that the domain runs some internal routing protocol. Whenever the MR moves to a new AR, it will keep the prefixes it got earlier, but it will propagate routing updates for the delegated prefixes to all routers within the domain. This will not be significantly heavier on the internal routing since there is no or little aggregation within one domain, and if there is, punching holes in routing tables like this is no big deal as long as the number of prefixes used in the domain isn't huge. Ok, now the MR can go on and initiate renumbering of the mobile networks it serves. > > The renumbering to the attached subnets under the MR, will also > trigger a change of the current CoA for all hosts (fixed or mobile > inside the vehicle). That will bring the entire branch (vehicle) inline > with the prefix of the visiting domain of the MR. That means to me that > a movement of an MR will diffuse as a ghost movement of an host > underneath it. > > Movement of the MR in effect triggers a ghost handoff of the MN. Why > ghost? The host did not move a single bit but had to change its prefix. > The semantics of the BU are not decoupling movement of a MN from > movement of the whole domain (or subdomain which in this case is a > vehicle). The BU sent out will signal the change of the previous (p)CoA > to a new (n)CoA. As such for the CNs this will look like a movement of > the MN. > > To this point I would like to differentiate between two dimensions of > movement. > > 1) apparent (what I have discussed above) > 2) actual (the MN does decide to move within the aircraft/spaceship > (see babylon 5 :) here things complicate a lot. This is so because as if > the renumbering was not enough, the MN will have to send an extra BU per > actual local movement. Here a hierarchical scheme should save the > day...(I am studying which) > > The question that remains here is > > 1) is renumbering fast enough to effect the semantics of a handoff > (that is potentially seamless). If not, renumbering will bring us to > square one for seamlessness... > 2) an MN has no direct means of discovering that a net renumbering > is required so that it can solicit and as a result speed it up. So if we > rely on timeouts and intervals here the handoff is not that fast... > I'm afraid it will be trickier to move seamless for every new feature we want to add to Mobile IP. > Instead of renumbering I would like to ask whether it is possible to ask > the routing engine on the border router to transfer routing state for > the attached subnets under the MR. Would that mean effectively host > routes for the MR (implicit for the subnets underneath it?). > > >From the perspective of route/prefix aggregation this should go > immediately down the drain in my view but I wanted to erify that with > someone before excluding it from the solution space. The reason is that > for transient routind state (the vehichle and thus MR, will move soon to > another domain so what is the point to aggregate here ..) (yes we want > to shrink the routing table, but we could allow for a temporal > inflation..couldn't we) Please see my comments above. Mobility is statistically quite local, so I guess it's fair to assume that the MR probably stays within the domain next time it moves. /Mattias From owner-mobile-ip@sunroof.eng.sun.com Sat Apr 7 13:16:03 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16500 for ; Sat, 7 Apr 2001 13:16:03 -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 KAA21085; Sat, 7 Apr 2001 10:16: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 KAA12239; Sat, 7 Apr 2001 10:15:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f37HDhK9003887 for ; Sat, 7 Apr 2001 10:13:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f37HDhfF003886 for mobile-ip-dist; Sat, 7 Apr 2001 10:13:43 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f37HDYK9003879 for ; Sat, 7 Apr 2001 10:13:34 -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 KAA12064 for ; Sat, 7 Apr 2001 10:13:33 -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 KAA15398 for ; Sat, 7 Apr 2001 10:13:32 -0700 (PDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f37HDVs11194 for ; Sat, 7 Apr 2001 19:13:31 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id TAA02710; Sat, 7 Apr 2001 19:13:29 +0200 Message-ID: <3ACF32BB.C71333A9@era.ericsson.se> Date: Sat, 07 Apr 2001 17:31:07 +0200 From: Mattias Pettersson X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6 References: <3ACDBFC1.F3E5121A@inrialpes.fr> <15053.58913.722549.842387@thomasm-u1.cisco.com> <3ACDEAB3.9E5ABDE9@inrialpes.fr> <3ACE016F.C744FDA5@cs.ucl.ac.uk> 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 Theo Pagtzis wrote: > > Thierry, > > Having looked in detail the issue of mobile routers in HMIP > [...] > Now when the MR is moving as the PoA for an aircraft and its nodes > inside, what would happen is that the interface attaching to the world > will obtain a CoA. I fully agree. > > Now that CoA has a prefix. This prefix most probably complies with the > prefix aggregation scheme of IPv6 for that domain. Sure. > > That implies to me that when an MR attaches to a new PoA it must trigger > RENUMBERING to its all of the rest of its interfaces (excluding the one > that got the CoA). The reason? all interfaces must comply with the same > prefix; otherwise the border router will not know how to route packets > to the old prefix, which by the way would routed by the OLD border > router. > > That implies to me that : > > movement of the MR will trigger network renumbering for all > attached subnets behind that MR simply because of the router/prefix > aggregation requirement. This is by the way one of the strong points of > IPv6 for network renumbering per domain. I fear that you go slightly too fast here. Before we move on, if we discuss further along this line, the MR needs a topologically correct prefix for the mobile network it is serving. I guess we both agree on that. Since the COA for the upper interface of the MR belongs to P1 (in accordance to Thierry's earlier figure) and P1 has prefix length (usually /64), MR needs a new prefix to use for the mobile network. This requires prefix delegation, e.g. draft-haberman-ipngwg-auto-prefix-00.txt. In this way, MR can get all the prefixes it needs for the mobile networks it is serving. Next it needs to run a routing protocol between itself and the delegating router so that packets can reach the nodes behind the MR, this is also mentioned in the draft above. Hopefully, if the MR moves within one domain for a while, and moves between ARs that all belong to the same aggregated prefix (NLA or whatever), it could keep on using the same delegated prefix(es) for the entire stay in this domain. This assumes that the domain runs some internal routing protocol. Whenever the MR moves to a new AR, it will keep the prefixes it got earlier, but it will propagate routing updates for the delegated prefixes to all routers within the domain. This will not be significantly heavier on the internal routing since there is no or little aggregation within one domain, and if there is, punching holes in routing tables like this is no big deal as long as the number of prefixes used in the domain isn't huge. Ok, now the MR can go on and initiate renumbering of the mobile networks it serves. > > The renumbering to the attached subnets under the MR, will also > trigger a change of the current CoA for all hosts (fixed or mobile > inside the vehicle). That will bring the entire branch (vehicle) inline > with the prefix of the visiting domain of the MR. That means to me that > a movement of an MR will diffuse as a ghost movement of an host > underneath it. > > Movement of the MR in effect triggers a ghost handoff of the MN. Why > ghost? The host did not move a single bit but had to change its prefix. > The semantics of the BU are not decoupling movement of a MN from > movement of the whole domain (or subdomain which in this case is a > vehicle). The BU sent out will signal the change of the previous (p)CoA > to a new (n)CoA. As such for the CNs this will look like a movement of > the MN. > > To this point I would like to differentiate between two dimensions of > movement. > > 1) apparent (what I have discussed above) > 2) actual (the MN does decide to move within the aircraft/spaceship > (see babylon 5 :) here things complicate a lot. This is so because as if > the renumbering was not enough, the MN will have to send an extra BU per > actual local movement. Here a hierarchical scheme should save the > day...(I am studying which) > > The question that remains here is > > 1) is renumbering fast enough to effect the semantics of a handoff > (that is potentially seamless). If not, renumbering will bring us to > square one for seamlessness... > 2) an MN has no direct means of discovering that a net renumbering > is required so that it can solicit and as a result speed it up. So if we > rely on timeouts and intervals here the handoff is not that fast... > I'm afraid it will be trickier to move seamless for every new feature we want to add to Mobile IP. > Instead of renumbering I would like to ask whether it is possible to ask > the routing engine on the border router to transfer routing state for > the attached subnets under the MR. Would that mean effectively host > routes for the MR (implicit for the subnets underneath it?). > > >From the perspective of route/prefix aggregation this should go > immediately down the drain in my view but I wanted to erify that with > someone before excluding it from the solution space. The reason is that > for transient routind state (the vehichle and thus MR, will move soon to > another domain so what is the point to aggregate here ..) (yes we want > to shrink the routing table, but we could allow for a temporal > inflation..couldn't we) Please see my comments above. Mobility is statistically quite local, so I guess it's fair to assume that the MR probably stays within the domain next time it moves. /Mattias From owner-mobile-ip@sunroof.eng.sun.com Sat Apr 7 13:17:10 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16543 for ; Sat, 7 Apr 2001 13:17: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 KAA16082; Sat, 7 Apr 2001 10:17:09 -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 KAA12344; Sat, 7 Apr 2001 10:17:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f37HFnK9003903 for ; Sat, 7 Apr 2001 10:15:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f37HFmkJ003902 for mobile-ip-dist; Sat, 7 Apr 2001 10:15: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f37HFTK9003895 for ; Sat, 7 Apr 2001 10:15:39 -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 KAA04213 for ; Sat, 7 Apr 2001 10:15:29 -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 KAA01462 for ; Sat, 7 Apr 2001 10:15:28 -0700 (PDT) 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 f37HFQI28410 for ; Sat, 7 Apr 2001 19:15:27 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id TAA02746; Sat, 7 Apr 2001 19:15:25 +0200 Message-ID: <3ACF32BB.C71333A9@era.ericsson.se> Date: Sat, 07 Apr 2001 17:31:07 +0200 From: Mattias Pettersson X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6 References: <3ACDBFC1.F3E5121A@inrialpes.fr> <15053.58913.722549.842387@thomasm-u1.cisco.com> <3ACDEAB3.9E5ABDE9@inrialpes.fr> <3ACE016F.C744FDA5@cs.ucl.ac.uk> 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 Theo Pagtzis wrote: > > Thierry, > > Having looked in detail the issue of mobile routers in HMIP > [...] > Now when the MR is moving as the PoA for an aircraft and its nodes > inside, what would happen is that the interface attaching to the world > will obtain a CoA. I fully agree. > > Now that CoA has a prefix. This prefix most probably complies with the > prefix aggregation scheme of IPv6 for that domain. Sure. > > That implies to me that when an MR attaches to a new PoA it must trigger > RENUMBERING to its all of the rest of its interfaces (excluding the one > that got the CoA). The reason? all interfaces must comply with the same > prefix; otherwise the border router will not know how to route packets > to the old prefix, which by the way would routed by the OLD border > router. > > That implies to me that : > > movement of the MR will trigger network renumbering for all > attached subnets behind that MR simply because of the router/prefix > aggregation requirement. This is by the way one of the strong points of > IPv6 for network renumbering per domain. I fear that you go slightly too fast here. Before we move on, if we discuss further along this line, the MR needs a topologically correct prefix for the mobile network it is serving. I guess we both agree on that. Since the COA for the upper interface of the MR belongs to P1 (in accordance to Thierry's earlier figure) and P1 has prefix length (usually /64), MR needs a new prefix to use for the mobile network. This requires prefix delegation, e.g. draft-haberman-ipngwg-auto-prefix-00.txt. In this way, MR can get all the prefixes it needs for the mobile networks it is serving. Next it needs to run a routing protocol between itself and the delegating router so that packets can reach the nodes behind the MR, this is also mentioned in the draft above. Hopefully, if the MR moves within one domain for a while, and moves between ARs that all belong to the same aggregated prefix (NLA or whatever), it could keep on using the same delegated prefix(es) for the entire stay in this domain. This assumes that the domain runs some internal routing protocol. Whenever the MR moves to a new AR, it will keep the prefixes it got earlier, but it will propagate routing updates for the delegated prefixes to all routers within the domain. This will not be significantly heavier on the internal routing since there is no or little aggregation within one domain, and if there is, punching holes in routing tables like this is no big deal as long as the number of prefixes used in the domain isn't huge. Ok, now the MR can go on and initiate renumbering of the mobile networks it serves. > > The renumbering to the attached subnets under the MR, will also > trigger a change of the current CoA for all hosts (fixed or mobile > inside the vehicle). That will bring the entire branch (vehicle) inline > with the prefix of the visiting domain of the MR. That means to me that > a movement of an MR will diffuse as a ghost movement of an host > underneath it. > > Movement of the MR in effect triggers a ghost handoff of the MN. Why > ghost? The host did not move a single bit but had to change its prefix. > The semantics of the BU are not decoupling movement of a MN from > movement of the whole domain (or subdomain which in this case is a > vehicle). The BU sent out will signal the change of the previous (p)CoA > to a new (n)CoA. As such for the CNs this will look like a movement of > the MN. > > To this point I would like to differentiate between two dimensions of > movement. > > 1) apparent (what I have discussed above) > 2) actual (the MN does decide to move within the aircraft/spaceship > (see babylon 5 :) here things complicate a lot. This is so because as if > the renumbering was not enough, the MN will have to send an extra BU per > actual local movement. Here a hierarchical scheme should save the > day...(I am studying which) > > The question that remains here is > > 1) is renumbering fast enough to effect the semantics of a handoff > (that is potentially seamless). If not, renumbering will bring us to > square one for seamlessness... > 2) an MN has no direct means of discovering that a net renumbering > is required so that it can solicit and as a result speed it up. So if we > rely on timeouts and intervals here the handoff is not that fast... > I'm afraid it will be trickier to move seamless for every new feature we want to add to Mobile IP. > Instead of renumbering I would like to ask whether it is possible to ask > the routing engine on the border router to transfer routing state for > the attached subnets under the MR. Would that mean effectively host > routes for the MR (implicit for the subnets underneath it?). > > >From the perspective of route/prefix aggregation this should go > immediately down the drain in my view but I wanted to erify that with > someone before excluding it from the solution space. The reason is that > for transient routind state (the vehichle and thus MR, will move soon to > another domain so what is the point to aggregate here ..) (yes we want > to shrink the routing table, but we could allow for a temporal > inflation..couldn't we) Please see my comments above. Mobility is statistically quite local, so I guess it's fair to assume that the MR probably stays within the domain next time it moves. /Mattias From owner-mobile-ip@sunroof.eng.sun.com Sat Apr 7 13:19:56 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16610 for ; Sat, 7 Apr 2001 13:19: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 KAA16733; Sat, 7 Apr 2001 10:19: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 KAA04599; Sat, 7 Apr 2001 10:19:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f37HI1K9003987 for ; Sat, 7 Apr 2001 10:18:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f37HI1ea003986 for mobile-ip-dist; Sat, 7 Apr 2001 10:18: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f37HHpK9003976 for ; Sat, 7 Apr 2001 10:17:51 -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 KAA17792 for ; Sat, 7 Apr 2001 10:17:51 -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 KAA16284 for ; Sat, 7 Apr 2001 10:17:50 -0700 (PDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f37HHns12169 for ; Sat, 7 Apr 2001 19:17:49 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id TAA02834; Sat, 7 Apr 2001 19:17:47 +0200 Message-ID: <3ACF32BB.C71333A9@era.ericsson.se> Date: Sat, 07 Apr 2001 17:31:07 +0200 From: Mattias Pettersson X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6 References: <3ACDBFC1.F3E5121A@inrialpes.fr> <15053.58913.722549.842387@thomasm-u1.cisco.com> <3ACDEAB3.9E5ABDE9@inrialpes.fr> <3ACE016F.C744FDA5@cs.ucl.ac.uk> 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 Theo Pagtzis wrote: > > Thierry, > > Having looked in detail the issue of mobile routers in HMIP > [...] > Now when the MR is moving as the PoA for an aircraft and its nodes > inside, what would happen is that the interface attaching to the world > will obtain a CoA. I fully agree. > > Now that CoA has a prefix. This prefix most probably complies with the > prefix aggregation scheme of IPv6 for that domain. Sure. > > That implies to me that when an MR attaches to a new PoA it must trigger > RENUMBERING to its all of the rest of its interfaces (excluding the one > that got the CoA). The reason? all interfaces must comply with the same > prefix; otherwise the border router will not know how to route packets > to the old prefix, which by the way would routed by the OLD border > router. > > That implies to me that : > > movement of the MR will trigger network renumbering for all > attached subnets behind that MR simply because of the router/prefix > aggregation requirement. This is by the way one of the strong points of > IPv6 for network renumbering per domain. I fear that you go slightly too fast here. Before we move on, if we discuss further along this line, the MR needs a topologically correct prefix for the mobile network it is serving. I guess we both agree on that. Since the COA for the upper interface of the MR belongs to P1 (in accordance to Thierry's earlier figure) and P1 has prefix length (usually /64), MR needs a new prefix to use for the mobile network. This requires prefix delegation, e.g. draft-haberman-ipngwg-auto-prefix-00.txt. In this way, MR can get all the prefixes it needs for the mobile networks it is serving. Next it needs to run a routing protocol between itself and the delegating router so that packets can reach the nodes behind the MR, this is also mentioned in the draft above. Hopefully, if the MR moves within one domain for a while, and moves between ARs that all belong to the same aggregated prefix (NLA or whatever), it could keep on using the same delegated prefix(es) for the entire stay in this domain. This assumes that the domain runs some internal routing protocol. Whenever the MR moves to a new AR, it will keep the prefixes it got earlier, but it will propagate routing updates for the delegated prefixes to all routers within the domain. This will not be significantly heavier on the internal routing since there is no or little aggregation within one domain, and if there is, punching holes in routing tables like this is no big deal as long as the number of prefixes used in the domain isn't huge. Ok, now the MR can go on and initiate renumbering of the mobile networks it serves. > > The renumbering to the attached subnets under the MR, will also > trigger a change of the current CoA for all hosts (fixed or mobile > inside the vehicle). That will bring the entire branch (vehicle) inline > with the prefix of the visiting domain of the MR. That means to me that > a movement of an MR will diffuse as a ghost movement of an host > underneath it. > > Movement of the MR in effect triggers a ghost handoff of the MN. Why > ghost? The host did not move a single bit but had to change its prefix. > The semantics of the BU are not decoupling movement of a MN from > movement of the whole domain (or subdomain which in this case is a > vehicle). The BU sent out will signal the change of the previous (p)CoA > to a new (n)CoA. As such for the CNs this will look like a movement of > the MN. > > To this point I would like to differentiate between two dimensions of > movement. > > 1) apparent (what I have discussed above) > 2) actual (the MN does decide to move within the aircraft/spaceship > (see babylon 5 :) here things complicate a lot. This is so because as if > the renumbering was not enough, the MN will have to send an extra BU per > actual local movement. Here a hierarchical scheme should save the > day...(I am studying which) > > The question that remains here is > > 1) is renumbering fast enough to effect the semantics of a handoff > (that is potentially seamless). If not, renumbering will bring us to > square one for seamlessness... > 2) an MN has no direct means of discovering that a net renumbering > is required so that it can solicit and as a result speed it up. So if we > rely on timeouts and intervals here the handoff is not that fast... > I'm afraid it will be trickier to move seamless for every new feature we want to add to Mobile IP. > Instead of renumbering I would like to ask whether it is possible to ask > the routing engine on the border router to transfer routing state for > the attached subnets under the MR. Would that mean effectively host > routes for the MR (implicit for the subnets underneath it?). > > >From the perspective of route/prefix aggregation this should go > immediately down the drain in my view but I wanted to erify that with > someone before excluding it from the solution space. The reason is that > for transient routind state (the vehichle and thus MR, will move soon to > another domain so what is the point to aggregate here ..) (yes we want > to shrink the routing table, but we could allow for a temporal > inflation..couldn't we) Please see my comments above. Mobility is statistically quite local, so I guess it's fair to assume that the MR probably stays within the domain next time it moves. /Mattias From owner-mobile-ip@sunroof.eng.sun.com Sat Apr 7 13:23:21 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16650 for ; Sat, 7 Apr 2001 13:23: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 KAA17361; Sat, 7 Apr 2001 10:23: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 KAA12741; Sat, 7 Apr 2001 10:23:16 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f37HM0K9004086 for ; Sat, 7 Apr 2001 10:22:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f37HM0H9004085 for mobile-ip-dist; Sat, 7 Apr 2001 10:22: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f37HLmK9004069 for ; Sat, 7 Apr 2001 10:21:48 -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 KAA12663 for ; Sat, 7 Apr 2001 10:21:48 -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 LAA25468 for ; Sat, 7 Apr 2001 11:21:47 -0600 (MDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f37HLjs13225 for ; Sat, 7 Apr 2001 19:21:45 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id TAA02959; Sat, 7 Apr 2001 19:21:43 +0200 Message-ID: <3ACF4C7C.F253553B@era.ericsson.se> Date: Sat, 07 Apr 2001 19:21:00 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6 References: <200104032053.f33KriWI249954@jurassic.eng.sun.com> <3ACDBC66.AA6BB313@era.ericsson.se> <15053.61721.423033.904286@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: > > Mattias Pettersson writes: > > Mohan Parthasarathy wrote: > > > > > Do we really need another draft ? From the discussions we had, > > > it looked like some clarifications are sufficient. At least > > > the mail from Mattias explained this clearly i guess. > > > > I questioned if the MR must tell the HA what prefixes are behind the MR > > and mentioned that this must be known by the HA (and also the BRs) by > > other means (which we haven't figured out yet...). > > Mattias, > > Are you talking about prefixes that are not part > of the home subnet prefix the MR subtends? If > so, wouldn't that be handled by a normal routing > protocol like OSPF? First question - yes. Second question - yes, normal routing protocols would handle this fine when the MR is at home (attached to HA's link). But we still need to run routing protocols between MR and all routers on the home link, including the HA. The BUs plus "Mobile Network Prefix Sub-Option" in the mobile networks draft only update the HA, not all the other routers on the home link. So should we run routing protocols through a bi-directional tunnel between the HA and MR? Routing protocols usually assume or reqiure link-local addresses for the source and destination of the messages. Or should the HA act as a proxy router on behalf of the MR and send routing messages to the other routers on the home link in order to maintain routes to the mobile networks? Or do we only allow statically configured routes in the routers pointing out the mobile prefixes? What do you people prefer? > > > The MN still needs to tell CNs about the prefixes, so the draft makes > > sense. > > I think we need to be very careful here. What does > this mean from a security statndpoint? What > authorized this? This may be no different than the > current MIP situation, but I wouldn't count on > that without testing the assumption thoroughly. The HA must verify the MR requesting forwarding of the mobile prefixes so it knows it is the same MR as was at home. What kind of authorization do we use between routers on the home link? > > Also: does this mean that the MR needs to create > flow based information for the static hosts behind > it? That seems to be the implication. Will this > scale well for large MR's such as on a plane or > aircraft carriers? I don't follow you here. Can you explain a bit more? /Mattias From owner-mobile-ip@sunroof.eng.sun.com Sat Apr 7 13:25:18 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16689 for ; Sat, 7 Apr 2001 13:25:17 -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 KAA22146; Sat, 7 Apr 2001 10:24: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 KAA12821; Sat, 7 Apr 2001 10:24:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f37HMTK9004096 for ; Sat, 7 Apr 2001 10:22:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f37HMTh1004095 for mobile-ip-dist; Sat, 7 Apr 2001 10:22: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f37HMEK9004088 for ; Sat, 7 Apr 2001 10:22: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 KAA04717 for ; Sat, 7 Apr 2001 10:22:14 -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 KAA17160 for ; Sat, 7 Apr 2001 10:22:12 -0700 (PDT) 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 f37HMBI29777 for ; Sat, 7 Apr 2001 19:22:11 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id TAA02969; Sat, 7 Apr 2001 19:22:10 +0200 Message-ID: <3ACF40E5.70C548D@era.ericsson.se> Date: Sat, 07 Apr 2001 18:31:33 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6 References: <200104061648.f36GmeCq983767@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 Mohan Parthasarathy wrote: > > > > > Mohan Parthasarathy wrote: > > > > > Do we really need another draft ? From the discussions we had, > > > it looked like some clarifications are sufficient. At least > > > the mail from Mattias explained this clearly i guess. > > > > I questioned if the MR must tell the HA what prefixes are behind the MR > > and mentioned that this must be known by the HA (and also the BRs) by > > other means (which we haven't figured out yet...). > > > Are you saying the reachability advertised by the routing protocols > is not sufficient i.e how did it work when the MR was home ? Home > Agent is yet another router. Are we saying that tunneling the > reachability information is not optimal ? Sorry, I wasn't clear enough. I believe the MR shouldn't tell the HA about the mobile prefixes by _Mobile IPv6_ methods, but rather use standard routing protocol messages (OSPF, RIPng, etc.). We both mean the same thing. As I wrote in another message, one option is to tunnel the routing messages, if we can verify that it will work. The routing protocols were probably not designed with this perverted network architecture in mind... :) /Mattias From owner-mobile-ip@sunroof.eng.sun.com Sat Apr 7 13:26:39 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16715 for ; Sat, 7 Apr 2001 13:26: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 KAA17895; Sat, 7 Apr 2001 10:25: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 KAA14898; Sat, 7 Apr 2001 10:24:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f37HN9K9004113 for ; Sat, 7 Apr 2001 10:23:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f37HN8sc004110 for mobile-ip-dist; Sat, 7 Apr 2001 10:23: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f37HMnK9004101 for ; Sat, 7 Apr 2001 10:22:49 -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 KAA04754 for ; Sat, 7 Apr 2001 10:22:49 -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 KAA02453 for ; Sat, 7 Apr 2001 10:22:47 -0700 (PDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f37HMls13419 for ; Sat, 7 Apr 2001 19:22:47 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id TAA02972; Sat, 7 Apr 2001 19:22:46 +0200 Message-ID: <3ACF4CBB.A66ED1FD@era.ericsson.se> Date: Sat, 07 Apr 2001 19:22:03 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6 References: <200104061648.f36GmeCq983767@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 Mohan Parthasarathy wrote: > > > > > Mohan Parthasarathy wrote: > > > > > Do we really need another draft ? From the discussions we had, > > > it looked like some clarifications are sufficient. At least > > > the mail from Mattias explained this clearly i guess. > > > > I questioned if the MR must tell the HA what prefixes are behind the MR > > and mentioned that this must be known by the HA (and also the BRs) by > > other means (which we haven't figured out yet...). > > > Are you saying the reachability advertised by the routing protocols > is not sufficient i.e how did it work when the MR was home ? Home > Agent is yet another router. Are we saying that tunneling the > reachability information is not optimal ? Sorry, I wasn't clear enough. I believe the MR shouldn't tell the HA about the mobile prefixes by _Mobile IPv6_ methods, but rather use standard routing protocol messages (OSPF, RIPng, etc.). We both mean the same thing. As I wrote in another message, one option is to tunnel the routing messages, if we can verify that it will work. The routing protocols were probably not designed with this perverted network architecture in mind... :) /Mattias From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 03:17: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 DAA01248 for ; Mon, 9 Apr 2001 03:17:54 -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 AAA27827; Mon, 9 Apr 2001 00:15: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 AAA29734; Mon, 9 Apr 2001 00:15:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f397DoK9005803 for ; Mon, 9 Apr 2001 00:13:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f397Do9b005802 for mobile-ip-dist; Mon, 9 Apr 2001 00:13: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f397DfK9005795 for ; Mon, 9 Apr 2001 00:13:41 -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 AAA26503 for ; Mon, 9 Apr 2001 00:13:42 -0700 (PDT) Received: from mail.zrz.tu-berlin.de (mail.zrz.TU-Berlin.DE [130.149.4.15]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA02280 for ; Mon, 9 Apr 2001 00:13:40 -0700 (PDT) Received: from ftsu07.ee.tu-berlin.de ([130.149.49.87] helo=ftmail.ee.tu-berlin.de) by mail.zrz.tu-berlin.de with esmtp (exim-3.22) for id 14mVro-00048B-00; Mon, 09 Apr 2001 09:13:40 +0200 Received: from ee.tu-berlin.de (fu@sinope.ee.TU-Berlin.DE [130.149.49.127]) by ftmail.ee.tu-berlin.de (8.11.3/8.11.3) with ESMTP id f397Ddf08695 for ; Mon, 9 Apr 2001 09:13:40 +0200 Message-ID: <3AD16123.6F3E788B@ee.tu-berlin.de> Date: Mon, 09 Apr 2001 09:13:39 +0200 From: Xiaoming Fu Organization: TKN, TU-Berlin X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en-US, de, zh-CN MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Requirements Draft for Mobile IP QoS - Invitation to Volunteer References: 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 Count me in if possible, thanks! Xiaoming Fu Telecommunication Networks Group Technical University Berlin 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 From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 08:16:50 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03982 for ; Mon, 9 Apr 2001 08:16: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 FAA10301; Mon, 9 Apr 2001 05:14:57 -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 FAA23073; Mon, 9 Apr 2001 05:14:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39CDYK9006119 for ; Mon, 9 Apr 2001 05:13:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39CDY3N006118 for mobile-ip-dist; Mon, 9 Apr 2001 05:13:34 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39CDPK9006111 for ; Mon, 9 Apr 2001 05:13:25 -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 FAA19248 for ; Mon, 9 Apr 2001 05:13:23 -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 FAA14614 for ; Mon, 9 Apr 2001 05:13:22 -0700 (PDT) Received: from ridingwood.shef.ac.uk ([143.167.59.249]) by mailhub1.shef.ac.uk with esmtp (Exim 3.22 #2) id 14maXq-0000Bj-00 for mobile-ip@sunroof.eng.sun.com; Mon, 09 Apr 2001 13:13:22 +0100 Received: from RIDINGWOOD/SpoolDir by ridingwood.shef.ac.uk (Mercury 1.48); 9 Apr 01 13:13:23 +0100 Received: from SpoolDir by RIDINGWOOD (Mercury 1.48); 9 Apr 01 13:13:09 +0100 Received: from borg (143.167.251.52) by ridingwood.shef.ac.uk (Mercury 1.48); 9 Apr 01 13:13:01 +0100 Message-ID: <006a01c0c0ee$5942bfb0$34fba78f@borg> From: "cny" To: References: Subject: Re: [mobile-ip] Requirements Draft for Mobile IP QoS - Invitation to Volunteer Date: Mon, 9 Apr 2001 14:12:29 +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 Hemant May I know what is NSIS ???? I am quite interested in this as well. Cheers Chern Nam Yap cny@ieee.org ----- Original Message ----- From: "Hemant Chaskar" To: Sent: Thursday, April 05, 2001 9:47 PM Subject: [mobile-ip] Requirements Draft for Mobile IP QoS - Invitation to Volunteer > 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 > From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 09:19:57 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05845 for ; Mon, 9 Apr 2001 09:19:57 -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 GAA29549; Mon, 9 Apr 2001 06:17:37 -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 GAA24560; Mon, 9 Apr 2001 06:17:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39DEiK9006331 for ; Mon, 9 Apr 2001 06:14:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39DEiOE006330 for mobile-ip-dist; Mon, 9 Apr 2001 06:14: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39DEXK9006320 for ; Mon, 9 Apr 2001 06:14:34 -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 GAA27951 for ; Mon, 9 Apr 2001 06:13:31 -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 GAA19551 for ; Mon, 9 Apr 2001 06:13:29 -0700 (PDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Apr 2001 09:12:37 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'fu@ee.tu-berlin.de'" , "Shahrier, Sharif M." Cc: "'seamoby-context@cdma-2000.org'" , "Kiernan, Brian G." , "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] RE: FW: [seamoby-context] QoS specification for context Date: Mon, 9 Apr 2001 09:12:36 -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: Well actually, in a DiffServ environment the boundary nodes derive the service level and policing parameters from TCA (traffic condition agreement). The TCA in turn is obtained from the SLA ( Service Level Agreement) between the customer and the service provider. Thus, you are largely correct in your observation. Thanks. -----Original Message----- From: Xiaoming Fu [mailto:fu@ee.tu-berlin.de] Sent: Monday, April 09, 2001 5:25 AM To: Shahrier, Sharif M. Cc: 'seamoby-context@cdma-2000.org' Subject: Re: FW: [seamoby-context] QoS specification for context > -----Original Message----- > From: Shahrier, Sharif M. > Sent: Friday, April 06, 2001 3:25 PM > To: Shahrier, Sharif M.; Kiernan, Brian G. > Cc: seamoby-context@cdma-2000.org > Subject: RE: [seamoby-context] QoS specification for context > > Pat & the group: > > Sec. 3.2.3 of the problem statement is about QoS, thus we need to > specify requirements. There is material in this section that can be used for > requirements but it is insufficient as is. > > Traffic flow may cross different domains with different QoS policies, thus, > context should store different parameters for each flow as needed in each > domain. > > Ex. Diffserv. > > - DSCP value for flow. > - AF or EF PHB implemented. > - Marker value: red, yellow or green. > - PIR, PBS CIR, CBS parameters. > - Token bucket: burst size B, rate r > - Flow classification: classifier, marker. > - Conditioning: meter, remarker, shaper, dropper. > - SLA --> TCA profile parameters. Is there some overlapping between the last item with other items above? I suppose it can be rewritten as "other SLA-->TCA profile parameters". Xiaoming Fu TKN, TU-Berlin From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 09:51:21 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06865 for ; Mon, 9 Apr 2001 09:51: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 GAA11187; Mon, 9 Apr 2001 06:49:09 -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 GAA01492; Mon, 9 Apr 2001 06:49:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39DlfK9006529 for ; Mon, 9 Apr 2001 06:47:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39Dlexq006528 for mobile-ip-dist; Mon, 9 Apr 2001 06:47: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39DlUK9006521 for ; Mon, 9 Apr 2001 06:47:31 -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 GAA27608 for ; Mon, 9 Apr 2001 06:47:31 -0700 (PDT) Received: from mail.zrz.tu-berlin.de (mail.zrz.TU-Berlin.DE [130.149.4.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA09412 for ; Mon, 9 Apr 2001 06:47:29 -0700 (PDT) Received: from ftsu07.ee.tu-berlin.de ([130.149.49.87] helo=ftmail.ee.tu-berlin.de) by mail.zrz.tu-berlin.de with esmtp (exim-3.22) for id 14mc0u-0007XH-00; Mon, 09 Apr 2001 15:47:28 +0200 Received: from ee.tu-berlin.de (fu@sinope.ee.TU-Berlin.DE [130.149.49.127]) by ftmail.ee.tu-berlin.de (8.11.3/8.11.3) with ESMTP id f39DlSf19731 for ; Mon, 9 Apr 2001 15:47:28 +0200 Message-ID: <3AD1BD70.66CFE654@ee.tu-berlin.de> Date: Mon, 09 Apr 2001 15:47:28 +0200 From: Xiaoming Fu Organization: Telecommunication Networks Group, TU-Berlin X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en-US, de, zh-CN MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Requirements Draft for Mobile IP QoS - Invitation to Volunteer References: <006a01c0c0ee$5942bfb0$34fba78f@borg> 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, > May I know what is NSIS ???? NSIS - Next Steps in Signaling(if I am right?), its BOF: http://www.ietf.org/ietf/01mar/nsis-agenda.txt Xiaoming > I am quite interested in this as well. > > Cheers > Chern Nam Yap > cny@ieee.org > > ----- Original Message ----- > From: "Hemant Chaskar" > To: > Sent: Thursday, April 05, 2001 9:47 PM > Subject: [mobile-ip] Requirements Draft for Mobile IP QoS - Invitation to > Volunteer > > > 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 > > From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 11:09:51 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08805 for ; Mon, 9 Apr 2001 11:09: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 IAA16400; Mon, 9 Apr 2001 08:04: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 IAA09503; Mon, 9 Apr 2001 08:03:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39F1eK9006911 for ; Mon, 9 Apr 2001 08:01:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39F1e0P006910 for mobile-ip-dist; Mon, 9 Apr 2001 08:01: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39F1RK9006900 for ; Mon, 9 Apr 2001 08:01:27 -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 IAA09723 for ; Mon, 9 Apr 2001 08:01:27 -0700 (PDT) Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA04643 for ; Mon, 9 Apr 2001 08:01:17 -0700 (PDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Mon, 9 Apr 2001 09:40:12 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Apr 2001 09:45:25 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E4301CDB3B2@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Location privacy Date: Mon, 9 Apr 2001 09:45:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C103.B60557C0" 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_01C0C103.B60557C0 Content-Type: text/plain; charset="iso-8859-1" Resending due to the Thursday server issues. -----Original Message----- From: Morrow, Glenn [RICH2:C330:EXCH] Sent: Thursday, April 05, 2001 2:03 PM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] Location privacy Raj, Why are you not too worried about it? Right now if someone tries to call me on my cell phone they don't get to know where I am and I certainly don't want them to necessarily know or have my service degraded because I'm half way accross the world. This seems like a reasonable and revenue affecting concern to both a service provider and to people in general. I'll also refer to Charlie's hierarchical related mathematics rebutal to any "light is pretty fast" arguments. Please clarify. Thanks, Glenn -----Original Message----- From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] Sent: Tuesday, April 03, 2001 12:24 PM To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Location privacy Location privacy is something that MAY need attention on it's own and for now, I'm not too worried about it. ------_=_NextPart_001_01C0C103.B60557C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Location privacy

Resending due to the Thursday server issues.

-----Original Message-----
From: Morrow, Glenn [RICH2:C330:EXCH]
Sent: Thursday, April 05, 2001 2:03 PM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: [mobile-ip] Location privacy


Raj,

Why are you not too worried about it? Right now if = someone tries to call me on my cell phone they don't get to know where = I am and I certainly don't want them to necessarily know or have my = service degraded because I'm half way accross the world. This seems = like a reasonable and revenue affecting concern to both a service = provider and to people in general.

I'll also refer to Charlie's hierarchical related = mathematics rebutal to any "light is pretty fast" = arguments.

Please clarify.

Thanks,

Glenn

-----Original Message-----
From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.c= om]
Sent: Tuesday, April 03, 2001 12:24 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Location privacy

Location privacy is something that MAY need attention = on it's own and
for now, I'm not too worried about it.

------_=_NextPart_001_01C0C103.B60557C0-- From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 11:13:53 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08917 for ; Mon, 9 Apr 2001 11:13: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 IAA20997; Mon, 9 Apr 2001 08:12: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 IAA11305; Mon, 9 Apr 2001 08:12:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39FBPK9007031 for ; Mon, 9 Apr 2001 08:11:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39FBPSj007030 for mobile-ip-dist; Mon, 9 Apr 2001 08:11: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39FBGK9007023 for ; Mon, 9 Apr 2001 08:11:16 -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 IAA11053 for ; Mon, 9 Apr 2001 08:11:16 -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 IAA13920 for ; Mon, 9 Apr 2001 08:11: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 f39FB9s00629 for ; Mon, 9 Apr 2001 17:11:09 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Mon Apr 09 17:11:08 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Apr 2001 17:11:07 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBD74@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] MIP v6 Regional Registration - identifying re quirements Date: Mon, 9 Apr 2001 17:11:05 +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: [Forwarding for the 4th time, sorry if you receive multiples] > (The authors of HMIPv6 prepared some answers and Claude > was meant to send it but I guess it was lost. Sorry if you > get multiple copies). > > Hello Phil, > > This is a great start. Thanks for taking the time. > We're not sure why it is referred to as RR but anyhow > that's just a name and we all know what you mean > (Localised moility management). > > We will only answer to the validity of the requirements and > not to where HMIPv6 stands in terms of supporting a > requirement. We think it is better to first agree on a set > of requirements and take it from there. > > I think I've finally caught up on all the mail about regional registrations > for MIP v6 and HMIP. There seems to be significant concerns about the task > to be accomplished and the specific approach that is specified in the HMIP > draft. A short list of concerns include worries about introducing single > points of failure, whether or not multiple levels of hierarchy are needed, > the amount of signaling and tunneling overhead that is implied, the > > => We believe we got some confirmation for ROHC and CT > folks that tunnelling will not be an issue. > > relevance of load balancing and the particular metrics in the HMIP draft, > > => Based on the comments received in Minneapolis we thought > it would be good to have load balancing (for HA/MAP/CN) in a separate draft. > Unless there is consensus against this, we will do that. > > Here's a short list of requirements drawn from comments received over the > last month or so and from the HMIP draft that the working group participants > can use as a basis for discussion. Please understand that this is not the > list of requirements I believe are needed > > => Understood. > > => Here are some comments. Hopefully these comments > should cause the people who raised the requirements > to provide some reasons for raising them. > > => BTW, the single point of failure issue is not an HMIP > specific problem. However HMIPv6 has less single > points of failure than other proopsals. > > We would like to add two more requirements. > > 0) Localised mobility management should provide the same > level of mobility management support as in the basic > MIPv6 specifiation. The mobility management functions > supported in MIPv6 must not be reduced in such mechanism. > > 0.5) The provided mechanism must interwork with existing > MIPv6, IPv6 and the proposed mechanisms for SA establishment > in MIPv6. > > 1) Regional registration shall be introduced to minimize the signaling > traffic to the home agent or correspondent nodes for intra-domain mobility > > => Agreed > > 2) Regional registration shall not introduce new overhead on links between > the mobile and the regional registration agents > > => We're not sure what this means. However if it means no more > overhead than a BU then it's seems like a reasonable requirement. > > 3) Connectivity to the mobiles shall not be interrupted in the presence of > the failure of regional registration agents > > => Agreed. Although this should trigger some redundancy work > in the MIP WG. But it should be kept as a target. > > 4) Regional registration shall scale to support millions of nodes in a > visited network > > => Agreed. > > 5) Regional registration shall be secure against malicious behavior from > visiting mobiles > > => Agreed. > > 6) Regional registration shall allow multiple levels of hierarchy > > => We can't see a reason for this requirement. We think it's > OK if we want to support mobile networks but we don't > think this requirement should be placed for all cases. > We never got an answer for the technical merits of > this requirement. It would be good to know why. Otherwise > we'd like to remove this requirement. > > 7) Regional registration shall support fast handoffs> > > => If that means coexist with the current FH proposal > then we agree. > > 8) Regional registration shall not require changes to the mobile node, the > home agent, or correspondent nodes > > => We can understand the HA and CN, but no changes in the MN > seems strange. Is this possible ? > > 9) Regional registration shall not introduce host routes in routing tables > > => Agreed. As long as a Binding Cache entry is not regarded as > a host route ? strictly speaking. > > > Hesham, Claude and Karim > From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 11:13:54 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08925 for ; Mon, 9 Apr 2001 11:13: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 IAA19023; Mon, 9 Apr 2001 08:08: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 IAA09941; Mon, 9 Apr 2001 08:02:52 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39F1SK9006903 for ; Mon, 9 Apr 2001 08:01:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39F1RhS006901 for mobile-ip-dist; Mon, 9 Apr 2001 08:01:27 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39F1IK9006893 for ; Mon, 9 Apr 2001 08:01: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 IAA09708 for ; Mon, 9 Apr 2001 08:01:18 -0700 (PDT) Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA05998 for ; Mon, 9 Apr 2001 08:01:17 -0700 (PDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Mon, 9 Apr 2001 09:44:04 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Apr 2001 09:49:18 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E4301CDB3C4@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] MIP v6 Regional Registration - identifying requir ements Date: Mon, 9 Apr 2001 09:49:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C104.40CE8480" 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_01C0C104.40CE8480 Content-Type: text/plain; charset="iso-8859-1" Resending due to Thursday's server issues. -----Original Message----- From: Morrow, Glenn [RICH2:C330:EXCH] Sent: Thursday, April 05, 2001 2:09 PM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] MIP v6 Regional Registration - identifying requirements In regards to (9) below. Is the implementation concept of binding cache not simply a new type of routing table overlay? And is not a binding entry a type of per host route? It seems to me that a duck has been semantically avoided being called a duck IMHO. I guess what I'm trying to say is, "Is it O.K. to use per host routes if we call the routing table a binding cache and the route a binding entry?". Thanks, Glenn ----------- previous message ------------ 9) Regional registration shall not introduce host routes in routing tables ------_=_NextPart_001_01C0C104.40CE8480 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] MIP v6 Regional Registration - identifying = requirements

Resending due to Thursday's server issues.

-----Original Message-----
From: Morrow, Glenn [RICH2:C330:EXCH]
Sent: Thursday, April 05, 2001 2:09 PM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: [mobile-ip] MIP v6 Regional = Registration - identifying
requirements


In regards to (9) below.

Is the implementation concept of binding cache not = simply a new type of routing table overlay?

And is not a binding entry a type of per host = route?

It seems to me that a duck has been semantically = avoided being called a duck IMHO.

I guess what I'm trying to say is, "Is it O.K. = to use per host routes if we call the routing table a binding cache and = the route a binding entry?".

Thanks,

Glenn

----------- previous message ------------

9) Regional registration shall not introduce host = routes in routing tables






 

------_=_NextPart_001_01C0C104.40CE8480-- From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 11:39: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 LAA09603 for ; Mon, 9 Apr 2001 11:39: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 IAA11862; Mon, 9 Apr 2001 08:35: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 IAA15271; Mon, 9 Apr 2001 08:35:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39FXeK9007146 for ; Mon, 9 Apr 2001 08:33:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39FXdNY007145 for mobile-ip-dist; Mon, 9 Apr 2001 08:33: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39FXVK9007138 for ; Mon, 9 Apr 2001 08:33:31 -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 IAA05790 for ; Mon, 9 Apr 2001 08:33:31 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA18688 for ; Mon, 9 Apr 2001 08:33:00 -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 f39FWtg29868 for ; Mon, 9 Apr 2001 10:33:05 -0500 (CDT) Received: from daebh01nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 9 Apr 2001 10:32:37 -0500 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Mon, 9 Apr 2001 10:32:36 -0500 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B0321379E@daeis07nok> To: mobile-ip@sunroof.eng.sun.com Cc: gmorrow@nortelnetworks.com Subject: RE: [mobile-ip] Location privacy Date: Mon, 9 Apr 2001 10:32:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C10A.4984AF40" Sender: owner-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_01C0C10A.4984AF40 Content-Type: text/plain; charset="iso-8859-1" Comments below: Glenn: >Raj, > >Why are you not too worried about it? Right now if someone tries to >call me on my cell phone they don't get to know where I am and I >certainly don't want them to necessarily know or have my service >degraded because I'm half way accross the world. This seems like a >reasonable and revenue affecting concern to both a service provider >and to people in general. > The scenario you describe is one that I have considered as well. The reason I mentioned that I was not too worried about it right now was from the perspective of Mobile IPv6 and getting the MIPv6 spec done in this WG. I prefer not to let the location privacy issue interfere with the MIPv6 spec being done and to add to that the issue of location privacy is being discussed and MAY be dealt with in another WG altogether (look at Phil's note to the list earlier). So for now I am just sticking my head in the sand and ignoring the problem. > >Please clarify. > >Thanks, > >Glenn > Basavaraj: >>Location privacy is something that MAY need attention on it's own and >>for now, I'm not too worried about it. ------_=_NextPart_001_01C0C10A.4984AF40 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Location privacy

Comments below:
 
Glenn:
>Raj,
>
>Why are you not too worried about it? Right now if someone tries to
>call me on my cell phone they don't get to know where I am and I
>certainly don't want them to necessarily know or have my service
>degraded because I'm half way accross the world. This seems like a
>reasonable and revenue affecting concern to both a service provider
>and to people in general. 
>
 
The scenario you describe is one that I have considered as well. The
reason I mentioned that I was not too worried about it right now was
from the perspective of Mobile IPv6 and getting the MIPv6 spec done in
this WG. I prefer not to let the location privacy issue interfere with
the MIPv6 spec being done and to add to that the issue of location
privacy is being discussed and MAY be dealt with in another WG
altogether (look at Phil's note to the list earlier).
So for now I am just sticking my head in the sand and ignoring the
problem. 
 
>
>Please clarify.
>
>Thanks,
>
>Glenn
>
Basavaraj:
>>Location privacy is something that MAY need attention on it's own and
>>for now, I'm not too worried about it.
 
 
 
------_=_NextPart_001_01C0C10A.4984AF40-- From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 12:06: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 MAA10335 for ; Mon, 9 Apr 2001 12:06: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 JAA14398; Mon, 9 Apr 2001 09:05:09 -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 JAA17536; Mon, 9 Apr 2001 09:05:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39G3mK9007236 for ; Mon, 9 Apr 2001 09:03:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39G3mno007235 for mobile-ip-dist; Mon, 9 Apr 2001 09:03: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39G3dK9007228 for ; Mon, 9 Apr 2001 09:03:39 -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 JAA21421 for ; Mon, 9 Apr 2001 09:03:39 -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 JAA12860 for ; Mon, 9 Apr 2001 09:03:37 -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 SAA01403 for ; Mon, 9 Apr 2001 18:03:19 +0200 (MEST) Message-ID: <3AD1DD22.4EFE9973@inrialpes.fr> Date: Mon, 09 Apr 2001 18:02:42 +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] Location privacy References: <7B5C0390ACE7D211BC9C0008C7EABA2B0321379E@daeis07nok> Content-Type: multipart/alternative; boundary="------------8F47D97A83DC7B0265C49D3B" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------8F47D97A83DC7B0265C49D3B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Raj, Some of the privacy issues are very specific to MIPv6 (as described in draft-castelluccia-mobileip-privacy-00.txt). IMO they should be discussed and considered in the MIP WG soon or later... regards, Claude. Basavaraj.Patil@nokia.com wrote: > > The scenario you describe is one that I have considered as well. The > > reason I mentioned that I was not too worried about it right now was > from the perspective of Mobile IPv6 and getting the MIPv6 spec done in > > this WG. I prefer not to let the location privacy issue interfere with > > the MIPv6 spec being done and to add to that the issue of location > privacy is being discussed and MAY be dealt with in another WG > altogether (look at Phil's note to the list earlier). > So for now I am just sticking my head in the sand and ignoring the > problem. > > >Please clarify. -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------8F47D97A83DC7B0265C49D3B Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
Hello Raj,

Some of the privacy issues are very specific to MIPv6 (as described in  draft-castelluccia-mobileip-privacy-00.txt).
IMO they should be discussed and considered in the MIP WG soon or later...
regards,
Claude.

Basavaraj.Patil@nokia.com wrote:

> The scenario you describe is one that I have considered as well. The
reason I mentioned that I was not too worried about it right now was
from the perspective of Mobile IPv6 and getting the MIPv6 spec done in
this WG. I prefer not to let the location privacy issue interfere with
the MIPv6 spec being done and to add to that the issue of location
privacy is being discussed and MAY be dealt with in another WG
altogether (look at Phil's note to the list earlier).
So for now I am just sticking my head in the sand and ignoring the
problem. >
>Please clarify.
-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  --------------8F47D97A83DC7B0265C49D3B-- From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 12:19:27 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10617 for ; Mon, 9 Apr 2001 12:19:26 -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 JAA27755; Mon, 9 Apr 2001 09:18: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 JAA24698; Mon, 9 Apr 2001 09:18:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39GGSK9007314 for ; Mon, 9 Apr 2001 09:16:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39GGSiP007313 for mobile-ip-dist; Mon, 9 Apr 2001 09:16: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39GGFK9007306 for ; Mon, 9 Apr 2001 09:16: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 JAA24057 for ; Mon, 9 Apr 2001 09:16:15 -0700 (PDT) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id JAA11356 for ; Mon, 9 Apr 2001 09:16:12 -0700 (PDT) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Mon Apr 9 12:13:50 EDT 2001 Received: from blhothuelpc (thuelpc [135.180.240.114]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id MAA01732 for ; Mon, 9 Apr 2001 12:16:12 -0400 (EDT) From: "Sandy Thuel" To: Subject: FW: [mobile-ip] dynamic home addressing as a WG item?? Date: Mon, 9 Apr 2001 12:13:31 -0400 Message-ID: <00cc01c0c110$04fd23b0$72f0b487@dnrc.belllabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-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 The following message never made it to the mailing list so I'm resending it. -----Original Message----- From: Sandy Thuel [mailto:thuel@lucent.com] Sent: Thursday, April 05, 2001 11:32 AM To: James Kempf; mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] dynamic home addressing as a WG item?? Hi James, Please see my comment in-line. > >I hear clearly that you'd rather NOT use DHCP > >but you haven't yet answered the question of > >whether or not configuration options are important. > >Are you implying that "address provisioning" is > >all that matters and other configuration options > >are NOT important? Or are you saying that no > >matter what configuration state is needed, Mobile > >IP should provision it? > > If by "configuration options" you mean service discovery, > then I think there are better ways to do this (DNS SRV RR > interdomain, SLP intradomain, maybe LDAP also). No. I wasn't referring to service discovery but to parameters which are typically associated with DHCP options [RFC2132] such as subnet mask, domain name, gateway router(s), DNS server(s), NTP server(s), etc. Please correct me if I'm wrong but my understanding was that these service discovery protocols don't allocate all these parameters. And even if they do, what is the extent of their deployment and support in today's networks to rely on them for mobile configuration support? > > I think a case can also be made for provisioning a mobile > node's service access information via AAA if the mobile > node is away from home and needs to obtain service > access information from the home domain. This is > one case that I have some difficulty seeing DHCP solving > without massively twisting it from its initial design center. I agree that AAA is, in principle, a promising candidate to be a repository for the configuration options I'm referring to and it could be a better alternative than DHCP. Do you know of any efforts to extend the AAA infrastructure to support this? In any case, if I want a solution for today, I still think DHCP is the only game in town... > > >Good observation. Users that power-up devices > >frequently are likely to be less tolerant of > >configuration latency than those who keep their > >devices powered on for extended periods of time > >(e.g., cellphones). But do you have any idea > >as to what latency is considered tolerable in > >either case? > > This is a human factors question I can't really answer. > Compare the amount of time it takes for your mobile > phone to come up when you first turn it on with how > long it takes Windows to boot on your laptop. Somewhere > in the middle, the latency becomes annoying if you > tend to turn the device on and off frequently. > If improving on a Windows bootup time is our baseline, configuration latency is not a problem at all :-) > > >I didn't say that any protocol changes are > >necessary (unless the MN requires anything more than > >a home address, as per my comment on the following > >question). What is needed is some *implementation* > >changes on home agents to provide DHCP > >proxy services. As for what this implementation > >entails, one solution, as you implicitly suggest, > >is to have an API between the HA and a co-located > >DHCP proxy agent. Rather than keeping the HA > >and DHCP proxies logically separated through an > >API, the implementation of DHCP proxies > >could be more tightly integrated with the HA. > >The issue here is not to debate on which is the > >best way to implement proxy services on home > >agents but to discuss whether or not ANY > >implementation changes to HA's to provide such > >services is a feasible requirement at this stage, > >when MIPv4 is already being deployed. > > An API doesn't necessarily mean that the DHCP > proxy is physically separate, the API may be > provided by the operating system. Yes. That's what I meant when I said the DHCP proxy and HA can be "logically" separated by an API. > > But I don't see any problem with having the > HA do DHCP out the back end, this is > an implementation choice. Agreed. Now, we have agreed that there are different ways to implement this. This settles affirmatively the question as to whether or not it is implementable. The more important question I'm trying to get at is whether or not it is feasible to require HA's to support this (picking a favorite implementation strategy of choice). Any thoughts? > > > >So you're implying once again that you don't > >care about any other configuration besides an > >IP address, correct? Note that if you DO care > >about anything other than an IP address, there is > >no other recourse but to extend Mobile IP to > >allow the MN to ask for it and get it from a > >HA. > > As I mentioned above, I think there are other, better > ways of provisioning service discovery on mobile > nodes. I hope my clarification above on what I was referring to as configuration options clarifies what I meant by this question. Thanks, Sandy From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 12:24:41 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10783 for ; Mon, 9 Apr 2001 12:24:41 -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 JAA28666; Mon, 9 Apr 2001 09:19: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 JAA25158; Mon, 9 Apr 2001 09:19:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39GHkK9007348 for ; Mon, 9 Apr 2001 09:17:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39GHk2s007347 for mobile-ip-dist; Mon, 9 Apr 2001 09:17: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39GHYK9007340 for ; Mon, 9 Apr 2001 09:17: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 JAA24452 for ; Mon, 9 Apr 2001 09:17:34 -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 JAA27478 for ; Mon, 9 Apr 2001 09:17:32 -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.9.3/8.9.1) with ESMTP id JAA21844 for ; Mon, 9 Apr 2001 09:17: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 ADS00646; Mon, 9 Apr 2001 09:17:31 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA06737; Mon, 9 Apr 2001 09:17:31 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15057.57498.876118.955302@thomasm-u1.cisco.com> Date: Mon, 9 Apr 2001 09:17:30 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Location privacy In-Reply-To: <3AD1DD22.4EFE9973@inrialpes.fr> References: <7B5C0390ACE7D211BC9C0008C7EABA2B0321379E@daeis07nok> <3AD1DD22.4EFE9973@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 I really don't know what MIP has to do with location privacy per se. In fact, it provides a fair veneer of privacy which is completely under the control of the mobile node: it just doesn't send binding updates if it wants rudimentary privacy. Moving the HA farther toward the mobile node (as does HMIP) reveals more information. The only way to reveal less information is to decouple your home agent from your home network; this is just an operational issue. Of course, the best is to run things through an ALG which I think is ultimately what will happen if people want to be assured privacy (eg battered wife). Mike Claude Castelluccia writes: > > Hello Raj, > > Some of the privacy issues are very specific to MIPv6 (as described in > draft-castelluccia-mobileip-privacy-00.txt). > IMO they should be discussed and considered in the MIP WG soon or > later... > regards, > Claude. > > Basavaraj.Patil@nokia.com wrote: > > > > The scenario you describe is one that I have considered as well. The > > > > reason I mentioned that I was not too worried about it right now was > > from the perspective of Mobile IPv6 and getting the MIPv6 spec done in > > > > this WG. I prefer not to let the location privacy issue interfere with > > > > the MIPv6 spec being done and to add to that the issue of location > > privacy is being discussed and MAY be dealt with in another WG > > altogether (look at Phil's note to the list earlier). > > So for now I am just sticking my head in the sand and ignoring the > > problem. > > > >Please clarify. > > -- > > ---------------------------------------- > Claude CASTELLUCCIA, INRIA Rhone-Alpes > ph: +33 4.76.61.52.15 (fax: 52.52) > http://www.inrialpes.fr/planete/ > > > > >   >
Hello Raj, >

Some of the privacy issues are very specific to MIPv6 (as described > in  draft-castelluccia-mobileip-privacy-00.txt). >
IMO they should be discussed and considered in the MIP WG soon > or later... >
regards, >
Claude. >

Basavaraj.Patil@nokia.com wrote: >

> > The scenario you > describe is one that I have considered as well. The >
reason I mentioned > that I was not too worried about it right now was >
from the perspective > of Mobile IPv6 and getting the MIPv6 spec done in >
this WG. I prefer > not to let the location privacy issue interfere with >
the MIPv6 spec > being done and to add to that the issue of location >
privacy is being > discussed and MAY be dealt with in another WG >
altogether (look > at Phil's note to the list earlier). >
So for now I > am just sticking my head in the sand and ignoring the >
problem. > > >
>Please clarify.
> > 
-- 
 > 
 > ----------------------------------------
 > Claude CASTELLUCCIA, INRIA Rhone-Alpes  
 > ph:  +33 4.76.61.52.15 (fax: 52.52)
 > http://www.inrialpes.fr/planete/
>   From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 12:27:05 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 MAA10871 for ; Mon, 9 Apr 2001 12:27:04 -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 JAA06137; Mon, 9 Apr 2001 09:26:08 -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 JAA26336; Mon, 9 Apr 2001 09:26:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39GOtK9007548 for ; Mon, 9 Apr 2001 09:24:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39GOtPK007547 for mobile-ip-dist; Mon, 9 Apr 2001 09:24:55 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39GOkK9007540 for ; Mon, 9 Apr 2001 09:24:46 -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 JAA22034 for ; Mon, 9 Apr 2001 09:24:46 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25245 for ; Mon, 9 Apr 2001 09:24:42 -0700 (PDT) Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.43.101]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id JAA24988; Mon, 9 Apr 2001 09:23:14 -0700 (PDT) Received: from gopal.cisco.com (gdommety-dsl5.cisco.com [10.19.17.142]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id ABS06899; Mon, 9 Apr 2001 09:24:30 -0700 (PDT) Message-Id: <4.3.2.7.2.20010409092000.00c914e0@mira-sjcm-3.cisco.com> X-Sender: gdommety@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Apr 2001 09:21:11 -0700 To: mobile-ip@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com From: Gopal Dommety Subject: [mobile-ip] Re: CVSE type number in RFC3025 Cc: kleung@cisco.com In-Reply-To: <3ACF28C6.1BCA13E4@attglobal.net> 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: Hello Sebastian: I am resending the reply that I sent on 04/04/01 to your original email... Initially 37 was assigned and we requested 38 to be assigned. Raj approved the request. But when the RFC was published 37 was there instead of 38. I have sent an email to the RFC editor requesting couple of days ago that the number be changed to 38. I am awaiting response the editor. I will let the group know when I hear from the editor. Thanks for pointing this discrepancy out. Regards, Gopal At 09:48 AM 07/04/01 -0500, Sebastian Thalanany wrote: >Hello Gopal, > There seems to be a discrepancy between the value > >assigned for the CVSE-TYPE-NUMBER in RFC 3025 and in IANA. The >difference in the assigned value was found to be as follows: > CVSE-TYPE-NUMBER = 37 in RFC3025 > CVSE-TYPE-NUMBER = 38 in IANA (Under Mobile IP numbers) > > The 3GPP2 IOS standard is using a value of 38. > > Please clarify. > > Thanks. > >Regards, > Sebastian From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 12:27: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 MAA10887 for ; Mon, 9 Apr 2001 12:27: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 JAA29260; Mon, 9 Apr 2001 09:19:06 -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 JAA14681; Mon, 9 Apr 2001 09:18:52 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39GGCK9007304 for ; Mon, 9 Apr 2001 09:16:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39GGCUa007303 for mobile-ip-dist; Mon, 9 Apr 2001 09:16: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39GG3K9007296 for ; Mon, 9 Apr 2001 09:16:03 -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 JAA23965 for ; Mon, 9 Apr 2001 09:16:02 -0700 (PDT) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA26033 for ; Mon, 9 Apr 2001 09:16:00 -0700 (PDT) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Mon Apr 9 12:15:20 EDT 2001 Received: from blhothuelpc (thuelpc [135.180.240.114]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id MAA01721 for ; Mon, 9 Apr 2001 12:15:30 -0400 (EDT) From: "Sandy Thuel" To: Subject: [mobile-ip] dynamic home addressing as a WG item?? Date: Mon, 9 Apr 2001 12:12:48 -0400 Message-ID: <00cb01c0c10f$ebab0da0$72f0b487@dnrc.belllabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-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 The following message never made it to the mailing list so I'm resending it. -----Original Message----- From: Sandy Thuel [mailto:thuel@lucent.com] Sent: Wednesday, April 04, 2001 12:15 PM To: James Kempf; mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] dynamic home addressing as a WG item?? Hi James, > > >1) What is the real value of DHCP options to mobile > > nodes? > > Frankly, I'd like to avoid having the mobile node have to use DHCP. It > would be better to have a single, unified address provisioning mechanism > based on mobile IP. The mobile node will have to use mobile IP > anyway. I hear clearly that you'd rather NOT use DHCP but you haven't yet answered the question of whether or not configuration options are important. Are you implying that "address provisioning" is all that matters and other configuration options are NOT important? Or are you saying that no matter what configuration state is needed, Mobile IP should provision it? > > >2) How important is it to minimize the power-up > > configuration latency of a mobile node? > > I think this is important, particularly for small devices that > come and go. > Obviously, > for an appliance like a cell phone that comes on and stays on (but maybe > in low power mode) it is less important. Good observation. Users that power-up devices frequently are likely to be less tolerant of configuration latency than those who keep their devices powered on for extended periods of time (e.g., cellphones). But do you have any idea as to what latency is considered tolerable in either case? > > >3) How feasible do you think it is to > > require changes on Mobile IP home agents > > to provide a new service (e.g., DHCP proxy > > service support)? > > MIPv4 is already undergoing deployment, so it seems like changing this > would be a hardship. I'm not exactly sure I understand why any protocol > changes are > necessary. Why couldn't the HA simply use DHCP through an API? I didn't say that any protocol changes are necessary (unless the MN requires anything more than a home address, as per my comment on the following question). What is needed is some *implementation* changes on home agents to provide DHCP proxy services. As for what this implementation entails, one solution, as you implicitly suggest, is to have an API between the HA and a co-located DHCP proxy agent. Rather than keeping the HA and DHCP proxies logically separated through an API, the implementation of DHCP proxies could be more tightly integrated with the HA. The issue here is not to debate on which is the best way to implement proxy services on home agents but to discuss whether or not ANY implementation changes to HA's to provide such services is a feasible requirement at this stage, when MIPv4 is already being deployed. > > > >4) How do you feel about the idea of adding > > DHCP-specific extensions to Mobile IP? > > > > > I'm opposed to adding DHCP extensions to mobile IP. I would rather see > an address provisioning mechanism presented to the mobile node > that hides the back end provisioning scheme. > So you're implying once again that you don't care about any other configuration besides an IP address, correct? Note that if you DO care about anything other than an IP address, there is no other recourse but to extend Mobile IP to allow the MN to ask for it and get it from a HA. Thanks for your input! Sandy From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 12:29: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 MAA10927 for ; Mon, 9 Apr 2001 12:29: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 JAA07446; Mon, 9 Apr 2001 09:27: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 JAA26932; Mon, 9 Apr 2001 09:27:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39GPqK9007558 for ; Mon, 9 Apr 2001 09:25:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39GPqqT007557 for mobile-ip-dist; Mon, 9 Apr 2001 09:25:52 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39GPfK9007550 for ; Mon, 9 Apr 2001 09:25: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 JAA22354 for ; Mon, 9 Apr 2001 09:25:40 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25613 for ; Mon, 9 Apr 2001 09:25:28 -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 f39GPNg07297 for ; Mon, 9 Apr 2001 11:25:33 -0500 (CDT) Received: from daebh01nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 9 Apr 2001 11:25:17 -0500 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Mon, 9 Apr 2001 11:25:17 -0500 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B032137A0@daeis07nok> To: mobile-ip@sunroof.eng.sun.com Cc: claude.castelluccia@inrialpes.fr Subject: Re: [mobile-ip] Location privacy Date: Mon, 9 Apr 2001 11:25:07 -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: Claude: >Hello Raj, >Some of the privacy issues are very specific to MIPv6 (as described >in draft-castelluccia-mobileip-privacy-00.txt). >IMO they should be discussed and considered in the MIP WG soon or later... >regards, >Claude. > No disagreement there Claude. If you look at Phil's note sent out earlier which said: " we have a charter item to "address location privacy." We'd like to gather some information about what the working group thinks the extent of the work on location privacy in this working group should be. It MUST in some serious way be connected with the Mobile IP protocol. There will be in the Apps area very soon a location privacy working group so we have to realize that this working group will not be the place to resolve all issues relating to location privacy. " I am merely saying that in terms of priority, getting the MIPv6 spec done is relatively more critical than addressing privacy issues related to MIPv6. -Basavaraj >Basavaraj.Patil@nokia.com wrote: >> >> The scenario you describe is one that I have considered as well. The >> reason I mentioned that I was not too worried about it right now was >> from the perspective of Mobile IPv6 and getting the MIPv6 spec done in >> this WG. I prefer not to let the location privacy issue interfere with >> the MIPv6 spec being done and to add to that the issue of location >> privacy is being discussed and MAY be dealt with in another WG >> altogether (look at Phil's note to the list earlier). >> So for now I am just sticking my head in the sand and ignoring the >> problem. > >-- > >---------------------------------------- >Claude CASTELLUCCIA, INRIA Rhone-Alpes >ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 12:40: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 MAA11241 for ; Mon, 9 Apr 2001 12:40:11 -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 JAA16115; Mon, 9 Apr 2001 09:37:06 -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 JAA28563; Mon, 9 Apr 2001 09:37:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39GZrK9007686 for ; Mon, 9 Apr 2001 09:35:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39GZrrl007685 for mobile-ip-dist; Mon, 9 Apr 2001 09:35: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39GZiK9007678 for ; Mon, 9 Apr 2001 09:35:44 -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 JAA28299 for ; Mon, 9 Apr 2001 09:35:44 -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 JAA22999 for ; Mon, 9 Apr 2001 09:35:35 -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.9.3/8.9.1) with ESMTP id JAA09590 for ; Mon, 9 Apr 2001 09:35: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 ADS01103; Mon, 9 Apr 2001 09:35:23 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA06744; Mon, 9 Apr 2001 09:35:23 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15057.58571.271181.254589@thomasm-u1.cisco.com> Date: Mon, 9 Apr 2001 09:35:23 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Location privacy In-Reply-To: <15057.57498.876118.955302@thomasm-u1.cisco.com> References: <7B5C0390ACE7D211BC9C0008C7EABA2B0321379E@daeis07nok> <3AD1DD22.4EFE9973@inrialpes.fr> <15057.57498.876118.955302@thomasm-u1.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 Argh. Sorry for following myself up but: Michael Thomas writes: > Moving the HA farther toward the mobile > node (as does HMIP) reveals more information. The > only way to reveal less information is to decouple > your home agent from your home network; This should read: "decouple your home agent's location from your ``home'' location" Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 12:51:40 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11597 for ; Mon, 9 Apr 2001 12:51:39 -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 JAA15857; Mon, 9 Apr 2001 09:48: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 JAA28305; Mon, 9 Apr 2001 09:48:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39Gl1K9007755 for ; Mon, 9 Apr 2001 09:47:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39Gl0m3007753 for mobile-ip-dist; Mon, 9 Apr 2001 09:47: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39GkiK9007740 for ; Mon, 9 Apr 2001 09:46: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 JAA01775 for ; Mon, 9 Apr 2001 09:46:44 -0700 (PDT) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA29889 for ; Mon, 9 Apr 2001 09:46:37 -0700 (PDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Mon, 9 Apr 2001 09:00:41 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Apr 2001 08:57:07 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E4301CDB299@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] location privacy Date: Mon, 9 Apr 2001 08:57:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C0FC.F6EBBD30" Sender: owner-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_01C0C0FC.F6EBBD30 Content-Type: text/plain; charset="iso-8859-1" Phil, It seems to me that MIP currently solves location privacy at the expense of route optimization. I believe that the MIP WG should work on a method of providing route optimized location privacy. The domain of the MIP WG should be focused on the network-layer addressing issues i.e. COA and home addresses. The application group should work on the user address issues. Thanks, Glenn -----Original Message----- From: Phil Roberts [mailto:PRoberts@MEGISTO.com] Sent: Friday, April 06, 2001 7:35 AM To: 'mobile-ip@sunroof.eng.sun.com' Subject: [mobile-ip] location privacy This and the next post I sent the last couple of days and never saw show up on the list. If you saw them, sorry for the duplicates. Hi, we have a charter item to "address location privacy." We'd like to gather some information about what the working group thinks the extent of the work on location privacy in this working group should be. It MUST in some serious way be connected with the Mobile IP protocol. There will be in the Apps area very soon a location privacy working group so we have to realize that this working group will not be the place to resolve all issues relating to location privacy. Phil ------_=_NextPart_001_01C0C0FC.F6EBBD30 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] location privacy

Phil,

It seems to me that MIP currently solves location privacy at the expense of route optimization.

I believe that the MIP WG should work on a method of providing route optimized location privacy.

The domain of the MIP WG should be focused on the network-layer addressing issues i.e. COA and home addresses.

The application group should work on the user address issues.

Thanks,

Glenn

-----Original Message-----
From: Phil Roberts [mailto:PRoberts@MEGISTO.com]
Sent: Friday, April 06, 2001 7:35 AM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: [mobile-ip] location privacy


This and the next post I sent the last couple of days and never saw show up
on the list.  If you saw them, sorry for the duplicates.


Hi,

     we have a charter item to "address location privacy."  We'd like to
gather some information about what the working group thinks the extent of
the work on location privacy in this working group should be.  It MUST in
some serious way be connected with the Mobile IP protocol.  There will be in
the Apps area very soon a location privacy working group so we have to
realize that this working group will not be the place to resolve all issues
relating to location privacy.

Phil


------_=_NextPart_001_01C0C0FC.F6EBBD30-- From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 13:15: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 NAA12085 for ; Mon, 9 Apr 2001 13:15:25 -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 KAA20817; Mon, 9 Apr 2001 10:14:23 -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 KAA27611; Mon, 9 Apr 2001 10:14:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39HCGK9007916 for ; Mon, 9 Apr 2001 10:12:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39HCFqa007915 for mobile-ip-dist; Mon, 9 Apr 2001 10:12: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39HC7K9007908 for ; Mon, 9 Apr 2001 10:12:07 -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 KAA27113 for ; Mon, 9 Apr 2001 10:12:06 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA20331 for ; Mon, 9 Apr 2001 10:12:04 -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 f39HC9g15113 for ; Mon, 9 Apr 2001 12:12:09 -0500 (CDT) Received: from daebh01nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 9 Apr 2001 12:12:04 -0500 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Mon, 9 Apr 2001 12:12:04 -0500 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B032137A8@daeis07nok> To: mobile-ip@sunroof.eng.sun.com Cc: mat@cisco.com Subject: RE: [mobile-ip] Location privacy Date: Mon, 9 Apr 2001 12:11: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: >Michael Thomas: > > I really don't know what MIP has to do with > location privacy per se. In fact, it provides a > fair veneer of privacy which is completely under > the control of the mobile node: it just doesn't > send binding updates if it wants rudimentary > privacy. Sending BUs to CNs causes route optimization. But irrespective of whether a MN decides to send a BU or not to a CN, the SRC address of packets from the MN to the CN is the COA. So the privacy factor (from a COA/location of the MN) perspective is gone. -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 13:37:05 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12737 for ; Mon, 9 Apr 2001 13:37:05 -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 KAA12121; Mon, 9 Apr 2001 10:35: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 KAA12966; Mon, 9 Apr 2001 10:35:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39HXoK9008091 for ; Mon, 9 Apr 2001 10:33:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39HXoti008090 for mobile-ip-dist; Mon, 9 Apr 2001 10:33: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39HXdK9008082 for ; Mon, 9 Apr 2001 10:33:39 -0700 (PDT) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA12517 for ; Mon, 9 Apr 2001 10:33:38 -0700 (PDT) Received: from nasnfs.Eng.Sun.COM (esun1as-be.Central.Sun.COM [129.147.34.142]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id KAA00988; Mon, 9 Apr 2001 10:33:04 -0700 (PDT) From: Patrice Calhoun Message-Id: <200104091733.KAA00988@nasnfs.Eng.Sun.COM> Date: Mon, 9 Apr 2001 11:29:07 -0700 To: , Subject: Re: FW: [mobile-ip] dynamic home addressing as a WG item?? 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 Here is a question for you Sandy. Is it at all possible for Mobile IP to provide the mobile's home address, as it is done today, and have the mobile issue a DHCP message NOT to request an IP address, but only to retrieve configuration information. So it would provide its address, but it is only looking for provisioning services. That would make this whole thing so much simpler. PatC >The following message never made it to the mailing >list so I'm resending it. > >-----Original Message----- >From: Sandy Thuel [mailto:thuel@lucent.com] >Sent: Thursday, April 05, 2001 11:32 AM >To: James Kempf; mobile-ip@sunroof.eng.sun.com; >mobile-ip@sunroof.eng.sun.com >Subject: RE: [mobile-ip] dynamic home addressing as a WG item?? > > > >Hi James, > > Please see my comment in-line. > >> >I hear clearly that you'd rather NOT use DHCP >> >but you haven't yet answered the question of >> >whether or not configuration options are important. >> >Are you implying that "address provisioning" is >> >all that matters and other configuration options >> >are NOT important? Or are you saying that no >> >matter what configuration state is needed, Mobile >> >IP should provision it? >> >> If by "configuration options" you mean service discovery, >> then I think there are better ways to do this (DNS SRV RR >> interdomain, SLP intradomain, maybe LDAP also). > >No. I wasn't referring to service discovery but >to parameters which are typically associated >with DHCP options [RFC2132] such as subnet mask, >domain name, gateway router(s), DNS server(s), >NTP server(s), etc. Please correct me if I'm >wrong but my understanding was that these service >discovery protocols don't allocate all these >parameters. And even if they do, what is >the extent of their deployment and support in >today's networks to rely on them for mobile >configuration support? > >> >> I think a case can also be made for provisioning a mobile >> node's service access information via AAA if the mobile >> node is away from home and needs to obtain service >> access information from the home domain. This is >> one case that I have some difficulty seeing DHCP solving >> without massively twisting it from its initial design center. > >I agree that AAA is, in principle, a promising >candidate to be a repository for the configuration >options I'm referring to and it could be a better >alternative than DHCP. Do you know of any efforts >to extend the AAA infrastructure to support this? >In any case, if I want a solution for today, I >still think DHCP is the only game in town... > >> >> >Good observation. Users that power-up devices >> >frequently are likely to be less tolerant of >> >configuration latency than those who keep their >> >devices powered on for extended periods of time >> >(e.g., cellphones). But do you have any idea >> >as to what latency is considered tolerable in >> >either case? >> >> This is a human factors question I can't really answer. >> Compare the amount of time it takes for your mobile >> phone to come up when you first turn it on with how >> long it takes Windows to boot on your laptop. Somewhere >> in the middle, the latency becomes annoying if you >> tend to turn the device on and off frequently. >> > >If improving on a Windows bootup time is >our baseline, configuration latency is >not a problem at all :-) > >> >> >I didn't say that any protocol changes are >> >necessary (unless the MN requires anything more than >> >a home address, as per my comment on the following >> >question). What is needed is some *implementation* >> >changes on home agents to provide DHCP >> >proxy services. As for what this implementation >> >entails, one solution, as you implicitly suggest, >> >is to have an API between the HA and a co-located >> >DHCP proxy agent. Rather than keeping the HA >> >and DHCP proxies logically separated through an >> >API, the implementation of DHCP proxies >> >could be more tightly integrated with the HA. >> >The issue here is not to debate on which is the >> >best way to implement proxy services on home >> >agents but to discuss whether or not ANY >> >implementation changes to HA's to provide such >> >services is a feasible requirement at this stage, >> >when MIPv4 is already being deployed. >> >> An API doesn't necessarily mean that the DHCP >> proxy is physically separate, the API may be >> provided by the operating system. > >Yes. That's what I meant when I said the DHCP >proxy and HA can be "logically" separated by >an API. > >> >> But I don't see any problem with having the >> HA do DHCP out the back end, this is >> an implementation choice. > >Agreed. Now, we have agreed that there are >different ways to implement this. This settles >affirmatively the question as to whether or not >it is implementable. The more important question >I'm trying to get at is whether or not it is >feasible to require HA's to support this (picking >a favorite implementation strategy of choice). >Any thoughts? > >> >> >> >So you're implying once again that you don't >> >care about any other configuration besides an >> >IP address, correct? Note that if you DO care >> >about anything other than an IP address, there is >> >no other recourse but to extend Mobile IP to >> >allow the MN to ask for it and get it from a >> >HA. >> >> As I mentioned above, I think there are other, better >> ways of provisioning service discovery on mobile >> nodes. > >I hope my clarification above on what I was >referring to as configuration options clarifies >what I meant by this question. > >Thanks, >Sandy From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 15:15: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 PAA14421 for ; Mon, 9 Apr 2001 15:15:22 -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 MAA01233; Mon, 9 Apr 2001 12:13:38 -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 MAA04934; Mon, 9 Apr 2001 12:13:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39JC4K9008426 for ; Mon, 9 Apr 2001 12:12:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39JC3i9008420 for mobile-ip-dist; Mon, 9 Apr 2001 12:12: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39JBpK9008406 for ; Mon, 9 Apr 2001 12:11: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 MAA06820 for ; Mon, 9 Apr 2001 12:11:50 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA22102 for ; Mon, 9 Apr 2001 12:11:49 -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.9.3/8.9.1) with ESMTP id MAA03824 for ; Mon, 9 Apr 2001 12:10:31 -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 ADT03418; Mon, 9 Apr 2001 12:11:47 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA06779; Mon, 9 Apr 2001 12:11:47 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15058.2419.409135.68086@thomasm-u1.cisco.com> Date: Mon, 9 Apr 2001 12:11:47 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: Re: FW: [mobile-ip] dynamic home addressing as a WG item?? In-Reply-To: <200104091733.KAA00988@nasnfs.Eng.Sun.COM> References: <200104091733.KAA00988@nasnfs.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 Patrice Calhoun writes: > Here is a question for you Sandy. > > Is it at all possible for Mobile IP to provide the mobile's home address, > as it is done today, and have the mobile issue a DHCP message NOT to request > an IP address, but only to retrieve configuration information. So it would > provide its address, but it is only looking for provisioning services. Yes. It's a DHCP INFORM. Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 15: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 PAA15085 for ; Mon, 9 Apr 2001 15: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 MAA22635; Mon, 9 Apr 2001 12:41: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 MAA10219; Mon, 9 Apr 2001 12:41:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39Jd3K9008538 for ; Mon, 9 Apr 2001 12:39:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39Jd3Tc008537 for mobile-ip-dist; Mon, 9 Apr 2001 12:39: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39JcsK9008530 for ; Mon, 9 Apr 2001 12:38: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 MAA09607 for ; Mon, 9 Apr 2001 12:38:53 -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 NAA08160 for ; Mon, 9 Apr 2001 13:38:53 -0600 (MDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Apr 2001 15:37:57 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'mobile-ip@sunroof.eng.sun.com'" Cc: "Kiernan, Brian G." , "'charliep@iprg.nokia.com'" , "Shahrier, Sharif M." Subject: [mobile-ip] some issues with IPv6 mobility draft (sharif) Date: Mon, 9 Apr 2001 15:37:55 -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: I have some issues to discuss with the document: "Mobility Support in IPv6" I would be grateful if people can take a look and make any contructive comments. Thanks. 1. Consider A, B where A is the mobile and B is the correpondent node. A is currently away from its home agent. B is also a mobile node. Suppose A send a BU(A) and moves to its new location. The network is heavily loaded, and B has not yet received the binding update. B also was to move. Thus, similarly, it sends a BU(B) to A, and moves to its new location. The binding updates BU(A) and BU(B) eventually arrives at A's and B's previous locations, respectively. But A and B have already moved. This means that nodes neither A or B will are aware of each other new respective locations. Thus, I believe this is be an erronous condition wrt A and B not knowing each others final destination addresses. 2. In light of the potential problem in (1), I propose that we eliminate all signaling between mobile-to-mobile with respect to Binding Update and Binding Request messages. Instead, after a mobile has moved to a new location: - It only sends a Binding Update to its home agent. - Home agent updates the binding for the mobile. - The home agent maintains a Binding Update List containing all the correspondent nodes that are currently communicating with the mobile. - The home agent (uni)multicasts a Binding Update to all the nodes in that Binding Update List. - The correspondent nodes send back Binding Acknowledgement to the home agent. - Home agent, in turn, sends back Binding Acknowlegement to the mobile. Under this scheme, we eliminate the need for mobile-to-mobile signaling. Only signaling between home agent and the mobile and correspondent(s) nodes are neccessary. Also, something like the scheme above may slove the problem described in (1). 3. If the home agent has failed/reconfigured, I believe that "dynamic home agent discovery" is used to locate a new home agent on the home link. However, it does not guard against failure to the home link itself. For this pupose we need to add fault tolerent capability to guard against link failure. Designate a "primary" home link and a "secondary" home link. Under non failure conditions, primary link is used as the home link. If the primary link fails, then the secondary link is used. New home agent is located. Of course, the number of links can be increased to an arbitrary number. These three points are not intended as final solutions, but as a framework from which a formal solution can be drafted. Best Regards, Sharif Shahrier InterDigital From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 15:49:14 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 PAA15197 for ; Mon, 9 Apr 2001 15:49:13 -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 MAA27603; Mon, 9 Apr 2001 12:48: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 MAA11500; Mon, 9 Apr 2001 12:48:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39JlGK9008584 for ; Mon, 9 Apr 2001 12:47:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39JlGV4008583 for mobile-ip-dist; Mon, 9 Apr 2001 12:47: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39Jl7K9008576 for ; Mon, 9 Apr 2001 12:47: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 MAA11269 for ; Mon, 9 Apr 2001 12:47:06 -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 NAA12645 for ; Mon, 9 Apr 2001 13:47:07 -0600 (MDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Apr 2001 15:46:11 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] some issues with IPv6 mobility draft (sharif) Date: Mon, 9 Apr 2001 15:46:10 -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: > I have some issues to discuss with the document: > > "Mobility Support in IPv6" > > > I would be grateful if people can take a look and make any contructive > comments. Thanks. > > > 1. Consider A, B where A is the mobile and B is the correpondent node. > A is currently > away from its home agent. B is also a mobile node. Suppose A send a > BU(A) and moves > to its new location. The network is heavily loaded, and B has not > yet received the > binding update. B also was to move. Thus, similarly, it sends a > BU(B) to A, and moves > to its new location. The binding updates BU(A) and BU(B) eventually > arrives at A's > and B's previous locations, respectively. But A and B have already > moved. This means > that nodes neither A or B will are aware of each other new > respective locations. > > Thus, I believe this is be an erronous condition wrt A and B not > knowing each others > final destination addresses. > > 2. In light of the potential problem in (1), I propose that we > eliminate all signaling > between mobile-to-mobile with respect to Binding Update and Binding > Request messages. > Instead, after a mobile has moved to a new location: > > - It only sends a Binding Update to its home agent. > - Home agent updates the binding for the mobile. > - The home agent maintains a Binding Update List containing > all the > correspondent nodes that are currently communicating with > the mobile. > - The home agent (uni)multicasts a Binding Update to all the > nodes in > that Binding Update List. > - The correspondent nodes send back Binding Acknowledgement > to the > home agent. > - Home agent, in turn, sends back Binding Acknowlegement to > the mobile. > > Under this scheme, we eliminate the need for mobile-to-mobile > signaling. Only > signaling between home agent and the mobile and correspondent(s) > nodes are > neccessary. Also, something like the scheme above may slove the > problem > described in (1). > > 3. If the home agent has failed/reconfigured, I believe that "dynamic > home agent > discovery" is used to locate a new home agent on the home link. > However, it > does not guard against failure to the home link itself. For this > pupose we > need to add fault tolerent capability to guard against link failure. > > > Designate a "primary" home link and a "secondary" home link. Under > non failure > conditions, primary link is used as the home link. If the primary > link fails, > then the secondary link is used. New home agent is located. Of > course, the > number of links can be increased to an arbitrary number. > > These three points are not intended as final solutions, but as > a framework from which a formal solution can be drafted. > > > Best Regards, > > Sharif Shahrier > InterDigital > > > From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 16:09: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 QAA15790 for ; Mon, 9 Apr 2001 16:09:15 -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 NAA13505; Mon, 9 Apr 2001 13:08: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 NAA17516; Mon, 9 Apr 2001 13:08:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39K5gK9008674 for ; Mon, 9 Apr 2001 13:05:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39K5gtg008673 for mobile-ip-dist; Mon, 9 Apr 2001 13:05: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39K5XK9008666 for ; Mon, 9 Apr 2001 13:05:33 -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 NAA08336 for ; Mon, 9 Apr 2001 13:05:32 -0700 (PDT) Received: from c007.snv.cp.net (c007-h014.c007.snv.cp.net [209.228.33.221]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id NAA11035 for ; Mon, 9 Apr 2001 13:05:30 -0700 (PDT) Received: (cpmta 7960 invoked from network); 9 Apr 2001 13:05:28 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.221) with SMTP; 9 Apr 2001 13:05:28 -0700 X-Sent: 9 Apr 2001 20:05:28 GMT Message-ID: <00d201c0c130$48b0a120$6501a8c0@philneum> From: "Phil Neumiller" To: References: Subject: Re: [mobile-ip] some issues with IPv6 mobility draft (sharif) Date: Mon, 9 Apr 2001 15:04:27 -0500 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: Sharif, Doesn't the BU get sent shortly *after* every move? So the condition where you send the BU and then move seems to be a rare case or perhaps when handoffs are occuring in *rapid* succession (i.e. faster than the latency between MN_A and CN_B). If the ping time between MN_A and CN_B is longer (on average) than the inter-handoff time MIP breaks in many awful ways right (i.e. it doesn't work) right? ----- Original Message ----- From: "Shahrier, Sharif M." To: Sent: Monday, April 09, 2001 2:46 PM Subject: [mobile-ip] some issues with IPv6 mobility draft (sharif) > > > I have some issues to discuss with the document: > > > > "Mobility Support in IPv6" > > > > > > I would be grateful if people can take a look and make any contructive > > comments. Thanks. > > > > > > 1. Consider A, B where A is the mobile and B is the correpondent node. > > A is currently > > away from its home agent. B is also a mobile node. Suppose A send a > > BU(A) and moves > > to its new location. The network is heavily loaded, and B has not > > yet received the > > binding update. B also was to move. Thus, similarly, it sends a > > BU(B) to A, and moves > > to its new location. The binding updates BU(A) and BU(B) eventually > > arrives at A's > > and B's previous locations, respectively. But A and B have already > > moved. This means > > that nodes neither A or B will are aware of each other new > > respective locations. > > > > Thus, I believe this is be an erronous condition wrt A and B not > > knowing each others > > final destination addresses. > > > > 2. In light of the potential problem in (1), I propose that we > > eliminate all signaling > > between mobile-to-mobile with respect to Binding Update and Binding > > Request messages. > > Instead, after a mobile has moved to a new location: > > > > - It only sends a Binding Update to its home agent. > > - Home agent updates the binding for the mobile. > > - The home agent maintains a Binding Update List containing > > all the > > correspondent nodes that are currently communicating with > > the mobile. > > - The home agent (uni)multicasts a Binding Update to all the > > nodes in > > that Binding Update List. > > - The correspondent nodes send back Binding Acknowledgement > > to the > > home agent. > > - Home agent, in turn, sends back Binding Acknowlegement to > > the mobile. > > > > Under this scheme, we eliminate the need for mobile-to-mobile > > signaling. Only > > signaling between home agent and the mobile and correspondent(s) > > nodes are > > neccessary. Also, something like the scheme above may slove the > > problem > > described in (1). > > > > 3. If the home agent has failed/reconfigured, I believe that "dynamic > > home agent > > discovery" is used to locate a new home agent on the home link. > > However, it > > does not guard against failure to the home link itself. For this > > pupose we > > need to add fault tolerent capability to guard against link failure. > > > > > > Designate a "primary" home link and a "secondary" home link. Under > > non failure > > conditions, primary link is used as the home link. If the primary > > link fails, > > then the secondary link is used. New home agent is located. Of > > course, the > > number of links can be increased to an arbitrary number. > > > > These three points are not intended as final solutions, but as > > a framework from which a formal solution can be drafted. > > > > > > Best Regards, > > > > Sharif Shahrier > > InterDigital > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 16:38: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 QAA16578 for ; Mon, 9 Apr 2001 16:38: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 NAA06496; Mon, 9 Apr 2001 13:37: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 NAA21609; Mon, 9 Apr 2001 13:37:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39Ka4K9008736 for ; Mon, 9 Apr 2001 13:36:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39Ka4i1008735 for mobile-ip-dist; Mon, 9 Apr 2001 13:36: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39KZtK9008728 for ; Mon, 9 Apr 2001 13:35:55 -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 NAA15753 for ; Mon, 9 Apr 2001 13:35:53 -0700 (PDT) Received: from idcpa4.pa.interdigital.com ([12.32.197.142]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA02708 for ; Mon, 9 Apr 2001 13:35:39 -0700 (PDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Apr 2001 16:34:58 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'mobile-ip@sunroof.eng.sun.com'" Cc: "Kiernan, Brian G." Subject: RE: [mobile-ip] some issues with IPv6 mobility draft (sharif) Date: Mon, 9 Apr 2001 16:34:57 -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: Phil, I checked the draft section 10.8. It doesn't seem to specify when the BU is sent, i.e. before or after. I guess this is determined in part by handoff protocols. Also, I don't believe that sending the BU after the move will solve the problem. For example, suppose A and B move at the same time. After the move they both send a BU to each others respective *original* destinations. Thus, again neither will be advised of their new locations. Best Regards, Sharif Shahrier InterDigital Sharif, Doesn't the BU get sent shortly *after* every move? So the condition where you send the BU and then move seems to be a rare case or perhaps when handoffs are occuring in *rapid* succession (i.e. faster than the latency between MN_A and CN_B). If the ping time between MN_A and CN_B is longer (on average) than the inter-handoff time MIP breaks in many awful ways right (i.e. it doesn't work) right? ----- Original Message ----- From: "Shahrier, Sharif M." To: Sent: Monday, April 09, 2001 2:46 PM Subject: [mobile-ip] some issues with IPv6 mobility draft (sharif) > > > I have some issues to discuss with the document: > > > > "Mobility Support in IPv6" > > > > > > I would be grateful if people can take a look and make any contructive > > comments. Thanks. > > > > > > 1. Consider A, B where A is the mobile and B is the correpondent node. > > A is currently > > away from its home agent. B is also a mobile node. Suppose A send a > > BU(A) and moves > > to its new location. The network is heavily loaded, and B has not > > yet received the > > binding update. B also was to move. Thus, similarly, it sends a > > BU(B) to A, and moves > > to its new location. The binding updates BU(A) and BU(B) eventually > > arrives at A's > > and B's previous locations, respectively. But A and B have already > > moved. This means > > that nodes neither A or B will are aware of each other new > > respective locations. > > > > Thus, I believe this is be an erronous condition wrt A and B not > > knowing each others > > final destination addresses. > > > > 2. In light of the potential problem in (1), I propose that we > > eliminate all signaling > > between mobile-to-mobile with respect to Binding Update and Binding > > Request messages. > > Instead, after a mobile has moved to a new location: > > > > - It only sends a Binding Update to its home agent. > > - Home agent updates the binding for the mobile. > > - The home agent maintains a Binding Update List containing > > all the > > correspondent nodes that are currently communicating with > > the mobile. > > - The home agent (uni)multicasts a Binding Update to all the > > nodes in > > that Binding Update List. > > - The correspondent nodes send back Binding Acknowledgement > > to the > > home agent. > > - Home agent, in turn, sends back Binding Acknowlegement to > > the mobile. > > > > Under this scheme, we eliminate the need for mobile-to-mobile > > signaling. Only > > signaling between home agent and the mobile and correspondent(s) > > nodes are > > neccessary. Also, something like the scheme above may slove the > > problem > > described in (1). > > > > 3. If the home agent has failed/reconfigured, I believe that "dynamic > > home agent > > discovery" is used to locate a new home agent on the home link. > > However, it > > does not guard against failure to the home link itself. For this > > pupose we > > need to add fault tolerent capability to guard against link failure. > > > > > > Designate a "primary" home link and a "secondary" home link. Under > > non failure > > conditions, primary link is used as the home link. If the primary > > link fails, > > then the secondary link is used. New home agent is located. Of > > course, the > > number of links can be increased to an arbitrary number. > > > > These three points are not intended as final solutions, but as > > a framework from which a formal solution can be drafted. > > > > > > Best Regards, > > > > Sharif Shahrier > > InterDigital > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 16:40:32 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16666 for ; Mon, 9 Apr 2001 16:40: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 NAA15709; Mon, 9 Apr 2001 13:39: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 NAA16534; Mon, 9 Apr 2001 13:38:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39KaTK9008746 for ; Mon, 9 Apr 2001 13:36:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39KaTkH008745 for mobile-ip-dist; Mon, 9 Apr 2001 13:36: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39KaHK9008738 for ; Mon, 9 Apr 2001 13:36:17 -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 NAA23773 for ; Mon, 9 Apr 2001 13:36:15 -0700 (PDT) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA02901 for ; Mon, 9 Apr 2001 13:36:00 -0700 (PDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Mon, 9 Apr 2001 14:00:03 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Apr 2001 14:00:00 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E4355CA1B@crchy271.us.nortel.com> From: "Rambabu Tummala" To: "'hchaskar@hotmail.com'" Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Requirements Draft for Mobile IP QoS - Invitation to Volunteer Date: Mon, 9 Apr 2001 13:59:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C127.45D20150" Sender: owner-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_01C0C127.45D20150 Content-Type: text/plain; charset="iso-8859-1" Hemant, I would like to volunteer. Please count me in. Regards, Rambabu Tummala Nortel Networks ESN 444-8970 External (972)684-8970 -----Original Message----- From: Hemant Chaskar [mailto:hchaskar@hotmail.com] Sent: Thursday, April 05, 2001 4:47 PM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Requirements Draft for Mobile IP QoS - Invitation to Volunteer 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 ------_=_NextPart_001_01C0C127.45D20150 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Requirements Draft for Mobile IP QoS - = Invitation to Volunteer

Hemant,

I would like to volunteer.  Please count me = in.

Regards,

Rambabu Tummala
Nortel Networks
ESN 444-8970
External (972)684-8970


-----Original Message-----
From: Hemant Chaskar [mailto:hchaskar@hotmail.com]
Sent: Thursday, April 05, 2001 4:47 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Requirements Draft for Mobile = IP QoS - Invitation
to Volunteer


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

------_=_NextPart_001_01C0C127.45D20150-- From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 16:48:26 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16804 for ; Mon, 9 Apr 2001 16:48:26 -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 NAA19355; Mon, 9 Apr 2001 13:46: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 NAA27642; Mon, 9 Apr 2001 13:46:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39Kj5K9008829 for ; Mon, 9 Apr 2001 13:45:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39Kj49t008828 for mobile-ip-dist; Mon, 9 Apr 2001 13:45: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39KitK9008821 for ; Mon, 9 Apr 2001 13:44:56 -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 NAA27333 for ; Mon, 9 Apr 2001 13:44:54 -0700 (PDT) Received: from idcpa4.pa.interdigital.com ([12.32.197.142]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA07992 for ; Mon, 9 Apr 2001 13:44:38 -0700 (PDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Apr 2001 16:43:32 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] some issues with IPv6 mobility draft (sharif) Date: Mon, 9 Apr 2001 16:43:31 -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: > I have some issues to discuss with the document: > > "Mobility Support in IPv6" > > > I would be grateful if people can take a look and make any contructive > comments. Thanks. > > > 1. Consider A, B where A is the mobile and B is the correpondent node. > A is currently > away from its home agent. B is also a mobile node. Suppose A send a > BU(A) and moves > to its new location. The network is heavily loaded, and B has not > yet received the > binding update. B also was to move. Thus, similarly, it sends a > BU(B) to A, and moves > to its new location. The binding updates BU(A) and BU(B) eventually > arrives at A's > and B's previous locations, respectively. But A and B have already > moved. This means > that nodes neither A or B will are aware of each other new > respective locations. > > Thus, I believe this is be an erronous condition wrt A and B not > knowing each others > final destination addresses. > > 2. In light of the potential problem in (1), I propose that we > eliminate all signaling > between mobile-to-mobile with respect to Binding Update and Binding > Request messages. > Instead, after a mobile has moved to a new location: > > - It only sends a Binding Update to its home agent. > - Home agent updates the binding for the mobile. > - The home agent maintains a Binding Update List containing > all the > correspondent nodes that are currently communicating with > the mobile. > - The home agent (uni)multicasts a Binding Update to all the > nodes in > that Binding Update List. > - The correspondent nodes send back Binding Acknowledgement > to the > home agent. > - Home agent, in turn, sends back Binding Acknowlegement to > the mobile. > > Under this scheme, we eliminate the need for mobile-to-mobile > signaling. Only > signaling between home agent and the mobile and correspondent(s) > nodes are > neccessary. Also, something like the scheme above may slove the > problem > described in (1). > > 3. If the home agent has failed/reconfigured, I believe that "dynamic > home agent > discovery" is used to locate a new home agent on the home link. > However, it > does not guard against failure to the home link itself. For this > pupose we > need to add fault tolerent capability to guard against link failure. > > > Designate a "primary" home link and a "secondary" home link. Under > non failure > conditions, primary link is used as the home link. If the primary > link fails, > then the secondary link is used. New home agent is located. Of > course, the > number of links can be increased to an arbitrary number. > > These three points are not intended as final solutions, but as > a framework from which a formal solution can be drafted. > > > Best Regards, > > Sharif Shahrier > InterDigital > > > From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 17:06:10 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17091 for ; Mon, 9 Apr 2001 17:06:10 -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 OAA00078; Mon, 9 Apr 2001 14:04: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 OAA29927; Mon, 9 Apr 2001 14:04:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39L3OK9008979 for ; Mon, 9 Apr 2001 14:03:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39L3ODS008978 for mobile-ip-dist; Mon, 9 Apr 2001 14:03:24 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39L3FK9008971 for ; Mon, 9 Apr 2001 14:03:15 -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 OAA02658 for ; Mon, 9 Apr 2001 14:03:14 -0700 (PDT) Received: from c007.snv.cp.net (c007-h013.c007.snv.cp.net [209.228.33.220]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA27363 for ; Mon, 9 Apr 2001 14:03:12 -0700 (PDT) Received: (cpmta 20664 invoked from network); 9 Apr 2001 14:03:08 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.220) with SMTP; 9 Apr 2001 14:03:08 -0700 X-Sent: 9 Apr 2001 21:03:08 GMT Message-ID: <011d01c0c138$56f80cc0$6501a8c0@philneum> From: "Phil Neumiller" To: Cc: "Kiernan, Brian G." References: Subject: Re: [mobile-ip] some issues with IPv6 mobility draft (sharif) Date: Mon, 9 Apr 2001 16:02:08 -0500 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: Hi Sharif, *If* this is a real problem and it certainly seems to be, I guess I would like to propose a solution that does *not* involve the HA. What COULD be done is to perhaps send the hand off candidate *list* (collection of HA/FA advertisements) heard by MN_A in the BU to CN_B. Then CN_B could multi-cast traffic temporarily to all the "advertised" new homes. I would prefer this solution since it requires only a small change on the MN not at HA. Thanks, Phil Neumiller ----- Original Message ----- From: "Shahrier, Sharif M." To: Cc: "Kiernan, Brian G." Sent: Monday, April 09, 2001 3:34 PM Subject: RE: [mobile-ip] some issues with IPv6 mobility draft (sharif) > Phil, > > I checked the draft section 10.8. It doesn't seem to specify when > the BU > is sent, i.e. before or after. I guess this is determined in part by > handoff > protocols. > > Also, I don't believe that sending the BU after the move will solve > the > problem. For example, suppose A and B move at the same time. After > the move > they both send a BU to each others respective *original* > destinations. Thus, > again neither will be advised of their new locations. > > Best Regards, > > Sharif Shahrier > InterDigital > > Sharif, > > Doesn't the BU get sent shortly *after* every move? So the condition where > you send the BU and then move seems to be a rare case or perhaps when > handoffs are occuring in *rapid* succession (i.e. faster than the latency > between MN_A and CN_B). If the ping time between MN_A and CN_B > is longer (on average) than the inter-handoff time MIP breaks in many > awful ways right (i.e. it doesn't work) right? > > From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 17:25:45 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17312 for ; Mon, 9 Apr 2001 17:25: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 OAA09605; Mon, 9 Apr 2001 14:25:09 -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 OAA07433; Mon, 9 Apr 2001 14:25:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39LNbK9009088 for ; Mon, 9 Apr 2001 14:23:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39LNbBg009087 for mobile-ip-dist; Mon, 9 Apr 2001 14:23: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 eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39LNRK9009080 for ; Mon, 9 Apr 2001 14:23:28 -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 RAA21959 for ; Mon, 9 Apr 2001 17:23:28 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA10046 for mobile-ip@sunroof.eng.sun.com; Mon, 9 Apr 2001 17:23:39 -0400 (EDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f38MTJK9005299 for ; Sun, 8 Apr 2001 15:29:20 -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 PAA23652 for ; Sun, 8 Apr 2001 15:29:20 -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 PAA27059 for ; Sun, 8 Apr 2001 15:29:18 -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 f38MTII03729 for ; Mon, 9 Apr 2001 00:29:18 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Mon Apr 09 00:29:19 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Apr 2001 00:24:54 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBD68@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] MIP v6 Regional Registration - identifying requir ements Date: Mon, 9 Apr 2001 00:29:17 +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: (The authors of HMIPv6 prepared some answers and Claude was meant to send it but I guess it was lost. Sorry if you get multiple copies). Hello Phil, This is a great start. Thanks for taking the time. We're not sure why it is referred to as RR but anyhow that's just a name and we all know what you mean (Localised moility management). We will only answer to the validity of the requirements and not to where HMIPv6 stands in terms of supporting a requirement. We think it is better to first agree on a set of requirements and take it from there. I think I've finally caught up on all the mail about regional registrations for MIP v6 and HMIP. There seems to be significant concerns about the task to be accomplished and the specific approach that is specified in the HMIP draft. A short list of concerns include worries about introducing single points of failure, whether or not multiple levels of hierarchy are needed, the amount of signaling and tunneling overhead that is implied, the => We believe we got some confirmation for ROHC and CT folks that tunnelling will not be an issue. relevance of load balancing and the particular metrics in the HMIP draft, => Based on the comments received in Minneapolis we thought it would be good to have load balancing (for HA/MAP/CN) in a separate draft. Unless there is consensus against this, we will do that. Here's a short list of requirements drawn from comments received over the last month or so and from the HMIP draft that the working group participants can use as a basis for discussion. Please understand that this is not the list of requirements I believe are needed => Understood. => Here are some comments. Hopefully these comments should cause the people who raised the requirements to provide some reasons for raising them. => BTW, the single point of failure issue is not an HMIP specific problem. However HMIPv6 has less single points of failure than other proopsals. We would like to add two more requirements. 0) Localised mobility management should provide the same level of mobility management support as in the basic MIPv6 specifiation. The mobility management functions supported in MIPv6 must not be reduced in such mechanism. 0.5) The provided mechanism must interwork with existing MIPv6, IPv6 and the proposed mechanisms for SA establishment in MIPv6. 1) Regional registration shall be introduced to minimize the signaling traffic to the home agent or correspondent nodes for intra-domain mobility => Agreed 2) Regional registration shall not introduce new overhead on links between the mobile and the regional registration agents => We're not sure what this means. However if it means no more overhead than a BU then it's seems like a reasonable requirement. 3) Connectivity to the mobiles shall not be interrupted in the presence of the failure of regional registration agents => Agreed. Although this should trigger some redundancy work in the MIP WG. But it should be kept as a target. 4) Regional registration shall scale to support millions of nodes in a visited network => Agreed. 5) Regional registration shall be secure against malicious behavior from visiting mobiles => Agreed. 6) Regional registration shall allow multiple levels of hierarchy => We can't see a reason for this requirement. We think it's OK if we want to support mobile networks but we don't think this requirement should be placed for all cases. We never got an answer for the technical merits of this requirement. It would be good to know why. Otherwise we'd like to remove this requirement. 7) Regional registration shall support fast handoffs => If that means coexist with the current FH proposal then we agree. 8) Regional registration shall not require changes to the mobile node, the home agent, or correspondent nodes => We can understand the HA and CN, but no changes in the MN seems strange. Is this possible ? 9) Regional registration shall not introduce host routes in routing tables => Agreed. As long as a Binding Cache entry is not regarded as a host route ? strictly speaking. Hesham, Claude and Karim From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 17:35:01 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17469 for ; Mon, 9 Apr 2001 17:35:00 -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 OAA13881; Mon, 9 Apr 2001 14:34:09 -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 OAA09606; Mon, 9 Apr 2001 14:34:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39LWWK9009201 for ; Mon, 9 Apr 2001 14:32:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39LWWkQ009198 for mobile-ip-dist; Mon, 9 Apr 2001 14:32: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39LWGK9009187 for ; Mon, 9 Apr 2001 14:32:16 -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 OAA29253 for ; Mon, 9 Apr 2001 14:32:16 -0700 (PDT) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA03391 for ; Mon, 9 Apr 2001 14:32:01 -0700 (PDT) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Mon Apr 9 17:28:07 EDT 2001 Received: from blhothuelpc (thuelpc [135.180.240.114]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id RAA24614 for ; Mon, 9 Apr 2001 17:30:29 -0400 (EDT) From: "Sandy Thuel" To: "Sun. Com" Subject: [mobile-ip] dynamic home addressing as a WG item?? Date: Mon, 9 Apr 2001 17:27:48 -0400 Message-ID: <00d701c0c13b$ecd92960$72f0b487@dnrc.belllabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-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 The following message never made it to the mailing list so I'm resending it. -----Original Message----- From: James Kempf [mailto:james.kempf@sun.com] Sent: Thursday, April 05, 2001 9:17 AM To: Sandy Thuel; mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] dynamic home addressing as a WG item?? At 12:14 PM 4/4/01 -0400, Sandy Thuel wrote: >I hear clearly that you'd rather NOT use DHCP >but you haven't yet answered the question of >whether or not configuration options are important. >Are you implying that "address provisioning" is >all that matters and other configuration options >are NOT important? Or are you saying that no >matter what configuration state is needed, Mobile >IP should provision it? If by "configuration options" you mean service discovery, then I think there are better ways to do this (DNS SRV RR interdomain, SLP intradomain, maybe LDAP also). I think a case can also be made for provisioning a mobile node's service access information via AAA if the mobile node is away from home and needs to obtain service access information from the home domain. This is one case that I have some difficulty seeing DHCP solving without massively twisting it from its initial design center. Did you have anything else in mind besides service discovery? >Good observation. Users that power-up devices >frequently are likely to be less tolerant of >configuration latency than those who keep their >devices powered on for extended periods of time >(e.g., cellphones). But do you have any idea >as to what latency is considered tolerable in >either case? This is a human factors question I can't really answer. Compare the amount of time it takes for your mobile phone to come up when you first turn it on with how long it takes Windows to boot on your laptop. Somewhere in the middle, the latency becomes annoying if you tend to turn the device on and off frequently. >I didn't say that any protocol changes are >necessary (unless the MN requires anything more than >a home address, as per my comment on the following >question). What is needed is some *implementation* >changes on home agents to provide DHCP >proxy services. As for what this implementation >entails, one solution, as you implicitly suggest, >is to have an API between the HA and a co-located >DHCP proxy agent. Rather than keeping the HA >and DHCP proxies logically separated through an >API, the implementation of DHCP proxies >could be more tightly integrated with the HA. >The issue here is not to debate on which is the >best way to implement proxy services on home >agents but to discuss whether or not ANY >implementation changes to HA's to provide such >services is a feasible requirement at this stage, >when MIPv4 is already being deployed. An API doesn't necessarily mean that the DHCP proxy is physically separate, the API may be provided by the operating system. But I don't see any problem with having the HA do DHCP out the back end, this is an implementation choice. >So you're implying once again that you don't >care about any other configuration besides an >IP address, correct? Note that if you DO care >about anything other than an IP address, there is >no other recourse but to extend Mobile IP to >allow the MN to ask for it and get it from a >HA. As I mentioned above, I think there are other, better ways of provisioning service discovery on mobile nodes. jak From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 17: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 RAA17531 for ; Mon, 9 Apr 2001 17: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 OAA19403; Mon, 9 Apr 2001 14:31:25 -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 OAA07435; Mon, 9 Apr 2001 14:31:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39LUAK9009171 for ; Mon, 9 Apr 2001 14:30:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39LUAaG009170 for mobile-ip-dist; Mon, 9 Apr 2001 14:30: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39LU1K9009163 for ; Mon, 9 Apr 2001 14:30: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 OAA05598 for ; Mon, 9 Apr 2001 14:30:00 -0700 (PDT) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id PAA10471 for ; Mon, 9 Apr 2001 15:30:01 -0600 (MDT) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Mon Apr 9 17:28:13 EDT 2001 Received: from blhothuelpc (thuelpc [135.180.240.114]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id RAA24516 for ; Mon, 9 Apr 2001 17:28:22 -0400 (EDT) From: "Sandy Thuel" To: Subject: RE: FW: [mobile-ip] dynamic home addressing as a WG item?? Date: Mon, 9 Apr 2001 17:25:41 -0400 Message-ID: <00d601c0c13b$a0de5350$72f0b487@dnrc.belllabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <200104091733.KAA00988@nasnfs.Eng.Sun.COM> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-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, > Here is a question for you Sandy. > > Is it at all possible for Mobile IP to provide the mobile's home address, > as it is done today, To set the record straight: where does Mobile IP get the home address in your model? From an address pool in the HA (i.e., NOT through DHCP)? > and have the mobile issue a DHCP message NOT > to request > an IP address, but only to retrieve configuration information. So it would > provide its address, but it is only looking for provisioning services. Although the DHCPINFORM message in the DHCP standard was created to enable this very thing (i.e., a node with an externally configured address to query for some other local configuration parameters), DHCP client/server implementations didn't support it until very recently. > > That would make this whole thing so much simpler. > I don't agree that a model where you get the address from the HA and configuration options from DHCP would make this much simpler for the following reason. Once the HA starts allocating addresses you have to now worry about: * provisioning/sizing the HA address pool * setting up some mechanism for reclaiming HA-allocated addresses (the equivalent of DHCP lease renewals) when the client no longer needs the address or when the HA who conferred an address has died. On the latter point, do you assume the home address given by the HA is leased? If so, do you suggest changing the Mobile IP standard to require registration renewals while the mobile node is at home (just to renew the home address lease)? If the address is not leased, how do you prevent rogue address problems? Thanks for your comments! Sandy > PatC > >The following message never made it to the mailing > >list so I'm resending it. > > > >-----Original Message----- > >From: Sandy Thuel [mailto:thuel@lucent.com] > >Sent: Thursday, April 05, 2001 11:32 AM > >To: James Kempf; mobile-ip@sunroof.eng.sun.com; > >mobile-ip@sunroof.eng.sun.com > >Subject: RE: [mobile-ip] dynamic home addressing as a WG item?? > > > > > > > >Hi James, > > > > Please see my comment in-line. > > > >> >I hear clearly that you'd rather NOT use DHCP > >> >but you haven't yet answered the question of > >> >whether or not configuration options are important. > >> >Are you implying that "address provisioning" is > >> >all that matters and other configuration options > >> >are NOT important? Or are you saying that no > >> >matter what configuration state is needed, Mobile > >> >IP should provision it? > >> > >> If by "configuration options" you mean service discovery, > >> then I think there are better ways to do this (DNS SRV RR > >> interdomain, SLP intradomain, maybe LDAP also). > > > >No. I wasn't referring to service discovery but > >to parameters which are typically associated > >with DHCP options [RFC2132] such as subnet mask, > >domain name, gateway router(s), DNS server(s), > >NTP server(s), etc. Please correct me if I'm > >wrong but my understanding was that these service > >discovery protocols don't allocate all these > >parameters. And even if they do, what is > >the extent of their deployment and support in > >today's networks to rely on them for mobile > >configuration support? > > > >> > >> I think a case can also be made for provisioning a mobile > >> node's service access information via AAA if the mobile > >> node is away from home and needs to obtain service > >> access information from the home domain. This is > >> one case that I have some difficulty seeing DHCP solving > >> without massively twisting it from its initial design center. > > > >I agree that AAA is, in principle, a promising > >candidate to be a repository for the configuration > >options I'm referring to and it could be a better > >alternative than DHCP. Do you know of any efforts > >to extend the AAA infrastructure to support this? > >In any case, if I want a solution for today, I > >still think DHCP is the only game in town... > > > >> > >> >Good observation. Users that power-up devices > >> >frequently are likely to be less tolerant of > >> >configuration latency than those who keep their > >> >devices powered on for extended periods of time > >> >(e.g., cellphones). But do you have any idea > >> >as to what latency is considered tolerable in > >> >either case? > >> > >> This is a human factors question I can't really answer. > >> Compare the amount of time it takes for your mobile > >> phone to come up when you first turn it on with how > >> long it takes Windows to boot on your laptop. Somewhere > >> in the middle, the latency becomes annoying if you > >> tend to turn the device on and off frequently. > >> > > > >If improving on a Windows bootup time is > >our baseline, configuration latency is > >not a problem at all :-) > > > >> > >> >I didn't say that any protocol changes are > >> >necessary (unless the MN requires anything more than > >> >a home address, as per my comment on the following > >> >question). What is needed is some *implementation* > >> >changes on home agents to provide DHCP > >> >proxy services. As for what this implementation > >> >entails, one solution, as you implicitly suggest, > >> >is to have an API between the HA and a co-located > >> >DHCP proxy agent. Rather than keeping the HA > >> >and DHCP proxies logically separated through an > >> >API, the implementation of DHCP proxies > >> >could be more tightly integrated with the HA. > >> >The issue here is not to debate on which is the > >> >best way to implement proxy services on home > >> >agents but to discuss whether or not ANY > >> >implementation changes to HA's to provide such > >> >services is a feasible requirement at this stage, > >> >when MIPv4 is already being deployed. > >> > >> An API doesn't necessarily mean that the DHCP > >> proxy is physically separate, the API may be > >> provided by the operating system. > > > >Yes. That's what I meant when I said the DHCP > >proxy and HA can be "logically" separated by > >an API. > > > >> > >> But I don't see any problem with having the > >> HA do DHCP out the back end, this is > >> an implementation choice. > > > >Agreed. Now, we have agreed that there are > >different ways to implement this. This settles > >affirmatively the question as to whether or not > >it is implementable. The more important question > >I'm trying to get at is whether or not it is > >feasible to require HA's to support this (picking > >a favorite implementation strategy of choice). > >Any thoughts? > > > >> > >> > >> >So you're implying once again that you don't > >> >care about any other configuration besides an > >> >IP address, correct? Note that if you DO care > >> >about anything other than an IP address, there is > >> >no other recourse but to extend Mobile IP to > >> >allow the MN to ask for it and get it from a > >> >HA. > >> > >> As I mentioned above, I think there are other, better > >> ways of provisioning service discovery on mobile > >> nodes. > > > >I hope my clarification above on what I was > >referring to as configuration options clarifies > >what I meant by this question. > > > >Thanks, > >Sandy > > From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 17:41:42 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 RAA17605 for ; Mon, 9 Apr 2001 17:41:42 -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 OAA23355; Mon, 9 Apr 2001 14:36: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 OAA10142; Mon, 9 Apr 2001 14:36:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39LYYK9009220 for ; Mon, 9 Apr 2001 14:34:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39LYY1v009219 for mobile-ip-dist; Mon, 9 Apr 2001 14:34:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39LYRK9009212 for ; Mon, 9 Apr 2001 14:34:27 -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 RAA23915 for ; Mon, 9 Apr 2001 17:34:27 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA10239 for mobile-ip@sunroof.eng.sun.com; Mon, 9 Apr 2001 17:34:38 -0400 (EDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33FOBIm021796 for ; Tue, 3 Apr 2001 08:24:11 -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 IAA06699 for ; Tue, 3 Apr 2001 08:24:11 -0700 (PDT) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id IAA29082 for ; Tue, 3 Apr 2001 08:24:10 -0700 (PDT) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Tue Apr 3 11:20:15 EDT 2001 Received: from valjean.dnrc.bell-labs.com (valjean [135.180.240.120]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id LAA16471 for ; Tue, 3 Apr 2001 11:22:32 -0400 (EDT) Received: (from salga@localhost) by valjean.dnrc.bell-labs.com (8.11.0/8.8.7) id f33FMME25716 for mobile-ip@sunroof.eng.sun.com; Tue, 3 Apr 2001 11:22:22 -0400 Date: Tue, 3 Apr 2001 11:22:22 -0400 From: Luca Salgarelli To: mobile-ip@sunroof.eng.sun.com Subject: Re: Some comments on: [mobile-ip] dynamic home addressing as a WG item?? Message-ID: <20010403112222.R3284@bell-labs.com> Mail-Followup-To: mobile-ip@sunroof.eng.sun.com References: <006101c0bbbd$1184e8f0$72f0b487@dnrc.belllabs.com> <017101c0bbd8$4270e980$6501a8c0@philneum> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <017101c0bbd8$4270e980$6501a8c0@philneum>; from neumiller@telocity.com on Mon, Apr 02, 2001 at 07:51:39PM -0500 X-Organization: Bell Laboratories Sender: owner-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 Phil. Although my K-mart crystal ball would tend to agree with yours if I look at some distant future :-), I would argue that today's and mid-term future networks are going to be largely based on IPv4. In these networks, DHCP seems to be the protocol of choice to dynamically configure clients. For example, almost all the deployments I know of 802.11b use DHCP to configure clients. If we add mobility support to those networks (i.e. MIPv4), I think that making MIPv4 gracefully interoperate with DHCP is not an option: it is a requirement. > > 2) How important is it to minimize the power-up > > configuration latency of a mobile node? > > Are you are saying that DHCP would be a signficant > portion of this? What proportion? Do you have a guess? > Do you have analysis or measurements? Would it be milliseconds, > seconds? Depending on the link layer used, power up > configuration has a huge standard deviation all on its own. > Of course we must add DHCP latency onto that directly. The DHCP proportion here is simple: a DHCP transaction takes 2 RTTs. > > 4) How do you feel about the idea of adding > > DHCP-specific extensions to Mobile IP > > NO. This is *EVIL*, and a very terrible idea. I never > want to see these words again! :-) No really, this is probably > not necessary. At least in the protocol sense. Could this not I agree with you. Luca On Mon, Apr 02, 2001 at 07:51:39PM -0500, Phil Neumiller wrote: > Hi Sandy, > > Some comments below (this is so long that you might > want to get a beverage). > > ----- Original Message ----- > From: "Sandy Thuel" > To: > Cc: > > Hi Folks, > > > > > > 1) What is the real value of DHCP options to mobile > > nodes? > > I guess I would even go a step further and question > what is the real value of DHCP itself to mobile nodes? > In the short term, it appears to be of quite high value. > > However... > > In my K-mart crystal ball (kind of cracked and fuzzy) I > see lots of cheap wireless devices that will be used to > living in MANETs *or* in infrastructures in the future. I see > this big train wreck of who gets to pick the mobile's IP > address coming. I suppose, if its a Windows type of > box, it will be UPnP, if its Bluetooth type of device, > well um, we need to wait until the BT SIG releases the > next spec, if its an 802.11b device, I don' know of > *any* commercial MANETs on 802.11 (know of some > in labs!), if its a 3G device I am not sure yet but, > I am pretty sure you can rule out DHCP on a > CDMA radio!..., then we have zeroconf in there too > along with SLP, Jini, and all kinds of other stuff trying > to figure out what the heck is going on and what the IP > addr and COA is (did I forget to mention ou friend > MIP acting as an MN). If it starts out as a MANET > MN and wants to hand up to being a full fledged up routable > fixed citizen like in a docking station I don't know what > the best answer is currently. Thank goodness we don't > have micro-mobility to worry about anymore!!! At least > for now... > > In the current home or enterprise WLAN/WPAN > markets the sheer simplicity of DHCP brings joy > to many people's hearts. However, in my crystal > ball I see a darker future of sheer chaos. DHCP is > basically founded upon a client server model, an > anachronism in today's SAN infested B2B IP planet > that is rapidly going peer-2-peer, as fast as you can > say gnutella (that's April 2001 for Napster). > > So what are we left with? Burning IEEE MAC > addresses into the foreheads of everywireless device and > doing RARPs? MANET addressing (a matter with its own > set of controversies)? Or a host of other jihads that > I am sure could be enumerated (please don't). > > > 2) How important is it to minimize the power-up > > configuration latency of a mobile node? > > Are you are saying that DHCP would be a signficant > portion of this? What proportion? Do you have a guess? > Do you have analysis or measurements? Would it be milliseconds, > seconds? Depending on the link layer used, power up > configuration has a huge standard deviation all on its own. > Of course we must add DHCP latency onto that directly. > > > > > 3) How feasible do you think it is to > > require changes on Mobile IP home agents > > to provide a new service (e.g., DHCP proxy > > service support)? > > Would need to be done in FAs too (for MIPv4)? > > > > > 4) How do you feel about the idea of adding > > DHCP-specific extensions to Mobile IP > > NO. This is *EVIL*, and a very terrible idea. I never > want to see these words again! :-) No really, this is probably > not necessary. At least in the protocol sense. Could this not > be done by some clever spoofing inside an AR where the > DHCP server spoofs the FA/HA but hands out the actual > address? I know this is kind of an implementor's hack, but > to change MIP enmeshes something so systemic as > DHCP with something so systemic with MIP and it makes > me say want to say YUCK really loud. I actually prefer the > coding hack to the design hack! > > When I re-read my comments I find they are of extremely > limited use (low S/N ratio) so in summary let me give you > my recommendation (worth about 2 cents these days): > > 1). We must figure out who wins the "I assign the address > to the MN battle" in all possible scenarios including > handoffs from MANETS (infrastructure-less) to > MIP supported networks and handins and outs of > zeroconf/DHCP/slp/UPnP/(MIP ^ MANET) supported > subnets [do all the logical permutations]. > > 2). Who is asking for DHCP support now, i.e. who is the > IETF customer for this work? Based on this, is this > work justified or will it substantially improve routing > configuration to/of mobile devices in the global Internet > for the long term. > > My fear is that DHCP may become a thing of the past and > things like BURP will open more doors to our future by > allowing non-local secure authentication (which normally > preceeds configuration) but we will see. > > Best regards, > > Phil From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 17:42:55 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17639 for ; Mon, 9 Apr 2001 17:42: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 OAA14198; Mon, 9 Apr 2001 14:34: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 OAA29830; Mon, 9 Apr 2001 14:34:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39LWVK9009199 for ; Mon, 9 Apr 2001 14:32:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39LWUuM009197 for mobile-ip-dist; Mon, 9 Apr 2001 14:32: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39LWEK9009183 for ; Mon, 9 Apr 2001 14: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 OAA06134 for ; Mon, 9 Apr 2001 14:32:15 -0700 (PDT) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA03369 for ; Mon, 9 Apr 2001 14:31:59 -0700 (PDT) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Mon Apr 9 17:28:09 EDT 2001 Received: from blhothuelpc (thuelpc [135.180.240.114]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id RAA24619 for ; Mon, 9 Apr 2001 17:30:31 -0400 (EDT) From: "Sandy Thuel" To: "Sun. Com" Subject: [mobile-ip] dynamic home addressing as a WG item?? Date: Mon, 9 Apr 2001 17:27:50 -0400 Message-ID: <00d801c0c13b$edfd0ff0$72f0b487@dnrc.belllabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-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 The following message never made it to the mailing list so I'm resending it. -----Original Message----- From: James Kempf [mailto:james.kempf@sun.com] Sent: Thursday, April 05, 2001 7:09 PM To: Sandy Thuel; mobile-ip@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] dynamic home addressing as a WG item?? Hi Sandy, At 11:31 AM 4/5/01 -0400, Sandy Thuel wrote: >No. I wasn't referring to service discovery but >to parameters which are typically associated >with DHCP options [RFC2132] such as subnet mask, >domain name, gateway router(s), DNS server(s), >NTP server(s), etc. Please correct me if I'm Well, of these NTP and DNS servers are service discovery, I agree that the others are configuration. Using service discovery to discover DNS might be quite difficult (especially if DNS SRV RRs were used), so I suppose that could be considered a configuration parameter as well. >wrong but my understanding was that these service >discovery protocols don't allocate all these >parameters. And even if they do, what is >the extent of their deployment and support in >today's networks to rely on them for mobile >configuration support? The options related to IP address configuration and routing (gateway router, subnet mask, and domain name) are not handled by service discovery currently but they could be handled by a mobile IP extension or AAA extension that hides the back end implementation so network operators could use the backend technique of their choosing. Regarding deployment of service discovery techniques, well, DNS is certanily widely deployed. I don't know how many deployments support SRV RRs but I suspect the number is growing. I don't know how widely deployed LDAP is but it certainly is becoming more popular in enterprise networks, and I believe one could make a case as widely deployed as DHCP. SLP is a complement to LDAP, and it is not as widely deployed as the other two, but growing. >I agree that AAA is, in principle, a promising >candidate to be a repository for the configuration >options I'm referring to and it could be a better >alternative than DHCP. Do you know of any efforts >to extend the AAA infrastructure to support this? No, but this is something that could easily become a standardized Diameter extension. >In any case, if I want a solution for today, I >still think DHCP is the only game in town... DHCP was developed for enterprise networks, it has little or no deployment in wide area mobile networks at this point, certainly not to the mobile node, and its characteristics are not particularly promising for wide area, IMHO. Since a mobile node must have mobile IP on it anyway, there is little point in requiring it to have DHCP as well. >Yes. That's what I meant when I said the DHCP >proxy and HA can be "logically" separated by >an API. This is a fine implementation option, and perhaps there are some points that would require standardization. > > > > But I don't see any problem with having the > > HA do DHCP out the back end, this is > > an implementation choice. > >Agreed. Now, we have agreed that there are >different ways to implement this. This settles >affirmatively the question as to whether or not >it is implementable. The more important question >I'm trying to get at is whether or not it is >feasible to require HA's to support this (picking >a favorite implementation strategy of choice). >Any thoughts? I don't think it should be required, a network operator may choose to do address and address parameter configuration out the back end of the HA using Radius or Diameter. But there are probably areas that could be standardized. >I hope my clarification above on what I was >referring to as configuration options clarifies >what I meant by this question. Yes, thanx. jak From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 17:54: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 RAA17742 for ; Mon, 9 Apr 2001 17:54:21 -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 OAA05722; Mon, 9 Apr 2001 14:52: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 OAA11322; Mon, 9 Apr 2001 14:52:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39LpDK9009352 for ; Mon, 9 Apr 2001 14:51:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39LpD2M009351 for mobile-ip-dist; Mon, 9 Apr 2001 14:51: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39Lp3K9009341 for ; Mon, 9 Apr 2001 14:51:03 -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 OAA10748 for ; Mon, 9 Apr 2001 14:51:03 -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 PAA22150 for ; Mon, 9 Apr 2001 15:51:03 -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 f39Lp0I22944 for ; Mon, 9 Apr 2001 23:51:00 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Apr 09 23:50:59 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Apr 2001 23:46:35 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBD75@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Location privacy Date: Mon, 9 Apr 2001 23:50: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: Mike, > I really don't know what MIP has to do with > location privacy per se. In fact, it provides a > fair veneer of privacy which is completely under > the control of the mobile node: it just doesn't > send binding updates if it wants rudimentary > privacy. > => At the expense of route optimisation. > Moving the HA farther toward the mobile > node (as does HMIP) reveals more information. The > only way to reveal less information is to decouple > your home agent from your home network; this is > just an operational issue. Of course, the best is > to run things through an ALG which I think is > ultimately what will happen if people want to be > assured privacy (eg battered wife). > => I really hope we don't have to resort to ALG's to get location privacy. I can see the next step being reintroducing NATs for the same purpose ! This would be a disaster IMO, especially for IPv6. Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 17:57: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 RAA17810 for ; Mon, 9 Apr 2001 17:57:30 -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 OAA09100; Mon, 9 Apr 2001 14:56: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 OAA15591; Mon, 9 Apr 2001 14:56:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39LtVK9009387 for ; Mon, 9 Apr 2001 14:55:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39LtV4j009386 for mobile-ip-dist; Mon, 9 Apr 2001 14:55: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 eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39LtOK9009376 for ; Mon, 9 Apr 2001 14:55:25 -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 RAA11892 for ; Mon, 9 Apr 2001 17:55:25 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA10591 for mobile-ip@sunroof.eng.sun.com; Mon, 9 Apr 2001 17:55:36 -0400 (EDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UGcxIm014919 for ; Fri, 30 Mar 2001 08:38:59 -0800 (PST) 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 IAA00130 for ; Fri, 30 Mar 2001 08:38:59 -0800 (PST) Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA06044 for ; Fri, 30 Mar 2001 09:38:58 -0700 (MST) Received: from zrchh190 by smtprch2.nortel.com; Fri, 30 Mar 2001 10:27:09 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Fri, 30 Mar 2001 10:33:13 -0600 Received: from qcarh006.nortelnetworks.com (zcars00w.ca.nortel.com [47.128.0.50]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id LAA01942; Fri, 30 Mar 2001 11:32:02 -0500 (EST) From: conf@uha.fr Received: from 192.58.194.94 (actually ecarsaaa.nortelnetworks.com) by qcarh006.nortelnetworks.com; Fri, 30 Mar 2001 11:29:21 -0500 Received: from nscolmar.uha.fr (nscolmar.uha.fr [194.167.108.34]) by with SMTP (MailShield v1.5); Fri, 30 Mar 2001 11:31:33 -0500 Received: from [194.167.108.50] (admpcsrv1.uha.fr [194.167.108.50]) by nscolmar.uha.fr (8.11.0/jtpda-5.3.3) with SMTP id f2U9GKX30625 ; Fri, 30 Mar 2001 11:16:20 +0200 Received: from admpcsrv1.uha.fr by [194.167.108.50] via smtpd (for nscolmar.uha.fr [194.167.108.34]) with SMTP; 30 Mar 2001 09:27:09 UT Received: from gtrpc31 ([192.168.12.82]) by admpcsrv1.uha.fr (Lotus Domino Release 5.0.3 (Intl)) with SMTP id 2001033011110010:6619 ; Fri, 30 Mar 2001 11:11:00 +0200 Message-Id: <3.0.1.32.20010330112350.008f1100@uha.fr> X-Sender: conf@uha.fr (Unverified) X-Mailer: Windows Eudora Pro Version 3.0.1 (32) [F] Date: Fri, 30 Mar 2001 11:23:50 +0200 To: conf@uha.fr Subject: [mobile-ip] Call for participation for ICN01 and Call for Papers for ECUMN'02 Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on ADMPCSRV1/SRV/COLMAR(Release 5.0.3 (Intl)|21 March 2000) at 30/03/2001 11:11:00, Serialize by Router on ADMPCSRV1/SRV/COLMAR(Release 5.0.3 (Intl)|21 March 2000) at 30/03/2001 11:23:17, Serialize complete at 30/03/2001 11:23:17 Content-Type: text/plain; charset="us-ascii" X-SMTP-HELO: nscolmar.uha.fr X-SMTP-MAIL-FROM: conf@uha.fr X-SMTP-RCPT-TO: mobile-ip@standards.nortelnetworks.com,mobile-.ip@standards.nortelnetworks.com X-SMTP-PEER-INFO: nscolmar.uha.fr [194.167.108.34] X-Orig: X-Orig: 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: Dear All, Please feel free to circulate to interested colleagues: 1. The preliminary program of ICN01 (International Conference on Networking) (see http://iutsun1.colmar.uha.fr/ICN01.html ) which will be held at Colmar, France, from Monday July 9, 2001 to Friday July 13, 2001. If you would like to Chair a session during ICN01, please contact lorenz@ieee.org 2. The call for papers of ECUMN'02 (see http://iutsun1.colmar.uha.fr/ECUMN02.html ) scheduled from April 8 to April 10, 2002. The deadline for this CfP is September 1, 2001. Accept our sincere apologies if you receive multiple copies. From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 18:06: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 SAA17892 for ; Mon, 9 Apr 2001 18:06:27 -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 PAA15754; Mon, 9 Apr 2001 15:05: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 PAA14827; Mon, 9 Apr 2001 15:05:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39M4FK9009887 for ; Mon, 9 Apr 2001 15:04:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39M4Fov009886 for mobile-ip-dist; Mon, 9 Apr 2001 15:04: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39M45K9009879 for ; Mon, 9 Apr 2001 15:04:06 -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 PAA07364 for ; Mon, 9 Apr 2001 15:04:06 -0700 (PDT) Received: from dorian.fokus.gmd.de (dorian.fokus.gmd.de [193.175.135.179]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA19760 for ; Mon, 9 Apr 2001 15:03:49 -0700 (PDT) Received: from fokus.gmd.de (localhost [127.0.0.1]) by dorian.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id 14mjlT-0003E3-00; Tue, 10 Apr 2001 00:04:03 +0200 Message-ID: <3AD231D3.7C47C799@fokus.gmd.de> Date: Tue, 10 Apr 2001 00:04:03 +0200 From: Andrei Pelinescu - Onciul X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.1-pre8-dorian i686) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: "Shahrier, Sharif M." Subject: Re: [mobile-ip] some issues with IPv6 mobility draft (sharif) 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 "Shahrier, Sharif M." wrote: > [...] > 1. Consider A, B where A is the mobile and B is the correpondent node. > A is currently > away from its home agent. B is also a mobile node. Suppose A send a > BU(A) and moves > to its new location. The network is heavily loaded, and B has not > yet received the > binding update. B also was to move. Thus, similarly, it sends a > BU(B) to A, and moves > to its new location. The binding updates BU(A) and BU(B) eventually > arrives at A's > and B's previous locations, respectively. But A and B have already > moved. This means > that nodes neither A or B will are aware of each other new > respective locations. > > Thus, I believe this is be an erronous condition wrt A and B not > knowing each others > final destination addresses. > > 2. In light of the potential problem in (1), I propose that we > eliminate all signaling > between mobile-to-mobile with respect to Binding Update and Binding > Request messages. I think we should only send binding updates to the home address of the "mobile" CN (or the correspondent MN? :)). This means we must not use the binding cache when sending a binding update. This approach will solve this problem with only a minor modification on the MN code. Andrei From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 18:12: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 SAA17984 for ; Mon, 9 Apr 2001 18:12: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 PAA19953; Mon, 9 Apr 2001 15:12: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 PAA09163; Mon, 9 Apr 2001 15:12:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39MAJK9009934 for ; Mon, 9 Apr 2001 15:10:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39MAI1G009933 for mobile-ip-dist; Mon, 9 Apr 2001 15:10:18 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39MA9K9009926 for ; Mon, 9 Apr 2001 15:10:09 -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 PAA19234 for ; Mon, 9 Apr 2001 15:10:05 -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 QAA02009 for ; Mon, 9 Apr 2001 16:10:06 -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 PAA09888; Mon, 9 Apr 2001 15:10:02 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f39M9wn26879; Mon, 9 Apr 2001 15:09:58 -0700 X-mProtect: Mon, 9 Apr 2001 15:09:58 -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(WTS.12.69) smtpd4nKuDz; Mon, 09 Apr 2001 14:39:01 PDT Message-ID: <3AD22BF7.369EC2B8@iprg.nokia.com> Date: Mon, 09 Apr 2001 14:39:03 -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 CC: "Kiernan, Brian G." Subject: Re: [mobile-ip] some issues with IPv6 mobility draft (sharif) 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 Okay, they wont. A keeps sending BUs to B's old CoA. It would keep getting ICMP unreachable messages for B's old CoA. then A would delete the binding cache entry it has for B. A would then send the next BU to B's home address, which is forwarded to B by B's home agent. so B eventually knows where A is. this works because you fall back to the home address when you cant reach someone at a particular CoA. it doesnt make sense for the Home Agent to maintain binding update lists for each mobile that it seves as the home agent. vijay "Shahrier, Sharif M." wrote: > > Phil, > > I checked the draft section 10.8. It doesn't seem to specify when > the BU > is sent, i.e. before or after. I guess this is determined in part by > handoff > protocols. > > Also, I don't believe that sending the BU after the move will solve > the > problem. For example, suppose A and B move at the same time. After > the move > they both send a BU to each others respective *original* > destinations. Thus, > again neither will be advised of their new locations. > > Best Regards, > > Sharif Shahrier > InterDigital > > Sharif, > > Doesn't the BU get sent shortly *after* every move? So the condition where > you send the BU and then move seems to be a rare case or perhaps when > handoffs are occuring in *rapid* succession (i.e. faster than the latency > between MN_A and CN_B). If the ping time between MN_A and CN_B > is longer (on average) than the inter-handoff time MIP breaks in many > awful ways right (i.e. it doesn't work) right? > > ----- Original Message ----- > From: "Shahrier, Sharif M." > To: > Sent: Monday, April 09, 2001 2:46 PM > Subject: [mobile-ip] some issues with IPv6 mobility draft (sharif) > > > > > > I have some issues to discuss with the document: > > > > > > "Mobility Support in IPv6" > > > > > > > > > I would be grateful if people can take a look and make any contructive > > > comments. Thanks. > > > > > > > > > 1. Consider A, B where A is the mobile and B is the correpondent node. > > > A is currently > > > away from its home agent. B is also a mobile node. Suppose A send a > > > BU(A) and moves > > > to its new location. The network is heavily loaded, and B has not > > > yet received the > > > binding update. B also was to move. Thus, similarly, it sends a > > > BU(B) to A, and moves > > > to its new location. The binding updates BU(A) and BU(B) eventually > > > arrives at A's > > > and B's previous locations, respectively. But A and B have already > > > moved. This means > > > that nodes neither A or B will are aware of each other new > > > respective locations. > > > > > > Thus, I believe this is be an erronous condition wrt A and B not > > > knowing each others > > > final destination addresses. > > > > > > 2. In light of the potential problem in (1), I propose that we > > > eliminate all signaling > > > between mobile-to-mobile with respect to Binding Update and Binding > > > Request messages. > > > Instead, after a mobile has moved to a new location: > > > > > > - It only sends a Binding Update to its home agent. > > > - Home agent updates the binding for the mobile. > > > - The home agent maintains a Binding Update List containing > > > all the > > > correspondent nodes that are currently communicating with > > > the mobile. > > > - The home agent (uni)multicasts a Binding Update to all the > > > nodes in > > > that Binding Update List. > > > - The correspondent nodes send back Binding Acknowledgement > > > to the > > > home agent. > > > - Home agent, in turn, sends back Binding Acknowlegement to > > > the mobile. > > > > > > Under this scheme, we eliminate the need for mobile-to-mobile > > > signaling. Only > > > signaling between home agent and the mobile and correspondent(s) > > > nodes are > > > neccessary. Also, something like the scheme above may slove the > > > problem > > > described in (1). > > > > > > 3. If the home agent has failed/reconfigured, I believe that "dynamic > > > home agent > > > discovery" is used to locate a new home agent on the home link. > > > However, it > > > does not guard against failure to the home link itself. For this > > > pupose we > > > need to add fault tolerent capability to guard against link failure. > > > > > > > > > Designate a "primary" home link and a "secondary" home link. Under > > > non failure > > > conditions, primary link is used as the home link. If the primary > > > link fails, > > > then the secondary link is used. New home agent is located. Of > > > course, the > > > number of links can be increased to an arbitrary number. > > > > > > These three points are not intended as final solutions, but as > > > a framework from which a formal solution can be drafted. > > > > > > > > > Best Regards, > > > > > > Sharif Shahrier > > > InterDigital > > > > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 18:13: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 SAA18000 for ; Mon, 9 Apr 2001 18:13:45 -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 PAA20591; Mon, 9 Apr 2001 15:13: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 PAA19859; Mon, 9 Apr 2001 15:13:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39MBqK9009944 for ; Mon, 9 Apr 2001 15:11:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39MBpUq009943 for mobile-ip-dist; Mon, 9 Apr 2001 15:11: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 jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39MBgK9009936 for ; Mon, 9 Apr 2001 15:11:42 -0700 (PDT) Received: from locked (locked.Eng.Sun.COM [129.146.85.189]) by jurassic.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with SMTP id f39MBgCq501689; Mon, 9 Apr 2001 15:11:42 -0700 (PDT) Message-Id: <200104092211.f39MBgCq501689@jurassic.eng.sun.com> Date: Mon, 9 Apr 2001 15:10:27 -0700 (PDT) From: Mohan Parthasarathy Subject: Re: [mobile-ip] some issues with IPv6 mobility draft (sharif) To: mobile-ip@sunroof.eng.sun.com Cc: brian.kiernan@InterDigital.com, charliep@iprg.nokia.com, Sharif.Shahrier@InterDigital.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: H+qS9fybZKPZU6n3xz01tw== 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: > > I have some issues to discuss with the document: > > "Mobility Support in IPv6" > > > I would be grateful if people can take a look and make any contructive > comments. Thanks. > > > 1. Consider A, B where A is the mobile and B is the correpondent node. > A is currently > away from its home agent. B is also a mobile node. Suppose A send a > BU(A) and moves > to its new location. The network is heavily loaded, and B has not > yet received the > binding update. B also was to move. Thus, similarly, it sends a > BU(B) to A, and moves > to its new location. The binding updates BU(A) and BU(B) eventually > arrives at A's > and B's previous locations, respectively. But A and B have already > moved. This means > that nodes neither A or B will are aware of each other new > respective locations. > > Thus, I believe this is be an erronous condition wrt A and B not > knowing each others > final destination addresses. > If the binding is wrong, you will get ICMP errors and if this persists you should delete your binding cache entry if you are a correspondent node. Now the packets go through the home agent which has the right binding. -mohan > 2. In light of the potential problem in (1), I propose that we > eliminate all signaling > between mobile-to-mobile with respect to Binding Update and Binding > Request messages. > Instead, after a mobile has moved to a new location: > > - It only sends a Binding Update to its home agent. > - Home agent updates the binding for the mobile. > - The home agent maintains a Binding Update List containing > all the > correspondent nodes that are currently communicating with > the mobile. > - The home agent (uni)multicasts a Binding Update to all the > nodes in > that Binding Update List. > - The correspondent nodes send back Binding Acknowledgement > to the > home agent. > - Home agent, in turn, sends back Binding Acknowlegement to > the mobile. > > Under this scheme, we eliminate the need for mobile-to-mobile > signaling. Only > signaling between home agent and the mobile and correspondent(s) > nodes are > neccessary. Also, something like the scheme above may slove the > problem > described in (1). > > 3. If the home agent has failed/reconfigured, I believe that "dynamic > home agent > discovery" is used to locate a new home agent on the home link. > However, it > does not guard against failure to the home link itself. For this > pupose we > need to add fault tolerent capability to guard against link failure. > > > Designate a "primary" home link and a "secondary" home link. Under > non failure > conditions, primary link is used as the home link. If the primary > link fails, > then the secondary link is used. New home agent is located. Of > course, the > number of links can be increased to an arbitrary number. > > These three points are not intended as final solutions, but as > a framework from which a formal solution can be drafted. > > > Best Regards, > > Sharif Shahrier > InterDigital > > > From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 18:20: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 SAA18111 for ; Mon, 9 Apr 2001 18:20:25 -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 PAA25567; Mon, 9 Apr 2001 15:19:41 -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 PAA18208; Mon, 9 Apr 2001 15:19:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39MIIK9010043 for ; Mon, 9 Apr 2001 15:18:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39MIIAp010042 for mobile-ip-dist; Mon, 9 Apr 2001 15:18:18 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39MI8K9010035 for ; Mon, 9 Apr 2001 15:18:08 -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 SAA14841 for ; Mon, 9 Apr 2001 18:18:08 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id SAA10973 for mobile-ip@sunroof.eng.sun.com; Mon, 9 Apr 2001 18:18:19 -0400 (EDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33LfRIm023874 for ; Tue, 3 Apr 2001 14:41:27 -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 OAA05773 for ; Tue, 3 Apr 2001 14:41:27 -0700 (PDT) Received: from mx1.thebiz.net (mx1.thebiz.net [216.238.0.20]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA17646 for ; Tue, 3 Apr 2001 14:41:26 -0700 (PDT) Received: (qmail 5537 invoked from network); 3 Apr 2001 17:41:23 -0400 Received: from mail1.backend.thebiz.net (HELO mail1.thebiz.net) (172.16.0.179) by mx1.backend.thebiz.net with SMTP; 3 Apr 2001 17:41:23 -0400 Received: (qmail 24210 invoked by uid 0); 3 Apr 2001 17:41:22 -0400 Received: from unknown (HELO stu.critical.com) (216.230.224.199) by mail.borg.com with SMTP; 3 Apr 2001 17:41:22 -0400 Message-Id: <5.0.2.1.0.20010403172506.009ef7c0@mail.borg.com> X-Sender: stu@mail.borg.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 03 Apr 2001 17:43:44 -0400 To: mobile-ip@sunroof.eng.sun.com From: "Stuart W. Card" Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6 In-Reply-To: <034BEFD03799D411A59F00508BDF7546013DBD04@esealnt448.al.sw. ericsson.se> 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 02:14 AM 2001-03-30 +0200, wrote: >Thierry Ernst has brought up a valid scenario in which the MIPv6 >spec does not work. This is reagrding the support of Mobile >Networks in MIPv6. > >The scenario and solution are explained in : >http://search.ietf.org/internet-drafts/draft-ernst-mobileip-v6-network-01.txt > >This draft was presented in Pittsburgh (00) and San Diego (01). >Personally I think this is a good solution and it deserves the >WG support... > >So do you think the draft or at least the problem should >be considered as part of the charter ? Much discussion followed. Several points: (1) Leaving behavior of implementations to interpretations made by implementors is a bad idea. The fact that the WG members themselves have different interpretations is sufficient evidence that interpretation of the current language by future implementors will lead to divergent behaviors. (2) The HA is not necessarily the _last_ router, going from the Internet core towards the prefixes for which the MR routes; it may not even be in the normal path for such packets. Further, the MR does not necessarily advertise; the routes may have been otherwise configured. Therefore, the HA does not necessarily have routing table entries that could be used to route traffic intended for prefixes behind the MR via the tunnel. (3) Solutions based upon making all the 'fixed' nodes on the mobile network act as if they were themselves (independently) mobile are not efficiently scalable. Therefore, the issue of Mobile Networks must be explicitly addressed, preferably in the Mobile IP WG rather than elsewhere. I think it is in the scope of the current charter, but if/when the charter is revised, this topic should explicitly be identified therein as within scope. I think Thierry Ernst's draft is a good thing, at least to kick off discussion. The ultimate requirements for Mobile Networks support should be integrated into the mainstream Mobile IP documents rather than addressed in separate RFCs. Several more points: (1) Mobile Routers may raise new authentication issues, relating to ensuring that the MR is truly the router properly authorized to route for the prefixes on which it sends BUs. (2) Mobile Routers may route for multiple prefixes of different sizes in arbitrary disconnected regions of the address space. (3) Mobile Routers may be multi-homed. The last point above is particularly important for me. I am building wireless mobile routers that concurrently use multiple wireless links to access multiple points of access into the wireline infrastructure. Except for this last point, everything is just IMO, and I'm not an expert on Mobile IP. Thanks all! Stuart W. Card, Chief Scientist & Vice-Pres., Critical Technologies Inc. Suite 400 Technology Center, 4th Floor 1001 Broad Street, Utica NY 13501 315-793-0248 x141 FAX -9710 http://www.critical.com From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 18:23: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 SAA18146 for ; Mon, 9 Apr 2001 18:23: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 PAA24402; Mon, 9 Apr 2001 15:18: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 PAA17069; Mon, 9 Apr 2001 15:17:55 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39MGYK9010030 for ; Mon, 9 Apr 2001 15:16:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39MGYDE010029 for mobile-ip-dist; Mon, 9 Apr 2001 15:16:34 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39MGPK9010022 for ; Mon, 9 Apr 2001 15:16:25 -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 PAA20897 for ; Mon, 9 Apr 2001 15:16:26 -0700 (PDT) Received: from c007.snv.cp.net (c007-h013.c007.snv.cp.net [209.228.33.220]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA23224 for ; Mon, 9 Apr 2001 15:16:25 -0700 (PDT) Received: (cpmta 21555 invoked from network); 9 Apr 2001 15:16:24 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.220) with SMTP; 9 Apr 2001 15:16:24 -0700 X-Sent: 9 Apr 2001 22:16:24 GMT Message-ID: <017801c0c142$92ff96c0$6501a8c0@philneum> From: "Phil Neumiller" To: Cc: "Kiernan, Brian G." References: <3AD22BF7.369EC2B8@iprg.nokia.com> Subject: Re: [mobile-ip] some issues with IPv6 mobility draft (sharif) Date: Mon, 9 Apr 2001 17:15:23 -0500 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: It would seem that perhaps an optimization is possible here then? I wonder "how long" it would take for the fall back to occur and how frequently this particular pathological race condition could occur. -pdn ----- Original Message ----- From: "Vijay Devarapalli" To: Cc: "Kiernan, Brian G." Sent: Monday, April 09, 2001 4:39 PM Subject: Re: [mobile-ip] some issues with IPv6 mobility draft (sharif) > Okay, they wont. A keeps sending BUs to B's old CoA. It > would keep getting ICMP unreachable messages for B's old > CoA. then A would delete the binding cache entry it has > for B. A would then send the next BU to B's home address, > which is forwarded to B by B's home agent. so B eventually > knows where A is. > > this works because you fall back to the home address when > you cant reach someone at a particular CoA. > > it doesnt make sense for the Home Agent to maintain binding > update lists for each mobile that it seves as the home agent. > > vijay > From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 18:29: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 SAA18226 for ; Mon, 9 Apr 2001 18:29: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 PAA08058; Mon, 9 Apr 2001 15:28: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 PAA19726; Mon, 9 Apr 2001 15:28:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39MRJK9010213 for ; Mon, 9 Apr 2001 15:27:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39MRJa0010212 for mobile-ip-dist; Mon, 9 Apr 2001 15:27: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39MR9K9010204 for ; Mon, 9 Apr 2001 15:27:10 -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 PAA19410 for ; Mon, 9 Apr 2001 15:27:05 -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 QAA10503 for ; Mon, 9 Apr 2001 16:26:59 -0600 (MDT) 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 f39MQws27902 for ; Tue, 10 Apr 2001 00:26:58 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Tue Apr 10 00:26:58 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Apr 2001 00:22:33 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBD7A@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] some issues with IPv6 mobility draft (sharif) Date: Tue, 10 Apr 2001 00:26:57 +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: Im not sure if this situation will happen. When you move you would have an anchor point in the visited network. This is either your previous default router in the basic MIPv6 case or your MAP in HMIPv6. This anchor point will have a tunnel to the MN. The lifetime of that tunnel should certainly be longer than a RTT on the Internet. If this didn't happen for some reason, then ICMP unreachables will be sent as others mentioned. So I don't think we have a problem, do we ? Hesham > -----Original Message----- > From: Phil Neumiller [SMTP:neumiller@telocity.com] > Sent: Tuesday, 10 April 2001 8:15 > To: mobile-ip@sunroof.eng.sun.com > Cc: Kiernan, Brian G. > Subject: Re: [mobile-ip] some issues with IPv6 mobility draft (sharif) > > It would seem that perhaps an optimization is possible here then? > I wonder "how long" it would take for the fall back to occur and > how frequently this particular pathological race condition could > occur. > > -pdn > ----- Original Message ----- > From: "Vijay Devarapalli" > To: > Cc: "Kiernan, Brian G." > Sent: Monday, April 09, 2001 4:39 PM > Subject: Re: [mobile-ip] some issues with IPv6 mobility draft (sharif) > > > > Okay, they wont. A keeps sending BUs to B's old CoA. It > > would keep getting ICMP unreachable messages for B's old > > CoA. then A would delete the binding cache entry it has > > for B. A would then send the next BU to B's home address, > > which is forwarded to B by B's home agent. so B eventually > > knows where A is. > > > > this works because you fall back to the home address when > > you cant reach someone at a particular CoA. > > > > it doesnt make sense for the Home Agent to maintain binding > > update lists for each mobile that it seves as the home agent. > > > > vijay > > > From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 19:02:33 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 TAA18517 for ; Mon, 9 Apr 2001 19:02: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 QAA22739; Mon, 9 Apr 2001 16:02:09 -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 QAA19423; Mon, 9 Apr 2001 16:02:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39N00K9010445 for ; Mon, 9 Apr 2001 16:00:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39N00Hh010444 for mobile-ip-dist; Mon, 9 Apr 2001 16:00: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39MxpK9010437 for ; Mon, 9 Apr 2001 15:59:51 -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 PAA25585 for ; Mon, 9 Apr 2001 15:59:51 -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 PAA21206 for ; Mon, 9 Apr 2001 15:59:45 -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 PAA16048 for ; Mon, 9 Apr 2001 15:59:45 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f39MxfA11393 for ; Mon, 9 Apr 2001 15:59:41 -0700 X-mProtect: Mon, 9 Apr 2001 15:59:41 -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(WTS.12.69) smtpdASDbVv; Mon, 09 Apr 2001 15:46:29 PDT Message-ID: <3AD23BC5.56050CD4@iprg.nokia.com> Date: Mon, 09 Apr 2001 15:46:29 -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] some issues with IPv6 mobility draft (sharif) References: <3AD22BF7.369EC2B8@iprg.nokia.com> <017801c0c142$92ff96c0$6501a8c0@philneum> 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 Phil, If A has an active session going on with B, then it wouldnt take long for A to figure out that B is not reachable. there is no 'race condition' here. they are just unreachable for a short duration of time. wonder how you came up with the term 'race condition' for this? vijay Phil Neumiller wrote: > > It would seem that perhaps an optimization is possible here then? > I wonder "how long" it would take for the fall back to occur and > how frequently this particular pathological race condition could > occur. > > -pdn > ----- Original Message ----- > From: "Vijay Devarapalli" > To: > Cc: "Kiernan, Brian G." > Sent: Monday, April 09, 2001 4:39 PM > Subject: Re: [mobile-ip] some issues with IPv6 mobility draft (sharif) > > > Okay, they wont. A keeps sending BUs to B's old CoA. It > > would keep getting ICMP unreachable messages for B's old > > CoA. then A would delete the binding cache entry it has > > for B. A would then send the next BU to B's home address, > > which is forwarded to B by B's home agent. so B eventually > > knows where A is. > > > > this works because you fall back to the home address when > > you cant reach someone at a particular CoA. > > > > it doesnt make sense for the Home Agent to maintain binding > > update lists for each mobile that it seves as the home agent. > > > > vijay > > From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 19:04:16 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 TAA18550 for ; Mon, 9 Apr 2001 19:04:15 -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 QAA22907; Mon, 9 Apr 2001 16:03: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 QAA26648; Mon, 9 Apr 2001 16:03:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39N2aK9010458 for ; Mon, 9 Apr 2001 16:02:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39N2a0B010457 for mobile-ip-dist; Mon, 9 Apr 2001 16:02: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 eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39N2UK9010450 for ; Mon, 9 Apr 2001 16:02:31 -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 TAA05043 for ; Mon, 9 Apr 2001 19:02:30 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA11765 for mobile-ip@sunroof.eng.sun.com; Mon, 9 Apr 2001 19:02:41 -0400 (EDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f341LSIm024676 for ; Tue, 3 Apr 2001 18:21:28 -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 SAA28635; Tue, 3 Apr 2001 18:21:28 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA08611; Tue, 3 Apr 2001 18:21:27 -0700 (PDT) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id SAA15378; Tue, 3 Apr 2001 18:19:55 -0700 (PDT) Received: from tmima-w2k.cisco.com (dhcp-171-70-57-96.cisco.com [171.70.57.96]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id ABX02451; Tue, 3 Apr 2001 18:19:35 -0700 (PDT) Message-Id: <4.3.2.7.2.20010403180901.02fb3798@mira-sjcm-2.cisco.com> X-Sender: tmima@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 03 Apr 2001 18:18:59 -0700 To: rajeev.koodli@nokia.com, mccap@research.bell-labs.com, rajeev.koodli@nokia.com From: Tmima Koren Subject: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Cc: kempf@heliopolis.Eng.Sun.COM, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org In-Reply-To: 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: I wonder if it's possible to do both: The new router sends a request for context transfer, but continues to forward the compressed packets to the old router, AND queues a copy of the packets he forwarded. Once he receives the context, the new router applies the necessary changes to the context from the queued packets. Now his context is good and he can continue decompressing. Tmima At 07:58 PM 4/3/2001 -0500, rajeev.koodli@nokia.com wrote: > > -----Original Message----- > > From: ext Pete McCann [mailto:mccap@research.bell-labs.com] > > Sent: Tuesday, April 03, 2001 5:30 PM > > To: rajeev.koodli@nokia.com > > Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > > rohc@cdt.luth.se; seamoby@diameter.org > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile > > IPv6 Handover > > > > > > > > > > Yes, you would need to re-initialize the context over the air, but I > > don't think the bandwidth usage is high enough to matter. In a > > wide-area cellular environment IP handoffs will be relatively > > infrequent. The important consideration is the "glitch" experienced > > in voice traffic at handoff time, and this can be minimized by > > temporarily anchoring the compressor. > > > >I don't agree with you comments that you could ignore bandwidth usage and >assume infrequent handovers. > >a> 84 bytes of IPv6/UDP/RTP headers with Mobile-IPv6 Home Address option for >a voice payload of 20 - 30 bytes. Several such packets sent per each stream. > >b> With fast user mobility, each BTS/AP being a router, I can imagine >frequent handovers. > >In any case, context relocation addresses a>, does not assume infrequent >handovers, as well as attempts to provide "glitch-free" voice. When the >context is already present at the target router before the MN starts sending >compressed packets, the application should not see the glitch. >I know there is work to be done here, so let's try to focus on that! > >Regards, > >-Rajeev > > > > -Pete > > > > rajeev.koodli@nokia.com (rk) writes: > > > > rk> Hi, > > > > rk> How does this avoid the core problem of context > > rk> _re-initialization_ ? You would still need to send IR packets (to > > rk> new access router over the air interface) subsequent to handover > > rk> in order to start a new context.. Anchoring it at the previous > > rk> router may buy you some time, but not the bits. I reckon > > rk> anchoring will bring its own set of problems. > > > > rk> Regards, > > > > rk> -Rajeev > > > > > > >> -----Original Message----- > > >> From: ext Pete McCann [mailto:mccap@research.bell-labs.com] > > >> Sent: Tuesday, April 03, 2001 11:32 AM > > >> To: kempf@heliopolis.Eng.Sun.COM > > >> Cc: mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se; > > >> seamoby@diameter.org > > >> Subject: RE: [seamoby] RE: [rohc] RE: Restarting > > Compressor on Mobile > > >> IPv6 Handover > > >> > > >> > > >> > > >> Hi, > > >> > > >> I think there is a simpler solution to this problem that > > most people > > >> are overlooking. > > >> > > >> It should be possible to keep the compressor/decompressor > > state at the > > >> old access router and to tunnel the already-compressed > > packets to and > > >> from the new access router. Then the MN and new access router can > > >> renegotiate header compression state from scratch and take > > as long as > > >> they want to do so, because the MN is still getting service in the > > >> meantime. > > >> > > >> Someone earlier asked about support for ROHC on IP tunnels > > and I think > > >> this would be a good application for that. > > >> > > >> We are trying to move the mountain to Mohammed and I don't > > see why we > > >> can't do the reverse instead. > > >> > > >> -Pete > > >> > > >> > > >> --- > > >> Mailing list for Robust Header Compression WG > > >> Archive: http://www.cdt.luth.se/rohc/ > > >> > > rk> --- > > rk> Mailing list for Robust Header Compression WG > > rk> Archive: http://www.cdt.luth.se/rohc/ > > From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 19:07: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 TAA18642 for ; Mon, 9 Apr 2001 19:07: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 QAA23938; Mon, 9 Apr 2001 16:06:40 -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 QAA27557; Mon, 9 Apr 2001 16:06:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39N5aK9010512 for ; Mon, 9 Apr 2001 16:05:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39N5ai2010511 for mobile-ip-dist; Mon, 9 Apr 2001 16:05: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 eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39N5VK9010504 for ; Mon, 9 Apr 2001 16:05:31 -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 TAA20346 for ; Mon, 9 Apr 2001 19:05:31 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA11818 for mobile-ip@sunroof.eng.sun.com; Mon, 9 Apr 2001 19:05:41 -0400 (EDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f344G3Im024888 for ; Tue, 3 Apr 2001 21:16:03 -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 VAA12309 for ; Tue, 3 Apr 2001 21:15:47 -0700 (PDT) From: khiem.le@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 WAA12550 for ; Tue, 3 Apr 2001 22:15:36 -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 f344Fdg02551 for ; Tue, 3 Apr 2001 23:15:39 -0500 (CDT) Received: from daebh01nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 3 Apr 2001 23:15:35 -0500 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Tue, 3 Apr 2001 23:15:35 -0500 Message-ID: <8572CF1E2A95D211A1190008C7EAA246027208F3@daeis05nok> To: tmima@cisco.com, rajeev.koodli@nokia.com, mccap@research.bell-labs.com, rajeev.koodli@nokia.com Cc: kempf@heliopolis.Eng.Sun.COM, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Tue, 3 Apr 2001 23:15:33 -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 Tmima, Your idea is very similar to the one I had some time ago (refer to http://www.cdt.luth.se/robhc/msg01274.html). Essentially the idea is to relax the timing constraints and allow some time to establish the context at the new compressor/decompressor. During that context establishment time, the packets transit through the new compressor/decompressor, but also transit through the old which continues to do compression/decompression. Once the context is established, the new can take over the compression/decompression process. The old compressor/decompressor helps the new compressor/decompressor establish its context by sending some context information. One way (as you described, correct me if I am wrong) is to take a snapshot of the context and send it. To maintain context synchronization between the old and new, the new may do some update of the received context snapshot to account for the fact that the context may have been updated by the old after it took the snapshot. However, the problem is that packets may be lost when sent from the old to the new. So the new may do a context update based on packet j, but that update was not done by the old, since packet j was never received by the old. One way to solve this problem is to modify the mechanism to send the context information from old to new. Instead of sending a context snapshot, the old sends the context-related information in pieces, so the new can gradually build up its context. This corresponds to the Relocation-deferred-after-Link-Switching (RDLS)scheme in http://www.cdt.luth.se/robhc/msg01274.html. You can look at it for details. The case where the old takes a snapshot of its context and sends to the new for immediate transfer of compression/decompression role corresponds to Relocation-concurrent-with-Link-Switching (RCLS). RDLS addresses the timing problem in a very reliable manner, but is more complex than RCLS. It also requires a higher capacity connection between the old and new. So each approach has its pros and cons. In any case, I believe the context transfer (whether RCLS or RDLS) is doable, and the advantages over brute force reinitialization over the wireless link outweigh the costs. Khiem > -----Original Message----- > From: ext Tmima Koren [mailto:tmima@cisco.com] > Sent: Tuesday, April 03, 2001 8:19 PM > To: rajeev.koodli@nokia.com; mccap@research.bell-labs.com; > rajeev.koodli@nokia.com > Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > rohc@cdt.luth.se; seamoby@diameter.org > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile > IPv6 Handover > > > I wonder if it's possible to do both: > The new router sends a request for context transfer, but continues to > forward the compressed packets to the old router, AND queues > a copy of the > packets he forwarded. Once he receives the context, the new > router applies > the necessary changes to the context from the queued packets. Now his > context is good and he can continue decompressing. > Tmima > > At 07:58 PM 4/3/2001 -0500, rajeev.koodli@nokia.com wrote: > > > -----Original Message----- > > > From: ext Pete McCann [mailto:mccap@research.bell-labs.com] > > > Sent: Tuesday, April 03, 2001 5:30 PM > > > To: rajeev.koodli@nokia.com > > > Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > > > rohc@cdt.luth.se; seamoby@diameter.org > > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting > Compressor on Mobile > > > IPv6 Handover > > > > > > > > > > > > > > > Yes, you would need to re-initialize the context over the > air, but I > > > don't think the bandwidth usage is high enough to matter. In a > > > wide-area cellular environment IP handoffs will be relatively > > > infrequent. The important consideration is the "glitch" > experienced > > > in voice traffic at handoff time, and this can be minimized by > > > temporarily anchoring the compressor. > > > > > > >I don't agree with you comments that you could ignore > bandwidth usage and > >assume infrequent handovers. > > > >a> 84 bytes of IPv6/UDP/RTP headers with Mobile-IPv6 Home > Address option for > >a voice payload of 20 - 30 bytes. Several such packets sent > per each stream. > > > >b> With fast user mobility, each BTS/AP being a router, I can imagine > >frequent handovers. > > > >In any case, context relocation addresses a>, does not > assume infrequent > >handovers, as well as attempts to provide "glitch-free" > voice. When the > >context is already present at the target router before the > MN starts sending > >compressed packets, the application should not see the glitch. > >I know there is work to be done here, so let's try to focus on that! > > > >Regards, > > > >-Rajeev > > > > > > > -Pete > > > > > > rajeev.koodli@nokia.com (rk) writes: > > > > > > rk> Hi, > > > > > > rk> How does this avoid the core problem of context > > > rk> _re-initialization_ ? You would still need to send IR > packets (to > > > rk> new access router over the air interface) subsequent > to handover > > > rk> in order to start a new context.. Anchoring it at > the previous > > > rk> router may buy you some time, but not the bits. I reckon > > > rk> anchoring will bring its own set of problems. > > > > > > rk> Regards, > > > > > > rk> -Rajeev > > > > > > > > > >> -----Original Message----- > > > >> From: ext Pete McCann [mailto:mccap@research.bell-labs.com] > > > >> Sent: Tuesday, April 03, 2001 11:32 AM > > > >> To: kempf@heliopolis.Eng.Sun.COM > > > >> Cc: mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se; > > > >> seamoby@diameter.org > > > >> Subject: RE: [seamoby] RE: [rohc] RE: Restarting > > > Compressor on Mobile > > > >> IPv6 Handover > > > >> > > > >> > > > >> > > > >> Hi, > > > >> > > > >> I think there is a simpler solution to this problem that > > > most people > > > >> are overlooking. > > > >> > > > >> It should be possible to keep the compressor/decompressor > > > state at the > > > >> old access router and to tunnel the already-compressed > > > packets to and > > > >> from the new access router. Then the MN and new > access router can > > > >> renegotiate header compression state from scratch and take > > > as long as > > > >> they want to do so, because the MN is still getting > service in the > > > >> meantime. > > > >> > > > >> Someone earlier asked about support for ROHC on IP tunnels > > > and I think > > > >> this would be a good application for that. > > > >> > > > >> We are trying to move the mountain to Mohammed and I don't > > > see why we > > > >> can't do the reverse instead. > > > >> > > > >> -Pete > > > >> > > > >> > > > >> --- > > > >> Mailing list for Robust Header Compression WG > > > >> Archive: http://www.cdt.luth.se/rohc/ > > > >> > > > rk> --- > > > rk> Mailing list for Robust Header Compression WG > > > rk> Archive: http://www.cdt.luth.se/rohc/ > > > > > --- > Mailing list for Robust Header Compression WG > Archive: http://www.cdt.luth.se/rohc/ > From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 19:10: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 TAA18767 for ; Mon, 9 Apr 2001 19:10:48 -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 QAA25241; Mon, 9 Apr 2001 16:09:56 -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 QAA28085; Mon, 9 Apr 2001 16:09:57 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39N8eK9010544 for ; Mon, 9 Apr 2001 16:08:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39N8dSb010543 for mobile-ip-dist; Mon, 9 Apr 2001 16:08: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 eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39N8ZK9010536 for ; Mon, 9 Apr 2001 16:08:35 -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 TAA05571 for ; Mon, 9 Apr 2001 19:08:32 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA11871 for mobile-ip@sunroof.eng.sun.com; Mon, 9 Apr 2001 19:08:42 -0400 (EDT) Received: from centralmail1.Central.Sun.COM (centralmail1.Central.Sun.COM [129.147.62.10]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f35NEPK9027872 for ; Thu, 5 Apr 2001 16:14:25 -0700 (PDT) Received: from esun1as-mm. (esun1as-mm.Central.Sun.COM [129.147.34.144]) by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id RAA13750; Thu, 5 Apr 2001 17:14:25 -0600 (MDT) Received: from sunyata.sun.com by esun1as-mm. (SMI-8.6/SMI-SVR4) id RAA28636; Thu, 5 Apr 2001 17:18:06 -0600 Message-Id: <5.0.0.25.1.20010406075853.00a134d0@localhost> X-Sender: kempf@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 06 Apr 2001 08:09:05 +0900 To: "Sandy Thuel" , , From: James Kempf Subject: RE: [mobile-ip] dynamic home addressing as a WG item?? In-Reply-To: <009401c0bde5$8bf9d3a0$72f0b487@dnrc.belllabs.com> References: <5.0.0.25.1.20010405220813.00a0c210@localhost> 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: Hi Sandy, At 11:31 AM 4/5/01 -0400, Sandy Thuel wrote: >No. I wasn't referring to service discovery but >to parameters which are typically associated >with DHCP options [RFC2132] such as subnet mask, >domain name, gateway router(s), DNS server(s), >NTP server(s), etc. Please correct me if I'm Well, of these NTP and DNS servers are service discovery, I agree that the others are configuration. Using service discovery to discover DNS might be quite difficult (especially if DNS SRV RRs were used), so I suppose that could be considered a configuration parameter as well. >wrong but my understanding was that these service >discovery protocols don't allocate all these >parameters. And even if they do, what is >the extent of their deployment and support in >today's networks to rely on them for mobile >configuration support? The options related to IP address configuration and routing (gateway router, subnet mask, and domain name) are not handled by service discovery currently but they could be handled by a mobile IP extension or AAA extension that hides the back end implementation so network operators could use the backend technique of their choosing. Regarding deployment of service discovery techniques, well, DNS is certanily widely deployed. I don't know how many deployments support SRV RRs but I suspect the number is growing. I don't know how widely deployed LDAP is but it certainly is becoming more popular in enterprise networks, and I believe one could make a case as widely deployed as DHCP. SLP is a complement to LDAP, and it is not as widely deployed as the other two, but growing. >I agree that AAA is, in principle, a promising >candidate to be a repository for the configuration >options I'm referring to and it could be a better >alternative than DHCP. Do you know of any efforts >to extend the AAA infrastructure to support this? No, but this is something that could easily become a standardized Diameter extension. >In any case, if I want a solution for today, I >still think DHCP is the only game in town... DHCP was developed for enterprise networks, it has little or no deployment in wide area mobile networks at this point, certainly not to the mobile node, and its characteristics are not particularly promising for wide area, IMHO. Since a mobile node must have mobile IP on it anyway, there is little point in requiring it to have DHCP as well. >Yes. That's what I meant when I said the DHCP >proxy and HA can be "logically" separated by >an API. This is a fine implementation option, and perhaps there are some points that would require standardization. > > > > But I don't see any problem with having the > > HA do DHCP out the back end, this is > > an implementation choice. > >Agreed. Now, we have agreed that there are >different ways to implement this. This settles >affirmatively the question as to whether or not >it is implementable. The more important question >I'm trying to get at is whether or not it is >feasible to require HA's to support this (picking >a favorite implementation strategy of choice). >Any thoughts? I don't think it should be required, a network operator may choose to do address and address parameter configuration out the back end of the HA using Radius or Diameter. But there are probably areas that could be standardized. >I hope my clarification above on what I was >referring to as configuration options clarifies >what I meant by this question. Yes, thanx. jak From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 19:13: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 TAA18839 for ; Mon, 9 Apr 2001 19:13:32 -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 QAA26317; Mon, 9 Apr 2001 16:12: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 QAA28610; Mon, 9 Apr 2001 16:12:55 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39NBbK9010582 for ; Mon, 9 Apr 2001 16:11:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39NBabE010581 for mobile-ip-dist; Mon, 9 Apr 2001 16:11: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 eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39NBWK9010574 for ; Mon, 9 Apr 2001 16:11:32 -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 TAA05953 for ; Mon, 9 Apr 2001 19:11:32 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA11927 for mobile-ip@sunroof.eng.sun.com; Mon, 9 Apr 2001 19:11:43 -0400 (EDT) Received: from centralmail1.Central.Sun.COM (centralmail1.Central.Sun.COM [129.147.62.10]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f362IxK9028403 for ; Thu, 5 Apr 2001 19:18:59 -0700 (PDT) Received: from esun1as-mm. (esun1as-mm.Central.Sun.COM [129.147.34.144]) by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id UAA14812 for ; Thu, 5 Apr 2001 20:18:53 -0600 (MDT) Received: from sunyata.sun.com by esun1as-mm. (SMI-8.6/SMI-SVR4) id UAA02747; Thu, 5 Apr 2001 20:22:36 -0600 Message-Id: <5.0.0.25.1.20010406111342.00a09a90@localhost> X-Sender: kempf@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 06 Apr 2001 11:13:54 +0900 To: mobile-ip@sunroof.eng.sun.com From: James Kempf Subject: Re: [mobile-ip] Requirements Draft for Mobile IP QoS - Invitation to Volunteer In-Reply-To: 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: I am interested. jak At 09:47 PM 4/5/01 +0000, you 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 > From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 19:19:14 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 TAA18956 for ; Mon, 9 Apr 2001 19:19:13 -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 QAA02511; Mon, 9 Apr 2001 16:18: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 QAA29326; Mon, 9 Apr 2001 16:18:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39NHdK9010626 for ; Mon, 9 Apr 2001 16:17:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39NHdac010625 for mobile-ip-dist; Mon, 9 Apr 2001 16:17: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 eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39NHYK9010618 for ; Mon, 9 Apr 2001 16:17:34 -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 TAA06393 for ; Mon, 9 Apr 2001 19:17:34 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA12037 for mobile-ip@sunroof.eng.sun.com; Mon, 9 Apr 2001 19:17:44 -0400 (EDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36KiVK9001335 for ; Fri, 6 Apr 2001 13:44:31 -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 NAA28556 for ; Fri, 6 Apr 2001 13:44:30 -0700 (PDT) From: khiem.le@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA01377 for ; Fri, 6 Apr 2001 13:44:27 -0700 (PDT) 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 f36KiUg14004 for ; Fri, 6 Apr 2001 15:44:30 -0500 (CDT) Received: from daebh01nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 6 Apr 2001 15:44:26 -0500 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Fri, 6 Apr 2001 15:44:26 -0500 Message-ID: <8572CF1E2A95D211A1190008C7EAA24602720924@daeis05nok> To: rajeev.koodli@nokia.com, mat@cisco.com Cc: gkenward@nortelnetworks.com, tmima@cisco.com, mccap@research.bell-labs.com, kempf@heliopolis.Eng.Sun.COM, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Fri, 6 Apr 2001 15:44:25 -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: Hi, I have been too busy to comment on all these mails, but I just want to say a couple of things. I'm afraid that it > is your place to prove that context transfer > of header compression state in the face of all > of these extenuating circumstances is still > worthwhile. There have been many mails pointing out the merit of doing header compression context transfer. To repeat them: continued, seamless compression/decompression, higher compression efficiency, and minimization of degradation on the user media. This last point is the most important in my mind. At this stage, the link technologies where header compression is going to be used are primarily cellular links. In the cellular environment, handoffs (or handovers) are events that happen in normal operation, and therefore a very significant design effort is spent to minimize the impact of HO on performance. In particular, one wants to minimize the duration of the break. If brute force header compression reinitialization is done, one would have to send a certain number of 40-60 byte or more IR headers, instead of the usual 1 byte header. This big bandwidth demand surge will put a strain on the link. Some links will cope with it by blanking out the user data to make room to carry the IR headers. When such blanking takes place, the user media (voice, etc.) will be unavoidably affected. The impairment caused by the handoff is thus extended, compared to the case where header compression is not present. In the current and 3G cellular technologies, the break is about 100-150 msec, without header compression. This already translates into the loss of 5-6 20 msec packets. If some IR headers have to be sent by blanking out the user data, the break will be significantly longer. For example, if 3 (an optimistic value) IR headers are sent, the resulting break is increased to 8-9 packets worth. I also want to point out that minimization of the break will help in futureproofness. Applications that will be introduced in the future may be even more sensitive to the break (or the threshold for user perceived degradation may be lower) than the currently known ones. For example, if a packet is generated every 10 msec, the number of packets affected will be doubled. The only way to minimize the break is to do header compression context transfer. Khiem > -----Original Message----- > From: Koodli Rajeev (NRC/MtView) > Sent: Friday, April 06, 2001 1:13 PM > To: 'ext Michael Thomas'; Koodli Rajeev (NRC/MtView) > Cc: Le Khiem (NRC/Dallas); gkenward@nortelnetworks.com; > tmima@cisco.com; > mccap@research.bell-labs.com; kempf@heliopolis.Eng.Sun.COM; > mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se; seamoby@diameter.org > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile > IPv6 Handover > > > > > > > > rajeev.koodli@nokia.com writes: > > > > From: ext Michael Thomas [mailto:mat@cisco.com] > > > > > > Can somebody explain to me how this has any > > > > possible applicability if you are using FMIP > > > > during the transition? FMIP requires a new tunnel > > > > for which there will be no compression state in > > > > the old access router. > > > > > > > > > > If there is no compression state at the old router, why > > would you try to > > > relocate it ? > > > > There's compression state there, but not the > > compression state that matters: when I'm > > receiving packets from the old AR during the > > FMIP transition time, there will be a *new* > > IP header appended toward the MN. This is > > because those packets will have to be tunneled to the > > MN. This means that it is a *new* compression > > context, not an old existing one. > > > I don't have sufficient details to comment.. > > > > > All of these interactions with MIP, FMIP, HMIP > > > > etc, etc make it look to me like this is a losing > > > > situation. It may be the better part of valor to > > > > say that fast/smooth handoffs are inherently more > > > > bandwidth consumptive and that one of the > > > > casualties is header compression state in the mean > > > > time. > > > > > > Can you justify your claim above ? > > > > I can't prove negatives. I'm afraid that it > > is your place to prove that context transfer > > of header compression state in the face of all > > of these extenuating circumstances is still > > worthwhile. > > > > You can't justify your claims. So, before you raise issues > (related/unrelated), try to make an effort to understand the > work done by others. > > As far as I am concerned, how about all the e-mail discussion > during the last two weeks ? Please take a look! > > > > >Trying to extend a point to point L2 > > > > compression mechanism across an arbitrary internet > > > > is just *bizzare*. L2TP is bad enough. > > > > > > > > > > You are compressing IP and transport headers! This should > > work on ANY link. > > > That's why you try to CT header compression state. Get it ? > > > > Oh sure, I get it... I "get" VoMPLS too, but > > that doesn't make it any less bizarre. > > > > If you got it, you would probably re-think! If you were to > re-think and understand the issues, you would probably > question yourself what's bizarre, and then write. > > -Rajeev > > > Mike > > > From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 19:23: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 TAA19024 for ; Mon, 9 Apr 2001 19:23: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 QAA05017; Mon, 9 Apr 2001 16:22:44 -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 QAA23126; Mon, 9 Apr 2001 16:22:36 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39NKeK9010677 for ; Mon, 9 Apr 2001 16:20:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39NKd7G010676 for mobile-ip-dist; Mon, 9 Apr 2001 16:20: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 eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39NKYK9010669 for ; Mon, 9 Apr 2001 16:20:35 -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 TAA21625 for ; Mon, 9 Apr 2001 19:20:34 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA12092 for mobile-ip@sunroof.eng.sun.com; Mon, 9 Apr 2001 19:20:45 -0400 (EDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36LTRK9001551 for ; Fri, 6 Apr 2001 14:29:27 -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 OAA08384 for ; Fri, 6 Apr 2001 14:29:28 -0700 (PDT) From: khiem.le@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 PAA19252 for ; Fri, 6 Apr 2001 15:29:27 -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 f36LTUg18672 for ; Fri, 6 Apr 2001 16:29:30 -0500 (CDT) Received: from daebh01nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 6 Apr 2001 16:29:14 -0500 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Fri, 6 Apr 2001 16:29:14 -0500 Message-ID: <8572CF1E2A95D211A1190008C7EAA24602720927@daeis05nok> To: neumiller@telocity.com, khiem.le@nokia.com, rajeev.koodli@nokia.com, mat@cisco.com Cc: gkenward@nortelnetworks.com, tmima@cisco.com, mccap@research.bell-labs.com, kempf@heliopolis.Eng.Sun.COM, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Fri, 6 Apr 2001 16:29:13 -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: Hi, Please see my comments below. Khiem > -----Original Message----- > From: ext Phil Neumiller [mailto:neumiller@telocity.com] > Sent: Friday, April 06, 2001 4:03 PM > To: khiem.le@nokia.com; rajeev.koodli@nokia.com; mat@cisco.com > Cc: gkenward@nortelnetworks.com; tmima@cisco.com; > mccap@research.bell-labs.com; kempf@heliopolis.Eng.Sun.COM; > mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se; seamoby@diameter.org > Subject: Re: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile > IPv6 Handover > > > This arguments seems completely bogus to me or I am missing something > really fundamental here. Are not both 3GPP and 3GPP2 CDMA? This > whole discussion falls apart and dies on the floor than. KL: I would appreciate it if you could give specific arguments rather than qualifying other people's arguments as "bogus". It is easy to do that, and I can do that too, if I wanted to. Yes, you are missing something fundamental. All this discussion is about HARD Handoff, not soft handoff. Hard handoff exists in both CDMA and TDMA. Your issue with TDMA/CDMA is irrelevant. Evidently you have not read (http://www.cdt.luth.se/robhc/msg01274.html) referenced in one of my earlier mails. In that material, I clearly stated the problem is hard HO, not soft HO. If you could at least read and try to understand before commenting, we can have a more productive discussion. > > ----- Original Message ----- > From: > > > > There have been many mails pointing out the merit of doing header > > compression context transfer. To repeat them: > > continued, seamless compression/decompression, higher compression > > efficiency, and minimization of degradation on the user > media. This last > > point is the most important in my mind. At this stage, the > link technologies > > where header compression is going to be used are primarily > cellular links. > > 1). Based on what evidence? So far we have WAP, iMode, and iDen. KL: What do WAP, iMODE and iDEN have to do with RTP header compression? > Are you ignoring other possible edge and infrastructure > technologies like > wirelesss PANs, WLANs, ad hoc networks for any particular reason? KL: I am not ignoring them. I am just saying that the 3GPP and 3GPP2 technologies will be the first major cases of ROHC utilization. In fact the ROHC work was driven by the 3GPP needs. > > > In the cellular environment, handoffs (or handovers) are > events that happen > > in normal operation, and therefore a very significant > design effort is spent > > to minimize the impact of HO on performance. In particular, > one wants to > > minimize the duration of the break. > > In post-modern cellular systems there is no break! Wake up! Qualcomm > won the war a long time ago, I just can't get it why you guys > are still in > this "break" mind set. 3GPP and 3GPP2 use CDMA!!!! ITS MAKE BEFORE > BREAK. THE SOONER PEOPLE START LEARNING HOW TO DEAL > WITH IP PACKETS OVER CDMA w/ soft handover THE SOONER the > MIP list will finally mature to where it needs to be (i.e. > like OBAST :-)!!! KL: Hard handoff has a break, whether in CDMA or TDMA. Wakeup! > > > if brute force header compression reinitialization is done, > one would have to send > > certain number of 40-60 > > byte or more IR headers, instead of the usual 1 byte > header. This big > > bandwidth demand surge will put a strain on the link. > > Please quantify this purported bandwidth demand surge and it > origination. KL: Please refer to the ROHC specs for the size of the IR headers vs, the minimal size compressed header. > > > Some links will cope > > with it by blanking out the user data to make room to carry > the IR headers. > > When such blanking takes place, the user media (voice, etc.) will be > > unavoidably affected. > > Yes but why would we use MIPv6 over TDMA systems? I just don't get > this argument at all???? KL: There may be a confusion here. The issue of MIPv6 is orthogonal to the issue "what is the impact/benefits/costs of doing vs not doing header compression?" There are cases where ROHC header compression is used and header compression context transfer is beneficial, and yet there is no MIPv6 involved. Refer to the upcoming 3GPP release. > > >The impairment caused by the handoff is thus extended, > > compared to the case where header compression is not present. > > What it impairment, its a SOFT handoff? > > > > > In the current and 3G cellular technologies, the break is > about 100-150 > > msec, without header compression. > > The break will be 0 ms in 3G systems (only when a hard > handover is forced) > is that what you are designing for the error leg cases? KL: Why is the hard handoff an error leg case? Hard handoff is part of the normal operation. > Again this argument > seems rediculously TDMA. > > I feel like Rip Van Winkle, did I wake up and everything went back to > TDMA? Why are we discussing this with reference to IPv6 handovers?? KL: I was discussing the issue "what is the impact/benefits/costs of doing vs not doing header compression?" > > Regards, > > Phil > > From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 19:28: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 TAA19113 for ; Mon, 9 Apr 2001 19:28: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 QAA02009; Mon, 9 Apr 2001 16:27:56 -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 QAA01574; Mon, 9 Apr 2001 16:27:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39NQfK9010753 for ; Mon, 9 Apr 2001 16:26:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39NQfon010752 for mobile-ip-dist; Mon, 9 Apr 2001 16:26: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 eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39NQaK9010745 for ; Mon, 9 Apr 2001 16:26:36 -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 TAA07320 for ; Mon, 9 Apr 2001 19:26:36 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA12214 for mobile-ip@sunroof.eng.sun.com; Mon, 9 Apr 2001 19:26:46 -0400 (EDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36LoIK9001712 for ; Fri, 6 Apr 2001 14:50:18 -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 OAA07337 for ; Fri, 6 Apr 2001 14:50:19 -0700 (PDT) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA12127 for ; Fri, 6 Apr 2001 14:50:18 -0700 (PDT) Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-blue.research.att.com (Postfix) with ESMTP id 9D42F4CE58; Fri, 6 Apr 2001 17:50:11 -0400 (EDT) Received: from research.att.com (ltkostic [135.207.133.7]) by surfcity.research.att.com (8.8.7/8.8.7) with ESMTP id RAA08408; Fri, 6 Apr 2001 17:49:42 -0400 (EDT) Message-ID: <3ACE3A82.6321EF2D@research.att.com> Date: Fri, 06 Apr 2001 17:52:02 -0400 From: Zoran Kostic X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Phil Neumiller Cc: khiem.le@nokia.com, rajeev.koodli@nokia.com, mat@cisco.com, gkenward@nortelnetworks.com, tmima@cisco.com, mccap@research.bell-labs.com, kempf@heliopolis.Eng.Sun.COM, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: [mobile-ip] Re: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover References: <8572CF1E2A95D211A1190008C7EAA24602720924@daeis05nok> <001c01c0bedc$eedfc9a0$6501a8c0@philneum> 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 In response to the assumptions about soft-handoff by Phil Neumiller. * Soft-handoff is used and works well for VOICE in CDMA systems * All versions of data-carrying CDMA systems get away from soft-handoff - that includes Qualcomm's HDR, 3GPP Downlink shared channel, 3GPP High-speed downlink shared channel... Phil Neumiller wrote: > This arguments seems completely bogus to me or I am missing something > really fundamental here. Are not both 3GPP and 3GPP2 CDMA? This > whole discussion falls apart and dies on the floor than. > > ----- Original Message ----- > From: > > > There have been many mails pointing out the merit of doing header > > compression context transfer. To repeat them: > > continued, seamless compression/decompression, higher compression > > efficiency, and minimization of degradation on the user media. This last > > point is the most important in my mind. At this stage, the link technologies > > where header compression is going to be used are primarily cellular links. > > 1). Based on what evidence? So far we have WAP, iMode, and iDen. > Are you ignoring other possible edge and infrastructure technologies like > wirelesss PANs, WLANs, ad hoc networks for any particular reason? > > > In the cellular environment, handoffs (or handovers) are events that happen > > in normal operation, and therefore a very significant design effort is spent > > to minimize the impact of HO on performance. In particular, one wants to > > minimize the duration of the break. > > In post-modern cellular systems there is no break! Wake up! Qualcomm > won the war a long time ago, I just can't get it why you guys are still in > this "break" mind set. 3GPP and 3GPP2 use CDMA!!!! ITS MAKE BEFORE > BREAK. THE SOONER PEOPLE START LEARNING HOW TO DEAL > WITH IP PACKETS OVER CDMA w/ soft handover THE SOONER the > MIP list will finally mature to where it needs to be (i.e. like OBAST :-)!!! > > > if brute force header compression reinitialization is done, one would have to send > > certain number of 40-60 > > byte or more IR headers, instead of the usual 1 byte header. This big > > bandwidth demand surge will put a strain on the link. > > Please quantify this purported bandwidth demand surge and it origination. > > > Some links will cope > > with it by blanking out the user data to make room to carry the IR headers. > > When such blanking takes place, the user media (voice, etc.) will be > > unavoidably affected. > > Yes but why would we use MIPv6 over TDMA systems? I just don't get > this argument at all???? > > >The impairment caused by the handoff is thus extended, > > compared to the case where header compression is not present. > > What it impairment, its a SOFT handoff? > > > > > In the current and 3G cellular technologies, the break is about 100-150 > > msec, without header compression. > > The break will be 0 ms in 3G systems (only when a hard handover is forced) > is that what you are designing for the error leg cases? Again this argument > seems rediculously TDMA. > > I feel like Rip Van Winkle, did I wake up and everything went back to > TDMA? Why are we discussing this with reference to IPv6 handovers?? > > Regards, > > Phil > > --- > Mailing list for Robust Header Compression WG > Archive: http://www.cdt.luth.se/rohc/ From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 19:31: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 TAA19195 for ; Mon, 9 Apr 2001 19:31:41 -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 QAA03290; Mon, 9 Apr 2001 16:31: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 QAA24953; Mon, 9 Apr 2001 16:31:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39NTgK9010783 for ; Mon, 9 Apr 2001 16:29:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39NTfoH010780 for mobile-ip-dist; Mon, 9 Apr 2001 16:29: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 eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39NTaK9010773 for ; Mon, 9 Apr 2001 16:29:36 -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 TAA07532 for ; Mon, 9 Apr 2001 19:29:36 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA12274 for mobile-ip@sunroof.eng.sun.com; Mon, 9 Apr 2001 19:29:46 -0400 (EDT) Received: from centralmail1.Central.Sun.COM (centralmail1.Central.Sun.COM [129.147.62.10]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f370jFK9002204 for ; Fri, 6 Apr 2001 17:45:15 -0700 (PDT) Received: from esun1as-mm. (esun1as-mm.Central.Sun.COM [129.147.34.144]) by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id SAA24005 for ; Fri, 6 Apr 2001 18:45:16 -0600 (MDT) Received: from sunyata.sun.com by esun1as-mm. (SMI-8.6/SMI-SVR4) id SAA06060; Fri, 6 Apr 2001 18:49:04 -0600 Message-Id: <5.0.0.25.1.20010407090059.00a23ea0@localhost> X-Sender: kempf@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sat, 07 Apr 2001 09:03:31 +0900 To: mobile-ip@sunroof.eng.sun.com, "'mobile-ip@sunroof.eng.sun.com'" From: James Kempf Subject: Re: [mobile-ip] location privacy In-Reply-To: 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: I'm having a difficult time understanding what this means. Is this a euphonisum for NATs? I have an even more difficult time seeing how to implement it. The routers need to see an address to route the packet. What are the requirements driving this topic? jak At 08:34 AM 4/6/01 -0400, Phil Roberts wrote: >This and the next post I sent the last couple of days and never saw show up >on the list. If you saw them, sorry for the duplicates. > > >Hi, > > we have a charter item to "address location privacy." We'd like to >gather some information about what the working group thinks the extent of >the work on location privacy in this working group should be. It MUST in >some serious way be connected with the Mobile IP protocol. There will be in >the Apps area very soon a location privacy working group so we have to >realize that this working group will not be the place to resolve all issues >relating to location privacy. > >Phil From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 19:33: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 TAA19234 for ; Mon, 9 Apr 2001 19:33:35 -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 QAA11510; Mon, 9 Apr 2001 16:33:06 -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 QAA25409; Mon, 9 Apr 2001 16:32:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39NV5K9010794 for ; Mon, 9 Apr 2001 16:31:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39NV5ax010793 for mobile-ip-dist; Mon, 9 Apr 2001 16:31:05 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39NUxK9010786 for ; Mon, 9 Apr 2001 16:30:59 -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 TAA22418 for ; Mon, 9 Apr 2001 19:30:56 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA12161; Mon, 9 Apr 2001 19:23:45 -0400 (EDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36LmVK9001648 for ; Fri, 6 Apr 2001 14:48: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 OAA12078 for ; Fri, 6 Apr 2001 14:48:32 -0700 (PDT) From: khiem.le@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 OAA26320 for ; Fri, 6 Apr 2001 14:48:32 -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 f36Lofw04799 for ; Fri, 6 Apr 2001 16:50:41 -0500 (CDT) Received: from daebh02nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 6 Apr 2001 16:48:15 -0500 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Fri, 6 Apr 2001 16:48:15 -0500 Message-ID: <8572CF1E2A95D211A1190008C7EAA24602720928@daeis05nok> To: mat@cisco.com, khiem.le@nokia.com Cc: rajeev.koodli@nokia.com, gkenward@nortelnetworks.com, tmima@cisco.com, mccap@research.bell-labs.com, kempf@heliopolis.Eng.Sun.COM, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Fri, 6 Apr 2001 16:48:14 -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: *** Mail could not be accepted*** at onion.east.sun.com due to lack of disk space for temp file. From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 19:34: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 TAA19250 for ; Mon, 9 Apr 2001 19:34: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 QAA12181; Mon, 9 Apr 2001 16:34:07 -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 QAA02807; Mon, 9 Apr 2001 16:33:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39NWgK9010820 for ; Mon, 9 Apr 2001 16:32:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39NWgYh010819 for mobile-ip-dist; Mon, 9 Apr 2001 16:32: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 eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39NWbK9010812 for ; Mon, 9 Apr 2001 16:32:37 -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 TAA07782 for ; Mon, 9 Apr 2001 19:32:37 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA12330 for mobile-ip@sunroof.eng.sun.com; Mon, 9 Apr 2001 19:32:47 -0400 (EDT) Received: from centralmail1.Central.Sun.COM (centralmail1.Central.Sun.COM [129.147.62.10]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f371DbK9002236 for ; Fri, 6 Apr 2001 18:13:37 -0700 (PDT) Received: from esun1as-mm. (esun1as-mm.Central.Sun.COM [129.147.34.144]) by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id TAA28798 for ; Fri, 6 Apr 2001 19:13:38 -0600 (MDT) Received: from sunyata.sun.com by esun1as-mm. (SMI-8.6/SMI-SVR4) id TAA06592; Fri, 6 Apr 2001 19:17:28 -0600 Message-Id: <5.0.0.25.1.20010407100750.00a1fab0@localhost> X-Sender: kempf@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sat, 07 Apr 2001 10:08:42 +0900 To: mobile-ip@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com From: James Kempf Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6 In-Reply-To: <3ACE9071.A24EF754@Kniveton.com> References: <3ACDBFC1.F3E5121A@inrialpes.fr> <15053.58913.722549.842387@thomasm-u1.cisco.com> <3ACDEAB3.9E5ABDE9@inrialpes.fr> <3ACE016F.C744FDA5@cs.ucl.ac.uk> 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 08:58 PM 4/6/01 -0700, T.J. Kniveton wrote: >Another possibility is for the MR to muck with the IP headers of forwarded >packets from the prefix, putting the MR's CoA in the From field, and >inserting a home address option with the other node's address (original Src >addr). Ugly but I think it would work. This would cause triangular routing >of course. Although I am probably at risk of getting lynched for even mentioning this, having the mobile router act as a NAT might work. jak From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 19:37: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 TAA19308 for ; Mon, 9 Apr 2001 19:37: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 QAA13894; Mon, 9 Apr 2001 16:36: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 QAA03427; Mon, 9 Apr 2001 16:36:52 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39NZhK9010886 for ; Mon, 9 Apr 2001 16:35:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39NZh6a010885 for mobile-ip-dist; Mon, 9 Apr 2001 16:35:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39NZbK9010874 for ; Mon, 9 Apr 2001 16:35:38 -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 TAA08085 for ; Mon, 9 Apr 2001 19:35:37 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA12385 for mobile-ip@sunroof.eng.sun.com; Mon, 9 Apr 2001 19:35:48 -0400 (EDT) Received: from centralmail1.Central.Sun.COM (centralmail1.Central.Sun.COM [129.147.62.10]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f371XwK9002360 for ; Fri, 6 Apr 2001 18:33:59 -0700 (PDT) Received: from esun1as-mm. (esun1as-mm.Central.Sun.COM [129.147.34.144]) by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id TAA00851; Fri, 6 Apr 2001 19:33:57 -0600 (MDT) Received: from sunyata.sun.com by esun1as-mm. (SMI-8.6/SMI-SVR4) id TAA06911; Fri, 6 Apr 2001 19:37:45 -0600 Message-Id: <5.0.0.25.1.20010407101802.00a149a0@localhost> X-Sender: kempf@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sat, 07 Apr 2001 10:28:59 +0900 To: "Phil Neumiller" , , , From: James Kempf Subject: [mobile-ip] Re: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Cc: , , , , , In-Reply-To: <004601c0bee2$6ea57f40$6501a8c0@philneum> References: <8572CF1E2A95D211A1190008C7EAA24602720927@daeis05nok> 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: Phil, I think this discussion may be a case of misunderstanding about what is done where. Header compression seems of most value on what in 3GPP speak is called the nonaccess stratum. This is the packets that applications at the top of the mobile's stack sees, and these are the bits that go out over the air. These packets never see soft handoff, because they are segmented into radio frames by the time soft handoff occurs. The compression must be done before the packets are stuffed into radio frames. In the so-called access stratum, header compression may be used to remove header overhead on slow links so that the real time requirements of CDMA radio access can be met. There isn't an issue with moving context because the SDU is at a centrallly located point so when a soft handoff leg needs to be added, the SDU can take care of it. The only time there may be an issue is when the SDU itself gets relocated (called SRNS relocation in 3GPP speak). This is a fairly rare event, but would need to be handled in an IP RAN design. Or maybe you had something different in mind? jak At 04:42 PM 4/6/01 -0500, Phil Neumiller wrote: >OK, now I am really confused. Typically (in my previous experience) >with some very large cariers like Sprint, Verizon, etc, Hard handoffs >were about 5-10% of ALL handoffs. > >Why is there no interest/concern about the soft case WHICH HAS >NOT YET BEEN RESOLVED (i.e. the other 90%)?????????? > >Regards, > >Phil From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 19:40: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 TAA19431 for ; Mon, 9 Apr 2001 19:40: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 QAA15717; Mon, 9 Apr 2001 16:40:11 -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 QAA08151; Mon, 9 Apr 2001 16:40:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39NciK9010935 for ; Mon, 9 Apr 2001 16:38:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39Nci7M010934 for mobile-ip-dist; Mon, 9 Apr 2001 16:38: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 eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39NcdK9010927 for ; Mon, 9 Apr 2001 16:38:39 -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 TAA23208 for ; Mon, 9 Apr 2001 19:38:39 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA12438 for mobile-ip@sunroof.eng.sun.com; Mon, 9 Apr 2001 19:38:49 -0400 (EDT) Received: from centralmail1.Central.Sun.COM (centralmail1.Central.Sun.COM [129.147.62.10]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f371ldK9002399 for ; Fri, 6 Apr 2001 18:47:40 -0700 (PDT) Received: from esun1as-mm. (esun1as-mm.Central.Sun.COM [129.147.34.144]) by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id TAA02017; Fri, 6 Apr 2001 19:47:39 -0600 (MDT) Received: from sunyata.sun.com by esun1as-mm. (SMI-8.6/SMI-SVR4) id TAA07096; Fri, 6 Apr 2001 19:51:28 -0600 Message-Id: <5.0.0.25.1.20010407104123.00a23d10@localhost> X-Sender: kempf@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sat, 07 Apr 2001 10:42:42 +0900 To: "Phil Neumiller" , , , From: James Kempf Subject: [mobile-ip] Re: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Cc: , , , , , In-Reply-To: <005601c0bf04$2e81b240$6501a8c0@philneum> References: <8572CF1E2A95D211A1190008C7EAA24602720927@daeis05nok> <5.0.0.25.1.20010407101802.00a149a0@localhost> 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: Hi Phil, At 08:43 PM 4/6/01 -0500, Phil Neumiller wrote: >One question is the SRNS operation "soft" in the 3GPP design (because it >was in OBAST of course!). I think it is but it is not between BTSs (Node B) as I presume it was in OBAST. It is between RNCs (serving RNC to drift RNC, at which point, drift RNC becomes serving). jak From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 19:44: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 TAA19517 for ; Mon, 9 Apr 2001 19:44:07 -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 QAA08321; Mon, 9 Apr 2001 16:43:31 -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 QAA27519; Mon, 9 Apr 2001 16:43:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39NfjK9010964 for ; Mon, 9 Apr 2001 16:41:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39Nfi8A010963 for mobile-ip-dist; Mon, 9 Apr 2001 16:41: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 eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39NfdK9010956 for ; Mon, 9 Apr 2001 16:41:40 -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 TAA08564 for ; Mon, 9 Apr 2001 19:41:39 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA12494 for mobile-ip@sunroof.eng.sun.com; Mon, 9 Apr 2001 19:41:50 -0400 (EDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f397C1K9005782 for ; Mon, 9 Apr 2001 00:12:01 -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 AAA26338 for ; Mon, 9 Apr 2001 00:12: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 AAA26338 for ; Mon, 9 Apr 2001 00:12:01 -0700 (PDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id AAA29668 for ; Mon, 9 Apr 2001 00:12:00 -0700 (MST)] Received: [from m-il06-r4.mot.com (m-il06-r4.mot.com [129.188.137.196]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id AAA22707 for ; Mon, 9 Apr 2001 00:11:59 -0700 (MST)] Received: from [140.101.173.9] by m-il06-r4.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Mon, 9 Apr 2001 00:11:58 -0700 Received: (from root@localhost) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) id JAA28218 for mobile-ip@sunroof.eng.sun.com.DELIVER; Mon, 9 Apr 2001 09:11:55 +0200 (METDST) Received: from riri.crm.mot.com.crm.mot.com (kador.crm.mot.com [140.101.173.57]) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) with ESMTP id JAA28141 for ; Mon, 9 Apr 2001 09:11:54 +0200 (METDST) Cc: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: dynamic home addressing as a WG item?? References: <007701c0bc72$e2e47310$72f0b487@dnrc.belllabs.com> From: Alexandru Petrescu In-Reply-To: <007701c0bc72$e2e47310$72f0b487@dnrc.belllabs.com> Message-Id: User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: 09 Apr 2001 09:11:28 +0200 Lines: 167 Sender: owner-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, late, hesitations about relevance to mip] "Sandy Thuel" writes: > > > 1) What is the real value of DHCP options to > > > mobile nodes? I guess stateful mechanisms (being already available and centralizing control) are definitely an option to be exploited by MNs during configuration of their CoA. > > > 2) How important is it to minimize the > > > power-up configuration latency of a mobile > > > node? I don't know. But in this context I know that DHCPv6 mesages originally designed for power-up could also be used for lower latency handoffs. > > 1). We must figure out who wins the "I assign > > the address to the MN battle" in all possible > > scenarios including handoffs from MANETS > > (infrastructure-less) to MIP supported > > networks and handins and outs of > > zeroconf/DHCP/slp/UPnP/(MIP ^ MANET) supported > > subnets [do all the logical permutations]. I'm interested in "optimal autoconfiguration" with a competition between stateless and stateful. The rfc's specify a certain order (first do stateless then, depending on it, do stateful) but I think there's room for improvement. For example, I could imagine the MN could use quick stateless to obtain a temporary site-local address to query the DNS, all at the same time doing a heavier DHCPv6 exchange to obtain the CoA to register with HA. Alex Complete original message follows: > Hi Phil, > > Thanks for taking the time to offer your > perspectives on DHCP! See my comments in-line. > > > > 1) What is the real value of DHCP options to mobile > > > nodes? > > > > I guess I would even go a step further and question > > what is the real value of DHCP itself to mobile nodes? > > In the short term, it appears to be of quite high value. > > > > However... > > > > You're absolutely right in that this meta-question > needs to be answered at large. With the > proliferation of different devices and > address allocation mechanisms that promises to > be around in the foreseeable future, it is > really unclear what will emerge as the king > address/configuration allocator. However, given > its current entrenchment, I believe that DHCP > will continue to play an important role for > some time to come. As a result, enabling its > use for mobile IP nodes should not be overlooked. > > > I am pretty sure you can rule out DHCP on a > > CDMA radio!... > > Not necessarily! Some cellular operators in > 3GPP2 are looking into using DHCP. The competition > here is IPCP(PPP), which typically does the > address allocation. But PPP is unfriendly to > mobility, which has opened the door > for some to consider a MobileIP/DHCP solution. > > > > > > 2) How important is it to minimize the power-up > > > configuration latency of a mobile node? > > > > Are you are saying that DHCP would be a signficant > > portion of this? What proportion? Do you have a guess? > > Do you have analysis or measurements? Would it be milliseconds, > > seconds? Depending on the link layer used, power up > > configuration has a huge standard deviation all on its own. > > Of course we must add DHCP latency onto that directly. > > We and others have taken DHCP latency measurements > and have found them to be in the ballpark of > 100-300 msec. (after some much-needed optimizations > to enhance the performance of DHCP - e.g., > taking the time-consuming address conflict > checking step out of critical path at both > the server and the client). This assumes RTT > between server and client is negligible (say on > the order of 1 msec.). However, if the RTT > between the DHCP client and server is large, > the 2 RTT's involved in a client-server transaction > dominates the configuration latency and can > push it into the seconds scale. The question is > how much of a latency is too much? How much is > OK? > > > > > > > > > 3) How feasible do you think it is to > > > require changes on Mobile IP home agents > > > to provide a new service (e.g., DHCP proxy > > > service support)? > > > > Would need to be done in FAs too (for MIPv4)? > > Although I can envision putting a > DHCP proxy client service on FA's, that would > eliminate the key benefit of offering proxy > services at the HA: reducing the RTT between > the proxy DHCP client and server. > > > > > > > > > 4) How do you feel about the idea of adding > > > DHCP-specific extensions to Mobile IP > > > > NO. This is *EVIL*, and a very terrible idea. > > We're in complete agreement here. > > > > > When I re-read my comments I find they are of extremely > > limited use (low S/N ratio) so in summary let me give you > > my recommendation (worth about 2 cents these days): > > > > 1). We must figure out who wins the "I assign the address > > to the MN battle" in all possible scenarios including > > handoffs from MANETS (infrastructure-less) to > > MIP supported networks and handins and outs of > > zeroconf/DHCP/slp/UPnP/(MIP ^ MANET) supported > > subnets [do all the logical permutations]. > > > > > > 2). Who is asking for DHCP support now, i.e. who is the > > IETF customer for this work? Based on this, is this > > work justified or will it substantially improve routing > > configuration to/of mobile devices in the global Internet > > for the long term. > > > > My fear is that DHCP may become a thing of the past and > > things like BURP will open more doors to our future by > > allowing non-local secure authentication (which normally > > preceeds configuration) but we will see. > > I agree someone has to figure out these different > issues you've raised but am not sure that the > mobileip WG is the one to do so. What we > do know is that DHCP is heavily used now and that > we should leverage its use for configuring > mobile nodes (while it's around). If some other > handy-dandy configuration protocol becomes > prevalent and popular in the future, we can think > about how to make it work for mobile IP nodes > then. > > Regards, > Sandy From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 19:46: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 TAA19585 for ; Mon, 9 Apr 2001 19:46: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 QAA19810; Mon, 9 Apr 2001 16:46: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 QAA09406; Mon, 9 Apr 2001 16:46:17 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39NikK9011027 for ; Mon, 9 Apr 2001 16:44:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39Nij9Z011026 for mobile-ip-dist; Mon, 9 Apr 2001 16:44: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 eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39NieK9011017 for ; Mon, 9 Apr 2001 16:44:41 -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 TAA08879 for ; Mon, 9 Apr 2001 19:44:40 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA12547 for mobile-ip@sunroof.eng.sun.com; Mon, 9 Apr 2001 19:44:50 -0400 (EDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39F2aK9006913 for ; Mon, 9 Apr 2001 08:02:36 -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 IAA29391 for ; Mon, 9 Apr 2001 08:02:36 -0700 (PDT) Received: from isis.lip6.fr (isis.lip6.fr [132.227.60.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06998 for ; Mon, 9 Apr 2001 08:02:34 -0700 (PDT) Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.11.0/jtpda-5.3.2) with ESMTP id f39F2Yg11913 for ; Mon, 9 Apr 2001 17:02:34 +0200 Received: from avalon (avalon.ipv6.lip6.fr [132.227.72.134]) by tibre.lip6.fr (8.11.3/8.11.3) with SMTP id f39F2VD29529 for ; Mon, 9 Apr 2001 17:02:32 +0200 (CEST) From: "Gwendal Le Grand" To: Subject: RE: [mobile-ip] Requirements Draft for Mobile IP QoS - Invitation to Volunteer Date: Mon, 9 Apr 2001 17:02:34 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: 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 QAA19810 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA19585 I'd like to participate Gwendal -------Gwendal LE GRAND------- mailto:Gwendal.Le-Grand@lip6.fr tel: +33 (0) 1 44 27 75 12 http://www-rp.lip6.fr/~legrand fax: +33 (0) 1 44 27 74 95 Universite Pierre et Marie Curie, Laboratoire LIP6-CNRS, Bureau C646 8 Rue du Capitaine Scott, 75015 Paris, France > -----Message d'origine----- > De : owner-mobile-ip@sunroof.eng.sun.com > [mailto:owner-mobile-ip@sunroof.eng.sun.com]De la part de Hemant Chaskar > Envoyé : jeudi 5 avril 2001 21:47 > À : mobile-ip@sunroof.eng.sun.com > Objet : [mobile-ip] Requirements Draft for Mobile IP QoS - Invitation to > Volunteer > > > 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 > From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 19:49:33 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 TAA19625 for ; Mon, 9 Apr 2001 19:49: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 QAA21848; Mon, 9 Apr 2001 16:49:10 -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 QAA05575; Mon, 9 Apr 2001 16:49:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39NlmK9011144 for ; Mon, 9 Apr 2001 16:47:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39NlmU0011142 for mobile-ip-dist; Mon, 9 Apr 2001 16:47: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 eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39NleK9011127 for ; Mon, 9 Apr 2001 16:47:41 -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 TAA09194 for ; Mon, 9 Apr 2001 19:47:41 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA12604 for mobile-ip@sunroof.eng.sun.com; Mon, 9 Apr 2001 19:47:51 -0400 (EDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39GJUK9007375 for ; Mon, 9 Apr 2001 09:19: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 JAA25846 for ; Mon, 9 Apr 2001 09:19:30 -0700 (PDT) Message-Id: <200104091619.JAA25846@heliopolis.eng.sun.com> Date: Mon, 9 Apr 2001 09:19:30 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] MIP v6 Regional Registration - identifying re quirements To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: IpV6ik9CT8eAr07VQ1XgeQ== 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: Hesham, >> A short list of concerns include worries about introducing single >> points of failure, whether or not multiple levels of hierarchy are needed, >> the amount of signaling and tunneling overhead that is implied, the >> >> => We believe we got some confirmation for ROHC and CT >> folks that tunnelling will not be an issue. >> Well, I'm glad you think that, because I've seen nothing in the email thread that gives me any confidence at all that this will be possible. I've seen Rajeev's note that changing the IP address on the header might work, but not that changing 40 bytes of header option will. And the ROHC chairs have not come out one way or the other on this. >> We would like to add two more requirements. >> >> 0) Localised mobility management should provide the same >> level of mobility management support as in the basic >> MIPv6 specifiation. The mobility management functions >> supported in MIPv6 must not be reduced in such mechanism. >> >> 0.5) The provided mechanism must interwork with existing >> MIPv6, IPv6 and the proposed mechanisms for SA establishment >> in MIPv6. Yes, I would agreee. Additionally, I would add: The mechanism should minimize mobile node involvement in routing, beyond what the current MIPv6 requires. Preferences, load balancing, and other complex host-based mechanism whereby the mobile node, rather than the network, is involved in determining routes should be avoided, since one area IP networks have proven successful is separating routing from hosts and placing that functionality into the network. >> 6) Regional registration shall allow multiple levels of hierarchy >> >> => We can't see a reason for this requirement. We think it's >> OK if we want to support mobile networks but we don't >> think this requirement should be placed for all cases. >> We never got an answer for the technical merits of >> this requirement. It would be good to know why. Otherwise >> we'd like to remove this requirement. >> Hesham, I've given reasons for this requirement multiple times, but my impression is that you've ignored them. The fact of the matter is you don't believe it's important because HMIP can only do it to a limited extent. >> >> 8) Regional registration shall not require changes to the mobile node, the >> home agent, or correspondent nodes >> >> => We can understand the HA and CN, but no changes in the MN >> seems strange. Is this possible ? >> Ideally, this would be great. The less the mobile node has to change, the better. jak From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 19:55: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 TAA19777 for ; Mon, 9 Apr 2001 19:55:15 -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 QAA23775; Mon, 9 Apr 2001 16:52: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 QAA07313; Mon, 9 Apr 2001 16:51:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39NolK9011194 for ; Mon, 9 Apr 2001 16:50:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39Noluv011193 for mobile-ip-dist; Mon, 9 Apr 2001 16:50: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39NogK9011186 for ; Mon, 9 Apr 2001 16:50: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 TAA24305 for ; Mon, 9 Apr 2001 19:50:42 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA12657 for mobile-ip@sunroof.eng.sun.com; Mon, 9 Apr 2001 19:50:52 -0400 (EDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39GjIK9007727 for ; Mon, 9 Apr 2001 09:45: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 JAA27603 for ; Mon, 9 Apr 2001 09:45:17 -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 JAA23854 for ; Mon, 9 Apr 2001 09:45: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 JAA03620 for ; Mon, 9 Apr 2001 09:45:16 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f39GjEJ22870 for ; Mon, 9 Apr 2001 09:45:14 -0700 X-mProtect: Mon, 9 Apr 2001 09:45:14 -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(WTS.12.69) smtpdynY3JH; Mon, 09 Apr 2001 09:01:34 PDT Message-ID: <3AD1DCDE.DCE53ECD@iprg.nokia.com> Date: Mon, 09 Apr 2001 09:01:35 -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] MIP v6 Regional Registration - identifying re quirements References: <034BEFD03799D411A59F00508BDF7546013DBD74@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 Hi all, I agree that localised mobility management is probably a neutral term here and better for the discussions. I have some questions WRT Phil's requirements list.. please see below: > > > We would like to add two more requirements. > > > > 0) Localised mobility management should provide the same > > level of mobility management support as in the basic > > MIPv6 specifiation. The mobility management functions > > supported in MIPv6 must not be reduced in such mechanism. Could we have an example that constitutes a reason for such a requirement? I was under the impression that this was not an issue. Basically I am not clear on the possibility for reduction of the mobility management mechanisms in core MIPv6. > > > > > 0.5) The provided mechanism must interwork with existing > > MIPv6, IPv6 and the proposed mechanisms for SA establishment > > in MIPv6. I thought that the localised mobility extensions are working by default over core MIPv6 otherwise they would not be extensions. As such I assume a default fallback to core MIPv6 is the extensions do not come in effect. Aren't we stating the obvious here? > > > > 2) Regional registration shall not introduce new overhead on links between > > the mobile and the regional registration agents > > > > => We're not sure what this means. However if it means no more > > overhead than a BU then it's seems like a reasonable requirement. I agree this is not clear. Are we talking about extraneous signalling compared to core MIPv6? I think this is unrealistic since each approach may tackle localisation from a different angle/perspective and thus may have different signalling requirements. I would not expect a single BU to be the only signal since both localised mobility schemes introduce configuration of mobility agents with RT advert options. I think this is part of the protocol even if people push it as a configuration issue, since without it the protocol does not work! > > > > > 3) Connectivity to the mobiles shall not be interrupted in the presence of > > the failure of regional registration agents > > > > => Agreed. Although this should trigger some redundancy work > > in the MIP WG. But it should be kept as a target. I think that a single point of failure cannot be avoided by any localised scheme/extension to core MIPv6. The reason is simple: each scheme todate has got a at least one mobility agent that provides the localisation effect for the MN to the rest of the world. If that mobility agent goes down, then this will be the end of it and this goes for ANY localised mobility scheme unless people want to convince me for the opposite. As such while one requirement must be that the main mobility agent of reference (GMA, MAP) must not be allowed to degrade the benefit of the extension by failing, it is unavoidable for any scheme and thus a primary requirement. If the multiplicity of points of failure increase beyond 1, we need to attempt a minimization of them while sustaining the benefit of the extension in mobility, but also consider the actual tradeof for introducing it. That is optimizing localisation. > > > > > > > 6) Regional registration shall allow multiple levels of hierarchy > > > > => We can't see a reason for this requirement. We think it's > > OK if we want to support mobile networks but we don't > > think this requirement should be placed for all cases. > > We never got an answer for the technical merits of > > this requirement. It would be good to know why. Otherwise > > we'd like to remove this requirement. The fundamental reason for which I am convinced that multiple level of hierarchy do make a difference is the optimization of the localisation point. I won't elaborate further on the distribution of the signalling within a multi-level hierarchy per MN, but this is also another positive point. I feel that the requirement should stay but not be mandated. > > > > > 7) Regional registration shall support fast handoffs> > > > > => If that means coexist with the current FH proposal > > then we agree. > > > > 8) Regional registration shall not require changes to the mobile node, the > > home agent, or correspondent nodes > > > > => We can understand the HA and CN, but no changes in the MN > > seems strange. Is this possible ? > the localised extensions for the MIPv6 protocol are extensions because they provide somewhat special treatment in the localisation effect. In this the MN is the PRIMARY participant. Asking the MN to behave with nothing more than core MIPv6 functions is effectively excluding the MN from the special treatment that can make the extensions a reality. I believe that the requirement for no changes to the MN should be removed. > > > > 9) Regional registration shall not introduce host routes in routing tables > > > > => Agreed. As long as a Binding Cache entry is not regarded as > > a host route ? strictly speaking. > > I think here we have renamed things at one level (B-Cache) and masked out temporaly the issue of host routes. I think this is incorrect since host routes ARE already in the B-Cache and as such if such requirement is in effect and we want to be correct we have to scrap the B-Cache, which is an absolute no-no. Under this light I feel that the requirement for no introduction of host routes is not realistic. However, minimizing the amount of host routes should be a requirement. > > > > > Hesham, Claude and Karim > > Theo UCL/ Mobile Systems From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 19:55: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 TAA19789 for ; Mon, 9 Apr 2001 19:55: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 QAA12684; Mon, 9 Apr 2001 16:54: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 QAA06585; Mon, 9 Apr 2001 16:54:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39NrnK9011237 for ; Mon, 9 Apr 2001 16:53:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39NrnLi011236 for mobile-ip-dist; Mon, 9 Apr 2001 16:53: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 eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39NrgK9011223 for ; Mon, 9 Apr 2001 16:53: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 TAA24573 for ; Mon, 9 Apr 2001 19:53:43 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA12710 for mobile-ip@sunroof.eng.sun.com; Mon, 9 Apr 2001 19:53:53 -0400 (EDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39Gu7K9007857 for ; Mon, 9 Apr 2001 09:56:08 -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 JAA07434 for ; Mon, 9 Apr 2001 09:56:07 -0700 (PDT) Message-Id: <200104091656.JAA07434@heliopolis.eng.sun.com> Date: Mon, 9 Apr 2001 09:56:07 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] location privacy To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 6z9HdPvAZRABfhD2TesLaA== 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'm having a bit of difficulty seeing where this issue is coming from at the IP layer. Is this a pseudonym for NATs? Routers need to see the IP address in order to route. What is driving this requirement? jak From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 19:58: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 TAA19841 for ; Mon, 9 Apr 2001 19:58:42 -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 QAA27845; Mon, 9 Apr 2001 16:58: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 QAA07247; Mon, 9 Apr 2001 16:57:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39NumK9011269 for ; Mon, 9 Apr 2001 16:56:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39NumT2011268 for mobile-ip-dist; Mon, 9 Apr 2001 16:56: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 eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39NuhK9011261 for ; Mon, 9 Apr 2001 16:56: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 TAA24817 for ; Mon, 9 Apr 2001 19:56:43 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA12763 for mobile-ip@sunroof.eng.sun.com; Mon, 9 Apr 2001 19:56:53 -0400 (EDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39GqSK9007817 for ; Mon, 9 Apr 2001 09:52:29 -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 JAA06769 for ; Mon, 9 Apr 2001 09:52:28 -0700 (PDT) Message-Id: <200104091652.JAA06769@heliopolis.eng.sun.com> Date: Mon, 9 Apr 2001 09:52:28 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] IPv6 Regional Registration - identifying requirements To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 0gBi3x/cIy6o51BMUoc/cw== 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: Ok, second time I'm sending this out. Hopefully the server won't crash again. >1) Regional registration shall be introduced to minimize the signaling >traffic to the home agent or correspondent nodes for intra-domain mobility This is the basic requirement. If the regional reg proposal doesn't do this, then it isn't necessary. Maybe we would also like to tighten this up and require that the protocol provide additional support beyond simply introducing a local home agent and requiring the mobile node to get it's global IP address from the local home agent every time it started? The point of this is that if something as simple as introducing a local home agent will work, then why go for any more elaborate scheme. >2) Regional registration shall not introduce new overhead on links between >the mobile and the regional registration agents This is crucial. The ROHC group has yet to prove that even a change of CoA with context transfer will work, not to mention additional overhead. Therefore, it is prudent that we design RegReg so that we do not make assumptions about what ROHC will do. We have already run into a case where we have made assumptions about what another working group's work will do (namely IPSEC) and it has gotten us into trouble. In that case, the assumptions were based on published RFCs, ROHC doesn't even have that for context transfer/compressor restart with new state. >3) Connectivity to the mobiles shall not be interrupted in the presence of >the failure of regional registration agents The regional agents need to function more like routers, and exhibit the same kind of fail-over and self-healing. I think it needs to be a requirement that the regional registration scheme include this as a basic part of the protocol, not as a future study item. >4) Regional registration shall scale to support millions of nodes in a >visited network This requirement is too broad. What does this mean in terms of the properties of the protocol? See below for more on this. >5) Regional registration shall be secure against malicious behavior from >visiting mobiles Yes, this is important. >6) Regional registration shall allow multiple levels of hierarchy Absolutely critical. In our OpenRAN study, this was a deficiency we identified with HMIP basic mode. Mobile operators need to have the freedom to configure localized signalling according to their own needs. Also, being able to support multiple levels of hierarchy may help with supporting mobile routers, see below. >7) Regional registration shall support fast handoffs This is important, but it should not be part of the design. It should be possible to keep the fast handoff design orthogonal from the RegReg design, so that fast handoff can be used for straight MIPv6 as well. Perhaps the requirement should be restated as: Regional registration shall not impose any additional requirements on fast handoff beyond what is required by basic MIPv6. >8) Regional registration shall not require changes to the mobile node, the >home agent, or correspondent nodes Yes, keeping the mobile node unchanged is important. Ideally, a standard MIPv6 mobile node would work with a regional scheme without any change. Perhaps that is too optimistic. An additional requirement in this area is: Regional registration shall minimize the involvement of the mobile node in routing beyond what is in the basic MIPv6 protocol. Preferences, load balancing, and other complex schemes requiring heavy mobile node involvement in choosing routes should be avoided, since experience with IP networks has shown that routing decisions are best left to routers. >9) Regional registration shall not introduce host routes in routing tables > This relates to 4) above and is a specific consequence of scalability. However, I would say that the requirement should be: Regional registration shall assure that router state scales linearly with the number of mobile nodes registered, and that the increase in router state is confined to those routers involved in implementing the regional registration protocol. This covers any router state, including such MIP specific items as binding caches, not just host routes. I would also add the following requirement: Regional registration shall not degrade support for mobile routers beyond what basic MIPv6 supports, and should provide additional support if possible. jak From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 20:01: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 UAA19934 for ; Mon, 9 Apr 2001 20:01:58 -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 RAA00467; Mon, 9 Apr 2001 17:01: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 RAA08171; Mon, 9 Apr 2001 17:01:28 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39NxqK9011311 for ; Mon, 9 Apr 2001 16:59:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39NxpiN011309 for mobile-ip-dist; Mon, 9 Apr 2001 16:59: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 eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39NxiK9011299 for ; Mon, 9 Apr 2001 16:59:44 -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 TAA25062 for ; Mon, 9 Apr 2001 19:59:44 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA12822 for mobile-ip@sunroof.eng.sun.com; Mon, 9 Apr 2001 19:59:54 -0400 (EDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39GjIK9007727 for ; Mon, 9 Apr 2001 09:45: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 JAA27603 for ; Mon, 9 Apr 2001 09:45:17 -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 JAA23854 for ; Mon, 9 Apr 2001 09:45: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 JAA03620 for ; Mon, 9 Apr 2001 09:45:16 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f39GjEJ22870 for ; Mon, 9 Apr 2001 09:45:14 -0700 X-mProtect: Mon, 9 Apr 2001 09:45:14 -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(WTS.12.69) smtpdynY3JH; Mon, 09 Apr 2001 09:01:34 PDT Message-ID: <3AD1DCDE.DCE53ECD@iprg.nokia.com> Date: Mon, 09 Apr 2001 09:01:35 -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] MIP v6 Regional Registration - identifying re quirements References: <034BEFD03799D411A59F00508BDF7546013DBD74@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 Hi all, I agree that localised mobility management is probably a neutral term here and better for the discussions. I have some questions WRT Phil's requirements list.. please see below: > > > We would like to add two more requirements. > > > > 0) Localised mobility management should provide the same > > level of mobility management support as in the basic > > MIPv6 specifiation. The mobility management functions > > supported in MIPv6 must not be reduced in such mechanism. Could we have an example that constitutes a reason for such a requirement? I was under the impression that this was not an issue. Basically I am not clear on the possibility for reduction of the mobility management mechanisms in core MIPv6. > > > > > 0.5) The provided mechanism must interwork with existing > > MIPv6, IPv6 and the proposed mechanisms for SA establishment > > in MIPv6. I thought that the localised mobility extensions are working by default over core MIPv6 otherwise they would not be extensions. As such I assume a default fallback to core MIPv6 is the extensions do not come in effect. Aren't we stating the obvious here? > > > > 2) Regional registration shall not introduce new overhead on links between > > the mobile and the regional registration agents > > > > => We're not sure what this means. However if it means no more > > overhead than a BU then it's seems like a reasonable requirement. I agree this is not clear. Are we talking about extraneous signalling compared to core MIPv6? I think this is unrealistic since each approach may tackle localisation from a different angle/perspective and thus may have different signalling requirements. I would not expect a single BU to be the only signal since both localised mobility schemes introduce configuration of mobility agents with RT advert options. I think this is part of the protocol even if people push it as a configuration issue, since without it the protocol does not work! > > > > > 3) Connectivity to the mobiles shall not be interrupted in the presence of > > the failure of regional registration agents > > > > => Agreed. Although this should trigger some redundancy work > > in the MIP WG. But it should be kept as a target. I think that a single point of failure cannot be avoided by any localised scheme/extension to core MIPv6. The reason is simple: each scheme todate has got a at least one mobility agent that provides the localisation effect for the MN to the rest of the world. If that mobility agent goes down, then this will be the end of it and this goes for ANY localised mobility scheme unless people want to convince me for the opposite. As such while one requirement must be that the main mobility agent of reference (GMA, MAP) must not be allowed to degrade the benefit of the extension by failing, it is unavoidable for any scheme and thus a primary requirement. If the multiplicity of points of failure increase beyond 1, we need to attempt a minimization of them while sustaining the benefit of the extension in mobility, but also consider the actual tradeof for introducing it. That is optimizing localisation. > > > > > > > 6) Regional registration shall allow multiple levels of hierarchy > > > > => We can't see a reason for this requirement. We think it's > > OK if we want to support mobile networks but we don't > > think this requirement should be placed for all cases. > > We never got an answer for the technical merits of > > this requirement. It would be good to know why. Otherwise > > we'd like to remove this requirement. The fundamental reason for which I am convinced that multiple level of hierarchy do make a difference is the optimization of the localisation point. I won't elaborate further on the distribution of the signalling within a multi-level hierarchy per MN, but this is also another positive point. I feel that the requirement should stay but not be mandated. > > > > > 7) Regional registration shall support fast handoffs> > > > > => If that means coexist with the current FH proposal > > then we agree. > > > > 8) Regional registration shall not require changes to the mobile node, the > > home agent, or correspondent nodes > > > > => We can understand the HA and CN, but no changes in the MN > > seems strange. Is this possible ? > the localised extensions for the MIPv6 protocol are extensions because they provide somewhat special treatment in the localisation effect. In this the MN is the PRIMARY participant. Asking the MN to behave with nothing more than core MIPv6 functions is effectively excluding the MN from the special treatment that can make the extensions a reality. I believe that the requirement for no changes to the MN should be removed. > > > > 9) Regional registration shall not introduce host routes in routing tables > > > > => Agreed. As long as a Binding Cache entry is not regarded as > > a host route ? strictly speaking. > > I think here we have renamed things at one level (B-Cache) and masked out temporaly the issue of host routes. I think this is incorrect since host routes ARE already in the B-Cache and as such if such requirement is in effect and we want to be correct we have to scrap the B-Cache, which is an absolute no-no. Under this light I feel that the requirement for no introduction of host routes is not realistic. However, minimizing the amount of host routes should be a requirement. > > > > > Hesham, Claude and Karim > > Theo UCL/ Mobile Systems From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 20:04: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 UAA20004 for ; Mon, 9 Apr 2001 20:04: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 RAA02139; Mon, 9 Apr 2001 17:04: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 RAA09918; Mon, 9 Apr 2001 17:04:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3A02oK9011331 for ; Mon, 9 Apr 2001 17:02:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3A02nFT011330 for mobile-ip-dist; Mon, 9 Apr 2001 17:02: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 eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3A02iK9011323 for ; Mon, 9 Apr 2001 17:02:45 -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 UAA25598 for ; Mon, 9 Apr 2001 20:02:45 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id UAA12876 for mobile-ip@sunroof.eng.sun.com; Mon, 9 Apr 2001 20:02:55 -0400 (EDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39GE4K9007282 for ; Mon, 9 Apr 2001 09:14: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 JAA23626 for ; Mon, 9 Apr 2001 09:14:04 -0700 (PDT) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA19724 for ; Mon, 9 Apr 2001 09:14:01 -0700 (PDT) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Mon Apr 9 12:12:58 EDT 2001 Received: from valjean.dnrc.bell-labs.com (valjean [135.180.240.120]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id MAA01510 for ; Mon, 9 Apr 2001 12:13:11 -0400 (EDT) Received: (from salga@localhost) by valjean.dnrc.bell-labs.com (8.11.0/8.8.7) id f39GCxD22647 for mobile-ip@sunroof.eng.sun.com; Mon, 9 Apr 2001 12:12:59 -0400 Date: Tue, 3 Apr 2001 11:22:22 -0400 From: Luca Salgarelli To: mobile-ip@sunroof.eng.sun.com Subject: Re: Some comments on: [mobile-ip] dynamic home addressing as a WG item?? Message-ID: <20010403112222.R3284@bell-labs.com> Mail-Followup-To: mobile-ip@sunroof.eng.sun.com References: <006101c0bbbd$1184e8f0$72f0b487@dnrc.belllabs.com> <017101c0bbd8$4270e980$6501a8c0@philneum> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <017101c0bbd8$4270e980$6501a8c0@philneum>; from neumiller@telocity.com on Mon, Apr 02, 2001 at 07:51:39PM -0500 X-Organization: Bell Laboratories Sender: owner-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 Phil. Although my K-mart crystal ball would tend to agree with yours if I look at some distant future :-), I would argue that today's and mid-term future networks are going to be largely based on IPv4. In these networks, DHCP seems to be the protocol of choice to dynamically configure clients. For example, almost all the deployments I know of 802.11b use DHCP to configure clients. If we add mobility support to those networks (i.e. MIPv4), I think that making MIPv4 gracefully interoperate with DHCP is not an option: it is a requirement. > > 2) How important is it to minimize the power-up > > configuration latency of a mobile node? > > Are you are saying that DHCP would be a signficant > portion of this? What proportion? Do you have a guess? > Do you have analysis or measurements? Would it be milliseconds, > seconds? Depending on the link layer used, power up > configuration has a huge standard deviation all on its own. > Of course we must add DHCP latency onto that directly. The DHCP proportion here is simple: a DHCP transaction takes 2 RTTs. > > 4) How do you feel about the idea of adding > > DHCP-specific extensions to Mobile IP > > NO. This is *EVIL*, and a very terrible idea. I never > want to see these words again! :-) No really, this is probably > not necessary. At least in the protocol sense. Could this not I agree with you. Luca On Mon, Apr 02, 2001 at 07:51:39PM -0500, Phil Neumiller wrote: > Hi Sandy, > > Some comments below (this is so long that you might > want to get a beverage). > > ----- Original Message ----- > From: "Sandy Thuel" > To: > Cc: > > Hi Folks, > > > > > > 1) What is the real value of DHCP options to mobile > > nodes? > > I guess I would even go a step further and question > what is the real value of DHCP itself to mobile nodes? > In the short term, it appears to be of quite high value. > > However... > > In my K-mart crystal ball (kind of cracked and fuzzy) I > see lots of cheap wireless devices that will be used to > living in MANETs *or* in infrastructures in the future. I see > this big train wreck of who gets to pick the mobile's IP > address coming. I suppose, if its a Windows type of > box, it will be UPnP, if its Bluetooth type of device, > well um, we need to wait until the BT SIG releases the > next spec, if its an 802.11b device, I don' know of > *any* commercial MANETs on 802.11 (know of some > in labs!), if its a 3G device I am not sure yet but, > I am pretty sure you can rule out DHCP on a > CDMA radio!..., then we have zeroconf in there too > along with SLP, Jini, and all kinds of other stuff trying > to figure out what the heck is going on and what the IP > addr and COA is (did I forget to mention ou friend > MIP acting as an MN). If it starts out as a MANET > MN and wants to hand up to being a full fledged up routable > fixed citizen like in a docking station I don't know what > the best answer is currently. Thank goodness we don't > have micro-mobility to worry about anymore!!! At least > for now... > > In the current home or enterprise WLAN/WPAN > markets the sheer simplicity of DHCP brings joy > to many people's hearts. However, in my crystal > ball I see a darker future of sheer chaos. DHCP is > basically founded upon a client server model, an > anachronism in today's SAN infested B2B IP planet > that is rapidly going peer-2-peer, as fast as you can > say gnutella (that's April 2001 for Napster). > > So what are we left with? Burning IEEE MAC > addresses into the foreheads of everywireless device and > doing RARPs? MANET addressing (a matter with its own > set of controversies)? Or a host of other jihads that > I am sure could be enumerated (please don't). > > > 2) How important is it to minimize the power-up > > configuration latency of a mobile node? > > Are you are saying that DHCP would be a signficant > portion of this? What proportion? Do you have a guess? > Do you have analysis or measurements? Would it be milliseconds, > seconds? Depending on the link layer used, power up > configuration has a huge standard deviation all on its own. > Of course we must add DHCP latency onto that directly. > > > > > 3) How feasible do you think it is to > > require changes on Mobile IP home agents > > to provide a new service (e.g., DHCP proxy > > service support)? > > Would need to be done in FAs too (for MIPv4)? > > > > > 4) How do you feel about the idea of adding > > DHCP-specific extensions to Mobile IP > > NO. This is *EVIL*, and a very terrible idea. I never > want to see these words again! :-) No really, this is probably > not necessary. At least in the protocol sense. Could this not > be done by some clever spoofing inside an AR where the > DHCP server spoofs the FA/HA but hands out the actual > address? I know this is kind of an implementor's hack, but > to change MIP enmeshes something so systemic as > DHCP with something so systemic with MIP and it makes > me say want to say YUCK really loud. I actually prefer the > coding hack to the design hack! > > When I re-read my comments I find they are of extremely > limited use (low S/N ratio) so in summary let me give you > my recommendation (worth about 2 cents these days): > > 1). We must figure out who wins the "I assign the address > to the MN battle" in all possible scenarios including > handoffs from MANETS (infrastructure-less) to > MIP supported networks and handins and outs of > zeroconf/DHCP/slp/UPnP/(MIP ^ MANET) supported > subnets [do all the logical permutations]. > > 2). Who is asking for DHCP support now, i.e. who is the > IETF customer for this work? Based on this, is this > work justified or will it substantially improve routing > configuration to/of mobile devices in the global Internet > for the long term. > > My fear is that DHCP may become a thing of the past and > things like BURP will open more doors to our future by > allowing non-local secure authentication (which normally > preceeds configuration) but we will see. > > Best regards, > > Phil From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 9 20:10: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 UAA20091 for ; Mon, 9 Apr 2001 20:10:35 -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 RAA19120; Mon, 9 Apr 2001 17:09: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 RAA14395; Mon, 9 Apr 2001 17:09:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3A08YK9011401 for ; Mon, 9 Apr 2001 17:08:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3A08YMk011400 for mobile-ip-dist; Mon, 9 Apr 2001 17:08:34 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3A08PK9011393 for ; Mon, 9 Apr 2001 17:08:25 -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 RAA14082 for ; Mon, 9 Apr 2001 17:08:25 -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 SAA28434 for ; Mon, 9 Apr 2001 18:08:12 -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 f3A08Ms27331 for ; Tue, 10 Apr 2001 02:08:22 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Tue Apr 10 02:08:22 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Apr 2001 02:03:57 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBD7B@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] MIP v6 Regional Registration - identifying re qui rements Date: Tue, 10 Apr 2001 02:08:18 +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: James, > >> A short list of concerns include worries about introducing single > >> points of failure, whether or not multiple levels of hierarchy are > needed, > >> the amount of signaling and tunneling overhead that is implied, the > >> > >> => We believe we got some confirmation for ROHC and CT > >> folks that tunnelling will not be an issue. > >> > > Well, I'm glad you think that, because I've seen nothing in the > email thread that gives me any confidence at all that this will > be possible. I've seen Rajeev's note that changing the IP > address on the header might work, but not that changing 40 bytes > of header option will. And the ROHC chairs have not come out > one way or the other on this. > => We have heard at least 4 times now that ROHC will handle IP in IP tunnels. IPv6 in IPv4 will also be handled. We don't need to discuss this since you can verify it by reading the spec. As for sending full headers after handovers, we've seen the discussions, one camp says that simultions have proven that losing more than 3 packets in WCDMA (an example of an error prone environment) is extremely unlikey. The other camp disagrees and says that the problem exists and can be solved by CT. What more do we need to know ? I don't think this is relevant to HMIPv6 only so I don't see why this keeps coming up in relation to HMIPv6. > >> We would like to add two more requirements. > >> > >> 0) Localised mobility management should provide the same > >> level of mobility management support as in the basic > >> MIPv6 specifiation. The mobility management functions > >> supported in MIPv6 must not be reduced in such mechanism. > >> > >> 0.5) The provided mechanism must interwork with existing > >> MIPv6, IPv6 and the proposed mechanisms for SA establishment > >> in MIPv6. > > Yes, I would agreee. > > Additionally, I would add: > > The mechanism should minimize mobile node involvement in routing, > beyond what the current MIPv6 requires. Preferences, load balancing, > and other complex host-based mechanism whereby the mobile node, > rather than the network, is involved in determining routes should > be avoided, > => I guess you are referring to HMIPv6 here and no the requirements in an abstract sense. The preference value was first introduced in the MIPv6 spec for the HA. Why is this any different ? do you have the same reservation on MIPv6 ? If so I disagree. I think the HA's preference field is useful. Regarding load balancing, this is something that we believe is important and needed. However, based on comments received we will put it in a different drat. This is not a new thing, it already exists in routers today. Furthermore, in some cellular networks (3GPP) a very similar feature is implemented in the GGSN. This is _already_being_developed in products (GGSNs). > >> 6) Regional registration shall allow multiple levels of hierarchy > >> > >> => We can't see a reason for this requirement. We think it's > >> OK if we want to support mobile networks but we don't > >> think this requirement should be placed for all cases. > >> We never got an answer for the technical merits of > >> this requirement. It would be good to know why. Otherwise > >> we'd like to remove this requirement. > >> > > Hesham, I've given reasons for this requirement multiple times, but > my impression is that you've ignored them. The fact of the matter is you don't > believe it's important because HMIP can only do it to a limited extent. > => Actually I haven't ignored anything. You haven't mentioned any reasons on this list or others. If I missed it, please point me to the mail or date and I'l look it up. When we discussed this in private I responded and didn't get a reply. So it would be much easier IMO if you just tell us the reasons. > >> > >> 8) Regional registration shall not require changes to the mobile node, > the > >> home agent, or correspondent nodes > >> > >> => We can understand the HA and CN, but no changes in the MN > >> seems strange. Is this possible ? > >> > > Ideally, this would be great. The less the mobile node has to > change, the better. > => Ageed, but I don't think it's possible. I stand corrected. Hesham > jak From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 10 05:23: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 FAA10021 for ; Tue, 10 Apr 2001 05:23:36 -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 CAA18564; Tue, 10 Apr 2001 02:22:30 -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 CAA28395; Tue, 10 Apr 2001 02:22:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3A9KXK9013107 for ; Tue, 10 Apr 2001 02:20:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3A9KX2U013106 for mobile-ip-dist; Tue, 10 Apr 2001 02:20: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3A9KOK9013099 for ; Tue, 10 Apr 2001 02:20:25 -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 CAA06124 for ; Tue, 10 Apr 2001 02:20:24 -0700 (PDT) Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA17454 for ; Tue, 10 Apr 2001 02:20:22 -0700 (PDT) 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 LAA29272; Tue, 10 Apr 2001 11:20:20 +0200 (MET DST) Message-ID: <3AD2D07B.C3900AE@darmstadt.gmd.de> Date: Tue, 10 Apr 2001 11:20:59 +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 CC: "Shahrier, Sharif M." Subject: Re: [mobile-ip] some issues with IPv6 mobility draft (sharif) 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 "Shahrier, Sharif M." wrote: > > I have some issues to discuss with the document: > > "Mobility Support in IPv6" > > > I would be grateful if people can take a look and make any contructive > comments. Thanks. > > 1. Consider A, B where A is the mobile and B is the correpondent node. > A is currently away from its home agent. B is also a mobile node. Suppose A send a > BU(A) and moves to its new location. The network is heavily loaded, and B has not > yet received the binding update. B also was to move. Thus, similarly, it sends a > BU(B) to A, and moves to its new location. The binding updates BU(A) and BU(B) eventually > arrives at A's and B's previous locations, respectively. But A and B have already > moved. This means that nodes neither A or B will are aware of each other new > respective locations. > > Thus, I believe this is be an erronous condition wrt A and B not knowing each others > final destination addresses. Let me work out this scenario in more detail. The BU(A) message informs all nodes which handle A's mobility (let us call them "mobile anchor points", following the hmipv6 draft) to forward packets addressed to A to the new position of A. Obviously, BU(A) should be sent in such a way that packets routed according to it cannot arrive at the new position before A itself arrives. To this end, A sends BU(A) after it arrives. Now consider a data stream sent from some other node B to A. The mobile anchor points re-direct this stream to A's new position after they received BU(A). Since there are non-zero intervals between the points in time where - A left the old position - the mobile anchor points re-direct the stream some packets will be lost. But assume that they are recovered by some TCP-like mechanism, i.e. that no packets sent to A are lost. This holds also for BU(B) messages, and mobility of A is handled correctly. By symmetry, the same applies to B. This means that your scenario is no principal problem (if the assumptions I mentioned really hold). But recovery of packets lost during mobility support may cause a considerable delay of binding updates which in turn will make mobility handling longer so that more packets are lost ... Wolfgang (Sorry for skipping your other comments) From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 10 06:01: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 GAA10236 for ; Tue, 10 Apr 2001 06:01:09 -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 DAA01700; Tue, 10 Apr 2001 03:00:01 -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 DAA08773; Tue, 10 Apr 2001 03:00:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3A9x7K9013157 for ; Tue, 10 Apr 2001 02:59:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3A9x7wR013156 for mobile-ip-dist; Tue, 10 Apr 2001 02:59: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3A9wwK9013149 for ; Tue, 10 Apr 2001 02:58:58 -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 CAA07518 for ; Tue, 10 Apr 2001 02:58:57 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA05940 for ; Tue, 10 Apr 2001 02:58:56 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f3A9woe16080; Tue, 10 Apr 2001 11:58:51 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA17664; Tue, 10 Apr 2001 11:58:50 +0200 (MET DST) Received: from localhost (localhost [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f3A9wnA38914; Tue, 10 Apr 2001 11:58:49 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200104100958.f3A9wnA38914@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: "Kiernan, Brian G." , "'charliep@iprg.nokia.com'" , "Shahrier, Sharif M." Subject: Re: [mobile-ip] some issues with IPv6 mobility draft (sharif) In-reply-to: Your message of Mon, 09 Apr 2001 15:37:55 EDT. Date: Tue, 10 Apr 2001 11:58:49 +0200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: 1. Consider A, B where A is the mobile and B is the correpondent node. A is currently away from its home agent. B is also a mobile node. Suppose A send a BU(A) and moves to its new location. The network is heavily loaded, and B has not yet received the binding update. B also was to move. Thus, similarly, it sends a BU(B) to A, and moves to its new location. The binding updates BU(A) and BU(B) eventually arrives at A's and B's previous locations, respectively. But A and B have already moved. This means that nodes neither A or B will are aware of each other new respective locations. => this situation (mobile to mobile) is addressed by sections 8.7 and 8.8 (but some junk proposals don't solve this so your question is pertinent). 2. In light of the potential problem in (1), I propose that we eliminate all signaling between mobile-to-mobile with respect to Binding Update and Binding Request messages. => first (1) is not a problem, second to use the home agent as a signaling agent is more complex and in general less efficient (the direct/optimized path is always shorter than the home agent one, this is the essential property of a distance in maths). Unfortunately this doesn't solve current security problems too because the home agent is not more special than the mobile node... 3. Multiple home links. => this should be in an application document because this doesn't change the protocol, only the way to use it. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 10 06:20:13 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 GAA10365 for ; Tue, 10 Apr 2001 06:20:13 -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 DAA08638; Tue, 10 Apr 2001 03:19:08 -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 DAA09564; Tue, 10 Apr 2001 03:19:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3AAIFK9013208 for ; Tue, 10 Apr 2001 03:18:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3AAIEjR013207 for mobile-ip-dist; Tue, 10 Apr 2001 03:18: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3AAI6K9013200 for ; Tue, 10 Apr 2001 03:18:06 -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 DAA09431 for ; Tue, 10 Apr 2001 03:18:05 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA12424 for ; Tue, 10 Apr 2001 03:18:03 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f3AAI1e14519 for ; Tue, 10 Apr 2001 12:18:02 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id MAA17999 for ; Tue, 10 Apr 2001 12:18:01 +0200 (MET DST) Received: from localhost (localhost [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f3AAI1A39097 for ; Tue, 10 Apr 2001 12:18:01 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200104101018.f3AAI1A39097@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] some issues with IPv6 mobility draft (sharif) In-reply-to: Your message of Tue, 10 Apr 2001 00:04:03 +0200. <3AD231D3.7C47C799@fokus.gmd.de> Date: Tue, 10 Apr 2001 12:18:01 +0200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: I think we should only send binding updates to the home address of the "mobile" CN (or the correspondent MN? :)). This means we must not use the binding cache when sending a binding update. => but this is less efficient if the mobile CN has not moved. The real answer (which is described in the draft!) is to send the BU to the CN as a standard packet but to flush the binding cache entry of the mobile CN if communication seems to be stalled or when ICMPs show something is wrong. This approach will solve this problem with only a minor modification on the MN code. => the draft solution works without any modification in this rare but possible case and is cleaner(*), simpler and more efficient in the general case. (PS: cleaner because this doesn't mixed the MN and the CN codes). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 10 06:28: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 GAA10412 for ; Tue, 10 Apr 2001 06:28:07 -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 DAA11157; Tue, 10 Apr 2001 03:26:50 -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 DAA11428; Tue, 10 Apr 2001 03:27:16 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3AAQ6K9013246 for ; Tue, 10 Apr 2001 03:26:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3AAQ6pk013245 for mobile-ip-dist; Tue, 10 Apr 2001 03:26: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3AAPvK9013238 for ; Tue, 10 Apr 2001 03:25:57 -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 DAA11312 for ; Tue, 10 Apr 2001 03:25:56 -0700 (PDT) Received: from bob.dera.gov.uk (bob.dera.gov.uk [192.5.29.90]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA15691 for ; Tue, 10 Apr 2001 03:25:56 -0700 (PDT) Received: by bob.dera.gov.uk; (8.8.8/1.3/10May95) id LAA23984; Tue, 10 Apr 2001 11:29:07 +0100 (BST) Received: (qmail 22758 invoked from network); 10 Apr 2001 11:16:18 -0000 Received: from gauntlet.mail.dera.gov.uk (172.16.9.10) by baton.dera.gov.uk with SMTP; 10 Apr 2001 11:16:18 -0000 Received: by gauntlet.mail.dera.gov.uk; id LAA20791; Tue, 10 Apr 2001 11:01:24 GMT Received: from unknown(10.71.64.31) by gauntlet.mail.dera.gov.uk via smap (3.2) id xma020425; Tue, 10 Apr 01 11:00:40 GMT Received: from FRN-MAIL-3.dera.gov.uk (unverified) by mailguard.dera.gov.uk (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Tue, 10 Apr 2001 11:31:31 +0100 Received: by frn-mail-3.dera.gov.uk with Internet Mail Service (5.5.2650.21) id <2MRA63BC>; Tue, 10 Apr 2001 11:24:58 +0100 Message-ID: <25649633ECEAD411AE9900508BCF86950DD975@mal-mail-2.dera.gov.uk> From: Murray Philip To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Requirements Draft for Mobile IP QoS - Invitation to Volunteer Date: Tue, 10 Apr 2001 11:24:58 +0100 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: Hemant I would like to be involved in this if possible Cheers Phil Phil Murray PC106b DERA St Andrews Road Malvern Worcestershire WR14 3PS Tel: +44 (0)1684 89 7364 Fax: +44 (0)1684 89 6247 >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 -- The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful. From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 10 07:44: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 HAA11895 for ; Tue, 10 Apr 2001 07:44:03 -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 EAA02841; Tue, 10 Apr 2001 04:42:49 -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 EAA15779; Tue, 10 Apr 2001 04:43:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3ABg1K9013390 for ; Tue, 10 Apr 2001 04:42:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3ABg0qr013389 for mobile-ip-dist; Tue, 10 Apr 2001 04:42: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3ABfpK9013382 for ; Tue, 10 Apr 2001 04:41:52 -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 EAA15693 for ; Tue, 10 Apr 2001 04:41:50 -0700 (PDT) Received: from tadlys-ryszbk3n.tadlys.com ([192.116.242.18]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA25541 for ; Tue, 10 Apr 2001 04:41:48 -0700 (PDT) content-class: urn:content-classes:message Subject: RE: [mobile-ip] Requirements Draft for Mobile IP QoS - Invitation to Volunteer Date: Tue, 10 Apr 2001 13:43:04 +0200 Message-ID: <7FC7789C292A1944A1DA28017A709B5B04977A@tadlys-ryszbk3n.tadlys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Thread-Topic: [mobile-ip] Requirements Draft for Mobile IP QoS - Invitation to Volunteer Thread-Index: AcDBs2drgAex6f7zQdCiwVwY9sGVMQ== From: "David Almer" To: X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Cc: "David Almer" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f3ABfqK9013383 Sender: owner-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 Hemant Hi, If possible, I would like to be involved. Please keep me posted. David Almer Tadlys Ltd. Director Systems Engineering 7 Oppenheimer St. Rehovot 76705, Israel tel: 972-8-936 6641/225 fax: 972-8-936 6651 email: almer@tadlys.com -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Hemant Chaskar Sent: Thursday, April 05, 2001 9:47 PM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Requirements Draft for Mobile IP QoS - Invitation to Volunteer 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 From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 10 09:20: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 JAA14197 for ; Tue, 10 Apr 2001 09:20: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 GAA22092; Tue, 10 Apr 2001 06:19: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 GAA16892; Tue, 10 Apr 2001 06:19:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3ADHcK9013583 for ; Tue, 10 Apr 2001 06:17:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3ADHbFj013582 for mobile-ip-dist; Tue, 10 Apr 2001 06:17: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3ADHQK9013575 for ; Tue, 10 Apr 2001 06:17:26 -0700 (PDT) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA24024 for ; Tue, 10 Apr 2001 06:17:27 -0700 (PDT) Received: from nasnfs.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id GAA16077; Tue, 10 Apr 2001 06:17:05 -0700 (PDT) From: Patrice Calhoun Message-Id: <200104101317.GAA16077@nasnfs.Eng.Sun.COM> Date: Tue, 10 Apr 2001 07:12:55 -0700 To: , Subject: Re: FW: [mobile-ip] dynamic home addressing as a WG item?? 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 >Patrice Calhoun writes: > > Here is a question for you Sandy. > > > > Is it at all possible for Mobile IP to provide the mobile's home address, > > as it is done today, and have the mobile issue a DHCP message NOT to request > > an IP address, but only to retrieve configuration information. So it would > > provide its address, but it is only looking for provisioning >services. > > Yes. It's a DHCP INFORM. ok, so if the desired functionality is to retrieve DHCP configuration information from the home network, the allow Mobile IP to provide home address assignment via the current mechanisms, and once the mobile is registered, a DHCP INFORM could be sent to the home network. (btw, I suspect this will really only work with reverse tunnels if the packet is a broadcast). PatC From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 10 09:36: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 JAA14647 for ; Tue, 10 Apr 2001 09:36:31 -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 GAA02634; Tue, 10 Apr 2001 06:35: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 GAA26113; Tue, 10 Apr 2001 06:35:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3ADVTK9013631 for ; Tue, 10 Apr 2001 06:31:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3ADVPXI013630 for mobile-ip-dist; Tue, 10 Apr 2001 06:31: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3ADVEK9013623 for ; Tue, 10 Apr 2001 06:31:15 -0700 (PDT) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA25709 for ; Tue, 10 Apr 2001 06:31:15 -0700 (PDT) Received: from nasnfs.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id GAA16208; Tue, 10 Apr 2001 06:30:49 -0700 (PDT) From: Patrice Calhoun Message-Id: <200104101330.GAA16208@nasnfs.Eng.Sun.COM> Date: Tue, 10 Apr 2001 07:26:41 -0700 To: , Subject: RE: FW: [mobile-ip] dynamic home addressing as a WG item?? 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 =>> Is it at all possible for Mobile IP to provide the mobile's home address, >> as it is done today, > >To set the record straight: where does Mobile IP >get the home address in your model? From an >address pool in the HA (i.e., NOT through DHCP)? How the HA allocates the address really is outside the scope of the protocol, and is purely an implementation decision. If an HA wants to issue DHCP requests on behalf of the mobile, then so be it. If it wants to mantain an internal address pool, which btw is pretty simple since it ALWAYS knows when the mobile node is registered, then that's ok too. > >> and have the mobile issue a DHCP message NOT >> to request >> an IP address, but only to retrieve configuration information. So it would >> provide its address, but it is only looking for provisioning services. > >Although the DHCPINFORM message in the DHCP standard >was created to enable this very thing (i.e., a >node with an externally configured address to >query for some other local configuration >parameters), DHCP client/server implementations >didn't support it until very recently. ok, so that could be used. > >> >> That would make this whole thing so much simpler. >> > >I don't agree that a model where you get the >address from the HA and configuration options >from DHCP would make this much simpler for the >following reason. Once the HA starts allocating >addresses you have to now worry about: >* provisioning/sizing the HA address pool Sorry but this happens in one place or another (DHCP or HA). An HA has a limited subnet size, so this isn't rocket science. If people want to use DHCP on the backend, again the HA could issue the DHCP request on behalf of the mobile, and no Mobile IP changes are required in this WG. >* setting up some mechanism for reclaiming > HA-allocated addresses (the equivalent of > DHCP lease renewals) when the client no longer > needs the address or when the HA who conferred > an address has died. When the HA determines that the mobile is no longer registered (either via an explicit deregistration or soft-state), it would send the appropriate message to its DHCP server on behalf of the mobile. > >On the latter point, >do you assume the home address given by the >HA is leased? If so, do you suggest changing the >Mobile IP standard to require registration >renewals while the mobile node is at home (just >to renew the home address lease)? If the >address is not leased, how do you prevent rogue >address problems? I do not understand what a rogue address problem is, so perhaps you could clarify. PatC From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 10 09:45:05 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 JAA14940 for ; Tue, 10 Apr 2001 09:45:04 -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 GAA14774; Tue, 10 Apr 2001 06:44:00 -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 GAA19930; Tue, 10 Apr 2001 06:44:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3ADgbK9013688 for ; Tue, 10 Apr 2001 06:42:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3ADgbCn013687 for mobile-ip-dist; Tue, 10 Apr 2001 06:42: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3ADgSK9013680 for ; Tue, 10 Apr 2001 06:42:28 -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 GAA26894 for ; Tue, 10 Apr 2001 06:42:26 -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 GAA05946 for ; Tue, 10 Apr 2001 06:42:25 -0700 (PDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Tue, 10 Apr 2001 09:36:57 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] location privacy Date: Tue, 10 Apr 2001 09:36:52 -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, what do you mean by "this?" That mobile-ip has location privacy in its charter, that there is a working group forming to take up the overall issue of location privacy, or the concept of location privacy itself? Phil > -----Original Message----- > From: James Kempf [mailto:james.kempf@Sun.COM] > Sent: Friday, April 06, 2001 8:04 PM > To: mobile-ip@sunroof.eng.sun.com; 'mobile-ip@sunroof.eng.sun.com' > Subject: Re: [mobile-ip] location privacy > > > I'm having a difficult time understanding what this means. Is this a > euphonisum > for NATs? I have an even more difficult time seeing how to > implement it. > The routers need to see an address to route the packet. What are the > requirements driving this topic? > > jak > > At 08:34 AM 4/6/01 -0400, Phil Roberts wrote: > >This and the next post I sent the last couple of days and > never saw show up > >on the list. If you saw them, sorry for the duplicates. > > > > > >Hi, > > > > we have a charter item to "address location privacy." > We'd like to > >gather some information about what the working group thinks > the extent of > >the work on location privacy in this working group should > be. It MUST in > >some serious way be connected with the Mobile IP protocol. > There will be in > >the Apps area very soon a location privacy working group so > we have to > >realize that this working group will not be the place to > resolve all issues > >relating to location privacy. > > > >Phil > From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 10 10:22: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 KAA16178 for ; Tue, 10 Apr 2001 10:22:07 -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 HAA00749; Tue, 10 Apr 2001 07:20:48 -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 HAA05071; Tue, 10 Apr 2001 07:21:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3AEJpK9013796 for ; Tue, 10 Apr 2001 07:19:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3AEJpT7013795 for mobile-ip-dist; Tue, 10 Apr 2001 07:19: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3AEJfK9013788 for ; Tue, 10 Apr 2001 07:19:42 -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 HAA01274 for ; Tue, 10 Apr 2001 07:19:42 -0700 (PDT) Received: from zrtps06u.us.nortel.com (h52s48a140n47.user.nortelnetworks.com [47.140.48.52]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA28757 for ; Tue, 10 Apr 2001 07:19:00 -0700 (PDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with ESMTP id f3AEFcJ06402 for ; Tue, 10 Apr 2001 10:15:38 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 10 Apr 2001 10:16:34 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Apr 2001 10:16:35 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C12578A@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Shahrier, Sharif M.'" , "'fu@ee.tu-berlin.de'" Cc: "'seamoby-context@cdma-2000.org'" , "Kiernan, Brian G." , "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] RE: FW: [seamoby-context] QoS specification for context Date: Tue, 10 Apr 2001 10:16:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C1C8.D8A47390" 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_01C0C1C8.D8A47390 Content-Type: text/plain; charset="iso-8859-1" And, of course, the TCA/SLA model has little to do with the legal contracts that constitute a service agreement between operators. And, there is no standard for electronic representation of this agreement, nor is there a standard repository. Indeed, I do not actually believe that any operator has implemented an electronic form of their SLAs, yet - and maybe never. Again, the TCA/SLA, if present, are part of the content, not requirements for CT. The CT is an information conveying service, and we need to identify requirements that define that service, not the information to be carried. If a particular piece of information has need for special treatment, then we need to examine that need as a possible requirement for CT. Otherwise, the information is opaque bits as far as CT is concerned. Gary > -----Original Message----- > From: Shahrier, Sharif M. [mailto:Sharif.Shahrier@InterDigital.com] > Sent: Monday, April 09, 2001 9:13 AM > To: 'fu@ee.tu-berlin.de'; Shahrier, Sharif M. > Cc: 'seamoby-context@cdma-2000.org'; Kiernan, Brian G.; > 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: FW: [seamoby-context] QoS specification for context > > > Well actually, in a DiffServ environment the boundary nodes derive the > service level and policing parameters from TCA (traffic condition > agreement). The TCA in turn is obtained from the SLA ( Service Level > Agreement) between the customer and the service provider. > Thus, you are > largely correct in your observation. Thanks. > > > -----Original Message----- > From: Xiaoming Fu [mailto:fu@ee.tu-berlin.de] > Sent: Monday, April 09, 2001 5:25 AM > To: Shahrier, Sharif M. > Cc: 'seamoby-context@cdma-2000.org' > Subject: Re: FW: [seamoby-context] QoS specification for context > > > > -----Original Message----- > > From: Shahrier, Sharif M. > > Sent: Friday, April 06, 2001 3:25 PM > > To: Shahrier, Sharif M.; Kiernan, Brian G. > > Cc: seamoby-context@cdma-2000.org > > Subject: RE: [seamoby-context] QoS specification for context > > > > Pat & the group: > > > > Sec. 3.2.3 of the problem statement is about QoS, > thus we need to > > specify requirements. There is material in this section > that can be used > for > > requirements but it is insufficient as is. > > > > Traffic flow may cross different domains with different QoS > policies, > thus, > > context should store different parameters for each flow as > needed in each > > domain. > > > > Ex. Diffserv. > > > > - DSCP value for flow. > > - AF or EF PHB implemented. > > - Marker value: red, yellow or green. > > - PIR, PBS CIR, CBS parameters. > > - Token bucket: burst size B, rate r > > - Flow classification: classifier, marker. > > - Conditioning: meter, remarker, shaper, dropper. > > - SLA --> TCA profile parameters. > Is there some overlapping between the last item with other > items above? > I > suppose it can be rewritten as "other SLA-->TCA profile parameters". > > Xiaoming Fu > TKN, TU-Berlin > ------_=_NextPart_001_01C0C1C8.D8A47390 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: FW: [seamoby-context] QoS specification for context

And, of course, the TCA/SLA model has little to do = with the legal
contracts that constitute a service agreement = between operators.
And, there is no standard for electronic = representation of this
agreement, nor is there a standard repository. = Indeed, I do not actually
believe that any operator has implemented an = electronic form of their SLAs,
yet - and maybe never.

Again, the TCA/SLA, if present, are part of the = content, not requirements
for CT. The CT is an information conveying service, = and we need to identify
requirements that define that service, not the = information to be carried.
If a particular piece of information has need for = special treatment, then
we need to examine that need as a possible = requirement for CT. Otherwise,
the information is opaque bits as far as CT is = concerned.

Gary

> -----Original Message-----
> From: Shahrier, Sharif M. [mailto:Sharif.Shahrier@= InterDigital.com]
> Sent: Monday, April 09, 2001 9:13 AM
> To: 'fu@ee.tu-berlin.de'; Shahrier, Sharif = M.
> Cc: 'seamoby-context@cdma-2000.org'; Kiernan, = Brian G.;
> 'mobile-ip@sunroof.eng.sun.com'
> Subject: RE: FW: [seamoby-context] QoS = specification for context
>
>
> Well actually, in a DiffServ environment the = boundary nodes derive the
> service level and policing parameters from TCA = (traffic condition
> agreement). The TCA in turn is obtained from = the SLA ( Service Level
> Agreement) between the customer and the service = provider.
> Thus, you are
> largely correct in  your observation. = Thanks.
>
>
> -----Original Message-----
> From: Xiaoming Fu [mailto:fu@ee.tu-berlin.de]=
> Sent: Monday, April 09, 2001 5:25 AM
> To: Shahrier, Sharif M.
> Cc: 'seamoby-context@cdma-2000.org'
> Subject: Re: FW: [seamoby-context] QoS = specification for context
>
>
> > -----Original Message-----
> > From: Shahrier, Sharif M.
> > Sent: Friday, April 06, 2001 3:25 = PM
> > To: Shahrier, Sharif M.; Kiernan, Brian = G.
> > Cc: seamoby-context@cdma-2000.org
> > Subject: RE: [seamoby-context] QoS = specification for context
> >
> > Pat & the group:
> >
> = >         Sec. 3.2.3 of the = problem statement is about QoS,
> thus we need to
> > specify requirements. There is material in = this section
> that can be used
> for
> > requirements but it is insufficient as = is.
> >
> > Traffic flow may cross different domains = with different QoS
> policies,
> thus,
> > context should store different parameters = for each flow as
> needed in each
> > domain.
> >
> > Ex. Diffserv.
> >
> = >         - DSCP value for = flow.
> = >         - AF or EF PHB = implemented.
> = >         - Marker value: = red, yellow or green.
> = >         - PIR, PBS CIR, = CBS parameters.
> = >         - Token bucket: = burst size B, rate r
> = >         - Flow = classification: classifier, marker.
> = >         - Conditioning: = meter, remarker, shaper, dropper.
> = >         - SLA --> TCA = profile parameters.
> Is there some overlapping between the last item = with other
> items above?
> I
> suppose it can be rewritten as "other = SLA-->TCA profile parameters".
>
> Xiaoming Fu
> TKN, TU-Berlin
>

------_=_NextPart_001_01C0C1C8.D8A47390-- From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 10 10:24: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 KAA16305 for ; Tue, 10 Apr 2001 10:24:21 -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 HAA10368; Tue, 10 Apr 2001 07:23: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 HAA01774; Tue, 10 Apr 2001 07:23:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3AEM0K9013806 for ; Tue, 10 Apr 2001 07:22:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3AELsRf013805 for mobile-ip-dist; Tue, 10 Apr 2001 07:21: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3AELdK9013798 for ; Tue, 10 Apr 2001 07:21: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 HAA04612 for ; Tue, 10 Apr 2001 07:21:39 -0700 (PDT) Received: from zrtps06u.us.nortel.com (h52s48a140n47.user.nortelnetworks.com [47.140.48.52]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA16348 for ; Tue, 10 Apr 2001 08:23:53 -0600 (MDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with ESMTP id f3AEK9J09029 for ; Tue, 10 Apr 2001 10:20:09 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 10 Apr 2001 10:20:56 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Apr 2001 10:20:57 -0400 Message-ID: From: "Hongyi Li" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents Date: Tue, 10 Apr 2001 10:20:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C1C9.74898250" 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_01C0C1C9.74898250 Content-Type: text/plain; charset="iso-8859-1" Hi Phil, Here are few more requirements I think that are impportant for RR/LMM (I like the term localized mobility management too): 10) LMM SHALL provide optimized routing for mobile-to-mobile communication. 11) LMM SHOULD minimize the number of network nodes affected by handoff signals. 12) LMM SHOULD support auto-configuration capabilities for mobile agents/FAs, access routers. 13) LMM SHOULD simplify the network design and provisioning for enabling LMM capability in a network and allow progressive LMM deployment capabilities. Some more comments in lines: > 1) Regional registration shall be introduced to minimize the signaling > traffic to the home agent or correspondent nodes for > intra-domain mobility > 2) Regional registration shall not introduce new overhead on > links between > the mobile and the regional registration agents > 3) Connectivity to the mobiles shall not be interrupted in > the presence of > the failure of regional registration agents > 4) Regional registration shall scale to support millions of nodes in a > visited network LMM SHALL be scalable in terms of number of connected users (i.e., active + dormant = millions) and the number of users on the move. > 5) Regional registration shall be secure against malicious > behavior from > visiting mobiles > 6) Regional registration shall allow multiple levels of hierarchy > 7) Regional registration shall support fast handoffs > 8) Regional registration shall not require changes to the > mobile node, the > home agent, or correspondent nodes > 9) Regional registration shall not introduce host routes in > routing tables I agree with Theo comments about host route. The LMM SHOULD minimize the amount of host routes in the routers. - Hongyi ------_=_NextPart_001_01C0C1C9.74898250 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] IPv6 Regional Registration - identifying = requirements

Hi Phil,
  Here are few more requirements I think that = are impportant for RR/LMM (I like
the term localized mobility management too):

 10) LMM SHALL provide optimized routing for = mobile-to-mobile communication.
 11) LMM SHOULD minimize the number of network = nodes affected by handoff signals.
 12) LMM SHOULD support auto-configuration = capabilities for mobile agents/FAs, access routers.
 13) LMM SHOULD simplify the network design and = provisioning for enabling LMM
capability in a network and allow progressive LMM = deployment capabilities.

Some more comments in lines:
  
> 1) Regional registration shall be introduced to = minimize the signaling
> traffic to the home agent or correspondent = nodes for
> intra-domain mobility
> 2) Regional registration shall not introduce = new overhead on
> links between
> the mobile and the regional registration = agents
> 3) Connectivity to the mobiles shall not be = interrupted in
> the presence of
> the failure of regional registration = agents
> 4) Regional registration shall scale to support = millions of nodes in a
> visited network

LMM SHALL be scalable in terms of number of connected = users (i.e., active + dormant =3D  millions) and the number of = users on the move.

> 5) Regional registration shall be secure against = malicious
> behavior from
> visiting mobiles
> 6) Regional registration shall allow multiple = levels of hierarchy
> 7) Regional registration shall support fast = handoffs
> 8) Regional registration shall not require = changes to the
> mobile node, the
> home agent, or correspondent nodes
> 9) Regional registration shall not introduce = host routes in
> routing tables

I agree with Theo comments about host route. The LMM = SHOULD minimize the amount of host routes in the routers.

- Hongyi

------_=_NextPart_001_01C0C1C9.74898250-- From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 10 10:36: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 KAA16684 for ; Tue, 10 Apr 2001 10:36: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 HAA19510; Tue, 10 Apr 2001 07:34:49 -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 HAA08446; Tue, 10 Apr 2001 07:34:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3AEXTK9013877 for ; Tue, 10 Apr 2001 07:33:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3AEXSge013876 for mobile-ip-dist; Tue, 10 Apr 2001 07:33: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3AEXJK9013869 for ; Tue, 10 Apr 2001 07:33:19 -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 HAA08203 for ; Tue, 10 Apr 2001 07:33:19 -0700 (PDT) Received: from zrtps06u.us.nortel.com (h52s48a140n47.user.nortelnetworks.com [47.140.48.52]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA05855 for ; Tue, 10 Apr 2001 07:33:19 -0700 (PDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with ESMTP id f3AEVuJ13511 for ; Tue, 10 Apr 2001 10:31:56 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 10 Apr 2001 10:32:55 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Apr 2001 10:32:56 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C12578D@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Michael Thomas'" , "rajeev.koodli" Cc: khiem.le@nokia.com, tmima@cisco.com, mccap@research.bell-labs.com, kempf@heliopolis.Eng.Sun.COM, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Tue, 10 Apr 2001 10:32:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C1CB.1D54C330" 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_01C0C1CB.1D54C330 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Friday, April 06, 2001 1:46 PM > To: rajeev.koodli > Cc: mat@cisco.com; khiem.le@nokia.com; Kenward, Gary > [WDLN2:AN10:EXCH]; > tmima@cisco.com; mccap@research.bell-labs.com; > kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > rohc@cdt.luth.se; seamoby@diameter.org > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile > IPv6 Handover > > > rajeev.koodli@nokia.com writes: > > > From: ext Michael Thomas [mailto:mat@cisco.com] > > > > Can somebody explain to me how this has any > > > possible applicability if you are using FMIP > > > during the transition? FMIP requires a new tunnel > > > for which there will be no compression state in > > > the old access router. > > > > > > > If there is no compression state at the old router, why > would you try to > > relocate it ? > > There's compression state there, but not the > compression state that matters: when I'm > receiving packets from the old AR during the > FMIP transition time, there will be a *new* > IP header appended toward the MN. This is > because those packets will have to be tunneled to the > MN. This means that it is a *new* compression > context, not an old existing one. Sounds like a problem with FMIP to me. Gary > ------_=_NextPart_001_01C0C1CB.1D54C330 Content-Type: text/html; charset="iso-8859-1" RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Friday, April 06, 2001 1:46 PM
> To: rajeev.koodli
> Cc: mat@cisco.com; khiem.le@nokia.com; Kenward, Gary
> [WDLN2:AN10:EXCH];
> tmima@cisco.com; mccap@research.bell-labs.com;
> kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com;
> rohc@cdt.luth.se; seamoby@diameter.org
> Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile
> IPv6 Handover
>
>
> rajeev.koodli@nokia.com writes:
>  > > From: ext Michael Thomas [mailto:mat@cisco.com]
>
>  > > Can somebody explain to me how this has any
>  > > possible applicability if you are using FMIP
>  > > during the transition? FMIP requires a new tunnel
>  > > for which there will be no compression state in
>  > > the old access router.
>  > >
>  >
>  > If there is no compression state at the old router, why
> would you try to
>  > relocate it ?
>
>    There's compression state there, but not the
>    compression state that matters: when I'm
>    receiving packets from the old AR during the
>    FMIP transition time, there will be a *new*
>    IP header appended toward the MN. This is
>    because those packets will have to be tunneled to the
>    MN. This means that it is a *new* compression
>    context, not an old existing one.

Sounds like a problem with FMIP to me.

Gary

>

------_=_NextPart_001_01C0C1CB.1D54C330-- From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 10 10:53: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 KAA17224 for ; Tue, 10 Apr 2001 10:53: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 HAA11834; Tue, 10 Apr 2001 07:43: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 HAA07357; Tue, 10 Apr 2001 07:43:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3AEfjK9013922 for ; Tue, 10 Apr 2001 07:41:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3AEfjYV013921 for mobile-ip-dist; Tue, 10 Apr 2001 07:41: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3AEfTK9013914 for ; Tue, 10 Apr 2001 07:41:30 -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 HAA09339 for ; Tue, 10 Apr 2001 07:41:30 -0700 (PDT) Received: from zcars04e.nortelnetworks.com (zcars04e.nortelnetworks.com [47.129.242.56]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA13137 for ; Tue, 10 Apr 2001 07:41:26 -0700 (PDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Tue, 10 Apr 2001 10:41:00 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Apr 2001 10:41:01 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C12578F@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'seamoby'" Cc: "'mobile-ip@sunroof.eng.sun.com'" , mat@cisco.com, tmima@cisco.com, mccap@research.bell-labs.com, kempf@heliopolis.eng.sun.com, rohc@cdt.luth.se Subject: RE: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compresso r on Mobile IPv6 Handover Date: Tue, 10 Apr 2001 10:40:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C1CC.42343220" 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_01C0C1CC.42343220 Content-Type: text/plain; charset="iso-8859-1" Michael: It *may* be the case here that FMIP is deficient in supporting context transfer for header compression state. FMIP does not define the problem space. Kheim has done a fairly eloquent job of describing a real world issue with wireless handover. To say that FMIP won't support it is to say that FMIP is broken, not that the problem should not be solved. So let's get on with solving the problem. If there is a requirement to change FMIP, I'm sure the MIP group would be interested in our input. After all, that is one of the reasons Seamoby was chartered. Gary "When your only tool is a hammer, all your problems tend to look like nails" > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Friday, April 06, 2001 5:15 PM > To: khiem.le > Cc: rajeev.koodli@nokia.com; mat@cisco.com; Kenward, Gary > [WDLN2:AN10:EXCH]; tmima@cisco.com; mccap@research.bell-labs.com; > kempf@heliopolis.eng.sun.com; mobile-ip@sunroof.eng.sun.com; > rohc@cdt.luth.se; seamoby@diameter.org > Subject: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting > Compressor > on Mobile IPv6 Handover > > > Kheim, > > I sorry to be so argumentative here, but I'm sure I > could come up with a long laundry list of the benefits > of quantum teleportation too. What obviously must be > done beyond wanting such a thing is to see: > > o if it can be done at all > o whether it would still be a benefit once we > had done it. > > For example, if we could do quantum teleportation > but the only way we could figure out how to > teleport a person resulted in them dying, I'm sure > you'd agree that we ought to reevaluate the > benefits. > > All I'm asking here is how CT would interact with > FMIP. I believe that FMIP is very likely to be a > very important part of handoffs and as such, I > would like to know whether CT for header > compression state will help, hinder or be of no > benefit at all. From what I can tell, there is > indeed a problem and it is not clear whether there > is a solution, or whether the solution would be > worse than the original problem given the high > likelihood of race conditions, etc. > > Mike > > khiem.le@nokia.com writes: > > Hi, > > > > I have been too busy to comment on all these mails, but I > just want to say a > > couple of things. > > > > I'm afraid that it > > > is your place to prove that context transfer > > > of header compression state in the face of all > > > of these extenuating circumstances is still > > > worthwhile. > > > > There have been many mails pointing out the merit of doing header > > compression context transfer. To repeat them: > > continued, seamless compression/decompression, higher compression > > efficiency, and minimization of degradation on the user > media. This last > > point is the most important in my mind. At this stage, the > link technologies > > where header compression is going to be used are primarily > cellular links. > > In the cellular environment, handoffs (or handovers) are > events that happen > > in normal operation, and therefore a very significant > design effort is spent > > to minimize the impact of HO on performance. In > particular, one wants to > > minimize the duration of the break. If brute force header > compression > > reinitialization is done, one would have to send a certain > number of 40-60 > > byte or more IR headers, instead of the usual 1 byte > header. This big > > bandwidth demand surge will put a strain on the link. Some > links will cope > > with it by blanking out the user data to make room to > carry the IR headers. > > When such blanking takes place, the user media (voice, > etc.) will be > > unavoidably affected. The impairment caused by the handoff > is thus extended, > > compared to the case where header compression is not present. > > > > In the current and 3G cellular technologies, the break is > about 100-150 > > msec, without header compression. This already translates > into the loss of > > 5-6 20 msec packets. If some IR headers have to be sent by > blanking out the > > user data, the break will be significantly longer. For > example, if 3 (an > > optimistic value) IR headers are sent, the resulting break > is increased to > > 8-9 packets worth. > > > > I also want to point out that minimization of the break > will help in > > futureproofness. Applications that will be introduced in > the future may be > > even more sensitive to the break (or the threshold for > user perceived > > degradation may be lower) than the currently known ones. > For example, if a > > packet is generated every 10 msec, the number of packets > affected will be > > doubled. > > > > The only way to minimize the break is to do header > compression context > > transfer. > > > > > > Khiem > > > -----Original Message----- > > > From: Koodli Rajeev (NRC/MtView) > > > Sent: Friday, April 06, 2001 1:13 PM > > > To: 'ext Michael Thomas'; Koodli Rajeev (NRC/MtView) > > > Cc: Le Khiem (NRC/Dallas); gkenward@nortelnetworks.com; > > > tmima@cisco.com; > > > mccap@research.bell-labs.com; kempf@heliopolis.Eng.Sun.COM; > > > mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se; > seamoby@diameter.org > > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting > Compressor on Mobile > > > IPv6 Handover > > > > > > > > > > > > > > > > > > rajeev.koodli@nokia.com writes: > > > > > > From: ext Michael Thomas [mailto:mat@cisco.com] > > > > > > > > > > Can somebody explain to me how this has any > > > > > > possible applicability if you are using FMIP > > > > > > during the transition? FMIP requires a new tunnel > > > > > > for which there will be no compression state in > > > > > > the old access router. > > > > > > > > > > > > > > > > If there is no compression state at the old router, why > > > > would you try to > > > > > relocate it ? > > > > > > > > There's compression state there, but not the > > > > compression state that matters: when I'm > > > > receiving packets from the old AR during the > > > > FMIP transition time, there will be a *new* > > > > IP header appended toward the MN. This is > > > > because those packets will have to be tunneled to the > > > > MN. This means that it is a *new* compression > > > > context, not an old existing one. > > > > > > > I don't have sufficient details to comment.. > > > > > > > > > All of these interactions with MIP, FMIP, HMIP > > > > > > etc, etc make it look to me like this is a losing > > > > > > situation. It may be the better part of valor to > > > > > > say that fast/smooth handoffs are inherently more > > > > > > bandwidth consumptive and that one of the > > > > > > casualties is header compression state in the mean > > > > > > time. > > > > > > > > > > Can you justify your claim above ? > > > > > > > > I can't prove negatives. I'm afraid that it > > > > is your place to prove that context transfer > > > > of header compression state in the face of all > > > > of these extenuating circumstances is still > > > > worthwhile. > > > > > > > > > > You can't justify your claims. So, before you raise issues > > > (related/unrelated), try to make an effort to understand the > > > work done by others. > > > > > > As far as I am concerned, how about all the e-mail discussion > > > during the last two weeks ? Please take a look! > > > > > > > > >Trying to extend a point to point L2 > > > > > > compression mechanism across an arbitrary internet > > > > > > is just *bizzare*. L2TP is bad enough. > > > > > > > > > > > > > > > > You are compressing IP and transport headers! This should > > > > work on ANY link. > > > > > That's why you try to CT header compression state. Get it ? > > > > > > > > Oh sure, I get it... I "get" VoMPLS too, but > > > > that doesn't make it any less bizarre. > > > > > > > > > > If you got it, you would probably re-think! If you were to > > > re-think and understand the issues, you would probably > > > question yourself what's bizarre, and then write. > > > > > > -Rajeev > > > > > > > Mike > > > > > > > > ------_=_NextPart_001_01C0C1CC.42343220 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover

Michael:

   It *may* be the case here that FMIP is deficient in supporting context
transfer for header compression state. FMIP does not define the problem
space. Kheim has done a fairly eloquent job of describing a real world issue
with wireless handover. To say that FMIP won't support it is to say that FMIP
is broken, not that the problem should not be solved.

  So let's get on with solving the problem. If there is a requirement to change
FMIP, I'm sure the MIP group would be interested in our input. After all,
that is one of the reasons Seamoby was chartered.

Gary

"When your only tool is a hammer, all your problems tend to look like nails"

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Friday, April 06, 2001 5:15 PM
> To: khiem.le
> Cc: rajeev.koodli@nokia.com; mat@cisco.com; Kenward, Gary
> [WDLN2:AN10:EXCH]; tmima@cisco.com; mccap@research.bell-labs.com;
> kempf@heliopolis.eng.sun.com; mobile-ip@sunroof.eng.sun.com;
> rohc@cdt.luth.se; seamoby@diameter.org
> Subject: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting
> Compressor
> on Mobile IPv6 Handover
>
>
> Kheim,
>
> I sorry to be so argumentative here, but I'm sure I
> could come up with a long laundry list of the benefits
> of quantum teleportation too. What obviously must be
> done beyond wanting such a thing is to see:
>
> o if it can be done at all
> o whether it would still be a benefit once we
>   had done it.
>
> For example, if we could do quantum teleportation
> but the only way we could figure out how to
> teleport a person resulted in them dying, I'm sure
> you'd agree that we ought to reevaluate the
> benefits.
>
> All I'm asking here is how CT would interact with
> FMIP. I believe that FMIP is very likely to be a
> very important part of handoffs and as such, I
> would like to know whether CT for header
> compression state will help, hinder or be of no
> benefit at all. From what I can tell, there is
> indeed a problem and it is not clear whether there
> is a solution, or whether the solution would be
> worse than the original problem given the high
> likelihood of race conditions, etc.
>
>          Mike
>
> khiem.le@nokia.com writes:
>  > Hi,
>  >
>  > I have been too busy to comment on all these mails, but I
> just want to say a
>  > couple of things.
>  >
>  > I'm afraid that it
>  > >    is your place to prove that context transfer
>  > >    of header compression state in the face of all
>  > >    of these extenuating circumstances is still
>  > >    worthwhile.
>  >
>  > There have been many mails pointing out the merit of doing header
>  > compression context transfer. To repeat them:
>  > continued, seamless compression/decompression, higher compression
>  > efficiency, and minimization of degradation on the user
> media. This last
>  > point is the most important in my mind. At this stage, the
> link technologies
>  > where header compression is going to be used are primarily
> cellular links.
>  > In the cellular environment, handoffs (or handovers) are
> events that happen
>  > in normal operation, and therefore a very significant
> design effort is spent
>  > to minimize the impact of HO on performance. In
> particular, one wants to
>  > minimize the duration of the break. If brute force header
> compression
>  > reinitialization is done, one would have to send a certain
> number of 40-60
>  > byte or more IR headers, instead of the usual 1 byte
> header. This big
>  > bandwidth demand surge will put a strain on the link. Some
> links will cope
>  > with it by blanking out the user data to make room to
> carry the IR headers.
>  > When such blanking takes place, the user media (voice,
> etc.) will be
>  > unavoidably affected. The impairment caused by the handoff
> is thus extended,
>  > compared to the case where header compression is not present. 
>  >
>  > In the current and 3G cellular technologies, the break is
> about 100-150
>  > msec, without header compression. This already translates
> into the loss of
>  > 5-6 20 msec packets. If some IR headers have to be sent by
> blanking out the
>  > user data, the break will be significantly longer. For
> example, if 3 (an
>  > optimistic value) IR headers are sent, the resulting break
> is increased to
>  > 8-9 packets worth.
>  >
>  > I also want to point out that minimization of the break
> will help in
>  > futureproofness.  Applications that will be introduced in
> the future may be
>  > even more sensitive to the break (or the threshold for
> user perceived
>  > degradation may be lower) than the currently known ones.
> For example, if a
>  > packet is generated every 10 msec, the number of packets
> affected will be
>  > doubled.
>  >   
>  > The only way to minimize the break is to do header
> compression context
>  > transfer. 
>  >
>  >
>  > Khiem
>  > > -----Original Message-----
>  > > From: Koodli Rajeev (NRC/MtView)
>  > > Sent: Friday, April 06, 2001 1:13 PM
>  > > To: 'ext Michael Thomas'; Koodli Rajeev (NRC/MtView)
>  > > Cc: Le Khiem (NRC/Dallas); gkenward@nortelnetworks.com;
>  > > tmima@cisco.com;
>  > > mccap@research.bell-labs.com; kempf@heliopolis.Eng.Sun.COM;
>  > > mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se;
> seamoby@diameter.org
>  > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting
> Compressor on Mobile
>  > > IPv6 Handover
>  > >
>  > >
>  > > >
>  > > >
>  > > > rajeev.koodli@nokia.com writes:
>  > > >  > > From: ext Michael Thomas [mailto:mat@cisco.com]
>  > > >
>  > > >  > > Can somebody explain to me how this has any
>  > > >  > > possible applicability if you are using FMIP
>  > > >  > > during the transition? FMIP requires a new tunnel
>  > > >  > > for which there will be no compression state in
>  > > >  > > the old access router.
>  > > >  > >
>  > > >  >
>  > > >  > If there is no compression state at the old router, why
>  > > > would you try to
>  > > >  > relocate it ?
>  > > >
>  > > >    There's compression state there, but not the
>  > > >    compression state that matters: when I'm
>  > > >    receiving packets from the old AR during the
>  > > >    FMIP transition time, there will be a *new*
>  > > >    IP header appended toward the MN. This is
>  > > >    because those packets will have to be tunneled to the
>  > > >    MN. This means that it is a *new* compression
>  > > >    context, not an old existing one.
>  > > > 
>  > > I don't have sufficient details to comment..
>  > >
>  > > >  > > All of these interactions with MIP, FMIP, HMIP
>  > > >  > > etc, etc make it look to me like this is a losing
>  > > >  > > situation. It may be the better part of valor to
>  > > >  > > say that fast/smooth handoffs are inherently more
>  > > >  > > bandwidth consumptive and that one of the
>  > > >  > > casualties is header compression state in the mean
>  > > >  > > time.
>  > > >  >
>  > > >  > Can you justify your claim above ?
>  > > >
>  > > >    I can't prove negatives. I'm afraid that it
>  > > >    is your place to prove that context transfer
>  > > >    of header compression state in the face of all
>  > > >    of these extenuating circumstances is still
>  > > >    worthwhile.
>  > > >
>  > >
>  > > You can't justify your claims. So, before you raise issues
>  > > (related/unrelated), try to make an effort to understand the
>  > > work done by others.
>  > >
>  > > As far as I am concerned, how about all the e-mail discussion
>  > > during the last two weeks ? Please take a look!
>  > >
>  > > >  > >Trying to extend a point to point L2
>  > > >  > > compression mechanism across an arbitrary internet
>  > > >  > > is just *bizzare*. L2TP is bad enough.
>  > > >  > >
>  > > >  >
>  > > >  > You are compressing IP and transport headers! This should
>  > > > work on ANY link.
>  > > >  > That's why you try to CT header compression state. Get it ?
>  > > >
>  > > >    Oh sure, I get it... I "get" VoMPLS too, but
>  > > >    that doesn't make it any less bizarre.
>  > > >
>  > >
>  > > If you got it, you would probably re-think! If you were to
>  > > re-think and understand the issues, you would probably
>  > > question yourself what's bizarre, and then write.
>  > >
>  > > -Rajeev
>  > >
>  > > >            Mike
>  > > >
>  > >
>

------_=_NextPart_001_01C0C1CC.42343220-- From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 10 11:05: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 LAA17472 for ; Tue, 10 Apr 2001 11:05: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 HAA10796; Tue, 10 Apr 2001 07:41: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 HAA09519; Tue, 10 Apr 2001 07:42:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3AEfFK9013912 for ; Tue, 10 Apr 2001 07:41:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3AEfEKB013911 for mobile-ip-dist; Tue, 10 Apr 2001 07:41: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3AEf6K9013904 for ; Tue, 10 Apr 2001 07:41:06 -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 HAA09246 for ; Tue, 10 Apr 2001 07:41:06 -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 IAA26852 for ; Tue, 10 Apr 2001 08:43:25 -0600 (MDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Tue, 10 Apr 2001 10:35:37 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents Date: Tue, 10 Apr 2001 10:35:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C1CB.81B97BF4" Sender: owner-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_01C0C1CB.81B97BF4 Content-Type: text/plain; charset="iso-8859-1" Hi, I'm a little confused about your req 10. MIP v6 already has route optimization. Do you envision req 10 to provide an alternative to that or to interoperate with that or ... something else? Thanks, Phil -----Original Message----- From: Hongyi Li [mailto:hyli@nortelnetworks.com] Sent: Tuesday, April 10, 2001 10:21 AM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents Hi Phil, Here are few more requirements I think that are impportant for RR/LMM (I like the term localized mobility management too): 10) LMM SHALL provide optimized routing for mobile-to-mobile communication. 11) LMM SHOULD minimize the number of network nodes affected by handoff signals. 12) LMM SHOULD support auto-configuration capabilities for mobile agents/FAs, access routers. 13) LMM SHOULD simplify the network design and provisioning for enabling LMM capability in a network and allow progressive LMM deployment capabilities. Some more comments in lines: > 1) Regional registration shall be introduced to minimize the signaling > traffic to the home agent or correspondent nodes for > intra-domain mobility > 2) Regional registration shall not introduce new overhead on > links between > the mobile and the regional registration agents > 3) Connectivity to the mobiles shall not be interrupted in > the presence of > the failure of regional registration agents > 4) Regional registration shall scale to support millions of nodes in a > visited network LMM SHALL be scalable in terms of number of connected users (i.e., active + dormant = millions) and the number of users on the move. > 5) Regional registration shall be secure against malicious > behavior from > visiting mobiles > 6) Regional registration shall allow multiple levels of hierarchy > 7) Regional registration shall support fast handoffs > 8) Regional registration shall not require changes to the > mobile node, the > home agent, or correspondent nodes > 9) Regional registration shall not introduce host routes in > routing tables I agree with Theo comments about host route. The LMM SHOULD minimize the amount of host routes in the routers. - Hongyi ------_=_NextPart_001_01C0C1CB.81B97BF4 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] IPv6 Regional Registration - identifying requirements
Hi,
 
I'm a little confused about your req 10.  MIP v6 already has route optimization.  Do you envision req 10 to provide an alternative to that or to interoperate with that or ... something else?
 
Thanks,
Phil
 
-----Original Message-----
From: Hongyi Li [mailto:hyli@nortelnetworks.com]
Sent: Tuesday, April 10, 2001 10:21 AM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents

Hi Phil,
  Here are few more requirements I think that are impportant for RR/LMM (I like
the term localized mobility management too):

 10) LMM SHALL provide optimized routing for mobile-to-mobile communication.
 11) LMM SHOULD minimize the number of network nodes affected by handoff signals.
 12) LMM SHOULD support auto-configuration capabilities for mobile agents/FAs, access routers.
 13) LMM SHOULD simplify the network design and provisioning for enabling LMM
capability in a network and allow progressive LMM deployment capabilities.

Some more comments in lines:
  
> 1) Regional registration shall be introduced to minimize the signaling
> traffic to the home agent or correspondent nodes for
> intra-domain mobility
> 2) Regional registration shall not introduce new overhead on
> links between
> the mobile and the regional registration agents
> 3) Connectivity to the mobiles shall not be interrupted in
> the presence of
> the failure of regional registration agents
> 4) Regional registration shall scale to support millions of nodes in a
> visited network

LMM SHALL be scalable in terms of number of connected users (i.e., active + dormant =  millions) and the number of users on the move.

> 5) Regional registration shall be secure against malicious
> behavior from
> visiting mobiles
> 6) Regional registration shall allow multiple levels of hierarchy
> 7) Regional registration shall support fast handoffs
> 8) Regional registration shall not require changes to the
> mobile node, the
> home agent, or correspondent nodes
> 9) Regional registration shall not introduce host routes in
> routing tables

I agree with Theo comments about host route. The LMM SHOULD minimize the amount of host routes in the routers.

- Hongyi

------_=_NextPart_001_01C0C1CB.81B97BF4-- From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 10 11:36: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 LAA18506 for ; Tue, 10 Apr 2001 11:36:23 -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 IAA11302; Tue, 10 Apr 2001 08: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 IAA05493; Tue, 10 Apr 2001 08:35:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3AFXTK9014045 for ; Tue, 10 Apr 2001 08:33:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3AFXT6U014043 for mobile-ip-dist; Tue, 10 Apr 2001 08:33: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3AFXHK9014036 for ; Tue, 10 Apr 2001 08:33:17 -0700 (PDT) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA05111; Tue, 10 Apr 2001 08:33:16 -0700 (PDT) Received: from nasnfs.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id IAA17371; Tue, 10 Apr 2001 08:32:06 -0700 (PDT) From: Patrice Calhoun Message-Id: <200104101532.IAA17371@nasnfs.Eng.Sun.COM> Date: Tue, 10 Apr 2001 09:28:40 -0700 To: "Gary Kenward" , "'fu@ee.tu-berlin.de'" , "'Shahrier, Sharif M.'" Cc: "'mobile-ip@sunroof.eng.sun.com'" , "Kiernan, Brian G." , "'seamoby-context@cdma-2000.org'" Subject: [mobile-ip] RE: FW: [seamoby-context] QoS specification for context 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 >And, of course, the TCA/SLA model has little to do with the legal >contracts that constitute a service agreement between operators. >And, there is no standard for electronic representation of this >agreement, nor is there a standard repository. Indeed, I do not actually >believe that any operator has implemented an electronic form of their SLAs, >yet - and maybe never. If I understand this thread properly, this sounds like the work being done in the Policy WG. PatC From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 10 11:36: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 LAA18534 for ; Tue, 10 Apr 2001 11:36:27 -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 IAA11678; Tue, 10 Apr 2001 08:35: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 IAA05603; Tue, 10 Apr 2001 08:35:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3AFYFK9014056 for ; Tue, 10 Apr 2001 08:34:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3AFYF3h014055 for mobile-ip-dist; Tue, 10 Apr 2001 08:34: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3AFY1K9014048 for ; Tue, 10 Apr 2001 08:34:02 -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 IAA05248 for ; Tue, 10 Apr 2001 08:34:01 -0700 (PDT) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id IAA07905 for ; Tue, 10 Apr 2001 08:34:00 -0700 (PDT) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Tue Apr 10 11:33:04 EDT 2001 Received: from blhothuelpc (thuelpc [135.180.240.114]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id LAA04260 for ; Tue, 10 Apr 2001 11:33:14 -0400 (EDT) From: "Sandy Thuel" To: Subject: RE: [mobile-ip] dynamic home addressing as a WG item?? Date: Tue, 10 Apr 2001 11:30:33 -0400 Message-ID: <00ed01c0c1d3$2ef60830$72f0b487@dnrc.belllabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <5.0.0.25.1.20010406075853.00a134d0@localhost> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-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 James, > >No. I wasn't referring to service discovery but > >to parameters which are typically associated > >with DHCP options [RFC2132] such as subnet mask, > >domain name, gateway router(s), DNS server(s), > >NTP server(s), etc. Please correct me if I'm > > Well, of these NTP and DNS servers are service > discovery, I agree that the others are configuration. > Using service discovery to discover DNS might > be quite difficult (especially if DNS SRV RRs were > used), so I suppose that could be considered a > configuration parameter as well. Precisely. This is the reason why many networks today use DHCP to allocate these configuration parameters. > The options related to IP address configuration > and routing (gateway router, subnet mask, > and domain name) are not handled by > service discovery currently but they could > be handled by a mobile IP extension or > AAA extension that hides the back end > implementation so network operators > could use the backend technique of their > choosing. Sure. But this is precisely the question: who should allocate these configuration parameters? Some backend mechanism made transparent through Mobile IP extensions? AAA extensions? DHCP? I obviously believe that DHCP should do it, at least today and in the foreseeable future. > >I agree that AAA is, in principle, a promising > >candidate to be a repository for the configuration > >options I'm referring to and it could be a better > >alternative than DHCP. Do you know of any efforts > >to extend the AAA infrastructure to support this? > > No, but this is something that could easily become > a standardized Diameter extension. I wonder if anyone on this mailing list with AAA expertise can shed some more light onto this possibility. > > >In any case, if I want a solution for today, I > >still think DHCP is the only game in town... > > DHCP was developed for enterprise networks, it > has little or no deployment in wide area mobile > networks at this point, certainly not to the mobile node, > and its characteristics > are not particularly promising for wide area, IMHO. Sure, DHCP was developed for enterprise networks but why is this a problem? The point is that DHCP IS widely deployed in LANs today and with a relatively simple solution you can use it to configure remote mobile nodes *as if* they were connected to their home networks, WITHOUT the need to change DHCP in any way to make it fit the special needs of mobile nodes. > Since a mobile node must have mobile IP on it > anyway, there is little point in requiring it to have > DHCP as well. Fine. You could make a Mobile IP client take on the responsabilities a DHCP client is used to handling but be ready to *change* that Mobile IP client. At the very least, you'd have to change the Mobile IP standard to require mobile nodes to register even while they're at home so that they can maintain soft-state support on their assigned home address. Now, if you happen to also need configuration parameters, you not only have to change the client state machine but you also need to extend Mobile IP messages... Changing the Mobile IP standard to do this is the key problem you can avoid by letting DHCP handle the dynamic addressing and configuration needs of the mobile nodes. > > > > > > But I don't see any problem with having the > > > HA do DHCP out the back end, this is > > > an implementation choice. > > > >Agreed. Now, we have agreed that there are > >different ways to implement this. This settles > >affirmatively the question as to whether or not > >it is implementable. The more important question > >I'm trying to get at is whether or not it is > >feasible to require HA's to support this (picking > >a favorite implementation strategy of choice). > >Any thoughts? > > I don't think it should be required, a network > operator may choose to do address and > address parameter configuration out > the back end of the HA using Radius or > Diameter. But there are probably areas > that could be standardized. Point well taken. 'Requiring' this functionality is too harsh a statement. Let me try again. What I'm trying to understand is what is the dynamic addressing AND configuration model that is *likely* to be embraced by ISP's. The model you seem to like is one where, from the point of view of the mobile node, Mobile IP handles all of this (i.e., the mobile node gets any needed address and configuration parameters from Mobile IP). And you'd like to leave the door open for operators to choose any back-end mechanism to do the actual address and configuration parameter allocation they want (be it AAA, DHCP or whatever). Does this accurately capture the model you have in mind? Regards, Sandy From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 10 12:40: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 MAA20243 for ; Tue, 10 Apr 2001 12:40:20 -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 JAA13843; Tue, 10 Apr 2001 09:39:08 -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 JAA03514; Tue, 10 Apr 2001 09:39:40 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3AGcJK9014239 for ; Tue, 10 Apr 2001 09:38:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3AGcI40014238 for mobile-ip-dist; Tue, 10 Apr 2001 09:38:18 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3AGc9K9014231 for ; Tue, 10 Apr 2001 09:38:09 -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 JAA03154 for ; Tue, 10 Apr 2001 09:38:09 -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 JAA28726 for ; Tue, 10 Apr 2001 09:38:08 -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.9.3/8.9.1) with ESMTP id JAA28466 for ; Tue, 10 Apr 2001 09:38: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 ADV02708; Tue, 10 Apr 2001 09:38:06 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA07100; Tue, 10 Apr 2001 09:38:05 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15059.14061.682431.241858@thomasm-u1.cisco.com> Date: Tue, 10 Apr 2001 09:38:05 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] IPv6 Regional Registration - identifying requirements In-Reply-To: <200104091652.JAA06769@heliopolis.eng.sun.com> References: <200104091652.JAA06769@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: > >2) Regional registration shall not introduce new overhead on links between > >the mobile and the regional registration agents > > This is crucial. The ROHC group has yet to prove that even a change > of CoA with context transfer will work, not to mention additional > overhead. Crucial for whom? The alternative is to require FA functionality in the access routers which is not without its own set of issues. Just because 3G is bandwidth starved -- which in the long run will be a transient problem -- doesn't mean we should optimize for it at all costs. We already have an L2 shipping right now -- 802.11 -- for which this issue is a big ho-hum. It needs to be given equal standing when the requirements are evaluated. > >7) Regional registration shall support fast handoffs > > This is important, but it should not be part of the design. It should > be possible to keep the fast handoff design orthogonal from the RegReg > design, so that fast handoff can be used for straight MIPv6 as well. > Perhaps the requirement should be restated as: > > Regional registration shall not impose any additional requirements > on fast handoff beyond what is required by basic MIPv6. What about your ROHC constraint? It looks like it conflicts. Mike From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 10 14:16: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 OAA22697 for ; Tue, 10 Apr 2001 14:16:58 -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 LAA00769; Tue, 10 Apr 2001 11:04: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 LAA12546; Tue, 10 Apr 2001 11:04:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3AI2AK9014664 for ; Tue, 10 Apr 2001 11:02:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3AI2AmW014663 for mobile-ip-dist; Tue, 10 Apr 2001 11:02: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3AI21K9014656 for ; Tue, 10 Apr 2001 11:02:01 -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 LAA09281 for ; Tue, 10 Apr 2001 11:02:01 -0700 (PDT) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id LAA01458 for ; Tue, 10 Apr 2001 11:02:00 -0700 (PDT) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Tue Apr 10 14:00:06 EDT 2001 Received: from blhothuelpc (thuelpc [135.180.240.114]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id OAA15212 for ; Tue, 10 Apr 2001 14:00:15 -0400 (EDT) From: "Sandy Thuel" To: Subject: RE: FW: [mobile-ip] dynamic home addressing as a WG item?? Date: Tue, 10 Apr 2001 13:57:34 -0400 Message-ID: <00ef01c0c1e7$b8627400$72f0b487@dnrc.belllabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <200104101330.GAA16208@nasnfs.Eng.Sun.COM> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-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, Let me sum up and clarify some points. As you suggested, it is possible to have the following dynamic addressing and configuration model for MNs: 1- MN gets a home address from the HA in its registration reply. The HA can allocate this address however it wants (be it through DHCP, its own address pool, AAA as suggested by jak, etc.) 2- After the MN is registered with the home address it got in step #1, have a DHCP client on the MN send a DHCPINFORM to its home network (and yes, it would have to be reverse-tunneled) to get whatever other configuration options it needs. 3- The MN is happy: it got its home address and all its configuration options. 4- Now, say the MN returns to its home network. It sends a de-registration message to its HA, and continues to use the home address it got through some unknown means from Mobile IP when it powered up away from home. 5- Some time after the MN de-registers, the MN powers down. It no longer needs its home address but can't tell its HA because it's not supposed to be sending any registration messages to it since it's at home. 6- Repeat steps 1-6 for a large number of MN's and you can imagine what'll happen to the address pool of whoever served as the address-allocator. This is what is referred to as a rogue address problem (i.e., addresses an address-allocator can't re-use because it has no safe way of reclaiming them). [Note: you can construct similar scenarios where say an operator reconfigures the address pool of the address-allocator and needs to reclaim or change a previously assigned address to the MN but can't get to it because there's no mobile IP message for the HA to inform this to an un-registered MN] So the problem with the model you suggest is that it is incomplete. It assumes the MN doesn't ever have to know who really allocated its home address. But this *isn't* true. It DOES matter to the MN who allocated its home address because there needs to be some means for the MN to communicate with its address-allocator so that it can defend its address or release it when it no longer needs it. Likewise, the address-allocator has to be able to maintain its right to reclaim any previously allocated address by telling the MN to give it up. So what are solutions to this problem? Solution 1: Change the Mobile IP standard to make sure there is always a communication path between the MN and its HA regardless of its location. In other words, *require* the MN to send registrations even while it's at home so that it can periodically tickle the HA to defend the home address that it (i.e., the HA) or some other address-allocator (eg., DHCP) gave to the MN. In this solution, Mobile IP registration messages double-duty as registration and address renewals while the MN is away from home while they only serve the purpose of address renewals while the MN is at home. Solution 2: Use Mobile IP to defend the home address while the MN is away from home (through registration messages that trigger the back-end renewals) BUT make the MN assume responsability for defending its home address when it returns home, taking Mobile IP completely out of the loop. This is what DHCP proxy does: a DHCP client on the MN assumes control of defending the home address when the MN returns home. This way, it avoids having to change the Mobile IP standard. Solution 3: Decouple addressing and configuration as much as possible from Mobile IP and let the MN handle it at all times. In other words, have a client that is specific to the address allocator (such as a DHCP client) directly handle transactions with the address allocator, regardless of whether the MN is at home or in a foreign network. This is what Transient Tunneling does. Sorry for the long message but I really hope this gives a clear picture of why this problem isn't as straightforward as it looks at first glance. Does this answer all your questions, Pat? Regards, Sandy > =>> Is it at all possible for Mobile IP to provide the mobile's > home address, > >> as it is done today, > > > >To set the record straight: where does Mobile IP > >get the home address in your model? From an > >address pool in the HA (i.e., NOT through DHCP)? > > How the HA allocates the address really is outside the scope of > the protocol, > and is purely an implementation decision. If an HA wants to issue > DHCP requests > on behalf of the mobile, then so be it. If it wants to mantain an internal > address pool, which btw is pretty simple since it ALWAYS knows > when the mobile > node is registered, then that's ok too. > > > > >> and have the mobile issue a DHCP message NOT > >> to request > >> an IP address, but only to retrieve configuration information. > So it would > >> provide its address, but it is only looking for provisioning services. > > > >Although the DHCPINFORM message in the DHCP standard > >was created to enable this very thing (i.e., a > >node with an externally configured address to > >query for some other local configuration > >parameters), DHCP client/server implementations > >didn't support it until very recently. > > ok, so that could be used. > > > > >> > >> That would make this whole thing so much simpler. > >> > > > >I don't agree that a model where you get the > >address from the HA and configuration options > >from DHCP would make this much simpler for the > >following reason. Once the HA starts allocating > >addresses you have to now worry about: > > >* provisioning/sizing the HA address pool > > Sorry but this happens in one place or another (DHCP or HA). An > HA has a limited > subnet size, so this isn't rocket science. If people want to use > DHCP on the > backend, again the HA could issue the DHCP request on behalf of > the mobile, and > no Mobile IP changes are required in this WG. > > >* setting up some mechanism for reclaiming > > HA-allocated addresses (the equivalent of > > DHCP lease renewals) when the client no longer > > needs the address or when the HA who conferred > > an address has died. > > When the HA determines that the mobile is no longer registered > (either via an > explicit deregistration or soft-state), it would send the > appropriate message to > its DHCP server on behalf of the mobile. > > > > >On the latter point, > >do you assume the home address given by the > >HA is leased? If so, do you suggest changing the > >Mobile IP standard to require registration > >renewals while the mobile node is at home (just > >to renew the home address lease)? If the > >address is not leased, how do you prevent rogue > >address problems? > > I do not understand what a rogue address problem is, so perhaps you could > clarify. > > PatC > From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 10 14:18:39 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 OAA22724 for ; Tue, 10 Apr 2001 14:18: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 LAA07970; Tue, 10 Apr 2001 11:17: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 LAA01023; Tue, 10 Apr 2001 11:17:41 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3AIFvK9014938 for ; Tue, 10 Apr 2001 11:15:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3AIFvNc014937 for mobile-ip-dist; Tue, 10 Apr 2001 11:15: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 eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3AIFfK9014930 for ; Tue, 10 Apr 2001 11:15:46 -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 OAA18741 for ; Tue, 10 Apr 2001 14:15:36 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id OAA01065 for mobile-ip@sunroof.eng.sun.com; Tue, 10 Apr 2001 14:15:46 -0400 (EDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36LmVK9001648 for ; Fri, 6 Apr 2001 14:48: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 OAA12078 for ; Fri, 6 Apr 2001 14:48:32 -0700 (PDT) From: khiem.le@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 OAA26320 for ; Fri, 6 Apr 2001 14:48:32 -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 f36Lofw04799 for ; Fri, 6 Apr 2001 16:50:41 -0500 (CDT) Received: from daebh02nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 6 Apr 2001 16:48:15 -0500 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Fri, 6 Apr 2001 16:48:15 -0500 Message-ID: <8572CF1E2A95D211A1190008C7EAA24602720928@daeis05nok> To: mat@cisco.com, khiem.le@nokia.com Cc: rajeev.koodli@nokia.com, gkenward@nortelnetworks.com, tmima@cisco.com, mccap@research.bell-labs.com, kempf@heliopolis.Eng.Sun.COM, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Fri, 6 Apr 2001 16:48:14 -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: Note from owner-mobile-ip: My bad - this post from khiem.le at Nokia came through my desktop, which was low on disk space. I'm reposting for the list... - Steve Hi Mike, > -----Original Message----- > From: ext Michael Thomas [mailto:mat@cisco.com] > Sent: Friday, April 06, 2001 4:15 PM > To: khiem.le@nokia.com > Cc: rajeev.koodli@nokia.com; mat@cisco.com; > gkenward@nortelnetworks.com; > tmima@cisco.com; mccap@research.bell-labs.com; > kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > rohc@cdt.luth.se; seamoby@diameter.org > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile > IPv6 Handover > > > > Kheim, > > I sorry to be so argumentative here, but I'm sure I > could come up with a long laundry list of the benefits > of quantum teleportation too. What obviously must be > done beyond wanting such a thing is to see: > > o if it can be done at all > o whether it would still be a benefit once we > had done it. > > For example, if we could do quantum teleportation > but the only way we could figure out how to > teleport a person resulted in them dying, I'm sure > you'd agree that we ought to reevaluate the > benefits. > > All I'm asking here is how CT would interact with > FMIP. I believe that FMIP is very likely to be a > very important part of handoffs and as such, I > would like to know whether CT for header > compression state will help, hinder or be of no > benefit at all. From what I can tell, there is > indeed a problem and it is not clear whether there > is a solution, or whether the solution would be > worse than the original problem given the high > likelihood of race conditions, etc. KL: At the least, and correct me if I am wrong, what you are saying is, at this stage, we should at least consider and investigate context transfer, before jumping to any conclusions that it should not be done. I agree. > > Mike > > khiem.le@nokia.com writes: > > Hi, > > > > I have been too busy to comment on all these mails, but I > just want to say a > > couple of things. > > > > I'm afraid that it > > > is your place to prove that context transfer > > > of header compression state in the face of all > > > of these extenuating circumstances is still > > > worthwhile. > > > > There have been many mails pointing out the merit of doing header > > compression context transfer. To repeat them: > > continued, seamless compression/decompression, higher compression > > efficiency, and minimization of degradation on the user > media. This last > > point is the most important in my mind. At this stage, the > link technologies > > where header compression is going to be used are primarily > cellular links. > > In the cellular environment, handoffs (or handovers) are > events that happen > > in normal operation, and therefore a very significant > design effort is spent > > to minimize the impact of HO on performance. In > particular, one wants to > > minimize the duration of the break. If brute force header > compression > > reinitialization is done, one would have to send a certain > number of 40-60 > > byte or more IR headers, instead of the usual 1 byte > header. This big > > bandwidth demand surge will put a strain on the link. Some > links will cope > > with it by blanking out the user data to make room to > carry the IR headers. > > When such blanking takes place, the user media (voice, > etc.) will be > > unavoidably affected. The impairment caused by the handoff > is thus extended, > > compared to the case where header compression is not present. > > > > In the current and 3G cellular technologies, the break is > about 100-150 > > msec, without header compression. This already translates > into the loss of > > 5-6 20 msec packets. If some IR headers have to be sent by > blanking out the > > user data, the break will be significantly longer. For > example, if 3 (an > > optimistic value) IR headers are sent, the resulting break > is increased to > > 8-9 packets worth. > > > > I also want to point out that minimization of the break > will help in > > futureproofness. Applications that will be introduced in > the future may be > > even more sensitive to the break (or the threshold for > user perceived > > degradation may be lower) than the currently known ones. > For example, if a > > packet is generated every 10 msec, the number of packets > affected will be > > doubled. > > > > The only way to minimize the break is to do header > compression context > > transfer. > > > > > > Khiem > > > -----Original Message----- > > > From: Koodli Rajeev (NRC/MtView) > > > Sent: Friday, April 06, 2001 1:13 PM > > > To: 'ext Michael Thomas'; Koodli Rajeev (NRC/MtView) > > > Cc: Le Khiem (NRC/Dallas); gkenward@nortelnetworks.com; > > > tmima@cisco.com; > > > mccap@research.bell-labs.com; kempf@heliopolis.Eng.Sun.COM; > > > mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se; > seamoby@diameter.org > > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting > Compressor on Mobile > > > IPv6 Handover > > > > > > > > > > > > > > > > > > rajeev.koodli@nokia.com writes: > > > > > > From: ext Michael Thomas [mailto:mat@cisco.com] > > > > > > > > > > Can somebody explain to me how this has any > > > > > > possible applicability if you are using FMIP > > > > > > during the transition? FMIP requires a new tunnel > > > > > > for which there will be no compression state in > > > > > > the old access router. > > > > > > > > > > > > > > > > If there is no compression state at the old router, why > > > > would you try to > > > > > relocate it ? > > > > > > > > There's compression state there, but not the > > > > compression state that matters: when I'm > > > > receiving packets from the old AR during the > > > > FMIP transition time, there will be a *new* > > > > IP header appended toward the MN. This is > > > > because those packets will have to be tunneled to the > > > > MN. This means that it is a *new* compression > > > > context, not an old existing one. > > > > > > > I don't have sufficient details to comment.. > > > > > > > > > All of these interactions with MIP, FMIP, HMIP > > > > > > etc, etc make it look to me like this is a losing > > > > > > situation. It may be the better part of valor to > > > > > > say that fast/smooth handoffs are inherently more > > > > > > bandwidth consumptive and that one of the > > > > > > casualties is header compression state in the mean > > > > > > time. > > > > > > > > > > Can you justify your claim above ? > > > > > > > > I can't prove negatives. I'm afraid that it > > > > is your place to prove that context transfer > > > > of header compression state in the face of all > > > > of these extenuating circumstances is still > > > > worthwhile. > > > > > > > > > > You can't justify your claims. So, before you raise issues > > > (related/unrelated), try to make an effort to understand the > > > work done by others. > > > > > > As far as I am concerned, how about all the e-mail discussion > > > during the last two weeks ? Please take a look! > > > > > > > > >Trying to extend a point to point L2 > > > > > > compression mechanism across an arbitrary internet > > > > > > is just *bizzare*. L2TP is bad enough. > > > > > > > > > > > > > > > > You are compressing IP and transport headers! This should > > > > work on ANY link. > > > > > That's why you try to CT header compression state. Get it ? > > > > > > > > Oh sure, I get it... I "get" VoMPLS too, but > > > > that doesn't make it any less bizarre. > > > > > > > > > > If you got it, you would probably re-think! If you were to > > > re-think and understand the issues, you would probably > > > question yourself what's bizarre, and then write. > > > > > > -Rajeev > > > > > > > Mike > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 10 14:21: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 OAA22860 for ; Tue, 10 Apr 2001 14:21:23 -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 LAA13426; Tue, 10 Apr 2001 11:21: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 LAA17145; Tue, 10 Apr 2001 11:20:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3AIIGK9014951 for ; Tue, 10 Apr 2001 11:18:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3AIIGAh014950 for mobile-ip-dist; Tue, 10 Apr 2001 11:18: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3AII6K9014943 for ; Tue, 10 Apr 2001 11:18:06 -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 LAA29553 for ; Tue, 10 Apr 2001 11:18:01 -0700 (PDT) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id LAA09602 for ; Tue, 10 Apr 2001 11:18:00 -0700 (PDT) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Tue Apr 10 14:16:06 EDT 2001 Received: from blhothuelpc (thuelpc [135.180.240.114]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id OAA16393 for ; Tue, 10 Apr 2001 14:16:16 -0400 (EDT) From: "Sandy Thuel" To: Subject: RE: [mobile-ip] Re: dynamic home addressing as a WG item?? Date: Tue, 10 Apr 2001 14:13:35 -0400 Message-ID: <00f001c0c1e9$f5730330$72f0b487@dnrc.belllabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-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 Alex, > > [sorry, late, hesitations about relevance to mip] > I hope your hesitations have been dispelled by now :-) > > > > 1) What is the real value of DHCP options to > > > > mobile nodes? > > I guess stateful mechanisms (being already > available and centralizing control) are definitely > an option to be exploited by MNs during > configuration of their CoA. > I think you misunderstood the question. I was referring to the so-called 'DHCP options' = configuration state DHCP allocates other than addresses. In addition, the questions in my message where specifically targeted at using DHCPv4 for configuring a home address, not a CoA. Sorry for the confusion. > > > > 2) How important is it to minimize the > > > > power-up configuration latency of a mobile > > > > node? > > I don't know. But in this context I know that > DHCPv6 mesages originally designed for power-up > could also be used for lower latency handoffs. Again, I think you're touching on the issue of dynamically configuring a CoA (not a home address, although it is certainly the case that any DHCP performance improvements helps reduce any configuration latency (whether it is the configuration of a CoA during handoffs or a home address during power-up). > > > > 1). We must figure out who wins the "I assign > > > the address to the MN battle" in all possible > > > scenarios including handoffs from MANETS > > > (infrastructure-less) to MIP supported > > > networks and handins and outs of > > > zeroconf/DHCP/slp/UPnP/(MIP ^ MANET) supported > > > subnets [do all the logical permutations]. > > I'm interested in "optimal autoconfiguration" with > a competition between stateless and stateful. The > rfc's specify a certain order (first do stateless > then, depending on it, do stateful) but I think > there's room for improvement. For example, I > could imagine the MN could use quick stateless to > obtain a temporary site-local address to query the > DNS, all at the same time doing a heavier DHCPv6 > exchange to obtain the CoA to register with HA. > Although this is an interesting issue, I'd rather not open the IPv6/DHCPv6 configuration can of worms at this moment. Let's try to reach consensus on how to handle the DHCPv4 case first. Thanks! Sandy From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 10 15:08: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 PAA24079 for ; Tue, 10 Apr 2001 15:08: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 LAA00089; Tue, 10 Apr 2001 11:58: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 LAA10378; Tue, 10 Apr 2001 11:58:57 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3AIvUK9015052 for ; Tue, 10 Apr 2001 11:57:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3AIvUET015051 for mobile-ip-dist; Tue, 10 Apr 2001 11:57: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3AIvKK9015042 for ; Tue, 10 Apr 2001 11:57:21 -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 LAA26858 for ; Tue, 10 Apr 2001 11:57:19 -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 LAA25491 for ; Tue, 10 Apr 2001 11:57:19 -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.9.3/8.9.1) with ESMTP id LAA20333 for ; Tue, 10 Apr 2001 11:57: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 ADV06957; Tue, 10 Apr 2001 11:57:15 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA07118; Tue, 10 Apr 2001 11:57:15 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15059.22411.688976.705878@thomasm-u1.cisco.com> Date: Tue, 10 Apr 2001 11:57:15 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents 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 Hongyi Li writes: > > 9) Regional registration shall not introduce host routes in > > routing tables > > I agree with Theo comments about host route. The LMM SHOULD minimize the > amount of host routes in the routers. I'm sorry but somebody's going to have to explain why this is a requirement. The number of routes in the MAP are the same. The only difference is the routes in the access and/or aggregation routers between the MAP and the MN, but that scales to the order of the subtended hosts at each point in the tree which doesn't seem especially onerous. Mike From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 10 15:34: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 PAA24690 for ; Tue, 10 Apr 2001 15:34:23 -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 MAA12620; Tue, 10 Apr 2001 12: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 MAA29961; Tue, 10 Apr 2001 12:33:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3AJTkK9015148 for ; Tue, 10 Apr 2001 12:29:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3AJTjU1015147 for mobile-ip-dist; Tue, 10 Apr 2001 12:29: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3AJTaK9015140 for ; Tue, 10 Apr 2001 12:29: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 MAA29077 for ; Tue, 10 Apr 2001 12:29:36 -0700 (PDT) Received: from zrtps06u.us.nortel.com (h52s48a140n47.user.nortelnetworks.com [47.140.48.52]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14571 for ; Tue, 10 Apr 2001 12:29:35 -0700 (PDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with ESMTP id f3AJSBJ29694 for ; Tue, 10 Apr 2001 15:28:11 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 10 Apr 2001 15:29:21 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Apr 2001 15:29:23 -0400 Message-ID: From: "Hongyi Li" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents Date: Tue, 10 Apr 2001 15:29:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C1F4.8B93E3C0" 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_01C0C1F4.8B93E3C0 Content-Type: text/plain; charset="iso-8859-1" Michael, To reduce the number of host routes is a desirable goal for the routers that have limited number of routing table entries. If a LMM protocol can aggregate / de-aggregate the host routes in the mobile agents (e.g. MAP), the protocol would be more scalable in term of routing table size. This is only a desirable requirement not a MUST. -Hongyi > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Tuesday, April 10, 2001 2:57 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying > requirem ents > > > Hongyi Li writes: > > > 9) Regional registration shall not introduce host routes in > > > routing tables > > > > I agree with Theo comments about host route. The LMM > SHOULD minimize the > > amount of host routes in the routers. > > I'm sorry but somebody's going to have to explain > why this is a requirement. The number of routes > in the MAP are the same. The only difference is > the routes in the access and/or aggregation > routers between the MAP and the MN, but that > scales to the order of the subtended hosts at > each point in the tree which doesn't seem > especially onerous. > > Mike > ------_=_NextPart_001_01C0C1F4.8B93E3C0 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents

Michael,
  To reduce the number of host routes is a desirable goal
for the routers that have limited number of routing table entries.
If a LMM protocol can aggregate / de-aggregate the host routes in
the mobile agents (e.g. MAP), the protocol would be more scalable
in term of routing table size. This is only a desirable requirement
not a MUST.

-Hongyi

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Tuesday, April 10, 2001 2:57 PM
> To: mobile-ip@sunroof.eng.sun.com
> Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying
> requirem ents
>
>
> Hongyi Li writes:
>  > > 9) Regional registration shall not introduce host routes in
>  > > routing tables
>  >
>  > I agree with Theo comments about host route. The LMM
> SHOULD minimize the
>  > amount of host routes in the routers.
>
>    I'm sorry but somebody's going to have to explain
>    why this is a requirement. The number of routes
>    in the MAP are the same. The only difference is
>    the routes in the access and/or aggregation
>    routers between the MAP and the MN, but that
>    scales to the order of the subtended hosts at
>    each point in the tree which doesn't seem
>    especially onerous.
>
>               Mike
>

------_=_NextPart_001_01C0C1F4.8B93E3C0-- From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 10 17:57: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 RAA26941 for ; Tue, 10 Apr 2001 17:57: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 OAA20760; Tue, 10 Apr 2001 14:54: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 OAA04099; Tue, 10 Apr 2001 14:54:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3ALrfK9015270 for ; Tue, 10 Apr 2001 14:53:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3ALreC8015269 for mobile-ip-dist; Tue, 10 Apr 2001 14:53: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3ALrVK9015262 for ; Tue, 10 Apr 2001 14:53:31 -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 OAA22294 for ; Tue, 10 Apr 2001 14:53:32 -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 OAA01991 for ; Tue, 10 Apr 2001 14:53:31 -0700 (PDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Apr 2001 17:52:36 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'Mohan Parthasarathy'" , mobile-ip@sunroof.eng.sun.com Cc: "Kiernan, Brian G." , charliep@iprg.nokia.com, "Shahrier, Sharif M." Subject: RE: [mobile-ip] some issues with IPv6 mobility draft (sharif) Date: Tue, 10 Apr 2001 17:52:30 -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: > > I have some issues to discuss with the document: > > "Mobility Support in IPv6" > > > I would be grateful if people can take a look and make any contructive > comments. Thanks. > > > 1. Consider A, B where A is the mobile and B is the correpondent node. > A is currently > away from its home agent. B is also a mobile node. Suppose A send a > BU(A) and moves > to its new location. The network is heavily loaded, and B has not > yet received the > binding update. B also was to move. Thus, similarly, it sends a > BU(B) to A, and moves > to its new location. The binding updates BU(A) and BU(B) eventually > arrives at A's > and B's previous locations, respectively. But A and B have already > moved. This means > that nodes neither A or B will are aware of each other new > respective locations. > > Thus, I believe this is be an erronous condition wrt A and B not > knowing each others > final destination addresses. > If the binding is wrong, you will get ICMP errors and if this persists you should delete your binding cache entry if you are a correspondent node. Now the packets go through the home agent which has the right binding. -mohan Yes, it may seem that ICMP(host unreachable) message may solve the problem. However, there are additional issues: * Suppose that node A is moving "rapidly". Node B is also moving. B sends a datagram to A; A is not there; ICMP host unreachable --> B. B deletes entry from its binding cache; sends Binding Request to A's HA;HA sends A's COA to B. Supposes this last step is long because of congestion. During the step above, A sends a Binding Update to its home agent, receives Acknowledgement, A moves to its new COA. B sends datagram to A's previous COA; A is not there; B is sent ICMP; Process continues forever..... A possible solution to prevent this "looping" effect is to keep caching A's new binding at its previous COA. The previous COA can use the binding to forward packets to A. But this method will also fail if one of the "previous" agents caching the COA's fails or is reconfigured ........ Thus, I prefer my previously posted "solution", in just using the HA approach because: o It eliminates extra level of signaling between mobile-to-mobile. Signaling is only between mobile and HA. o It simplifies the binding caches at each MN and CN, reduces overhead of protocol operation. * Secondly, how does the ICMP solve the problem with multicast groups? A multicast group is assigned a particular multicast address for communication. Thus, if one member of the group is unreachable, it doesn't seem that the ICMP solution will solve the problem here. Comments please ....... Sharif. From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 10 18:32: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 SAA27386 for ; Tue, 10 Apr 2001 18:32: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 PAA28240; Tue, 10 Apr 2001 15:32: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 PAA29978; Tue, 10 Apr 2001 15:31:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3AMUHK9015330 for ; Tue, 10 Apr 2001 15:30:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3AMUHdp015329 for mobile-ip-dist; Tue, 10 Apr 2001 15:30: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3AMU8K9015322 for ; Tue, 10 Apr 2001 15:30: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 PAA29744; Tue, 10 Apr 2001 15:30:06 -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 QAA12647; Tue, 10 Apr 2001 16:30: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 PAA18029; Tue, 10 Apr 2001 15:29:33 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3AMTU015862; Tue, 10 Apr 2001 15:29:30 -0700 X-mProtect: Tue, 10 Apr 2001 15:29:30 -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(WTS.12.69) smtpdpP5y2J; Tue, 10 Apr 2001 15:29:25 PDT Message-ID: <3AD38948.8DA1437A@iprg.nokia.com> Date: Tue, 10 Apr 2001 15:29:28 -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 CC: "'Mohan Parthasarathy'" , "Kiernan, Brian G." , charliep@iprg.nokia.com, "Shahrier, Sharif M." Subject: Re: [mobile-ip] some issues with IPv6 mobility draft (sharif) 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 "Shahrier, Sharif M." wrote: > * Suppose that node A is moving "rapidly". Node B is also moving. > B sends a datagram to A; A is not there; ICMP host unreachable --> B. B > deletes entry from its binding cache; sends Binding Request to A's HA;HA > sends A's COA to B. Supposes this last step is long because of congestion. Wrong again!! the A's Home agent does not respond to the binding request. the binding request is tunneled to A and A responds with a BU. > > During the step above, A sends a Binding Update to its home agent, receives > Acknowledgement, A moves to its new COA. B sends datagram to A's previous > COA; A is not there; B is sent ICMP; Process continues forever..... > > A possible solution to prevent this "looping" effect is to keep caching A's > new binding at its previous COA. The previous COA can use the binding to > forward packets to A. > This is already there in the base mobile ipv6. the previous access router to which the A was connected to forwards packets to A's new location. this is set up by A sending a BU to its previous access router binding its new CoA and old CoA. > But this method will also fail if one of the "previous" agents caching the > COA's fails or is reconfigured ........ > > Thus, I prefer my previously posted "solution", in just using the HA > approach because: > whatever you have described till now is based on lot of things failing. you also assume that the MN is handing off faster than the round trip time to the CN. and your solution of the home agent maintaining the binding update list is not worthy of any consideration. stop this thread on the mailing list. lets go offline. i can explain things in more detail there... vijay > o It eliminates extra level of signaling between mobile-to-mobile. Signaling > is only between mobile and HA. > o It simplifies the binding caches at each MN and CN, reduces overhead of > protocol operation. > > * Secondly, how does the ICMP solve the problem with > multicast groups? A multicast group is assigned a particular multicast > address for communication. Thus, if one member of the group is unreachable, > it doesn't seem that the ICMP solution will solve the problem here. > > Comments please ....... > > Sharif. From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 10 19:00:16 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27653 for ; Tue, 10 Apr 2001 19:00:16 -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 PAA21301; Tue, 10 Apr 2001 15:59: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 PAA09842; Tue, 10 Apr 2001 15:59:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3AMw9K9015387 for ; Tue, 10 Apr 2001 15:58:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3AMw9kd015386 for mobile-ip-dist; Tue, 10 Apr 2001 15:58: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3AMw0K9015379 for ; Tue, 10 Apr 2001 15:58:00 -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 PAA09259 for ; Tue, 10 Apr 2001 15:58:00 -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 PAA15395 for ; Tue, 10 Apr 2001 15:58:00 -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.9.3/8.9.1) with ESMTP id PAA07246 for ; Tue, 10 Apr 2001 15:56:40 -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 ADV13561; Tue, 10 Apr 2001 15:57:58 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA07170; Tue, 10 Apr 2001 15:57:58 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15059.36853.876585.189955@thomasm-u1.cisco.com> Date: Tue, 10 Apr 2001 15:57:57 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Routing header ordering In-Reply-To: <3ACDFBA5.3655D603@inrialpes.fr> References: <3ACDBFC1.F3E5121A@inrialpes.fr> <15053.58913.722549.842387@thomasm-u1.cisco.com> <3ACDEAB3.9E5ABDE9@inrialpes.fr> <15053.60925.641884.938683@thomasm-u1.cisco.com> <3ACDFBA5.3655D603@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: > > If you want an optimized route, MN needs to know > > send a BU to CN as well. > > Not necessarily. It depends on the solution adopted to support MR. The > MN can tell its CNs it is located in the mobile network whereas the MR > can tell them where is the MR. Thierry, I think we might be talking past each other. What I was talking about is a mobile node (not a stationary host) behind a mobile router. If they are both off their home network, each in turn would need to perform route optimization. I think I've convinced myself that may be a general problem with a naive approach. Consider a a mobile node behind a mobile router, both away from their home subnet. They have home agents HAr and HAn respectively. Also, there is AR1 and AR2 which MR attaches to. The initial flow is: CN->HAr->AR1->MR->HAn->MN | | <---BU--------+ | | <--------BU------------+ That is, each time a packet arrives on its home agent tunnel interface, that node sends a BU. We get route optimization because it sends it Co(MR) and then Co(MN) which is the least cost route. Thus each IP packet to MN from CN is (initially): DST(CoA(AR1.x)):RH(CoA(MR.y)):RH(CoA(HAn.z)) When the MR moves, after it's sent its BU to the CN, the flow is: CN->AR2->MR->MN The CN->MN packets now look like: DST(CoA(AR2.c)):RH(CoA(MR.y)):RH(CoA(HAn.z)) The potential problem lies in the ordering of the routing headers. If instead -- for whatever reason -- the CN formed a packet like: DST(CoA(MR.y)):RH(CoA(AR2.c))):RH(CoA(HAn.z)) it would then take the route: CN->HAr->AR2->MR->MN | <----BU-------+ which would seemingly either get into a loop, or non-optimal routing. What I don't see is how CN can sort this all out. How, for example, does it know that MR is topologically closer which is the key to getting the routing header stack right?!? Mike From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 11 02:04: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 CAA17111 for ; Wed, 11 Apr 2001 02:04:30 -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 XAA19231; Tue, 10 Apr 2001 23:04: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 XAA07791; Tue, 10 Apr 2001 23:03:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3B62XK9015703 for ; Tue, 10 Apr 2001 23:02:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3B62X31015702 for mobile-ip-dist; Tue, 10 Apr 2001 23:02: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3B62OK9015695 for ; Tue, 10 Apr 2001 23:02: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 XAA26484 for ; Tue, 10 Apr 2001 23:02:25 -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 AAA11776 for ; Wed, 11 Apr 2001 00:05:48 -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 XAA28773; Tue, 10 Apr 2001 23:02:19 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3B62IF09762; Tue, 10 Apr 2001 23:02:18 -0700 X-mProtect: Tue, 10 Apr 2001 23:02: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(WTS.12.69) smtpdQfV1Yb; Tue, 10 Apr 2001 23:02:07 PDT Message-ID: <3AD3F16A.7A23C3B1@iprg.nokia.com> Date: Tue, 10 Apr 2001 22:53:46 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: Pekka Nikander Subject: [mobile-ip] A less drafty draft 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, We have a fairly complete draft, specifying a method for establishing a Binding Key between mobile node and Correspondent Node, available at the following URL: http://people.nokia.net/charliep/txt/bke/bke.txt It is our belief that the protocol in this draft is suitable for meeting the requirements laid out at IETF 50 by Jeff Schiller to enable the use of Binding Update messages between mobile nodes and correspondent nodes. This draft is also going to be submitted to the Internet Draft directories. Comments are, as always, welcome! Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 11 05:07: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 FAA19098 for ; Wed, 11 Apr 2001 05:07:45 -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 CAA14127; Wed, 11 Apr 2001 02:06:50 -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 CAA21322; Wed, 11 Apr 2001 02:06:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3B95UK9015835 for ; Wed, 11 Apr 2001 02:05:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3B95THu015834 for mobile-ip-dist; Wed, 11 Apr 2001 02:05: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3B95JK9015827 for ; Wed, 11 Apr 2001 02:05:19 -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 CAA18369 for ; Wed, 11 Apr 2001 02:05:19 -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 CAA13505 for ; Wed, 11 Apr 2001 02:05:18 -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 LAA19775 for ; Wed, 11 Apr 2001 11:04:56 +0200 (MEST) Message-ID: <3AD41E16.A81A847B@inrialpes.fr> Date: Wed, 11 Apr 2001 11:04:22 +0200 From: Thierry Ernst Organization: INRIA Rhone-Alpes 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] Routing header ordering References: <3ACDBFC1.F3E5121A@inrialpes.fr> <15053.58913.722549.842387@thomasm-u1.cisco.com> <3ACDEAB3.9E5ABDE9@inrialpes.fr> <15053.60925.641884.938683@thomasm-u1.cisco.com> <3ACDFBA5.3655D603@inrialpes.fr> <15059.36853.876585.189955@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, Michael, > > > If you want an optimized route, MN needs to know > > > send a BU to CN as well. > > > > Not necessarily. It depends on the solution adopted to support MR. The > > MN can tell its CNs it is located in the mobile network whereas the MR > > can tell them where is the MR. To clarify: I meant "the solution to the problem you are stating depends whether we use my solution to support mobile networks, or HMIP", then any discussion is pure theory... > I think we might be talking past each other. What > I was talking about is a mobile node (not a > stationary host) behind a mobile router. If they > are both off their home network, each in turn > would need to perform route optimization. Don't take me wrong, I understood what you said. I use to call a cat a cat: o A MN is a node which is changing it's point of attachment, no matter what is the point of attachment (a fixed router or a mobile router). o A MR is a router which is changing its point of attachment. o A Stationary Node (SN) is a node which is not changing its point of attachment. If a MR and all its attached nodes is moving, its attached SNs are still attached to it and I don't call them "MNs". > I think I've convinced myself that may be a > general problem with a naive approach. Consider a > a mobile node behind a mobile router, both away > from their home subnet. They have home agents HAr > and HAn respectively. Also, there is AR1 and AR2 > which MR attaches to. The initial flow is: > > CN->HAr->AR1->MR->HAn->MN > | | > <---BU--------+ | > | > <--------BU------------+ > which would seemingly either get into a loop, or > non-optimal routing. What I don't see is how CN > can sort this all out. How, for example, does it > know that MR is topologically closer which is the > key to getting the routing header stack right?!? The problem you are speaking about is clear to me and to anyone who would think about it for a little while, and it is not yet documented in my draft (i.e. sending the mobile_network_prefix to HA and CNs) since I over-simplified it to get a clear picture of (some of) the potential problems. It currently only address the case where there are no MNs behind the MR. It could also address MN behind the MR, but there are additional problems, amongst them the "Routing Header Ordering". Anyway, you can basically perform route optimization between CN and MN_behind_the_MR with my proposal, but the CN operation needs to be modified in order to know how to fill the Routing Header with 2 COAs: one for the MR, and one for the MN. This is tricky, but a longest prefix match would be enough to decide which COA needs to be included first. The problem I can see is ratter the cost of signalling has both the MR and the MN need to advertise their own COA. I don't want to enter into details right now because I need to solve other aspects (mainly authorization) before I design the overall solution. Anyway, I will document my draft before next IETF meeting and address some of the issues I have left behind. I think we need to agree that the issues of Mobile Routers and Networks is sufficiently important to be addressed by the MIP WG. I think everyone agree that there are problems to be solved. At least the past discussions has shown that quite a few people are trying to tackle the problems and some have voted for it to be included in the WG charter. Cheers, Thierry. http://www.inrialpes.fr/planete/people/ernst/Documents/draft-ernst-mobileip-v6-network.txt -- * 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/ From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 11 06:11: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 GAA19443 for ; Wed, 11 Apr 2001 06:11: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 DAA18676; Wed, 11 Apr 2001 03:08:54 -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 DAA23909; Wed, 11 Apr 2001 03:08:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BA6lK9015892 for ; Wed, 11 Apr 2001 03:06:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3BA6kUZ015891 for mobile-ip-dist; Wed, 11 Apr 2001 03:06: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BA6bK9015884 for ; Wed, 11 Apr 2001 03:06:38 -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 DAA27707 for ; Wed, 11 Apr 2001 03:06:37 -0700 (PDT) Received: from c007.snv.cp.net (c007-h000.c007.snv.cp.net [209.228.33.206]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id DAA17368 for ; Wed, 11 Apr 2001 03:06:36 -0700 (PDT) Received: (cpmta 8940 invoked from network); 11 Apr 2001 03:06:35 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.206) with SMTP; 11 Apr 2001 03:06:35 -0700 X-Sent: 11 Apr 2001 10:06:35 GMT Message-ID: <000b01c0c26e$d7f01340$6501a8c0@philneum> From: "Phil Neumiller" To: Cc: "Pekka Nikander" References: <3AD3F16A.7A23C3B1@iprg.nokia.com> Subject: Re: [mobile-ip] A less drafty draft Date: Wed, 11 Apr 2001 05:04:40 -0500 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: I had some basic questions on the less drafty draft. 0). WARNING: Often security holes and exploits are found in the procedures used to implement cryptographically secure algorithms, i.e. the implementation goo is the place where the holes will turn up for would be attackers. Since this less drafty draft is indeed implementation goo, it deserves extra careful attention. I believe this draft is security work and requires careful cryptanalysis. Again I must ask, is the MIP WG the most qualified WG in the IETF to perform this duty? 1). Why is forcing the malicious node onto the routing path between the CN and HA so important? Is this somehow perceived to be harder for the attacker to do? What other way could an attacker choose to attack, i.e. this seems like a tautology to me (i.e. if you are going to attack you probably want to be mucking with the route on the route) [if its not DoS]. 2). If the CN is a MN (does not seem to be ruled out), then why is this routing path necessarily "a small part of the Internet"? Seems like there *could* be a few routers between two arbitary points on the planet. 3). MNs will usually be on the air. So eavesdropping on "all" the traffic between the MN and the CN does not seem like such a chore to me. Doesn't this put all key construction material in the hands of an attacker? -pdn From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 11 09:26:03 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 JAA23644 for ; Wed, 11 Apr 2001 09: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 GAA00611; Wed, 11 Apr 2001 06: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 GAA05138; Wed, 11 Apr 2001 06:25:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BDOBK9016015 for ; Wed, 11 Apr 2001 06:24:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3BDOBJ7016014 for mobile-ip-dist; Wed, 11 Apr 2001 06:24:11 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BDO2K9016007 for ; Wed, 11 Apr 2001 06:24: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 GAA13475 for ; Wed, 11 Apr 2001 06:24:01 -0700 (PDT) Received: from zrtps06u.us.nortel.com (h52s48a140n47.user.nortelnetworks.com [47.140.48.52]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA08004 for ; Wed, 11 Apr 2001 07:29:57 -0600 (MDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with ESMTP id f3BDMaq05234 for ; Wed, 11 Apr 2001 09:22:36 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 11 Apr 2001 09:23:34 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 11 Apr 2001 09:23:36 -0400 Message-ID: From: "Hongyi Li" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents Date: Wed, 11 Apr 2001 09:23:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C28A.9B7E3970" 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_01C0C28A.9B7E3970 Content-Type: text/plain; charset="iso-8859-1" Hi Phil, Mobile IPv6 achieves route optimization by using cutting through path that bypasses the anchor point (i.e., home agent). If a LMM protocol introduces new type of anchor points, the path optimization will become an issue again. Therefore , it is a goal for LMM to achieve the same level of route optimization as in MIP v6 that is to use the route selected by native IP routing protocol (i.e., OSPF, RIP, BGP..). The route optimization requirement is applicable for all mobile communications and shouldn't limited for mobile-to-mobile. Therefore, the requirement 10 should be "LMM SHALL provide optimized routing for mobile communication" -Hongyi -----Original Message----- From: Phil Roberts [mailto:PRoberts@MEGISTO.com] Sent: Tuesday, April 10, 2001 10:35 AM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents Hi, I'm a little confused about your req 10. MIP v6 already has route optimization. Do you envision req 10 to provide an alternative to that or to interoperate with that or ... something else? Thanks, Phil -----Original Message----- From: Hongyi Li [mailto:hyli@nortelnetworks.com] Sent: Tuesday, April 10, 2001 10:21 AM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents Hi Phil, Here are few more requirements I think that are impportant for RR/LMM (I like the term localized mobility management too): 10) LMM SHALL provide optimized routing for mobile-to-mobile communication. 11) LMM SHOULD minimize the number of network nodes affected by handoff signals. 12) LMM SHOULD support auto-configuration capabilities for mobile agents/FAs, access routers. 13) LMM SHOULD simplify the network design and provisioning for enabling LMM capability in a network and allow progressive LMM deployment capabilities. Some more comments in lines: > 1) Regional registration shall be introduced to minimize the signaling > traffic to the home agent or correspondent nodes for > intra-domain mobility > 2) Regional registration shall not introduce new overhead on > links between > the mobile and the regional registration agents > 3) Connectivity to the mobiles shall not be interrupted in > the presence of > the failure of regional registration agents > 4) Regional registration shall scale to support millions of nodes in a > visited network LMM SHALL be scalable in terms of number of connected users (i.e., active + dormant = millions) and the number of users on the move. > 5) Regional registration shall be secure against malicious > behavior from > visiting mobiles > 6) Regional registration shall allow multiple levels of hierarchy > 7) Regional registration shall support fast handoffs > 8) Regional registration shall not require changes to the > mobile node, the > home agent, or correspondent nodes > 9) Regional registration shall not introduce host routes in > routing tables I agree with Theo comments about host route. The LMM SHOULD minimize the amount of host routes in the routers. - Hongyi ------_=_NextPart_001_01C0C28A.9B7E3970 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] IPv6 Regional Registration - identifying requirements
Hi Phil,
  Mobile IPv6 achieves route optimization by using cutting through path that bypasses the anchor
point (i.e., home agent). If a LMM protocol introduces new type of anchor points, the path optimization will become
an issue again. Therefore , it is a goal for LMM to achieve the same level of route optimization as in MIP v6 that
is to use the route selected by native IP routing protocol (i.e., OSPF, RIP, BGP..).
  The route optimization requirement is applicable for all mobile communications and shouldn't limited for
mobile-to-mobile. Therefore, the requirement 10 should be "LMM SHALL provide optimized routing for mobile
communication"
 
-Hongyi
 
-----Original Message-----
From: Phil Roberts [mailto:PRoberts@MEGISTO.com]
Sent: Tuesday, April 10, 2001 10:35 AM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents

Hi,
 
I'm a little confused about your req 10.  MIP v6 already has route optimization.  Do you envision req 10 to provide an alternative to that or to interoperate with that or ... something else?
 
Thanks,
Phil
 
-----Original Message-----
From: Hongyi Li [mailto:hyli@nortelnetworks.com]
Sent: Tuesday, April 10, 2001 10:21 AM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents

Hi Phil,
  Here are few more requirements I think that are impportant for RR/LMM (I like
the term localized mobility management too):

 10) LMM SHALL provide optimized routing for mobile-to-mobile communication.
 11) LMM SHOULD minimize the number of network nodes affected by handoff signals.
 12) LMM SHOULD support auto-configuration capabilities for mobile agents/FAs, access routers.
 13) LMM SHOULD simplify the network design and provisioning for enabling LMM
capability in a network and allow progressive LMM deployment capabilities.

Some more comments in lines:
  
> 1) Regional registration shall be introduced to minimize the signaling
> traffic to the home agent or correspondent nodes for
> intra-domain mobility
> 2) Regional registration shall not introduce new overhead on
> links between
> the mobile and the regional registration agents
> 3) Connectivity to the mobiles shall not be interrupted in
> the presence of
> the failure of regional registration agents
> 4) Regional registration shall scale to support millions of nodes in a
> visited network

LMM SHALL be scalable in terms of number of connected users (i.e., active + dormant =  millions) and the number of users on the move.

> 5) Regional registration shall be secure against malicious
> behavior from
> visiting mobiles
> 6) Regional registration shall allow multiple levels of hierarchy
> 7) Regional registration shall support fast handoffs
> 8) Regional registration shall not require changes to the
> mobile node, the
> home agent, or correspondent nodes
> 9) Regional registration shall not introduce host routes in
> routing tables

I agree with Theo comments about host route. The LMM SHOULD minimize the amount of host routes in the routers.

- Hongyi

------_=_NextPart_001_01C0C28A.9B7E3970-- From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 11 09:27:52 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 JAA23696 for ; Wed, 11 Apr 2001 09:27:51 -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 GAA02082; Wed, 11 Apr 2001 06:27: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 GAA10588; Wed, 11 Apr 2001 06:26:57 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BDPMK9016025 for ; Wed, 11 Apr 2001 06:25:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3BDPMrL016024 for mobile-ip-dist; Wed, 11 Apr 2001 06:25: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BDPAK9016017 for ; Wed, 11 Apr 2001 06:25: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 GAA05116 for ; Wed, 11 Apr 2001 06:25:10 -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 GAA00402 for ; Wed, 11 Apr 2001 06:25:09 -0700 (PDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Wed, 11 Apr 2001 09:24:11 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'Vijay Devarapalli'" , mobile-ip@sunroof.eng.sun.com Cc: "'Mohan Parthasarathy'" , "Kiernan, Brian G." , charliep@IPRG.nokia.com, "Shahrier, Sharif M." Subject: RE: [mobile-ip] some issues with IPv6 mobility draft (sharif) Date: Wed, 11 Apr 2001 09:24:05 -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: "Shahrier, Sharif M." wrote: > * Suppose that node A is moving "rapidly". Node B is also moving. > B sends a datagram to A; A is not there; ICMP host unreachable --> B. B > deletes entry from its binding cache; sends Binding Request to A's HA;HA > sends A's COA to B. Supposes this last step is long because of congestion. Wrong again!! the A's Home agent does not respond to the binding request. the binding request is tunneled to A and A responds with a BU. I think there is a mis-understanding here. You are correct in stating that the Binding Request is sent to MN A, and it Replies with a Binding Update. These messages are generally exchanged when B's Binding Cache entry is close to Expiration of its lifetime, and the messages are "piggybacked". Thus, I can see that you are familiar with section 8.6 of the draft. However, the draft does not deal with the problem I had pointed out. I was merely pointing out a possible "extension" to the draft to deal with the problem; by sending Binding Request to the HA after it receives the ICMP message. This is not currently in the draft. Of course, B cannot send a Binding Request to A, which is what you are saying, because it doesn't know the location of A !! That is the root of the problem !! > > During the step above, A sends a Binding Update to its home agent, receives > Acknowledgement, A moves to its new COA. B sends datagram to A's previous > COA; A is not there; B is sent ICMP; Process continues forever..... > > A possible solution to prevent this "looping" effect is to keep caching A's > new binding at its previous COA. The previous COA can use the binding to > forward packets to A. > This is already there in the base mobile ipv6. the previous access router to which the A was connected to forwards packets to A's new location. this is set up by A sending a BU to its previous access router binding its new CoA and old CoA. Yes, but please read my next paragraph. This method is not robust, and will not work if the previous access router fails or is reconfigured. I am not aware of any existing solutions that was handle this scanario. Do you? > But this method will also fail if one of the "previous" agents caching the > COA's fails or is reconfigured ........ > > Thus, I prefer my previously posted "solution", in just using the HA > approach because: > whatever you have described till now is based on lot of things failing. you also assume that the MN is handing off faster than the round trip time to the CN. No, there are a number of possibilities. One of them is that the communication between HA and CN is slower than HA and MN, because of congestion. There are many other cases. and your solution of the home agent maintaining the binding update list is not worthy of any consideration. stop this thread on the mailing list. lets go offline. i can explain things in more detail there... You are welcome in your comments. However: * You have not provided an alternative, strong, robust solution to the problem I indicated. * You have not given a good reason why using just "HA signaling" is a bad idea. * You have not given a good reason as to why we should "ignore" the problem completely. Until, that happens, I don't see any reason not to persist with this. In any case, the issue of multicasting makes the problem even worse, and I would welcome and comments or solutions in that respect. Thanks. Sharif. vijay > o It eliminates extra level of signaling between mobile-to-mobile. Signaling > is only between mobile and HA. > o It simplifies the binding caches at each MN and CN, reduces overhead of > protocol operation. > > * Secondly, how does the ICMP solve the problem with > multicast groups? A multicast group is assigned a particular multicast > address for communication. Thus, if one member of the group is unreachable, > it doesn't seem that the ICMP solution will solve the problem here. > > Comments please ....... > > Sharif. From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 11 09:59: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 JAA24205 for ; Wed, 11 Apr 2001 09:59:05 -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 GAA26306; Wed, 11 Apr 2001 06:58: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 GAA18135; Wed, 11 Apr 2001 06:58:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BDtMK9016169 for ; Wed, 11 Apr 2001 06:55:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3BDtMQ5016167 for mobile-ip-dist; Wed, 11 Apr 2001 06:55: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BDtDK9016160 for ; Wed, 11 Apr 2001 06:55:13 -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 GAA17802 for ; Wed, 11 Apr 2001 06:55:13 -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 GAA03437 for ; Wed, 11 Apr 2001 06:55:11 -0700 (PDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Wed, 11 Apr 2001 09:49:42 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents Date: Wed, 11 Apr 2001 09:49:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C28E.42707FEC" Sender: owner-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_01C0C28E.42707FEC Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Hongyi Li [mailto:hyli@nortelnetworks.com] Sent: Wednesday, April 11, 2001 9:24 AM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents Hi Phil, Mobile IPv6 achieves route optimization by using cutting through path that bypasses the anchor point (i.e., home agent). If a LMM protocol introduces new type of anchor points, the path optimization will become an issue again. Therefore , it is a goal for LMM to achieve the same level of route optimization as in MIP v6 that is to use the route selected by native IP routing protocol (i.e., OSPF, RIP, BGP..). The route optimization requirement is applicable for all mobile communications and shouldn't limited for mobile-to-mobile. Therefore, the requirement 10 should be "LMM SHALL provide optimized routing for mobile communication" [Phil Roberts] Hi, Understand your revised requirement, but I'm not sure what you're trying to say in the first paragraph. If there is a localized mobility management agent somewhere between the last hop router and the home agent, do you want the route optimized path to go through that local mobility agent or not? And does it depend on the circumstances of the communication? *And* can you write a requirement saying that? (Not to imply that it will be an accepted requirement but one up for discussion). Phil -Hongyi -----Original Message----- From: Phil Roberts [mailto:PRoberts@MEGISTO.com] Sent: Tuesday, April 10, 2001 10:35 AM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents Hi, I'm a little confused about your req 10. MIP v6 already has route optimization. Do you envision req 10 to provide an alternative to that or to interoperate with that or ... something else? Thanks, Phil -----Original Message----- From: Hongyi Li [mailto:hyli@nortelnetworks.com] Sent: Tuesday, April 10, 2001 10:21 AM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents Hi Phil, Here are few more requirements I think that are impportant for RR/LMM (I like the term localized mobility management too): 10) LMM SHALL provide optimized routing for mobile-to-mobile communication. 11) LMM SHOULD minimize the number of network nodes affected by handoff signals. 12) LMM SHOULD support auto-configuration capabilities for mobile agents/FAs, access routers. 13) LMM SHOULD simplify the network design and provisioning for enabling LMM capability in a network and allow progressive LMM deployment capabilities. Some more comments in lines: > 1) Regional registration shall be introduced to minimize the signaling > traffic to the home agent or correspondent nodes for > intra-domain mobility > 2) Regional registration shall not introduce new overhead on > links between > the mobile and the regional registration agents > 3) Connectivity to the mobiles shall not be interrupted in > the presence of > the failure of regional registration agents > 4) Regional registration shall scale to support millions of nodes in a > visited network LMM SHALL be scalable in terms of number of connected users (i.e., active + dormant = millions) and the number of users on the move. > 5) Regional registration shall be secure against malicious > behavior from > visiting mobiles > 6) Regional registration shall allow multiple levels of hierarchy > 7) Regional registration shall support fast handoffs > 8) Regional registration shall not require changes to the > mobile node, the > home agent, or correspondent nodes > 9) Regional registration shall not introduce host routes in > routing tables I agree with Theo comments about host route. The LMM SHOULD minimize the amount of host routes in the routers. - Hongyi ------_=_NextPart_001_01C0C28E.42707FEC Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] IPv6 Regional Registration - identifying requirements
 
-----Original Message-----
From: Hongyi Li [mailto:hyli@nortelnetworks.com]
Sent: Wednesday, April 11, 2001 9:24 AM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents

Hi Phil,
  Mobile IPv6 achieves route optimization by using cutting through path that bypasses the anchor
point (i.e., home agent). If a LMM protocol introduces new type of anchor points, the path optimization will become
an issue again. Therefore , it is a goal for LMM to achieve the same level of route optimization as in MIP v6 that
is to use the route selected by native IP routing protocol (i.e., OSPF, RIP, BGP..).
  The route optimization requirement is applicable for all mobile communications and shouldn't limited for
mobile-to-mobile. Therefore, the requirement 10 should be "LMM SHALL provide optimized routing for mobile
communication"
[Phil Roberts] 
Hi,
 
   Understand your revised requirement, but I'm not sure what you're trying to say in the first paragraph.  If there is a
localized mobility management agent somewhere between the last hop router and the home agent, do you want the
route optimized path to go through that local mobility agent or not?  And does it depend on the circumstances of the
communication?  *And* can you write a requirement saying that?  (Not to imply that it will be an accepted requirement
but one up for discussion).
 
Phil
 
 
-Hongyi
 
-----Original Message-----
From: Phil Roberts [mailto:PRoberts@MEGISTO.com]
Sent: Tuesday, April 10, 2001 10:35 AM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents

Hi,
 
I'm a little confused about your req 10.  MIP v6 already has route optimization.  Do you envision req 10 to provide an alternative to that or to interoperate with that or ... something else?
 
Thanks,
Phil
 
-----Original Message-----
From: Hongyi Li [mailto:hyli@nortelnetworks.com]
Sent: Tuesday, April 10, 2001 10:21 AM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents

Hi Phil,
  Here are few more requirements I think that are impportant for RR/LMM (I like
the term localized mobility management too):

 10) LMM SHALL provide optimized routing for mobile-to-mobile communication.
 11) LMM SHOULD minimize the number of network nodes affected by handoff signals.
 12) LMM SHOULD support auto-configuration capabilities for mobile agents/FAs, access routers.
 13) LMM SHOULD simplify the network design and provisioning for enabling LMM
capability in a network and allow progressive LMM deployment capabilities.

Some more comments in lines:
  
> 1) Regional registration shall be introduced to minimize the signaling
> traffic to the home agent or correspondent nodes for
> intra-domain mobility
> 2) Regional registration shall not introduce new overhead on
> links between
> the mobile and the regional registration agents
> 3) Connectivity to the mobiles shall not be interrupted in
> the presence of
> the failure of regional registration agents
> 4) Regional registration shall scale to support millions of nodes in a
> visited network

LMM SHALL be scalable in terms of number of connected users (i.e., active + dormant =  millions) and the number of users on the move.

> 5) Regional registration shall be secure against malicious
> behavior from
> visiting mobiles
> 6) Regional registration shall allow multiple levels of hierarchy
> 7) Regional registration shall support fast handoffs
> 8) Regional registration shall not require changes to the
> mobile node, the
> home agent, or correspondent nodes
> 9) Regional registration shall not introduce host routes in
> routing tables

I agree with Theo comments about host route. The LMM SHOULD minimize the amount of host routes in the routers.

- Hongyi

------_=_NextPart_001_01C0C28E.42707FEC-- From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 11 11:07: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 LAA25616 for ; Wed, 11 Apr 2001 11:07:50 -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 IAA21177; Wed, 11 Apr 2001 08:07: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 IAA28968; Wed, 11 Apr 2001 08:06:57 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BF5fK9016265 for ; Wed, 11 Apr 2001 08:05:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3BF5e6A016264 for mobile-ip-dist; Wed, 11 Apr 2001 08:05: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BF5VK9016257 for ; Wed, 11 Apr 2001 08:05:31 -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 IAA27217 for ; Wed, 11 Apr 2001 08:05:31 -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 JAA08976 for ; Wed, 11 Apr 2001 09:11:51 -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 IAA24105; Wed, 11 Apr 2001 08:05:25 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3BF5O517850; Wed, 11 Apr 2001 08:05:24 -0700 X-mProtect: Wed, 11 Apr 2001 08:05:24 -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(WTS.12.69) smtpdWBXOhU; Wed, 11 Apr 2001 08:05:18 PDT Message-ID: <3AD472AF.5CC3FF28@iprg.nokia.com> Date: Wed, 11 Apr 2001 08:05:19 -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: Phil Neumiller CC: mobile-ip@sunroof.eng.sun.com, Pekka Nikander Subject: Re: [mobile-ip] A less drafty draft References: <3AD3F16A.7A23C3B1@iprg.nokia.com> <000b01c0c26e$d7f01340$6501a8c0@philneum> 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 Phil, > 0). WARNING: Often security holes and exploits are found in the procedures used > to implement cryptographically secure algorithms, i.e. the implementation goo is > the place where the holes will turn up for would be attackers. Since this less > drafty draft is indeed implementation goo, it deserves extra careful attention. > I believe this draft is security work and requires careful cryptanalysis. Again > I must ask, is the MIP WG the most qualified WG in the IETF to perform this duty? Well, someone has to do it, and sooner is better in my opinion. Given recent events, I have no doubt that BKE will get a full security review before it would have any chance to progress to Proposed Standard. > 1). Why is forcing the malicious node onto the routing path between the CN and HA > so important? Is this somehow perceived to be harder for the attacker to do? > What other way could an attacker choose to attack, i.e. this seems like a > tautology to me (i.e. if you are going to attack you probably want to be > mucking with the route on the route) [if its not DoS]. If I were an attacker, I'd rather attack from some totally random spot in the Internet, difficult to detect, and able to be changed to a new vantage point instantaneously. The stated restriction makes almost all such vantage points unworkable. Having said that ... Our protocol is NOT vulnerable to random nodes on the path between the correspondent node and the home network. Most nodes on that path do not have any way to discover the random number 'R' which is sent by the mobile node to the correspondent node in the Binding Key Establishment destination option. Such nodes cannot pretend to be the mobile node. They also cannot receive the key information from the mobile node, which will be addressed directly to the correspondent node. The protocol is vulnerable only to attackers on the correspondent node's link, and (when the HA->MN tunnel is unprotected) on the mobile node's current link. Actually, we'd prefer if there weren't any vulnerabilities to attackers on any paths. Here, it's worthwhile to keep in mind the goal: "Do no harm", which I interpret to mean that we should not introduce vulnerabilities to any attacks which do not exist between statically located IPv4 network nodes. If a mobile node is on its home network, the only vulnerabilities exist when there are attackers between itself and its correspondent node. If the mobile node moves, and uses the BKE protocol, then we have not introduced any further vulnerability. > 2). If the CN is a MN (does not seem to be ruled out), then why is this routing path > necessarily "a small part of the Internet"? Seems like there *could* be a few > routers between two arbitary points on the planet. Agreed. Let's say there are 15. That's still a tiny part of the Internet. But see above, where anyway our vulnerability is much more restricted than that. Again, I claim that our solution is much better (and still computationally very small) than the minimum required solution, reducing vulnerability even beyond that which is required by "Do no harm". > 3). MNs will usually be on the air. So eavesdropping on "all" the traffic between > the MN and the CN does not seem like such a chore to me. Doesn't this put > all key construction material in the hands of an attacker? Key material can be acquired by anyone on the same link as the correspondent node. With unprotected tunnels, it puts key material in the hands of anyone on the same link as the mobile node. The key material is ONLY to be used for authenticating Binding Updates, which are ONLY used to enable a correspondent node to have efficient communications with a mobile node. In my view, this is an acceptable risk, less vulnerable than ARP today. For cases where additional authentication is necessary, we can design additional protocol. However, the additional protocol SHOULD NOT be mandatory for implementation in all IPv6 nodes. BKE, on the other hand, SHOULD be mandatory for implementation in all IPv6 nodes. We have to build a protocol that is simple, effective, and yet "does no harm". Regards, Charlie P. PS. I boldly adjusted your white space in places to make your text look prettier on my screen. Thanks for using ASCII only in your e-mails :-) From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 11 12:04:46 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA27113 for ; Wed, 11 Apr 2001 12:04: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 JAA11734; Wed, 11 Apr 2001 09:02: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 JAA10555; Wed, 11 Apr 2001 09:03:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BG2YK9016376 for ; Wed, 11 Apr 2001 09:02:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3BG2XPT016375 for mobile-ip-dist; Wed, 11 Apr 2001 09:02: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BG2OK9016368 for ; Wed, 11 Apr 2001 09:02:24 -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 JAA14264 for ; Wed, 11 Apr 2001 09:02:24 -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 JAA04890 for ; Wed, 11 Apr 2001 09:02:22 -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 JAA28977; Wed, 11 Apr 2001 09:02:18 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3BG2Hq10415; Wed, 11 Apr 2001 09:02:17 -0700 X-mProtect: Wed, 11 Apr 2001 09:02: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(WTS.12.69) smtpdtA1LJu; Wed, 11 Apr 2001 09:02:10 PDT Message-ID: <3AD48002.E21502C2@iprg.nokia.com> Date: Wed, 11 Apr 2001 09:02:10 -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: Phil Neumiller CC: mobile-ip@sunroof.eng.sun.com, Pekka Nikander Subject: Re: [mobile-ip] A less drafty draft References: <3AD3F16A.7A23C3B1@iprg.nokia.com> <000b01c0c26e$d7f01340$6501a8c0@philneum> <3AD472AF.5CC3FF28@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 Hello again Phil, I need to make a clarification to my previous note, which was written with an unstated assumption. The assumption I made, was that the mobile node itself had started the process of creating a Binding Key. Consider what happens if this assumption is invalid, and an active attacker resides along the routing path between the correspondent node and the home network. In this case, the correspondent node can be fooled into setting up a security association with the active attacker as follows: - Attacker sends Binding Warning with IP source address some random care-of address (perhaps its own IP address). - Attacker receives Binding Request on its way from the correspondent node to the home network. - Attacker responds to the Binding Request with a suitably doctored up BKE message. - Correspondent node now believes that it can rely on the BKSA supplied by the attacker. Note that all of this does not introduce any vulnerability not already present in today's Internet. Furthermore, we can protect against usurping EXISTING security associations by simple rules at the correspondent nodes. Lastly, if ingress filtering is in place, the attacker is limited to using a care-of address which is topologically correct along the restricted routing path. Thanks again for your consideration of our protocol. Regards, Charlie P. "Charles E. Perkins" wrote: > > Hello Phil, > > > 0). WARNING: Often security holes and exploits are found in the procedures used > > to implement cryptographically secure algorithms, i.e. the implementation goo is > > the place where the holes will turn up for would be attackers. Since this less > > drafty draft is indeed implementation goo, it deserves extra careful attention. > > I believe this draft is security work and requires careful cryptanalysis. Again > > I must ask, is the MIP WG the most qualified WG in the IETF to perform this duty? > > Well, someone has to do it, and sooner is better in my opinion. Given > recent events, I have no doubt that BKE will get a full security review > before it would have any chance to progress to Proposed Standard. > > > 1). Why is forcing the malicious node onto the routing path between the CN and HA > > so important? Is this somehow perceived to be harder for the attacker to do? > > What other way could an attacker choose to attack, i.e. this seems like a > > tautology to me (i.e. if you are going to attack you probably want to be > > mucking with the route on the route) [if its not DoS]. > > If I were an attacker, I'd rather attack from some totally random spot > in the Internet, difficult to detect, and able to be changed to a new > vantage point instantaneously. The stated restriction makes almost all > such vantage points unworkable. Having said that ... > > Our protocol is NOT vulnerable to random nodes on the path between the > correspondent node and the home network. Most nodes on that path do not > have any way to discover the random number 'R' which is sent by the mobile > node to the correspondent node in the Binding Key Establishment destination > option. Such nodes cannot pretend to be the mobile node. They also cannot > receive the key information from the mobile node, which will be addressed > directly to the correspondent node. The protocol is vulnerable only to > attackers on the correspondent node's link, and (when the HA->MN tunnel > is unprotected) on the mobile node's current link. > > Actually, we'd prefer if there weren't any vulnerabilities to attackers on > any paths. Here, it's worthwhile to keep in mind the goal: > "Do no harm", > which I interpret to mean that we should not introduce vulnerabilities to > any attacks which do not exist between statically located IPv4 network nodes. > If a mobile node is on its home network, the only vulnerabilities exist when > there are attackers between itself and its correspondent node. If the mobile > node moves, and uses the BKE protocol, then we have not introduced any further > vulnerability. > > > 2). If the CN is a MN (does not seem to be ruled out), then why is this routing path > > necessarily "a small part of the Internet"? Seems like there *could* be a few > > routers between two arbitary points on the planet. > > Agreed. Let's say there are 15. That's still a tiny part of the Internet. > But see above, where anyway our vulnerability is much more restricted > than that. Again, I claim that our solution is much better (and still > computationally very small) than the minimum required solution, reducing > vulnerability even beyond that which is required by "Do no harm". > > > 3). MNs will usually be on the air. So eavesdropping on "all" the traffic between > > the MN and the CN does not seem like such a chore to me. Doesn't this put > > all key construction material in the hands of an attacker? > > Key material can be acquired by anyone on the same link as the correspondent > node. With unprotected tunnels, it puts key material in the hands of anyone > on the same link as the mobile node. The key material is ONLY to be used > for authenticating Binding Updates, which are ONLY used to enable a > correspondent > node to have efficient communications with a mobile node. > > In my view, this is an acceptable risk, less vulnerable than ARP today. > > For cases where additional authentication is necessary, we can design > additional protocol. However, the additional protocol SHOULD NOT be > mandatory for implementation in all IPv6 nodes. BKE, on the other hand, > SHOULD be mandatory for implementation in all IPv6 nodes. We have to > build a protocol that is simple, effective, and yet "does no harm". > > Regards, > Charlie P. > > PS. I boldly adjusted your white space in places to make your text look > prettier on my screen. Thanks for using ASCII only in your e-mails :-) From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 11 12:30: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 MAA27780 for ; Wed, 11 Apr 2001 12:30: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 JAA05743; Wed, 11 Apr 2001 09:29: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 JAA13221; Wed, 11 Apr 2001 09:29:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BGS0K9016452 for ; Wed, 11 Apr 2001 09:28:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3BGS0hN016451 for mobile-ip-dist; Wed, 11 Apr 2001 09:28: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 eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BGRsK9016444 for ; Wed, 11 Apr 2001 09:27:54 -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 MAA27528 for ; Wed, 11 Apr 2001 12:27:53 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id MAA22561 for mobile-ip@sunroof.eng.sun.com; Wed, 11 Apr 2001 12:28:03 -0400 (EDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3A24YK9012222 for ; Mon, 9 Apr 2001 19:04:35 -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 TAA20645 for ; Mon, 9 Apr 2001 19:04:34 -0700 (PDT) Received: from NEPTUNE.zucotto.com ([216.95.209.154]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA26402 for ; Mon, 9 Apr 2001 19:04:33 -0700 (PDT) Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Apr 2001 22:04:32 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B90D2AFF@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Michael Thomas'" , khiem.le@nokia.com Cc: rajeev.koodli@nokia.com, gkenward@nortelnetworks.com, tmima@cisco.com, mccap@research.bell-labs.com, kempf@heliopolis.Eng.Sun.COM, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Mon, 9 Apr 2001 22:04:32 -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: > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Friday, April 06, 2001 5:15 PM > To: khiem.le@nokia.com > Cc: rajeev.koodli@nokia.com; mat@cisco.com; > gkenward@nortelnetworks.com; > tmima@cisco.com; mccap@research.bell-labs.com; > kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > rohc@cdt.luth.se; seamoby@diameter.org > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile > IPv6 Handover > > > > Kheim, > > I sorry to be so argumentative here, but I'm sure I > could come up with a long laundry list of the benefits > of quantum teleportation too. What obviously must be > done beyond wanting such a thing is to see: > > o if it can be done at all > o whether it would still be a benefit once we > had done it. > > For example, if we could do quantum teleportation > but the only way we could figure out how to > teleport a person resulted in them dying, I'm sure > you'd agree that we ought to reevaluate the > benefits. > > All I'm asking here is how CT would interact with > FMIP. I believe that FMIP is very likely to be a > very important part of handoffs and as such, I > would like to know whether CT for header > compression state will help, hinder or be of no > benefit at all. From what I can tell, there is > indeed a problem and it is not clear whether there > is a solution, or whether the solution would be > worse than the original problem given the high > likelihood of race conditions, etc. Just becuase it doesn't work for FMIP does not mean we should stop. If it doesn't work for FMIP then change FMIP. - Kulwinder. > > Mike > > khiem.le@nokia.com writes: > > Hi, > > > > I have been too busy to comment on all these mails, but I > just want to say a > > couple of things. > > > > I'm afraid that it > > > is your place to prove that context transfer > > > of header compression state in the face of all > > > of these extenuating circumstances is still > > > worthwhile. > > > > There have been many mails pointing out the merit of doing header > > compression context transfer. To repeat them: > > continued, seamless compression/decompression, higher compression > > efficiency, and minimization of degradation on the user > media. This last > > point is the most important in my mind. At this stage, the > link technologies > > where header compression is going to be used are primarily > cellular links. > > In the cellular environment, handoffs (or handovers) are > events that happen > > in normal operation, and therefore a very significant > design effort is spent > > to minimize the impact of HO on performance. In > particular, one wants to > > minimize the duration of the break. If brute force header > compression > > reinitialization is done, one would have to send a certain > number of 40-60 > > byte or more IR headers, instead of the usual 1 byte > header. This big > > bandwidth demand surge will put a strain on the link. Some > links will cope > > with it by blanking out the user data to make room to > carry the IR headers. > > When such blanking takes place, the user media (voice, > etc.) will be > > unavoidably affected. The impairment caused by the handoff > is thus extended, > > compared to the case where header compression is not present. > > > > In the current and 3G cellular technologies, the break is > about 100-150 > > msec, without header compression. This already translates > into the loss of > > 5-6 20 msec packets. If some IR headers have to be sent by > blanking out the > > user data, the break will be significantly longer. For > example, if 3 (an > > optimistic value) IR headers are sent, the resulting break > is increased to > > 8-9 packets worth. > > > > I also want to point out that minimization of the break > will help in > > futureproofness. Applications that will be introduced in > the future may be > > even more sensitive to the break (or the threshold for > user perceived > > degradation may be lower) than the currently known ones. > For example, if a > > packet is generated every 10 msec, the number of packets > affected will be > > doubled. > > > > The only way to minimize the break is to do header > compression context > > transfer. > > > > > > Khiem > > > -----Original Message----- > > > From: Koodli Rajeev (NRC/MtView) > > > Sent: Friday, April 06, 2001 1:13 PM > > > To: 'ext Michael Thomas'; Koodli Rajeev (NRC/MtView) > > > Cc: Le Khiem (NRC/Dallas); gkenward@nortelnetworks.com; > > > tmima@cisco.com; > > > mccap@research.bell-labs.com; kempf@heliopolis.Eng.Sun.COM; > > > mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se; > seamoby@diameter.org > > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting > Compressor on Mobile > > > IPv6 Handover > > > > > > > > > > > > > > > > > > rajeev.koodli@nokia.com writes: > > > > > > From: ext Michael Thomas [mailto:mat@cisco.com] > > > > > > > > > > Can somebody explain to me how this has any > > > > > > possible applicability if you are using FMIP > > > > > > during the transition? FMIP requires a new tunnel > > > > > > for which there will be no compression state in > > > > > > the old access router. > > > > > > > > > > > > > > > > If there is no compression state at the old router, why > > > > would you try to > > > > > relocate it ? > > > > > > > > There's compression state there, but not the > > > > compression state that matters: when I'm > > > > receiving packets from the old AR during the > > > > FMIP transition time, there will be a *new* > > > > IP header appended toward the MN. This is > > > > because those packets will have to be tunneled to the > > > > MN. This means that it is a *new* compression > > > > context, not an old existing one. > > > > > > > I don't have sufficient details to comment.. > > > > > > > > > All of these interactions with MIP, FMIP, HMIP > > > > > > etc, etc make it look to me like this is a losing > > > > > > situation. It may be the better part of valor to > > > > > > say that fast/smooth handoffs are inherently more > > > > > > bandwidth consumptive and that one of the > > > > > > casualties is header compression state in the mean > > > > > > time. > > > > > > > > > > Can you justify your claim above ? > > > > > > > > I can't prove negatives. I'm afraid that it > > > > is your place to prove that context transfer > > > > of header compression state in the face of all > > > > of these extenuating circumstances is still > > > > worthwhile. > > > > > > > > > > You can't justify your claims. So, before you raise issues > > > (related/unrelated), try to make an effort to understand the > > > work done by others. > > > > > > As far as I am concerned, how about all the e-mail discussion > > > during the last two weeks ? Please take a look! > > > > > > > > >Trying to extend a point to point L2 > > > > > > compression mechanism across an arbitrary internet > > > > > > is just *bizzare*. L2TP is bad enough. > > > > > > > > > > > > > > > > You are compressing IP and transport headers! This should > > > > work on ANY link. > > > > > That's why you try to CT header compression state. Get it ? > > > > > > > > Oh sure, I get it... I "get" VoMPLS too, but > > > > that doesn't make it any less bizarre. > > > > > > > > > > If you got it, you would probably re-think! If you were to > > > re-think and understand the issues, you would probably > > > question yourself what's bizarre, and then write. > > > > > > -Rajeev > > > > > > > Mike > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 11 12:40: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 MAA28262 for ; Wed, 11 Apr 2001 12:40: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 JAA15587; Wed, 11 Apr 2001 09:39:59 -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 JAA22924; Wed, 11 Apr 2001 09:39:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BGc0K9016516 for ; Wed, 11 Apr 2001 09:38:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3BGc0rX016515 for mobile-ip-dist; Wed, 11 Apr 2001 09:38: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BGbpK9016508 for ; Wed, 11 Apr 2001 09:37:51 -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 JAA18624 for ; Wed, 11 Apr 2001 09:37:51 -0700 (PDT) Received: from comis.kaist.ac.kr.kaist.ac.kr (comis.kaist.ac.kr [143.248.146.14]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA05754 for ; Wed, 11 Apr 2001 10:44:11 -0600 (MDT) Received: from ggumdol (liszt.kaist.ac.kr [143.248.146.41]) by comis.kaist.ac.kr.kaist.ac.kr (8.9.3+Sun/8.9.3) with SMTP id BAA10751 for ; Thu, 12 Apr 2001 01:38:21 +0900 (KST) Message-ID: <002101c0c2a5$959a3e80$2992f88f@ggumdol> From: "Jeong-woo Cho" To: Subject: [mobile-ip] Please Help Me. Date: Thu, 12 Apr 2001 01:36:39 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001E_01C0C2F1.0561DB60" 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: This is a multi-part message in MIME format. ------=_NextPart_000_001E_01C0C2F1.0561DB60 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 DQoNCiBIb3cgY2FuIEkgdW5zdWJzY3JpYmUgdGhpcyBtYWlsaW5nIGxpc3Q/DQoNCiBQbGVhc2Ug bGV0IG1lIGtub3cuDQoNCiBUaGFua3MgaW4gYWR2YW5jZS4NCg0KDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQog Q2hvLCBKZW9uZy13b28NCiANCiBDb21tdW5pY2F0aW9uIGFuZCBJbmZvcm1hdGlvbiBTeXN0ZW1z IExhYm9yYXRvcnkNCiBEZXB0LiBvZiBFbGVjdHJpY2FsIEVuZ2luZWVyaW5nIGFuZCBDb21wdXRl ciBTY2llbmNlDQogS29yZWEgQWR2YW5jZWQgSW5zdGl0dXRlIG9mIFNjaWVuY2UgYW5kIFRlY2hu b2xvZ3koS0FJU1QpDQogMzczLTEgS3Vzb25nLWRvbmcsIFl1c29uZy1ndSwgVGFlam9uIDMwNS03 MDEsIEtPUkVBDQogDQogVEVMOiAtODItNDItODY5LTgwNjcgKGV4LjEwNykgRkFYOiAtODItNDIt ODY3LTA1NTANCiBFLW1haWw6IGdndW1kb2xAY29taXMua2Fpc3QuYWMua3INCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCg0KDQo= ------=_NextPart_000_001E_01C0C2F1.0561DB60 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjUwLjQ1MjIuMTgwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4m bmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+ PEZPTlQgc2l6ZT0yPiZuYnNwO0hvdyBjYW4gSSB1bnN1YnNjcmliZSB0aGlzIG1haWxpbmcgbGlz dD88L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8 RElWPjxGT05UIHNpemU9Mj4mbmJzcDtQbGVhc2UgbGV0IG1lIGtub3cuPC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+ Jm5ic3A7VGhhbmtzIGluIGFkdmFuY2UuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4N CjxESVY+PEJSPjxGT05UIA0Kc2l6ZT0yPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08QlI+Jm5ic3A7Q2hvLCANCkpl b25nLXdvbzxCUj4mbmJzcDs8QlI+Jm5ic3A7Q29tbXVuaWNhdGlvbiBhbmQgSW5mb3JtYXRpb24g U3lzdGVtcyANCkxhYm9yYXRvcnk8QlI+Jm5ic3A7RGVwdC4gb2YgRWxlY3RyaWNhbCBFbmdpbmVl cmluZyBhbmQgQ29tcHV0ZXIgDQpTY2llbmNlPEJSPiZuYnNwO0tvcmVhIEFkdmFuY2VkIEluc3Rp dHV0ZSBvZiBTY2llbmNlIGFuZCANClRlY2hub2xvZ3koS0FJU1QpPEJSPiZuYnNwOzM3My0xIEt1 c29uZy1kb25nLCBZdXNvbmctZ3UsIFRhZWpvbiAzMDUtNzAxLCANCktPUkVBPEJSPiZuYnNwOzxC Uj4mbmJzcDtURUw6IC04Mi00Mi04NjktODA2NyAoZXguMTA3KSBGQVg6IA0KLTgyLTQyLTg2Ny0w NTUwPEJSPiZuYnNwO0UtbWFpbDogPC9GT05UPjxBIA0KaHJlZj0ibWFpbHRvOmdndW1kb2xAY29t aXMua2Fpc3QuYWMua3IiPjxGT05UIA0Kc2l6ZT0yPmdndW1kb2xAY29taXMua2Fpc3QuYWMua3I8 L0ZPTlQ+PC9BPjxCUj48Rk9OVCANCnNpemU9Mj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj48 L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_001E_01C0C2F1.0561DB60-- From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 11 12:50:59 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28628 for ; Wed, 11 Apr 2001 12:50:58 -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 JAA04925; Wed, 11 Apr 2001 09:47:00 -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 JAA18858; Wed, 11 Apr 2001 09:46:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BGibK9016556 for ; Wed, 11 Apr 2001 09:44:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3BGibth016555 for mobile-ip-dist; Wed, 11 Apr 2001 09: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 eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BGiWK9016548 for ; Wed, 11 Apr 2001 09:44:33 -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 MAA13371 for ; Wed, 11 Apr 2001 12:44:33 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id MAA22846 for mobile-ip@sunroof.eng.sun.com; Wed, 11 Apr 2001 12:44:42 -0400 (EDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3A8WXK9013047 for ; Tue, 10 Apr 2001 01:32: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 BAA24784 for ; Tue, 10 Apr 2001 01:32:33 -0700 (PDT) Received: from exchange01.iirltd.co.uk (groupwise.iirltd.co.uk [193.133.64.177]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA23642 for ; Tue, 10 Apr 2001 01:32:32 -0700 (PDT) Received: by EXCHANGE01 with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Apr 2001 09:31:34 +0100 Message-ID: From: Claire Tranah To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] 4G Mobile - Call for Papers Date: Tue, 10 Apr 2001 09:31:24 +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: We are now accepting abstracts for THE PATH TO 4G MOBILE 14th-15th September, Helsinki. The intellectual content of the event is being overseen by a scientific committee of prominent personalities in the 4G world details of which can be found at www.4gnetworks.net. Further details on the event can be found on the website or by contacting ctranah@iir-conferences.com directly. Deadline for abstracts is 20th April. Please feel free to forward this to any of your colleagues working in this area who you think might be interested in participating. Please do not hesitate to contact me should you have any further questions. Looking forward to receiving your abstract. Claire Tranah Conference Producer - IIR Telecoms ctranah@iir-conferences.com From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 11 12:56: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 MAA28760 for ; Wed, 11 Apr 2001 12:56:52 -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 JAA00945; Wed, 11 Apr 2001 09:56: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 JAA27153; Wed, 11 Apr 2001 09:55:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BGrRK9016601 for ; Wed, 11 Apr 2001 09:53:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3BGrQI2016600 for mobile-ip-dist; Wed, 11 Apr 2001 09:53: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BGrGK9016593 for ; Wed, 11 Apr 2001 09:53:16 -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 JAA21089 for ; Wed, 11 Apr 2001 09:53:17 -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 JAA09054 for ; Wed, 11 Apr 2001 09:53:16 -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 SAA03084 for ; Wed, 11 Apr 2001 18:52:54 +0200 (MEST) Message-ID: <3AD48BC4.DD9A8B18@inrialpes.fr> Date: Wed, 11 Apr 2001 18:52:21 +0200 From: Thierry Ernst Organization: INRIA Rhone-Alpes 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] Please Help Me. References: <002101c0c2a5$959a3e80$2992f88f@ggumdol> 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, Go on the Mobile IP WG web page, all details are provided: http://www.ietf.org/html.charters/mobileip-charter.html 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 Apr 11 12:58:38 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28788 for ; Wed, 11 Apr 2001 12:58:37 -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 JAA08703; Wed, 11 Apr 2001 09:54: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 JAA22660; Wed, 11 Apr 2001 09:53:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BGq9K9016588 for ; Wed, 11 Apr 2001 09:52:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3BGq9ho016587 for mobile-ip-dist; Wed, 11 Apr 2001 09:52: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 eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BGpxK9016580 for ; Wed, 11 Apr 2001 09:51:59 -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 MAA14569 for ; Wed, 11 Apr 2001 12:51:59 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id MAA22971 for mobile-ip@sunroof.eng.sun.com; Wed, 11 Apr 2001 12:52:09 -0400 (EDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3ADMTK9013606 for ; Tue, 10 Apr 2001 06:22:29 -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 GAA24469 for ; Tue, 10 Apr 2001 06:22:30 -0700 (PDT) Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA23806 for ; Tue, 10 Apr 2001 06:22:29 -0700 (PDT) Received: from zrchh190 by smtprch2.nortel.com; Tue, 10 Apr 2001 08:07:44 -0500 Received: from marvin.corpeast.baynetworks.com by zrchh190; Tue, 10 Apr 2001 08:12:58 -0500 Received: from zrtps06t.us.nortel.com (zrtps06t.us.nortel.com [47.140.48.51]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id JAA09703 for ; Tue, 10 Apr 2001 09:12:50 -0400 (EDT) Received: from 47.234.0.32 (actually ertpsms2.internet.nortel.com) by zrtps06t; Tue, 10 Apr 2001 09:11:45 -0400 Received: from by.genie.uottawa.ca ( [137.122.20.226]) by with SMTP (MailShield v1.5); Tue, 10 Apr 2001 09:13:49 -0400 Received: from mobstar ([137.122.107.157]) by by.genie.uottawa.ca (8.9.1/8.9.1) with SMTP id HAA00181; Tue, 10 Apr 2001 07:52:00 -0400 (EDT) From: Ahmed Karmouch To: karmouch Subject: [mobile-ip] IEEE/ACM Workshop on Mobile Software Agents- MATA 2001-Extended Deadline-April 16. Date: Mon, 9 Apr 2001 22:43:53 -0400 Message-ID: <001f01c0ad2a$7563cb80$9d6b7a89@uottawa.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-UIDL: ae345eaa9c07da9d4d3b9ea7fdaf9c90 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-MIME-Autoconverted: from 8bit to quoted-printable by by.genie.uottawa.ca id HAA00181 X-SMTP-HELO: by.genie.uottawa.ca X-SMTP-MAIL-FROM: Karmouch@site.uottawa.ca X-SMTP-RCPT-TO: payam@nortelnetworks.com,nseddigh@nortelnetworks.com,mobile-ip@standards.nortelnetworks.com X-SMTP-PEER-INFO: [137.122.20.226] X-Orig: X-Orig: X-Orig: X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f3ADMUK9013608 Sender: owner-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 JAA08703 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA28788 [My apologies if you receive this more than once] ====================================================== MATA'2001 Third International Workshop on Mobile Agents for Telecommunication Applications August 14-16, 2001, Montréal, CANADA Co-sponsored by IEEE and ACM http://www.congresbcu.com/mata01/ CALL FOR PAPERS ================ Technical papers (4500 words maximum) describing previously unpublished, completed research or work in progress, not currently under review by another journal or conference, are solicited on the following topics: Mobile Agent Architecture and Models Agent Identification, Tracking and Persistence Agent-based Mobility Management in Mobile Networks Web Agent Systems Agent Integration with CORBA and TINA Active Networks and Mobile Agents Feature Interaction and Agents Mobile Agents Communication Language Security in Mobile Agent Systems Interactive Multimedia Presentation Agents Agent-based Electronic Commerce Agent-based Access to Legacy Services Managing QoS with agents Information Discovery and Gathering using agents Data Mining Agents Network Management Agents Policy-based Management using Mobile Agents Education and Applications of Mobile Agents Prototypes and Experience with Mobile Agents Seamless Messaging and Mobile Agents Accepted papers will be published in the conference proceedings. Papers of particular merit will be proposed for publication in IEEE Network Magazine. All paper submissions should have a cover page containing the title, names, email address and complete postal addresses (including telephone and fax numbers) for all authors. Please indicate the main author for the purpose of correspondence. The cover page should also provide an abstract (150 words maximum), and a list of keywords. Please include a statement stating that "when accepted, one of the authors will attend the Workshop to present the paper". Submissions should be sent by email to the program chair: Roch Glitho Ericcson Research Canada 8400, boul. Décarie Ville Mont-Royal, Québec, Canada, H4P 2N2 email: roch.glitho@lmc.ericsson.se Tel.: (514) 345-7000 ext. 2266 IMPORTANT DATES FOR PAPER SUBMISSION Full paper submission due April 16, 2001 Notification of acceptance May 15, 2001 Final paper due June 15, 2001 ======================================= From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 11 13:28:06 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA29388 for ; Wed, 11 Apr 2001 13:28:06 -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 KAA25267; Wed, 11 Apr 2001 10:22: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 KAA04459; Wed, 11 Apr 2001 10:23:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BHLTK9016975 for ; Wed, 11 Apr 2001 10:21:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3BHLTG0016974 for mobile-ip-dist; Wed, 11 Apr 2001 10:21: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BHLKK9016967 for ; Wed, 11 Apr 2001 10:21: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 KAA01072 for ; Wed, 11 Apr 2001 10:21:20 -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 LAA05274 for ; Wed, 11 Apr 2001 11:27:42 -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 KAA06964; Wed, 11 Apr 2001 10:21:18 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3BHLGR00914; Wed, 11 Apr 2001 10:21:16 -0700 X-mProtect: Wed, 11 Apr 2001 10:21:16 -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(WTS.12.69) smtpdmKsohg; Wed, 11 Apr 2001 10:21:05 PDT Message-ID: <3AD49283.AFDBFB53@iprg.nokia.com> Date: Wed, 11 Apr 2001 10:21:07 -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: "Shahrier, Sharif M." CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] some issues with IPv6 mobility draft (sharif) 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, comments below "Shahrier, Sharif M." wrote: > > > Wrong again!! the A's Home agent does not respond to the > binding request. the binding request is tunneled to A > and A responds with a BU. > > I think there is a mis-understanding here. You are correct in > stating that the Binding Request is sent to MN A, and it > Replies with a Binding Update. These messages are generally > exchanged when B's Binding Cache entry is close to > Expiration of its lifetime, and the messages are "piggybacked". > > Thus, I can see that you are familiar with section 8.6 of the draft. > > However, the draft does not deal with the problem I had pointed out. I was > merely pointing out a possible "extension" to the draft to deal with the > problem; by sending Binding Request to the HA after it receives the > ICMP message. This is not currently in the draft. > > Of course, B cannot send a Binding Request to A, which is what you are > saying, because it doesn't know the location of A !! That is the root of the > problem !! > No. B's sends a binding request the home address of A, which gets tunneled to A by A's Home Agent. A responds with a new binding update. there is no need for the Home Agent to respond to the binding request. Please understand this - you use a MN's home address when you dont have a binding cache entry for the MN. and Binding request - Binding Update exchange can be done any time. not just when the binding cache entry is about to expire. and when you delete a binding cache entry due to ICMP unreachable messages, you would send a binding request to the MN's home address. or you should just use triangle routing by sending all packets to MN's home address. > > > > During the step above, A sends a Binding Update to its home agent, > receives > > Acknowledgement, A moves to its new COA. B sends datagram to A's previous > > COA; A is not there; B is sent ICMP; Process continues forever..... > > > > A possible solution to prevent this "looping" effect is to keep caching > A's > > new binding at its previous COA. The previous COA can use the binding to > > forward packets to A. > > > > This is already there in the base mobile ipv6. the previous > access router to which the A was connected to forwards > packets to A's new location. this is set up by A sending a > BU to its previous access router binding its new CoA and > old CoA. > > Yes, but please read my next paragraph. This method is not robust, and will > not work if the previous access router fails or is reconfigured. > I am not aware of any existing solutions that was handle this > scanario. Do you? > > > But this method will also fail if one of the "previous" agents caching the > > COA's fails or is reconfigured ........ > > > > Thus, I prefer my previously posted "solution", in just using the HA > > approach because: > > > > whatever you have described till now is based on lot of things > failing. you also assume that the MN is handing off faster than > the round trip time to the CN. > > No, there are a number of possibilities. One of them is that the > communication between HA and CN is slower than > HA and MN, because of congestion. There are many other cases. > > and your solution of the home agent maintaining the binding update > list is not worthy of any consideration. stop this thread on the > mailing list. lets go offline. i can explain things in more detail > there... > > You are welcome in your comments. However: > > * You have not provided an alternative, strong, robust solution to the > problem I indicated. i dont see a problem. > * You have not given a good reason why using just "HA signaling" is a bad > idea. well one easy answer is that the Home agent does not have a security association with the CN. so it cannot do your "HA signaling" vijay From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 11 14:13:40 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00330 for ; Wed, 11 Apr 2001 14:13:40 -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 LAA21109; Wed, 11 Apr 2001 11:11: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 LAA13125; Wed, 11 Apr 2001 11:12:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BIASK9017059 for ; Wed, 11 Apr 2001 11:10:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3BIASmU017058 for mobile-ip-dist; Wed, 11 Apr 2001 11:10: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BIAJK9017051 for ; Wed, 11 Apr 2001 11:10:19 -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 LAA16043 for ; Wed, 11 Apr 2001 11:10:19 -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 LAA23708 for ; Wed, 11 Apr 2001 11:10:18 -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 UAA04343; Wed, 11 Apr 2001 20:09:55 +0200 (MEST) Message-ID: <3AD49DD1.1684173D@inrialpes.fr> Date: Wed, 11 Apr 2001 20:09:21 +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, hipsec@mail.freeswan.org Subject: [mobile-ip] -New ID about Address owernship- Content-Type: multipart/alternative; boundary="------------44C26F0F35C3BD3CB1EE363C" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------44C26F0F35C3BD3CB1EE363C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, We have just submitted a new draft that addresses the address owernship (and the redirection authorization) problem of Mobile IPv6 using a "HIP based solution"..... This draft is available at: http://www.inrialpes.fr/planete/people/ccastel/draft-montenegro-sucv-00.txt thanks in advance for your comments, regards, Claude. Abstract This document addresses the identifier ownership problem. It does so by using characteristics of Statistic Uniqueness and Cryptographic Verifiability (SUCV) of certain entities which this document calls SUCV Identifiers (SUCV ID's). This note also proposes using these SUCV characteristics in related entities called SUCV Addresses in order to severely limit certain classes of denial of service attacks and hijacking attacks. SUCV addresses are particularly applicable to solve the 'address ownership' problem that severely undermines confidence in mechanisms like Binding Updates in Mobile IP for IPv6. -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------44C26F0F35C3BD3CB1EE363C Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello,

We have just submitted a new draft that addresses the address owernship
(and the redirection authorization) problem of Mobile IPv6 using a "HIP based solution".....

This draft is available at:
http://www.inrialpes.fr/planete/people/ccastel/draft-montenegro-sucv-00.txt
 

thanks in advance for your comments,
regards,
Claude.

Abstract
   This document addresses the identifier ownership problem.  It
   does so by using characteristics of Statistic Uniqueness and
   Cryptographic Verifiability (SUCV) of certain entities which
   this document calls SUCV Identifiers (SUCV ID's).  This note
   also proposes using these SUCV characteristics in related
   entities called SUCV Addresses in order to severely limit
   certain classes of denial of service attacks and hijacking
   attacks. SUCV addresses are particularly applicable to solve the
   'address ownership' problem that severely undermines confidence
   in mechanisms like Binding Updates in Mobile IP for IPv6. 

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  --------------44C26F0F35C3BD3CB1EE363C-- From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 11 15:03: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 PAA01185 for ; Wed, 11 Apr 2001 15:03: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 MAA20476; Wed, 11 Apr 2001 12:02:22 -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 MAA06113; Wed, 11 Apr 2001 12:02:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BIxuK9017133 for ; Wed, 11 Apr 2001 11:59:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3BIxtKt017132 for mobile-ip-dist; Wed, 11 Apr 2001 11:59:55 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BIxiK9017125 for ; Wed, 11 Apr 2001 11:59:45 -0700 (PDT) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA02380; Wed, 11 Apr 2001 11:59:44 -0700 (PDT) Received: from nasnfs.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id LAA18435; Wed, 11 Apr 2001 11:59:19 -0700 (PDT) From: Patrice Calhoun Message-Id: <200104111859.LAA18435@nasnfs.Eng.Sun.COM> Date: Wed, 11 Apr 2001 14:55:02 -0700 To: Cc: Subject: [mobile-ip] Proposed changes to draft-ietf-mobileip-aaa-key-04.txt 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 All, 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) So, since the mobile knows its secret with the AAAH, and its NAI, if it receives the random value it could derive the key. This means that no encrypted key is ever sent over the air and is more secure. Does anyone have *any* objections to making such a change? PatC From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 11 15:03: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 PAA01196 for ; Wed, 11 Apr 2001 15:03: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 MAA21072; Wed, 11 Apr 2001 12:03:00 -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 MAA04889; Wed, 11 Apr 2001 12:02:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BJ0UK9017143 for ; Wed, 11 Apr 2001 12:00:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3BJ0TVA017142 for mobile-ip-dist; Wed, 11 Apr 2001 12:00: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BJ0IK9017135 for ; Wed, 11 Apr 2001 12:00:18 -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 MAA05214 for ; Wed, 11 Apr 2001 12:00:18 -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 NAA08727 for ; Wed, 11 Apr 2001 13:06:53 -0600 (MDT) Received: from ws34.nomadiclab.com (ws34.nomadiclab.com [195.165.196.34]) by ws130.nomadiclab.com (Postfix) with ESMTP id 395BB72503; Wed, 11 Apr 2001 22:00:15 +0300 (EEST) Received: from nomadiclab.com (localhost [127.0.0.1]) by ws34.nomadiclab.com (Postfix) with ESMTP id 52E3BBA0B; Wed, 11 Apr 2001 22:00:14 +0300 (EEST) Message-ID: <3AD4AB4A.52FE660D@nomadiclab.com> Date: Wed, 11 Apr 2001 22:06:50 +0300 From: Pekka Nikander X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,fi MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Cc: hipsec@mail.freeswan.org Subject: Re: [mobile-ip] -New ID about Address owernship- References: <3AD49DD1.1684173D@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 Claude, > http://www.inrialpes.fr/planete/people/ccastel/draft-montenegro-sucv-00.txt > This document addresses the identifier ownership problem. It > does so by using characteristics of Statistic Uniqueness and > Cryptographic Verifiability (SUCV) of certain entities which > this document calls SUCV Identifiers (SUCV ID's).... Basically similar solutions have been coined already a few times so far. First, Greg O'Shea and Michael Rose came to the same solution last summer, and their work is now being published at this month's ACM CCR. They call their solution Child-Proorf Authentication for MIPv6 (CAM). (I learned about their work yesterday.) Second, I came (independently) to the same solution in February this year, and then went a little bit further than Greg and Mike went. I still haven't had time to publish my results, but an informal not-quite-ready draft has been available since Minneapolis at http://www.tml.hut.fi/~pnr/publications/draft-nikander-ipng-pbk-addresses-00.txt Furthermore, Gabriel Montenegro says that he's came to the same result as well, but I haven't seen him putting his version of the idea into a form where you could easily read it. I think it might be worth to see if we could join our efforts. What do you think? --Pekka From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 11 15:28:07 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01588 for ; Wed, 11 Apr 2001 15:28:07 -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 MAA27730; Wed, 11 Apr 2001 12:26: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 MAA11324; Wed, 11 Apr 2001 12:27:28 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BJPvK9017255 for ; Wed, 11 Apr 2001 12:25:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3BJPvDT017254 for mobile-ip-dist; Wed, 11 Apr 2001 12:25: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BJPmK9017247 for ; Wed, 11 Apr 2001 12:25:48 -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 MAA10961 for ; Wed, 11 Apr 2001 12:25:48 -0700 (PDT) Received: from newman.frascone.com (frascone.com [216.62.83.25]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id NAA23313 for ; Wed, 11 Apr 2001 13:32:26 -0600 (MDT) Received: (qmail 9735 invoked by uid 500); 11 Apr 2001 19:25:46 -0000 Date: Wed, 11 Apr 2001 14:25:46 -0500 From: David Frascone To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Proposed changes to draft-ietf-mobileip-aaa-key-04.txt Message-ID: <20010411142546.J14053@newman.frascone.com> References: <200104111859.LAA18435@nasnfs.Eng.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104111859.LAA18435@nasnfs.Eng.Sun.COM>; from pcalhoun@nasnfs.Eng.Sun.COM on Wed, Apr 11, 2001 at 02:55:02PM -0700 X-encrypt-payload: no Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: So, the keys would be the 16 byte MD5 hash? I can live with that. On Wed, Apr 11, 2001 at 02:55:02PM -0700, Patrice Calhoun wrote: > All, > > 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) > > So, since the mobile knows its secret with the AAAH, and its NAI, if it > receives the random value it could derive the key. This means that no encrypted > key is ever sent over the air and is more secure. > > Does anyone have *any* objections to making such a change? > > PatC > From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 11 15:48:18 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01839 for ; Wed, 11 Apr 2001 15:48:18 -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 MAA06502; Wed, 11 Apr 2001 12:45: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 MAA09074; Wed, 11 Apr 2001 12:47:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BJigK9017302 for ; Wed, 11 Apr 2001 12:44:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3BJifKJ017301 for mobile-ip-dist; Wed, 11 Apr 2001 12:44: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BJiWK9017294 for ; Wed, 11 Apr 2001 12:44: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 MAA17767 for ; Wed, 11 Apr 2001 12:44:21 -0700 (PDT) Received: from htt-consult.com (homebase.htt-consult.com [65.84.78.210]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id NAA02594 for ; Wed, 11 Apr 2001 13:51:31 -0600 (MDT) Received: from rgm.htt-consult.com ([65.84.78.214]) by htt-consult.com ; Wed, 11 Apr 2001 15:45:27 -0400 Message-Id: <5.0.0.25.2.20010411154003.03229010@localhost> X-Sender: rgm-ietf@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 11 Apr 2001 15:41:43 -0400 To: mobile-ip@sunroof.eng.sun.com From: Robert Moskowitz Subject: Re: [mobile-ip] -New ID about Address owernship- Cc: hipsec@mail.freeswan.org In-Reply-To: <3AD4AB4A.52FE660D@nomadiclab.com> References: <3AD49DD1.1684173D@inrialpes.fr> 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 10:06 PM 4/11/2001 +0300, Pekka Nikander wrote: >Claude, > > > http://www.inrialpes.fr/planete/people/ccastel/draft-montenegro-sucv-00.txt > > >Furthermore, Gabriel Montenegro says that he's came to the same result >as well, but I haven't seen him putting his version of the idea into >a form where you could easily read it. check the author name in the draft. This IS Gabriel's ideas. He and I discussed this at IETF. From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 11 16:34:21 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02873 for ; Wed, 11 Apr 2001 16:34:21 -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 NAA22680; Wed, 11 Apr 2001 13:22: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 NAA21749; Wed, 11 Apr 2001 13:23:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BKLYK9017370 for ; Wed, 11 Apr 2001 13:21:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3BKLX5U017369 for mobile-ip-dist; Wed, 11 Apr 2001 13:21: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BKLOK9017362 for ; Wed, 11 Apr 2001 13:21:24 -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 NAA26009 for ; Wed, 11 Apr 2001 13:21:19 -0700 (PDT) Received: from zrtps06u.us.nortel.com (h52s48a140n47.user.nortelnetworks.com [47.140.48.52]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA05171 for ; Wed, 11 Apr 2001 13:21:17 -0700 (PDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with ESMTP id f3BKJqq26376 for ; Wed, 11 Apr 2001 16:19:52 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 11 Apr 2001 16:20:54 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 11 Apr 2001 16:20:56 -0400 Message-ID: From: "Muhammad Jaseemuddin" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents Date: Wed, 11 Apr 2001 16:20:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C2C4.E84CF4F0" 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_01C0C2C4.E84CF4F0 Content-Type: text/plain Phil: Route optimization does not fully optimize the route in case of any form of regional registration. e.g. HMIPv6. For example if the CN is outside the domain, then the packets will follow the optimized path upto the local mobility anchor point (MAP), and then follow the optimal path to the mobile. If the MAP is not co-located with the border routers, then the scheme does not use optimal route from the border routers to the mobile. This situation becomes more conspicous if the CN is another mobile within the domain but necessarily on the same subnet as the the subnet on which the mobile's AR is connected. One can argue that in that case MN should send BU to CN with its LCOA if it (somehow) discovers that the CN is actually a mobile in the same domain. Then, intra-MAP domain signaling will be increased and the benefit of MAP will be less obvious. What I interepreted from Hongyi's requirement 10 is to address the above issue? Cheers, - Muhammad Jaseemuddin > -----Original Message----- > From: Phil Roberts [SMTP:PRoberts@MEGISTO.com] > Sent: Tuesday, April 10, 2001 10:35 AM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying > requirem ents > > Hi, > > I'm a little confused about your req 10. MIP v6 already has route > optimization. Do you envision req 10 to provide an alternative to that or > to interoperate with that or ... something else? > > Thanks, > Phil > > > -----Original Message----- > From: Hongyi Li [mailto:hyli@nortelnetworks.com] > Sent: Tuesday, April 10, 2001 10:21 AM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying > requirem ents > > > > Hi Phil, > Here are few more requirements I think that are impportant for > RR/LMM (I like > the term localized mobility management too): > > 10) LMM SHALL provide optimized routing for mobile-to-mobile > communication. > 11) LMM SHOULD minimize the number of network nodes affected by > handoff signals. > 12) LMM SHOULD support auto-configuration capabilities for mobile > agents/FAs, access routers. > 13) LMM SHOULD simplify the network design and provisioning for > enabling LMM > capability in a network and allow progressive LMM deployment > capabilities. > > Some more comments in lines: > > > 1) Regional registration shall be introduced to minimize the > signaling > > traffic to the home agent or correspondent nodes for > > intra-domain mobility > > 2) Regional registration shall not introduce new overhead on > > links between > > the mobile and the regional registration agents > > 3) Connectivity to the mobiles shall not be interrupted in > > the presence of > > the failure of regional registration agents > > 4) Regional registration shall scale to support millions of nodes > in a > > visited network > > LMM SHALL be scalable in terms of number of connected users (i.e., > active + dormant = millions) and the number of users on the move. > > > 5) Regional registration shall be secure against malicious > > behavior from > > visiting mobiles > > 6) Regional registration shall allow multiple levels of hierarchy > > 7) Regional registration shall support fast handoffs > > 8) Regional registration shall not require changes to the > > mobile node, the > > home agent, or correspondent nodes > > 9) Regional registration shall not introduce host routes in > > routing tables > > I agree with Theo comments about host route. The LMM SHOULD minimize > the amount of host routes in the routers. > > - Hongyi > ------_=_NextPart_001_01C0C2C4.E84CF4F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] IPv6 Regional Registration - identifying = requirem ents

Phil:

 Route = optimization does not fully optimize the route in case of any form of = regional registration. e.g. HMIPv6. For example if the CN is outside = the domain, then the packets will follow the optimized path upto the = local mobility anchor point (MAP), and then follow the optimal path to = the mobile. If the MAP is not co-located with the border routers, then = the scheme does not use optimal route from the border routers to the = mobile. This situation becomes more conspicous if the CN is another = mobile within the domain but necessarily on the same subnet as the the = subnet on which the mobile's AR is connected. One can argue that in = that case MN should send BU to CN with its LCOA if it (somehow) = discovers that the CN is actually a mobile in the same domain. Then, = intra-MAP domain signaling will be increased and the benefit of MAP = will be less obvious.

 What I = interepreted from Hongyi's requirement 10 is to address the above = issue?

Cheers,
- Muhammad = Jaseemuddin
 

------_=_NextPart_001_01C0C2C4.E84CF4F0-- From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 11 16:34:25 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02894 for ; Wed, 11 Apr 2001 16:34:25 -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 NAA27805; Wed, 11 Apr 2001 13:32: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 NAA28178; Wed, 11 Apr 2001 13:33:55 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BKVsK9017428 for ; Wed, 11 Apr 2001 13:31:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3BKVrMu017427 for mobile-ip-dist; Wed, 11 Apr 2001 13:31: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BKVjK9017420 for ; Wed, 11 Apr 2001 13:31: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 NAA23567 for ; Wed, 11 Apr 2001 13:31:44 -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 NAA05140 for ; Wed, 11 Apr 2001 13:31:40 -0700 (PDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Wed, 11 Apr 2001 16:26:09 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents Date: Wed, 11 Apr 2001 16:26:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C2C5.A4FA67D6" Sender: owner-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_01C0C2C5.A4FA67D6 Content-Type: text/plain; charset="iso-8859-1" Agreed. But I can't tell from the requirement what exactly is required. Is it something like "2 MNs behind the same LMA shall use an optimized route that doesn't go through the LMA?" -----Original Message----- From: Muhammad Jaseemuddin [mailto:jaseem@nortelnetworks.com] Sent: Wednesday, April 11, 2001 4:21 PM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents Phil: Route optimization does not fully optimize the route in case of any form of regional registration. e.g. HMIPv6. For example if the CN is outside the domain, then the packets will follow the optimized path upto the local mobility anchor point (MAP), and then follow the optimal path to the mobile. If the MAP is not co-located with the border routers, then the scheme does not use optimal route from the border routers to the mobile. This situation becomes more conspicous if the CN is another mobile within the domain but necessarily on the same subnet as the the subnet on which the mobile's AR is connected. One can argue that in that case MN should send BU to CN with its LCOA if it (somehow) discovers that the CN is actually a mobile in the same domain. Then, intra-MAP domain signaling will be increased and the benefit of MAP will be less obvious. What I interepreted from Hongyi's requirement 10 is to address the above issue? Cheers, - Muhammad Jaseemuddin -----Original Message----- From: Phil Roberts [SMTP:PRoberts@MEGISTO.com] Sent: Tuesday, April 10, 2001 10:35 AM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents Hi, I'm a little confused about your req 10. MIP v6 already has route optimization. Do you envision req 10 to provide an alternative to that or to interoperate with that or ... something else? Thanks, Phil -----Original Message----- From: Hongyi Li [ mailto:hyli@nortelnetworks.com ] Sent: Tuesday, April 10, 2001 10:21 AM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents Hi Phil, Here are few more requirements I think that are impportant for RR/LMM (I like the term localized mobility management too): 10) LMM SHALL provide optimized routing for mobile-to-mobile communication. 11) LMM SHOULD minimize the number of network nodes affected by handoff signals. 12) LMM SHOULD support auto-configuration capabilities for mobile agents/FAs, access routers. 13) LMM SHOULD simplify the network design and provisioning for enabling LMM capability in a network and allow progressive LMM deployment capabilities. Some more comments in lines: > 1) Regional registration shall be introduced to minimize the signaling > traffic to the home agent or correspondent nodes for > intra-domain mobility > 2) Regional registration shall not introduce new overhead on > links between > the mobile and the regional registration agents > 3) Connectivity to the mobiles shall not be interrupted in > the presence of > the failure of regional registration agents > 4) Regional registration shall scale to support millions of nodes in a > visited network LMM SHALL be scalable in terms of number of connected users (i.e., active + dormant = millions) and the number of users on the move. > 5) Regional registration shall be secure against malicious > behavior from > visiting mobiles > 6) Regional registration shall allow multiple levels of hierarchy > 7) Regional registration shall support fast handoffs > 8) Regional registration shall not require changes to the > mobile node, the > home agent, or correspondent nodes > 9) Regional registration shall not introduce host routes in > routing tables I agree with Theo comments about host route. The LMM SHOULD minimize the amount of host routes in the routers. - Hongyi ------_=_NextPart_001_01C0C2C5.A4FA67D6 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents
Agreed.   But I can't tell from the requirement what exactly is required.  Is it something like "2 MNs behind the same LMA shall use an optimized route that doesn't go through the LMA?"
 
-----Original Message-----
From: Muhammad Jaseemuddin [mailto:jaseem@nortelnetworks.com]
Sent: Wednesday, April 11, 2001 4:21 PM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents

Phil:

 Route optimization does not fully optimize the route in case of any form of regional registration. e.g. HMIPv6. For example if the CN is outside the domain, then the packets will follow the optimized path upto the local mobility anchor point (MAP), and then follow the optimal path to the mobile. If the MAP is not co-located with the border routers, then the scheme does not use optimal route from the border routers to the mobile. This situation becomes more conspicous if the CN is another mobile within the domain but necessarily on the same subnet as the the subnet on which the mobile's AR is connected. One can argue that in that case MN should send BU to CN with its LCOA if it (somehow) discovers that the CN is actually a mobile in the same domain. Then, intra-MAP domain signaling will be increased and the benefit of MAP will be less obvious.

 What I interepreted from Hongyi's requirement 10 is to address the above issue?

Cheers,
- Muhammad Jaseemuddin
 

------_=_NextPart_001_01C0C2C5.A4FA67D6-- From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 11 16:35:06 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02931 for ; Wed, 11 Apr 2001 16:35:05 -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 NAA27928; Wed, 11 Apr 2001 13:32:57 -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 NAA29323; Wed, 11 Apr 2001 13:34:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BKWXK9017448 for ; Wed, 11 Apr 2001 13:32:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3BKWW9F017447 for mobile-ip-dist; Wed, 11 Apr 2001 13:32: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BKWEK9017437 for ; Wed, 11 Apr 2001 13:32:14 -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 NAA27841; Wed, 11 Apr 2001 13:32:13 -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 NAA11414; Wed, 11 Apr 2001 13:32: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 NAA27089; Wed, 11 Apr 2001 13:32:12 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3BKWBX12120; Wed, 11 Apr 2001 13:32:11 -0700 X-mProtect: Wed, 11 Apr 2001 13:32:11 -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(WTS.12.69) smtpdy3INWP; Wed, 11 Apr 2001 13:32:07 PDT Message-ID: <3AD4BF47.99D6BE56@iprg.nokia.com> Date: Wed, 11 Apr 2001 13:32:08 -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: pcalhoun@eng.sun.com CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Proposed changes to draft-ietf-mobileip-aaa-key-04.txt References: <200104111859.LAA18435@nasnfs.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 Pat, I don't mind the change, but if the encoding is cryptographically strong, it doesn't increase the security by any appreciable amount. > 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. I reckon MD5 should be HMAC_MD5, and the input data should have the secret appended also after the random value. 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. Did anyone contribute proposed text? Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 11 16:35:32 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02948 for ; Wed, 11 Apr 2001 16:35: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 NAA28377; Wed, 11 Apr 2001 13:33: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 NAA24198; Wed, 11 Apr 2001 13:34:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BKWJK9017444 for ; Wed, 11 Apr 2001 13:32:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3BKWI4v017441 for mobile-ip-dist; Wed, 11 Apr 2001 13:32:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BKWAK9017430 for ; Wed, 11 Apr 2001 13:32:10 -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 QAA13014 for ; Wed, 11 Apr 2001 16:32:09 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id QAA28417 for mobile-ip@sunroof.eng.sun.com; Wed, 11 Apr 2001 16:32:19 -0400 (EDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BJHYK9017230 for ; Wed, 11 Apr 2001 12:17:36 -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 MAA14573 for ; Wed, 11 Apr 2001 12:17:33 -0700 (PDT) Message-Id: <200104111917.MAA14573@heliopolis.eng.sun.com> Date: Wed, 11 Apr 2001 12:17:33 -0700 (PDT) From: James Kempf Subject: [mobile-ip] test To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: nwYkOry4nHDgwzHGHYcfpw== 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: test From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 11 17:13:03 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03410 for ; Wed, 11 Apr 2001 17:13:03 -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 OAA10060; Wed, 11 Apr 2001 14:00: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 OAA25725; Wed, 11 Apr 2001 14:01:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BL0KK9017576 for ; Wed, 11 Apr 2001 14:00:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3BL0KUa017575 for mobile-ip-dist; Wed, 11 Apr 2001 14:00: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BL09K9017568 for ; Wed, 11 Apr 2001 14:00:09 -0700 (PDT) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA04799; Wed, 11 Apr 2001 14:00:09 -0700 (PDT) Received: from nasnfs.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id NAA21315; Wed, 11 Apr 2001 13:57:06 -0700 (PDT) From: Patrice Calhoun Message-Id: <200104112057.NAA21315@nasnfs.Eng.Sun.COM> Date: Wed, 11 Apr 2001 16:54:07 -0700 To: "Charles E. Perkins" Cc: Subject: Re: [mobile-ip] Proposed changes to draft-ietf-mobileip-aaa-key-04.txt 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 >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 Wed Apr 11 17:24: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 RAA03616 for ; Wed, 11 Apr 2001 17:24:58 -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 OAA05429; Wed, 11 Apr 2001 14:24: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 OAA05296; Wed, 11 Apr 2001 14:24:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BLMBK9017636 for ; Wed, 11 Apr 2001 14:22:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3BLMAT8017635 for mobile-ip-dist; Wed, 11 Apr 2001 14:22: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BLM1K9017628 for ; Wed, 11 Apr 2001 14:22:02 -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 OAA01314 for ; Wed, 11 Apr 2001 14:22:01 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA29985 for ; Wed, 11 Apr 2001 14:22:00 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f3BLLwe19902 for ; Wed, 11 Apr 2001 23:21:59 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id XAA11129 for ; Wed, 11 Apr 2001 23:21:58 +0200 (MET DST) Received: from localhost (localhost [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f3BLLwA48885 for ; Wed, 11 Apr 2001 23:21:58 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200104112121.f3BLLwA48885@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] A less drafty draft In-reply-to: Your message of Wed, 11 Apr 2001 05:04:40 CDT. <000b01c0c26e$d7f01340$6501a8c0@philneum> Date: Wed, 11 Apr 2001 23:21:58 +0200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: I had some basic questions on the less drafty draft. => can you use the standard line length? 0). WARNING: Often security holes and exploits are found in the procedures used to implement cryptographically secure algorithms, i.e. the implementation goo is the place where the holes will turn up for would be attackers. Since this less drafty draft is indeed implementation goo, it deserves extra careful attention. I believe this draft is security work and requires careful cryptanalysis. Again I must ask, is the MIP WG the most qualified WG in the IETF to perform this duty? => do you propose to create a new WG or to add a security statement in the charter? (I believe the second solution is the best one) 1). Why is forcing the malicious node onto the routing path between the CN and HA so important? => because if we restrict the places where the attacker must be we restrict possible attacks too. And as the MN can be wireless (mobile = wireless = cellular :-) this is important to reduce the vulnerabilities with the malicious guy to the MN. Is this somehow perceived to be harder for the attacker to do? => yes 3). MNs will usually be on the air. So eavesdropping on "all" the traffic between the MN and the CN does not seem like such a chore to me. => so you'd like to answer to your first point (:-)? Doesn't this put all key construction material in the hands of an attacker? => no if the HA->MN tunnel is protected and the N2 nonce not available to eavesdroppers on the MN radio link. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 11 17:27:47 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03675 for ; Wed, 11 Apr 2001 17:27:47 -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 OAA21730; Wed, 11 Apr 2001 14:25: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 OAA10927; Wed, 11 Apr 2001 14:27:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BLPmK9017662 for ; Wed, 11 Apr 2001 14:25:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3BLPmZk017661 for mobile-ip-dist; Wed, 11 Apr 2001 14:25: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 locked.eng.sun.com (locked [129.146.85.189]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BLPaK9017644 for ; Wed, 11 Apr 2001 14:25:36 -0700 (PDT) Received: (from mohanp@localhost) by locked.eng.sun.com (8.11.2+Sun/8.10.1) id f3BLOKT14614; Wed, 11 Apr 2001 14:24:20 -0700 (PDT) From: Mohan Parthasarathy Message-Id: <200104112124.f3BLOKT14614@locked.eng.sun.com> Subject: Re: [mobile-ip] -New ID about Address owernship- In-Reply-To: <3AD49DD1.1684173D@inrialpes.fr> from Claude Castelluccia at "Apr 11, 2001 08:09:21 pm" To: mobile-ip@sunroof.eng.sun.com Date: Wed, 11 Apr 2001 14:24:20 -0700 (PDT) CC: hipsec@mail.freeswan.org X-Mailer: ELM [version 2.4ME+ PL66 (25)] 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 Hi Claude, In section (2.2) where you discuss PBK : 2. Generate an EID = hash(public component) a. the initiator sends EID to responder along with initial protocol exchanges. b. the initiator sends public component to responder along with subsequent exchanges. Notice that the exchange at step 2 must be secure in order to avoid intruder-in-the-middle attacks, but it is an improvement over cookies. Could you explain how you are communicating the public key securely in your protocol ? I have not read all the details of HIP, so i could be missing something. And also what prevents from someone intercepting msg2 other than the original MN and establish the secret ? -thanks mohan > > We have just submitted a new draft that addresses the address owernship > (and the redirection authorization) problem of Mobile IPv6 using a "HIP > based solution"..... > > This draft is available at: > http://www.inrialpes.fr/planete/people/ccastel/draft-montenegro-sucv-00.txt > > > > thanks in advance for your comments, > regards, > Claude. > > Abstract > This document addresses the identifier ownership problem. It > does so by using characteristics of Statistic Uniqueness and > Cryptographic Verifiability (SUCV) of certain entities which > this document calls SUCV Identifiers (SUCV ID's). This note > also proposes using these SUCV characteristics in related > entities called SUCV Addresses in order to severely limit > certain classes of denial of service attacks and hijacking > attacks. SUCV addresses are particularly applicable to solve the > 'address ownership' problem that severely undermines confidence > in mechanisms like Binding Updates in Mobile IP for IPv6. > > -- > > ---------------------------------------- > Claude CASTELLUCCIA, INRIA Rhone-Alpes > ph: +33 4.76.61.52.15 (fax: 52.52) > http://www.inrialpes.fr/planete/ > > From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 11 17:34: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 RAA03836 for ; Wed, 11 Apr 2001 17:34: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 OAA12550; Wed, 11 Apr 2001 14:33: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 OAA07624; Wed, 11 Apr 2001 14:32:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BLVfK9017726 for ; Wed, 11 Apr 2001 14:31:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3BLVeZO017725 for mobile-ip-dist; Wed, 11 Apr 2001 14:31: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BLVWK9017718 for ; Wed, 11 Apr 2001 14:31:32 -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 OAA12241 for ; Wed, 11 Apr 2001 14:31:31 -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 PAA28225 for ; Wed, 11 Apr 2001 15:39:11 -0600 (MDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Wed, 11 Apr 2001 17:26:00 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] A less drafty draft Date: Wed, 11 Apr 2001 17:26:00 -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: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: Wednesday, April 11, 2001 5:22 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] A less drafty draft > > > => do you propose to create a new WG or to add a security > statement in the > charter? (I believe the second solution is the best one) I'm not sure what Phil (the other one) is proposing, but we don't need a security statement in our charter. All protocols that are produced for Proposed Std must have a security considerations section. It's our responsibility to make sure our protocols are secured. The assumptions we've made about what and how we could make MIP v6 secure were mistaken to some degree. The task at hand now, as I explained in an earlier post, is to get a better set of requirements, reconsider our assumptions, and update the MIP v6 draft in a way that is secure enough to satisfy the IESG. We're trying to involve folks with security clue in every step of this activity. Phil From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 11 18:02:03 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04118 for ; Wed, 11 Apr 2001 18:02:02 -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 OAA05102; Wed, 11 Apr 2001 14:55:34 -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 OAA17831; Wed, 11 Apr 2001 14:56:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BLtQK9017796 for ; Wed, 11 Apr 2001 14:55:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3BLtP5R017795 for mobile-ip-dist; Wed, 11 Apr 2001 14:55: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BLtHK9017788 for ; Wed, 11 Apr 2001 14:55:17 -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 OAA17960 for ; Wed, 11 Apr 2001 14:55:16 -0700 (PDT) From: Franck.Le@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA26058 for ; Wed, 11 Apr 2001 14:55:11 -0700 (PDT) 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 f3BLt5g01114 for ; Wed, 11 Apr 2001 16:55:15 -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, 11 Apr 2001 16:55:00 -0500 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Wed, 11 Apr 2001 16:55:00 -0500 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B028DC52F@daeis07nok> To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Proposed changes to draft-ietf-mobileip-aaa-key-0 4.txt Date: Wed, 11 Apr 2001 16:55:00 -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 all, >-----Original Message----- >From: ext Charles E. Perkins [mailto:charliep@iprg.nokia.com] >Sent: 11 April, 2001 3:32 PM >To: pcalhoun@eng.sun.com >Cc: mobile-ip@sunroof.eng.sun.com >Subject: Re: [mobile-ip] Proposed changes to >draft-ietf-mobileip-aaa-key-04.txt > > >Hello Pat, > >I don't mind the change, but if the encoding is cryptographically >strong, it doesn't increase the security by any appreciable amount. > >> 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. I reckon MD5 should be HMAC_MD5, >and the input data should have the secret appended also after the >random value. 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. Probably neither the NAI nor the IP address need to be taken as an input thus as you say, allowing many ways to identify the user. The user's identity will already be used to retrieve the long term key. And for the algorithm, we may want to give the possibility to use different ones: since it is between the MN and the AAAh, the operator may prefer to decide some proprietary algorithms > >Did anyone contribute proposed text? We have actually described similar key distribution mechanims (based on random numbers) in the following internet drafts: http://search.ietf.org/internet-drafts/draft-le-mobileip-keydistribution-00. txt This document also defines another key distribution alternative based on Diffie Hellman thus providing other security services. The description of the two mechanisms is IPv6 specific but the same concept (key distribution based on random numbers and key distribution based on Diffie Hellman) could apply for MIPv4: we just need to define the extensions to carry the appropriate information. From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 11 20:24:30 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05437 for ; Wed, 11 Apr 2001 20:24: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 RAA04959; Wed, 11 Apr 2001 17:22: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 RAA04937; Wed, 11 Apr 2001 17:23:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3C0MLK9017952 for ; Wed, 11 Apr 2001 17:22:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3C0MKHI017951 for mobile-ip-dist; Wed, 11 Apr 2001 17:22: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3C0MCK9017944 for ; Wed, 11 Apr 2001 17:22:12 -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 RAA02796 for ; Wed, 11 Apr 2001 17:22:12 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA04714 for ; Wed, 11 Apr 2001 17:22:10 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f3C0M9e16128 for ; Thu, 12 Apr 2001 02:22:10 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id CAA12303 for ; Thu, 12 Apr 2001 02:22:09 +0200 (MET DST) Received: from localhost (localhost [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f3C0M9A49936 for ; Thu, 12 Apr 2001 02:22:09 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200104120022.f3C0M9A49936@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] -New ID about Address owernship- In-reply-to: Your message of Wed, 11 Apr 2001 20:09:21 +0200. <3AD49DD1.1684173D@inrialpes.fr> Date: Thu, 12 Apr 2001 02:22:09 +0200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: If SUCV addresses are used in a very temporary way (RFC 3041 with a new address per connection for instance) the computation of the public/private key pairs can become very expensive... But the document does not specify what is the format of the public part (the argument of the hash function) so I suggest to add a random part in it: - i.e. hash(public-part) becomes hash(public-part || random-value) - the random part should large enough in order to avoid (hash) collision with the same key pair (so 64 bits again?) - the same argument proves that the random part should be really random or an attacker can harm with collisions (*) - short term new ID should be done with a new random value, long term with a new key pair - in case of a (real) collision to provide a new random value is far cheaper than to compute a new key pair - analysis (section 4.4) is based on the hash function strength and result space so the introduction of a random part won't change this. (*) weak attacks because if the bad guy can know the public key and can guess the random value he doesn't know the private key so the signature check will fail (i.e. there is room only for a DoS attack). Regards Francis.Dupont@enst-bretagne.fr PS: in 5.0 the IID should not have the 'u' bit set because the low HIT-64 is not really *universally* unique. The 4.4 argument doesn't apply because there are/will be more than 3*10^9 MAC devices in the Universe... In fact this doesn't really matter because the low part of HIT-64 has no need to be universal? PPS: in 4.4 the argument about collisions is valid only in the Mobile IPv6 context, i.e. you shan't bet one million dollars on it. The context should be recalled in the last statement (just in order to avoid misuse of your nice proposal in a very different context :-). From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 12 04:24:34 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA24573 for ; Thu, 12 Apr 2001 04:24: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 BAA12542; Thu, 12 Apr 2001 01:22:10 -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 BAA25656; Thu, 12 Apr 2001 01:23:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3C8MPK9018635 for ; Thu, 12 Apr 2001 01:22:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3C8MONP018634 for mobile-ip-dist; Thu, 12 Apr 2001 01:22:24 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3C8MEK9018627 for ; Thu, 12 Apr 2001 01:22:14 -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 BAA29472 for ; Thu, 12 Apr 2001 01:22: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 BAA20433; Thu, 12 Apr 2001 01:22:11 -0700 (PDT) Received: from loyaute (loyaute.inrialpes.fr [194.199.20.110]) by ebene.inrialpes.fr (8.9.3+Sun/8.8.6) with SMTP id KAA18273; Thu, 12 Apr 2001 10:21:48 +0200 (MEST) Message-ID: <00b101c0c328$27f43d80$6e14c7c2@loyaute.inrialpes.fr> From: "Claude Castelluccia" To: Cc: Subject: Re: [mobile-ip] -New ID about Address owernship- Date: Thu, 12 Apr 2001 10:11:19 +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 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-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 Mohan, -----Message d'origine----- > > Notice that the exchange at step 2 must be secure in order to > avoid intruder-in-the-middle attacks, but it is an improvement > over cookies. > >Could you explain how you are communicating the public key securely >in your protocol ? I have not read all the details of HIP, so >i could be missing something. In the context of MIPV6 you don't need to send the public key securely. The home address is binded to the MN's public key and the msg2 (that included the BU) is signed by the MN's private key... An intruder-in-the-middle could intercepts msg2 and send a fake one to the CN. But this "fake" BU can not use the MN's home address because the intruder won't be able to sign it (because it does not know the private key)....so it won't be able to redirect the trafic destined to the MN.... the only think it could do is to send a BU with a fake home address ....this won't be very harmfull... did I answer your question? regards, Claude. > > From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 12 08:47:14 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28403 for ; Thu, 12 Apr 2001 08:47: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 FAA27105; Thu, 12 Apr 2001 05:44:40 -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 FAA06372; Thu, 12 Apr 2001 05:46:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CCj2K9018954 for ; Thu, 12 Apr 2001 05:45:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3CCj2bi018953 for mobile-ip-dist; Thu, 12 Apr 2001 05:45: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CCirK9018946 for ; Thu, 12 Apr 2001 05:44: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 FAA06206 for ; Thu, 12 Apr 2001 05:44:54 -0700 (PDT) Received: from goliath.siemens.de ([194.138.37.131]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA27383 for ; Thu, 12 Apr 2001 05:44:51 -0700 (PDT) X-Envelope-Sender-Is: Franz.Lackinger@icn.siemens.de (at relayer goliath.siemens.de) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.1/8.11.1) with ESMTP id f3CCipC05976 for ; Thu, 12 Apr 2001 14:44:51 +0200 (MET DST) Received: from icn.siemens.de ([139.21.173.41]) by mail3.siemens.de (8.11.1/8.11.1) with ESMTP id f3CCipr43576794 for ; Thu, 12 Apr 2001 14:44:51 +0200 (MEST) Message-ID: <3AD5A35C.1DC6E556@icn.siemens.de> Date: Thu, 12 Apr 2001 14:45:16 +0200 From: Franz Lackinger X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.0-4GB i686) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip Subject: [mobile-ip] MIPv6 fast handover implementations? 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, does anyone have (or planning) a MIPv6 implementation including fast handover as described in the Internet-Draft "Fast Handovers for Mobile IPv6" ? Thanks in advance Franz -- Franz Lackinger, ICM N MC MI E 3, MchH/St, SIEMENS AG fon: +49 89 722 37904 mobile: +49 160 4755795 mailto: Franz.Lackinger@icn.siemens.de From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 12 10:25:32 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01285 for ; Thu, 12 Apr 2001 10:25:32 -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 HAA12562; Thu, 12 Apr 2001 07:23: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 HAA05997; Thu, 12 Apr 2001 07:25:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CENhK9019162 for ; Thu, 12 Apr 2001 07:23:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3CENhue019161 for mobile-ip-dist; Thu, 12 Apr 2001 07:23:43 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CENSK9019154 for ; Thu, 12 Apr 2001 07:23: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 HAA27281 for ; Thu, 12 Apr 2001 07:23:28 -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 HAA15263 for ; Thu, 12 Apr 2001 07:23:27 -0700 (PDT) Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id <22FGTWL0>; Thu, 12 Apr 2001 16:23:03 +0200 Received: from rd.francetelecom.fr (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 221NBBV7; Thu, 12 Apr 2001 16:22:57 +0200 Message-ID: <3AD5B9CA.CF550C7B@rd.francetelecom.fr> Date: Thu, 12 Apr 2001 16:20:58 +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] A less drafty draft References: 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 HAA12562 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA01285 Hi Phil, Phil Roberts a écrit : > > -----Original Message----- > > From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] > > Sent: Wednesday, April 11, 2001 5:22 PM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] A less drafty draft > > > > > > => do you propose to create a new WG or to add a security > > statement in the > > charter? (I believe the second solution is the best one) > > I'm not sure what Phil (the other one) is proposing, but we don't > need a security statement in our charter. All protocols that are > produced for Proposed Std must have a security considerations section. > It's our responsibility to make sure our protocols are secured. The > assumptions we've made about what and how we could make MIP v6 secure > were mistaken to some degree. The task at hand now, as I explained > in an earlier post, is to get a better set of requirements, JMC : For the moment, I saw at least two solutions to secure BU but no set of requirements (unless you speak about Thomas Narten's mail). Did I miss something ? > reconsider > our assumptions, and update the MIP v6 draft in a way that is secure > enough to satisfy the IESG. We're trying to involve folks with security > clue in every step of this activity. > > Phil Regards. JMC. -- France Telecom R&D - DTL/SSR Jean-Michel COMBES, Internet/Intranet Security E-Mail : jeanmichel.combes@rd.francetelecom.fr 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 Apr 12 11:02:52 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02258 for ; Thu, 12 Apr 2001 11:02: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 HAA00520; Thu, 12 Apr 2001 07:59: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 IAA03492; Thu, 12 Apr 2001 08:00:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CEweK9019239 for ; Thu, 12 Apr 2001 07:58:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3CEwdxq019238 for mobile-ip-dist; Thu, 12 Apr 2001 07:58: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CEwOK9019227 for ; Thu, 12 Apr 2001 07:58:24 -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 HAA00611 for ; Thu, 12 Apr 2001 07:58:24 -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 HAA15245 for ; Thu, 12 Apr 2001 07:58:23 -0700 (PDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Thu, 12 Apr 2001 10:52:51 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] A less drafty draft Date: Thu, 12 Apr 2001 10:52:50 -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: > JMC : > For the moment, I saw at least two solutions to secure BU but > no set of > requirements (unless you speak about Thomas Narten's mail). Did I miss > something ? > > Regards. > JMC. > Hi, I posted a mail with subject Next Steps. A group is working on producing a set of security requirements which we don't have yet. Phil > -- > > France Telecom R&D - DTL/SSR > Jean-Michel COMBES, Internet/Intranet Security > E-Mail : jeanmichel.combes@rd.francetelecom.fr > 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 Apr 12 11:38:46 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02964 for ; Thu, 12 Apr 2001 11:38:46 -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 IAA14416; Thu, 12 Apr 2001 08:29: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 IAA13929; Thu, 12 Apr 2001 08:21:28 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CFK8K9019356 for ; Thu, 12 Apr 2001 08:20:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3CFK7hr019355 for mobile-ip-dist; Thu, 12 Apr 2001 08:20: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CFJwK9019348 for ; Thu, 12 Apr 2001 08:19:59 -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 IAA06839 for ; Thu, 12 Apr 2001 08:19:58 -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 IAA28207 for ; Thu, 12 Apr 2001 08:19:52 -0700 (PDT) Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id <22FGTXHH>; Thu, 12 Apr 2001 17:19:32 +0200 Received: from rd.francetelecom.fr (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 221NBBZA; Thu, 12 Apr 2001 17:19:21 +0200 Message-ID: <3AD5C701.346EC304@rd.francetelecom.fr> Date: Thu, 12 Apr 2001 17:17:21 +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] A less drafty draft References: <3AD5B9CA.CF550C7B@rd.francetelecom.fr> <15061.49804.692345.636891@thomasm-u1.cisco.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 IAA14416 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA02964 Hi Mike, Excuse me but this wasn't a remark, just a question. I should have to change my mail subject ... Regards. JMC. Michael Thomas a écrit : > Jean-Michel COMBES writes: > > JMC : > > For the moment, I saw at least two solutions to secure BU but no set of > > requirements (unless you speak about Thomas Narten's mail). Did I miss > > something ? > > Yes, it's very upsetting to see Charlie throw > down the gauntlet here which will surely start > a draft war. I thought we had all agreed > to wait for the chairs to put together the > requirements based on feedback from the IESG > so that we could at least have some basis to > evaluate drafts in light of *their* requirements. > As it is right now, this is all pure speculation > and will only serve to lengthen this process. > > Mike -- France Telecom R&D - DTL/SSR Jean-Michel COMBES, Internet/Intranet Security E-Mail : jeanmichel.combes@rd.francetelecom.fr 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 Apr 12 11:57: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 LAA03346 for ; Thu, 12 Apr 2001 11:57: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 IAA28437; Thu, 12 Apr 2001 08:51: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 IAA10444; Thu, 12 Apr 2001 08:51:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CFnoK9019516 for ; Thu, 12 Apr 2001 08:49:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3CFnovh019515 for mobile-ip-dist; Thu, 12 Apr 2001 08:49: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CFnfK9019508 for ; Thu, 12 Apr 2001 08:49:41 -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 IAA12812 for ; Thu, 12 Apr 2001 08:49:40 -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 IAA26605 for ; Thu, 12 Apr 2001 08:49:38 -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 f3CFnbI09698 for ; Thu, 12 Apr 2001 17:49:37 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Apr 12 17:49:36 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Apr 2001 17:45:09 +0200 Message-ID: From: "Karim El-Malki (ERA)" To: "'Phil Roberts '" , "''mobile-ip@sunroof.eng.sun.com' '" Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents Date: Thu, 12 Apr 2001 17:49:36 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) List-Subscribe: List-Unsubscribe: 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 can't understand the route opt. requirement either. The MN supports MIPv6 and can decide whether it wants to use the local anchor point or not when sending BUs to CNs. There is no need to require anything from the local anchor point itself. I believe that the HMIPv6 draft has a note on this. If the MN determines that the CN lies within its same (MAP) site then it may decide to communicate directly with the CN. Regards /Karim -----Original Message----- From: Phil Roberts To: 'mobile-ip@sunroof.eng.sun.com' Sent: 2001-04-11 22:26 Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents Agreed. But I can't tell from the requirement what exactly is required. Is it something like "2 MNs behind the same LMA shall use an optimized route that doesn't go through the LMA?" -----Original Message----- From: Muhammad Jaseemuddin [mailto:jaseem@nortelnetworks.com] Sent: Wednesday, April 11, 2001 4:21 PM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents Phil: Route optimization does not fully optimize the route in case of any form of regional registration. e.g. HMIPv6. For example if the CN is outside the domain, then the packets will follow the optimized path upto the local mobility anchor point (MAP), and then follow the optimal path to the mobile. If the MAP is not co-located with the border routers, then the scheme does not use optimal route from the border routers to the mobile. This situation becomes more conspicous if the CN is another mobile within the domain but necessarily on the same subnet as the the subnet on which the mobile's AR is connected. One can argue that in that case MN should send BU to CN with its LCOA if it (somehow) discovers that the CN is actually a mobile in the same domain. Then, intra-MAP domain signaling will be increased and the benefit of MAP will be less obvious. What I interepreted from Hongyi's requirement 10 is to address the above issue? Cheers, - Muhammad Jaseemuddin -----Original Message----- From: Phil Roberts [SMTP:PRoberts@MEGISTO.com] Sent: Tuesday, April 10, 2001 10:35 AM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents Hi, I'm a little confused about your req 10. MIP v6 already has route optimization. Do you envision req 10 to provide an alternative to that or to interoperate with that or ... something else? Thanks, Phil -----Original Message----- From: Hongyi Li [ mailto:hyli@nortelnetworks.com ] Sent: Tuesday, April 10, 2001 10:21 AM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents Hi Phil, Here are few more requirements I think that are impportant for RR/LMM (I like the term localized mobility management too): 10) LMM SHALL provide optimized routing for mobile-to-mobile communication. 11) LMM SHOULD minimize the number of network nodes affected by handoff signals. 12) LMM SHOULD support auto-configuration capabilities for mobile agents/FAs, access routers. 13) LMM SHOULD simplify the network design and provisioning for enabling LMM capability in a network and allow progressive LMM deployment capabilities. Some more comments in lines: > 1) Regional registration shall be introduced to minimize the signaling > traffic to the home agent or correspondent nodes for > intra-domain mobility > 2) Regional registration shall not introduce new overhead on > links between > the mobile and the regional registration agents > 3) Connectivity to the mobiles shall not be interrupted in > the presence of > the failure of regional registration agents > 4) Regional registration shall scale to support millions of nodes in a > visited network LMM SHALL be scalable in terms of number of connected users (i.e., active + dormant = millions) and the number of users on the move. > 5) Regional registration shall be secure against malicious > behavior from > visiting mobiles > 6) Regional registration shall allow multiple levels of hierarchy > 7) Regional registration shall support fast handoffs > 8) Regional registration shall not require changes to the > mobile node, the > home agent, or correspondent nodes > 9) Regional registration shall not introduce host routes in > routing tables I agree with Theo comments about host route. The LMM SHOULD minimize the amount of host routes in the routers. - Hongyi From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 12 12:14: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 MAA03708 for ; Thu, 12 Apr 2001 12:14:36 -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 JAA21025; Thu, 12 Apr 2001 09:14: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 JAA23748; Thu, 12 Apr 2001 09:14:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CGD7K9019580 for ; Thu, 12 Apr 2001 09:13:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3CGD7eN019579 for mobile-ip-dist; Thu, 12 Apr 2001 09:13: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CGCwK9019572 for ; Thu, 12 Apr 2001 09:12: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 JAA07032 for ; Thu, 12 Apr 2001 09:12:58 -0700 (PDT) Message-Id: <200104121612.JAA07032@heliopolis.eng.sun.com> Date: Thu, 12 Apr 2001 09:12:58 -0700 (PDT) From: James Kempf Subject: Eliminating Triangle Routing and RegReg: A Requirement? (RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents) To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: cpvtOjNtfy5PRlN1Y+0mAQ== 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: Phil/Karim, I think the problem is that both RegReg proposals currently reintroduce triangle routing. The elimination of triangle routing was viewed as one of the big steps forward with MIPv6. Granted, the fact that the MAP/GFA is topologically closer to the mobile node means that the size of the mobile-bound leg will be smaller. And, since the network engineer has complete freedom to place the MAP/GFA as they choose, it could be placed at a border router, where the mobile-bound packets have to come through anyway. I can't see much possibility for getting around this if the regional care of address is to remain unchanged. There is basically a contradiction between the major requirement of RegReg to reduce signalling over wide areas and the need for a binding update when the mobile changes care of address in order to eliminate triangle routing. Therefore, I think a perhaps better way to handle this would be to make sure that the RegReg hierarchical agent is designed flexibly enough so that it can be placed at any point in the network: Recognizing that triangle routing is unavoidable if signalling is to be reduced over a wide area, the RegReg protocol MUST be designed such that intermediate agents/routers can be flexibly inserted into the path of mobile-bound traffic such that the triangle legs correspond to the normal routing paths that mobile-bound traffic would take without RegReg. Or something like that. jak >From: "Karim El-Malki (ERA)" >To: "'Phil Roberts '" , "''mobile-ip@sunroof.eng.sun.com' '" >Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents >Date: Thu, 12 Apr 2001 17:49:36 +0200 > >I can't understand the route opt. requirement either. >The MN supports MIPv6 and can decide whether it wants to >use the local anchor point or not when sending BUs to CNs. >There is no need to require anything from the local anchor >point itself. I believe that the HMIPv6 draft has a >note on this. If the MN determines that the CN lies within >its same (MAP) site then it may decide to communicate directly >with the CN. >Regards >/Karim > >-----Original Message----- >From: Phil Roberts >To: 'mobile-ip@sunroof.eng.sun.com' >Sent: 2001-04-11 22:26 >Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents > >Agreed. But I can't tell from the requirement what exactly is >required. Is it something like "2 MNs behind the same LMA shall use an >optimized route that doesn't go through the LMA?" > > >-----Original Message----- >From: Muhammad Jaseemuddin [mailto:jaseem@nortelnetworks.com] >Sent: Wednesday, April 11, 2001 4:21 PM >To: 'mobile-ip@sunroof.eng.sun.com' >Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying >requirem ents > > > >Phil: > > Route optimization does not fully optimize the route in case of any >form of regional registration. e.g. HMIPv6. For example if the CN is >outside the domain, then the packets will follow the optimized path upto >the local mobility anchor point (MAP), and then follow the optimal path >to the mobile. If the MAP is not co-located with the border routers, >then the scheme does not use optimal route from the border routers to >the mobile. This situation becomes more conspicous if the CN is another >mobile within the domain but necessarily on the same subnet as the the >subnet on which the mobile's AR is connected. One can argue that in that >case MN should send BU to CN with its LCOA if it (somehow) discovers >that the CN is actually a mobile in the same domain. Then, intra-MAP >domain signaling will be increased and the benefit of MAP will be less >obvious. > > What I interepreted from Hongyi's requirement 10 is to address the >above issue? > >Cheers, >- Muhammad Jaseemuddin > > > > -----Original Message----- >From: Phil Roberts [SMTP:PRoberts@MEGISTO.com] >Sent: Tuesday, April 10, 2001 10:35 AM >To: 'mobile-ip@sunroof.eng.sun.com' >Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying >requirem ents > > Hi, > >I'm a little confused about your req 10. MIP v6 already has route >optimization. Do you envision req 10 to provide an alternative to that >or to interoperate with that or ... something else? > > >Thanks, >Phil > > > -----Original Message----- >From: Hongyi Li [ mailto:hyli@nortelnetworks.com > ] >Sent: Tuesday, April 10, 2001 10:21 AM >To: 'mobile-ip@sunroof.eng.sun.com' >Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying >requirem ents > > > > Hi Phil, > Here are few more requirements I think that are impportant for RR/LMM >(I like >the term localized mobility management too): > > 10) LMM SHALL provide optimized routing for mobile-to-mobile >communication. > 11) LMM SHOULD minimize the number of network nodes affected by handoff >signals. > 12) LMM SHOULD support auto-configuration capabilities for mobile >agents/FAs, access routers. > 13) LMM SHOULD simplify the network design and provisioning for >enabling LMM >capability in a network and allow progressive LMM deployment >capabilities. > > Some more comments in lines: > >> 1) Regional registration shall be introduced to minimize the signaling >> traffic to the home agent or correspondent nodes for >> intra-domain mobility >> 2) Regional registration shall not introduce new overhead on >> links between >> the mobile and the regional registration agents >> 3) Connectivity to the mobiles shall not be interrupted in >> the presence of >> the failure of regional registration agents >> 4) Regional registration shall scale to support millions of nodes in a >> visited network > > LMM SHALL be scalable in terms of number of connected users >(i.e., active + dormant = millions) and the number of users on the >move. > > > 5) Regional registration shall be secure against malicious >> behavior from >> visiting mobiles >> 6) Regional registration shall allow multiple levels of hierarchy >> 7) Regional registration shall support fast handoffs >> 8) Regional registration shall not require changes to the >> mobile node, the >> home agent, or correspondent nodes >> 9) Regional registration shall not introduce host routes in >> routing tables > > I agree with Theo comments about host route. The LMM SHOULD >minimize the amount of host routes in the routers. > > - Hongyi > From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 12 12:48: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 MAA04612 for ; Thu, 12 Apr 2001 12:48:07 -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 JAA08963; Thu, 12 Apr 2001 09:33:50 -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 JAA20247; Thu, 12 Apr 2001 09:33:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CGWJK9019637 for ; Thu, 12 Apr 2001 09:32:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3CGWI5F019636 for mobile-ip-dist; Thu, 12 Apr 2001 09:32:18 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CGW9K9019629 for ; Thu, 12 Apr 2001 09:32:09 -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 JAA19717 for ; Thu, 12 Apr 2001 09:32:08 -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 KAA24461 for ; Thu, 12 Apr 2001 10:34:00 -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 JAA27112; Thu, 12 Apr 2001 09:32:00 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3CGVvF04784; Thu, 12 Apr 2001 09:31:57 -0700 X-mProtect: Thu, 12 Apr 2001 09:31:57 -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(WTS.12.69) smtpdo5DNOT; Thu, 12 Apr 2001 09:31:25 PDT Message-ID: <3AD5D85E.654DCCAB@iprg.nokia.com> Date: Thu, 12 Apr 2001 09:31:26 -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: Michael Thomas CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] A less drafty draft References: <3AD5B9CA.CF550C7B@rd.francetelecom.fr> <15061.49804.692345.636891@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 Hello Michael, Michael Thomas wrote: > Yes, it's very upsetting to see Charlie throw > down the gauntlet here which will surely start > a draft war. I sure am surprised to see this reaction. We don't need to have a draft war. We need to expedite work towards a goal. If BAKE doesn't meet the requirements set forth, then either it has to be modified or discarded. My experience is that when someone is motivated to get the job done and has the ability to do it, good results are possible. It's better to take advantage of the drive and motivation engendered by the need for immediate action. I feel that we need to get the security issues resolved sooner rather than later, and Pekka and I were motivated to try to accomplish something. I'd prefer that not be characterized as something malevolent, but whether you prefer to do so is, of course, your choice. I'd rather you see it as a solid step towards a goal, but again... > I thought we had all agreed > to wait for the chairs to put together the > requirements based on feedback from the IESG > so that we could at least have some basis to > evaluate drafts in light of *their* requirements. > As it is right now, this is all pure speculation > and will only serve to lengthen this process. You and I have been in some of the same rooms where the requirements were pretty clearly laid out. We are both waiting for more official formulations. There is a lot of work to do. I don't intend to do anything to lengthen the process. On the contrary. Furthermore, it will be the responsibility of Pekka and myself to make sure our draft meets the requirements, as they become more concretely formulated. How will this result in lengthening the process? Our draft is not pure speculation, and it's intended to be part of a draft war, and we have constructed no gauntlet. Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 12 12:57: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 MAA04789 for ; Thu, 12 Apr 2001 12:57: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 JAA01927; Thu, 12 Apr 2001 09:57: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 JAA05313; Thu, 12 Apr 2001 09:56:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CGtDK9019692 for ; Thu, 12 Apr 2001 09:55:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3CGtDUj019691 for mobile-ip-dist; Thu, 12 Apr 2001 09:55: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CGt4K9019684 for ; Thu, 12 Apr 2001 09:55:04 -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 JAA25160 for ; Thu, 12 Apr 2001 09:55:03 -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 KAA08283 for ; Thu, 12 Apr 2001 10:57:16 -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.9.3/8.9.1) with ESMTP id JAA03887; Thu, 12 Apr 2001 09:53:33 -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 ADZ01561; Thu, 12 Apr 2001 09:54:51 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA07789; Thu, 12 Apr 2001 09:54:51 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15061.56795.208181.755937@thomasm-u1.cisco.com> Date: Thu, 12 Apr 2001 09:54:51 -0700 (PDT) To: "Charles E. Perkins" Cc: Michael Thomas , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] A less drafty draft In-Reply-To: <3AD5D85E.654DCCAB@iprg.nokia.com> References: <3AD5B9CA.CF550C7B@rd.francetelecom.fr> <15061.49804.692345.636891@thomasm-u1.cisco.com> <3AD5D85E.654DCCAB@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 What you are of course not bringing up is that Dave Oran and I had a concrete draft on this subject from *before* IETF 50 which I shared with both you and Pekka. I see that you two have incorporated several of the features of the draft as well, though unacknowledged. I have been waiting to publish it because we agreed to wait for the chairs to lay out the ground rules and form the design team. Yet you've decided -- again -- to take matters into your own hands and start the process that is very likely to extend this for a very long time. Express faux-surprise all you like. I find it rather disingenuous. It needn't have been this way. Mike Charles E. Perkins writes: > > Hello Michael, > > Michael Thomas wrote: > > > Yes, it's very upsetting to see Charlie throw > > down the gauntlet here which will surely start > > a draft war. > > I sure am surprised to see this reaction. We don't need > to have a draft war. We need to expedite work towards a > goal. If BAKE doesn't meet the requirements set forth, > then either it has to be modified or discarded. > > My experience is that when someone is motivated to get > the job done and has the ability to do it, good results > are possible. It's better to take advantage of the drive > and motivation engendered by the need for immediate > action. I feel that we need to get the security issues > resolved sooner rather than later, and Pekka and I were > motivated to try to accomplish something. I'd prefer > that not be characterized as something malevolent, but > whether you prefer to do so is, of course, your choice. > I'd rather you see it as a solid step towards a goal, > but again... > > > I thought we had all agreed > > to wait for the chairs to put together the > > requirements based on feedback from the IESG > > so that we could at least have some basis to > > evaluate drafts in light of *their* requirements. > > As it is right now, this is all pure speculation > > and will only serve to lengthen this process. > > You and I have been in some of the same rooms where the > requirements were pretty clearly laid out. We are both > waiting for more official formulations. There is a lot > of work to do. I don't intend to do anything to lengthen > the process. On the contrary. Furthermore, it will be > the responsibility of Pekka and myself to make sure our > draft meets the requirements, as they become more > concretely formulated. How will this result in lengthening > the process? > > Our draft is not pure speculation, and it's intended to > be part of a draft war, and we have constructed no gauntlet. > > > Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 12 13:12: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 NAA05111 for ; Thu, 12 Apr 2001 13:12:26 -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 KAA17920; Thu, 12 Apr 2001 10:12: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 KAA10425; Thu, 12 Apr 2001 10:12:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CHAUK9019750 for ; Thu, 12 Apr 2001 10:10:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3CHATMc019749 for mobile-ip-dist; Thu, 12 Apr 2001 10:10: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CHAJK9019739 for ; Thu, 12 Apr 2001 10:10:19 -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 KAA09982 for ; Thu, 12 Apr 2001 10:10:18 -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 LAA18818 for ; Thu, 12 Apr 2001 11:13:00 -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 KAA01047; Thu, 12 Apr 2001 10:10:17 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3CHAEu15215; Thu, 12 Apr 2001 10:10:14 -0700 X-mProtect: Thu, 12 Apr 2001 10:10:14 -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(WTS.12.69) smtpdrAt7pe; Thu, 12 Apr 2001 10:10:10 PDT Message-ID: <3AD5E175.C4D1D4E7@iprg.nokia.com> Date: Thu, 12 Apr 2001 10:10:13 -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: Michael Thomas CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] A less drafty draft References: <3AD5B9CA.CF550C7B@rd.francetelecom.fr> <15061.49804.692345.636891@thomasm-u1.cisco.com> <3AD5D85E.654DCCAB@iprg.nokia.com> <15061.56795.208181.755937@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 Hello Michael, The effort in this draft stems from the triangle I drew on the paper in that room on Tuesday night. Pekka graciously offered to fill out the details, which he has done in "impeccable" fashion. > What you are of course not bringing up is that > Dave Oran and I had a concrete draft on this > subject from *before* IETF 50 which I shared with > both you and Pekka. I didn't bring up your draft, because it wasn't relevant to the discussion in your note. I assume now that you believe in the possibility of a draft war between your draft and the BAKE draft. Fine. I don't really have time to fight. > I see that you two have > incorporated several of the features of the draft > as well, though unacknowledged. I have no conscious recollection of taking any ideas from your draft. However, if you would like to be acknowledged, please craft the acknowledgement you want and (within reason and agreement from Pekka) I'll include it in the Acknowledgement section. > I have been > waiting to publish it because we agreed to wait > for the chairs to lay out the ground rules and > form the design team. Yet you've decided -- again > -- to take matters into your own hands and start > the process that is very likely to extend this for > a very long time. I decided to take action that Tuesday night, and I didn't hear anyone say not to. I did in fact, send out a primitive version of the draft that same week. It did not elicit this kind of heavy-handed accusation from you, nor any request to delay further development. I didn't ask you to stop working on your draft, either. > Express faux-surprise all you like. I find it > rather disingenuous. It needn't have been this > way. I may be a lot of things, but I'm not a liar. And what is "it", that needn't have been this way? I still want to get a good solution ASAP. I'm sure you can help very much if you so choose. Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 12 13:44:55 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05854 for ; Thu, 12 Apr 2001 13:44: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 KAA17774; Thu, 12 Apr 2001 10:42: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 KAA09901; Thu, 12 Apr 2001 10:39:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CHbJK9019834 for ; Thu, 12 Apr 2001 10:37:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3CHbJ5f019833 for mobile-ip-dist; Thu, 12 Apr 2001 10:37: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CHbAK9019826 for ; Thu, 12 Apr 2001 10:37:10 -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 KAA14001 for ; Thu, 12 Apr 2001 10:37:09 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22515 for ; Thu, 12 Apr 2001 10:37:08 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f3CHb7e21912; Thu, 12 Apr 2001 19:37:07 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA23160; Thu, 12 Apr 2001 19:37:07 +0200 (MET DST) Received: from localhost (localhost [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f3CHb6A52770; Thu, 12 Apr 2001 19:37:06 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200104121737.f3CHb6A52770@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: hipsec@mail.freeswan.org Subject: Re: [mobile-ip] -New ID about Address owernship- In-reply-to: Your message of Wed, 11 Apr 2001 20:09:21 +0200. <3AD49DD1.1684173D@inrialpes.fr> Date: Thu, 12 Apr 2001 19:37:06 +0200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Note I am not (yet) a member of the hipsec list so if this mail bounces it should be reposted in the list... I have a concern about to use the HIP stuff for the mobile IPv6 security because HIP was designed to "rapidly establish an ESP Security Association" so it is very powerful but expensive: There is significant overhead associated with building HIP-based SAs (both in terms of CPU cycles, but also in terms of required message flows) This has negative implications for larger servers that process many 100s of thousands of connections at a time or for smaller mobile nodes that are short in processor and battery resources (you have recognized the argument :-). An illustration: HIP provides a good protection against DoS attacks, in fact this is not really an advantage: HIP must provide this because HIP mechanisms involve a lot of powerful/expensive crypto which could make DoS attacks very prejudicial... The less drafty draft uses only SHA-1 which is far less expensive: the exact requirements for mobile IPv6 security are not yet available but HIP seems to overfulfill them. BTW I like very much the SUCV address idea but section 6.1 should be simplify/adapted (i.e. not cut&pasted from the HIP document). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 12 14:27:42 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 OAA06981 for ; Thu, 12 Apr 2001 14:27: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 LAA28632; Thu, 12 Apr 2001 11:27: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 LAA29924; Thu, 12 Apr 2001 11:27:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CIPnK9020242 for ; Thu, 12 Apr 2001 11:25:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3CIPncN020241 for mobile-ip-dist; Thu, 12 Apr 2001 11:25: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CIPXK9020228 for ; Thu, 12 Apr 2001 11:25: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 LAA11866 for ; Thu, 12 Apr 2001 11:25:32 -0700 (PDT) Message-Id: <200104121825.LAA11866@heliopolis.eng.sun.com> Date: Thu, 12 Apr 2001 11:25:32 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] dynamic home addressing as a WG item?? To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 9icUHxeStIix973ulfIa1Q== 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 Sandy, I've been having problems with my email, which is why the response is delayed. >> The options related to IP address configuration >> and routing (gateway router, subnet mask, >> and domain name) are not handled by >> service discovery currently but they could >> be handled by a mobile IP extension or >> AAA extension that hides the back end >> implementation so network operators >> could use the backend technique of their >> choosing. > >Sure. But this is precisely the question: >who should allocate these configuration >parameters? Some backend mechanism made >transparent through Mobile IP extensions? >AAA extensions? DHCP? I obviously believe >that DHCP should do it, at least today and in >the foreseeable future. > I think the question is "how should the mobile node access these parameters" not "who should allocate the parameters." Since these have to do with the HA, they need to be allocated by the HA on the home subnet. The HA can allocate them via DHCP or however it chooses. I think that it would be better to come up with a lightweight way of doing this, rather than requiring DHCP relays and reverse tunnels. A simple extension to MIP that allows an HA to send configuration information in a registration reply would do the trick. >> No, but this is something that could easily become >> a standardized Diameter extension. > >I wonder if anyone on this mailing list with >AAA expertise can shed some more light onto >this possibility. > To get it to the end node would actually require something like BURP, but that's not being discussed for BURP. Diameter is infrastructure only. >Sure, DHCP was developed for enterprise networks >but why is this a problem? The point is that DHCP >IS widely deployed in LANs today and with a >relatively simple solution you can use it to >configure remote mobile nodes *as if* they >were connected to their home networks, WITHOUT >the need to change DHCP in any way to make it fit >the special needs of mobile nodes. > One of the problems with mobility is that people assume it is possible to simply extend enterprise designs based on always wired hosts. This sometimes works, but often it doesn't. Mobility has its own unique aspects, and I think extending DHCP isn't the right way to go. Just as there are separate routing protocols for local domain and wide area, I think we need address and basic configuration provisioning to fit the mobile case. They need to be simple and lightweight. DHCP is neither in a mobile deployment scenario (and, btw., I did read both drafts). >Fine. You could make a Mobile IP client take on >the responsabilities a DHCP client is used to >handling but be ready to *change* that Mobile IP >client. At the very least, you'd have to change >the Mobile IP standard to require mobile nodes >to register even while they're at home so that >they can maintain soft-state support on their >assigned home address. Now, if you happen >to also need configuration parameters, you not >only have to change the client state machine >but you also need to extend Mobile IP messages... >Changing the Mobile IP standard to do this is >the key problem you can avoid by letting DHCP >handle the dynamic addressing and configuration >needs of the mobile nodes. > Sure, mobile IP isn't cast in stone at this point. Maybe the problem here is that we have two different models in mind. I think there is a distinction between "nomadic" users and "mobile" users. Nomadic users set up somewhere, do IP traffic for a while, then shut down. They do not change their point of attachment. These types of users are and will continue to be well-served by DHCP. Mobile users are constantly changing their point of attachment, and occasionally their hosts may go into dormant mode in order to save power, while still maintaining a virtual IP connection. These users are better served with mobile IP. Currently, there is no way to get nonservice related configuration parameters through mobile IP. This is an oversight that needs fixing. It does not, IMHO, mean that a protocol designed for nomadic use should be extended to something it wasn't designed for, namely mobile users. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 12 14:28: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 OAA07018 for ; Thu, 12 Apr 2001 14:28: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 IAA14195; Thu, 12 Apr 2001 08:00: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 IAA07633; Thu, 12 Apr 2001 08:00:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CEwbK9019236 for ; Thu, 12 Apr 2001 07:58:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3CEwbKI019235 for mobile-ip-dist; Thu, 12 Apr 2001 07:58: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CEwMK9019221 for ; Thu, 12 Apr 2001 07:58:22 -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 HAA10543 for ; Thu, 12 Apr 2001 07:58:21 -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 HAA15226 for ; Thu, 12 Apr 2001 07:58:21 -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.9.3/8.9.1) with ESMTP id HAA18002 for ; Thu, 12 Apr 2001 07:58: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 ADY02904; Thu, 12 Apr 2001 07:58:21 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA07777; Thu, 12 Apr 2001 07:58:20 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15061.49804.692345.636891@thomasm-u1.cisco.com> Date: Thu, 12 Apr 2001 07:58:20 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] A less drafty draft In-Reply-To: <3AD5B9CA.CF550C7B@rd.francetelecom.fr> References: <3AD5B9CA.CF550C7B@rd.francetelecom.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 Jean-Michel COMBES writes: > JMC : > For the moment, I saw at least two solutions to secure BU but no set of > requirements (unless you speak about Thomas Narten's mail). Did I miss > something ? Yes, it's very upsetting to see Charlie throw down the gauntlet here which will surely start a draft war. I thought we had all agreed to wait for the chairs to put together the requirements based on feedback from the IESG so that we could at least have some basis to evaluate drafts in light of *their* requirements. As it is right now, this is all pure speculation and will only serve to lengthen this process. Mike From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 12 15:39: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 PAA08692 for ; Thu, 12 Apr 2001 15:39: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 MAA26485; Thu, 12 Apr 2001 12:38: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 MAA08545; Thu, 12 Apr 2001 12:38:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CJVHK9020702 for ; Thu, 12 Apr 2001 12:31:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3CJVHIA020701 for mobile-ip-dist; Thu, 12 Apr 2001 12:31: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CJV8K9020694 for ; Thu, 12 Apr 2001 12:31:08 -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 MAA15520 for ; Thu, 12 Apr 2001 12:31:03 -0700 (PDT) Received: from c007.snv.cp.net (c007-h008.c007.snv.cp.net [209.228.33.214]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id MAA21072 for ; Thu, 12 Apr 2001 12:31:03 -0700 (PDT) Received: (cpmta 18369 invoked from network); 12 Apr 2001 12:30:57 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.214) with SMTP; 12 Apr 2001 12:30:57 -0700 X-Sent: 12 Apr 2001 19:30:57 GMT Message-ID: <01fa01c0c386$f8749dc0$6501a8c0@philneum> From: "Phil Neumiller" To: References: <200104121825.LAA11866@heliopolis.eng.sun.com> Subject: Re: [mobile-ip] dynamic home addressing as a WG item?? Date: Thu, 12 Apr 2001 14:29:56 -0500 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: Hi James, I have a comment on your suggestion to Sandy below. ----- Original Message ----- From: "James Kempf" To: Sent: Thursday, April 12, 2001 1:25 PM > I think that it would be better to come up with > a lightweight way of doing this, rather than > requiring DHCP relays and reverse tunnels. > A simple extension to MIP that allows an > HA to send configuration information in > a registration reply would do the trick. I would say its a "hack" not a trick and it has the negative effect of putting a routing protocol (MIP) under the yoke of something that is clearly an application layer duty. DON'T DO IT! (That's how I really feel James...) -pdn From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 12 15:53:41 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09045 for ; Thu, 12 Apr 2001 15:53:40 -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 MAA18090; Thu, 12 Apr 2001 12:50: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 MAA20131; Thu, 12 Apr 2001 12:52:38 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CJokK9020755 for ; Thu, 12 Apr 2001 12:50:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3CJojuT020754 for mobile-ip-dist; Thu, 12 Apr 2001 12:50: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CJoYK9020746 for ; Thu, 12 Apr 2001 12:50:36 -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 MAA14774 for ; Thu, 12 Apr 2001 12:50:33 -0700 (PDT) Message-Id: <200104121950.MAA14774@heliopolis.eng.sun.com> Date: Thu, 12 Apr 2001 12:50:33 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] dynamic home addressing as a WG item?? To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: SPAKY449qx04t2KFfuRNPg== 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 Phil, >I would say its a "hack" not a trick and it has the negative >effect of putting a routing protocol (MIP) under the yoke >of something that is clearly an application layer duty. >DON'T DO IT! (That's how I really feel James...) OK, then what would you suggest? I think extending DHCP to the mobile is just as much of a hack. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 12 15:53:42 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09056 for ; Thu, 12 Apr 2001 15:53:41 -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 MAA17261; Thu, 12 Apr 2001 12:49:09 -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 MAA11476; Thu, 12 Apr 2001 12:50:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CJlmK9020739 for ; Thu, 12 Apr 2001 12:47:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3CJlltF020738 for mobile-ip-dist; Thu, 12 Apr 2001 12:47: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CJldK9020731 for ; Thu, 12 Apr 2001 12:47:39 -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 MAA14690 for ; Thu, 12 Apr 2001 12:47:38 -0700 (PDT) Message-Id: <200104121947.MAA14690@heliopolis.eng.sun.com> Date: Thu, 12 Apr 2001 12:47:38 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] MIP v6 Regional Registration - identifying re qui rements To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: pXlUxJ9P9BVu8rP1IyHcNA== 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've been having problems with my email again, don't know if this made it out on Monday. >> >> A short list of concerns include worries about introducing single >> >> points of failure, whether or not multiple levels of hierarchy are >> needed, >> >> the amount of signaling and tunneling overhead that is implied, the >> >> >> >> => We believe we got some confirmation for ROHC and CT >> >> folks that tunnelling will not be an issue. >> >> >> >> Well, I'm glad you think that, because I've seen nothing in the >> email thread that gives me any confidence at all that this will >> be possible. I've seen Rajeev's note that changing the IP >> address on the header might work, but not that changing 40 bytes >> of header option will. And the ROHC chairs have not come out >> one way or the other on this. >> > => We have heard at least 4 times now that ROHC will > handle IP in IP tunnels. IPv6 in IPv4 will also be handled. > We don't need to discuss this since you can verify it > by reading the spec. > > As for sending full headers after handovers, we've seen > the discussions, one camp says that simultions have > proven that losing more than 3 packets in WCDMA (an > example of an error prone environment) is extremely > unlikey. The other camp disagrees and says that the > problem exists and can be solved by CT. What more > do we need to know ? > I don't think this is relevant to HMIPv6 only so I > don't see why this keeps coming up in relation > to HMIPv6. > I'm not bringing it up in the context of HMIPv6 only, I'm bringing it up in the context of requirements for RegReg. I think there needs to be a requirement for minimizing over the air header, in the absence of a definitive statement that handovers will not be slowed. MIPv6 has already been bitten by using work from another working group in a way that generated unintended consequences, we don't want that to happen again. Until I see a statement from the ROHC working group that piling on tunnel overhead won't cause significant (and 3 packets is significant) latency increase in handover, I think we need a requirement that the RegReg protocol introduces no header overhead beyond basic MIPv6. >> >> We would like to add two more requirements. >> >> >> >> 0) Localised mobility management should provide the same >> >> level of mobility management support as in the basic >> >> MIPv6 specifiation. The mobility management functions >> >> supported in MIPv6 must not be reduced in such mechanism. >> >> >> >> 0.5) The provided mechanism must interwork with existing >> >> MIPv6, IPv6 and the proposed mechanisms for SA establishment >> >> in MIPv6. >> >> Yes, I would agreee. >> >> Additionally, I would add: >> >> The mechanism should minimize mobile node involvement in routing, >> beyond what the current MIPv6 requires. Preferences, load balancing, >> and other complex host-based mechanism whereby the mobile node, >> rather than the network, is involved in determining routes should >> be avoided, >> > => I guess you are referring to HMIPv6 here and no the requirements > in an abstract sense. The preference value was first introduced in > the MIPv6 spec for the HA. Why is this any different ? do you have > the same reservation on MIPv6 ? If so I disagree. I think the > HA's preference field is useful. > Actually, yes. I think the whole HA preference list thing in MIPv6 is unnecessarily complex. Why should a host care what router it's getting? The only reason I could see for a host to care is that it is authenticated for a particular router and not another, and that isn't addressed by the preferences design, or, it could be addressed in a roundabout and rather cumbersome way, IMHO. Routing decisions should be left to routers, not hosts. This has been a proven, successful design in the wired Internet and I don't know why it should not be so for wireless as well. > Regarding load balancing, this is something that we believe is > important and needed. However, based on comments received > we will put it in a different drat. This is not a new thing, it already > exists in routers today. Furthermore, in some cellular networks > (3GPP) a very similar feature is implemented in the GGSN. > This is _already_being_developed in products (GGSNs). > GPRS is a competing IP mobility standard being pushed by 3GPP. They've shown little or no interest in deploying mobile IP. Why should we do something to accommodate them, or accommodate our design to their poor design? >> >> 6) Regional registration shall allow multiple levels of hierarchy >> >> >> >> => We can't see a reason for this requirement. We think it's >> >> OK if we want to support mobile networks but we don't >> >> think this requirement should be placed for all cases. >> >> We never got an answer for the technical merits of >> >> this requirement. It would be good to know why. Otherwise >> >> we'd like to remove this requirement. >> >> >> >> Hesham, I've given reasons for this requirement multiple times, but >> my impression is that you've ignored them. The fact of the matter is you don't >> believe it's important because HMIP can only do it to a limited extent. >> > => Actually I haven't ignored anything. You haven't mentioned any > reasons on this list or others. If I missed it, please point me to > the mail or date and I'l look it up. When we discussed this > in private I responded and didn't get a reply. > So it would be much easier IMO if you just tell us the > reasons. > OK, I missed the private email, like I said, I've been having email problems. Here are a couple reasons: 1) Our design work on an all-IP radio access network showed that if mobile IP is to be used for managing movement of the macrodiversity resolution point and radio control server, then the hierarchical signalling must be arranged to allow multiple levels of hierarchy. Typically one level of hierarchy will be involved in managing macrodiversity resolution/radio control in the RAN while another will be involved in managing the movement of the mobile's globally visible IP address. 2) A large ISP that peers for multiple wireless ISPs and, in addition, has its own wireless networks may want to aggregate traffic for particular wireless ISPs through particular RegReg routers. This is very similar to how current ISPs aggregate through particular border routers. Routing hierarchies have been important in the wired Internet, we see no reason why the same might also not be true with wireless. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 12 16:22:44 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09853 for ; Thu, 12 Apr 2001 16:22: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 NAA01269; Thu, 12 Apr 2001 13:19: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 NAA23805; Thu, 12 Apr 2001 13:21:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CKJcK9020891 for ; Thu, 12 Apr 2001 13:19:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3CKJbuK020890 for mobile-ip-dist; Thu, 12 Apr 2001 13:19: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CKJTK9020883 for ; Thu, 12 Apr 2001 13:19:29 -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 NAA19141 for ; Thu, 12 Apr 2001 13:19:21 -0700 (PDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA05097 for ; Thu, 12 Apr 2001 14:22:34 -0600 (MDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 12 Apr 2001 16:18:56 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Apr 2001 16:18:57 -0400 Message-ID: From: "Hongyi Li" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents Date: Thu, 12 Apr 2001 16:18:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C38D.CC08FCC0" 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_01C0C38D.CC08FCC0 Content-Type: text/plain; charset="iso-8859-1" Hi Phil, Optimize routing is a goal for MIPv6 and it should be the goal for LMM/RR as well. This requirement simply requires that the data packets between two communicating nodes (regardless of where the two nodes are) take the path selected by the native IP routing protocol (e.g., OSPF). An example of non-optimized path is that if an anchor node is not on the optimal path between two communicating nodes and packets still travel through that anchor anchor node (triangular routing). This is just a proposed requirement. I am not arguing whether a particular protocol can meet the requirement or not. -Hongyi -----Original Message----- From: Phil Roberts [mailto:PRoberts@MEGISTO.com] Sent: Wednesday, April 11, 2001 4:26 PM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents Agreed. But I can't tell from the requirement what exactly is required. Is it something like "2 MNs behind the same LMA shall use an optimized route that doesn't go through the LMA?" -----Original Message----- From: Muhammad Jaseemuddin [mailto:jaseem@nortelnetworks.com] Sent: Wednesday, April 11, 2001 4:21 PM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents Phil: Route optimization does not fully optimize the route in case of any form of regional registration. e.g. HMIPv6. For example if the CN is outside the domain, then the packets will follow the optimized path upto the local mobility anchor point (MAP), and then follow the optimal path to the mobile. If the MAP is not co-located with the border routers, then the scheme does not use optimal route from the border routers to the mobile. This situation becomes more conspicous if the CN is another mobile within the domain but necessarily on the same subnet as the the subnet on which the mobile's AR is connected. One can argue that in that case MN should send BU to CN with its LCOA if it (somehow) discovers that the CN is actually a mobile in the same domain. Then, intra-MAP domain signaling will be increased and the benefit of MAP will be less obvious. What I interepreted from Hongyi's requirement 10 is to address the above issue? Cheers, - Muhammad Jaseemuddin -----Original Message----- From: Phil Roberts [SMTP:PRoberts@MEGISTO.com] Sent: Tuesday, April 10, 2001 10:35 AM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents Hi, I'm a little confused about your req 10. MIP v6 already has route optimization. Do you envision req 10 to provide an alternative to that or to interoperate with that or ... something else? Thanks, Phil -----Original Message----- From: Hongyi Li [ mailto:hyli@nortelnetworks.com ] Sent: Tuesday, April 10, 2001 10:21 AM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents Hi Phil, Here are few more requirements I think that are impportant for RR/LMM (I like the term localized mobility management too): 10) LMM SHALL provide optimized routing for mobile-to-mobile communication. 11) LMM SHOULD minimize the number of network nodes affected by handoff signals. 12) LMM SHOULD support auto-configuration capabilities for mobile agents/FAs, access routers. 13) LMM SHOULD simplify the network design and provisioning for enabling LMM capability in a network and allow progressive LMM deployment capabilities. Some more comments in lines: > 1) Regional registration shall be introduced to minimize the signaling > traffic to the home agent or correspondent nodes for > intra-domain mobility > 2) Regional registration shall not introduce new overhead on > links between > the mobile and the regional registration agents > 3) Connectivity to the mobiles shall not be interrupted in > the presence of > the failure of regional registration agents > 4) Regional registration shall scale to support millions of nodes in a > visited network LMM SHALL be scalable in terms of number of connected users (i.e., active + dormant = millions) and the number of users on the move. > 5) Regional registration shall be secure against malicious > behavior from > visiting mobiles > 6) Regional registration shall allow multiple levels of hierarchy > 7) Regional registration shall support fast handoffs > 8) Regional registration shall not require changes to the > mobile node, the > home agent, or correspondent nodes > 9) Regional registration shall not introduce host routes in > routing tables I agree with Theo comments about host route. The LMM SHOULD minimize the amount of host routes in the routers. - Hongyi ------_=_NextPart_001_01C0C38D.CC08FCC0 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents
Hi Phil,
 
  Optimize routing is a goal for MIPv6 and it should be the goal for LMM/RR as well.
This requirement simply requires that the data packets between two communicating
nodes (regardless of where the two nodes are) take the path selected by the native
IP routing protocol (e.g., OSPF).
 
  An example of non-optimized path is that if an anchor node is not on the optimal
path between two communicating nodes and packets still travel through that anchor
anchor node (triangular routing).
 
  This is just a proposed requirement. I am not arguing whether a particular protocol
can meet the requirement or not. 
 
-Hongyi
 
-----Original Message-----
From: Phil Roberts [mailto:PRoberts@MEGISTO.com]
Sent: Wednesday, April 11, 2001 4:26 PM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents

Agreed.   But I can't tell from the requirement what exactly is required.  Is it something like "2 MNs behind the same LMA shall use an optimized route that doesn't go through the LMA?"
 
-----Original Message-----
From: Muhammad Jaseemuddin [mailto:jaseem@nortelnetworks.com]
Sent: Wednesday, April 11, 2001 4:21 PM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents

Phil:

 Route optimization does not fully optimize the route in case of any form of regional registration. e.g. HMIPv6. For example if the CN is outside the domain, then the packets will follow the optimized path upto the local mobility anchor point (MAP), and then follow the optimal path to the mobile. If the MAP is not co-located with the border routers, then the scheme does not use optimal route from the border routers to the mobile. This situation becomes more conspicous if the CN is another mobile within the domain but necessarily on the same subnet as the the subnet on which the mobile's AR is connected. One can argue that in that case MN should send BU to CN with its LCOA if it (somehow) discovers that the CN is actually a mobile in the same domain. Then, intra-MAP domain signaling will be increased and the benefit of MAP will be less obvious.

 What I interepreted from Hongyi's requirement 10 is to address the above issue?

Cheers,
- Muhammad Jaseemuddin
 

    -----Original Message-----
    From:   Phil Roberts [SMTP:PRoberts@MEGISTO.com]
    Sent:   Tuesday, April 10, 2001 10:35 AM
    To:     'mobile-ip@sunroof.eng.sun.com'
    Subject:        RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents

    Hi,
     
    I'm a little confused about your req 10.  MIP v6 already has route optimization.  Do you envision req 10 to provide an alternative to that or to interoperate with that or ... something else?


    Thanks,
    Phil
     

      -----Original Message-----
      From: Hongyi Li [mailto:hyli@nortelnetworks.com]
      Sent: Tuesday, April 10, 2001 10:21 AM
      To: 'mobile-ip@sunroof.eng.sun.com'
      Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents

      Hi Phil,
        Here are few more requirements I think that are impportant for RR/LMM (I like
      the term localized mobility management too):

       10) LMM SHALL provide optimized routing for mobile-to-mobile communication.
       11) LMM SHOULD minimize the number of network nodes affected by handoff signals.
       12) LMM SHOULD support auto-configuration capabilities for mobile agents/FAs, access routers.
       13) LMM SHOULD simplify the network design and provisioning for enabling LMM
      capability in a network and allow progressive LMM deployment capabilities.

      Some more comments in lines:
        
      > 1) Regional registration shall be introduced to minimize the signaling
      > traffic to the home agent or correspondent nodes for
      > intra-domain mobility
      > 2) Regional registration shall not introduce new overhead on
      > links between
      > the mobile and the regional registration agents
      > 3) Connectivity to the mobiles shall not be interrupted in
      > the presence of
      > the failure of regional registration agents
      > 4) Regional registration shall scale to support millions of nodes in a
      > visited network

      LMM SHALL be scalable in terms of number of connected users (i.e., active + dormant =  millions) and the number of users on the move.

      > 5) Regional registration shall be secure against malicious
      > behavior from
      > visiting mobiles
      > 6) Regional registration shall allow multiple levels of hierarchy
      > 7) Regional registration shall support fast handoffs
      > 8) Regional registration shall not require changes to the
      > mobile node, the
      > home agent, or correspondent nodes
      > 9) Regional registration shall not introduce host routes in
      > routing tables

      I agree with Theo comments about host route. The LMM SHOULD minimize the amount of host routes in the routers.

      - Hongyi

------_=_NextPart_001_01C0C38D.CC08FCC0-- From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 12 16:47: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 QAA10569 for ; Thu, 12 Apr 2001 16:47: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 NAA17874; Thu, 12 Apr 2001 13:46:13 -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 NAA29447; Thu, 12 Apr 2001 13:46:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CKifK9021006 for ; Thu, 12 Apr 2001 13:44:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3CKifv7021005 for mobile-ip-dist; Thu, 12 Apr 2001 13:44: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CKiVK9020998 for ; Thu, 12 Apr 2001 13:44:32 -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 NAA24226 for ; Thu, 12 Apr 2001 13:44:30 -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 NAA16492 for ; Thu, 12 Apr 2001 13:44:25 -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 NAA18412 for ; Thu, 12 Apr 2001 13:44:21 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3CKiHX26562 for ; Thu, 12 Apr 2001 13:44:17 -0700 X-mProtect: Thu, 12 Apr 2001 13:44:17 -0700 Nokia Silicon Valley Messaging Protection Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "cs.ucl.ac.uk") by darkstar.iprg.nokia.com(WTS.12.69) smtpd5uBZUa; Thu, 12 Apr 2001 13:44:07 PDT Message-ID: <3AD6139B.4C826296@cs.ucl.ac.uk> Date: Thu, 12 Apr 2001 13:44:11 -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: [Fwd: Re: [mobile-ip] IPv6 Regional Registration - identifying requirem ents] 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 Muhammad, I would second Karim and Phil, that the so-called route optimization requirement is rather redundant since the core MIPv6 protocol takes care of route optimization. The rate with which mobile peers (that is CNs and MNs) update their bindings is all I can understand from your interpretation of no.10. And such issue depends totally on the peers, I cannot see where the protocol kicks in, in this one. I think we are arguing over a non-existent issue here, but perhaps one can convince us for the opposite . At the moment personally I stand unconvinced. Theo UCL/ Mobile Systems "Karim El-Malki (ERA)" wrote: > I can't understand the route opt. requirement either. > The MN supports MIPv6 and can decide whether it wants to > use the local anchor point or not when sending BUs to CNs. > There is no need to require anything from the local anchor > point itself. I believe that the HMIPv6 draft has a > note on this. If the MN determines that the CN lies within > its same (MAP) site then it may decide to communicate directly > with the CN. > Regards > /Karim > > -----Original Message----- > From: Phil Roberts > To: 'mobile-ip@sunroof.eng.sun.com' > Sent: 2001-04-11 22:26 > Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents > > Agreed. But I can't tell from the requirement what exactly is > required. Is it something like "2 MNs behind the same LMA shall use an > optimized route that doesn't go through the LMA?" > > > -----Original Message----- > From: Muhammad Jaseemuddin [mailto:jaseem@nortelnetworks.com] > Sent: Wednesday, April 11, 2001 4:21 PM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying > requirem ents > > Phil: > > Route optimization does not fully optimize the route in case of any > form of regional registration. e.g. HMIPv6. For example if the CN is > outside the domain, then the packets will follow the optimized path upto > the local mobility anchor point (MAP), and then follow the optimal path > to the mobile. If the MAP is not co-located with the border routers, > then the scheme does not use optimal route from the border routers to > the mobile. This situation becomes more conspicous if the CN is another > mobile within the domain but necessarily on the same subnet as the the > subnet on which the mobile's AR is connected. One can argue that in that > case MN should send BU to CN with its LCOA if it (somehow) discovers > that the CN is actually a mobile in the same domain. Then, intra-MAP > domain signaling will be increased and the benefit of MAP will be less > obvious. > > What I interepreted from Hongyi's requirement 10 is to address the > above issue? > > Cheers, > - Muhammad Jaseemuddin > > > -----Original Message----- > From: Phil Roberts [SMTP:PRoberts@MEGISTO.com] > Sent: Tuesday, April 10, 2001 10:35 AM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying > requirem ents > > Hi, > > I'm a little confused about your req 10. MIP v6 already has route > optimization. Do you envision req 10 to provide an alternative to that > or to interoperate with that or ... something else? > > > Thanks, > Phil > > > -----Original Message----- > From: Hongyi Li [ mailto:hyli@nortelnetworks.com > ] > Sent: Tuesday, April 10, 2001 10:21 AM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying > requirem ents > > Hi Phil, > Here are few more requirements I think that are impportant for RR/LMM > (I like > the term localized mobility management too): > > 10) LMM SHALL provide optimized routing for mobile-to-mobile > communication. > 11) LMM SHOULD minimize the number of network nodes affected by handoff > signals. > 12) LMM SHOULD support auto-configuration capabilities for mobile > agents/FAs, access routers. > 13) LMM SHOULD simplify the network design and provisioning for > enabling LMM > capability in a network and allow progressive LMM deployment > capabilities. > > Some more comments in lines: > > > 1) Regional registration shall be introduced to minimize the signaling > > traffic to the home agent or correspondent nodes for > > intra-domain mobility > > 2) Regional registration shall not introduce new overhead on > > links between > > the mobile and the regional registration agents > > 3) Connectivity to the mobiles shall not be interrupted in > > the presence of > > the failure of regional registration agents > > 4) Regional registration shall scale to support millions of nodes in a > > visited network > > LMM SHALL be scalable in terms of number of connected users > (i.e., active + dormant = millions) and the number of users on the > move. > > > 5) Regional registration shall be secure against malicious > > behavior from > > visiting mobiles > > 6) Regional registration shall allow multiple levels of hierarchy > > 7) Regional registration shall support fast handoffs > > 8) Regional registration shall not require changes to the > > mobile node, the > > home agent, or correspondent nodes > > 9) Regional registration shall not introduce host routes in > > routing tables > > I agree with Theo comments about host route. The LMM SHOULD > minimize the amount of host routes in the routers. > > - Hongyi From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 12 16:48:13 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10643 for ; Thu, 12 Apr 2001 16:48:13 -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 NAA12420; Thu, 12 Apr 2001 13:44: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 NAA29653; Thu, 12 Apr 2001 13:46:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CKjTK9021016 for ; Thu, 12 Apr 2001 13:45:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3CKjSWA021015 for mobile-ip-dist; Thu, 12 Apr 2001 13:45: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CKjEK9021008 for ; Thu, 12 Apr 2001 13:45:15 -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 NAA01709 for ; Thu, 12 Apr 2001 13:45:13 -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 NAA26720 for ; Thu, 12 Apr 2001 13:45:13 -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 NAA18508 for ; Thu, 12 Apr 2001 13:45:12 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3CKjB627434 for ; Thu, 12 Apr 2001 13:45:11 -0700 X-mProtect: Thu, 12 Apr 2001 13:45:11 -0700 Nokia Silicon Valley Messaging Protection Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "cs.ucl.ac.uk") by darkstar.iprg.nokia.com(WTS.12.69) smtpdCMn6se; Thu, 12 Apr 2001 13:45:06 PDT Message-ID: <3AD613D2.225B097E@cs.ucl.ac.uk> Date: Thu, 12 Apr 2001 13:45: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: [mobile-ip] [Fwd: Re: Eliminating Triangle Routing and RegReg: A Requirement? (RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents)] 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, I agree with what you said, but I think we knew that as soon as the notion of LMM was coming into effect as a valid extension of base MIPv6. I agree with the flexibility issue raised but I think that was a fundamental freedom in any LMM scheme I have read so far. I also think that triangular routing is what it would look like, however it would not be suboptimal if the GMA/MAP is positioned at the border router. So one leg of the triangle goes away for sure. The border router is the only door to the domain so it will go through that anyway. Intermediate routes are transparent (dynamic) so we couldn't care less on these. About the leg from the GMA/MAP to the MN: I believe that the leg CAN ONLY correspond to the normal routing paths that the MN-bound traffic would take without RegReg. What else could it be? I cannot see any _non-normal_ routing paths that could possible come in effect and really become candidates for the routing leg of the mobility agent towards the MN. We are arguing here on a "ghost" requirement about a tradeoff which is the very essence of the extension. I don't think we will ever catch that without killing the extension. Theo UCL/ Mobile Systems Now apart from recognizing James Kempf wrote: > Phil/Karim, > > I think the problem is that both RegReg proposals currently reintroduce > triangle routing. The elimination of triangle routing was viewed as > one of the big steps forward with MIPv6. Granted, the fact that the MAP/GFA is > topologically closer to the mobile node means that the size of the mobile-bound > leg will be smaller. And, since the network engineer has complete freedom to > place the MAP/GFA as they choose, it could be placed at a border router, where > the mobile-bound packets have to come through anyway. > > I can't see much possibility for getting around this if the regional care > of address is to remain unchanged. There is basically a contradiction > between the major requirement of RegReg to reduce signalling over wide > areas and the need for a binding update when the mobile changes care of > address in order to eliminate triangle routing. > > Therefore, I think a perhaps better way to handle this would be to > make sure that the RegReg hierarchical agent is designed flexibly > enough so that it can be placed at any point in the network: > > Recognizing that triangle routing is unavoidable if signalling > is to be reduced over a wide area, the RegReg protocol MUST > be designed such that intermediate agents/routers can be > flexibly inserted into the path of mobile-bound traffic such > that the triangle legs correspond to the normal routing > paths that mobile-bound traffic would take without RegReg. > > Or something like that. > > jak From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 12 16:48:48 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10682 for ; Thu, 12 Apr 2001 16:48:47 -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 NAA12964; Thu, 12 Apr 2001 13:46:00 -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 NAA24956; Thu, 12 Apr 2001 13:47:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CKkKK9021026 for ; Thu, 12 Apr 2001 13:46:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3CKkJcZ021025 for mobile-ip-dist; Thu, 12 Apr 2001 13:46: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CKk1K9021018 for ; Thu, 12 Apr 2001 13:46:01 -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 NAA01869 for ; Thu, 12 Apr 2001 13:46:00 -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 NAA23521 for ; Thu, 12 Apr 2001 13:45:59 -0700 (PDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Thu, 12 Apr 2001 16:40:26 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents Date: Thu, 12 Apr 2001 16:40:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C390.CD53DD4A" Sender: owner-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_01C0C390.CD53DD4A Content-Type: text/plain; charset="iso-8859-1" OK. I was just trying to get at what you were asking for. It sounds like you want some entity (the mobile) to determine whether the direct path to the CN is more efficient than the path to the CN through the LMM agent, and if so, to choose that path. Is that correct? -----Original Message----- From: Hongyi Li [mailto:hyli@nortelnetworks.com] Sent: Thursday, April 12, 2001 4:19 PM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents Hi Phil, Optimize routing is a goal for MIPv6 and it should be the goal for LMM/RR as well. This requirement simply requires that the data packets between two communicating nodes (regardless of where the two nodes are) take the path selected by the native IP routing protocol (e.g., OSPF). An example of non-optimized path is that if an anchor node is not on the optimal path between two communicating nodes and packets still travel through that anchor anchor node (triangular routing). This is just a proposed requirement. I am not arguing whether a particular protocol can meet the requirement or not. -Hongyi -----Original Message----- From: Phil Roberts [mailto:PRoberts@MEGISTO.com] Sent: Wednesday, April 11, 2001 4:26 PM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents Agreed. But I can't tell from the requirement what exactly is required. Is it something like "2 MNs behind the same LMA shall use an optimized route that doesn't go through the LMA?" -----Original Message----- From: Muhammad Jaseemuddin [mailto:jaseem@nortelnetworks.com] Sent: Wednesday, April 11, 2001 4:21 PM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents Phil: Route optimization does not fully optimize the route in case of any form of regional registration. e.g. HMIPv6. For example if the CN is outside the domain, then the packets will follow the optimized path upto the local mobility anchor point (MAP), and then follow the optimal path to the mobile. If the MAP is not co-located with the border routers, then the scheme does not use optimal route from the border routers to the mobile. This situation becomes more conspicous if the CN is another mobile within the domain but necessarily on the same subnet as the the subnet on which the mobile's AR is connected. One can argue that in that case MN should send BU to CN with its LCOA if it (somehow) discovers that the CN is actually a mobile in the same domain. Then, intra-MAP domain signaling will be increased and the benefit of MAP will be less obvious. What I interepreted from Hongyi's requirement 10 is to address the above issue? Cheers, - Muhammad Jaseemuddin -----Original Message----- From: Phil Roberts [SMTP:PRoberts@MEGISTO.com] Sent: Tuesday, April 10, 2001 10:35 AM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents Hi, I'm a little confused about your req 10. MIP v6 already has route optimization. Do you envision req 10 to provide an alternative to that or to interoperate with that or ... something else? Thanks, Phil -----Original Message----- From: Hongyi Li [ mailto:hyli@nortelnetworks.com ] Sent: Tuesday, April 10, 2001 10:21 AM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents Hi Phil, Here are few more requirements I think that are impportant for RR/LMM (I like the term localized mobility management too): 10) LMM SHALL provide optimized routing for mobile-to-mobile communication. 11) LMM SHOULD minimize the number of network nodes affected by handoff signals. 12) LMM SHOULD support auto-configuration capabilities for mobile agents/FAs, access routers. 13) LMM SHOULD simplify the network design and provisioning for enabling LMM capability in a network and allow progressive LMM deployment capabilities. Some more comments in lines: > 1) Regional registration shall be introduced to minimize the signaling > traffic to the home agent or correspondent nodes for > intra-domain mobility > 2) Regional registration shall not introduce new overhead on > links between > the mobile and the regional registration agents > 3) Connectivity to the mobiles shall not be interrupted in > the presence of > the failure of regional registration agents > 4) Regional registration shall scale to support millions of nodes in a > visited network LMM SHALL be scalable in terms of number of connected users (i.e., active + dormant = millions) and the number of users on the move. > 5) Regional registration shall be secure against malicious > behavior from > visiting mobiles > 6) Regional registration shall allow multiple levels of hierarchy > 7) Regional registration shall support fast handoffs > 8) Regional registration shall not require changes to the > mobile node, the > home agent, or correspondent nodes > 9) Regional registration shall not introduce host routes in > routing tables I agree with Theo comments about host route. The LMM SHOULD minimize the amount of host routes in the routers. - Hongyi ------_=_NextPart_001_01C0C390.CD53DD4A Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents
OK.  I was just trying to get at what you were asking for.  It sounds like you want some
entity (the mobile) to determine whether the direct path to the CN is more efficient than
the path to the CN through the LMM agent, and if so, to choose that path.  Is that
correct?
 
-----Original Message-----
From: Hongyi Li [mailto:hyli@nortelnetworks.com]
Sent: Thursday, April 12, 2001 4:19 PM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents

Hi Phil,
 
  Optimize routing is a goal for MIPv6 and it should be the goal for LMM/RR as well.
This requirement simply requires that the data packets between two communicating
nodes (regardless of where the two nodes are) take the path selected by the native
IP routing protocol (e.g., OSPF).
 
  An example of non-optimized path is that if an anchor node is not on the optimal
path between two communicating nodes and packets still travel through that anchor
anchor node (triangular routing).
 
  This is just a proposed requirement. I am not arguing whether a particular protocol
can meet the requirement or not. 
 
-Hongyi
 
-----Original Message-----
From: Phil Roberts [mailto:PRoberts@MEGISTO.com]
Sent: Wednesday, April 11, 2001 4:26 PM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents

Agreed.   But I can't tell from the requirement what exactly is required.  Is it something like "2 MNs behind the same LMA shall use an optimized route that doesn't go through the LMA?"
 
-----Original Message-----
From: Muhammad Jaseemuddin [mailto:jaseem@nortelnetworks.com]
Sent: Wednesday, April 11, 2001 4:21 PM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents

Phil:

 Route optimization does not fully optimize the route in case of any form of regional registration. e.g. HMIPv6. For example if the CN is outside the domain, then the packets will follow the optimized path upto the local mobility anchor point (MAP), and then follow the optimal path to the mobile. If the MAP is not co-located with the border routers, then the scheme does not use optimal route from the border routers to the mobile. This situation becomes more conspicous if the CN is another mobile within the domain but necessarily on the same subnet as the the subnet on which the mobile's AR is connected. One can argue that in that case MN should send BU to CN with its LCOA if it (somehow) discovers that the CN is actually a mobile in the same domain. Then, intra-MAP domain signaling will be increased and the benefit of MAP will be less obvious.

 What I interepreted from Hongyi's requirement 10 is to address the above issue?

Cheers,
- Muhammad Jaseemuddin
 

    -----Original Message-----
    From:   Phil Roberts [SMTP:PRoberts@MEGISTO.com]
    Sent:   Tuesday, April 10, 2001 10:35 AM
    To:     'mobile-ip@sunroof.eng.sun.com'
    Subject:        RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents

    Hi,
     
    I'm a little confused about your req 10.  MIP v6 already has route optimization.  Do you envision req 10 to provide an alternative to that or to interoperate with that or ... something else?


    Thanks,
    Phil
     

      -----Original Message-----
      From: Hongyi Li [mailto:hyli@nortelnetworks.com]
      Sent: Tuesday, April 10, 2001 10:21 AM
      To: 'mobile-ip@sunroof.eng.sun.com'
      Subject: RE: [mobile-ip] IPv6 Regional Registration - identifying requirem ents

      Hi Phil,
        Here are few more requirements I think that are impportant for RR/LMM (I like
      the term localized mobility management too):

       10) LMM SHALL provide optimized routing for mobile-to-mobile communication.
       11) LMM SHOULD minimize the number of network nodes affected by handoff signals.
       12) LMM SHOULD support auto-configuration capabilities for mobile agents/FAs, access routers.
       13) LMM SHOULD simplify the network design and provisioning for enabling LMM
      capability in a network and allow progressive LMM deployment capabilities.

      Some more comments in lines:
        
      > 1) Regional registration shall be introduced to minimize the signaling
      > traffic to the home agent or correspondent nodes for
      > intra-domain mobility
      > 2) Regional registration shall not introduce new overhead on
      > links between
      > the mobile and the regional registration agents
      > 3) Connectivity to the mobiles shall not be interrupted in
      > the presence of
      > the failure of regional registration agents
      > 4) Regional registration shall scale to support millions of nodes in a
      > visited network

      LMM SHALL be scalable in terms of number of connected users (i.e., active + dormant =  millions) and the number of users on the move.

      > 5) Regional registration shall be secure against malicious
      > behavior from
      > visiting mobiles
      > 6) Regional registration shall allow multiple levels of hierarchy
      > 7) Regional registration shall support fast handoffs
      > 8) Regional registration shall not require changes to the
      > mobile node, the
      > home agent, or correspondent nodes
      > 9) Regional registration shall not introduce host routes in
      > routing tables

      I agree with Theo comments about host route. The LMM SHOULD minimize the amount of host routes in the routers.

      - Hongyi

------_=_NextPart_001_01C0C390.CD53DD4A-- From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 12 17:39:25 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11612 for ; Thu, 12 Apr 2001 17:39:24 -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 OAA05289; Thu, 12 Apr 2001 14:36: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 OAA14402; Thu, 12 Apr 2001 14:35:41 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CLXdK9021310 for ; Thu, 12 Apr 2001 14:33:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3CLXc8P021309 for mobile-ip-dist; Thu, 12 Apr 2001 14:33: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 jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CLXUK9021302 for ; Thu, 12 Apr 2001 14:33:30 -0700 (PDT) Received: from locked (locked.Eng.Sun.COM [129.146.85.189]) by jurassic.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with SMTP id f3CLXVB2465124; Thu, 12 Apr 2001 14:33:31 -0700 (PDT) Message-Id: <200104122133.f3CLXVB2465124@jurassic.eng.sun.com> Date: Thu, 12 Apr 2001 14:32:13 -0700 (PDT) From: Mohan Parthasarathy Subject: Re: [mobile-ip] -New ID about Address owernship- To: claude.castelluccia@inrialpes.fr, mobile-ip@sunroof.eng.sun.com Cc: hipsec@mail.freeswan.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: HeIGLXkBUPPtC9lIFth0Hw== 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: > > > > Notice that the exchange at step 2 must be secure in order to > > avoid intruder-in-the-middle attacks, but it is an improvement > > over cookies. > > > >Could you explain how you are communicating the public key securely > >in your protocol ? I have not read all the details of HIP, so > >i could be missing something. > > > In the context of MIPV6 you don't need to send the public key securely. > The home address is binded to the MN's public key and the msg2 (that > included the > BU) is signed by the MN's private key... > > An intruder-in-the-middle could intercepts msg2 and send a fake one to the > CN. But this "fake" BU can > not use the MN's home address because the intruder won't be able to sign it > (because it does not > know the private key)....so it won't be able to redirect the trafic destined > to the MN.... the only think it could > do is to send a BU with a fake home address ....this won't be very > harmfull... > I am assuming that the HIP cookie is newly generated for every transaction and this should help prevent replay attacks when msg3 is replayed with an invalid signature. I could not verify this anywhere. In section 6.1, you are allowing the possiblity of configuring a new coA with a new identifier. If you really have to prove that the CoA is not stolen, the identifiier should match that of the home address. So, i don't understand this part. This protocol solves the address ownership problem of the MN. But it does not really do any verification of the CN itself. It can be easily done by CN signing the message and sending the public key as part of msg2. But this is more work for the CN even before it can verify that the MN is a valid one or not. -mohan > did I answer your question? > > regards, > > Claude. > > > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 12 17:41:43 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11696 for ; Thu, 12 Apr 2001 17:41: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 OAA06706; Thu, 12 Apr 2001 14:39:09 -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 OAA12072; Thu, 12 Apr 2001 14:40:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CLdJK9021330 for ; Thu, 12 Apr 2001 14:39:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3CLdIgC021329 for mobile-ip-dist; Thu, 12 Apr 2001 14:39:18 -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.84.31] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CLdAK9021322 for ; Thu, 12 Apr 2001 14:39:10 -0700 (PDT) Received: from locked (locked.Eng.Sun.COM [129.146.85.189]) by jurassic.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with SMTP id f3CLdBB2466000; Thu, 12 Apr 2001 14:39:11 -0700 (PDT) Message-Id: <200104122139.f3CLdBB2466000@jurassic.eng.sun.com> Date: Thu, 12 Apr 2001 14:37:53 -0700 (PDT) From: Mohan Parthasarathy Subject: Re: [mobile-ip] -New ID about Address owernship- To: Francis.Dupont@enst-bretagne.fr, mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: R11y+lAk0a/J1TUVQQNrzA== 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: > X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f > From: Francis Dupont > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] -New ID about Address owernship- > Date: Thu, 12 Apr 2001 02:22:09 +0200 > List-Archive: > List-Owner: > List-Subscribe: > List-Unsubscribe: If SUCV addresses are used in a very temporary way (RFC 3041 > > with a new address per connection for instance) the computation > of the public/private key pairs can become very expensive... But this implies that the identifier part of your home address changes too. So, i don't understand how this would work. -mohan > But the document does not specify what is the format of the > public part (the argument of the hash function) so I suggest > to add a random part in it: > - i.e. hash(public-part) becomes hash(public-part || random-value) > - the random part should large enough in order to avoid (hash) collision > with the same key pair (so 64 bits again?) > - the same argument proves that the random part should be really random > or an attacker can harm with collisions (*) > - short term new ID should be done with a new random value, long term > with a new key pair > - in case of a (real) collision to provide a new random value is > far cheaper than to compute a new key pair > - analysis (section 4.4) is based on the hash function strength and > result space so the introduction of a random part won't change this. > > (*) weak attacks because if the bad guy can know the public key and > can guess the random value he doesn't know the private key so the > signature check will fail (i.e. there is room only for a DoS attack). > > Regards > > Francis.Dupont@enst-bretagne.fr > > PS: in 5.0 the IID should not have the 'u' bit set because the low HIT-64 > is not really *universally* unique. The 4.4 argument doesn't apply because > there are/will be more than 3*10^9 MAC devices in the Universe... > In fact this doesn't really matter because the low part of HIT-64 has > no need to be universal? > PPS: in 4.4 the argument about collisions is valid only in the Mobile IPv6 > context, i.e. you shan't bet one million dollars on it. The context should > be recalled in the last statement (just in order to avoid misuse of your > nice proposal in a very different context :-). From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 12 17:56: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 RAA11844 for ; Thu, 12 Apr 2001 17:56: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 OAA10717; Thu, 12 Apr 2001 14:55: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 OAA12947; Thu, 12 Apr 2001 14:55:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CLrfK9021380 for ; Thu, 12 Apr 2001 14:53:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3CLrf7u021379 for mobile-ip-dist; Thu, 12 Apr 2001 14:53: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CLrWK9021372 for ; Thu, 12 Apr 2001 14:53: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 OAA18637 for ; Thu, 12 Apr 2001 14:53:33 -0700 (PDT) Message-Id: <200104122153.OAA18637@heliopolis.eng.sun.com> Date: Thu, 12 Apr 2001 14:53:33 -0700 (PDT) From: James Kempf Subject: [mobile-ip] Involvement w. 3Gs? (context transfer from Seamoby) To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Y7vXfTV6dE7eaFfRPOtunQ== 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: A debate has been going on on the Seamoby list about how involved the MIP group should be with the 3Gs, but it looked like here was rather the right place to have it. One issue that comes up to me is the following. The MIP group has tried to work with the 3Gs over the last few years, and has had moderate success with 3GPP2. They are using MIP, we have successfully developed several enhancements to their packet architecture more or less collaboratively together with them, they are committed to working together with us in the future, and we have good working relationships with TSG-P members. The same cannot be said of 3GPP. They have a competing IP mobility standard which they have continued to push. At an IEE conference in London a few weeks ago, a paper was given announcing a plan to do inter-GGSN GPRS transfer (called GPRX). The R99 spec for 3GPP specifies that this should be done through mobile IP, but no 3GPP vendor implements it and none of the mobile operators are deploying it. They have shown no interest in working with IETF to resolve this. Naturally, the next step is when 3GPP operators begin deploying 802.11 networks, they start using GPRS for that as well. So the issue is, what should the IETF do about this (is there anything we *can* do)? It looks to me like 3GPP is now getting into the business of defining IP standards. Do we maybe have to recognize that, like STD0048 and STD0019 for NetBios, GPRS is becoming a de facto standard and try to bring it into IETF? Or should we rather be pushing back on them in some way to deploy mobile IP, like R99 says? Or should we simply ignore them and instead work on getting mobility integrated more deeply into the IPng core, hoping they will sink under the load of their spectrum auction debt? jak From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 12 18:09:23 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12114 for ; Thu, 12 Apr 2001 18:09:23 -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 PAA19070; Thu, 12 Apr 2001 15:07:00 -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 PAA16762; Thu, 12 Apr 2001 15:08:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CM6UK9021449 for ; Thu, 12 Apr 2001 15:06:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3CM6TrA021448 for mobile-ip-dist; Thu, 12 Apr 2001 15:06: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CM6KK9021441 for ; Thu, 12 Apr 2001 15:06:21 -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 PAA22722 for ; Thu, 12 Apr 2001 15:06:16 -0700 (PDT) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id QAA29933 for ; Thu, 12 Apr 2001 16:10:00 -0600 (MDT) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Thu Apr 12 18:02:26 EDT 2001 Received: from valjean.dnrc.bell-labs.com (valjean [135.180.240.120]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id SAA11483 for ; Thu, 12 Apr 2001 18:04:51 -0400 (EDT) Received: (from salga@localhost) by valjean.dnrc.bell-labs.com (8.11.0/8.8.7) id f3CM4dn28051 for mobile-ip@sunroof.eng.sun.com; Thu, 12 Apr 2001 18:04:39 -0400 Date: Thu, 12 Apr 2001 18:04:39 -0400 From: Luca Salgarelli To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] dynamic home addressing as a WG item?? Message-ID: <20010412180439.H4902@bell-labs.com> Mail-Followup-To: mobile-ip@sunroof.eng.sun.com References: <200104121825.LAA11866@heliopolis.eng.sun.com> <01fa01c0c386$f8749dc0$6501a8c0@philneum> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01fa01c0c386$f8749dc0$6501a8c0@philneum>; from neumiller@telocity.com on Thu, Apr 12, 2001 at 02:29:56PM -0500 X-Organization: Bell Laboratories Sender: owner-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. I think I agree with Phil on this. I am not comfortable with the idea of coupling a routing protocol with something needed to distribute configuration information. I think that a clean separation between the two is needed. > OK, then what would you suggest? I think extending > DHCP to the mobile is just as much of a hack. I don't see why you consider "extending DHCP" to the mobile a hack: Mobile-IP is designed to transparently hide the movements of the client. So I don't see why you would see letting DHCP "transparently" run on top of the Mobile-IP tunnel a hack. Luca On Thu, Apr 12, 2001 at 02:29:56PM -0500, Phil Neumiller wrote: > Hi James, > > I have a comment on your suggestion to Sandy below. > ----- Original Message ----- > From: "James Kempf" > To: > Sent: Thursday, April 12, 2001 1:25 PM > > > I think that it would be better to come up with > > a lightweight way of doing this, rather than > > requiring DHCP relays and reverse tunnels. > > A simple extension to MIP that allows an > > HA to send configuration information in > > a registration reply would do the trick. > > I would say its a "hack" not a trick and it has the negative > effect of putting a routing protocol (MIP) under the yoke > of something that is clearly an application layer duty. > DON'T DO IT! (That's how I really feel James...) > > -pdn From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 12 18:13: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 SAA12157 for ; Thu, 12 Apr 2001 18:13: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 PAA23193; Thu, 12 Apr 2001 15:13: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 PAA18165; Thu, 12 Apr 2001 15:13:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CMBiK9021490 for ; Thu, 12 Apr 2001 15:11:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3CMBiHV021489 for mobile-ip-dist; Thu, 12 Apr 2001 15:11: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CMBZK9021481 for ; Thu, 12 Apr 2001 15:11:35 -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 PAA19674 for ; Thu, 12 Apr 2001 15:11:30 -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 QAA02633 for ; Thu, 12 Apr 2001 16:15:14 -0600 (MDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Thu, 12 Apr 2001 18:05:57 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Involvement w. 3Gs? (context transfer from Seamob y) Date: Thu, 12 Apr 2001 18:05:57 -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: James Kempf [mailto:James.Kempf@Sun.COM] > Sent: Thursday, April 12, 2001 5:54 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] Involvement w. 3Gs? (context transfer > from Seamoby) > > > A debate has been going on on the Seamoby list about how involved the > MIP group should be with the 3Gs, but it looked like here was rather > the right place to have it. Hi Jim, > > One issue that comes up to me is the following. The MIP group > has tried to > work with the 3Gs over the last few years, and has had > moderate success > with 3GPP2. They are using MIP, we have successfully developed several > enhancements to their packet architecture more or less collaboratively > together with them, they are committed to working together with us > in the future, and we have good working relationships with > TSG-P members. > A large part of this is due to the fact that there was significant cross polination between the two SDOs, which is IMO a good thing. > The same cannot be said of 3GPP. They have a competing IP mobility > standard which they have continued to push. At an IEE > conference in London a > few weeks ago, a paper was given announcing a plan to do inter-GGSN > GPRS transfer (called GPRX). The R99 spec for 3GPP specifies that this > should be done through mobile IP, but no 3GPP vendor implements it > and none of the mobile operators are deploying it. They have > shown no interest in working with IETF to resolve this. > Naturally, the next step is when 3GPP operators begin deploying 802.11 > networks, they start using GPRS for that as well. I'm not sure this is all that natural. I can't say that I've never heard anyone propose something like this, but I don't think there are standards in place from the 3GPP to facilitate this easily. The GGSN has specified interfaces to an MT and an SGSN and an MT has specified interfaces for the air, to an SGSN, and to a GGSN (among other specified interfaces). None of these seem naturally detachable from the other, and don't seem easily to allow an MN to speak to a router across 802.11. One might think the operators might find it easier to use some already existing IETF protocols in a more creative way to enable this kind of service. > > So the issue is, what should the IETF do about this (is there anything > we *can* do)? It looks to me like 3GPP is now getting into the > business of defining IP standards. Do we maybe have to recognize that, > like STD0048 and STD0019 for NetBios, GPRS is becoming a de > facto standard and > try to bring it into IETF? Or should we rather be pushing > back on them in some > way to deploy mobile IP, like R99 says? Or should we simply > ignore them and > instead work on getting mobility integrated more deeply into > the IPng core, > hoping they will sink under the load of their spectrum auction debt? Good questions to which I have no good answers. Certainly we have some immediate goals to complete the MIP specs. I don't see a clear path for bringing GPRS into the IETF - it has lots of tentacles. What do you have in mind? > > jak > From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 12 18:27: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 SAA12434 for ; Thu, 12 Apr 2001 18:27: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 PAA02112; Thu, 12 Apr 2001 15:27:01 -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 PAA27005; Thu, 12 Apr 2001 15:26:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CMPWK9021542 for ; Thu, 12 Apr 2001 15:25:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3CMPVaV021541 for mobile-ip-dist; Thu, 12 Apr 2001 15:25: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CMPNK9021534 for ; Thu, 12 Apr 2001 15:25:23 -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 PAA19666 for ; Thu, 12 Apr 2001 15:25:23 -0700 (PDT) Message-Id: <200104122225.PAA19666@heliopolis.eng.sun.com> Date: Thu, 12 Apr 2001 15:25:24 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] dynamic home addressing as a WG item?? To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 5Olg6LV564q2YLDju5RgkQ== 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 Luca, >I think I agree with Phil on this. I am not comfortable with the idea of >coupling a routing protocol with something needed to distribute >configuration information. > But you are comfortable with having an address provisioning mechanism distribute service discovery and configuration information? Curious. >I think that a clean separation between the two is needed. > >> OK, then what would you suggest? I think extending >> DHCP to the mobile is just as much of a hack. > >I don't see why you consider "extending DHCP" to the mobile a hack: >Mobile-IP is designed to transparently hide the movements of the client. So >I don't see why you would see letting DHCP "transparently" run on top of >the Mobile-IP tunnel a hack. > > I consider it a hack because it involves a lot of mechanism (DHCP relays, reverse tunneling) that is unnecessary. Besides, there is no requirement for the home network to use DHCP to configure the mobile node, it could use something different (LDAP for example). I rather think the hiding should be done by on the mobile side, so that it does not have to deal with how the home network configures. Hmm, is this perhaps the problem? You, Sandy, and maybe Phil view the mobile node as being an extension of the home network, correct? This is the traditional mobile IP view. I have rather a different view. I view the mobile node as mostly away from the home network, not really bound to it except though routing. So a possible, even likely, situation is that the mobile node gets a locally assigned home address every time it comes up in someone's network. As a result, the mobile node should be getting the configuration information from where the home address is assigned, and I view it as rather too burdensome to require every wireless network operator to have to deploy DHCP. Besides, as I said at the beginning of this thread, I don't see why every mobile node in the world has to essentially support two address provisioning mechanisms, mobile IP and DHCP. Phil's comments notwidthstanding, mobile IP does not just do routing, it also does address configuration. We need to find out some other way of doing lightweight configuration, since that is all DHCP will be used for on the mobile node. Maybe what we need is "DHCP lite" that extracts out the configuration part of DHCP and gets rid of the need for a reverse tunnel for broadcast. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 12 18:38:51 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12631 for ; Thu, 12 Apr 2001 18:38: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 PAA01524; Thu, 12 Apr 2001 15:36:08 -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 PAA29885; Thu, 12 Apr 2001 15:37:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CMaQK9021590 for ; Thu, 12 Apr 2001 15:36:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3CMaPsU021589 for mobile-ip-dist; Thu, 12 Apr 2001 15:36: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CMaHK9021582 for ; Thu, 12 Apr 2001 15:36:17 -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 PAA19949 for ; Thu, 12 Apr 2001 15:36:17 -0700 (PDT) Message-Id: <200104122236.PAA19949@heliopolis.eng.sun.com> Date: Thu, 12 Apr 2001 15:36:17 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] Involvement w. 3Gs? (context transfer from Seamob y) To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: MBFZLXFcTN4l8PG0a+6EEg== 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 Phil, >> So the issue is, what should the IETF do about this (is there anything >> we *can* do)? It looks to me like 3GPP is now getting into the >> business of defining IP standards. Do we maybe have to recognize that, >> like STD0048 and STD0019 for NetBios, GPRS is becoming a de >> facto standard and >> try to bring it into IETF? Or should we rather be pushing >> back on them in some >> way to deploy mobile IP, like R99 says? Or should we simply >> ignore them and >> instead work on getting mobility integrated more deeply into >> the IPng core, >> hoping they will sink under the load of their spectrum auction debt? > >Good questions to which I have no good answers. Certainly we have some >immediate goals to complete the MIP specs. I don't see a clear path for >bringing GPRS into the IETF - it has lots of tentacles. What do you have in >mind? > > I've got no easy answers either, unfortunately. Trying to bring GPRS into IETF at this point would probably not work, as you say, yet I don't think we can ignore it. Maybe we can look into doing something like IPng is doing with their interim meeting, in which they've invited some 3GPP SA2 members to attend. We should probably at least be trying to get a dialog going somehow. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 12 18:46: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 SAA12760 for ; Thu, 12 Apr 2001 18:46: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 PAA16209; Thu, 12 Apr 2001 15:46:33 -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 PAA22944; Thu, 12 Apr 2001 15:46:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CMj5K9021810 for ; Thu, 12 Apr 2001 15:45:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3CMj4EP021809 for mobile-ip-dist; Thu, 12 Apr 2001 15:45: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CMilK9021775 for ; Thu, 12 Apr 2001 15:44: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 PAA25917 for ; Thu, 12 Apr 2001 15:44:47 -0700 (PDT) Received: from c007.snv.cp.net (c007-h000.c007.snv.cp.net [209.228.33.206]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA23682 for ; Thu, 12 Apr 2001 15:44:46 -0700 (PDT) Received: (cpmta 14422 invoked from network); 12 Apr 2001 15:44:46 -0700 Received: from unknown (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.206) with SMTP; 12 Apr 2001 15:44:46 -0700 X-Sent: 12 Apr 2001 22:44:46 GMT Message-ID: <028601c0c3a2$0bdfaba0$6501a8c0@philneum> From: "Phil Neumiller" To: References: Subject: Re: [mobile-ip] Involvement w. 3Gs? (context transfer from Seamoby) Date: Thu, 12 Apr 2001 17:43:44 -0500 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: Since I ah, sortof, kind-of started this rant, I had a few more words... ----- Original Message ----- From: "Phil Roberts" > > > -----Original Message----- > > So the issue is, what should the IETF do about this (is there anything > > we *can* do)? It looks to me like 3GPP is now getting into the > > business of defining IP standards. Do we maybe have to recognize that, Actually, Jim just let them. We know that the IETF defines the architecture and standards for the global Internet. Eventually, even 3GPP will realize that they have little control over something as powerful and growing as the global Internet. What I am worried about is that we (the IETF) have been "paying them too much attention [ESPECIALLY in the MIP WG]!". Just ignore them! Let us get on with fixing the parts of the global Internet that are not up to snuff for carying voice and video and lets make IP mobility work for the human race, not just the 3GPP fat cats! I want every person on the planet to have IP access and the only feasible way to do this is with inexpensive wireless. Much of the world has yet to experience the joy of the WWW and the wealth of data internet access offers, this is by far a more important and might I add humanitarian goal for the IETF to pursue and it will raise the human spirit, standard of living, and provide opportunities for the world economy. I don't want to sound like a communist or socialist here, I believe that capitalism can work just fine in this environment, on the contrary what we have now is what amounts to "central planning" with the damn spectrum auctions (taxes)! > > like STD0048 and STD0019 for NetBios, GPRS is becoming a de > > facto standard and > > try to bring it into IETF? Why bring it into the IETF? That seems pretty dumb. Let them do their thing, since they claim it is better anyway. It is not consistent at all with the architecture of the global Internet, therefore ignore it. It will be transient like every cellular and wireless infrastructure before it. The Internet is not transient, it is the closest thing to being an immortal architecture that we have (warts and all). > >Or should we rather be pushing > > back on them in some > > way to deploy mobile IP, like R99 says? Or should we simply No pushing necessary. Lead by example. Why have we not given more attention to the UNII and ISM bands? In the US their are tons of grass root movements springing up in cities offering ISP wireless or even free wireless access. > > ignore them and > > instead work on getting mobility integrated more deeply into > > the IPng core, > > hoping they will sink under the load of their spectrum auction debt? This sounds like the plan I have advocated for years, of course everybody always yells at me for being a 3G hater when I say stuff like this. What happened to you James? :-) -pdn From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 12 18:56:57 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12987 for ; Thu, 12 Apr 2001 18:56:56 -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 PAA08844; Thu, 12 Apr 2001 15:54: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 PAA25065; Thu, 12 Apr 2001 15:56:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CMsmK9021918 for ; Thu, 12 Apr 2001 15:54:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3CMsmiJ021917 for mobile-ip-dist; Thu, 12 Apr 2001 15:54: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CMsdK9021910 for ; Thu, 12 Apr 2001 15:54: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 PAA29176 for ; Thu, 12 Apr 2001 15:54:35 -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 QAA21659 for ; Thu, 12 Apr 2001 16:58:18 -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 f3CMscg21192 for ; Thu, 12 Apr 2001 17:54:38 -0500 (CDT) Received: from daebh01nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 12 Apr 2001 17:54:32 -0500 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Thu, 12 Apr 2001 17:54:32 -0500 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B03213808@daeis07nok> To: mobile-ip@sunroof.eng.sun.com Cc: James.Kempf@Sun.COM Subject: RE: [mobile-ip] Involvement w. 3Gs? (context transfer from Seamob y) Date: Thu, 12 Apr 2001 17:54: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: James, > >A debate has been going on on the Seamoby list about how involved the >MIP group should be with the 3Gs, but it looked like here was rather >the right place to have it. > You are aware I suppose of liasions between the IETF and the 3Gs. And the 3G bodies are not unaware of Mobile IP but, "You can lead a horse to the water but...." >One issue that comes up to me is the following. The MIP group has tried to >work with the 3Gs over the last few years, and has had moderate success >with 3GPP2. They are using MIP, we have successfully developed several >enhancements to their packet architecture more or less collaboratively >together with them, they are committed to working together with us >in the future, and we have good working relationships with TSG-P members. > That's a good thing no doubt and especially for the Mobile IP WG and the protocol in general if it has to have a chance at being deployed on a large scale. >The same cannot be said of 3GPP. They have a competing IP mobility >standard which they have continued to push. Just because 3GPP does not use Mobile IP as the mobility protocol in the architecture, you cannot say that they have been any less co-operative with the IETF. And you do agree that there is nothing preventing running Mobile IP on top of 3GPP networks.... So if Mobile IP is deployed in the Internet and other IP networks on a large scale, you can think of the GGSN as your default router from the MN and still do Mobile IP. >At an IEE conference in London a >few weeks ago, a paper was given announcing a plan to do inter-GGSN >GPRS transfer (called GPRX). The R99 spec for 3GPP specifies that this >should be done through mobile IP, but no 3GPP vendor implements it >and none of the mobile operators are deploying it. They have >shown no interest in working with IETF to resolve this. Do you have any insights into why they would want to specify a new mechanism (GPRX)? After all as you said the R99 spec does include support for an FA in the GGSN and inter-GGSN transfers could be handled between the FAs. I am sure the Mobile IP WG would be able to satisfy the requirements for an inter-GGSN /FA transfer that are specific to 3GPP. Anyone here care to throw some more light on GPRX and why you cannot do this with Mobile IP? >Naturally, the next step is when 3GPP operators begin deploying 802.11 >networks, they start using GPRS for that as well. > Now I think you are starting to be a bit paranoid :) >So the issue is, what should the IETF do about this (is there anything >we *can* do)? It looks to me like 3GPP is now getting into the >business of defining IP standards. I disagree. I do not believe that 3GPP is interested in defining IP standards (Period). >Do we maybe have to recognize that, >like STD0048 and STD0019 for NetBios, GPRS is becoming a de facto >standard and try to bring it into IETF? Or should we rather be >pushing back on them in some way to deploy mobile IP, like R99 says? If there is enough clamoring for Mobile IP support (lots of PDAs, laptops and mobile devices running Mobile IP client software) , then operators will ensure that the R99 network does support Mobile IP (I guess you mean support an FA at the GGSN). I mean seriously how difficult is it for a vendor to incorporate an FA in the GGSN? Maybe some of the GGSN vendors can speak up and say if their GGSN does include an FA and Mobile IP support. >Or should we simply ignore them and instead work on getting mobility >integrated more deeply into the IPng core, hoping they will sink >under the load of their spectrum auction debt? > > jak > My view is that Mobile IP can and does address the needs of IP based mobile networks. If we can get the specs done from our side, we can pretty much leave trying to force someone to adopt it outside the scope of the WG. So we should focus on getting a good solid spec for mobility (If you build it, they....) -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 12 20:37: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 UAA14277 for ; Thu, 12 Apr 2001 20:37:25 -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 RAA17650; Thu, 12 Apr 2001 17:36:18 -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 RAA25744; Thu, 12 Apr 2001 17:36:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3D0YrK9022563 for ; Thu, 12 Apr 2001 17:34:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3D0YrN1022562 for mobile-ip-dist; Thu, 12 Apr 2001 17:34: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3D0YiK9022555 for ; Thu, 12 Apr 2001 17:34:45 -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 RAA15520 for ; Thu, 12 Apr 2001 17:34:44 -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 RAA06447 for ; Thu, 12 Apr 2001 17:34:44 -0700 (PDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Thu, 12 Apr 2001 20:29:12 -0400 Message-ID: From: Ken Rehbehn To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Involvement w. 3Gs? (context transfer from Seamob y) Date: Thu, 12 Apr 2001 20:29:11 -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: > >At an IEE conference in London a > >few weeks ago, a paper was given announcing a plan to do inter-GGSN > >GPRS transfer (called GPRX). The R99 spec for 3GPP specifies > that this > >should be done through mobile IP, but no 3GPP vendor implements it > >and none of the mobile operators are deploying it. They have > >shown no interest in working with IETF to resolve this. > > Do you have any insights into why they would want to specify a new > mechanism (GPRX)? After all as you said the R99 spec does include > support for an FA in the GGSN and inter-GGSN transfers could be > handled between the FAs. I am sure the Mobile IP WG would be able to > satisfy the requirements for an inter-GGSN /FA transfer that are > specific to 3GPP. Anyone here care to throw some more light on GPRX > and why you cannot do this with Mobile IP? > This sounds like the GRX. It is not a new protocol. The GSM Association developed this as an agreement between GPRS operators to facilitate interconnection of disparate GPRS systems in support of roaming users. They called this the GPRS Roaming Exchange (GRX) and invited various organizations, such as ISPs, to bid on supplying the service. A good example of one is http://www.sonera.fi/english/solutions/grx/. The agreement uses off-the-shelf IP routing facilities (BGP4 and DNS) to interconnect private IP-based radio access networks using routing policies. The IP packets containing the GPRS GTP tunnels flow across these network borders when a customer roams. The entire mechanism is transparent to the roaming user (until they get the bill!). Ken From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 12 20:50: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 UAA14399 for ; Thu, 12 Apr 2001 20: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 RAA23047; Thu, 12 Apr 2001 17:49:27 -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 RAA23689; Thu, 12 Apr 2001 17:49:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3D0mBK9022658 for ; Thu, 12 Apr 2001 17:48:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3D0mA6K022657 for mobile-ip-dist; Thu, 12 Apr 2001 17:48: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3D0m2K9022650 for ; Thu, 12 Apr 2001 17:48:02 -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 RAA17590 for ; Thu, 12 Apr 2001 17:48:01 -0700 (PDT) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id RAA22524 for ; Thu, 12 Apr 2001 17:48:01 -0700 (PDT) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Thu Apr 12 20:46:28 EDT 2001 Received: from valjean.dnrc.bell-labs.com (valjean [135.180.240.120]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id UAA18580 for ; Thu, 12 Apr 2001 20:46:39 -0400 (EDT) Received: (from salga@localhost) by valjean.dnrc.bell-labs.com (8.11.0/8.8.7) id f3D0kRR07904 for mobile-ip@sunroof.eng.sun.com; Thu, 12 Apr 2001 20:46:27 -0400 Date: Thu, 12 Apr 2001 20:46:27 -0400 From: Luca Salgarelli To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] dynamic home addressing as a WG item?? Message-ID: <20010412204627.A7887@bell-labs.com> Mail-Followup-To: mobile-ip@sunroof.eng.sun.com References: <200104122225.PAA19666@heliopolis.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104122225.PAA19666@heliopolis.eng.sun.com>; from James.Kempf@sun.com on Thu, Apr 12, 2001 at 03:25:24PM -0700 X-Organization: Bell Laboratories Sender: owner-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. > >I think I agree with Phil on this. I am not comfortable with the idea of > >coupling a routing protocol with something needed to distribute > >configuration information. > > > > But you are comfortable with having an address provisioning mechanism > distribute service discovery and configuration information? Curious. Hmmm, as far as I know, DHCP stands for Dynamic Host *Configuration* Protocol. It has been designed exactly for distributing configuration information. > >I don't see why you consider "extending DHCP" to the mobile a hack: > >Mobile-IP is designed to transparently hide the movements of the client. So > >I don't see why you would see letting DHCP "transparently" run on top of > >the Mobile-IP tunnel a hack. > > I consider it a hack because it involves a lot of mechanism (DHCP relays, > reverse tunneling) that is unnecessary. Besides, there is no requirement > for the home network to use DHCP to configure the mobile node, it > could use something different (LDAP for example). I rather think > the hiding should be done by on the mobile side, so that it does > not have to deal with how the home network configures. I agree that something different could be used, but the way it is (very successfully) being done today is through DHCP. Network administrators just seem to like it a lot, so I think supporting it should be somthing we should make MIP capable of. If then we want to think at a better way to do it, it is fine by me. > Hmm, is this perhaps the problem? You, Sandy, and maybe Phil view the > mobile node as being an extension of the home network, correct? This > is the traditional mobile IP view. I have rather a different view. > I view the mobile node as mostly away from the home network, not > really bound to it except though routing. So a possible, even likely, > situation is that the mobile node gets a locally assigned home > address every time it comes up in someone's network. As a result, > the mobile node should be getting the configuration information from > where the home address is assigned, and I view it as rather too burdensome > to require every wireless network operator to have to deploy DHCP. I agree, we are probably thinking about two different scenarios. Nevertheless, I don't think anybody is saying that support for DHCP should be a MUST for MIP. What I would like to see is some way for MIP to support it, for the ISP's that think it is needed. > Besides, as I said at the beginning of this thread, I don't see why every > mobile node in the world has to essentially support two address > provisioning mechanisms, mobile IP and DHCP. Phil's comments > notwidthstanding, mobile IP does not just do routing, it also does > address configuration. Again, that might work in the scenario you described above. It will not work (very well, at least) in scenarios where the mobile goes home from time to time, as Sandy pointed out already. Luca > We need to find out some other way of doing > lightweight configuration, since that is all DHCP will be used for on the > mobile node. > > Maybe what we need is "DHCP lite" that extracts out the configuration > part of DHCP and gets rid of the need for a reverse tunnel for broadcast. > > jak From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 12 22:48: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 WAA17193 for ; Thu, 12 Apr 2001 22:48: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 TAA05927; Thu, 12 Apr 2001 19:48: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 TAA12646; Thu, 12 Apr 2001 19:48:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3D2krK9023235 for ; Thu, 12 Apr 2001 19:46:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3D2krHK023234 for mobile-ip-dist; Thu, 12 Apr 2001 19:46: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3D2kjK9023227 for ; Thu, 12 Apr 2001 19:46:45 -0700 (PDT) Received: from awe171-106 (awe195-17.AWE.Sun.COM [192.29.195.17]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id TAA25695 for ; Thu, 12 Apr 2001 19:46:44 -0700 (PDT) Message-Id: <200104130246.TAA25695@heliopolis.eng.sun.com> Date: Thu, 12 Apr 2001 18:39:20 -0700 (PDT) From: kempf Subject: (privately...) RE: [mobile-ip] Involvement w. 3Gs? (context transfer from Seamob y) To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 0Ace0jsNw0gnMRolkYH+qg== 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: Ken, > > >This sounds like the GRX. It is not a new protocol. > >The GSM Association developed this as an agreement between GPRS operators to >facilitate interconnection of disparate GPRS systems in support of roaming >users. They called this the GPRS Roaming Exchange (GRX) and invited various >organizations, such as ISPs, to bid on supplying the service. A good >example of one is http://www.sonera.fi/english/solutions/grx/. > >The agreement uses off-the-shelf IP routing facilities (BGP4 and DNS) to >interconnect private IP-based radio access networks using routing policies. >The IP packets containing the GPRS GTP tunnels flow across these network >borders when a customer roams. > >The entire mechanism is transparent to the roaming user (until they get the >bill!). > Thanx. Any idea why they would want to do this as opposed to using mobile IP? jak From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 12 23:13: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 XAA17400 for ; Thu, 12 Apr 2001 23:13:24 -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 UAA12811; Thu, 12 Apr 2001 20:13: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 UAA10430; Thu, 12 Apr 2001 20:13:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3D3AOK9023293 for ; Thu, 12 Apr 2001 20:10:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3D3ANDD023292 for mobile-ip-dist; Thu, 12 Apr 2001 20:10: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3D39xK9023285 for ; Thu, 12 Apr 2001 20:10:00 -0700 (PDT) Received: from awe171-106 (awe195-17.AWE.Sun.COM [192.29.195.17]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id UAA26083 for ; Thu, 12 Apr 2001 20:09:58 -0700 (PDT) Message-Id: <200104130309.UAA26083@heliopolis.eng.sun.com> Date: Thu, 12 Apr 2001 19:02:34 -0700 (PDT) From: kempf Subject: Re: [mobile-ip] dynamic home addressing as a WG item?? To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: kYA4BYv7WQkyN/o7UuYpCg== 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: Hi Luca, OK, I think I've got this sorted out now. (Note to PhilN: if you haven't already, please read the drafts before you hit the "send" key...). >Hmmm, as far as I know, DHCP stands for Dynamic Host *Configuration* >Protocol. It has been designed exactly for distributing configuration >information. > DHCP was originally designed to configure address information, it was only due to the lack of a standardized configuration mechanism that everything else got dumped in. Now, there are far better ways of doing configuration of service discovery information (LDAP, SLP, DNS SRV RR). And the only reason DHCPpppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppp pkkkkkkkkkkkkkkkkkkkk was needed to do address configuration was because IPv4 doesn't have autoaddress config nor router-advertised subnet prefixes. > >I agree that something different could be used, but the way it is >(very successfully) being done today is through DHCP. Network >administrators just seem to like it a lot, so I think supporting it should >be somthing we should make MIP capable of. If then we want to think at a >better way to do it, it is fine by me. > The fact of the matter is that mobile IP is currently deployed in 3GPP2 networks without DHCP & there is no DHCP on 3GPP2 phones or the brand new Sprint PCS modems I've just started seeing advertised in the New York Times. They use PPP and Radius to configure the address information. So from the point of view of the system administrators and users who are using mobile IP *today* this is a very big change indeed, despite what enterprise network administrators think. Not every IP node is connected to an enterprise network, in fact, in the future, nodes homed and connected to enterprise networks may be in the minority. >I agree, we are probably thinking about two different scenarios. >Nevertheless, I don't think anybody is saying that support for DHCP should >be a MUST for MIP. What I would like to see is some way for MIP to support >it, for the ISP's that think it is needed. > I disagree. I would rather see something that builds on the current infrastructure, that won't involve 3GPP2 having to tear up their current infrastructure. If DHCP is put in, people will think the problem is solved. >Again, that might work in the scenario you described above. It will not >work (very well, at least) in scenarios where the mobile goes home from >time to time, as Sandy pointed out already. > I think it will work just fine when the mobile node goes home. The mobile node has mobile IP with address and routability configuration (see below for more on this), uses that to get what it needs from the home agent, home agent uses DHCP out the back end (or Radius/Diameter and PPP/BURP if it is in a WAN situation) to get the address/routability information. Now perhaps some perspective (especially for PhilN's benefit). I think we are talking about three different kinds of configuration information supplied by DHCP: 1) Information that is required for basic routing of packets to the host. On IPv4, this consists of the IP address, the subnet mask, and perhaps the gateway router. On IPv6, this consists of the subnet prefix, perhaps an IP address if one is assigned, the router can be discovered. 2) Borderline service discovery information that would be difficult to bootstrap. This is primarily DNS. 3) Service discovery information such as printers, LDAP servers and the like. From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 12 23:25:14 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA17528 for ; Thu, 12 Apr 2001 23:25: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 UAA09615; Thu, 12 Apr 2001 20:22: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 UAA15875; Thu, 12 Apr 2001 20:24:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3D3NKK9023357 for ; Thu, 12 Apr 2001 20:23:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3D3NKTU023356 for mobile-ip-dist; Thu, 12 Apr 2001 20:23: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3D3NAK9023349 for ; Thu, 12 Apr 2001 20:23:10 -0700 (PDT) Received: from awe171-106 (awe195-17.AWE.Sun.COM [192.29.195.17]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id UAA26215 for ; Thu, 12 Apr 2001 20:23:09 -0700 (PDT) Message-Id: <200104130323.UAA26215@heliopolis.eng.sun.com> Date: Thu, 12 Apr 2001 19:15:45 -0700 (PDT) From: kempf Subject: Not so...Re: (privately...) RE: [mobile-ip] Involvement w. 3Gs? (context transfer from Seamob y) To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: KaWrjrnc2V73lNP/aVBchg== 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: OK, maybe not so privately. But still, why do the 3GPP operators think they need this? jak >Ken, > >> >> >>This sounds like the GRX. It is not a new protocol. >> >>The GSM Association developed this as an agreement between GPRS operators to >>facilitate interconnection of disparate GPRS systems in support of roaming >>users. They called this the GPRS Roaming Exchange (GRX) and invited various >>organizations, such as ISPs, to bid on supplying the service. A good >>example of one is http://www.sonera.fi/english/solutions/grx/. >> >>The agreement uses off-the-shelf IP routing facilities (BGP4 and DNS) to >>interconnect private IP-based radio access networks using routing policies. >>The IP packets containing the GPRS GTP tunnels flow across these network >>borders when a customer roams. >> >>The entire mechanism is transparent to the roaming user (until they get the >>bill!). >> > >Thanx. Any idea why they would want to do this as opposed to using mobile IP? > > jak > From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 12 23:36: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 XAA17983 for ; Thu, 12 Apr 2001 23:36: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 UAA19393; Thu, 12 Apr 2001 20:35:51 -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 UAA09033; Thu, 12 Apr 2001 20:35:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3D3YVK9023475 for ; Thu, 12 Apr 2001 20:34:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3D3YUOv023474 for mobile-ip-dist; Thu, 12 Apr 2001 20:34: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3D3YLK9023467 for ; Thu, 12 Apr 2001 20:34:22 -0700 (PDT) Received: from awe171-106 (awe195-17.AWE.Sun.COM [192.29.195.17]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id UAA26383 for ; Thu, 12 Apr 2001 20:34:20 -0700 (PDT) Message-Id: <200104130334.UAA26383@heliopolis.eng.sun.com> Date: Thu, 12 Apr 2001 19:26:57 -0700 (PDT) From: kempf Subject: Re: [mobile-ip] dynamic home addressing as a WG item?? To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: swktRRf5OZNpoWglk2hKvg== 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: Hi Luca, OK, please ignore the previous reply, with garbage, my keyboard started going crazy in the middle, will my email woes ever subside... Anyway ... >Hmmm, as far as I know, DHCP stands for Dynamic Host *Configuration* >Protocol. It has been designed exactly for distributing configuration >information. > DHCP was originally designed to configure address information, it was only due to the lack of a standardized service discovery mechanism that everything else got dumped in. Now, there are far better ways of doing configuration of service discovery information (LDAP, SLP, DNS SRV RR). And the only reason DHCP was needed to do address configuration was because IPv4 doesn't have autoaddress config nor router-advertised subnet prefixes. >I agree that something different could be used, but the way it is >(very successfully) being done today is through DHCP. Network >administrators just seem to like it a lot, so I think supporting it should >be somthing we should make MIP capable of. If then we want to think at a >better way to do it, it is fine by me. > The fact of the matter is that mobile IP is currently deployed in 3GPP2 networks without DHCP & there is no DHCP on 3GPP2 phones or the brand new Sprint PCS modems I've just started seeing advertised in the New York Times. They use PPP and Radius to configure the address information. So from the point of view of the system administrators and users who are using mobile IP *today* this is a very big change indeed, despite what enterprise network administrators think. Not every IP node is connected to an enterprise network, in fact, in the future, nodes homed and connected to enterprise networks may be in the minority. >I agree, we are probably thinking about two different scenarios. >Nevertheless, I don't think anybody is saying that support for DHCP should >be a MUST for MIP. What I would like to see is some way for MIP to support >it, for the ISP's that think it is needed. > I disagree. I would rather see something that builds on the current infrastructure, that won't involve 3GPP2 having to tear up their current infrastructure. If DHCP is put in, people will think the problem is solved. >Again, that might work in the scenario you described above. It will not >work (very well, at least) in scenarios where the mobile goes home from >time to time, as Sandy pointed out already. > Sure, it will work just fine when the mobile node goes home. The mobile node has mobile IP with address and routability configuration (see below for more on this), uses that to get what it needs from the home agent, home agent uses DHCP out the back end (or Radius/PPP or Diameter if it is in a WAN situation) to get the address/routability information, gives it to the mobile, mobile node uses service discovery to find services. Now perhaps some perspective (especially for PhilN's benefit). I think we are talking about three different kinds of configuration information supplied by DHCP: 1) Information that is required for basic routing of packets to the host. On IPv4, this consists of the IP address, the subnet mask, and perhaps the gateway router. On IPv6, this consists of the subnet prefix, perhaps an IP address if one is assigned, the router can be discovered. 2) Borderline service discovery information that would be difficult to bootstrap. This is primarily DNS. 3) Service discovery information such as printers, LDAP servers and the like. Now, I think we all agree that mobile IP shouldn't be delivering 3) and I think that there are today better ways of doing 3) as I discussed above. If DHCP is available, by all means use it, but it isn't available on today's mobile IP networks and I don't think 3) is enough justification to introduce DHCP. As far as 1) is concerned, what's the problem with having mobile IP deliver basic routability information? In IPv6, most of this information is delivered by router advertisements or by address autoconfig, which is part of the routing protocol. Since mobile IP is concerned with routing, I think it should be involved in distributing routing configuration. That leaves only 2). My understanding is that the DNSng group is working on ways to find a DNS server in IPv6 that don't require getting it from DHCP. So that leaves one single piece of information in IPv4 that doesn't fit in. This could be distributed by AAA or even we could make one tiny exception and do it by mobile IP as well (just as DHCP is used in enterprise networks for all kinds of service discovery information), or we could come up with a protocol like IPv6 is. Bottom line for me is that DHCP is not used in mobile IP networks today, Radius/PPP is. I would rather see us building on that infrastructure than introducing new requirements for what the mobile node has to support. And I don't buy the argument that we can do it as an option. Once it is there, people will think they have to support it. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 13 05:03: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 FAA03777 for ; Fri, 13 Apr 2001 05:03: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 CAA22883; Fri, 13 Apr 2001 02:02:58 -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 CAA08140; Fri, 13 Apr 2001 02:02:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3D91iK9023816 for ; Fri, 13 Apr 2001 02:01:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3D91iMi023815 for mobile-ip-dist; Fri, 13 Apr 2001 02:01: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3D91ZK9023808 for ; Fri, 13 Apr 2001 02:01:35 -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 CAA14622 for ; Fri, 13 Apr 2001 02:01:34 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA22340 for ; Fri, 13 Apr 2001 03:08:21 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f3D91Ne19287; Fri, 13 Apr 2001 11:01:24 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA29453; Fri, 13 Apr 2001 11:01:23 +0200 (MET DST) Received: from localhost (localhost [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f3D91LA55014; Fri, 13 Apr 2001 11:01:22 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200104130901.f3D91LA55014@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Robert Moskowitz cc: mobile-ip@sunroof.eng.sun.com, hipsec@mail.freeswan.org Subject: Re: [mobile-ip] -New ID about Address owernship- In-reply-to: Your message of Thu, 12 Apr 2001 15:58:40 EDT. <5.0.0.25.2.20010412134432.029127d0@localhost> Date: Fri, 13 Apr 2001 11:01:21 +0200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: >This has negative implications for larger servers that process many 100s >of thousands of connections at a time or for smaller mobile nodes that >are short in processor and battery resources >(you have recognized the argument :-). Similar to WTLS 1.2 What kind of server maintains 100,000s of concurrent connections? => ask IESG (:-)! >An illustration: HIP provides a good protection against DoS attacks, >in fact this is not really an advantage: HIP must provide this because >HIP mechanisms involve a lot of powerful/expensive crypto which could >make DoS attacks very prejudicial... Any key exchange mechanism adds to the risk of DoS attacks, but a well worked out mechanism should also remove exposure to transport level attacks. For MIP's initial usage of HIP only being used for BUs, HIP's goal would be to protect the BUs and give the CN's trust in them. => my concern is that HIP does too much. As soon as the exact requirements will be available we'll see if HIP is above, below or just at the good level of protection/complexity. I believe that it will be above like IKE is according to IESG... This is not about the merits of HIP but my concern is different: is HIP the right tool for mobile IPv6 BUs with random CNs. > The less drafty draft uses only SHA-1 which is far less expensive: the > exact requirements for mobile IPv6 security are not yet available but HIP > seems to overfulfill them. To the later, that it may. SHA-1 is less expensive than any PK crypto, no one can argue that. Does 'drafty draft' meet reasonable security requirements? => we need to get the requirements before judging... I offer HIP for a number of reasons: I am working on HIP for secure Internet model that understands 'addressing realms' (like IPv4and v6 co-existing and NAT traversal) and flexible mobility. => but HIP itself doesn't support the mobile-to-mobile case (it lacks a fallback mechanism or if you prefer HITs are not routable). It is HARD to get a trusted binding between two hosts. Shortcuts tend to be longcuts, in that they are later found to be flawed; 'good enough' (look at WEP) can end up being no protection at all. HIP has had a reasonable peer review and is itself based on other mechanisms like SSL, IKE, SKIP, and Photuris. => the issue is not that HIP is too weak, it is that HIP is too strong. From the security point of view IKE can fulfill all the requirements of Mobile IPv6 but it is incredible expensive to use (the first home registration from a visited network (the first thing the mobile does) works well, including between different implementations, but has abyssal performances). It can rely on a global PKI too (like DNSsec). All the arguments used against IPsec/IKE applies to HIP too... >BTW I like very much the SUCV address idea but section 6.1 should >be simplify/adapted (i.e. not cut&pasted from the HIP document). I do not know if SUCV will be secure, I am studying it. => I believe it is secure enough for temporary addresses (military argument: short term informations need less protection than long term). We have to see for permanent addresses in the mobile IPv6 BUs to random CNs context. The opportunistic mode of HIP needs further development and I am doing that. => this is an important point because "a global PKI is not available and perhaps not desirable" (quoting Jeff Schiller). Consider for a moment where a BU HELLO is equivalent in HIP to the I1 HIP packet. Also note that an optimization of HIP could allow for a data payload INSIDE of I2 (but not appended after, as the intiator does not get the responder's SPI until R2). The ESP transform used in MIP for BUs could be ESP NULL with HMAC-SHA1-96. Once the initial HIP exchange is completed, ESP is used for all future exchanges until either a timeout (could be set fairly long here) or loss of state (CN or MN boot). => I believe the divorce is complete between IPsec and Mobile IPv6 people, i.e. the BUs auth* will be provided by an ad-hoc mechanism, not by an IPsec transform... But if you read the less drafty draft you can find an ESP protection for the HA-MN tunnel. This is a VPN-like case so it is apparently readily supported by the current generation of IPsec/IKE implementations (:-). But the MN (by definition :-) can move so we have again the SA rebuild/update issue: HIP can be very useful there and as the HA never moves we don't fall in the mobile-to-mobile hard case. HIP as written in my 3 IDs is a full protocol. There is much that others can do to target it to particular opportunities. => even if HIP is not suitable for the random CN case there are some others: - not random CNs (same than the random CN case but with a common PKI or a common trusted third party) - permanent home registration (common PKI, trusted third party, AAA, ..., but as this is the principal mechanism (previous cases are optimizations) this is critical for both security and performances) - temporary home registration (the smooth hand-off case) (AAA credentials, all involved entities on the same link). Thanks Francis.Dupont@enst-bretagne.fr PS: any mechanism which can reconcile IPsec (mainly ESP tunnel transform :-) and mobility based on addresses is *wellcome*! From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 13 05:35:39 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA04042 for ; Fri, 13 Apr 2001 05:35: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 CAA00586; Fri, 13 Apr 2001 02:32: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 CAA16535; Fri, 13 Apr 2001 02:35:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3D9Y5K9023889 for ; Fri, 13 Apr 2001 02:34:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3D9Y4lp023888 for mobile-ip-dist; Fri, 13 Apr 2001 02:34: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3D9XtK9023881 for ; Fri, 13 Apr 2001 02:33:56 -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 CAA10904; Fri, 13 Apr 2001 02:33:54 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA01032; Fri, 13 Apr 2001 03:40:40 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f3D9Xpe17384; Fri, 13 Apr 2001 11:33:51 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA00132; Fri, 13 Apr 2001 11:33:51 +0200 (MET DST) Received: from localhost (localhost [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f3D9XoA55092; Fri, 13 Apr 2001 11:33:50 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200104130933.f3D9XoA55092@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Mohan Parthasarathy cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] -New ID about Address owernship- In-reply-to: Your message of Thu, 12 Apr 2001 14:37:53 PDT. <200104122139.f3CLdBB2466000@jurassic.eng.sun.com> Date: Fri, 13 Apr 2001 11:33:50 +0200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > with a new address per connection for instance) the computation > of the public/private key pairs can become very expensive... But this implies that the identifier part of your home address changes too. So, i don't understand how this would work. => if you want to use a temporary address and mobility you have to get a temporary care-of address and home address pair and to send a home registration (I assume we have a cheap way to add secondary home registrations for an already established MN-HA SA). Regards Francis.Dupont@enst-bretagne.fr PS: the only issue is that sending of BUs will reveal the current public key so if the key is reused one can discover the node is the same but: - the key is only in one (or a little number of) packet(s) - to send BUs is optional (I assume home registrations are protected for confidentiality) PS (about assumptions): - the first point works if a mechanism for secondary home registrations is added (a sub-option for secondary home address). Such a mechanism can be useful if we want to get better control on the home address set (today there is only the prefix length stuff: one address or all addresses according to home prefixes). - the second point works with a confidentiality protection of all parameters as provided by ESP on the MN-HA reverse tunnel. PS (basic note): to use a temporary care-of address with a permanent home address (or the opposite) gives no privacy at all. For a specific discussion about mobility and privacy you can read (it will be updated ASAP) draft-castelluccia-mobileip-privacy-00.txt From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 13 07:12: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 HAA04783 for ; Fri, 13 Apr 2001 07:12: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 EAA29874; Fri, 13 Apr 2001 04:12:34 -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 EAA22533; Fri, 13 Apr 2001 04:12:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3DBBKK9024043 for ; Fri, 13 Apr 2001 04:11:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3DBBJOx024042 for mobile-ip-dist; Fri, 13 Apr 2001 04:11: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3DBB9K9024035 for ; Fri, 13 Apr 2001 04:11:09 -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 EAA17535 for ; Fri, 13 Apr 2001 04:11:08 -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 EAA06796 for ; Fri, 13 Apr 2001 04:11:07 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA00488; Fri, 13 Apr 2001 07:11:06 -0400 Date: Fri, 13 Apr 2001 07:11:06 -0400 (EDT) From: Jim Bound To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Involvement w. 3Gs? (context transfer from Seamoby) In-Reply-To: <200104122153.OAA18637@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: 3G Rel 5 has to much on their plate to add MIPv6. Rel 6 will have it. Also they don't define IP protocols. Also I don't think we should take more on here in the IETF our plate is already full. /jim On Thu, 12 Apr 2001, James Kempf wrote: > A debate has been going on on the Seamoby list about how involved the > MIP group should be with the 3Gs, but it looked like here was rather > the right place to have it. > > One issue that comes up to me is the following. The MIP group has tried to > work with the 3Gs over the last few years, and has had moderate success > with 3GPP2. They are using MIP, we have successfully developed several > enhancements to their packet architecture more or less collaboratively > together with them, they are committed to working together with us > in the future, and we have good working relationships with TSG-P members. > > The same cannot be said of 3GPP. They have a competing IP mobility > standard which they have continued to push. At an IEE conference in London a > few weeks ago, a paper was given announcing a plan to do inter-GGSN > GPRS transfer (called GPRX). The R99 spec for 3GPP specifies that this > should be done through mobile IP, but no 3GPP vendor implements it > and none of the mobile operators are deploying it. They have > shown no interest in working with IETF to resolve this. > Naturally, the next step is when 3GPP operators begin deploying 802.11 > networks, they start using GPRS for that as well. > > So the issue is, what should the IETF do about this (is there anything > we *can* do)? It looks to me like 3GPP is now getting into the > business of defining IP standards. Do we maybe have to recognize that, > like STD0048 and STD0019 for NetBios, GPRS is becoming a de facto standard and > try to bring it into IETF? Or should we rather be pushing back on them in some > way to deploy mobile IP, like R99 says? Or should we simply ignore them and > instead work on getting mobility integrated more deeply into the IPng core, > hoping they will sink under the load of their spectrum auction debt? > > jak > From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 13 07:17:04 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 HAA05089 for ; Fri, 13 Apr 2001 07:17:03 -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 EAA01230; Fri, 13 Apr 2001 04:16:36 -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 EAA15761; Fri, 13 Apr 2001 04:16:30 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3DBEsK9024083 for ; Fri, 13 Apr 2001 04:14:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3DBEsnu024082 for mobile-ip-dist; Fri, 13 Apr 2001 04:14: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3DBEjK9024075 for ; Fri, 13 Apr 2001 04:14:45 -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 EAA15643 for ; Fri, 13 Apr 2001 04:14:44 -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 EAA00609 for ; Fri, 13 Apr 2001 04:14:43 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA19554; Fri, 13 Apr 2001 07:14:43 -0400 Date: Fri, 13 Apr 2001 07:14:43 -0400 (EDT) From: Jim Bound To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Involvement w. 3Gs? (context transfer from Seamoby) In-Reply-To: <028601c0c3a2$0bdfaba0$6501a8c0@philneum> 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 with Phil below. Let 3G (GP or GP2) do there thing and we do ours and we lead where appropriate by example. And its not like our house is clean here. We move way to slow these days. If we hold up others they will not wait for us and move forward as they should. /jim On Thu, 12 Apr 2001, Phil Neumiller wrote: > Since I ah, sortof, kind-of started this rant, I had a few more words... > > ----- Original Message ----- > From: "Phil Roberts" > > > > > -----Original Message----- > > > So the issue is, what should the IETF do about this (is there anything > > > we *can* do)? It looks to me like 3GPP is now getting into the > > > business of defining IP standards. Do we maybe have to recognize that, > > Actually, Jim just let them. We know that the IETF defines the architecture > and standards for the global Internet. Eventually, even 3GPP will realize > that they have little control over something as powerful and growing as > the global Internet. What I am worried about is that we (the IETF) have > been "paying them too much attention [ESPECIALLY in the MIP WG]!". > Just ignore them! > > Let us get on with fixing the parts of the global Internet that are not up to > snuff for carying voice and video and lets make IP mobility work for the > human race, not just the 3GPP fat cats! I want every person on the planet to > have IP access and the only feasible way to do this is with inexpensive > wireless. Much of the world has yet to experience the joy of the WWW > and the wealth of data internet access offers, this is by far a more important > and might I add humanitarian goal for the IETF to pursue and it will raise > the human spirit, standard of living, and provide opportunities for the > world economy. I don't want to sound like a communist or socialist here, > I believe that capitalism can work just fine in this environment, on the contrary > what we have now is what amounts to "central planning" with the damn > spectrum auctions (taxes)! > > > > like STD0048 and STD0019 for NetBios, GPRS is becoming a de > > > facto standard and > > > try to bring it into IETF? > > Why bring it into the IETF? That seems pretty dumb. Let them do > their thing, since they claim it is better anyway. It is not consistent at > all with the architecture of the global Internet, therefore ignore it. It > will be transient like every cellular and wireless infrastructure before it. > The Internet is not transient, it is the closest thing to being an immortal > architecture that we have (warts and all). > > > >Or should we rather be pushing > > > back on them in some > > > way to deploy mobile IP, like R99 says? Or should we simply > > No pushing necessary. Lead by example. Why have we not given more > attention to the UNII and ISM bands? In the US their are tons of grass > root movements springing up in cities offering ISP wireless or even free > wireless access. > > > > ignore them and > > > instead work on getting mobility integrated more deeply into > > > the IPng core, > > > hoping they will sink under the load of their spectrum auction debt? > > This sounds like the plan I have advocated for years, of course everybody > always yells at me for being a 3G hater when I say stuff like this. What > happened to you James? :-) > > -pdn > > From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 13 09:53:16 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08461 for ; Fri, 13 Apr 2001 09:53:15 -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 GAA11268; Fri, 13 Apr 2001 06:49:54 -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 GAA00805; Fri, 13 Apr 2001 06:52:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3DDoEK9024356 for ; Fri, 13 Apr 2001 06:50:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3DDoEK0024355 for mobile-ip-dist; Fri, 13 Apr 2001 06:50: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3DDo5K9024348 for ; Fri, 13 Apr 2001 06:50:05 -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 GAA29343 for ; Fri, 13 Apr 2001 06:50:03 -0700 (PDT) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id GAA08869 for ; Fri, 13 Apr 2001 06:50:02 -0700 (PDT) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Fri Apr 13 09:49:31 EDT 2001 Received: from valjean.dnrc.bell-labs.com (valjean [135.180.240.120]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id JAA17649 for ; Fri, 13 Apr 2001 09:49:42 -0400 (EDT) Received: (from salga@localhost) by valjean.dnrc.bell-labs.com (8.11.0/8.8.7) id f3DDnUF08466 for mobile-ip@sunroof.eng.sun.com; Fri, 13 Apr 2001 09:49:30 -0400 Date: Fri, 13 Apr 2001 09:49:30 -0400 From: Luca Salgarelli To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] dynamic home addressing as a WG item?? Message-ID: <20010413094930.J4902@bell-labs.com> Mail-Followup-To: mobile-ip@sunroof.eng.sun.com References: <200104130334.UAA26383@heliopolis.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104130334.UAA26383@heliopolis.eng.sun.com>; from James.Kempf@sun.com on Thu, Apr 12, 2001 at 07:26:57PM -0700 X-Organization: Bell Laboratories Sender: owner-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. > DHCP was originally designed to configure address information, it was > only due to the lack of a standardized service discovery mechanism that > everything else got dumped in. We can debate about this forever, but that does not mean that the DHCP specs we have today for IPv4 don't do a good job in distributing configuration information, and not only addresses. Otherwise how do you justify its widespread use? > >I agree that something different could be used, but the way it is (very > >successfully) being done today is through DHCP. Network administrators > >just seem to like it a lot, so I think supporting it should be somthing > >we should make MIP capable of. If then we want to think at a better way > >to do it, it is fine by me. > > > > The fact of the matter is that mobile IP is currently deployed in 3GPP2 > networks without DHCP & there is no DHCP on 3GPP2 phones or the brand new > Sprint PCS modems I've just started seeing advertised in the New York > Times. They use PPP and Radius to configure the address information. So > from the point of view of the system administrators and users who are > using mobile IP *today* this is a very big change indeed, despite what > enterprise network administrators think. I agree on the 3GPP2 comment, and I also agree on the fact that 3GPP2 today is the major utilizer of Mobile-IP. But I disagree with respect to a couple of points: 1) Making Mobile-IP able to gracefully support DHCP does not mean that every Mobile-IP network *MUST* deploy and use DHCP. It only means that who *wants* to (e.g. corporate networks) will be able to do it. 2) The fact that today's 3GPP2 clients use PPP and RADIUS to configure their addresses does not mean that they won't need something else to configure their (corporate?) home addresses in some scenarios. Again, I would like to stress point (1), which I pointed out already in my previous e-mails: we are not talking about a mechanism that HAS TO be deployed. We are talking about leaving the possibility open for ISP's that want to use it. > >I agree, we are probably thinking about two different scenarios. > >Nevertheless, I don't think anybody is saying that support for DHCP > >should be a MUST for MIP. What I would like to see is some way for MIP > >to support it, for the ISP's that think it is needed. > > > > I disagree. I would rather see something that builds on the current > infrastructure, that won't involve 3GPP2 having to tear up their current > infrastructure. If DHCP is put in, people will think the problem is > solved. I disagree with you once more: we are not saying that DHCP must be put in. If people want to use something else, fine! We don't want to mandate the use of DHCP. > >Again, that might work in the scenario you described above. It will not > >work (very well, at least) in scenarios where the mobile goes home from > >time to time, as Sandy pointed out already. > > > > Sure, it will work just fine when the mobile node goes home. The mobile > node has mobile IP with address and routability configuration (see below > for more on this), uses that to get what it needs from the home agent, > home agent uses DHCP out the back end (or Radius/PPP or Diameter if it is > in a WAN situation) to get the address/routability information, gives it > to the mobile, mobile node uses service discovery to find services. I don't know if you read previous notes from Sandy's about this (I think it was a response to Pat), but this scheme won't just be so simple if the mobile goes home. Simply put, if the HA is responsible for a pool of addresses, the client will have to keep re-registering even if it is at home in order to defend the address. Luca From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 13 09:59:49 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08693 for ; Fri, 13 Apr 2001 09:59: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 GAA13195; Fri, 13 Apr 2001 06:56: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 GAA01251; Fri, 13 Apr 2001 06:59:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3DDvhK9024411 for ; Fri, 13 Apr 2001 06:57:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3DDvher024410 for mobile-ip-dist; Fri, 13 Apr 2001 06:57:43 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3DDvYK9024402 for ; Fri, 13 Apr 2001 06:57:34 -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 GAA02219 for ; Fri, 13 Apr 2001 06:57:32 -0700 (PDT) Received: from epona.host4u.net (epona.host4u.net [216.71.64.106]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA19765 for ; Fri, 13 Apr 2001 06:57:32 -0700 (PDT) Received: from TIMCLIFFFETYU8 (cd-188-41.ra30.dc.capu.net [64.50.188.41]) by epona.host4u.net (8.9.3/8.9.3) with SMTP id IAA21763 for ; Fri, 13 Apr 2001 08:57:30 -0500 From: "Tim Clifford" To: Subject: RE: [mobile-ip] Involvement w. 3Gs? (context transfer from Seamob y) Date: Fri, 13 Apr 2001 10:00:17 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 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: Content-Transfer-Encoding: 7bit Ken a few comments on the GRX, I wrote UUNET's response to the RFP. - there's actually little emphasis, the *specs* actually question its viability, about using standard IP mechanisms for the GRX. There's currently significant question about the way that things like DNS would be implemented and its a *private* DNS, not part of the Internet DNS - the interconnection is between GPRS PLMN, not "IP-based radio access networks." I suspect the GRX was based on the R98 spec, which states (section 5.4.2) that an"..inter-PLMN backbone network can be a Packet Data Network, e.g., the public Internet or a leased line." It was pretty much up to the respondees to the RFI how to provide the service; mostly I believe providers went the IP VPN route As to why it was decided to use these non-Internet mechanisms, I don't expect there's a technical reason. tim -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Ken Rehbehn Sent: Thursday, April 12, 2001 8:29 PM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] Involvement w. 3Gs? (context transfer from Seamob y) > >At an IEE conference in London a > >few weeks ago, a paper was given announcing a plan to do inter-GGSN > >GPRS transfer (called GPRX). The R99 spec for 3GPP specifies > that this > >should be done through mobile IP, but no 3GPP vendor implements it > >and none of the mobile operators are deploying it. They have > >shown no interest in working with IETF to resolve this. > > Do you have any insights into why they would want to specify a new > mechanism (GPRX)? After all as you said the R99 spec does include > support for an FA in the GGSN and inter-GGSN transfers could be > handled between the FAs. I am sure the Mobile IP WG would be able to > satisfy the requirements for an inter-GGSN /FA transfer that are > specific to 3GPP. Anyone here care to throw some more light on GPRX > and why you cannot do this with Mobile IP? > This sounds like the GRX. It is not a new protocol. The GSM Association developed this as an agreement between GPRS operators to facilitate interconnection of disparate GPRS systems in support of roaming users. They called this the GPRS Roaming Exchange (GRX) and invited various organizations, such as ISPs, to bid on supplying the service. A good example of one is http://www.sonera.fi/english/solutions/grx/. The agreement uses off-the-shelf IP routing facilities (BGP4 and DNS) to interconnect private IP-based radio access networks using routing policies. The IP packets containing the GPRS GTP tunnels flow across these network borders when a customer roams. The entire mechanism is transparent to the roaming user (until they get the bill!). Ken From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 13 10:52:17 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09883 for ; Fri, 13 Apr 2001 10:52: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 HAA27914; Fri, 13 Apr 2001 07:47: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 HAA07518; Fri, 13 Apr 2001 07:50:16 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3DEmfK9024557 for ; Fri, 13 Apr 2001 07:48:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3DEmfep024556 for mobile-ip-dist; Fri, 13 Apr 2001 07:48: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3DEmWK9024549 for ; Fri, 13 Apr 2001 07:48:32 -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 HAA09773 for ; Fri, 13 Apr 2001 07:48:32 -0700 (PDT) Received: from prserv.net (out4.prserv.net [32.97.166.34] (may be forged)) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA01690 for ; Fri, 13 Apr 2001 07:48:32 -0700 (PDT) Received: from [32.101.185.133] (slip-32-101-185-133.ca.us.prserv.net[32.101.185.133]) by prserv.net (out4) with ESMTP id <2001041314483020400m5gi2e>; Fri, 13 Apr 2001 14:48:30 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: ahmrphd@pop3.attglobal.net Message-Id: In-Reply-To: <028601c0c3a2$0bdfaba0$6501a8c0@philneum> References: Date: Fri, 13 Apr 2001 07:48:55 -0700 To: mobile-ip@sunroof.eng.sun.com From: Arthur Ross Subject: Re: [mobile-ip] Involvement w. 3Gs? (context transfer from Seamoby) Sender: owner-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 15:43 -0700 04/12/2001, Phil Neumiller wrote: > >> > ignore them and >> > instead work on getting mobility integrated more deeply into >> > the IPng core, >> > hoping they will sink under the load of their spectrum auction debt? > >This sounds like the plan I have advocated for years, of course everybody >always yells at me for being a 3G hater when I say stuff like this. What >happened to you James? :-) > He's begun to see the light! -- A From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 13 11:18:08 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10290 for ; Fri, 13 Apr 2001 11:18:08 -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 IAA06548; Fri, 13 Apr 2001 08:15:07 -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 IAA12512; Fri, 13 Apr 2001 08:11:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3DFAGK9024708 for ; Fri, 13 Apr 2001 08:10:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3DFAF8G024707 for mobile-ip-dist; Fri, 13 Apr 2001 08:10: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3DFA7K9024700 for ; Fri, 13 Apr 2001 08:10:07 -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 IAA22935 for ; Fri, 13 Apr 2001 08:10:06 -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 JAA19321 for ; Fri, 13 Apr 2001 09:18:14 -0600 (MDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Fri, 13 Apr 2001 11:04:32 -0400 Message-ID: From: Ken Rehbehn To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Involvement w. 3Gs? (context transfer from Seamob y) Date: Fri, 13 Apr 2001 11:04:24 -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: Tim Clifford [mailto:tjc@lacunanet.net] > Sent: Friday, April 13, 2001 10:00 AM ... good stuff snipped ... > As to why it was decided to use these non-Internet mechanisms, I don't > expect there's a technical reason. > > tim I think they used internet mechanisms. Just not the ones the folks on this list would prefer! The reason for this decision is based on the business context. The group that did this was the operator community that was attempting to solve a problem. They did so in a forum conducted long after the standards for GPRS were baked. They needed to take advantage of currently shipping functionality to solve the roaming problem. No changes could be expected in handsets. The consequence is that they turned to BGP4 routing "glue" and other internet-based mechanisms. The solution seems to work but is quite limited to the specific problem they tried to address. Replacement of handsets and infrastructure is a wicked problem if you have to answer to shareholders. From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 13 11:26:31 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10590 for ; Fri, 13 Apr 2001 11:26: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 IAA10267; Fri, 13 Apr 2001 08:23: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 IAA16105; Fri, 13 Apr 2001 08:25:57 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3DFOQK9024844 for ; Fri, 13 Apr 2001 08:24:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3DFOPR1024843 for mobile-ip-dist; Fri, 13 Apr 2001 08: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3DFOHK9024836 for ; Fri, 13 Apr 2001 08:24:17 -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 IAA04395 for ; Fri, 13 Apr 2001 08:24:16 -0700 (PDT) Message-Id: <200104131524.IAA04395@heliopolis.eng.sun.com> Date: Fri, 13 Apr 2001 08:24:16 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Involvement w. 3Gs? (context transfer from Seamoby) To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: SqMCZ6bpiNi4uoadBBc9AQ== 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 Arthur, >>> > ignore them and >>> > instead work on getting mobility integrated more deeply into >>> > the IPng core, >>> > hoping they will sink under the load of their spectrum auction debt? >> >>This sounds like the plan I have advocated for years, of course everybody >>always yells at me for being a 3G hater when I say stuff like this. What >>happened to you James? :-) >> >He's begun to see the light! > Sorry, that's not quite it. My view is that we should continue the highly productive relationship with 3GPP2. It is just starting to really move. Sprint now advertises a modem that uses the IOS/PDSN mobile IP based design. Mobile IP was completely ignored by the enterprise networking and wireline ISP community until 3GPP2 took it up, why should we give up on something that looks like it is succeeding? As for 3GPP, well, I think we need to open a dialog with them, particularly the rabid GPRS/GTP types, and figure out what we need to do to get them on board moving toward the kinds of interoperability that IETF works to foster. They must have some reasons why they're ignoring mobile IP, to the extent these reasons are technical, we may be able to persuade them to pay more attention. MWIF has had considerable success persuading 3GPP to look at IP as transport in UTRAN, so they are not unpersuadable. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 13 12:17: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 MAA12310 for ; Fri, 13 Apr 2001 12:17: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 JAA19835; Fri, 13 Apr 2001 09:17: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 JAA05064; Fri, 13 Apr 2001 09:17:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3DGFIK9024909 for ; Fri, 13 Apr 2001 09:15:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3DGFIdr024908 for mobile-ip-dist; Fri, 13 Apr 2001 09:15:18 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3DGF9K9024901 for ; Fri, 13 Apr 2001 09:15:10 -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 JAA05667 for ; Fri, 13 Apr 2001 09:15:09 -0700 (PDT) Message-Id: <200104131615.JAA05667@heliopolis.eng.sun.com> Date: Fri, 13 Apr 2001 09:15:09 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] dynamic home addressing as a WG item?? To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: zerA/BewTZ1meb7dVDgO4A== 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 Luca, >We can debate about this forever, but that does not mean that the DHCP >specs we have today for IPv4 don't do a good job in distributing >configuration information, and not only addresses. Otherwise how do you >justify its widespread use? > Because it was there first and it did an OK job and there were no competitors. And also, BTW, because Microsoft, the volume OS vendor for nomadic (as opposed to mobile) hosts, put it into their OS. It doesn't mean DHCP is the best way today with other choices available. Moving forward (and this debate is all about futures, there is no widespread, global mobility available today), I simply don't think it is the right technical decision to take a protocol that was designed to fill a hole in IPv4 routing and address provisioning for co-operatively managed enterprise networks but grew into a general purpose configuration protocol simply because there were no competitors, and extend it into the protocol for configuring globally mobile IP hosts. >I agree on the 3GPP2 comment, and I also agree on the fact that 3GPP2 today >is the major utilizer of Mobile-IP. But I disagree with respect to a couple >of points: > >1) Making Mobile-IP able to gracefully support DHCP does not mean that >every Mobile-IP network *MUST* deploy and use DHCP. It only means that who >*wants* to (e.g. corporate networks) will be able to do it. > If corporate networks want this, they should be arranging for VPNs with their ISPs. DHCP was designed for and is primarily deployed in co-operatively managed, enterprise networks, not the kinds of wide area networks that mobile IP is being used for. The standard way to extend such networks remotely is to set up a VPN. Here's an example of how extending DHCP to wide area networks can go awry. Last year, a friend of mine signed up for DSL service from the local telephone company. After it was installed, he turned on his Windows box, browsed into Network Neighborhood, and ended up on his neighbor's hard drive. DHCP doesn't have the right kind of security characteristics for wide area networks. VPNs do. I know there is work underway to address security for DHCP, but since the design center for the protocol is enterprise networks, the work is probably going to assume all kinds of supporting infrastructure that may not be there for wide area cases. So if we extend DHCP to wide area networks through mobile IP, we'd end up having to go through another extensive security analysis to figure out how to make sure that there were no security holes. The two existing drafts are just the tip of the iceberg in terms of the work needed. >2) The fact that today's 3GPP2 clients use PPP and RADIUS to configure >their addresses does not mean that they won't need something else to >configure their (corporate?) home addresses in some scenarios. > Right, if they want to remotely extend this functionality, they should use a VPN. That's how it is done today. Now, perhaps there needs to be some work to address how to extend VPNs to mobile, as opposed to nomadic, users, but that is orthogonal to whether extensions to mobile IP are needed to support DHCP. >Again, I would like to stress point (1), which I pointed out already in my >previous e-mails: we are not talking about a mechanism that HAS TO be >deployed. We are talking about leaving the possibility open for ISP's that >want to use it. > And I'd like to stress that I don't believe it is the right technical decision to use a protocol that was designed for co-operatively managed enterprise networks in wide area networks. Again, as mentioned above, there are cases where this has been done that I've seen that have resulted in not good stuff happening. The two situations have different characteristics with respect to security. >I don't know if you read previous notes from Sandy's about this (I think it >was a response to Pat), but this scheme won't just be so simple if the >mobile goes home. Simply put, if the HA is responsible for a pool of >addresses, the client will have to keep re-registering even if it is at >home in order to defend the address. > So? If DHCP were used by the client, it would have to renew the lease periodically anyway. What's the difference? You didn't respond to my analysis about exactly what configuration information we are talking about, but let me return to that point. Let's leave IPv6 out of the picture, since I think we can both figure out better ways to do this than DHCP (although I'm sure if DHCP gets integrated with mobile IP in IPv4, people will want it for IPv6, which will only perpetuate the problem). Suppose we agree that service discovery information (3 on my previous email) isn't a sufficiently good reason to integrate DHCP. There are other ways to do service discovery, and, frankly, the mobile node may want to discover this information locally rather than in the home network. For example, if I want to print something, I'll want to print it locally, not back in my office. There may additionally be some services that might have to be discovered in the home network. The upshot is, there are complexities to service discovery, and simply punching a reverse tunnel with DHCP back to the home network isn't going to solve the problem. Point 2 on my previous email was the DNS server. This is difficult to bootstrap with service discovery. An IPv4 mobile node would need to have this information configured because it cannot discover it, but it is not clear that providing it from the home network is the right way to go either. Signalling times may be lengthy if a home network DNS server is used, it might make more sense to get this information locally somehow too. I don't know how the 3GPP2 network currently does this, but I suspect it is done through Radius/PPP somehow. It seems to me that there may be work here extending the current method, but probably DHCP is not the way to go either. Point 1 on my previous email was routability configuration. In IPv4, this consists of the address, the subnet mask, and the default router. With mobile IP, the default router is supplied by the foreign agent, so this information is not needed. The address can be supplied by the home agent via mobile IP, so DHCP isn't needed for this either. The upshot is that only the home subnet mask is must be somehow configured. The two IDs are proposing a complex mechanism with unknown security characteristics consisting of reverse tunnels and DHCP relay agents in the home agent simply to provide the mobile node with the subnet mask? This doesn't make sense to me. It makes more sense to add a home agent registration reply extension that would provide the mobile node with its subnet mask (in fact, I may just write up an ID to do that). In summary, DHCP is a protocol designed for enterprise networks. It is not designed for wide area networks. We should not extend mobile IP to support it, since there are better ways of doing host configuration today than when DHCP was invented, that would work better in wide area networks. jak jak From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 13 12:20:34 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12388 for ; Fri, 13 Apr 2001 12:20:33 -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 JAA02003; Fri, 13 Apr 2001 09:17:36 -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 JAA05616; Fri, 13 Apr 2001 09:20:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3DGIoK9024941 for ; Fri, 13 Apr 2001 09:18:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3DGIoxm024940 for mobile-ip-dist; Fri, 13 Apr 2001 09:18: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3DGIfK9024932 for ; Fri, 13 Apr 2001 09:18: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 JAA05769 for ; Fri, 13 Apr 2001 09:18:41 -0700 (PDT) Message-Id: <200104131618.JAA05769@heliopolis.eng.sun.com> Date: Fri, 13 Apr 2001 09:18:41 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] Involvement w. 3Gs? (context transfer from Seamob y) To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: q2sadXixStBGvS6jJt9HzQ== 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: >Replacement of handsets and infrastructure is a wicked problem if you have >to answer to shareholders. GSM operators I've talked to say that they figure on a 3 year replacement time for handsets, and that handset backward compatibility is not a big issue for them. On the other hand, the US is different. One person in 3GPP2 told me they expected their analog phone in their car that they bought in the early 1980's to continue working indefinitely. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 13 13:32:44 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14830 for ; Fri, 13 Apr 2001 13:32:43 -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 KAA03567; Fri, 13 Apr 2001 10:29: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 KAA08362; Fri, 13 Apr 2001 10:19:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3DHIVK9025126 for ; Fri, 13 Apr 2001 10:18:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3DHIUtn025125 for mobile-ip-dist; Fri, 13 Apr 2001 10:18: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3DHIMK9025118 for ; Fri, 13 Apr 2001 10:18: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 KAA08346 for ; Fri, 13 Apr 2001 10:18:20 -0700 (PDT) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA21712 for ; Fri, 13 Apr 2001 11:27:11 -0600 (MDT) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Fri Apr 13 13:15:49 EDT 2001 Received: from valjean.dnrc.bell-labs.com (valjean [135.180.240.120]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id NAA02944 for ; Fri, 13 Apr 2001 13:18:13 -0400 (EDT) Received: (from salga@localhost) by valjean.dnrc.bell-labs.com (8.11.0/8.8.7) id f3DHI1J09269 for mobile-ip@sunroof.eng.sun.com; Fri, 13 Apr 2001 13:18:01 -0400 Date: Fri, 13 Apr 2001 13:18:01 -0400 From: Luca Salgarelli To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] dynamic home addressing as a WG item?? Message-ID: <20010413131801.G8454@bell-labs.com> Mail-Followup-To: mobile-ip@sunroof.eng.sun.com References: <200104131615.JAA05667@heliopolis.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104131615.JAA05667@heliopolis.eng.sun.com>; from James.Kempf@sun.com on Fri, Apr 13, 2001 at 09:15:09AM -0700 X-Organization: Bell Laboratories Sender: owner-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, this is a loooong mail :-). I'll try to be brief: > ... > If corporate networks want this, they should be arranging for VPNs with > their ISPs. DHCP was designed for and is primarily deployed in > co-operatively managed, enterprise networks, not the kinds of wide area > networks that mobile IP is being used for. The standard way to extend > such networks remotely is to set up a VPN. > > Here's an example of how extending DHCP to wide area networks can go > awry. Last year, a friend of mine signed up for DSL service from the > local telephone company. After it was installed, he turned on his > Windows box, browsed into Network Neighborhood, and ended up on his > neighbor's hard drive. > > DHCP doesn't have the right kind of security characteristics for wide > area networks. VPNs do. I know there is work underway to address security > for DHCP, but since the design center for the protocol is enterprise > networks, the work is probably going to assume all kinds of supporting > infrastructure that may not be there for wide area cases. > > So if we extend DHCP to wide area networks through mobile IP, we'd end up > having to go through another extensive security analysis to figure out > how to make sure that there were no security holes. The two existing > drafts are just the tip of the iceberg in terms of the work needed. I don't think we are "extending" DHCP to go wide area. I see the HA(-FA)-Mobile tunnel as an extension of the home (or corporate) network in the wide-area. That extension can also be made secure using IPSec. If you accept this model at least for some scenarios, why can't you put DHCP *on top* of it? That tunnel simply enables your mobile to operate exactly as if it were at home, with exactly the same security characteristics (provided IPSec works well...). At the very least this is as secure as the basic Mobile-IP is. > ... > > And I'd like to stress that I don't believe it is the right technical > decision to use a protocol that was designed for co-operatively managed > enterprise networks in wide area networks. Again, as mentioned above, > there are cases where this has been done that I've seen that have > resulted in not good stuff happening. The two situations have different > characteristics with respect to security. This is simply not true if the model is the one I outlined above. > >I don't know if you read previous notes from Sandy's about this (I think > >it was a response to Pat), but this scheme won't just be so simple if > >the mobile goes home. Simply put, if the HA is responsible for a pool of > >addresses, the client will have to keep re-registering even if it is at > >home in order to defend the address. > > So? If DHCP were used by the client, it would have to renew the lease > periodically anyway. What's the difference? That Mobile-IP simply does not tell you that you have to keep registering when you are at home. > You didn't respond to my analysis about exactly what configuration > information we are talking about, but let me return to that point. I did not respond because I think that we are talking about two different models. In my mind, the model is that Mobile-IP serves as an extension of your home-network when you go away. In that scenario, the configuration information are exactly the same that my PC gets through DHCP today when I power it up in my office, i.e. DNS servers, domain name, default gateway, plus possibly IMAP server and HTTP proxy. > Let's leave IPv6 out of the picture, since I think we can both figure out > better ways to do this than DHCP (although I'm sure if DHCP gets > integrated with mobile IP in IPv4, people will want it for IPv6, which > will only perpetuate the problem). > > Suppose we agree that service discovery information (3 on my previous > email) isn't a sufficiently good reason to integrate DHCP. There are > other ways to do service discovery, and, frankly, the mobile node may > want to discover this information locally rather than in the home > network. For example, if I want to print something, I'll want to print it > locally, not back in my office. There may additionally be some services > that might have to be discovered in the home network. The upshot is, > there are complexities to service discovery, and simply punching a > reverse tunnel with DHCP back to the home network isn't going to solve > the problem. Why not? It seems to be solving it well for clients that are at home. Again, my point is that you might want to apply the same model for some nomadic users that use Mobile-IP. > Point 2 on my previous email was the DNS server. This is difficult to > bootstrap with service discovery. An IPv4 mobile node would need to have > this information configured because it cannot discover it, but it is not > clear that providing it from the home network is the right way to go > either. Signalling times may be lengthy if a home network DNS server is > used, it might make more sense to get this information locally somehow > too. I don't know how the 3GPP2 network currently does this, but I > suspect it is done through Radius/PPP somehow. It seems to me that there > may be work here extending the current method, but probably DHCP is not > the way to go either. Hmmmm, if you want to access nodes that are inside your corporate network that you reach through Mobile-IP (plus possibly IPSec) you will need to use a DNS server which is inside your corporation. > The upshot is that only the home subnet mask is must be somehow > configured. The two IDs are proposing a complex mechanism with unknown > security characteristics consisting of reverse tunnels and DHCP relay > agents in the home agent simply to provide the mobile node with the > subnet mask? You don't need to add any DHCP relay agent to the HA using Transient Tunneling: you just need to have the client act like one, which is trivial. The Home Agent can be a stock RFC2002/2794/3024-compatible one. Transient-tunnel does not modify standard Mobile-IP at all. > This doesn't make sense to me. It makes more sense to add a home agent > registration reply extension that would provide the mobile node with its > subnet mask (in fact, I may just write up an ID to do that). This coul be fine if these are really the only configuration parameters you need. If you really need something more (see my note on corporate-DNS above), you are really making a routing protocol (MIP) the distributor of configuration information. Furthermore all this is fine until you go home, where you would have to keep registering with your HA to "defend" your registration information. > In summary, DHCP is a protocol designed for enterprise networks. It is > not designed for wide area networks. We should not extend mobile IP to > support it, since there are better ways of doing host configuration today > than when DHCP was invented, that would work better in wide area > networks. I assume you have read draft-thuel-mobileip-tt-01.txt: I don't think we are extending Mobile-IP *at all*: we are simply outlining a way to use a Mobile-IP tunnel to have DHCP run on top of it, which by the way means that we are not extending DHCP either to wide area networks, if you accept the notion that a Mobile-IP tunnel buys you a transparent extension to your home network. Luca From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 13 18:24:19 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19555 for ; Fri, 13 Apr 2001 18:24:19 -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 PAA11126; Fri, 13 Apr 2001 15:20: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 PAA09255; Fri, 13 Apr 2001 15:23:30 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3DMM2K9025578 for ; Fri, 13 Apr 2001 15:22:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3DMM2Hq025577 for mobile-ip-dist; Fri, 13 Apr 2001 15:22: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3DMLrK9025570 for ; Fri, 13 Apr 2001 15:21: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 PAA15343 for ; Fri, 13 Apr 2001 15:21:54 -0700 (PDT) Message-Id: <200104132221.PAA15343@heliopolis.eng.sun.com> Date: Fri, 13 Apr 2001 15:21:54 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] dynamic home addressing as a WG item?? To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ltV/wYLMVWgPINWVEvntcg== 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 Luca, >this is a loooong mail :-). I'll try to be brief: > Yes, well, it doesn't look like we have much that we agree on here. Hopefully, now that our views are known, we can agree to disagree. Maybe somebody else out there in SMTP land has an opinion? >I don't think we are "extending" DHCP to go wide area. I see the >HA(-FA)-Mobile tunnel as an extension of the home (or corporate) network in >the wide-area. That extension can also be made secure using IPSec. If you >accept this model at least for some scenarios, why can't you put DHCP *on >top* of it? That tunnel simply enables your mobile to operate exactly as if >it were at home, with exactly the same security characteristics (provided >IPSec works well...). At the very least this is as secure as the basic >Mobile-IP is. > Extending the corporate network to mobile (as opposed to nomadic) users by defining a VPN-like overlay on top of mobile IP is a very interesting and relevent technical topic. We could certainly open a mailing list, collect drafts, even hold a BOF on it, might make a good working group. But that is not what is being proposed. What is being proposed in draft-thuel-mobileip-tt-01.txt and draft-glass-mobileip-agent-dhcp-proxy-01.txt is to either relay or punch a temporary tunnel back to the home network. After the relay or temporary tunnel is done, the mobile node is still in the remote network. The mobile node is not a node on the home network, this is extending DHCP to the wide area, as I said. It simply does not solve the problem of configuring a mobile node. >This is simply not true if the model is the one I outlined above. > The two proposals under discussion don't address the model you outlined. They address something far simpler and more dangerous. Like the camel's nose in the tent. > >> So? If DHCP were used by the client, it would have to renew the lease >> periodically anyway. What's the difference? > >That Mobile-IP simply does not tell you that you have to keep registering >when you are at home. > So maybe this is a defect in mobile IP that needs to be fixed. >In my mind, the model is that Mobile-IP serves as an extension of your >home-network when you go away. In that scenario, the configuration This is, in my mind, erroneous. People are talking about doing location based services on the mobile node. It's a completely different model than the VPN/nomadic model. Nobody talks about location based services for a VPN/nomadic model. >information are exactly the same that my PC gets through DHCP today when I >power it up in my office, i.e. DNS servers, domain name, default gateway, >plus possibly IMAP server and HTTP proxy. > Agreed, there may be some configuration information that the mobile may need from the home network. The IMAP server is a good example. But in a wide area networking situation, these could better be delivered by AAA. >Why not? It seems to be solving it well for clients that are at home. >Again, my point is that you might want to apply the same model for some >nomadic users that use Mobile-IP. > I disagree. I think the wide area, mobile model is different from the nomadic model. I think the difference is what makes the mobile model interesting. Like, for example, location based services. Most nomadic users don't care about this, because they are sitting somewhere and not moving, connected up into their corporate network. If they care, then they only need to access location based service info once, like, for example, browse the web page for Dallas-Fort Worth airport while they are sitting in the departure lounge with their laptop. With mobile users, it gets more interesting. The services change as you are walking down the street, or thorough the airport mall. I can't imagine how a static, one time, non-attribute based configuration mechanism like DHCP could possibly deal with providing the kind of rich, multifacted, time-varying configuration needed by a mobile user. Integrating it with mobile IP will only confuse the issue. >Hmmmm, if you want to access nodes that are inside your corporate network >that you reach through Mobile-IP (plus possibly IPSec) you will need to use >a DNS server which is inside your corporation. > Agreed, but, again, this could be delivered via AAA, as, I presume it is today in 3GPP2. >You don't need to add any DHCP relay agent to the HA using Transient >Tunneling: you just need to have the client act like one, which is trivial. >The Home Agent can be a stock RFC2002/2794/3024-compatible one. >Transient-tunnel does not modify standard Mobile-IP at all. > But you still have to punch the tunnel. After the tunnel goes away, the mobile node is thrown back onto the remote network, where the configuration info it gets from DHCP may or may not make sense. A simple example. Suppose I am a mobile user and I want to use the local DNS server in the DFW airport to find location-based information on the location of shops selling gifts, because I want to buy one to take home for my wife. If I get my DNS server force-configured from my home network via DHCP, I can't find a thing locally. >This coul be fine if these are really the only configuration parameters you >need. If you really need something more (see my note on corporate-DNS >above), you are really making a routing protocol (MIP) the distributor of >configuration information. > AAA isn't MIP, it's AAA. Having MIP do the routing protocol configuration, as is done in IPv6, and some other technique, like AAA, do the home network service configuration makes more sense to me than using an enterprise based protocol like DHCP. There still needs to be some way of discovering locally available services, however. >Furthermore all this is fine until you go home, where you would have to >keep registering with your HA to "defend" your registration information. > Right, so we change MIP to let you do this via MIP. >I assume you have read draft-thuel-mobileip-tt-01.txt: I don't think we are >extending Mobile-IP *at all*: we are simply outlining a way to use a >Mobile-IP tunnel to have DHCP run on top of it, which by the way means that >we are not extending DHCP either to wide area networks, if you accept the >notion that a Mobile-IP tunnel buys you a transparent extension to your >home network. > Yes, I read it, and, like I said, I think it is extending DHCP to wide area networks. Once the transient tunnel goes away, the mobile node is left high and dry on the remote network, where the configuration information from the home network may or may not make sense. It makes sense to me that there needs to be some way of configuring routing parameters. MIP is a routing protocol, so let's use it for configuring routing parameters. Furthermore, it also makes sense to me that there may need to be some way of configuring home network parameters on a mobile node, like the IMAP server, maybe DNS if the mobile node wants to get back into the corporate network, but also maybe NOT DNS if the mobile node wants location based services in the roamed network. Like I said, this is a complex issue, it needs proper study, and it is not aimeable to a simple hack like punching a temporary tunnel back to the home agent, or having the home agent act like a DHCP relay. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 13 19:36:42 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 TAA20601 for ; Fri, 13 Apr 2001 19:36:41 -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 QAA22483; Fri, 13 Apr 2001 16:34: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 QAA21900; Fri, 13 Apr 2001 16:34:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3DNXZK9025688 for ; Fri, 13 Apr 2001 16:33:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3DNXYqw025687 for mobile-ip-dist; Fri, 13 Apr 2001 16:33:34 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3DNXPK9025680 for ; Fri, 13 Apr 2001 16:33:26 -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 QAA26180 for ; Fri, 13 Apr 2001 16:33:25 -0700 (PDT) Received: from c007.snv.cp.net (c007-h014.c007.snv.cp.net [209.228.33.221]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id QAA10363 for ; Fri, 13 Apr 2001 16:33:24 -0700 (PDT) Received: (cpmta 9141 invoked from network); 13 Apr 2001 16:33:24 -0700 Received: from unknown (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.221) with SMTP; 13 Apr 2001 16:33:24 -0700 X-Sent: 13 Apr 2001 23:33:24 GMT Message-ID: <048401c0c472$0041c500$6501a8c0@philneum> From: "Phil Neumiller" To: , Subject: [mobile-ip] WG Announcement of Appeal: 3G Biases in SeaMoby and MIP Date: Fri, 13 Apr 2001 18:29:35 -0500 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: Attn: SeaMoby and Mobile IP WG members. Description of Appeal ---------------------- As permitted by RFC 2026 section 6.5.1 an individual (or individuals) may disagree with a WG recommendation and may approach the IESG for an appeal in a case where the WG has made an incorrect technical choice which places the quality and/or integrity of the Working Group's product(s) in significant jeopardy. In a nutshell, my appeal, is that: the SeaMoby and Mobile IP WGs have been mis-directed to focus too much on the interests of a group of outside standards development organizations, namely 3GPP (http://www.3gpp.org/) and 3GPP2 (http://www.3gpp2.org/), rather than enhancing the global Internet which is the IETF's primary directive per RFC 2026 section 1.1 which I quote a subsection here for convenience: "In the case of protocols developed and/or standardized by non-Internet organizations, however, the Internet Standards Process normally applies to the application of the protocol or procedure in the Internet context, not to the specification of the protocol itself." I will attempt to prove in this appeals process that the mobileip and seamoby WGs have been developing protocols primarily for a non-Internet organization [namely 3GPP and 3GPP2] and have not kept the Internet context of their process as their primary focus. In this case, I believe the technical error to be in both the mobile IP and SeaMoby WG agendas themselves (therefore by direct consequence each of the WG's priorities), so the appeal is more appropriately directed at the IESG than the WG members or chairs. Since, WG members and chairs must abide by the IESG approved agenda for the WG. In this appeal I will not implicate any individual WG member or chair and all member names will be removed from quotations used in my case. I will refer to a "WG chair" as just that, and a "WG member" as just that, thus removing any prejudices that could intervene in my interest of fairness and the technical correctness of my appeal. I can provide on demand the names of the quoted individuals to the ADs or the IESG if an AD or the IESG needs to cross reference or ask further questions. Next Steps ------------ The matter has been discussed repeatedly and at length with the WG chairs and members on the said lists and they have repeatedly stated that they recognize no bias in the WG activities. By section 6.5.1 of RFC 2026 I hereby open this appeals process to the mobileip and seamoby WGs as a whole for debate. NOTE: This is the final chance for each WG to resolve this issue internally before the appeal will be brought formally to the ADs and possibly the IESG. After the discussion, which [we can agree] to conclude on April 20, 2001 [provided the chairs and ADs believe this is enough time], and if this appeal can not be resolved within the mobileip and seamoby WG confines, the matter will be taken to the ADs for resolution. I welcome the ADs to monitor this public airing of the appeals notice to the WGs and interject guidence as necessary. As WG members concerned about mobility and the global Internet please reply to this message with your own comments that are directly pertinent to this appeal to the ADs and possibly the IESG itself. If you wish your comments to be anonymous please send them to the ADs or WG chairs directly where your privacy will be respected [I request that an anonymous version be reposted to the list by the ADs and/or chairs on this thread]. Thanks, Phil Neumiller From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 13 20:20:45 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20983 for ; Fri, 13 Apr 2001 20:20: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 RAA23309; Fri, 13 Apr 2001 17:17: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 RAA02591; Fri, 13 Apr 2001 17:20:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3E0J2K9025772 for ; Fri, 13 Apr 2001 17:19:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3E0J2Ip025771 for mobile-ip-dist; Fri, 13 Apr 2001 17:19: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3E0IpK9025764 for ; Fri, 13 Apr 2001 17:18:51 -0700 (PDT) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA21253; Fri, 13 Apr 2001 17:18:50 -0700 (PDT) Received: from darius (darius [152.70.40.121]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id RAA11409; Fri, 13 Apr 2001 17:18:32 -0700 (PDT) Date: Fri, 13 Apr 2001 17:18:32 -0700 (PDT) From: Patrice Calhoun Subject: [mobile-ip] Re: [seamoby] WG Announcement of Appeal: 3G Biases in SeaMoby and MIP To: Phil Neumiller Cc: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org In-Reply-To: "Your message with ID" <048401c0c472$0041c500$6501a8c0@philneum> 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: > Attn: SeaMoby and Mobile IP WG members. > > Description of Appeal > ---------------------- > As permitted by RFC 2026 section 6.5.1 an individual (or individuals) may > disagree with a WG recommendation and may approach the IESG for an > appeal in a case where the WG has made an incorrect technical choice which > places the quality and/or integrity of the Working Group's product(s) in > significant jeopardy. > > In a nutshell, my appeal, is that: the SeaMoby and Mobile IP WGs have > been mis-directed to focus too much on the interests of a group of outside > standards development organizations, namely 3GPP (http://www.3gpp.org/) > and 3GPP2 (http://www.3gpp2.org/), rather than enhancing the global Internet > which is the IETF's primary directive per RFC 2026 section 1.1 which I > quote a subsection here for convenience: > > "In the case of protocols developed and/or standardized by non-Internet > organizations, however, the Internet Standards Process normally applies > to the application of the protocol or procedure in the Internet context, > not to the specification of the protocol itself." > > I will attempt to prove in this appeals process that the mobileip and seamoby > WGs have been developing protocols primarily for a non-Internet organization > [namely 3GPP and 3GPP2] and have not kept the Internet context of their > process as their primary focus. > > In this case, I believe the technical error to be in both the mobile IP and > SeaMoby WG agendas themselves (therefore by direct consequence each of > the WG's priorities), so the appeal is more appropriately directed at the > IESG than the WG members or chairs. Since, WG members and chairs must abide > by the IESG approved agenda for the WG. > > In this appeal I will not implicate any individual WG member or chair and all > member names will be removed from quotations used in my case. I will refer > to a "WG chair" as just that, and a "WG member" as just that, thus removing > any prejudices that could intervene in my interest of fairness and the > technical correctness of my appeal. I can provide on demand the names of > the quoted individuals to the ADs or the IESG if an AD or the IESG needs to > cross reference or ask further questions. > > Next Steps > ------------ > The matter has been discussed repeatedly and at length with the WG chairs and > members on the said lists and they have repeatedly stated that they > recognize no bias in the WG activities. By section 6.5.1 of RFC 2026 I > hereby open this appeals process to the mobileip and seamoby WGs as a whole > for debate. > > NOTE: > This is the final chance for each WG to resolve this issue internally before > the appeal will be brought formally to the ADs and possibly the IESG. > > After the discussion, which [we can agree] to conclude on April 20, 2001 > [provided the chairs and ADs believe this is enough time], and if this appeal > can not be resolved within the mobileip and seamoby WG confines, the matter > will be taken to the ADs for resolution. Given that I will be on vacation, and not have access to the Internet, between April 14th through the 22nd, I would ask for this timeline to be extended to April 30th. PatC From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 13 21:36:57 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA22454 for ; Fri, 13 Apr 2001 21:36: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 SAA14889; Fri, 13 Apr 2001 18:33: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 SAA04431; Fri, 13 Apr 2001 18:36:40 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3E1VoK9025856 for ; Fri, 13 Apr 2001 18:31:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3E1Vn3n025855 for mobile-ip-dist; Fri, 13 Apr 2001 18:31: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3E1VcK9025848 for ; Fri, 13 Apr 2001 18:31:41 -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 SAA11106 for ; Fri, 13 Apr 2001 18:31:15 -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 TAA09910 for ; Fri, 13 Apr 2001 19:42:05 -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 SAA19235; Fri, 13 Apr 2001 18:30:37 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3E1UaL24274; Fri, 13 Apr 2001 18:30:36 -0700 X-mProtect: Fri, 13 Apr 2001 18:30:36 -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(WTS.12.69) smtpd4ZLvT3; Fri, 13 Apr 2001 18:30:30 PDT Message-ID: <3AD7A87E.5492B509@iprg.nokia.com> Date: Fri, 13 Apr 2001 18:31:42 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: seamoby@cdma-2000.org, Phil Roberts , "Basavaraj Patil (NTC/Dallas)" Subject: Re: [mobile-ip] WG Announcement of Appeal: 3G Biases in SeaMoby and MIP References: <048401c0c472$0041c500$6501a8c0@philneum> 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, I'm confused about how you can tell whether the working groups were biased. What if the working groups were just working on the agenda items suggested by the participants? Can you suggest an alternative agenda which would not have shown the effects of the claimed bias? What else should the working groups have been working on, other than the things that were brought into discussion by the participants? As someone who was involved in the mobile-ip working group, and also who tried to become familiar with the needs of 3GPP2 and 3GPP, I don't know if I would be considered to be objective. With that understanding, however, I'll state anyway that I don't think the agenda in the mobile-ip working was subservient to the needs of outside SDOs. In fact, even before there was substantial input from those organizations, we had already made a lot of discussion about regional registration (called in those days Hierarchical Foreign Agents). Questions about smooth handover are of more recent vintage, but do not show evidence of being under the control of 3GPP*. There were some drafts to exhibit 3G requirements. I don't think they progressed to Informational RFC, and I don't remember too much recent discussion. Can you characterize the effects of the claimed bias? For possible comparison purposes, I can suggest some things that didn't happen, which would have been more solid evidence of bias: - Allowing GTP as a tunneling choice along with IP-within-IP tunneling - Insertion of additional round trips to HLR before granting network access - Allowing PPP as a tunneling choice along with IP-within-IP tunneling (...maybe it would have been a good idea, though!...) - Specification of SS-7 proxies These things didn't happen. Some things more directly related to 3GPP2 were actively discussed, but they could not at all be characterized as displacing other more important topics like Mobile IPv6. I think you have a very difficult case to make, given the available evidence. Lastly, I do not think that the discussion raised by considerations of 3G requirements have had the harmful effect you claim, except unless you believe that adopting IETF standards would have the effect of making those standards longer-lived and thus antithetical to your goals for a longer time. Regards, Charlie P. Phil Neumiller wrote: > Description of Appeal > ---------------------- > As permitted by RFC 2026 section 6.5.1 an individual (or individuals) may > disagree with a WG recommendation and may approach the IESG for an > appeal in a case where the WG has made an incorrect technical choice which > places the quality and/or integrity of the Working Group's product(s) in > significant jeopardy. > > In a nutshell, my appeal, is that: the SeaMoby and Mobile IP WGs have > been mis-directed to focus too much on the interests of a group of outside > standards development organizations, namely 3GPP (http://www.3gpp.org/) > and 3GPP2 (http://www.3gpp2.org/), rather than enhancing the global Internet > which is the IETF's primary directive per RFC 2026 section 1.1 which I > quote a subsection here for convenience: > > "In the case of protocols developed and/or standardized by non-Internet > organizations, however, the Internet Standards Process normally applies > to the application of the protocol or procedure in the Internet context, > not to the specification of the protocol itself." > > I will attempt to prove in this appeals process that the mobileip and seamoby > WGs have been developing protocols primarily for a non-Internet organization > [namely 3GPP and 3GPP2] and have not kept the Internet context of their > process as their primary focus. > > In this case, I believe the technical error to be in both the mobile IP and > SeaMoby WG agendas themselves (therefore by direct consequence each of > the WG's priorities), so the appeal is more appropriately directed at the IESG > than the WG members or chairs. Since, WG members and chairs must abide > by the IESG approved agenda for the WG. > > In this appeal I will not implicate any individual WG member or chair and all > member names will be removed from quotations used in my case. I will refer > to a "WG chair" as just that, and a "WG member" as just that, thus removing > any prejudices that could intervene in my interest of fairness and the technical > correctness of my appeal. I can provide on demand the names of the quoted > individuals to the ADs or the IESG if an AD or the IESG needs to cross > reference or ask further questions. > > Next Steps > ------------ > The matter has been discussed repeatedly and at length with the WG chairs and > members on the said lists and they have repeatedly stated that they recognize no > bias in the WG activities. By section 6.5.1 of RFC 2026 I hereby open this > appeals process to the mobileip and seamoby WGs as a whole for debate. > > NOTE: > This is the final chance for each WG to resolve this issue internally before the > appeal will be brought formally to the ADs and possibly the IESG. > > After the discussion, which [we can agree] to conclude on April 20, 2001 > [provided the chairs and ADs believe this is enough time], and if this appeal > can not be resolved within the mobileip and seamoby WG confines, the matter > will be taken to the ADs for resolution. I welcome the ADs to monitor this > public airing of the appeals notice to the WGs and interject guidence as > necessary. > > As WG members concerned about mobility and the global Internet please > reply to this message with your own comments that are directly pertinent to this > appeal to the ADs and possibly the IESG itself. If you wish your comments > to be anonymous please send them to the ADs or WG chairs directly where > your privacy will be respected [I request that an anonymous version be reposted > to the list by the ADs and/or chairs on this thread]. > > Thanks, > > Phil Neumiller From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 13 22:08: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 WAA22696 for ; Fri, 13 Apr 2001 22:08:42 -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 TAA26286; Fri, 13 Apr 2001 19:08: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 TAA15749; Fri, 13 Apr 2001 19:08:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3E26iK9025944 for ; Fri, 13 Apr 2001 19:06:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3E26iDV025943 for mobile-ip-dist; Fri, 13 Apr 2001 19:06: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3E26ZK9025936 for ; Fri, 13 Apr 2001 19:06:35 -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 TAA00894 for ; Fri, 13 Apr 2001 19:06:34 -0700 (PDT) Received: from cwcsun41.cwc.nus.edu.sg (cwcsun41.cwc.nus.edu.sg [137.132.163.102]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA21272 for ; Fri, 13 Apr 2001 19:06:26 -0700 (PDT) Received: from santhosh ([172.16.2.114]) by cwcsun41.cwc.nus.edu.sg (8.9.3/8.9.3) with SMTP id KAA23187 for ; Sat, 14 Apr 2001 10:05:16 +0800 (SGT) Message-ID: <002b01c0c488$023814c0$720210ac@cwc.nus.edu.sg> From: "Santhosh K. Pilakkat" To: References: <048401c0c472$0041c500$6501a8c0@philneum> Subject: Re: [mobile-ip] WG Announcement of Appeal: 3G Biases in SeaMoby and MIP Date: Sat, 14 Apr 2001 10:09:59 +0800 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 > In a nutshell, my appeal, is that: the SeaMoby and Mobile IP WGs have > been mis-directed to focus too much on the interests of a group of outside > standards development organizations, namely 3GPP (http://www.3gpp.org/) > and 3GPP2 (http://www.3gpp2.org/), rather than enhancing the global Internet > which is the IETF's primary directive per RFC 2026 section 1.1 which I > quote a subsection here for convenience: > > "In the case of protocols developed and/or standardized by non-Internet > organizations, however, the Internet Standards Process normally applies > to the application of the protocol or procedure in the Internet context, > not to the specification of the protocol itself." With out going into the merits of WG Agenda - Aren't you contradicting your appeal squarely here? 1. the focus should be "..enhancing the global Internet which is the IETF's primary directive per RFC 2026 ...". - 3GPP and 3GPP2 networks can be expected to be the largest networks/user base that will use the work products of these WGs, hence enhancing the global Internet. What can be a beetre way than have the greatest number of deployment/ adopters? 2. the quote above, the way I read it is exempting the need for other standard organisations to use Internet Process (I.e 3GPP and 3GPP2 can have their own standardisation process to come out with standards. Only the application of theses standards in the Internet context need to be guided by internet standards following Internet process. The standards themselves need not.). In the case of the WGs, the protocol themselves are standardized by the WGs (and not 3GPP or 3GPP2, though they will adopt it with their due process similar to the one you quoted). Regards Santhosh From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 13 23:11:04 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA24192 for ; Fri, 13 Apr 2001 23:11: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 UAA06749; Fri, 13 Apr 2001 20:07:50 -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 UAA10143; Fri, 13 Apr 2001 20:10:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3E35ZK9026005 for ; Fri, 13 Apr 2001 20:05:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3E35Xwe026004 for mobile-ip-dist; Fri, 13 Apr 2001 20:05: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3E35CK9025997 for ; Fri, 13 Apr 2001 20:05:13 -0700 (PDT) Received: from awe171-106 (awe195-32.AWE.Sun.COM [192.29.195.32]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id UAA20249; Fri, 13 Apr 2001 20:05:09 -0700 (PDT) Message-Id: <200104140305.UAA20249@heliopolis.eng.sun.com> Date: Fri, 13 Apr 2001 18:57:45 -0700 (PDT) From: kempf Subject: Re: [mobile-ip] WG Announcement of Appeal: 3G Biases in SeaMoby and MIP To: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 3PDL/hTB/dPWf5Ntsa0iPg== 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: Phil, Since you seem to have enough time on your hands for this kind of thing, why don't you broaden out your crusade a bit? Here are some other examples: - The IPng working group is having an interim meeting in Seattle next month, at which 3GPP will be presenting requirements. Surely another example of IETF developing standards for the 3Gs. - Some active members from 3GPP (attending IETF as individuals, since that is the only status recognized at IETF) presented requirements to the AAA working group at IETF 50. Yet another example. - Some active members from 3GPP presented requirements at the SIP working group at IETF 50. - And perhaps the worst violation of all: The MEGACO working group developed a protocol for talking to softswitches with IP that was subsequently adopted by the ITU! C'mon. The fact that these groups are coming to IETF for help is a sign of *success*. We need to be expanding our contacts with these groups (hence my email yesterday to the mobile IP list about trying to get 3GPP to move more in the direction of MIP). MIP adoption by 3GPP2 and MEGACO adoption by ITU are great success stories, we need more of them. We just need to make sure they understand the Internet architecture, and the consequences of changing it. IETF would be shooting itself in the foot (or maybe a bit higher, like the head) if it would ignore what are obvious customers for our protocols. People whose companies are participants in the 3Gs are just as welcome, as individuals, as anyone else. jak >X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f >X-Sent: 13 Apr 2001 23:33:24 GMT >From: "Phil Neumiller" >To: , >Subject: [mobile-ip] WG Announcement of Appeal: 3G Biases in SeaMoby and MIP >Date: Fri, 13 Apr 2001 18:29:35 -0500 >X-Priority: 3 >X-MSMail-Priority: Normal >X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 >List-Archive: >List-Owner: >List-Subscribe: >List-Unsubscribe: >Attn: SeaMoby and Mobile IP WG members. > >Description of Appeal >---------------------- >As permitted by RFC 2026 section 6.5.1 an individual (or individuals) may >disagree with a WG recommendation and may approach the IESG for an >appeal in a case where the WG has made an incorrect technical choice which >places the quality and/or integrity of the Working Group's product(s) in >significant jeopardy. > >In a nutshell, my appeal, is that: the SeaMoby and Mobile IP WGs have >been mis-directed to focus too much on the interests of a group of outside >standards development organizations, namely 3GPP (http://www.3gpp.org/) >and 3GPP2 (http://www.3gpp2.org/), rather than enhancing the global Internet >which is the IETF's primary directive per RFC 2026 section 1.1 which I >quote a subsection here for convenience: > > "In the case of protocols developed and/or standardized by non-Internet > organizations, however, the Internet Standards Process normally applies > to the application of the protocol or procedure in the Internet context, > not to the specification of the protocol itself." > >I will attempt to prove in this appeals process that the mobileip and seamoby >WGs have been developing protocols primarily for a non-Internet organization >[namely 3GPP and 3GPP2] and have not kept the Internet context of their >process as their primary focus. > >In this case, I believe the technical error to be in both the mobile IP and >SeaMoby WG agendas themselves (therefore by direct consequence each of >the WG's priorities), so the appeal is more appropriately directed at the IESG >than the WG members or chairs. Since, WG members and chairs must abide >by the IESG approved agenda for the WG. > >In this appeal I will not implicate any individual WG member or chair and all >member names will be removed from quotations used in my case. I will refer >to a "WG chair" as just that, and a "WG member" as just that, thus removing >any prejudices that could intervene in my interest of fairness and the technical >correctness of my appeal. I can provide on demand the names of the quoted >individuals to the ADs or the IESG if an AD or the IESG needs to cross >reference or ask further questions. > >Next Steps >------------ >The matter has been discussed repeatedly and at length with the WG chairs and >members on the said lists and they have repeatedly stated that they recognize no >bias in the WG activities. By section 6.5.1 of RFC 2026 I hereby open this >appeals process to the mobileip and seamoby WGs as a whole for debate. > >NOTE: >This is the final chance for each WG to resolve this issue internally before the >appeal will be brought formally to the ADs and possibly the IESG. > >After the discussion, which [we can agree] to conclude on April 20, 2001 >[provided the chairs and ADs believe this is enough time], and if this appeal >can not be resolved within the mobileip and seamoby WG confines, the matter >will be taken to the ADs for resolution. I welcome the ADs to monitor this >public airing of the appeals notice to the WGs and interject guidence as >necessary. > >As WG members concerned about mobility and the global Internet please >reply to this message with your own comments that are directly pertinent to this >appeal to the ADs and possibly the IESG itself. If you wish your comments >to be anonymous please send them to the ADs or WG chairs directly where >your privacy will be respected [I request that an anonymous version be reposted >to the list by the ADs and/or chairs on this thread]. > >Thanks, > >Phil Neumiller > > From owner-mobile-ip@sunroof.eng.sun.com Sat Apr 14 02:08: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 CAA09192 for ; Sat, 14 Apr 2001 02:08:47 -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 XAA14068; Fri, 13 Apr 2001 23:08: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 XAA23785; Fri, 13 Apr 2001 23:08:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3E67BK9026176 for ; Fri, 13 Apr 2001 23:07:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3E67BWK026175 for mobile-ip-dist; Fri, 13 Apr 2001 23:07:11 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3E671K9026168 for ; Fri, 13 Apr 2001 23:07:02 -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 XAA23727 for ; Fri, 13 Apr 2001 23:07:02 -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 XAA13539 for ; Fri, 13 Apr 2001 23:07:01 -0700 (PDT) Received: from ws34.nomadiclab.com (ws34.nomadiclab.com [195.165.196.34]) by ws130.nomadiclab.com (Postfix) with ESMTP id ABA7072503; Sat, 14 Apr 2001 09:06:58 +0300 (EEST) Received: from nomadiclab.com (localhost [127.0.0.1]) by ws34.nomadiclab.com (Postfix) with ESMTP id 48827BA0B; Sat, 14 Apr 2001 09:06:57 +0300 (EEST) Message-ID: <3AD7EA9A.726AB396@nomadiclab.com> Date: Sat, 14 Apr 2001 09:13:46 +0300 From: Pekka Nikander X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,fi MIME-Version: 1.0 To: Michael Thomas Cc: "Charles E. Perkins" , MobileIP Mailing List Subject: My apologies to Michael Thomas and others (Re: [mobile-ip] A less drafty draft) References: <3AD5B9CA.CF550C7B@rd.francetelecom.fr> <15061.49804.692345.636891@thomasm-u1.cisco.com> <3AD5D85E.654DCCAB@iprg.nokia.com> <15061.56795.208181.755937@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, Please accept my sincere apologies that I have hurt your feelings by being involved in a process that has caused you hard feelings. And please forgive me that I cannot say much more, partly because I don't understand all that is going on, partly because of my vocabulary lacking. Charlie, I think that we definitely must acknowledge Michael and Dave Oran and a number of other people in the BAKE draft. It was an oversight from my part that I did not check the acknowledgements section wrt the people that helped me/us. My apologies to everybody involved -- I definitely recognize some of you, but please don't get upset if I/we forget you even from the next revision of the BAKE draft. (And when you inidicate our fault, it would be nice if you remember that kindness hurts less. :-) That said, let me express my belief that developing requirements in isolation from what is technically possible and what is not is seldom if ever the most productive way of conducting things. BAKE is a result of designing from one starting point. Michael, your still unpublished design is another. Things being as they are, maybe you should go ahead and submit it to the directories. SUCV (which I like very much) is a result from starting at another starting point. My still unpublished but SUCV resembling design is yet another. The CAM approach by Microsoft Research is still yet another. I have probably forgotten some, and there are sure others to appear. In the case of Mobile IPv6 security, I think that we still do not know what is technically possible and what is not. That is, I am aware of quite little scientific work that covers cryptographic protocols that are meant to build relative security out of "nothing". That is, according to a commonly accepted principle, you cannot build secure security associations unless you have already some existing security relationship. However, what you can do and what you cannot, if you don't have an existing relationship, is (to my knowledge) largely unknown. That is, independent of whether we proceed to a Proposed Standard within a very quick timeframe or not, I do expect the scientific crypto protocols community to take apart our standards proposal and to rip it into pieces. In fact, I think it would be best to proceed into a PS as soon as possible, since that would give us some publicity, leading to increased interest in "beating us" by the crypto protocol analysis people. And that, in turn, is the only way we can increase our knowledge and eventually get a solution whose limitations we do understand properly. Yet in other words: my only motivation in getting the BAKE draft out soon was to foster analysis and discussion so that we would, in the end, get the best possible protocol that we can get, given our current level of understanding. The fact that you, Michael, and maybe some other people feel betrayed (or whatever) is most unfortunate, and I cannot but express my apologies. Yours sincerely, --Pekka Michael Thomas wrote: > > What you are of course not bringing up is that > Dave Oran and I had a concrete draft on this > subject from *before* IETF 50 which I shared with > both you and Pekka. I see that you two have > incorporated several of the features of the draft > as well, though unacknowledged. I have been > waiting to publish it because we agreed to wait > for the chairs to lay out the ground rules and > form the design team. Yet you've decided -- again > -- to take matters into your own hands and start > the process that is very likely to extend this for > a very long time. > > Express faux-surprise all you like. I find it > rather disingenuous. It needn't have been this > way. ...snip... (the rest cut away) From owner-mobile-ip@sunroof.eng.sun.com Sat Apr 14 04:51:54 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA10188 for ; Sat, 14 Apr 2001 04:51:53 -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 BAA13947; Sat, 14 Apr 2001 01: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 BAA08200; Sat, 14 Apr 2001 01:51:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3E8oMK9026323 for ; Sat, 14 Apr 2001 01:50:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3E8oMbi026322 for mobile-ip-dist; Sat, 14 Apr 2001 01:50: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3E8oCK9026315 for ; Sat, 14 Apr 2001 01:50:12 -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 BAA26728 for ; Sat, 14 Apr 2001 01:50:11 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA01676 for ; Sat, 14 Apr 2001 01:50:10 -0700 (PDT) Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id BAA10833 for ; Sat, 14 Apr 2001 01:50:33 -0700 (PDT) Message-Id: <5.0.2.1.2.20010414011934.03f18328@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sat, 14 Apr 2001 01:41:36 -0700 To: mobile-ip@sunroof.eng.sun.com From: Fred Baker Subject: [mobile-ip] the security issue In-Reply-To: <3AD7EA9A.726AB396@nomadiclab.com> References: <3AD5B9CA.CF550C7B@rd.francetelecom.fr> <15061.49804.692345.636891@thomasm-u1.cisco.com> <3AD5D85E.654DCCAB@iprg.nokia.com> <15061.56795.208181.755937@thomasm-u1.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:13 AM 4/14/2001 +0300, Pekka Nikander wrote: >That is, according to a commonly accepted principle, you cannot build >secure security associations unless you have already some existing >security relationship. You actually can, but they are of limited value. IKE generates a security association ex nihilo using a diffie-helman algorithm, which allows you to keep private information private and enables you to be sure you are still talking with the same person. The problem you are referring to is that you don't authoritatively know who that person *is* apart from a security association demonstrably set up with the person you intend. You are depending on a dynamic association (and therefore key) to authenticate the Home Agent or the Mobile Node and determine whether either is authorized to instruct you to change your binding association. But a dynamic association only tells you that you are talking with the same process you spoke with before, not that the process is indeed the authorized agent. For all you know, it is a law enforcement agency wishing to inspect your communications, or the bad guys who want to use your communications to your harm. >That is, independent of whether we proceed to a Proposed Standard within a >very quick timeframe or not IMHO, you can go to PS with optimized routing (which I think is a truly cool feature) if and only if you can solve the authentication/authorization problem, because you don't want people hijacking connections, and IPSEC unfortunately forces you into assuming some form of global PKI. The simplest thing for the working group will be to cull that out separately and take the dogleg routing part to PS. Optimized Routing can then be done with a little less pressure. As I understand it, Optimized Routing is something the Correspondent Node is required to understand, but not required to use. This would be consistent with that. A simple suggestion *might* be to have the mobile node send its correspondent a certificate containing the appropriate public key, so that the correspondent can know for certain that it received something properly authenticated. Problem there is the exchange that would carry that - it is one thing for the mobile node to include an option, but it is quite another for it to send a separate exchange using a different protocol and assume that the correspondent is using the protocol, and no firewall has decided to block it, and no snooper got in and sent a different one first. Who authorizes the authority? From owner-mobile-ip@sunroof.eng.sun.com Sun Apr 15 23:08:32 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA16139 for ; Sun, 15 Apr 2001 23:08: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 UAA07513; Sun, 15 Apr 2001 20:07: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 UAA20792; Sun, 15 Apr 2001 20:07:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3G2NkK9029331 for ; Sun, 15 Apr 2001 19:23:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3G2Njd2029330 for mobile-ip-dist; Sun, 15 Apr 2001 19:23: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3G2NaK9029323 for ; Sun, 15 Apr 2001 19:23:37 -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 TAA05722 for ; Sun, 15 Apr 2001 19:23:32 -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 TAA20693 for ; Sun, 15 Apr 2001 19:23:31 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA04511; Sun, 15 Apr 2001 22:23:31 -0400 Date: Sun, 15 Apr 2001 22:23:31 -0400 (EDT) From: Jim Bound To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] dynamic home addressing as a WG item?? In-Reply-To: <200104131615.JAA05667@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: VPNs have their major problems too like they created the need for Virtual Routing Domains and IMO to make this short it sucks. /jim On Fri, 13 Apr 2001, James Kempf wrote: > Hi Luca, > > > >We can debate about this forever, but that does not mean that the DHCP > >specs we have today for IPv4 don't do a good job in distributing > >configuration information, and not only addresses. Otherwise how do you > >justify its widespread use? > > > > Because it was there first and it did an OK job and there were no > competitors. And also, BTW, because Microsoft, the volume > OS vendor for nomadic (as opposed to mobile) hosts, put it into their OS. It > doesn't mean DHCP is the best way today with other choices available. > > Moving forward (and this debate is all about futures, there is no > widespread, global mobility available today), I simply don't think > it is the right technical decision to take a protocol that was > designed to fill a hole in IPv4 routing and address provisioning > for co-operatively managed enterprise networks but grew into a general purpose > configuration protocol simply because there were no competitors, and > extend it into the protocol for configuring globally mobile IP hosts. > > >I agree on the 3GPP2 comment, and I also agree on the fact that 3GPP2 today > >is the major utilizer of Mobile-IP. But I disagree with respect to a couple > >of points: > > > >1) Making Mobile-IP able to gracefully support DHCP does not mean that > >every Mobile-IP network *MUST* deploy and use DHCP. It only means that who > >*wants* to (e.g. corporate networks) will be able to do it. > > > > If corporate networks want this, they should be arranging for VPNs with > their ISPs. DHCP was designed for and is primarily deployed in co-operatively > managed, enterprise networks, not the kinds of wide area networks that mobile IP > is being used for. The standard way to extend such networks remotely > is to set up a VPN. > > Here's an example of how extending DHCP to wide area > networks can go awry. Last year, a friend of mine signed up for > DSL service from the local telephone company. After it was installed, > he turned on his Windows box, browsed into Network Neighborhood, > and ended up on his neighbor's hard drive. > > DHCP doesn't have the right kind of security characteristics for > wide area networks. VPNs do. I know there is work underway to address security > for DHCP, but since the design center for the protocol is enterprise > networks, the work is probably going to assume all kinds of supporting > infrastructure that may not be there for wide area cases. > > So if we extend DHCP to wide area networks through mobile IP, we'd > end up having to go through another extensive security analysis > to figure out how to make sure that there were no security holes. > The two existing drafts are just the tip of the iceberg in terms of the > work needed. > > >2) The fact that today's 3GPP2 clients use PPP and RADIUS to configure > >their addresses does not mean that they won't need something else to > >configure their (corporate?) home addresses in some scenarios. > > > > Right, if they want to remotely extend this functionality, they should > use a VPN. That's how it is done today. > > Now, perhaps there needs to be some work to address how to extend VPNs > to mobile, as opposed to nomadic, users, but that is orthogonal to > whether extensions to mobile IP are needed to support DHCP. > > >Again, I would like to stress point (1), which I pointed out already in my > >previous e-mails: we are not talking about a mechanism that HAS TO be > >deployed. We are talking about leaving the possibility open for ISP's that > >want to use it. > > > > And I'd like to stress that I don't believe it is the right technical > decision to use a protocol that was designed for co-operatively > managed enterprise networks in wide area networks. Again, as mentioned above, > there are cases where this has been done that I've seen that have resulted > in not good stuff happening. The two situations have different > characteristics with respect to security. > > >I don't know if you read previous notes from Sandy's about this (I think it > >was a response to Pat), but this scheme won't just be so simple if the > >mobile goes home. Simply put, if the HA is responsible for a pool of > >addresses, the client will have to keep re-registering even if it is at > >home in order to defend the address. > > > > So? If DHCP were used by the client, it would have to renew the lease > periodically anyway. What's the difference? > > > You didn't respond to my analysis about exactly what configuration information > we are talking about, but let me return to that point. Let's leave > IPv6 out of the picture, since I think we can both figure out better > ways to do this than DHCP (although I'm sure if DHCP gets integrated > with mobile IP in IPv4, people will want it for IPv6, which will only > perpetuate the problem). > > Suppose we agree that service discovery information (3 on my previous email) > isn't a sufficiently good reason to integrate DHCP. There are other > ways to do service discovery, and, frankly, the mobile node may want to discover > this information locally rather than in the home network. For example, > if I want to print something, I'll want to print it locally, not back > in my office. There may additionally be some services that might > have to be discovered in the home network. The upshot is, there are > complexities to service discovery, and simply punching a reverse tunnel > with DHCP back to the home network isn't going to solve the problem. > > Point 2 on my previous email was the DNS server. This is difficult > to bootstrap with service discovery. An IPv4 mobile node would need > to have this information configured because it cannot discover it, but it is not > clear that providing it from the home network is the right way to go either. > Signalling times may be lengthy if a home network DNS server is used, it might > make more sense to get this information locally somehow too. I don't know > how the 3GPP2 network currently does this, but I suspect it is done > through Radius/PPP somehow. It seems to me that there may be work here > extending the current method, but probably DHCP is not the way to go either. > > Point 1 on my previous email was routability configuration. In IPv4, > this consists of the address, the subnet mask, and the default router. > With mobile IP, the default router is supplied by the foreign agent, > so this information is not needed. The address can be supplied by the > home agent via mobile IP, so DHCP isn't needed for this either. > > The upshot is that only the home subnet mask is must be somehow configured. > The two IDs are proposing a complex mechanism with unknown security > characteristics consisting of reverse tunnels and DHCP relay agents in the home > agent simply to provide the mobile node with the subnet mask? This doesn't make > sense to me.. It makes more sense to add a home agent registration reply > extension that would provide the mobile node with its subnet mask (in fact, I > may just write up an ID to do that). > > In summary, DHCP is a protocol designed for enterprise networks. It > is not designed for wide area networks. We should not extend mobile > IP to support it, since there are better ways of doing host configuration > today than when DHCP was invented, that would work better in wide > area networks. > > jak > > jak > From owner-mobile-ip@sunroof.eng.sun.com Sun Apr 15 23:39:10 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA16655 for ; Sun, 15 Apr 2001 23:39:09 -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 UAA20398; Sun, 15 Apr 2001 20:38:57 -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 UAA07845; Sun, 15 Apr 2001 20:35:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3G2cFK9029343 for ; Sun, 15 Apr 2001 19:38:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3G2cDQ8029342 for mobile-ip-dist; Sun, 15 Apr 2001 19:38: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3G2c2K9029335 for ; Sun, 15 Apr 2001 19:38:05 -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 TAA19403 for ; Sun, 15 Apr 2001 19:38:02 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id UAA02675 for ; Sun, 15 Apr 2001 20:58:53 -0600 (MDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA04050; Sun, 15 Apr 2001 22:38:01 -0400 Date: Sun, 15 Apr 2001 22:38:01 -0400 (EDT) From: Jim Bound To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] WG Announcement of Appeal: 3G Biases in SeaMoby and MIP In-Reply-To: <048401c0c472$0041c500$6501a8c0@philneum> 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: Phil, Can you state one thing done in MIP v4 or v6 that holds your claim for the appeal? Seamoby is still in brainstorm mode and has produced no fruit. Not saying your not right but I watch this too and don't see the issue here. I do agree reqs definition and some architecture is wise? thanks /jim On Fri, 13 Apr 2001, Phil Neumiller wrote: > Description of Appeal > ---------------------- > As permitted by RFC 2026 section 6.5.1 an individual (or individuals) may > disagree with a WG recommendation and may approach the IESG for an > appeal in a case where the WG has made an incorrect technical choice which > places the quality and/or integrity of the Working Group's product(s) in > significant jeopardy. > > In a nutshell, my appeal, is that: the SeaMoby and Mobile IP WGs have > been mis-directed to focus too much on the interests of a group of outside > standards development organizations, namely 3GPP (http://www.3gpp.org/) > and 3GPP2 (http://www.3gpp2.org/), rather than enhancing the global Internet > which is the IETF's primary directive per RFC 2026 section 1.1 which I > quote a subsection here for convenience: > > "In the case of protocols developed and/or standardized by non-Internet > organizations, however, the Internet Standards Process normally applies > to the application of the protocol or procedure in the Internet context, > not to the specification of the protocol itself." > > I will attempt to prove in this appeals process that the mobileip and seamoby > WGs have been developing protocols primarily for a non-Internet organization > [namely 3GPP and 3GPP2] and have not kept the Internet context of their > process as their primary focus. > > In this case, I believe the technical error to be in both the mobile IP and > SeaMoby WG agendas themselves (therefore by direct consequence each of > the WG's priorities), so the appeal is more appropriately directed at the IESG > than the WG members or chairs. Since, WG members and chairs must abide > by the IESG approved agenda for the WG. > > In this appeal I will not implicate any individual WG member or chair and all > member names will be removed from quotations used in my case. I will refer > to a "WG chair" as just that, and a "WG member" as just that, thus removing > any prejudices that could intervene in my interest of fairness and the technical > correctness of my appeal. I can provide on demand the names of the quoted > individuals to the ADs or the IESG if an AD or the IESG needs to cross > reference or ask further questions. > > Next Steps > ------------ > The matter has been discussed repeatedly and at length with the WG chairs and > members on the said lists and they have repeatedly stated that they recognize no > bias in the WG activities. By section 6.5.1 of RFC 2026 I hereby open this > appeals process to the mobileip and seamoby WGs as a whole for debate. > > NOTE: > This is the final chance for each WG to resolve this issue internally before the > appeal will be brought formally to the ADs and possibly the IESG. > > After the discussion, which [we can agree] to conclude on April 20, 2001 > [provided the chairs and ADs believe this is enough time], and if this appeal > can not be resolved within the mobileip and seamoby WG confines, the matter > will be taken to the ADs for resolution. I welcome the ADs to monitor this > public airing of the appeals notice to the WGs and interject guidence as > necessary. > > As WG members concerned about mobility and the global Internet please > reply to this message with your own comments that are directly pertinent to this > appeal to the ADs and possibly the IESG itself. If you wish your comments > to be anonymous please send them to the ADs or WG chairs directly where > your privacy will be respected [I request that an anonymous version be reposted > to the list by the ADs and/or chairs on this thread]. > > Thanks, > > Phil Neumiller > > From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 16 02:01:55 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA26116 for ; Mon, 16 Apr 2001 02:01:54 -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 XAA20384; Sun, 15 Apr 2001 23:01: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 WAA19277; Sun, 15 Apr 2001 22:58:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3G53tK9029734 for ; Sun, 15 Apr 2001 22:03:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3G53sik029733 for mobile-ip-dist; Sun, 15 Apr 2001 22:03: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3G53iK9029726 for ; Sun, 15 Apr 2001 22:03:46 -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 WAA27224 for ; Sun, 15 Apr 2001 22:03:38 -0700 (PDT) Received: from internaut.com ([64.38.134.99]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA10782 for ; Sun, 15 Apr 2001 22:03:37 -0700 (PDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id VAA69826 for ; Sun, 15 Apr 2001 21:57:25 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Sun, 15 Apr 2001 21:57:25 -0700 (PDT) From: Bernard Aboba To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] WG Announcement of Appeal: 3G Biases in SeaMoby and MIP 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: Not sure I see the issue either, unless you can point to specific technical or process problems. Developing protocols for a community of users isn't a sin by itself, assuming that the protocols are technically sound. In fact, if anything, the IETF probably needs to be more sensitive to the concerns of operators, not less. While it may be worthwhile to be concerned about a "rush to judgement" there isn't much in the recent past which suggests that the IETF is becoming hasty -- in fact, in most cases, some sense of urgency would be welcome. On Sun, 15 Apr 2001, Jim Bound wrote: > Phil, > > Can you state one thing done in MIP v4 or v6 that holds your claim for the > appeal? Seamoby is still in brainstorm mode and has produced no fruit. > Not saying your not right but I watch this too and don't see the issue > here. I do agree reqs definition and some architecture is wise? > > thanks > > /jim > From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 16 10:38:14 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04799 for ; Mon, 16 Apr 2001 10:38: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 HAA17393; Mon, 16 Apr 2001 07:32: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 HAA19721; Mon, 16 Apr 2001 07:34:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3GDvTK9000230 for ; Mon, 16 Apr 2001 06:57:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3GDvS7D000229 for mobile-ip-dist; Mon, 16 Apr 2001 06:57: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3GDvHK9000222 for ; Mon, 16 Apr 2001 06:57:18 -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 GAA27902 for ; Mon, 16 Apr 2001 06:57:18 -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 GAA12953 for ; Mon, 16 Apr 2001 06:57:17 -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 JAA03714; Mon, 16 Apr 2001 09:57:14 -0400 (EDT) Message-Id: <200104161357.JAA03714@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-reg-revok-00.txt Date: Mon, 16 Apr 2001 09:57:14 -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 : Registration Revocation in Mobile IP Author(s) : S. Glass Filename : draft-ietf-mobileip-reg-revok-00.txt Pages : 20 Date : 13-Apr-01 During the original design of Mobile IP, the potential need for an administrative domain to be able to actively revoke a current Mobile IP registration was recognized. Due to the lack of a specific scenario requiring such a mechanism, it was decided that instead of designing a mechanism explicitly for the purpos of registration revocation, a passive mechanism, namely short registration lifetimes, and the denial of a subsequent registration of a MN, would be sufficient for this purpose. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-reg-revok-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-reg-revok-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-reg-revok-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010413122103.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-reg-revok-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-reg-revok-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010413122103.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 16 12:17:51 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07623 for ; Mon, 16 Apr 2001 12:17:51 -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 JAA03198; Mon, 16 Apr 2001 09:16: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 JAA16350; Mon, 16 Apr 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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3GFsDK9000527 for ; Mon, 16 Apr 2001 08:54:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3GFsCQ9000523 for mobile-ip-dist; Mon, 16 Apr 2001 08:54: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 eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3GFrxK9000508 for ; Mon, 16 Apr 2001 08:54:00 -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 LAA19303 for ; Mon, 16 Apr 2001 11:53:59 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id LAA27623 for mobile-ip@sunroof.eng.sun.com; Mon, 16 Apr 2001 11:54:09 -0400 (EDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CK0aK9020813 for ; Thu, 12 Apr 2001 13:00: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 NAA19897 for ; Thu, 12 Apr 2001 13:00:35 -0700 (PDT) Received: from htt-consult.com (homebase.htt-consult.com [65.84.78.210]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id NAA00166 for ; Thu, 12 Apr 2001 13:00:33 -0700 (PDT) Received: from rgm.htt-consult.com ([65.84.78.214]) by htt-consult.com ; Thu, 12 Apr 2001 15:58:58 -0400 Message-Id: <5.0.0.25.2.20010412134432.029127d0@localhost> X-Sender: rgm@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 12 Apr 2001 15:58:40 -0400 To: Francis Dupont , mobile-ip@sunroof.eng.sun.com From: Robert Moskowitz Subject: Re: [mobile-ip] -New ID about Address owernship- Cc: hipsec@mail.freeswan.org In-Reply-To: <200104121737.f3CHb6A52770@givry.rennes.enst-bretagne.fr> References: 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 07:37 PM 4/12/2001 +0200, Francis Dupont wrote: >Note I am not (yet) a member of the hipsec list so if >this mail bounces it should be reposted in the list... it got through. >I have a concern about to use the HIP stuff for the mobile IPv6 security >because HIP was designed to "rapidly establish an ESP Security Association" >so it is very powerful but expensive: >There is significant overhead associated with building HIP-based SAs >(both in terms of CPU cycles, but also in terms of required message flows) much less than IKE. 4 packets, as defined. DSA/RSA and D-H operations in line with SSL/TLS >This has negative implications for larger servers that process many 100s >of thousands of connections at a time or for smaller mobile nodes that >are short in processor and battery resources >(you have recognized the argument :-). Similar to WTLS 1.2 What kind of server maintains 100,000s of concurrent connections? These typically have hardware boosts of all kinds, particularly if they are doing things like SSL already. >An illustration: HIP provides a good protection against DoS attacks, >in fact this is not really an advantage: HIP must provide this because >HIP mechanisms involve a lot of powerful/expensive crypto which could >make DoS attacks very prejudicial... Any key exchange mechanism adds to the risk of DoS attacks, but a well worked out mechanism should also remove exposure to transport level attacks. For MIP's initial usage of HIP only being used for BUs, HIP's goal would be to protect the BUs and give the CN's trust in them. > The less drafty draft uses only SHA-1 which is far less expensive: the > exact requirements for mobile IPv6 security are not yet available but HIP > seems to overfulfill them. To the later, that it may. SHA-1 is less expensive than any PK crypto, no one can argue that. Does 'drafty draft' meet reasonable security requirements? There are others better than I to evaluate it; some of them evaluated HIP and help me get its security complete. I offer HIP for a number of reasons: I am working on HIP for secure Internet model that understands 'addressing realms' (like IPv4and v6 co-existing and NAT traversal) and flexible mobility. It is HARD to get a trusted binding between two hosts. Shortcuts tend to be longcuts, in that they are later found to be flawed; 'good enough' (look at WEP) can end up being no protection at all. HIP has had a reasonable peer review and is itself based on other mechanisms like SSL, IKE, SKIP, and Photuris. >BTW I like very much the SUCV address idea but section 6.1 should >be simplify/adapted (i.e. not cut&pasted from the HIP document). I do not know if SUCV will be secure, I am studying it. Allowing a HIT that is an SUCV is a no-brainer, and if it makes sense (as I told Gabriel) consider it done. The opertunistic mode of HIP needs further development and I am doing that. Consider for a moment where a BU HELLO is equivalent in HIP to the I1 HIP packet. Also note that an optimization of HIP could allow for a data payload INSIDE of I2 (but not appended after, as the intiator does not get the responder's SPI until R2). The ESP transform used im MIP for BUs could be ESP NULL with HMAC-SHA1-96. Once the initial HIP exchange is completed, ESP is used for all future exchanges until either a timeout (could be set fairly long here) or loss of state (CN or MN boot). HIP as written in my 3 IDs is a full protocol. There is much that others can do to target it to particular opportunities. >Regards > >Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 16 12:30:44 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07813 for ; Mon, 16 Apr 2001 12:30:43 -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 JAA14858; Mon, 16 Apr 2001 09:25:09 -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 JAA19121; Mon, 16 Apr 2001 09:28:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3GG7vK9000550 for ; Mon, 16 Apr 2001 09:07:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3GG7uha000549 for mobile-ip-dist; Mon, 16 Apr 2001 09:07: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3GG7jK9000542 for ; Mon, 16 Apr 2001 09:07:47 -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 JAA14711 for ; Mon, 16 Apr 2001 09:07:46 -0700 (PDT) Received: from hyomin.dongeui.ac.kr (hyomin.dongeui.ac.kr [203.241.192.9]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA01620 for ; Mon, 16 Apr 2001 09:07:43 -0700 (PDT) Received: from kslpc ([203.241.205.136]) by hyomin.dongeui.ac.kr (8.9.3/8.9.3) with SMTP id BAA05517 for ; Tue, 17 Apr 2001 01:11:18 +0900 (KST) Message-ID: <004601c0c68f$286981c0$88cdf1cb@dongeui.ac.kr> From: "Kye-Sang Lee" To: Subject: [mobile-ip] Minneapolis Minutes ? Date: Tue, 17 Apr 2001 01:06:12 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0043_01C0C6DA.982F9800" 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 Sender: owner-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_0043_01C0C6DA.982F9800 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGksIGFsbC4NCg0KSSdtIGxvb2tpbmcgZm9yIHRoZSBtaW51dGVzIG9mIE1pbm5lYXBvbGlzIG1v YmlsZWlwIHdnIG1lZXRpbmcuDQpQbGVhc2UgZm9yd2FyZCBvbmUuDQoNClRoYW5rcyBhIGxvdCwg aW4gYWR2YW5jZS4NCg0KTGVlLg0K ------=_NextPart_000_0043_01C0C6DA.982F9800 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjAwLjI2MTQuMzUwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhpLCBhbGwu PC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkknbSBs b29raW5nIGZvciB0aGUgbWludXRlcyBvZiBNaW5uZWFwb2xpcyBtb2JpbGVpcCB3ZyANCm1lZXRp bmcuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+UGxlYXNlIGZvcndhcmQgb25lLjwv Rk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5UaGFua3Mg YSBsb3QsIGluIGFkdmFuY2UuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+ PEZPTlQgc2l6ZT0yPkxlZS48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0043_01C0C6DA.982F9800-- From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 16 12:56:09 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08347 for ; Mon, 16 Apr 2001 12:56:09 -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 JAA09212; Mon, 16 Apr 2001 09:55: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 JAA15058; Mon, 16 Apr 2001 09:53:10 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3GGUDK9000643 for ; Mon, 16 Apr 2001 09:30:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3GGUDS4000642 for mobile-ip-dist; Mon, 16 Apr 2001 09:30: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3GGU2K9000635 for ; Mon, 16 Apr 2001 09:30:03 -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 JAA13385 for ; Mon, 16 Apr 2001 09:30:01 -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 JAA17872 for ; Mon, 16 Apr 2001 09:30:00 -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 JAA11476; Mon, 16 Apr 2001 09:30:00 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3GGTuq10807; Mon, 16 Apr 2001 09:29:56 -0700 X-mProtect: Mon, 16 Apr 2001 09:29:56 -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(WTS.12.69) smtpdBsJdCB; Mon, 16 Apr 2001 09:29:46 PDT Message-ID: <3ADB1DFD.1076622D@iprg.nokia.com> Date: Mon, 16 Apr 2001 09:29:49 -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: Kory Keith CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Question about Registration Replies and RFC2002bis References: <20010406143350.46943.qmail@web11207.mail.yahoo.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 Kory, I'm finally catching up, please excuse the delay... > In RFC 2002bis, it clearly states that the MN should > send 0.0.0.0 as it source address in the IP field of > the Registration Request when requesting a Dynamic > Home Address. (3.6.1.1). Correct. > My question is about 3.7.2.3 where it states the > following: > > IP Destination Address > Copied from the IP Source Address of the > Registration Request. > > If I read this correctly, the Foreign Agent is meant > to send the Registration Reply to the MN with a > destination address of 0.0.0.0 in the IP header. How > can this be valid when 0.0.0.0 is a reserved address > in the IP standard and should not be used as a > destination address?? That's a good question. This language is a holdover from RFC 2002, by which it was not possible to use 0.0.0.0. Unfortunately, I think the answer is that there isn't a good answer. The choices seem to be: - 0.0.0.0 - 255.255.255.255 - 224.0.0.1 - subnet-directed broadast, _if_ the Prefix Information Option has been included in the Agent Advertisements. Probably arguments could be made for all of them, but I would sort-of favor the third one if we were starting from a clean slate. For any of the choices, the foreign agent should deliver the Registration Reply to only one layer-2 address. If the document comes back from IESG again with requests for additional revision, perhaps this is a change that could be made. Does anyone else have comments about what should be changed? I think at least some clarification should be added to the specification. Regards, Charlie P. > > Kory Keith > > __________________________________________________ > Do You Yahoo!? > Get email at your own domain with Yahoo! Mail. > http://personal.mail.yahoo.com/ From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 16 12:56:23 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08362 for ; Mon, 16 Apr 2001 12:56: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 JAA09158; Mon, 16 Apr 2001 09:55: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 JAA15055; Mon, 16 Apr 2001 09:53:10 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3GGYRK9000665 for ; Mon, 16 Apr 2001 09:34:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3GGYQTn000664 for mobile-ip-dist; Mon, 16 Apr 2001 09:34: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 eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3GGYKK9000657 for ; Mon, 16 Apr 2001 09:34:21 -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 MAA28478 for ; Mon, 16 Apr 2001 12:34:20 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id MAA28306 for mobile-ip@sunroof.eng.sun.com; Mon, 16 Apr 2001 12:34:30 -0400 (EDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3E0XXK9025816 for ; Fri, 13 Apr 2001 17:33: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 RAA04187 for ; Fri, 13 Apr 2001 17:33:33 -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 RAA07794 for ; Fri, 13 Apr 2001 17:33:32 -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 RAA16685; Fri, 13 Apr 2001 17:33:01 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3E0X0m24003; Fri, 13 Apr 2001 17:33:00 -0700 X-mProtect: Fri, 13 Apr 2001 17:33:00 -0700 Nokia Silicon Valley Messaging Protection Received: from dhcp-3-129.iprg.nokia.com (205.226.3.129, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdyWnara; Fri, 13 Apr 2001 17:32:53 PDT Message-ID: <3AD79BC7.9FBD3355@iprg.nokia.com> Date: Fri, 13 Apr 2001 17:37:27 -0700 From: Cedric Westphal Organization: NOKIA X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Phil Neumiller CC: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org Subject: [mobile-ip] Re: [seamoby] WG Announcement of Appeal: 3G Biases in SeaMoby and MIP References: <048401c0c472$0041c500$6501a8c0@philneum> 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 Phil, assuming your appeal is validated, and there is indeed a bias in MIP and seamoby towards 3GPPs, what would be the consequences? I have a hard time figuring out what is the purpose of this crusade. If it makes you happy, I'll agree to all the biases you want. Yes, many members of MIP and seamoby WG that earn a paycheck get it from one of the 76 companies that are 3GPP2 members (including all 3 chairs, one area director, one technical advisor, and yourself till a couple weeks ago). Do they influence the outcome? You bet. QED. WGs are biased. Congratulations, you won. To answer my first question, what consequences? I suggest to ban from the IETF all these pesky corporate sell-outs working for cisco, lucent, nokia, sun, nortel, etc. They are way too influential. Cedric. Phil Neumiller wrote: > Attn: SeaMoby and Mobile IP WG members. > > Description of Appeal > ---------------------- > As permitted by RFC 2026 section 6.5.1 an individual (or individuals) may > disagree with a WG recommendation and may approach the IESG for an > appeal in a case where the WG has made an incorrect technical choice which > places the quality and/or integrity of the Working Group's product(s) in > significant jeopardy. > > In a nutshell, my appeal, is that: the SeaMoby and Mobile IP WGs have > been mis-directed to focus too much on the interests of a group of outside > standards development organizations, namely 3GPP (http://www.3gpp.org/) > and 3GPP2 (http://www.3gpp2.org/), rather than enhancing the global Internet > which is the IETF's primary directive per RFC 2026 section 1.1 which I > quote a subsection here for convenience: > > "In the case of protocols developed and/or standardized by non-Internet > organizations, however, the Internet Standards Process normally applies > to the application of the protocol or procedure in the Internet context, > not to the specification of the protocol itself." > > I will attempt to prove in this appeals process that the mobileip and seamoby > WGs have been developing protocols primarily for a non-Internet organization > [namely 3GPP and 3GPP2] and have not kept the Internet context of their > process as their primary focus. > > In this case, I believe the technical error to be in both the mobile IP and > SeaMoby WG agendas themselves (therefore by direct consequence each of > the WG's priorities), so the appeal is more appropriately directed at the IESG > than the WG members or chairs. Since, WG members and chairs must abide > by the IESG approved agenda for the WG. > > In this appeal I will not implicate any individual WG member or chair and all > member names will be removed from quotations used in my case. I will refer > to a "WG chair" as just that, and a "WG member" as just that, thus removing > any prejudices that could intervene in my interest of fairness and the technical > correctness of my appeal. I can provide on demand the names of the quoted > individuals to the ADs or the IESG if an AD or the IESG needs to cross > reference or ask further questions. > > Next Steps > ------------ > The matter has been discussed repeatedly and at length with the WG chairs and > members on the said lists and they have repeatedly stated that they recognize no > bias in the WG activities. By section 6.5.1 of RFC 2026 I hereby open this > appeals process to the mobileip and seamoby WGs as a whole for debate. > > NOTE: > This is the final chance for each WG to resolve this issue internally before the > appeal will be brought formally to the ADs and possibly the IESG. > > After the discussion, which [we can agree] to conclude on April 20, 2001 > [provided the chairs and ADs believe this is enough time], and if this appeal > can not be resolved within the mobileip and seamoby WG confines, the matter > will be taken to the ADs for resolution. I welcome the ADs to monitor this > public airing of the appeals notice to the WGs and interject guidence as > necessary. > > As WG members concerned about mobility and the global Internet please > reply to this message with your own comments that are directly pertinent to this > appeal to the ADs and possibly the IESG itself. If you wish your comments > to be anonymous please send them to the ADs or WG chairs directly where > your privacy will be respected [I request that an anonymous version be reposted > to the list by the ADs and/or chairs on this thread]. > > Thanks, > > Phil Neumiller From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 16 14:04:24 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10189 for ; Mon, 16 Apr 2001 14:04: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 LAA10900; Mon, 16 Apr 2001 11:00:59 -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 KAA00365; Mon, 16 Apr 2001 10:58:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3GHYTK9000955 for ; Mon, 16 Apr 2001 10:34:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3GHYStm000954 for mobile-ip-dist; Mon, 16 Apr 2001 10:34: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 eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3GHYKK9000947 for ; Mon, 16 Apr 2001 10:34:21 -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 NAA11322 for ; Mon, 16 Apr 2001 13:34:19 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id NAA29304 for mobile-ip@sunroof.eng.sun.com; Mon, 16 Apr 2001 13:34:31 -0400 (EDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3GDkDK9000197 for ; Mon, 16 Apr 2001 06:46:14 -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 GAA11747 for ; Mon, 16 Apr 2001 06:46:12 -0700 (PDT) Received: from htt-consult.com (homebase.htt-consult.com [65.84.78.210]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id GAA07134 for ; Mon, 16 Apr 2001 06:46:11 -0700 (PDT) Received: from rgm.htt-consult.com ([65.84.78.214]) by htt-consult.com ; Mon, 16 Apr 2001 09:44:49 -0400 Message-Id: <5.0.0.25.2.20010416092944.0291a1f0@localhost> X-Sender: rgm@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 16 Apr 2001 09:44:01 -0400 To: Mohan Parthasarathy , claude.castelluccia@inrialpes.fr, mobile-ip@sunroof.eng.sun.com From: Robert Moskowitz Subject: Re: [mobile-ip] -New ID about Address owernship- Cc: hipsec@mail.freeswan.org In-Reply-To: <200104122133.f3CLXVB2465124@jurassic.eng.sun.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 02:32 PM 4/12/2001 -0700, Mohan Parthasarathy wrote: Back from the holidays... >I am assuming that the HIP cookie is newly generated for every >transaction and this should help prevent replay attacks when msg3 >is replayed with an invalid signature. I could not verify >this anywhere. I have not built a state machine for the SUCV draft, but in HIP.... It is easy for an implementation to handle an apparent replay attack of I2 packets. After receipt of the I2, the state machine moves forward to at least state: I1o,Ro1 Since I2 has the HIT in the clear, if the responder laready has state for that HIT, it MUST treat any I2 packets as a replay attack. The rewrite of HIP will have clear text instructing developers on handling attacks like this. >This protocol solves the address ownership problem of the MN. >But it does not really do any verification of the CN itself. >It can be easily done by CN signing the message and sending >the public key as part of msg2. But this is more work for >the CN even before it can verify that the MN is a valid >one or not. that is all true. There is a fair amount of discussion of this in the HIP architecture. This is part of why I had to go with 4 packets in HIP. I have the R1 packet totally independent of any information in the I1 packet. This allows the responder (in this case the CN) to off-line prepare the R1 packets and to use them for multiple initiators. Thus R1 can be signed and the initiator can establish trust of R's existance. This also means that the responder does not have any meaningful information about initiator until I2 and requiring an R2 packet in response to this information. The SUCV ID avoids MOST of the overhead (but not all!) of initial state management by only needing to track the SUCV, cookie, and SPI. It must not support signing of msg2, as this will allow for a serious resource attack on the CN. All engineering is a trade-off. You might look at the SUCV ID as a stepping stone to HIP in this regard. From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 16 16:37:26 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13380 for ; Mon, 16 Apr 2001 16:37:26 -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 NAA02656; Mon, 16 Apr 2001 13:36:23 -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 NAA29019; Mon, 16 Apr 2001 13:35:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3GK2PK9001157 for ; Mon, 16 Apr 2001 13:02:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3GK2KhP001156 for mobile-ip-dist; Mon, 16 Apr 2001 13:02: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3GK1vK9001149 for ; Mon, 16 Apr 2001 13:02:04 -0700 (PDT) Received: from sunray-mpke (sunray-mpke.Eng.Sun.COM [129.146.6.32]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id NAA01758; Mon, 16 Apr 2001 13:01:50 -0700 (PDT) Message-Id: <200104162001.NAA01758@heliopolis.eng.sun.com> Date: Mon, 16 Apr 2001 13:01:48 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Question about Registration Replies and RFC2002bis To: korykeith@yahoo.com, mobile-ip@sunroof.eng.sun.com Cc: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ZswogsaBW9pXh1JFUjCiqA== 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 Charlie, Another issue that came up here in the discussion about DHCP is that RFC 2002bis currently does not require the mobile node to periodically reregister when it is on the home network. If the mobile node gets a dynamic home address and the HA is maintaining it by DHCP, then the HA will periodically need to reregister. Does it make sense to also require the mobile node to reregister, or do you think this should be completely handled by the HA? jak >X-mProtect: Mon, 16 Apr 2001 09:29:56 -0700 Nokia Silicon Valley Messaging Protection >Date: Mon, 16 Apr 2001 09:29:49 -0700 >From: "Charles E. Perkins" >To: Kory Keith >CC: mobile-ip@sunroof.eng.sun.com >Subject: Re: [mobile-ip] Question about Registration Replies and RFC2002bis > >Hello Kory, > >I'm finally catching up, please excuse the delay... > >> In RFC 2002bis, it clearly states that the MN should >> send 0.0.0.0 as it source address in the IP field of >> the Registration Request when requesting a Dynamic >> Home Address. (3.6.1.1). > >Correct. > >> My question is about 3.7.2.3 where it states the >> following: >> >> IP Destination Address >> Copied from the IP Source Address of the >> Registration Request. >> >> If I read this correctly, the Foreign Agent is meant >> to send the Registration Reply to the MN with a >> destination address of 0.0.0.0 in the IP header. How >> can this be valid when 0.0.0.0 is a reserved address >> in the IP standard and should not be used as a >> destination address?? > >That's a good question. This language is a holdover from >RFC 2002, by which it was not possible to use 0.0.0.0. >Unfortunately, I think the answer is that there isn't >a good answer. The choices seem to be: > >- 0.0.0.0 >- 255.255.255.255 >- 224.0.0.1 >- subnet-directed broadast, _if_ the Prefix Information > Option has been included in the Agent Advertisements. > >Probably arguments could be made for all of them, but >I would sort-of favor the third one if we were starting >from a clean slate. For any of the choices, the foreign >agent should deliver the Registration Reply to only one >layer-2 address. > >If the document comes back from IESG again with requests >for additional revision, perhaps this is a change that >could be made. Does anyone else have comments about what >should be changed? I think at least some clarification >should be added to the specification. > >Regards, >Charlie P. > > > >> >> Kory Keith >> >> __________________________________________________ >> Do You Yahoo!? >> Get email at your own domain with Yahoo! Mail. >> http://personal.mail.yahoo.com/ From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 16 17:44:02 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14372 for ; Mon, 16 Apr 2001 17:44: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 OAA15974; Mon, 16 Apr 2001 14:42:59 -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 OAA18106; Mon, 16 Apr 2001 14:41:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3GLePK9001361 for ; Mon, 16 Apr 2001 14:40:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3GLeOnV001360 for mobile-ip-dist; Mon, 16 Apr 2001 14:40:24 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3GLeGK9001353 for ; Mon, 16 Apr 2001 14:40:16 -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 OAA25185 for ; Mon, 16 Apr 2001 14:40:17 -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 OAA13556 for ; Mon, 16 Apr 2001 14:40:03 -0700 (PDT) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id QAA13828 for ; Mon, 16 Apr 2001 16:40:02 -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 f3GLe2e10843 for ; Mon, 16 Apr 2001 16:40:02 -0500 (CDT) Message-ID: <3ADB585C.D2739923@usa.alcatel.com> Date: Mon, 16 Apr 2001 16:38:52 -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] WG Announcement of Appeal: 3G Biases in SeaMoby andMIP 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 Concur with Bernard 100%. However, I would have liked to see another petition making points on -WG chairs never asking for vote of confidence of the members in IETF meetings -WG chairs (very small numbers) making it a habit to bully poor members who dare to make comments by taking some voluntary time from their work -Conflict of interest issues such as WGs producing work largely coauthored by WG chairs. Bernard Aboba wrote: > Not sure I see the issue either, unless you can point to specific > technical or process problems. Developing protocols for a community of > users isn't a sin by itself, assuming that the protocols are technically > sound. In fact, if anything, the IETF probably needs to be more sensitive > to the concerns of operators, not less. While it may be worthwhile to be > concerned about a "rush to judgement" there isn't much in the recent past > which suggests that the IETF is becoming hasty -- in fact, in most cases, > some sense of urgency would be welcome. > > -- Behcet From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 16 18:38:15 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14873 for ; Mon, 16 Apr 2001 18:38:14 -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 PAA26462; Mon, 16 Apr 2001 15:37: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 PAA07511; Mon, 16 Apr 2001 15:36:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3GMYQK9001409 for ; Mon, 16 Apr 2001 15:34:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3GMYPxB001408 for mobile-ip-dist; Mon, 16 Apr 2001 15:34: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3GMYGK9001401 for ; Mon, 16 Apr 2001 15:34:17 -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 PAA25459 for ; Mon, 16 Apr 2001 15:34:18 -0700 (PDT) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id RAA07865 for ; Mon, 16 Apr 2001 17:00:29 -0600 (MDT) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Mon Apr 16 18:30:11 EDT 2001 Received: from blhothuelpc (thuelpc [135.180.240.114]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id SAA05596 for ; Mon, 16 Apr 2001 18:32:37 -0400 (EDT) From: "Sandy Thuel" To: Subject: RE: [mobile-ip] dynamic home addressing as a WG item?? Date: Mon, 16 Apr 2001 18:29:53 -0400 Message-ID: <001e01c0c6c4$c21ca240$72f0b487@dnrc.belllabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <200104132221.PAA15343@heliopolis.eng.sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 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: Content-Transfer-Encoding: 7bit Hi James, Sorry for the delay as I try to dig myself out of my email backlog. BTW, thanks for your thoughtful comments on this issue. After reading through the several emails you and Luca recently sent about this subject, I thought it would be useful to highlight what I perceived were the key issues/concerns and offer some comments. Let's try to clear out the air and see where we've gone so far. Please let me know if I missed or mis-understood something important. There seem to be three primary questions intertwined in these recent discussions: A) What is the MN's home networking model? B) What constitutes *home* configuration state? C) Who should allocate *home* configuration state? My summary for each: A) What is the MN's home networking model? You are correct in that our home networking models differ. I assume the traditional Mobile IP notion of a home network, as the network to which the MN belongs (in enterprise networks terms, the MN's home LAN; in cellular networks terms, the MN's service provider's home access network). I assume that the MN gets a home address assigned from the address pool of its home network regardless of where the MN is. In addition, I assume the MN would like to have access to other services offered *in* its home access network such as DNS. Beyond that, I make no assumptions about where the MN tends to live and how often it moves. Of course, I assume the MN also needs an address from its local access network and may also want to get some other local configuration parameters there too (e.g., printers). Can you clarify the home networking model you assume? You suggested in a previous message that the MN would get a *home* address from the local access network: "So a possible, even likely, situation is that the mobile node gets a locally assigned home address every time it comes up in someone's network....jak" I don't understand how this works. Are you advocating a model where the MN has no fixed notion of a home network (i.e., the MN 'makes' the network it powers up on serve as its home network)? I think having a clear understanding of our home networking model will help clarify some confusion. BTW, let me emphasize that the configuration state we are talking about dynamically allocating to a MN is strictly home network configuration state and yes, we are talking about configuring it remotely (across a WAN). B) What constitutes *home* configuration state? Your classification of configuration state was a nice step in the right direction. Allow me to distinguish just two categories for discussion purposes: - routing and identity related: IP address, subnet mask, gateway router, domain name - service (discovery) related: DNS, HTTP proxy, IMAP server, NTP server, printers, LDAP servers, etc. C) Who should allocate *home* configuration state? (This is where the fire gets hot.) You seem to suggest the following solution: let Mobile IP allocate the IP address and subnet mask to the MN adding whatever extensions are needed to make it happen (= a new Mobile IP extension for the subnet mask + changes to the Mobile IP standard so the client sends registrations while at home). Let service discovery handle informing the MN of available services where possible. Otherwise, rely on AAA to inform the MN (e.g., DNS). (Q: In your model, how does the MN get its domain name? Through AAA? Also, how would the MN discover its gateway router in the absence of an FA?) There are several issues with this model. First, we have a strong difference of opinion regarding the issue of changing the Mobile IP standard to require client registrations while at home and extending it to piggyback routing related config. state. You don't seem to think it's a big deal to do this. We do, particularly in the short-term, as we try to expedite the deployment of M-IP. Changes of this nature are very costly and they take time to be adopted. In addition, we must be careful in thinking that a "tiny" extension to Mobile IP will solve the problem. Today we extend it to handle the subnet mask, tomorrow... (you get the picture). Now, is DHCP the end-all solution? Of course not. DHCP is not God's gift to mankind any more than PPP/Radius are (no offense intended). But DHCP *is* here, now, and used quite extensively. I'll grant you that mobile phones with DHCP clients aren't available today at my favorite phone retailer and I would concede that there are concerns about doing DHCP over the air. But there many other devices besides cellphones which are mobile, wireless and have DHCP clients. I just don't buy the argument that if-cellphones-don't-need-it-today-then-it must-not-be-needed. On the security issue you have a real, valid point. DHCP is clearly not secure today even though there's a lot of ongoing work to fix this. Running DHCP over a secure Mobile IP tunnel would at least not open any new security loopholes due to remote access. There is still the known vulnerability of DHCP to attacks within the home network. So, what are we to do? Wait for DHCP to become secure before we can use it? Wait for configuration-related extensions to AAA to come out so we can use them? Wait for Mobile IP to be changed to handle configuration state out to the MN? Pick two out of three? Pick all three? It's not clear to me which of these (and many other scenarios we can dream up) will eventually win. But what I can't understand is why we can't give the option of enabling the use of what's already in place today. We are not proposing any changes to neither Mobile IP nor DHCP, but just telling you how you could use them together to do remote configurations of MN's if you want to. Your remote MN with its DHCP client will be at least as secure as if it were roaming within its home network. If and when DHCP is made secure, kudos for this solution. And if someday AAA manages to undertake dynamic configuration duties under its wings, operators can go ahead and use it instead of DHCP. What's so evil about this? Regards, Sandy From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 17 02:27:13 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA03688 for ; Tue, 17 Apr 2001 02:27:12 -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 XAA20858; Mon, 16 Apr 2001 23:25: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 XAA24464; Mon, 16 Apr 2001 23:24:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3H6MvK9001905 for ; Mon, 16 Apr 2001 23:22:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3H6Mv5r001904 for mobile-ip-dist; Mon, 16 Apr 2001 23:22: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3H6MmK9001897 for ; Mon, 16 Apr 2001 23:22:48 -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 XAA04133 for ; Mon, 16 Apr 2001 23:22:50 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA25880 for ; Mon, 16 Apr 2001 23:22:49 -0700 (PDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3H6NBH29287 for ; Tue, 17 Apr 2001 09:23:11 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 17 Apr 2001 09:22:45 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Tue, 17 Apr 2001 09:21:58 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680AD31@eseis04nok> To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Involvement w. 3Gs? (context transfer from Seamob y) Date: Tue, 17 Apr 2001 09:21:52 +0300 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: Hi James, > So the issue is, what should the IETF do about this (is there anything > we *can* do)? It looks to me like 3GPP is now getting into the > business of defining IP standards. Do we maybe have to recognize that, > like STD0048 and STD0019 for NetBios, GPRS is becoming a de > facto standard and try to bring it into IETF? Or should we rather > be pushing back on them in some way to deploy mobile IP, like R99 says? > Or should we simply ignore them and instead work on getting mobility > integrated more deeply into the IPng core, hoping they will sink under > the load of their spectrum auction debt? As I understand it, the current 3GPP architecture (release 99) is more or less an access network for the Internet (at least the packet side, that is). Also, I think that this was a design goal. IMO, the IETF does not need to care about this. Mobile IP will be able to run over the 3GPP architecture - this is not an optimal solution for sure, but I don't see why some folks seem threatened by this. I'd propose that we (the IETF) continue to work on providing good IP-based solutions. I think that the future will be with MIPv6 and we should get this finished ASAP! It is very hard to get other SDOs to use protocols which are not finished. best regards, John From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 17 02:42:13 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA03808 for ; Tue, 17 Apr 2001 02:42: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 XAA16210; Mon, 16 Apr 2001 23:41: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 XAA05551; Mon, 16 Apr 2001 23:40:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3H6dFK9002028 for ; Mon, 16 Apr 2001 23:39:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3H6dFiC002027 for mobile-ip-dist; Mon, 16 Apr 2001 23:39: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3H6d6K9002020 for ; Mon, 16 Apr 2001 23:39:06 -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 XAA05403 for ; Mon, 16 Apr 2001 23:39:08 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA19105 for ; Mon, 16 Apr 2001 23:39:07 -0700 (PDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3H6du820497 for ; Tue, 17 Apr 2001 09:39:56 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 17 Apr 2001 09:39:01 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Tue, 17 Apr 2001 09:38:45 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680AD33@eseis04nok> To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Involvement w. 3Gs? (context transfer from Seamob y) Date: Tue, 17 Apr 2001 09:38:10 +0300 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: Hi Tim & Jim, > - the interconnection is between GPRS PLMN, not "IP-based radio access > networks." I suspect the GRX was based on the R98 spec, which states > (section 5.4.2) that an"..inter-PLMN backbone network can be > a Packet Data Network, e.g., the public Internet or a leased line." It > was pretty much up to the respondees to the RFI how to provide the service; > mostly I believe providers went the IP VPN route > > As to why it was decided to use these non-Internet mechanisms, I don't > expect there's a technical reason. I'd suggest that many in the GSM/GPRS community were not very familiar with Internet technologies. It would be helpful to remember that there are technical experts out there who are not IETF members :) In discussing a lot of these issues (AAA, Mobile IP, GPRS, GTP and so on) with 3GPP delegates, it has become clear to me that many of these delegates know the GSM/UMTS technologies extremely well, but do not know IP technologies so well. It stands to reason then, that they will have a bias towardst their own technologies. Of course, that is something that never happens in the IETF, thankfully :) Is it so unreasonable for the IETF to develop technically good solutions and then let other bodies use them? best regards, John From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 17 02:49:00 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA03870 for ; Tue, 17 Apr 2001 02:48:59 -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 XAA20399; Mon, 16 Apr 2001 23:47:34 -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 XAA05921; Mon, 16 Apr 2001 23:46:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3H6jTK9002056 for ; Mon, 16 Apr 2001 23:45:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3H6jSee002055 for mobile-ip-dist; Mon, 16 Apr 2001 23:45: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3H6jKK9002048 for ; Mon, 16 Apr 2001 23:45:20 -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 XAA03623 for ; Mon, 16 Apr 2001 23:45:21 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA25258 for ; Tue, 17 Apr 2001 01:15:40 -0600 (MDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3H6jQS25691 for ; Tue, 17 Apr 2001 09:45:26 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 17 Apr 2001 09:45:18 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Tue, 17 Apr 2001 09:45:03 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680AD34@eseis04nok> To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Involvement w. 3Gs? (context transfer from Seamob y) Date: Tue, 17 Apr 2001 09:44:55 +0300 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: Hi Jim, > >Replacement of handsets and infrastructure is a wicked > >problem if you have to answer to shareholders. > > GSM operators I've talked to say that they figure on a 3 year > replacement time for handsets, and that handset backward > compatibility is not a big issue for them. I'd still think that a portion of their customers won't change, and they will still need to support them (some countries do require such things). Further more, infrastructure is expensive and you cannot expect things to change so quickly. You cannot say the Internet is any better, otherwise we should all have IPv6 addresses already. best regards, John From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 17 03:39:35 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA04152 for ; Tue, 17 Apr 2001 03:39: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 AAA09300; Tue, 17 Apr 2001 00:20: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 AAA21334; Tue, 17 Apr 2001 00:18:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3H7GWK9002097 for ; Tue, 17 Apr 2001 00:16:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3H7GWXh002096 for mobile-ip-dist; Tue, 17 Apr 2001 00:16: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3H7FvK9002089 for ; Tue, 17 Apr 2001 00:16:23 -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 AAA06327 for ; Tue, 17 Apr 2001 00:15:24 -0700 (PDT) Received: from mmlab.snu.ac.kr (mmlab.snu.ac.kr [147.46.114.112]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA02830 for ; Tue, 17 Apr 2001 00:15:23 -0700 (PDT) Received: from trust (opal.snu.ac.kr [147.46.114.116]) by mmlab.snu.ac.kr (8.9.3/8.9.3) with SMTP id QAA28365 for ; Tue, 17 Apr 2001 16:15:17 +0900 (KST) From: "Paik, Eun Kyoung" To: Subject: RE: [mobile-ip] Involvement w. 3Gs? (context transfer from Seamoby) Date: Tue, 17 Apr 2001 16:15:15 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f3H7GNK9002090 Sender: owner-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 AAA09300 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA04152 ìíì, 아래 ë©”ì¼ì— ë³´ë©´ 3GPP2ê°€ MIP를 사용한다고 í•˜ëŠ”ë° MIPv6ì— ëŒ€í•œ 얘기는 어떻게 ë˜ê°€ê³  있는지 알아ë´ë‹¤ì˜¤. 3GPP2ì—ì„œë„ MNì´ IP address를 사용하니 ? > -----Original Message----- > From: owner-mobile-ip@sunroof.eng.sun.com > [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Jim Bound > Sent: Friday, April 13, 2001 8:11 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Involvement w. 3Gs? (context transfer > from Seamoby) > > > 3G Rel 5 has to much on their plate to add MIPv6. Rel 6 will have it. > Also they don't define IP protocols. Also I don't think we should take > more on here in the IETF our plate is already full. > > /jim > > On Thu, 12 Apr 2001, James Kempf wrote: > > > A debate has been going on on the Seamoby list about how involved the > > MIP group should be with the 3Gs, but it looked like here was rather > > the right place to have it. > > > > One issue that comes up to me is the following. The MIP group > has tried to > > work with the 3Gs over the last few years, and has had moderate success > > with 3GPP2. They are using MIP, we have successfully developed several > > enhancements to their packet architecture more or less collaboratively > > together with them, they are committed to working together with us > > in the future, and we have good working relationships with > TSG-P members. > > > > The same cannot be said of 3GPP. They have a competing IP mobility > > standard which they have continued to push. At an IEE > conference in London a > > few weeks ago, a paper was given announcing a plan to do inter-GGSN > > GPRS transfer (called GPRX). The R99 spec for 3GPP specifies that this > > should be done through mobile IP, but no 3GPP vendor implements it > > and none of the mobile operators are deploying it. They have > > shown no interest in working with IETF to resolve this. > > Naturally, the next step is when 3GPP operators begin deploying 802.11 > > networks, they start using GPRS for that as well. > > > > So the issue is, what should the IETF do about this (is there anything > > we *can* do)? It looks to me like 3GPP is now getting into the > > business of defining IP standards. Do we maybe have to recognize that, > > like STD0048 and STD0019 for NetBios, GPRS is becoming a de > facto standard and > > try to bring it into IETF? Or should we rather be pushing back > on them in some > > way to deploy mobile IP, like R99 says? Or should we simply > ignore them and > > instead work on getting mobility integrated more deeply into > the IPng core, > > hoping they will sink under the load of their spectrum auction debt? > > > > jak > > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 17 08:50:34 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06450 for ; Tue, 17 Apr 2001 08:50: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 FAA01658; Tue, 17 Apr 2001 05:47: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 FAA14140; Tue, 17 Apr 2001 05:46:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HCjNK9002462 for ; Tue, 17 Apr 2001 05:45:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3HCjNQl002461 for mobile-ip-dist; Tue, 17 Apr 2001 05:45: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HCjCK9002454 for ; Tue, 17 Apr 2001 05:45:13 -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 FAA13826 for ; Tue, 17 Apr 2001 05:45:13 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA29104 for ; Tue, 17 Apr 2001 05:45:07 -0700 (PDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3HCib205710 for ; Tue, 17 Apr 2001 15:44:43 +0300 (EET DST) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 17 Apr 2001 15:44:38 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Tue, 17 Apr 2001 15:44:14 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680AD4A@eseis04nok> To: neumiller@telocity.com Cc: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org Subject: RE: [mobile-ip] WG Announcement of Appeal: 3G Biases in SeaMoby a nd MIP Date: Tue, 17 Apr 2001 15:44:06 +0300 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: Hi Phil, > In a nutshell, my appeal, is that: the SeaMoby and Mobile IP WGs have > been mis-directed to focus too much on the interests of a > group of outside standards development organizations, namely 3GPP > (http://www.3gpp.org/) and 3GPP2 (http://www.3gpp2.org/), rather than > enhancing the global Internet which is the IETF's primary directive > per RFC 2026 section 1.1 which I quote a subsection here for convenience: First off, I do not know of ANY work that SeaMoby or Mobile IP is doing for 3GPP. As said by MANY others, Mobile IP can run over 3GPP networks, but none of the internal interfaces in the current 3GPP networks use Mobile IP. I do not see how any of the work in SeaMoby and Mobile IP WGs would be comprimised by 3GPP. In fact, some people have brought 3GPP up in the SeaMoby Context Transfer work and the consensus has been that the current 3GPP architecture does not support context transfer. > I can provide on demand the names of the quoted > individuals to the ADs or the IESG if an AD or the IESG needs to cross > reference or ask further questions. Hopefully, if you do this, you contact the person you are quoting beforehand, just to ensure you don't quote them out of text. > Next Steps Finally, having followed much of the discussion & work that has taken place, I still don't have a clear picture of what it is you are striving for. I think the best way forward would be for you do document your vision/architecture in an Internet Draft. Currently, you have submittend this draft: http://search.ietf.org/internet-drafts/draft-neumiller-seamoby-cnpmobility-0 0.txt which expires on May 18th, 2001. I think that this is a good start for work within SeaMoby. Perhaps it would be useful for you to update it and/or reissue it. Other than that, there is the OBAST requirements draft that was issued last June-ish, but that was, IMO, too vague to base work on. It also has expired. Again, if you feel that is the correct target architecture, then you should re-issue it and update it. If you have issued other drafts, please let me know. I think that this appeal would be much more effective if you document your work via Internet Drafts. If you meet with resistance to your submissions, and you feel that this is the correct direction, then an appeal would be much more reason (again, in my opinion). best regards, John From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 17 08:53:11 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06476 for ; Tue, 17 Apr 2001 08:53: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 FAA13190; Tue, 17 Apr 2001 05:49: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 FAA13915; Tue, 17 Apr 2001 05:45:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HChwK9002452 for ; Tue, 17 Apr 2001 05:43:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3HChvuj002451 for mobile-ip-dist; Tue, 17 Apr 2001 05:43: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HChmK9002444 for ; Tue, 17 Apr 2001 05:43:48 -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 FAA13707 for ; Tue, 17 Apr 2001 05:43:48 -0700 (PDT) Received: from mmlab.snu.ac.kr (mmlab.snu.ac.kr [147.46.114.112]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA25822 for ; Tue, 17 Apr 2001 05:43:43 -0700 (PDT) Received: from trust (opal.snu.ac.kr [147.46.114.116]) by mmlab.snu.ac.kr (8.9.3/8.9.3) with SMTP id VAA01351 for ; Tue, 17 Apr 2001 21:43:31 +0900 (KST) From: "Paik, Eun Kyoung" To: Subject: RE: [mobile-ip] Involvement w. 3Gs? (context transfer from Seamoby) Date: Tue, 17 Apr 2001 21:43:27 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <200104122153.OAA18637@heliopolis.eng.sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f3HChnK9002445 Sender: owner-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 Would you let me know what the conference or the title of the paper was ? Eun Paik > -----Original Message----- > From: owner-mobile-ip@sunroof.eng.sun.com > [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of James Kempf > Sent: Friday, April 13, 2001 6:54 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] Involvement w. 3Gs? (context transfer from Seamoby) > > The same cannot be said of 3GPP. They have a competing IP mobility > standard which they have continued to push. At an IEE conference > in London a > few weeks ago, a paper was given announcing a plan to do inter-GGSN > GPRS transfer (called GPRX). The R99 spec for 3GPP specifies that this > should be done through mobile IP, but no 3GPP vendor implements it > and none of the mobile operators are deploying it. They have > shown no interest in working with IETF to resolve this. > Naturally, the next step is when 3GPP operators begin deploying 802.11 > networks, they start using GPRS for that as well. > From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 17 09:06:47 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06810 for ; Tue, 17 Apr 2001 09:06: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 GAA15703; Tue, 17 Apr 2001 06:05: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 GAA02517; Tue, 17 Apr 2001 06:04:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HD31K9002509 for ; Tue, 17 Apr 2001 06:03:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3HD30Xg002508 for mobile-ip-dist; Tue, 17 Apr 2001 06:03: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HD2pK9002501 for ; Tue, 17 Apr 2001 06:02:51 -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 GAA16178 for ; Tue, 17 Apr 2001 06:02:51 -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 HAA15521 for ; Tue, 17 Apr 2001 07:34:50 -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 f3HD2mS11858 for ; Tue, 17 Apr 2001 15:02:48 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Tue Apr 17 15:02:45 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Apr 2001 15:02:45 +0200 Message-ID: From: "Karim El-Malki (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] MIP v6 Regional Registration - identifying re qui rements Date: Tue, 17 Apr 2001 15:02:38 +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 James Some comments below. > > I've been having problems with my email again, don't know if this > made it out on Monday. > > > >> >> A short list of concerns include worries about > introducing single > >> >> points of failure, whether or not multiple > levels of hierarchy are > >> needed, > >> >> the amount of signaling and tunneling overhead > that is implied, the > >> >> > >> >> => We believe we got some confirmation for ROHC and CT > >> >> folks that tunnelling will not be an issue. > >> >> > >> > >> Well, I'm glad you think that, because I've seen nothing in the > >> email thread that gives me any confidence at all that this will > >> be possible. I've seen Rajeev's note that changing the IP > >> address on the header might work, but not that changing 40 bytes > >> of header option will. And the ROHC chairs have not come out > >> one way or the other on this. > >> > > => We have heard at least 4 times now that ROHC will > > handle IP in IP tunnels. IPv6 in IPv4 will also be handled. > > We don't need to discuss this since you can verify it > > by reading the spec. > > > > As for sending full headers after handovers, we've seen > > the discussions, one camp says that simultions have > > proven that losing more than 3 packets in WCDMA (an > > example of an error prone environment) is extremely > > unlikey. The other camp disagrees and says that the > > problem exists and can be solved by CT. What more > > do we need to know ? > > I don't think this is relevant to HMIPv6 only so I > > don't see why this keeps coming up in relation > > to HMIPv6. > > > > I'm not bringing it up in the context of HMIPv6 only, I'm bringing it > up in the context of requirements for RegReg. Karim: OK, but there should be no difference. I think that the point Hesham was making above is that compressing a tunnel is something that has a wider scope than local MIP mobility. HMIP should not be designed specifically to remove tunnelling since that is part of MIPv6. Any optimisations for wireless can be done but should be simple IMO, and given the wider scope, should not be MIP-specific. The use of header compression seems like a good idea. In fact, independently of whether there is a tunnel or not, the spectrum efficiency issue is still a problem. Even one IP header is not good enough, so putting a tunnelling restriction on HMIP wouldn't solve that problem. On the other hand, as mentioned previously, if you have HC then you get to compress single or multiple headers. This allows the HMIP solution to be more generic. > I think there > needs to be a requirement for minimizing over the air header, in > the absence of a definitive statement that handovers will not be > slowed. Karim: The spectrum efficiency problem doesn't disappear if you don't have tunnelling. One IP header (and UDP/RTP or TCP headers) is still an issue, which ROHC has targeted. So I believe this is a generic problem which exists independently of MIP, and should be solved in ROHC WG not MIP. Your other issue, CT, has to do with handoffs which HMIP does not have as a requirement to solve. Also, you imply that moving a header compression context for a tunnel is hard to do (compared to moving context for a single header)? If this is true then this applies to all tunnelling to the MN, independently of MIP. Is the work at a stage where such conclusions can be drawn? Should there be such limitation (i.e. do not tunnel)? Until we are sure I think we should not make the HMIP solution too handover-specific. If it is found that CT for HC is needed (which some do not believe is the case) then we should make sure that the CT solution works independently of what you are transferring. This sounds better to me than posing limitations on the local mobility solution. > MIPv6 has already been bitten by using work from another > working group in a way that generated unintended > consequences, we don't want > that to happen again. Until I see a statement from the ROHC > working group > that piling on tunnel overhead won't cause significant (and 3 packets > is significant) latency increase in handover, I think we need > a requirement > that the RegReg protocol introduces no header overhead beyond basic > MIPv6. Karim: Some comments on HC above. Regarding your last sentence (requirement) I think I agree in principle, but we probably don't mean the same thing. The local mobility agent is basically a local Home Agent. So it will tunnel packets to the MN as in basic MIPv6. > >> >> We would like to add two more requirements. > >> >> > >> >> 0) Localised mobility management should provide the same > >> >> level of mobility management support as in the basic > >> >> MIPv6 specifiation. The mobility management functions > >> >> supported in MIPv6 must not be reduced in such > mechanism. > >> >> > >> >> 0.5) The provided mechanism must interwork with > existing > >> >> MIPv6, IPv6 and the proposed mechanisms for SA > establishment > >> >> in MIPv6. > >> > >> Yes, I would agreee. > >> > >> Additionally, I would add: > >> > >> The mechanism should minimize mobile node involvement > in routing, > >> beyond what the current MIPv6 requires. Preferences, > load balancing, > >> and other complex host-based mechanism whereby the mobile node, > >> rather than the network, is involved in determining > routes should > >> be avoided, > >> Karim: I think that we agree that the "multiple interface" or load balancing part should be put in another draft and we will try and get that in by the next IETF. However, it is important to allow the MN to use its local policies to move connections over different interfaces depending on the cost, QoS etc. of the access. So, in general I don't think we should disallow such mechanisms. > > => I guess you are referring to HMIPv6 here and no the > requirements > > in an abstract sense. The preference value was first > introduced in > > the MIPv6 spec for the HA. Why is this any different ? > do you have > > the same reservation on MIPv6 ? If so I disagree. I think the > > HA's preference field is useful. > > > > Actually, yes. I think the whole HA preference list thing in MIPv6 is > unnecessarily complex. Why should a host care what router > it's getting? > The only reason I could see for a host to care is that it is > authenticated > for a particular router and not another, and that isn't addressed > by the preferences design, or, it could be addressed in a > roundabout and > rather cumbersome way, IMHO. Karim: Well, you may want to get more users on one agent than another for example. Anyway, this discussion is now about MIPv6 and not only HMIP so it may need a separate thread. > > Routing decisions should be left to routers, not hosts. This has > been a proven, successful design in the wired Internet and I don't > know why it should not be so for wireless as well. Karim: Mobiles may want to decide which interface to receive traffic on. Cost and QoS are two important reasons to get mobiles involved in this decision. > > > Regarding load balancing, this is something that we believe is > > important and needed. However, based on comments received > > we will put it in a different drat. This is not a new > thing, it already > > exists in routers today. Furthermore, in some cellular networks > > (3GPP) a very similar feature is implemented in the GGSN. > > This is _already_being_developed in products (GGSNs). > > > > GPRS is a competing IP mobility standard being pushed by > 3GPP. They've > shown little or no interest in deploying mobile IP. Why should we > do something to accommodate them, or accommodate our design to their > poor design? Karim: Hesham's comment related to the fact that it is a "very similar feature". I believe the intended point was that such a feature is required and 3GPP has a solution for it. Nothing was said about having to accommodate any design for another. > > >> >> 6) Regional registration shall allow multiple > levels of hierarchy > >> >> > >> >> => We can't see a reason for this requirement. > We think it's > >> >> OK if we want to support mobile networks but we don't > >> >> think this requirement should be placed for all cases. > >> >> We never got an answer for the technical merits of > >> >> this requirement. It would be good to know why. > Otherwise > >> >> we'd like to remove this requirement. > >> >> > >> > >> Hesham, I've given reasons for this requirement multiple times, but > >> my impression is that you've ignored them. The fact of the > matter is you > don't > >> believe it's important because HMIP can only do it to a > limited extent. > >> > > => Actually I haven't ignored anything. You haven't > mentioned any > > reasons on this list or others. If I missed it, please > point me to > > the mail or date and I'l look it up. When we discussed this > > in private I responded and didn't get a reply. > > So it would be much easier IMO if you just tell us the > > reasons. > > > > OK, I missed the private email, like I said, I've been having > email problems. > > Here are a couple reasons: > > 1) Our design work on an all-IP radio access network showed that if > mobile IP is to be used for managing movement of the macrodiversity > resolution point and radio control server, then the hierarchical > signalling must be arranged to allow multiple levels of hierarchy. > Typically one level of hierarchy will be involved in managing > macrodiversity resolution/radio control in the RAN while another > will be involved in managing the movement of the mobile's globally > visible IP address. Macrodiversity on IP-level and other such issues are likely to start a long discussion which we may not want to repeat. I don't know much about your work so let me have more information if you would like some comments. However, I can't see in principle why you need two levels instead of one. I'd like to add that this is only one view of how an all-IP network should be. The way the 3GPPs see it today, although you may not personally hold this in high regard, is quite different. I could add another view, possibly different from your study. These comments are not meant to be a criticism of your study, but unless we all agree on the future all-IP architecture it is difficult to use this as a requirement. The architecture issue is a tough topic. I currently understand that this is something meant for the 3GPPs to solve and therefore out of our scope. > 2) A large ISP that peers for multiple wireless ISPs and, in addition, > has its own wireless networks may want to aggregate traffic for > particular wireless ISPs through particular RegReg routers. This > is very similar to how current ISPs aggregate through particular > border routers. Routing hierarchies have been important in the > wired Internet, we see no reason why the same might also not > be true with wireless. I understand the routing hierarchy concept, but I can't see how this maps to mobility and local mobility agents. The "local" agents (MAP) must be placed locally and not in the backbone of large ISPs. A large ISP can still aggregate traffic from multiple smaller providers without the need to own local agents (except for their own access networks if any). So I agree with you that aggregation can be applied to wireless, but no need to de-localise the local agents. Regards /Karim From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 17 09:20:29 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07099 for ; Tue, 17 Apr 2001 09:20: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 GAA24014; Tue, 17 Apr 2001 06:19: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 GAA04423; Tue, 17 Apr 2001 06:18:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HDGaK9002540 for ; Tue, 17 Apr 2001 06:16:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3HDGZAr002539 for mobile-ip-dist; Tue, 17 Apr 2001 06:16: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HDGQK9002532 for ; Tue, 17 Apr 2001 06:16:27 -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 GAA24943 for ; Tue, 17 Apr 2001 06:16:09 -0700 (PDT) Received: from rly-ip01.mx.aol.com (rly-ip01.mx.aol.com [205.188.156.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA24335 for ; Tue, 17 Apr 2001 06:16:09 -0700 (PDT) Received: from tot-wa.proxy.aol.com (tot-wa.proxy.aol.com [205.188.192.1]) by rly-ip01.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id JAA03007 for ; Tue, 17 Apr 2001 09:15:28 -0400 (EDT) Received: from lacuna2 (AC859012.ipt.aol.com [172.133.144.18]) by tot-wa.proxy.aol.com (8.10.0/8.10.0) with SMTP id f3HDFQj08821 for ; Tue, 17 Apr 2001 09:15:27 -0400 (EDT) From: "tim clifford" To: Subject: RE: [mobile-ip] Involvement w. 3Gs? (context transfer from Seamob y) Date: Tue, 17 Apr 2001 09:12:04 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <01D91AFB08B6D211BFD00008C7EABAE10680AD33@eseis04nok> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-Apparently-From: Timcmd@aol.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: Content-Transfer-Encoding: 7bit John My point that there wasn't a technical reason for the GSM not using Internet technologies was mostly in fact that there's less familiarity with the Internet and its protocols. I'll let the conspiracy theorists worry about the other factors. So, its absolutely reasonable for the IETF to forge ahead and let other groups use them. It may be the problem of the mobile/GSM/etc. community alone if they don't adopt best practices. However I'd also suggest that if the market forecasts are anywhere near correct then mobile access becomes a huge factor in the evolution of the Internet. So finding some way to bridge the gap might be a more "global" optimum approach. tim > -----Original Message----- > From: owner-mobile-ip@sunroof.eng.sun.com > [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of > john.loughney@nokia.com > Sent: Tuesday, April 17, 2001 2:38 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] Involvement w. 3Gs? (context transfer from > Seamob y) > > > Hi Tim & Jim, > > > - the interconnection is between GPRS PLMN, not "IP-based radio access > > networks." I suspect the GRX was based on the R98 spec, which states > > (section 5.4.2) that an"..inter-PLMN backbone network can be > > a Packet Data Network, e.g., the public Internet or a leased line." It > > was pretty much up to the respondees to the RFI how to provide the > service; > > mostly I believe providers went the IP VPN route > > > > As to why it was decided to use these non-Internet mechanisms, I don't > > expect there's a technical reason. > > I'd suggest that many in the GSM/GPRS community were not very familiar > with Internet technologies. It would be helpful to remember that there > are technical experts out there who are not IETF members :) > > In discussing a lot of these issues (AAA, Mobile IP, GPRS, GTP and so > on) with 3GPP delegates, it has become clear to me that many of these > delegates know the GSM/UMTS technologies extremely well, but do not > know IP technologies so well. It stands to reason then, that they will > have a bias towardst their own technologies. Of course, that is > something that never happens in the IETF, thankfully :) > > Is it so unreasonable for the IETF to develop technically good solutions > and then let other bodies use them? > > best regards, > John From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 17 09:26:51 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07272 for ; Tue, 17 Apr 2001 09:26: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 GAA02172; Tue, 17 Apr 2001 06:26:04 -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 GAA18978; Tue, 17 Apr 2001 06:24:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HDNPK9002587 for ; Tue, 17 Apr 2001 06:23:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3HDNPtj002586 for mobile-ip-dist; Tue, 17 Apr 2001 06:23: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HDNGK9002579 for ; Tue, 17 Apr 2001 06:23:17 -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 GAA05063 for ; Tue, 17 Apr 2001 06:23:17 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA18754 for ; Tue, 17 Apr 2001 06:23:16 -0700 (PDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3HDNLS25677 for ; Tue, 17 Apr 2001 16:23:21 +0300 (EET DST) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 17 Apr 2001 16:23:08 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Tue, 17 Apr 2001 16:23:08 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680AD4D@eseis04nok> To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Involvement w. 3Gs? (context transfer from Seamob y) Date: Tue, 17 Apr 2001 16:22:58 +0300 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: Hi Tim, > My point that there wasn't a technical reason for the GSM not > using Internet technologies was mostly in fact that there's less > familiarity with the Internet and its protocols. I'll let the > conspiracy theorists worry about the other factors. Exactly. I actually meant to expand upon your point. I just wanted to emphasize that there is less familiarity with Internet protocols in many cellular groups. I really don't think that any SDO wants to take anything away from the IETF or the Internet. best regards, John From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 17 09:51:33 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07667 for ; Tue, 17 Apr 2001 09:51: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 GAA22240; Tue, 17 Apr 2001 06: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 GAA08217; Tue, 17 Apr 2001 06:49:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HDlpK9002638 for ; Tue, 17 Apr 2001 06:47:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3HDlp3l002637 for mobile-ip-dist; Tue, 17 Apr 2001 06:47: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HDlgK9002630 for ; Tue, 17 Apr 2001 06:47:43 -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 GAA07944 for ; Tue, 17 Apr 2001 06:47:42 -0700 (PDT) Received: from idcpa4.pa.interdigital.com ([12.32.197.142]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA02769 for ; Tue, 17 Apr 2001 06:47:42 -0700 (PDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Apr 2001 09:46:47 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Design teams for mobileip--(sharif) Date: Tue, 17 Apr 2001 09:46:46 -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: Could some please let me know of all the design teams that are currently active in mobileip. Thanks . Sharif. From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 17 09:59:41 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07888 for ; Tue, 17 Apr 2001 09:59: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 GAA10852; Tue, 17 Apr 2001 06:58:33 -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 GAA09843; Tue, 17 Apr 2001 06:56:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HDsLK9002685 for ; Tue, 17 Apr 2001 06:54:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3HDsLVB002684 for mobile-ip-dist; Tue, 17 Apr 2001 06:54: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HDsCK9002677 for ; Tue, 17 Apr 2001 06:54:12 -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 GAA11081 for ; Tue, 17 Apr 2001 06:54:12 -0700 (PDT) Received: from c007.snv.cp.net (c007-h011.c007.snv.cp.net [209.228.33.217]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id GAA01106 for ; Tue, 17 Apr 2001 06:54:10 -0700 (PDT) Received: (cpmta 9574 invoked from network); 17 Apr 2001 06:54:10 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.217) with SMTP; 17 Apr 2001 06:54:10 -0700 X-Sent: 17 Apr 2001 13:54:10 GMT Message-ID: <004901c0c745$7b458b80$6501a8c0@philneum> From: "Phil Neumiller" To: References: Subject: Re: [mobile-ip] Design teams for mobileip--(sharif) Date: Tue, 17 Apr 2001 08:51:12 -0500 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: There are none listed on the MIP web page so the correct answer is none. The MIPv4 fast handoff archives up to 0101 are at: http://www.diameter.org/cgi-bin/lwgate/FAST-HANDOFF/ . I am looking for the MIPv6 archives now, but can't find them. The rest of MIP's archvives are at: > ftp://ftp.ietf.org/ietf-mail-archive/mobileip/ for all (back to 1992 :) > > ftp://ftp.ietf.org/ietf-mail-archive/mobileip/current for this month > > ftp://ftp.ietf.org/ietf-mail-archive/mobileip/2001-03.mail etc. for prev ----- Original Message ----- From: "Shahrier, Sharif M." To: Sent: Tuesday, April 17, 2001 8:46 AM Subject: RE: [mobile-ip] Design teams for mobileip--(sharif) > Could some please let me know of all the design teams that are currently > active in mobileip. > > Thanks . > > Sharif. > From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 17 10:40:47 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08845 for ; Tue, 17 Apr 2001 10:40:46 -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 HAA00517; Tue, 17 Apr 2001 07:38:35 -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 HAA18419; Tue, 17 Apr 2001 07:36:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HEZjK9002782 for ; Tue, 17 Apr 2001 07:35:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3HEZjHu002781 for mobile-ip-dist; Tue, 17 Apr 2001 07:35: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HEZaK9002774 for ; Tue, 17 Apr 2001 07:35:36 -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 HAA14767 for ; Tue, 17 Apr 2001 07:35:36 -0700 (PDT) Received: from c007.snv.cp.net (c007-h012.c007.snv.cp.net [209.228.33.219]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id JAA17950 for ; Tue, 17 Apr 2001 09:08:32 -0600 (MDT) Received: (cpmta 20265 invoked from network); 17 Apr 2001 07:35:31 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.219) with SMTP; 17 Apr 2001 07:35:31 -0700 X-Sent: 17 Apr 2001 14:35:31 GMT Message-ID: <006801c0c74b$3e5b0140$6501a8c0@philneum> From: "Phil Neumiller" To: Subject: [mobile-ip] Proposal for RAM based MIPv6 address lookup Date: Tue, 17 Apr 2001 09:32:28 -0500 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: Hi, Assume we need to assign every device on the planet a home address and potentially a COA as it moves. This leaves 2^31 addresses for MIPv6 to use as home addresses. Then clearly 8.6 GB would be enough RAM to store all possible MIPv6 HA to COA mappings (provided home addresses were mapped to VM addresses). These address servers could be spread across server pools and made redundant and be spread across the globe to ensure low latency access everywhere on the planet. This would allow a much faster deployment of MIPv6 since testbeds could go up now and no router upgrades would be needed to provide fully optimized MIPv6 service. IPv6 over IPv4 tunnelling from MN to CN could be used pretty effectively. Eventually operators could control their own agents in their routers as they wish to upgrade them, but this approach would allow for massive and effective deployment immediately of MIPv6. Comments? Which big server company (hey Sun!!!) wants to set one of these up for us to play with? Thanks, Phil From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 17 11:35:17 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10300 for ; Tue, 17 Apr 2001 11:35:15 -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 IAA09184; Tue, 17 Apr 2001 08:34:34 -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 IAA27554; Tue, 17 Apr 2001 08:33:17 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HFW0K9002855 for ; Tue, 17 Apr 2001 08:32:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3HFW0Cl002854 for mobile-ip-dist; Tue, 17 Apr 2001 08:32: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HFVpK9002847 for ; Tue, 17 Apr 2001 08:31:51 -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 IAA27453 for ; Tue, 17 Apr 2001 08:31:50 -0700 (PDT) Received: from c007.snv.cp.net (c007-h014.c007.snv.cp.net [209.228.33.221]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA26920 for ; Tue, 17 Apr 2001 10:04:45 -0600 (MDT) Received: (cpmta 7356 invoked from network); 17 Apr 2001 08:31:48 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.221) with SMTP; 17 Apr 2001 08:31:48 -0700 X-Sent: 17 Apr 2001 15:31:48 GMT Message-ID: <009601c0c753$16c69560$6501a8c0@philneum> From: "Phil Neumiller" To: References: <006801c0c74b$3e5b0140$6501a8c0@philneum> Subject: Re: [mobile-ip] Proposal for RAM based MIPv6 address lookup Date: Tue, 17 Apr 2001 10:28:37 -0500 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: I want to retract mentioning Sun in this post. I could have mentioned any workstation vendor capable of supporting large amounts of RAM, like Dell etc. Sun is in no way connected to this half-baked idea that I have proposed to the list as a potential short cut to deployment and more massive experimentation. Thanks, Phil ----- Original Message ----- From: "Phil Neumiller" To: Sent: Tuesday, April 17, 2001 9:32 AM Subject: [mobile-ip] Proposal for RAM based MIPv6 address lookup > Hi, > > Assume we need to assign every device on the planet a home address and > potentially a COA as it moves. This leaves 2^31 addresses for MIPv6 to > use as home addresses. Then clearly 8.6 GB would be enough RAM to > store all possible MIPv6 HA to COA mappings (provided home addresses > were mapped to VM addresses). These address servers could be spread > across server pools and made redundant and be spread across the globe > to ensure low latency access everywhere on the planet. > > This would allow a much faster deployment of MIPv6 since testbeds could > go up now and no router upgrades would be needed to provide fully optimized > MIPv6 service. IPv6 over IPv4 tunnelling from MN to CN could be used > pretty effectively. > > Eventually operators could control their own agents in their routers as they > wish to upgrade them, but this approach would allow for massive and effective > deployment immediately of MIPv6. Comments? Which big server company > (hey Sun!!!) wants to set one of these up for us to play with? > > Thanks, > > Phil > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 17 12:18:48 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11152 for ; Tue, 17 Apr 2001 12:18:47 -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 JAA16583; Tue, 17 Apr 2001 09:17: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 JAA01688; Tue, 17 Apr 2001 09:11:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HG9oK9002916 for ; Tue, 17 Apr 2001 09:09:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3HG9nNI002915 for mobile-ip-dist; Tue, 17 Apr 2001 09:09: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HG9fK9002908 for ; Tue, 17 Apr 2001 09:09:41 -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 JAA05863 for ; Tue, 17 Apr 2001 09:09:40 -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 JAA27742 for ; Tue, 17 Apr 2001 09:09:40 -0700 (PDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Apr 2001 12:08:45 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Proposal for RAM based MIPv6 address lookup Date: Tue, 17 Apr 2001 12:08:44 -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: One method that can be used is a first-level cache to store some of the COAs. Slower main memory DRAMs may be used as primary storage. This would save on having to use expensive SRAM (although nowadays the SRAMs are fairly cheap). Depending on the locality of the COA accesses, the cache could be designed to produce a lot of "hits" to improve the performance of lookup. A natural extention of this of course is to use multi level caches. It would also be quite interesting to investigate different caching algorithms for this case. I had done quite a bit of cache modeling, simulation on real-time cache architecture, thus if anyboby is interested please contact me for off-line discussions. Thanks. Sharif. -----Original Message----- From: Phil Neumiller [mailto:neumiller@telocity.com] Sent: Tuesday, April 17, 2001 10:32 AM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Proposal for RAM based MIPv6 address lookup Hi, Assume we need to assign every device on the planet a home address and potentially a COA as it moves. This leaves 2^31 addresses for MIPv6 to use as home addresses. Then clearly 8.6 GB would be enough RAM to store all possible MIPv6 HA to COA mappings (provided home addresses were mapped to VM addresses). These address servers could be spread across server pools and made redundant and be spread across the globe to ensure low latency access everywhere on the planet. This would allow a much faster deployment of MIPv6 since testbeds could go up now and no router upgrades would be needed to provide fully optimized MIPv6 service. IPv6 over IPv4 tunnelling from MN to CN could be used pretty effectively. Eventually operators could control their own agents in their routers as they wish to upgrade them, but this approach would allow for massive and effective deployment immediately of MIPv6. Comments? Which big server company (hey Sun!!!) wants to set one of these up for us to play with? Thanks, Phil From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 17 12:35:44 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11398 for ; Tue, 17 Apr 2001 12:35:43 -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 JAA17959; Tue, 17 Apr 2001 09:34: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 JAA11080; Tue, 17 Apr 2001 09:33:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HGVgK9002974 for ; Tue, 17 Apr 2001 09:31:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3HGVg4W002973 for mobile-ip-dist; Tue, 17 Apr 2001 09:31: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HGVVK9002959 for ; Tue, 17 Apr 2001 09:31:31 -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 JAA10251 for ; Tue, 17 Apr 2001 09:31:30 -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 JAA29999 for ; Tue, 17 Apr 2001 09:31:28 -0700 (PDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Tue, 17 Apr 2001 12:25:45 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Design teams for mobileip--(sharif) Date: Tue, 17 Apr 2001 12:25:36 -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 Sharif, Three teams have been formed in the last year in MIP. MIPv4 fast handoff - this group is essentially done, they are producing another version of their draft, but all discussion is being done on the main MIP mailing list at this point MIPv6 fast handoff - same status although there is still some editing discussion going on the private list QoS and MIP - don't know whether this would be called a design team, it's a group gathering requirements for the interaction between MIP and QoS There are a few other conversations between authors of various drafts trying to merge their concepts into single drafts. Oh, and mailing list archive locations will be posted when the teams are done. Phil > -----Original Message----- > From: Shahrier, Sharif M. [mailto:Sharif.Shahrier@InterDigital.com] > Sent: Tuesday, April 17, 2001 9:47 AM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] Design teams for mobileip--(sharif) > > > Could some please let me know of all the design teams that > are currently > active in mobileip. > > Thanks . > > Sharif. > From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 17 12:36:19 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11411 for ; Tue, 17 Apr 2001 12:36: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 JAA17729; Tue, 17 Apr 2001 09:34: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 JAA09730; Tue, 17 Apr 2001 09:33:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HGVoK9002977 for ; Tue, 17 Apr 2001 09:31:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3HGVo6H002976 for mobile-ip-dist; Tue, 17 Apr 2001 09:31: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HGVbK9002966 for ; Tue, 17 Apr 2001 09:31:37 -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 JAA10267 for ; Tue, 17 Apr 2001 09:31:37 -0700 (PDT) Received: from c007.snv.cp.net (c007-h000.c007.snv.cp.net [209.228.33.206]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id JAA00056 for ; Tue, 17 Apr 2001 09:31:35 -0700 (PDT) Received: (cpmta 24885 invoked from network); 17 Apr 2001 09:27:34 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.206) with SMTP; 17 Apr 2001 09:27:34 -0700 X-Sent: 17 Apr 2001 16:27:34 GMT Message-ID: <00d201c0c75a$db960540$6501a8c0@philneum> From: "Phil Neumiller" To: References: Subject: Re: [mobile-ip] Proposal for RAM based MIPv6 address lookup Date: Tue, 17 Apr 2001 11:24:14 -0500 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: Yes a fully associative memory might be the best I was thinking that what I proposed would allow something to put up pretty fast with reasonable performance with not such a big price tag as associative memory. ----- Original Message ----- From: "Shahrier, Sharif M." To: Sent: Tuesday, April 17, 2001 11:08 AM Subject: RE: [mobile-ip] Proposal for RAM based MIPv6 address lookup > One method that can be used is a first-level cache to store some of the > COAs. Slower main memory DRAMs may be used as primary storage. This would > save on having to use expensive SRAM (although nowadays the SRAMs are fairly > cheap). Depending on the locality of the COA accesses, the cache could be > designed to produce a lot of "hits" to improve the performance of lookup. > A natural extention of this of course is to use multi level caches. > > It would also be quite interesting to investigate different caching > algorithms for this case. > > I had done quite a bit of cache modeling, simulation on real-time cache > architecture, thus if anyboby is interested please contact me for off-line > discussions. > > Thanks. > > Sharif. > > -----Original Message----- > From: Phil Neumiller [mailto:neumiller@telocity.com] > Sent: Tuesday, April 17, 2001 10:32 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] Proposal for RAM based MIPv6 address lookup > > Hi, > > Assume we need to assign every device on the planet a home address and > potentially a COA as it moves. This leaves 2^31 addresses for MIPv6 to > use as home addresses. Then clearly 8.6 GB would be enough RAM to > store all possible MIPv6 HA to COA mappings (provided home addresses > were mapped to VM addresses). These address servers could be spread > across server pools and made redundant and be spread across the globe > to ensure low latency access everywhere on the planet. > > This would allow a much faster deployment of MIPv6 since testbeds could > go up now and no router upgrades would be needed to provide fully optimized > MIPv6 service. IPv6 over IPv4 tunnelling from MN to CN could be used > pretty effectively. > > Eventually operators could control their own agents in their routers as they > wish to upgrade them, but this approach would allow for massive and > effective > deployment immediately of MIPv6. Comments? Which big server company > (hey Sun!!!) wants to set one of these up for us to play with? > > Thanks, > > Phil > > From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 17 13:08:13 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11921 for ; Tue, 17 Apr 2001 13:08:13 -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 KAA11561; Tue, 17 Apr 2001 10:05: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 JAA11870; Tue, 17 Apr 2001 09:57:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HGuVK9003042 for ; Tue, 17 Apr 2001 09:56:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3HGuUFJ003041 for mobile-ip-dist; Tue, 17 Apr 2001 09:56: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HGuLK9003034 for ; Tue, 17 Apr 2001 09:56: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 JAA11505 for ; Tue, 17 Apr 2001 09:56:21 -0700 (PDT) Received: from c007.snv.cp.net (c007-h000.c007.snv.cp.net [209.228.33.206]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA29994 for ; Tue, 17 Apr 2001 09:56:21 -0700 (PDT) Received: (cpmta 22870 invoked from network); 17 Apr 2001 09:56:20 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.206) with SMTP; 17 Apr 2001 09:56:20 -0700 X-Sent: 17 Apr 2001 16:56:20 GMT Message-ID: <00fb01c0c75e$d6daf160$6501a8c0@philneum> From: "Phil Neumiller" To: References: Subject: Re: [mobile-ip] Design teams for mobileip--(sharif) Date: Tue, 17 Apr 2001 11:52:44 -0500 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: Aren't IETF lists supposed to be public? This seems to be a inner clique thing going on here Phil. I would like the AD to speak up on this. I think the MIP DT mail lists NEED to be accesible to the entire WG at all times, as they are in SeaMoby. Thanks, Phil ----- Original Message ----- From: "Phil Roberts" > > Oh, and mailing list archive locations will be posted when the teams are > done. > > Phil > From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 17 13:24:48 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12143 for ; Tue, 17 Apr 2001 13:24:47 -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 KAA00198; Tue, 17 Apr 2001 10:16: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 KAA08076; Tue, 17 Apr 2001 10:15:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HHE7K9003093 for ; Tue, 17 Apr 2001 10:14:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3HHE7Ou003092 for mobile-ip-dist; Tue, 17 Apr 2001 10:14: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HHDwK9003085 for ; Tue, 17 Apr 2001 10:13:58 -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 KAA20409 for ; Tue, 17 Apr 2001 10:13:57 -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 KAA13725 for ; Tue, 17 Apr 2001 10:13:56 -0700 (PDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Tue, 17 Apr 2001 13:08:15 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Design teams for mobileip--(sharif) Date: Tue, 17 Apr 2001 13:08:07 -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: Both fast handoff lists were open to begin with but due to some concerns about the ability to make progress the ADs asked us to close them, so we did. The archives will be made public when the teams are done. Versions of each draft have been published and you are welcome to comment on them on the main list. > -----Original Message----- > From: Phil Neumiller [mailto:neumiller@telocity.com] > Sent: Tuesday, April 17, 2001 12:53 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Design teams for mobileip--(sharif) > > > Aren't IETF lists supposed to be public? This seems to be a inner > clique thing going on here Phil. I would like the AD to > speak up on this. > I think the MIP DT mail lists NEED to be accesible to the entire WG > at all times, as they are in SeaMoby. > > Thanks, > > Phil > > ----- Original Message ----- > From: "Phil Roberts" > > > > Oh, and mailing list archive locations will be posted when > the teams are > > done. > > > > Phil > > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 17 14:22:20 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12783 for ; Tue, 17 Apr 2001 14:22:19 -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 LAA29015; Tue, 17 Apr 2001 11:14:50 -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 LAA04546; Tue, 17 Apr 2001 11:14:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HICrK9003172 for ; Tue, 17 Apr 2001 11:12:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3HICqp5003171 for mobile-ip-dist; Tue, 17 Apr 2001 11:12:52 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HICiK9003164 for ; Tue, 17 Apr 2001 11:12:44 -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 LAA20783 for ; Tue, 17 Apr 2001 11:12:43 -0700 (PDT) Received: from c007.snv.cp.net (c007-h013.c007.snv.cp.net [209.228.33.220]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA13652 for ; Tue, 17 Apr 2001 11:12:42 -0700 (PDT) Received: (cpmta 5550 invoked from network); 17 Apr 2001 11:12:40 -0700 Received: from unknown (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.220) with SMTP; 17 Apr 2001 11:12:40 -0700 X-Sent: 17 Apr 2001 18:12:40 GMT Message-ID: <011701c0c769$76b5e6e0$6501a8c0@philneum> From: "Phil Neumiller" To: References: Subject: Re: [mobile-ip] Design teams for mobileip--(sharif) Date: Tue, 17 Apr 2001 13:08:47 -0500 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: I guess this is another item to add to my appeal. I believe this is setting a bad precedent for the IETF. Thanks, Phil ----- Original Message ----- From: "Phil Roberts" To: Sent: Tuesday, April 17, 2001 12:08 PM Subject: RE: [mobile-ip] Design teams for mobileip--(sharif) > Both fast handoff lists were open to begin with but due to some concerns > about the ability to make progress the ADs asked us to close them, so we > did. The archives will be made public when the teams are done. Versions of > each draft have been published and you are welcome to comment on them on the > main list. > > From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 17 15:31:10 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14453 for ; Tue, 17 Apr 2001 15:31:08 -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 MAA02098; Tue, 17 Apr 2001 12:30: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 MAA15991; Tue, 17 Apr 2001 12:30:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HJStK9003231 for ; Tue, 17 Apr 2001 12:28:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3HJSskJ003230 for mobile-ip-dist; Tue, 17 Apr 2001 12:28: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HJSkK9003223 for ; Tue, 17 Apr 2001 12:28:46 -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 MAA06401 for ; Tue, 17 Apr 2001 12:28:45 -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 MAA20003 for ; Tue, 17 Apr 2001 12:28:44 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA32282; Tue, 17 Apr 2001 15:28:40 -0400 Date: Tue, 17 Apr 2001 15:28:40 -0400 (EDT) From: Jim Bound To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Design teams for mobileip--(sharif) In-Reply-To: <011701c0c769$76b5e6e0$6501a8c0@philneum> 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: You did not respond to my previous issue with your appeal regarding 3GPP et al which I am not clear is valid or warranted. But this one may have some meat here is why. I am on two design teams to work problems and get back to the working groups here in the IETF (which ones are not relevent). We formed these teams "for" the working groups and asked for volunteers. The list is closed because the "design team" wanted it closed and the working group does not care. But in the case where a team is formed and the management team in the IETF did not ask for volunteers from the working group then that is a closed process because when the management team makes such decisions it is a formal process. As opposed to working group members going off and solving a problem which is 'ad hoc'. To then close that formal list is insult to injury at a minimum to get input from the working group at a minimum. Then the other problem with this for your appeal is as follows. Why were certain people put on this closed team and not others. What "discrimination" was used to determine who was part of this formal process. Was it fair discrimination to the working group as a whole? This is a classic example of why the good-ole-boy-network needs fixing. It is a bad precedent and I believe could potentially cause a legal problem to the IETF which is the last thing we need here. In a private company, private entity, or academic/research centers this is done often and valid, but this is the IETF the open process for open standards. I also understand that authors are not part of the design teams? How was that discrimination arrived at and seems not wise to me? But then maybe there are perfect reasonable explanations for the above? regards, /jim On Tue, 17 Apr 2001, Phil Neumiller wrote: > I guess this is another item to add to my appeal. I believe this is > setting a bad precedent for the IETF. > > Thanks, > > Phil > ----- Original Message ----- > From: "Phil Roberts" > To: > Sent: Tuesday, April 17, 2001 12:08 PM > Subject: RE: [mobile-ip] Design teams for mobileip--(sharif) > > > > Both fast handoff lists were open to begin with but due to some concerns > > about the ability to make progress the ADs asked us to close them, so we > > did. The archives will be made public when the teams are done. Versions of > > each draft have been published and you are welcome to comment on them on the > > main list. > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 17 15:42:49 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14833 for ; Tue, 17 Apr 2001 15:42:47 -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 MAA08340; Tue, 17 Apr 2001 12:38: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 MAA08355; Tue, 17 Apr 2001 12:38:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HJY7K9003254 for ; Tue, 17 Apr 2001 12:34:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3HJY6oQ003253 for mobile-ip-dist; Tue, 17 Apr 2001 12:34: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HJXvK9003246 for ; Tue, 17 Apr 2001 12:33:58 -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 MAA16563 for ; Tue, 17 Apr 2001 12:33:56 -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 MAA23751 for ; Tue, 17 Apr 2001 12:33:51 -0700 (PDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Apr 2001 15:32:55 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Proposal for RAM based MIPv6 address lookup Date: Tue, 17 Apr 2001 15:32:54 -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: Actually, the size of the cache would generally be much smaller than the full SRAM required to store all the COAs. Also, you can use a fully associative or a set associative cache depending on the cost/speed tradeoff you're looking for. Sharif -----Original Message----- From: Phil Neumiller [mailto:neumiller@telocity.com] Sent: Tuesday, April 17, 2001 12:24 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Proposal for RAM based MIPv6 address lookup Yes a fully associative memory might be the best I was thinking that what I proposed would allow something to put up pretty fast with reasonable performance with not such a big price tag as associative memory. ----- Original Message ----- From: "Shahrier, Sharif M." To: Sent: Tuesday, April 17, 2001 11:08 AM Subject: RE: [mobile-ip] Proposal for RAM based MIPv6 address lookup > One method that can be used is a first-level cache to store some of the > COAs. Slower main memory DRAMs may be used as primary storage. This would > save on having to use expensive SRAM (although nowadays the SRAMs are fairly > cheap). Depending on the locality of the COA accesses, the cache could be > designed to produce a lot of "hits" to improve the performance of lookup. > A natural extention of this of course is to use multi level caches. > > It would also be quite interesting to investigate different caching > algorithms for this case. > > I had done quite a bit of cache modeling, simulation on real-time cache > architecture, thus if anyboby is interested please contact me for off-line > discussions. > > Thanks. > > Sharif. > > -----Original Message----- > From: Phil Neumiller [mailto:neumiller@telocity.com] > Sent: Tuesday, April 17, 2001 10:32 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] Proposal for RAM based MIPv6 address lookup > > Hi, > > Assume we need to assign every device on the planet a home address and > potentially a COA as it moves. This leaves 2^31 addresses for MIPv6 to > use as home addresses. Then clearly 8.6 GB would be enough RAM to > store all possible MIPv6 HA to COA mappings (provided home addresses > were mapped to VM addresses). These address servers could be spread > across server pools and made redundant and be spread across the globe > to ensure low latency access everywhere on the planet. > > This would allow a much faster deployment of MIPv6 since testbeds could > go up now and no router upgrades would be needed to provide fully optimized > MIPv6 service. IPv6 over IPv4 tunnelling from MN to CN could be used > pretty effectively. > > Eventually operators could control their own agents in their routers as they > wish to upgrade them, but this approach would allow for massive and > effective > deployment immediately of MIPv6. Comments? Which big server company > (hey Sun!!!) wants to set one of these up for us to play with? > > Thanks, > > Phil > > From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 17 15:48:35 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15058 for ; Tue, 17 Apr 2001 15:48:34 -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 MAA15532; Tue, 17 Apr 2001 12:47: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 MAA10195; Tue, 17 Apr 2001 12:47:40 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HJfeK9003283 for ; Tue, 17 Apr 2001 12:41:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3HJfd52003282 for mobile-ip-dist; Tue, 17 Apr 2001 12:41: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HJfUK9003275 for ; Tue, 17 Apr 2001 12:41:31 -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 MAA17775 for ; Tue, 17 Apr 2001 12:41:29 -0700 (PDT) Received: from c007.snv.cp.net (c007-h013.c007.snv.cp.net [209.228.33.220]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id MAA10508 for ; Tue, 17 Apr 2001 12:41:29 -0700 (PDT) Received: (cpmta 22380 invoked from network); 17 Apr 2001 12:41:28 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.220) with SMTP; 17 Apr 2001 12:41:28 -0700 X-Sent: 17 Apr 2001 19:41:28 GMT Message-ID: <015401c0c775$d275a400$6501a8c0@philneum> From: "Phil Neumiller" To: References: Subject: Re: [mobile-ip] Design teams for mobileip--(sharif) Date: Tue, 17 Apr 2001 14:37:15 -0500 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: Hi Jim (Bound), I was waiting to see if there was any WG consenus on the 3G bias. So far, from what I have seen posted (and it probably has not been given enough time), people are happy with the way 3G issues seem to dominate the MIP WG agenda. I have restated my case privately to two people and that may have helped explain my position better. I will not restate it here. I am willing to listen to a voices of reason in the MIP and SeaMoby WGs. Here is my primary issue (already explained but sometimes a different explantation is good): 1). The IETF's primary job is to extend, promote, architect, and design the global Internet. 2). Cellular networks are private, walled garden systems, that will BORROW work as needed from the IETF, to reach their own goals which includes charging their users exhorbitant fees that go directly into the pockets of tax zelous governments throughout the world. In the US these moneys are used to pay down the national debt. 3). The less heard voices, of wireless PAN and wireless LAN (many grassroots movements (its the Linux of wireless)), have a better Internet model IMHO, and are under-represented in the IETF or bullied out of position by big cellular/carrier $. If you differ in opinion, that is fine. However, I will stick to mine. If you can argue differently please do. Thanks, Phil ----- Original Message ----- From: "Jim Bound" To: Sent: Tuesday, April 17, 2001 2:28 PM Subject: Re: [mobile-ip] Design teams for mobileip--(sharif) > You did not respond to my previous issue with your appeal regarding 3GPP > et al which I am not clear is valid or warranted. But this one may have > some meat here is why. > > I am on two design teams to work problems and get back to the working > groups here in the IETF (which ones are not relevent). We formed these > teams "for" the working groups and asked for volunteers. The list is > closed because the "design team" wanted it closed and the working group > does not care. > > But in the case where a team is formed and the management team in the IETF > did not ask for volunteers from the working group then that is a closed > process because when the management team makes such decisions it is a > formal process. As opposed to working group members going off and solving > a problem which is 'ad hoc'. To then close that formal list is insult to > injury at a minimum to get input from the working group at a minimum. > > Then the other problem with this for your appeal is as follows. Why were > certain people put on this closed team and not others. What > "discrimination" was used to determine who was part of this formal > process. Was it fair discrimination to the working group as a whole? > > This is a classic example of why the good-ole-boy-network needs fixing. > > It is a bad precedent and I believe could potentially cause a legal > problem to the IETF which is the last thing we need here. In a private > company, private entity, or academic/research centers this is done often > and valid, but this is the IETF the open process for open standards. > > I also understand that authors are not part of the design teams? How was > that discrimination arrived at and seems not wise to me? > > But then maybe there are perfect reasonable explanations for the above? > > regards, > /jim > > On Tue, 17 Apr 2001, Phil Neumiller wrote: > > > I guess this is another item to add to my appeal. I believe this is > > setting a bad precedent for the IETF. > > > > Thanks, > > > > Phil > > ----- Original Message ----- > > From: "Phil Roberts" > > To: > > Sent: Tuesday, April 17, 2001 12:08 PM > > Subject: RE: [mobile-ip] Design teams for mobileip--(sharif) > > > > > > > Both fast handoff lists were open to begin with but due to some concerns > > > about the ability to make progress the ADs asked us to close them, so we > > > did. The archives will be made public when the teams are done. Versions of > > > each draft have been published and you are welcome to comment on them on the > > > main list. > > > > > > > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 17 16:21:22 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15894 for ; Tue, 17 Apr 2001 16:21:21 -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 NAA28429; Tue, 17 Apr 2001 13:03:48 -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 NAA22369; Tue, 17 Apr 2001 13:03:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HK0lK9003321 for ; Tue, 17 Apr 2001 13:00:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3HK0lXH003320 for mobile-ip-dist; Tue, 17 Apr 2001 13:00: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HK0cK9003313 for ; Tue, 17 Apr 2001 13:00:38 -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 NAA26555 for ; Tue, 17 Apr 2001 13:00:36 -0700 (PDT) Received: from idcpa4.pa.interdigital.com ([12.32.197.142]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA23431 for ; Tue, 17 Apr 2001 13:00:33 -0700 (PDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Apr 2001 15:59:36 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Issues pertaining to "Mobility Support in IPv6" v 13 Date: Tue, 17 Apr 2001 15:59:35 -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: I would like to discuss a couple of issues relating to the "Mobility Support in IPv6" draft v13.0. It is regarding to failure/reconfiguration of home agent router while the MN is away from its home agent. It is stated that the dynamic home agent address discovey procedure was to be used to dynamically discover the IP address of a home agent. As an alternative, a dual home agent router system can be used, to form a 2MR system. One of the routers is the "shadow" of the other and is only used as backup. If the "primary" one fails or is reconfigured, the "shadow" router could be switched into operation. From my previous knowledge, 2MR systems are quite fail-safe and is deployed in many fault tolerant systems. I was wondering how people felt about the 2MR approach. Another problem that I didn't see being discussed is the failure of home agent's link when the MN is away from its home agent. Link failure or reconfiguration is just as important as home agent failure. I believe that this needs to be explicitly spelled out in the draft together with a solution. Could people comment on this as well. Sharif. From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 17 17:41:05 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16962 for ; Tue, 17 Apr 2001 17:41:04 -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 OAA23955; Tue, 17 Apr 2001 14:40: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 OAA24494; Tue, 17 Apr 2001 14:39:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HLboK9003485 for ; Tue, 17 Apr 2001 14:37:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3HLbn6M003484 for mobile-ip-dist; Tue, 17 Apr 2001 14:37: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 eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HLbiK9003477 for ; Tue, 17 Apr 2001 14:37:45 -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 RAA02393 for ; Tue, 17 Apr 2001 17:37:44 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA27868 for mobile-ip@sunroof.eng.sun.com; Tue, 17 Apr 2001 17:37:56 -0400 (EDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HLVWK9003448 for ; Tue, 17 Apr 2001 14:31:33 -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 OAA16319 for ; Tue, 17 Apr 2001 14:31:33 -0700 (PDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA25796 for ; Tue, 17 Apr 2001 14:31:32 -0700 (PDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (motgate3 2.1) with ESMTP id OAA20728 for ; Tue, 17 Apr 2001 14:25:44 -0700 (MST)] Received: [from il35exm01.cig.mot.com (IL35EXM01.cig.mot.com [160.19.16.101]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id OAA23875 for ; Tue, 17 Apr 2001 14:31:23 -0700 (MST)] Received: by IL35EXM01.cig.mot.com with Internet Mail Service (5.5.2653.19) id <2RXQ3W7B>; Tue, 17 Apr 2001 16:31:23 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B1B7AD8@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'john.loughney@nokia.com'" Cc: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org Subject: RE: [seamoby] RE: [mobile-ip] WG Announcement of Appeal: 3G Biase s in SeaMoby and MIP Date: Tue, 17 Apr 2001 16:31:22 -0500 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 agree with John, How about the following in CT requirement "3GPP and 3GPP2 MUST not use seamoby/CT protocols" would that make sense???? :) see my response below -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Tuesday, April 17, 2001 7:44 AM To: neumiller@telocity.com Cc: mobile-ip@sunroof.eng.sun.com; seamoby@cdma-2000.org Subject: [seamoby] RE: [mobile-ip] WG Announcement of Appeal: 3G Biases in SeaMoby and MIP First off, I do not know of ANY work that SeaMoby or Mobile IP is doing for 3GPP. As said by MANY others, Mobile IP can run over 3GPP networks, but none of the internal interfaces in the current 3GPP networks use Mobile IP. I do not see how any of the work in SeaMoby and Mobile IP WGs would be comprimised by 3GPP. In fact, some people have brought 3GPP up in the SeaMoby Context Transfer work and the consensus has been that the current 3GPP architecture does not support context transfer. > I can provide on demand the names of the quoted > individuals to the ADs or the IESG if an AD or the IESG needs to cross > reference or ask further questions. Madjid N>> Talking about quoting, last week, Phil himself brought the 3GPP-3GPP2 context transfer issue up on the list (http://www.diameter.org/cgi-bin/lwgate/SEAMOBY-CONTEXT/archives/seamoby-context.archive.0104/Author/article-115.html) "I am not sure if this matters to the CT team or not, but those of you that care about 3GPP and 3GPP2 and/or CT compatibility with MIP SHOULD be concerned about this" We were then accused of doing academic excercises in seamoby and doing a context transfer that does not have any customer. we responded by (http://www.diameter.org/cgi-bin/lwgate/SEAMOBY-CONTEXT/archives/seamoby-context.archive.0104/Subject/article-151.html) We all decided to wait with different technology's specific CT requirements, or specific CT context, so I don't know what the purpose of this thread is,.... This week we were accused of being slaves of 3G/MIP, and were asked to stop the requirement work. which one is it? I don't understand and I don't want to guess what I will be accused of tommorrow, since It is my vacation anyway :) I think the CT work has been very fruitful (until recently) in bringing people from different technologies together to write broad requirements for whoever want to use it. We all agreed the CT is just a transport vehicle for getting context from one place to another, just like a truck. Somebody might use the truck for drug traffic, the other for getting food to starved children, in any cases nobody sues the truck company because the first one used its trucks for drug traffic. Now making a terrible analogy here (my appologies) Can we ban 3GPP* from using CT protocol??? didn't think so. I don't think we had any bias in our work, except that some people might think, our paycheck is coming from the wrong companies. Hey, somebody send me a few million bucks to support myself and I start writing protocols for IETF as a freelance!! Lets put a positive spin to everything, give us some triggers for CT!! From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 17 18:26:03 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17321 for ; Tue, 17 Apr 2001 18:26:00 -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 PAA00348; Tue, 17 Apr 2001 15:25: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 PAA18373; Tue, 17 Apr 2001 15:25:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HMN9K9003610 for ; Tue, 17 Apr 2001 15:23:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3HMN8t3003609 for mobile-ip-dist; Tue, 17 Apr 2001 15:23: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HMN0K9003602 for ; Tue, 17 Apr 2001 15:23:00 -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 PAA09721 for ; Tue, 17 Apr 2001 15:23:00 -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 PAA29923 for ; Tue, 17 Apr 2001 15:23:00 -0700 (PDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Tue, 17 Apr 2001 18:17:18 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Cc: Phil Roberts Subject: [mobile-ip] Revised Localized Mobility Management Requirements Date: Tue, 17 Apr 2001 18:17:15 -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: OK. Let's make another cut through these. Seems that folks like the title Localized Mobility Management. I didn't retain the original numbers. Agreed upon requirements where there was no dissent: 1. Regional registration shall be introduced to minimize the signaling traffic to the home agent or correspondent nodes for intradomain mobility. 2. Regional registration shall be secure against malicious behavior from visiting mobiles That's about it. There was only minor dissent on these: 3. Connectivity to the mobiles shall not be interrupted in the presence of the failure of regional registration agents. [Only comment was that disruption should be minimized. I'd like to get a sense from the working group whether it feels that this one should be restated] 4. Regional registration shall support fast handoffs. [Several comments that it should be compatible and no dependencies between the specs, so how about: Regional registration shall be compatible with fast handoffs.] 5. Regional registration shall scale to support millions of nodes in a visited network. [One comment that this was too broad, so I'd request someone to rephrase it in a better way] Mostly disagreement on these: 6. . Regional registration shall not introduce new overhead on links between the mobile and the local mobility management agents. [Comments were that it should be minimized, or that it was ok if it meant no more overhead than a binding update. Here's my attempt at a revision: local mobility management shall not introduce new messages to notify the LMM agents of a move. There is a disagreement as to whether adding additional over the air bytes is an issue, and if it is whether it's this WG's responsibility to solve it] 7. Regional registration shall allow multiple levels of hierarchy. [There was some strong disagreement on this. Perhaps Jim or Karim could start a separate thread to track this one down?] 8. Regional registration shall not require changes ot the MN, the home agent, or correspondent nodes. [Many thought requiring no change to the MN was not doable, but the home agent or CN should be unchanged. So I propose we just rewrite this as: Regional registration shall not require changes to the home agent or correspondent nodes.] 9. Regional registration shall not introduce host routes in routing tables. [Didn't get much positive on this one and got the sense folks don't want to rathole on a host routing discussion. I propose we drop this.] We also had request for some new requirements: 10. LMM should provide the same level of mobility mgmt support as in the basic MIP v6 spec. MM fns supported in MIP v6 must not be reduced. [Some positive feedback on this, shall we keep it?] 11. LMM must interwork with MIPv6, IPv6, and the proposed mechanisms for SA establishment [One comment that this was stating the obvious. Shall we keep it?] 12. LMM should be optimized for mobile-to-mobile. [Never really understood what this requirement was supposed to be. Got similar feedback from others. I propose we drop it.] Received no feedback on the following proposed requirements. Anybody want to keep these? 13. Should minimize # of network nodes affected by HO signalling. 14. Should support autoconfig. 15. Should simplify network design and provisioning. From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 17 19:09:04 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA17819 for ; Tue, 17 Apr 2001 19:09:03 -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 QAA01870; Tue, 17 Apr 2001 16:08: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 QAA21636; Tue, 17 Apr 2001 16:08:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HN76K9003666 for ; Tue, 17 Apr 2001 16:07:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3HN76Px003665 for mobile-ip-dist; Tue, 17 Apr 2001 16:07: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HN6wK9003658 for ; Tue, 17 Apr 2001 16:06: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 QAA11876 for ; Tue, 17 Apr 2001 16:06:58 -0700 (PDT) Message-Id: <200104172306.QAA11876@heliopolis.eng.sun.com> Date: Tue, 17 Apr 2001 16:06:58 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] dynamic home addressing as a WG item?? To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: An1/y/BtUrL1Yveko7T3/g== 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 Sandy, It has been an interesting exchange. > Can you clarify the home networking model you > assume? You suggested in a previous message that > the MN would get a *home* address from the > local access network: > I have two different models in mind: 1) In IPv4, the mobile node gets a "home" address assigned by the local network. The advantage of this is that it reduces the size of the triangle route leg from the home agent for the mobile node initially. Since MIPv4 is not likely to have route optimization nor regional registration widely deployed soon (because it was not specified early enough), this technique is a practical way of reducing triangle routing, especially if the host network puts the HA directly on the routing path which the mobile node's packets must travel. Like other optimization techniques, the assumption here is that most mobile nodes won't move far enough topologically from their initial location that triangle routing will become a problem. 2) In IPv6, either the above technique is used, or the mobile node comes with a global address baked into it. I believe 3GPP is planning on doing the latter (though it isn't planning on using MIP). Since route optimization is built into MIPv6, the first technique may not be important. Another possibility is that the mobile node makes up its home address using address autoconfig when it first comes up. In neither case do I think DHCP would be relevent. There may be some few cases where the mobile node has to get an address from the HA, these should be handled by mobile IP. > I don't understand how this works. Are you > advocating a model where the MN has no > fixed notion of a home network (i.e., > the MN 'makes' the network it powers up on > serve as its home network)? Yes and no. From an addressing viewpoint, what does it matter where the mobile node gets it's "home" address from? The address is there for routing purposes, the mobility protocol should arrange for the address to optimize routing. The only reason why the mobile node should care about its home network is for AAA purposes, to determine whether the mobile node has authorization to use network resources or not. This is handled, in IPv4, by the MIP AAA extension. And maybe for such home network related service configuration information like the IMAP server. >B) What constitutes *home* configuration state? > > Your classification of configuration state > was a nice step in the right direction. Allow > me to distinguish just two categories for > discussion purposes: > - routing and identity related: IP address, > subnet mask, gateway router, domain name > - service (discovery) related: DNS, > HTTP proxy, IMAP server, NTP server, > printers, LDAP servers, etc. > > Well, DNS is borderline. One could argue that DNS is identity related in the sense that it indicates what you can resolve. I actually prefer to keep it separate from the others because a) DNS can be used to do service configuration itself. b) IPv6 has its own DNS service discovery technique. >C) Who should allocate *home* configuration state? > > (This is where the fire gets hot.) You > seem to suggest the following solution: let > Mobile IP allocate the IP address and subnet > mask to the MN adding whatever extensions > are needed to make it happen (= a new Mobile > IP extension for the subnet mask + changes to > the Mobile IP standard so the client sends > registrations while at home). Let service Or the HA can proxy the DHCP lease renewal until the MN deregisters. > discovery handle informing the MN of available > services where possible. Otherwise, rely on > AAA to inform the MN (e.g., DNS). > > (Q: In your model, how does the MN get its > domain name? Through AAA? The NAI is needed in order to perform AAA. Typically, this includes the domain name, but it need not. So, yes, in that case if the domain name were not preconfigured into the mobile node, it would be obtained via AAA. >Also, how would the > MN discover its gateway router in the absence > of an FA?) > I thought we were talking about mobile IP? There is always an FA involved in MIPv4, except at home. In that case, it can use the HA as the router. In MIPv6, there is an Access Router which the mobile node discovers via a Router Advert. > There are several issues with this model. > First, we have a strong difference of opinion > regarding the issue of changing the Mobile IP > standard to require client registrations while > at home and extending it to piggyback routing > related config. state. You don't seem to think > it's a big deal to do this. We do, particularly > in the short-term, as we try to expedite > the deployment of M-IP. Changes of this nature > are very costly and they take time to be > adopted. In addition, we must be careful in > thinking that a "tiny" extension to Mobile IP > will solve the problem. Today we extend it to > handle the subnet mask, tomorrow... (you get > the picture). > Well, if you don't like that, then we can use AAA to get the routing related config as well. In fact, I think this is probably how 3GPP2 does it today. As for reregistering at home, if the HA is proxying the address via DHCP, the mobile node doesn't have to reregister. The HA can continue to proxy until the mobile node deregisters. I believe Charlie is currently in discussion about deregistration in 2002bis. > Now, is DHCP the end-all solution? Of course > not. DHCP is not God's gift to mankind any > more than PPP/Radius are (no offense intended). > But DHCP *is* here, now, and used quite > extensively. I'll grant you that mobile phones > with DHCP clients aren't available today at > my favorite phone retailer and I would concede > that there are concerns about doing DHCP over > the air. But there many other devices besides > cellphones which are mobile, wireless and have > DHCP clients. I just don't buy the argument > that if-cellphones-don't-need-it-today-then-it > must-not-be-needed. > The issue I have with DHCP is that after you've got the config state on the mobile host, the mobile host gets dumped back into the remote network where the config state may or may not make sense. Even assuming there is any logical home network, which I think is not a vaild assumption. Here's an example. What happens if the home network uses "split" DNS, where different names are resolvable inside and outside the corporate network? The mobile node is left outside the corporate network with a DNS server inside that: a) It may not even be able to reach through the corporate firewall, b) If it can reach the server, the names the server resolves may not be reachable from the mobile node. My point is that if you want to make the mobile node part of the corporate network, you must do a full job of it, and have the mobile node become topologically part of the corporate network, like a VPN. Not some partial solution, where the mobile node gets configured with home network state then gets dumped back onto the remote network. Otherwise, how is the mobile node going to sort through the configuration from the home network and make sense of what works and what doesn't? > On the security issue you have a real, valid > point. DHCP is clearly not secure today > even though there's a lot of ongoing work to > fix this. Running DHCP over a secure Mobile IP > tunnel would at least not open any new security > loopholes due to remote access. There is > still the known vulnerability of DHCP to > attacks within the home network. So, what are > we to do? Wait for DHCP to become secure before > we can use it? Yes, why not? We are not talking about a corporate network where one system administration team has control, we are talking about the Internet. There are enough security problems to solve without generating new ones. >Wait for configuration-related > extensions to AAA to come out so we can use > them? Actually, I've been talking with some people about doing a draft on this. We should have something ready by the next IETF. >Wait for Mobile IP to be changed to > handle configuration state out to the MN? > Pick two out of three? Pick all three? It's > not clear to me which of these (and many other > scenarios we can dream up) will eventually > win. But what I can't understand is why we > can't give the option of enabling the use of > what's already in place today. We are not > proposing any changes to neither Mobile IP > nor DHCP, but just telling you how you could > use them together to do remote configurations > of MN's if you want to. Your remote MN with > its DHCP client will be at least as secure as > if it were roaming within its home network. > If and when DHCP is made secure, kudos for > this solution. And if someday AAA manages > to undertake dynamic configuration duties > under its wings, operators can go ahead and > use it instead of DHCP. What's so evil > about this? > Look, Sandy, I don't want to rain on your parade, but I really think we should be looking at solving the problem rather than putting a bandaide(tm) on it. The problem is how to make the mobile node topologically and configuration wise part of the corporate network using mobile IP to handle mobility rather than the current L2 technology (L2TP and PPP). There are so many things that could go wrong with simply punching a tunnel and retrieving home configuration state. Nobody can stop you from filing your ID as an individual contribution, and, in any event, if the WG chairs and other WG members feel that this is an important enough item to solve, then I'm not going to complain if it gets onto the WG task lisk (though the MIP WG certainly has more than enough to do now). However, if it does get on the WG task list, I'm going to insist that some of the problems I've identified get solved, and maybe even suggest some solutions. But I'd rather see a solution to the whole problem, rather than trying to patch something together. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 17 19:23:40 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18041 for ; Tue, 17 Apr 2001 19:23:39 -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 QAA07316; Tue, 17 Apr 2001 16:22: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 QAA13330; Tue, 17 Apr 2001 16:22:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HNKpK9003691 for ; Tue, 17 Apr 2001 16:20:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3HNKorV003690 for mobile-ip-dist; Tue, 17 Apr 2001 16:20: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HNKgK9003683 for ; Tue, 17 Apr 2001 16:20: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 QAA24491 for ; Tue, 17 Apr 2001 16:20:42 -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 QAA10155 for ; Tue, 17 Apr 2001 16:20:41 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA32349; Tue, 17 Apr 2001 19:20:41 -0400 Date: Tue, 17 Apr 2001 19:20:41 -0400 (EDT) From: Jim Bound To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Design teams for mobileip--(sharif) In-Reply-To: <015401c0c775$d275a400$6501a8c0@philneum> 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 Phil, Good logical come back and position. I hear you. Some of my response is thats life and the strong survive and the weak die. Weak at different times is different things. But the key to our processes here is the test of fairness. If it can be proved that the principle of fairness has been usurped by our process I will stand behind you at the appeal as one person in this community. I am just not sure that principle has been broken. > I was waiting to see if there was any WG consenus on the 3G bias. So > far, from what I have seen posted (and it probably has not been given > enough time), people are happy with the way 3G issues seem to dominate > the MIP WG agenda. I have restated my case privately to two people and > that may have helped explain my position better. I will not restate it here. You don't need any consensus to state an appeal that POISED process is to cover individual views and fairness or in this case a technology idea set not being permitted to be seen. But I have never heard of any case where a draft was not permitted to be submitted to a working group. There was one and it was back in the CIDR working group during the Private Address Wars. > I am willing to listen to a voices of reason in the MIP and SeaMoby WGs. > Here is my primary issue (already explained but sometimes a different > explantation is good): > > 1). The IETF's primary job is to extend, promote, architect, and design the > global Internet. I would not agree with extend, promote, architect, or design the Internet. But only protocols for the use by the Internet. I am being very picky about the words in conjunction with the Internet. The end result of the IETF work permits the market to promote, design, and architect the operation of the Internet. But I think I get your drift and agree with it but in a core wording sense applying the exact words to Internet can be challenged. > 2). Cellular networks are private, walled garden systems, that will BORROW > work as needed from the IETF, to reach their own goals which includes > charging their users exhorbitant fees that go directly into the pockets of > tax zelous governments throughout the world. In the US these moneys > are used to pay down the national debt. True. Its a form of capitalism and these are the strong in an economic sense, hence; they have power yes. I accept that it is just the way it is today. Private Enterprise can change this if they so desire and I believe monopolies that are truly of that state are wrong and cause robber barron capitalism and not enlightened capitalism. But I don't see the technical or architectural case in our community where we can do anything about this in the IETF. > 3). The less heard voices, of wireless PAN and wireless LAN (many grassroots > movements (its the Linux of wireless)), have a better Internet model IMHO, > and are under-represented in the IETF or bullied out of position by big > cellular/carrier $. I realize this and it happens everyday somewhere in all enterprise that is just life. But if someone is being bullied in the IETF and their ideas and drafts are not being presented by the IETF Announce List or Chairs are not giving them time to discuss their ideas with a working group then that is another matter. I have not heard anyone claim this fact. > If you differ in opinion, that is fine. However, I will stick to mine. If you can > argue differently please do. I don't see the base for the appeal still. I do see the pain your stating and we may be missing on the Internet a good view and idea but I don't think its the fault of the IETF at all from the above bullets. But I was responding in my last mail to the issue of fairness in the design team choice via a formal IETF process as opposed to a bunch of us having some beers and coming up with ideas on napkins and then writing a draft. As an engineer I can say I don't want to have a beer with that person cause they annoy me or are to square or whatever and draw on the napkin what I like with who I like. But if I was a member of a formal entity with title and role then that is a different matter and I would have to be very careful to always remain objective technically and about people. regards, /jim From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 17 19:28:07 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18149 for ; Tue, 17 Apr 2001 19:28:07 -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 QAA09206; Tue, 17 Apr 2001 16:27: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 QAA26380; Tue, 17 Apr 2001 16:27:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HNPiK9003734 for ; Tue, 17 Apr 2001 16:25:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3HNPiMB003733 for mobile-ip-dist; Tue, 17 Apr 2001 16:25: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HNPZK9003726 for ; Tue, 17 Apr 2001 16:25:36 -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 QAA03810 for ; Tue, 17 Apr 2001 16:25:35 -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 QAA13557 for ; Tue, 17 Apr 2001 16:25:34 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA00493; Tue, 17 Apr 2001 19:25:34 -0400 Date: Tue, 17 Apr 2001 19:25:34 -0400 (EDT) From: Jim Bound To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Issues pertaining to "Mobility Support in IPv6" v 13 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 would argue that I agree with you about it should be mentioned. I don't agree that it needs to be spelled out at all to move this draft forward to PS. Anymore than we had to have DHCP failover spelled out to move DHCP forward to PS and many other pieces of work. This should be a seperate work item and draft dealing with failover in general and possibly an opportunity to join forces with MANET work. This is exactly the kind of thing that MUST NOT hold up MIPv6 going to PS and code started. If during PS we learn we can solve this and it should have it included fine. But its not needed for PS or get this stuff widely implemented for testing (it is implemented by early coder adopters but we need it implemented by suppliers now). regards, /jim On Tue, 17 Apr 2001, Shahrier, Sharif M. wrote: > I would like to discuss a couple of issues relating to the "Mobility Support > in IPv6" draft v13.0. It is regarding to failure/reconfiguration of home > agent router while the MN is away from its home agent. It is stated that the > dynamic home agent address discovey procedure was to be used to dynamically > discover the IP address of a home agent. > > As an alternative, a dual home agent router system can be used, to form a > 2MR system. One of the routers is the "shadow" of the other and is only used > as backup. If the "primary" one fails or is reconfigured, the "shadow" > router could be switched into operation. From my previous knowledge, 2MR > systems are quite fail-safe and is deployed in many fault tolerant systems. > > I was wondering how people felt about the 2MR approach. > > Another problem that I didn't see being discussed is the failure of home > agent's link when the MN is away from its home agent. Link failure or > reconfiguration is just as important as home agent failure. I believe that > this needs to be explicitly spelled out in the draft together with a > solution. > > Could people comment on this as well. > > Sharif. > From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 17 19:36:20 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18256 for ; Tue, 17 Apr 2001 19:36: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 QAA20970; Tue, 17 Apr 2001 16:35:50 -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 QAA05849; Tue, 17 Apr 2001 16:35:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HNXjK9003763 for ; Tue, 17 Apr 2001 16:33:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3HNXj65003762 for mobile-ip-dist; Tue, 17 Apr 2001 16: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HNXbK9003755 for ; Tue, 17 Apr 2001 16:33:37 -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 QAA15390 for ; Tue, 17 Apr 2001 16:33:37 -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 QAA12498 for ; Tue, 17 Apr 2001 16:33:36 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA22551; Tue, 17 Apr 2001 19:33:35 -0400 Date: Tue, 17 Apr 2001 19:33:35 -0400 (EDT) From: Jim Bound To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Design teams for mobileip--(sharif) In-Reply-To: <200104172152.OAA18784@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: And there was nothing wrong with Charlie and Pekka putting out their draft either right? I didn't see an issue with that. Its the process being questioned and if you think its all fair all the time in all cases thats cool. I don't and either do a few of us. Thats what this is about Given what just happened to MIPv6 this is normal also in any technical process when folks are blind sided by a decision. Its healthy for a full court press on fairness and logic check on whats up here to the IETF mgmt team. Everything is suspect for awhile. Its natural. Hopefully we will all be nice and cordial during the discussion. /jim On Tue, 17 Apr 2001, James Kempf wrote: > Hi, > > I'm having a difficult time understanding what the fuss is about here. > > While I have no problem with open design teams, I also think the > IETF review process is rich enough in opportunities for people to contribute who > were not on the initial design team even if the design team is closed. > As anybody who has done technical work knows, small groups are usually > more efficient at coming up with good technical solutions than larger > groups. Small groups tend to avoid the "design by committee" problem. > When the design team comes to the working group later, there is > ample opportunity, both before and after working group last call, > for others to contribute to the design, if they see something that > has been missed. And, if you feel you have some unique technical insight > into the problem and a positive (and I do stress positive) role > to play in solving it, I'm sure both the ADs and working group chair > can be persuaded to allow you on the design team. > > jak > > >Date: Tue, 17 Apr 2001 15:28:40 -0400 (EDT) > >From: Jim Bound > >To: mobile-ip@sunroof.eng.sun.com > >Subject: Re: [mobile-ip] Design teams for mobileip--(sharif) > > > >You did not respond to my previous issue with your appeal regarding 3GPP > >et al which I am not clear is valid or warranted. But this one may have > >some meat here is why. > > > >I am on two design teams to work problems and get back to the working > >groups here in the IETF (which ones are not relevent). We formed these > >teams "for" the working groups and asked for volunteers. The list is > >closed because the "design team" wanted it closed and the working group > >does not care. > > > >But in the case where a team is formed and the management team in the IETF > >did not ask for volunteers from the working group then that is a closed > >process because when the management team makes such decisions it is a > >formal process. As opposed to working group members going off and solving > >a problem which is 'ad hoc'. To then close that formal list is insult to > >injury at a minimum to get input from the working group at a minimum. > > > >Then the other problem with this for your appeal is as follows. Why were > >certain people put on this closed team and not others. What > >"discrimination" was used to determine who was part of this formal > >process. Was it fair discrimination to the working group as a whole? > > > >This is a classic example of why the good-ole-boy-network needs fixing. > > > >It is a bad precedent and I believe could potentially cause a legal > >problem to the IETF which is the last thing we need here. In a private > >company, private entity, or academic/research centers this is done often > >and valid, but this is the IETF the open process for open standards. > > > >I also understand that authors are not part of the design teams? How was > >that discrimination arrived at and seems not wise to me? > > > >But then maybe there are perfect reasonable explanations for the above? > > > >regards, > >/jim > > > >On Tue, 17 Apr 2001, Phil Neumiller wrote: > > > >> I guess this is another item to add to my appeal. I believe this is > >> setting a bad precedent for the IETF. > >> > >> Thanks, > >> > >> Phil > >> ----- Original Message ----- > >> From: "Phil Roberts" > >> To: > >> Sent: Tuesday, April 17, 2001 12:08 PM > >> Subject: RE: [mobile-ip] Design teams for mobileip--(sharif) > >> > >> > >> > Both fast handoff lists were open to begin with but due to some concerns > >> > about the ability to make progress the ADs asked us to close them, so we > >> > did. The archives will be made public when the teams are done. Versions > of > >> > each draft have been published and you are welcome to comment on them on > the > >> > main list. > >> > > >> > >> > > >> > >> > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 17 19:45:20 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18408 for ; Tue, 17 Apr 2001 19:45:19 -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 QAA27185; Tue, 17 Apr 2001 16:44: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 QAA15883; Tue, 17 Apr 2001 16:44:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HNhBK9003786 for ; Tue, 17 Apr 2001 16:43:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3HNhBTS003785 for mobile-ip-dist; Tue, 17 Apr 2001 16:43:11 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HNh2K9003778 for ; Tue, 17 Apr 2001 16:43: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 QAA07243 for ; Tue, 17 Apr 2001 16:43:02 -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 QAA17094 for ; Tue, 17 Apr 2001 16:43:01 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA13279; Tue, 17 Apr 2001 19:43:01 -0400 Date: Tue, 17 Apr 2001 19:43:01 -0400 (EDT) From: Jim Bound To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Design teams for mobileip--(sharif) 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: another example one could get absurd about is 3GPP2 who should be mandating IPv6 instead of trying to use IPv4 and MIPv4 for a billion mobile nodes. The place to fix that error is not here in the IETF but elswhere to use IPv6 and MIPv6 as will be done with 3GPP. Clearly some vendors don't want that to happen and it will be a good and technical battle to usurp them but its not to be fought here. Likewise the battle of how wireless is deployed and integrated into the Internet battle is not here in the IETF its elsewhere and that will be a great battle that has just started. I don't care what the IETF even thinks about the issue. But I do care that we figure out here all variants of handoffs, context transfer, et al. Thats our job here not the former. And that is enough technical work to go around. regards, /jim From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 17 19:55:06 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18531 for ; Tue, 17 Apr 2001 19:55:05 -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 QAA03012; Tue, 17 Apr 2001 16:54: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 OAA10918; Tue, 17 Apr 2001 14:54:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HLq8K9003535 for ; Tue, 17 Apr 2001 14:52:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3HLq8wN003534 for mobile-ip-dist; Tue, 17 Apr 2001 14:52: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HLpxK9003527 for ; Tue, 17 Apr 2001 14:52:00 -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 OAA18784 for ; Tue, 17 Apr 2001 14:52:00 -0700 (PDT) Message-Id: <200104172152.OAA18784@heliopolis.eng.sun.com> Date: Tue, 17 Apr 2001 14:52:00 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Design teams for mobileip--(sharif) To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: hXsOc3OXTIDKCPV8mon7MA== 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, I'm having a difficult time understanding what the fuss is about here. While I have no problem with open design teams, I also think the IETF review process is rich enough in opportunities for people to contribute who were not on the initial design team even if the design team is closed. As anybody who has done technical work knows, small groups are usually more efficient at coming up with good technical solutions than larger groups. Small groups tend to avoid the "design by committee" problem. When the design team comes to the working group later, there is ample opportunity, both before and after working group last call, for others to contribute to the design, if they see something that has been missed. And, if you feel you have some unique technical insight into the problem and a positive (and I do stress positive) role to play in solving it, I'm sure both the ADs and working group chair can be persuaded to allow you on the design team. jak >Date: Tue, 17 Apr 2001 15:28:40 -0400 (EDT) >From: Jim Bound >To: mobile-ip@sunroof.eng.sun.com >Subject: Re: [mobile-ip] Design teams for mobileip--(sharif) > >You did not respond to my previous issue with your appeal regarding 3GPP >et al which I am not clear is valid or warranted. But this one may have >some meat here is why. > >I am on two design teams to work problems and get back to the working >groups here in the IETF (which ones are not relevent). We formed these >teams "for" the working groups and asked for volunteers. The list is >closed because the "design team" wanted it closed and the working group >does not care. > >But in the case where a team is formed and the management team in the IETF >did not ask for volunteers from the working group then that is a closed >process because when the management team makes such decisions it is a >formal process. As opposed to working group members going off and solving >a problem which is 'ad hoc'. To then close that formal list is insult to >injury at a minimum to get input from the working group at a minimum. > >Then the other problem with this for your appeal is as follows. Why were >certain people put on this closed team and not others. What >"discrimination" was used to determine who was part of this formal >process. Was it fair discrimination to the working group as a whole? > >This is a classic example of why the good-ole-boy-network needs fixing. > >It is a bad precedent and I believe could potentially cause a legal >problem to the IETF which is the last thing we need here. In a private >company, private entity, or academic/research centers this is done often >and valid, but this is the IETF the open process for open standards. > >I also understand that authors are not part of the design teams? How was >that discrimination arrived at and seems not wise to me? > >But then maybe there are perfect reasonable explanations for the above? > >regards, >/jim > >On Tue, 17 Apr 2001, Phil Neumiller wrote: > >> I guess this is another item to add to my appeal. I believe this is >> setting a bad precedent for the IETF. >> >> Thanks, >> >> Phil >> ----- Original Message ----- >> From: "Phil Roberts" >> To: >> Sent: Tuesday, April 17, 2001 12:08 PM >> Subject: RE: [mobile-ip] Design teams for mobileip--(sharif) >> >> >> > Both fast handoff lists were open to begin with but due to some concerns >> > about the ability to make progress the ADs asked us to close them, so we >> > did. The archives will be made public when the teams are done. Versions of >> > each draft have been published and you are welcome to comment on them on the >> > main list. >> > >> >> > >> >> > From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 17 20:27:05 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18854 for ; Tue, 17 Apr 2001 20:27: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 RAA22827; Tue, 17 Apr 2001 17:26: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 RAA17232; Tue, 17 Apr 2001 17:26:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3I0OVK9003816 for ; Tue, 17 Apr 2001 17:24:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3I0OVqx003815 for mobile-ip-dist; Tue, 17 Apr 2001 17:24: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3I0OMK9003808 for ; Tue, 17 Apr 2001 17:24:22 -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 RAA27079 for ; Tue, 17 Apr 2001 17:24:21 -0700 (PDT) Received: from c007.snv.cp.net (c007-h013.c007.snv.cp.net [209.228.33.220]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id RAA11299 for ; Tue, 17 Apr 2001 17:24:21 -0700 (PDT) Received: (cpmta 25756 invoked from network); 17 Apr 2001 17:24:16 -0700 Received: from unknown (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.220) with SMTP; 17 Apr 2001 17:24:16 -0700 X-Sent: 18 Apr 2001 00:24:16 GMT Message-ID: <021f01c0c79d$32d3ad20$6501a8c0@philneum> From: "Phil Neumiller" To: , References: <048401c0c472$0041c500$6501a8c0@philneum> Subject: [mobile-ip] ANNOUNCEMENT: 3G bias appeal cancelled Date: Tue, 17 Apr 2001 19:19:07 -0500 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: I give up. It is clear from the emails I have received thus far that this appeal is not going to go anywhere in the MIP or SeaMoby WGs. Consider it cancelled. I still believe there are too many 3G biases among other problems in the agenda and priorities of the MIP & SeaMoby WGs. However, I will show deference to each WG as a whole. I am sorry for the inconvenience this thread may have caused the WG and chairs. Best regards to all, Phil Neumiller From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 17 20:41:09 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18987 for ; Tue, 17 Apr 2001 20:41:08 -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 RAA00042; Tue, 17 Apr 2001 17:40: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 RAA12261; Tue, 17 Apr 2001 17:40:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3I0dBK9003839 for ; Tue, 17 Apr 2001 17:39:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3I0dBJp003838 for mobile-ip-dist; Tue, 17 Apr 2001 17:39:11 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3I0d2K9003831 for ; Tue, 17 Apr 2001 17:39: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 RAA28098 for ; Tue, 17 Apr 2001 17:39:02 -0700 (PDT) Received: from internaut.com ([64.38.134.99]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA21819 for ; Tue, 17 Apr 2001 17:39:01 -0700 (PDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id RAA72732 for ; Tue, 17 Apr 2001 17:32:40 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Tue, 17 Apr 2001 17:32:40 -0700 (PDT) From: Bernard Aboba To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Design teams for mobileip--(sharif) 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: > 3). The less heard voices, of wireless PAN and wireless LAN (many grassroots > movements (its the Linux of wireless)), have a better Internet model IMHO, > and are under-represented in the IETF or bullied out of position by big > cellular/carrier $. There's a good reason why wireless PAN and wireless LAN are "under-represented" in the IETF. That's because the standardization of these technologies does not occur in the IETF. If you want to influence the standardization of these technologies, I would advise you to attend the IEEE 802.11 and 802.15 WGs. IEEE 802 is next meeting in Orlando, FL May 14-18, 2001. Info is available from the IEEE 802 web site: http://grouper.ieee.org/groups/802/index.html From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 17 20:53: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 UAA19154 for ; Tue, 17 Apr 2001 20:53: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 RAA09108; Tue, 17 Apr 2001 17:52: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 RAA13991; Tue, 17 Apr 2001 17:52:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3I0p1K9003883 for ; Tue, 17 Apr 2001 17:51:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3I0p1eN003882 for mobile-ip-dist; Tue, 17 Apr 2001 17:51: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3I0oqK9003875 for ; Tue, 17 Apr 2001 17:50: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 RAA13648 for ; Tue, 17 Apr 2001 17:50:52 -0700 (PDT) Message-Id: <200104180050.RAA13648@heliopolis.eng.sun.com> Date: Tue, 17 Apr 2001 17:50:52 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] MIP v6 Regional Registration - identifying re qui rements To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: vMCURXaSctvUDiRUkzKg/w== 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 Karim, >OK, but there should be no difference. >I think that the point Hesham was making above is that compressing >a tunnel is something that has a wider scope than local MIP mobility. >HMIP should not be designed specifically to remove tunnelling >since that is part of MIPv6. Any optimisations for wireless can >be done but should be simple IMO, and given the wider scope, should not >be MIP-specific. The use of header compression seems like a good idea. >In fact, independently of whether there is a tunnel or not, the >spectrum efficiency issue is still a problem. Even one IP header is >not good enough, so putting a tunnelling restriction on HMIP wouldn't >solve that problem. On the other hand, as mentioned previously, if >you have HC then you get to compress single or multiple headers. >This allows the HMIP solution to be more generic. > Sure, I've got no argument with using header compression, and I agree that the issue of whether it will work in the face of handover is a general problem. The issue I have is designing something based on an assumption that it will work a certain way when we currently don't have a definitive statement that it will work that way. I just don't want to get blindsided again like happened with security and binding updates. Perhaps the requirement should be restated as a requirement that the ROHC/Semoby context transfer groups be requested to review any design for a statement as to whether the design will not cause any latency when header compression state is transferred during handover, if the design does in fact include additional header bytes. >The spectrum efficiency problem doesn't disappear if you don't >have tunnelling. One IP header (and UDP/RTP or TCP headers) is >still an issue, which ROHC has targeted. So I believe this is a >generic problem which exists independently of MIP, and should be >solved in ROHC WG not MIP. > Agreed. >Your other issue, CT, has to do with handoffs which HMIP does not >have as a requirement to solve. Also, you imply that moving a header >compression context for a tunnel is hard to do (compared to moving >context for a single header)? If this is true then this applies to >all tunnelling to the MN, independently of MIP. Is the work at a >stage where such conclusions can be drawn? Should there be such >limitation (i.e. do not tunnel)? Until we are sure I think we should >not make the HMIP solution too handover-specific. If it is found that >CT for HC is needed (which some do not believe is the case) then we >should make sure that the CT solution works independently of what >you are transferring. This sounds better to me than posing limitations >on the local mobility solution. > Honestly, Karim, I just don't know, and I don't think anybody does. I just don't feel comfortable making assumptions about technology that isn't there now, and may or may not be there when we need it. But we do need to make progress, and so maybe we can establish a review requirement as suggested above. > >> MIPv6 has already been bitten by using work from another >> working group in a way that generated unintended >> consequences, we don't want >> that to happen again. Until I see a statement from the ROHC >> working group >> that piling on tunnel overhead won't cause significant (and 3 packets >> is significant) latency increase in handover, I think we need >> a requirement >> that the RegReg protocol introduces no header overhead beyond basic >> MIPv6. > >Karim: >Some comments on HC above. >Regarding your last sentence (requirement) I think I agree >in principle, but we probably don't mean the same thing. The local >mobility agent is basically a local Home Agent. So it will tunnel >packets to the MN as in basic MIPv6. > The requirement I see is that any additional header state be eliminated by compression, and that transfer of compressor state upon handover makes it possible to restart compression so as to not introduce any additional latency into handover. >I think that we agree that the "multiple interface" or load balancing >part should be put in another draft and we will try and get that in >by the next IETF. However, it is important to allow the MN to >use its local policies to move connections over different interfaces >depending on the cost, QoS etc. of the access. So, in general >I don't think we should disallow such mechanisms. > Well, we have a disgreement here. I think hosts should be kept out of routing decisions as much as possible. This is based on the successful history of IP design, in which hosts do very little routing. Mobile IP already involves the host in much more of the routing decision than has traditionally been the case, and I see little point in expanding that role unless absolutely necessary. The current preferences design is, in any case, too broad. What do these mean? There could be a potential interoperability problem if the mobile node moved from one network where the local policy defined preferences one way into another where they were defined another way. How would the mobile node know that the interpretation of preferences had changed? In most routing protocols, attributes are standardized so that interoperability based on attributes is possible. So including something as simple as preferences is a slippery slope. If you want to look at local policies, I believe the Seamoby group is working on a protocol to discover access point capability. It sounds to me that you want something more along those lines. With such a protocol, the meaning of the attributes/preferences would be standarized, eliminating the interoperability problem. >Karim: >Mobiles may want to decide which interface to receive traffic on. >Cost and QoS are two important reasons to get mobiles involved >in this decision. > Again, the right way to do that is using something like the Seamoby protocol, where there is a framework for standarizing the meaning. Including it in the routing protocol is not the right direction, IMHO. > >Macrodiversity on IP-level and other such issues are likely to >start a long discussion which we may not want to repeat. I don't know >much about your work so let me have more information if you would >like some comments. However, I can't see in principle why you need two >levels instead of one. I'd like to add that this is only one view of >how an all-IP network should be. The way the 3GPPs see it today, >although you may not personally hold this in high regard, is quite >different. I could add another view, possibly different from your study. >These comments are not meant to be a criticism of your study, but unless >we all agree on the future all-IP architecture it is difficult to use >this as a requirement. The architecture issue is a tough topic. >I currently understand that this is something meant for the 3GPPs to >solve and therefore out of our scope. > Sure, but this is a requirements discussion and I'm bringing up a potential area where it might be required. If we ignore this possibility, we have effectively foreclosed one potential application area for LMM. And, as we have recently been reminded by our good friend PhilN, we are not here to design systems for 3GPP/2. Though I disagree with his assessment of the situation, the point of requirements generation is to come up with requirements from the working group members about what they see as important for the Internet. I think this is important if we are to leave open an option for having IP radio access networks that use IETF protocols. >I understand the routing hierarchy concept, but I can't see how this >maps to mobility and local mobility agents. The "local" agents (MAP) >must be placed locally and not in the backbone of large ISPs. >A large ISP can still aggregate traffic from multiple smaller >providers without the need to own local agents (except for their >own access networks if any). So I agree with you that aggregation >can be applied to wireless, but no need to de-localise the local >agents. > > The MAP or some other hierarchical agent is acting as a router. Traffic from outside the local managed mobility domain must come through the agent. The ISP may want to aggregate to direct traffic from a collection of lower level agents through a border agent, and recursively. If multiple levels of hierarchy are not allowed, this option is effectively foreclosed by the design. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 17 21:07: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 VAA19315 for ; Tue, 17 Apr 2001 21:07: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 SAA13876; Tue, 17 Apr 2001 18:07:00 -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 SAA24669; Tue, 17 Apr 2001 18:06:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3I14pK9003911 for ; Tue, 17 Apr 2001 18:04:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3I14otS003910 for mobile-ip-dist; Tue, 17 Apr 2001 18:04: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3I14gK9003903 for ; Tue, 17 Apr 2001 18:04: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 SAA17331; Tue, 17 Apr 2001 18:04:42 -0700 (PDT) Message-Id: <200104180104.SAA17331@heliopolis.eng.sun.com> Date: Tue, 17 Apr 2001 18:04:42 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Revised Localized Mobility Management Requirements To: mobile-ip@sunroof.eng.sun.com Cc: PRoberts@MEGISTO.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Q4BrSeISgcnNBYtcDWStfQ== 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 Phil, >There was only minor dissent on these: >3. Connectivity to the mobiles shall not be interrupted in the presence of >the failure of regional registration agents. >[Only comment was that disruption should be minimized. I'd like to get a >sense from the working group whether it feels that this one should be >restated] Yes, it needs to be restated. >4. Regional registration shall support fast handoffs. >[Several comments that it should be compatible and no dependencies between >the specs, so how about: Regional registration shall be compatible with fast >handoffs.] Sounds good. >5. Regional registration shall scale to support millions of nodes in a >visited network. >[One comment that this was too broad, so I'd request someone to rephrase it >in a better way] > I made the comment, actually, I think we need to identify what this means in terms of specific technical requirements. Here are a few: 5.1 Router/agent state involved in implementing localized mobility management should scale linearly at most. 5.2 The number of routers/agents should scale sublinearly or linearly with the number of deployed subnets, not with the number of mobile nodes. >Mostly disagreement on these: >6. . Regional registration shall not introduce new overhead on links >between the mobile and the local mobility management agents. >[Comments were that it should be minimized, or that it was ok if it meant no >more overhead than a binding update. Here's my attempt at a revision: local >mobility management shall not introduce new messages to notify the LMM >agents of a move. There is a disagreement as to whether adding additional >over the air bytes is an issue, and if it is whether it's this WG's >responsibility to solve it] I would suggest a requirement that the design verify that any additional bytes are removable with header compression, and that header compression + context transfer will not introduce any additional latency into handover, if any additional header bytes are being introduced This should require a review by ROHC. >7. Regional registration shall allow multiple levels of hierarchy. >[There was some strong disagreement on this. Perhaps Jim or Karim could >start a separate thread to track this one down?] We're working on it. >8. Regional registration shall not require changes ot the MN, the home >agent, or correspondent nodes. >[Many thought requiring no change to the MN was not doable, but the home >agent or CN should be unchanged. So I propose we just rewrite this as: >Regional registration shall not require changes to the home agent or >correspondent nodes.] OK. >9. Regional registration shall not introduce host routes in routing tables. >[Didn't get much positive on this one and got the sense folks don't want to >rathole on a host routing discussion. I propose we drop this.] > This is a subtopic of the router/agent state scaling requirement, which I think is more appropriate. >We also had request for some new requirements: >10. LMM should provide the same level of mobility mgmt support as in the >basic MIP v6 spec. MM fns supported in MIP v6 must not be reduced. >[Some positive feedback on this, shall we keep it?] Yes. >11. LMM must interwork with MIPv6, IPv6, and the proposed mechanisms for SA >establishment >[One comment that this was stating the obvious. Shall we keep it?] > Not clear what the consequences are. Can we have clarification from the proposer? >12. LMM should be optimized for mobile-to-mobile. >[Never really understood what this requirement was supposed to be. Got >similar feedback from others. I propose we drop it.] > Agreed. >Received no feedback on the following proposed requirements. Anybody want >to keep these? >13. Should minimize # of network nodes affected by HO signalling. Agree. >14. Should support autoconfig. Agree. >15. Should simplify network design and provisioning. Agree. Also: 16. LMM should not introduce any additional machineary beyond that required for LMM (preferences, load balancing, etc.). These are the domain of other protocols being developed by other working groups. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 18 05:37:05 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 FAA08577 for ; Wed, 18 Apr 2001 05:37: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 CAA00592; Wed, 18 Apr 2001 02:33: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 CAA22677; Wed, 18 Apr 2001 02:28:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3I9R3K9004274 for ; Wed, 18 Apr 2001 02:27:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3I9R3rQ004273 for mobile-ip-dist; Wed, 18 Apr 2001 02:27: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3I9QsK9004266 for ; Wed, 18 Apr 2001 02:26:54 -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 CAA22485 for ; Wed, 18 Apr 2001 02:26:53 -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 CAA03637 for ; Wed, 18 Apr 2001 02:26:50 -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 f3I9QjS27817 for ; Wed, 18 Apr 2001 11:26:45 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Apr 18 11:26:43 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Apr 2001 11:22:10 +0200 Message-ID: From: "Karim El-Malki (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] MIP v6 Regional Registration - identifying re qui rements Date: Wed, 18 Apr 2001 11:26:42 +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 James > >OK, but there should be no difference. > >I think that the point Hesham was making above is that compressing > >a tunnel is something that has a wider scope than local MIP mobility. > >HMIP should not be designed specifically to remove tunnelling > >since that is part of MIPv6. Any optimisations for wireless can > >be done but should be simple IMO, and given the wider scope, > should not > >be MIP-specific. The use of header compression seems like a > good idea. > >In fact, independently of whether there is a tunnel or not, the > >spectrum efficiency issue is still a problem. Even one IP header is > >not good enough, so putting a tunnelling restriction on HMIP wouldn't > >solve that problem. On the other hand, as mentioned previously, if > >you have HC then you get to compress single or multiple headers. > >This allows the HMIP solution to be more generic. > > > > Sure, I've got no argument with using header compression, and I agree > that the issue of whether it will work in the face of handover > is a general problem. The issue I have is designing something > based on an assumption that it will work a certain way when we > currently don't have a definitive statement that it will work that > way. I just don't want to get blindsided again like happened > with security > and binding updates. > > Perhaps the requirement should be restated as a requirement that > the ROHC/Semoby context transfer groups be requested to > review any design for a > statement as to whether the design will not cause any latency when > header compression state is transferred during handover, if the > design does in fact include additional header bytes. Karim: I'm also happy that we leave this to ROHC/Seamoby and make changes if/when we are advised to do so. From the comments so far it looks as if we can be flexible and use tunnelling. Regarding Seamoby, I'd like to wait until we know if header compression CT is needed. If so we could put a requirement to the CT group. Of course, from the local mobility viewpoint, we are also required to monitor activities in ROHC/Seamoby and get their feedback (as you wrote above), but that goes without saying. More on the requirements issue below. > >Your other issue, CT, has to do with handoffs which HMIP does not > >have as a requirement to solve. Also, you imply that moving a header > >compression context for a tunnel is hard to do (compared to moving > >context for a single header)? If this is true then this applies to > >all tunnelling to the MN, independently of MIP. Is the work at a > >stage where such conclusions can be drawn? Should there be such > >limitation (i.e. do not tunnel)? Until we are sure I think we should > >not make the HMIP solution too handover-specific. If it is found that > >CT for HC is needed (which some do not believe is the case) then we > >should make sure that the CT solution works independently of what > >you are transferring. This sounds better to me than posing > limitations > >on the local mobility solution. > > > > Honestly, Karim, I just don't know, and I don't think anybody does. > I just don't feel comfortable making assumptions about technology > that isn't there now, and may or may not be there when we need it. > > But we do need to make progress, and so maybe we can establish > a review requirement as suggested above. Karim: Yes, I'm happy to move on and review the solution once the other groups give us guidelines. However I don't think this is a requirement on local mobility, instead we should put requirements on other groups. If these requirements can't be met we'll know and will make changes. i.e. Seamoby: If CT for HC is needed, we require tunnel CT. I propose we include a short discussion in the draft on HC, explaining what we discussed. What do you think about this? > > > >> MIPv6 has already been bitten by using work from another > >> working group in a way that generated unintended > >> consequences, we don't want > >> that to happen again. Until I see a statement from the ROHC > >> working group > >> that piling on tunnel overhead won't cause significant > (and 3 packets > >> is significant) latency increase in handover, I think we need > >> a requirement > >> that the RegReg protocol introduces no header overhead beyond basic > >> MIPv6. > > > >Karim: > >Some comments on HC above. > >Regarding your last sentence (requirement) I think I agree > >in principle, but we probably don't mean the same thing. The local > >mobility agent is basically a local Home Agent. So it will tunnel > >packets to the MN as in basic MIPv6. > > > > The requirement I see is that any additional header state be > eliminated by compression, and that transfer of compressor state > upon handover makes it possible to restart compression so as > to not introduce > any additional latency into handover. Karim: I agree with what you have above, except for the latency part. If a user cannot notice (or is not disrupted by) the reestablishment of header compression context without CT, then no additional latency is introduced (i.e. the MN gets service, but the first few packets are sent uncompressed). I think we got feedback both from people saying that CT is needed and from people saying CT is not needed for header compression. So I'd like to modify your requirement to be: "it should be possible to reduce impact due to additional headers by compression, and the service perceived by the user should not be degraded upon L3 handoff (either through reestablishment of context or through transfer of compressor state upon handover)" However this requirement is not a requirement on local mobility, it's a requirement on ROHC/Seamoby CT. So I think it's more appropriate to pass this requirement onto those groups and monitor the results. > > >I think that we agree that the "multiple interface" or load balancing > >part should be put in another draft and we will try and get that in > >by the next IETF. However, it is important to allow the MN to > >use its local policies to move connections over different interfaces > >depending on the cost, QoS etc. of the access. So, in general > >I don't think we should disallow such mechanisms. > > > > Well, we have a disgreement here. > > I think hosts should be kept out of routing decisions as much > as possible. > This is based on the successful history of IP design, in > which hosts do very little routing. Mobile IP already involves the > host in much more of the routing decision than has traditionally been > the case, and I see little point in expanding that role > unless absolutely > necessary. > > The current preferences design is, in any case, too broad. What do > these mean? There could be a potential interoperability problem > if the mobile node moved from one network where the local policy > defined preferences one way into another where they were defined > another way. How would the mobile node know that the interpretation > of preferences had changed? In most routing protocols, attributes > are standardized so that interoperability based on attributes > is possible. > So including something as simple as preferences is a slippery slope. > > If you want to look at local policies, I believe the Seamoby group > is working on a protocol to discover access point capability. > It sounds to me that you want something more along those lines. > With such a protocol, the meaning of the attributes/preferences > would be standarized, eliminating the interoperability problem. Karim: I didn't mean to exclude the Seamoby AP discovery mechanism. It is in fact one way of informing the MN of what access is available to it. The MN may use other methods too, which are not necessarily better. For example, if it has WLAN, Bluetooth and W-CDMA interfaces it could know locally (local user preferences) which one it prefers for which type of connection and act as a consequence. However, the way the MN finds this out is outside the scope of this draft. So I think we agree that it could be useful to allow the MN to move connections over different accesses as it moves. Regarding the preferences value, that is only needed to choose between MAPs where multiple MAPs are advertised. More below. > >Karim: > >Mobiles may want to decide which interface to receive traffic on. > >Cost and QoS are two important reasons to get mobiles involved > >in this decision. > > > > Again, the right way to do that is using something like the Seamoby > protocol, where there is a framework for standarizing the meaning. > Including it in the routing protocol is not the right direction, IMHO. Karim: OK, but it was never included. I agree that Seamoby may provide the right solution for access discovery, and appropriately access discovery was not included in the local mobility protocol. The preference value is a different issue, only used to pick a MAP. What was included (in HMIPv6) was a mechanism to move connections to different MN interfaces. The method used by the MN to find out the "best" interface/access for a connection was not included in the spec. So I think we should allow a multiply-interfaced MN to move connections between its interfaces, but in a more generic way applicable to HA and/or local agent (i.e. MAP). That's the separate draft I was talking about. I think we agree on this, but had a misunderstanding on the preference issue? > > > >Macrodiversity on IP-level and other such issues are likely to > >start a long discussion which we may not want to repeat. I don't know > >much about your work so let me have more information if you would > >like some comments. However, I can't see in principle why > you need two > >levels instead of one. I'd like to add that this is only one view of > >how an all-IP network should be. The way the 3GPPs see it today, > >although you may not personally hold this in high regard, is quite > >different. I could add another view, possibly different from > your study. > >These comments are not meant to be a criticism of your > study, but unless > >we all agree on the future all-IP architecture it is difficult to use > >this as a requirement. The architecture issue is a tough topic. > >I currently understand that this is something meant for the 3GPPs to > >solve and therefore out of our scope. > > > > Sure, but this is a requirements discussion and I'm bringing up > a potential area where it might be required. > > If we ignore this possibility, we have effectively foreclosed one > potential application area for LMM. And, as we have recently > been reminded by our good friend PhilN, we are not here to > design systems for 3GPP/2. Though I disagree with his assessment > of the situation, the point of requirements generation is to > come up with requirements from the working group members about > what they see as important for the Internet. I think this is important > if we are to leave open an option for having IP radio access > networks that use IETF protocols. Karim: OK, I see your point, but this still needs a discussion so that we agree on what we want. This requirement makes certain architectural assumptions about the IP radio network. The problem is that we probably have different views of what an IP wireless network should be, so any requirement from one side or another will be a source of misunderstanding. In my case, for example, I can only see the need for a one-level local MAP (possibly multiple independent MAPs to share the MN load in a large local network and for eventual redundancy mechanisms to be developed). > > >I understand the routing hierarchy concept, but I can't see how this > >maps to mobility and local mobility agents. The "local" agents (MAP) > >must be placed locally and not in the backbone of large ISPs. > >A large ISP can still aggregate traffic from multiple smaller > >providers without the need to own local agents (except for their > >own access networks if any). So I agree with you that aggregation > >can be applied to wireless, but no need to de-localise the local > >agents. > > > > > > The MAP or some other hierarchical agent is acting as a router. > Traffic from outside the local managed mobility domain must > come through the agent. The ISP may want to aggregate to direct > traffic from a collection of lower level agents through a > border agent, and recursively. If multiple levels of hierarchy > are not allowed, this option is effectively foreclosed by the > design. Karim: Let's say you don't have multiple levels of agents, but have multiple levels of routers. I can see ways in which you can achieve what you are saying through normal IP routing, without having to deploy local agents in the large ISP. What I mean is that you don't need to use MIPv6 and local agents to make traffic from outside a local domain go through a particular border router. So, I don't think that placing a local agent to aggregate traffic in a transit ISP network is the right solution. Regards /Karim From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 18 06:04: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 GAA08709 for ; Wed, 18 Apr 2001 06:04:38 -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 DAA13357; Wed, 18 Apr 2001 03:03: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 DAA20853; Wed, 18 Apr 2001 03:03:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IA28K9004306 for ; Wed, 18 Apr 2001 03:02:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3IA277h004305 for mobile-ip-dist; Wed, 18 Apr 2001 03:02: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IA1wK9004298 for ; Wed, 18 Apr 2001 03:01:58 -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 DAA10148 for ; Wed, 18 Apr 2001 03:01:57 -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 DAA24584 for ; Wed, 18 Apr 2001 03:01:52 -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 f3IA1oS29874 for ; Wed, 18 Apr 2001 12:01:50 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed Apr 18 12:01:50 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Apr 2001 11:57:17 +0200 Message-ID: From: "Karim El-Malki (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Revised Localized Mobility Management Requirement s Date: Wed, 18 Apr 2001 12:01:45 +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 Phil I agree with most of the proposals and in dropping requirements from 9 onwards. > Agreed upon requirements where there was no dissent: > 1. Regional registration shall be introduced to minimize the signaling > traffic to the home agent or correspondent nodes for > intradomain mobility. > 2. Regional registration shall be secure against malicious > behavior from > visiting mobiles OK. > There was only minor dissent on these: > 3. Connectivity to the mobiles shall not be interrupted in > the presence of > the failure of regional registration agents. > [Only comment was that disruption should be minimized. I'd > like to get a > sense from the working group whether it feels that this one should be > restated] OK as it is for me. However, this is applicable to HAs also so it could be generalised and a common solution should be devised. Hesham had proposed to start some work on this. > 4. Regional registration shall support fast handoffs. > [Several comments that it should be compatible and no > dependencies between > the specs, so how about: Regional registration shall be > compatible with fast > handoffs.] OK with your proposed change. > 5. Regional registration shall scale to support millions of nodes in a > visited network. > [One comment that this was too broad, so I'd request someone > to rephrase it > in a better way] I can't understand the purpose of this one since it is applicable in the same way to a HA. Is there anything specific to local mobility? > > Mostly disagreement on these: > 6. . Regional registration shall not introduce new overhead on links > between the mobile and the local mobility management agents. > [Comments were that it should be minimized, or that it was ok > if it meant no > more overhead than a binding update. Here's my attempt at a > revision: local > mobility management shall not introduce new messages to notify the LMM > agents of a move. There is a disagreement as to whether > adding additional > over the air bytes is an issue, and if it is whether it's this WG's > responsibility to solve it] Do you mean to say that no new messages apart from MIPv6 BUs should be introduced? I'm OK with that. Regarding the overhead I think we're concluding that we need to monitor other groups (ROHC/Seamoby) and possibly provide them with requirements from our side. > 7. Regional registration shall allow multiple levels of hierarchy. > [There was some strong disagreement on this. Perhaps Jim or > Karim could > start a separate thread to track this one down?] Ongoing (thread is MIP v6 Regional Registration - identifying re qui rements) > 8. Regional registration shall not require changes ot the MN, the home > agent, or correspondent nodes. > [Many thought requiring no change to the MN was not doable, > but the home > agent or CN should be unchanged. So I propose we just > rewrite this as: > Regional registration shall not require changes to the home agent or > correspondent nodes.] MN needs some change, so I'm OK with your proposal. Regards /Karim From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 18 06:29: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 GAA08870 for ; Wed, 18 Apr 2001 06:29:08 -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 DAA22662; Wed, 18 Apr 2001 03:28: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 DAA06995; Wed, 18 Apr 2001 03:27:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IAQkK9004356 for ; Wed, 18 Apr 2001 03:26:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3IAQk3v004355 for mobile-ip-dist; Wed, 18 Apr 2001 03:26: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IAQbK9004348 for ; Wed, 18 Apr 2001 03:26:37 -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 DAA06941 for ; Wed, 18 Apr 2001 03:26:36 -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 DAA22711 for ; Wed, 18 Apr 2001 03:26:30 -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 f3IAQTP15752 for ; Wed, 18 Apr 2001 12:26:29 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Wed Apr 18 12:26:28 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Apr 2001 12:26:28 +0200 Message-ID: From: "Karim El-Malki (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Revised Localized Mobility Management Requirement s Date: Wed, 18 Apr 2001 12:26:25 +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 James A few comments below. > >Mostly disagreement on these: > >6. . Regional registration shall not introduce new overhead on links > >between the mobile and the local mobility management agents. > >[Comments were that it should be minimized, or that it was > ok if it meant no > >more overhead than a binding update. Here's my attempt at a > revision: local > >mobility management shall not introduce new messages to > notify the LMM > >agents of a move. There is a disagreement as to whether > adding additional > >over the air bytes is an issue, and if it is whether it's this WG's > >responsibility to solve it] > > I would suggest a requirement that the design verify that any > additional > bytes are removable with header compression, and that header > compression > + context transfer will not introduce any additional latency into > handover, if any additional header bytes are being introduced > This should > require a review by ROHC. This is really a requirement on ROHC to support multiple header compression and is independent of MIP. Also, Context transfer for HC is not yet a settled issue from what I understand. Some say you can reestablish context by transmitting a few uncompressed packets. The MN still gets service so no additional latency is involved. Others say you need CT. If CT for HC is required (depending on the ROHC/Seamoby decisions) then this becomes a requirement on Seamoby CT to support tunnel HC CT. Again this is applicable to tunnelling and has a wider scope than MIP. So I believe these are not requirements on local mobility. > Also: > > 16. LMM should not introduce any additional machineary beyond that > required for LMM (preferences, load balancing, etc.). These are > the domain of other protocols being developed by other working > groups. Do you mean that preference etc. should or should not be covered? Advertising a preference for an agent is part of MIPv6. Moving MN connections to different MN interfaces is useful but will be put into another draft, to be generalised to work for HA also. Why is your requirement above needed? I think it doesn't really need to be stated as a requirement since it is obvious that the domain of other WGs is outside the scope. Is there anything else in particular you wanted to avoid having in the draft? Regards /Karim From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 18 09:14:15 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10691 for ; Wed, 18 Apr 2001 09:14:14 -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 GAA05658; Wed, 18 Apr 2001 06:10: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 GAA07214; Wed, 18 Apr 2001 06:10:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3ID9EK9004528 for ; Wed, 18 Apr 2001 06:09:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3ID9DO5004527 for mobile-ip-dist; Wed, 18 Apr 2001 06:09: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3ID94K9004520 for ; Wed, 18 Apr 2001 06:09:05 -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 GAA23167 for ; Wed, 18 Apr 2001 06:09:05 -0700 (PDT) Received: from idcpa4.pa.interdigital.com ([12.32.197.142]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA11342 for ; Wed, 18 Apr 2001 06:09:04 -0700 (PDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Apr 2001 09:08:09 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Issues pertaining to "Mobility Support in IPv6" v 13 Date: Wed, 18 Apr 2001 09:08:08 -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: Jim, I don't disagree with you in that the coding should start as soon as possible, however, It is generally a good design practice to identify the potential sources of failure as early as possible in the design phase, and poduce soulutions for detection and recovery. (sharif) I would argue that I agree with you about it should be mentioned. I don't agree that it needs to be spelled out at all to move this draft forward to PS. Anymore than we had to have DHCP failover spelled out to move DHCP forward to PS and many other pieces of work. This should be a seperate work item and draft dealing with failover in general and possibly an opportunity to join forces with MANET work. This is exactly the kind of thing that MUST NOT hold up MIPv6 going to PS and code started. If during PS we learn we can solve this and it should have it included fine. But its not needed for PS or get this stuff widely implemented for testing (it is implemented by early coder adopters but we need it implemented by suppliers now). regards, /jim On Tue, 17 Apr 2001, Shahrier, Sharif M. wrote: > I would like to discuss a couple of issues relating to the "Mobility Support > in IPv6" draft v13.0. It is regarding to failure/reconfiguration of home > agent router while the MN is away from its home agent. It is stated that the > dynamic home agent address discovey procedure was to be used to dynamically > discover the IP address of a home agent. > > As an alternative, a dual home agent router system can be used, to form a > 2MR system. One of the routers is the "shadow" of the other and is only used > as backup. If the "primary" one fails or is reconfigured, the "shadow" > router could be switched into operation. From my previous knowledge, 2MR > systems are quite fail-safe and is deployed in many fault tolerant systems. > > I was wondering how people felt about the 2MR approach. > > Another problem that I didn't see being discussed is the failure of home > agent's link when the MN is away from its home agent. Link failure or > reconfiguration is just as important as home agent failure. I believe that > this needs to be explicitly spelled out in the draft together with a > solution. > > Could people comment on this as well. > > Sharif. > From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 18 11:20:22 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12769 for ; Wed, 18 Apr 2001 11:20: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 IAA24298; Wed, 18 Apr 2001 08:18:34 -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 IAA13583; Wed, 18 Apr 2001 08:18:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IFHAK9004721 for ; Wed, 18 Apr 2001 08:17:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3IFH94F004720 for mobile-ip-dist; Wed, 18 Apr 2001 08:17: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IFH1K9004713 for ; Wed, 18 Apr 2001 08:17: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 IAA28252 for ; Wed, 18 Apr 2001 08:17:01 -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 JAA05502 for ; Wed, 18 Apr 2001 09:55:27 -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 KAA04615 for ; Wed, 18 Apr 2001 10:16:59 -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 f3IFH2n26301 for ; Wed, 18 Apr 2001 10:17:02 -0500 (CDT) Message-ID: <3ADDA18E.79A6388C@usa.alcatel.com> Date: Wed, 18 Apr 2001 10:15: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] Design teams for mobileip--(sharif) 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 Phil, Sorry to bring this up again. I think that there two problems here that needs to be addressed: 1. WG members were not consulted when DTs were closed. Jim Bound says other WG chairs know, this how come Mobile IP WG chairs do not? 2. The same has been repeated over maybe 3 times MIPv6 DT, MIPv4 DT and Security DT (?). Phil Roberts wrote: > Both fast handoff lists were open to begin with but due to some concerns > about the ability to make progress the ADs asked us to close them, so we > did. I saw this movie before (another WG chair made similar statements without providing any proof). Phil do you mind providing any evidence on this? > The archives will be made public when the teams are done. Versions of > each draft have been published and you are welcome to comment on them on the > main list. I know where one of the lists is located. I can tell more on how the list was closed, etc., if required The remedy to the situation is quite simple: WG chairs should apologize, at the least. And thanks to Phil Neumiller for bringing this up. -- Behcet From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 18 11:25:07 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12814 for ; Wed, 18 Apr 2001 11:25: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 IAA26785; Wed, 18 Apr 2001 08:21: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 IAA10200; Wed, 18 Apr 2001 08:20:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IFJNK9004753 for ; Wed, 18 Apr 2001 08:19:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3IFJMmR004752 for mobile-ip-dist; Wed, 18 Apr 2001 08:19: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IFJCK9004742 for ; Wed, 18 Apr 2001 08:19:13 -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 IAA28622 for ; Wed, 18 Apr 2001 08:19:13 -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 JAA07177 for ; Wed, 18 Apr 2001 09:57:38 -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 KAA22305 for ; Wed, 18 Apr 2001 10:19:27 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Wed, 18 Apr 2001 10:19:08 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Apr 2001 10:18:58 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E4301E8A285@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Revised Localized Mobility Management Requirement s Date: Wed, 18 Apr 2001 10:18:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C81A.E28BC6D0" Sender: owner-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_01C0C81A.E28BC6D0 Content-Type: text/plain; charset="iso-8859-1" Phil, Could you plese send out a consolidation of all of the proposed requirements, including a reworded 9 and 10+? -----Original Message----- From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] Sent: Wednesday, April 18, 2001 5:02 AM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] Revised Localized Mobility Management Requirement s Hi Phil I agree with most of the proposals and in dropping requirements from 9 onwards. > Agreed upon requirements where there was no dissent: > 1. Regional registration shall be introduced to minimize the signaling > traffic to the home agent or correspondent nodes for > intradomain mobility. > 2. Regional registration shall be secure against malicious > behavior from > visiting mobiles OK. > There was only minor dissent on these: > 3. Connectivity to the mobiles shall not be interrupted in > the presence of > the failure of regional registration agents. > [Only comment was that disruption should be minimized. I'd > like to get a > sense from the working group whether it feels that this one should be > restated] OK as it is for me. However, this is applicable to HAs also so it could be generalised and a common solution should be devised. Hesham had proposed to start some work on this. > 4. Regional registration shall support fast handoffs. > [Several comments that it should be compatible and no > dependencies between > the specs, so how about: Regional registration shall be > compatible with fast > handoffs.] OK with your proposed change. > 5. Regional registration shall scale to support millions of nodes in a > visited network. > [One comment that this was too broad, so I'd request someone > to rephrase it > in a better way] I can't understand the purpose of this one since it is applicable in the same way to a HA. Is there anything specific to local mobility? > > Mostly disagreement on these: > 6. . Regional registration shall not introduce new overhead on links > between the mobile and the local mobility management agents. > [Comments were that it should be minimized, or that it was ok > if it meant no > more overhead than a binding update. Here's my attempt at a > revision: local > mobility management shall not introduce new messages to notify the LMM > agents of a move. There is a disagreement as to whether > adding additional > over the air bytes is an issue, and if it is whether it's this WG's > responsibility to solve it] Do you mean to say that no new messages apart from MIPv6 BUs should be introduced? I'm OK with that. Regarding the overhead I think we're concluding that we need to monitor other groups (ROHC/Seamoby) and possibly provide them with requirements from our side. > 7. Regional registration shall allow multiple levels of hierarchy. > [There was some strong disagreement on this. Perhaps Jim or > Karim could > start a separate thread to track this one down?] Ongoing (thread is MIP v6 Regional Registration - identifying re qui rements) > 8. Regional registration shall not require changes ot the MN, the home > agent, or correspondent nodes. > [Many thought requiring no change to the MN was not doable, > but the home > agent or CN should be unchanged. So I propose we just > rewrite this as: > Regional registration shall not require changes to the home agent or > correspondent nodes.] MN needs some change, so I'm OK with your proposal. Regards /Karim ------_=_NextPart_001_01C0C81A.E28BC6D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Revised Localized Mobility Management = Requirement s

Phil,

Could you plese send out a consolidation of all of = the proposed requirements, including a reworded 9 and 10+?

-----Original Message-----
From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era= .ericsson.se]
Sent: Wednesday, April 18, 2001 5:02 AM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: [mobile-ip] Revised Localized Mobility = Management
Requirement s


Hi Phil

I agree with most of the proposals and in dropping = requirements
from 9 onwards.

> Agreed upon requirements where there was no = dissent:
> 1. Regional registration shall be introduced to = minimize the signaling
> traffic to the home agent or correspondent = nodes for
> intradomain mobility.
> 2. Regional registration shall be secure = against malicious
> behavior from
> visiting mobiles

OK.

> There was only minor dissent on these:
> 3. Connectivity to the mobiles shall not be = interrupted in
> the presence of
> the failure of regional registration = agents.
> [Only comment was that disruption should be = minimized.  I'd
> like to get a
> sense from the working group whether it feels = that this one should be
> restated]

OK as it is for me.
However, this is applicable to HAs also so it could = be generalised
and a common solution should be devised. Hesham had = proposed to start
some work on this.

> 4. Regional registration shall support fast = handoffs.
> [Several comments that it should be compatible = and no
> dependencies between
> the specs, so how about: Regional registration = shall be
> compatible with fast
> handoffs.]

OK with your proposed change.

> 5. Regional registration shall scale to support = millions of nodes in a
> visited network.
> [One comment that this was too broad, so I'd = request someone
> to rephrase it
> in a better way]

I can't understand the purpose of this one since it = is applicable
in the same way to a HA. Is there anything specific = to local mobility?

>
> Mostly disagreement on these:
> 6. .  Regional registration shall not = introduce new overhead on links
> between the mobile and the local mobility = management agents.
> [Comments were that it should be minimized, or = that it was ok
> if it meant no
> more overhead than a binding update.  = Here's my attempt at a
> revision: local
> mobility management shall not introduce new = messages to notify the LMM
> agents of a move.  There is a disagreement = as to whether
> adding additional
> over the air bytes is an issue, and if it is = whether it's this WG's
> responsibility to solve it]

Do you mean to say that no new messages apart from = MIPv6 BUs should
be introduced? I'm OK with that.
Regarding the overhead I think we're concluding that = we need to
monitor other groups (ROHC/Seamoby) and possibly = provide them with
requirements from our side.

> 7. Regional registration shall allow multiple = levels of hierarchy.
> [There was some strong disagreement on = this.  Perhaps Jim or
> Karim could
> start a separate thread to track this one = down?]

Ongoing (thread is MIP v6 Regional Registration - = identifying re qui rements)

> 8. Regional registration shall not require = changes ot the MN, the home
> agent, or correspondent nodes.
> [Many thought requiring no change to the MN was = not doable,
> but the home
> agent or CN should be unchanged.  So I = propose we just
> rewrite this as:
> Regional registration shall not require changes = to the home agent or
> correspondent nodes.]

MN needs some change, so I'm OK with your = proposal.

Regards
/Karim

------_=_NextPart_001_01C0C81A.E28BC6D0-- From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 18 11:46:33 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13177 for ; Wed, 18 Apr 2001 11:46:32 -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 IAA20957; Wed, 18 Apr 2001 08:45: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 IAA18579; Wed, 18 Apr 2001 08:45:30 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IFiHK9004848 for ; Wed, 18 Apr 2001 08:44:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3IFiGW6004847 for mobile-ip-dist; Wed, 18 Apr 2001 08:44: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IFi8K9004840 for ; Wed, 18 Apr 2001 08:44:08 -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 IAA02944 for ; Wed, 18 Apr 2001 08:44:08 -0700 (PDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA01613 for ; Wed, 18 Apr 2001 08:44:06 -0700 (PDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 18 Apr 2001 11:38:28 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Apr 2001 11:36:08 -0400 Message-ID: From: "Hongyi Li" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Revised Localized Mobility Management Requirement s (fwd) Date: Wed, 18 Apr 2001 11:36:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C81D.46B72B70" 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_01C0C81D.46B72B70 Content-Type: text/plain; charset="iso-8859-1" Hi Phil, > There was only minor dissent on these: > 3. Connectivity to the mobiles shall not be interrupted in > the presence of > the failure of regional registration agents. > [Only comment was that disruption should be minimized. I'd > like to get a > sense from the working group whether it feels that this one should be > restated] Original requirement is fine to me. > 4. Regional registration shall support fast handoffs. > [Several comments that it should be compatible and no > dependencies between > the specs, so how about: Regional registration shall be > compatible with fast > handoffs.] Agree with the change > Mostly disagreement on these: > 6. . Regional registration shall not introduce new overhead on links > between the mobile and the local mobility management agents. > [Comments were that it should be minimized, or that it was ok > if it meant no > more overhead than a binding update. Here's my attempt at a > revision: local > mobility management shall not introduce new messages to notify the LMM > agents of a move. There is a disagreement as to whether > adding additional > over the air bytes is an issue, and if it is whether it's this WG's > responsibility to solve it] This requirement should split into two. The first one requires LMM should not introduce additional signaling messages. Second one requires LMM shall not introduce new overhead on the bearer path between mobile node and agent. Instead of relying on the header compression algorithm to reduce the packet size, we should avoid introduce extra overhead to the bearer traffic in the first place. > 9. Regional registration shall not introduce host routes in > routing tables. > [Didn't get much positive on this one and got the sense folks > don't want to > rathole on a host routing discussion. I propose we drop this.] Agree to drop it. > 12. LMM should be optimized for mobile-to-mobile. > [Never really understood what this requirement was supposed > to be. Got > similar feedback from others. I propose we drop it.] This requirement was intend to avoid introduce anchor point in LMM. If people believe MIPv6 path optimization can already solve the triangular routing problem, I agree to drop it. -Hongyi ------_=_NextPart_001_01C0C81D.46B72B70 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Revised Localized Mobility Management Requirements (fwd)

Hi Phil,


> There was only minor dissent on these:
> 3. Connectivity to the mobiles shall not be interrupted in
> the presence of
> the failure of regional registration agents.
> [Only comment was that disruption should be minimized.  I'd
> like to get a
> sense from the working group whether it feels that this one should be
> restated]

Original requirement is fine to me.

> 4. Regional registration shall support fast handoffs.
> [Several comments that it should be compatible and no
> dependencies between
> the specs, so how about: Regional registration shall be
> compatible with fast
> handoffs.]

Agree with the change

> Mostly disagreement on these:
> 6. .  Regional registration shall not introduce new overhead on links
> between the mobile and the local mobility management agents.
> [Comments were that it should be minimized, or that it was ok
> if it meant no
> more overhead than a binding update.  Here's my attempt at a
> revision: local
> mobility management shall not introduce new messages to notify the LMM
> agents of a move.  There is a disagreement as to whether
> adding additional
> over the air bytes is an issue, and if it is whether it's this WG's
> responsibility to solve it]

This requirement should split into two.
The first one requires LMM should not introduce additional signaling
messages. Second one requires LMM shall not introduce new overhead
on the bearer path between mobile node and agent.

Instead of relying on the header compression algorithm to reduce
the packet size, we should avoid introduce extra overhead to the
bearer traffic in the first place.
 

> 9. Regional registration shall not introduce host routes in
> routing tables.
> [Didn't get much positive on this one and got the sense folks
> don't want to
> rathole on a host routing discussion.  I propose we drop this.]

Agree to drop it.
 
> 12. LMM should be optimized for mobile-to-mobile.
> [Never really understood what this requirement was supposed
> to be.  Got
> similar feedback from others.  I propose we drop it.]

This requirement was intend to avoid introduce anchor point in
LMM. If people believe MIPv6 path optimization can already solve the
triangular routing problem, I agree to drop it.


-Hongyi

------_=_NextPart_001_01C0C81D.46B72B70-- From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 18 12: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 MAA14135 for ; Wed, 18 Apr 2001 12:44:09 -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 JAA15749; Wed, 18 Apr 2001 09:18: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 JAA07884; Wed, 18 Apr 2001 09:18:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IGGYK9004905 for ; Wed, 18 Apr 2001 09:16:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3IGGXus004904 for mobile-ip-dist; Wed, 18 Apr 2001 09:16: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IGGPK9004897 for ; Wed, 18 Apr 2001 09:16:25 -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 JAA09907 for ; Wed, 18 Apr 2001 09:16:25 -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 KAA24300 for ; Wed, 18 Apr 2001 10:54:51 -0600 (MDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Wed, 18 Apr 2001 12:10:40 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Design teams for mobileip--(sharif) Date: Wed, 18 Apr 2001 12:10:37 -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: Behcet Sarikaya [mailto:behcet.sarikaya@usa.alcatel.com] > Sent: Wednesday, April 18, 2001 10:16 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Design teams for mobileip--(sharif) > On design teams you might want to look at RFC 2418, sec 6.5. > > Phil, > Sorry to bring this up again. I think that there two > problems here that needs > to be addressed: > 1. WG members were not consulted when DTs were closed. Jim > Bound says other WG > chairs know, this how come Mobile IP WG chairs do not? The members of the design team mailing lists were informed. > 2. The same has been repeated over maybe 3 times MIPv6 DT, > MIPv4 DT and Security > DT (?). There is no Security DT in the MIP WG that I know of. There is a group of folks working on requirements but it's outside the MIP WG. > > Phil Roberts wrote: > > > Both fast handoff lists were open to begin with but due to > some concerns > > about the ability to make progress the ADs asked us to > close them, so we > > did. > > I saw this movie before (another WG chair made similar > statements without > providing any proof). Phil do you mind providing any evidence on this? > > > The archives will be made public when the teams are done. > Versions of > > each draft have been published and you are welcome to > comment on them on the > > main list. > > I know where one of the lists is located. I can tell more > on how the list was > closed, etc., if required > > The remedy to the situation is quite simple: WG chairs > should apologize, at > the least. > And thanks to Phil Neumiller for bringing this up. > -- > Behcet > From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 18 14:23: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 OAA15192 for ; Wed, 18 Apr 2001 14:23: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 LAA05064; Wed, 18 Apr 2001 11: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 LAA20396; Wed, 18 Apr 2001 11:21:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IIJ6K9005106 for ; Wed, 18 Apr 2001 11:19:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3IIJ5nt005105 for mobile-ip-dist; Wed, 18 Apr 2001 11:19:05 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IIIsK9005098 for ; Wed, 18 Apr 2001 11:18: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 LAA10105 for ; Wed, 18 Apr 2001 11:18:53 -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 MAA25754 for ; Wed, 18 Apr 2001 12:56:59 -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 LAA01064 for ; Wed, 18 Apr 2001 11:18:52 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3IIIpP17771 for ; Wed, 18 Apr 2001 11:18:51 -0700 X-mProtect: Wed, 18 Apr 2001 11:18:51 -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(WTS.12.69) smtpdZA3tnc; Wed, 18 Apr 2001 11:18:44 PDT Message-ID: <3ADDDA84.64F00A10@iprg.nokia.com> Date: Wed, 18 Apr 2001 11:18:44 -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] Revised Localized Mobility Management 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 Hi Phil, a few comments below.. Phil Roberts wrote: > OK. Let's make another cut through these. Seems that folks like the title > Localized Mobility Management. I didn't retain the original numbers. > > Agreed upon requirements where there was no dissent: > 1. Regional registration shall be introduced to minimize the signaling > traffic to the home agent or correspondent nodes for intradomain mobility. > 2. Regional registration shall be secure against malicious behavior from > visiting mobiles > Perhaps on 2 we want to incorporate _any_ malicious behaviour..not just the MNs?? > > That's about it. > > There was only minor dissent on these: > 3. Connectivity to the mobiles shall not be interrupted in the presence of > the failure of regional registration agents. I would like to propose here that this requirement is made rather more generic. The requirement in the rationale I have considered is that : "a Localised mobility management scheme should be able to adapt to topological changes arising in the domain that the LMM scheme is in effect. The reason: the failure of LMM agents manifests itself as a topological change, since in IPv6 any such LMM agent will be a routing element. However, the population of new routing elements that can be potential candidates for LMM agents is also a manifestation of a topological change. The LMM scheme should be able to adapt to both; the latter is extremely important in terms of scalability and incremental deployment since we cannot expect to cast a domain topology in stone and live without expansion. > > [Only comment was that disruption should be minimized. I'd like to get a > sense from the working group whether it feels that this one should be > restated] My feeling on this one is that objectively we need to strive for elimination. However, with the current expertise we have this may not seem a realistic target for the particular requirement which to me sounds like "topological changes in the routing fabric with regard to an LMM scheme MUST bear a measure of minimal disruption to the extension optimizations effected by that (LMM) scheme. However, it is the intention that an LMM scheme should strive to eliminate even minimal disruption to the MNs, if possible." As such we should explictly state that we are making a minimum requirement the minimization and we strive for elimination. > > 4. Regional registration shall support fast handoffs. > [Several comments that it should be compatible and no dependencies between > the specs, so how about: Regional registration shall be compatible with fast > handoffs.] > Agreed. Although I think that it is fast handoffs that should worry about that requirement not the LMM scheme itself. In a divide and conquer manner I consider that you try to effect 1. Mobility 1.a localisation of mobility and subsequent speedups (LMM) 1.a.a speedup optimizations by applying fast handoff techniques over that LMM... So the compatibility is for the fast handoff scheme not for LMM since the LMM is the core of the optimization... I am not sure what is the order of prescedence for others over fast handoffs though.. > 5. Regional registration shall scale to support millions of nodes in a > visited network. > [One comment that this was too broad, so I'd request someone to rephrase it > in a better way] > Well thinking about it again and again we have two sides of scalability, one interacting with the other. Consider: The LMM scheme should be able to adapt (according to the rationale I have provided above) to topological changes effected in the routing fabric of the domain the LMM scheme gets applied on. But why should it be able to adapt? Of course to utilise _all_ the available (during expansion) or possible (during contraction) routing elements and thus candidate LMM agents. On reason for that is to optimize the localisation point (better candidates). But as soon as the localisation point gets optimized in a distributed fashion (i.e. not all MNs get the same one) you have what????? SCALABILITY..... So adaptivity may implicitly effect scalability from the routing fabric's viewpoint of an LMM scheme. From the perspective of the MN: We want the following: "the LMM-enabled domain to support a dense population of mobile nodes." That may be mi/bi/trillions, etc. However, to effect that, the LMM scheme MUST take advantage of the scalability potentials of the routing fabric in terms of LMM-aware routers. An that implies that it is the LMM scheme that has to provide such internal scalability before it can adhere to any scalability goals for dense MN populations within an LMM-aware domain. In that respect, I am inclined to say that: an LMM scheme MUST provide scalable population of LMM-aware routing elements which should be utilised if the scheme is to support dense populations of MNs within an LMM-aware domain. > > Mostly disagreement on these: > 6. . Regional registration shall not introduce new overhead on links > between the mobile and the local mobility management agents. > [Comments were that it should be minimized, or that it was ok if it meant no > more overhead than a binding update. Here's my attempt at a revision: local > mobility management shall not introduce new messages to notify the LMM > agents of a move. There is a disagreement as to whether adding additional > over the air bytes is an issue, and if it is whether it's this WG's > responsibility to solve it] > I agree that an LMM scheme should minimize overhead on links between LMM agents and MNs But there is also a slight falacy about what constitutes a new message. We have the backdoor of expanding the BU I guess so I could render the requirement invalid. I think it would work better to let implementors feel responsible about minimization rather than trying to constraint them like that..they usually find the backdoor straight away.. > 7. Regional registration shall allow multiple levels of hierarchy. > [There was some strong disagreement on this. Perhaps Jim or Karim could > start a separate thread to track this one down?] I personally insist that multiple levels of LMM hierarchy should be allowed. I feel unconvinced that single depth is sufficient for different LMM scenarios > > 8. Regional registration shall not require changes ot the MN, the home > agent, or correspondent nodes. > [Many thought requiring no change to the MN was not doable, but the home > agent or CN should be unchanged. So I propose we just rewrite this as: > Regional registration shall not require changes to the home agent or > correspondent nodes.] fine > > 9. Regional registration shall not introduce host routes in routing tables. > [Didn't get much positive on this one and got the sense folks don't want to > rathole on a host routing discussion. I propose we drop this.] agreed > > > We also had request for some new requirements: > 10. LMM should provide the same level of mobility mgmt support as in the > basic MIP v6 spec. MM fns supported in MIP v6 must not be reduced. > [Some positive feedback on this, shall we keep it?] > if we specify what we mean by level of mobility management so that we understand what we are talking about, then maybe.... > 11. LMM must interwork with MIPv6, IPv6, and the proposed mechanisms for SA > establishment > [One comment that this was stating the obvious. Shall we keep it?] > I am not in favour of keeping that for reasons already explained. > > 12. LMM should be optimized for mobile-to-mobile. > [Never really understood what this requirement was supposed to be. Got > similar feedback from others. I propose we drop it.] > basically here people referred to CN being in the same net with the MN and both being mobile, didn't they? Although the description of the original req has not been very clear, I suggest we either become clearer on what we want to get out of that or drop it. > > Received no feedback on the following proposed requirements. Anybody want > to keep these? > 13. Should minimize # of network nodes affected by HO signalling. > not sure about what is meant by that..either elaborate a little or drop.. > 14. Should support autoconfig. > I would say an ABSOLUTE 'must' or at worst 'should'. Most LMM schemes I know of, have pushed a lot of important parts of the protocol. If single points of failure must be resolved then autoconfiguration is nothing _less_ than a must. > 15. Should simplify network design and provisioning. simplification is a contradiction to specialisation (i.e. extension). Drop. Theo UCL/Mobile Systems From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 18 15:08:48 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16244 for ; Wed, 18 Apr 2001 15:08:47 -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 MAA04814; Wed, 18 Apr 2001 12:08:01 -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 MAA22864; Wed, 18 Apr 2001 12:07:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IJ6DK9005250 for ; Wed, 18 Apr 2001 12:06:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3IJ6CLV005249 for mobile-ip-dist; Wed, 18 Apr 2001 12:06: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IJ64K9005242 for ; Wed, 18 Apr 2001 12:06: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 MAA18535 for ; Wed, 18 Apr 2001 12:06:03 -0700 (PDT) Message-Id: <200104181906.MAA18535@heliopolis.eng.sun.com> Date: Wed, 18 Apr 2001 12:06:03 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Revised Localized Mobility Management Requirements To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: DGpKFNmkrAHBGb7dR0Oh7w== 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: > "a Localised mobility management scheme should be able to adapt to >topological changes >arising in the domain that the LMM scheme is in effect. > >The reason: > > the failure of LMM agents manifests itself as a topological change, since >in IPv6 any such LMM agent will be a routing element. However, the population >of new routing elements that can be potential candidates for LMM agents is also >a manifestation of a topological change. > >The LMM scheme should be able to adapt to both; the latter is extremely >important in terms of scalability and incremental deployment since we cannot >expect to cast a domain topology in stone and live without expansion. > I agree with this. It is a much more precise description. jak >> >> [Only comment was that disruption should be minimized. I'd like to get a >> sense from the working group whether it feels that this one should be >> restated] > >My feeling on this one is that objectively we need to strive for elimination. >However, with the current expertise we have this may not seem a realistic >target for the particular requirement which to me sounds like > >"topological changes in the routing fabric with regard to an LMM scheme MUST >bear a measure of minimal disruption to the extension optimizations effected by >that (LMM) scheme. However, it is the intention that an LMM scheme should >strive to eliminate even minimal disruption to the MNs, if possible." > >As such we should explictly state that we are making a minimum requirement the >minimization and we strive for elimination. > > > >> >> 4. Regional registration shall support fast handoffs. >> [Several comments that it should be compatible and no dependencies between >> the specs, so how about: Regional registration shall be compatible with fast >> handoffs.] >> > >Agreed. Although I think that it is fast handoffs that should worry about that >requirement not the LMM scheme itself. In a divide and conquer manner I >consider that you try to effect > > 1. Mobility > 1.a localisation of mobility and subsequent speedups (LMM) > 1.a.a speedup optimizations by applying fast handoff techniques over >that LMM... > >So the compatibility is for the fast handoff scheme not for LMM since the LMM >is the core of the optimization... > >I am not sure what is the order of prescedence for others over fast handoffs >though.. > > > >> 5. Regional registration shall scale to support millions of nodes in a >> visited network. >> [One comment that this was too broad, so I'd request someone to rephrase it >> in a better way] >> > >Well thinking about it again and again we have two sides of scalability, one >interacting with the other. Consider: > > The LMM scheme should be able to adapt (according to the rationale I have >provided above) to topological changes effected in the routing fabric of the >domain the LMM scheme gets applied on. But why should it be able to adapt? Of >course to utilise _all_ the available (during expansion) or possible (during >contraction) routing elements and thus candidate LMM agents. > > On reason for that is to optimize the localisation point (better >candidates). But as soon as the localisation point gets optimized in a >distributed fashion (i.e. not all MNs get the same one) you have what????? >SCALABILITY..... > >So adaptivity may implicitly effect scalability from the routing fabric's >viewpoint of an LMM scheme. > >>From the perspective of the MN: > > We want the following: > "the LMM-enabled domain to support a dense population of mobile nodes." > >That may be mi/bi/trillions, etc. However, to effect that, the LMM scheme MUST >take advantage of the scalability potentials of the routing fabric in terms of >LMM-aware routers. >An that implies that it is the LMM scheme that has to provide such internal >scalability before it can adhere to any scalability goals for dense MN >populations within an LMM-aware domain. > > >In that respect, I am inclined to say that: > >an LMM scheme MUST provide scalable population of LMM-aware routing elements >which should be utilised if the scheme is to support dense populations of MNs >within an LMM-aware domain. > > > >> >> Mostly disagreement on these: >> 6. . Regional registration shall not introduce new overhead on links >> between the mobile and the local mobility management agents. >> [Comments were that it should be minimized, or that it was ok if it meant no >> more overhead than a binding update. Here's my attempt at a revision: local >> mobility management shall not introduce new messages to notify the LMM >> agents of a move. There is a disagreement as to whether adding additional >> over the air bytes is an issue, and if it is whether it's this WG's >> responsibility to solve it] >> > >I agree that an LMM scheme should minimize overhead on links between LMM agents >and MNs >But there is also a slight falacy about what constitutes a new message. We have >the backdoor of expanding the BU I guess so I could render the requirement >invalid. > >I think it would work better to let implementors feel responsible about >minimization rather than trying to constraint them like that..they usually find >the backdoor straight away.. > > >> 7. Regional registration shall allow multiple levels of hierarchy. >> [There was some strong disagreement on this. Perhaps Jim or Karim could >> start a separate thread to track this one down?] > >I personally insist that multiple levels of LMM hierarchy should be allowed. I >feel unconvinced that single depth is sufficient for different LMM scenarios > > >> >> 8. Regional registration shall not require changes ot the MN, the home >> agent, or correspondent nodes. >> [Many thought requiring no change to the MN was not doable, but the home >> agent or CN should be unchanged. So I propose we just rewrite this as: >> Regional registration shall not require changes to the home agent or >> correspondent nodes.] > >fine > >> >> 9. Regional registration shall not introduce host routes in routing tables. >> [Didn't get much positive on this one and got the sense folks don't want to >> rathole on a host routing discussion. I propose we drop this.] > >agreed > >> >> >> We also had request for some new requirements: >> 10. LMM should provide the same level of mobility mgmt support as in the >> basic MIP v6 spec. MM fns supported in MIP v6 must not be reduced. >> [Some positive feedback on this, shall we keep it?] >> > >if we specify what we mean by level of mobility management so that we >understand what we are talking about, then maybe.... > > > >> 11. LMM must interwork with MIPv6, IPv6, and the proposed mechanisms for SA >> establishment >> [One comment that this was stating the obvious. Shall we keep it?] >> > >I am not in favour of keeping that for reasons already explained. > > >> >> 12. LMM should be optimized for mobile-to-mobile. >> [Never really understood what this requirement was supposed to be. Got >> similar feedback from others. I propose we drop it.] >> > >basically here people referred to CN being in the same net with the MN and both >being mobile, didn't they? > >Although the description of the original req has not been very clear, I suggest >we either become clearer on what we want to get out of that or drop it. > > >> >> Received no feedback on the following proposed requirements. Anybody want >> to keep these? >> 13. Should minimize # of network nodes affected by HO signalling. >> > >not sure about what is meant by that..either elaborate a little or drop.. > > >> 14. Should support autoconfig. >> > >I would say an ABSOLUTE 'must' or at worst 'should'. Most LMM schemes I know >of, have pushed a lot of important parts of the protocol. If single points of >failure must be resolved then autoconfiguration is nothing _less_ than a must. > > >> 15. Should simplify network design and provisioning. > >simplification is a contradiction to specialisation (i.e. extension). Drop. > > >Theo > >UCL/Mobile Systems > From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 18 15:18: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 PAA16401 for ; Wed, 18 Apr 2001 15:18:27 -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 MAA28245; Wed, 18 Apr 2001 12:16:34 -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 MAA28698; Wed, 18 Apr 2001 12:14:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IJD9K9005307 for ; Wed, 18 Apr 2001 12:13:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3IJD9t0005306 for mobile-ip-dist; Wed, 18 Apr 2001 12:13: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IJD0K9005298 for ; Wed, 18 Apr 2001 12:13:00 -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 MAA12886 for ; Wed, 18 Apr 2001 12:12:59 -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 MAA22491 for ; Wed, 18 Apr 2001 12:12:54 -0700 (PDT) Received: from ws34.nomadiclab.com (ws34.nomadiclab.com [195.165.196.34]) by ws130.nomadiclab.com (Postfix) with ESMTP id BB67572503 for ; Wed, 18 Apr 2001 22:12:52 +0300 (EEST) Received: from nomadiclab.com (localhost [127.0.0.1]) by ws34.nomadiclab.com (Postfix) with ESMTP id 10C49BA0B for ; Wed, 18 Apr 2001 22:12:52 +0300 (EEST) Message-ID: <3ADDE8E6.B4C4F482@nomadiclab.com> Date: Wed, 18 Apr 2001 22:20:06 +0300 From: Pekka Nikander X-Mailer: Mozilla 4.75 [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] the security issue References: <3AD5B9CA.CF550C7B@rd.francetelecom.fr> <15061.49804.692345.636891@thomasm-u1.cisco.com> <3AD5D85E.654DCCAB@iprg.nokia.com> <15061.56795.208181.755937@thomasm-u1.cisco.com> <5.0.2.1.2.20010414011934.03f18328@mira-sjcm-2.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 > At 09:13 AM 4/14/2001 +0300, Pekka Nikander wrote: > >That is, according to a commonly accepted principle, you cannot build > >secure security associations unless you have already some existing > >security relationship. Fred Baker wrote: > You actually can, but they are of limited value. IKE generates a security > association ex nihilo using a diffie-helman algorithm, which allows you to > keep private information private and enables you to be sure you are still > talking with the same person. The problem you are referring to is that you > don't authoritatively know who that person *is* apart from a security > association demonstrably set up with the person you intend. I known and agree. Here we have a terminology issue. With a "secure security association" I meant something where you know the "identity" of your peer. (I don't want here to go to the hairy issue of what is identity.) And since you know the "identity" of your peer, you can probably somehow deduce in which respects you can trust your peer. > You are > depending on a dynamic association (and therefore key) to authenticate the > Home Agent or the Mobile Node and determine whether either is authorized to > instruct you to change your binding association. But a dynamic association > only tells you that you are talking with the same process you spoke with > before, not that the process is indeed the authorized agent. For all you > know, it is a law enforcement agency wishing to inspect your > communications, or the bad guys who want to use your communications to your > harm. Sure. That is the reason why the Home Agent is explicitly involved in BAKE. I don't see any major difference, in this respect, between using D-H and using the symmetric key procedure that we use in BAKE. Either way, you are vulnerable to certain active attackers. As a related question, how would you define the "process [that] is indeed the authorized agent"? What is the qualification that makes the agent an authorized one? Who or what provides that authority? How do you check that the agent possesses the authority? In the case of CAM/SUCV, the major idea is to use host ID part of an IPv6 address as an implicit security association, binding a public key to an IPv6 address. http://www.tml.hut.fi/~pnr/publications/draft-nikander-ipng-pbk-addresses-00.txt goes a little bit further, and defines "address ownership" in terms of binding a public key to an IPv6 address like CAM/SUCV, checking the reachablity of the agent through that address, and requesting the agent to provide a previous hash value in a series of hash values, i.e., a one time password. Thus, that gives one practical answer to how to check if an agent is authorized. > >That is, independent of whether we proceed to a Proposed Standard within a > >very quick timeframe or not > > IMHO, you can go to PS with optimized routing (which I think is a truly > cool feature) if and only if you can solve the authentication/authorization > problem, ... > A simple suggestion *might* be to have the mobile node send its > correspondent a certificate containing the appropriate public key, so that > the correspondent can know for certain that it received something properly > authenticated. I don't see how this would be any better than, e.g., just running D-H. Whose signature should the certificate include? How does the CN know that the issuer of the certificate is authorized to provide statements about what home addresses the MN may use and what not? Or, as you say, > ... Who authorizes the authority? Some people are promoting some sort of a global PKI, and those blinded by AAA think that everybody would use it. PKI or AAA will definitely work for some, but IMHO scalability and deployment problems will be quite hard. Both BAKE and CAM/SUCV/... approaches look for solutions at a different direction. --Pekka From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 18 16:18:53 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17161 for ; Wed, 18 Apr 2001 16:18:52 -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 NAA14453; Wed, 18 Apr 2001 13:17:59 -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 NAA14955; Wed, 18 Apr 2001 13:17:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IKFmK9005443 for ; Wed, 18 Apr 2001 13:15:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3IKFhcR005442 for mobile-ip-dist; Wed, 18 Apr 2001 13:15:43 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IKFTK9005435 for ; Wed, 18 Apr 2001 13:15:29 -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 NAA28932 for ; Wed, 18 Apr 2001 13:15:28 -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 NAA18653 for ; Wed, 18 Apr 2001 13:15:27 -0700 (PDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Apr 2001 16:14:32 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'mobile-ip@sunroof.eng.sun.com'" Cc: "'proberts@megisto.com'" , "'basavaraj.patil@nokia.com'" , "Shahrier, Sharif M." Subject: [mobile-ip] failure detection and recovery issues in MIPv6 Date: Wed, 18 Apr 2001 16:14:27 -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: Folks, I would like to solicit some comments from the WG regarding the issue of "failure detection" and "failure recovery". So far, I have had one comment, thus any further comments would be very valuable to us in deciding whether or not to persue this work. I would like to discuss a couple of issues relating to the "Mobility Support in IPv6" draft v13.0. It is regarding to failure/reconfiguration of home agent router while the MN is away from its home agent. It is stated that the dynamic home agent address discovey procedure was to be used to dynamically discover the IP address of a home agent. As an alternative, a dual home agent router system can be used, to form a 2MR system. One of the routers is the "shadow" of the other and is only used as backup. If the "primary" one fails or is reconfigured, the "shadow" router could be switched into operation. From my previous knowledge, 2MR systems are quite fail-safe and have been successfully deployed in many fault tolerant systems. I was wondering how people felt about the 2MR approach for failure detection and recovery. Another problem that I didn't see being discussed in the draft is the failure of home agent's link when the MN is away from its home agent. Link failure or reconfiguration is just as important as home agent failure. I believe that this needs to be explicitly spelled out in the draft. Could people comment on this as well. There are other issues regarding fault tolerance as well. Now regarding these two issues, I could either: * Produce a framework draft and ask it be rated to a mobileip draft at the next meeting. This will allow people time to investigate the fault tolerance problem within a mobile network and come up with ideas. * Produce a complete solutions draft and ask it to be rated to mobileip draft, and merged with the current MIPv6 spec. * A combination of the two. Again, Thanks in advance for your comments. Sharif. From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 18 16:56:57 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17826 for ; Wed, 18 Apr 2001 16:56:56 -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 NAA24768; Wed, 18 Apr 2001 13:55: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 NAA26825; Wed, 18 Apr 2001 13:55:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IKrdK9005474 for ; Wed, 18 Apr 2001 13:53:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3IKrdlC005473 for mobile-ip-dist; Wed, 18 Apr 2001 13:53: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 bebop.france (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IKrUK9005466 for ; Wed, 18 Apr 2001 13:53:30 -0700 (PDT) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.france (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id WAA01503 for ; Wed, 18 Apr 2001 22:53:26 +0200 (MET DST) Date: Wed, 18 Apr 2001 13:53:25 -0700 (PDT) From: Erik Nordmark Subject: Re: [mobile-ip] Revised Localized Mobility Management Requirements To: mobile-ip@sunroof.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: > OK. Let's make another cut through these. Seems that folks like the title > Localized Mobility Management. I didn't retain the original numbers. > > Agreed upon requirements where there was no dissent: > 1. Regional registration shall be introduced to minimize the signaling > traffic to the home agent or correspondent nodes for intradomain mobility. I assume this applies to a "domain" being something larger than one IP subnet and smaller than the whole Internet, since in the first case L2 does the work and in the second case the existing HA does the work. My question is whether it would be useful to constrain the size and other attributes a bit more. For instance, is this "domain" within one adminstrative domain or not? The answer affects what trust models make sense for securing things. Even within one adminstrative domain there might be cases where you want to limit this "domain" to less than the whole adminstrative domain - for instance if the adminstrative domain spans the globe. This might mean that it might make sense to view this as a "small RTT domain" (using the exactly defined "small" :-), since in a large RTT domain the latency of updating the local mobility agent(s) might be as large as updating the home agent. Erik From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 18 17:55:04 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18616 for ; Wed, 18 Apr 2001 17:55:03 -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 OAA15490; Wed, 18 Apr 2001 14:54:28 -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 OAA12659; Wed, 18 Apr 2001 14:54:16 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3ILqpK9005507 for ; Wed, 18 Apr 2001 14:52:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3ILqp4k005506 for mobile-ip-dist; Wed, 18 Apr 2001 14:52: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3ILqgK9005499 for ; Wed, 18 Apr 2001 14:52: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 OAA12156 for ; Wed, 18 Apr 2001 14:52:43 -0700 (PDT) Message-Id: <200104182152.OAA12156@heliopolis.eng.sun.com> Date: Wed, 18 Apr 2001 14:52:43 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] MIP v6 Regional Registration - identifying re qui rements To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 1kN4DWfVz2K5jjb+f1rdjQ== 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 Karim, >> The requirement I see is that any additional header state be >> eliminated by compression, and that transfer of compressor state >> upon handover makes it possible to restart compression so as >> to not introduce >> any additional latency into handover. > >Karim: >I agree with what you have above, except for the latency part. >If a user cannot notice (or is not disrupted by) the reestablishment >of header compression context without CT, then no additional latency >is introduced (i.e. the MN gets service, but the first few packets are >sent uncompressed). I think we got feedback both from people saying >that CT is needed and from people saying CT is not needed for header >compression. So I'd like to modify your requirement to be: >"it should be possible to reduce impact due to additional headers by >compression, and the service perceived by the user should not be >degraded upon L3 handoff (either through reestablishment of context or >through transfer of compressor state upon handover)" > >However this requirement is not a requirement on local mobility, >it's a requirement on ROHC/Seamoby CT. So I think it's more appropriate >to pass this requirement onto those groups and monitor the results. > OK, so I think we have agreement that the requirements should state something about ROHC/Seamoby review to make sure that compression and context transfer can handle a change in header during handover, if the solution introduces any additional header overhead beyond standard MIPv6. Phil, please take note? >I didn't mean to exclude the Seamoby AP discovery mechanism. It is >in fact one way of informing the MN of what access is available to it. >The MN may use other methods too, which are not necessarily better. >For example, if it has WLAN, Bluetooth and W-CDMA interfaces it >could know locally (local user preferences) which one it prefers for >which type of connection and act as a consequence. However, the way the >MN finds this out is outside the scope of this draft. > >So I think we agree that it could be useful to allow the MN to >move connections over different accesses as it moves. Yes, but I don't see this as specifically a LMM requirement. This is actually a more a basic MIPv6 requirement since I could imagine that it would be useful even in the absence of LMM. And, I am not clear whether MIPv6 actually will support it now, would need to spend some time with the spec to make sure. In any event, I don't see it as part of the LMM requirement set. >The preference value is a different issue, only used to pick a MAP. Why couldn't the Seamoby protocol be used for this? The MAP could advertise using the Seamoby protocol and the mobile could select a MAP based on that. >What was included (in HMIPv6) was a mechanism to move connections to >different MN interfaces. The method used by the MN to find out the "best" >interface/access for a connection was not included in the spec. > >So I think we should allow a multiply-interfaced MN to move connections >between its interfaces, but in a more generic way applicable to HA and/or >local agent (i.e. MAP). That's the separate draft I was talking about. >I think we agree on this, but had a misunderstanding on the preference >issue? > Yes, that's right. As Hesham pointed out, basic MIPv6 also has these preferences, so perhaps I need to formulate a proposal to Dave and Charlie that it be removed from there as well, since the Seamoby protocol should take care of it. > >OK, I see your point, but this still needs a discussion so that we >agree on what we want. This requirement makes certain architectural >assumptions about the IP radio network. The problem is that we probably >have different views of what an IP wireless network should be, so any >requirement from one side or another will be a source of misunderstanding. >In my case, for example, I can only see the need for a one-level local MAP >(possibly multiple independent MAPs to share the MN load in a large local >network and for eventual redundancy mechanisms to be developed). > Right, I understand. I was not proposing a requirement specifically for a radio access network, but using the radio access network as an example of what the requirement would allow or deny. >Let's say you don't have multiple levels of agents, but have multiple >levels of routers. I can see ways in which you can achieve what you >are saying through normal IP routing, without having to deploy local >agents in the large ISP. What I mean is that you don't need to use >MIPv6 and local agents to make traffic from outside a local domain go >through a particular border router. So, I don't think that placing a >local agent to aggregate traffic in a transit ISP network is the right >solution. > Well, packets from CNs outside the MAP domain are getting sent to the RCoA at the MAP, where they are encapsulated and sent to the mobile node. So, like I said, the MAP is operating as a router. Now, if a wired network operator is acting as an ISP peer for a bunch of wireless ISPs, the wired operator may want to set up a single MAP through which all the peered MIP traffic is run, and each sub-ISP will want to have their own MAP for signalling within their domain. These sorts of routing hierarchies are commonly used, and if the LMM solution precludes them, we may end up with problems down the line. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 19 03:42:51 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08270 for ; Thu, 19 Apr 2001 03:42: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 AAA20198; Thu, 19 Apr 2001 00:41: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 AAA16232; Thu, 19 Apr 2001 00:41:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3J7eXK9005959 for ; Thu, 19 Apr 2001 00:40:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3J7eXjD005958 for mobile-ip-dist; Thu, 19 Apr 2001 00: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3J7eOK9005951 for ; Thu, 19 Apr 2001 00:40:24 -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 AAA17927 for ; Thu, 19 Apr 2001 00:40:22 -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 AAA08472 for ; Thu, 19 Apr 2001 00:40:21 -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 JAA09595 for ; Thu, 19 Apr 2001 09:39:47 +0200 (MEST) Message-ID: <3ADE9632.C17A64D0@inrialpes.fr> Date: Thu, 19 Apr 2001 09:39:30 +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] Revised Localized Mobility Management Requirements References: Content-Type: multipart/alternative; boundary="------------7EB6C64816A3388F19B7BCF2" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------7EB6C64816A3388F19B7BCF2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Erik, Erik Nordmark wrote: > > OK. Let's make another cut through these. Seems that folks like the title > > Localized Mobility Management. I didn't retain the original numbers. > > > > Agreed upon requirements where there was no dissent: > > 1. Regional registration shall be introduced to minimize the signaling > > traffic to the home agent or correspondent nodes for intradomain mobility. > > I assume this applies to a "domain" being something larger than one IP subnet > and smaller than the whole Internet, since in the first case L2 does the work > and in the second case the existing HA does the work. > My question is whether it would be useful to constrain the size and other > attributes a bit more. > > For instance, is this "domain" within one adminstrative domain or not? > The answer affects what trust models make sense for securing things. > Just as an example in HMIPv6, we refer as "domain" the set of nodes that are supported by the same MAP (or set of MAPs)... I am not sure whether this domain has to be owned by the same administrative entity (probably not)... regards, Claude. -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------7EB6C64816A3388F19B7BCF2 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Erik,

Erik Nordmark wrote:

> OK.  Let's make another cut through these.  Seems that folks like the title
> Localized Mobility Management.  I didn't retain the original numbers.
>
> Agreed upon requirements where there was no dissent:
> 1. Regional registration shall be introduced to minimize the signaling
> traffic to the home agent or correspondent nodes for intradomain mobility.

I assume this applies to a "domain" being something larger than one IP subnet
and smaller than the whole Internet, since in the first case L2 does the work
and in the second case the existing HA does the work.
My question is whether it would be useful to constrain the size and other
attributes a bit more.

For instance, is this "domain" within one adminstrative domain or not?
The answer affects what trust models make sense for securing things.
 

Just as an example in HMIPv6, we refer as "domain" the set of nodes that are supported by the
same MAP (or set of MAPs)...
I am not sure whether this domain has to be owned by the same administrative entity (probably not)...

regards,
Claude. 




-- 

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

 

--------------7EB6C64816A3388F19B7BCF2--



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 19 04:41:05 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA08802
	for ; Thu, 19 Apr 2001 04:41:04 -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 BAA01247;
	Thu, 19 Apr 2001 01:39:22 -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 BAA20802;
	Thu, 19 Apr 2001 01:39:15 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3J8c1K9006045
	for ; Thu, 19 Apr 2001 01:38:01 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3J8c1rg006044
	for mobile-ip-dist; Thu, 19 Apr 2001 01:38: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3J8boK9006037
	for ; Thu, 19 Apr 2001 01:37:50 -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 BAA22236
	for ; Thu, 19 Apr 2001 01:37:50 -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 DAA23788
	for ; Thu, 19 Apr 2001 03:21:00 -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 f3J8blO16273
	for ; Thu, 19 Apr 2001 10:37:47 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Apr 19 10:37:46 2001 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Thu, 19 Apr 2001 10:33:12 +0200
Message-ID: 
From: "Karim El-Malki (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Revised Localized Mobility Management Requirement
	s
Date: Thu, 19 Apr 2001 10:37:40 +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 Theo and James

> >     "a Localised mobility management scheme should be able 
> to adapt to
> >topological changes
> >arising in the domain that the LMM scheme is in effect.
> >
> >The reason:
> >
> >    the failure of LMM agents manifests itself as a 
> topological change, since
> >in IPv6 any such LMM agent will be a routing element. 
> However, the population
> >of new routing elements that can be potential candidates for 
> LMM agents is also
> >a manifestation of a topological change.
> >
> >The LMM scheme should be able to adapt to both; the latter 
> is extremely
> >important in terms of scalability and incremental deployment 
> since we cannot
> >expect to cast a domain topology in stone and live without expansion.
> >
> 
> I agree with this. It is a much more precise description.
> 

I think this change could bring new functionality into local MIP mobility
which is not necessarily needed. The local agent is basically a
local HA. Adapting to topological change is in the domain of MANET.
IMO we need some agent redundancy protocol more than a MANET protocol
which the above points to. It may be due to my misinterpretation, but
that's the way it reads to me. So I am happier with Phil's version
or something along those lines.

In any case this requirement can be applied to HAs and local agents (MAPs),
so it could be (should be?) solved outside the local mobility draft.
(i.e. mobility agent redundancy protocol).

Regards
/Karim


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 19 04:46:57 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA08850
	for ; Thu, 19 Apr 2001 04:46:56 -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 BAA04308;
	Thu, 19 Apr 2001 01:45: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 BAA05228;
	Thu, 19 Apr 2001 01:45:42 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3J8iaK9006067
	for ; Thu, 19 Apr 2001 01:44:36 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3J8iZUh006066
	for mobile-ip-dist; Thu, 19 Apr 2001 01:44: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3J8iRK9006059
	for ; Thu, 19 Apr 2001 01:44:27 -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 BAA21240
	for ; Thu, 19 Apr 2001 01:44:26 -0700 (PDT)
Received: from taku.hut.fi (taku.hut.fi [130.233.228.87])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA27916
	for ; Thu, 19 Apr 2001 01:44:25 -0700 (PDT)
Received: from gamma.hut.fi (tweckstr@gamma.hut.fi [130.233.224.52])
	by taku.hut.fi (8.9.3/8.9.3) with ESMTP id LAA17635
	for ; Thu, 19 Apr 2001 11:44:24 +0300 (EET DST)
Date: Thu, 19 Apr 2001 11:44:24 +0300 (EET DST)
From: =?ISO-8859-1?Q?Tom_Weckstr=F6m?= 
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Revised Localized Mobility Management Requirements
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 BAA04308
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA08850

Hi.

Small comments to Erik's good notifications:

On Wed, 18 Apr 2001, Erik Nordmark wrote:

Erik.N >> OK.  Let's make another cut through these.  Seems that folks like the title
Erik.N >> Localized Mobility Management.  I didn't retain the original numbers.
Erik.N >> 
Erik.N >> Agreed upon requirements where there was no dissent:
Erik.N >> 1. Regional registration shall be introduced to minimize the signaling
Erik.N >> traffic to the home agent or correspondent nodes for intradomain mobility.
Erik.N >
Erik.N >I assume this applies to a "domain" being something larger than one IP subnet
Erik.N >and smaller than the whole Internet, since in the first case L2 does the work
Erik.N >and in the second case the existing HA does the work.
Erik.N >My question is whether it would be useful to constrain the size and other
Erik.N >attributes a bit more.
Erik.N >
Erik.N >For instance, is this "domain" within one adminstrative domain or not?
Erik.N >The answer affects what trust models make sense for securing things.
Erik.N >
Erik.N >Even within one adminstrative domain there might be cases where you want
Erik.N >to limit this "domain" to less than the whole adminstrative domain - for
Erik.N >instance if the adminstrative domain spans the globe.
Erik.N >This might mean that it might make sense to view this as a "small RTT domain"
Erik.N >(using the exactly defined "small" :-), since in a large RTT domain
Erik.N >the latency of updating the local mobility agent(s) might be as large as 
Erik.N >updating the home agent.
Erik.N >
Erik.N >  Erik

Firstly, a good design principle to limit the size of a "domain" is to
think how fast handoffs this "domain" would be able to provide. In a
humongous hierarchy with slow links between the elements of the hierarchy,
even the localized mobility management may not provide reasonably fast
handoffs. The size of the domain is also linked to the number of MNs the
system must support. By splitting mega-domains, one would also gain some
scalability for the entire system of domains, but that is merely a network
design issue, perhaps not that tightly related to protocol design.

Secondly, the latency of updating the binding in the HA in the MN's home 
network is always at least one hop slower (round trip 2 hops) than
updating only the local mobility agents. Correct me, if you can think of a
scenario that breaks my argument.

Best regards,
		Tom
-- 
	Tom Weckström		Dynamics group
				Helsinki University of Technology
				dynamics@cs.hut.fi
				http://www.cs.hut.fi/Research/Dynamics/



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 19 05:43:33 2001
Received: from mercury.Sun.COM ([192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09403
	for ; Thu, 19 Apr 2001 05:43:32 -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 CAA01778;
	Thu, 19 Apr 2001 02:41: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 CAA07957;
	Thu, 19 Apr 2001 02:41:06 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3J9e0K9006259
	for ; Thu, 19 Apr 2001 02:40:00 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3J9e0OR006258
	for mobile-ip-dist; Thu, 19 Apr 2001 02:40: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3J9dpK9006251
	for ; Thu, 19 Apr 2001 02:39:51 -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 CAA07662
	for ; Thu, 19 Apr 2001 02:39:50 -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 CAA05082
	for ; Thu, 19 Apr 2001 02:39:48 -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 f3J9dkN19220
	for ; Thu, 19 Apr 2001 11:39:46 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Apr 19 11:39:41 2001 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Thu, 19 Apr 2001 11:35:06 +0200
Message-ID: 
From: "Karim El-Malki (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] MIP v6 Regional Registration - identifying re qui
	 rements
Date: Thu, 19 Apr 2001 11:39:35 +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 James

More comments below.

> >> The requirement I see is that any additional header state be
> >> eliminated by compression, and that transfer of compressor state
> >> upon handover makes it possible to restart compression so as 
> >> to not introduce 
> >> any additional latency into handover.
> >
> >Karim:
> >I agree with what you have above, except for the latency part.
> >If a user cannot notice (or is not disrupted by) the reestablishment
> >of header compression context without CT, then no additional latency
> >is introduced (i.e. the MN gets service, but the first few 
> packets are
> >sent uncompressed). I think we got feedback both from people saying
> >that CT is needed and from people saying CT is not needed for header
> >compression. So I'd like to modify your requirement to be:
> >"it should be possible to reduce impact due to additional headers by
> >compression, and the service perceived by the user should not be
> >degraded upon L3 handoff (either through reestablishment of 
> context or
> >through transfer of compressor state upon handover)"
> >
> >However this requirement is not a requirement on local mobility,
> >it's a requirement on ROHC/Seamoby CT. So I think it's more 
> appropriate
> >to pass this requirement onto those groups and monitor the results.
> >
> 
> OK, so I think we have agreement that the requirements should state
> something about ROHC/Seamoby review to make sure that compression
> and context transfer can handle a change in header during handover,
> if the solution introduces any additional header overhead beyond
> standard MIPv6. Phil, please take note?

Karim:
Almost. CT may not be needed for header compression, so the requirement
cannot state that we must make sure that CT works for us.
The only thing I can see is the need for ROHC when low bandwidth
links are used. Should we have a requirement saying this? Don't know if
it is much use though.


> 
> >I didn't mean to exclude the Seamoby AP discovery mechanism. It is
> >in fact one way of informing the MN of what access is 
> available to it.
> >The MN may use other methods too, which are not necessarily better.
> >For example, if it has WLAN, Bluetooth and W-CDMA interfaces it
> >could know locally (local user preferences) which one it prefers for
> >which type of connection and act as a consequence. However, 
> the way the
> >MN finds this out is outside the scope of this draft.
> >
> >So I think we agree that it could be useful to allow the MN to
> >move connections over different accesses as it moves.
> 
> Yes, but I don't see this as specifically a LMM requirement. This
> is actually a more a basic MIPv6 requirement since I could imagine
> that it would be useful even in the absence of LMM. And, I am
> not clear whether MIPv6 actually  will support it now, would need
> to spend some time with the spec to make sure. In any event, I
> don't see it as part of the LMM requirement set.

Karim:
Agreed. It is something more generic, and we decided to make it
into a separate draft in Minneapolis.

> 
> >The preference value is a different issue, only used to pick a MAP.
> 
> Why couldn't the Seamoby protocol be used for this? The MAP could
> advertise using the Seamoby protocol and the mobile could select
> a MAP based on that.

Karim:
Well, the MAP will advertise, so why not make use of the preference?
I'm sure you could use the Seamoby protocol to convey more info,
but they could coexist. It is possible that not all MNs support
the seamoby AP discovery protocol. I think it is a basic MIPv6
discussion in any case, as you say in your comment below.

> 
> >What was included (in HMIPv6) was a mechanism to move connections to
> >different MN interfaces. The method used by the MN to find 
> out the "best"
> >interface/access for a connection was not included in the spec.
> >
> >So I think we should allow a multiply-interfaced MN to move 
> connections
> >between its interfaces, but in a more generic way applicable 
> to HA and/or
> >local agent (i.e. MAP). That's the separate draft I was 
> talking about.
> >I think we agree on this, but had a misunderstanding on the 
> preference
> >issue?
> >
> 
> Yes, that's right. As Hesham pointed out, basic MIPv6 also has these
> preferences, so perhaps I need to formulate a proposal to Dave
> and Charlie that it be removed from there as well, since the Seamoby
> protocol should take care of it. 

Karim:
I'm not sure I agree on its removal, but it is a MIPv6 issue.


> 
> >
> >OK, I see your point, but this still needs a discussion so that we
> >agree on what we want. This requirement makes certain architectural
> >assumptions about the IP radio network. The problem is that 
> we probably
> >have different views of what an IP wireless network should be, so any
> >requirement from one side or another will be a source of 
> misunderstanding.
> >In my case, for example, I can only see the need for a 
> one-level local MAP
> >(possibly multiple independent MAPs to share the MN load in 
> a large local
> >network and for eventual redundancy mechanisms to be developed).
> >
> 
> Right, I understand. I was not proposing a requirement specifically
> for a radio access network, but using the radio access network as
> an example of what the requirement would allow or deny.
> 
> >Let's say you don't have multiple levels of agents, but have multiple
> >levels of routers. I can see ways in which you can achieve what you
> >are saying through normal IP routing, without having to deploy local
> >agents in the large ISP. What I mean is that you don't need to use
> >MIPv6 and local agents to make traffic from outside a local domain go
> >through a particular border router. So, I don't think that placing a
> >local agent to aggregate traffic in a transit ISP network is 
> the right
> >solution.
> >
> 
> Well, packets from CNs outside the MAP domain are getting sent to the
> RCoA at the MAP, where they are encapsulated and sent to the mobile
> node. So, like I said, the MAP is operating as a router. Now, if
> a wired network operator is acting as an ISP peer for a bunch of
> wireless ISPs, the wired operator may want to set up a single MAP
> through which all the peered MIP traffic is run, and each sub-ISP will
> want to have their own MAP for signalling within their domain. These
> sorts of routing hierarchies are commonly used, and if the LMM
> solution precludes them, we may end up with problems down the line.

Karim:
I can see that you could use a MAP for this, but is it not simpler to
use normal routing to direct all traffic to local MAPs (RCOAs) through a
certain router if required? What I mean is that it's not a strong reason
to have multiple levels since it can be done otherwise without the need
for MIP.

Regards
/Karim



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 19 08:42:21 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10371
	for ; Thu, 19 Apr 2001 08:42:20 -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 FAA28010;
	Thu, 19 Apr 2001 05:41: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 FAA10881;
	Thu, 19 Apr 2001 05:41:21 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JCeBK9006446
	for ; Thu, 19 Apr 2001 05:40:11 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3JCeBu3006445
	for mobile-ip-dist; Thu, 19 Apr 2001 05:40:11 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JCe1K9006438
	for ; Thu, 19 Apr 2001 05:40:02 -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 FAA12145
	for ; Thu, 19 Apr 2001 05:40:02 -0700 (PDT)
Received: from c007.snv.cp.net (c007-h012.c007.snv.cp.net [209.228.33.219])
	by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id FAA27020
	for ; Thu, 19 Apr 2001 05:40:01 -0700 (PDT)
Received: (cpmta 21037 invoked from network); 19 Apr 2001 05:40:00 -0700
Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129)
  by smtp.telocity.com (209.228.33.219) with SMTP; 19 Apr 2001 05:40:00 -0700
X-Sent: 19 Apr 2001 12:40:00 GMT
Message-ID: <018401c0c8cd$ba8800a0$6501a8c0@philneum>
From: "Phil Neumiller" 
To: , 
References: 
Subject: Re: [mobile-ip] Design teams for mobileip--(sharif)
Date: Thu, 19 Apr 2001 07:39:02 -0500
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: 

Phil R.,

I qoute RFC 2418, sec 6.5 for convience:

// QUOTE
6.5. Design teams

   It is often useful, and perhaps inevitable, for a sub-group of a
   working group to develop a proposal to solve a particular problem.
   Such a sub-group is called a design team.  In order for a design team
   to remain small and agile, it is acceptable to have closed membership
   and private meetings.  Design teams may range from an informal chat
   between people in a hallway to a formal set of expert volunteers that
   the WG chair or AD appoints to attack a controversial problem.  The
   output of a design team is always subject to approval, rejection or
   modification by the WG as a whole.
// END QUOTE

My beef with RFC 2418 section 6.5 sentence 3, is where it appears that
the MIP WG has decided to attack even "non-controversial work", i.e
almost all its work, in closed design teams with no open mail lists.  This
includes all the MIPv6 work the MIPv4 fast handoff work.

I don't believe this is what Scott intended and I have copied him on this
mail and I would like him to clarify and comment.

Thanks,

Phil N.








From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 19 08:51:35 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10472
	for ; Thu, 19 Apr 2001 08:51: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 FAA04264;
	Thu, 19 Apr 2001 05:50: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 FAA25511;
	Thu, 19 Apr 2001 05:50:37 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JCnaK9006468
	for ; Thu, 19 Apr 2001 05:49:36 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3JCnaOT006467
	for mobile-ip-dist; Thu, 19 Apr 2001 05:49: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JCnPK9006460
	for ; Thu, 19 Apr 2001 05:49:25 -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 FAA25371
	for ; Thu, 19 Apr 2001 05:49:25 -0700 (PDT)
Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA00335
	for ; Thu, 19 Apr 2001 07:33:37 -0600 (MDT)
Received: (from sob@localhost)
	by newdev.harvard.edu (8.9.3/8.9.3) id IAA07240;
	Thu, 19 Apr 2001 08:49:05 -0400 (EDT)
Date: Thu, 19 Apr 2001 08:49:05 -0400 (EDT)
From: Scott Bradner 
Message-Id: <200104191249.IAA07240@newdev.harvard.edu>
To: neumiller@telocity.com
Subject: Re: [mobile-ip] Design teams for mobileip--(sharif)
Cc: mobile-ip@sunroof.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: 

note that teh output of design teams is input for working groups - anything
that a design team does can be modified or undone by the WG

Scott


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 19 10:24:06 2001
Received: from mercury.Sun.COM ([192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11560
	for ; Thu, 19 Apr 2001 10:24:02 -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 HAA01783;
	Thu, 19 Apr 2001 07:21: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 HAA26994;
	Thu, 19 Apr 2001 07:20:36 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JEIUK9006650
	for ; Thu, 19 Apr 2001 07:18:30 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3JEIUcr006649
	for mobile-ip-dist; Thu, 19 Apr 2001 07:18: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JEILK9006642
	for ; Thu, 19 Apr 2001 07:18: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 HAA09569
	for ; Thu, 19 Apr 2001 07:18:21 -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 HAA05145
	for ; Thu, 19 Apr 2001 07:18:21 -0700 (PDT)
Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21)
	id ; Thu, 19 Apr 2001 10:12:35 -0400
Message-ID: 
From: Phil Roberts 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: [mobile-ip] WG last call: AAA Keys
Date: Thu, 19 Apr 2001 10:12:35 -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: 

This is a Mobile IP WG last call for the I-D
draft-ietf-mobileip-aaa-key-04.txt
AAA Registration Keys for Mobile IP. This draft will be sent to the IESG
requesting a proposed standard status to be associated with it at the end of
the last call
period. Please send your comments to the WG discussion list.

WG Last call issued on : Apr 19, 2001
Expires on : May 4, 2001

Basavaraj Patil
Phil Roberts


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 19 10:41:51 2001
Received: from mercury.Sun.COM ([192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11838
	for ; Thu, 19 Apr 2001 10:41: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 HAA10985;
	Thu, 19 Apr 2001 07:40:23 -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 HAA12184;
	Thu, 19 Apr 2001 07:39:53 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JEcfK9006669
	for ; Thu, 19 Apr 2001 07:38:42 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3JEcfae006668
	for mobile-ip-dist; Thu, 19 Apr 2001 07:38: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JEcWK9006661
	for ; Thu, 19 Apr 2001 07:38:32 -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 HAA01617
	for ; Thu, 19 Apr 2001 07:38:33 -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 HAA05135
	for ; Thu, 19 Apr 2001 07:38:32 -0700 (PDT)
Received: from kaspit.cisco.com (kaspit.cisco.com [144.254.91.49])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA05400
	for ; Thu, 19 Apr 2001 07:38:36 -0700 (PDT)
Received: from sdraznin-7220.cisco.com (par-ilm-dhcp2-vl111-8.cisco.com [144.254.56.177])
	by kaspit.cisco.com (Mirapoint)
	with ESMTP id AFK11732;
	Thu, 19 Apr 2001 17:38:27 +0300 (GMT-3)
Message-Id: <4.3.2.7.2.20010419173903.00bb9590@kaspit.cisco.com>
X-Sender: sdraznin@kaspit.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 19 Apr 2001 17:41:34 +0100
To: mobile-ip@sunroof.eng.sun.com
From: Draznin Sagiv 
Subject: [mobile-ip] "beginners question"
In-Reply-To: <3ADE9632.C17A64D0@inrialpes.fr>
References: 
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_1933380==_.ALT"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

--=====================_1933380==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Sorry for the "beginners question",
Someone can explain the main differences between GPRS and Mobile IP?

  At 09:39 AM 4/19/2001 +0200, you wrote:
>Hello Erik,
>
>Erik Nordmark wrote:
>> > OK.  Let's make another cut through these.  Seems that folks like the 
>> title
>> > Localized Mobility Management.  I didn't retain the original numbers.
>> >
>> > Agreed upon requirements where there was no dissent:
>> > 1. Regional registration shall be introduced to minimize the signaling
>> > traffic to the home agent or correspondent nodes for intradomain 
>> mobility.
>>
>>I assume this applies to a "domain" being something larger than one IP 
>>subnet
>>and smaller than the whole Internet, since in the first case L2 does the 
>>work
>>and in the second case the existing HA does the work.
>>My question is whether it would be useful to constrain the size and other
>>attributes a bit more.
>>
>>For instance, is this "domain" within one adminstrative domain or not?
>>The answer affects what trust models make sense for securing things.
>>
>Just as an example in HMIPv6, we refer as "domain" the set of nodes that 
>are supported by the
>same MAP (or set of MAPs)...
>I am not sure whether this domain has to be owned by the same 
>administrative entity (probably not)...
>
>regards,
>Claude.
>
>
>--
>
>----------------------------------------
>Claude CASTELLUCCIA, INRIA Rhone-Alpes
>ph:  +33 4.76.61.52.15 (fax: 52.52)
>http://www.inrialpes.fr/planete/

------------------------------------------------------
Sagiv Draznin
System Engineer ,SP ,Mobile Tech
Cisco Systems Israel
  Herzliya Business Park
  4 Maskit St. P.O.Box 4032
  Herzliya Pituach, 46733, Israel
  Phone:+972-9-9700622
  Mobile:+972-54-972622
  FAX:    +972-9-9700019
  E.mail:sdraznin@cisco.com
   WEB:www.cisco.com
     ICQ #:93366338
-------------------------------------------------------
--=====================_1933380==_.ALT
Content-Type: text/html; charset="us-ascii"


Sorry for the "beginners question",

Someone can explain the main differences between GPRS and Mobile 
IP?



 At 09:39 AM 4/19/2001 +0200, you wrote:


Hello Erik, 



Erik Nordmark wrote: 


> OK.  Let's make another cut through
these.  Seems that folks like the title 

> Localized Mobility Management.  I didn't retain the original
numbers. 

> 

> Agreed upon requirements where there was no dissent: 

> 1. Regional registration shall be introduced to minimize the
signaling 

> traffic to the home agent or correspondent nodes for intradomain
mobility. 



I assume this applies to a "domain" being something larger than
one IP subnet 

and smaller than the whole Internet, since in the first case L2 does the
work 

and in the second case the existing HA does the work. 

My question is whether it would be useful to constrain the size and other


attributes a bit more. 



For instance, is this "domain" within one adminstrative domain
or not? 

The answer affects what trust models make sense for securing things.


 
Just as an example in HMIPv6, we refer as
"domain" the set of nodes that are supported by the 

same MAP (or set of MAPs)... 

I am not sure whether this domain has to be owned by the same
administrative entity (probably not)... 



regards, 

Claude. 






-- 

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




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

Sagiv Draznin

System
Engineer ,SP ,Mobile Tech

Cisco Systems Israel

 Herzliya Business Park

 4 Maskit St. P.O.Box 4032

 Herzliya Pituach, 46733, Israel

 Phone:+972-9-9700622

 Mobile:+972-54-972622

 FAX:    +972-9-9700019

 E.mail:sdraznin@cisco.com

  WEB:www.cisco.com

    ICQ #:93366338

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

--=====================_1933380==_.ALT--



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 19 10:50:05 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11956
	for ; Thu, 19 Apr 2001 10:50:04 -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 HAA29994;
	Thu, 19 Apr 2001 07:48: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 HAA03236;
	Thu, 19 Apr 2001 07:48:08 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JEkbK9006691
	for ; Thu, 19 Apr 2001 07:46:37 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3JEka2V006690
	for mobile-ip-dist; Thu, 19 Apr 2001 07:46: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JEkSK9006683
	for ; Thu, 19 Apr 2001 07:46:28 -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 HAA01114
	for ; Thu, 19 Apr 2001 07:46:28 -0700 (PDT)
Received: from cnr.kaist.ac.kr (cnr.kaist.ac.kr [143.248.147.103])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA09372
	for ; Thu, 19 Apr 2001 07:46:27 -0700 (PDT)
Received: from ns (cnrpc7.kaist.ac.kr [143.248.147.101])
	by cnr.kaist.ac.kr (8.9.3+Sun/8.9.1) with SMTP id XAA13449
	for ; Thu, 19 Apr 2001 23:46:48 +0900 (KST)
Message-ID: <004a01c0c8df$78030560$6593f88f@kaist.ac.kr>
From: "Yun Won Chung" 
To: 
References:  <4.3.2.7.2.20010419173903.00bb9590@kaspit.cisco.com>
Subject: Re: [mobile-ip] "beginners question"
Date: Thu, 19 Apr 2001 23:46:07 +0900
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0047_01C0C92A.E7A789E0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-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_0047_01C0C92A.E7A789E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: base64

R1BSUyB1c2VzIGl0cyBzcGVjaWZpYyByYWRpbyBhY2Nlc3MgdGVjaG5vbG9naWVzIGFuZCBtb2Jp
bGl0eSBtYW5hZ2VtZW50IHByb2NlZHVyZXMsDQpidXQgTW9iaWxlIElQIGlzIGxheWVyIDMgcHJv
dG9jb2wgYW5kIGluZGVwZW5kZW50IG9mIGxheWVyIDEgb3IgMiB0ZWNobm9sb2dpZXMuDQpTbywg
TW9iaWxlIElQIGNhbiBiZSB1c2VkIGluIGludGVybmV0d29ya2luZyBiZXR3ZWVuIGRpZmZlcmVu
dCBtb2JpbGUgc3lzdGVtcywNCnN1Y2ggYXMgR1BSUywgSU1ULTIwMDAsIFdMQU4sIGV0Yy4NCiAg
LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCiAgRnJvbTogRHJhem5pbiBTYWdpdiANCiAg
VG86IG1vYmlsZS1pcEBzdW5yb29mLmVuZy5zdW4uY29tIA0KICBTZW50OiBGcmlkYXksIEFwcmls
IDIwLCAyMDAxIDE6NDEgQU0NCiAgU3ViamVjdDogW21vYmlsZS1pcF0gImJlZ2lubmVycyBxdWVz
dGlvbiINCg0KDQogIFNvcnJ5IGZvciB0aGUgImJlZ2lubmVycyBxdWVzdGlvbiIsDQogIFNvbWVv
bmUgY2FuIGV4cGxhaW4gdGhlIG1haW4gZGlmZmVyZW5jZXMgYmV0d2VlbiBHUFJTIGFuZCBNb2Jp
bGUgSVA/DQoNCiAgIEF0IDA5OjM5IEFNIDQvMTkvMjAwMSArMDIwMCwgeW91IHdyb3RlOg0KDQog
ICAgSGVsbG8gRXJpaywgDQoNCiAgICBFcmlrIE5vcmRtYXJrIHdyb3RlOiANCg0KICAgICAgPiBP
Sy4gIExldCdzIG1ha2UgYW5vdGhlciBjdXQgdGhyb3VnaCB0aGVzZS4gIFNlZW1zIHRoYXQgZm9s
a3MgbGlrZSB0aGUgdGl0bGUgDQogICAgICA+IExvY2FsaXplZCBNb2JpbGl0eSBNYW5hZ2VtZW50
LiAgSSBkaWRuJ3QgcmV0YWluIHRoZSBvcmlnaW5hbCBudW1iZXJzLiANCiAgICAgID4gDQogICAg
ICA+IEFncmVlZCB1cG9uIHJlcXVpcmVtZW50cyB3aGVyZSB0aGVyZSB3YXMgbm8gZGlzc2VudDog
DQogICAgICA+IDEuIFJlZ2lvbmFsIHJlZ2lzdHJhdGlvbiBzaGFsbCBiZSBpbnRyb2R1Y2VkIHRv
IG1pbmltaXplIHRoZSBzaWduYWxpbmcgDQogICAgICA+IHRyYWZmaWMgdG8gdGhlIGhvbWUgYWdl
bnQgb3IgY29ycmVzcG9uZGVudCBub2RlcyBmb3IgaW50cmFkb21haW4gbW9iaWxpdHkuIA0KDQog
ICAgICBJIGFzc3VtZSB0aGlzIGFwcGxpZXMgdG8gYSAiZG9tYWluIiBiZWluZyBzb21ldGhpbmcg
bGFyZ2VyIHRoYW4gb25lIElQIHN1Ym5ldCANCiAgICAgIGFuZCBzbWFsbGVyIHRoYW4gdGhlIHdo
b2xlIEludGVybmV0LCBzaW5jZSBpbiB0aGUgZmlyc3QgY2FzZSBMMiBkb2VzIHRoZSB3b3JrIA0K
ICAgICAgYW5kIGluIHRoZSBzZWNvbmQgY2FzZSB0aGUgZXhpc3RpbmcgSEEgZG9lcyB0aGUgd29y
ay4gDQogICAgICBNeSBxdWVzdGlvbiBpcyB3aGV0aGVyIGl0IHdvdWxkIGJlIHVzZWZ1bCB0byBj
b25zdHJhaW4gdGhlIHNpemUgYW5kIG90aGVyIA0KICAgICAgYXR0cmlidXRlcyBhIGJpdCBtb3Jl
LiANCg0KICAgICAgRm9yIGluc3RhbmNlLCBpcyB0aGlzICJkb21haW4iIHdpdGhpbiBvbmUgYWRt
aW5zdHJhdGl2ZSBkb21haW4gb3Igbm90PyANCiAgICAgIFRoZSBhbnN3ZXIgYWZmZWN0cyB3aGF0
IHRydXN0IG1vZGVscyBtYWtlIHNlbnNlIGZvciBzZWN1cmluZyB0aGluZ3MuIA0KICAgICAgIA0K
ICAgIEp1c3QgYXMgYW4gZXhhbXBsZSBpbiBITUlQdjYsIHdlIHJlZmVyIGFzICJkb21haW4iIHRo
ZSBzZXQgb2Ygbm9kZXMgdGhhdCBhcmUgc3VwcG9ydGVkIGJ5IHRoZSANCiAgICBzYW1lIE1BUCAo
b3Igc2V0IG9mIE1BUHMpLi4uIA0KICAgIEkgYW0gbm90IHN1cmUgd2hldGhlciB0aGlzIGRvbWFp
biBoYXMgdG8gYmUgb3duZWQgYnkgdGhlIHNhbWUgYWRtaW5pc3RyYXRpdmUgZW50aXR5IChwcm9i
YWJseSBub3QpLi4uIA0KDQogICAgcmVnYXJkcywgDQogICAgQ2xhdWRlLiANCg0KDQoNCi0tIA0K
DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDbGF1ZGUgQ0FTVEVM
TFVDQ0lBLCBJTlJJQSBSaG9uZS1BbHBlcyAgDQpwaDogICszMyA0Ljc2LjYxLjUyLjE1IChmYXg6
IDUyLjUyKQ0KaHR0cDovL3d3dy5pbnJpYWxwZXMuZnIvcGxhbmV0ZS8NCiAgICAgIA0KDQogIC0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICBT
YWdpdiBEcmF6bmluDQogIFN5c3RlbSBFbmdpbmVlciAsU1AgLE1vYmlsZSBUZWNoDQogIENpc2Nv
IFN5c3RlbXMgSXNyYWVsDQogICBIZXJ6bGl5YSBCdXNpbmVzcyBQYXJrDQogICA0IE1hc2tpdCBT
dC4gUC5PLkJveCA0MDMyDQogICBIZXJ6bGl5YSBQaXR1YWNoLCA0NjczMywgSXNyYWVsDQogICBQ
aG9uZTorOTcyLTktOTcwMDYyMg0KICAgTW9iaWxlOis5NzItNTQtOTcyNjIyDQogICBGQVg6ICAg
ICs5NzItOS05NzAwMDE5DQogICBFLm1haWw6c2RyYXpuaW5AY2lzY28uY29tDQogICAgV0VCOnd3
dy5jaXNjby5jb20NCiAgICAgIElDUSAjOjkzMzY2MzM4DQogIC0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQo=

------=_NextPart_000_0047_01C0C92A.E7A789E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M
IDUuNTAuNDUyMi4xODAwIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFE
Pg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBmYWNlPSYjNDQ0MDQ7JiM0NzU0
ODsgc2l6ZT0yPkdQUlMgdXNlcyBpdHMgc3BlY2lmaWMgcmFkaW8gYWNjZXNzIHRlY2hub2xvZ2ll
cyBhbmQgDQptb2JpbGl0eSBtYW5hZ2VtZW50IHByb2NlZHVyZXMsPC9GT05UPjwvRElWPg0KPERJ
Vj48Rk9OVCBmYWNlPSYjNDQ0MDQ7JiM0NzU0ODsgc2l6ZT0yPmJ1dCBNb2JpbGUgSVAgaXMgbGF5
ZXIgMyBwcm90b2NvbCBhbmQgaW5kZXBlbmRlbnQgDQpvZiZuYnNwO2xheWVyIDEgb3IgMiB0ZWNo
bm9sb2dpZXMuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjNDQ0MDQ7JiM0NzU0ODsg
c2l6ZT0yPlNvLCBNb2JpbGUgSVAgY2FuIGJlIHVzZWQgaW4gaW50ZXJuZXR3b3JraW5nIGJldHdl
ZW4gDQpkaWZmZXJlbnQgbW9iaWxlIHN5c3RlbXMsPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBm
YWNlPSYjNDQ0MDQ7JiM0NzU0ODsgc2l6ZT0yPnN1Y2ggYXMgR1BSUywgSU1ULTIwMDAsIFdMQU4s
IGV0Yy48L0ZPTlQ+PC9ESVY+DQo8QkxPQ0tRVU9URSANCnN0eWxlPSJQQURESU5HLVJJR0hUOiAw
cHg7IFBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogIzAw
MDAwMCAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgPERJViBzdHlsZT0iRk9OVDog
MTBwdCAmIzQ0NDA0OyYjNDc1NDg7Ij4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvRElW
Pg0KICA8RElWIA0KICBzdHlsZT0iQkFDS0dST1VORDogI2U0ZTRlNDsgRk9OVDogMTBwdCAmIzQ0
NDA0OyYjNDc1NDg7OyBmb250LWNvbG9yOiBibGFjayI+PEI+RnJvbTo8L0I+IDxBIA0KICB0aXRs
ZT1zZHJhem5pbkBjaXNjby5jb20gaHJlZj0ibWFpbHRvOnNkcmF6bmluQGNpc2NvLmNvbSI+RHJh
em5pbiBTYWdpdjwvQT4gDQogIDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiAxMHB0ICYjNDQ0
MDQ7JiM0NzU0ODsiPjxCPlRvOjwvQj4gPEEgdGl0bGU9bW9iaWxlLWlwQHN1bnJvb2YuZW5nLnN1
bi5jb20gDQogIGhyZWY9Im1haWx0bzptb2JpbGUtaXBAc3Vucm9vZi5lbmcuc3VuLmNvbSI+bW9i
aWxlLWlwQHN1bnJvb2YuZW5nLnN1bi5jb208L0E+IA0KICA8L0RJVj4NCiAgPERJViBzdHlsZT0i
Rk9OVDogMTBwdCAmIzQ0NDA0OyYjNDc1NDg7Ij48Qj5TZW50OjwvQj4gRnJpZGF5LCBBcHJpbCAy
MCwgMjAwMSAxOjQxIEFNPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDEwcHQgJiM0NDQwNDsm
IzQ3NTQ4OyI+PEI+U3ViamVjdDo8L0I+IFttb2JpbGUtaXBdICJiZWdpbm5lcnMgDQogIHF1ZXN0
aW9uIjwvRElWPg0KICA8RElWPjxCUj48L0RJVj5Tb3JyeSBmb3IgdGhlICJiZWdpbm5lcnMgcXVl
c3Rpb24iLDxCUj5Tb21lb25lIGNhbiBleHBsYWluIHRoZSANCiAgbWFpbiBkaWZmZXJlbmNlcyBi
ZXR3ZWVuIEdQUlMgYW5kIE1vYmlsZSBJUD88QlI+PEJSPiZuYnNwO0F0IDA5OjM5IEFNIA0KICA0
LzE5LzIwMDEgKzAyMDAsIHlvdSB3cm90ZTo8QlI+DQogIDxCTE9DS1FVT1RFIGNpdGUgdHlwZT0i
Y2l0ZSI+SGVsbG8gRXJpaywgPEJSPjxCUj5FcmlrIE5vcmRtYXJrIHdyb3RlOiA8QlI+DQogICAg
PEJMT0NLUVVPVEUgY2l0ZSB0eXBlPSJjaXRlIj4mZ3Q7IE9LLiZuYnNwOyBMZXQncyBtYWtlIGFu
b3RoZXIgY3V0IHRocm91Z2ggDQogICAgICB0aGVzZS4mbmJzcDsgU2VlbXMgdGhhdCBmb2xrcyBs
aWtlIHRoZSB0aXRsZSA8QlI+Jmd0OyBMb2NhbGl6ZWQgTW9iaWxpdHkgDQogICAgICBNYW5hZ2Vt
ZW50LiZuYnNwOyBJIGRpZG4ndCByZXRhaW4gdGhlIG9yaWdpbmFsIG51bWJlcnMuIDxCUj4mZ3Q7
IDxCUj4mZ3Q7IA0KICAgICAgQWdyZWVkIHVwb24gcmVxdWlyZW1lbnRzIHdoZXJlIHRoZXJlIHdh
cyBubyBkaXNzZW50OiA8QlI+Jmd0OyAxLiBSZWdpb25hbCANCiAgICAgIHJlZ2lzdHJhdGlvbiBz
aGFsbCBiZSBpbnRyb2R1Y2VkIHRvIG1pbmltaXplIHRoZSBzaWduYWxpbmcgPEJSPiZndDsgDQog
ICAgICB0cmFmZmljIHRvIHRoZSBob21lIGFnZW50IG9yIGNvcnJlc3BvbmRlbnQgbm9kZXMgZm9y
IGludHJhZG9tYWluIG1vYmlsaXR5LiANCiAgICAgIDxCUj48QlI+SSBhc3N1bWUgdGhpcyBhcHBs
aWVzIHRvIGEgImRvbWFpbiIgYmVpbmcgc29tZXRoaW5nIGxhcmdlciB0aGFuIA0KICAgICAgb25l
IElQIHN1Ym5ldCA8QlI+YW5kIHNtYWxsZXIgdGhhbiB0aGUgd2hvbGUgSW50ZXJuZXQsIHNpbmNl
IGluIHRoZSBmaXJzdCANCiAgICAgIGNhc2UgTDIgZG9lcyB0aGUgd29yayA8QlI+YW5kIGluIHRo
ZSBzZWNvbmQgY2FzZSB0aGUgZXhpc3RpbmcgSEEgZG9lcyB0aGUgDQogICAgICB3b3JrLiA8QlI+
TXkgcXVlc3Rpb24gaXMgd2hldGhlciBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gY29uc3RyYWluIHRo
ZSBzaXplIA0KICAgICAgYW5kIG90aGVyIDxCUj5hdHRyaWJ1dGVzIGEgYml0IG1vcmUuIDxCUj48
QlI+Rm9yIGluc3RhbmNlLCBpcyB0aGlzIA0KICAgICAgImRvbWFpbiIgd2l0aGluIG9uZSBhZG1p
bnN0cmF0aXZlIGRvbWFpbiBvciBub3Q/IDxCUj5UaGUgYW5zd2VyIGFmZmVjdHMgDQogICAgICB3
aGF0IHRydXN0IG1vZGVscyBtYWtlIHNlbnNlIGZvciBzZWN1cmluZyB0aGluZ3MuIA0KICAgIDxC
Uj4mbmJzcDs8L0JMT0NLUVVPVEU+SnVzdCBhcyBhbiBleGFtcGxlIGluIEhNSVB2Niwgd2UgcmVm
ZXIgYXMgImRvbWFpbiIgDQogICAgdGhlIHNldCBvZiBub2RlcyB0aGF0IGFyZSBzdXBwb3J0ZWQg
YnkgdGhlIDxCUj5zYW1lIE1BUCAob3Igc2V0IG9mIE1BUHMpLi4uIA0KICAgIDxCUj5JIGFtIG5v
dCBzdXJlIHdoZXRoZXIgdGhpcyBkb21haW4gaGFzIHRvIGJlIG93bmVkIGJ5IHRoZSBzYW1lIA0K
ICAgIGFkbWluaXN0cmF0aXZlIGVudGl0eSAocHJvYmFibHkgbm90KS4uLiA8QlI+PEJSPnJlZ2Fy
ZHMsIDxCUj5DbGF1ZGUuIA0KICAgIDxCUj48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldywgQ291cmll
ciI+PEJSPjwvRk9OVD48QlI+PFBSRT4tLSANCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLQ0KQ2xhdWRlIENBU1RFTExVQ0NJQSwgSU5SSUEgUmhvbmUtQWxwZXMmbmJz
cDsgDQpwaDombmJzcDsgKzMzIDQuNzYuNjEuNTIuMTUgKGZheDogNTIuNTIpDQo8QSBocmVmPSJo
dHRwOi8vd3d3LmlucmlhbHBlcy5mci9wbGFuZXRlLyI+aHR0cDovL3d3dy5pbnJpYWxwZXMuZnIv
cGxhbmV0ZS88L0E+PC9QUkU+PEZPTlQgDQogICAgZmFjZT0iQ291cmllciBOZXcsIENvdXJpZXIi
PjwvRk9OVD4mbmJzcDsgPC9CTE9DS1FVT1RFPjxCUj48Rk9OVCANCiAgZmFjZT0iQ29taWMgU2Fu
cyBNUyIgDQogIHNpemU9Mj48ST4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS08QlI+PC9GT05UPjxGT05UIA0KICBmYWNlPSJDb21pYyBTYW5zIE1T
IiBjb2xvcj0jMDAwMGZmPlNhZ2l2IERyYXpuaW48QlI+PC9JPjwvRk9OVD48Rk9OVCANCiAgZmFj
ZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzAwMDBmZiBzaXplPTI+U3lzdGVtIEVuZ2luZWVyICxT
UCAsTW9iaWxlIA0KICBUZWNoPEJSPjwvRk9OVD5DaXNjbyBTeXN0ZW1zIElzcmFlbDxCUj4mbmJz
cDtIZXJ6bGl5YSBCdXNpbmVzcyBQYXJrPEJSPiZuYnNwOzQgDQogIE1hc2tpdCBTdC4gUC5PLkJv
eCA0MDMyPEJSPiZuYnNwO0hlcnpsaXlhIFBpdHVhY2gsIDQ2NzMzLCANCiAgSXNyYWVsPEJSPiZu
YnNwO1Bob25lOis5NzItOS05NzAwNjIyPEJSPiZuYnNwO01vYmlsZTorOTcyLTU0LTk3MjYyMjxC
Uj4mbmJzcDtGQVg6Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICArOTcyLTktOTcwMDAxOTxCUj4mbmJz
cDtFLm1haWw6c2RyYXpuaW5AY2lzY28uY29tPEJSPiZuYnNwOyANCiAgV0VCOnd3dy5jaXNjby5j
b208QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IElDUSAjOjkzMzY2MzM4PEJSPjxGT05UIA0KICBzaXpl
PTQ+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LTwvRk9OVD4gDQo8L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4NCg==

------=_NextPart_000_0047_01C0C92A.E7A789E0--



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 19 10:57:41 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12084
	for ; Thu, 19 Apr 2001 10:57: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 HAA07310;
	Thu, 19 Apr 2001 07:56:37 -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 HAA14893;
	Thu, 19 Apr 2001 07:56:31 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JEtMK9006717
	for ; Thu, 19 Apr 2001 07:55:23 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3JEtMiQ006716
	for mobile-ip-dist; Thu, 19 Apr 2001 07:55: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JEtDK9006709
	for ; Thu, 19 Apr 2001 07:55:14 -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 HAA15796
	for ; Thu, 19 Apr 2001 07:55:13 -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 JAA09227
	for ; Thu, 19 Apr 2001 09:40:32 -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 JAA14334;
	Thu, 19 Apr 2001 09:55:04 -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 f3JEt3e00548;
	Thu, 19 Apr 2001 09:55:03 -0500 (CDT)
Message-ID: <3ADEEDE9.77B6BAAA@usa.alcatel.com>
Date: Thu, 19 Apr 2001 09:53:49 -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
CC: neumiller@telocity.com
Subject: Re: [mobile-ip] Design teams for mobileip--(sharif)
References: <200104191249.IAA07240@newdev.harvard.edu>
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 suggest that RFC 2418 be amended (as is already followed by many WGs)
in view of the excessive use of DT's (making IETF look like ETSI, CCITT, etc.)
to mandate a WG approval of each DT and its closedness or opennes
and bring penalties for WG chairs who do not follow the rules
and also
mandatory vote of confidence in IETF meetings for WG chairs and ADs.

Food for thought.

Scott Bradner wrote:

> note that teh output of design teams is input for working groups - anything
> that a design team does can be modified or undone by the WG
>
> Scott

--
Behcet



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 19 11:16:13 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12513
	for ; Thu, 19 Apr 2001 11:16:12 -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 IAA24487;
	Thu, 19 Apr 2001 08:15: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 IAA10577;
	Thu, 19 Apr 2001 08:15:02 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JFDSK9006777
	for ; Thu, 19 Apr 2001 08:13:29 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3JFDSXc006776
	for mobile-ip-dist; Thu, 19 Apr 2001 08:13: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JFDJK9006768
	for ; Thu, 19 Apr 2001 08:13:19 -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 IAA10092
	for ; Thu, 19 Apr 2001 08:13:18 -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 IAA22436
	for ; Thu, 19 Apr 2001 08:13:18 -0700 (PDT)
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 KAA18736
	for ; Thu, 19 Apr 2001 10:13:17 -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 f3JFDLn19310
	for ; Thu, 19 Apr 2001 10:13:21 -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 f3JFD9710527
	for ; Thu, 19 Apr 2001 10:13:09 -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 f3JFCsw21519
	for ; Thu, 19 Apr 2001 10:12:54 -0500 (CDT)
Message-ID: <3ADF0076.CBE1B6FF@usa.alcatel.com>
Date: Thu, 19 Apr 2001 10:12:54 -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] "beginners question"
References:  <4.3.2.7.2.20010419173903.00bb9590@kaspit.cisco.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

In Mobip, the mobile node is allocated a fixed home address and only the
traffix destined to the mobile is tunneled. The home agent is fixed.
In GPRS, the mobile node can be allocated a fixed address or dynamic
address, the traffic to and from the mobile are tunneled on both
directions.  The GGSN can be located at home or in visiting network.



Draznin Sagiv wrote:

>  Sorry for the "beginners question",
> Someone can explain the main differences between GPRS and Mobile IP?
>
>  At 09:39 AM 4/19/2001 +0200, you wrote:
>
>> Hello Erik,
>>
>> Erik Nordmark wrote:
>>
>> > > OK.  Let's make another cut through these.  Seems that folks like
>> > the title
>> > > Localized Mobility Management.  I didn't retain the original
>> > numbers.
>> > >
>> > > Agreed upon requirements where there was no dissent:
>> > > 1. Regional registration shall be introduced to minimize the
>> > signaling
>> > > traffic to the home agent or correspondent nodes for intradomain
>> > mobility.
>> >
>> > I assume this applies to a "domain" being something larger than one
>> > IP subnet
>> > and smaller than the whole Internet, since in the first case L2
>> > does the work
>> > and in the second case the existing HA does the work.
>> > My question is whether it would be useful to constrain the size and
>> > other
>> > attributes a bit more.
>> >
>> > For instance, is this "domain" within one adminstrative domain or
>> > not?
>> > The answer affects what trust models make sense for securing
>> > things.
>>
>> Just as an example in HMIPv6, we refer as "domain" the set of nodes
>> that are supported by the
>> same MAP (or set of MAPs)...
>> I am not sure whether this domain has to be owned by the same
>> administrative entity (probably not)...
>>
>> regards,
>> Claude.
>>
>>
>>
>> --
>>
>> ----------------------------------------
>> Claude CASTELLUCCIA, INRIA Rhone-Alpes
>> ph:  +33 4.76.61.52.15 (fax: 52.52)
>> http://www.inrialpes.fr/planete/
>>
>>
>
>
> ------------------------------------------------------
> Sagiv Draznin
> System Engineer ,SP ,Mobile Tech
> Cisco Systems Israel
>  Herzliya Business Park
>  4 Maskit St. P.O.Box 4032
>  Herzliya Pituach, 46733, Israel
>  Phone:+972-9-9700622
>  Mobile:+972-54-972622
>  FAX:    +972-9-9700019
>  E.mail:sdraznin@cisco.com
>   WEB:www.cisco.com
>     ICQ #:93366338
> -------------------------------------------------------



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 19 11:32:39 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12855
	for ; Thu, 19 Apr 2001 11:32: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 IAA12900;
	Thu, 19 Apr 2001 08:31: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 IAA22702;
	Thu, 19 Apr 2001 08:31:19 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JFTbK9006808
	for ; Thu, 19 Apr 2001 08:29:37 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3JFTbUJ006807
	for mobile-ip-dist; Thu, 19 Apr 2001 08:29: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JFTTK9006800
	for ; Thu, 19 Apr 2001 08:29:29 -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 IAA08155
	for ; Thu, 19 Apr 2001 08:29:29 -0700 (PDT)
Message-Id: <200104191529.IAA08155@heliopolis.eng.sun.com>
Date: Thu, 19 Apr 2001 08:29:29 -0700 (PDT)
From: James Kempf 
Subject: Re: [mobile-ip] Revised Localized Mobility Management Requirements
To: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: zBXLSarwngrkcxb+SOuz/Q==
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 Claude,

>> > OK.  Let's make another cut through these.  Seems that folks like the title
>> > Localized Mobility Management.  I didn't retain the original numbers.
>> >
>> > Agreed upon requirements where there was no dissent:
>> > 1. Regional registration shall be introduced to minimize the signaling
>> > traffic to the home agent or correspondent nodes for intradomain mobility.
>>
>> I assume this applies to a "domain" being something larger than one IP subnet
>> and smaller than the whole Internet, since in the first case L2 does the work
>> and in the second case the existing HA does the work.
>> My question is whether it would be useful to constrain the size and other
>> attributes a bit more.
>>
>> For instance, is this "domain" within one adminstrative domain or not?
>> The answer affects what trust models make sense for securing things.
>>
>
>Just as an example in HMIPv6, we refer as "domain" the set of nodes that are
>supported by the
>same MAP (or set of MAPs)...
>I am not sure whether this domain has to be owned by the same administrative
>entity (probably not)...
>

There are security implications of LMM. When the mobile node switches
between one LMM authentication domain and another, it will probably
have to go through  some kind of authentication exchange to change
its regional care of address. So that suggests to me that it will
probably be owned by the same administrative entity, at least for
the top level. If the LMM protocol supports multiple levels of hierarchy
(a requirement that I think is important), there can be subLMM agents
that sit under the top agent, so again they would be under the same
administrative entity.

Given the authentication requirement, I have a difficult time seeing
how the "domain" could not be under the same administrative entity.
Can you be more specific about what you had in mind?

		jak



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 19 12:00:30 2001
Received: from mercury.Sun.COM ([192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13390
	for ; Thu, 19 Apr 2001 12:00:29 -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 IAA15223;
	Thu, 19 Apr 2001 08:55: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 IAA19423;
	Thu, 19 Apr 2001 08:47:48 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JFjxK9006870
	for ; Thu, 19 Apr 2001 08:46:00 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3JFjx1n006869
	for mobile-ip-dist; Thu, 19 Apr 2001 08:45: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JFjoK9006862
	for ; Thu, 19 Apr 2001 08:45:51 -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 IAA24017
	for ; Thu, 19 Apr 2001 08:45:50 -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 IAA14618
	for ; Thu, 19 Apr 2001 08:45:50 -0700 (PDT)
Received: from msubbara-u10.cisco.com (msubbara-u10.cisco.com [64.102.66.20])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA23799;
	Thu, 19 Apr 2001 08:45:50 -0700 (PDT)
Received: (msubbara@localhost) by msubbara-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA26973; Thu, 19 Apr 2001 11:45:00 -0400 (EDT)
Date: Thu, 19 Apr 2001 11:45:00 -0400
From: Madhavi Subbarao 
To: mobile-ip@sunroof.eng.sun.com
Cc: "'proberts@megisto.com'" ,
        "'basavaraj.patil@nokia.com'" ,
        "Shahrier, Sharif M." 
Subject: [mobile-ip] Re: mobile-ip] failure detection and recovery issues in MIPv6
Message-ID: <20010419114500.A26969@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 Sharif.Shahrier@InterDigital.com on Wed, Apr 18, 2001 at 04:14:27PM -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 Sharif,

The need for redundancy is not specific to MIPv6, and an important
issue for MIP deployment in general.  We will be submitting an I-D on
general MIP Home Agent Redundancy very soon...hopefully, next week.

Thanks,
Madhavi

On Wed, Apr 18, 2001 at 04:14:27PM -0400, Shahrier, Sharif M. wrote:
> Folks,
> 
> 	I would like to solicit some comments from the WG regarding the
> issue of "failure detection" and "failure recovery". So far, I have had one
> comment, thus any further comments would be very valuable to us in deciding
> whether or not to persue this work.
> 
> I would like to discuss a couple of issues relating to the "Mobility Support
> in IPv6" draft v13.0. It is regarding to failure/reconfiguration of home
> agent router while the MN is away from its home agent. It is stated that the
> dynamic home agent address discovey procedure was to be used to dynamically
> discover the IP address of a home agent. 
> As an alternative, a dual home agent router system can be used, to form a
> 2MR system. One of the routers is the "shadow" of the other and is only used
> as backup. If the "primary" one fails or is reconfigured, the "shadow"
> router could be switched into operation. From my previous knowledge, 2MR
> systems are quite fail-safe and have been successfully deployed in many
> fault tolerant systems. 
> I was wondering how people felt about the 2MR approach for failure detection
> and recovery.
> Another problem that I didn't see being discussed in the draft is the
> failure of home agent's link when the MN is away from its home agent. Link
> failure or reconfiguration is just as important as home agent failure. I
> believe  that this needs to be explicitly spelled out  in the draft.
> Could people comment on this as well.
> There are other issues regarding fault tolerance as well.
> Now regarding these two issues, I could either:
> * Produce a framework draft and ask it be rated to a mobileip draft at the
> next meeting. This will allow people time to investigate the fault tolerance
> problem within a mobile network and come up with ideas.
> * Produce a complete solutions draft and ask it to be rated to mobileip
> draft, and merged with the current MIPv6 spec.
> * A combination of the two.
> Again, Thanks in advance for your comments.
> Sharif.


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 19 12:01:41 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13471
	for ; Thu, 19 Apr 2001 12:01: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 JAA10672;
	Thu, 19 Apr 2001 09:00: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 JAA27005;
	Thu, 19 Apr 2001 09:00:31 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JFxDK9006897
	for ; Thu, 19 Apr 2001 08:59:13 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3JFxCxU006896
	for mobile-ip-dist; Thu, 19 Apr 2001 08:59: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JFx4K9006889
	for ; Thu, 19 Apr 2001 08:59: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 IAA17574
	for ; Thu, 19 Apr 2001 08:59:04 -0700 (PDT)
Message-Id: <200104191559.IAA17574@heliopolis.eng.sun.com>
Date: Thu, 19 Apr 2001 08:59:04 -0700 (PDT)
From: James Kempf 
Subject: Re: [mobile-ip] Revised Localized Mobility Management Requirements
To: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: CKEDXEAxMAoVhOxmBH8nYQ==
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: 

Tom,


>Firstly, a good design principle to limit the size of a "domain" is to
>think how fast handoffs this "domain" would be able to provide. In a
>humongous hierarchy with slow links between the elements of the hierarchy,
>even the localized mobility management may not provide reasonably fast
>handoffs. The size of the domain is also linked to the number of MNs the
>system must support. By splitting mega-domains, one would also gain some
>scalability for the entire system of domains, but that is merely a network
>design issue, perhaps not that tightly related to protocol design.
>

Yes, this is another reason why I think that the design must support
arbitrary levels of hierarchy. Service providers need the flexibility
to do network engineering so they can optimally lay out their
routing.

		jak




From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 19 12:26:19 2001
Received: from mercury.Sun.COM ([192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13932
	for ; Thu, 19 Apr 2001 12:26:18 -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 JAA24968;
	Thu, 19 Apr 2001 09:14: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 JAA18179;
	Thu, 19 Apr 2001 09:13:23 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JGCGK9006937
	for ; Thu, 19 Apr 2001 09:12:16 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3JGCGXJ006936
	for mobile-ip-dist; Thu, 19 Apr 2001 09:12: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JGC7K9006929
	for ; Thu, 19 Apr 2001 09:12:07 -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 JAA17945
	for ; Thu, 19 Apr 2001 09:12:07 -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 JAA29460
	for ; Thu, 19 Apr 2001 09:12:07 -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 LAA15344
	for ; Thu, 19 Apr 2001 11:12:19 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Thu, 19 Apr 2001 11:11:45 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Thu, 19 Apr 2001 11:11:34 -0500
Message-ID: <85AA7486A2C1D411BCA20000F8073E4301EF0592@crchy271.us.nortel.com>
From: "Glenn Morrow" 
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Design teams for mobileip--(sharif)
Date: Thu, 19 Apr 2001 11:11:32 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0C8EB.667901D0"
Sender: owner-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_01C0C8EB.667901D0
Content-Type: text/plain;
	charset="iso-8859-1"

I agree 100% with you Jim - something stinks in the MIP WG. This is why it
has been going on since 1993 with minor progress.

-----Original Message-----
From: Jim Bound [mailto:seamus@bit-net.com]
Sent: Tuesday, April 17, 2001 2:29 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Design teams for mobileip--(sharif)


You did not respond to my previous issue with your appeal regarding 3GPP
et al which I am not clear is valid or warranted.  But this one may have
some meat here is why.

I am on two design teams to work problems and get back to the working
groups here in the IETF (which ones are not relevent).  We formed these
teams "for" the working groups and asked for volunteers.  The list is
closed because the "design team" wanted it closed and the working group
does not care.

But in the case where a team is formed and the management team in the IETF
did not ask for volunteers from the working group then that is a closed
process because when the management team makes such decisions it is a
formal process.  As opposed to working group members going off and solving
a problem which is 'ad hoc'.  To then close that formal list is insult to
injury at a minimum to get input from the working group at a minimum.

Then the other problem with this for your appeal is as follows.  Why were
certain people put on this closed team and not others.  What
"discrimination" was used to determine who was part of this formal
process.  Was it fair discrimination to the working group as a whole?

This is a classic example of why the good-ole-boy-network needs fixing.

It is a bad precedent and I believe could potentially cause a legal
problem to the IETF which is the last thing we need here.  In a private
company,  private entity, or academic/research centers this is done often
and valid, but this is the IETF the open process for open standards.

I also understand that authors are not part of the design teams?  How was
that discrimination arrived at and seems not wise to me?

But then maybe there are perfect reasonable explanations for the above?

regards,
/jim

On Tue, 17 Apr 2001, Phil Neumiller wrote:

> I guess this is another item to add to my appeal.  I believe this is
> setting a bad precedent for the IETF.
> 
> Thanks,
> 
> Phil
> ----- Original Message -----
> From: "Phil Roberts" 
> To: 
> Sent: Tuesday, April 17, 2001 12:08 PM
> Subject: RE: [mobile-ip] Design teams for mobileip--(sharif)
> 
> 
> > Both fast handoff lists were open to begin with but due to some concerns
> > about the ability to make progress the ADs asked us to close them, so we
> > did.  The archives will be made public when the teams are done.
Versions of
> > each draft have been published and you are welcome to comment on them on
the
> > main list.
> >
> 
> >
> 
> 


------_=_NextPart_001_01C0C8EB.667901D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [mobile-ip] Design teams for mobileip--(sharif)




I agree 100% with you Jim - something stinks in the =
MIP WG. This is why it has been going on since 1993 with minor =
progress.



-----Original Message-----

From: Jim Bound [mailto:seamus@bit-net.com]=


Sent: Tuesday, April 17, 2001 2:29 PM

To: mobile-ip@sunroof.eng.sun.com

Subject: Re: [mobile-ip] Design teams for =
mobileip--(sharif)






You did not respond to my previous issue with your =
appeal regarding 3GPP

et al which I am not clear is valid or =
warranted.  But this one may have

some meat here is why.




I am on two design teams to work problems and get =
back to the working

groups here in the IETF (which ones are not =
relevent).  We formed these

teams "for" the working groups and asked =
for volunteers.  The list is

closed because the "design team" wanted it =
closed and the working group

does not care.




But in the case where a team is formed and the =
management team in the IETF

did not ask for volunteers from the working group =
then that is a closed

process because when the management team makes such =
decisions it is a

formal process.  As opposed to working group =
members going off and solving

a problem which is 'ad hoc'.  To then close =
that formal list is insult to

injury at a minimum to get input from the working =
group at a minimum.




Then the other problem with this for your appeal is =
as follows.  Why were

certain people put on this closed team and not =
others.  What

"discrimination" was used to determine who =
was part of this formal

process.  Was it fair discrimination to the =
working group as a whole?




This is a classic example of why the =
good-ole-boy-network needs fixing.




It is a bad precedent and I believe could potentially =
cause a legal

problem to the IETF which is the last thing we need =
here.  In a private

company,  private entity, or academic/research =
centers this is done often

and valid, but this is the IETF the open process for =
open standards.




I also understand that authors are not part of the =
design teams?  How was

that discrimination arrived at and seems not wise to =
me?




But then maybe there are perfect reasonable =
explanations for the above?




regards,

/jim




On Tue, 17 Apr 2001, Phil Neumiller wrote:




> I guess this is another item to add to my =
appeal.  I believe this is

> setting a bad precedent for the IETF.

> 

> Thanks,

> 

> Phil

> ----- Original Message -----

> From: "Phil Roberts" =
<PRoberts@MEGISTO.com>

> To: =
<mobile-ip@sunroof.eng.sun.com>

> Sent: Tuesday, April 17, 2001 12:08 PM

> Subject: RE: [mobile-ip] Design teams for =
mobileip--(sharif)

> 

> 

> > Both fast handoff lists were open to begin =
with but due to some concerns

> > about the ability to make progress the ADs =
asked us to close them, so we

> > did.  The archives will be made =
public when the teams are done.  Versions of

> > each draft have been published and you are =
welcome to comment on them on the

> > main list.

> >

> 

> >

> 

> 





------_=_NextPart_001_01C0C8EB.667901D0--


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 19 12:35:06 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14086
	for ; Thu, 19 Apr 2001 12:35:05 -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 JAA05054;
	Thu, 19 Apr 2001 09:28:09 -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 JAA29995;
	Thu, 19 Apr 2001 09:27:57 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JGQJK9006994
	for ; Thu, 19 Apr 2001 09:26:19 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3JGQIMO006993
	for mobile-ip-dist; Thu, 19 Apr 2001 09:26:18 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JGQ9K9006986
	for ; Thu, 19 Apr 2001 09:26:10 -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 JAA21040
	for ; Thu, 19 Apr 2001 09:26:09 -0700 (PDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06687
	for ; Thu, 19 Apr 2001 09:26:04 -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.9.3/8.9.1) with ESMTP id JAA14830;
	Thu, 19 Apr 2001 09:24:42 -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 AEI04613;
	Thu, 19 Apr 2001 09:26:00 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA10057; Thu, 19 Apr 2001 09:26:00 -0700 (PDT)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15071.4503.914618.357282@thomasm-u1.cisco.com>
Date: Thu, 19 Apr 2001 09:25:59 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Cc: Phil Roberts 
Subject: [mobile-ip] Revised Localized Mobility Management Requirements
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

So I've got a nagging question:

Why is RR and the forward tunnel aspect of FMIP
considered to be different problems? They both
involve registering with an AR which acts like a
home agent for the MN.

Wouldn't it be better to have exactly *one* set of
requirements and protocol of how a MN attaches to
a local home agent, and let FMIP just define the
interaction (or not, IMO) between the old AR and
the new AR?

If nothing else, the combinatorics of
MIP/HMIP/FMIP here are pretty hard to get my head
around.

		Mike

Phil Roberts writes:
 > OK.  Let's make another cut through these.  Seems that folks like the title
 > Localized Mobility Management.  I didn't retain the original numbers.
 > 
 > Agreed upon requirements where there was no dissent:
 > 1. Regional registration shall be introduced to minimize the signaling
 > traffic to the home agent or correspondent nodes for intradomain mobility.
 > 2. Regional registration shall be secure against malicious behavior from
 > visiting mobiles
 > 
 > That's about it.
 > 
 > There was only minor dissent on these:
 > 3. Connectivity to the mobiles shall not be interrupted in the presence of
 > the failure of regional registration agents.
 > [Only comment was that disruption should be minimized.  I'd like to get a
 > sense from the working group whether it feels that this one should be
 > restated]
 > 4. Regional registration shall support fast handoffs.
 > [Several comments that it should be compatible and no dependencies between
 > the specs, so how about: Regional registration shall be compatible with fast
 > handoffs.]
 > 5. Regional registration shall scale to support millions of nodes in a
 > visited network.
 > [One comment that this was too broad, so I'd request someone to rephrase it
 > in a better way]
 > 
 > Mostly disagreement on these:
 > 6. .  Regional registration shall not introduce new overhead on links
 > between the mobile and the local mobility management agents.
 > [Comments were that it should be minimized, or that it was ok if it meant no
 > more overhead than a binding update.  Here's my attempt at a revision: local
 > mobility management shall not introduce new messages to notify the LMM
 > agents of a move.  There is a disagreement as to whether adding additional
 > over the air bytes is an issue, and if it is whether it's this WG's
 > responsibility to solve it]
 > 7. Regional registration shall allow multiple levels of hierarchy.
 > [There was some strong disagreement on this.  Perhaps Jim or Karim could
 > start a separate thread to track this one down?]
 > 8. Regional registration shall not require changes ot the MN, the home
 > agent, or correspondent nodes.
 > [Many thought requiring no change to the MN was not doable, but the home
 > agent or CN should be unchanged.  So I propose we just rewrite this as:
 > Regional registration shall not require changes to the home agent or
 > correspondent nodes.]
 > 9. Regional registration shall not introduce host routes in routing tables.
 > [Didn't get much positive on this one and got the sense folks don't want to
 > rathole on a host routing discussion.  I propose we drop this.]  
 > 
 > We also had request for some new requirements:
 > 10. LMM should provide the same level of mobility mgmt support as in the
 > basic MIP v6 spec.  MM fns supported in MIP v6 must not be reduced.
 > [Some positive feedback on this, shall we keep it?]
 > 11. LMM must interwork with MIPv6, IPv6, and the proposed mechanisms for SA
 > establishment
 > [One comment that this was stating the obvious.  Shall we keep it?]
 > 
 > 12. LMM should be optimized for mobile-to-mobile.
 > [Never really understood what this requirement was supposed to be.  Got
 > similar feedback from others.  I propose we drop it.]
 > 
 > Received no feedback on the following proposed requirements.  Anybody want
 > to keep these?
 > 13. Should minimize # of network nodes affected by HO signalling.
 > 14. Should support autoconfig.
 > 15. Should simplify network design and provisioning.
 > 
 > 
 > 


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 19 12:45:27 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14257
	for ; Thu, 19 Apr 2001 12:45: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 JAA18055;
	Thu, 19 Apr 2001 09:41: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 JAA03468;
	Thu, 19 Apr 2001 09:41:36 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JGdZK9007019
	for ; Thu, 19 Apr 2001 09:39:35 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3JGdYPs007018
	for mobile-ip-dist; Thu, 19 Apr 2001 09:39:34 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JGdPK9007011
	for ; Thu, 19 Apr 2001 09:39:26 -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 JAA05013
	for ; Thu, 19 Apr 2001 09:39:25 -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 LAA12807
	for ; Thu, 19 Apr 2001 11:24:53 -0600 (MDT)
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 LAA14895
	for ; Thu, 19 Apr 2001 11:39:23 -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 f3JGdWo23881
	for ; Thu, 19 Apr 2001 11:39:32 -0500 (CDT)
Message-ID: <3ADF065F.DE947535@usa.alcatel.com>
Date: Thu, 19 Apr 2001 11:38:09 -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] Design teams for mobileip--(sharif)
References: <85AA7486A2C1D411BCA20000F8073E4301EF0592@crchy271.us.nortel.com>
Content-Type: multipart/alternative;
 boundary="------------431195800856893E251E30B2"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

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

In my humble opinion MIP WG made strategic mistakes by
-not including paging into its charter (an area in which progress could
have been made in a reasonable amount of time)
-by including fast handover into the charter and getting into the
vicious circle between two mipv4 proposals rather than spinning it off
to Seamoby which stands for Seamless mobility but tries to do the paging
and context transfer.
- and (you can add others here)...

Glenn Morrow wrote:

>
>
> I agree 100% with you Jim - something stinks in the MIP WG. This is
> why it has been going on since 1993 with minor progress.
>

--
Behcet

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



In my humble opinion MIP WG made strategic mistakes by

-not including paging into its charter (an area in which progress could
have been made in a reasonable amount of time)

-by including fast handover into the charter and getting into the vicious
circle between two mipv4 proposals rather than spinning it off to Seamoby
which stands for Seamless mobility but tries to do the paging and context
transfer.

- and (you can add others here)...

Glenn Morrow wrote:

 

I agree 100% with you Jim - something stinks in the MIP
WG. This is why it has been going on since 1993 with minor progress.

 

--

Behcet

--------------431195800856893E251E30B2--



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 19 13:25:26 2001
Received: from mercury.Sun.COM ([192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14852
	for ; Thu, 19 Apr 2001 13:25: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 KAA00783;
	Thu, 19 Apr 2001 10:24:36 -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 KAA13980;
	Thu, 19 Apr 2001 10:20:19 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JHIUK9007068
	for ; Thu, 19 Apr 2001 10:18:30 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3JHIUP1007067
	for mobile-ip-dist; Thu, 19 Apr 2001 10:18: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JHILK9007060
	for ; Thu, 19 Apr 2001 10:18:21 -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 KAA16645
	for ; Thu, 19 Apr 2001 10:18:20 -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 KAA07808
	for ; Thu, 19 Apr 2001 10:18:20 -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 MAA00630
	for ; Thu, 19 Apr 2001 12:18:37 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Thu, 19 Apr 2001 12:12:42 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Thu, 19 Apr 2001 12:18:01 -0500
Message-ID: <85AA7486A2C1D411BCA20000F8073E4301EF067D@crchy271.us.nortel.com>
From: "Glenn Morrow" 
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Revised Localized Mobility Management Requirement s
Date: Thu, 19 Apr 2001 12:18:00 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0C8F4.AF83F4D0"
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_01C0C8F4.AF83F4D0
Content-Type: text/plain;
	charset="iso-8859-1"

I would recommend using the term domain to mean administrative domain and
not try to overload it.

-----Original Message-----
From: Claude Castelluccia [mailto:claude.castelluccia@inrialpes.fr]
Sent: Thursday, April 19, 2001 2:40 AM
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Revised Localized Mobility Management Requirements


Hello Erik, 

Erik Nordmark wrote: 


> OK.  Let's make another cut through these.  Seems that folks like the
title 
> Localized Mobility Management.  I didn't retain the original numbers. 
> 
> Agreed upon requirements where there was no dissent: 
> 1. Regional registration shall be introduced to minimize the signaling 
> traffic to the home agent or correspondent nodes for intradomain mobility.


I assume this applies to a "domain" being something larger than one IP
subnet 
and smaller than the whole Internet, since in the first case L2 does the
work 
and in the second case the existing HA does the work. 
My question is whether it would be useful to constrain the size and other 
attributes a bit more. 


For instance, is this "domain" within one adminstrative domain or not? 
The answer affects what trust models make sense for securing things. 
 

Just as an example in HMIPv6, we refer as "domain" the set of nodes that are
supported by the 
same MAP (or set of MAPs)... 
I am not sure whether this domain has to be owned by the same administrative
entity (probably not)... 

regards, 
Claude. 


-- 



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

Claude CASTELLUCCIA, INRIA Rhone-Alpes  

ph:  +33 4.76.61.52.15 (fax: 52.52)

http://www.inrialpes.fr/planete/  
  


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









I 
would recommend using the term domain to mean administrative domain and not try 
to overload it.



  
-----Original Message-----
From: Claude Castelluccia 
  [mailto:claude.castelluccia@inrialpes.fr]
Sent: Thursday, April 19, 
  2001 2:40 AM
To: mobile-ip@sunroof.eng.sun.com
Subject: 
  Re: [mobile-ip] Revised Localized Mobility Management 
  Requirements

Hello Erik, 
  
Erik Nordmark wrote: 
  
> OK.  Let's make another cut through 
    these.  Seems that folks like the title 
> Localized Mobility 
    Management.  I didn't retain the original numbers. 
> 
> 
    Agreed upon requirements where there was no dissent: 
> 1. Regional 
    registration shall be introduced to minimize the signaling 
> traffic 
    to the home agent or correspondent nodes for intradomain mobility. 
    
I assume this applies to a "domain" being something larger than one IP 
    subnet 
and smaller than the whole Internet, since in the first case L2 
    does the work 
and in the second case the existing HA does the work. 
    
My question is whether it would be useful to constrain the size and 
    other 
attributes a bit more. 
    
For instance, is this "domain" within one adminstrative domain or not? 
    
The answer affects what trust models make sense for securing things. 
    
 
Just as an example in HMIPv6, we refer as "domain" 
  the set of nodes that are supported by the 
same MAP (or set of MAPs)... 
  
I am not sure whether this domain has to be owned by the same 
  administrative entity (probably not)... 
  
regards, 
Claude. 
-- 

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



------_=_NextPart_001_01C0C8F4.AF83F4D0--


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 19 13:37:09 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15033
	for ; Thu, 19 Apr 2001 13:37:08 -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 KAA10857;
	Thu, 19 Apr 2001 10:32: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 KAA26405;
	Thu, 19 Apr 2001 10:32:47 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JHV0K9007104
	for ; Thu, 19 Apr 2001 10:31:00 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3JHUtqP007103
	for mobile-ip-dist; Thu, 19 Apr 2001 10:30:55 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JHUlK9007096
	for ; Thu, 19 Apr 2001 10:30:47 -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 KAA08766
	for ; Thu, 19 Apr 2001 10:30:46 -0700 (PDT)
Received: from c007.snv.cp.net (c007-h015.c007.snv.cp.net [209.228.33.222])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA05425
	for ; Thu, 19 Apr 2001 10:30:44 -0700 (PDT)
Received: (cpmta 20684 invoked from network); 19 Apr 2001 10:30:43 -0700
Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129)
  by smtp.telocity.com (209.228.33.222) with SMTP; 19 Apr 2001 10:30:43 -0700
X-Sent: 19 Apr 2001 17:30:43 GMT
Message-ID: <023301c0c8f6$4cd7e060$6501a8c0@philneum>
From: "Phil Neumiller" 
To: 
References: <85AA7486A2C1D411BCA20000F8073E4301EF067D@crchy271.us.nortel.com>
Subject: Re: [mobile-ip] Revised Localized Mobility Management Requirement s
Date: Thu, 19 Apr 2001 12:29:27 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_022F_01C0C8CC.5FE1EFE0"
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: 

This is a multi-part message in MIME format.

------=_NextPart_000_022F_01C0C8CC.5FE1EFE0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

If they had read the MM design team problem statement and
participated in those meetings they would be using that term.
Phil R, why did you start this in MIP anyway, since SeaMoby had
a head start?  I just don't understand why you did not take that
document and extend that team?

----- Original Message ----- 
From: Glenn Morrow 
To: mobile-ip@sunroof.eng.sun.com 
Sent: Thursday, April 19, 2001 12:18 PM
Subject: RE: [mobile-ip] Revised Localized Mobility Management Requirement s


I would recommend using the term domain to mean administrative domain and not try to overload it.
  -----Original Message-----
  From: Claude Castelluccia [mailto:claude.castelluccia@inrialpes.fr]
  Sent: Thursday, April 19, 2001 2:40 AM
  To: mobile-ip@sunroof.eng.sun.com
  Subject: Re: [mobile-ip] Revised Localized Mobility Management Requirements


  Hello Erik, 
  Erik Nordmark wrote: 

    > OK.  Let's make another cut through these.  Seems that folks like the title 
    > Localized Mobility Management.  I didn't retain the original numbers. 
    > 
    > Agreed upon requirements where there was no dissent: 
    > 1. Regional registration shall be introduced to minimize the signaling 
    > traffic to the home agent or correspondent nodes for intradomain mobility. 
    I assume this applies to a "domain" being something larger than one IP subnet 
    and smaller than the whole Internet, since in the first case L2 does the work 
    and in the second case the existing HA does the work. 
    My question is whether it would be useful to constrain the size and other 
    attributes a bit more. 

    For instance, is this "domain" within one adminstrative domain or not? 
    The answer affects what trust models make sense for securing things. 
     

  Just as an example in HMIPv6, we refer as "domain" the set of nodes that are supported by the 
  same MAP (or set of MAPs)... 
  I am not sure whether this domain has to be owned by the same administrative entity (probably not)... 
  regards, 
  Claude. 


-- 

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

------=_NextPart_000_022F_01C0C8CC.5FE1EFE0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









If they had read the MM design team =
problem=20
statement and


participated in those meetings they =
would be=20
using that term.


Phil R, why did you start this in MIP =
anyway,=20
since SeaMoby had


a head start?  I just don't =
understand why=20
you did not take that


document and extend that =
team?


 


----- Original Message -----=20

From: Glenn=20
Morrow 



Sent: Thursday, April 19, 2001 12:18 PM


Subject: RE: [mobile-ip] Revised Localized Mobility =
Management=20
Requirement s





I=20
would recommend using the term domain to mean administrative domain and =
not try=20
to overload it.



  
-----Original Message-----
From: Claude =
Castelluccia=20
  [mailto:claude.castelluccia@inrialpes.fr]
Sent: Thursday, =
April 19,=20
  2001 2:40 AM
To: mobile-ip@sunroof.eng.sun.c=
om
Subject:=20
  Re: [mobile-ip] Revised Localized Mobility Management=20
  Requirements

Hello Erik,=20
  
Erik Nordmark wrote:=20
  
> OK.  Let's make another cut =
through=20
    these.  Seems that folks like the title 
> Localized =
Mobility=20
    Management.  I didn't retain the original numbers. 
> =

>=20
    Agreed upon requirements where there was no dissent: 
> 1. =
Regional=20
    registration shall be introduced to minimize the signaling 
> =
traffic=20
    to the home agent or correspondent nodes for intradomain mobility.=20
    
I assume this applies to a "domain" being something larger than =
one IP=20
    subnet 
and smaller than the whole Internet, since in the first =
case L2=20
    does the work 
and in the second case the existing HA does the =
work.=20
    
My question is whether it would be useful to constrain the size =
and=20
    other 
attributes a bit more.=20
    
For instance, is this "domain" within one adminstrative domain or =
not?=20
    
The answer affects what trust models make sense for securing =
things.=20
    
 
Just as an example in HMIPv6, we refer as =
"domain"=20
  the set of nodes that are supported by the 
same MAP (or set of =
MAPs)...=20
  
I am not sure whether this domain has to be owned by the same=20
  administrative entity (probably not)...=20
  
regards, 
Claude. 
-- 

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



------=_NextPart_000_022F_01C0C8CC.5FE1EFE0--



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 19 14:00:31 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15410
	for ; Thu, 19 Apr 2001 14:00:31 -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 KAA08797;
	Thu, 19 Apr 2001 10:59: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 KAA03134;
	Thu, 19 Apr 2001 10:59:04 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JHucK9007220
	for ; Thu, 19 Apr 2001 10:56:38 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3JHubKM007219
	for mobile-ip-dist; Thu, 19 Apr 2001 10:56: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JHuTK9007212
	for ; Thu, 19 Apr 2001 10:56:29 -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 KAA26275
	for ; Thu, 19 Apr 2001 10:56:28 -0700 (PDT)
Message-Id: <200104191756.KAA26275@heliopolis.eng.sun.com>
Date: Thu, 19 Apr 2001 10:56:28 -0700 (PDT)
From: James Kempf 
Subject: RE: [mobile-ip] Revised Localized Mobility Management Requirement s
To: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 1rfxJJATMnN+jOC5LFnF0A==
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 Karim,

>
>> >     "a Localised mobility management scheme should be able 
>> to adapt to
>> >topological changes
>> >arising in the domain that the LMM scheme is in effect.
...

>I think this change could bring new functionality into local MIP mobility
>which is not necessarily needed. The local agent is basically a
>local HA. 

Actually, that is only true for HMIP. In RegReg, it is a router. 

>Adapting to topological change is in the domain of MANET.
>IMO we need some agent redundancy protocol more than a MANET protocol
>which the above points to. It may be due to my misinterpretation, but
>that's the way it reads to me. So I am happier with Phil's version
>or something along those lines.
>

Adapting to topological change may be needed if a router
goes down and the route changes to another. I think it should
be a requirement that an LMM router actually handles this kind of thing,
exactly as for a regular router.

>In any case this requirement can be applied to HAs and local agents (MAPs),
>so it could be (should be?) solved outside the local mobility draft.
>(i.e. mobility agent redundancy protocol).

Whether it applies to HAs or not is irrelvent for the current discussion.
The final LMM solution does not have to look like an HA. 

		jak



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 19 14:02:11 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15438
	for ; Thu, 19 Apr 2001 14:02: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 LAA10815;
	Thu, 19 Apr 2001 11:00: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 LAA25309;
	Thu, 19 Apr 2001 11:00:38 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JHvuK9007230
	for ; Thu, 19 Apr 2001 10:57:57 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3JHvuPZ007229
	for mobile-ip-dist; Thu, 19 Apr 2001 10:57: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JHvhK9007222
	for ; Thu, 19 Apr 2001 10:57: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 KAA02569
	for ; Thu, 19 Apr 2001 10:57:42 -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 KAA20496
	for ; Thu, 19 Apr 2001 10:57:35 -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 KAA01293
	for ; Thu, 19 Apr 2001 10:57:35 -0700 (PDT)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3JHvVK17127
	for ; Thu, 19 Apr 2001 10:57:31 -0700
X-mProtect:  Thu, 19 Apr 2001 10:57:31 -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(WTS.12.69) smtpd1SpsG9; Thu, 19 Apr 2001 10:56:23 PDT
Message-ID: <3ADF26CA.F8076D53@iprg.nokia.com>
Date: Thu, 19 Apr 2001 10:56:26 -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] Revised Localized 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

Hi Karim,

  It surely brings new functionality, which is pretty much the autoconfig
stuff. I have provided
some reasoning as to why this is a must as far as the points of failure
(topological change) is concerned. If the LMM scheme does not want to cater
for extensibility (which is another requirement under the name scalability)
then it is up to the protocol. This is why I mentioned "should"  rather than
"must".

However, looking at the inter-relations between requirements the LMM will need
scalability anyway, which to me signifies a requirement for the second part of
what I term extensibility as manifestation of new candidate LMM-aware routing
elements that present strong candidacy for topological changes also.

Whether this is part of a single document or a cluster of documents (draft or
other) I am not really fussed..whatever serves better a modular and concrete
specification of the LMM scheme as a whole.

Theo

UCL/ Mobile Systems

"Karim El-Malki (ERA)" wrote:

> Hello Theo and James
>
> > >     "a Localised mobility management scheme should be able
> > to adapt to
> > >topological changes
> > >arising in the domain that the LMM scheme is in effect.
> > >
> > >The reason:
> > >
> > >    the failure of LMM agents manifests itself as a
> > topological change, since
> > >in IPv6 any such LMM agent will be a routing element.
> > However, the population
> > >of new routing elements that can be potential candidates for
> > LMM agents is also
> > >a manifestation of a topological change.
> > >
> > >The LMM scheme should be able to adapt to both; the latter
> > is extremely
> > >important in terms of scalability and incremental deployment
> > since we cannot
> > >expect to cast a domain topology in stone and live without expansion.
> > >
> >
> > I agree with this. It is a much more precise description.
> >
>
> I think this change could bring new functionality into local MIP mobility
> which is not necessarily needed. The local agent is basically a
> local HA. Adapting to topological change is in the domain of MANET.
> IMO we need some agent redundancy protocol more than a MANET protocol
> which the above points to. It may be due to my misinterpretation, but
> that's the way it reads to me. So I am happier with Phil's version
> or something along those lines.
>
> In any case this requirement can be applied to HAs and local agents (MAPs),
> so it could be (should be?) solved outside the local mobility draft.
> (i.e. mobility agent redundancy protocol).
>
> Regards
> /Karim



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 19 14:30:58 2001
Received: from mercury.Sun.COM ([192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15914
	for ; Thu, 19 Apr 2001 14:30:57 -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 LAA29788;
	Thu, 19 Apr 2001 11:23:20 -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 LAA09893;
	Thu, 19 Apr 2001 11:20:58 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JIJHK9007258
	for ; Thu, 19 Apr 2001 11:19:17 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3JIJHaq007257
	for mobile-ip-dist; Thu, 19 Apr 2001 11:19: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JIJ8K9007250
	for ; Thu, 19 Apr 2001 11:19:09 -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 LAA03294
	for ; Thu, 19 Apr 2001 11:19:08 -0700 (PDT)
Message-Id: <200104191819.LAA03294@heliopolis.eng.sun.com>
Date: Thu, 19 Apr 2001 11:19:08 -0700 (PDT)
From: James Kempf 
Subject: RE: [mobile-ip] MIP v6 Regional Registration - identifying re qui  rements
To: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: H4DTSVGIbiHhr6gCzUKbWw==
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 Karim,

>Almost. CT may not be needed for header compression, so the requirement
>cannot state that we must make sure that CT works for us.
>The only thing I can see is the need for ROHC when low bandwidth
>links are used. Should we have a requirement saying this? Don't know if
>it is much use though.
>

Here's what I want the requirement to say:

	The LMM design MUST not introduce any additional latency
	into handover. Candidate LMM designs that require additional
	header overhead for tunnels MUST be reviewed by the ROHC
	working group to determine if the header overhead can be
	compressed out, and if the header compressor can be restared
	from transferred compressor context when handover occurs
	without requiring any full header packet exchange on the new link.

>Well, the MAP will advertise, so why not make use of the preference?
>I'm sure you could use the Seamoby protocol to convey more info,
>but they could coexist. It is possible that not all MNs support
>the seamoby AP discovery protocol. I think it is a basic MIPv6
>discussion in any case, as you say in your comment below.
>

There's still the interoperability problem, and co-ordinating between
the Seamoby protocol and the LMM preferences would be a problem.
I think it would make more sense to focus on one capabilities solution
and not try to split into two.


>I can see that you could use a MAP for this, but is it not simpler to
>use normal routing to direct all traffic to local MAPs (RCOAs) through a
>certain router if required? What I mean is that it's not a strong reason
>to have multiple levels since it can be done otherwise without the need
>for MIP.
>

Let me state this perhaps more clearly. By its very nature, LMM reintroduces
triangle routing into mobile IP. It does this because the LMM agent
acts like the home agent in the sense that all traffic to the mobile node
must go through it. There is no way to avoid this, it is a consequence
of having to keep the regional care of address fixed.

One way to reduce the length of the unwanted triangle leg is to position
the LMM agent in the natural routing path of the mobile node. This
collapses the triangle into approximately the nontriangular path.

As the mobile node moves, however, the triangle may become extended,
to the point where delays are occuring in the routing. If the option of 
deploying multiple levels of hierarchy is available, the network can
be engineered so that the bottom level LMM agent moves if the triangle
becomes too extended, while the upper level stays the same. 

The above argument explains why at least two levels of hierarchy are needed.
An argument for more is that, in a large multinational ISP, the signalling
lines may become extended to the point where updating the local care of
address becomes a problem. Allowing multiple levels of hierarchy allows
the ISP to design their network so that signalling is optimized.

		jak 



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 19 14:31:45 2001
Received: from mercury.Sun.COM ([192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15964
	for ; Thu, 19 Apr 2001 14:31:45 -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 LAA02927;
	Thu, 19 Apr 2001 11:29:39 -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 LAA10967;
	Thu, 19 Apr 2001 11:25:31 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JIO6K9007286
	for ; Thu, 19 Apr 2001 11:24:06 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3JIO5WM007285
	for mobile-ip-dist; Thu, 19 Apr 2001 11:24:05 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JINsK9007278
	for ; Thu, 19 Apr 2001 11:23: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 LAA10481
	for ; Thu, 19 Apr 2001 11:23:54 -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 NAA19032
	for ; Thu, 19 Apr 2001 13:09:42 -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 LAA03971
	for ; Thu, 19 Apr 2001 11:23:51 -0700 (PDT)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3JINmE32258
	for ; Thu, 19 Apr 2001 11:23:48 -0700
X-mProtect:  Thu, 19 Apr 2001 11:23:48 -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(WTS.12.69) smtpd51ptfZ; Thu, 19 Apr 2001 11:23:20 PDT
Message-ID: <3ADF2D1B.19CE7F55@iprg.nokia.com>
Date: Thu, 19 Apr 2001 11:23:23 -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] Revised Localized Mobility Management Requirements
References:  <15071.4503.914618.357282@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 Mike,

  I will only show my rationale behind it and hope that it reflects and objective
interpretation and classification in the pursuit for fine-grained mobility.

Having as a given core MIPv6, we attempt to approach reduction of signalling by
localisation.

An LMM is nothing more than an instantiation of the mobility problem that is
fine-grained over a certain locality. That means to me that an LMM should sit on
top of core MIPv6 just to be able to revert back if the LMM does not work or
fails.

A Fast MIPv6 scheme attempts to remove latency during the handoff independent of
the mobility pattern. This is somewhat different than what the LMM is primarily
pursuing: that is reduction of signalling, but as a side-effect it should meet
lower latencies since the localisation point is closer now. That means to me also
that an FMIP scheme should be able to sit on top of core MIPv6 for similar reasons
to the ones for an LMM scheme.

Now one could say here that an LMM and an FMIPv6 scheme lie on the same level of
applicability...I think not...

Why

If one tries to apply mobility in the following order we have:

core MIPv6
LMM for v6 (localisation extn of the core MIPv6)
since the LMM for v6 is only effecting a localisation (and fundamentaly
_recursing_ base mobility to a good extent) I would find it reasonable to try and
speed up the process locally..
that is apply FMIP on top of the LMM

If we follow the opposite order from the LMM scheme onwards, I see it happening in
a bit unnatural fashion. Consider:

core MIPv6 in effect
Fast MIPv6  to speed up the handoff process
Now apply the LMM scheme..I cannot see how you speed up the handoff and past that
you try to reduce the signalling by effecting localisation...

This is because you have already tried to use optimized signalling for speed over
any AR and then you try to reduce them for locality when you become extra specific
about the instance of the AR: that is (in the current specs) a GMA/MAP. I don't
think it will get reduced without losing optimality for the original purpose

Theo

UCL/Mobile Systems



Michael Thomas wrote:

> So I've got a nagging question:
>
> Why is RR and the forward tunnel aspect of FMIP
> considered to be different problems? They both
> involve registering with an AR which acts like a
> home agent for the MN.
>
> Wouldn't it be better to have exactly *one* set of
> requirements and protocol of how a MN attaches to
> a local home agent, and let FMIP just define the
> interaction (or not, IMO) between the old AR and
> the new AR?
>
> If nothing else, the combinatorics of
> MIP/HMIP/FMIP here are pretty hard to get my head
> around.
>
>                 Mike



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 19 15:13:37 2001
Received: from mercury.Sun.COM ([192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16808
	for ; Thu, 19 Apr 2001 15:13:37 -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 LAA17229;
	Thu, 19 Apr 2001 11:58: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 LAA06376;
	Thu, 19 Apr 2001 11:58:25 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JIv3K9007329
	for ; Thu, 19 Apr 2001 11:57:03 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3JIv3lK007328
	for mobile-ip-dist; Thu, 19 Apr 2001 11:57: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JIusK9007321
	for ; Thu, 19 Apr 2001 11:56:54 -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 LAA05858
	for ; Thu, 19 Apr 2001 11:56:53 -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 LAA07208
	for ; Thu, 19 Apr 2001 11:56:53 -0700 (PDT)
Received: by zcamail05.zca.compaq.com (Postfix, from userid 12345)
	id 2E59D158; Thu, 19 Apr 2001 11:59:33 -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 D7DDD351
	for ; Thu, 19 Apr 2001 11:59:32 -0700 (PDT)
Received: by exctay-gh03.tay.cpqcorp.net with Internet Mail Service (5.5.2652.78)
	id <27D2QC14>; Thu, 19 Apr 2001 14:56:52 -0400
Message-ID: <88BD5A70CA8BFA4CA15D0ED053E49D69245433@tayexc14.americas.cpqcorp.net>
From: "Powell, Ken" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Mobile Prefix Advertisements
Date: Thu, 19 Apr 2001 14:56:45 -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.,

Just wanted to let you know that I reviewed your proposed
changes, along with doing another complete read-through
of the mobile-ipv6 spec. As always, I have some comments
brewing, particularly for section 9.8. This stuff is
not easy and the details could have a big impact on our
implementation. I asked our development team to sanity
check all my comments, and to also do a detailed review
of section 9.8 to be sure we get it right.

BTW, I noticed you didn't touch Appendix A. I'll be
proposing some changes I think you asked for a long
time ago. Your new Home Prefix Solicitation and Home
Prefix Advertisement changes make my temporary home
address kludge unnecessary.

Ken 

> -----Original Message-----
> From: T.J. Kniveton [mailto:TJ@Kniveton.com]
> Sent: Saturday, March 31, 2001 8:25 AM
> To: mobile-ip@sunroof.eng.sun.com
> Subject: [mobile-ip] Mobile Prefix Advertisements
> 
> 
> Hi,
> 
> At IETF50, I presented some problems with Network Renumbering and
> Tunneled Router Advertisements, and also presented a solution that had
> been discussed on this mailing list -- namely, to create a 
> new ICMP type
> for transporting prefix info from home link router 
> advertisements to the
> mobile node away from home.
> 
> So far, this idea is generally agreed upon as a reasonable 
> solution, so
> I am hoping people are open to trying this out. I have just finished
> writing proposed changes to the Mobile IPv6 draft which..
> 1. incorporate these new ICMP types
> 2. clean up the text in the renumbering section to make it easier to
> understand, and
> 3. simplify and re-evaluate rules and streamline the 
> specified mechanism
> a bit
> 4. keep as much of what was there as possible
> 
> Although there is still more work to get this right, I put these files
> on my web site so people can take a look. Please point out errors, and
> especially glaring problems, or make suggestions, whatever..
> 
> http://www.kniveton.com/tj/specs/
> 
> The resultant file is MIPv6-13tj2.txt -- my suggestion on how 
> to look at
> these changes would be download MIPv6-13.txt (the original draft) and
> MIPv6-13tj2.txt, and run "Compare Two Files" under xemacs's 
> Tools menu.
> 
> --
> T.J. Kniveton
> NOKIA Research
> 
> 


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 19 15:49:05 2001
Received: from mercury.Sun.COM ([192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17499
	for ; Thu, 19 Apr 2001 15:49: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 MAA10333;
	Thu, 19 Apr 2001 12:47:01 -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 MAA01383;
	Thu, 19 Apr 2001 12:46:22 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JJhwK9007440
	for ; Thu, 19 Apr 2001 12:43:58 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3JJhwHm007439
	for mobile-ip-dist; Thu, 19 Apr 2001 12:43: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JJhnK9007432
	for ; Thu, 19 Apr 2001 12:43:49 -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 MAA16920
	for ; Thu, 19 Apr 2001 12:43:48 -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 MAA14555
	for ; Thu, 19 Apr 2001 12:43:47 -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.9.3/8.9.1) with ESMTP id MAA02143
	for ; Thu, 19 Apr 2001 12:43:52 -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 AEI10762;
	Thu, 19 Apr 2001 12:43:46 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA10090; Thu, 19 Apr 2001 12:43:46 -0700 (PDT)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15071.16369.993033.641569@thomasm-u1.cisco.com>
Date: Thu, 19 Apr 2001 12:43:45 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Revised Localized Mobility Management Requirements
In-Reply-To: <3ADF2D1B.19CE7F55@iprg.nokia.com>
References: 
	<15071.4503.914618.357282@thomasm-u1.cisco.com>
	<3ADF2D1B.19CE7F55@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

Theo Pagtzis writes:
 > Now one could say here that an LMM and an FMIPv6 scheme lie on the same level of
 > applicability...I think not...

   I'm not saying that they're equally applicable. I'm saying that
   the mechanisms are nearly (completely?) identical and that it
   would be nice to keep it that way since they
   both have to interoperate with AAA, QoS, etc too.

   In general, I think that RR, etc, would do well 
   to steer away from what their applicability is
   and focus more on what the protocol mechanisms 
   are given a set of requirements. All I'm asking
   is why FMIP's needs for a localized forward
   tunnel to be established should not be part of
   the requirements for RR. We could then delete
   the redundant set of mechanism from FMIP.
 

		Mike


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 19 16:42:08 2001
Received: from mercury.Sun.COM ([192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18173
	for ; Thu, 19 Apr 2001 16:42:07 -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 NAA25074;
	Thu, 19 Apr 2001 13:18: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 NAA06425;
	Thu, 19 Apr 2001 13:16:52 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JKEQK9007748
	for ; Thu, 19 Apr 2001 13:14:26 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3JKEQcB007747
	for mobile-ip-dist; Thu, 19 Apr 2001 13:14: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JKEFK9007740
	for ; Thu, 19 Apr 2001 13:14:15 -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 NAA05288
	for ; Thu, 19 Apr 2001 13:14:14 -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 NAA08992
	for ; Thu, 19 Apr 2001 13:14:13 -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 NAA12515
	for ; Thu, 19 Apr 2001 13:14:13 -0700 (PDT)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3JKE9K15793
	for ; Thu, 19 Apr 2001 13:14:09 -0700
X-mProtect:  Thu, 19 Apr 2001 13:14:09 -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(WTS.12.69) smtpdXIRFQT; Thu, 19 Apr 2001 13:13:59 PDT
Message-ID: <3ADF470A.B625A88B@iprg.nokia.com>
Date: Thu, 19 Apr 2001 13:14: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
Subject: Re: [mobile-ip] Revised Localized Mobility Management Requirements
References:  <15071.4503.914618.357282@thomasm-u1.cisco.com> <3ADF2D1B.19CE7F55@iprg.nokia.com> <15071.16369.993033.641569@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 Mike,


Michael Thomas wrote:

> Theo Pagtzis writes:
>  > Now one could say here that an LMM and an FMIPv6 scheme lie on the same level of
>  > applicability...I think not...
>
>    I'm not saying that they're equally applicable. I'm saying that
>    the mechanisms are nearly (completely?) identical and that it
>    would be nice to keep it that way since they
>    both have to interoperate with AAA, QoS, etc too.
>
>    In general, I think that RR, etc, would do well
>    to steer away from what their applicability is
>    and focus more on what the protocol mechanisms
>    are given a set of requirements. All I'm asking
>    is why FMIP's needs for a localized forward
>    tunnel to be established should not be part of
>    the requirements for RR. We could then delete
>    the redundant set of mechanism from FMIP.
>

IMHO it is quite the opposite...it is not that FMIP needs a localised forward tunnel
but that the localised forward tunnel could use FMIP to further speed up handoff..

IF FMIP wants to be applicable over an LMM scheme it should  be compatible with the
LMM's mode of operation, i.e if we want to apply FMIP over an LMM scheme the FMIP
proto should be adaptable to LMM..

In practice that should not be difficult at all since the AR are simply becoming
LMM-aware routing elements..of course there is more to it, but this is the core
essense, I think.


Theo

UCL/ Mobile Systems








From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 19 20:12:20 2001
Received: from mercury.Sun.COM ([192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20100
	for ; Thu, 19 Apr 2001 20:12:15 -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 RAA26243;
	Thu, 19 Apr 2001 17:11: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 RAA19620;
	Thu, 19 Apr 2001 17:11:20 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3K0A1K9008028
	for ; Thu, 19 Apr 2001 17:10:02 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3K0A1xj008027
	for mobile-ip-dist; Thu, 19 Apr 2001 17:10: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3K09pK9008020
	for ; Thu, 19 Apr 2001 17:09:52 -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 RAA28266
	for ; Thu, 19 Apr 2001 17:09:51 -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 RAA20839
	for ; Thu, 19 Apr 2001 17:09:51 -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.9.3/8.9.1) with ESMTP id RAA00521
	for ; Thu, 19 Apr 2001 17:10: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 AEI17962;
	Thu, 19 Apr 2001 17:09:50 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA10140; Thu, 19 Apr 2001 17:09:50 -0700 (PDT)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15071.32334.37526.224514@thomasm-u1.cisco.com>
Date: Thu, 19 Apr 2001 17:09:50 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] two new drafts on mipv6 security available
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've made two new drafts available on my web server
and will be publishing them soon. 

The first is the Home Agent Cookies draft which
I've mentioned before. It's still got some rough
patches, but there are probably some useful things
in there beyond the protocol like the analysis of
some of the attacks, a section on NAT traversal
(bletch, I know, but our x-AD said that many on
the IESG felt it was necessary), as well as a
comparison to PBK.

The second draft is aimed at being able to use ESP
to transport binding updates instead of AH. It
also pays some lip service to when you should and
shouldn't use IPsec in general to secure binding 
updates. 

They're available at:

http://mtcc.com/standards/draft-thomas-mobileip-ha-cookies-00.txt
http://mtcc.com/standards/draft-thomas-mobileip-esp-bu-00.txt

Enjoy.

		Mike


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 19 21:48:25 2001
Received: from mercury.Sun.COM ([192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21754
	for ; Thu, 19 Apr 2001 21:48:24 -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 SAA18734;
	Thu, 19 Apr 2001 18:47:07 -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 SAA13177;
	Thu, 19 Apr 2001 18:45:27 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3K1haK9008163
	for ; Thu, 19 Apr 2001 18:43:37 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3K1haHk008162
	for mobile-ip-dist; Thu, 19 Apr 2001 18:43: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 bebop.france (bebop.France.Sun.COM [129.157.174.15] (may be forged))
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3K1hQK9008155
	for ; Thu, 19 Apr 2001 18:43:27 -0700 (PDT)
Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11])
	by bebop.france (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id DAA18968
	for ; Fri, 20 Apr 2001 03:43:23 +0200 (MET DST)
Date: Thu, 19 Apr 2001 18:43:16 -0700 (PDT)
From: Erik Nordmark 
Subject: Re: [mobile-ip] Revised Localized Mobility Management Requirements
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: 

> Firstly, a good design principle to limit the size of a "domain" is to
> think how fast handoffs this "domain" would be able to provide. In a
> humongous hierarchy with slow links between the elements of the hierarchy,
> even the localized mobility management may not provide reasonably fast
> handoffs. The size of the domain is also linked to the number of MNs the
> system must support. By splitting mega-domains, one would also gain some
> scalability for the entire system of domains, but that is merely a network
> design issue, perhaps not that tightly related to protocol design.

I agree in general.
But I've heard arguments for having a hirarchy of agents within each domain
and I'm struggling trying to understand whether that is a requirement or not.
Basically I see two approaches and I don't know how to resolve them:
1. A domain might be huge (for whatever reason) hence for scaling reasons
   you need to be capable of having a arbirarely deep hirarchy of agents.
2. Simplicity is good idea and a solution without hirarchy is likely to
   be simpler, if not to implement to operate, than one with a hirarchy.

This coupled with the size of the domain being a network design issue
makes this hard to resolve.

  Erik




From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 19 22:02:55 2001
Received: from mercury.Sun.COM ([192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA21882
	for ; Thu, 19 Apr 2001 22:02:55 -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 TAA21580;
	Thu, 19 Apr 2001 19:01:50 -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 TAA05317;
	Thu, 19 Apr 2001 19:01:10 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3K1xTK9008188
	for ; Thu, 19 Apr 2001 18:59:30 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3K1xThj008187
	for mobile-ip-dist; Thu, 19 Apr 2001 18:59: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3K1xAK9008180
	for ; Thu, 19 Apr 2001 18:59: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 SAA13941
	for ; Thu, 19 Apr 2001 18:59:10 -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 SAA16690
	for ; Thu, 19 Apr 2001 18:59:09 -0700 (PDT)
Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM)
	id AA12589; Thu, 19 Apr 2001 21:59:09 -0400
Date: Thu, 19 Apr 2001 21:59:08 -0400 (EDT)
From: Jim Bound 
To: mobile-ip@sunroof.eng.sun.com
Cc: neumiller@telocity.com
Subject: Re: [mobile-ip] Design teams for mobileip--(sharif)
In-Reply-To: <3ADEEDE9.77B6BAAA@usa.alcatel.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: 

WOW.  A bit extreme even for me. We don't want WGs approving DT's.  DT's
as 2418 states can be a hallway conversation.  I think keeping a record of
DTs defined by the ADs with who was on them would be a very good idea
though.  That way if the DTs are always the same people we can see that.
One they are hard working, knowledgable, and will volunteer for stuff. Or
two they have the afforementioned traits but also part of the control
process for the IETF.  The second is the issue.

I believe the first step to an AD that breaks the rules or is otherwise
ill behaved is to contact the IESG Chair.  If not resolved then IAB appeal
and if still not resolved ISOC appeal.

/jim

On Thu, 19 Apr 2001, Behcet Sarikaya wrote:

> I suggest that RFC 2418 be amended (as is already followed by many WGs)
> in view of the excessive use of DT's (making IETF look like ETSI, CCITT, etc.)
> to mandate a WG approval of each DT and its closedness or opennes
> and bring penalties for WG chairs who do not follow the rules
> and also
> mandatory vote of confidence in IETF meetings for WG chairs and ADs.
> 
> Food for thought.
> 
> Scott Bradner wrote:
> 
> > note that teh output of design teams is input for working groups - anything
> > that a design team does can be modified or undone by the WG
> >
> > Scott
> 
> --
> Behcet
> 



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 19 22:13:32 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA21973
	for ; Thu, 19 Apr 2001 22:13:31 -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 TAA23518;
	Thu, 19 Apr 2001 19:12: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 TAA19587;
	Thu, 19 Apr 2001 19:12:47 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3K2BVK9008205
	for ; Thu, 19 Apr 2001 19:11:31 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3K2BPBd008204
	for mobile-ip-dist; Thu, 19 Apr 2001 19:11: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3K2B4K9008197
	for ; Thu, 19 Apr 2001 19:11: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 TAA16005
	for ; Thu, 19 Apr 2001 19:11:04 -0700 (PDT)
Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id UAA09853
	for ; Thu, 19 Apr 2001 20:59:47 -0600 (MDT)
Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM)
	id AA13880; Thu, 19 Apr 2001 22:11:02 -0400
Date: Thu, 19 Apr 2001 22:11:02 -0400 (EDT)
From: Jim Bound 
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Design teams for mobileip--(sharif)
In-Reply-To: <85AA7486A2C1D411BCA20000F8073E4301EF0592@crchy271.us.nortel.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: 

thanks.  I know.  Back many years ago when Charlie and Dave came to IPv6
and presented the essential idea and I think draft 03 got most of what is
needed at that point.  Then the WG fixed the mobile parts to a fine tune.
Now we are just pontificating to the current spec of MIPv6.  Once we have
the answer to the security issue presented at IETF50 we should ship MIPv6
to PS and move on to all other subjects.  1993...man that is ridiculous by
anyones analysis and its not the WGs and authors fault.  I have seen this
in a few Areas.  I believe its usually the case of the authors initial
idea, the WG consensus idea, and the AD's idea.  The last part is the
problem.  The AD should not be providing "ideas" as AD but only as
individual WG member.  It causes them to have more power technically than
the rest of the WG.  This is plain wrong by any interpretation of the
founding IETF principles for this community.  It doesn't just happen in
MIP either.  The AD is only a MANAGER thats it. 

I for one am going be on things I see like this like a pit bull chasing a
meat truck.  Its another form of "bullying people".  And I have zero
tolerance for that and strong enough to tell them to stick it and record
it and use the recordings.  I am sure my drafts will suffer from these
comments to I am working on :----)

/jim

On Thu, 19 Apr 2001, Glenn Morrow wrote:

> I agree 100% with you Jim - something stinks in the MIP WG. This is why it
> has been going on since 1993 with minor progress.
> 
> -----Original Message-----
> From: Jim Bound [mailto:seamus@bit-net.com]
> Sent: Tuesday, April 17, 2001 2:29 PM
> To: mobile-ip@sunroof.eng.sun.com
> Subject: Re: [mobile-ip] Design teams for mobileip--(sharif)
> 
> 
> You did not respond to my previous issue with your appeal regarding 3GPP
> et al which I am not clear is valid or warranted.  But this one may have
> some meat here is why.
> 
> I am on two design teams to work problems and get back to the working
> groups here in the IETF (which ones are not relevent).  We formed these
> teams "for" the working groups and asked for volunteers.  The list is
> closed because the "design team" wanted it closed and the working group
> does not care.
> 
> But in the case where a team is formed and the management team in the IETF
> did not ask for volunteers from the working group then that is a closed
> process because when the management team makes such decisions it is a
> formal process.  As opposed to working group members going off and solving
> a problem which is 'ad hoc'.  To then close that formal list is insult to
> injury at a minimum to get input from the working group at a minimum.
> 
> Then the other problem with this for your appeal is as follows.  Why were
> certain people put on this closed team and not others.  What
> "discrimination" was used to determine who was part of this formal
> process.  Was it fair discrimination to the working group as a whole?
> 
> This is a classic example of why the good-ole-boy-network needs fixing.
> 
> It is a bad precedent and I believe could potentially cause a legal
> problem to the IETF which is the last thing we need here.  In a private
> company,  private entity, or academic/research centers this is done often
> and valid, but this is the IETF the open process for open standards.
> 
> I also understand that authors are not part of the design teams?  How was
> that discrimination arrived at and seems not wise to me?
> 
> But then maybe there are perfect reasonable explanations for the above?
> 
> regards,
> /jim
> 
> On Tue, 17 Apr 2001, Phil Neumiller wrote:
> 
> > I guess this is another item to add to my appeal.  I believe this is
> > setting a bad precedent for the IETF.
> > 
> > Thanks,
> > 
> > Phil
> > ----- Original Message -----
> > From: "Phil Roberts" 
> > To: 
> > Sent: Tuesday, April 17, 2001 12:08 PM
> > Subject: RE: [mobile-ip] Design teams for mobileip--(sharif)
> > 
> > 
> > > Both fast handoff lists were open to begin with but due to some concerns
> > > about the ability to make progress the ADs asked us to close them, so we
> > > did.  The archives will be made public when the teams are done.
> Versions of
> > > each draft have been published and you are welcome to comment on them on
> the
> > > main list.
> > >
> > 
> > >
> > 
> > 
> 
> 



From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 20 00:15:48 2001
Received: from mercury.Sun.COM ([192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA24014
	for ; Fri, 20 Apr 2001 00:15: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 VAA11804;
	Thu, 19 Apr 2001 21:14: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 VAA16957;
	Thu, 19 Apr 2001 21:14:24 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3K4DGK9008356
	for ; Thu, 19 Apr 2001 21:13:17 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3K4DGk9008355
	for mobile-ip-dist; Thu, 19 Apr 2001 21:13: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3K4D5K9008347
	for ; Thu, 19 Apr 2001 21:13: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 VAA16775
	for ; Thu, 19 Apr 2001 21:13:05 -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 VAA24858
	for ; Thu, 19 Apr 2001 21:13:04 -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 f3K4FFw12913
	for ; Thu, 19 Apr 2001 23:15:25 -0500 (CDT)
Received: from daebh01nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id ;
 Thu, 19 Apr 2001 23:12:54 -0500
Received: by daebh01nok with Internet Mail Service (5.5.2652.78)
	id ; Thu, 19 Apr 2001 23:12:54 -0500
Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B03213890@daeis07nok>
To: mobile-ip@sunroof.eng.sun.com
Cc: Erik.Nordmark@eng.sun.com
Subject: RE: [mobile-ip] Revised Localized Mobility Management Requirement
	s
Date: Thu, 19 Apr 2001 23:12:53 -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: 

Erik wrote:
> 
> I agree in general.
> But I've heard arguments for having a hirarchy of agents 
> within each domain
> and I'm struggling trying to understand whether that is a 
> requirement or not.

I think the idea of allowing multiple agents and a hierarchy is to
have flexibility in deployment.  But I am not sure if multiple levels
will be truly required and to what extent does such a deployment
perform better with say a single level.

> Basically I see two approaches and I don't know how to resolve them:
> 1. A domain might be huge (for whatever reason) hence for 
> scaling reasons
>    you need to be capable of having a arbirarely deep 
> hirarchy of agents.

Why? Would this not work just as well with a single level of hierarchy,
but one where there are multiple top level agents, i.e a distributed
set of top-level agents which can load balance if that is a concern.

> 2. Simplicity is good idea and a solution without hirarchy is 
> likely to
>    be simpler, if not to implement to operate, than one with 
> a hirarchy.
> 

Completely agree here Erik. I know there have been arguments for
having a hierarchy, but I still do not totally get it. 

> This coupled with the size of the domain being a network design issue
> makes this hard to resolve.
> 
>   Erik
> 


> 


From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 20 05:36:36 2001
Received: from mercury.Sun.COM ([192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09478
	for ; Fri, 20 Apr 2001 05:36: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 CAA18543;
	Fri, 20 Apr 2001 02:35: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 CAA12910;
	Fri, 20 Apr 2001 02:35:17 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3K9YBK9008717
	for ; Fri, 20 Apr 2001 02:34:11 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3K9YBQG008716
	for mobile-ip-dist; Fri, 20 Apr 2001 02:34:11 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3K9XxK9008709
	for ; Fri, 20 Apr 2001 02:34: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 CAA20099
	for ; Fri, 20 Apr 2001 02:33:58 -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 CAA24823
	for ; Fri, 20 Apr 2001 02:33:57 -0700 (PDT)
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 f3K9XtN21744
	for ; Fri, 20 Apr 2001 11:33:55 +0200 (MEST)
Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T))
	id LAA14297; Fri, 20 Apr 2001 11:33:55 +0200
Message-ID: <3AE00251.164B6C00@era.ericsson.se>
Date: Fri, 20 Apr 2001 11:33:05 +0200
From: Mattias Pettersson 
Organization: Ericsson Research
X-Mailer: Mozilla 4.76 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Mobile Prefix Advertisements
References: <88BD5A70CA8BFA4CA15D0ED053E49D69245433@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.,

> BTW, I noticed you didn't touch Appendix A. I'll be
> proposing some changes I think you asked for a long
> time ago. Your new Home Prefix Solicitation and Home
> Prefix Advertisement changes make my temporary home
> address kludge unnecessary.

I would be happy to let the temporary home address go, too.

/Mattias

> 
> Ken


From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 20 06:51:27 2001
Received: from mercury.Sun.COM ([192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10027
	for ; Fri, 20 Apr 2001 06:51:26 -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 DAA07073;
	Fri, 20 Apr 2001 03: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 DAA25632;
	Fri, 20 Apr 2001 03:50:12 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3KAn2K9008762
	for ; Fri, 20 Apr 2001 03:49:02 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3KAn18o008761
	for mobile-ip-dist; Fri, 20 Apr 2001 03:49: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3KAmpK9008754
	for ; Fri, 20 Apr 2001 03:48:53 -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 DAA25540
	for ; Fri, 20 Apr 2001 03:48:49 -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 DAA10360
	for ; Fri, 20 Apr 2001 03:48:49 -0700 (PDT)
Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM)
	id AA23308; Fri, 20 Apr 2001 06:48:48 -0400
Date: Fri, 20 Apr 2001 06:48:48 -0400 (EDT)
From: Jim Bound 
To: mobile-ip@sunroof.eng.sun.com
Cc: Erik.Nordmark@eng.sun.com
Subject: RE: [mobile-ip] Revised Localized Mobility Management Requirement s
In-Reply-To: <7B5C0390ACE7D211BC9C0008C7EABA2B03213890@daeis07nok>
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: 

hierarchy permits distributing the problem set across that graph and a
vechicle to provide another level of indirection as required.  This gives
us the capability to address the scalability as Erik points out.  Load
balancing across multiple top level agents will cause the bottleneck above
the domain and it will have to be parsed there.  We need to remember that
we are dealing with a dynamic update environment and those updates may not
need to be done at the root of the domain in all cases.  As far as simple
to operate vs complex needs to be defined before we throw it out and part
of that engineering trade-off is perforance/cost too to build and procure. 
If done correctly the replacement of domain parts could be cheaper once
the hierarchy is set up and at the base of the hierarchy performance will
be better in the domain if going to the root is not required.  As far as
building it.  Thats a distributed problem I don't see an issue there. 

/jim

On Thu, 19 Apr 2001 Basavaraj.Patil@nokia.com wrote:

> Erik wrote:
> > 
> > I agree in general.
> > But I've heard arguments for having a hirarchy of agents 
> > within each domain
> > and I'm struggling trying to understand whether that is a 
> > requirement or not.
> 
> I think the idea of allowing multiple agents and a hierarchy is to
> have flexibility in deployment.  But I am not sure if multiple levels
> will be truly required and to what extent does such a deployment
> perform better with say a single level.
> 
> > Basically I see two approaches and I don't know how to resolve them:
> > 1. A domain might be huge (for whatever reason) hence for 
> > scaling reasons
> >    you need to be capable of having a arbirarely deep 
> > hirarchy of agents.
> 
> Why? Would this not work just as well with a single level of hierarchy,
> but one where there are multiple top level agents, i.e a distributed
> set of top-level agents which can load balance if that is a concern.
> 
> > 2. Simplicity is good idea and a solution without hirarchy is 
> > likely to
> >    be simpler, if not to implement to operate, than one with 
> > a hirarchy.
> > 
> 
> Completely agree here Erik. I know there have been arguments for
> having a hierarchy, but I still do not totally get it. 
> 
> > This coupled with the size of the domain being a network design issue
> > makes this hard to resolve.
> > 
> >   Erik
> > 
> 
> 
> > 
> 



From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 20 08:45:38 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA11055
	for ; Fri, 20 Apr 2001 08:45: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 FAA04224;
	Fri, 20 Apr 2001 05:32: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 FAA03852;
	Fri, 20 Apr 2001 05:32:15 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3KCUtK9008875
	for ; Fri, 20 Apr 2001 05:30:56 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3KCUtCw008874
	for mobile-ip-dist; Fri, 20 Apr 2001 05:30:55 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3KCUiK9008867
	for ; Fri, 20 Apr 2001 05:30: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 FAA08637
	for ; Fri, 20 Apr 2001 05:30:45 -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 FAA27540
	for ; Fri, 20 Apr 2001 05:30:44 -0700 (PDT)
Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 20 Apr 2001 08:24:57 -0400
Message-ID: 
From: Phil Roberts 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Design teams for mobileip--(sharif)
Date: Fri, 20 Apr 2001 08:24:56 -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,

    is there some other list on which this thread could be continued?  I'm
happy to have it here as long as it's specific complaints or concerns about
this WG, but it seems to be drifting towards general IETF process issues.

Phil


> -----Original Message-----
> From: Jim Bound [mailto:seamus@bit-net.com]
> Sent: Thursday, April 19, 2001 9:59 PM
> To: mobile-ip@sunroof.eng.sun.com
> Cc: neumiller@telocity.com
> Subject: Re: [mobile-ip] Design teams for mobileip--(sharif)
> 
> 
> WOW.  A bit extreme even for me. We don't want WGs approving 
> DT's.  DT's
> as 2418 states can be a hallway conversation.  I think 
> keeping a record of
> DTs defined by the ADs with who was on them would be a very good idea
> though.  That way if the DTs are always the same people we 
> can see that.
> One they are hard working, knowledgable, and will volunteer 
> for stuff. Or
> two they have the afforementioned traits but also part of the control
> process for the IETF.  The second is the issue.
> 
> I believe the first step to an AD that breaks the rules or is 
> otherwise
> ill behaved is to contact the IESG Chair.  If not resolved 
> then IAB appeal
> and if still not resolved ISOC appeal.
> 
> /jim
> 
> On Thu, 19 Apr 2001, Behcet Sarikaya wrote:
> 
> > I suggest that RFC 2418 be amended (as is already followed 
> by many WGs)
> > in view of the excessive use of DT's (making IETF look like 
> ETSI, CCITT, etc.)
> > to mandate a WG approval of each DT and its closedness or opennes
> > and bring penalties for WG chairs who do not follow the rules
> > and also
> > mandatory vote of confidence in IETF meetings for WG chairs and ADs.
> > 
> > Food for thought.
> > 
> > Scott Bradner wrote:
> > 
> > > note that teh output of design teams is input for working 
> groups - anything
> > > that a design team does can be modified or undone by the WG
> > >
> > > Scott
> > 
> > --
> > Behcet
> > 
> 


From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 20 12:00:45 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13666
	for ; Fri, 20 Apr 2001 12:00: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 IAA10353;
	Fri, 20 Apr 2001 08:59:41 -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 IAA29278;
	Fri, 20 Apr 2001 08:59:33 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3KFwPK9009028
	for ; Fri, 20 Apr 2001 08:58:26 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3KFwPSs009027
	for mobile-ip-dist; Fri, 20 Apr 2001 08:58: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3KFwHK9009019
	for ; Fri, 20 Apr 2001 08:58:17 -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 IAA15130
	for ; Fri, 20 Apr 2001 08:58:16 -0700 (PDT)
Message-Id: <200104201558.IAA15130@heliopolis.eng.sun.com>
Date: Fri, 20 Apr 2001 08:58:16 -0700 (PDT)
From: James Kempf 
Subject: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised Localized Mobility Management Requirement s)
To: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 9CRcapFEAXIEtp3a5v3mwQ==
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: 

Raj and Erik,

>> Basically I see two approaches and I don't know how to resolve them:
>> 1. A domain might be huge (for whatever reason) hence for 
>> scaling reasons
>>    you need to be capable of having a arbirarely deep 
>> hirarchy of agents.
>
>Why? Would this not work just as well with a single level of hierarchy,
>but one where there are multiple top level agents, i.e a distributed
>set of top-level agents which can load balance if that is a concern.
>

No, because the signalling lines may depend on the depth as well
as the breadth of the routing topology. So in a large, multicontinental
routing domain, the signalling for a single per domain agent may be just
as expensive as signalling directly to the corresponding nodes
and home agent. 

In addition, changing a single top level agent requires the mobile to signal a 
regional care of address change to the home agent and all
corresponding nodes. It is therefore a heavyweight solution and
one that should not often be done, even if there is no reauthentication
involved. Making it the basis of dealing with load balancing is therefore
likely to lead to more signalling latency than if multiple levels
of LMM agents were allowed.

>> 2. Simplicity is good idea and a solution without hirarchy is 
>> likely to
>>    be simpler, if not to implement to operate, than one with 
>> a hirarchy.
>> 
>
>Completely agree here Erik. I know there have been arguments for
>having a hierarchy, but I still do not totally get it. 
>

I'm all for simplicity, which is why I would like the requirements
to preclude preferences or other complex attributes that need
additional standardization. But, in this case, I think not allowing multiple 
levels of LMM agents shuts out possible deployment scenarios that
I believe are realistic and will directly affect how well the
solution  fufills the fundamental requirement, namely localizing
signalling.

		jak



From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 20 14:04:53 2001
Received: from mercury.Sun.COM ([192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15545
	for ; Fri, 20 Apr 2001 14:04:53 -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 LAA10900;
	Fri, 20 Apr 2001 11:00: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 LAA06034;
	Fri, 20 Apr 2001 11:00:14 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3KHwmK9009263
	for ; Fri, 20 Apr 2001 10:58:48 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3KHwlwQ009262
	for mobile-ip-dist; Fri, 20 Apr 2001 10:58: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3KHwWK9009247
	for ; Fri, 20 Apr 2001 10:58: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 KAA02642
	for ; Fri, 20 Apr 2001 10:58:31 -0700 (PDT)
From: Basavaraj.Patil@nokia.com
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA23961
	for ; Fri, 20 Apr 2001 10:58:29 -0700 (PDT)
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 f3KHwDg28805
	for ; Fri, 20 Apr 2001 12:58:28 -0500 (CDT)
Received: from daebh02nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id ;
 Fri, 20 Apr 2001 12:58:03 -0500
Received: by daebh02nok with Internet Mail Service (5.5.2652.78)
	id ; Fri, 20 Apr 2001 12:58:03 -0500
Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B032138A0@daeis07nok>
To: mobile-ip@sunroof.eng.sun.com
Cc: James.Kempf@Sun.COM
Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L
	ocalized Mobility Management Requirement s)
Date: Fri, 20 Apr 2001 12:58:00 -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: 

Comments inline:

>James wrote:
>Raj and Erik,
>
>>>Erik:
>>> Basically I see two approaches and I don't know how to resolve them:
>>> 1. A domain might be huge (for whatever reason) hence for 
>>> scaling reasons
>>>    you need to be capable of having a arbirarely deep 
>>> hirarchy of agents.
>>Raj:
>>Why? Would this not work just as well with a single level of hierarchy,
>>but one where there are multiple top level agents, i.e a distributed
>>set of top-level agents which can load balance if that is a concern.
>>
>
>No, because the signalling lines may depend on the depth as well
>as the breadth of the routing topology. So in a large, multicontinental
>routing domain, the signalling for a single per domain agent may be just
>as expensive as signalling directly to the corresponding nodes
>and home agent. 
>

But that would imply that the mobility agent assigned to the MN is
probably not the optimum one. The idea is to reduce signaling and this
can be accomplished if you have a mobility agent closer or at some
optimum level in the network. So there is some engineering about where
the mobility agent resides and I would think that in the case of an
inter-continental routing domain, the mobility agent serving a MN
would be somewhere close to the MN and the signaling would not have to
traverse some undersea cables. And why would you believe there be only
one domain agent in a large routing domain? 

>In addition, changing a single top level agent requires the mobile to
>signal a  
>regional care of address change to the home agent and all
>corresponding nodes. 

But how often do you change a top-level agent? Irrespective of how
many levels of hierarchy you have, if you change the top level agent,
you will need to signal the HA and CNs. So if you are changing your
top level agent every time you perform a hand off, then obviously
there is something wrong with the location of the top-level agent.

>It is therefore a heavyweight solution and
>one that should not often be done, even if there is no reauthentication
>involved. Making it the basis of dealing with load balancing is therefore
>likely to lead to more signalling latency than if multiple levels
>of LMM agents were allowed.
>

Multiple LMM agents are required no doubt, but do we really need
multiple levels of these agents? I do agree with some of the examples
you have provided of not limiting a hierarchy or ruling it out, but
from a deployment perspective, I am not so sure...

>>> 2. Simplicity is good idea and a solution without hirarchy is 
>>> likely to
>>>    be simpler, if not to implement to operate, than one with 
>>> a hirarchy.
>>> 
>>
>>Completely agree here Erik. I know there have been arguments for
>>having a hierarchy, but I still do not totally get it. 
>>
>
>I'm all for simplicity, which is why I would like the requirements
>to preclude preferences or other complex attributes that need
>additional standardization. But, in this case, I think not allowing
multiple 
>levels of LMM agents shuts out possible deployment scenarios that
>I believe are realistic and will directly affect how well the
>solution  fufills the fundamental requirement, namely localizing
>signalling.
>
>		jak
>

I do not think we should rule out multiple levels of LMM agents from
the requirements at this stage, but let's discuss the implications of
a multi-level hierarchy from a routing, deployment, failure-point etc.
perspective. Obviously there are quite a few people who feel quite
strongly about it and to rule it out would be unwise. 

-Basavaraj


From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 20 14:19:38 2001
Received: from mercury.Sun.COM ([192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15819
	for ; Fri, 20 Apr 2001 14:19: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 LAA18201;
	Fri, 20 Apr 2001 11:18: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 LAA12087;
	Fri, 20 Apr 2001 11:18:17 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3KIGZK9009330
	for ; Fri, 20 Apr 2001 11:16:36 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3KIGZv4009329
	for mobile-ip-dist; Fri, 20 Apr 2001 11:16: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3KIGPK9009322
	for ; Fri, 20 Apr 2001 11:16:27 -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 LAA00355
	for ; Fri, 20 Apr 2001 11:16:24 -0700 (PDT)
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA03675
	for ; Fri, 20 Apr 2001 11:16:21 -0700 (PDT)
Received: from grubby.research.bell-labs.com ([135.104.2.9]) by crufty; Fri Apr 20 14:12:35 EDT 2001
Received: from king.research.bell-labs.com ([135.1.152.1]) by grubby; Fri Apr 20 14:14:59 EDT 2001
Received: from notmafia.research.bell-labs.com.research.bell-labs.com (notmafia [135.1.152.230])
	by king.research.bell-labs.com (Postfix) with SMTP id F2EEC5701F
	for ; Fri, 20 Apr 2001 13:14:53 -0500 (CDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Pete McCann 
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] WG last call: AAA Keys
In-Reply-To: 
References: 
X-Mailer: VM 6.33 under Emacs 19.34.2
Message-Id: <20010420181454.F2EEC5701F@king.research.bell-labs.com>
Date: Fri, 20 Apr 2001 13:14:54 -0500 (CDT)
Sender: owner-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,

The current version of this draft does not seem to reflect the changes
suggested by Pat last week, namely, that instead of sending keys in
the registration reply, we would send a random number from which keys
would be generated.

If it is a matter of proposing specific text, I would be glad to
volunteer if no one else is working on this.

Also, does it make sense to include a (possibly very long) Lifetime
for the MN-HA key as well as the MN-FA key?

-Pete

Phil Roberts  (PR) writes:

PR> This is a Mobile IP WG last call for the I-D
PR> draft-ietf-mobileip-aaa-key-04.txt
PR> AAA Registration Keys for Mobile IP. This draft will be sent to the IESG
PR> requesting a proposed standard status to be associated with it at the end of
PR> the last call
PR> period. Please send your comments to the WG discussion list.

PR> WG Last call issued on : Apr 19, 2001
PR> Expires on : May 4, 2001

PR> Basavaraj Patil
PR> Phil Roberts



From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 20 15:47:47 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17064
	for ; Fri, 20 Apr 2001 15:47: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 MAA07738;
	Fri, 20 Apr 2001 12:46:52 -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 MAA02823;
	Fri, 20 Apr 2001 12:46:42 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3KJh2K9009433
	for ; Fri, 20 Apr 2001 12:43:02 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3KJh1JY009432
	for mobile-ip-dist; Fri, 20 Apr 2001 12:43: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3KJgrK9009425
	for ; Fri, 20 Apr 2001 12:42: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 MAA28080;
	Fri, 20 Apr 2001 12:42:52 -0700 (PDT)
Message-Id: <200104201942.MAA28080@heliopolis.eng.sun.com>
Date: Fri, 20 Apr 2001 12:42:52 -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, Basavaraj.Patil@nokia.com
Cc: James.Kempf@Sun.COM
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: Vfp0nKso9vjRx85XTG2JEw==
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: 

Raj,


>I do not think we should rule out multiple levels of LMM agents from
>the requirements at this stage, but let's discuss the implications of
>a multi-level hierarchy from a routing, deployment, failure-point etc.
>perspective. Obviously there are quite a few people who feel quite
>strongly about it and to rule it out would be unwise. 
>

Ulimately, the issue is one of deployment. The worst possible case
is we cycle an LMM protocol without multiple levels of hierarchy
to proposed and discover during deployment that we need it. 

		jak



From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 20 15:49:47 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17135
	for ; Fri, 20 Apr 2001 15:49:45 -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 MAA09159;
	Fri, 20 Apr 2001 12:48:40 -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 MAA21277;
	Fri, 20 Apr 2001 12:48:34 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3KJlKK9009445
	for ; Fri, 20 Apr 2001 12:47:20 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3KJlKl3009444
	for mobile-ip-dist; Fri, 20 Apr 2001 12:47: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3KJl5K9009437
	for ; Fri, 20 Apr 2001 12:47:07 -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 MAA26245
	for ; Fri, 20 Apr 2001 12:47:03 -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 MAA10039
	for ; Fri, 20 Apr 2001 12:47:01 -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 MAA11238
	for ; Fri, 20 Apr 2001 12:47:01 -0700 (PDT)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3KJkxD12906
	for ; Fri, 20 Apr 2001 12:46:59 -0700
X-mProtect:  Fri, 20 Apr 2001 12:46:59 -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(WTS.12.69) smtpd1ZFTSG; Fri, 20 Apr 2001 12:46:49 PDT
Message-ID: <3AE09229.A2B11D29@iprg.nokia.com>
Date: Fri, 20 Apr 2001 12:46:49 -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: <7B5C0390ACE7D211BC9C0008C7EABA2B032138A0@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

Hi Basavaraj,

some comments below..

Basavaraj.Patil@nokia.com wrote:

> Comments inline:
>
> >James wrote:
> >Raj and Erik,
> >
> >>>Erik:
> >>> Basically I see two approaches and I don't know how to resolve them:
> >>> 1. A domain might be huge (for whatever reason) hence for
> >>> scaling reasons
> >>>    you need to be capable of having a arbirarely deep
> >>> hirarchy of agents.
> >>Raj:
> >>Why? Would this not work just as well with a single level of hierarchy,
> >>but one where there are multiple top level agents, i.e a distributed
> >>set of top-level agents which can load balance if that is a concern.
> >>
> >
> >No, because the signalling lines may depend on the depth as well
> >as the breadth of the routing topology. So in a large, multicontinental
> >routing domain, the signalling for a single per domain agent may be just
> >as expensive as signalling directly to the corresponding nodes
> >and home agent.
> >
>
> But that would imply that the mobility agent assigned to the MN is
> probably not the optimum one. The idea is to reduce signaling and this
> can be accomplished if you have a mobility agent closer or at some
> optimum level in the network. So there is some engineering about where
> the mobility agent resides and I would think that in the case of an
> inter-continental routing domain, the mobility agent serving a MN
> would be somewhere close to the MN and the signaling would not have to
> traverse some undersea cables. And why would you believe there be only
> one domain agent in a large routing domain?

carefull here...we need differentiate between optimality over the reduction
of signalling and optimality over the location of the LMM agent. The reason?
the MNs velocity vector...

If you locate too close to the LMM then if the MN is moving with irregular
speeds then you would need to change your LMM too often...so although you
managed to save something on the signalling you threw it in the bin since you
have to perform LMM-agent change more often...

I don't think Jak refered to single LMM agents in a large routing
domain...quite the opposite but the MN is not stationary...the leg between
the LMM agent and the MN will be growing long...reaching base MIPv6 behaviour
(to some extent )...

We definetely need the spine of LMMs (i.e. hierarchy) so that we can traverse
over it and adjust that "leg". I think that is the beauty of multiple-level
hierarchy in an LMM..



>
>
> >In addition, changing a single top level agent requires the mobile to
> >signal a
> >regional care of address change to the home agent and all
> >corresponding nodes.
>
> But how often do you change a top-level agent? Irrespective of how
> many levels of hierarchy you have, if you change the top level agent,
> you will need to signal the HA and CNs. So if you are changing your
> top level agent every time you perform a hand off, then obviously
> there is something wrong with the location of the top-level agent.

surely not too often....otherwise we mush the LMM protocol...but you still
need that hierarchy...
to optimize the signalling between the LMMs..

>
>
> >It is therefore a heavyweight solution and
> >one that should not often be done, even if there is no reauthentication
> >involved. Making it the basis of dealing with load balancing is therefore
> >likely to lead to more signalling latency than if multiple levels
> >of LMM agents were allowed.
> >
>
> Multiple LMM agents are required no doubt, but do we really need
> multiple levels of these agents? I do agree with some of the examples
> you have provided of not limiting a hierarchy or ruling it out, but
> from a deployment perspective, I am not so sure...

IMHO I think that the deployment is what is all about...it may be painfull
(no doubt) to go through it
but I feel that it will pay off..

>
> >>> 2. Simplicity is good idea and a solution without hirarchy is
> >>> likely to
> >>>    be simpler, if not to implement to operate, than one with
> >>> a hirarchy.
> >>>
> >>
> >>Completely agree here Erik. I know there have been arguments for
> >>having a hierarchy, but I still do not totally get it.
> >>
> >
> >I'm all for simplicity, which is why I would like the requirements
> >to preclude preferences or other complex attributes that need
> >additional standardization. But, in this case, I think not allowing
> multiple
> >levels of LMM agents shuts out possible deployment scenarios that
> >I believe are realistic and will directly affect how well the
> >solution  fufills the fundamental requirement, namely localizing
> >signalling.
> >
> >               jak
> >
>
> I do not think we should rule out multiple levels of LMM agents from
> the requirements at this stage, but let's discuss the implications of
> a multi-level hierarchy from a routing, deployment, failure-point etc.
> perspective. Obviously there are quite a few people who feel quite
> strongly about it and to rule it out would be unwise.

Well that is what we have been doing for the last week or so..


Theo


UCL/ Mobile Systems



From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 20 17:03:13 2001
Received: from mercury.Sun.COM ([192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18017
	for ; Fri, 20 Apr 2001 17:03:12 -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 OAA02629;
	Fri, 20 Apr 2001 14:02: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 OAA12445;
	Fri, 20 Apr 2001 14:02:31 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3KL1FK9009559
	for ; Fri, 20 Apr 2001 14:01:15 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3KL1FXc009558
	for mobile-ip-dist; Fri, 20 Apr 2001 14:01: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3KL16K9009551
	for ; Fri, 20 Apr 2001 14:01: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 OAA10438
	for ; Fri, 20 Apr 2001 14:01:01 -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 PAA22726
	for ; Fri, 20 Apr 2001 15:54:42 -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 QAA27783
	for ; Fri, 20 Apr 2001 16:01:18 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Fri, 20 Apr 2001 15:55:24 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Fri, 20 Apr 2001 16:00:43 -0500
Message-ID: <85AA7486A2C1D411BCA20000F8073E4301F4B105@crchy271.us.nortel.com>
From: "Glenn Morrow" 
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Design teams for mobileip--(sharif)
Date: Fri, 20 Apr 2001 16:00:28 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0C9DC.EDD2B0D0"
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_01C0C9DC.EDD2B0D0
Content-Type: text/plain;
	charset="iso-8859-1"

Jim,

I really don't think the ADs are the problem. I think that the starting
requirements were the problem and people have continually avoiding issues
for the sake of getting a draft passed. i.e. let's wait until this becomes
an RFC before they even try to guage whether or not the requirement must be
handled. 

Now that we are discussing requirements, people are requirement shaping to
fit their pre-conceived solutions.

There are also competing access specific solutons that do meet many of the
requirements as best as they can because they could not change IP itself.
This WG is supposed to do that. I am actually beginning to be suspect of
some of the vendors in the WG of avoiding issues on purpose in order to
maximize the potential of revenues in terms of IPR and equipment sales from
these access specific solutions. Sometimes requirements are avoided because
the vendors want to sell even more hardware and software to the providers.
The MIP WG is a cellular industry turf-war. MIP is routers invading the
cellular real-estate market.

This is the ying and yang between the Industry, ADs, IESG, IAB and the MIP
WG - lack of communication, sabotage and delay due to business interests,
basic ignorance of ramifications shaded via mal-aligned ideological
reasoning and arrogance. 

I wouldn't blame it on the pawns too much; although, I don't see the IESG,
IAB and ADs as pawns but rather Bishops and Rooks. The people bantering over
the same issues for almost 9 years in the WG are the pawns.

If you believe an AD is at fault talk to them. I have found almost all of
them to be very insightful - even if I do not agree with their point of
view. 

I can't really see this as the problem. Getting a draft to RFC status is not
on my top priority. Getting the right solution is. 

I do not believe that this was the first time discussions about MIP and
security issues occurred? 

It is more likely that these issues were mass-hypnotically or ideologically
ignored; hardly a blindside. 

This is, of course, only IMOOCC (In My Opinion Of Constuctive Criticism) for
the group as an amorphous black-whole. This may not be seen as "positive"
but I do.


Thank You,

Glenn


-----Original Message-----
From: Jim Bound [mailto:seamus@bit-net.com]
Sent: Thursday, April 19, 2001 9:11 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Design teams for mobileip--(sharif)


thanks.  I know.  Back many years ago when Charlie and Dave came to IPv6
and presented the essential idea and I think draft 03 got most of what is
needed at that point.  Then the WG fixed the mobile parts to a fine tune.
Now we are just pontificating to the current spec of MIPv6.  Once we have
the answer to the security issue presented at IETF50 we should ship MIPv6
to PS and move on to all other subjects.  1993...man that is ridiculous by
anyones analysis and its not the WGs and authors fault.  I have seen this
in a few Areas.  I believe its usually the case of the authors initial
idea, the WG consensus idea, and the AD's idea.  The last part is the
problem.  The AD should not be providing "ideas" as AD but only as
individual WG member.  It causes them to have more power technically than
the rest of the WG.  This is plain wrong by any interpretation of the
founding IETF principles for this community.  It doesn't just happen in
MIP either.  The AD is only a MANAGER thats it. 

I for one am going be on things I see like this like a pit bull chasing a
meat truck.  Its another form of "bullying people".  And I have zero
tolerance for that and strong enough to tell them to stick it and record
it and use the recordings.  I am sure my drafts will suffer from these
comments to I am working on :----)

/jim

On Thu, 19 Apr 2001, Glenn Morrow wrote:

> I agree 100% with you Jim - something stinks in the MIP WG. This is why it
> has been going on since 1993 with minor progress.
> 
> -----Original Message-----
> From: Jim Bound [mailto:seamus@bit-net.com]
> Sent: Tuesday, April 17, 2001 2:29 PM
> To: mobile-ip@sunroof.eng.sun.com
> Subject: Re: [mobile-ip] Design teams for mobileip--(sharif)
> 
> 
> You did not respond to my previous issue with your appeal regarding 3GPP
> et al which I am not clear is valid or warranted.  But this one may have
> some meat here is why.
> 
> I am on two design teams to work problems and get back to the working
> groups here in the IETF (which ones are not relevent).  We formed these
> teams "for" the working groups and asked for volunteers.  The list is
> closed because the "design team" wanted it closed and the working group
> does not care.
> 
> But in the case where a team is formed and the management team in the IETF
> did not ask for volunteers from the working group then that is a closed
> process because when the management team makes such decisions it is a
> formal process.  As opposed to working group members going off and solving
> a problem which is 'ad hoc'.  To then close that formal list is insult to
> injury at a minimum to get input from the working group at a minimum.
> 
> Then the other problem with this for your appeal is as follows.  Why were
> certain people put on this closed team and not others.  What
> "discrimination" was used to determine who was part of this formal
> process.  Was it fair discrimination to the working group as a whole?
> 
> This is a classic example of why the good-ole-boy-network needs fixing.
> 
> It is a bad precedent and I believe could potentially cause a legal
> problem to the IETF which is the last thing we need here.  In a private
> company,  private entity, or academic/research centers this is done often
> and valid, but this is the IETF the open process for open standards.
> 
> I also understand that authors are not part of the design teams?  How was
> that discrimination arrived at and seems not wise to me?
> 
> But then maybe there are perfect reasonable explanations for the above?
> 
> regards,
> /jim
> 
> On Tue, 17 Apr 2001, Phil Neumiller wrote:
> 
> > I guess this is another item to add to my appeal.  I believe this is
> > setting a bad precedent for the IETF.
> > 
> > Thanks,
> > 
> > Phil
> > ----- Original Message -----
> > From: "Phil Roberts" 
> > To: 
> > Sent: Tuesday, April 17, 2001 12:08 PM
> > Subject: RE: [mobile-ip] Design teams for mobileip--(sharif)
> > 
> > 
> > > Both fast handoff lists were open to begin with but due to some
concerns
> > > about the ability to make progress the ADs asked us to close them, so
we
> > > did.  The archives will be made public when the teams are done.
> Versions of
> > > each draft have been published and you are welcome to comment on them
on
> the
> > > main list.
> > >
> > 
> > >
> > 
> > 
> 
> 


------_=_NextPart_001_01C0C9DC.EDD2B0D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [mobile-ip] Design teams for mobileip--(sharif)




Jim,




I really don't think the ADs are the problem. I think =
that the starting requirements were the problem and people have =
continually avoiding issues for the sake of getting a draft passed. =
i.e. let's wait until this becomes an RFC before they even try to guage =
whether or not the requirement must be handled. 



Now that we are discussing requirements, people are =
requirement shaping to fit their pre-conceived solutions.




There are also competing access specific solutons =
that do meet many of the requirements as best as they can because they =
could not change IP itself. This WG is supposed to do that. I am =
actually beginning to be suspect of some of the vendors in the WG of =
avoiding issues on purpose in order to maximize the potential of =
revenues in terms of IPR and equipment sales from these access specific =
solutions. Sometimes requirements are avoided because the vendors want =
to sell even more hardware and software to the providers. The MIP WG is =
a cellular industry turf-war. MIP is routers invading the cellular =
real-estate market.



This is the ying and yang between the Industry, ADs, =
IESG, IAB and the MIP WG - lack of communication, sabotage and delay =
due to business interests, basic ignorance of ramifications shaded via =
mal-aligned ideological reasoning and arrogance. 



I wouldn't blame it on the pawns too much; although, =
I don't see the IESG, IAB and ADs as pawns but rather Bishops and =
Rooks. The people bantering over the same issues for almost 9 years in =
the WG are the pawns.



If you believe an AD is at fault talk to them. I have =
found almost all of them to be very insightful - even if I do not agree =
with their point of view. 



I can't really see this as the problem. Getting a =
draft to RFC status is not on my top priority. Getting the right =
solution is. 



I do not believe that this was the first time =
discussions about MIP and security issues occurred? 




It is more likely that these issues were =
mass-hypnotically or ideologically ignored; hardly a blindside. 




This is, of course, only IMOOCC (In My Opinion Of =
Constuctive Criticism) for the group as an amorphous black-whole. This =
may not be seen as "positive" but I do.





Thank You,




Glenn






-----Original Message-----

From: Jim Bound [mailto:seamus@bit-net.com]=


Sent: Thursday, April 19, 2001 9:11 PM

To: mobile-ip@sunroof.eng.sun.com

Subject: RE: [mobile-ip] Design teams for =
mobileip--(sharif)






thanks.  I know.  Back many years ago when =
Charlie and Dave came to IPv6

and presented the essential idea and I think draft =
03 got most of what is

needed at that point.  Then the WG fixed the =
mobile parts to a fine tune.

Now we are just pontificating to the current spec of =
MIPv6.  Once we have

the answer to the security issue presented at IETF50 =
we should ship MIPv6

to PS and move on to all other subjects.  =
1993...man that is ridiculous by

anyones analysis and its not the WGs and authors =
fault.  I have seen this

in a few Areas.  I believe its usually the case =
of the authors initial

idea, the WG consensus idea, and the AD's =
idea.  The last part is the

problem.  The AD should not be providing =
"ideas" as AD but only as

individual WG member.  It causes them to have =
more power technically than

the rest of the WG.  This is plain wrong by any =
interpretation of the

founding IETF principles for this community.  =
It doesn't just happen in

MIP either.  The AD is only a MANAGER thats it. =





I for one am going be on things I see like this like =
a pit bull chasing a

meat truck.  Its another form of "bullying =
people".  And I have zero

tolerance for that and strong enough to tell them to =
stick it and record

it and use the recordings.  I am sure my drafts =
will suffer from these

comments to I am working on :----)




/jim




On Thu, 19 Apr 2001, Glenn Morrow wrote:




> I agree 100% with you Jim - something stinks in =
the MIP WG. This is why it

> has been going on since 1993 with minor =
progress.

> 

> -----Original Message-----

> From: Jim Bound [mailto:seamus@bit-net.com]=


> Sent: Tuesday, April 17, 2001 2:29 PM

> To: mobile-ip@sunroof.eng.sun.com

> Subject: Re: [mobile-ip] Design teams for =
mobileip--(sharif)

> 

> 

> You did not respond to my previous issue with =
your appeal regarding 3GPP

> et al which I am not clear is valid or =
warranted.  But this one may have

> some meat here is why.

> 

> I am on two design teams to work problems and =
get back to the working

> groups here in the IETF (which ones are not =
relevent).  We formed these

> teams "for" the working groups and =
asked for volunteers.  The list is

> closed because the "design team" =
wanted it closed and the working group

> does not care.

> 

> But in the case where a team is formed and the =
management team in the IETF

> did not ask for volunteers from the working =
group then that is a closed

> process because when the management team makes =
such decisions it is a

> formal process.  As opposed to working =
group members going off and solving

> a problem which is 'ad hoc'.  To then =
close that formal list is insult to

> injury at a minimum to get input from the =
working group at a minimum.

> 

> Then the other problem with this for your =
appeal is as follows.  Why were

> certain people put on this closed team and not =
others.  What

> "discrimination" was used to =
determine who was part of this formal

> process.  Was it fair discrimination to =
the working group as a whole?

> 

> This is a classic example of why the =
good-ole-boy-network needs fixing.

> 

> It is a bad precedent and I believe could =
potentially cause a legal

> problem to the IETF which is the last thing we =
need here.  In a private

> company,  private entity, or =
academic/research centers this is done often

> and valid, but this is the IETF the open =
process for open standards.

> 

> I also understand that authors are not part of =
the design teams?  How was

> that discrimination arrived at and seems not =
wise to me?

> 

> But then maybe there are perfect reasonable =
explanations for the above?

> 

> regards,

> /jim

> 

> On Tue, 17 Apr 2001, Phil Neumiller =
wrote:

> 

> > I guess this is another item to add to my =
appeal.  I believe this is

> > setting a bad precedent for the =
IETF.

> > 

> > Thanks,

> > 

> > Phil

> > ----- Original Message -----

> > From: "Phil Roberts" =
<PRoberts@MEGISTO.com>

> > To: =
<mobile-ip@sunroof.eng.sun.com>

> > Sent: Tuesday, April 17, 2001 12:08 =
PM

> > Subject: RE: [mobile-ip] Design teams for =
mobileip--(sharif)

> > 

> > 

> > > Both fast handoff lists were open to =
begin with but due to some concerns

> > > about the ability to make progress =
the ADs asked us to close them, so we

> > > did.  The archives will be made =
public when the teams are done.

> Versions of

> > > each draft have been published and =
you are welcome to comment on them on

> the

> > > main list.

> > >

> > 

> > >

> > 

> > 

> 

> 





------_=_NextPart_001_01C0C9DC.EDD2B0D0--


From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 20 21:02: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 VAA20595
	for ; Fri, 20 Apr 2001 21:02:57 -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 SAA20025;
	Fri, 20 Apr 2001 18:02: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 SAA18811;
	Fri, 20 Apr 2001 18:02:12 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3L10aK9009959
	for ; Fri, 20 Apr 2001 18:00:36 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3L10aNf009958
	for mobile-ip-dist; Fri, 20 Apr 2001 18:00: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 bebop.france (bebop.France.Sun.COM [129.157.174.15] (may be forged))
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3L10QK9009951
	for ; Fri, 20 Apr 2001 18:00:27 -0700 (PDT)
Received: from lillen (hobo123.Eng.Sun.COM [129.146.31.123])
	by bebop.france (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id DAA23997;
	Sat, 21 Apr 2001 03:00:20 +0200 (MET DST)
Date: Fri, 20 Apr 2001 18:00:13 -0700 (PDT)
From: Erik Nordmark 
Subject: RE: [mobile-ip] Revised Localized Mobility Management Requirement s
To: Jim Bound 
Cc: mobile-ip@sunroof.eng.sun.com, Erik.Nordmark@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: 

> hierarchy permits distributing the problem set across that graph and a
> vechicle to provide another level of indirection as required.  This gives
> us the capability to address the scalability as Erik points out.  Load

Jim,

note my clarification that I'm not advocating that we need an
hirarchy for scalability. I'm just 1) trying to understand the
arguments/requirements and 2) sort out in my head how we can
compare the different type of fruit.
(Trading off e.g. the simplicity of no hirarchy against the flexibility
possible with an hirarchy.)

  Erik



From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 20 21:03:52 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 VAA20635
	for ; Fri, 20 Apr 2001 21:03: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 SAA20444;
	Fri, 20 Apr 2001 18:03: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 SAA28555;
	Fri, 20 Apr 2001 18:03:20 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3L12CK9009969
	for ; Fri, 20 Apr 2001 18:02:12 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3L12B6q009968
	for mobile-ip-dist; Fri, 20 Apr 2001 18:02:11 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3L121K9009961
	for ; Fri, 20 Apr 2001 18:02:01 -0700 (PDT)
Received: from lillen (hobo123.Eng.Sun.COM [129.146.31.123])
	by bebop.france (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id DAA24116;
	Sat, 21 Apr 2001 03:01:55 +0200 (MET DST)
Date: Fri, 20 Apr 2001 18:01:19 -0700 (PDT)
From: Erik Nordmark 
Subject: RE: [mobile-ip] Revised Localized Mobility Management Requirement s
To: Basavaraj.Patil@nokia.com
Cc: mobile-ip@sunroof.eng.sun.com, Erik.Nordmark@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: 

> > Basically I see two approaches and I don't know how to resolve them:
> > 1. A domain might be huge (for whatever reason) hence for 
> > scaling reasons
> >    you need to be capable of having a arbirarely deep 
> > hirarchy of agents.
> 
> Why? Would this not work just as well with a single level of hierarchy,
> but one where there are multiple top level agents, i.e a distributed
> set of top-level agents which can load balance if that is a concern.

I don't know why - others are making claims like the above - I'm just
trying to understand how the different types of claims based on
different approaches to costructing requirement can be resolved.

Sorry for not making that clear up front.

  Erik




From owner-mobile-ip@sunroof.eng.sun.com  Sat Apr 21 14:23: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 OAA11644
	for ; Sat, 21 Apr 2001 14:23: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 LAA13599;
	Sat, 21 Apr 2001 11:22: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 LAA03549;
	Sat, 21 Apr 2001 11:22:38 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3LILQK9010587
	for ; Sat, 21 Apr 2001 11:21:26 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3LILP6f010586
	for mobile-ip-dist; Sat, 21 Apr 2001 11:21: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3LILEK9010579
	for ; Sat, 21 Apr 2001 11:21:17 -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 LAA03450
	for ; Sat, 21 Apr 2001 11:21:14 -0700 (PDT)
Received: from fep09-svc.tin.it (mta09-acc.tin.it [212.216.176.40])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA27133
	for ; Sat, 21 Apr 2001 11:21:13 -0700 (PDT)
Received: from pivendi ([212.171.216.10]) by fep09-svc.tin.it
          (InterMail vM.4.01.03.13 201-229-121-113) with SMTP
          id <20010421182111.PQDJ7098.fep09-svc.tin.it@pivendi>
          for ;
          Sat, 21 Apr 2001 20:21:11 +0200
Message-ID: <013101d737a4$c913c800$0ad8abd4@pivendi>
From: "pieracarlo venditti" 
To: 
Subject: [mobile-ip] a doubt about MIP
Date: Thu, 22 Apr 2021 20:24:47 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_012C_01D737B5.89D40220"
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
Sender: owner-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_012C_01D737B5.89D40220
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,
I'm an italian student, I studied RFC2002 but I've a doubt about Mobile =
IP protocol: if Mobile Node assumes that it has lost contact with its =
agent and it recives two new Advertisements, I don't understand if it =
attempts registration with the two Foreign Agents  sending the two new =
Advertisements or it attempts registration with only one of them and if =
it is so with which of them?
Thanks in advance
Carlo

------=_NextPart_000_012C_01D737B5.89D40220
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









Hello,


I'm an italian student, I studied =
RFC2002 but I've=20
a doubt about Mobile IP protocol: if Mobile Node assumes that it has =
lost=20
contact with its agent and it recives two new Advertisements, I don't =
understand=20
if it attempts registration with the two Foreign Agents  sending =
the two=20
new Advertisements or it attempts registration with only one of them and =
if it=20
is so with which of them?


Thanks in advance


Carlo


------=_NextPart_000_012C_01D737B5.89D40220--



From owner-mobile-ip@sunroof.eng.sun.com  Sat Apr 21 14:49: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 OAA11758
	for ; Sat, 21 Apr 2001 14:49: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 LAA18145;
	Sat, 21 Apr 2001 11:48:50 -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 LAA18951;
	Sat, 21 Apr 2001 11:48:45 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3LIlYK9010620
	for ; Sat, 21 Apr 2001 11:47:34 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3LIlXnC010619
	for mobile-ip-dist; Sat, 21 Apr 2001 11:47: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3LIlMK9010612
	for ; Sat, 21 Apr 2001 11:47:24 -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 LAA04599
	for ; Sat, 21 Apr 2001 11:47:22 -0700 (PDT)
Received: from artemis.shef.ac.uk (artemis.shef.ac.uk [143.167.2.11])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA01984
	for ; Sat, 21 Apr 2001 11:47:21 -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 14r2Pc-0007W7-00
	for mobile-ip@sunroof.eng.sun.com; Sat, 21 Apr 2001 19:47:16 +0100
Received: from ridingwood.shef.ac.uk ([143.167.59.249])
	by mailhub1.shef.ac.uk with esmtp (Exim 3.22 #3)
	id 14r2Pb-0005WP-00
	for mobile-ip@sunroof.eng.sun.com; Sat, 21 Apr 2001 19:47:15 +0100
Received: from RIDINGWOOD/SpoolDir by ridingwood.shef.ac.uk (Mercury 1.48);
    21 Apr 01 19:47:17 +0100
Received: from SpoolDir by RIDINGWOOD (Mercury 1.48); 21 Apr 01 19:47:11 +0100
Received: from borg (143.167.251.68) by ridingwood.shef.ac.uk (Mercury 1.48);
    21 Apr 01 19:47:08 +0100
Message-ID: <000901c0ca93$7b8bd9e0$44fba78f@borg>
From: "cny" 
To: 
References: <013101d737a4$c913c800$0ad8abd4@pivendi>
Subject: Re: [mobile-ip] a doubt about MIP
Date: Sat, 21 Apr 2001 20:47:14 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0006_01C0CAA4.3F06EE40"
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 *14r2Pc-0007W7-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_0006_01C0CAA4.3F06EE40
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi=20

It really depend on implementations.
That is movement detection methods.

1) Lazy Cell Switching
if the mobile node loses 3 advertisements, it will then use the first =
advertisment it receives.
2.5 sec delay if each advertisment is sent once per seconds.

2) Eager Cell Switching
Every advertisment the mobile node receives, it will used the =
advertisment under that mobile agent.
0.5 sec delay if each advertisment is sent once per seconds.

3) Prefixed Matching
Handoffs depending upon a different prefix advertisment the mobile node =
receives.
0.5 sec delay if each advertisment is sent once per seconds.

May i know what are you doing for your project then???? :)

Cheers
Chern Nam Yap





  ----- Original Message -----=20
  From: pieracarlo venditti=20
  To: mobile-ip@sunroof.eng.sun.com=20
  Sent: Thursday, April 22, 2021 8:24 PM
  Subject: [mobile-ip] a doubt about MIP


  Hello,
  I'm an italian student, I studied RFC2002 but I've a doubt about =
Mobile IP protocol: if Mobile Node assumes that it has lost contact with =
its agent and it recives two new Advertisements, I don't understand if =
it attempts registration with the two Foreign Agents  sending the two =
new Advertisements or it attempts registration with only one of them and =
if it is so with which of them?
  Thanks in advance
  Carlo



------=_NextPart_000_0006_01C0CAA4.3F06EE40
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









Hi 


 


It really depend on =
implementations.


That is movement detection =
methods.


 


1) Lazy Cell Switching


if the mobile node loses 3 =
advertisements, it will=20
then use the first advertisment it receives.


2.5 sec delay if each advertisment is =
sent once per=20
seconds.


 


2) Eager Cell Switching


Every advertisment the mobile=20
node receives, it will used the advertisment under=20
that mobile agent.


0.5 sec delay if each advertisment =
is sent=20
once per seconds.


 


3) Prefixed Matching


Handoffs depending upon a=20
different prefix advertisment the mobile=20
node receives.


0.5 sec delay if each advertisment =
is sent=20
once per seconds.


 


May i know what are you doing for your =
project=20
then???? :)


 


Cheers


Chern Nam Yap


 


 


 


 


 



  
----- Original Message ----- 

  From:=20
  pieracarlo =
venditti=20
  
  
To: mobile-ip@sunroof.eng.sun.c=
om=20
  

  
Sent: Thursday, April 22, 2021 =
8:24=20
  PM

  
Subject: [mobile-ip] a doubt =
about=20
  MIP

  


  
Hello,

  
I'm an italian student, I studied =
RFC2002 but=20
  I've a doubt about Mobile IP protocol: if Mobile Node assumes that it =
has lost=20
  contact with its agent and it recives two new Advertisements, I don't=20
  understand if it attempts registration with the two Foreign =
Agents =20
  sending the two new Advertisements or it attempts registration with =
only one=20
  of them and if it is so with which of them?

  
Thanks in advance

  
Carlo

  
 

  
 


------=_NextPart_000_0006_01C0CAA4.3F06EE40--



From owner-mobile-ip@sunroof.eng.sun.com  Sat Apr 21 15:03:00 2001
Received: from mercury.Sun.COM ([192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11831
	for ; Sat, 21 Apr 2001 15:02:59 -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 MAA29647;
	Sat, 21 Apr 2001 12:02: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 MAA19480;
	Sat, 21 Apr 2001 12:02:24 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3LJ1HK9010645
	for ; Sat, 21 Apr 2001 12:01:17 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3LJ1GBD010644
	for mobile-ip-dist; Sat, 21 Apr 2001 12:01: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3LJ16K9010637
	for ; Sat, 21 Apr 2001 12:01:08 -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 MAA11512
	for ; Sat, 21 Apr 2001 12:01:05 -0700 (PDT)
Received: from taku.hut.fi (taku.hut.fi [130.233.228.87])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21137
	for ; Sat, 21 Apr 2001 12:01:04 -0700 (PDT)
Received: from gamma.hut.fi (tweckstr@gamma.hut.fi [130.233.224.52])
	by taku.hut.fi (8.9.3/8.9.3) with ESMTP id WAA08498
	for ; Sat, 21 Apr 2001 22:01:03 +0300 (EET DST)
Date: Sat, 21 Apr 2001 22:01:02 +0300 (EET DST)
From: =?ISO-8859-1?Q?Tom_Weckstr=F6m?= 
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] a doubt about MIP
In-Reply-To: <013101d737a4$c913c800$0ad8abd4@pivendi>
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 mercury.Sun.COM id MAA29647
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA11831

Hello.

On Thu, 22 Apr 2021, pieracarlo venditti wrote:

pieven >Hello,
pieven >I'm an italian student, I studied RFC2002 but I've a doubt about Mobile IP protocol: if Mobile Node assumes that it has lost contact with its agent and it recives two new Advertisements, I don't understand if it attempts registration with the two Foreign Agents  sending the two new Advertisements or it attempts registration with only one of them and if it is so with which of them?
pieven >Thanks in advance
pieven >Carlo
pieven >

The previously presented three possible methods are one way to explain
what could happen.

Another way to make sure the connection is maintained and the handofver is
as smooth as possible is to combine WLAN link layer information such as
link quality to the MNs registration decision.

For example, Dynamics HUT Mobile IP has different policies that affect the
way the MN makes registration decisions according to received agent
advertisements and WLAN link quality. More info from Dyanmics web site and
our publications.

	Tom

-- 
	Tom Weckström		Dynamics group
				Helsinki University of Technology
				dynamics@cs.hut.fi
				http://www.cs.hut.fi/Research/Dynamics/



From owner-mobile-ip@sunroof.eng.sun.com  Sun Apr 22 04:28: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 EAA07658
	for ; Sun, 22 Apr 2001 04:28: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 BAA29323;
	Sun, 22 Apr 2001 01: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 BAA25244;
	Sun, 22 Apr 2001 01:27:42 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3M8PmK9011020
	for ; Sun, 22 Apr 2001 01:25:48 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3M8PmEa011019
	for mobile-ip-dist; Sun, 22 Apr 2001 01:25: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3M8PYK9011012
	for ; Sun, 22 Apr 2001 01:25:37 -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 BAA09985
	for ; Sun, 22 Apr 2001 01:25:23 -0700 (PDT)
Received: from relay4.inwind.it (relay4.inwind.it [212.141.53.75])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA24969
	for ; Sun, 22 Apr 2001 01:25:14 -0700 (PDT)
Received: from annozero (62.98.201.99) by relay4.inwind.it (5.5.025)
        id 3ACAF5250034DA46 for mobile-ip@sunroof.eng.sun.com; Sun, 22 Apr 2001 10:25:13 +0200
Message-ID: <003801c0cb05$dc736940$63c9623e@annozero>
From: "Pugini Fabio" 
To: 
References: <013101d737a4$c913c800$0ad8abd4@pivendi> <000901c0ca93$7b8bd9e0$44fba78f@borg>
Subject: Re: [mobile-ip] a doubt about MIP
Date: Sun, 22 Apr 2001 10:25:52 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0035_01C0CB16.9BD4AFA0"
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: 

Messaggio in formato MIME composto da piy parti.

------=_NextPart_000_0035_01C0CB16.9BD4AFA0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi
To be sincere, I think Piercarlo meant something different (I know that =
since we discussed about this topic few days ago). Our doubt is: what =
happens if a mobile node, which detects that it has just moved into a =
new Visited Network (by means of LCS or ECS or Pre-Matching =
indiferently), receives two or more advertisement in a very small =
time-interval (I mean before the registration), because it moved in a =
overlapping coverage areas of many BS? We thought that two possibility =
are available:
1) It keeps on sending registartion requests until it registers with a =
new Foreign Agent, that is until the first confirmation is received (not =
necessarily the one relevant to the first advertisement sent). In this =
case: What happens to the following confirmations that will soon arrive? =
Will they be ignored or will they be considered (than the node will =
switch to new foreign agents and finally register with the "last" one)?
2) It sends the first registration request and starts waiting for the =
relevant confirmation without sending any other registr. requests. (this =
seems to me to be  a very strange, and nowhere explained, approach).

Any help in understanding this operation will be highily appriciated.


In order to answer to last Chern Nam Yap's question, I can say that =
Piercarlo and I (we are students) are trying to analize the Mobile IP =
advertisement/registration way of operation. In the abovementioned first =
option (when  the mobile node considers all the registration =
confirmation it receives), we envision some delay/loss issues.
Best Regards
  ----- Original Message -----=20
  From: cny=20
  To: mobile-ip@sunroof.eng.sun.com=20
  Sent: Saturday, April 21, 2001 8:47 PM
  Subject: Re: [mobile-ip] a doubt about MIP


  Hi=20

  It really depend on implementations.
  That is movement detection methods.

  1) Lazy Cell Switching
  if the mobile node loses 3 advertisements, it will then use the first =
advertisment it receives.
  2.5 sec delay if each advertisment is sent once per seconds.

  2) Eager Cell Switching
  Every advertisment the mobile node receives, it will used the =
advertisment under that mobile agent.
  0.5 sec delay if each advertisment is sent once per seconds.

  3) Prefixed Matching
  Handoffs depending upon a different prefix advertisment the mobile =
node receives.
  0.5 sec delay if each advertisment is sent once per seconds.

  May i know what are you doing for your project then???? :)

  Cheers
  Chern Nam Yap





    ----- Original Message -----=20
    From: pieracarlo venditti=20
    To: mobile-ip@sunroof.eng.sun.com=20
    Sent: Thursday, April 22, 2021 8:24 PM
    Subject: [mobile-ip] a doubt about MIP


    Hello,
    I'm an italian student, I studied RFC2002 but I've a doubt about =
Mobile IP protocol: if Mobile Node assumes that it has lost contact with =
its agent and it recives two new Advertisements, I don't understand if =
it attempts registration with the two Foreign Agents  sending the two =
new Advertisements or it attempts registration with only one of them and =
if it is so with which of them?
    Thanks in advance
    Carlo



------=_NextPart_000_0035_01C0CB16.9BD4AFA0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









Hi


To be sincere, I think Piercarlo meant =
something=20
different (I know that since we discussed about this topic few days =
ago). Our=20
doubt is: what happens if a mobile node, which detects that it has just =
moved=20
into a new Visited Network (by means of LCS or ECS or Pre-Matching=20
indiferently), receives two or more advertisement in a very small =
time-interval=20
(I mean before the registration), because it moved in a overlapping =
coverage=20
areas of many BS? We thought that two possibility are =
available:


1) It keeps on sending registartion=20
requests until it registers with =
a new=20
Foreign Agent, that is until the first confirmation is received (not =
necessarily=20
the one relevant to the first advertisement sent). In this case: What =
happens to=20
the following confirmations that will soon arrive? Will they be ignored =
or will=20
they be considered (than the node will switch to new foreign agents and =
finally=20
register with the "last" one)?


2) It sends the first registration =
request and=20
starts waiting for the relevant confirmation without sending any other =
registr.=20
requests. (this seems to me to be  a very strange, and nowhere =
explained,=20
approach).


 


Any help in understanding this =
operation will be=20
highily appriciated.


 


 


In order to answer to last Chern Nam Yap's question, I can say that Piercarlo and I (we =
are=20
students) are trying to analize the Mobile IP advertisement/registration =
way of=20
operation. In the abovementioned first option (when  the =
mobile node=20
considers all the registration confirmation it receives), we envision =
some=20
delay/loss issues.


Best Regards



  
----- Original Message ----- 

  From:=20
  cny 
  
To: mobile-ip@sunroof.eng.sun.c=
om=20
  

  
Sent: Saturday, April 21, 2001 =
8:47=20
  PM

  
Subject: Re: [mobile-ip] a =
doubt about=20
  MIP

  


  
Hi 

  
 

  
It really depend on =
implementations.

  
That is movement detection =
methods.

  
 

  
1) Lazy Cell Switching

  
if the mobile node loses 3 =
advertisements, it=20
  will then use the first advertisment it receives.

  
2.5 sec delay if each advertisment is =
sent once=20
  per seconds.

  
 

  
2) Eager Cell Switching

  
Every advertisment the mobile=20
  node receives, it will used the advertisment under =

  that mobile agent.

  
0.5 sec delay if each =
advertisment is sent=20
  once per seconds.

  
 

  
3) Prefixed Matching

  
Handoffs depending upon a=20
  different prefix advertisment the mobile=20
  node receives.

  
0.5 sec delay if each =
advertisment is sent=20
  once per seconds.

  
 

  
May i know what are you doing for =
your project=20
  then???? :)

  
 

  
Cheers

  
Chern Nam Yap

  
 

  
 

  
 

  
 

  
 

  

    
----- Original Message ----- 

    From:=20
    pieracarlo=20
    venditti 
    
To: mobile-ip@sunroof.eng.sun.c=
om=20
    

    
Sent: Thursday, April 22, =
2021 8:24=20
    PM

    
Subject: [mobile-ip] a doubt =
about=20
    MIP

    


    
Hello,

    
I'm an italian student, I studied =
RFC2002 but=20
    I've a doubt about Mobile IP protocol: if Mobile Node assumes that =
it has=20
    lost contact with its agent and it recives two new Advertisements, I =
don't=20
    understand if it attempts registration with the two Foreign =
Agents =20
    sending the two new Advertisements or it attempts registration with =
only one=20
    of them and if it is so with which of them?

    
Thanks in advance

    
Carlo

    
 

    
 


------=_NextPart_000_0035_01C0CB16.9BD4AFA0--



From owner-mobile-ip@sunroof.eng.sun.com  Sun Apr 22 10:29: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 KAA09098
	for ; Sun, 22 Apr 2001 10:29:11 -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 HAA22601;
	Sun, 22 Apr 2001 07:26: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 HAA01265;
	Sun, 22 Apr 2001 07:26:30 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3MENRK9011239
	for ; Sun, 22 Apr 2001 07:23:27 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3MENRGF011238
	for mobile-ip-dist; Sun, 22 Apr 2001 07:23:27 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3MENFK9011231
	for ; Sun, 22 Apr 2001 07:23:18 -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 HAA10516
	for ; Sun, 22 Apr 2001 07:23:16 -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 HAA00152
	for ; Sun, 22 Apr 2001 07:23:14 -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 f3MENDN01798
	for ; Sun, 22 Apr 2001 16:23:13 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Sun Apr 22 16:23:13 2001 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Sun, 22 Apr 2001 16:18:36 +0200
Message-ID: 
From: "Karim El-Malki (ERA)" 
To: "'James Kempf '" ,
        "'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)
Date: Sun, 22 Apr 2001 16:23:12 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
List-Subscribe: 
List-Unsubscribe: 
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 Raj and James

>>I do not think we should rule out multiple levels of LMM agents from
>>the requirements at this stage, but let's discuss the implications of
>>a multi-level hierarchy from a routing, deployment, failure-point etc.
>>perspective. Obviously there are quite a few people who feel quite
>>strongly about it and to rule it out would be unwise. 
>>
>
>Ulimately, the issue is one of deployment. The worst possible case
>is we cycle an LMM protocol without multiple levels of hierarchy
>to proposed and discover during deployment that we need it. 

We have been trying to identify what applications require multiple
levels of local agents (MAPs) linked to each other. This requirement
is still not clear to me, but I wouldn't rule out that we can
agree on reasons with more discussion.

What I would not like to see is a design which is made more
complex (and introduces multiple points of failure) solely to be
optimised for a special case of a hierarchy in which one BU is passed
on between mobility agents (MAPs). At least, this is what I'm
questioning. In fact the current WG draft (HMIPv6) does not rule out a
MAP hierarchy, but considers mostly a MN using one MAP. The v4 WG
draft (Regional Reg) also considers a 2-level hierarchy (one GFA
with one level of FAs below it) but allows multiple levels. Of
course, in v6 there can be multiple levels of ARs between MN and local
agent. As Raj wrote in a previous email, it is possible to have agents
(MAPs) located at different "levels" and the MN can use or be made to
use the appropriate one. These can be, but do not have to be necessarily
linked to each other. If packets need to be forwarded between local
agents, the MN can send appropriate BUs to the individual agents and
create a MAP hierarchy. This is allowed in the current draft and we can
work on further optimisations. It's need however is still being discussed.
I just wanted to clarify this point.

Regards
/Karim


From owner-mobile-ip@sunroof.eng.sun.com  Sun Apr 22 15:30: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 PAA12593
	for ; Sun, 22 Apr 2001 15:30:40 -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 MAA14434;
	Sun, 22 Apr 2001 12:29: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 MAA23626;
	Sun, 22 Apr 2001 12:29:43 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3MJSTK9011449
	for ; Sun, 22 Apr 2001 12:28:29 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3MJST73011448
	for mobile-ip-dist; Sun, 22 Apr 2001 12:28: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3MJSKK9011440
	for ; Sun, 22 Apr 2001 12:28:20 -0700 (PDT)
Received: from awe171-106 (awe195-141.AWE.Sun.COM [192.29.195.141])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id MAA12878;
	Sun, 22 Apr 2001 12:28:18 -0700 (PDT)
Message-Id: <200104221928.MAA12878@heliopolis.eng.sun.com>
Date: Sun, 22 Apr 2001 11:20:47 -0700 (PDT)
From: kempf 
Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L  ocalized Mobility Management Requirement s)
To: James.Kempf@Sun.COM, mobile-ip@sunroof.eng.sun.com,
        Basavaraj.Patil@nokia.com, Karim.El-Malki@era.ericsson.se
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: wSDCYo+3+UNq6gY3N40H1Q==
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: 

Hi Karim,

>We have been trying to identify what applications require multiple
>levels of local agents (MAPs) linked to each other. This requirement
>is still not clear to me, but I wouldn't rule out that we can
>agree on reasons with more discussion.
>

I think we could talk about various reasons for several months and
not agree that any of them were compelling enough, from your point
of view, to include hierarchy. 

The strongest reason I can see is one of trying to avoid suprise.
If we do not include hierarchy and it becomes necessary during deployment, then 
we end up having to recycle to proposed standard, delaying adoption. On the 
other hand, if we do include hierarchy and it doesn't get used, then there
is just a feature there which nobody uses. Naturally including hierarchy makes 
the design somewhat more complex, but I think that can be minimized if the
design is done properly. This is what I was trying to get at at the
WG meeting in Minneapolis, but, unfortunately, wasn't able to clearly
articulate it.

I'm actually speaking from experience here, having been involved in
a standard that needed to be so recycled.

>What I would not like to see is a design which is made more
>complex (and introduces multiple points of failure) solely to be
>optimised for a special case of a hierarchy in which one BU is passed
>on between mobility agents (MAPs). At least, this is what I'm
>questioning.

I presume you are referring to the RRv6 design? I don't think anybody
is proposing that this design be normative for the hierarchy
requirement. If you like, we can adopt a requirement concerning the
interaction between multiple levels that rules out extraneous signalling. 

>In fact the current WG draft (HMIPv6) does not rule out a
>MAP hierarchy, but considers mostly a MN using one MAP. The v4 WG
>draft (Regional Reg) also considers a 2-level hierarchy (one GFA
>with one level of FAs below it) but allows multiple levels. Of
>course, in v6 there can be multiple levels of ARs between MN and local
>agent. As Raj wrote in a previous email, it is possible to have agents
>(MAPs) located at different "levels" and the MN can use or be made to
>use the appropriate one. These can be, but do not have to be necessarily
>linked to each other. If packets need to be forwarded between local
>agents, the MN can send appropriate BUs to the individual agents and
>create a MAP hierarchy. This is allowed in the current draft and we can
>work on further optimisations. It's need however is still being discussed.
>I just wanted to clarify this point.
>

OK.

		jak



From owner-mobile-ip@sunroof.eng.sun.com  Sun Apr 22 16:55:07 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13489
	for ; Sun, 22 Apr 2001 16:55: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 NAA19778;
	Sun, 22 Apr 2001 13:54: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 NAA18701;
	Sun, 22 Apr 2001 13:54:16 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3MKr4K9011570
	for ; Sun, 22 Apr 2001 13:53:04 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3MKr417011569
	for mobile-ip-dist; Sun, 22 Apr 2001 13:53: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3MKqpK9011559
	for ; Sun, 22 Apr 2001 13:52: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 NAA18647
	for ; Sun, 22 Apr 2001 13:52:51 -0700 (PDT)
Received: from fep23-svc.tin.it (mta23-acc.tin.it [212.216.176.76])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA02837
	for ; Sun, 22 Apr 2001 13:52:49 -0700 (PDT)
Received: from pivendi ([212.171.211.200]) by fep23-svc.tin.it
          (InterMail vM.4.01.03.13 201-229-121-113) with SMTP
          id <20010422205247.VGZR23027.fep23-svc.tin.it@pivendi>
          for ;
          Sun, 22 Apr 2001 22:52:47 +0200
Message-ID: <001401d73883$216298e0$c8d3abd4@pivendi>
From: "pieracarlo venditti" 
To: 
Subject: [mobile-ip] problem  about  Mobile IP
Date: Fri, 23 Apr 2021 22:56:22 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000F_01D73893.E151C760"
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
Sender: owner-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_000F_01D73893.E151C760
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,=20
I'm an italian student, I read RFC2002 but my doubt is : what happens if =
a mobile node, which detects that it has just moved into a new Visited =
Network (by means of LCS or ECS ),recives two or more advertisemsnt in a =
very small time-interval (I mean before the registration), because it =
moved in a overlapping coverage areas of many BS? I thought that two =
possibility are available:
1) It keeps on sending registration request until it registers with a =
new Foreign Agent, that is until the first confirmation is recived (not =
necessarily the one relevant to the first advertisement sent).In this =
case:What happens to the following confirmations that will soon arrive =
?Will they be ignored or will they be considered (than the node will =
switch to new foreign agents and finally register with the "last" one)?
2)it sends the first registration request and starts waiting the =
relevant confirmation without sending any other registration request.
Thanks in advance
Carlo=20

------=_NextPart_000_000F_01D73893.E151C760
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









Hi, 


I'm an italian student, I read RFC2002 =
but=20
my doubt is : what happens if a =
mobile node,=20
which detects that it has just moved into a new Visited Network (by =
means of LCS=20
or ECS ),recives two or more advertisemsnt in a very small time-interval =
(I mean=20
before the registration), because it moved in a overlapping coverage =
areas of=20
many BS? I thought that two possibility are available:


1) It keeps on =
sending registration request=20
until it registers with a new Foreign Agent, that is until the first=20
confirmation is recived (not necessarily the one relevant to the first=20
advertisement sent).In this case:What happens to the following =
confirmations=20
that will soon arrive ?Will they be ignored or will they be considered =
(than the=20
node will switch to new foreign agents and finally register with the =
"last"=20
one)?


2)it sends the first registration =
request and=20
starts waiting the relevant confirmation without sending any other =
registration=20
request.


Thanks in advance


Carlo 


------=_NextPart_000_000F_01D73893.E151C760--



From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 23 06:44: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 GAA03221
	for ; Mon, 23 Apr 2001 06:44:20 -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 DAA04390;
	Mon, 23 Apr 2001 03:43:07 -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 DAA01981;
	Mon, 23 Apr 2001 03:42:58 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3NAfcK9012053
	for ; Mon, 23 Apr 2001 03:41:38 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3NAfbEJ012052
	for mobile-ip-dist; Mon, 23 Apr 2001 03:41: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3NAfQK9012045
	for ; Mon, 23 Apr 2001 03:41: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 DAA13072
	for ; Mon, 23 Apr 2001 03:41:25 -0700 (PDT)
Received: from rndsv.sungmi.co.kr ([168.126.181.1])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA29536
	for ; Mon, 23 Apr 2001 03:41:19 -0700 (PDT)
Received: from eastelsystems.com (168.126.181.222 [168.126.181.222]) by rndsv.sungmi.co.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id JNGXP8CQ; Mon, 23 Apr 2001 19:40:22 +0900
Message-ID: <3AE406BF.30306@eastelsystems.com>
Date: Mon, 23 Apr 2001 19:41:03 +0900
From: Jang JaeIk 
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; 0.8.1) Gecko/20010323
X-Accept-Language: ko, en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Mobile IPv6 Home Agent product and best place?
Content-Type: text/plain; charset=EUC-KR
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 questioned if there is any product(Home Agent) for supporting mobile IPv6.
And in 3G network, where is the best place for HA?

Thanks in advance.



From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 23 08:58: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 IAA04011
	for ; Mon, 23 Apr 2001 08:58: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 FAA11160;
	Mon, 23 Apr 2001 05:56: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 FAA11036;
	Mon, 23 Apr 2001 05:56:22 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3NCt7K9012211
	for ; Mon, 23 Apr 2001 05:55:07 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3NCt7kg012210
	for mobile-ip-dist; Mon, 23 Apr 2001 05:55: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3NCsuK9012203
	for ; Mon, 23 Apr 2001 05:54:58 -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 FAA14835
	for ; Mon, 23 Apr 2001 05:54:57 -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 FAA08475
	for ; Mon, 23 Apr 2001 05:54:56 -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 HAA13337
	for ; Mon, 23 Apr 2001 07:55:12 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Mon, 23 Apr 2001 07:54:38 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Mon, 23 Apr 2001 07:54:25 -0500
Message-ID: <85AA7486A2C1D411BCA20000F8073E4301F4B35B@crchy271.us.nortel.com>
From: "Glenn Morrow" 
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Mobile IPv6 Home Agent product and best place?
Date: Mon, 23 Apr 2001 07:54:17 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0CBF4.82015CC0"
Sender: owner-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_01C0CBF4.82015CC0
Content-Type: text/plain;
	charset="KS_C_5601-1987"

I'm not sure there is a best place. I guess it could be anywhere - an
enterprise, a providers link or the visited providers link. It all depends
on what functionality you are trying to achieve or the user values most. 

For instance a mobile user that does not care about location privicy would
be fine with having the HA in the visited network. 

Someone who is concerned about location privacy will want to have it on
either their home provider's or their enterprise link. 

Some person in an RV running a Web Server or FTP server will likely choose
their home provider's link. Keeping the same IP address is important for
this type of application.

A mobile router on a bus, train, etc.. might have the HA on a link of the
providers' site router.

Hope this helps,

Glenn

-----Original Message-----
From: Jang JaeIk [mailto:jijang@eastelsystems.com]
Sent: Monday, April 23, 2001 5:41 AM
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Mobile IPv6 Home Agent product and best place?


Hi all

I questioned if there is any product(Home Agent) for supporting mobile IPv6.
And in 3G network, where is the best place for HA?

Thanks in advance.


------_=_NextPart_001_01C0CBF4.82015CC0
Content-Type: text/html;
	charset="KS_C_5601-1987"
Content-Transfer-Encoding: quoted-printable






RE: [mobile-ip] Mobile IPv6 Home Agent product and best =
place?




I'm not sure there is a best place. I guess it could =
be anywhere - an enterprise, a providers link or the visited providers =
link. It all depends on what functionality you are trying to achieve or =
the user values most. 



For instance a mobile user that does not care about =
location privicy would be fine with having the HA in the visited =
network. 



Someone who is concerned about location privacy will =
want to have it on either their home provider's or their enterprise =
link. 



Some person in an RV running a Web Server or FTP =
server will likely choose their home provider's link. Keeping the same =
IP address is important for this type of application.



A mobile router on a bus, train, etc.. might have the =
HA on a link of the providers' site router.




Hope this helps,




Glenn




-----Original Message-----

From: Jang JaeIk [mailto:jijang@eastelsystems.com=
]

Sent: Monday, April 23, 2001 5:41 AM

To: mobile-ip@sunroof.eng.sun.com

Subject: [mobile-ip] Mobile IPv6 Home Agent product =
and best place?






Hi all




I questioned if there is any product(Home Agent) for =
supporting mobile IPv6.

And in 3G network, where is the best place for =
HA?




Thanks in advance.





------_=_NextPart_001_01C0CBF4.82015CC0--


From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 23 10:20:54 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 KAA04724
	for ; Mon, 23 Apr 2001 10:20:53 -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 HAA17429;
	Mon, 23 Apr 2001 07:19: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 HAA13697;
	Mon, 23 Apr 2001 07:18:11 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3NEG1K9012275
	for ; Mon, 23 Apr 2001 07:16:01 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3NEG15b012274
	for mobile-ip-dist; Mon, 23 Apr 2001 07:16: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3NEFpK9012267
	for ; Mon, 23 Apr 2001 07:15: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 HAA20256
	for ; Mon, 23 Apr 2001 07:15:41 -0700 (PDT)
Received: from mailgw.local.ipunplugged.com ([213.88.134.217])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA07427
	for ; Mon, 23 Apr 2001 07:15:29 -0700 (PDT)
Received: from fredrikj (c35.local.ipunplugged.com [192.168.4.234])
	by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id QAA15008
	for ; Mon, 23 Apr 2001 16:16:36 +0200
From: "Fredrik Johansson" 
To: 
Subject: RE: [mobile-ip] WG last call: AAA Keys
Date: Mon, 23 Apr 2001 16:17:25 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <20010420181454.F2EEC5701F@king.research.bell-labs.com>
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: 
Content-Transfer-Encoding: 7bit

I believe there will be many more changes to this draft as soon as Pat has
the time to make the changes we discussed in Minneapolis. For example to add
algorithm, lifetime and so on to the subtypes. I also believe that Charlie's
generalized key draft will have some changes that will affect this draft.
Can we please wait until Pat have time to comment on this.

/Fredrik

P.S. Pat if you would like any help on the draft and what we decided just
tell me.

>
>Hi,
>
>The current version of this draft does not seem to reflect the changes
>suggested by Pat last week, namely, that instead of sending keys in
>the registration reply, we would send a random number from which keys
>would be generated.
>
>If it is a matter of proposing specific text, I would be glad to
>volunteer if no one else is working on this.
>
>Also, does it make sense to include a (possibly very long) Lifetime
>for the MN-HA key as well as the MN-FA key?
>
>-Pete
>
>Phil Roberts  (PR) writes:
>
>PR> This is a Mobile IP WG last call for the I-D
>PR> draft-ietf-mobileip-aaa-key-04.txt
>PR> AAA Registration Keys for Mobile IP. This draft will be sent
>to the IESG
>PR> requesting a proposed standard status to be associated with it
>at the end of
>PR> the last call
>PR> period. Please send your comments to the WG discussion list.
>
>PR> WG Last call issued on : Apr 19, 2001
>PR> Expires on : May 4, 2001
>
>PR> Basavaraj Patil
>PR> Phil Roberts



From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 23 10:30: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 KAA04867
	for ; Mon, 23 Apr 2001 10:30:33 -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 HAA20968;
	Mon, 23 Apr 2001 07:27: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 HAA21653;
	Mon, 23 Apr 2001 07:26:18 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3NEOxK9012307
	for ; Mon, 23 Apr 2001 07:24:59 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3NEOxUe012306
	for mobile-ip-dist; Mon, 23 Apr 2001 07:24: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3NEOmK9012299
	for ; Mon, 23 Apr 2001 07:24:51 -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 HAA25903
	for ; Mon, 23 Apr 2001 07:24:48 -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 JAA14121
	for ; Mon, 23 Apr 2001 09:30:56 -0600 (MDT)
Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 23 Apr 2001 10:18:55 -0400
Message-ID: 
From: Phil Roberts 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] WG last call: AAA Keys
Date: Mon, 23 Apr 2001 10:18:54 -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: 

Yes you are correct.  Someone pointed out to me right after I sent this that
Pat is in the process of producing another draft.   We expect to hear
comments from Pat on this shortly.

> -----Original Message-----
> From: Fredrik Johansson [mailto:fredrik.johansson@ipunplugged.com]
> Sent: Monday, April 23, 2001 10:17 AM
> To: mobile-ip@sunroof.eng.sun.com
> Subject: RE: [mobile-ip] WG last call: AAA Keys
> 
> 
> I believe there will be many more changes to this draft as 
> soon as Pat has
> the time to make the changes we discussed in Minneapolis. For 
> example to add
> algorithm, lifetime and so on to the subtypes. I also believe 
> that Charlie's
> generalized key draft will have some changes that will affect 
> this draft.
> Can we please wait until Pat have time to comment on this.
> 
> /Fredrik
> 
> P.S. Pat if you would like any help on the draft and what we 
> decided just
> tell me.
> 
> >
> >Hi,
> >
> >The current version of this draft does not seem to reflect 
> the changes
> >suggested by Pat last week, namely, that instead of sending keys in
> >the registration reply, we would send a random number from which keys
> >would be generated.
> >
> >If it is a matter of proposing specific text, I would be glad to
> >volunteer if no one else is working on this.
> >
> >Also, does it make sense to include a (possibly very long) Lifetime
> >for the MN-HA key as well as the MN-FA key?
> >
> >-Pete
> >
> >Phil Roberts  (PR) writes:
> >
> >PR> This is a Mobile IP WG last call for the I-D
> >PR> draft-ietf-mobileip-aaa-key-04.txt
> >PR> AAA Registration Keys for Mobile IP. This draft will be sent
> >to the IESG
> >PR> requesting a proposed standard status to be associated with it
> >at the end of
> >PR> the last call
> >PR> period. Please send your comments to the WG discussion list.
> >
> >PR> WG Last call issued on : Apr 19, 2001
> >PR> Expires on : May 4, 2001
> >
> >PR> Basavaraj Patil
> >PR> Phil Roberts
> 


From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 23 11:37:05 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 LAA05687
	for ; Mon, 23 Apr 2001 11:37: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 IAA27832;
	Mon, 23 Apr 2001 08:36:28 -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 IAA02988;
	Mon, 23 Apr 2001 08:36:16 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3NFZ0K9012457
	for ; Mon, 23 Apr 2001 08:35:01 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3NFZ0KX012456
	for mobile-ip-dist; Mon, 23 Apr 2001 08:35: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3NFYnK9012449
	for ; Mon, 23 Apr 2001 08:34:49 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA26265;
	Mon, 23 Apr 2001 08:34:48 -0700 (PDT)
Received: from darius (darius [152.70.40.121])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id IAA10022;
	Mon, 23 Apr 2001 08:34:46 -0700 (PDT)
Date: Mon, 23 Apr 2001 08:34:49 -0700 (PDT)
From: Patrice Calhoun 
Subject: Re: [mobile-ip] Question about Registration Replies and RFC2002bis
To: mobile-ip@sunroof.eng.sun.com
Cc: korykeith@yahoo.com
In-Reply-To: "Your message with ID" <200104162001.NAA01758@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: 

> Hi Charlie,
> 
> Another issue that came up here in the discussion about DHCP is that
> RFC 2002bis currently does not require the mobile node to periodically
> reregister when it is on the home network. If the mobile node gets a dynamic 
> home address and the HA is maintaining it by DHCP, then the HA will
> periodically need to reregister.

Well, it sure makes sense to have the registration lifetime set to (DHCP
leasetime + fudgefactor).

PatC



From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 23 11:53: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 LAA06028
	for ; Mon, 23 Apr 2001 11:53:23 -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 IAA02502;
	Mon, 23 Apr 2001 08:44: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 IAA27897;
	Mon, 23 Apr 2001 08:44:10 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3NFgZK9012489
	for ; Mon, 23 Apr 2001 08:42:35 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3NFgZ24012488
	for mobile-ip-dist; Mon, 23 Apr 2001 08:42: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3NFgNK9012481
	for ; Mon, 23 Apr 2001 08:42:24 -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 IAA04251
	for ; Mon, 23 Apr 2001 08:42:23 -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 IAA27850
	for ; Mon, 23 Apr 2001 08:42:23 -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 IAA23938
	for ; Mon, 23 Apr 2001 08:42:22 -0700 (PDT)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3NFgJx22993
	for ; Mon, 23 Apr 2001 08:42:19 -0700
X-mProtect:  Mon, 23 Apr 2001 08:42:19 -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(WTS.12.69) smtpduXfX7Y; Mon, 23 Apr 2001 08:42:15 PDT
Message-ID: <3AE44D59.50035FB6@iprg.nokia.com>
Date: Mon, 23 Apr 2001 08:42: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: 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 Karim,

I personally think that by linking the LMMin a hierarchy will certainly
assist in the resiliency features that ensures survivability over single or
multiple points of failure.

I have further argued in previous emails that by providing a hierarchy of
LMMs the locality of signalling can be further optimized, to the closest LMM
point such that the velocity vector of the MN does not upset the transitive
permancency of the GMA/MAP/other point in an LMM scheme.

The above constitute serious reasons for me to include them in the
requirements set for LMM. Whether trivial domain depths want to default to a
single depth LMM is something that perhaps can initialise the LMM hierarchy
but SHOULD certainly be augmentable to more than one depths in the
LMM-aware (and subsequently underlying domain) routing element hierarchy.

You may see such need right now as redundant but I feel it is a requirement
waiting to arise when a more complex real-world LMM scenario _becomes_ the
norm..

Theo

UCL/ Mobile Systems


"Karim El-Malki (ERA)" wrote:

> Hello Raj and James
>
> >>I do not think we should rule out multiple levels of LMM agents from
> >>the requirements at this stage, but let's discuss the implications of
> >>a multi-level hierarchy from a routing, deployment, failure-point etc.
> >>perspective. Obviously there are quite a few people who feel quite
> >>strongly about it and to rule it out would be unwise.
> >>
> >
> >Ulimately, the issue is one of deployment. The worst possible case
> >is we cycle an LMM protocol without multiple levels of hierarchy
> >to proposed and discover during deployment that we need it.
>
> We have been trying to identify what applications require multiple
> levels of local agents (MAPs) linked to each other. This requirement
> is still not clear to me, but I wouldn't rule out that we can
> agree on reasons with more discussion.
>
> What I would not like to see is a design which is made more
> complex (and introduces multiple points of failure) solely to be
> optimised for a special case of a hierarchy in which one BU is passed
> on between mobility agents (MAPs). At least, this is what I'm
> questioning. In fact the current WG draft (HMIPv6) does not rule out a
> MAP hierarchy, but considers mostly a MN using one MAP. The v4 WG
> draft (Regional Reg) also considers a 2-level hierarchy (one GFA
> with one level of FAs below it) but allows multiple levels. Of
> course, in v6 there can be multiple levels of ARs between MN and local
> agent. As Raj wrote in a previous email, it is possible to have agents
> (MAPs) located at different "levels" and the MN can use or be made to
> use the appropriate one. These can be, but do not have to be necessarily
> linked to each other. If packets need to be forwarded between local
> agents, the MN can send appropriate BUs to the individual agents and
> create a MAP hierarchy. This is allowed in the current draft and we can
> work on further optimisations. It's need however is still being discussed.
> I just wanted to clarify this point.
>
> Regards
> /Karim



From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 23 12:20:22 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06504
	for ; Mon, 23 Apr 2001 12:20:21 -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 JAA27931;
	Mon, 23 Apr 2001 09:18: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 JAA10941;
	Mon, 23 Apr 2001 09:18:18 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3NGGtK9012599
	for ; Mon, 23 Apr 2001 09:16:56 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3NGGtLF012598
	for mobile-ip-dist; Mon, 23 Apr 2001 09:16:55 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3NGGiK9012591
	for ; Mon, 23 Apr 2001 09:16:45 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04775
	for ; Mon, 23 Apr 2001 09:16:44 -0700 (PDT)
Received: from darius (darius [152.70.40.121])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id JAA10556
	for ; Mon, 23 Apr 2001 09:16:43 -0700 (PDT)
Date: Mon, 23 Apr 2001 09:16:45 -0700 (PDT)
From: Patrice Calhoun 
Subject: Re: [mobile-ip] Design teams for mobileip--(sharif)
To: mobile-ip@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <011701c0c769$76b5e6e0$6501a8c0@philneum>
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 guess this is another item to add to my appeal.  I believe this is
> setting a bad precedent for the IETF.

I suggest that you read section 6.5 of RFC 2418 before you add more items to
your crusade. Closed design teams are OK, when the ADs are in agreement. In
this particular case, they were.

Note, however, that the goal of the MIPv4 design team was to consolidate all 5
Internet Drafts into one, so attendance was limited to people that were
authors of one of the I-Ds. Of course, the once the merging was completed, the
WG had the ability to comment on the merged draft.

PatC



From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 23 13:00:40 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06953
	for ; Mon, 23 Apr 2001 13:00: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 JAA04697;
	Mon, 23 Apr 2001 09: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 JAA19743;
	Mon, 23 Apr 2001 09:59:19 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3NGvuK9012657
	for ; Mon, 23 Apr 2001 09:57:56 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3NGvunH012656
	for mobile-ip-dist; Mon, 23 Apr 2001 09:57: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3NGvjK9012649
	for ; Mon, 23 Apr 2001 09:57:46 -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 JAA13741
	for ; Mon, 23 Apr 2001 09:57:44 -0700 (PDT)
Received: from artemis.shef.ac.uk (artemis.shef.ac.uk [143.167.2.11])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA19605
	for ; Mon, 23 Apr 2001 12:04:26 -0600 (MDT)
Received: from [143.167.1.9] (helo=mailhub1.shef.ac.uk)
	by artemis.shef.ac.uk with esmtp (Exim 3.22 #4)
	id 14rjb8-0006i6-00; Mon, 23 Apr 2001 17:54:02 +0100
Received: from ridingwood.shef.ac.uk ([143.167.59.249])
	by mailhub1.shef.ac.uk with esmtp (Exim 3.22 #3)
	id 14rjb8-0004Q0-00; Mon, 23 Apr 2001 17:54:02 +0100
Received: from RIDINGWOOD/SpoolDir by ridingwood.shef.ac.uk (Mercury 1.48);
    23 Apr 01 17:54:02 +0100
Received: from SpoolDir by RIDINGWOOD (Mercury 1.48); 23 Apr 01 17:53:56 +0100
Received: from borg (143.167.251.68) by ridingwood.shef.ac.uk (Mercury 1.48);
    23 Apr 01 17:53:48 +0100
Message-ID: <016c01c0cc15$fffffd40$44fba78f@borg>
From: "cny" 
To: , ,
        
References: <013101d737a4$c913c800$0ad8abd4@pivendi> <000901c0ca93$7b8bd9e0$44fba78f@borg> <003801c0cb05$dc736940$63c9623e@annozero>
Subject: Re: [mobile-ip] a doubt about MIP
Date: Mon, 23 Apr 2001 18:54:02 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0169_01C0CC26.C37963F0"
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 *14rjb8-0006i6-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_0169_01C0CC26.C37963F0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi=20

Yes this is a interesting case, but normally the second way is assume.

Chern Nam Yap




  ----- Original Message -----=20
  From: Pugini Fabio=20
  To: mobile-ip@sunroof.eng.sun.com=20
  Sent: Sunday, April 22, 2001 10:25 AM
  Subject: Re: [mobile-ip] a doubt about MIP


  Hi
  To be sincere, I think Piercarlo meant something different (I know =
that since we discussed about this topic few days ago). Our doubt is: =
what happens if a mobile node, which detects that it has just moved into =
a new Visited Network (by means of LCS or ECS or Pre-Matching =
indiferently), receives two or more advertisement in a very small =
time-interval (I mean before the registration), because it moved in a =
overlapping coverage areas of many BS? We thought that two possibility =
are available:
  1) It keeps on sending registartion requests until it registers with a =
new Foreign Agent, that is until the first confirmation is received (not =
necessarily the one relevant to the first advertisement sent). In this =
case: What happens to the following confirmations that will soon arrive? =
Will they be ignored or will they be considered (than the node will =
switch to new foreign agents and finally register with the "last" one)?
  2) It sends the first registration request and starts waiting for the =
relevant confirmation without sending any other registr. requests. (this =
seems to me to be  a very strange, and nowhere explained, approach).

  Any help in understanding this operation will be highily appriciated.


  In order to answer to last Chern Nam Yap's question, I can say that =
Piercarlo and I (we are students) are trying to analize the Mobile IP =
advertisement/registration way of operation. In the abovementioned first =
option (when  the mobile node considers all the registration =
confirmation it receives), we envision some delay/loss issues.
  Best Regards
    ----- Original Message -----=20
    From: cny=20
    To: mobile-ip@sunroof.eng.sun.com=20
    Sent: Saturday, April 21, 2001 8:47 PM
    Subject: Re: [mobile-ip] a doubt about MIP


    Hi=20

    It really depend on implementations.
    That is movement detection methods.

    1) Lazy Cell Switching
    if the mobile node loses 3 advertisements, it will then use the =
first advertisment it receives.
    2.5 sec delay if each advertisment is sent once per seconds.

    2) Eager Cell Switching
    Every advertisment the mobile node receives, it will used the =
advertisment under that mobile agent.
    0.5 sec delay if each advertisment is sent once per seconds.

    3) Prefixed Matching
    Handoffs depending upon a different prefix advertisment the mobile =
node receives.
    0.5 sec delay if each advertisment is sent once per seconds.

    May i know what are you doing for your project then???? :)

    Cheers
    Chern Nam Yap





      ----- Original Message -----=20
      From: pieracarlo venditti=20
      To: mobile-ip@sunroof.eng.sun.com=20
      Sent: Thursday, April 22, 2021 8:24 PM
      Subject: [mobile-ip] a doubt about MIP


      Hello,
      I'm an italian student, I studied RFC2002 but I've a doubt about =
Mobile IP protocol: if Mobile Node assumes that it has lost contact with =
its agent and it recives two new Advertisements, I don't understand if =
it attempts registration with the two Foreign Agents  sending the two =
new Advertisements or it attempts registration with only one of them and =
if it is so with which of them?
      Thanks in advance
      Carlo



------=_NextPart_000_0169_01C0CC26.C37963F0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









Hi 


 


Yes this is a interesting case, but=20
normally the second way is assume.


 


Chern Nam Yap


 


 


 


 



  
----- Original Message ----- 

  From:=20
  Pugini Fabio 
  
To: mobile-ip@sunroof.eng.sun.c=
om=20
  

  
Sent: Sunday, April 22, 2001 =
10:25=20
  AM

  
Subject: Re: [mobile-ip] a =
doubt about=20
  MIP

  


  
Hi

  
To be sincere, I think Piercarlo =
meant something=20
  different (I know that since we discussed about this topic few days =
ago). Our=20
  doubt is: what happens if a mobile node, which detects that it has =
just moved=20
  into a new Visited Network (by means of LCS or ECS or Pre-Matching=20
  indiferently), receives two or more advertisement in a very small=20
  time-interval (I mean before the registration), because it moved in a=20
  overlapping coverage areas of many BS? We thought that two possibility =
are=20
  available:

  
1) It keeps on sending registartion=20
  requests until it registers =
with a new=20
  Foreign Agent, that is until the first confirmation is received (not=20
  necessarily the one relevant to the first advertisement sent). In this =
case:=20
  What happens to the following confirmations that will soon arrive? =
Will they=20
  be ignored or will they be considered (than the node will switch to =
new=20
  foreign agents and finally register with the "last" one)?

  
2) It sends the first registration =
request and=20
  starts waiting for the relevant confirmation without sending any other =

  registr. requests. (this seems to me to be  a very strange, and =
nowhere=20
  explained, approach).

  
 

  
Any help in understanding this =
operation will be=20
  highily appriciated.

  
 

  
 

  
In order to answer to last =
Chern Nam Yap's question, I can say that =
Piercarlo and I (we=20
  are students) are trying to analize the Mobile IP =
advertisement/registration=20
  way of operation. In the abovementioned first option (when  =
the=20
  mobile node considers all the registration confirmation it receives), =
we=20
  envision some delay/loss issues.

  
Best Regards

  

    
----- Original Message ----- 

    From:=20
    cny 
    
To: mobile-ip@sunroof.eng.sun.c=
om=20
    

    
Sent: Saturday, April 21, =
2001 8:47=20
    PM

    
Subject: Re: [mobile-ip] a =
doubt about=20
    MIP

    


    
Hi 

    
 

    
It really depend on=20
    implementations.

    
That is movement detection=20
methods.

    
 

    
1) Lazy Cell Switching

    
if the mobile node loses 3 =
advertisements, it=20
    will then use the first advertisment it receives.

    
2.5 sec delay if each advertisment =
is sent once=20
    per seconds.

    
 

    
2) Eager Cell =
Switching

    
Every advertisment the mobile=20
    node receives, it will used the =
advertisment under=20
    that mobile agent.

    
0.5 sec delay if each =
advertisment is sent=20
    once per seconds.

    
 

    
3) Prefixed Matching

    
Handoffs depending upon a =

    different prefix advertisment the mobile=20
    node receives.

    
0.5 sec delay if each =
advertisment is sent=20
    once per seconds.

    
 

    
May i know what are you doing for =
your project=20
    then???? :)

    
 

    
Cheers

    
Chern Nam Yap

    
 

    
 

    
 

    
 

    
 

    

      
----- Original Message ----- =


      From:=20
      pieracarlo=20
      venditti 
      
To: mobile-ip@sunroof.eng.sun.c=
om=20
      

      
Sent: Thursday, April 22, =
2021 8:24=20
      PM

      
Subject: [mobile-ip] a =
doubt about=20
      MIP

      


      
Hello,

      
I'm an italian student, I studied =
RFC2002 but=20
      I've a doubt about Mobile IP protocol: if Mobile Node assumes that =
it has=20
      lost contact with its agent and it recives two new Advertisements, =
I don't=20
      understand if it attempts registration with the two Foreign =
Agents =20
      sending the two new Advertisements or it attempts registration =
with only=20
      one of them and if it is so with which of them?

      
Thanks in advance

      
Carlo

      
 

      
 


------=_NextPart_000_0169_01C0CC26.C37963F0--



From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 23 13:59:19 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08495
	for ; Mon, 23 Apr 2001 13:59: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 KAA28511;
	Mon, 23 Apr 2001 10:58: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 KAA03358;
	Mon, 23 Apr 2001 10:57:56 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3NHuNK9012825
	for ; Mon, 23 Apr 2001 10:56:23 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3NHuNKm012824
	for mobile-ip-dist; Mon, 23 Apr 2001 10:56: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3NHuCK9012817
	for ; Mon, 23 Apr 2001 10:56:13 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA05050
	for ; Mon, 23 Apr 2001 10:56:12 -0700 (PDT)
Received: from darius (darius [152.70.40.121])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id KAA11899
	for ; Mon, 23 Apr 2001 10:56:10 -0700 (PDT)
Date: Mon, 23 Apr 2001 10:56:12 -0700 (PDT)
From: Patrice Calhoun 
Subject: Re: [mobile-ip] WG last call: AAA Keys
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: 

I have lots of comments, and the ID cannot proceed as is. I will have to
re-issue another revision next week.

PatC



From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 23 14:01:48 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08684
	for ; Mon, 23 Apr 2001 14:01: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 KAA29046;
	Mon, 23 Apr 2001 10:58: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 KAA05681;
	Mon, 23 Apr 2001 10:58:30 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3NHuxK9012853
	for ; Mon, 23 Apr 2001 10:56:59 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3NHuw6Y012852
	for mobile-ip-dist; Mon, 23 Apr 2001 10:56: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 eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3NHuqK9012845
	for ; Mon, 23 Apr 2001 10:56:52 -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 NAA01084
	for ; Mon, 23 Apr 2001 13:56:51 -0400 (EDT)
Received: (from glass@localhost)
	by onion.east.sun.com (8.9.3+Sun/8.9.3) id NAA17824
	for mobile-ip@sunroof.eng.sun.com; Mon, 23 Apr 2001 13:57:02 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3NHGxK9012711
	for ; Mon, 23 Apr 2001 10:17:01 -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 KAA00687
	for ; Mon, 23 Apr 2001 10:16:57 -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 MAA04122
	for ; Mon, 23 Apr 2001 12:23:39 -0600 (MDT)
Received: (from smap@localhost)
	by tml-gw.tml.hut.fi (8.8.7/8.8.7) id UAA01371
	for ; Mon, 23 Apr 2001 20:16:54 +0300
Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0)
	id xma001367; Mon, 23 Apr 01 20:16:51 +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 f3NHGpr29955
	for ; Mon, 23 Apr 2001 20:16:51 +0300 (EEST)
Received: from localhost (lpetande@localhost)
	by morphine.tml.hut.fi (8.11.3/8.11.3) with ESMTP id f3NHFu803104
	for ; Mon, 23 Apr 2001 20:15:56 +0300 (EET DST)
X-Authentication-Warning: morphine.tml.hut.fi: lpetande owned process doing -bs
Date: Mon, 23 Apr 2001 20:15:56 +0300 (EET DST)
From: Lars Henrik Petander 
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Some thoughts on BAKE and MIPv6 security
In-Reply-To: <3AD48002.E21502C2@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: 

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  Mon Apr 23 15:38:39 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 PAA11325
	for ; Mon, 23 Apr 2001 15:38:38 -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 MAA13513;
	Mon, 23 Apr 2001 12:37:49 -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 MAA00367;
	Mon, 23 Apr 2001 12:37:28 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3NJW7K9013120
	for ; Mon, 23 Apr 2001 12:32:07 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3NJW6x7013119
	for mobile-ip-dist; Mon, 23 Apr 2001 12:32: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3NJVoK9013112
	for ; Mon, 23 Apr 2001 12:31: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 MAA07080
	for ; Mon, 23 Apr 2001 12:31:49 -0700 (PDT)
Received: from zcars0m9. (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id MAA14001
	for ; Mon, 23 Apr 2001 12:31:49 -0700 (PDT)
Received: from zcars04f.ca.nortel.com by zcars0m9. (SMI-8.6/SMI-SVR4)
	id PAA17855; Mon, 23 Apr 2001 15:31:46 -0400
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Mon, 23 Apr 2001 15:31:29 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Mon, 23 Apr 2001 15:31:30 -0400
Message-ID: 
From: "Muhammad Jaseemuddin" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Revised Localized Mobility Management Requirement s
Date: Mon, 23 Apr 2001 15:31:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0CC2B.FEFBF8C0"
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_01C0CC2B.FEFBF8C0
Content-Type: text/plain;
	charset="iso-8859-1"



> -----Original Message-----
> From:	Theo Pagtzis [SMTP:tpagtzis@iprg.nokia.com]
> Sent:	Wednesday, April 18, 2001 2:19 PM
> To:	mobile-ip@sunroof.eng.sun.com
> Subject:	Re: [mobile-ip] Revised Localized Mobility Management
> Requirements
> 
> Hi Phil,
> 
> a few comments below..
> 
> 
> Phil Roberts wrote:
> 
> > OK.  Let's make another cut through these.  Seems that folks like the
> title
> > Localized Mobility Management.  I didn't retain the original numbers.
> >
> > Agreed upon requirements where there was no dissent:
> > 1. Regional registration shall be introduced to minimize the signaling
> > traffic to the home agent or correspondent nodes for intradomain
> mobility.
> > 2. Regional registration shall be secure against malicious behavior from
> > visiting mobiles
> >
> 
> Perhaps on 2 we want to incorporate _any_ malicious behaviour..not just
> the
> MNs??
> 
> 
> >
> > That's about it.
> >
> > There was only minor dissent on these:
> > 3. Connectivity to the mobiles shall not be interrupted in the presence
> of
> > the failure of regional registration agents.
> 
> I would like to propose here that this requirement is made rather more
> generic.
> The requirement in the rationale I have considered is that :
> 
>      "a Localised mobility management scheme should be able to adapt to
> topological changes
> arising in the domain that the LMM scheme is in effect.
> 
> The reason:
> 
>     the failure of LMM agents manifests itself as a topological change,
> since
> in IPv6 any such LMM agent will be a routing element. However, the
> population
> of new routing elements that can be potential candidates for LMM agents is
> also
> a manifestation of a topological change.
> 
> The LMM scheme should be able to adapt to both; the latter is extremely
> important in terms of scalability and incremental deployment since we
> cannot
> expect to cast a domain topology in stone and live without expansion.
> 
> >
> > [Only comment was that disruption should be minimized.  I'd like to get
> a
> > sense from the working group whether it feels that this one should be
> > restated]
> 
> My feeling on this one is that objectively we need to strive for
> elimination.
> However, with the current expertise we have this may not seem a realistic
> target for the particular requirement which to me sounds like
> 
> "topological changes in the routing fabric with regard to an LMM scheme
> MUST
> bear a measure of minimal disruption to the extension optimizations
> effected by
> that (LMM) scheme. However, it is the intention that an LMM scheme should
> strive to eliminate even minimal disruption to the MNs, if possible."
> 
> As such we should explictly state that we are making a minimum requirement
> the
> minimization and we strive for elimination.
> 
> 
> 
> >
> > 4. Regional registration shall support fast handoffs.
> > [Several comments that it should be compatible and no dependencies
> between
> > the specs, so how about: Regional registration shall be compatible with
> fast
> > handoffs.]
> >
> 
> Agreed. Although I think that it is fast handoffs that should worry about
> that
> requirement not the LMM scheme itself. In a divide and conquer manner I
> consider that you try to effect
> 
>    1. Mobility
>     1.a  localisation of mobility and subsequent speedups (LMM)
>        1.a.a speedup optimizations by applying fast handoff techniques
> over
> that LMM...
> 
> So the compatibility is for the fast handoff scheme not for LMM since the
> LMM
> is the core of the optimization...
> 
> I am not sure what is the order of prescedence for others over fast
> handoffs
> though..
> 
	[MJ]  I agree that the fast handoff should comply with the LMM
requirements. Hence, I would like to propose the 
	following additional LMM requirement.

	x. LMM MAY require a MN to change IP address as a result of handover
to the new AR.

	Hence, any fast handoff solution based on LMM requirement SHOULD not
automatically assume change of IP address during handoff. The fast handoff
solution should provide a provision in its signaling messages whether or not
new AR should assign a new IP address. I think this requirement is important
to decouple LMM with fast handoff. If LMM requires MNs to get new IP address
at the new ARs, then it should be somehow (e.g. through configuring handoff
signaling message) made known to the fast handoff, hence fast handoff can
facilitate acquisition of new IP address. For example, fast handover IPv6
defines code value 1 (No change of COA required) for IPv6 PrRtAdv message,
but assumes always change of address in HI message. I think HI message
should also have a bit (like S bit defining stateful address configuration)
defining whether or not change of address is required. 

> > 5. Regional registration shall scale to support millions of nodes in a
> > visited network.
> > [One comment that this was too broad, so I'd request someone to rephrase
> it
> > in a better way]
> >
> 
> Well thinking about it again and again we have two sides of scalability,
> one
> interacting with the other. Consider:
> 
>       The LMM scheme should be able to adapt (according to the rationale I
> have
> provided above) to topological changes effected in the routing fabric of
> the
> domain the LMM scheme gets applied on. But why should it be able to adapt?
> Of
> course to utilise _all_ the available (during expansion) or possible
> (during
> contraction) routing elements and thus candidate LMM agents.
> 
>     On reason for that is to optimize the localisation point (better
> candidates). But as soon as the localisation point gets optimized in a
> distributed fashion (i.e. not all MNs get the same one) you have what?????
> SCALABILITY.....
> 
> So adaptivity may implicitly effect scalability from the routing fabric's
> viewpoint of an LMM scheme.
> 
> From the perspective of the MN:
> 
>      We want the following:
>    "the LMM-enabled domain to support a dense population of mobile nodes."
> 
> That may be mi/bi/trillions, etc. However, to effect that, the LMM scheme
> MUST
> take advantage of the scalability potentials of the routing fabric in
> terms of
> LMM-aware routers.
> An that implies that it is the LMM scheme that has to provide such
> internal
> scalability before it can adhere to any scalability goals for dense MN
> populations within an LMM-aware domain.
> 
> 
> In that respect, I am inclined to say that:
> 
> an LMM scheme MUST provide scalable population of LMM-aware routing
> elements
> which should be utilised if the scheme is to support dense populations of
> MNs
> within an LMM-aware domain.
> 
> 
> 
> >
> > Mostly disagreement on these:
> > 6. .  Regional registration shall not introduce new overhead on links
> > between the mobile and the local mobility management agents.
> > [Comments were that it should be minimized, or that it was ok if it
> meant no
> > more overhead than a binding update.  Here's my attempt at a revision:
> local
> > mobility management shall not introduce new messages to notify the LMM
> > agents of a move.  There is a disagreement as to whether adding
> additional
> > over the air bytes is an issue, and if it is whether it's this WG's
> > responsibility to solve it]
> >
> 
> I agree that an LMM scheme should minimize overhead on links between LMM
> agents
> and MNs
> But there is also a slight falacy about what constitutes a new message. We
> have
> the backdoor of expanding the BU I guess so I could render the requirement
> invalid.
> 
> I think it would work better to let implementors feel responsible about
> minimization rather than trying to constraint them like that..they usually
> find
> the backdoor straight away..
> 
> 
> > 7. Regional registration shall allow multiple levels of hierarchy.
> > [There was some strong disagreement on this.  Perhaps Jim or Karim could
> > start a separate thread to track this one down?]
> 
> I personally insist that multiple levels of LMM hierarchy should be
> allowed. I
> feel unconvinced that single depth is sufficient for different LMM
> scenarios
> 
> 
> >
> > 8. Regional registration shall not require changes ot the MN, the home
> > agent, or correspondent nodes.
> > [Many thought requiring no change to the MN was not doable, but the home
> > agent or CN should be unchanged.  So I propose we just rewrite this as:
> > Regional registration shall not require changes to the home agent or
> > correspondent nodes.]
> 
> fine
> 
> >
> > 9. Regional registration shall not introduce host routes in routing
> tables.
> > [Didn't get much positive on this one and got the sense folks don't want
> to
> > rathole on a host routing discussion.  I propose we drop this.]
> 
> agreed
> 
> >
> >
> > We also had request for some new requirements:
> > 10. LMM should provide the same level of mobility mgmt support as in the
> > basic MIP v6 spec.  MM fns supported in MIP v6 must not be reduced.
> > [Some positive feedback on this, shall we keep it?]
> >
> 
> if we specify what we mean by level of mobility management so that we
> understand what we are talking about, then maybe....
> 
> 
> 
> > 11. LMM must interwork with MIPv6, IPv6, and the proposed mechanisms for
> SA
> > establishment
> > [One comment that this was stating the obvious.  Shall we keep it?]
> >
> 
> I am not in favour of keeping that for reasons already explained.
> 
> 
> >
> > 12. LMM should be optimized for mobile-to-mobile.
> > [Never really understood what this requirement was supposed to be.  Got
> > similar feedback from others.  I propose we drop it.]
> >
> 
> basically here people referred to CN being in the same net with the MN and
> both
> being mobile, didn't they?
> 
> Although the description of the original req has not been very clear, I
> suggest
> we either become clearer on what we want to get out of that or drop it.
> 
> 
> >
> > Received no feedback on the following proposed requirements.  Anybody
> want
> > to keep these?
> > 13. Should minimize # of network nodes affected by HO signalling.
> >
> 
> not sure about what is meant by that..either elaborate a little or drop..
> 
> 
> > 14. Should support autoconfig.
> >
> 
> I would say an ABSOLUTE 'must' or at worst 'should'. Most LMM schemes I
> know
> of, have pushed a lot of important parts of the protocol. If single points
> of
> failure must be resolved then autoconfiguration is nothing _less_ than a
> must.
> 
> 
> > 15. Should simplify network design and provisioning.
> 
> simplification is a contradiction to specialisation (i.e. extension).
> Drop.
> 
> 
> Theo
> 
> UCL/Mobile Systems
> 

------_=_NextPart_001_01C0CC2B.FEFBF8C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [mobile-ip] Revised Localized Mobility Management =
Requirements







    

    -----Original Message-----

    From:   Theo Pagtzis =
[SMTP:tpagtzis@iprg.nokia.com]

    Sent:   Wednesday, April 18, 2001 2:19 PM

    To:     mobile-ip@sunroof.eng.sun.com

    Subject:       =
 Re: [mobile-ip] Revised Localized =
Mobility Management Requirements

    


    Hi Phil,

    


    a few comments below..

    

    


    Phil Roberts wrote:

    


    > OK.  Let's make another cut =
through these.  Seems that folks like the title

    > Localized Mobility =
Management.  I didn't retain the original numbers.

    >

    > Agreed upon requirements where =
there was no dissent:

    > 1. Regional registration shall =
be introduced to minimize the signaling

    > traffic to the home agent or =
correspondent nodes for intradomain mobility.

    > 2. Regional registration shall =
be secure against malicious behavior from

    > visiting mobiles

    >

    


    Perhaps on 2 we want to incorporate =
_any_ malicious behaviour..not just the

    MNs??

    

    


    >

    > That's about it.

    >

    > There was only minor dissent on =
these:

    > 3. Connectivity to the mobiles =
shall not be interrupted in the presence of

    > the failure of regional =
registration agents.

    


    I would like to propose here that this =
requirement is made rather more generic.

    The requirement in the rationale I =
have considered is that :

    


         "a =
Localised mobility management scheme should be able to adapt to

    topological changes

    arising in the domain that the LMM =
scheme is in effect.

    


    The reason:

    


        the failure of LMM =
agents manifests itself as a topological change, since

    in IPv6 any such LMM agent will be a =
routing element. However, the population

    of new routing elements that can be =
potential candidates for LMM agents is also

    a manifestation of a topological =
change.

    


    The LMM scheme should be able to adapt =
to both; the latter is extremely

    important in terms of scalability and =
incremental deployment since we cannot

    expect to cast a domain topology in =
stone and live without expansion.

    


    >

    > [Only comment was that =
disruption should be minimized.  I'd like to get a

    > sense from the working group =
whether it feels that this one should be

    > restated]

    


    My feeling on this one is that =
objectively we need to strive for elimination.

    However, with the current expertise =
we have this may not seem a realistic

    target for the particular requirement =
which to me sounds like

    


    "topological changes in the =
routing fabric with regard to an LMM scheme MUST

    bear a measure of minimal disruption =
to the extension optimizations effected by

    that (LMM) scheme. However, it is the =
intention that an LMM scheme should

    strive to eliminate even minimal =
disruption to the MNs, if possible."

    


    As such we should explictly state that =
we are making a minimum requirement the

    minimization and we strive for =
elimination.

    

    

    


    >

    > 4. Regional registration shall =
support fast handoffs.

    > [Several comments that it should =
be compatible and no dependencies between

    > the specs, so how about: =
Regional registration shall be compatible with fast

    > handoffs.]

    >

    


    Agreed. Although I think that it is =
fast handoffs that should worry about that

    requirement not the LMM scheme =
itself. In a divide and conquer manner I

    consider that you try to =
effect

    


       1. Mobility

        1.a  =
localisation of mobility and subsequent speedups (LMM)

           =
1.a.a speedup optimizations by applying fast handoff techniques =
over

    that LMM...

    


    So the compatibility is for the fast =
handoff scheme not for LMM since the LMM

    is the core of the =
optimization...

    


    I am not sure what is the order of =
prescedence for others over fast handoffs

    though..

    


    [MJ]  I agree that the fast handoff should comply =
with the LMM requirements. Hence, I would like to propose the 

    following =
additional LMM requirement.

    


    x. LMM MAY require a =
MN to change IP address as a result of handover to the new AR.

    


    Hence, any fast =
handoff solution based on LMM requirement SHOULD not automatically =
assume change of IP address during handoff. The fast handoff solution =
should provide a provision in its signaling messages whether or not new =
AR should assign a new IP address. I think this requirement is =
important to decouple LMM with fast handoff. If LMM requires MNs to get =
new IP address at the new ARs, then it should be somehow (e.g. through =
configuring handoff signaling message) made known to the fast handoff, =
hence fast handoff can facilitate acquisition of new IP address. For =
example, fast handover IPv6 defines code value 1 (No change of COA =
required) for IPv6 PrRtAdv message, but assumes always change of =
address in HI message. I think HI message should also have a bit (like =
S bit defining stateful address configuration) defining whether or not =
change of address is required. 
    


    > 5. Regional registration shall =
scale to support millions of nodes in a

    > visited network.

    > [One comment that this was too =
broad, so I'd request someone to rephrase it

    > in a better way]

    >

    


    Well thinking about it again and again =
we have two sides of scalability, one

    interacting with the other. =
Consider:

    


          The LMM =
scheme should be able to adapt (according to the rationale I =
have

    provided above) to topological =
changes effected in the routing fabric of the

    domain the LMM scheme gets applied =
on. But why should it be able to adapt? Of

    course to utilise _all_ the available =
(during expansion) or possible (during

    contraction) routing elements and =
thus candidate LMM agents.

    


        On reason for that =
is to optimize the localisation point (better

    candidates). But as soon as the =
localisation point gets optimized in a

    distributed fashion (i.e. not all MNs =
get the same one) you have what?????

    SCALABILITY.....

    


    So adaptivity may implicitly effect =
scalability from the routing fabric's

    viewpoint of an LMM scheme.

    


    From the perspective of the MN:

    


         We want the =
following:

       "the LMM-enabled =
domain to support a dense population of mobile nodes."

    


    That may be mi/bi/trillions, etc. =
However, to effect that, the LMM scheme MUST

    take advantage of the scalability =
potentials of the routing fabric in terms of

    LMM-aware routers.

    An that implies that it is the LMM =
scheme that has to provide such internal

    scalability before it can adhere to =
any scalability goals for dense MN

    populations within an LMM-aware =
domain.

    

    


    In that respect, I am inclined to say =
that:

    


    an LMM scheme MUST provide scalable =
population of LMM-aware routing elements

    which should be utilised if the =
scheme is to support dense populations of MNs

    within an LMM-aware domain.

    

    

    


    >

    > Mostly disagreement on =
these:

    > 6. .  Regional registration =
shall not introduce new overhead on links

    > between the mobile and the local =
mobility management agents.

    > [Comments were that it should be =
minimized, or that it was ok if it meant no

    > more overhead than a binding =
update.  Here's my attempt at a revision: local

    > mobility management shall not =
introduce new messages to notify the LMM

    > agents of a move.  There is =
a disagreement as to whether adding additional

    > over the air bytes is an issue, =
and if it is whether it's this WG's

    > responsibility to solve =
it]

    >

    


    I agree that an LMM scheme should =
minimize overhead on links between LMM agents

    and MNs

    But there is also a slight falacy =
about what constitutes a new message. We have

    the backdoor of expanding the BU I =
guess so I could render the requirement

    invalid.

    


    I think it would work better to let =
implementors feel responsible about

    minimization rather than trying to =
constraint them like that..they usually find

    the backdoor straight away..

    

    


    > 7. Regional registration shall =
allow multiple levels of hierarchy.

    > [There was some strong =
disagreement on this.  Perhaps Jim or Karim could

    > start a separate thread to track =
this one down?]

    


    I personally insist that multiple =
levels of LMM hierarchy should be allowed. I

    feel unconvinced that single depth is =
sufficient for different LMM scenarios

    

    


    >

    > 8. Regional registration shall =
not require changes ot the MN, the home

    > agent, or correspondent =
nodes.

    > [Many thought requiring no =
change to the MN was not doable, but the home

    > agent or CN should be =
unchanged.  So I propose we just rewrite this as:

    > Regional registration shall not =
require changes to the home agent or

    > correspondent nodes.]

    


    fine

    


    >

    > 9. Regional registration shall =
not introduce host routes in routing tables.

    > [Didn't get much positive on =
this one and got the sense folks don't want to

    > rathole on a host routing =
discussion.  I propose we drop this.]

    


    agreed

    


    >

    >

    > We also had request for some new =
requirements:

    > 10. LMM should provide the same =
level of mobility mgmt support as in the

    > basic MIP v6 spec.  MM fns =
supported in MIP v6 must not be reduced.

    > [Some positive feedback on this, =
shall we keep it?]

    >

    


    if we specify what we mean by level of =
mobility management so that we

    understand what we are talking about, =
then maybe....

    

    

    


    > 11. LMM must interwork with =
MIPv6, IPv6, and the proposed mechanisms for SA

    > establishment

    > [One comment that this was =
stating the obvious.  Shall we keep it?]

    >

    


    I am not in favour of keeping that for =
reasons already explained.

    

    


    >

    > 12. LMM should be optimized for =
mobile-to-mobile.

    > [Never really understood what =
this requirement was supposed to be.  Got

    > similar feedback from =
others.  I propose we drop it.]

    >

    


    basically here people referred to CN =
being in the same net with the MN and both

    being mobile, didn't they?

    


    Although the description of the =
original req has not been very clear, I suggest

    we either become clearer on what we =
want to get out of that or drop it.

    

    


    >

    > Received no feedback on the =
following proposed requirements.  Anybody want

    > to keep these?

    > 13. Should minimize # of network =
nodes affected by HO signalling.

    >

    


    not sure about what is meant by =
that..either elaborate a little or drop..

    

    


    > 14. Should support =
autoconfig.

    >

    


    I would say an ABSOLUTE 'must' or at =
worst 'should'. Most LMM schemes I know

    of, have pushed a lot of important =
parts of the protocol. If single points of

    failure must be resolved then =
autoconfiguration is nothing _less_ than a must.

    

    


    > 15. Should simplify network =
design and provisioning.

    


    simplification is a contradiction to =
specialisation (i.e. extension). Drop.

    

    


    Theo

    


    UCL/Mobile Systems

    




------_=_NextPart_001_01C0CC2B.FEFBF8C0--


From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 23 18:27: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 SAA14078
	for ; Mon, 23 Apr 2001 18:27: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 PAA02938;
	Mon, 23 Apr 2001 15:22: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 MAA24650;
	Mon, 23 Apr 2001 12:30:39 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3NJS8K9013105
	for ; Mon, 23 Apr 2001 12:28:08 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3NJS8VI013104
	for mobile-ip-dist; Mon, 23 Apr 2001 12:28: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3NJRwK9013097
	for ; Mon, 23 Apr 2001 12:27: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 MAA27721
	for ; Mon, 23 Apr 2001 12:27:56 -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 MAA16732
	for ; Mon, 23 Apr 2001 12:27: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 f3NJRqO18214
	for ; Mon, 23 Apr 2001 21:27:53 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Mon Apr 23 19:49:13 2001 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Mon, 23 Apr 2001 19:44:35 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBD92@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Revised Localized Mobility Management Requirement
	 s
Date: Mon, 23 Apr 2001 19:49:12 +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, 

Just catching up on email, one clarification below.


> >I think this change could bring new functionality into local MIP mobility
> >which is not necessarily needed. The local agent is basically a
> >local HA. 
> 
> Actually, that is only true for HMIP. In RegReg, it is a router. 
> 
	=> That's not true. HMIP basic mode is identical to the HA, 
	but Extended mode is a HA with some modification. How is 
	RegReg different from an Etended mode MAP ? 

	Regards,
	Hesham



From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 04:11:37 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA04819
	for ; Tue, 24 Apr 2001 04:11: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 BAA27334;
	Tue, 24 Apr 2001 01:10: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 BAA02475;
	Tue, 24 Apr 2001 01:10:48 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3O88vK9013817
	for ; Tue, 24 Apr 2001 01:08:57 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3O88uQQ013816
	for mobile-ip-dist; Tue, 24 Apr 2001 01:08: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3O88kK9013809
	for ; Tue, 24 Apr 2001 01:08:48 -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 BAA26408
	for ; Tue, 24 Apr 2001 01:08:45 -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 DAA10572
	for ; Tue, 24 Apr 2001 03:17:24 -0600 (MDT)
Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.43.101])
	by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id BAA10583
	for ; Tue, 24 Apr 2001 01:07:22 -0700 (PDT)
Received: from GDOMMETY-W2K2.cisco.com (gdommety-dsl5.cisco.com [10.19.17.142])
	by mira-sjcm-3.cisco.com (Mirapoint)
	with ESMTP id ADQ27059;
	Tue, 24 Apr 2001 01:08:40 -0700 (PDT)
Message-Id: <4.3.2.7.2.20010424010738.017aec80@mira-sjcm-3.cisco.com>
X-Sender: gdommety@mira-sjcm-3.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 24 Apr 2001 01:10:28 -0700
To: mobile-ip@sunroof.eng.sun.com
From: Gopal Dommety 
Subject: [mobile-ip] New RFC 3115 replacing RFC 3025 
In-Reply-To: <3ACF28C6.1BCA13E4@attglobal.net>
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: 

Hello,

	New RFC 3115 was issued replacing RFC 3025 correcting the discrepancy
between the IANA assigned types and the ones listed in the RFC.

Thanks
Gopal




From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 04:18: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 EAA04866
	for ; Tue, 24 Apr 2001 04:18:32 -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 BAA24905;
	Tue, 24 Apr 2001 01:17: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 BAA03151;
	Tue, 24 Apr 2001 01:17:52 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3O8GTK9013860
	for ; Tue, 24 Apr 2001 01:16:30 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3O8GTFJ013859
	for mobile-ip-dist; Tue, 24 Apr 2001 01:16: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3O8G4K9013852
	for ; Tue, 24 Apr 2001 01:16:13 -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 BAA19524
	for ; Tue, 24 Apr 2001 01:16:03 -0700 (PDT)
Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA29003
	for ; Tue, 24 Apr 2001 01:16:02 -0700 (PDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f3O8G1e31184
	for ; Tue, 24 Apr 2001 10:16:01 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA09163
	for ; Tue, 24 Apr 2001 10:16:00 +0200 (MET DST)
Received: from localhost (localhost [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f3O8G0A03918
	for ; Tue, 24 Apr 2001 10:16:00 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200104240816.f3O8G0A03918@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Mobile IPv6 Home Agent product and best place? 
In-reply-to: Your message of Mon, 23 Apr 2001 19:41:03 +0900.
             <3AE406BF.30306@eastelsystems.com> 
Date: Tue, 24 Apr 2001 10:16:00 +0200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 In your previous mail you wrote:

   I questioned if there is any product(Home Agent) for supporting mobile IPv6.

=> I don't know for *products* but many mobile IPv6 implementations,
even partial implementations, have support for the HA.

   And in 3G network, where is the best place for HA?
   
=> on the home link... This is not a joke, the real issue is from which ISP
you get your addresses.

Regards

Francis.Dupont@enst-bretagne.fr

PS: this is a case where the mobile will never be attached to the home link,
in fact the home link doesn't need to physically exist.


From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 10:59:16 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08846
	for ; Tue, 24 Apr 2001 10:59: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 HAA29033;
	Tue, 24 Apr 2001 07:57: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 HAA14309;
	Tue, 24 Apr 2001 07:57:47 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OEukK9014231
	for ; Tue, 24 Apr 2001 07:56:46 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3OEukmd014230
	for mobile-ip-dist; Tue, 24 Apr 2001 07:56: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 bebop.france (bebop.France.Sun.COM [129.157.174.15] (may be forged))
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OEuaK9014223
	for ; Tue, 24 Apr 2001 07:56:37 -0700 (PDT)
Received: from lillen (gbl-rem-34 [129.157.174.34])
	by bebop.france (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id QAA18315;
	Tue, 24 Apr 2001 16:56:32 +0200 (MET DST)
Date: Tue, 24 Apr 2001 07:56:32 -0700 (PDT)
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: Basavaraj.Patil@nokia.com
In-Reply-To: "Your message with ID" <200104201942.MAA28080@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: 

> Ulimately, the issue is one of deployment. The worst possible case
> is we cycle an LMM protocol without multiple levels of hierarchy
> to proposed and discover during deployment that we need it. 

Jim,

You are stating the design philosophy that leads to kitchen sink
protocols - put in as much as possible to make sure nothing we can
ever imagine has been left out.

I much prefer the opposite philosophy - only include what we know for 
sure will be needed.

   Erik




From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 11:06:17 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08963
	for ; Tue, 24 Apr 2001 11:06:16 -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 HAA26891;
	Tue, 24 Apr 2001 07:55: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 HAA10781;
	Tue, 24 Apr 2001 07:55:21 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OEs8K9014211
	for ; Tue, 24 Apr 2001 07:54:08 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3OEs7wv014210
	for mobile-ip-dist; Tue, 24 Apr 2001 07: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OErvK9014203
	for ; Tue, 24 Apr 2001 07:53: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 HAA10634
	for ; Tue, 24 Apr 2001 07:53:57 -0700 (PDT)
From: marc.greis@nokia.com
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA08942
	for ; Tue, 24 Apr 2001 07:53:56 -0700 (PDT)
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 f3OErqg16456
	for ; Tue, 24 Apr 2001 09:54:02 -0500 (CDT)
Received: from daebh01nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id  for ;
 Tue, 24 Apr 2001 09:53:45 -0500
Received: by daebh01nok with Internet Mail Service (5.5.2652.78)
	id ; Tue, 24 Apr 2001 09:53:45 -0500
Message-ID: <30F2DED23724D311902D0008C7EABAFB04630DAF@daeis06nok>
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Mobile IPv6 Home Agent product and best place?
Date: Tue, 24 Apr 2001 09:53:42 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="KS_C_5601-1987"
Sender: owner-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,

Without trying to give a good answer to your question at this point, I'd
like to remind you that there are different "flavors" of "3G" (3GPP, 3GPP2,
different releases, etc.), so I'm sure you'll be more likely to get a
helpful answer to your question if you are a bit more specific about which
flavor of 3G you are referring to.

Marc

> -----Original Message-----
> From: ext Jang JaeIk [mailto:jijang@eastelsystems.com]
> Sent: 23 April, 2001 5:41 AM
> To: mobile-ip@sunroof.eng.sun.com
> Subject: [mobile-ip] Mobile IPv6 Home Agent product and best place?
> 
> 
> Hi all
> 
> I questioned if there is any product(Home Agent) for 
> supporting mobile IPv6.
> And in 3G network, where is the best place for HA?
> 
> Thanks in advance.
> 


From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 12:27: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 MAA10174
	for ; Tue, 24 Apr 2001 12:27:25 -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 IAA12486;
	Tue, 24 Apr 2001 08:58: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 IAA00157;
	Tue, 24 Apr 2001 08:56:41 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OFtUK9014312
	for ; Tue, 24 Apr 2001 08:55:31 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3OFtUuC014311
	for mobile-ip-dist; Tue, 24 Apr 2001 08:55: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OFtMK9014304
	for ; Tue, 24 Apr 2001 08:55: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 IAA20107;
	Tue, 24 Apr 2001 08:55:21 -0700 (PDT)
Message-Id: <200104241555.IAA20107@heliopolis.eng.sun.com>
Date: Tue, 24 Apr 2001 08:55:21 -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
Cc: Basavaraj.Patil@nokia.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: Yi1VDbApn86w7XUToqZpYA==
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,

>> Ulimately, the issue is one of deployment. The worst possible case
>> is we cycle an LMM protocol without multiple levels of hierarchy
>> to proposed and discover during deployment that we need it. 
>
>Jim,
>
>You are stating the design philosophy that leads to kitchen sink
>protocols - put in as much as possible to make sure nothing we can
>ever imagine has been left out.
>
>I much prefer the opposite philosophy - only include what we know for 
>sure will be needed.
>


Actually, no. I'm saying that we have had at least three people who
have given good arguments, IMHO, as to why multiple levels of
hierarchy might be needed. On the other side, those arguments
are refuted by two people who think that no hierarchy is needed.
Neither side is going to convince the other, both sides have
good arguments.

The kitchen sink results when somebody says "let's put in this neat
feature," then somebody else says "let's put in this neat feature,"
and the group iterates on this for several rounds with nobody 
really coming up with good arguments for or against the feature except
that it was X's idea.

What I'm saying is that we have some arguments the feature is needed,
so let's put it in. From Karim's last email, it sounds like we can
probably accommodate his concerns about multiplying failure possibilities.
If we don't put it in and deployment proves that we need it, as I and
at least two other people on the list think will likely be the case, we
are stuck with going back through proposed standard. 

		jak



From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 13:12: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 NAA10822
	for ; Tue, 24 Apr 2001 13:12: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 KAA21839;
	Tue, 24 Apr 2001 10:10:55 -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 KAA11214;
	Tue, 24 Apr 2001 10:09:29 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OH89K9014350
	for ; Tue, 24 Apr 2001 10:08:09 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3OH89Gb014349
	for mobile-ip-dist; Tue, 24 Apr 2001 10:08: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OH7wK9014342
	for ; Tue, 24 Apr 2001 10:08:00 -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 KAA09146
	for ; Tue, 24 Apr 2001 10:07:58 -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 KAA00599
	for ; Tue, 24 Apr 2001 10:07:57 -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 KAA22742
	for ; Tue, 24 Apr 2001 10:07:56 -0700 (PDT)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3OH7sA08940
	for ; Tue, 24 Apr 2001 10:07:54 -0700
X-mProtect:  Tue, 24 Apr 2001 10:07:54 -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(WTS.12.69) smtpdLyBL9X; Tue, 24 Apr 2001 10:07:45 PDT
Message-ID: <3AE5B308.FCC68DBA@iprg.nokia.com>
Date: Tue, 24 Apr 2001 10:08:24 -0700
From: Charlie Perkins 
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: 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: <200104241555.IAA20107@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 James and Erik,

The point of hierarchy is to localize the signaling.  That's a good
feature.  It also has the advantage of reducing signaling across
administrative boundaries.  Both of these are valuable for scalability.
Furthermore, I think that proper design will see to it that not
much complexity is added.  The reason for this is that the
regional-aware routers act "enough" like home agents that
almost the same protocol works.  I think even HMIP could
be made to work with hierarchy; the restriction seems purely
artificial.

Adding features for special cases can be good or bad.  However
that isn't what is happening here.  It's almost like removing restrictions
to allow more general operation.  That's not a kitchen-sink approach.

Regards,
Charlie P.


James Kempf wrote:

> Hi Erik,
>
> >> Ulimately, the issue is one of deployment. The worst possible case
> >> is we cycle an LMM protocol without multiple levels of hierarchy
> >> to proposed and discover during deployment that we need it.
> >
> >Jim,
> >
> >You are stating the design philosophy that leads to kitchen sink
> >protocols - put in as much as possible to make sure nothing we can
> >ever imagine has been left out.
> >
> >I much prefer the opposite philosophy - only include what we know for
> >sure will be needed.
> >
>
> Actually, no. I'm saying that we have had at least three people who
> have given good arguments, IMHO, as to why multiple levels of
> hierarchy might be needed. On the other side, those arguments
> are refuted by two people who think that no hierarchy is needed.
> Neither side is going to convince the other, both sides have
> good arguments.
>
> The kitchen sink results when somebody says "let's put in this neat
> feature," then somebody else says "let's put in this neat feature,"
> and the group iterates on this for several rounds with nobody
> really coming up with good arguments for or against the feature except
> that it was X's idea.
>
> What I'm saying is that we have some arguments the feature is needed,
> so let's put it in. From Karim's last email, it sounds like we can
> probably accommodate his concerns about multiplying failure possibilities.
> If we don't put it in and deployment proves that we need it, as I and
> at least two other people on the list think will likely be the case, we
> are stuck with going back through proposed standard.
>
>                 jak



From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 13:37:27 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11181
	for ; Tue, 24 Apr 2001 13:37: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 KAA28682;
	Tue, 24 Apr 2001 10:36: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 KAA16048;
	Tue, 24 Apr 2001 10:36:08 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OHYaK9014391
	for ; Tue, 24 Apr 2001 10:34:36 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3OHYawe014390
	for mobile-ip-dist; Tue, 24 Apr 2001 10:34: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OHYNK9014383
	for ; Tue, 24 Apr 2001 10:34:25 -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 KAA22710
	for ; Tue, 24 Apr 2001 10:34:22 -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 KAA15888
	for ; Tue, 24 Apr 2001 10:34:21 -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 KAA25180
	for ; Tue, 24 Apr 2001 10:34:20 -0700 (PDT)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3OHYJO19825
	for ; Tue, 24 Apr 2001 10:34:19 -0700
X-mProtect:  Tue, 24 Apr 2001 10:34:19 -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(WTS.12.69) smtpdV3su1Q; Tue, 24 Apr 2001 10:34:12 PDT
Message-ID: <3AE5B915.F12B64BA@iprg.nokia.com>
Date: Tue, 24 Apr 2001 10:34:13 -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

Hi Erik,

   I am not sure if you have seen the reasons I have provided for
multi-level hierarchy in previous postings.

While I have not seen any arguments against  them you claim that we are
trying to include everything in the requirements including the kitchen
sink...I feel that this is not the case.

I did not present previous reasoning as a nicety but as an upcoming (in
the very near future) need. I feel that short-sighted requirements
specifications is bound to meet serious revisiting later and as such
lack of concrete consideration.

I am sure that you would agree that when you design for a protocol you
do not only cater for what you need right now. In my book this is called
patchwork since the so called incremental evolution in protocol can only
bring side-effects to the core features..twist that tweak there and the
protocol as a totality looks like Frankenstein...

So I would argue against the philosophy of "include what we know for
sure will succeed". This looks to me like a telecoms attitude.. that
would take on only what is a guaranteed success...perhaps people these
days are influenced more by the Nasdaq indexes..

But in anycase there is no such case that we know for sure it will
succeed with the current set of requirements for LMM..nobody has
deployed such scheme yet (to my knowledge)..we are only trying to be
robust and complete on important issues that the constituency feels
strongly about LMM. I believe that this is far from "kitchen sink"
reflections...


Theo

UCL/ Mobile Systems


Erik Nordmark wrote:

> > Ulimately, the issue is one of deployment. The worst possible case
> > is we cycle an LMM protocol without multiple levels of hierarchy
> > to proposed and discover during deployment that we need it.
>
> Jim,
>
> You are stating the design philosophy that leads to kitchen sink
> protocols - put in as much as possible to make sure nothing we can
> ever imagine has been left out.
>
> I much prefer the opposite philosophy - only include what we know for
> sure will be needed.
>
>    Erik



From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 15:13: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 PAA12983
	for ; Tue, 24 Apr 2001 15:13: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 MAA26187;
	Tue, 24 Apr 2001 12:12: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 MAA14120;
	Tue, 24 Apr 2001 12:12:35 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OJAPK9014455
	for ; Tue, 24 Apr 2001 12:10:25 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3OJAOT9014454
	for mobile-ip-dist; Tue, 24 Apr 2001 12:10:24 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OJAEK9014447
	for ; Tue, 24 Apr 2001 12:10:16 -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 MAA22901
	for ; Tue, 24 Apr 2001 12:10:13 -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 MAA14413
	for ; Tue, 24 Apr 2001 12:10:12 -0700 (PDT)
Received: from ws34.nomadiclab.com (ws34.nomadiclab.com [195.165.196.34])
	by ws130.nomadiclab.com (Postfix) with ESMTP id 1834B72505
	for ; Tue, 24 Apr 2001 22:10:05 +0300 (EEST)
Received: from nomadiclab.com (localhost [127.0.0.1])
	by ws34.nomadiclab.com (Postfix) with ESMTP id 633B1BA0B
	for ; Tue, 24 Apr 2001 22:10:04 +0300 (EEST)
Message-ID: <3AE503F9.6D6D2110@nomadiclab.com>
Date: Tue, 24 Apr 2001 07:41:29 +0300
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

Lars Henrik Petander wrote:
> 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.

Right.  But only from a limited number of locations within the Internet.

> A good example of a vulnerable
> host is a MN in its home network, which is likely to be wireless and
> eavesdroppable.

MN's home network is indeed vulnerable, since being located there
allows an attacker to launch an active attack against an arbitrary CN.
The same applies to any attacker at the CN->HA link, the home network
is no different in that sense.  However, even being located at the MN's 
home network should be safe against passive attackers.  However, if you 
have found an attack where it is enough to eavesdrop at the MN's home 
network, please describe it.  That is, there are certain to be attacks
the we haven't thought about.

> 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 don't have any personal opinions with regard to BAKE.  I just started
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.  

What comes to D-H, IMHO the triangular message exchange in BAKE is
_almost_ as safe as D-H, and much cheaper.  (The difference is
that BAKE is vulnerable to passive attackers that are able to
eavesdrop near the CN or both the MN->CN and CN->HA links, while
D-H is not.  I think that there is no difference with regard to
active attackers, but I am not quite sure.)

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.

> I am afraid that any unauthenticated key exchange is likely to suffer from
> the same (or a similar) vulnerability. 

I agree.

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

As I already said above, I mostly agree.  However, my thoughts are still
unclear about the relative benefits and drawbacks of using certificates
vs. implicitly authenticated keys ala CAM/SUCV/PBK-ADDRESSES.

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.

> In absence of a PKI they could always revert to unauthenticated
> key establishment, the use of which should be configurable in CNs.

IMHO global PKI is an unrealistic assumption.  One issue here is 
whether you want to use BAKE at all if you have properly authorized
public keys.  If you have public keys, you probably could and should
use some other protocol, such as IKE (or maybe HIP :-), in any case,
and leave BAKE or something like that for the case when you don't
have such keys.

Really, the interesting case here is when you don't have properly 
authorized keys, i.e. either no keys or CAM/SUCV/PBK/PBK-ADDRESSES 
like keys.  IMHO, BAKE does quite a good job for the case of no
keys, but more work is needed for the CAM/... case.

--Pekka Nikander




From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 16:26: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 QAA14566
	for ; Tue, 24 Apr 2001 16:26:27 -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 NAA26368;
	Tue, 24 Apr 2001 13:24: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 NAA28790;
	Tue, 24 Apr 2001 13:23:50 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OKKtK9014543
	for ; Tue, 24 Apr 2001 13:20:55 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3OKKt2e014542
	for mobile-ip-dist; Tue, 24 Apr 2001 13:20:55 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OKKhK9014535
	for ; Tue, 24 Apr 2001 13:20:45 -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 NAA25442
	for ; Tue, 24 Apr 2001 13:20:32 -0700 (PDT)
From: Basavaraj.Patil@nokia.com
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA25663
	for ; Tue, 24 Apr 2001 13:20:32 -0700 (PDT)
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 f3OKKQg10254
	for ; Tue, 24 Apr 2001 15:20:36 -0500 (CDT)
Received: from daebh01nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id  for ;
 Tue, 24 Apr 2001 15:20:21 -0500
Received: by daebh01nok with Internet Mail Service (5.5.2652.78)
	id ; Tue, 24 Apr 2001 15:20:21 -0500
Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B032138CF@daeis07nok>
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Q: GNAIE
Date: Tue, 24 Apr 2001 15:20:20 -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: 

RFC2794 already has a type value (131) assigned to the MN-NAI extension.
draft-ietf-mobileip-gnaie-02.txt proposes in section 2.1 a new type for the
same extension. Do we really require this? 

The problem that I have is that the same data (MN-NAI) will have different
type values depending on the format of the extension in use (MIER or
othewise).

-Basavaraj


From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 16:42:17 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14840
	for ; Tue, 24 Apr 2001 16:42:17 -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 NAA09402;
	Tue, 24 Apr 2001 13:41: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 NAA00326;
	Tue, 24 Apr 2001 13:41:23 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OKdSK9014577
	for ; Tue, 24 Apr 2001 13:39:29 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3OKdSHl014576
	for mobile-ip-dist; Tue, 24 Apr 2001 13:39: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OKdJK9014569
	for ; Tue, 24 Apr 2001 13:39: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 NAA02792
	for ; Tue, 24 Apr 2001 13:39:18 -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 NAA05916
	for ; Tue, 24 Apr 2001 13:39:17 -0700 (PDT)
Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.43.101])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA00014
	for ; Tue, 24 Apr 2001 13:39:43 -0700 (PDT)
Received: from GDOMMETY-W2K2.cisco.com (dhcp-171-70-57-67.cisco.com [171.70.57.67])
	by mira-sjcm-3.cisco.com (Mirapoint)
	with ESMTP id ADQ38556;
	Tue, 24 Apr 2001 13:39:13 -0700 (PDT)
Message-Id: <4.3.2.7.2.20010424134007.017a8290@mira-sjcm-3.cisco.com>
X-Sender: gdommety@mira-sjcm-3.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 24 Apr 2001 13:41:02 -0700
To: mobile-ip@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com
From: Gopal Dommety 
Subject: Re: [mobile-ip] Q: GNAIE
In-Reply-To: <7B5C0390ACE7D211BC9C0008C7EABA2B032138CF@daeis07nok>
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 03:20 PM 4/24/2001 -0500, Basavaraj.Patil@nokia.com wrote:
>RFC2794 already has a type value (131) assigned to the MN-NAI extension.
>draft-ietf-mobileip-gnaie-02.txt proposes in section 2.1 a new type for the
>same extension. Do we really require this?


I don't think having two types for the same extension is a good idea.

-Gopal


>The problem that I have is that the same data (MN-NAI) will have different
>type values depending on the format of the extension in use (MIER or
>othewise).
>
>-Basavaraj



From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 16:44:44 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14924
	for ; Tue, 24 Apr 2001 16:44: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 NAA11336;
	Tue, 24 Apr 2001 13:43: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 NAA01086;
	Tue, 24 Apr 2001 13:43:45 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OKgIK9014587
	for ; Tue, 24 Apr 2001 13:42:18 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3OKgHBZ014586
	for mobile-ip-dist; Tue, 24 Apr 2001 13:42: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OKg5K9014579
	for ; Tue, 24 Apr 2001 13:42:05 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA00553
	for ; Tue, 24 Apr 2001 13:42:04 -0700 (PDT)
Received: from darius (darius [152.70.40.121])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id NAA28145
	for ; Tue, 24 Apr 2001 13:42:03 -0700 (PDT)
Date: Tue, 24 Apr 2001 13:42:06 -0700 (PDT)
From: Patrice Calhoun 
Subject: Re: [mobile-ip] Q: GNAIE
To: mobile-ip@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <7B5C0390ACE7D211BC9C0008C7EABA2B032138CF@daeis07nok>
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: 

> RFC2794 already has a type value (131) assigned to the MN-NAI extension.
> draft-ietf-mobileip-gnaie-02.txt proposes in section 2.1 a new type for the
> same extension. Do we really require this? 
> 
> The problem that I have is that the same data (MN-NAI) will have different
> type values depending on the format of the extension in use (MIER or
> othewise).

Correct.

I suppose it would be OK for GNAIE NOT to re-define the MN-NAI since it is
already specified in RFC 2794. As it stands, my code would accept both formats.
 PatC



From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 17:39: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 RAA15878
	for ; Tue, 24 Apr 2001 17:39:05 -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 OAA29845;
	Tue, 24 Apr 2001 14:37: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 OAA18394;
	Tue, 24 Apr 2001 14:37:24 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OLZAK9014656
	for ; Tue, 24 Apr 2001 14:35:11 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3OLZAwG014655
	for mobile-ip-dist; Tue, 24 Apr 2001 14:35: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OLZ0K9014648
	for ; Tue, 24 Apr 2001 14:35:01 -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 OAA19020
	for ; Tue, 24 Apr 2001 14:35:00 -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 OAA05932
	for ; Tue, 24 Apr 2001 14:34:59 -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 f3OLYwN06168
	for ; Tue, 24 Apr 2001 23:34:58 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Apr 24 23:34:58 2001 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Tue, 24 Apr 2001 23:34:57 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBD9F@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Cc: Basavaraj.Patil@nokia.com
Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L
	 ocalized Mobility Management Requirement s)
Date: Tue, 24 Apr 2001 23:34:56 +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: 


> Actually, no. I'm saying that we have had at least three people who
> have given good arguments, IMHO, as to why multiple levels of
> hierarchy might be needed. On the other side, those arguments
> are refuted by two people who think that no hierarchy is needed.
> Neither side is going to convince the other, both sides have
> good arguments.
> 
	=> I'm not sure who you mean by the "two" people, there is definitely 
	more (at least the authors of HMIP are) but anyway
	after reading the discussion it really seems to me like the only 
	two (understandable IMHO) reasons are:

	1.  In future there may be a need for multi-level hierarchy. That need 
	is not explained really. To me this is not a good reason for including
	any feature. Ithink it makes a lot of sense of scope the problem to
	what we know without "guessing" what might happen in future
	and how theuse of MIP can be changed dramatically. No one 
	knows that this is true.

	2. Multi-level hierarchy localises the signalling. Let's try to understand 
	what this really means. A MAP domain is as large as the amount 
	of traffic that a MAP can handle, regardless of the number of 
	levels of hierarchy. The signalling will always be local to that
	domain. So I'm not really clear on the significant advantage here. 
	We're certainly not expecting any inter-continental mobility 
	management using HMIPv6. So careful placement of the MAP 
	using network engineering skills and common sense is 
	sufficient. 

> What I'm saying is that we have some arguments the feature is needed,
> so let's put it in. From Karim's last email, it sounds like we can
> probably accommodate his concerns about multiplying failure possibilities.
> 
	=> At a cost. The beneft MUST outweigh the cost. This is not 
	the case here IMO.

> If we don't put it in and deployment proves that we need it, 
> 
	=> This is exactly point one above. 

	Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 17:45:40 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15968
	for ; Tue, 24 Apr 2001 17:45: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 OAA01917;
	Tue, 24 Apr 2001 14:45: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 OAA28346;
	Tue, 24 Apr 2001 14:43:08 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OLfnK9014676
	for ; Tue, 24 Apr 2001 14:41:49 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3OLfnx9014675
	for mobile-ip-dist; Tue, 24 Apr 2001 14:41: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OLfdK9014668
	for ; Tue, 24 Apr 2001 14:41:40 -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 OAA14475
	for ; Tue, 24 Apr 2001 14:41:40 -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 OAA09466
	for ; Tue, 24 Apr 2001 14:41:39 -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 f3OLfcO16369
	for ; Tue, 24 Apr 2001 23:41:38 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Tue Apr 24 23:41:37 2001 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Tue, 24 Apr 2001 23:36:58 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBDA0@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 L
	 ocalized Mobility Management Requirement s)
Date: Tue, 24 Apr 2001 23:41: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: 

	Hello Charlie,

> The point of hierarchy is to localize the signaling.  That's a good
> feature.  It also has the advantage of reducing signaling across
> administrative boundaries.  
> 
	=> I don't understand how multi-level hierarchy can reduce 
	signalling across administrative domains. If by "administrative
	domains" you refer to the top Anchor's domain then signalling 
	to the HA is required regardless of how many levels you have.. 

> Both of these are valuable for scalability.
> 
	=> IMHO a real scalability benefit from hierarchy would be 
	if we can have less state in the "further" agents than 
	he "closer" ones. This is not the case in single level
	or multi-level hierarchy so I'm not sure I see a significant
	scalability benefit.

	Regards,
	Hesham



From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 17:49:22 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16063
	for ; Tue, 24 Apr 2001 17:49:21 -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 OAA05015;
	Tue, 24 Apr 2001 14:48: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 OAA00051;
	Tue, 24 Apr 2001 14:48:28 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OLktK9014712
	for ; Tue, 24 Apr 2001 14:46:55 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3OLksB0014711
	for mobile-ip-dist; Tue, 24 Apr 2001 14:46: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OLkjK9014704
	for ; Tue, 24 Apr 2001 14:46:45 -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 OAA06325;
	Tue, 24 Apr 2001 14:46:45 -0700 (PDT)
Message-Id: <200104242146.OAA06325@heliopolis.eng.sun.com>
Date: Tue, 24 Apr 2001 14:46:46 -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
Cc: Basavaraj.Patil@nokia.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: rluyIY7dc6e13BiwqM6+1w==
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,

Thanx for your response, but I think we've been through these
points a number of times, we really don't need to rehash them again. Charlie, 
Theo, myself, and one other person (whose name I've forgotten) have spoken up 
for a requirement to support hierarchy. You and Karim have spoken up against it, 
and Raj, expressing a preference for simplicity, has an inclination
against it.

Anybody else out there in SMTP-land want to express a preference?

Phil, any ideas about how to proceed?

		jak


>From: "Hesham Soliman  (ERA)" 
>To: "'mobile-ip@sunroof.eng.sun.com'" 
>Cc: Basavaraj.Patil@nokia.com
>Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L 
ocalized Mobility Management Requirement s)
>Date: Tue, 24 Apr 2001 23:34:56 +0200
>
>
>> Actually, no. I'm saying that we have had at least three people who
>> have given good arguments, IMHO, as to why multiple levels of
>> hierarchy might be needed. On the other side, those arguments
>> are refuted by two people who think that no hierarchy is needed.
>> Neither side is going to convince the other, both sides have
>> good arguments.
>> 
>	=> I'm not sure who you mean by the "two" people, there is definitely 
>	more (at least the authors of HMIP are) but anyway
>	after reading the discussion it really seems to me like the only 
>	two (understandable IMHO) reasons are:
>
>	1.  In future there may be a need for multi-level hierarchy. That need 
>	is not explained really. To me this is not a good reason for including
>	any feature. Ithink it makes a lot of sense of scope the problem to
>	what we know without "guessing" what might happen in future
>	and how theuse of MIP can be changed dramatically. No one 
>	knows that this is true.
>
>	2. Multi-level hierarchy localises the signalling. Let's try to 
understand 
>	what this really means. A MAP domain is as large as the amount 
>	of traffic that a MAP can handle, regardless of the number of 
>	levels of hierarchy. The signalling will always be local to that
>	domain. So I'm not really clear on the significant advantage here. 
>	We're certainly not expecting any inter-continental mobility 
>	management using HMIPv6. So careful placement of the MAP 
>	using network engineering skills and common sense is 
>	sufficient. 
>
>> What I'm saying is that we have some arguments the feature is needed,
>> so let's put it in. From Karim's last email, it sounds like we can
>> probably accommodate his concerns about multiplying failure possibilities.
>> 
>	=> At a cost. The beneft MUST outweigh the cost. This is not 
>	the case here IMO.
>
>> If we don't put it in and deployment proves that we need it, 
>> 
>	=> This is exactly point one above. 
>
>	Hesham



From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 17:49: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 RAA16085
	for ; Tue, 24 Apr 2001 17:49:44 -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 OAA04218;
	Tue, 24 Apr 2001 14:46: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 OAA15940;
	Tue, 24 Apr 2001 14:46:03 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OLiWK9014698
	for ; Tue, 24 Apr 2001 14:44:33 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3OLiWBw014695
	for mobile-ip-dist; Tue, 24 Apr 2001 14:44: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OLiLK9014687
	for ; Tue, 24 Apr 2001 14:44:22 -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 OAA21202
	for ; Tue, 24 Apr 2001 14:44:21 -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 OAA01123
	for ; Tue, 24 Apr 2001 14:44:19 -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 f3OLiBO16677
	for ; Tue, 24 Apr 2001 23:44:11 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Tue Apr 24 23:44:10 2001 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Tue, 24 Apr 2001 23:44:10 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBDA1@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Cc: Basavaraj.Patil@nokia.com
Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L
	 ocalized Mobility Management Requirement s)
Date: Tue, 24 Apr 2001 23:44:08 +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: 

One more thing to consider. Is the need for multi-level
hierarchy specific to MIPv6 ? Because this is not 
the case in MIPv4. So why is this any different ?

Hesham

> -----Original Message-----
> From:	James Kempf [SMTP:James.Kempf@Sun.COM]
> Sent:	Wednesday, 25 April 2001 1:55
> To:	mobile-ip@sunroof.eng.sun.com
> Cc:	Basavaraj.Patil@nokia.com
> Subject:	RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L ocalized Mobility Management Requirement s)
> 
> Hi Erik,
> 
> >> Ulimately, the issue is one of deployment. The worst possible case
> >> is we cycle an LMM protocol without multiple levels of hierarchy
> >> to proposed and discover during deployment that we need it. 
> >
> >Jim,
> >
> >You are stating the design philosophy that leads to kitchen sink
> >protocols - put in as much as possible to make sure nothing we can
> >ever imagine has been left out.
> >
> >I much prefer the opposite philosophy - only include what we know for 
> >sure will be needed.
> >
> 
> 
> Actually, no. I'm saying that we have had at least three people who
> have given good arguments, IMHO, as to why multiple levels of
> hierarchy might be needed. On the other side, those arguments
> are refuted by two people who think that no hierarchy is needed.
> Neither side is going to convince the other, both sides have
> good arguments.
> 
> The kitchen sink results when somebody says "let's put in this neat
> feature," then somebody else says "let's put in this neat feature,"
> and the group iterates on this for several rounds with nobody 
> really coming up with good arguments for or against the feature except
> that it was X's idea.
> 
> What I'm saying is that we have some arguments the feature is needed,
> so let's put it in. From Karim's last email, it sounds like we can
> probably accommodate his concerns about multiplying failure possibilities.
> If we don't put it in and deployment proves that we need it, as I and
> at least two other people on the list think will likely be the case, we
> are stuck with going back through proposed standard. 
> 
> 		jak


From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 18:04:40 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16396
	for ; Tue, 24 Apr 2001 18:04:40 -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 PAA17870;
	Tue, 24 Apr 2001 15:04: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 PAA27181;
	Tue, 24 Apr 2001 15:03:44 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OM11K9014790
	for ; Tue, 24 Apr 2001 15:01:01 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3OM10NG014789
	for mobile-ip-dist; Tue, 24 Apr 2001 15:01: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OM0kK9014775
	for ; Tue, 24 Apr 2001 15:00: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 PAA19328
	for ; Tue, 24 Apr 2001 15:00:46 -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 RAA06384
	for ; Tue, 24 Apr 2001 17:10:22 -0600 (MDT)
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 f3OM0cO18531
	for ; Wed, 25 Apr 2001 00:00:38 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Wed Apr 25 00:00:38 2001 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Tue, 24 Apr 2001 23:55:58 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBDA4@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Cc: Basavaraj.Patil@nokia.com
Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L
	 ocalized Mobility Management Requirement s)
Date: Wed, 25 Apr 2001 00:00:36 +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, 

Fair enough. However, I don't really believe that stating 
an opinion is enough, the reasons should be discussed. 
But I guess you would say that this was already done. 

What gets me though is why these arguments are only 
raised in the context of MIPv6 ?

Anyway 5 or 6 people can hardly represent a WG so let's 
hear what people think. 

Hesham

> -----Original Message-----
> From:	James Kempf [SMTP:James.Kempf@Sun.COM]
> Sent:	Wednesday, 25 April 2001 7:47
> To:	mobile-ip@sunroof.eng.sun.com
> Cc:	Basavaraj.Patil@nokia.com
> Subject:	RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L ocalized Mobility Management Requirement s)
> 
> Hi Hesham,
> 
> Thanx for your response, but I think we've been through these
> points a number of times, we really don't need to rehash them again. Charlie, 
> Theo, myself, and one other person (whose name I've forgotten) have spoken up 
> for a requirement to support hierarchy. You and Karim have spoken up against it, 
> and Raj, expressing a preference for simplicity, has an inclination
> against it.
> 
> Anybody else out there in SMTP-land want to express a preference?
> 
> Phil, any ideas about how to proceed?
> 
> 		jak
> 
> 
> >From: "Hesham Soliman  (ERA)" 
> >To: "'mobile-ip@sunroof.eng.sun.com'" 
> >Cc: Basavaraj.Patil@nokia.com
> >Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L 
> ocalized Mobility Management Requirement s)
> >Date: Tue, 24 Apr 2001 23:34:56 +0200
> >
> >
> >> Actually, no. I'm saying that we have had at least three people who
> >> have given good arguments, IMHO, as to why multiple levels of
> >> hierarchy might be needed. On the other side, those arguments
> >> are refuted by two people who think that no hierarchy is needed.
> >> Neither side is going to convince the other, both sides have
> >> good arguments.
> >> 
> >	=> I'm not sure who you mean by the "two" people, there is definitely 
> >	more (at least the authors of HMIP are) but anyway
> >	after reading the discussion it really seems to me like the only 
> >	two (understandable IMHO) reasons are:
> >
> >	1.  In future there may be a need for multi-level hierarchy. That need 
> >	is not explained really. To me this is not a good reason for including
> >	any feature. Ithink it makes a lot of sense of scope the problem to
> >	what we know without "guessing" what might happen in future
> >	and how theuse of MIP can be changed dramatically. No one 
> >	knows that this is true.
> >
> >	2. Multi-level hierarchy localises the signalling. Let's try to 
> understand 
> >	what this really means. A MAP domain is as large as the amount 
> >	of traffic that a MAP can handle, regardless of the number of 
> >	levels of hierarchy. The signalling will always be local to that
> >	domain. So I'm not really clear on the significant advantage here. 
> >	We're certainly not expecting any inter-continental mobility 
> >	management using HMIPv6. So careful placement of the MAP 
> >	using network engineering skills and common sense is 
> >	sufficient. 
> >
> >> What I'm saying is that we have some arguments the feature is needed,
> >> so let's put it in. From Karim's last email, it sounds like we can
> >> probably accommodate his concerns about multiplying failure possibilities.
> >> 
> >	=> At a cost. The beneft MUST outweigh the cost. This is not 
> >	the case here IMO.
> >
> >> If we don't put it in and deployment proves that we need it, 
> >> 
> >	=> This is exactly point one above. 
> >
> >	Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 18:05:39 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 SAA16441
	for ; Tue, 24 Apr 2001 18:05: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 PAA11379;
	Tue, 24 Apr 2001 15:02:39 -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 PAA26705;
	Tue, 24 Apr 2001 15:02:16 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OLwfK9014772
	for ; Tue, 24 Apr 2001 14:58:41 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3OLwfDG014771
	for mobile-ip-dist; Tue, 24 Apr 2001 14:58: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OLwTK9014763
	for ; Tue, 24 Apr 2001 14:58:30 -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 OAA25421
	for ; Tue, 24 Apr 2001 14:58:30 -0700 (PDT)
Received: from c007.snv.cp.net (c007-h014.c007.snv.cp.net [209.228.33.221])
	by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA13006
	for ; Tue, 24 Apr 2001 14:58:28 -0700 (PDT)
Received: (cpmta 21384 invoked from network); 24 Apr 2001 14:52:13 -0700
Received: from unknown (HELO philneum) (64.193.0.129)
  by smtp.telocity.com (209.228.33.221) with SMTP; 24 Apr 2001 14:52:13 -0700
X-Sent: 24 Apr 2001 21:52:13 GMT
Message-ID: <005501c0cd08$b48ac680$6401a8c0@philneum>
From: "Phil Neumiller" 
To: 
References: <034BEFD03799D411A59F00508BDF7546013DBDA0@esealnt448.al.sw.ericsson.se>
Subject: Re: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L ocalized Mobility Management Requirement s)
Date: Tue, 24 Apr 2001 16:51:17 -0500
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: 

Charlie, Hesham,

With SeaMoby context transfer, the HA can be virtualized.  The HA could also
be replicated for multi-home agent-ing.  One of the beauties of the SeaMoby
context transfer is that the the "essence" of the MN or AR hosting the MN can
be transported seamlessly to where it makes the most sense at that current
time, i.e. the network can evolve by having the HA follow the mobile or
by going to the optimal location for service (i.e. load balancing, QoS, and
other factors can be part of the decision process).

Thanks,

Phil
----- Original Message -----
From: "Hesham Soliman (ERA)" 
To: 
Sent: Tuesday, April 24, 2001 4:41 PM
Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L ocalized Mobility Management Requirement s)


> Hello Charlie,
>
> > The point of hierarchy is to localize the signaling.  That's a good
> > feature.  It also has the advantage of reducing signaling across
> > administrative boundaries.
> >
> => I don't understand how multi-level hierarchy can reduce
> signalling across administrative domains. If by "administrative
> domains" you refer to the top Anchor's domain then signalling
> to the HA is required regardless of how many levels you have..
>
> > Both of these are valuable for scalability.
> >
> => IMHO a real scalability benefit from hierarchy would be
> if we can have less state in the "further" agents than
> he "closer" ones. This is not the case in single level
> or multi-level hierarchy so I'm not sure I see a significant
> scalability benefit.
>
> Regards,
> Hesham
>
>




From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 18:10:31 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16522
	for ; Tue, 24 Apr 2001 18:10:30 -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 PAA20037;
	Tue, 24 Apr 2001 15:06:33 -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 PAA20573;
	Tue, 24 Apr 2001 15:06:15 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OM3nK9014823
	for ; Tue, 24 Apr 2001 15:03:49 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3OM3mfm014818
	for mobile-ip-dist; Tue, 24 Apr 2001 15:03: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OM3ZK9014810
	for ; Tue, 24 Apr 2001 15:03:37 -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 PAA03531
	for ; Tue, 24 Apr 2001 15:03:35 -0700 (PDT)
Received: from c007.snv.cp.net (c007-h014.c007.snv.cp.net [209.228.33.221])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA21141
	for ; Tue, 24 Apr 2001 15:03:30 -0700 (PDT)
Received: (cpmta 26390 invoked from network); 24 Apr 2001 15:01:52 -0700
Received: from unknown (HELO philneum) (64.193.0.129)
  by smtp.telocity.com (209.228.33.221) with SMTP; 24 Apr 2001 15:01:52 -0700
X-Sent: 24 Apr 2001 22:01:52 GMT
Message-ID: <007401c0cd0a$0da29620$6401a8c0@philneum>
From: "Phil Neumiller" 
To: ,
        "James Kempf" 
Cc: 
References: <200104242146.OAA06325@heliopolis.eng.sun.com>
Subject: Re: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L  ocalized Mobility Management Requirement s)
Date: Tue, 24 Apr 2001 17:00:56 -0500
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: 

The LMM can be virtualized with SeaMoby CT, i.e. can follow the MN.
I recommend this option over hierarchical.  Its simpler and more elegant.

Thanks,

Phil
----- Original Message -----
From: "James Kempf" 
To: 
Cc: 
Sent: Tuesday, April 24, 2001 4:46 PM
Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L ocalized Mobility Management Requirement s)


> Hi Hesham,
>
> Thanx for your response, but I think we've been through these
> points a number of times, we really don't need to rehash them again. Charlie,
> Theo, myself, and one other person (whose name I've forgotten) have spoken up
> for a requirement to support hierarchy. You and Karim have spoken up against it,
> and Raj, expressing a preference for simplicity, has an inclination
> against it.
>
> Anybody else out there in SMTP-land want to express a preference?
>
> Phil, any ideas about how to proceed?
>
> jak
>
>
> >From: "Hesham Soliman  (ERA)" 
> >To: "'mobile-ip@sunroof.eng.sun.com'" 
> >Cc: Basavaraj.Patil@nokia.com
> >Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L
> ocalized Mobility Management Requirement s)
> >Date: Tue, 24 Apr 2001 23:34:56 +0200
> >
> >
> >> Actually, no. I'm saying that we have had at least three people who
> >> have given good arguments, IMHO, as to why multiple levels of
> >> hierarchy might be needed. On the other side, those arguments
> >> are refuted by two people who think that no hierarchy is needed.
> >> Neither side is going to convince the other, both sides have
> >> good arguments.
> >>
> > => I'm not sure who you mean by the "two" people, there is definitely
> > more (at least the authors of HMIP are) but anyway
> > after reading the discussion it really seems to me like the only
> > two (understandable IMHO) reasons are:
> >
> > 1.  In future there may be a need for multi-level hierarchy. That need
> > is not explained really. To me this is not a good reason for including
> > any feature. Ithink it makes a lot of sense of scope the problem to
> > what we know without "guessing" what might happen in future
> > and how theuse of MIP can be changed dramatically. No one
> > knows that this is true.
> >
> > 2. Multi-level hierarchy localises the signalling. Let's try to
> understand
> > what this really means. A MAP domain is as large as the amount
> > of traffic that a MAP can handle, regardless of the number of
> > levels of hierarchy. The signalling will always be local to that
> > domain. So I'm not really clear on the significant advantage here.
> > We're certainly not expecting any inter-continental mobility
> > management using HMIPv6. So careful placement of the MAP
> > using network engineering skills and common sense is
> > sufficient.
> >
> >> What I'm saying is that we have some arguments the feature is needed,
> >> so let's put it in. From Karim's last email, it sounds like we can
> >> probably accommodate his concerns about multiplying failure possibilities.
> >>
> > => At a cost. The beneft MUST outweigh the cost. This is not
> > the case here IMO.
> >
> >> If we don't put it in and deployment proves that we need it,
> >>
> > => This is exactly point one above.
> >
> > Hesham
>
>




From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 18:11: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 SAA16556
	for ; Tue, 24 Apr 2001 18:11:50 -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 PAA14179;
	Tue, 24 Apr 2001 15:08: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 PAA28254;
	Tue, 24 Apr 2001 15:07:50 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OM4qK9014841
	for ; Tue, 24 Apr 2001 15:04:52 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3OM4pTs014840
	for mobile-ip-dist; Tue, 24 Apr 2001 15: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OM4dK9014833
	for ; Tue, 24 Apr 2001 15:04:40 -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 PAA25853
	for ; Tue, 24 Apr 2001 15:04:39 -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 PAA21902
	for ; Tue, 24 Apr 2001 15:04:38 -0700 (PDT)
Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 24 Apr 2001 17:58:44 -0400
Message-ID: 
From: Phil Roberts 
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)
Date: Tue, 24 Apr 2001 17:58: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: 

How to proceed?  Good question.  It would be really good if some other folks
weighed in on the issue.  Does anyone who hasn't commented on this so far
care to add anything?  care at all?

Phil


> -----Original Message-----
> From: James Kempf [mailto:James.Kempf@Sun.COM]
> Sent: Tuesday, April 24, 2001 5:47 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
> L ocalized Mobility Management Requirement s)
> 
> 
> Hi Hesham,
> 
> Thanx for your response, but I think we've been through these
> points a number of times, we really don't need to rehash them 
> again. Charlie, 
> Theo, myself, and one other person (whose name I've 
> forgotten) have spoken up 
> for a requirement to support hierarchy. You and Karim have 
> spoken up against it, 
> and Raj, expressing a preference for simplicity, has an inclination
> against it.
> 
> Anybody else out there in SMTP-land want to express a preference?
> 
> Phil, any ideas about how to proceed?
> 
> 		jak
> 
> 
> >From: "Hesham Soliman  (ERA)" 
> >To: "'mobile-ip@sunroof.eng.sun.com'" 
> >Cc: Basavaraj.Patil@nokia.com
> >Subject: RE: Multiple Levels of LMM agents (was: RE: 
> [mobile-ip] Revised L 
> ocalized Mobility Management Requirement s)
> >Date: Tue, 24 Apr 2001 23:34:56 +0200
> >
> >
> >> Actually, no. I'm saying that we have had at least three people who
> >> have given good arguments, IMHO, as to why multiple levels of
> >> hierarchy might be needed. On the other side, those arguments
> >> are refuted by two people who think that no hierarchy is needed.
> >> Neither side is going to convince the other, both sides have
> >> good arguments.
> >> 
> >	=> I'm not sure who you mean by the "two" people, there 
> is definitely 
> >	more (at least the authors of HMIP are) but anyway
> >	after reading the discussion it really seems to me like 
> the only 
> >	two (understandable IMHO) reasons are:
> >
> >	1.  In future there may be a need for multi-level 
> hierarchy. That need 
> >	is not explained really. To me this is not a good 
> reason for including
> >	any feature. Ithink it makes a lot of sense of scope 
> the problem to
> >	what we know without "guessing" what might happen in future
> >	and how theuse of MIP can be changed dramatically. No one 
> >	knows that this is true.
> >
> >	2. Multi-level hierarchy localises the signalling. Let's try to 
> understand 
> >	what this really means. A MAP domain is as large as the amount 
> >	of traffic that a MAP can handle, regardless of the number of 
> >	levels of hierarchy. The signalling will always be local to that
> >	domain. So I'm not really clear on the significant 
> advantage here. 
> >	We're certainly not expecting any inter-continental mobility 
> >	management using HMIPv6. So careful placement of the MAP 
> >	using network engineering skills and common sense is 
> >	sufficient. 
> >
> >> What I'm saying is that we have some arguments the feature 
> is needed,
> >> so let's put it in. From Karim's last email, it sounds like we can
> >> probably accommodate his concerns about multiplying 
> failure possibilities.
> >> 
> >	=> At a cost. The beneft MUST outweigh the cost. This is not 
> >	the case here IMO.
> >
> >> If we don't put it in and deployment proves that we need it, 
> >> 
> >	=> This is exactly point one above. 
> >
> >	Hesham
> 


From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 18:12:31 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16580
	for ; Tue, 24 Apr 2001 18:12: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 PAA24107;
	Tue, 24 Apr 2001 15:11:50 -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 PAA27682;
	Tue, 24 Apr 2001 15:11:37 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OM99K9014871
	for ; Tue, 24 Apr 2001 15:09:10 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3OM98Zd014870
	for mobile-ip-dist; Tue, 24 Apr 2001 15:09: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OM8xK9014863
	for ; Tue, 24 Apr 2001 15:09:00 -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 PAA07179
	for ; Tue, 24 Apr 2001 15:08:59 -0700 (PDT)
Message-Id: <200104242208.PAA07179@heliopolis.eng.sun.com>
Date: Tue, 24 Apr 2001 15:08:59 -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
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: o/di6disa0/rgaXWnifS3g==
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 Phil,

An interesting idea.

So can you explain how this will reduce the length of the signalling leg between
the LMM agent and mobile node when the mobile node changes subnet? The 
primary argument for hierarchy is that you can have a lower level LMM
agent that is close to the mobile node with which the mobile node does
a short leg BU when changing CoA, but the global CoA remains the 
same. 

		jak

>X-Sent: 24 Apr 2001 21:52:13 GMT
>From: "Phil Neumiller" 
>To: 
>Subject: Re: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L 
ocalized Mobility Management Requirement s)
>Date: Tue, 24 Apr 2001 16:51:17 -0500
>X-Priority: 3
>X-MSMail-Priority: Normal
>X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
>
>Charlie, Hesham,
>
>With SeaMoby context transfer, the HA can be virtualized.  The HA could also
>be replicated for multi-home agent-ing.  One of the beauties of the SeaMoby
>context transfer is that the the "essence" of the MN or AR hosting the MN can
>be transported seamlessly to where it makes the most sense at that current
>time, i.e. the network can evolve by having the HA follow the mobile or
>by going to the optimal location for service (i.e. load balancing, QoS, and
>other factors can be part of the decision process).
>
>Thanks,
>
>Phil
>----- Original Message -----
>From: "Hesham Soliman (ERA)" 
>To: 
>Sent: Tuesday, April 24, 2001 4:41 PM
>Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L 
ocalized Mobility Management Requirement s)
>
>
>> Hello Charlie,
>>
>> > The point of hierarchy is to localize the signaling.  That's a good
>> > feature.  It also has the advantage of reducing signaling across
>> > administrative boundaries.
>> >
>> => I don't understand how multi-level hierarchy can reduce
>> signalling across administrative domains. If by "administrative
>> domains" you refer to the top Anchor's domain then signalling
>> to the HA is required regardless of how many levels you have..
>>
>> > Both of these are valuable for scalability.
>> >
>> => IMHO a real scalability benefit from hierarchy would be
>> if we can have less state in the "further" agents than
>> he "closer" ones. This is not the case in single level
>> or multi-level hierarchy so I'm not sure I see a significant
>> scalability benefit.
>>
>> Regards,
>> Hesham
>>
>>
>
>



From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 18:20:13 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 SAA16727
	for ; Tue, 24 Apr 2001 18:20: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 PAA17898;
	Tue, 24 Apr 2001 15:17:57 -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 PAA23358;
	Tue, 24 Apr 2001 15:17:47 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OMEqK9014906
	for ; Tue, 24 Apr 2001 15:14:52 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3OMEqse014905
	for mobile-ip-dist; Tue, 24 Apr 2001 15:14:52 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OMEcK9014898
	for ; Tue, 24 Apr 2001 15:14:41 -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 PAA22627
	for ; Tue, 24 Apr 2001 15:14:39 -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 PAA27119
	for ; Tue, 24 Apr 2001 15:14:39 -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 PAA20844;
	Tue, 24 Apr 2001 15:14:34 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3OMEVB11437;
	Tue, 24 Apr 2001 15:14:31 -0700
X-mProtect:  Tue, 24 Apr 2001 15:14:31 -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(WTS.12.69) smtpd3YSMuI; Tue, 24 Apr 2001 15:14:27 PDT
Message-ID: <3AE5FAC6.6E713BC3@iprg.nokia.com>
Date: Tue, 24 Apr 2001 15:14:30 -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: Basavaraj.Patil@nokia.com
Subject: Re: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L 
 ocalized Mobility Management Requirement s)
References: <034BEFD03799D411A59F00508BDF7546013DBD9F@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,

Not sure that you have read  either my previous postings and of course underlying
reasoning on this topic.

I will just reiterate what the constituency has spoken here and say that we (and
speaking also for myself, I) have elaborated on the topic as concretely as possible..

You may feel that you do not _understand_ the reasons (once more)...the rest of the
constituency _has_. To that people have either agreed or disagreed or expressed
reservations. You, _simply_ don't understand it... QED..

Design means to me catering for future needs. If you do not know future needs you
have to envisage strong possible (within reason) scenarios. Multi-level hierarchy is
one of them IMHO the arguments have been presented in past postings (please take a
look at the thread).

You insist to make specific LMMs to MAP...i.e. HMIP... we have been trying to talk
about LMM candidate schemes. The earth does not revolve around HMIP but LMMs....

The size of the domain is something that is not cast in stone. It is expressed as the
growth in network infrastructure that maps to an individual ISP. The world expects
that ISPs will grow larger in that sense by populating the routing fabring with more
and more routing elements...

in layman's terms MORE CARS --> MORE ROADS otherwise congestion and collapse is
around the corner...I hope you can see the natural analogy with networks.

I guess the above _signifies_ how the benefit outweighs the cost...what is the
benefit...?????

yes you "guessed" right....SCALABILITY...

I hope the above make things a little clearer now...


Theo

UCL/ Mobile Systems


"Hesham Soliman (ERA)" wrote:

>         => I'm not sure who you mean by the "two" people, there is definitely
>         more (at least the authors of HMIP are) but anyway
>         after reading the discussion it really seems to me like the only
>         two (understandable IMHO) reasons are:
>
>         1.  In future there may be a need for multi-level hierarchy. That need
>         is not explained really. To me this is not a good reason for including
>         any feature. Ithink it makes a lot of sense of scope the problem to
>         what we know without "guessing" what might happen in future
>         and how theuse of MIP can be changed dramatically. No one
>         knows that this is true.
>
>         2. Multi-level hierarchy localises the signalling. Let's try to understand
>         what this really means. A MAP domain is as large as the amount
>         of traffic that a MAP can handle, regardless of the number of
>         levels of hierarchy. The signalling will always be local to that
>         domain. So I'm not really clear on the significant advantage here.
>         We're certainly not expecting any inter-continental mobility
>         management using HMIPv6. So careful placement of the MAP
>         using network engineering skills and common sense is
>         sufficient.
>
> > What I'm saying is that we have some arguments the feature is needed,
> > so let's put it in. From Karim's last email, it sounds like we can
> > probably accommodate his concerns about multiplying failure possibilities.
> >
>         => At a cost. The beneft MUST outweigh the cost. This is not
>         the case here IMO.
>
> > If we don't put it in and deployment proves that we need it,
> >
>         => This is exactly point one above.
>
>         Hesham



From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 18:25: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 SAA16817
	for ; Tue, 24 Apr 2001 18:25:41 -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 PAA20252;
	Tue, 24 Apr 2001 15:23:55 -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 PAA00676;
	Tue, 24 Apr 2001 15:23:27 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OMLFK9014923
	for ; Tue, 24 Apr 2001 15:21:15 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3OMLEEt014922
	for mobile-ip-dist; Tue, 24 Apr 2001 15:21: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OML4K9014915
	for ; Tue, 24 Apr 2001 15:21:06 -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 PAA24179
	for ; Tue, 24 Apr 2001 15:21:00 -0700 (PDT)
Received: from c007.snv.cp.net (c007-h014.c007.snv.cp.net [209.228.33.221])
	by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA01381
	for ; Tue, 24 Apr 2001 15:20:59 -0700 (PDT)
Received: (cpmta 5711 invoked from network); 24 Apr 2001 15:20:58 -0700
Received: from unknown (HELO philneum) (64.193.0.129)
  by smtp.telocity.com (209.228.33.221) with SMTP; 24 Apr 2001 15:20:58 -0700
X-Sent: 24 Apr 2001 22:20:58 GMT
Message-ID: <008b01c0cd0c$b8d8ee20$6401a8c0@philneum>
From: "Phil Neumiller" 
To: 
References: <200104242208.PAA07179@heliopolis.eng.sun.com>
Subject: Re: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L ocalized Mobility Management Requirement s)
Date: Tue, 24 Apr 2001 17:20:02 -0500
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: 

Hi James,

My answer is below.
----- Original Message -----
From: "James Kempf" 
To: 
Sent: Tuesday, April 24, 2001 5:08 PM
Subject: Re: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L ocalized Mobility Management Requirement s)


> Hi Phil,
>
> An interesting idea.
>
> So can you explain how this will reduce the length of the signalling leg between
> the LMM agent and mobile node when the mobile node changes subnet?

Oh, yes.  We had talked about this on the CT list just today.  Lets say I am a
LMM pool hosting router.  We know that due to just the physics of proximity with
other LMM pool hosting routers that any given host will almost always hand off
exclusively with a certain set of "regular neighbors".  A security association (sort
of a security web) is formed apriori with the regular neighbors so that secure
tunnels are in place between all regular neighbors.  This makes the context
transfer very fast, i.e. no dependency on building a secure tunnel before transfering
it.  This allows the virtual LMM to simply walk through the pre-approved
web of routers that it is authorized for.  If make-before-break is desired that
can be added for seamlessness.






From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 18:35: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 SAA16913
	for ; Tue, 24 Apr 2001 18:35: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 PAA25626;
	Tue, 24 Apr 2001 15:34: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 PAA06270;
	Tue, 24 Apr 2001 15:34:03 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OMVFK9014948
	for ; Tue, 24 Apr 2001 15:31:15 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3OMVFCg014947
	for mobile-ip-dist; Tue, 24 Apr 2001 15:31: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OMV5K9014940
	for ; Tue, 24 Apr 2001 15:31: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 PAA26864
	for ; Tue, 24 Apr 2001 15:31:05 -0700 (PDT)
Received: from c007.snv.cp.net (c007-h011.c007.snv.cp.net [209.228.33.217])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id RAA21205
	for ; Tue, 24 Apr 2001 17:40:45 -0600 (MDT)
Received: (cpmta 15598 invoked from network); 24 Apr 2001 15:29:40 -0700
Received: from unknown (HELO philneum) (64.193.0.129)
  by smtp.telocity.com (209.228.33.217) with SMTP; 24 Apr 2001 15:29:40 -0700
X-Sent: 24 Apr 2001 22:29:40 GMT
Message-ID: <00a901c0cd0d$efba3240$6401a8c0@philneum>
From: "Phil Neumiller" 
To: 
References: <200104242208.PAA07179@heliopolis.eng.sun.com> <008b01c0cd0c$b8d8ee20$6401a8c0@philneum>
Subject: Re: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L ocalized Mobility Management Requirement s)
Date: Tue, 24 Apr 2001 17:28:44 -0500
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: 

Also, you can pre-flood neighbors with the "notion" of a MN "may"
becoming your way shortly, which can be used for optimization
purposes and QoS equations and handofff decisions.




From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 18:37: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 SAA16932
	for ; Tue, 24 Apr 2001 18:37:02 -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 PAA26354;
	Tue, 24 Apr 2001 15:36:35 -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 PAA28447;
	Tue, 24 Apr 2001 15:36:26 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OMYYK9014983
	for ; Tue, 24 Apr 2001 15:34:34 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3OMYY0D014982
	for mobile-ip-dist; Tue, 24 Apr 2001 15:34:34 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OMYKK9014975
	for ; Tue, 24 Apr 2001 15:34:22 -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 PAA04556;
	Tue, 24 Apr 2001 15:34: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 PAA07809;
	Tue, 24 Apr 2001 15:34:15 -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 PAA22595;
	Tue, 24 Apr 2001 15:34:06 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3OMY5b12285;
	Tue, 24 Apr 2001 15:34:05 -0700
X-mProtect:  Tue, 24 Apr 2001 15:34:05 -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(WTS.12.69) smtpdW50NTk; Tue, 24 Apr 2001 15:34:01 PDT
Message-ID: <3AE5FF5A.668B3554@iprg.nokia.com>
Date: Tue, 24 Apr 2001 15:34: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 ,
        "Basavaraj.Patil" 
Subject: Re: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L 
 ocalized Mobility Management Requirement s)
References: <200104242146.OAA06325@heliopolis.eng.sun.com> <007401c0cd0a$0da29620$6401a8c0@philneum>
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 Phil,

   II don't think I have heard something new here...

The reason:

    At the moment Seamoby CT is actually acting on last hop ARs (unless I am wrong please correct me) so what you are
suggesting is bring the LMM next to the MN...

I horrifically fear that... this will be the end of LMM schemes.... WHY???? But this is CORE MIPv6... !!!!

What you want is to have the LMM in an optimal position for _both_ :

    1) low signalling
     2) reduction in transiting between LMM agents (that is the core ones like GMA/MAP/fooGMA/fooMAP/ blah blah..)

otherwise one advantage will just kill the other and at the end you will be pseudo-LMMing the MN..which is what
else...core MIPv6...


With respect to the elaboration about the LMM pool hosting router IMHO what you have just mentioned is a way of
establishing the hierarchy , and in fact _a priori_  ....very good...

that is with a minimum of 2 LMMs...I think that to me constitutes a hierarchy which DOES grow larger depending on the
degree of visibility you want to keep forward for CT since remember you do not move just forward but backwards also as an
MN... effectively over the LMM spine..

I believe that Phil's elaboration in fact shows how mutli-depth LMM actually helps CT here... :)))

Need I say more...?


Theo


UCL/ Mobile Systems




Phil Neumiller wrote:

> The LMM can be virtualized with SeaMoby CT, i.e. can follow the MN.
> I recommend this option over hierarchical.  Its simpler and more elegant.
>
> Thanks,
>




>
> Phil
> ----- Original Message -----
> From: "James Kempf" 
> To: 
> Cc: 
> Sent: Tuesday, April 24, 2001 4:46 PM
> Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L ocalized Mobility Management Requirement s)
>
> > Hi Hesham,
> >
> > Thanx for your response, but I think we've been through these
> > points a number of times, we really don't need to rehash them again. Charlie,
> > Theo, myself, and one other person (whose name I've forgotten) have spoken up
> > for a requirement to support hierarchy. You and Karim have spoken up against it,
> > and Raj, expressing a preference for simplicity, has an inclination
> > against it.
> >
> > Anybody else out there in SMTP-land want to express a preference?
> >
> > Phil, any ideas about how to proceed?
> >
> > jak
> >
> >
> > >From: "Hesham Soliman  (ERA)" 
> > >To: "'mobile-ip@sunroof.eng.sun.com'" 
> > >Cc: Basavaraj.Patil@nokia.com
> > >Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L
> > ocalized Mobility Management Requirement s)
> > >Date: Tue, 24 Apr 2001 23:34:56 +0200
> > >
> > >
> > >> Actually, no. I'm saying that we have had at least three people who
> > >> have given good arguments, IMHO, as to why multiple levels of
> > >> hierarchy might be needed. On the other side, those arguments
> > >> are refuted by two people who think that no hierarchy is needed.
> > >> Neither side is going to convince the other, both sides have
> > >> good arguments.
> > >>
> > > => I'm not sure who you mean by the "two" people, there is definitely
> > > more (at least the authors of HMIP are) but anyway
> > > after reading the discussion it really seems to me like the only
> > > two (understandable IMHO) reasons are:
> > >
> > > 1.  In future there may be a need for multi-level hierarchy. That need
> > > is not explained really. To me this is not a good reason for including
> > > any feature. Ithink it makes a lot of sense of scope the problem to
> > > what we know without "guessing" what might happen in future
> > > and how theuse of MIP can be changed dramatically. No one
> > > knows that this is true.
> > >
> > > 2. Multi-level hierarchy localises the signalling. Let's try to
> > understand
> > > what this really means. A MAP domain is as large as the amount
> > > of traffic that a MAP can handle, regardless of the number of
> > > levels of hierarchy. The signalling will always be local to that
> > > domain. So I'm not really clear on the significant advantage here.
> > > We're certainly not expecting any inter-continental mobility
> > > management using HMIPv6. So careful placement of the MAP
> > > using network engineering skills and common sense is
> > > sufficient.
> > >
> > >> What I'm saying is that we have some arguments the feature is needed,
> > >> so let's put it in. From Karim's last email, it sounds like we can
> > >> probably accommodate his concerns about multiplying failure possibilities.
> > >>
> > > => At a cost. The beneft MUST outweigh the cost. This is not
> > > the case here IMO.
> > >
> > >> If we don't put it in and deployment proves that we need it,
> > >>
> > > => This is exactly point one above.
> > >
> > > Hesham
> >
> >



From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 18:46:16 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 SAA17046
	for ; Tue, 24 Apr 2001 18:46:15 -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 PAA29925;
	Tue, 24 Apr 2001 15:45: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 PAA00575;
	Tue, 24 Apr 2001 15:45:17 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OMhaK9015013
	for ; Tue, 24 Apr 2001 15:43:36 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3OMhaha015012
	for mobile-ip-dist; Tue, 24 Apr 2001 15:43: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OMhPK9015005
	for ; Tue, 24 Apr 2001 15:43:27 -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 PAA09290
	for ; Tue, 24 Apr 2001 15:43:25 -0700 (PDT)
Received: from c007.snv.cp.net (c007-h011.c007.snv.cp.net [209.228.33.217])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id RAA27521
	for ; Tue, 24 Apr 2001 17:53:05 -0600 (MDT)
Received: (cpmta 27875 invoked from network); 24 Apr 2001 15:43:24 -0700
Received: from unknown (HELO philneum) (64.193.0.129)
  by smtp.telocity.com (209.228.33.217) with SMTP; 24 Apr 2001 15:43:24 -0700
X-Sent: 24 Apr 2001 22:43:24 GMT
Message-ID: <00b501c0cd0f$daf70840$6401a8c0@philneum>
From: "Phil Neumiller" 
To: 
Cc: "James Kempf" ,
        "Basavaraj.Patil" 
References: <200104242146.OAA06325@heliopolis.eng.sun.com> <007401c0cd0a$0da29620$6401a8c0@philneum> <3AE5FF5A.668B3554@iprg.nokia.com>
Subject: Re: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L  ocalized Mobility Management Requirement s)
Date: Tue, 24 Apr 2001 17:42:28 -0500
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: 

Hi Theo,

----- Original Message -----
From: "Theo Pagtzis" 


> Hi Phil,
>
>    II don't think I have heard something new here...
>
> The reason:
>
>     At the moment Seamoby CT is actually acting on last hop ARs (unless I am wrong please correct me) so what you are
> suggesting is bring the LMM next to the MN...
>
> I horrifically fear that... this will be the end of LMM schemes.... WHY???? But this is CORE MIPv6... !!!!

Hmm.  The end-to-end principle of the global Internet clearly states that all intelligence
should be moved to the edge of the network.  The method I propose moves the routing
decision to the edge where it belong and also has proven to scale.

>
> What you want is to have the LMM in an optimal position for _both_ :
>
>     1) low signalling
>      2) reduction in transiting between LMM agents (that is the core ones like GMA/MAP/fooGMA/fooMAP/ blah blah..)

The optimal position for "localized mobility management" is the first router the MN
touches.  This is what I am proposing.  How much more local can you get?
How much lowere signalling can you get?

>
> With respect to the elaboration about the LMM pool hosting router IMHO what you have just mentioned is a way of
> establishing the hierarchy , and in fact _a priori_  ....very good...
>
No, I have proposed a web on the edge where routers know about their
handoff candidates or learn them as needed.

> that is with a minimum of 2 LMMs...I think that to me constitutes a hierarchy which DOES grow larger depending on the
> degree of visibility you want to keep forward for CT since remember you do not move just forward but backwards also as an
> MN... effectively over the LMM spine..
>
> I believe that Phil's elaboration in fact shows how mutli-depth LMM actually helps CT here... :)))
>
> Need I say more...?

I believe my elaboration is the antithesis of hierarchy, i.e. fully distributed which is the best
way for the global Internet IMHO.  I guess we differ here?

Thanks,

Phil




From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 18:49:41 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17110
	for ; Tue, 24 Apr 2001 18:49: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 PAA22446;
	Tue, 24 Apr 2001 15:48: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 PAA01867;
	Tue, 24 Apr 2001 15:48:02 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OMkLK9015025
	for ; Tue, 24 Apr 2001 15:46:21 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3OMkLwM015024
	for mobile-ip-dist; Tue, 24 Apr 2001 15:46: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OMkBK9015017
	for ; Tue, 24 Apr 2001 15:46:12 -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 PAA08629
	for ; Tue, 24 Apr 2001 15:46:11 -0700 (PDT)
Message-Id: <200104242246.PAA08629@heliopolis.eng.sun.com>
Date: Tue, 24 Apr 2001 15:46:11 -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
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: F/sgPWqyGJSNcTNHrzlqOg==
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 Phil,

>
>Oh, yes.  We had talked about this on the CT list just today.  Lets say I am a
>LMM pool hosting router.  We know that due to just the physics of proximity 
with
>other LMM pool hosting routers that any given host will almost always hand off
>exclusively with a certain set of "regular neighbors".  A security association 
(sort
>of a security web) is formed apriori with the regular neighbors so that secure
>tunnels are in place between all regular neighbors.  This makes the context
>transfer very fast, i.e. no dependency on building a secure tunnel before 
transfering
>it.  This allows the virtual LMM to simply walk through the pre-approved
>web of routers that it is authorized for.  If make-before-break is desired that
>can be added for seamlessness.

There is, of course, one problem here. The LMM agent doesn't necessarily have to 
be at the access router, in fact, many deployment situations would instead have 
it at the border router for purposes of reducing the frequency of globally
visible CoA changes. Otherwise, there is no benefit for the mobile node.

		jak



From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 18:57: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 SAA17213
	for ; Tue, 24 Apr 2001 18:57:11 -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 PAA04871;
	Tue, 24 Apr 2001 15:56:09 -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 PAA13141;
	Tue, 24 Apr 2001 15:55:53 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OMroK9015049
	for ; Tue, 24 Apr 2001 15:53:50 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3OMrnZp015048
	for mobile-ip-dist; Tue, 24 Apr 2001 15:53: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OMrdK9015041
	for ; Tue, 24 Apr 2001 15:53:41 -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 PAA09507
	for ; Tue, 24 Apr 2001 15:53:40 -0700 (PDT)
Received: from c007.snv.cp.net (c007-h011.c007.snv.cp.net [209.228.33.217])
	by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA26757
	for ; Tue, 24 Apr 2001 15:53:39 -0700 (PDT)
Received: (cpmta 5169 invoked from network); 24 Apr 2001 15:52:35 -0700
Received: from unknown (HELO philneum) (64.193.0.129)
  by smtp.telocity.com (209.228.33.217) with SMTP; 24 Apr 2001 15:52:35 -0700
X-Sent: 24 Apr 2001 22:52:35 GMT
Message-ID: <00cf01c0cd11$23a79fe0$6401a8c0@philneum>
From: "Phil Neumiller" 
To: 
References: <200104242246.PAA08629@heliopolis.eng.sun.com>
Subject: Re: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L ocalized Mobility Management Requirement s)
Date: Tue, 24 Apr 2001 17:51:39 -0500
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: 

Hi James,

Some comments below.
----- Original Message -----
From: "James Kempf" 
To: 

> There is, of course, one problem here. The LMM agent doesn't necessarily have to
> be at the access router, in fact, many deployment situations would instead have
> it at the border router for purposes of reducing the frequency of globally
> visible CoA changes. Otherwise, there is no benefit for the mobile node.

That seems odd to me James.  I guess I would not classify it as a "local"
method then?  Eitherway, there is no loss of generality here, exact same
technique can apply to border routers, why not?




From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 18:58:19 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17234
	for ; Tue, 24 Apr 2001 18:58: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 PAA29628;
	Tue, 24 Apr 2001 15:57:44 -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 PAA13839;
	Tue, 24 Apr 2001 15:57:31 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OMtBK9015059
	for ; Tue, 24 Apr 2001 15:55:12 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3OMtBH0015058
	for mobile-ip-dist; Tue, 24 Apr 2001 15:55:11 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OMt2K9015051
	for ; Tue, 24 Apr 2001 15:55: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 PAA08900
	for ; Tue, 24 Apr 2001 15:55:01 -0700 (PDT)
Message-Id: <200104242255.PAA08900@heliopolis.eng.sun.com>
Date: Tue, 24 Apr 2001 15:55:02 -0700 (PDT)
From: James Kempf 
Subject: [mobile-ip] Hierarchy and Low Latency Handoff
To: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: v01J3mABambookxc2FUJVA==
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 H&K,

The design for low latency MIPv6 handoff proposes using bicasting to smooth 
handover.  I know it has been taken out of the draft, but Hesham
in particular has been a major proponent of bicasting, and I belive
there are plans afoot to do a separate draft or otherwise record
in some fashion bicasting as a viable handoff smoothing technique.

Now, if bicasting is used, then the new AR or the mobile node (depending on 
whether mobile assisted or network assisted handoff is used) needs to signal 
back to the LMM agent in order to get a new packet stream to the new AR. If the 
signalling line between the new AR and the LMM agent gets stretched enough, 
though, the latency in signalling may be enough to cause  packet loss and an 
.... urption in the conversation :-).

Thus it seems to me that in order to fufill the requirement that
the hiearchical scheme work well with with low latency handoff, we
really must have a requirement for multiple levels of hierarchy, *if*
bicasting is to remain a viable alternative for smoothing low latency
handoff.

The other possibility is that we drop bicasting as a candidate for
handoff smoothing. 

		jak





From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 18:58:31 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17256
	for ; Tue, 24 Apr 2001 18:58:30 -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 PAA29820;
	Tue, 24 Apr 2001 15:58:00 -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 PAA13915;
	Tue, 24 Apr 2001 15:57:44 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OMtXK9015069
	for ; Tue, 24 Apr 2001 15:55:33 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3OMtWUV015068
	for mobile-ip-dist; Tue, 24 Apr 2001 15:55: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OMtKK9015061
	for ; Tue, 24 Apr 2001 15:55: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 PAA10013
	for ; Tue, 24 Apr 2001 15:55:20 -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 PAA19103
	for ; Tue, 24 Apr 2001 15:55:19 -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 f3OMtHN14011
	for ; Wed, 25 Apr 2001 00:55:18 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Wed Apr 25 00:55:19 2001 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Wed, 25 Apr 2001 00:55:17 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBDA5@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 L
	 ocalized Mobility Management Requirement s)
Date: Wed, 25 Apr 2001 00:55:16 +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 
> primary argument for hierarchy is that you can have a lower level LMM
> agent that is close to the mobile node with which the mobile node does
> a short leg BU when changing CoA, but the global CoA remains the 
> same. 
> 
	=> So the main gain here if I understand you correctly is that
	you get a "quicker" update of the routing tables. 
	In a wireless system where forwarding delays on the wire are 
	completely insgnificant compared to the delays over the air,,
	I don't see a significant value adding here. We can easily illustrate
	this with some well known numbers. 
	Unless you see other gains that I couldn't interpret..

	Hesham 


From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 19:15: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 TAA17425
	for ; Tue, 24 Apr 2001 19:15:33 -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 QAA12106;
	Tue, 24 Apr 2001 16:14:42 -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 QAA23589;
	Tue, 24 Apr 2001 16:14:33 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OND5K9015107
	for ; Tue, 24 Apr 2001 16:13:05 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3OND5XD015106
	for mobile-ip-dist; Tue, 24 Apr 2001 16:13:05 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3ONCuK9015099
	for ; Tue, 24 Apr 2001 16:12:57 -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 QAA09344
	for ; Tue, 24 Apr 2001 16:12:56 -0700 (PDT)
Message-Id: <200104242312.QAA09344@heliopolis.eng.sun.com>
Date: Tue, 24 Apr 2001 16:12: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
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: /Voa5zv8Gkqc2zHmYuNhBw==
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 Phil,


>> There is, of course, one problem here. The LMM agent doesn't necessarily have 
to
>> be at the access router, in fact, many deployment situations would instead 
have
>> it at the border router for purposes of reducing the frequency of globally
>> visible CoA changes. Otherwise, there is no benefit for the mobile node.
>
>That seems odd to me James.  I guess I would not classify it as a "local"
>method then?  Eitherway, there is no loss of generality here, exact same
>technique can apply to border routers, why not?
>
>

I think I understand what you are getting at. Let me summarize:

If the LMM is at the AR, when the mobile node moves, it quickly signals the CoA 
change to new AR/LMM, and the AR/LMM leisurely signals it back to the various 
CNs and HA. During the period in which the CNs and HA still know the mobile by
it's old CoA, the old LMM at the old AR is tunnelling to the new LMM.
So, in essence, the LMM becomes kind of like the IPv4 FA. Is that it?

I think this is not what most people in this thread would think of as
being LMM. The two currently proposed schemes use an agent back in
the network. And, you are right, it is not really localized at all.
I think that name was chosen so as not to prejudice the discussion
toward either of the two techniques.

		jak 



From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 19:17:15 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA17484
	for ; Tue, 24 Apr 2001 19:17: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 QAA13372;
	Tue, 24 Apr 2001 16:16: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 QAA23885;
	Tue, 24 Apr 2001 16:16:35 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3ONEaK9015122
	for ; Tue, 24 Apr 2001 16:14:36 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3ONEa39015121
	for mobile-ip-dist; Tue, 24 Apr 2001 16:14: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3ONELK9015114
	for ; Tue, 24 Apr 2001 16:14:23 -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 QAA19560;
	Tue, 24 Apr 2001 16:14:21 -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 QAA27969;
	Tue, 24 Apr 2001 16:14:21 -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 QAA25712;
	Tue, 24 Apr 2001 16:14:14 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3ONEB510963;
	Tue, 24 Apr 2001 16:14:11 -0700
X-mProtect:  Tue, 24 Apr 2001 16:14:11 -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(WTS.12.69) smtpdbeHFe7; Tue, 24 Apr 2001 16:14:05 PDT
Message-ID: <3AE608C0.2E36B7F9@iprg.nokia.com>
Date: Tue, 24 Apr 2001 16:14:08 -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 ,
        "Basavaraj.Patil" 
Subject: Re: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L 
 ocalized Mobility Management Requirement s)
References: <200104242146.OAA06325@heliopolis.eng.sun.com> <007401c0cd0a$0da29620$6401a8c0@philneum> <3AE5FF5A.668B3554@iprg.nokia.com> <00b501c0cd0f$daf70840$6401a8c0@philneum>
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 Phil,

    some more elaboration below..


> > Hi Phil,
> >
> >    II don't think I have heard something new here...
> >
> > The reason:
> >
> >     At the moment Seamoby CT is actually acting on last hop ARs (unless I am wrong please correct me) so what you are
> > suggesting is bring the LMM next to the MN...
> >
> > I horrifically fear that... this will be the end of LMM schemes.... WHY???? But this is CORE MIPv6... !!!!
>
> Hmm.  The end-to-end principle of the global Internet clearly states that all intelligence
> should be moved to the edge of the network.  The method I propose moves the routing
> decision to the edge where it belong and also has proven to scale.

which edge is that? the border one or the last hop to the MN?

You see if you move the intelligence too close to the MN, from a Mobile IP perspective, you are basic acting like core MIPv6
(in terms of localisation). So the default localisation if I am an MN in MIPv6 is last hop AR, which _indeed cannot get ANY
closer..(ok for adhoc is the MN itself but that's a killer in this WG)

What we want is to localise mobility with some slack in our movement (just to put it simply). This slack is enough for us to
reduce the signalling overheads to the involved entities (HA/CNs). But we don't want to make the slack too big since the
latency will catch up with us..so the original benefit just gets negated...



>
>
> The optimal position for "localized mobility management" is the first router the MN
> touches.  This is what I am proposing.  How much more local can you get?
> How much lowere signalling can you get?
>

well I think this is not Localised Mobility management at least in the light of the proposed schemes, that is...Reg^2 v6 and
HMIPv6

Why do you think you get lower signalling in such case in the first place anyway?????? Every time an MN touches a router it
will be as local as possible but this is not LMM ...this is core MIPv6 (unless I ready something wrong here..)



>
> >
> > With respect to the elaboration about the LMM pool hosting router IMHO what you have just mentioned is a way of
> > establishing the hierarchy , and in fact _a priori_  ....very good...
> >
> No, I have proposed a web on the edge where routers know about their
> handoff candidates or learn them as needed.

yes but that web has a depth of at least 2 (spans vertically not horizontally) isn't that a 2-level hierarchy?


>
>
> > that is with a minimum of 2 LMMs...I think that to me constitutes a hierarchy which DOES grow larger depending on the
> > degree of visibility you want to keep forward for CT since remember you do not move just forward but backwards also as an
> > MN... effectively over the LMM spine..
> >
>
> I believe my elaboration is the antithesis of hierarchy, i.e. fully distributed which is the best
> way for the global Internet IMHO.  I guess we differ here?

I must say that this is far from truth... by the moment you have the notion of "next possible candates" you have already
established a hierarchy structure of "previous -> next"

The above is the building block for any hierarchy in the world....since you interact between the two states and the state is
temporal to that depth of the structure..

of course you can turn your hierarchy drawing by 90 degrees and it does not look like a hierarchy anymore...


Theo


UCL/ Mobile Systems


>
>
> Thanks,
>
> Phil



From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 19:23:40 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA17554
	for ; Tue, 24 Apr 2001 19:23:39 -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 QAA17380;
	Tue, 24 Apr 2001 16:23: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 QAA21717;
	Tue, 24 Apr 2001 16:22:55 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3ONKmK9015160
	for ; Tue, 24 Apr 2001 16:20:49 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3ONKmWf015159
	for mobile-ip-dist; Tue, 24 Apr 2001 16:20: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3ONKbK9015152
	for ; Tue, 24 Apr 2001 16:20:39 -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 QAA21118
	for ; Tue, 24 Apr 2001 16:20:37 -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 QAA15895
	for ; Tue, 24 Apr 2001 16:20:35 -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 f3ONKYN17468
	for ; Wed, 25 Apr 2001 01:20:34 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Apr 25 01:20:34 2001 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Wed, 25 Apr 2001 01:15:54 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBDA7@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Hierarchy and Low Latency Handoff
Date: Wed, 25 Apr 2001 01:20:31 +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, 

Very good and timely point. There is a misunderstanding 
though and I'll try to clarify it below.



> The design for low latency MIPv6 handoff proposes using bicasting to smooth 
> handover.  I know it has been taken out of the draft, but Hesham
> in particular has been a major proponent of bicasting, and I belive
> there are plans afoot to do a separate draft or otherwise record
> in some fashion bicasting as a viable handoff smoothing technique.
> 
	=> Correct. Karim and I are writing a draft (or copying parts 
	of the old draft !) on this. We don't believe the Fast Handoff 
	solution for v6 is complete without it (unlike the v4 low latency draft). 
	In fact the design team has agreed that this will be highlighted 
	in the draft. I haven't had a chance to review the last revision yet though.

> Now, if bicasting is used, then the new AR or the mobile node (depending on 
> whether mobile assisted or network assisted handoff is used) needs to signal 
> back to the LMM agent in order to get a new packet stream to the new AR. If the 
> signalling line between the new AR and the LMM agent gets stretched enough, 
> though, the latency in signalling may be enough to cause  packet loss and an 
> .... urption in the conversation :-).
> 
	=> Ok so there are two cases, in the first case the MN sends a BU
	to the old AR (or LMM agent in case if HMIP is used). If bicasting 
	is used then this BU will request it. The forwarding delay on to
	the LMM agent is almost the same as the delay to the AR. 
	This is due to the fact that the bottle neck here is the 
	air interface. Delays on te wire are insignificant compared 
	to the massive delays over the air. 

	In the second case(no BU from the MN to the old AR) the MN
	can simply send the BU to the LMM agent (MAP in HMIPv6)
	some time after moving. The aim here would be to get 
	a more optimal route and reduce signalling outside 
	the domain. Bicasting can still be done from the 
	old AR. This is only one way of doing it and there 
	are more that we will discuss in the draft. 

	Personally I think there are still some open issues for the 
	second scenario (no BU from the MN) that need 
	to be explained in the draft but as I said I haven't had the 
	time to detail these issues. 

	Either way, the main point here is that delays on the 
	wire are completely insignificant compared to the 
	delays over the air. This is a _proven_fact.




> Thus it seems to me that in order to fufill the requirement that
> the hiearchical scheme work well with with low latency handoff, we
> really must have a requirement for multiple levels of hierarchy, *if*
> bicasting is to remain a viable alternative for smoothing low latency
> handoff.
> 
	=> I hope my explanation above clears this misunderstanding.

> The other possibility is that we drop bicasting as a candidate for
> handoff smoothing. 
> 
	=> Hmmm .. we did agree to keep it didn't we ? :)

	Could someone help me out and explain why this is 
	such a MIPv6 specific requirement ? 
	Please don't tell me that V6 is new and exciting :)
	That doesn't answer my question.

	Just trying to understand.

	Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 19:24:39 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 TAA17595
	for ; Tue, 24 Apr 2001 19:24: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 QAA15282;
	Tue, 24 Apr 2001 16:24: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 QAA17920;
	Tue, 24 Apr 2001 16:23:51 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3ONMUK9015174
	for ; Tue, 24 Apr 2001 16:22:31 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3ONMUbd015173
	for mobile-ip-dist; Tue, 24 Apr 2001 16:22: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3ONMFK9015162
	for ; Tue, 24 Apr 2001 16:22:16 -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 QAA25040
	for ; Tue, 24 Apr 2001 16:22:15 -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 QAA01393
	for ; Tue, 24 Apr 2001 16:22:15 -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 QAA26376
	for ; Tue, 24 Apr 2001 16:22:15 -0700 (PDT)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3ONMDr22911
	for ; Tue, 24 Apr 2001 16:22:13 -0700
X-mProtect:  Tue, 24 Apr 2001 16:22:13 -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(WTS.12.69) smtpdat4eoM; Tue, 24 Apr 2001 16:22:06 PDT
Message-ID: <3AE60A9F.5E27EB57@iprg.nokia.com>
Date: Tue, 24 Apr 2001 16:22:08 -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: <200104242312.QAA09344@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


I second what James has just said here...


Theo


UCL/ Mobile Systems

James Kempf wrote:

> Hi Phil,
>
> >> There is, of course, one problem here. The LMM agent doesn't necessarily have
> to
> >> be at the access router, in fact, many deployment situations would instead
> have
> >> it at the border router for purposes of reducing the frequency of globally
> >> visible CoA changes. Otherwise, there is no benefit for the mobile node.
> >
> >That seems odd to me James.  I guess I would not classify it as a "local"
> >method then?  Eitherway, there is no loss of generality here, exact same
> >technique can apply to border routers, why not?
> >
> >
>
> I think I understand what you are getting at. Let me summarize:
>
> If the LMM is at the AR, when the mobile node moves, it quickly signals the CoA
> change to new AR/LMM, and the AR/LMM leisurely signals it back to the various
> CNs and HA. During the period in which the CNs and HA still know the mobile by
> it's old CoA, the old LMM at the old AR is tunnelling to the new LMM.
> So, in essence, the LMM becomes kind of like the IPv4 FA. Is that it?
>
> I think this is not what most people in this thread would think of as
> being LMM. The two currently proposed schemes use an agent back in
> the network. And, you are right, it is not really localized at all.
> I think that name was chosen so as not to prejudice the discussion
> toward either of the two techniques.
>
>                 jak



From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 19:31:28 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA17707
	for ; Tue, 24 Apr 2001 19:31:27 -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 QAA21788;
	Tue, 24 Apr 2001 16:30: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 QAA24238;
	Tue, 24 Apr 2001 16:30:21 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3ONSdK9015245
	for ; Tue, 24 Apr 2001 16:28:40 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3ONSd6V015243
	for mobile-ip-dist; Tue, 24 Apr 2001 16:28: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3ONSRK9015233
	for ; Tue, 24 Apr 2001 16:28:29 -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 QAA23682
	for ; Tue, 24 Apr 2001 16:28:27 -0700 (PDT)
Received: from c007.snv.cp.net (c007-h015.c007.snv.cp.net [209.228.33.222])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id SAA17898
	for ; Tue, 24 Apr 2001 18:38:20 -0600 (MDT)
Received: (cpmta 20914 invoked from network); 24 Apr 2001 16:28:25 -0700
Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129)
  by smtp.telocity.com (209.228.33.222) with SMTP; 24 Apr 2001 16:28:25 -0700
X-Sent: 24 Apr 2001 23:28:25 GMT
Message-ID: <00f301c0cd16$24f53c40$6401a8c0@philneum>
From: "Phil Neumiller" 
To: 
References: <200104242312.QAA09344@heliopolis.eng.sun.com>
Subject: Re: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L ocalized Mobility Management Requirement s)
Date: Tue, 24 Apr 2001 18:27:29 -0500
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: 

> I think I understand what you are getting at. Let me summarize:
>
> If the LMM is at the AR, when the mobile node moves, it quickly signals the CoA
> change to new AR/LMM, and the AR/LMM leisurely signals it back to the various
> CNs and HA. During the period in which the CNs and HA still know the mobile by
> it's old CoA, the old LMM at the old AR is tunnelling to the new LMM.
> So, in essence, the LMM becomes kind of like the IPv4 FA. Is that it?

If the LMM "follows" the mobile i.e. is virtual, it can "move" (by transferring its
context (using SeaMoby CT) and by setting up temporary tunnels) to any
LMM hosting router in any possible architecture.  So it does not need to reside
in an AR or a BR.  In fact the same method can work the mixes of both network
types and it works irrespective of crossing administrative domains or
routing domains (subnets).  I guess I would argue that the LMM becomes
like an OBAST agent but I won't go down that rat hole.
>
> I think this is not what most people in this thread would think of as
> being LMM. The two currently proposed schemes use an agent back in
> the network. And, you are right, it is not really localized at all.
> I think that name was chosen so as not to prejudice the discussion
> toward either of the two techniques.

I guess I thought I was suggesting a "third" alternative.

Thanks,

Phil






From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 19:32: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 TAA17740
	for ; Tue, 24 Apr 2001 19:32: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 QAA17881;
	Tue, 24 Apr 2001 16:30: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 QAA19646;
	Tue, 24 Apr 2001 16:30:14 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3ONStK9015252
	for ; Tue, 24 Apr 2001 16:28:55 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3ONSsOF015251
	for mobile-ip-dist; Tue, 24 Apr 2001 16:28: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3ONSZK9015240
	for ; Tue, 24 Apr 2001 16:28:37 -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 QAA19213
	for ; Tue, 24 Apr 2001 16:28:35 -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 SAA17960
	for ; Tue, 24 Apr 2001 18:38:28 -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 QAA26785
	for ; Tue, 24 Apr 2001 16:28:33 -0700 (PDT)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3ONSUA31658
	for ; Tue, 24 Apr 2001 16:28:30 -0700
X-mProtect:  Tue, 24 Apr 2001 16:28:30 -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(WTS.12.69) smtpdOWINSZ; Tue, 24 Apr 2001 16:28:25 PDT
Message-ID: <3AE60C1C.C485CCAE@iprg.nokia.com>
Date: Tue, 24 Apr 2001 16:28:28 -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] Hierarchy and Low Latency Handoff
References: <034BEFD03799D411A59F00508BDF7546013DBDA7@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

>

Hi Hesham,

>
>
> > Thus it seems to me that in order to fufill the requirement that
> > the hiearchical scheme work well with with low latency handoff, we
> > really must have a requirement for multiple levels of hierarchy, *if*
> > bicasting is to remain a viable alternative for smoothing low latency
> > handoff.
> >
>         => I hope my explanation above clears this misunderstanding.
>
> > The other possibility is that we drop bicasting as a candidate for
> > handoff smoothing.
> >
>         => Hmmm .. we did agree to keep it didn't we ? :)
>
>         Could someone help me out and explain why this is
>         such a MIPv6 specific requirement ?

which one are you referring to?

>
>         Please don't tell me that V6 is new and exciting :)
>         That doesn't answer my question.
>
>         Just trying to understand.
>
>         Hesham

Theo

UCL/ Mobile Systems



From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 19:39:28 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA17792
	for ; Tue, 24 Apr 2001 19:39: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 QAA26071;
	Tue, 24 Apr 2001 16:38: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 QAA26297;
	Tue, 24 Apr 2001 16:38:39 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3ONaPK9015282
	for ; Tue, 24 Apr 2001 16:36:25 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3ONaOnf015281
	for mobile-ip-dist; Tue, 24 Apr 2001 16:36:24 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3ONaDK9015274
	for ; Tue, 24 Apr 2001 16:36: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 QAA25798
	for ; Tue, 24 Apr 2001 16:36:13 -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 SAA20947
	for ; Tue, 24 Apr 2001 18:46: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 f3ONa9O01980
	for ; Wed, 25 Apr 2001 01:36:09 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Wed Apr 25 01:36:08 2001 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Wed, 25 Apr 2001 01:31:29 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBDA9@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Cc: Basavaraj.Patil@nokia.com
Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L
	 ocalized Mobility Management Requirement s)
Date: Wed, 25 Apr 2001 01:36: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: 

Hello Theo,


> Not sure that you have read  either my previous postings and of course underlying
> reasoning on this topic.
> 
	=> Yes I have. I thought I included it in the discussion.


> The size of the domain is something that is not cast in stone. It is expressed as the
> growth in network infrastructure that maps to an individual ISP. The world expects
> that ISPs will grow larger in that sense by populating the routing fabring with more
> and more routing elements...
> 
	=> The size of a LMM domain (or MAP domain or GMA domain) is 
	restricted to how much traffic the top LMM agent can handle.
	This is orthogonal to how big an ISP is. There is no need 
	to assume that an ISP domain = LMM domain. Actually for a
	very large ISP this is probably not possible.

> yes you "guessed" right....SCALABILITY...
> 
	=> Could you explain scalability of what ?
	It's certainly not the scalability of the amount of state
	kept in the routers.

	Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 19:40: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 TAA17856
	for ; Tue, 24 Apr 2001 19:40: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 QAA20735;
	Tue, 24 Apr 2001 16:40:01 -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 QAA15419;
	Tue, 24 Apr 2001 16:39:52 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3ONc1K9015302
	for ; Tue, 24 Apr 2001 16:38:02 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3ONc1ik015301
	for mobile-ip-dist; Tue, 24 Apr 2001 16:38: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3ONbmK9015293
	for ; Tue, 24 Apr 2001 16:37:48 -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 QAA09888
	for ; Tue, 24 Apr 2001 16:37:48 -0700 (PDT)
Message-Id: <200104242337.QAA09888@heliopolis.eng.sun.com>
Date: Tue, 24 Apr 2001 16:37:48 -0700 (PDT)
From: James Kempf 
Subject: RE: [mobile-ip] Hierarchy and Low Latency Handoff
To: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 9tXqEJ5y+DOHf0v6DTsb6A==
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,

>	Either way, the main point here is that delays on the 
>	wire are completely insignificant compared to the 
>	delays over the air. This is a _proven_fact.
>

Not quite. I did a little experiment at IETF50 to see what signalling
delays would be for an intercontinental BU - about 160 ms RTT to Japan
and Europe. That is over half the RTT delay recommended by the ITU
before human perception notices a gap. I think transcontinental
times would be maybe half of this. 

If the network operator cannot deploy a hierarchy of LMM agents,
they may not be able to counter.

But I think you've missed my point. You maintain, as I understand it, that we 
shouldn't include hierarchy because there is no demonstrated need for it
at this time. We've been discussing this issue for some time, and I've
just come up with an interaction between low latency handoff and
hierarchy that could cause an interruption in real time traffic
in certain deployments. Arguable, but possible.

Do you honestly believe that this won't happen again? 

			jak
			
PS: On the issue of handoff smoothing, there is more that could be
said and I think there are other problems with bicasting in addition
to the ones identified in the low latency MIPv6 work. We have kept it
in the low latency IPv4 handover draft for now. This issue should
be discussed in a separate thread when the drafts are put up for
working group review, here is not the right place to talk about
it.




From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 19:51:49 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18018
	for ; Tue, 24 Apr 2001 19:51:49 -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 QAA26442;
	Tue, 24 Apr 2001 16:39:34 -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 QAA21605;
	Tue, 24 Apr 2001 16:39:28 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3ONblK9015292
	for ; Tue, 24 Apr 2001 16:37:47 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3ONbkCu015291
	for mobile-ip-dist; Tue, 24 Apr 2001 16:37: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3ONbbK9015284
	for ; Tue, 24 Apr 2001 16:37:38 -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 QAA26094
	for ; Tue, 24 Apr 2001 16:37:37 -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 QAA25385
	for ; Tue, 24 Apr 2001 16:37:35 -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 f3ONbYN22430
	for ; Wed, 25 Apr 2001 01:37:34 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Apr 25 01:37:34 2001 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Wed, 25 Apr 2001 01:37:34 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBDAA@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Hierarchy and Low Latency Handoff
Date: Wed, 25 Apr 2001 01:37:33 +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 Theo, 
> >         Could someone help me out and explain why this is
> >         such a MIPv6 specific requirement ?
> 
> which one are you referring to?
> 
	=> The multi-level hierarchy.

	Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 19:53: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 TAA18055
	for ; Tue, 24 Apr 2001 19:53: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 QAA24686;
	Tue, 24 Apr 2001 16:52: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 QAA18416;
	Tue, 24 Apr 2001 16:52:29 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3ONouK9015349
	for ; Tue, 24 Apr 2001 16:50:56 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3ONouWm015348
	for mobile-ip-dist; Tue, 24 Apr 2001 16:50: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3ONokK9015341
	for ; Tue, 24 Apr 2001 16:50: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 QAA28802
	for ; Tue, 24 Apr 2001 16:50:45 -0700 (PDT)
Received: from rndsv.sungmi.co.kr ([168.126.181.1])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA26290
	for ; Tue, 24 Apr 2001 19:00:36 -0600 (MDT)
Received: from eastelsystems.com (168.126.181.223 [168.126.181.223]) by rndsv.sungmi.co.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id JNGXQBWM; Wed, 25 Apr 2001 08:49:46 +0900
Message-ID: <3AE6113B.7040704@eastelsystems.com>
Date: Wed, 25 Apr 2001 08:50:19 +0900
From: Jang JaeIk 
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; 0.8.1) Gecko/20010323
X-Accept-Language: ko, en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Mobile IPv6 Home Agent product and best place?
References: <30F2DED23724D311902D0008C7EABAFB04630DAF@daeis06nok>
Content-Type: text/plain; charset=EUC-KR
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,

It is 3GPP.

marc.greis@nokia.com wrote:

> Hi,
> 
> Without trying to give a good answer to your question at this point, I'd
> like to remind you that there are different "flavors" of "3G" (3GPP, 3GPP2,
> different releases, etc.), so I'm sure you'll be more likely to get a
> helpful answer to your question if you are a bit more specific about which
> flavor of 3G you are referring to.
> 
> Marc
> 
>> -----Original Message-----
>> From: ext Jang JaeIk [mailto:jijang@eastelsystems.com]
>> Sent: 23 April, 2001 5:41 AM
>> To: mobile-ip@sunroof.eng.sun.com
>> Subject: [mobile-ip] Mobile IPv6 Home Agent product and best place?
>> 
>> 
>> Hi all
>> 
>> I questioned if there is any product(Home Agent) for 
>> supporting mobile IPv6.
>> And in 3G network, where is the best place for HA?
>> 
>> Thanks in advance.
>> 




From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 19:53: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 TAA18077
	for ; Tue, 24 Apr 2001 19:53: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 QAA25033;
	Tue, 24 Apr 2001 16:53: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 QAA18577;
	Tue, 24 Apr 2001 16:52:55 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3ONpVK9015359
	for ; Tue, 24 Apr 2001 16:51:32 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3ONpVbt015358
	for mobile-ip-dist; Tue, 24 Apr 2001 16:51: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3ONpIK9015351
	for ; Tue, 24 Apr 2001 16:51:19 -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 QAA10173
	for ; Tue, 24 Apr 2001 16:51:18 -0700 (PDT)
Message-Id: <200104242351.QAA10173@heliopolis.eng.sun.com>
Date: Tue, 24 Apr 2001 16:51:19 -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
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: BVCIZkXZhsWqKUhFcLXxOg==
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 Phil,


>If the LMM "follows" the mobile i.e. is virtual, it can "move" (by transferring 
its
>context (using SeaMoby CT) and by setting up temporary tunnels) to any
>LMM hosting router in any possible architecture.  So it does not need to reside
>in an AR or a BR.  In fact the same method can work the mixes of both network
>types and it works irrespective of crossing administrative domains or
>routing domains (subnets).  I guess I would argue that the LMM becomes
>like an OBAST agent but I won't go down that rat hole.

Can you explain how this would work irrespective of subnets? The 
LMM is acting as a router, if subnet routing is being used, then
it pretty much has to take into account the subnet structure, doesn't it? The CN
directs packets to the global CoA on the LMM instead of directly to the MN, the 
LMM tunnels or otherwise arranges for delivery of the packets to the MN.


>I guess I thought I was suggesting a "third" alternative.
>

Well, maybe so. The LMM as FA scheme I outlined would work, and maybe
you have something else in mind. It sure would be great if we could
get rid of having to tie down the LMM, but I'm having trouble seeing
how this could work.

		jak



From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 19:56:26 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18138
	for ; Tue, 24 Apr 2001 19:56:25 -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 QAA04992;
	Tue, 24 Apr 2001 16:55: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 QAA00573;
	Tue, 24 Apr 2001 16:55:43 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3ONs3K9015385
	for ; Tue, 24 Apr 2001 16:54:03 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3ONs3GC015384
	for mobile-ip-dist; Tue, 24 Apr 2001 16:54: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3ONrqK9015377
	for ; Tue, 24 Apr 2001 16:53:54 -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 QAA29978
	for ; Tue, 24 Apr 2001 16:53:52 -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 TAA27290
	for ; Tue, 24 Apr 2001 19:03:46 -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 f3ONrnN24593
	for ; Wed, 25 Apr 2001 01:53:49 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Apr 25 01:53:49 2001 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Wed, 25 Apr 2001 01:49:09 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBDAB@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Hierarchy and Low Latency Handoff
Date: Wed, 25 Apr 2001 01:53:48 +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, 

	>	Either way, the main point here is that delays on the 
	>	wire are completely insignificant compared to the 
	>	delays over the air. This is a _proven_fact.
	>

	Not quite. I did a little experiment at IETF50 to see what signalling
	delays would be for an intercontinental BU - about 160 ms RTT to Japan
	and Europe. That is over half the RTT delay recommended by the ITU
	before human perception notices a gap. I think transcontinental
	 would be maybe half of this. 

	If the network operator cannot deploy a hierarchy of LMM agents,
	they may not be able to counter.

	=> James, I'm sorry but you completely misuse the 
	proposal here. Do you expect a MN to be located 
	in Europe and send a BU t an LMM agent / MAP 
	in the US ? Of course not. 
	We're not building a global mobility management 
	solution, it's _local_. LMM.
	We're not suggesting  that MNs BUs traverse the globe 
	in underwater cables.


	But I think you've missed my point. You maintain, as I understand it, that we 
	shouldn't include hierarchy because there is no demonstrated need for it
	at this time. We've been discussing this issue for some time, and I've
	just come up with an interaction between low latency handoff and
	hierarchy that could cause an interruption in real time traffic
	in certain deployments. Arguable, but possible.

	=> I thought I just showed one way of doing this in my 
	response. The delays over the wire are _insignificant_.
	Unless of course you start sending BUs across continents. 
	We can very happily say that our proposal does not 
	support this scenario where a MN is located in one 
	continent and the MAP is located in another. 
	What's the point of building such a network ?

	You still haven't answered my question on why 
	this is a v6 specific requirement.

	Hesham



From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 20:49:09 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18828
	for ; Tue, 24 Apr 2001 20:49:08 -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 RAA00015;
	Tue, 24 Apr 2001 17:48: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 RAA12632;
	Tue, 24 Apr 2001 17:48:28 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3P0lCK9015460
	for ; Tue, 24 Apr 2001 17:47:13 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3P0lCW0015459
	for mobile-ip-dist; Tue, 24 Apr 2001 17:47: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3P0l2K9015452
	for ; Tue, 24 Apr 2001 17:47:03 -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 RAA12324
	for ; Tue, 24 Apr 2001 17:47:01 -0700 (PDT)
Received: from sirius.ctr.columbia.edu (sirius.ctr.columbia.edu [128.59.64.60])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA04417
	for ; Tue, 24 Apr 2001 17:47:00 -0700 (PDT)
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 UAA20931 for ; Tue, 24 Apr 2001 20:47:00 -0400 (EDT)
From: "Andrew T. Campbell" 
To: 
Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L  ocalized Mobility Management Requirement s)
Date: Tue, 24 Apr 2001 20:45:36 -0700
Message-ID: <004901c0cd3a$30c46b30$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)
In-Reply-To: 
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

I think we need the edge hierarchies (not necessarily trees like
Cellular IP/ HMIP which aren't robust) to hold the per-host
routing states to deliver IP micro-mobility (QOS, etc.) to mobile
hosts. Could be a mesh or tree. Could be deep.

Its the infrastructure to implement the IP control plane for mobile networks

---
Andrew
http://comet.columbia.edu/~campbell


> -----Original Message-----
> From: owner-mobile-ip@sunroof.eng.sun.com
> [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Phil Roberts
> Sent: Tuesday, April 24, 2001 2:59 PM
> 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)
>
>
> How to proceed?  Good question.  It would be really good if
> some other folks
> weighed in on the issue.  Does anyone who hasn't commented on
> this so far
> care to add anything?  care at all?
>
> Phil
>
>
> > -----Original Message-----
> > From: James Kempf [mailto:James.Kempf@Sun.COM]
> > Sent: Tuesday, April 24, 2001 5:47 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
> > L ocalized Mobility Management Requirement s)
> >
> >
> > Hi Hesham,
> >
> > Thanx for your response, but I think we've been through these
> > points a number of times, we really don't need to rehash them
> > again. Charlie,
> > Theo, myself, and one other person (whose name I've
> > forgotten) have spoken up
> > for a requirement to support hierarchy. You and Karim have
> > spoken up against it,
> > and Raj, expressing a preference for simplicity, has an inclination
> > against it.
> >
> > Anybody else out there in SMTP-land want to express a preference?
> >
> > Phil, any ideas about how to proceed?
> >
> > 		jak
> >
> >
> > >From: "Hesham Soliman  (ERA)" 
> > >To: "'mobile-ip@sunroof.eng.sun.com'"
> 
> > >Cc: Basavaraj.Patil@nokia.com
> > >Subject: RE: Multiple Levels of LMM agents (was: RE:
> > [mobile-ip] Revised L
> > ocalized Mobility Management Requirement s)
> > >Date: Tue, 24 Apr 2001 23:34:56 +0200
> > >
> > >
> > >> Actually, no. I'm saying that we have had at least three
> people who
> > >> have given good arguments, IMHO, as to why multiple levels of
> > >> hierarchy might be needed. On the other side, those arguments
> > >> are refuted by two people who think that no hierarchy is needed.
> > >> Neither side is going to convince the other, both sides have
> > >> good arguments.
> > >>
> > >	=> I'm not sure who you mean by the "two" people, there
> > is definitely
> > >	more (at least the authors of HMIP are) but anyway
> > >	after reading the discussion it really seems to me like
> > the only
> > >	two (understandable IMHO) reasons are:
> > >
> > >	1.  In future there may be a need for multi-level
> > hierarchy. That need
> > >	is not explained really. To me this is not a good
> > reason for including
> > >	any feature. Ithink it makes a lot of sense of scope
> > the problem to
> > >	what we know without "guessing" what might happen in future
> > >	and how theuse of MIP can be changed dramatically. No one
> > >	knows that this is true.
> > >
> > >	2. Multi-level hierarchy localises the signalling. Let's try to
> > understand
> > >	what this really means. A MAP domain is as large as the amount
> > >	of traffic that a MAP can handle, regardless of the number of
> > >	levels of hierarchy. The signalling will always be local to that
> > >	domain. So I'm not really clear on the significant
> > advantage here.
> > >	We're certainly not expecting any inter-continental mobility
> > >	management using HMIPv6. So careful placement of the MAP
> > >	using network engineering skills and common sense is
> > >	sufficient.
> > >
> > >> What I'm saying is that we have some arguments the feature
> > is needed,
> > >> so let's put it in. From Karim's last email, it sounds
> like we can
> > >> probably accommodate his concerns about multiplying
> > failure possibilities.
> > >>
> > >	=> At a cost. The beneft MUST outweigh the cost. This is not
> > >	the case here IMO.
> > >
> > >> If we don't put it in and deployment proves that we need it,
> > >>
> > >	=> This is exactly point one above.
> > >
> > >	Hesham
> >
>
>



From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 20:51:55 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18933
	for ; Tue, 24 Apr 2001 20:51:55 -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 RAA01516;
	Tue, 24 Apr 2001 17:51:29 -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 RAA13288;
	Tue, 24 Apr 2001 17:51:24 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3P0oLK9015483
	for ; Tue, 24 Apr 2001 17:50:22 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3P0oKAt015482
	for mobile-ip-dist; Tue, 24 Apr 2001 17:50: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3P0oAK9015475
	for ; Tue, 24 Apr 2001 17:50:12 -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 RAA10520
	for ; Tue, 24 Apr 2001 17:50:10 -0700 (PDT)
Received: from c007.snv.cp.net (c007-h008.c007.snv.cp.net [209.228.33.214])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id RAA09538
	for ; Tue, 24 Apr 2001 17:50:09 -0700 (PDT)
Received: (cpmta 20573 invoked from network); 24 Apr 2001 17:50:07 -0700
Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129)
  by smtp.telocity.com (209.228.33.214) with SMTP; 24 Apr 2001 17:50:07 -0700
X-Sent: 25 Apr 2001 00:50:07 GMT
Message-ID: <011b01c0cd21$8f65c440$6401a8c0@philneum>
From: "Phil Neumiller" 
To: 
References: <200104242351.QAA10173@heliopolis.eng.sun.com>
Subject: Re: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L ocalized Mobility Management Requirement s)
Date: Tue, 24 Apr 2001 19:49:12 -0500
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: 

Hi James,

I just got back from taking the dog for a walk (and me!).  I will
take a stab at further explaining this James (last one for tonight).

----- Original Message -----
From: "James Kempf" 
To: 
Sent: Tuesday, April 24, 2001 6:51 PM
Subject: Re: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L ocalized Mobility Management Requirement s)


>
> Can you explain how this would work irrespective of subnets?

I think I made this argument once in the MM design team about 6 months
ago but I don't feel like digging through all the archives, so let me take
another shot at it.

The handoff destination LMM (if hosted in a router) is routable from the
source LMM even if it is in a different subnet right?  So as far as CT (and
setting up a temporary tunnel) why do I care about crossing a subnet
boundary?  I already stated that the neighboring LMM hosts will "know"
about each other so their security associations are ideally pre-configured
thus contributing no additive latency (also the assumption is they have
routes to each other - something I have called "sidehaul" in a prior life).
Sidehaul does add overhead, but only while the "backhaul" pipe is
re-pointing itself at the destination LMM.

> The
> LMM is acting as a router, if subnet routing is being used, then
> it pretty much has to take into account the subnet structure, doesn't it?

No.  This is the beauty of peer-to-peer design.  All you need to know is the
IP address of the source and destination.  Router hierarchy really does not
matter at all.





From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 20:57: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 UAA19060
	for ; Tue, 24 Apr 2001 20:57:16 -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 RAA13790;
	Tue, 24 Apr 2001 17:56: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 RAA11417;
	Tue, 24 Apr 2001 17:56:36 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3P0t8K9015506
	for ; Tue, 24 Apr 2001 17:55:09 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3P0t8mE015505
	for mobile-ip-dist; Tue, 24 Apr 2001 17:55: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3P0sxK9015498
	for ; Tue, 24 Apr 2001 17:55:00 -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 RAA11128
	for ; Tue, 24 Apr 2001 17:54:58 -0700 (PDT)
Received: from c007.snv.cp.net (c007-h011.c007.snv.cp.net [209.228.33.217])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id RAA11157
	for ; Tue, 24 Apr 2001 17:54:58 -0700 (PDT)
Received: (cpmta 29765 invoked from network); 24 Apr 2001 17:54:57 -0700
Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129)
  by smtp.telocity.com (209.228.33.217) with SMTP; 24 Apr 2001 17:54:57 -0700
X-Sent: 25 Apr 2001 00:54:57 GMT
Message-ID: <012301c0cd22$3c38a020$6401a8c0@philneum>
From: "Phil Neumiller" 
To: 
References: <004901c0cd3a$30c46b30$ca413b80@SWEETPEA>
Subject: Re: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L  ocalized Mobility Management Requirement s)
Date: Tue, 24 Apr 2001 19:54:02 -0500
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: 

I guess I would argue for a completely virtualized topology that
allows for trees or meshes depending on traffic, network design,
QoS, etc.  If we simply make every router in the global Internet
capable of hosting an LMM and we create "contract nets" between
them, this would allow for "emergence" of  globally optimal
behavior from simple localized exchanges of contracts (much as
a cellular automata based design would work).

Thanks,

Phil Neumiller


----- Original Message -----
From: "Andrew T. Campbell" 
To: 
Sent: Tuesday, April 24, 2001 10:45 PM
Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L ocalized Mobility Management Requirement s)


> I think we need the edge hierarchies (not necessarily trees like
> Cellular IP/ HMIP which aren't robust) to hold the per-host
> routing states to deliver IP micro-mobility (QOS, etc.) to mobile
> hosts. Could be a mesh or tree. Could be deep.
>
> Its the infrastructure to implement the IP control plane for mobile networks
>
> ---
> Andrew
> http://comet.columbia.edu/~campbell
>
>




From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 21:14:48 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA19369
	for ; Tue, 24 Apr 2001 21:14: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 SAA12664;
	Tue, 24 Apr 2001 18:14: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 SAA14711;
	Tue, 24 Apr 2001 18:14:04 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3P1CUK9015544
	for ; Tue, 24 Apr 2001 18:12:30 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3P1CTEJ015543
	for mobile-ip-dist; Tue, 24 Apr 2001 18:12: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3P1CGK9015536
	for ; Tue, 24 Apr 2001 18:12: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 SAA09291
	for ; Tue, 24 Apr 2001 18:12:16 -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 SAA13790
	for ; Tue, 24 Apr 2001 18:12:15 -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 SAA04549
	for ; Tue, 24 Apr 2001 18:12:15 -0700 (PDT)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3P1CCv01940
	for ; Tue, 24 Apr 2001 18:12:12 -0700
X-mProtect:  Tue, 24 Apr 2001 18:12:12 -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(WTS.12.69) smtpd3GYSap; Tue, 24 Apr 2001 18:12:08 PDT
Message-ID: <3AE6246A.D57EC757@iprg.nokia.com>
Date: Tue, 24 Apr 2001 18:12:10 -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: <004901c0cd3a$30c46b30$ca413b80@SWEETPEA> <012301c0cd22$3c38a020$6401a8c0@philneum>
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

hang on a sec...

I cannot imagine that we can place such requirement about making eahc AR an LMM candidate. Some ARs may offer LMM_A while
others will offer LMM_B...we are making requirement here !!! We are not ratifying an IEEE  XYZ.LMMx scheme here for
global deployment !!!

I think this is heading towards a cliff...

While we use CT as an example, I would suggest that we do not deviate/bias too much on that solution space...and besides
this is a CT discussion....if it goes the heading I see it going...

Theo

UCL/ Mobile Systems



Phil Neumiller wrote:

> I guess I would argue for a completely virtualized topology that
> allows for trees or meshes depending on traffic, network design,
> QoS, etc.  If we simply make every router in the global Internet
> capable of hosting an LMM and we create "contract nets" between
> them, this would allow for "emergence" of  globally optimal
> behavior from simple localized exchanges of contracts (much as
> a cellular automata based design would work).
>
> Thanks,
>
> Phil Neumiller
>
> ----- Original Message -----
> From: "Andrew T. Campbell" 
> To: 
> Sent: Tuesday, April 24, 2001 10:45 PM
> Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L ocalized Mobility Management Requirement s)
>
> > I think we need the edge hierarchies (not necessarily trees like
> > Cellular IP/ HMIP which aren't robust) to hold the per-host
> > routing states to deliver IP micro-mobility (QOS, etc.) to mobile
> > hosts. Could be a mesh or tree. Could be deep.
> >
> > Its the infrastructure to implement the IP control plane for mobile networks
> >
> > ---
> > Andrew
> > http://comet.columbia.edu/~campbell
> >
> >



From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 24 21:27:06 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA19472
	for ; Tue, 24 Apr 2001 21:27: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 SAA17494;
	Tue, 24 Apr 2001 18:26: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 SAA19008;
	Tue, 24 Apr 2001 18:26:10 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3P1P0K9015575
	for ; Tue, 24 Apr 2001 18:25:00 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3P1P0gg015574
	for mobile-ip-dist; Tue, 24 Apr 2001 18:25: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3P1OlK9015567
	for ; Tue, 24 Apr 2001 18:24:49 -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 SAA16103
	for ; Tue, 24 Apr 2001 18:24:47 -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 SAA21596
	for ; Tue, 24 Apr 2001 18:24:46 -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 SAA05208
	for ; Tue, 24 Apr 2001 18:24:46 -0700 (PDT)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3P1OhR11869
	for ; Tue, 24 Apr 2001 18:24:43 -0700
X-mProtect:  Tue, 24 Apr 2001 18:24:43 -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(WTS.12.69) smtpdmVMsU9; Tue, 24 Apr 2001 18:24:38 PDT
Message-ID: <3AE62759.C8541FD0@iprg.nokia.com>
Date: Tue, 24 Apr 2001 18:24:41 -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: <200104242351.QAA10173@heliopolis.eng.sun.com> <011b01c0cd21$8f65c440$6401a8c0@philneum>
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


> > Can you explain how this would work irrespective of subnets?

I think I forgot to state a basic assumption under LMMs here....

Not all ARs in a domain are assumed to be LMM-enabled.. this is fundamental to the LMM's operation...which reminds me...

Another requirement :


"An LMM scheme MUST be supported at the very minimum by a sparse (proper subset) routing element population within a
single administrative domain."

I think this is also quite important and has not been adressed specifically, cheers Phil.

So the LMM agents need to know how to reach their immediate neighbours..

Theo

UCL/ Mobile Systems


>
>
> I think I made this argument once in the MM design team about 6 months
> ago but I don't feel like digging through all the archives, so let me take
> another shot at it.
>
> The handoff destination LMM (if hosted in a router) is routable from the
> source LMM even if it is in a different subnet right?  So as far as CT (and
> setting up a temporary tunnel) why do I care about crossing a subnet
> boundary?  I already stated that the neighboring LMM hosts will "know"
> about each other so their security associations are ideally pre-configured
> thus contributing no additive latency (also the assumption is they have
> routes to each other - something I have called "sidehaul" in a prior life).
> Sidehaul does add overhead, but only while the "backhaul" pipe is
> re-pointing itself at the destination LMM.
>
> > The
> > LMM is acting as a router, if subnet routing is being used, then
> > it pretty much has to take into account the subnet structure, doesn't it?
>
> No.  This is the beauty of peer-to-peer design.  All you need to know is the
> IP address of the source and destination.  Router hierarchy really does not
> matter at all.



From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 25 00:54:19 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA24236
	for ; Wed, 25 Apr 2001 00:54: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 VAA03142;
	Tue, 24 Apr 2001 21:53:11 -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 VAA05546;
	Tue, 24 Apr 2001 21:53:03 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3P4pjK9015874
	for ; Tue, 24 Apr 2001 21:51:45 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3P4pj86015873
	for mobile-ip-dist; Tue, 24 Apr 2001 21:51: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3P4pYK9015866
	for ; Tue, 24 Apr 2001 21:51:36 -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 VAA05391
	for ; Tue, 24 Apr 2001 21:51:34 -0700 (PDT)
Received: from web10106.mail.yahoo.com (web10106.mail.yahoo.com [216.136.130.56])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id VAA23987
	for ; Tue, 24 Apr 2001 21:51:34 -0700 (PDT)
Message-ID: <20010425045133.98721.qmail@web10106.mail.yahoo.com>
Received: from [208.194.216.245] by web10106.mail.yahoo.com; Tue, 24 Apr 2001 21:51:33 PDT
Date: Tue, 24 Apr 2001 21:51:33 -0700 (PDT)
From: Yogesh 
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: James.Kempf@Sun.COM, charliep@iprg.nokia.com
In-Reply-To: <200104242146.OAA06325@heliopolis.eng.sun.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1015613911-988174293=:93743"
Sender: owner-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-1015613911-988174293=:93743
Content-Type: text/plain; charset=us-ascii


 Dear James, Charlie, and all,
I would like to put forth my arguments on hierarchies from a slightly different perspective. IP is a very flexible architecture and relays on several _supporting_ mechanisms to facilitate what it does facilitate. In my opinion, its unwise to push all such hierarchy mechanisms into the "native IP" protocol and make it complicated. In fact several other protocols would have greatly benefited had there been a possibility of hierarchy in IP itself (by hierarchy I mean the mechanism that supports hierarchy, not the static address hierarchy).

Take for example routing. If there was a hierarchy maintenance mechanism inbuilt in IP, then many of the routing protocols could have been simpler. However, instead of adding hierarchy, the protocol designers came up with the concept of CIDR, to gain the benefits of hierarchy, _without_ "corrupting" the native IP stack. This of course makes routing a bit more complicated (although not too much), but it leaves IP to be a very generic protocol without enforcing any policy. Levels of hierarchy and hierarchy itself is a matter of policy and should be left out of IP.

The difficulty with hierarchy is that it requires states, and when you have states, you require reliability. IP being a datagram service cannot provide this. If the datagram nature of IP is to remain intact (which I think it should), then building a hierarchy in the native IP protocol is impossible ( if you are re-transmitting IP packets at the network layer then its no longer the original datagram model of IP. Its rather a reliable service inside the IP header. A wolf in the sheep's clothing)

In my opinion, the Mobile-IPv6 should only aim at coming up with a mobility management mask (similar to subnet mask in CIDR), and should rely on _supporting_ mechanisms to provide hierarchy. This can allow numerous levels of hierarchy, _without_ "corrupting" the IP stack. This also has the added benefit that a router can safely ignore all such mobility masks if it does not want to support this feature. I can provide more details if needed.

A little digression  from the original topic and coming back to the re-transmission mechanisms, I think Mobile-IPv6 should also get rid of all re-transmission mechanisms. In the present Mobile-IPv6 draft, a mobile node keeps sending binding update to the home agent unless it receives a response from the home agent. This is less than ideal and should be changed. A router that drops a binding update should send an explicit ICMP message saying so (this means that the binding update can no longer be the destination option, but an ICMP message). A mobile node should send binding update only once, and after it has detected movement. All such error report ICMP messages should be reported to the upper layer protocol, which could decide the best strategy (the argument that this will break the existing applications is bogus since IPv6 itself will break all existing applications. If one can move to IPv6 from IPv4, then once can also catch these ICMP messages.) The benefit is that an uppe!
!
!
!
r layer protocol is probably a better judge of what has to be done next (possibly though human interaction) as opposed to a dumb piece of software that will keep retransmitting for ever.

I read these e-mails in my free time, more as a hobbyist, and I will not be able to respond to your comments during my working hours (8:00-5:00 central time). Hope that's fine.

Thank you for your time.
Best Regards
Yogesh

  James Kempf  wrote: 
Hi Hesham,

Thanx for your response, but I think we've been through these
points a number of times, we really don't need to rehash them again. Charlie, 
Theo, myself, and one other person (whose name I've forgotten) have spoken up 
for a requirement to support hierarchy. You and Karim have spoken up against it, 
and Raj, expressing a preference for simplicity, has an inclination
against it.

Anybody else out there in SMTP-land want to express a preference?

Phil, any ideas about how to proceed?

jak


>From: "Hesham Soliman (ERA)" 
>To: "'mobile-ip@sunroof.eng.sun.com'" 
>Cc: Basavaraj.Patil@nokia.com
>Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L 
ocalized Mobility Management Requirement s)
>Date: Tue, 24 Apr 2001 23:34:56 +0200
>
>
>> Actually, no. I'm saying that we have had at least three people who
>> have given good arguments, IMHO, as to why multiple levels of
>> hierarchy might be needed. On the other side, those arguments
>> are refuted by two people who think that no hierarchy is needed.
>> Neither side is going to convince the other, both sides have
>> good arguments.
>> 
> => I'm not sure who you mean by the "two" people, there is definitely 
> more (at least the authors of HMIP are) but anyway
> after reading the discussion it really seems to me like the only 
> two (understandable IMHO) reasons are:
>
> 1. In future there may be a need for multi-level hierarchy. That need 
> is not explained really. To me this is not a good reason for including
> any feature. Ithink it makes a lot of sense of scope the problem to
> what we know without "guessing" what might happen in future
> and how theuse of MIP can be changed dramatically. No one 
> knows that this is true.
>
> 2. Multi-level hierarchy localises the signalling. Let's try to 
understand 
> what this really means. A MAP domain is as large as the amount 
> of traffic that a MAP can handle, regardless of the number of 
> levels of hierarchy. The signalling will always be local to that
> domain. So I'm not really clear on the significant advantage here. 
> We're certainly not expecting any inter-continental mobility 
> management using HMIPv6. So careful placement of the MAP 
> using network engineering skills and common sense is 
> sufficient. 
>
>> What I'm saying is that we have some arguments the feature is needed,
>> so let's put it in. From Karim's last email, it sounds like we can
>> probably accommodate his concerns about multiplying failure possibilities.
>> 
> => At a cost. The beneft MUST outweigh the cost. This is not 
> the case here IMO.
>
>> If we don't put it in and deployment proves that we need it, 
>> 
> => This is exactly point one above. 
>
> Hesham


Swami Prem Yogesh
Research Engineer
Office:                          Home:
Nokia Research Center            826W, Royal Lane
6000 Connection Dr.              #392
Irving, Texas-75039              Irving, Texas-75039 
Tel: 972-374-0669                Tel: 972-831-9589


---------------------------------
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
--0-1015613911-988174293=:93743
Content-Type: text/html; charset=us-ascii


 Dear James, Charlie, and all,

I would like to put forth my arguments on hierarchies from a slightly different perspective. IP is a very flexible architecture and relays on several _supporting_ mechanisms to facilitate what it does facilitate. In my opinion, its unwise to push all such hierarchy mechanisms into the "native IP" protocol and make it complicated. In fact several other protocols would have greatly benefited had there been a possibility of hierarchy in IP itself (by hierarchy I mean the mechanism that supports hierarchy, not the static address hierarchy).


Take for example routing. If there was a hierarchy maintenance mechanism inbuilt in IP, then many of the routing protocols could have been simpler. However, instead of adding hierarchy, the protocol designers came up with the concept of CIDR, to gain the benefits of hierarchy, _without_ "corrupting" the native IP stack. This of course makes routing a bit more complicated (although not too much), but it leaves IP to be a very generic protocol without enforcing any policy. Levels of hierarchy and hierarchy itself is a matter of policy and should be left out of IP.


The difficulty with hierarchy is that it requires states, and when you have states, you require reliability. IP being a datagram service cannot provide this. If the datagram nature of IP is to remain intact (which I think it should), then building a hierarchy in the native IP protocol is impossible ( if you are re-transmitting IP packets at the network layer then its no longer the original datagram model of IP. Its rather a reliable service inside the IP header. A wolf in the sheep's clothing)


In my opinion, the Mobile-IPv6 should only aim at coming up with a mobility management mask (similar to subnet mask in CIDR), and should rely on _supporting_ mechanisms to provide hierarchy. This can allow numerous levels of hierarchy, _without_ "corrupting" the IP stack. This also has the added benefit that a router can safely ignore all such mobility masks if it does not want to support this feature. I can provide more details if needed.


A little digression  from the original topic and coming back to the re-transmission mechanisms, I think Mobile-IPv6 should also get rid of all re-transmission mechanisms. In the present Mobile-IPv6 draft, a mobile node keeps sending binding update to the home agent unless it receives a response from the home agent. This is less than ideal and should be changed. A router that drops a binding update should send an explicit ICMP message saying so (this means that the binding update can no longer be the destination option, but an ICMP message). A mobile node should send binding update only once, and after it has detected movement. All such error report ICMP messages should be reported to the upper layer protocol, which could decide the best strategy (the argument that this will break the existing applications is bogus since IPv6 itself will break all existing applications. If one can move to IPv6 from IPv4, then once can also catch these ICMP messages.) The benefit is that!
!
!
!
 an upper layer protocol is probably a better judge of what has to be done next (possibly though human interaction) as opposed to a dumb piece of software that will keep retransmitting for ever.


I read these e-mails in my free time, more as a hobbyist, and I will not be able to respond to your comments during my working hours (8:00-5:00 central time). Hope that's fine.


Thank you for your time.
Best Regards
Yogesh


  James Kempf <James.Kempf@Sun.COM> wrote: 


Hi Hesham,

Thanx for your response, but I think we've been through these
points a number of times, we really don't need to rehash them again. Charlie, 
Theo, myself, and one other person (whose name I've forgotten) have spoken up 
for a requirement to support hierarchy. You and Karim have spoken up against it, 
and Raj, expressing a preference for simplicity, has an inclination
against it.

Anybody else out there in SMTP-land want to express a preference?

Phil, any ideas about how to proceed?

jak


>From: "Hesham Soliman (ERA)" 
>To: "'mobile-ip@sunroof.eng.sun.com'" 
>Cc: Basavaraj.Patil@nokia.com
>Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L 
ocalized Mobility Management Requirement s)
>Date: Tue, 24 Apr 2001 23:34:56!
!
!
!
 +0200
>
>
>> Actually, no. I'm saying that we have had at least three people who
>> have given good arguments, IMHO, as to why multiple levels of
>> hierarchy might be needed. On the other side, those arguments
>> are refuted by two people who think that no hierarchy is needed.
>> Neither side is going to convince the other, both sides have
>> good arguments.
>> 
> => I'm not sure who you mean by the "two" people, there is definitely 
> more (at least the authors of HMIP are) but anyway
> after reading the discussion it really seems to me like the only 
> two (understandable IMHO) reasons are:
>
> 1. In future there may be a need for multi-level hierarchy. That need 
> is not explained really. To me this is not a good reason for including
> any feature. Ithink it makes a lot of sense of scope the problem to
> what we know without "guessing" what !
!
!
!
might happen in future
> and how theuse of MIP can be changed dramatically. No one 
> knows that this is true.
>
> 2. Multi-level hierarchy localises the signalling. Let's try to 
understand 
> what this really means. A MAP domain is as large as the amount 
> of traffic that a MAP can handle, regardless of the number of 
> levels of hierarchy. The signalling will always be local to that
> domain. So I'm not really clear on the significant advantage here. 
> We're certainly not expecting any inter-continental mobility 
> management using HMIPv6. So careful placement of the MAP 
> using network engineering skills and common sense is 
> sufficient. 
>
>> What I'm saying is that we have some arguments the feature is needed,
>> so let's put it in. From Karim's last email, it sounds like we can
>> probably accommodate his concerns about multiplying failure possibilities.
&g!
!
!
!
t;> 
> => At a cost. The beneft MUST outweigh the cost. This is not 
> the case here IMO.
>
>> If we don't put it in and deployment proves that we need it, 
>> 
> => This is exactly point one above. 
>
> Hesham


Swami Prem Yogesh
Research Engineer
Office:                          Home:
Nokia Research Center            826W, Royal Lane
6000 Connection Dr.              #392
Irving, Texas-75039              Irving, Texas-75039 
Tel: 972-374-0669                Tel: 972-831-9589

Do You Yahoo!?

Yahoo! Auctions - buy the things you want at great prices
--0-1015613911-988174293=:93743--


From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 25 03:06: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 DAA08621
	for ; Wed, 25 Apr 2001 03:06:32 -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 AAA18140;
	Wed, 25 Apr 2001 00:04:49 -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 AAA18410;
	Wed, 25 Apr 2001 00:04:40 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3P73MK9016040
	for ; Wed, 25 Apr 2001 00:03:23 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3P73MYQ016039
	for mobile-ip-dist; Wed, 25 Apr 2001 00:03: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3P73CK9016032
	for ; Wed, 25 Apr 2001 00:03:13 -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 AAA20745
	for ; Wed, 25 Apr 2001 00:03:12 -0700 (PDT)
Received: from mailgw.local.ipunplugged.com ([213.88.134.217])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA17401
	for ; Wed, 25 Apr 2001 00:03:11 -0700 (PDT)
Received: from fredrikj (c42.local.ipunplugged.com [192.168.4.241])
	by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id JAA14903
	for ; Wed, 25 Apr 2001 09:04:17 +0200
From: "Fredrik Johansson" 
To: 
Subject: RE: [mobile-ip] Q: GNAIE
Date: Wed, 25 Apr 2001 09:05:02 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
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: 
Content-Transfer-Encoding: 7bit

>
>> RFC2794 already has a type value (131) assigned to the MN-NAI extension.
>> draft-ietf-mobileip-gnaie-02.txt proposes in section 2.1 a new
>type for the
>> same extension. Do we really require this?
>>
>> The problem that I have is that the same data (MN-NAI) will have
>different
>> type values depending on the format of the extension in use (MIER or
>> othewise).
>
>Correct.
>
>I suppose it would be OK for GNAIE NOT to re-define the MN-NAI since it is
>already specified in RFC 2794. As it stands, my code would accept
>both formats.
> PatC

Do you mean to keep the old format for the mn-nai (type,length,nai) and
remove the mn-nai sub type from the generalized nai extension?

/Fredrik



From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 25 06:43: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 GAA10233
	for ; Wed, 25 Apr 2001 06:43:40 -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 DAA11988;
	Wed, 25 Apr 2001 03:41: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 DAA12922;
	Wed, 25 Apr 2001 03:41:31 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PAdmK9016348
	for ; Wed, 25 Apr 2001 03:39:48 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3PAdmLq016347
	for mobile-ip-dist; Wed, 25 Apr 2001 03:39: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PAdYK9016340
	for ; Wed, 25 Apr 2001 03:39:37 -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 DAA14165
	for ; Wed, 25 Apr 2001 03:39:34 -0700 (PDT)
Received: from tml-gw.tml.hut.fi (tml.hut.fi [130.233.44.1])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA13853
	for ; Wed, 25 Apr 2001 03:39:33 -0700 (PDT)
Received: (from smap@localhost)
	by tml-gw.tml.hut.fi (8.8.7/8.8.7) id NAA21885
	for ; Wed, 25 Apr 2001 13:39:31 +0300
Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0)
	id xma021878; Wed, 25 Apr 01 13:39:20 +0300
Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7])
	by mail.tml.hut.fi (8.11.0/8.11.0) with ESMTP id f3PAdJr10629
	for ; Wed, 25 Apr 2001 13:39:19 +0300 (EEST)
Received: from localhost (lpetande@localhost)
	by morphine.tml.hut.fi (8.11.3/8.11.3) with ESMTP id f3PAcO307993
	for ; Wed, 25 Apr 2001 13:38:24 +0300 (EET DST)
X-Authentication-Warning: morphine.tml.hut.fi: lpetande owned process doing -bs
Date: Wed, 25 Apr 2001 13:38:24 +0300 (EET DST)
From: Lars Henrik Petander 
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Some thoughts on BAKE and MIPv6 security
In-Reply-To: <3AE503F9.6D6D2110@nomadiclab.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: 


Thanks for your reply Pekka. I may have missed something of the MN - CN
authorization picture as I was not at the IETF meeting. OTOH I'm working
on the authentication side of the MIPL Linux MIPv6 implementation and
would like to see a solution that works also on untrusted links, that is
a solution applicable also to WLAN and similar low cost wireless links.

On Tue, 24 Apr 2001, Pekka Nikander wrote:

> 
> > A good example of a vulnerable
> > host is a MN in its home network, which is likely to be wireless and
> > eavesdroppable.
> 
> MN's home network is indeed vulnerable, since being located there
> allows an attacker to launch an active attack against an arbitrary CN.
> The same applies to any attacker at the CN->HA link, the home network
> is no different in that sense.  However, even being located at the MN's 
> home network should be safe against passive attackers.  However, if you 
> have found an attack where it is enough to eavesdrop at the MN's home 
> network, please describe it.  That is, there are certain to be attacks
> the we haven't thought about.

I meant MN in the sense of it being just a CN while it is in its home
network. 
 
> 
> > 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 don't have any personal opinions with regard to BAKE.  I just started
> 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. 

> 
> What comes to D-H, IMHO the triangular message exchange in BAKE is
> _almost_ as safe as D-H, and much cheaper.  (The difference is
> that BAKE is vulnerable to passive attackers that are able to
> eavesdrop near the CN or both the MN->CN and CN->HA links, while
> D-H is not.  I think that there is no difference with regard to
> active attackers, but I am not quite sure.)

Unauthenticated D-H in itself does not IMHO provide any protection against
active attackers on the routing path, who pose as a MN to the CN. However,
it allows the authentication of the public keys used and thus makes it
possible to at least try an authenticated exchange. If authentication of
the key exchange is not possible, then a policy could be used to decide
whether to allow the unauthenticated exchange.

> 
> 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 wonder if any one protocol can or should even try
to satisfy the, for now unpublished, requirements and still be applicable
to CNs on untrusted links. Perhaps MN should propose a protocol for
establishing a key in binding warning and CN to approve or disapprove it
in a binding request. A simple key establishment protocol with cookie
protection against DoS attacks + D-H could be used as an alternative to
BAKE or some other similar protocol.

> > 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. 
> 
> As I already said above, I mostly agree.  However, my thoughts are still
> unclear about the relative benefits and drawbacks of using certificates
> vs. implicitly authenticated keys ala CAM/SUCV/PBK-ADDRESSES.

I am not yet familiar with CAM and SUCV, but I have mixed feelings also
towards PBK, which seems applicable only to single connections and not
routing in general (you can establish the keys by pinging a CN and
afterwards all traffic to the home address is routed according to the new
binding).

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

> 
> > In absence of a PKI they could always revert to unauthenticated
> > key establishment, the use of which should be configurable in CNs.
> 
> IMHO global PKI is an unrealistic assumption. 

Yes, it is currently a farfetched one, but organization wide PKIs are
already deployed and can be used if the key establishment protocol allows
it.

> One issue here is 
> whether you want to use BAKE at all if you have properly authorized
> public keys.  If you have public keys, you probably could and should
> use some other protocol, such as IKE (or maybe HIP :-), in any case,
> and leave BAKE or something like that for the case when you don't
> have such keys.

I agree with you here, but use of BAKE and similar protocols should be
nevertheless restricted to trusted links or servers that don't care with
whom they are communicating with. For example: we are thinking about
deploying an IPv6 WLAN with Mobile IPv6 support on the university campus
at HUT (definitely an untrusted link). In this case route optimization
with BAKE or PBK would open new vulnerabilities in the wireless devices
which use MIPv6.


BR,

Henrik Petander



From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 25 07:05: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 HAA10390
	for ; Wed, 25 Apr 2001 07:05: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 EAA15753;
	Wed, 25 Apr 2001 04: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 EAA14104;
	Wed, 25 Apr 2001 04:00:12 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PAwYK9016403
	for ; Wed, 25 Apr 2001 03:58:34 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3PAwYQn016402
	for mobile-ip-dist; Wed, 25 Apr 2001 03:58:34 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PAwNK9016395
	for ; Wed, 25 Apr 2001 03:58:25 -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 DAA13862
	for ; Wed, 25 Apr 2001 03:58:22 -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 GAA10304
	for ; Wed, 25 Apr 2001 06:10:59 -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 MAA18547;
	Wed, 25 Apr 2001 12:58:14 +0200 (MET DST)
Message-ID: <3AE6AE0D.DB9CE57@darmstadt.gmd.de>
Date: Wed, 25 Apr 2001 12:59:25 +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: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L  
 ocalized Mobility Management Requirement s)
References: <20010425045133.98721.qmail@web10106.mail.yahoo.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

Yogesh,

(I'm happy to have found in your contribution some kind of a SYNCH point 
in this interesting ongoing discussion on Hierarchical Mobility Management.
Sorry for skipping many of the others - it's too much.
Living in time zone GMT-1 somehow out-of-SYNCH, 
I'm trying to run through about 20-30 contributions each morning
which is quite hopeless.)

I think I understand your point:
By dividing addresses, one arrives at a hierarchical address space
which, applying the divide-and-conquer principle, makes routing more efficient
(i.e. routing algorithms are faster).
However, this notion of "hierarchy"
is different from that considered for Hierarchical Mobility Management.
Let me shortly explain why I think this is so.

Mobility is managed by a set of "mobility agents" (HA, FA, MAP, ...),
their service is to forward packets to hosts
currently not a the position indicated by their address.
You may view the set of mobility agents as a "mobile network"
where the links are IP paths ("tunnels").
This is very similar to Virtual Private Networks and the like.
The question is now which topology this mobile network has.

For classical Mobile IP, it is a "clique" (in the graph-theoretic sense,
i.e. any FA is directly linked (via a single tunnel) to any HA.
In Hierarchical Mobility Management (whichever proposal you consider),
the topology is not a clique, it is a "tree" (again in the graph-theoretic sense)
with a distinguished "root", sometimes also called a "hierarchy".

But note that this makes sense with a flat (i.e. non-hierarchical)
address space, with a two-layer hierarchy as in classical IP,
and with any other number of layers.
No matter how many layers you have,
the topology of each layer may be a clique, a tree or anything you prefer.
The two notions of "hierarchy" are independent of each other.
Maybe, one should reserve the word "hierarchy" for the address space
and talk of "Tree-like Mobility Management"
in order to avoid confusions.
But I know - terminology tends to (and should) freeze very rapidly.

Let me finish by mentioning that a question more critial 
than the height of a mobile network is whether it should be tree-like at all.
Note that IP is not, for various well-known reasons.
But starting with trees is a good practice since
topologies with weaker or no restrictions are much harder to handle.

Hope this helps (instead of confusing)

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 Apr 25 08:39: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 IAA13078
	for ; Wed, 25 Apr 2001 08:39: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 FAA08254;
	Wed, 25 Apr 2001 05:37: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 FAA14240;
	Wed, 25 Apr 2001 05:37:14 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PCa6K9016499
	for ; Wed, 25 Apr 2001 05:36:06 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3PCa5FF016498
	for mobile-ip-dist; Wed, 25 Apr 2001 05:36:05 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PCZtK9016491
	for ; Wed, 25 Apr 2001 05:35:57 -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 FAA22389
	for ; Wed, 25 Apr 2001 05:35: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 HAA18820
	for ; Wed, 25 Apr 2001 07:48:33 -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 f3PCZkg15964
	for ; Wed, 25 Apr 2001 07:35:56 -0500 (CDT)
Received: from daebh02nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id  for ;
 Wed, 25 Apr 2001 07:35:41 -0500
Received: by daebh02nok with Internet Mail Service (5.5.2652.78)
	id ; Wed, 25 Apr 2001 07:35:41 -0500
Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B032138D4@daeis07nok>
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Q: GNAIE
Date: Wed, 25 Apr 2001 07:35:40 -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: 

Can the authors of this I-D (draft-ietf-mobileip-gnaie-02.txt) fix this
problem
and issue a new version of the draft?

-Basavaraj

> 
> > RFC2794 already has a type value (131) assigned to the 
> MN-NAI extension.
> > draft-ietf-mobileip-gnaie-02.txt proposes in section 2.1 a 
> new type for the
> > same extension. Do we really require this? 
> > 
> > The problem that I have is that the same data (MN-NAI) will 
> have different
> > type values depending on the format of the extension in use (MIER or
> > othewise).
> 
> Correct.
> 
> I suppose it would be OK for GNAIE NOT to re-define the 
> MN-NAI since it is
> already specified in RFC 2794. As it stands, my code would 
> accept both formats.
>  PatC
> 


From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 25 08:51:40 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13419
	for ; Wed, 25 Apr 2001 08:51: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 FAA17398;
	Wed, 25 Apr 2001 05:49:38 -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 FAA15255;
	Wed, 25 Apr 2001 05:49:24 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PCmCK9016536
	for ; Wed, 25 Apr 2001 05:48:13 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3PCmCBo016535
	for mobile-ip-dist; Wed, 25 Apr 2001 05:48: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PCm0K9016528
	for ; Wed, 25 Apr 2001 05:48:03 -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 FAA23292
	for ; Wed, 25 Apr 2001 05:48:02 -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 FAA29054
	for ; Wed, 25 Apr 2001 05:48:00 -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 f3PClxO13920
	for ; Wed, 25 Apr 2001 14:48:00 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Wed Apr 25 14:47:59 2001 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Wed, 25 Apr 2001 14:47:58 +0200
Message-ID: 
From: "Karim El-Malki (ERA)" 
To: "'James Kempf '" ,
        "'Erik Nordmark '"
	 ,
        "'mobile-ip@sunroof.eng.sun.com '"
	 
Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L
	 ocalized Mobility Management Requirement s)
Date: Wed, 25 Apr 2001 14:47:53 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
List-Subscribe: 
List-Unsubscribe: 
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 and Erik

>>> Ulimately, the issue is one of deployment. The worst possible case
>>> is we cycle an LMM protocol without multiple levels of hierarchy
>>> to proposed and discover during deployment that we need it. 
>>
>>Jim,
>>
>>You are stating the design philosophy that leads to kitchen sink
>>protocols - put in as much as possible to make sure nothing we can
>>ever imagine has been left out.
>>
>>I much prefer the opposite philosophy - only include what we know for 
>>sure will be needed.
>>
>
>
>Actually, no. I'm saying that we have had at least three people who
>have given good arguments, IMHO, as to why multiple levels of
>hierarchy might be needed. On the other side, those arguments
>are refuted by two people who think that no hierarchy is needed.
>Neither side is going to convince the other, both sides have
>good arguments.
>
>The kitchen sink results when somebody says "let's put in this neat
>feature," then somebody else says "let's put in this neat feature,"
>and the group iterates on this for several rounds with nobody 
>really coming up with good arguments for or against the feature except
>that it was X's idea.
>
>What I'm saying is that we have some arguments the feature is needed,
>so let's put it in. From Karim's last email, it sounds like we can
>probably accommodate his concerns about multiplying failure
>possibilities.
>If we don't put it in and deployment proves that we need it, as I and
>at least two other people on the list think will likely be the case, we
>are stuck with going back through proposed standard.

I agree with Erik's point. If putting another requirement on local
mobility gets us to produce optimised solutions for it without knowing
if it is needed that's IMO not a good idea. On this point I agree that
we should include what we know is needed and keep the solution simple.
However, my previous comment was that in this particular case we can probably get the basic linked local agents functionality for free in
the solution. At least that's what we have now, even though I'm not
convinced this functionality will be useful.

Regards
/Karim


From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 25 09:26:21 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14697
	for ; Wed, 25 Apr 2001 09:26: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 GAA08026;
	Wed, 25 Apr 2001 06:24: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 GAA25284;
	Wed, 25 Apr 2001 06:24:28 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PDMnK9016633
	for ; Wed, 25 Apr 2001 06:22:49 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3PDMmer016632
	for mobile-ip-dist; Wed, 25 Apr 2001 06: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PDMbK9016625
	for ; Wed, 25 Apr 2001 06:22:38 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA20017
	for ; Wed, 25 Apr 2001 06:22:39 -0700 (PDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id GAA04269
	for ; Wed, 25 Apr 2001 06:22:38 -0700 (PDT)
Date: Wed, 25 Apr 2001 06:22:38 -0700 (PDT)
From: Patrice Calhoun 
Subject: RE: [mobile-ip] Q: GNAIE
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: 

> >
> >> RFC2794 already has a type value (131) assigned to the MN-NAI extension.
> >> draft-ietf-mobileip-gnaie-02.txt proposes in section 2.1 a new
> >type for the
> >> same extension. Do we really require this?
> >>
> >> The problem that I have is that the same data (MN-NAI) will have
> >different
> >> type values depending on the format of the extension in use (MIER or
> >> othewise).
> >
> >Correct.
> >
> >I suppose it would be OK for GNAIE NOT to re-define the MN-NAI since it is
> >already specified in RFC 2794. As it stands, my code would accept
> >both formats.
> > PatC
> 
> Do you mean to keep the old format for the mn-nai (type,length,nai) and
> remove the mn-nai sub type from the generalized nai extension?

I believe that is what people are asking for. I agree that obsoleting RFC 2794
would be a BAD thing.

PatC



From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 25 09:43:44 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15369
	for ; Wed, 25 Apr 2001 09:43: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 GAA18926;
	Wed, 25 Apr 2001 06:41: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 GAA23557;
	Wed, 25 Apr 2001 06:41:07 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PDa8K9016667
	for ; Wed, 25 Apr 2001 06:36:08 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3PDa8BY016666
	for mobile-ip-dist; Wed, 25 Apr 2001 06:36: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PDZvK9016659
	for ; Wed, 25 Apr 2001 06:36:00 -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 GAA20176
	for ; Wed, 25 Apr 2001 06:35:58 -0700 (PDT)
From: Basavaraj.Patil@nokia.com
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA20694
	for ; Wed, 25 Apr 2001 06:35:47 -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 f3PDZpg22695
	for ; Wed, 25 Apr 2001 08:35:51 -0500 (CDT)
Received: from daebh02nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id ;
 Wed, 25 Apr 2001 08:35:46 -0500
Received: by daebh02nok with Internet Mail Service (5.5.2652.78)
	id ; Wed, 25 Apr 2001 08:35:46 -0500
Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B032138D7@daeis07nok>
To: Erik.Nordmark@eng.sun.com, mobile-ip@sunroof.eng.sun.com
Cc: Basavaraj.Patil@nokia.com
Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L
	 ocalized Mobility Management Requirement s)
Date: Wed, 25 Apr 2001 08:35:45 -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: 

 
> > Ulimately, the issue is one of deployment. The worst possible case
> > is we cycle an LMM protocol without multiple levels of hierarchy
> > to proposed and discover during deployment that we need it. 
> 
> Jim,
> 
> You are stating the design philosophy that leads to kitchen sink
> protocols - put in as much as possible to make sure nothing we can
> ever imagine has been left out.
> 
> I much prefer the opposite philosophy - only include what we know for 
> sure will be needed.
> 
>    Erik

What we do not want to see is another IN (Intelligent network) type of
solution,
and cram a lot of smarts about mobility and optimization in the network by
introducing multiple levels of smart routers/agents. After all "the stupid
network"
does have it's merits :)
There are enough compelling reasons to add one LMM agent, but more than
one ....? Or let's put it this way, how many levels of hierarchy would be
optimal?

So if we were to deploy this solution (since we agree that the issue is one
of 
deployment) today, how would you propose changing existing routers in the
operator's network which may have to become mobility aware? You could
potentially
add one more new router/LMM into the network quite easily as opposed to 
introducing new functionality into an operator's existing network and
equipment.

-Basavaraj


From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 25 09:44:59 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15442
	for ; Wed, 25 Apr 2001 09:44:59 -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 GAA20005;
	Wed, 25 Apr 2001 06:42: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 GAA26968;
	Wed, 25 Apr 2001 06:42:40 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PDbmK9016677
	for ; Wed, 25 Apr 2001 06:37:49 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3PDbmPD016676
	for mobile-ip-dist; Wed, 25 Apr 2001 06:37: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PDbdK9016669
	for ; Wed, 25 Apr 2001 06:37:39 -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 GAA20363
	for ; Wed, 25 Apr 2001 06:37: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 patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA16544
	for ; Wed, 25 Apr 2001 06:37:38 -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 f3PDe2w08877
	for ; Wed, 25 Apr 2001 08:40:02 -0500 (CDT)
Received: from daebh02nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id  for ;
 Wed, 25 Apr 2001 08:37:38 -0500
Received: by daebh02nok with Internet Mail Service (5.5.2652.78)
	id ; Wed, 25 Apr 2001 08:37:38 -0500
Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B032138D8@daeis07nok>
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Q: GNAIE
Date: Wed, 25 Apr 2001 08:37:38 -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: 
 

> > Do you mean to keep the old format for the mn-nai 
> (type,length,nai) and
> > remove the mn-nai sub type from the generalized nai extension?
> 
> I believe that is what people are asking for. I agree that 
> obsoleting RFC 2794
> would be a BAD thing.
>

Agree with you Pat. Let's not try to change RFC2794. 
 
> PatC
> 

-Basavaraj


From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 25 10:12: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 KAA16709
	for ; Wed, 25 Apr 2001 10:12: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 HAA11921;
	Wed, 25 Apr 2001 07:10: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 HAA00527;
	Wed, 25 Apr 2001 07:09:57 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PE7kK9016742
	for ; Wed, 25 Apr 2001 07:07:46 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3PE7eiX016741
	for mobile-ip-dist; Wed, 25 Apr 2001 07:07: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PE7PK9016734
	for ; Wed, 25 Apr 2001 07:07:26 -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 HAA01454
	for ; Wed, 25 Apr 2001 07:07:26 -0700 (PDT)
Received: from atlsnmx1.nextel.com (atlsnmx1.nextel.com [167.20.198.200])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA05922
	for ; Wed, 25 Apr 2001 07:07:23 -0700 (PDT)
Received: from atlntgw01.nextel.com (atlntgw01.nextel.com [10.8.79.187])
	by atlsnmx1.nextel.com (8.8.8+Sun/8.8.6) with ESMTP id KAA14693
	for ; Wed, 25 Apr 2001 10:07:21 -0400 (EDT)
Received: by atlntgw01.nextel.com with Internet Mail Service (5.5.2650.21)
	id ; Wed, 25 Apr 2001 10:07:55 -0400
Message-ID: <020A5EC56F3FD411B5230008C716D085868612@nhqntex01.nextel.com>
From: "Martin, David P" 
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)
Date: Wed, 25 Apr 2001 10:02:12 -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've been following the discussion, and since you've asked I'll give you an
opinion.

It seems that Hesham's main point is that the speed of the fixed network (or
"wired") is so much greater than that of the wireless network that the
benefits of hierarchy are minimized.

I'm not sure I would agree that the speed of the fixed network will *always*
significantly outstrip that of the mobile network.  I don't feel I have a
good enough grasp of all the issues to weigh in on one side or the other,
but did want to highlight an assumption I don't feel comfortable with.

> -----Original Message-----
> From: Phil Roberts [mailto:PRoberts@MEGISTO.com]
> Sent: Tuesday, April 24, 2001 5:59 PM
> 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)
> 
> 
> How to proceed?  Good question.  It would be really good if 
> some other folks
> weighed in on the issue.  Does anyone who hasn't commented on 
> this so far
> care to add anything?  care at all?
> 
> Phil
> 
> 
> > -----Original Message-----
> > From: James Kempf [mailto:James.Kempf@Sun.COM]
> > Sent: Tuesday, April 24, 2001 5:47 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
> > L ocalized Mobility Management Requirement s)
> > 
> > 
> > Hi Hesham,
> > 
> > Thanx for your response, but I think we've been through these
> > points a number of times, we really don't need to rehash them 
> > again. Charlie, 
> > Theo, myself, and one other person (whose name I've 
> > forgotten) have spoken up 
> > for a requirement to support hierarchy. You and Karim have 
> > spoken up against it, 
> > and Raj, expressing a preference for simplicity, has an inclination
> > against it.
> > 
> > Anybody else out there in SMTP-land want to express a preference?
> > 
> > Phil, any ideas about how to proceed?
> > 
> > 		jak
> > 
> > 
> > >From: "Hesham Soliman  (ERA)" 
> > >To: "'mobile-ip@sunroof.eng.sun.com'" 
> 
> > >Cc: Basavaraj.Patil@nokia.com
> > >Subject: RE: Multiple Levels of LMM agents (was: RE: 
> > [mobile-ip] Revised L 
> > ocalized Mobility Management Requirement s)
> > >Date: Tue, 24 Apr 2001 23:34:56 +0200
> > >
> > >
> > >> Actually, no. I'm saying that we have had at least three 
> people who
> > >> have given good arguments, IMHO, as to why multiple levels of
> > >> hierarchy might be needed. On the other side, those arguments
> > >> are refuted by two people who think that no hierarchy is needed.
> > >> Neither side is going to convince the other, both sides have
> > >> good arguments.
> > >> 
> > >	=> I'm not sure who you mean by the "two" people, there 
> > is definitely 
> > >	more (at least the authors of HMIP are) but anyway
> > >	after reading the discussion it really seems to me like 
> > the only 
> > >	two (understandable IMHO) reasons are:
> > >
> > >	1.  In future there may be a need for multi-level 
> > hierarchy. That need 
> > >	is not explained really. To me this is not a good 
> > reason for including
> > >	any feature. Ithink it makes a lot of sense of scope 
> > the problem to
> > >	what we know without "guessing" what might happen in future
> > >	and how theuse of MIP can be changed dramatically. No one 
> > >	knows that this is true.
> > >
> > >	2. Multi-level hierarchy localises the signalling. Let's try to 
> > understand 
> > >	what this really means. A MAP domain is as large as the amount 
> > >	of traffic that a MAP can handle, regardless of the number of 
> > >	levels of hierarchy. The signalling will always be local to that
> > >	domain. So I'm not really clear on the significant 
> > advantage here. 
> > >	We're certainly not expecting any inter-continental mobility 
> > >	management using HMIPv6. So careful placement of the MAP 
> > >	using network engineering skills and common sense is 
> > >	sufficient. 
> > >
> > >> What I'm saying is that we have some arguments the feature 
> > is needed,
> > >> so let's put it in. From Karim's last email, it sounds 
> like we can
> > >> probably accommodate his concerns about multiplying 
> > failure possibilities.
> > >> 
> > >	=> At a cost. The beneft MUST outweigh the cost. This is not 
> > >	the case here IMO.
> > >
> > >> If we don't put it in and deployment proves that we need it, 
> > >> 
> > >	=> This is exactly point one above. 
> > >
> > >	Hesham
> > 
> 


From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 25 10:30: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 KAA17529
	for ; Wed, 25 Apr 2001 10:30: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 HAA19809;
	Wed, 25 Apr 2001 07:28: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 HAA03309;
	Wed, 25 Apr 2001 07:28:12 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PEQjK9016837
	for ; Wed, 25 Apr 2001 07:26:45 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3PEQihx016836
	for mobile-ip-dist; Wed, 25 Apr 2001 07:26: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PEQYK9016829
	for ; Wed, 25 Apr 2001 07:26: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 HAA04055
	for ; Wed, 25 Apr 2001 07:26:32 -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 HAA16244
	for ; Wed, 25 Apr 2001 07:26:31 -0700 (PDT)
Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21)
	id ; Wed, 25 Apr 2001 10:20:35 -0400
Message-ID: 
From: Phil Roberts 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: [mobile-ip] LMM multiple level summary
Date: Wed, 25 Apr 2001 10:20:32 -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,

	I'm making another pass through the requirements and it seems as if
there is convergence except on the issue of multiple levels of hierarcy.
I'll start a separate thread on the things we've converged on.  Here's my
attempt at summarizing the pros and cons of multiple levels without any
comment on the merits either way.  Again, I'd like to ask for folks who
haven't been really active in this thread to make comments on these.  Could
I also ask that the folks that have been really active refrain from the
discussion for a little while just to give others a chance?


The reasons that have been presented FOR using multiple levels of hierarchy:
1.  Multiple levels of hierarchy allows lower level LMM to change while top
level LMM remains the same, thus localizing the signalling so that it
remains between MN and LMM agents and doesn't go out to all the CNs
2.  Multiple levels of hierarchy allows the elimination of a kind of lower
level triangle routing.
3.  Multiple levels conform to some visions of what all IP cellular networks
might become.
4.  Multiple levels of hierarchy may assist in network engineering.
5.  Linking LMM agents in a hierarchy will assist in resiliency.
6.  Deployment may make it obvious multiple levels are needed and then we'll
have to recycle to proposed standard to get them in.

The reasons that have been presented AGAINST using multiple levels of
hierarchy:
1.  Design and implementation is much simpler without it.
2.  Multiple levels multiplies the possibilities of failures.
3.  It's better in principle only to include what we know is needed.
4.  It's better to use normal IP routing for traffic engineering.



From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 25 10:49:05 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18279
	for ; Wed, 25 Apr 2001 10:49:05 -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 HAA04499;
	Wed, 25 Apr 2001 07:45: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 HAA05300;
	Wed, 25 Apr 2001 07:45:28 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PEhUK9016871
	for ; Wed, 25 Apr 2001 07:43:30 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3PEhU7i016870
	for mobile-ip-dist; Wed, 25 Apr 2001 07:43: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PEhLK9016863
	for ; Wed, 25 Apr 2001 07:43: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 HAA05779
	for ; Wed, 25 Apr 2001 07:43:22 -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 HAA02607
	for ; Wed, 25 Apr 2001 07:43:21 -0700 (PDT)
Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21)
	id ; Wed, 25 Apr 2001 10:37:25 -0400
Message-ID: 
From: Phil Roberts 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: [mobile-ip] Final(?) Cut on LMM Requirements
Date: Wed, 25 Apr 2001 10:37:21 -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: 

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.)
2. LMM shall be secure from malicious behavior.
3. Connectivity to the mobiles should be minimized (MUST) or eliminated
(strive for this) in the presence of failure of LMM agents.
(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.)
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)
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))
8. LMM shall not require changes to the HA and the CNs.
9. LMM should provide the same level of mobility management support as in
the basic MIPv6 spec.
10. LMM should support autoconfig.

Unless there is some strong objection to these they will be requirements.
We may or may not add one on multiple levels of hierarchy depending on the
other discussion.

Phil


From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 25 11:56:45 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20724
	for ; Wed, 25 Apr 2001 11:56: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 IAA02842;
	Wed, 25 Apr 2001 08:54: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 IAA18370;
	Wed, 25 Apr 2001 08:54:48 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PFrUK9017018
	for ; Wed, 25 Apr 2001 08:53:30 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3PFrU2L017017
	for mobile-ip-dist; Wed, 25 Apr 2001 08:53: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PFrJK9017010
	for ; Wed, 25 Apr 2001 08:53:21 -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 IAA17185
	for ; Wed, 25 Apr 2001 08:53:20 -0700 (PDT)
Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA20115
	for ; Wed, 25 Apr 2001 08:53:19 -0700 (PDT)
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id IAA22296 for ; Wed, 25 Apr 2001 08:53:18 -0700 (MST)]
Received: [from m-il06-r1.mot.com (m-il06-r1.mot.com [129.188.137.193]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id IAA22122 for ; Wed, 25 Apr 2001 08:53:18 -0700 (MST)]
Received: from [140.101.173.9] by m-il06-r1.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Wed, 25 Apr 2001 08:53:08 -0700
Received: (from root@localhost)
	by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) id RAA27550
	for mobile-ip@sunroof.eng.sun.com.DELIVER; Wed, 25 Apr 2001 17:53:04 +0200 (METDST)
Received: from crm.mot.com (routier@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 RAA27435
	for ; Wed, 25 Apr 2001 17:53:02 +0200 (METDST)
Message-Id: <3AE6F2DB.88661142@crm.mot.com>
Date: Wed, 25 Apr 2001 17:52:59 +0200
From: Damien Routier 
Organization: Centre de Recherche de Motorola - Paris
X-Mailer: Mozilla 4.74C-CRM-4.7_2.2 [en] (X11; U; Linux 2.2.16 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Authenticating BU and PKI
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 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 ...?

thanks for paying attention to this "dummy" question
have a nice day

Damien 
Motorola Research Center, Paris


From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 25 13:00:37 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22647
	for ; Wed, 25 Apr 2001 13:00: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 JAA00713;
	Wed, 25 Apr 2001 09:58: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 JAA01772;
	Wed, 25 Apr 2001 09:58:51 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PGvXK9017170
	for ; Wed, 25 Apr 2001 09:57:33 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3PGvWrT017169
	for mobile-ip-dist; Wed, 25 Apr 2001 09:57: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PGvOK9017162
	for ; Wed, 25 Apr 2001 09:57:24 -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 JAA22528;
	Wed, 25 Apr 2001 09:57:22 -0700 (PDT)
Message-Id: <200104251657.JAA22528@heliopolis.eng.sun.com>
Date: Wed, 25 Apr 2001 09:57:22 -0700 (PDT)
From: James Kempf 
Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L  ocalized Mobility Management Requirement s)
To: Erik.Nordmark@eng.sun.com, mobile-ip@sunroof.eng.sun.com
Cc: Basavaraj.Patil@nokia.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: xsJDyNSjJ+fP+bPKYa72/Q==
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: 

Raj,


>What we do not want to see is another IN (Intelligent network) type of
>solution,
>and cram a lot of smarts about mobility and optimization in the network by
>introducing multiple levels of smart routers/agents. After all "the stupid
>network"
>does have it's merits :)
>There are enough compelling reasons to add one LMM agent, but more than
>one ....? Or let's put it this way, how many levels of hierarchy would be
>optimal?
>
>So if we were to deploy this solution (since we agree that the issue is one
>of 
>deployment) today, how would you propose changing existing routers in the
>operator's network which may have to become mobility aware? You could
>potentially
>add one more new router/LMM into the network quite easily as opposed to 
>introducing new functionality into an operator's existing network and
>equipment.
>

I guess I don't understand your response. Nobody's proposing an IN like
solution. The RR proposal has hierarchy, it is not all that much
more complicated than HMIP, IMHO.

All that we're asking for is that the requirements state that the
solution SHOULD (not MUST) support multiple levels of LMM agents.
The reason is so that if a network operator has a deployment situation
where the signalling lines get long, they can deploy an upper level
agent to keep the external CoA fixed.

People are reading too much into "LMM" and "hierarchy" as words.

		jak



From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 25 13:42: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 NAA24009
	for ; Wed, 25 Apr 2001 13:42: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 KAA29647;
	Wed, 25 Apr 2001 10:41: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 KAA11214;
	Wed, 25 Apr 2001 10:40:25 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PHc2K9017260
	for ; Wed, 25 Apr 2001 10:38:03 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3PHc22Z017259
	for mobile-ip-dist; Wed, 25 Apr 2001 10:38: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PHbnK9017252
	for ; Wed, 25 Apr 2001 10:37: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 KAA14898
	for ; Wed, 25 Apr 2001 10:37:50 -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 KAA07145
	for ; Wed, 25 Apr 2001 10:37:44 -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 KAA18828
	for ; Wed, 25 Apr 2001 10:37:43 -0700 (PDT)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3PHbew06406
	for ; Wed, 25 Apr 2001 10:37:40 -0700
X-mProtect:  Wed, 25 Apr 2001 10:37:40 -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(WTS.12.69) smtpd16ku5c; Wed, 25 Apr 2001 10:37:35 PDT
Message-ID: <3AE70B61.9C2DFDCE@iprg.nokia.com>
Date: Wed, 25 Apr 2001 10:37:37 -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] Final(?) Cut on 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

Hi Phil,

Some comments here:

BTW do we think that the LMM should not require all routers to be LMM-aware?

more comments below..


Phil Roberts wrote:

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

I am not aware of a name that maps to such notion but I think we could enforce
a number of hops that identify a

    macro domain (adminstrative)
     micro domain (two or more domains) that constitute a macro domain. It's
cardinality could be identified as
                                                    diameter of macro domain
                        MDcard =      ----------------------------
                                                 target diameter for micro
domain

depending on the target diameter for a micro domain we can have a variable
sized domain as part ot the admin one.


>
> 2. LMM shall be secure from malicious behavior.

agreed

>
> 3. Connectivity to the mobiles should be minimized (MUST) or eliminated
> (strive for this) in the presence of failure of LMM agents.

agreed

>
> (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.)
> 4. LMM shall be compatible with fast handoffs.

agreed

>

>

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

In principle fine; just a shot to see if we can enrich the revised one:

The LMM shall scale to support aggregates of dense populations of MNs (in the
figures of mi/bi/zillions) per administrative domain unit. These dense MN
populations should be distributed within constituents of the admin domain so as
to avoid hot spot effects that can undermine the efficiency of the LMM scheme.


>
> 6. LMM shall not increase the number of messages between the MN and the LMM
> agents.

as opposed to what?  We need to provide a yardstick here...

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

I think we state as a requirement that:


"Any additional header overhead caused by LMM should be eliminated so as not to
introduce any perceived service disruption."

I suggest that we leave the solution space (ROHC/Seamoby) out of this since
that other group are working on them..it is the task of these groups to effect
such optimizations over any LMM protocols.

>
> 8. LMM shall not require changes to the HA and the CNs.

agreed

>
> 9. LMM should provide the same level of mobility management support as in
> the basic MIPv6 spec.
>

of course you imply "A minimum of" otherwise there is no reason for an
extension


> 10. LMM should support autoconfig.
>

very much agreed


>
> Unless there is some strong objection to these they will be requirements.
> We may or may not add one on multiple levels of hierarchy depending on the
> other discussion.
>

In terms of the host routes and multiple levels of hierarchy I can only
emphasize that we are going to find them in front of us as soon as

- not all routing elements are LMM-aware (need to know the immediate LMM-aware
neighbours to cater for resiliency), hence we need urgently host routes..which
BTW the B-Cache has had for years... :))))
- we want resiliency to failure....we will need to know the previous and next
LMM-aware routers which can only map to a hierarchy... assuming no partitioning
in LMM servicing..


If we opt not to put them in it is just that we have decided to turn a blind
eye and put them under the carpet...but we will step on that spot very soon...



Theo


UCL/ Mobile Systems



From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 25 14:01:12 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24607
	for ; Wed, 25 Apr 2001 14:01:07 -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 LAA23821;
	Wed, 25 Apr 2001 11:00: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 KAA20089;
	Wed, 25 Apr 2001 10:59:48 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PHwOK9017311
	for ; Wed, 25 Apr 2001 10:58:24 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3PHwNiR017310
	for mobile-ip-dist; Wed, 25 Apr 2001 10:58: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PHwBK9017303
	for ; Wed, 25 Apr 2001 10:58:13 -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 KAA18093;
	Wed, 25 Apr 2001 10:58:10 -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 KAA22138;
	Wed, 25 Apr 2001 10:58:09 -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 KAA20831;
	Wed, 25 Apr 2001 10:58:07 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3PHw4920748;
	Wed, 25 Apr 2001 10:58:04 -0700
X-mProtect:  Wed, 25 Apr 2001 10:58:04 -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(WTS.12.69) smtpdDOQKof; Wed, 25 Apr 2001 10:57:57 PDT
Message-ID: <3AE71027.C1F84A4D@iprg.nokia.com>
Date: Wed, 25 Apr 2001 10:57:59 -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: Erik.Nordmark@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)
References: <7B5C0390ACE7D211BC9C0008C7EABA2B032138D7@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

Hi Raj,



Basavaraj.Patil@nokia.com wrote:

>
> What we do not want to see is another IN (Intelligent network) type of
> solution,
> and cram a lot of smarts about mobility and optimization in the network by
> introducing multiple levels of smart routers/agents. After all "the stupid
> network"
> does have it's merits :)

I do not think that anybody talked about intelligent networks in the
slightest..so I cannot follow your thinking here..


>
> There are enough compelling reasons to add one LMM agent, but more than
> one ....? Or let's put it this way, how many levels of hierarchy would be
> optimal?
>

Personally I have provided reasons that are compelling enough to think twice
_before_ trying to even consider droping the proposed requirement.

How many levels of hierarchy would be required at the very least? At least
two...this is "previous and next" this to me is the _fundamental_ notion and
requirement for a multi-level (that is more than _one_) hierarchy.... look all
the MIPv6 scheme that claim speedups...they talk about previous and next...why
can't you think that as a hierarchy...or can you argue that it isn't?

Increasing the cardinality of the depth does not mean that it will grow to
hunderds of hops...do a traceroute from your lab...how many hops do you see
within _your_ admin domain for a route to  London (say). I gather that it is
not more than 4-5 before bordering..

So I think that we are not talking about hierarchies that will grow by the
tenths or hunderds here...





>
> So if we were to deploy this solution (since we agree that the issue is one
> of
> deployment) today, how would you propose changing existing routers in the
> operator's network which may have to become mobility aware? You could
> potentially
> add one more new router/LMM into the network quite easily as opposed to
> introducing new functionality into an operator's existing network and
> equipment.

Who said that all routing element have to LMM-aware? I think Phil Roberts
needs to make a serious requirement statement on that here...in the reqs set.

But at the same time who said that a network operator will only buy only a
single LMM-aware router? It is, clearly, a mistake to assume such thing. So
what happens when it has more than one (just say two for the sake of the
argument, although it could be more)...if you want to cater for resiliency to
failures you NEED AT LEAST TWO........so there you have a resiliency fallback
hierarchy,....why is it impossible to see such hierarchy working for other
purposes AS WELL....?????

You may want to pay attentiion to the fact that I said NOTHING about having to
upgrade existing equipment..since you suggest purchasing new equipment (which
I think will be more expensive but nevertheless arguable)

If it scares people to see a multi-level (with an upper boundary of say 4-5)
hierarchy on its own, I would urge people to consider such hierarchy in the
face of resiliency (with a _lower_ boundary of 2)...

Resiliency in the book of LMMs so far IS a requirement...transitively you will
see where I am heading at...

Theo


UCL/ Mobile Systems



>
>
> -Basavaraj



From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 25 15:10: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 PAA27379
	for ; Wed, 25 Apr 2001 15:10:21 -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 MAA13020;
	Wed, 25 Apr 2001 12:09: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 MAA02719;
	Wed, 25 Apr 2001 12:09:41 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PJ8PK9017418
	for ; Wed, 25 Apr 2001 12:08:25 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3PJ8OR1017417
	for mobile-ip-dist; Wed, 25 Apr 2001 12:08: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PJ8FK9017410
	for ; Wed, 25 Apr 2001 12:08: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 MAA02268
	for ; Wed, 25 Apr 2001 12:08:15 -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 OAA06693
	for ; Wed, 25 Apr 2001 14:22:01 -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 f3PJ83g21406
	for ; Wed, 25 Apr 2001 14:08:13 -0500 (CDT)
Received: from daebh02nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id ;
 Wed, 25 Apr 2001 14:07:51 -0500
Received: by daebh02nok with Internet Mail Service (5.5.2652.78)
	id ; Wed, 25 Apr 2001 14:07:51 -0500
Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B032138E1@daeis07nok>
To: James.Kempf@Sun.COM, Erik.Nordmark@eng.sun.com,
        mobile-ip@sunroof.eng.sun.com
Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L
	  ocalized Mobility Management Requirement s)
Date: Wed, 25 Apr 2001 14:07:49 -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,

>Raj,
>
--snip-----
>
>I guess I don't understand your response. Nobody's proposing an IN like
>solution. 

I did not mean to say IN in the traditional sense of IN. What I meant
to say was that we should not be building additional intelligence in
the routing infrastructure via LMM agents (or multiple LMM agents :)
and the like to handle mobile nodes in an efficient manner. 

>The RR proposal has hierarchy, it is not all that much
>more complicated than HMIP, IMHO.
>

My statement had no relevance on any specific solution. 
But HMIP allows you to have a hierarchy as well, does'nt it?

>All that we're asking for is that the requirements state that the
>solution SHOULD (not MUST) support multiple levels of LMM agents.

No problem from my perspective with this requirement. I think we have
debated enough on this topic. I propose that we leave the requirement
in there and let deployments decide on the levels of LMMs required.

>The reason is so that if a network operator has a deployment situation
>where the signalling lines get long, they can deploy an upper level
>agent to keep the external CoA fixed.
>
>People are reading too much into "LMM" and "hierarchy" as words.
>
>		jak

-Basavaraj


From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 25 15:52:26 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28966
	for ; Wed, 25 Apr 2001 15:52: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 MAA18741;
	Wed, 25 Apr 2001 12:51: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 MAA11686;
	Wed, 25 Apr 2001 12:51:18 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PJjxK9017516
	for ; Wed, 25 Apr 2001 12:45:59 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3PJjwVh017515
	for mobile-ip-dist; Wed, 25 Apr 2001 12:45: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PJjoK9017508
	for ; Wed, 25 Apr 2001 12:45:50 -0700 (PDT)
Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207])
	by jurassic.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with SMTP id f3PJjgiF232118;
	Wed, 25 Apr 2001 12:45:43 -0700 (PDT)
Message-Id: <200104251945.f3PJjgiF232118@jurassic.eng.sun.com>
Date: Wed, 25 Apr 2001 12:46:50 -0700 (PDT)
From: Samita Chakrabarti 
Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised Loca lized Mobility Management Requirement s)
To: mobile-ip@sunroof.eng.sun.com
Cc: samita@jurassic.Eng.Sun.COM
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: pqYQWtc7kWNv2v0Hs3GGPQ==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 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: 

> How to proceed?  Good question.  It would be really good if some other folks
> weighed in on the issue.  Does anyone who hasn't commented on this so far
> care to add anything?  care at all?
>
> Phil
>
>

IMHO, we need to be  careful what we decide as the requirement for
LMM or GMA or MAP ( however, we like to call it). Ideally, multi-level
hierarchy seems nice because the mobile can roam a broad geographical
area without ever sending binding updates to CN or HA. But, it comes with
a very high cost:
      - cost of designing a complex protocol, which may take
        long time for real deployment of MIPv6 and consequently IPv6.

     -- cost of maintaing the states within the multi-level hierarchical
        agents-- i,e when a MN moves from one chain of hierarchy to another
        the protocol needs to update all the routers in the new chain.
        (static host routes are not desirable and thus it needs a new protocol)

      -- For failure and recovery, either the protocol will be complex or folks
         will have to maintain multiple back ups.

     -- Are we gaining in any latency here  as opposed to sending a BU to
        a CN  and implementing MIPV6 fast handoff ?
        For data networking, I'd say in future, in most cases the CN location
        will be close by (with CDN). For VoIP, I expect that
        most of the cases we should either use route-optimization for MIPV6
        or use a HA which is close by (Ofcourse it depends on the business
        model).

     -- For most situtations the active communication takes place for short
        period of time, so if the coverage of LMM is reasonably large enough
        then less likely a MN will run into handoff situation

   How about thinking of an access network comprised of multiple MAPs at the
   same level serving a large geographical area and distributing the loads
   of MNs. Currently, when a MN moves from one MAP to another(in this scenario),
   we need to have MIPV6 type of mobility (or MIPV6 handoff). I wonder if
   it meets the cellular carrier's latency requirements ? If not, or some other
   non-technical business reason, access network does not want the MN to send
   BU to it's CN when it moves from one MAP (or LMM or GMA) to another, then
   it makes sense to develop some protocol to update the next LMM about the
   previous one and so on.
  
  But if multi-level hierarchy model seems to be inevitable in distant future,
   then how about making it  optional for the basic protocol
  and implementation and deployment of hierarchical mobility management.
  Sorry, I have not had chance to read all the emails on this thread.
  
  -Samita




From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 25 15:59:46 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 PAA29252
	for ; Wed, 25 Apr 2001 15:59: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 MAA03615;
	Wed, 25 Apr 2001 12:59: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 MAA16964;
	Wed, 25 Apr 2001 12:58:45 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PJumK9017563
	for ; Wed, 25 Apr 2001 12:56:48 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3PJumYs017562
	for mobile-ip-dist; Wed, 25 Apr 2001 12:56: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PJubK9017555
	for ; Wed, 25 Apr 2001 12:56:39 -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 MAA14903
	for ; Wed, 25 Apr 2001 12:56:32 -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 PAA09506
	for ; Wed, 25 Apr 2001 15:09:45 -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 MAA00574;
	Wed, 25 Apr 2001 12:56:20 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3PJuIp26926;
	Wed, 25 Apr 2001 12:56:18 -0700
X-mProtect:  Wed, 25 Apr 2001 12:56:18 -0700 Nokia Silicon Valley Messaging Protection
Received: from maxdialin25.iprg.nokia.com (205.226.20.219, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpd7IAnDy; Wed, 25 Apr 2001 12:56:11 PDT
Message-ID: <3AE72C1E.5888CD80@iprg.nokia.com>
Date: Wed, 25 Apr 2001 12:57:18 -0700
From: Charlie Perkins 
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Basavaraj.Patil@nokia.com
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: <7B5C0390ACE7D211BC9C0008C7EABA2B032138D7@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


Basavaraj.Patil@nokia.com wrote:

> What we do not want to see is another IN (Intelligent network) type of
> solution,
> and cram a lot of smarts about mobility and optimization in the network by
> introducing multiple levels of smart routers/agents. After all "the stupid
> network"
> does have it's merits :)
> There are enough compelling reasons to add one LMM agent, but more than
> one ....? Or let's put it this way, how many levels of hierarchy would be
> optimal?

One thing that the network is supposed to do is route packets.
Everything about this discussion has to do with routing packets.
Thus, comparison to IN is misleading at best.

There is no single answer for the number of levels of hierarchy.
My guess is that at least for now it will be no more than low single digit.
For some installations it will be one.  For some installations
it will be zero.

> So if we were to deploy this solution (since we agree that the issue is one
> of
> deployment) today, how would you propose changing existing routers in the
> operator's network which may have to become mobility aware? You could
> potentially
> add one more new router/LMM into the network quite easily as opposed to
> introducing new functionality into an operator's existing network and
> equipment.

This really misses the point.  No one is claiming that all installations would
have to have multiple levels of hierarchies.  I only claim that some will, and
that the ones that will want multiple levels will represent many millions (if
not billions) of mobile nodes, in the not-so-distant future.  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.



From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 25 16:07:01 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 QAA29494
	for ; Wed, 25 Apr 2001 16:07:00 -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 NAA06650;
	Wed, 25 Apr 2001 13:06: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 NAA18561;
	Wed, 25 Apr 2001 13:06:10 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PK4KK9017582
	for ; Wed, 25 Apr 2001 13:04:20 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3PK4Jbt017581
	for mobile-ip-dist; Wed, 25 Apr 2001 13:04: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PK45K9017574
	for ; Wed, 25 Apr 2001 13:04:06 -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 NAA18163
	for ; Wed, 25 Apr 2001 13:03:50 -0700 (PDT)
Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA09112
	for ; Wed, 25 Apr 2001 13:03:49 -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 PAA11709
	for ; Wed, 25 Apr 2001 15:03:49 -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 f3PK3tn11174
	for ; Wed, 25 Apr 2001 15:03:55 -0500 (CDT)
Message-ID: <3AE71F41.68D60611@usa.alcatel.com>
Date: Wed, 25 Apr 2001 15:02:25 -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] Hierarchy and Low Latency Handoff
References: <034BEFD03799D411A59F00508BDF7546013DBDA7@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

Hi Hesham,
  Bicasting is a special case of multicasting. Why not use multicasting from the MAP on
the downlink? In fact we have a draft on some thing like this for fast handoff.

"Hesham Soliman (ERA)" wrote:

>
>         => Correct. Karim and I are writing a draft (or copying parts
>         of the old draft !) on this. We don't believe the Fast Handoff
>         solution for v6 is complete without it (unlike the v4 low latency draft).
>         In fact the design team has agreed that this will be highlighted
>         in the draft. I haven't had a chance to review the last revision yet though.

--
Behcet




From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 25 16:13: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 QAA29733
	for ; Wed, 25 Apr 2001 16:13:09 -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 NAA09690;
	Wed, 25 Apr 2001 13:12: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 NAA15605;
	Wed, 25 Apr 2001 13:12:30 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PK9sK9017602
	for ; Wed, 25 Apr 2001 13:09:54 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3PK9sh4017601
	for mobile-ip-dist; Wed, 25 Apr 2001 13:09: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 jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged))
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PK9iK9017594
	for ; Wed, 25 Apr 2001 13:09:46 -0700 (PDT)
Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207])
	by jurassic.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with SMTP id f3PK9fiF236650;
	Wed, 25 Apr 2001 13:09:42 -0700 (PDT)
Message-Id: <200104252009.f3PK9fiF236650@jurassic.eng.sun.com>
Date: Wed, 25 Apr 2001 13:10:51 -0700 (PDT)
From: Samita Chakrabarti 
Subject: Re: [mobile-ip] Final(?) Cut on LMM Requirements
To: mobile-ip@sunroof.eng.sun.com, PRoberts@MEGISTO.com
Cc: samita@jurassic.Eng.Sun.COM
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: GEC5EXOZS3G4wAW8nu5Uyg==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 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: 


> Seems like we're converging apart from the multiple levels of hierarchy

> 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 am not  sure if the above requirement means that one LMM shall scale to
support millions of nodes. Or does it mean that LMM could be a cluster of
agent nodes distributing the loads among themselves ?

If LMM  means one node, then I would say 'million nodes' is a strong requirement
or it's inherently assuming multi-level hierarchy :)

I think we need to have a requirement for scalability or load distribution
among the hierarchical mobility agents.

> 8. LMM shall not require changes to the HA and the CNs.

> 

Is this requirement a "must"  or should ?  I agree that no changes
for CN, but are we sure that there can't be any change in HA also 
in the future ? I can't think of any example of the top my head right
now, but wonder, if that is a safe assumption in case we might need
some change in HA to support certain features in LMM (MAP or GMA).

Thanks,
-Samita



From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 25 16:18:17 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29880
	for ; Wed, 25 Apr 2001 16:18: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 NAA08120;
	Wed, 25 Apr 2001 13:17: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 NAA16641;
	Wed, 25 Apr 2001 13:17:12 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PKFEK9017623
	for ; Wed, 25 Apr 2001 13:15:14 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3PKFD7s017622
	for mobile-ip-dist; Wed, 25 Apr 2001 13:15: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PKF2K9017615
	for ; Wed, 25 Apr 2001 13:15: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 NAA27447;
	Wed, 25 Apr 2001 13:14:56 -0700 (PDT)
Message-Id: <200104252014.NAA27447@heliopolis.eng.sun.com>
Date: Wed, 25 Apr 2001 13:14:56 -0700 (PDT)
From: James Kempf 
Subject: Re: [mobile-ip] Final(?) Cut on LMM Requirements
To: mobile-ip@sunroof.eng.sun.com, PRoberts@MEGISTO.com
Cc: samita@jurassic.Eng.Sun.COM
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: dw96lTF4xPFaSq/Lc1W54g==
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: 

>
>> 8. LMM shall not require changes to the HA and the CNs.
>
>> 
>
>Is this requirement a "must"  or should ?  I agree that no changes
>for CN, but are we sure that there can't be any change in HA also 
>in the future ? I can't think of any example of the top my head right
>now, but wonder, if that is a safe assumption in case we might need
>some change in HA to support certain features in LMM (MAP or GMA).
>

IHMO, this requirement is a MUST. 

		jak



From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 25 16:26:32 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00136
	for ; Wed, 25 Apr 2001 16:26:31 -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 NAA13803;
	Wed, 25 Apr 2001 13: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 NAA20909;
	Wed, 25 Apr 2001 13:23:33 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PKLUK9017642
	for ; Wed, 25 Apr 2001 13:21:30 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3PKLTw5017641
	for mobile-ip-dist; Wed, 25 Apr 2001 13:21: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PKLJK9017634
	for ; Wed, 25 Apr 2001 13:21:21 -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 NAA21411
	for ; Wed, 25 Apr 2001 13:21:19 -0700 (PDT)
Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA16070
	for ; Wed, 25 Apr 2001 13:21:18 -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 PAA14483;
	Wed, 25 Apr 2001 15:21:16 -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 f3PKLMn15123;
	Wed, 25 Apr 2001 15:21:22 -0500 (CDT)
Message-ID: <3AE72357.436AC3D7@usa.alcatel.com>
Date: Wed, 25 Apr 2001 15:19:52 -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
CC: Basavaraj.Patil@nokia.com
Subject: Re: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised 
 Localized Mobility Management Requirement s)
References: <7B5C0390ACE7D211BC9C0008C7EABA2B032138D7@daeis07nok> <3AE72C1E.5888CD80@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 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



From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 25 16:37: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 QAA00422
	for ; Wed, 25 Apr 2001 16:37:55 -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 NAA20564;
	Wed, 25 Apr 2001 13:37:28 -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 NAA24619;
	Wed, 25 Apr 2001 13:37:14 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PKZiK9017677
	for ; Wed, 25 Apr 2001 13:35:44 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3PKZi8V017676
	for mobile-ip-dist; Wed, 25 Apr 2001 13:35: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PKZYK9017668
	for ; Wed, 25 Apr 2001 13:35: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 NAA24314
	for ; Wed, 25 Apr 2001 13:35:28 -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 NAA10665
	for ; Wed, 25 Apr 2001 13:35:27 -0700 (PDT)
Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21)
	id ; Wed, 25 Apr 2001 16:29:30 -0400
Message-ID: 
From: Phil Roberts 
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: Wed, 25 Apr 2001 16:29: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: 

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
> 


From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 25 16:55: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 QAA00885
	for ; Wed, 25 Apr 2001 16:55:20 -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 NAA28929;
	Wed, 25 Apr 2001 13:54: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 NAA27835;
	Wed, 25 Apr 2001 13:54:27 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PKquK9017704
	for ; Wed, 25 Apr 2001 13:52:56 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3PKquCv017703
	for mobile-ip-dist; Wed, 25 Apr 2001 13:52: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PKqSK9017696
	for ; Wed, 25 Apr 2001 13:52: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 NAA28613
	for ; Wed, 25 Apr 2001 13:52:27 -0700 (PDT)
Message-Id: <200104252052.NAA28613@heliopolis.eng.sun.com>
Date: Wed, 25 Apr 2001 13:52:27 -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
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: RXpr4Y/L7ea5ZBFCIh2AaA==
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 Phil,

OK, it is clearer. Comments below.

>I think I made this argument once in the MM design team about 6 months
>ago but I don't feel like digging through all the archives, so let me take
>another shot at it.
>
>The handoff destination LMM (if hosted in a router) is routable from the
>source LMM even if it is in a different subnet right?  So as far as CT (and
>setting up a temporary tunnel) why do I care about crossing a subnet
>boundary?  I already stated that the neighboring LMM hosts will "know"
>about each other so their security associations are ideally pre-configured
>thus contributing no additive latency (also the assumption is they have
>routes to each other - something I have called "sidehaul" in a prior life).
>Sidehaul does add overhead, but only while the "backhaul" pipe is
>re-pointing itself at the destination LMM.
>

Basically, the MN comes up, gets an IP address on the local subnet.
When the MN moves across a subnet boundary, rather than getting
a new CoA, the AR on the old subnet sets up a bidirectional tunnel
with the new AR to forward packets for that IP address, which does
not change. This goes on for some period of time until, presumably,
the tunnels get too stretched and the MN abandons the old IP address
and gets a new one (at which time it had better not have an open
TCP connection).

This sounds alot like the UTRAN Iur interface, and the abandonment
of the old IP address is alot like SRNS relocation, but I don't
think it is mobile IP. 

			jak
			
PS: I do kind of like it, though.




From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 25 17:41: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 RAA02078
	for ; Wed, 25 Apr 2001 17:41: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 OAA18947;
	Wed, 25 Apr 2001 14:41: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 OAA05000;
	Wed, 25 Apr 2001 14:39:29 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PLYJK9017756
	for ; Wed, 25 Apr 2001 14:34:19 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3PLYI86017755
	for mobile-ip-dist; Wed, 25 Apr 2001 14:34:18 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PLY8K9017748
	for ; Wed, 25 Apr 2001 14:34:10 -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 OAA06957
	for ; Wed, 25 Apr 2001 14:34:09 -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 OAA11462
	for ; Wed, 25 Apr 2001 14:34:07 -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 QAA25025
	for ; Wed, 25 Apr 2001 16:34:06 -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 f3PLYGo09175
	for ; Wed, 25 Apr 2001 16:34:16 -0500 (CDT)
Message-ID: <3AE7346A.728F6E3E@usa.alcatel.com>
Date: Wed, 25 Apr 2001 16:32:42 -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] Mobile IPv6 Home Agent product and best place?
References: <30F2DED23724D311902D0008C7EABAFB04630DAF@daeis06nok> <3AE6113B.7040704@eastelsystems.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 Jang, I think that your question was already answered by Francis, i.e. the
answer is your ISP or operating company will set up an HA and probably hardwire
it in 3GPP UE.
  The placement of mobility routers, e.g. MAPs of HMIP is a newer issue which is
not yet resolved.

Jang JaeIk wrote:

> Hi,
>
> It is 3GPP.
>
> marc.greis@nokia.com wrote:
>
> > Hi,
> >
> > Without trying to give a good answer to your question at this point, I'd
> > like to remind you that there are different "flavors" of "3G" (3GPP, 3GPP2,
> > different releases, etc.), so I'm sure you'll be more likely to get a
> > helpful answer to your question if you are a bit more specific about which
> > flavor of 3G you are referring to.
> >
> > Marc
> >
> >> -----Original Message-----
> >> From: ext Jang JaeIk [mailto:jijang@eastelsystems.com]
> >> Sent: 23 April, 2001 5:41 AM
> >> To: mobile-ip@sunroof.eng.sun.com
> >> Subject: [mobile-ip] Mobile IPv6 Home Agent product and best place?
> >>
> >>
> >> Hi all
> >>
> >> I questioned if there is any product(Home Agent) for
> >> supporting mobile IPv6.
> >> And in 3G network, where is the best place for HA?
> >>
> >> Thanks in advance.
> >>

--
Behcet



From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 25 20:23:56 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04621
	for ; Wed, 25 Apr 2001 20:23: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 RAA14836;
	Wed, 25 Apr 2001 17:23:35 -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 RAA09924;
	Wed, 25 Apr 2001 17:23:27 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3Q0MDK9017918
	for ; Wed, 25 Apr 2001 17:22:13 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3Q0MDjd017917
	for mobile-ip-dist; Wed, 25 Apr 2001 17:22: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3Q0M2K9017910
	for ; Wed, 25 Apr 2001 17:22:04 -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 RAA13477
	for ; Wed, 25 Apr 2001 17:22:03 -0700 (PDT)
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA13579
	for ; Wed, 25 Apr 2001 17:22:01 -0700 (PDT)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id KAA01512 for ; Thu, 26 Apr 2001 10:21:59 +1000 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
 via SMTP by mailo.vtcif.telstra.com.au, id smtpd0CGTuH; Thu Apr 26 10:21:23 2001
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id KAA03105 for ; Thu, 26 Apr 2001 10:21:21 +1000 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
 via SMTP by localhost, id smtpd.Fu0j_; Thu Apr 26 10:20:54 2001
Received: from ntmsg0028.corpmail.telstra.com.au (ntmsg0028.corpmail.telstra.com.au [192.168.174.24]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id KAA20646 for ; Thu, 26 Apr 2001 10:20:54 +1000 (EST)
Received: by ntmsg0028.corpmail.telstra.com.au with Internet Mail Service (5.5.2650.21)
	id ; Thu, 26 Apr 2001 10:20:19 +1000
Message-ID: <73388857A695D31197EF00508B08F29801908CBC@ntmsg0131.corpmail.telstra.com.au>
From: "Venning, Roger" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L
	ocalized Mobility Management Requirements)
Date: Thu, 26 Apr 2001 10:20:13 +1000
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 concur with Andrew (and thus with Jim & Theo).
There are a wealth of possibilities that may arise in
the QOS etc. control area if signalling explicitly interacts
with LMM entities that approximately mirror the structure
of network topology.

Many deployment situations will want to use multi-level
hierarchical topologies, and thus having multi-level
hierarchies available in LMM is advantageous.

(BTW. International travel is quick, but not so quick that
we need to avoid non-LMM managed handoffs when traveling
internationally... ie. no need for inter-continental BU)

Roger.

PS. is it just me, or do other people suffer from subject
lines having inserted spaces, and thus breaking threading
logic in their mail client?

--
Roger Venning - Technologist - Telstra Research Laboratories

          For a successful technology, reality must take
          precendence over public relations, for Nature
          cannot be fooled.                 Richard Feynman


> -----Original Message-----
> From: Andrew T. Campbell [mailto:campbell@comet.columbia.edu]
> Sent: Wednesday, 25 April 2001 1:46 PM
> 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)
> 
> 
> I think we need the edge hierarchies (not necessarily trees like
> Cellular IP/ HMIP which aren't robust) to hold the per-host
> routing states to deliver IP micro-mobility (QOS, etc.) to mobile
> hosts. Could be a mesh or tree. Could be deep.
> 
> Its the infrastructure to implement the IP control plane for 
> mobile networks
> 
> ---
> Andrew
> http://comet.columbia.edu/~campbell
> 
> 
> > -----Original Message-----
> > From: owner-mobile-ip@sunroof.eng.sun.com
> > [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of 
> Phil Roberts
> > Sent: Tuesday, April 24, 2001 2:59 PM
> > 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)
> >
> >
> > How to proceed?  Good question.  It would be really good if
> > some other folks
> > weighed in on the issue.  Does anyone who hasn't commented on
> > this so far
> > care to add anything?  care at all?
> >
> > Phil
> >
> >
> > > -----Original Message-----
> > > From: James Kempf [mailto:James.Kempf@Sun.COM]
> > > Sent: Tuesday, April 24, 2001 5:47 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
> > > L ocalized Mobility Management Requirement s)
> > >
> > >
> > > Hi Hesham,
> > >
> > > Thanx for your response, but I think we've been through these
> > > points a number of times, we really don't need to rehash them
> > > again. Charlie,
> > > Theo, myself, and one other person (whose name I've
> > > forgotten) have spoken up
> > > for a requirement to support hierarchy. You and Karim have
> > > spoken up against it,
> > > and Raj, expressing a preference for simplicity, has an 
> inclination
> > > against it.
> > >
> > > Anybody else out there in SMTP-land want to express a preference?
> > >
> > > Phil, any ideas about how to proceed?
> > >
> > > 		jak
> > >
> > >
> > > >From: "Hesham Soliman  (ERA)" 
> > > >To: "'mobile-ip@sunroof.eng.sun.com'"
> > 
> > > >Cc: Basavaraj.Patil@nokia.com
> > > >Subject: RE: Multiple Levels of LMM agents (was: RE:
> > > [mobile-ip] Revised L
> > > ocalized Mobility Management Requirement s)
> > > >Date: Tue, 24 Apr 2001 23:34:56 +0200
> > > >
> > > >
> > > >> Actually, no. I'm saying that we have had at least three
> > people who
> > > >> have given good arguments, IMHO, as to why multiple levels of
> > > >> hierarchy might be needed. On the other side, those arguments
> > > >> are refuted by two people who think that no hierarchy 
> is needed.
> > > >> Neither side is going to convince the other, both sides have
> > > >> good arguments.
> > > >>
> > > >	=> I'm not sure who you mean by the "two" people, there
> > > is definitely
> > > >	more (at least the authors of HMIP are) but anyway
> > > >	after reading the discussion it really seems to me like
> > > the only
> > > >	two (understandable IMHO) reasons are:
> > > >
> > > >	1.  In future there may be a need for multi-level
> > > hierarchy. That need
> > > >	is not explained really. To me this is not a good
> > > reason for including
> > > >	any feature. Ithink it makes a lot of sense of scope
> > > the problem to
> > > >	what we know without "guessing" what might happen in future
> > > >	and how theuse of MIP can be changed dramatically. No one
> > > >	knows that this is true.
> > > >
> > > >	2. Multi-level hierarchy localises the signalling. Let's try to
> > > understand
> > > >	what this really means. A MAP domain is as large as the amount
> > > >	of traffic that a MAP can handle, regardless of the number of
> > > >	levels of hierarchy. The signalling will always be local to that
> > > >	domain. So I'm not really clear on the significant
> > > advantage here.
> > > >	We're certainly not expecting any inter-continental mobility
> > > >	management using HMIPv6. So careful placement of the MAP
> > > >	using network engineering skills and common sense is
> > > >	sufficient.
> > > >
> > > >> What I'm saying is that we have some arguments the feature
> > > is needed,
> > > >> so let's put it in. From Karim's last email, it sounds
> > like we can
> > > >> probably accommodate his concerns about multiplying
> > > failure possibilities.
> > > >>
> > > >	=> At a cost. The beneft MUST outweigh the cost. This is not
> > > >	the case here IMO.
> > > >
> > > >> If we don't put it in and deployment proves that we need it,
> > > >>
> > > >	=> This is exactly point one above.
> > > >
> > > >	Hesham
> > >
> >
> >
> 


From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 25 22:04:01 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 WAA06824
	for ; Wed, 25 Apr 2001 22:04:00 -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 TAA09602;
	Wed, 25 Apr 2001 19:03: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 TAA23829;
	Wed, 25 Apr 2001 19:03:24 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3Q21wK9018038
	for ; Wed, 25 Apr 2001 19:01:58 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3Q21vH2018037
	for mobile-ip-dist; Wed, 25 Apr 2001 19:01: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3Q21hK9018030
	for ; Wed, 25 Apr 2001 19:01:44 -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 TAA28478
	for ; Wed, 25 Apr 2001 19:01:43 -0700 (PDT)
Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id VAA09971
	for ; Wed, 25 Apr 2001 21:17:30 -0600 (MDT)
Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM)
	id AA25219; Wed, 25 Apr 2001 22:01:38 -0400
Date: Wed, 25 Apr 2001 22:01:37 -0400 (EDT)
From: Jim Bound 
To: mobile-ip@sunroof.eng.sun.com
Cc: PRoberts@MEGISTO.com, samita@jurassic.Eng.Sun.COM
Subject: Re: [mobile-ip] Final(?) Cut on LMM Requirements
In-Reply-To: <200104252014.NAA27447@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: 

> >
> >> 8. LMM shall not require changes to the HA and the CNs.
> >
> >> 
> >
> >Is this requirement a "must"  or should ?  I agree that no changes
> >for CN, but are we sure that there can't be any change in HA also 
> >in the future ? I can't think of any example of the top my head right
> >now, but wonder, if that is a safe assumption in case we might need
> >some change in HA to support certain features in LMM (MAP or GMA).
> >
> 
> IHMO, this requirement is a MUST. 
> 
> 		jak

  IHMO, this requirement is a MUST too.

/jim



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 03:42:50 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA25590
	for ; Thu, 26 Apr 2001 03:42:50 -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 AAA05164;
	Thu, 26 Apr 2001 00:41:18 -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 AAA23633;
	Thu, 26 Apr 2001 00:39:50 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3Q7c7K9018395
	for ; Thu, 26 Apr 2001 00:38:08 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3Q7bvvD018394
	for mobile-ip-dist; Thu, 26 Apr 2001 00:37: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3Q7bVK9018387
	for ; Thu, 26 Apr 2001 00:37:39 -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 AAA06528
	for ; Thu, 26 Apr 2001 00:36:54 -0700 (PDT)
Received: from taku.hut.fi (taku.hut.fi [130.233.228.87])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA03133
	for ; Thu, 26 Apr 2001 00:36:53 -0700 (PDT)
Received: from gamma.hut.fi (tweckstr@gamma.hut.fi [130.233.224.52])
	by taku.hut.fi (8.9.3/8.9.3) with ESMTP id KAA23195
	for ; Thu, 26 Apr 2001 10:36:52 +0300 (EET DST)
Date: Thu, 26 Apr 2001 10:36:50 +0300 (EET DST)
From: =?ISO-8859-1?Q?Tom_Weckstr=F6m?= 
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: <034BEFD03799D411A59F00508BDF7546013DBDA5@esealnt448.al.sw.ericsson.se>
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 AAA05164
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA25590

On Wed, 25 Apr 2001, Hesham Soliman  (ERA) wrote:

Hesham >>  The 
Hesham >> primary argument for hierarchy is that you can have a lower level LMM
Hesham >> agent that is close to the mobile node with which the mobile node does
Hesham >> a short leg BU when changing CoA, but the global CoA remains the 
Hesham >> same. 
Hesham >> 
Hesham >	=> So the main gain here if I understand you correctly is that
Hesham >	you get a "quicker" update of the routing tables. 
Hesham >	In a wireless system where forwarding delays on the wire are 
Hesham >	completely insgnificant compared to the delays over the air,,
Hesham >	I don't see a significant value adding here. We can easily illustrate
Hesham >	this with some well known numbers. 
Hesham >	Unless you see other gains that I couldn't interpret..
Hesham >
Hesham >	Hesham 
Hesham >

Hesham, you just admitted that we get a faster routing table update with
multilevel hierarchy. There is little to argue against this clear benefit.
This benefit, in the end, results in *better scalability* as Theo and
others have already said.

Regards,
-- 
	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 Apr 26 03: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 DAA25766
	for ; Thu, 26 Apr 2001 03:50: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 AAA07675;
	Thu, 26 Apr 2001 00:47:28 -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 AAA27757;
	Thu, 26 Apr 2001 00:47:18 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3Q7jEK9018445
	for ; Thu, 26 Apr 2001 00:45:14 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3Q7j8bt018444
	for mobile-ip-dist; Thu, 26 Apr 2001 00:45: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3Q7irK9018437
	for ; Thu, 26 Apr 2001 00:44: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 AAA16436
	for ; Thu, 26 Apr 2001 00:44:54 -0700 (PDT)
Received: from taku.hut.fi (taku.hut.fi [130.233.228.87])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA07014
	for ; Thu, 26 Apr 2001 03:02:12 -0600 (MDT)
Received: from gamma.hut.fi (tweckstr@gamma.hut.fi [130.233.224.52])
	by taku.hut.fi (8.9.3/8.9.3) with ESMTP id KAA28577;
	Thu, 26 Apr 2001 10:44:51 +0300 (EET DST)
Date: Thu, 26 Apr 2001 10:44:50 +0300 (EET DST)
From: =?ISO-8859-1?Q?Tom_Weckstr=F6m?= 
To: "'mobile-ip@sunroof.eng.sun.com'" 
cc: 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: <034BEFD03799D411A59F00508BDF7546013DBDA9@esealnt448.al.sw.ericsson.se>
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 mercury.Sun.COM id AAA07675
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA25766

Hello,

On Wed, 25 Apr 2001, Hesham Soliman  (ERA) wrote:

Hesham >Hello Theo,

Hesham >> The size of the domain is something that is not cast in stone. It is expressed as the
Hesham >> growth in network infrastructure that maps to an individual ISP. The world expects
Hesham >> that ISPs will grow larger in that sense by populating the routing fabring with more
Hesham >> and more routing elements...
Hesham >> 
Hesham >	=> The size of a LMM domain (or MAP domain or GMA domain) is 
Hesham >	restricted to how much traffic the top LMM agent can handle.
Hesham >	This is orthogonal to how big an ISP is. There is no need 
Hesham >	to assume that an ISP domain = LMM domain. Actually for a
Hesham >	very large ISP this is probably not possible.
Hesham >
Hesham >> yes you "guessed" right....SCALABILITY...
Hesham >> 
Hesham >	=> Could you explain scalability of what ?
Hesham >	It's certainly not the scalability of the amount of state
Hesham >	kept in the routers.
Hesham >
Hesham >	Hesham

As I have experienced the scalability benefit of the LMM, it will allow
scalability in the number of MNs moving within the domain through the
reduced signaling.

BR,
-- 
	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 Apr 26 05:09:09 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA26561
	for ; Thu, 26 Apr 2001 05:09: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 CAA16538;
	Thu, 26 Apr 2001 02:08: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 CAA04452;
	Thu, 26 Apr 2001 02:08:34 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3Q97NK9018556
	for ; Thu, 26 Apr 2001 02:07:23 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3Q97MUk018555
	for mobile-ip-dist; Thu, 26 Apr 2001 02:07: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 bebop.france (bebop.France.Sun.COM [129.157.174.15] (may be forged))
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3Q974K9018548
	for ; Thu, 26 Apr 2001 02:07:09 -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 LAA11141;
	Thu, 26 Apr 2001 11:06:54 +0200 (MET DST)
Date: Thu, 26 Apr 2001 02:06:55 -0700 (PDT)
From: Erik Nordmark 
Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L  ocalized Mobility Management Requirement s)
To: James Kempf 
Cc: Erik.Nordmark@eng.sun.com, mobile-ip@sunroof.eng.sun.com,
        Basavaraj.Patil@nokia.com
In-Reply-To: "Your message with ID" <200104251657.JAA22528@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: 

> All that we're asking for is that the requirements state that the
> solution SHOULD (not MUST) support multiple levels of LMM agents.
> The reason is so that if a network operator has a deployment situation
> where the signalling lines get long, they can deploy an upper level
> agent to keep the external CoA fixed.

I still don't have a picture that tells me what you gain.
I assume keeping the external COA fixed is not a goal in itself - the
goal is just better performance (less signalling over long paths).

So if the signalling lines (e.g. between different metropolitan areas,
different small countries, or different topological clouds that don't follow
any geographic notion like metro or country) are long then you can just have
one LMM per such cloud without any hierarchy.
Thus movement between clouds cause the home agent and 
correspondents to be updated.

In this case when a mobile moves within the cloud (e.g. one metro)
there is only local signalling, and the movement between clouds 
the boundaries between the clouds in the operator's network have
been designed so that the movement between them is infrequent.

When would you need another level of hierarchy?

Or stated differently, if you place the LMMs so that the latency over the
wired part of the network between the MNs and their LMM is on the order
of 10 ms, and let the HA then it seems like for it to make sense to have 
another level of hierachy below it that level should be two orders of magnitude
of delay less i.e. on the order of .1 ms. Thus speed of light in copper/glass
would limit that to 20-30km in size. Sure, you could argue that you need an
additional level for each factor 3 or 10 in the latency domain, but my
personal gut feel is that in such a case you are adding complexity for little
performance gain, especially given that any signalling involving the MN will
add on the order of 50 ms of delay due to the coding necessary to deal with
the fading.

   Erik



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 10:14:33 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04718
	for ; Thu, 26 Apr 2001 10:14:32 -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 HAA20935;
	Thu, 26 Apr 2001 07:13:50 -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 HAA26427;
	Thu, 26 Apr 2001 07:13:43 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QEBxK9018839
	for ; Thu, 26 Apr 2001 07:11:59 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QEBwFv018838
	for mobile-ip-dist; Thu, 26 Apr 2001 07:11: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QEBgK9018831
	for ; Thu, 26 Apr 2001 07:11:49 -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 HAA10395
	for ; Thu, 26 Apr 2001 07:11:42 -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 HAA19535
	for ; Thu, 26 Apr 2001 07:11:41 -0700 (PDT)
Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id KAA21902; Thu, 26 Apr 2001 10:11:38 -0400
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Thu, 26 Apr 2001 10:11:28 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Thu, 26 Apr 2001 10:11:30 -0400
Message-ID: 
From: "Muhammad Jaseemuddin" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Final(?) Cut on LMM Requirements
Date: Thu, 26 Apr 2001 10:11:27 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0CE5A.C8C954B0"
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_01C0CE5A.C8C954B0
Content-Type: text/plain



> -----Original Message-----
> From:	James Kempf [SMTP:James.Kempf@Sun.COM]
> Sent:	Wednesday, April 25, 2001 4:15 PM
> To:	mobile-ip@sunroof.eng.sun.com; PRoberts@MEGISTO.com
> Cc:	samita@jurassic.Eng.Sun.COM
> Subject:	Re: [mobile-ip] Final(?) Cut on LMM Requirements
> 
> >
> >> 8. LMM shall not require changes to the HA and the CNs.
> >
> >> 
> >
> >Is this requirement a "must"  or should ?  I agree that no changes
> >for CN, but are we sure that there can't be any change in HA also 
> >in the future ? I can't think of any example of the top my head right
> >now, but wonder, if that is a safe assumption in case we might need
> >some change in HA to support certain features in LMM (MAP or GMA).
> >
> 
> IHMO, this requirement is a MUST. 
> 
> 		jak
> 
	[MJ]  I also think that this requirement is a MUST. LMM is a
solution deployed most likely in an access network, which should not have
any global implication. As a matter of fact in my view this should even be
transparent to MNs. What LMM is supposed to do is to do mobility aware
routing within the domain. It should be decoupled from signaling. Mobile IP
and fast handover should be the two signaling a MN should be aware of and
deal with. Former is for gloabl mobility and the later for local mobility.
End nodes should not dictate which routing solution is deployed within the
network.  This is just my 0.02 cents view. There is no need to discuss
involving MN thread again I guess it was discussed previously.

	- Muhammad Jaseemuddin

------_=_NextPart_001_01C0CE5A.C8C954B0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: [mobile-ip] Final(?) Cut on LMM Requirements







    

    -----Original Message-----

    From:   James Kempf [SMTP:James.Kempf@Sun.COM]

    Sent:   Wednesday, April 25, 2001 4:15 PM

    To:     mobile-ip@sunroof.eng.sun.com; =
PRoberts@MEGISTO.com

    Cc:     samita@jurassic.Eng.Sun.COM

    Subject:       =
 Re: [mobile-ip] Final(?) Cut on LMM =
Requirements

    


    >

    >> 8. LMM shall not require =
changes to the HA and the CNs.

    >

    >> 

    >

    >Is this requirement a =
"must"  or should ?  I agree that no changes

    >for CN, but are we sure that =
there can't be any change in HA also 

    >in the future ? I can't think of =
any example of the top my head right

    >now, but wonder, if that is a =
safe assumption in case we might need

    >some change in HA to support =
certain features in LMM (MAP or GMA).

    >

    


    IHMO, this requirement is a MUST. =


    


            =
        jak

    


    [MJ]  I also think that this requirement is a MUST. =
LMM is a solution deployed most likely in an access network, which =
should not have any global implication. As a matter of fact in my view =
this should even be transparent to MNs. What LMM is supposed to do is =
to do mobility aware routing within the domain. It should be decoupled =
from signaling. Mobile IP and fast handover should be the two signaling =
a MN should be aware of and deal with. Former is for gloabl mobility =
and the later for local mobility. End nodes should not dictate which =
routing solution is deployed within the network.  This is just my =
0.02 cents view. There is no need to discuss involving MN thread again =
I guess it was discussed previously.
    


    - Muhammad =
Jaseemuddin

    




------_=_NextPart_001_01C0CE5A.C8C954B0--


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 10:29:13 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05345
	for ; Thu, 26 Apr 2001 10:29:13 -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 HAA02179;
	Thu, 26 Apr 2001 07:28: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 HAA05117;
	Thu, 26 Apr 2001 07:28:37 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QER9K9018870
	for ; Thu, 26 Apr 2001 07:27:09 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QER9uf018869
	for mobile-ip-dist; Thu, 26 Apr 2001 07: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QEQwK9018862
	for ; Thu, 26 Apr 2001 07:27: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 HAA27803
	for ; Thu, 26 Apr 2001 07:26:58 -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 HAA08231
	for ; Thu, 26 Apr 2001 07:26:53 -0700 (PDT)
Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id KAA23781; Thu, 26 Apr 2001 10:26:33 -0400
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Thu, 26 Apr 2001 10:26:15 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Thu, 26 Apr 2001 10:26:17 -0400
Message-ID: 
From: "Muhammad Jaseemuddin" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Final(?) Cut on LMM Requirements
Date: Thu, 26 Apr 2001 10:26:13 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0CE5C.D8E6EEA0"
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_01C0CE5C.D8E6EEA0
Content-Type: text/plain

Phil:

> -----Original Message-----
> From:	Phil Roberts [SMTP:PRoberts@MEGISTO.com]
> Sent:	Wednesday, April 25, 2001 10:37 AM
> To:	'mobile-ip@sunroof.eng.sun.com'
> 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.)
> 2. LMM shall be secure from malicious behavior.
> 3. Connectivity to the mobiles should be minimized (MUST) or eliminated
> (strive for this) in the presence of failure of LMM agents.
> (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.)
> 4. LMM shall be compatible with fast handoffs.
	[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?

> 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)
> 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))
> 8. LMM shall not require changes to the HA and the CNs.
> 9. LMM should provide the same level of mobility management support as in
> the basic MIPv6 spec.
> 10. LMM should support autoconfig.
> 
> Unless there is some strong objection to these they will be requirements.
> We may or may not add one on multiple levels of hierarchy depending on the
> other discussion.
> 
> Phil
> 
	- Muhammad Jaseemuddin

------_=_NextPart_001_01C0CE5C.D8E6EEA0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: [mobile-ip] Final(?) Cut on LMM Requirements




Phil:



    

    -----Original Message-----

    From:   Phil Roberts [SMTP:PRoberts@MEGISTO.com]

    Sent:   Wednesday, April 25, 2001 10:37 AM

    To:     'mobile-ip@sunroof.eng.sun.com'

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

    2. LMM shall be secure from malicious =
behavior.

    3. Connectivity to the mobiles should =
be minimized (MUST) or eliminated

    (strive for this) in the presence of =
failure of LMM agents.

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

    4. LMM shall be compatible with fast =
handoffs.

    [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?
    


    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)

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

    8. LMM shall not require changes to =
the HA and the CNs.

    9. LMM should provide the same level =
of mobility management support as in

    the basic MIPv6 spec.

    10. LMM should support =
autoconfig.

    


    Unless there is some strong objection =
to these they will be requirements.

    We may or may not add one on multiple =
levels of hierarchy depending on the

    other discussion.

    


    Phil

    


    - Muhammad =
Jaseemuddin

    




------_=_NextPart_001_01C0CE5C.D8E6EEA0--


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 10:31:39 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 KAA05507
	for ; Thu, 26 Apr 2001 10:31:38 -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 HAA03737;
	Thu, 26 Apr 2001 07:30: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 HAA05394;
	Thu, 26 Apr 2001 07:30:16 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QESXK9018880
	for ; Thu, 26 Apr 2001 07:28:33 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QESXwY018879
	for mobile-ip-dist; Thu, 26 Apr 2001 07:28: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 bebop.france (bebop.France.Sun.COM [129.157.174.15] (may be forged))
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QESKK9018872
	for ; Thu, 26 Apr 2001 07:28: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 QAA10707;
	Thu, 26 Apr 2001 16:28:18 +0200 (MET DST)
Date: Thu, 26 Apr 2001 07:28:18 -0700 (PDT)
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: Basavaraj.Patil@nokia.com
In-Reply-To: "Your message with ID" <3AE5FAC6.6E713BC3@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: 

> Hello Hesham,
> 
> Not sure that you have read  either my previous postings and of course
> underlying reasoning on this topic.
> 
> I will just reiterate what the constituency has spoken here and say that we
> (and speaking also for myself, I) have elaborated on the topic as concretely
> as possible..
> 
> You may feel that you do not _understand_ the reasons (once more)...the rest
> of the constituency _has_. To that people have either agreed or disagreed or
> expressed reservations. You, _simply_ don't understand it... QED..

Count me in for an other person who fails to understand the arguments.

Perhaps my lack of understanding has to do with the following:
With LMM we are fundamentally talking about optimizations - mobile IP
without LMM works in the sense that packets move - we just want to optimize
the amount of signalling traffic as well as the time it takes to
update the mobility agents when the MN moves.

Since this is an ENGINEERING organization I'd expect an argument for
"do it this way because it is more optimal" would actually contain some
engineering: example topologies, numbers showing signalling volume and
signaling latency with and without an hierarchy.
I frankly haven't seen any engineering rigor in any arguments for or against
a hierarchy. (Thesis topic anyone?)

Instead we are operating in a mode where some folks (including me)
arguing that without hierarchy things are simpler and others arguing that
hirarachy is more general and flexible.
Neither argument has anything to do with ENGINEERING.

   Erik



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 10:42: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 KAA05999
	for ; Thu, 26 Apr 2001 10:42: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 HAA07584;
	Thu, 26 Apr 2001 07:39:23 -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 HAA14172;
	Thu, 26 Apr 2001 07:38:48 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QEb4K9018940
	for ; Thu, 26 Apr 2001 07:37:04 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QEb3Ih018939
	for mobile-ip-dist; Thu, 26 Apr 2001 07:37: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 bebop.france (bebop.France.Sun.COM [129.157.174.15] (may be forged))
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QEamK9018929
	for ; Thu, 26 Apr 2001 07:36:48 -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 QAA12374;
	Thu, 26 Apr 2001 16:36:46 +0200 (MET DST)
Date: Thu, 26 Apr 2001 07:36:46 -0700 (PDT)
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: James Kempf ,
        "Basavaraj.Patil" 
In-Reply-To: "Your message with ID" <3AE608C0.2E36B7F9@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: 

Theo,

> I must say that this is far from truth... by the moment you have the notion
> of "next possible candates" you have already established a hierarchy
> structure of "previous -> next"

Now I'm really confused.
I've been assuming that the hierarchy that we've been discussing is
common for a number of MNs (perhaps all) in some particular part of
the network.

But your previous->next relationship is a function of the individual movement
patterns of a particular MN thus it might be different for all MNs (at least
if you track enough of their history using a chain of prev->next
relationships).

That sounds like the "update the previous FA" scheme in MIPv4 which
doesn't look like a (shared) hierarchy at all.

   Erik



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 10:44:00 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06121
	for ; Thu, 26 Apr 2001 10:43:59 -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 HAA13220;
	Thu, 26 Apr 2001 07:42: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 HAA02347;
	Thu, 26 Apr 2001 07:42:47 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QEfcK9018970
	for ; Thu, 26 Apr 2001 07:41:38 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QEfcqu018969
	for mobile-ip-dist; Thu, 26 Apr 2001 07:41: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 bebop.france (bebop.France.Sun.COM [129.157.174.15] (may be forged))
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QEfSK9018962
	for ; Thu, 26 Apr 2001 07:41:29 -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 QAA13008
	for ; Thu, 26 Apr 2001 16:41:27 +0200 (MET DST)
Date: Thu, 26 Apr 2001 07:41:27 -0700 (PDT)
From: Erik Nordmark 
Subject: RE: [mobile-ip] Hierarchy and Low Latency Handoff
To: mobile-ip@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <200104242337.QAA09888@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,

> Not quite. I did a little experiment at IETF50 to see what signalling
> delays would be for an intercontinental BU - about 160 ms RTT to Japan
> and Europe. That is over half the RTT delay recommended by the ITU
> before human perception notices a gap. I think transcontinental
> times would be maybe half of this. 
> 
> If the network operator cannot deploy a hierarchy of LMM agents,
> they may not be able to counter.

Why not. Each operator could solve the above by having an LMM agent
per continent. Or they could be more fine grain and have one per metropolitan
area.
I don't see what benefits you could derive (and what the numbers would be
in terms of signalling traffic volume and signalling delay) by an
operator having e.g. both continent level LMMs as well as metro-area LMMs.
 
  Erik



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 10:47:54 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 KAA06270
	for ; Thu, 26 Apr 2001 10:47:54 -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 HAA10724;
	Thu, 26 Apr 2001 07:45: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 HAA07099;
	Thu, 26 Apr 2001 07:43:47 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QEgYK9018985
	for ; Thu, 26 Apr 2001 07:42:35 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QEgYeB018984
	for mobile-ip-dist; Thu, 26 Apr 2001 07:42:34 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QEgNK9018975
	for ; Thu, 26 Apr 2001 07:42:23 -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 HAA06904
	for ; Thu, 26 Apr 2001 07:42:23 -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 HAA11874
	for ; Thu, 26 Apr 2001 07:42:22 -0700 (PDT)
Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21)
	id ; Thu, 26 Apr 2001 10:36:24 -0400
Message-ID: 
From: Phil Roberts 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Final(?) Cut on LMM Requirements
Date: Thu, 26 Apr 2001 10:36:18 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0CE5E.44A7CB0E"
Sender: owner-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_01C0CE5E.44A7CB0E
Content-Type: text/plain;
	charset="iso-8859-1"

 


4. LMM shall be compatible with fast handoffs. 
[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?

	- Muhammad Jaseemuddin 
[Phil Roberts] 

	I didn't see any response to your post.  Personally speaking I
really don't want these two proposals coupled in any way.  It makes sense to
make sure they are compatible (you can use them at the same time) but it
does not make sense that they should have dependencies on each other.  It
seems reasonable to me that some networks with fast handover enabled will
see little if any need for LMM support. 


------_=_NextPart_001_01C0CE5E.44A7CB0E
Content-Type: text/html;
	charset="iso-8859-1"




RE: [mobile-ip] Final(?) Cut on LMM Requirements




 



  

4. LMM shall be compatible with fast 
  handoffs. 
[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?

  
    
    
    - Muhammad 
    Jaseemuddin 
    [Phil Roberts] 
    
    
    I 
    didn't see any response to your post.  Personally speaking I really 
    don't want these two proposals coupled in any way.  It makes sense 
    to make sure they are compatible (you can use them at the same time) but it 
    does not make sense that they should have dependencies on each 
    other.  It seems reasonable to me that some networks 
    with fast handover enabled will see little if any need for LMM 
    support. 


------_=_NextPart_001_01C0CE5E.44A7CB0E--


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 11:37:36 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08665
	for ; Thu, 26 Apr 2001 11:37:36 -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 IAA00870;
	Thu, 26 Apr 2001 08:37:08 -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 IAA11296;
	Thu, 26 Apr 2001 08:36:45 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QFZUK9019186
	for ; Thu, 26 Apr 2001 08:35:30 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QFZTgK019185
	for mobile-ip-dist; Thu, 26 Apr 2001 08:35: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QFZHK9019178
	for ; Thu, 26 Apr 2001 08:35: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 IAA15139
	for ; Thu, 26 Apr 2001 08:35:17 -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 IAA08154
	for ; Thu, 26 Apr 2001 08:35: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 IAA00714
	for ; Thu, 26 Apr 2001 08:35:17 -0700 (PDT)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3QFZFJ08618
	for ; Thu, 26 Apr 2001 08:35:15 -0700
X-mProtect:  Thu, 26 Apr 2001 08:35: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(WTS.12.69) smtpd0jEHhr; Thu, 26 Apr 2001 08:35:10 PDT
Message-ID: <3AE8402F.7AEF1C7E@iprg.nokia.com>
Date: Thu, 26 Apr 2001 08:35:11 -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

Erik Nordmark wrote:

> > Hello Hesham,
> >
> > Not sure that you have read  either my previous postings and of course
> > underlying reasoning on this topic.
> >
> > I will just reiterate what the constituency has spoken here and say that we
> > (and speaking also for myself, I) have elaborated on the topic as concretely
> > as possible..
> >
> > You may feel that you do not _understand_ the reasons (once more)...the rest
> > of the constituency _has_. To that people have either agreed or disagreed or
> > expressed reservations. You, _simply_ don't understand it... QED..
>
> Count me in for an other person who fails to understand the arguments.
>
> Perhaps my lack of understanding has to do with the following:
> With LMM we are fundamentally talking about optimizations - mobile IP
> without LMM works in the sense that packets move - we just want to optimize
> the amount of signalling traffic as well as the time it takes to
> update the mobility agents when the MN moves.
>
> Since this is an ENGINEERING organization I'd expect an argument for
> "do it this way because it is more optimal" would actually contain some
> engineering: example topologies, numbers showing signalling volume and
> signaling latency with and without an hierarchy.
> I frankly haven't seen any engineering rigor in any arguments for or against
> a hierarchy. (Thesis topic anyone?)
>
> Instead we are operating in a mode where some folks (including me)
> arguing that without hierarchy things are simpler and others arguing that
> hirarachy is more general and flexible.
> Neither argument has anything to do with ENGINEERING.
>
>    Erik

Hi Erik,

   if you see the thread of my previous postings, you will see that I am indeed
talking about optimizations. in terms of signalling and positioning of the LMM
over an LMM hierarchy if such exists.

In particular from previous posting...

   "What you want is to have the LMM in an optimal position for _both_ :

    1) low signalling
     2) reduction in transiting between LMM agents (that is the core ones like
GMA/MAP/fooGMA/fooMAP/ blah blah..)

otherwise one advantage will just kill the other and at the end you will be
pseudo-LMMing the MN..which is what
else...core MIPv6...  blah blah blah"


If this does not elaborate on optimization then what does it?????



I have also argued about multiple needs for this LMM hierarchy, such as
resiliency to failures. Please tell me how would you expect to recover from a
failure of an LMM if you do not know where it lies with relation to its
neighbours..how are these connected? Does it look like a hierarchy to you? When I
am saying hierarchy I mean would the packet go through one LMM before reaching
the one that just failed...The hierarchy argued here can be used for a
multiplicity of purposes

Both schemes are pushing everything in the autoconfiguration...can you envisage
how you are going to autoconfigure the LMM scheme...with a hierarchy I CAN....and
IMHO I cannot see much else..even if you rename it with a different term...

As for the rigour that you suggested...it is as rigorous as the
counterarguments...but I think I have much more reasons that are compelling such
as resiliency AND autoconfig of the LMM.

What I am saying is that you will use it when it comes to resiliency and
autoconfig, but you want like to admit it..

Populating the admin domain with more LMM-aware routers will also require
repositioning of the LMM...what are you going to do then...move it by hand...and
MOST importantly WHERE???
The WHERE word is all about the optimization implied by an LMM hierarchy...

BTW if we want to take drafts and proposals strictly by  rigour of numbers (soon
to come though..stay tuned..) we would need to scrap quite a few proposals here
in IETF, with all due respect of course...I haven't seen that many figures in
drafts...supporting their engineering benefit..in fact it is  more research that
gives the figures and engineering goes out and implements it...because it
"works"...am I wrong here???


Theo


UCL/ Mobile Systems







From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 11:50: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 LAA09163
	for ; Thu, 26 Apr 2001 11:50:16 -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 IAA04681;
	Thu, 26 Apr 2001 08:41: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 IAA15494;
	Thu, 26 Apr 2001 08:37:49 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QFaVK9019196
	for ; Thu, 26 Apr 2001 08:36:31 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QFaVEb019195
	for mobile-ip-dist; Thu, 26 Apr 2001 08:36: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QFaKK9019188
	for ; Thu, 26 Apr 2001 08:36:20 -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 IAA15274
	for ; Thu, 26 Apr 2001 08:36:19 -0700 (PDT)
Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA01133
	for ; Thu, 26 Apr 2001 10:54:01 -0600 (MDT)
Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM)
	id AA10241; Thu, 26 Apr 2001 11:16:21 -0400
Date: Thu, 26 Apr 2001 11:16:21 -0400 (EDT)
From: Jim Bound 
To: mobile-ip@sunroof.eng.sun.com
Cc: 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=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,

I think your point is valid.  But I think its an architecture discussion
and not an engineering discussion and those  are different.  But I do
concede to your point at my end.  But I believe there is an engineering
argument too but first we need to know if LMMs distributed help in the
architecture adn that is a discussion we should have at a minimum.

/jim

On Thu, 26 Apr 2001, Erik Nordmark wrote:

> > Hello Hesham,
> > 
> > Not sure that you have read  either my previous postings and of course
> > underlying reasoning on this topic.
> > 
> > I will just reiterate what the constituency has spoken here and say that we
> > (and speaking also for myself, I) have elaborated on the topic as concretely
> > as possible..
> > 
> > You may feel that you do not _understand_ the reasons (once more)...the rest
> > of the constituency _has_. To that people have either agreed or disagreed or
> > expressed reservations. You, _simply_ don't understand it... QED..
> 
> Count me in for an other person who fails to understand the arguments.
> 
> Perhaps my lack of understanding has to do with the following:
> With LMM we are fundamentally talking about optimizations - mobile IP
> without LMM works in the sense that packets move - we just want to optimize
> the amount of signalling traffic as well as the time it takes to
> update the mobility agents when the MN moves.
> 
> Since this is an ENGINEERING organization I'd expect an argument for
> "do it this way because it is more optimal" would actually contain some
> engineering: example topologies, numbers showing signalling volume and
> signaling latency with and without an hierarchy.
> I frankly haven't seen any engineering rigor in any arguments for or against
> a hierarchy. (Thesis topic anyone?)
> 
> Instead we are operating in a mode where some folks (including me)
> arguing that without hierarchy things are simpler and others arguing that
> hirarachy is more general and flexible.
> Neither argument has anything to do with ENGINEERING.
> 
>    Erik
> 



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 12:11: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 MAA10200
	for ; Thu, 26 Apr 2001 12:11: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 IAA11368;
	Thu, 26 Apr 2001 08: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 IAA13818;
	Thu, 26 Apr 2001 08:51:35 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QFoOK9019249
	for ; Thu, 26 Apr 2001 08:50:24 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QFoNMo019248
	for mobile-ip-dist; Thu, 26 Apr 2001 08:50: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QFoCK9019241
	for ; Thu, 26 Apr 2001 08:50:12 -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 IAA13640
	for ; Thu, 26 Apr 2001 08:50:10 -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 LAA21361
	for ; Thu, 26 Apr 2001 11:08:44 -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 IAA01496
	for ; Thu, 26 Apr 2001 08:49:57 -0700 (PDT)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3QFnun25642
	for ; Thu, 26 Apr 2001 08:49:56 -0700
X-mProtect:  Thu, 26 Apr 2001 08:49:56 -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(WTS.12.69) smtpdf0hENg; Thu, 26 Apr 2001 08:49:49 PDT
Message-ID: <3AE8439F.5F744F91@iprg.nokia.com>
Date: Thu, 26 Apr 2001 08:49:51 -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

Hi again Erik,


Erik Nordmark wrote:

> Theo,
>
> > I must say that this is far from truth... by the moment you have the notion
> > of "next possible candates" you have already established a hierarchy
> > structure of "previous -> next"
>
> Now I'm really confused.
> I've been assuming that the hierarchy that we've been discussing is
> common for a number of MNs (perhaps all) in some particular part of
> the network.
>
> But your previous->next relationship is a function of the individual movement
> patterns of a particular MN thus it might be different for all MNs (at least
> if you track enough of their history using a chain of prev->next
> relationships).
>
> That sounds like the "update the previous FA" scheme in MIPv4 which
> doesn't look like a (shared) hierarchy at all.
>
>    Erik

Ok,

   the hierarchy implied by the "previous->next" relationship can either be
generic...ie all mobile nodes that are participating in a admin domain ...or it
can be specific that is per MN by refering specifically to generic relationship.
It is only the per-MN behaviour that is instantiated on the second.

In your understanding (above) you happen to see the second. The first though is
ALREADY there.

In the first you refer to a packet that goes from the previous LMM-aware routing
element to the next..

In the second you refer to a packet for a _particular_ MN that goes for the last
hop previous LMM-aware routing element to the next..

So you have correctly assumed a common hierarchy for all MNs here..you just pick
a snapshot for the individual MN...

It is like the analogy...I can see the map of the roads...but at the same time I
can see my route on that map.


Multicast has said it in a different ..perhaps clearer way...incoming and
outgoing interfaces...but it is the same thing...stil hierarchy..

I only wanted to show that the building blocks for a hierarchy are in principle
there...it is just a matter of tying them together...in an admin domain

So I am definetely refering to a shared hierarchy...one which an LMM scheme
could instantiate differently than another depending on how it wants to see
it...


Theo


UCL/ Mobile Systems



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 12:17:20 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10444
	for ; Thu, 26 Apr 2001 12:17:19 -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 JAA07849;
	Thu, 26 Apr 2001 09:16:50 -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 IAA11133;
	Thu, 26 Apr 2001 08:10:27 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QF9CK9019119
	for ; Thu, 26 Apr 2001 08:09:13 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QF9C8e019118
	for mobile-ip-dist; Thu, 26 Apr 2001 08:09: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QF92K9019111
	for ; Thu, 26 Apr 2001 08:09:04 -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 IAA06127
	for ; Thu, 26 Apr 2001 08:09:01 -0700 (PDT)
Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA26329
	for ; Thu, 26 Apr 2001 10:27:18 -0600 (MDT)
Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM)
	id AA16135; Thu, 26 Apr 2001 11:08:46 -0400
Date: Thu, 26 Apr 2001 11:08:46 -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,

The metro networks are good example of the need for hiearchy.  The metro
is not a clean cloud with perfect routing core and edges at all at least
today, In addition there are ILECs under the metro core that will begin to
support mobility esp for phones and pda's under the ILECs are the LACs and
then under that VPN networks.  If I roam around all day at ILEC1 within
LACs having a distributed LMM hierarchy permits me to not bother the metro
HA.  I am assuming IPv6 or Global IPv4 Addresses above too.

/jim

On Thu, 26 Apr 2001, Erik Nordmark wrote:

> > All that we're asking for is that the requirements state that the
> > solution SHOULD (not MUST) support multiple levels of LMM agents.
> > The reason is so that if a network operator has a deployment situation
> > where the signalling lines get long, they can deploy an upper level
> > agent to keep the external CoA fixed.
> 
> I still don't have a picture that tells me what you gain.
> I assume keeping the external COA fixed is not a goal in itself - the
> goal is just better performance (less signalling over long paths).
> 
> So if the signalling lines (e.g. between different metropolitan areas,
> different small countries, or different topological clouds that don't follow
> any geographic notion like metro or country) are long then you can just have
> one LMM per such cloud without any hierarchy.
> Thus movement between clouds cause the home agent and 
> correspondents to be updated.
> 
> In this case when a mobile moves within the cloud (e.g. one metro)
> there is only local signalling, and the movement between clouds 
> the boundaries between the clouds in the operator's network have
> been designed so that the movement between them is infrequent.
> 
> When would you need another level of hierarchy?
> 
> Or stated differently, if you place the LMMs so that the latency over the
> wired part of the network between the MNs and their LMM is on the order
> of 10 ms, and let the HA then it seems like for it to make sense to have 
> another level of hierachy below it that level should be two orders of magnitude
> of delay less i.e. on the order of .1 ms. Thus speed of light in copper/glass
> would limit that to 20-30km in size. Sure, you could argue that you need an
> additional level for each factor 3 or 10 in the latency domain, but my
> personal gut feel is that in such a case you are adding complexity for little
> performance gain, especially given that any signalling involving the MN will
> add on the order of 50 ms of delay due to the coding necessary to deal with
> the fading.
> 
>    Erik
> 



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 12:17:25 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10457
	for ; Thu, 26 Apr 2001 12:17:25 -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 JAA07704;
	Thu, 26 Apr 2001 09:16: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 JAA18070;
	Thu, 26 Apr 2001 09:12:44 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QGBXK9019301
	for ; Thu, 26 Apr 2001 09:11:33 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QGBXfU019300
	for mobile-ip-dist; Thu, 26 Apr 2001 09:11: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QGBOK9019293
	for ; Thu, 26 Apr 2001 09:11:25 -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 JAA15530;
	Thu, 26 Apr 2001 09:11:22 -0700 (PDT)
Message-Id: <200104261611.JAA15530@heliopolis.eng.sun.com>
Date: Thu, 26 Apr 2001 09:11:22 -0700 (PDT)
From: James Kempf 
Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L  ocalized Mobility Management Requirement s)
To: James.Kempf@Sun.COM, Erik.Nordmark@eng.sun.com
Cc: Erik.Nordmark@eng.sun.com, mobile-ip@sunroof.eng.sun.com,
        Basavaraj.Patil@nokia.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: XAkdzPJLxzYYdsYC6WU+UQ==
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: 

Erik,

>I still don't have a picture that tells me what you gain.
>I assume keeping the external COA fixed is not a goal in itself - the
>goal is just better performance (less signalling over long paths).
>

Not quite. It is only by keeping the external CoA fixed that you can
eliminate frequent full-BU-sending MN to CN handovers. If the external
CoA moves, then a full-BU-sending MN to CN handover is needed, in
which the MN must send BUs to all CNs. If the CN is on the other
side of the world, this could be upwards of 160 ms RTT. If there
is more than one such CN, it could quickly add up. If only the
local CoA changes, then the MN needs to send only a single BU, 
to the LMM.

>So if the signalling lines (e.g. between different metropolitan areas,
>different small countries, or different topological clouds that don't follow
>any geographic notion like metro or country) are long then you can just have
>one LMM per such cloud without any hierarchy.
>Thus movement between clouds cause the home agent and 
>correspondents to be updated.
>

If you have one LMM per cloud w. no hierarchy, you have to change globally 
visible CoA when you move from one LMM to another. This results in latency
when multiple BUs get sent to the CNs, instead of just one to the LMM. It is 
possible in deployment situations that for topological or network administration 
reasons you would have to deploy many LMMs and as a result suffer much
latency from frequent full-BU-sending handovers, rather than the
single BU-sending handover you get if you don't change the globally
visible CoA. 

>In this case when a mobile moves within the cloud (e.g. one metro)
>there is only local signalling, and the movement between clouds 
>the boundaries between the clouds in the operator's network have
>been designed so that the movement between them is infrequent.
>

May not be possible to design such that movement between them is
infrequent. What if you have a situation with multiple, small
wireless ISPs in a geographical area who want to optimize signalling
within their own administrative domain, but they are peering 
through a larger ISP? (BTW, this is an example I brought up
last week on the list if you care to check the archive).

If the LMM protocol supports hierarchy, the peering ISP can
support an upper level LMM that keeps the globally visible
CoA constant while the MN moves between LMM agents in the
small wireless ISPs.

>When would you need another level of hierarchy?
>

See above.

>Or stated differently, if you place the LMMs so that the latency over the
>wired part of the network between the MNs and their LMM is on the order
>of 10 ms, and let the HA then it seems like for it to make sense to have 
>another level of hierachy below it that level should be two orders of magnitude
>of delay less i.e. on the order of .1 ms. Thus speed of light in copper/glass
>would limit that to 20-30km in size. Sure, you could argue that you need an
>additional level for each factor 3 or 10 in the latency domain, but my
>personal gut feel is that in such a case you are adding complexity for little
>performance gain, especially given that any signalling involving the MN will
>add on the order of 50 ms of delay due to the coding necessary to deal with
>the fading.
>

It doesn't have anything to do with the latency between the levels
of hierarchy but rather between the mobile node and the CNs. If you
can't arrange LMM agents such that you can keep the global CoA constant
and thus reduce the need for full-BU-sending handovers, you end up
with high latency handovers and frequent dropped calls.

		jak



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 12:26:22 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10860
	for ; Thu, 26 Apr 2001 12:26: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 JAA18342;
	Thu, 26 Apr 2001 09:25: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 JAA20834;
	Thu, 26 Apr 2001 09:25:40 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QGOQK9019345
	for ; Thu, 26 Apr 2001 09:24:26 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QGOQNG019344
	for mobile-ip-dist; Thu, 26 Apr 2001 09:24: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QGOHK9019337
	for ; Thu, 26 Apr 2001 09:24:17 -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 JAA15870;
	Thu, 26 Apr 2001 09:24:16 -0700 (PDT)
Message-Id: <200104261624.JAA15870@heliopolis.eng.sun.com>
Date: Thu, 26 Apr 2001 09:24:16 -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
Cc: Basavaraj.Patil@nokia.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: jn4tPoZ3YrZMc6pcw2Dtiw==
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: 

>Since this is an ENGINEERING organization I'd expect an argument for
>"do it this way because it is more optimal" would actually contain some
>engineering: example topologies, numbers showing signalling volume and
>signaling latency with and without an hierarchy.
>I frankly haven't seen any engineering rigor in any arguments for or against
>a hierarchy. (Thesis topic anyone?)
>
>Instead we are operating in a mode where some folks (including me)
>arguing that without hierarchy things are simpler and others arguing that
>hirarachy is more general and flexible.
>Neither argument has anything to do with ENGINEERING.
>

I think you are being unrealistic, Erik.

The fact of the matter is that the current HMIP proposal was made
a working group draft without any of the kind of hard evidence
you are asking for. It was made a working group draft because 
of the following:

	1) There were three individual draft proposals given at IETF 48.
	2) Two of them were similar, and they were combined.
	3) The other one was slightly more complex, and people had
	some questions at the meeting on it.
	4) The working group chairs asked for comments on the list
	about making the combined draft a working group draft and, since 
	nobody was paying attention at that time, there were none
	and the draft became a working group draft.
	
There was no discussion of requirements, and as we are seeing now,
there is wide disagreement about what the requirements are. There
was absolutely no studies of the kind you are asking for, nothing
anywhere near it.

I think it is unrealistic, and frankly unfair, to demand now that
people come up with detailed engineering studies during a post-hoc requirements
phase to justify a decision that was made on rather thin engineering
evidence in the first place.

If you want this kind of evidence, I suggest we drop working group
status for HMIP and make a concerted evidence to get it.

		jak
		
PS: With regards to arguments from topologies, etc., please see my
previous email giving an example of a particular deployment
situation where performance would suffer if there is no possiblity
to limit the number of full-BU-sending handovers.




From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 12:29: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 MAA11091
	for ; Thu, 26 Apr 2001 12:29:17 -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 JAA00444;
	Thu, 26 Apr 2001 09:28: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 JAA25824;
	Thu, 26 Apr 2001 09:28:36 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QGRUK9019365
	for ; Thu, 26 Apr 2001 09:27:30 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QGRTis019364
	for mobile-ip-dist; Thu, 26 Apr 2001 09:27: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QGRLK9019357
	for ; Thu, 26 Apr 2001 09:27: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 JAA15957
	for ; Thu, 26 Apr 2001 09:27:20 -0700 (PDT)
Message-Id: <200104261627.JAA15957@heliopolis.eng.sun.com>
Date: Thu, 26 Apr 2001 09:27:20 -0700 (PDT)
From: James Kempf 
Subject: RE: [mobile-ip] Hierarchy and Low Latency Handoff
To: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: vR/0Tpo1IDI7QeybKguccg==
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: 

Erik,

>
>> Not quite. I did a little experiment at IETF50 to see what signalling
>> delays would be for an intercontinental BU - about 160 ms RTT to Japan
>> and Europe. That is over half the RTT delay recommended by the ITU
>> before human perception notices a gap. I think transcontinental
>> times would be maybe half of this. 
>> 
>> If the network operator cannot deploy a hierarchy of LMM agents,
>> they may not be able to counter.
>
>Why not. Each operator could solve the above by having an LMM agent
>per continent. Or they could be more fine grain and have one per metropolitan
>area.
>I don't see what benefits you could derive (and what the numbers would be
>in terms of signalling traffic volume and signalling delay) by an
>operator having e.g. both continent level LMMs as well as metro-area LMMs.
> 

Please see my previous post (third time!) about a deployment situation/network
topology that would result in significant increase in handover latency
(and thus probability of dropped calls).

		jak



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 12:53:03 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12137
	for ; Thu, 26 Apr 2001 12:53:03 -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 JAA11793;
	Thu, 26 Apr 2001 09:52:28 -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 JAA01309;
	Thu, 26 Apr 2001 09:51:28 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QGo0K9019428
	for ; Thu, 26 Apr 2001 09:50:00 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QGo05x019427
	for mobile-ip-dist; Thu, 26 Apr 2001 09:50: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QGnpK9019420
	for ; Thu, 26 Apr 2001 09:49:52 -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 JAA16904
	for ; Thu, 26 Apr 2001 09:49:50 -0700 (PDT)
Message-Id: <200104261649.JAA16904@heliopolis.eng.sun.com>
Date: Thu, 26 Apr 2001 09:49:51 -0700 (PDT)
From: James Kempf 
Subject: [mobile-ip] Protocol Decision Fixed?
To: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: fxdexQfCpJCPxyoYMX/WGQ==
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 Phil,


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

A requirements phase is usually gone through in order to define what
the protocol needs to accomplish. Doing a requirements analysis
subsequent to selecting a protocol is a bit like putting on your
bathing suit after you've jumped into the water with your cloths
on. :-) The tendency is to "cook" the requirements to satisfy the
already selected protocol. IMHO, we are seeing a bit of that
now, with the authors of the selected protocol arguing strenuously
against including requirements which their protocol currently
can't support. In addition, they seem to be getting support from one WG
chair and an AD who may have some vested interest in keeping 
the protocol decision fixed, despite the somewhat dubious technical 
grounds on which it was selected in the first place. Meanwhile, those other 
members of the working group who have spoken up have largely been arguing in the 
opposite direction.

If the IESG and WG chairs decide they want to keep the protocol
decision fixed, then let's simply drop discussion of requirements
and rubber stamp HMIP. I'm perfectly fine with that. There's no point in wasting 
transcontinental bandwidth on email any further. Clearly, we're in the 
"political" layer of the IP stack here. :-)

		jak



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 12:59:03 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12382
	for ; Thu, 26 Apr 2001 12:59: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 JAA17102;
	Thu, 26 Apr 2001 09:58: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 HAA07173;
	Thu, 26 Apr 2001 07:58:07 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QEutK9019091
	for ; Thu, 26 Apr 2001 07:56:55 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QEutAU019090
	for mobile-ip-dist; Thu, 26 Apr 2001 07:56:55 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QEugK9019076
	for ; Thu, 26 Apr 2001 07:56:43 -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 QAA14561;
	Thu, 26 Apr 2001 16:56:39 +0200 (MET DST)
Date: Thu, 26 Apr 2001 07:56:40 -0700 (PDT)
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, tweckstr@cc.hut.fi
Cc: Basavaraj.Patil@nokia.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: 

Tom,

> As I have experienced the scalability benefit of the LMM, it will allow
> scalability in the number of MNs moving within the domain through the
> reduced signaling.

Do you have example topologies and numbers showing the differences?

   Erik



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 13:42:48 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 NAA13985
	for ; Thu, 26 Apr 2001 13:42:47 -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 KAA14429;
	Thu, 26 Apr 2001 10:41: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 KAA09916;
	Thu, 26 Apr 2001 10:26:45 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QHPKK9019617
	for ; Thu, 26 Apr 2001 10:25:20 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QHPKl1019616
	for mobile-ip-dist; Thu, 26 Apr 2001 10:25: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QHP9K9019609
	for ; Thu, 26 Apr 2001 10:25:10 -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 KAA09521
	for ; Thu, 26 Apr 2001 10:25:08 -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 KAA21175
	for ; Thu, 26 Apr 2001 10:25:07 -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 f3QHP6O07707
	for ; Thu, 26 Apr 2001 19:25:06 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Apr 26 19:22:39 2001 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Thu, 26 Apr 2001 19:19:46 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBDBB@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" ,
        PRoberts@MEGISTO.com
Cc: samita@jurassic.Eng.Sun.COM
Subject: RE: [mobile-ip] Final(?) Cut on LMM Requirements
Date: Thu, 26 Apr 2001 19:24: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: 


> > Seems like we're converging apart from the multiple levels of hierarchy
> 
> > 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 am not  sure if the above requirement means that one LMM shall scale to
> support millions of nodes. Or does it mean that LMM could be a cluster of
> agent nodes distributing the loads among themselves ?
> 
	=> I think one LMM will scale to however many nodes it 
	can support physically. If that number is 10 then it will 
	be 10, if it's a million then be it. I hope people understand
	that the number of levels is completely irrelevant here. 
	The top LMM will ALWAYS keep ALL states regardless
	of how mny levels are below it. 

	Having said that I like your proposal about having more
	than one node serving on the same level. This allows 
	the LMM nodes to share the load. This is exactly 
	what we had in mind for HMIPv6.

> If LMM  means one node, then I would say 'million nodes' is a strong requirement
> 
	=> Well I just think a number is meaningless. 
	But to be honest I can't articulate a god scalability requirement
	right now. 

> I think we need to have a requirement for scalability or load distribution
> among the hierarchical mobility agents.
> 
	=> Agreed. A protocol scalability requiremet.

> > 8. LMM shall not require changes to the HA and the CNs.
> 
> > 
> 
> Is this requirement a "must"  or should ?  I agree that no changes
> for CN, but are we sure that there can't be any change in HA also 
> in the future ? I can't think of any example of the top my head right
> now, but wonder, if that is a safe assumption in case we might need
> some change in HA to support certain features in LMM (MAP or GMA).
> 
	=> Agreed. 

	Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 13:52:09 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 NAA14294
	for ; Thu, 26 Apr 2001 13:52:08 -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 KAA18594;
	Thu, 26 Apr 2001 10:47:50 -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 KAA05262;
	Thu, 26 Apr 2001 10:31:37 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QHU6K9019646
	for ; Thu, 26 Apr 2001 10:30:07 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QHU6Ks019645
	for mobile-ip-dist; Thu, 26 Apr 2001 10:30: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QHTvK9019638
	for ; Thu, 26 Apr 2001 10:29:57 -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 KAA25125
	for ; Thu, 26 Apr 2001 10:29:56 -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 KAA20135
	for ; Thu, 26 Apr 2001 10:29:54 -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 f3QHTnO08521
	for ; Thu, 26 Apr 2001 19:29:49 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Apr 26 19:28:00 2001 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Thu, 26 Apr 2001 19:25:07 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBDBC@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 L
	 ocalized Mobility Management Requirement s)
Date: Thu, 26 Apr 2001 19:29:47 +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: 


> Hesham >>  The 
> Hesham >> primary argument for hierarchy is that you can have a lower level LMM
> Hesham >> agent that is close to the mobile node with which the mobile node does
> Hesham >> a short leg BU when changing CoA, but the global CoA remains the 
> Hesham >> same. 
> Hesham >> 
> Hesham >	=> So the main gain here if I understand you correctly is that
> Hesham >	you get a "quicker" update of the routing tables. 
> Hesham >	In a wireless system where forwarding delays on the wire are 
> Hesham >	completely insgnificant compared to the delays over the air,,
> Hesham >	I don't see a significant value adding here. We can easily illustrate
> Hesham >	this with some well known numbers. 
> Hesham >	Unless you see other gains that I couldn't interpret..
> Hesham >
> Hesham >	Hesham 
> Hesham >
> 
> Hesham, you just admitted that we get a faster routing table update with
> multilevel hierarchy. 
> 
	=> Did I ??? You need to go past the first sentence I think. 
	I'm talking about facts here and laws of physics which are
	documented in cellular standards. 

> There is little to argue against this clear benefit.
> This benefit, in the end, results in *better scalability* as Theo and
> others have already said.
> 
	=> Scalability of what ? How can you possibly claim that 
	keeping more state in the network scales better ?
	Please explain this to me.

	Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 13:53: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 NAA14332
	for ; Thu, 26 Apr 2001 13:53: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 KAA18561;
	Thu, 26 Apr 2001 10:47:48 -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 KAA12481;
	Thu, 26 Apr 2001 10:37:43 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QHa6K9019685
	for ; Thu, 26 Apr 2001 10:36:06 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QHa5Q2019684
	for mobile-ip-dist; Thu, 26 Apr 2001 10:36:05 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QHZtK9019677
	for ; Thu, 26 Apr 2001 10:35:56 -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 KAA11948
	for ; Thu, 26 Apr 2001 10:35:50 -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 KAA25205
	for ; Thu, 26 Apr 2001 10:35:47 -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 f3QHZkN02605
	for ; Thu, 26 Apr 2001 19:35:46 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu Apr 26 19:35:46 2001 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Thu, 26 Apr 2001 19:31:04 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBDBD@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 L
	 ocalized Mobility Management Requirement s)
Date: Thu, 26 Apr 2001 19:35:40 +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: 

> I've been following the discussion, and since you've asked I'll give you an
> opinion.
> 
> It seems that Hesham's main point is that the speed of the fixed network (or
> "wired") is so much greater than that of the wireless network that the
> benefits of hierarchy are minimized.
> 
> I'm not sure I would agree that the speed of the fixed network will *always*
> significantly outstrip that of the mobile network.  I don't feel I have a
> good enough grasp of all the issues to weigh in on one side or the other,
> but did want to highlight an assumption I don't feel comfortable with.
> 
	=> Maybe I can give some factual figures here to help. 
	If the delay over the air is 60-80 ms (80 being the worste case
	scenario) and routers are forwarding at wire speed, or let's 
	say there is a 1 ms delay per router. Is the fixed network
	delay still of any significance ? 

	Hesham


> > -----Original Message-----
> > From: Phil Roberts [mailto:PRoberts@MEGISTO.com]
> > Sent: Tuesday, April 24, 2001 5:59 PM
> > 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)
> > 
> > 
> > How to proceed?  Good question.  It would be really good if 
> > some other folks
> > weighed in on the issue.  Does anyone who hasn't commented on 
> > this so far
> > care to add anything?  care at all?
> > 
> > Phil
> > 
> > 
> > > -----Original Message-----
> > > From: James Kempf [mailto:James.Kempf@Sun.COM]
> > > Sent: Tuesday, April 24, 2001 5:47 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
> > > L ocalized Mobility Management Requirement s)
> > > 
> > > 
> > > Hi Hesham,
> > > 
> > > Thanx for your response, but I think we've been through these
> > > points a number of times, we really don't need to rehash them 
> > > again. Charlie, 
> > > Theo, myself, and one other person (whose name I've 
> > > forgotten) have spoken up 
> > > for a requirement to support hierarchy. You and Karim have 
> > > spoken up against it, 
> > > and Raj, expressing a preference for simplicity, has an inclination
> > > against it.
> > > 
> > > Anybody else out there in SMTP-land want to express a preference?
> > > 
> > > Phil, any ideas about how to proceed?
> > > 
> > > 		jak
> > > 
> > > 
> > > >From: "Hesham Soliman  (ERA)" 
> > > >To: "'mobile-ip@sunroof.eng.sun.com'" 
> > 
> > > >Cc: Basavaraj.Patil@nokia.com
> > > >Subject: RE: Multiple Levels of LMM agents (was: RE: 
> > > [mobile-ip] Revised L 
> > > ocalized Mobility Management Requirement s)
> > > >Date: Tue, 24 Apr 2001 23:34:56 +0200
> > > >
> > > >
> > > >> Actually, no. I'm saying that we have had at least three 
> > people who
> > > >> have given good arguments, IMHO, as to why multiple levels of
> > > >> hierarchy might be needed. On the other side, those arguments
> > > >> are refuted by two people who think that no hierarchy is needed.
> > > >> Neither side is going to convince the other, both sides have
> > > >> good arguments.
> > > >> 
> > > >	=> I'm not sure who you mean by the "two" people, there 
> > > is definitely 
> > > >	more (at least the authors of HMIP are) but anyway
> > > >	after reading the discussion it really seems to me like 
> > > the only 
> > > >	two (understandable IMHO) reasons are:
> > > >
> > > >	1.  In future there may be a need for multi-level 
> > > hierarchy. That need 
> > > >	is not explained really. To me this is not a good 
> > > reason for including
> > > >	any feature. Ithink it makes a lot of sense of scope 
> > > the problem to
> > > >	what we know without "guessing" what might happen in future
> > > >	and how theuse of MIP can be changed dramatically. No one 
> > > >	knows that this is true.> 
> > > >
> > > >	2. Multi-level hierarchy localises the signalling. Let's try to 
> > > understand 
> > > >	what this really means. A MAP domain is as large as the amount 
> > > >	of traffic that a MAP can handle, regardless of the number of 
> > > >	levels of hierarchy. The signalling will always be local to that
> > > >	domain. So I'm not really clear on the significant 
> > > advantage here. 
> > > >	We're certainly not expecting any inter-continental mobility 
> > > >	management using HMIPv6. So careful placement of the MAP 
> > > >	using network engineering skills and common sense is 
> > > >	sufficient. 
> > > >
> > > >> What I'm saying is that we have some arguments the feature 
> > > is needed,
> > > >> so let's put it in. From Karim's last email, it sounds 
> > like we can
> > > >> probably accommodate his concerns about multiplying 
> > > failure possibilities.
> > > >> 
> > > >	=> At a cost. The beneft MUST outweigh the cost. This is not 
> > > >	the case here IMO.
> > > >
> > > >> If we don't put it in and deployment proves that we need it, 
> > > >> 
> > > >	=> This is exactly point one above. 
> > > >
> > > >	Hesham
> > > 
> > 


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 13:58: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 NAA14529
	for ; Thu, 26 Apr 2001 13: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 KAA22035;
	Thu, 26 Apr 2001 10:53:32 -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 KAA00482;
	Thu, 26 Apr 2001 10:44:30 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QHgUK9019738
	for ; Thu, 26 Apr 2001 10:42:30 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QHgTrx019737
	for mobile-ip-dist; Thu, 26 Apr 2001 10:42: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QHgKK9019730
	for ; Thu, 26 Apr 2001 10:42:20 -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 KAA13241
	for ; Thu, 26 Apr 2001 10:42:19 -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 KAA29731
	for ; Thu, 26 Apr 2001 10:42:15 -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 f3QHgAN03737
	for ; Thu, 26 Apr 2001 19:42:10 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Thu Apr 26 19:42:10 2001 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Thu, 26 Apr 2001 19:42:09 +0200
Message-ID: 
From: "Karim El-Malki (ERA)" 
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)
Date: Thu, 26 Apr 2001 19:42:05 +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 James

> >Since this is an ENGINEERING organization I'd expect an argument for
> >"do it this way because it is more optimal" would actually 
> contain some
> >engineering: example topologies, numbers showing signalling 
> volume and
> >signaling latency with and without an hierarchy.
> >I frankly haven't seen any engineering rigor in any 
> arguments for or against
> >a hierarchy. (Thesis topic anyone?)
> >
> >Instead we are operating in a mode where some folks (including me)
> >arguing that without hierarchy things are simpler and others 
> arguing that
> >hirarachy is more general and flexible.
> >Neither argument has anything to do with ENGINEERING.
> >
> 
> I think you are being unrealistic, Erik.
> 
> The fact of the matter is that the current HMIP proposal was made
> a working group draft without any of the kind of hard evidence
> you are asking for. It was made a working group draft because 
> of the following:
> 
> 	1) There were three individual draft proposals given at IETF 48.
> 	2) Two of them were similar, and they were combined.
> 	3) The other one was slightly more complex, and people had
> 	some questions at the meeting on it.
> 	4) The working group chairs asked for comments on the list
> 	about making the combined draft a working group draft 
> and, since 
> 	nobody was paying attention at that time, there were none
> 	and the draft became a working group draft.
> 	
> There was no discussion of requirements, and as we are seeing now,
> there is wide disagreement about what the requirements are. There
> was absolutely no studies of the kind you are asking for, nothing
> anywhere near it.
> 
> I think it is unrealistic, and frankly unfair, to demand now that
> people come up with detailed engineering studies during a 
> post-hoc requirements
> phase to justify a decision that was made on rather thin engineering
> evidence in the first place.
> 
> If you want this kind of evidence, I suggest we drop working group
> status for HMIP and make a concerted evidence to get it.

You are making a simple thing complicated. HMIPv6 provides the same basic
local home agent functionality as in Regional Registrations for
MIPv4. The same overall reasoning applies. Are you questioning the whole
hierarchical/regional work? What I actually understand from your email
above is that you'd prefer an item to be dropped rather than having it
if it does not support the requirement you have put forward. Why?

Also, I can't understand what HMIPv6 has to do with this. If you have
technical problems with HMIPv6 please bring them up. You definitely seem
to have something against it. You have already made these comments against
HMIPv6 and I replied to your email with the 4 reasons you have copied above.
As a side note, I see you've changed a few points: 3) went from a security
problem to "slightly more complex". I thought you had said you didn't
know what happened in this discussion, but now I'm confused.

Anyway, let's get back to the requirements discussion and not waste
our time on these issues.

> PS: With regards to arguments from topologies, etc., please see my
> previous email giving an example of a particular deployment
> situation where performance would suffer if there is no possiblity
> to limit the number of full-BU-sending handovers.
> 

I think I've replied to this one. Why do you want to have an interconnect
ISP implement a _local_ MIPv6 agent? Doesn't seem to be the right place
to put a LMM. One LMM per cloud and handoffs between clouds are fine.
You won't handoff between ISP clouds continuously since a LMM is expected
to handle a significant area and number of MNs. It's a local HA after all.

Regards
/Karim


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 14:22:10 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15161
	for ; Thu, 26 Apr 2001 14:22: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 LAA25784;
	Thu, 26 Apr 2001 11:20: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 LAA23496;
	Thu, 26 Apr 2001 11:20:34 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QIInK9019807
	for ; Thu, 26 Apr 2001 11:18:49 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QIInv8019806
	for mobile-ip-dist; Thu, 26 Apr 2001 11:18: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QIIdK9019799
	for ; Thu, 26 Apr 2001 11:18:40 -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 LAA22936
	for ; Thu, 26 Apr 2001 11:18:38 -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 LAA12107
	for ; Thu, 26 Apr 2001 11:18:31 -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 f3QIINO17713
	for ; Thu, 26 Apr 2001 20:18:23 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Thu Apr 26 20:18:22 2001 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Thu, 26 Apr 2001 20:13:41 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBDBE@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Protocol Decision Fixed?
Date: Thu, 26 Apr 2001 20:18:22 +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'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.
	>
	>

	A requirements phase is usually gone through in order to define what
	the protocol needs to accomplish. Doing a requirements analysis
	subsequent to selecting a protocol is a bit like putting on your
	bathing suit after you've jumped into the water with your cloths
	on. :-) The tendency is to "cook" the requirements to satisfy the
	already selected protocol. IMHO, we are seeing a bit of that
	now, with the authors of the selected protocol arguing strenuously
	against including requirements which their protocol currently
	can't support. In addition, they seem to be getting support from one WG
	chair and an AD who may have some vested interest in keeping 
	the protocol decision fixed, despite the somewhat dubious technical 
	grounds on which it was selected in the first place. Meanwhile, those other 
	members of the working group who have spoken up have largely been arguing in the 
	opposite direction.

	If the IESG and WG chairs decide they want to keep the protocol
	decision fixed, then let's simply drop discussion of requirements
	and rubber stamp HMIP. I'm perfectly fine with that. There's no point in wasting 
	transcontinental bandwidth on email any further. Clearly, we're in the 
	"political" layer of the IP stack here. :-)

	=> These are some pretty rediculous accusations 
	you managed to come up with. Are you going to 
	accuse everyone who doesn't see your point of view
	as being part of a larger conspiracy ? 
	Stick to the technical argument james and if you 
	find that you're argument is no longer valid don't 
	start these accusations. Let's be professional.
	Try to understand that it is not just the "authors",
	the "WG chair"

	Since you brought up the topic, why are these 
	requirements suddenly rising suddenly against MIPv6 ??
	What is it that you don't like about HMIPv6 that made 
	you turn this requirements discussion around towards removing 
	it from WG ????


	Hesham



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 14:34:03 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15526
	for ; Thu, 26 Apr 2001 14:34: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 LAA05580;
	Thu, 26 Apr 2001 11:32: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 LAA26449;
	Thu, 26 Apr 2001 11:32:48 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QIUfK9019884
	for ; Thu, 26 Apr 2001 11:30:41 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QIUfpP019883
	for mobile-ip-dist; Thu, 26 Apr 2001 11:30: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 eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QIUVK9019876
	for ; Thu, 26 Apr 2001 11:30:36 -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 OAA12223
	for ; Thu, 26 Apr 2001 14:30:26 -0400 (EDT)
Received: (from glass@localhost)
	by onion.east.sun.com (8.9.3+Sun/8.9.3) id OAA03278
	for mobile-ip@sunroof.eng.sun.com; Thu, 26 Apr 2001 14:30:39 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QAtGK9018687
	for ; Thu, 26 Apr 2001 03:55: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 DAA08777
	for ; Thu, 26 Apr 2001 03:55:15 -0700 (PDT)
Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA04128
	for ; Thu, 26 Apr 2001 03:55:13 -0700 (PDT)
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id DAA27579 for ; Thu, 26 Apr 2001 03:55:13 -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 DAA10988 for ; Thu, 26 Apr 2001 03:55:13 -0700 (MST)]
Received: from [140.101.173.9] by m-il06-r4.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Thu, 26 Apr 2001 03:55:11 -0700
Received: (from root@localhost)
	by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) id MAA14029
	for mobile-ip@sunroof.eng.sun.com.DELIVER; Thu, 26 Apr 2001 12:55:10 +0200 (METDST)
Received: from crm.mot.com (test7.crm.mot.com [140.101.173.237])
	by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) with ESMTP id MAA13997
	for ; Thu, 26 Apr 2001 12:55:09 +0200 (METDST)
Message-Id: <3AE7FE8C.7A911FA9@crm.mot.com>
Date: Thu, 26 Apr 2001 12:55:08 +0200
From: Christophe Janneteau 
Organization: Centre de Recherche de Motorola - Paris
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Requirements Draft for Mobile IP QoS - Invitation to Volunteer
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 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


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 14:37:18 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15585
	for ; Thu, 26 Apr 2001 14:37: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 LAA08340;
	Thu, 26 Apr 2001 11:36: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 LAA21127;
	Thu, 26 Apr 2001 11:36:27 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QIZ4K9019943
	for ; Thu, 26 Apr 2001 11:35:05 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QIZ4NZ019942
	for mobile-ip-dist; Thu, 26 Apr 2001 11: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QIYtK9019935
	for ; Thu, 26 Apr 2001 11:34:55 -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 LAA20593
	for ; Thu, 26 Apr 2001 11:34:54 -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 LAA05488
	for ; Thu, 26 Apr 2001 11:34:54 -0700 (PDT)
Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21)
	id ; Thu, 26 Apr 2001 14:28:55 -0400
Message-ID: 
From: Phil Roberts 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Protocol Decision Fixed?
Date: Thu, 26 Apr 2001 14:28:47 -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,

    Is there a question buried in here or are you just venting?  I think the
WG is having a fairly productive discussion of requirements right now.  Why
don't we finish that before trying to decide whether to revisit the choice
of draft to take forward?

Phil


> -----Original Message-----
> From: James Kempf [mailto:James.Kempf@Sun.COM]
> Sent: Thursday, April 26, 2001 12:50 PM
> To: mobile-ip@sunroof.eng.sun.com
> Subject: [mobile-ip] Protocol Decision Fixed?
> 
> 
> Hi Phil,
> 
> 
> >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.
> >
> >
> 
> A requirements phase is usually gone through in order to define what
> the protocol needs to accomplish. Doing a requirements analysis
> subsequent to selecting a protocol is a bit like putting on your
> bathing suit after you've jumped into the water with your cloths
> on. :-) The tendency is to "cook" the requirements to satisfy the
> already selected protocol. IMHO, we are seeing a bit of that
> now, with the authors of the selected protocol arguing strenuously
> against including requirements which their protocol currently
> can't support. In addition, they seem to be getting support 
> from one WG
> chair and an AD who may have some vested interest in keeping 
> the protocol decision fixed, despite the somewhat dubious technical 
> grounds on which it was selected in the first place. 
> Meanwhile, those other 
> members of the working group who have spoken up have largely 
> been arguing in the 
> opposite direction.
> 
> If the IESG and WG chairs decide they want to keep the protocol
> decision fixed, then let's simply drop discussion of requirements
> and rubber stamp HMIP. I'm perfectly fine with that. There's 
> no point in wasting 
> transcontinental bandwidth on email any further. Clearly, 
> we're in the 
> "political" layer of the IP stack here. :-)
> 
> 		jak
> 


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 14:59:57 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16118
	for ; Thu, 26 Apr 2001 14:59:56 -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 LAA26290;
	Thu, 26 Apr 2001 11:58: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 LAA01073;
	Thu, 26 Apr 2001 11:57:57 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QIuDK9020030
	for ; Thu, 26 Apr 2001 11:56:13 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QIuCLi020029
	for mobile-ip-dist; Thu, 26 Apr 2001 11:56: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QIu3K9020022
	for ; Thu, 26 Apr 2001 11:56:04 -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 LAA00596
	for ; Thu, 26 Apr 2001 11:56:02 -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 LAA24627
	for ; Thu, 26 Apr 2001 11:56:01 -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 NAA17165
	for ; Thu, 26 Apr 2001 13:56:27 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Thu, 26 Apr 2001 13:56:05 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Thu, 26 Apr 2001 13:55:50 -0500
Message-ID: <85AA7486A2C1D411BCA20000F8073E4302071DC1@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: Thu, 26 Apr 2001 13:55:47 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0CE82.81020F00"
Sender: owner-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_01C0CE82.81020F00
Content-Type: text/plain;
	charset="iso-8859-1"

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_01C0CE82.81020F00
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






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@u=
sa.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_01C0CE82.81020F00--


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 15:21: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 PAA16806
	for ; Thu, 26 Apr 2001 15:21:32 -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 MAA10104;
	Thu, 26 Apr 2001 12:20: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 MAA05663;
	Thu, 26 Apr 2001 12:20:42 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QJJ0K9020201
	for ; Thu, 26 Apr 2001 12:19:00 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QJIxoC020200
	for mobile-ip-dist; Thu, 26 Apr 2001 12:18: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QJIoK9020193
	for ; Thu, 26 Apr 2001 12:18:51 -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 MAA00926
	for ; Thu, 26 Apr 2001 12:18:49 -0700 (PDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA21039
	for ; Thu, 26 Apr 2001 13:20:04 -0600 (MDT)
Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.43.101])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA02996;
	Thu, 26 Apr 2001 12:19:02 -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 AEA14299;
	Thu, 26 Apr 2001 12:18:33 -0700 (PDT)
Message-Id: <4.3.2.7.2.20010426111546.017b0d60@mira-sjcm-3.cisco.com>
X-Sender: gdommety@mira-sjcm-3.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 26 Apr 2001 12:20:17 -0700
To: mobile-ip@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com
From: Gopal Dommety 
Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip]
  Revised L  ocalized Mobility Management Requirement s)
Cc: Basavaraj.Patil@nokia.com
In-Reply-To: <200104242146.OAA06325@heliopolis.eng.sun.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: 

Hello:

Going through the Advantages and disadvantages of  of LMMs or LMAs it might 
be clear if multiple levels of hierarchy are needed.

Advantages:

1. Localizes  signalling (Localizing signalling does not mean reducing 
signalling)  For localizing signalling one level of hierarchy is enough, if 
we assume that the cost to send a message within a domain is the the same 
irrespective of the nuber of routed hops.

2. Could potentially reduce handoff delay. Handoff delay consists of two 
components that are relavent to this discussion
1) transimssion delay  2) processing delay. Unless over a low speed link 
transmission delay is not a major factor. Processing delay
is what will hit you the most.  Multiple levels of hierarchy add to the 
processing dealy and so could actually increase the handoff delay.

3. Reduces the need to update the caches in the CN or change the VPN tunnel 
endpoint. For this also one level of hierarchy is enough.

Disadvantages of LMMs or LMAs

1. The amount of processing for the data path increases. Every data packet 
has to traverse these hierarchies. so multiple levels of hierarchies are 
not necessarly good.

2. The points of failure increases. Increases in the levels of hierarchies 
are not necessarly good.

So multiple levels of hierarchy may not be needed if the cost of 
transmitting/packet is not affected significantly by the number of routed 
hops it traverses (who knows one day slow routing might be back in fashion).

I am not against multiple hierarchies, if the simplicity of the solution is 
not comprimised. I personally think it is very
easy to have muliple levels of hierarchy (see 
draft-dommety-mobileip-lma-ipv6-02.txt).



Thanks
Gopal









At 02:46 PM 4/24/2001 -0700, James Kempf wrote:
>Hi Hesham,
>
>Thanx for your response, but I think we've been through these
>points a number of times, we really don't need to rehash them again. Charlie,
>Theo, myself, and one other person (whose name I've forgotten) have spoken up
>for a requirement to support hierarchy. You and Karim have spoken up 
>against it,
>and Raj, expressing a preference for simplicity, has an inclination
>against it.
>
>Anybody else out there in SMTP-land want to express a preference?
>
>Phil, any ideas about how to proceed?
>
>                 jak
>
>
> >From: "Hesham Soliman  (ERA)" 
> >To: "'mobile-ip@sunroof.eng.sun.com'" 
> >Cc: Basavaraj.Patil@nokia.com
> >Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L
>ocalized Mobility Management Requirement s)
> >Date: Tue, 24 Apr 2001 23:34:56 +0200
> >
> >
> >> Actually, no. I'm saying that we have had at least three people who
> >> have given good arguments, IMHO, as to why multiple levels of
> >> hierarchy might be needed. On the other side, those arguments
> >> are refuted by two people who think that no hierarchy is needed.
> >> Neither side is going to convince the other, both sides have
> >> good arguments.
> >>
> >       => I'm not sure who you mean by the "two" people, there is 
> definitely
> >       more (at least the authors of HMIP are) but anyway
> >       after reading the discussion it really seems to me like the only
> >       two (understandable IMHO) reasons are:
> >
> >       1.  In future there may be a need for multi-level hierarchy. That 
> need
> >       is not explained really. To me this is not a good reason for 
> including
> >       any feature. Ithink it makes a lot of sense of scope the problem to
> >       what we know without "guessing" what might happen in future
> >       and how theuse of MIP can be changed dramatically. No one
> >       knows that this is true.
> >
> >       2. Multi-level hierarchy localises the signalling. Let's try to
>understand
> >       what this really means. A MAP domain is as large as the amount
> >       of traffic that a MAP can handle, regardless of the number of
> >       levels of hierarchy. The signalling will always be local to that
> >       domain. So I'm not really clear on the significant advantage here.
> >       We're certainly not expecting any inter-continental mobility
> >       management using HMIPv6. So careful placement of the MAP
> >       using network engineering skills and common sense is
> >       sufficient.
> >
> >> What I'm saying is that we have some arguments the feature is needed,
> >> so let's put it in. From Karim's last email, it sounds like we can
> >> probably accommodate his concerns about multiplying failure possibilities.
> >>
> >       => At a cost. The beneft MUST outweigh the cost. This is not
> >       the case here IMO.
> >
> >> If we don't put it in and deployment proves that we need it,
> >>
> >       => This is exactly point one above.
> >
> >       Hesham



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 15:48: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 PAA17484
	for ; Thu, 26 Apr 2001 15:48: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 MAA22517;
	Thu, 26 Apr 2001 12:47:49 -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 MAA11321;
	Thu, 26 Apr 2001 12:47:38 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QJjlK9020258
	for ; Thu, 26 Apr 2001 12:45:47 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QJjkww020257
	for mobile-ip-dist; Thu, 26 Apr 2001 12:45: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QJjYK9020250
	for ; Thu, 26 Apr 2001 12:45: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 MAA03953
	for ; Thu, 26 Apr 2001 12:45:32 -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 MAA29765
	for ; Thu, 26 Apr 2001 12:45:25 -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 f3QJjCO01105
	for ; Thu, 26 Apr 2001 21:45:12 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Thu Apr 26 21:45:12 2001 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Thu, 26 Apr 2001 21:45:11 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBDC1@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Cc: Basavaraj.Patil@nokia.com
Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L
	 ocalized Mobility Management Requirement s)
Date: Thu, 26 Apr 2001 21:45:10 +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: 

Gopal, 

Great summary. Makes a lot of sense to me. 
Hopefully slow routing will not be fashionable :)

Hesham


> Advantages:
> 
> 1. Localizes  signalling (Localizing signalling does not mean reducing 
> signalling)  For localizing signalling one level of hierarchy is enough, if 
> we assume that the cost to send a message within a domain is the the same 
> irrespective of the nuber of routed hops.
> 
> 2. Could potentially reduce handoff delay. Handoff delay consists of two 
> components that are relavent to this discussion
> 1) transimssion delay  2) processing delay. Unless over a low speed link 
> transmission delay is not a major factor. Processing delay
> is what will hit you the most.  Multiple levels of hierarchy add to the 
> processing dealy and so could actually increase the handoff delay.
> 
> 3. Reduces the need to update the caches in the CN or change the VPN tunnel 
> endpoint. For this also one level of hierarchy is enough.
> 
> Disadvantages of LMMs or LMAs
> 
> 1. The amount of processing for the data path increases. Every data packet 
> has to traverse these hierarchies. so multiple levels of hierarchies are 
> not necessarly good.
> 
> 2. The points of failure increases. Increases in the levels of hierarchies 
> are not necessarly good.
> 
> So multiple levels of hierarchy may not be needed if the cost of 
> transmitting/packet is not affected significantly by the number of routed 
> hops it traverses (who knows one day slow routing might be back in fashion).
> 
> I am not against multiple hierarchies, if the simplicity of the solution is 
> not comprimised. I personally think it is very
> easy to have muliple levels of hierarchy (see 
> draft-dommety-mobileip-lma-ipv6-02.txt).
> 
> 
> 
> Thanks
> Gopal
> 
> 
> 
> 
> 
> 
> 
> 
> 
> At 02:46 PM 4/24/2001 -0700, James Kempf wrote:
> >Hi Hesham,
> >
> >Thanx for your response, but I think we've been through these
> >points a number of times, we really don't need to rehash them again. Charlie,
> >Theo, myself, and one other person (whose name I've forgotten) have spoken up
> >for a requirement to support hierarchy. You and Karim have spoken up 
> >against it,
> >and Raj, expressing a preference for simplicity, has an inclination
> >against it.
> >
> >Anybody else out there in SMTP-land want to express a preference?
> >
> >Phil, any ideas about how to proceed?
> >
> >                 jak
> >
> >
> > >From: "Hesham Soliman  (ERA)" 
> > >To: "'mobile-ip@sunroof.eng.sun.com'" 
> > >Cc: Basavaraj.Patil@nokia.com
> > >Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L
> >ocalized Mobility Management Requirement s)
> > >Date: Tue, 24 Apr 2001 23:34:56 +0200
> > >
> > >
> > >> Actually, no. I'm saying that we have had at least three people who
> > >> have given good arguments, IMHO, as to why multiple levels of
> > >> hierarchy might be needed. On the other side, those arguments
> > >> are refuted by two people who think that no hierarchy is needed.
> > >> Neither side is going to convince the other, both sides have
> > >> good arguments.
> > >>
> > >       => I'm not sure who you mean by the "two" people, there is 
> > definitely
> > >       more (at least the authors of HMIP are) but anyway
> > >       after reading the discussion it really seems to me like the only
> > >       two (understandable IMHO) reasons are:
> > >
> > >       1.  In future there may be a need for multi-level hierarchy. That 
> > need
> > >       is not explained really. To me this is not a good reason for 
> > including
> > >       any feature. Ithink it makes a lot of sense of scope the problem to
> > >       what we know without "guessing" what might happen in future
> > >       and how theuse of MIP can be changed dramatically. No one
> > >       knows that this is true.
> > >
> > >       2. Multi-level hierarchy localises the signalling. Let's try to> 
> >understand
> > >       what this really means. A MAP domain is as large as the amount
> > >       of traffic that a MAP can handle, regardless of the number of
> > >       levels of hierarchy. The signalling will always be local to that
> > >       domain. So I'm not really clear on the significant advantage here.
> > >       We're certainly not expecting any inter-continental mobility
> > >       management using HMIPv6. So careful placement of the MAP
> > >       using network engineering skills and common sense is
> > >       sufficient.
> > >
> > >> What I'm saying is that we have some arguments the feature is needed,
> > >> so let's put it in. From Karim's last email, it sounds like we can
> > >> probably accommodate his concerns about multiplying failure possibilities.
> > >>
> > >       => At a cost. The beneft MUST outweigh the cost. This is not
> > >       the case here IMO.
> > >
> > >> If we don't put it in and deployment proves that we need it,
> > >>
> > >       => This is exactly point one above.
> > >
> > >       Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 15:57:16 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17650
	for ; Thu, 26 Apr 2001 15:57: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 MAA11483;
	Thu, 26 Apr 2001 12:56: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 MAA14370;
	Thu, 26 Apr 2001 12:55:49 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QJr1K9020284
	for ; Thu, 26 Apr 2001 12:53:01 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QJr1wu020283
	for mobile-ip-dist; Thu, 26 Apr 2001 12:53: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QJqoK9020276
	for ; Thu, 26 Apr 2001 12:52:52 -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 MAA12383
	for ; Thu, 26 Apr 2001 12:52:49 -0700 (PDT)
Received: from c007.snv.cp.net (c007-h012.c007.snv.cp.net [209.228.33.219])
	by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id MAA08277
	for ; Thu, 26 Apr 2001 12:52:44 -0700 (PDT)
Received: (cpmta 10348 invoked from network); 26 Apr 2001 12:50:37 -0700
Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129)
  by smtp.telocity.com (209.228.33.219) with SMTP; 26 Apr 2001 12:50:37 -0700
X-Sent: 26 Apr 2001 19:50:37 GMT
Message-ID: <004901c0ce8a$0daca1c0$6401a8c0@philneum>
From: "Phil Neumiller" 
To: 
References: 
Subject: Re: [mobile-ip] Protocol Decision Fixed?
Date: Thu, 26 Apr 2001 14:49:42 -0500
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: 

Phil R.,

So if I submit a new draft, that competes with the existing two protocol
proposals will it  be ignored?  If the requirements of the existing proposals
are suitable then its a horse race right?  What if I have a faster horse?

Thanks,

Phil N.

----- Original Message -----
From: "Phil Roberts" 
To: 
Sent: Thursday, April 26, 2001 1:28 PM
Subject: RE: [mobile-ip] Protocol Decision Fixed?


> Hi,
>
>     Is there a question buried in here or are you just venting?  I think the
> WG is having a fairly productive discussion of requirements right now.  Why
> don't we finish that before trying to decide whether to revisit the choice
> of draft to take forward?
>
> Phil
>
>
> > -----Original Message-----
> > From: James Kempf [mailto:James.Kempf@Sun.COM]
> > Sent: Thursday, April 26, 2001 12:50 PM
> > To: mobile-ip@sunroof.eng.sun.com
> > Subject: [mobile-ip] Protocol Decision Fixed?
> >
> >
> > Hi Phil,
> >
> >
> > >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.
> > >
> > >
> >
> > A requirements phase is usually gone through in order to define what
> > the protocol needs to accomplish. Doing a requirements analysis
> > subsequent to selecting a protocol is a bit like putting on your
> > bathing suit after you've jumped into the water with your cloths
> > on. :-) The tendency is to "cook" the requirements to satisfy the
> > already selected protocol. IMHO, we are seeing a bit of that
> > now, with the authors of the selected protocol arguing strenuously
> > against including requirements which their protocol currently
> > can't support. In addition, they seem to be getting support
> > from one WG
> > chair and an AD who may have some vested interest in keeping
> > the protocol decision fixed, despite the somewhat dubious technical
> > grounds on which it was selected in the first place.
> > Meanwhile, those other
> > members of the working group who have spoken up have largely
> > been arguing in the
> > opposite direction.
> >
> > If the IESG and WG chairs decide they want to keep the protocol
> > decision fixed, then let's simply drop discussion of requirements
> > and rubber stamp HMIP. I'm perfectly fine with that. There's
> > no point in wasting
> > transcontinental bandwidth on email any further. Clearly,
> > we're in the
> > "political" layer of the IP stack here. :-)
> >
> > jak
> >
>




From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 16:02:36 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17839
	for ; Thu, 26 Apr 2001 16:02: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 NAA17057;
	Thu, 26 Apr 2001 13:01: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 NAA14303;
	Thu, 26 Apr 2001 13:01:42 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QJwvK9020314
	for ; Thu, 26 Apr 2001 12:58:57 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QJwvAN020313
	for mobile-ip-dist; Thu, 26 Apr 2001 12: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QJwmK9020305
	for ; Thu, 26 Apr 2001 12:58:48 -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 MAA14947
	for ; Thu, 26 Apr 2001 12:58:32 -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 MAA06610
	for ; Thu, 26 Apr 2001 12:58:08 -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 f3QJvqO02948
	for ; Thu, 26 Apr 2001 21:57:52 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Apr 26 21:56:03 2001 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Thu, 26 Apr 2001 21:57:51 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBDC3@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 L
	 ocalized Mobility Management Requirement s)
Date: Thu, 26 Apr 2001 21:57:51 +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: 

> Hesham >> The size of the domain is something that is not cast in stone. It is expressed as the
> Hesham >> growth in network infrastructure that maps to an individual ISP. The world expects
> Hesham >> that ISPs will grow larger in that sense by populating the routing fabring with more
> Hesham >> and more routing elements...
> Hesham >> 
> Hesham >	=> The size of a LMM domain (or MAP domain or GMA domain) is 
> Hesham >	restricted to how much traffic the top LMM agent can handle.
> Hesham >	This is orthogonal to how big an ISP is. There is no need 
> Hesham >	to assume that an ISP domain = LMM domain. Actually for a
> Hesham >	very large ISP this is probably not possible.
> Hesham >
> Hesham >> yes you "guessed" right....SCALABILITY...
> Hesham >> 
> Hesham >	=> Could you explain scalability of what ?
> Hesham >	It's certainly not the scalability of the amount of state
> Hesham >	kept in the routers.
> Hesham >
> Hesham >	Hesham
> 
> As I have experienced the scalability benefit of the LMM, it will allow
> scalability in the number of MNs moving within the domain through the
> reduced signaling.
> 
	=> That's not correct. The amount of signals sent by the MN is 
	exactly the same whether you have one level or more. Unless 
	you are referring to different signals.

	Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 16:08:58 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18035
	for ; Thu, 26 Apr 2001 16:08: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 NAA21596;
	Thu, 26 Apr 2001 13:08: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 NAA16792;
	Thu, 26 Apr 2001 13:07:51 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QK6QK9020361
	for ; Thu, 26 Apr 2001 13:06:26 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QK6Pk9020360
	for mobile-ip-dist; Thu, 26 Apr 2001 13:06: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QK6HK9020353
	for ; Thu, 26 Apr 2001 13:06:17 -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 NAA23174
	for ; Thu, 26 Apr 2001 13:06:15 -0700 (PDT)
Message-Id: <200104262006.NAA23174@heliopolis.eng.sun.com>
Date: Thu, 26 Apr 2001 13:06:16 -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
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: BVqcOUavMpvfYpKGsfZbVg==
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 Karim,

>You are making a simple thing complicated. HMIPv6 provides the same basic
>local home agent functionality as in Regional Registrations for
>MIPv4. The same overall reasoning applies. Are you questioning the whole
>hierarchical/regional work? What I actually understand from your email
>above is that you'd prefer an item to be dropped rather than having it
>if it does not support the requirement you have put forward. Why?
>

I'm questioning the process that went into blessing HMIP as 
a working group draft. It looks more like sausage making than
engineering to me. :-)

A requirements phase (which is what I interpreted PhilR's email of two weeks
ago to have started) is supposed to define what the protocol should
do, not provide an ex post facto justification for selecting
a particular protocol. As the name "local mobility management" should
imply, the point of the exercise is to gather requirements for
local mobility management, not for hierarchical or regional or
any other kind of solution to local mobility management, and especially
not for a particular protocol design. So if the working group is
not going to open up the protocol selection process again, there
is little point in going through a requirements discussion. We
should just rubber stamp HMIP and get on with our lives.

>Also, I can't understand what HMIPv6 has to do with this. If you have
>technical problems with HMIPv6 please bring them up. You definitely seem
>to have something against it. You have already made these comments against
>HMIPv6 and I replied to your email with the 4 reasons you have copied above.
>As a side note, I see you've changed a few points: 3) went from a security
>problem to "slightly more complex". I thought you had said you didn't
>know what happened in this discussion, but now I'm confused.
>

To the extent that HMIP statisfies the working group requirements
for localized mobility management, it is as good a solution as
any other. In my mind, it does not satisfy several important
requirements around reducing the frequency of handover related signalling 
latency in certain deployment situations, but I will most definitely
NOT go through these again, because I'm sure you or Hesham will
have some argument about why my concerns in this area are irrelevant,
and I feel we've wasted enough intercontinental bandwidth on these
issues. 

		jak



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 16:22:42 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18620
	for ; Thu, 26 Apr 2001 16:22: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 NAA02654;
	Thu, 26 Apr 2001 13:21:57 -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 NAA18714;
	Thu, 26 Apr 2001 13:21:36 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QKJPK9020424
	for ; Thu, 26 Apr 2001 13:19:25 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QKJPnn020423
	for mobile-ip-dist; Thu, 26 Apr 2001 13:19: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QKJ6K9020416
	for ; Thu, 26 Apr 2001 13:19:14 -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 NAA13222
	for ; Thu, 26 Apr 2001 13:18:46 -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 NAA29932
	for ; Thu, 26 Apr 2001 13:18:45 -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 NAA25198
	for ; Thu, 26 Apr 2001 13:18:45 -0700 (PDT)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3QKIhn21098
	for ; Thu, 26 Apr 2001 13:18:43 -0700
X-mProtect:  Thu, 26 Apr 2001 13:18:43 -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(WTS.12.69) smtpdTxsyUb; Thu, 26 Apr 2001 13:18:33 PDT
Message-ID: <3AE8829B.893DC87@iprg.nokia.com>
Date: Thu, 26 Apr 2001 13:18:35 -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: <4.3.2.7.2.20010426111546.017b0d60@mira-sjcm-3.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 Gopal,

some comments below

Gopal Dommety wrote:

> Hello:
>
> Going through the Advantages and disadvantages of  of LMMs or LMAs it might
> be clear if multiple levels of hierarchy are needed.
>
> Advantages:
>
> 1. Localizes  signalling (Localizing signalling does not mean reducing
> signalling)  For localizing signalling one level of hierarchy is enough, if
> we assume that the cost to send a message within a domain is the the same
> irrespective of the nuber of routed hops.

Fortunately or unfortunately it MEANS reducing....since the localisation of
multiple movements does not translate to equal number of updates to CNs and
HA...This is a given ages ago...


>
>
> 2. Could potentially reduce handoff delay. Handoff delay consists of two
> components that are relavent to this discussion
> 1) transimssion delay  2) processing delay. Unless over a low speed link
> transmission delay is not a major factor. Processing delay
> is what will hit you the most.  Multiple levels of hierarchy add to the
> processing dealy and so could actually increase the handoff delay.
>

I would not touch on handoff delay..unless you want to get the fast handoff
proponents say that LMMs are not handing off fast enough so they are not good..We
definetely don't want to reach handoff levels equal to core MIPv6 but I would not
go as far as implying that an LMM is by virtue handing off fast...in that spirit
any LMM is not handing off fast by default..however it is definetely faster than
core MIPv6


>
> 3. Reduces the need to update the caches in the CN or change the VPN tunnel
> endpoint. For this also one level of hierarchy is enough.

you have just contradicted yourself with your first argument...I think I don't
need to explain this one..


>
>
> Disadvantages of LMMs or LMAs
>
> 1. The amount of processing for the data path increases. Every data packet
> has to traverse these hierarchies. so multiple levels of hierarchies are
> not necessarly good.
>

yes this is a classical tradeoff against resiliency...but we knew that ..perhaps
resilency-free and fault-INtolerant systems may also come into fashion...


>
> 2. The points of failure increases. Increases in the levels of hierarchies
> are not necessarly good.
>

well we know from fault-tolerant systems that the probability of having two (say
LMM-aware) autonomous entities failing at the same time is exponentially SMALL and
decreases with the number of the probable failing entities tending to zero. This
is the basic principle of backup systems ...otherwise critical systems would not
exist..

So the above is becoming as probable as 10E-5 or something like that...in that
sense there is a minute possibility, definetely not normative, that it could not
be good but then forget resiliency anyway since you can get so pedantic...

>
> So multiple levels of hierarchy may not be needed if the cost of
> transmitting/packet is not affected significantly by the number of routed
> hops it traverses (who knows one day slow routing might be back in fashion).
>

This of course goes for the existence of LMM also...if in core MIPv6 such cost is
not significantly affected then forget LMM just hack core MIPv6... What I am
saying is that we start considering BIG IFs which I don't think reflect upcoming
scenarios...remember murphy's law...by the time a system has been specified...is
obsolete...you want to leave multiple hierarchies out...be my guest...we will have
to devise yet another extension...

All I am saying is that a multi-level LMM hierarchy can only benefit ANY LMM
scheme for upcoming realistic mobility scenarios...like IPRANs..

>

Theo


UCL/ Mobile Systems



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 16:26:12 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18718
	for ; Thu, 26 Apr 2001 16:26: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 NAA06324;
	Thu, 26 Apr 2001 13:25:42 -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 NAA20280;
	Thu, 26 Apr 2001 13:25:32 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QKODK9020450
	for ; Thu, 26 Apr 2001 13:24:13 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QKODbs020449
	for mobile-ip-dist; Thu, 26 Apr 2001 13:24: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QKO2K9020442
	for ; Thu, 26 Apr 2001 13:24:04 -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 NAA19179
	for ; Thu, 26 Apr 2001 13:24:01 -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 NAA21353
	for ; Thu, 26 Apr 2001 13:23:54 -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 f3QKNeN27988
	for ; Thu, 26 Apr 2001 22:23:40 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Apr 26 22:23:39 2001 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Thu, 26 Apr 2001 22:18:58 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBDC7@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: Thu, 26 Apr 2001 22:23:38 +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 Phil, 

	Looks good. Just a couple of questions to help understand the last
	requirment.

> 10. LMM should support autoconfig.
> 
	=> I don't understand this one. Autoconfig for the LMM agent ?
	which parameters are we referring to ?

	Thanks,
	Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 17:00:18 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21502
	for ; Thu, 26 Apr 2001 17:00: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 NAA06480;
	Thu, 26 Apr 2001 13:59:36 -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 NAA20414;
	Thu, 26 Apr 2001 13:59:22 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QKv4K9020552
	for ; Thu, 26 Apr 2001 13:57:04 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QKv4TQ020551
	for mobile-ip-dist; Thu, 26 Apr 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 eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QKuxK9020544
	for ; Thu, 26 Apr 2001 13:56:59 -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 QAA09938
	for ; Thu, 26 Apr 2001 16:56:57 -0400 (EDT)
Received: (from glass@localhost)
	by onion.east.sun.com (8.9.3+Sun/8.9.3) id QAA09313
	for mobile-ip@sunroof.eng.sun.com; Thu, 26 Apr 2001 16:57:09 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QK8OK9020372
	for ; Thu, 26 Apr 2001 13:08:24 -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 NAA16924
	for ; Thu, 26 Apr 2001 13:08:22 -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 NAA12228
	for ; Thu, 26 Apr 2001 13:08:14 -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 f3QK87N26082
	for ; Thu, 26 Apr 2001 22:08:07 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Apr 26 22:08:07 2001 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Thu, 26 Apr 2001 22:08:06 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBDC5@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: Thu, 26 Apr 2001 22:08:04 +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: 

	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. 


	Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 17:13:21 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21848
	for ; Thu, 26 Apr 2001 17:13: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 NAA26825;
	Thu, 26 Apr 2001 13:49: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 NAA24801;
	Thu, 26 Apr 2001 13:48:56 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QKkjK9020500
	for ; Thu, 26 Apr 2001 13:46:45 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QKkiLO020499
	for mobile-ip-dist; Thu, 26 Apr 2001 13:46: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 bebop.france (bebop.France.Sun.COM [129.157.174.15] (may be forged))
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QKkQK9020485
	for ; Thu, 26 Apr 2001 13:46:27 -0700 (PDT)
Received: from lillen (gbl-rem-34 [129.157.174.34])
	by bebop.france (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id WAA13331;
	Thu, 26 Apr 2001 22:46:15 +0200 (MET DST)
Date: Thu, 26 Apr 2001 12:54:30 -0700 (PDT)
From: Erik Nordmark 
Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L  ocalized Mobility Management Requirement s)
To: James Kempf 
Cc: Erik.Nordmark@eng.sun.com, mobile-ip@sunroof.eng.sun.com,
        Basavaraj.Patil@nokia.com
In-Reply-To: "Your message with ID" <200104261611.JAA15530@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: 

> Not quite. It is only by keeping the external CoA fixed that you can
> eliminate frequent full-BU-sending MN to CN handovers. If the external
> CoA moves, then a full-BU-sending MN to CN handover is needed, in
> which the MN must send BUs to all CNs. If the CN is on the other
> side of the world, this could be upwards of 160 ms RTT. If there
> is more than one such CN, it could quickly add up. If only the
> local CoA changes, then the MN needs to send only a single BU, 
> to the LMM.

Yes, but if the network is engineered so that this only happens infrequently
e.g. when moving between metro areas then this might be a reasonable
tradeoff.
Or stated differently, if an operator has a world-wide network and
a hierarchy of LMMs with "global" at the top, and metro area LMMs below that,
then any movement between metro areas involves signalling across the planet
to reach the global LMM. Thus in this case you have no gain.
Perhaps there is gain for some other split. But I personally feel I need
concrete examples before I can understand when there is a gain.

> May not be possible to design such that movement between them is
> infrequent. What if you have a situation with multiple, small
> wireless ISPs in a geographical area who want to optimize signalling
> within their own administrative domain, but they are peering 
> through a larger ISP? (BTW, this is an example I brought up
> last week on the list if you care to check the archive).

You're assuming that those ISPs have sufficient mutual trust to
eastblish whatever security associations are needed, right?
(This is presumably a lot easier when confined to a single adminstrative
domain.)
If they are really overlapping ISPs (i.e. an MN might ping-pong between
base stations belonging to different ISPs) then what is the benefit of
each ISP running an LMM? Seems like there might as much inter-ISP as
intra-ISP local movement. Thus isn't a shared LMM for the set of ISPs 
what you'd want in this case?

> If the LMM protocol supports hierarchy, the peering ISP can
> support an upper level LMM that keeps the globally visible
> CoA constant while the MN moves between LMM agents in the
> small wireless ISPs.

See above. Can also be done with a single LMM for the set of ISPs.

> It doesn't have anything to do with the latency between the levels
> of hierarchy but rather between the mobile node and the CNs. 

Huh? Are you saying that the latency between a MN and a CN is 10 ms
it doesn't matter if the latency between the MN and the bottom level 
LMM is 50 ms, the latency between the bottom and level 2 LMM is 100 ms, etc?

I think the relative latency is what matter.

> If you
> can't arrange LMM agents such that you can keep the global CoA constant
> and thus reduce the need for full-BU-sending handovers, you end up
> with high latency handovers and frequent dropped calls.

Sounds like we almost agree on one thing.
Except that "constant" isn't the goal since that reads like looking
for a free lunch to me.

  Erik



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 17:22: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 RAA22872
	for ; Thu, 26 Apr 2001 17:22: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 NAA25512;
	Thu, 26 Apr 2001 13:54:48 -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 NAA26141;
	Thu, 26 Apr 2001 13:48:32 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QKklK9020503
	for ; Thu, 26 Apr 2001 13:46:47 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QKkkYF020501
	for mobile-ip-dist; Thu, 26 Apr 2001 13:46: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 bebop.france (bebop.France.Sun.COM [129.157.174.15] (may be forged))
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QKkRK9020486
	for ; Thu, 26 Apr 2001 13:46:28 -0700 (PDT)
Received: from lillen (gbl-rem-34 [129.157.174.34])
	by bebop.france (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id WAA13341
	for ; Thu, 26 Apr 2001 22:46:24 +0200 (MET DST)
Date: Thu, 26 Apr 2001 13:15:18 -0700 (PDT)
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" <3AE8439F.5F744F91@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: 

> So you have correctly assumed a common hierarchy for all MNs here..you just
> pick a snapshot for the individual MN...
> 
> It is like the analogy...I can see the map of the roads...but at the same
> time I can see my route on that map.

Sure, but the road network doesn't pretend to be a tree-like (i.e. what
I think we mean by hierarchical) structure (unless you are referring to
the meta structure of national roads vs. regional vs. local vs. cow-paths
as the tree-like structure).

Or concretely, if MN1 moves from LMMa to LMMb and MN2 moves from LMMb to
LMMa, what does the common tree look like?
Is LMMa a parent and a child of LMMb?

> Multicast has said it in a different ..perhaps clearer way...incoming and
> outgoing interfaces...but it is the same thing...stil hierarchy..

Yes, for one sender - there is no IP multicast tree that is common for
all senders. I think this is analogous to one tree per MN.

  Erik



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 17:27:22 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 RAA22943
	for ; Thu, 26 Apr 2001 17:27:21 -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 OAA10110;
	Thu, 26 Apr 2001 14:26:07 -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 OAA06260;
	Thu, 26 Apr 2001 14:25:58 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QLOKK9020636
	for ; Thu, 26 Apr 2001 14:24:20 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QLOJUB020635
	for mobile-ip-dist; Thu, 26 Apr 2001 14:24: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QLOAK9020628
	for ; Thu, 26 Apr 2001 14:24:11 -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 OAA28454
	for ; Thu, 26 Apr 2001 14:24:10 -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 PAA05525
	for ; Thu, 26 Apr 2001 15:25:36 -0600 (MDT)
Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.43.101])
	by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id OAA20497
	for ; Thu, 26 Apr 2001 14:22:31 -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 AEA16701;
	Thu, 26 Apr 2001 14:23:52 -0700 (PDT)
Message-Id: <4.3.2.7.2.20010426142249.017b2758@mira-sjcm-3.cisco.com>
X-Sender: gdommety@mira-sjcm-3.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 26 Apr 2001 14:25:42 -0700
To: mobile-ip@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com
From: Gopal Dommety 
Subject: Re: [mobile-ip] Protocol Decision Fixed?
In-Reply-To: <200104261649.JAA16904@heliopolis.eng.sun.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: 



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



I am not sure if this "fair amount of reflection" was done.

I agree with James that we should have the requirements and then worry 
about protocol selection/design.

-Gopal


> >
> >
>
>A requirements phase is usually gone through in order to define what
>the protocol needs to accomplish. Doing a requirements analysis
>subsequent to selecting a protocol is a bit like putting on your
>bathing suit after you've jumped into the water with your cloths
>on. :-) The tendency is to "cook" the requirements to satisfy the
>already selected protocol. IMHO, we are seeing a bit of that
>now, with the authors of the selected protocol arguing strenuously
>against including requirements which their protocol currently
>can't support. In addition, they seem to be getting support from one WG
>chair and an AD who may have some vested interest in keeping
>the protocol decision fixed, despite the somewhat dubious technical
>grounds on which it was selected in the first place. Meanwhile, those other
>members of the working group who have spoken up have largely been arguing 
>in the
>opposite direction.
>
>If the IESG and WG chairs decide they want to keep the protocol
>decision fixed, then let's simply drop discussion of requirements
>and rubber stamp HMIP. I'm perfectly fine with that. There's no point in 
>wasting
>transcontinental bandwidth on email any further. Clearly, we're in the
>"political" layer of the IP stack here. :-)





>                 jak



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 17:33:50 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23108
	for ; Thu, 26 Apr 2001 17:33:49 -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 OAA02832;
	Thu, 26 Apr 2001 14:32: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 OAA00365;
	Thu, 26 Apr 2001 14:32:37 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QLV7K9020671
	for ; Thu, 26 Apr 2001 14:31:08 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QLV7nu020670
	for mobile-ip-dist; Thu, 26 Apr 2001 14: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QLUtK9020663
	for ; Thu, 26 Apr 2001 14:30: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 OAA07474
	for ; Thu, 26 Apr 2001 14:30:55 -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 PAA05873
	for ; Thu, 26 Apr 2001 15:32:27 -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 OAA01286
	for ; Thu, 26 Apr 2001 14:24:21 -0700 (PDT)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3QLOIw25038
	for ; Thu, 26 Apr 2001 14:24:18 -0700
X-mProtect:  Thu, 26 Apr 2001 14:24:18 -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(WTS.12.69) smtpdrziJLa; Thu, 26 Apr 2001 14:24:12 PDT
Message-ID: <3AE891FF.F283253E@iprg.nokia.com>
Date: Thu, 26 Apr 2001 14:24:15 -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

Erik,

  I don't want to get into the design of roads but at the very least a main road
branches off to many streets, a main freeway branches onto many main roads, blah
blah blah.. To me it looks like a hierarchy (could also be tree-like) where the
main entity is a parent of sub-entities..but anyway ..it was only an analogy..if
you don't like it ..forget it..



Erik Nordmark wrote:

> > So you have correctly assumed a common hierarchy for all MNs here..you just
> > pick a snapshot for the individual MN...
> >
> > It is like the analogy...I can see the map of the roads...but at the same
> > time I can see my route on that map.
>
> Sure, but the road network doesn't pretend to be a tree-like (i.e. what
> I think we mean by hierarchical) structure (unless you are referring to
> the meta structure of national roads vs. regional vs. local vs. cow-paths
> as the tree-like structure).
>
> Or concretely, if MN1 moves from LMMa to LMMb and MN2 moves from LMMb to
> LMMa, what does the common tree look like?
> Is LMMa a parent and a child of LMMb?

same to both...what is the point here?

>
>
> > Multicast has said it in a different ..perhaps clearer way...incoming and
> > outgoing interfaces...but it is the same thing...stil hierarchy..
>
> Yes, for one sender - there is no IP multicast tree that is common for
> all senders. I think this is analogous to one tree per MN.

right but I am looking now at the hierarchy from the LMMs perspective not the
MNs...


Theo


UCL/ Mobile Systems




From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 17:35: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 RAA23149
	for ; Thu, 26 Apr 2001 17:35:44 -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 OAA13295;
	Thu, 26 Apr 2001 14:33:04 -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 OAA28778;
	Thu, 26 Apr 2001 14:31:33 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QLTTK9020661
	for ; Thu, 26 Apr 2001 14:29:29 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QLTSjX020660
	for mobile-ip-dist; Thu, 26 Apr 2001 14:29: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QLTIK9020653
	for ; Thu, 26 Apr 2001 14:29:18 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA27920
	for ; Thu, 26 Apr 2001 14:29:18 -0700 (PDT)
Received: from darius (darius [152.70.40.121])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id OAA19465
	for ; Thu, 26 Apr 2001 14:29:17 -0700 (PDT)
Date: Thu, 26 Apr 2001 14:29:20 -0700 (PDT)
From: Patrice Calhoun 
Subject: Re: [mobile-ip] Protocol Decision Fixed?
To: mobile-ip@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <4.3.2.7.2.20010426142249.017b2758@mira-sjcm-3.cisco.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: 

> 
> 
> > >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.
> 
> 
> 
> I am not sure if this "fair amount of reflection" was done.
> 
> I agree with James that we should have the requirements and then worry 
> about protocol selection/design.

and for what it's worth, the requirements should be listed in an
Internet-Draft (even if there are no intentions of publication), and each
requirement should be justified.

The WG should get to review, and do a last call on the requirements.

*then* you start worrying about protocol selection.

PatC



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 17:39:49 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23196
	for ; Thu, 26 Apr 2001 17:39: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 OAA08083;
	Thu, 26 Apr 2001 14:39: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 OAA09538;
	Thu, 26 Apr 2001 14:39:10 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QLb9K9020722
	for ; Thu, 26 Apr 2001 14:37:09 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QLb8K8020721
	for mobile-ip-dist; Thu, 26 Apr 2001 14:37: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QLauK9020712
	for ; Thu, 26 Apr 2001 14:36: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 OAA01593
	for ; Thu, 26 Apr 2001 14:36:57 -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 OAA06024
	for ; Thu, 26 Apr 2001 14:36:56 -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 OAA02151
	for ; Thu, 26 Apr 2001 14:36:56 -0700 (PDT)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3QLasK13321
	for ; Thu, 26 Apr 2001 14:36:54 -0700
X-mProtect:  Thu, 26 Apr 2001 14:36:54 -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(WTS.12.69) smtpdZm0VUB; Thu, 26 Apr 2001 14:36:44 PDT
Message-ID: <3AE894ED.42E23B19@iprg.nokia.com>
Date: Thu, 26 Apr 2001 14:36:45 -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

Erik Nordmark wrote:

> > If this does not elaborate on optimization then what does it?????
>
> Numbers!!!
>
> As in "I optimized the frob code and it sped up by 10% assuming this following
> traffic pattern" when optimizing a protocol implementation.
>
> > I have also argued about multiple needs for this LMM hierarchy, such as
> > resiliency to failures. Please tell me how would you expect to recover from a
> > failure of an LMM if you do not know where it lies with relation to its
> > neighbours..how are these connected? Does it look like a hierarchy to you?
> > When I am saying hierarchy I mean would the packet go through one LMM before
> > reaching the one that just failed...The hierarchy argued here can be used
> > for a multiplicity of purposes
>
> I don't see how hierarchy makes recovering from failures any easier.

well if you are an LMM and you fail it would be safe for the LMM above or below
you (ie. upstream or downstream) to take over. This is much better than leaving
the MN hanging out to dry...


>
> And a hierarchy does increase the potential number of single
> points of failure.

I cannot see the "why" here...


>
> Whether there is a single level of multiple LMMs or a hierarchy with
> multiple LMMs at each level for redundancy, you still need the
> equivalent of the OSPF hello protocol to track the liveness of
> the individual LMMs as well as the communication paths between them.
> The more LMMs to observe the more hello traffic will fly around the network.
> I assume, given a maximum failure recovery time of N (seconds), that
> there is a tradeoff between the amount of hello traffic compared to
> the amount of handoff related control traffic between the LMMs and the MN.
> But presumably the "cost" is higher if the MNs need to send lots of
> hello packets compared to most of the hello traffic being in the wired
> part of the network.

I don't want to involve the MN in maintaining resiliency in the hierarchy...if
millions of MN start doing what you say there will be problems...in a shell I am
not refering to any solution yet.. just requirements....


>
> In addition, if there is a hierarchy do you need to worry about the
> probability of more than one LMM node failing at the same
> time in a given branch in the tree?
>

not really...I only mentioned that since you said that a hierarchy increases the
probabilities for single points of failure...If routing elements have the same
probability of failing then it does not matter if it is an LMM or not. You would
have increased probability if two or more LMMs would fail at the same time...hence
my argument that this is rare...so it would look more like individual LMM
failures...and by the time the second LMM failure would come up the repair should
be in effect....





>
> So make some assumptions about a topology of LMM and then calculated the
> signalling and hello traffic and compare a flat and hierarchical scheme.
>
> > As for the rigour that you suggested...it is as rigorous as the
> > counterarguments...[...]
>
> I was pointing fingers at everybody (including myself) for lack of rigor.
>
> > BTW if we want to take drafts and proposals strictly by  rigour of numbers
> > (soon to come though..stay tuned..) we would need to scrap quite a few
> > proposals here in IETF, with all due respect of course...I haven't seen that
> > many figures in drafts...supporting their engineering benefit..in fact it is
> > more research that gives the figures and engineering goes out and implements
> > it...because it "works"...am I wrong here???
>
> Most IETF protocols aren't there for optimization only - they actually
> solve a new problem. The LMM is just optimization. Thus I think we need
> to actually do engineering here.

In that case I will restrict my wording on LMMs..No LMMs have provided any figures
so I have a difficulty believing one against the other...how about that....?????


Theo


UCL/ Mobile Systems

>



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 17:47: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 RAA23366
	for ; Thu, 26 Apr 2001 17:47: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 OAA19071;
	Thu, 26 Apr 2001 14:46: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 OAA08390;
	Thu, 26 Apr 2001 14:46:09 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QLiRK9020763
	for ; Thu, 26 Apr 2001 14:44:27 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QLiQdu020762
	for mobile-ip-dist; Thu, 26 Apr 2001 14:44: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QLiDK9020755
	for ; Thu, 26 Apr 2001 14:44:13 -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 OAA02320
	for ; Thu, 26 Apr 2001 14:44: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 OAA23047
	for ; Thu, 26 Apr 2001 14:44: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 OAA02528
	for ; Thu, 26 Apr 2001 14:44:10 -0700 (PDT)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3QLi6l21902
	for ; Thu, 26 Apr 2001 14:44:06 -0700
X-mProtect:  Thu, 26 Apr 2001 14:44:06 -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(WTS.12.69) smtpdM9OhqF; Thu, 26 Apr 2001 14:43:57 PDT
Message-ID: <3AE896A0.8C4AA0B5@iprg.nokia.com>
Date: Thu, 26 Apr 2001 14:44:00 -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] Protocol Decision Fixed?
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

I would be more than glad to participate in the editing of such draft.

Please consider me in if such request is in effect by the WG chair hats...


Theo


UCL/ Mobile Systems



Patrice Calhoun wrote:

> >
> >
> > > >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.
> >
> >
> >
> > I am not sure if this "fair amount of reflection" was done.
> >
> > I agree with James that we should have the requirements and then worry
> > about protocol selection/design.
>
> and for what it's worth, the requirements should be listed in an
> Internet-Draft (even if there are no intentions of publication), and each
> requirement should be justified.
>
> The WG should get to review, and do a last call on the requirements.
>
> *then* you start worrying about protocol selection.
>
> PatC



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 17:49: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 RAA23414
	for ; Thu, 26 Apr 2001 17:49:41 -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 OAA18124;
	Thu, 26 Apr 2001 14:43: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 OAA07774;
	Thu, 26 Apr 2001 14:43:45 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QLgCK9020751
	for ; Thu, 26 Apr 2001 14:42:12 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QLgBTT020750
	for mobile-ip-dist; Thu, 26 Apr 2001 14:42:11 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QLg0K9020743
	for ; Thu, 26 Apr 2001 14:42:01 -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 OAA07394
	for ; Thu, 26 Apr 2001 14:42:01 -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 OAA08709
	for ; Thu, 26 Apr 2001 14:42:00 -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 OAA02437
	for ; Thu, 26 Apr 2001 14:42:00 -0700 (PDT)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3QLfvM19981
	for ; Thu, 26 Apr 2001 14:41:57 -0700
X-mProtect:  Thu, 26 Apr 2001 14:41:57 -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(WTS.12.69) smtpdtpjLYe; Thu, 26 Apr 2001 14:41:52 PDT
Message-ID: <3AE89622.960537C3@iprg.nokia.com>
Date: Thu, 26 Apr 2001 14:41:54 -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] Protocol Decision Fixed?
References: <4.3.2.7.2.20010426142249.017b2758@mira-sjcm-3.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

I would concur with the constituency that we need to be FIRM on the requirements
first...


We should have done that way before people accepted ANY LMM as a working group
item...

unfortunately we have to pay the price now...but better late than sorry...

Theo

UCL/ Mobile Systems


Gopal Dommety wrote:

> > >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.
>
> I am not sure if this "fair amount of reflection" was done.
>
> I agree with James that we should have the requirements and then worry
> about protocol selection/design.
>
> -Gopal
>
> > >
> > >
> >
> >A requirements phase is usually gone through in order to define what
> >the protocol needs to accomplish. Doing a requirements analysis
> >subsequent to selecting a protocol is a bit like putting on your
> >bathing suit after you've jumped into the water with your cloths
> >on. :-) The tendency is to "cook" the requirements to satisfy the
> >already selected protocol. IMHO, we are seeing a bit of that
> >now, with the authors of the selected protocol arguing strenuously
> >against including requirements which their protocol currently
> >can't support. In addition, they seem to be getting support from one WG
> >chair and an AD who may have some vested interest in keeping
> >the protocol decision fixed, despite the somewhat dubious technical
> >grounds on which it was selected in the first place. Meanwhile, those other
> >members of the working group who have spoken up have largely been arguing
> >in the
> >opposite direction.
> >
> >If the IESG and WG chairs decide they want to keep the protocol
> >decision fixed, then let's simply drop discussion of requirements
> >and rubber stamp HMIP. I'm perfectly fine with that. There's no point in
> >wasting
> >transcontinental bandwidth on email any further. Clearly, we're in the
> >"political" layer of the IP stack here. :-)
>
> >                 jak



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 19:18: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 TAA24546
	for ; Thu, 26 Apr 2001 19:18:07 -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 QAA23402;
	Thu, 26 Apr 2001 16:17: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 QAA01786;
	Thu, 26 Apr 2001 16:17:33 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QNFlK9021003
	for ; Thu, 26 Apr 2001 16:15:47 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QNFfUI021001
	for mobile-ip-dist; Thu, 26 Apr 2001 16:15: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QNFMK9020986
	for ; Thu, 26 Apr 2001 16:15: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 QAA23196
	for ; Thu, 26 Apr 2001 16:15:22 -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 QAA11720
	for ; Thu, 26 Apr 2001 16:15:21 -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 SAA01579
	for ; Thu, 26 Apr 2001 18:15:21 -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 f3QNFWo12323
	for ; Thu, 26 Apr 2001 18:15:32 -0500 (CDT)
Message-ID: <3AE89DA1.4DBDD93C@usa.alcatel.com>
Date: Thu, 26 Apr 2001 18:13:53 -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] Protocol Decision Fixed?
References:  <004901c0ce8a$0daca1c0$6401a8c0@philneum>
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

Phil N.,
  Why don't you submit your new draft? You should be able to get a slot in London
to defend it. I don't think there is any obstacle for that. Anybody can submit a
draft to the WG of choice and get a presentation, except for Seamoby which is
curfewed.


Phil Neumiller wrote:

> Phil R.,
>
> So if I submit a new draft, that competes with the existing two protocol
> proposals will it  be ignored?  If the requirements of the existing proposals
> are suitable then its a horse race right?  What if I have a faster horse?
>
> Thanks,
>
> Phil N.
>

--
Behcet



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 20:22: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 UAA25261
	for ; Thu, 26 Apr 2001 20:22:33 -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 NAA20665;
	Thu, 26 Apr 2001 13:46:42 -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 NAA25669;
	Thu, 26 Apr 2001 13:46:23 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QKiiK9020483
	for ; Thu, 26 Apr 2001 13:44:44 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QKih44020482
	for mobile-ip-dist; Thu, 26 Apr 2001 13:44:43 -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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QKiYK9020475
	for ; Thu, 26 Apr 2001 13:44:34 -0700 (PDT)
Received: from lillen (gbl-rem-34 [129.157.174.34])
	by bebop.france (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id WAA13213
	for ; Thu, 26 Apr 2001 22:44:30 +0200 (MET DST)
Date: Thu, 26 Apr 2001 12:11:42 -0700 (PDT)
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" <3AE8402F.7AEF1C7E@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: 

> If this does not elaborate on optimization then what does it?????

Numbers!!!

As in "I optimized the frob code and it sped up by 10% assuming this following
traffic pattern" when optimizing a protocol implementation.

> I have also argued about multiple needs for this LMM hierarchy, such as
> resiliency to failures. Please tell me how would you expect to recover from a
> failure of an LMM if you do not know where it lies with relation to its
> neighbours..how are these connected? Does it look like a hierarchy to you?
> When I am saying hierarchy I mean would the packet go through one LMM before
> reaching the one that just failed...The hierarchy argued here can be used
> for a multiplicity of purposes

I don't see how hierarchy makes recovering from failures any easier.
And a hierarchy does increase the potential number of single
points of failure.
Whether there is a single level of multiple LMMs or a hierarchy with
multiple LMMs at each level for redundancy, you still need the
equivalent of the OSPF hello protocol to track the liveness of
the individual LMMs as well as the communication paths between them.
The more LMMs to observe the more hello traffic will fly around the network.
I assume, given a maximum failure recovery time of N (seconds), that
there is a tradeoff between the amount of hello traffic compared to
the amount of handoff related control traffic between the LMMs and the MN.
But presumably the "cost" is higher if the MNs need to send lots of
hello packets compared to most of the hello traffic being in the wired
part of the network.
In addition, if there is a hierarchy do you need to worry about the
probability of more than one LMM node failing at the same
time in a given branch in the tree?

So make some assumptions about a topology of LMM and then calculated the
signalling and hello traffic and compare a flat and hierarchical scheme.


> As for the rigour that you suggested...it is as rigorous as the
> counterarguments...[...]

I was pointing fingers at everybody (including myself) for lack of rigor.


> BTW if we want to take drafts and proposals strictly by  rigour of numbers
> (soon to come though..stay tuned..) we would need to scrap quite a few
> proposals here in IETF, with all due respect of course...I haven't seen that
> many figures in drafts...supporting their engineering benefit..in fact it is 
> more research that gives the figures and engineering goes out and implements
> it...because it "works"...am I wrong here???

Most IETF protocols aren't there for optimization only - they actually
solve a new problem. The LMM is just optimization. Thus I think we need
to actually do engineering here.
(I think the header compression RFCs like 2507 actually has some numbers
in there. This is an example of something I'd call "just" optimizations.)

   Erik



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 20:33:46 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA25525
	for ; Thu, 26 Apr 2001 20:33:45 -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 RAA24501;
	Thu, 26 Apr 2001 17:33: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 RAA14685;
	Thu, 26 Apr 2001 17:33:09 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3R0VoK9021221
	for ; Thu, 26 Apr 2001 17:31:50 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3R0VopM021220
	for mobile-ip-dist; Thu, 26 Apr 2001 17:31: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3R0VdK9021213
	for ; Thu, 26 Apr 2001 17:31:41 -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 RAA07844
	for ; Thu, 26 Apr 2001 17:31:39 -0700 (PDT)
Received: from prserv.net (out4.prserv.net [32.97.166.34] (may be forged))
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA23872
	for ; Thu, 26 Apr 2001 17:31:38 -0700 (PDT)
Received: from [32.101.227.180] (slip-32-101-227-103.ca.us.prserv.net[32.101.227.103])
          by prserv.net (out4) with ESMTP
          id <2001042700313620404ln2cae>; Fri, 27 Apr 2001 00:31:37 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: ahmrphd@pop3.attglobal.net
Message-Id: 
In-Reply-To: <200104242246.PAA08629@heliopolis.eng.sun.com>
Date: Thu, 26 Apr 2001 17:31:10 -0700
To: mobile-ip@sunroof.eng.sun.com
From: Arthur Ross 
Subject: Re: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L
 ocalized Mobility Management Requirement s)
Sender: owner-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 15:46 -0700 04/24/2001, James Kempf wrote:
>Hi Phil,
>
>>
>>Oh, yes.  We had talked about this on the CT list just today.  Lets say I
>>am a
>>LMM pool hosting router.  We know that due to just the physics of proximity
>with
>>other LMM pool hosting routers that any given host will almost always
>>hand off
>>exclusively with a certain set of "regular neighbors".  A security
>>association
>(sort
>>of a security web) is formed apriori with the regular neighbors so that
>>secure
>>tunnels are in place between all regular neighbors.  This makes the context
>>transfer very fast, i.e. no dependency on building a secure tunnel before
>transfering
>>it.  This allows the virtual LMM to simply walk through the pre-approved
>>web of routers that it is authorized for.  If make-before-break is
>>desired that
>>can be added for seamlessness.
>
>There is, of course, one problem here. The LMM agent doesn't necessarily
>have to
>be at the access router, in fact, many deployment situations would instead
>have
>it at the border router for purposes of reducing the frequency of globally
>visible CoA changes. Otherwise, there is no benefit for the mobile node.
>
>		jak

Pardon me for showing up to this LMM party a day late & a dollar short -
had other distractions, and the volume of stuff on this thread has been so
large that it's been a bit challenging to keep up.

Seems to me that there is a basic issue that has slipped under the radar,
in the realm of "Where does IP meets radio physics?"

Most of this LMM discussion presupposes that the attachment points come one
at a time, and that there is a CoA change propagated as a result of MN
movement, the CoA associated with the old attachment link being replaced
with that of a new link.

That's too much of a simplification, depending on the nature of the air
interface in question.

The attachment points may be multiple and simultaneous, with time-varying
performance that will exhibit high raw error rates. From a comm-theoretic
standpoint, you will almost always do better in bad link conditions if the
network can use whatever transceiver resources are available, i.e. listen
from multiple transceivers & diversity combine them in the network;
transmit from multiple transceivers & diversity combine them in the MN.
This is what "soft handoff" in the CDMA air interfaces is all about.

This leads to the need to distinguish between the addresses of the access
transceivers (which may or may not be one-to-one with access routers), and
physical radio comm link addresses (spreading code, or whatever). The
physical addresses may be MN-permanent, BTS-permanent, dynamically
assigned, or something as yet to be defined. That is a question in itself.

I firmly believe that the IP nature of the network should extend down as
close to the ether as possible, meaning that those transceivers (BTS's, in
"big wireless" parlance), should be the lowest level in the LMM heirarchy,
however it is structured. But if you insist on that as a requirement, and
further require that, within broad limits, any air interface be
supportable, there is a problem. The nature of the air interface intrudes
into the lower layers of LMM. The routing problem is complicated by having
to deliver & collect to/from multiple places. That first level access
(border?) router will, in practice, wind up being a
"router/distributer/combiner", i.e. NOT universal and air interface
independent.

I think we need to keep in mind, when writing this stuff, that distinction
between MN permanent IPv6 addresses, CoA's, and radio addresses, .

   -- ahmr


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 22:06: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 WAA27947
	for ; Thu, 26 Apr 2001 22:06: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 TAA15471;
	Thu, 26 Apr 2001 19:05: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 TAA22823;
	Thu, 26 Apr 2001 19:05:52 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3R23bK9021528
	for ; Thu, 26 Apr 2001 19:03:37 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3R23anQ021527
	for mobile-ip-dist; Thu, 26 Apr 2001 19:03: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3R23PK9021520
	for ; Thu, 26 Apr 2001 19:03:28 -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 TAA22540
	for ; Thu, 26 Apr 2001 19:03:25 -0700 (PDT)
Received: from c007.snv.cp.net (c007-h011.c007.snv.cp.net [209.228.33.217])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id TAA11400
	for ; Thu, 26 Apr 2001 19:03:25 -0700 (PDT)
Received: (cpmta 6050 invoked from network); 26 Apr 2001 19:03:24 -0700
Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129)
  by smtp.telocity.com (209.228.33.217) with SMTP; 26 Apr 2001 19:03:24 -0700
X-Sent: 27 Apr 2001 02:03:24 GMT
Message-ID: <00c401c0cebe$21907fc0$6401a8c0@philneum>
From: "Phil Neumiller" 
To: 
References: 
Subject: Re: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L ocalized Mobility Management Requirement s)
Date: Thu, 26 Apr 2001 21:02:29 -0500
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: 

Arthur,

Please take a look at the OBAST paper at http://federalmobility.com/.  I think this
will explain how to do this with CDMA macro-diversity selection.  The paper
describes a way to put macro-diversity into a BTS thus allowing BTSs, SDUs,
and RNCs to all be co-located at the edge of the network and function peer-to
peer.  What I have been describing in digestable chunks to the MIP list is
essentially OBAST.  Others have called it MIPv6, some have called it
MIPv4 fast handoff, but none of those address the CDMA issues (and therefore
3G issues) that you have brought up, except for OBAST.

Thanks,

Phil

----- Original Message -----
From: "Arthur Ross" 
To: 


> The attachment points may be multiple and simultaneous, with time-varying
> performance that will exhibit high raw error rates. From a comm-theoretic
> standpoint, you will almost always do better in bad link conditions if the
> network can use whatever transceiver resources are available, i.e. listen
> from multiple transceivers & diversity combine them in the network;
> transmit from multiple transceivers & diversity combine them in the MN.
> This is what "soft handoff" in the CDMA air interfaces is all about.
>
> This leads to the need to distinguish between the addresses of the access
> transceivers (which may or may not be one-to-one with access routers), and
> physical radio comm link addresses (spreading code, or whatever). The
> physical addresses may be MN-permanent, BTS-permanent, dynamically
> assigned, or something as yet to be defined. That is a question in itself.
> >




From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 22:29:38 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA28246
	for ; Thu, 26 Apr 2001 22:29: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 TAA10639;
	Thu, 26 Apr 2001 19:29: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 TAA25661;
	Thu, 26 Apr 2001 19:28:54 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3R2RhK9021637
	for ; Thu, 26 Apr 2001 19:27:43 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3R2RgKo021636
	for mobile-ip-dist; Thu, 26 Apr 2001 19:27: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.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3R2RVK9021629
	for ; Thu, 26 Apr 2001 19:27:34 -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 TAA09051
	for ; Thu, 26 Apr 2001 19:27:31 -0700 (PDT)
Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id UAA03787
	for ; Thu, 26 Apr 2001 20:29:53 -0600 (MDT)
Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM)
	id AA11578; Thu, 26 Apr 2001 22:27:29 -0400
Date: Thu, 26 Apr 2001 22:27:29 -0400 (EDT)
From: Jim Bound 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Protocol Decision Fixed?
In-Reply-To: <034BEFD03799D411A59F00508BDF7546013DBDBE@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: 

Just to clarify my input here as Hesham's note made me want to do this.
The LMM discussion to me is a requirements discussion for Mobile IP
operation.  Its end result will affect other protocols and methodologies.
I have not decided if Regional or HMIPv6 is the solution in my mind
technically.  Nor am I against HMIPv6 and in fact I like it.  But what we
decide about LMM will affect CT and the true goal in my mind Seamless
Mobility but I also think that requires pilc and sctp work to become a
reality in the stacks.

I don't agree with Karim that one LMM per cloud is all that will ever be
needed simply because the cloud will be too large in some cases as a metro
network (e.g. LA, Boston, London, Tokyo, Paris).

Also think about this.  I leave my office and I am mobile with my PDA
gambling on the horses and keep doing it in my car.  While heading to the
bar I hit another access router and then in the bar I hit their wireline
10MB xDSL access router and get a cheaper rate and jump off the metro cost
to the xDSL cheaper cost.  Still gambling in the bar on my PDA.  Then I
jump into a taxi to get home and hit the metro again.  Then I finally get
home watching the wagers on the last race in my house and now jump on that
Access Router at my home xDSL which is the cheapest rate for connectivity
via my access point in my house.  Win a million dollars and go to bed.

I would argue the above was all in the same cloud in metro LA and the
wager access was in the city seciton I work, party, and live in.  Its a
subset of the cloud.  And there were other subsets in the cloud (the car,
taxi, bar, home) which are LMMs.  

To answer Eriks question mails ago.  Yes there is a permanent CoA and a
bunch of more efficient CoAs within the subsets above which are used to
communicate to the CN wager machine.  All of this is possbile with MIPv6
too.  It will also make CT and Seamless Mobility more efficient within the
subset of the cloud metro LA.

Disclaimer - I am not a fan of gambling but do believe it will be one of
the predominant uses of wireless networks and as I don't believe vice is a
crime fine with me then ok to make profit from it.  Well what is the
predominant use of the Internet WEB? :-----------------) 

regards,
/jim

On Thu, 26 Apr 2001, Hesham Soliman  (ERA) wrote:

> 	>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.
> 	>
> 	>
> 
> 	A requirements phase is usually gone through in order to define what
> 	the protocol needs to accomplish. Doing a requirements analysis
> 	subsequent to selecting a protocol is a bit like putting on your
> 	bathing suit after you've jumped into the water with your cloths
> 	on. :-) The tendency is to "cook" the requirements to satisfy the
> 	already selected protocol. IMHO, we are seeing a bit of that
> 	now, with the authors of the selected protocol arguing strenuously
> 	against including requirements which their protocol currently
> 	can't support. In addition, they seem to be getting support from one WG
> 	chair and an AD who may have some vested interest in keeping 
> 	the protocol decision fixed, despite the somewhat dubious technical 
> 	grounds on which it was selected in the first place. Meanwhile, those other 
> 	members of the working group who have spoken up have largely been arguing in the 
> 	opposite direction.
> 
> 	If the IESG and WG chairs decide they want to keep the protocol
> 	decision fixed, then let's simply drop discussion of requirements
> 	and rubber stamp HMIP. I'm perfectly fine with that. There's no point in wasting 
> 	transcontinental bandwidth on email any further. Clearly, we're in the 
> 	"political" layer of the IP stack here. :-)
> 
> 	=> These are some pretty rediculous accusations 
> 	you managed to come up with. Are you going to 
> 	accuse everyone who doesn't see your point of view
> 	as being part of a larger conspiracy ? 
> 	Stick to the technical argument james and if you 
> 	find that you're argument is no longer valid don't 
> 	start these accusations. Let's be professional.
> 	Try to understand that it is not just the "authors",
> 	the "WG chair"
> 
> 	Since you brought up the topic, why are these 
> 	requirements suddenly rising suddenly against MIPv6 ??
> 	What is it that you don't like about HMIPv6 that made 
> 	you turn this requirements discussion around towards removing 
> 	it from WG ????
> 
> 
> 	Hesham
> 



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 22:39:48 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 WAA29318
	for ; Thu, 26 Apr 2001 22:39:48 -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 TAA23650;
	Thu, 26 Apr 2001 19:39: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 TAA02767;
	Thu, 26 Apr 2001 19:39: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 f3R2brIM021742
	for ; Thu, 26 Apr 2001 19:37:53 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3R2bqIj021741
	for mobile-ip-dist; Thu, 26 Apr 2001 19:37:52 -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 f3R2bfIM021734
	for ; Thu, 26 Apr 2001 19:37:44 -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 TAA02705
	for ; Thu, 26 Apr 2001 19:37:40 -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 TAA14064
	for ; Thu, 26 Apr 2001 19:37:39 -0700 (PDT)
Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM)
	id AA32190; Thu, 26 Apr 2001 22:37:39 -0400
Date: Thu, 26 Apr 2001 22:37:39 -0400 (EDT)
From: Jim Bound 
To: mobile-ip@sunroof.eng.sun.com
Cc: 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: <4.3.2.7.2.20010426111546.017b0d60@mira-sjcm-3.cisco.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: 

I agree with these.  But I think if the hierarchies are defined well the
traversals can be optimized.  In my last example when I leave the office
to my car to the bar to the taxi to the home the path for each point is
defined and so is all the signaling.  

Now sure someone could build this poorly as the current VPN/LT2P networks
in some cases I see today and it will run poorly.  We can only prevent
users and vendors from doing dumb and evil things to networks to some
degree as protocol designers.  If we try to catch every case we will all
be here till 2003 discussing it.

As Charlie put it mails ago we can have one, two, three, etc.. or none of
hiearchy but to not permit using indirection and distribution of task in
Mobile IP Wireless is not wise it appears to me.

/jim

On Thu, 26 Apr 2001, Gopal Dommety wrote:

> Hello:
> 
> Going through the Advantages and disadvantages of  of LMMs or LMAs it might 
> be clear if multiple levels of hierarchy are needed.
> 
> Advantages:
> 
> 1. Localizes  signalling (Localizing signalling does not mean reducing 
> signalling)  For localizing signalling one level of hierarchy is enough, if 
> we assume that the cost to send a message within a domain is the the same 
> irrespective of the nuber of routed hops.
> 
> 2. Could potentially reduce handoff delay. Handoff delay consists of two 
> components that are relavent to this discussion
> 1) transimssion delay  2) processing delay. Unless over a low speed link 
> transmission delay is not a major factor. Processing delay
> is what will hit you the most.  Multiple levels of hierarchy add to the 
> processing dealy and so could actually increase the handoff delay.
> 
> 3. Reduces the need to update the caches in the CN or change the VPN tunnel 
> endpoint. For this also one level of hierarchy is enough.
> 
> Disadvantages of LMMs or LMAs
> 
> 1. The amount of processing for the data path increases. Every data packet 
> has to traverse these hierarchies. so multiple levels of hierarchies are 
> not necessarly good.
> 
> 2. The points of failure increases. Increases in the levels of hierarchies 
> are not necessarly good.
> 
> So multiple levels of hierarchy may not be needed if the cost of 
> transmitting/packet is not affected significantly by the number of routed 
> hops it traverses (who knows one day slow routing might be back in fashion).
> 
> I am not against multiple hierarchies, if the simplicity of the solution is 
> not comprimised. I personally think it is very
> easy to have muliple levels of hierarchy (see 
> draft-dommety-mobileip-lma-ipv6-02.txt).
> 
> 
> 
> Thanks
> Gopal
> 
> 
> 
> 
> 
> 
> 
> 
> 
> At 02:46 PM 4/24/2001 -0700, James Kempf wrote:
> >Hi Hesham,
> >
> >Thanx for your response, but I think we've been through these
> >points a number of times, we really don't need to rehash them again. Charlie,
> >Theo, myself, and one other person (whose name I've forgotten) have spoken up
> >for a requirement to support hierarchy. You and Karim have spoken up 
> >against it,
> >and Raj, expressing a preference for simplicity, has an inclination
> >against it.
> >
> >Anybody else out there in SMTP-land want to express a preference?
> >
> >Phil, any ideas about how to proceed?
> >
> >                 jak
> >
> >
> > >From: "Hesham Soliman  (ERA)" 
> > >To: "'mobile-ip@sunroof.eng.sun.com'" 
> > >Cc: Basavaraj.Patil@nokia.com
> > >Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L
> >ocalized Mobility Management Requirement s)
> > >Date: Tue, 24 Apr 2001 23:34:56 +0200
> > >
> > >
> > >> Actually, no. I'm saying that we have had at least three people who
> > >> have given good arguments, IMHO, as to why multiple levels of
> > >> hierarchy might be needed. On the other side, those arguments
> > >> are refuted by two people who think that no hierarchy is needed.
> > >> Neither side is going to convince the other, both sides have
> > >> good arguments.
> > >>
> > >       => I'm not sure who you mean by the "two" people, there is 
> > definitely
> > >       more (at least the authors of HMIP are) but anyway
> > >       after reading the discussion it really seems to me like the only
> > >       two (understandable IMHO) reasons are:
> > >
> > >       1.  In future there may be a need for multi-level hierarchy. That 
> > need
> > >       is not explained really. To me this is not a good reason for 
> > including
> > >       any feature. Ithink it makes a lot of sense of scope the problem to
> > >       what we know without "guessing" what might happen in future
> > >       and how theuse of MIP can be changed dramatically. No one
> > >       knows that this is true.
> > >
> > >       2. Multi-level hierarchy localises the signalling. Let's try to
> >understand
> > >       what this really means. A MAP domain is as large as the amount
> > >       of traffic that a MAP can handle, regardless of the number of
> > >       levels of hierarchy. The signalling will always be local to that
> > >       domain. So I'm not really clear on the significant advantage here.
> > >       We're certainly not expecting any inter-continental mobility
> > >       management using HMIPv6. So careful placement of the MAP
> > >       using network engineering skills and common sense is
> > >       sufficient.
> > >
> > >> What I'm saying is that we have some arguments the feature is needed,
> > >> so let's put it in. From Karim's last email, it sounds like we can
> > >> probably accommodate his concerns about multiplying failure possibilities.
> > >>
> > >       => At a cost. The beneft MUST outweigh the cost. This is not
> > >       the case here IMO.
> > >
> > >> If we don't put it in and deployment proves that we need it,
> > >>
> > >       => This is exactly point one above.
> > >
> > >       Hesham
> 



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 22:58: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 WAA29822
	for ; Thu, 26 Apr 2001 22:58:57 -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 QAA18582;
	Thu, 26 Apr 2001 16:02:58 -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 QAA28005;
	Thu, 26 Apr 2001 16:02:46 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QN1FK9020956
	for ; Thu, 26 Apr 2001 16:01:15 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QN1FJP020955
	for mobile-ip-dist; Thu, 26 Apr 2001 16:01: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 heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QN16K9020948
	for ; Thu, 26 Apr 2001 16:01:06 -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 QAA29425
	for ; Thu, 26 Apr 2001 16:01:06 -0700 (PDT)
Message-Id: <200104262301.QAA29425@heliopolis.eng.sun.com>
Date: Thu, 26 Apr 2001 16:01:06 -0700 (PDT)
From: James Kempf 
Subject: [mobile-ip] Some Analysis
To: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: MULTIPART/mixed; BOUNDARY=Army_of_Caterpillars_697_000
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: 

--Army_of_Caterpillars_697_000
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: WrUF+7z3WQUCo/NpVd2dtQ==

(second send, first perhaps filtered due to size...)

> Numbers!!!
>

After having unjustly flamed Erik this morning and being inspired by
his challenge, I went through an analysis comparing signalling
overhead on hierarchical v.s. nonhierarchical designs. The attached
zipped PDF (sorry for the zip, I couldn't get a unzipped through the list size 
filter) and text explain.

Note to H&K: Arguments about the analysis are welcome, but please
don't post "this won't happen in practice" arguments. You may have
your opinion and I may have mine. The math speaks for itself.

		jak

--Army_of_Caterpillars_697_000
Content-Type: APPLICATION/octet-stream; name="lmm-analysis.zip"; x-unix-mode=0664
Content-Description: lmm-analysis.zip
Content-MD5: IJHJGNRPNpfv7molbHaa8A==
Content-Transfer-Encoding: BASE64

UEsDBBQAAAAIAKV1mir3319kSgMAAAkIAAAQAAAAbG1tLWFuYWx5c2lzLnR4
dK1VTU/bQBA9Z3/F3Jq0AbXXCioF2gokkgtIFG5rexKvst51d9dJ01/fN2sg
CaSgSkVCcjzf770Zf+W5cUypZpp7a/3auAU5TmsflsQumWQ40rC1rCNT5N5V
l6VvWu024l0ZvQi6GX1WanAxITqiC98wTRYIV4PpTN5MfWEs08xXrAbns6EZ
4aVJNZ37EDi23lWSqrc3sCWftCXXNQUH8nPKMWpwNZ0OlxK7ROyVL7U1v7nq
05u0oal2esEhOx7dwO/Gt2R5xfYVbxqaOdWGgw5lvSETybiVtyuuRkpdcZLB
7pErmoVDChmZrd5QAZiYHWFo7ZB2pgY/+sn+5gkwxPNhmLt+lDec+5HV4Pal
t7Zb737gnQB1y+SLyGElnOkE/9b6zBg8yDsEN3oJdiM7cAsM9lWgIIyfHWpl
CdTeVgLEdx9IW0tmvPxMedwvX+gud/hoguF++/a1Rh5BN6Dm1a7Utq1Xu0Lp
jNPJaa4+7hu53WvPjCm3vhw92dRXdj5lbaOmjvQNJZLxjj4d5/6dXxN6LDur
e7cdHvyKQ826AnSBCg9hJi5rZ352aBCEqLwrgZFp5t3eyCWWSh0d+FPqOuff
kUULodZI5+dzAoh5AYBY5RttHA35V9nFvjWMkpsfI797l0gtOEm/jQZ4NLk+
v7zMyzqMXUOGTukj1o2azOaIPgCzDz136rprW4+skGIKGnNGGakMPkZyO+Xj
MRZNFjZuu36CxUQpJrWWj7XQ71vFpbppWmvmopTcrqP3dDBM4sQoscNnhXIu
Uuribdwz0zoiAVPNAarFZZx3kEwEgPkIjbHrhemPVddWEEMUMgT1ghfGORgU
6gb8iAmMiYV/4Qmw4NhNjv+VWZk8S/p/cvIW+89BHN71HUgjwswECTfRRLWF
7uFOThB0MLManD2anrODL8IB020vgktHPlRASLarV/f+Dj3pDFEF49gDB5wZ
p8T5oOf42aFb+85WYEDuU86RQsdPipvI4PnpXp7O6IRo8oDTGf7PXwgVgfA/
ok8jCZfo7U/kOJGQs05UI5+aKPtKoDSaAp/IYpO727ty2NrtQSJdYBDo6Kbu
4njnFmWG5T65ciMhL+YX1dPaQM/arvUmqkJUmyBOZPsDUEsBAhMDFAAAAAgA
pXWaKvffX2RKAwAACQgAABAAAAAAAAAAAQAAALSBAAAAAGxtbS1hbmFseXNp
cy50eHRQSwUGAAAAAAEAAQA+AAAAeAMAAAAA

--Army_of_Caterpillars_697_000
Content-Type: APPLICATION/octet-stream; name="lmm.zip"; x-unix-mode=0664
Content-Description: lmm.zip
Content-MD5: bGmwsx9txYBhTjLgHuw15Q==
Content-Transfer-Encoding: BASE64

UEsDBBQAAAAIAOd1mio3ZtnWi18AAEA7AQAHAAAAbG1tLnBkZs29265l2XEl
pucC8h/OiwDKQCbn/QIIAihKcsvdlGmq4G5b7IdSMVms9skqdVbRlvon/eA/
sH/Ec4yImJd19q5KUvt0NwFRyThr7bXWnBEx4zIi4k9/+Vd/89a/828++9P/
9//7v/+fP/mTP3nzWX5yT9/+439689mf//mbz376795/89X3v3sqg/irN5/9
xV+8+ey77z++/+LDm8/+85vP3Dvn3NP+37/6H436f7357B+e/uO47TeD8vQ/
4b/+E/9WPa6tDf/dwtPHr9589tanNG5qT29Ddu96yk8fSHTvcnCL+AxiLO9a
1Ctbi0qM73yuQqy5CzH0d6V0IeaqV4b8rje9MoaixPAudb3SeSX6/i52PCj1
d9UZcdzunRBj1Ffy4V0TYnvXiz7I9Xd5/BSJuXsllnfJZyG6mJQY32V+e6rv
Uq1KdO+KCyCW8cJye6/ji7vQ4lhi0vI7X/mY/K6mILTxOeM1SHNF7x23RN47
nlblyb2N5/G907uQ9QvdYIcWhdhqnq/Yuj4l1hcfMxYltPnZMeh7p5DmArmY
hdiyfqFPY1O9fHYIumd+rEsKQiwl6PaMVzJir0Yc75yiLGVoRqzvohFT0VeK
YyljFWL1eXJMj0H3zOkXRbxJkd11Qa+cXAhi05ef/LqIv3vz2W//h/syEQYz
/EEyEfzYbr539O+i95SJEMbbZLzN+KqsXBkGq+aGpYzhXfFeiWMFUwIxvau1
K3GwSyCxcFGEGMbb4WPiYNUsqxbcWKzIzx6CkpMSB09k3J7Gjqr0hMGq4w8n
a/nBlzH3kwd9d+Pp9WRg39L4unRh/9rGBfUiPdUP4QsX4SvjQfyiLCtIYh63
p3YR/TzYqJrmCP6ykbuOubG74/ahWvpVyvNguNovvFXGOjS9cmyYEocWEeLG
2XUIbWsXwWj+XZJv3+SqQe1dxbKPK9uLlS/vfNQ9CjVd92h8e+pzN0PFb8ax
nioDweGLSBzvGYwZhiqlgox5KIJ0ZZuxXF2v9PFdLU1YcTxMiYMDhZPHaxiD
Df5M5OShp1OOP3Tl0BTRy5VZF/nW7Q+XwFYH8+FthjDEoS0+KNFRsXtIoH7h
2J5AZTYWpaoyC+Bsh6XEVykXDlU1uBBM7Ms4qvRjan8XChSkb/x+IQ7mqHg6
ZL6rsA0ZqGTNcWbFqE8vQ29lLtDQarboBduDp48jLxZ9UJbTZBCH/E/i0C+F
xKFfne7uYD5fuL6D3ZU1oSAq33MselPtjp32tV5U0nioc6q8nFsq6dBo9/kA
2p3qeRB9UuL4/UQZGK9Ukr0SFFkSouv67YP1S9IvGouixHEmUHmNbw/GxDm+
K63IKmEHhTiUTnyxnsPGkKULQ9jadeWHcrGXr0NT8KyFXraXr+OLqPuwCE5v
r4MHUhFmGJbNZAawI9km2IPa+PbQhMGiCcbQFEEYbOjoWiaxUiko077K0TTe
ZqiWoZYyz24Khoe2y0JMJqawt2CfgFj1SA3j8I1jWanV7OzmOeN5ZZ2HL60f
xwe1aZnNPfNtMEe0PYMOA7HjhNQrC9RJeKKm7M02sg/9jd/s43fyZXtwcCVT
kOMU8o63D6VY+lzfjHPA9/HErE9vg1GoFIb5lL1dWYYxQ/UxHmRfNNWHw8q0
STwUzb2N3LZ8WF++pMkcgTIwHtSnphhCIrePs9qnyXC4iweCMxmokbp2fNHY
QVPkOK8qP7MMqdan47CFTvF9nEKm5sqQ8OxkPaOxe87jk9Nl5ccR6nuTPTJj
FQdaxhGK3SxhKZqIsxr7XoveHj314MkMQ1OU4IRtcrNjRBUNiGEqmsm09fVs
Nj8e7ITdYap+UFOqh01a7EiFCnxB5Dl7JbYeLsSrBN77wv32k6gPOon6Sjtx
vvxOHJztqwhwMpV/78rMLf+R2x+9E0Nuhw7HF45zMI5FoUfpYR8XISbl9On9
gdhUyj0ONVhmMObs9PQJ9havTOPIc9MuTJBIWKLeLN2MteCVQ8OpZvbjsHCF
vzlMq6gPGoon4ayBgejN5zAT0OMosfdsODiwkXV8Wjdrb6gWOGH4nWwPGnIM
xTaIhcIhiz7OL3ipsK3rthNVmGMIcV0Mlx0V+TAr7ei/cvYP8IGalbDsXbYr
h+wWJw9qLc33DAXbMY686tX87TC++fJjlcx2h6anioJRlI04bM3IK+Ge6tKN
uypPobFK46hW4jido65n8UrEJhZb+Wnlw6nFexboGN1iepNZdrOpfvXDaO7C
YGNBnLmVnmcXiWZ4wH+tFAwcR2bQw3oOTYhxOt+TacX+eQXBGN/SShQmdE28
yqGCGRTB95UkL4gIhQjAODJ0F2EotiBfV/WUy0P/1qpf3GQZMvx0L5/R9egZ
p0SQNRwMrwcC1oN8usnTWPcUswhe7fKMsZWebDZoEEDSxgHj9Doz3AYb4adJ
c2pbDyYZgn1KN5yplIRWlBnHkdR5tG2qYbBi7llpap5Z0MT0ymXfbhLnZm53
bzSsflCayvU4NeEgH9wx5L/4fq7gEDEf/claMBVTP1cfhmbRXXK2qmPhqjJw
VHMatlFT/i0q+oMBUq8no0MrduWYYDvs1FrauGiIE4xd4TbjmKFVfBJaVN8+
I9xVhdZUFoejnIU2jAHVYsPRLfK9P3LdWI6ehFY1enHj3gcLFywhhxVNncGp
IVvZ68ciZiGLh9iJ16uy6DLEL8nMqVMSB2nYNZE7gRBG4hf44XwjpoJIRpCr
xqcjYDUEdAipfKZTK3wss1N7COuMdxiyGorpNAbyBm3Yu+ZxOvHuoARbMZNv
GMt8AsJswojjbMy0v3Of6pDRAi64525wwT3XWc5QJ68y3Mpc+nlaXlXS3Y12
pkfLdPXGc1O8CMp4v15VlOFeiY0s4Vi83zDn1aAcn5TkO8w/hzcq67K+dxx9
iQ7D0GtOBQVRmCLL1yQgGii8XOTmyf3DxuKZNXaiidbCr5NBsDlyOAWJ23IL
k9jZiKfQjBv73JLxjPDzICUxaMe/ELiUuJbEoyb/gSRO94M5HBZFpmIa9kYt
NHB5JtuRq4EgHMmq1Dq1B2k4Avqxz/in7/1QYNg2PZin2gVLMqLnh5bRuAeE
pYo8NB7apA0FTB9h3FBEMXmsJ/krIyghtLHsnk4LtZG8H+SLz8jBHO8hlYM1
gsqcmGcIuVOkkUIQV7xBsILIbxXLbqxFCyrlsdRje1Q93N6xcWNK5xMbjr0q
pCyLOey+nr2+q/hCfhheLuj7d8mCeMTjeHQOtnQ+yrePU48yM9YjiAcLw2Us
maxbluPeR4TGm6yvd7q+hRyxy74tF2WrdHnGEJVKx33IfpF45bav83DBP1uK
h5xDZ2e+y7DWnGg1/NPTvR/LE0WmacxxWZQXX4PdAz13WtIInJ/sXhn4ehZa
p04f1/XQX9DUCsc/oxj24x/+Jc25SVMxm/buQYu+v6CBkU7aXJZbS7XRtns3
2nzGRkspGi1RH+3vN2njO9YzxI7Zv3ejlRYu27ut31DPQqvUJfeuK8gGgK0q
kkfp3r2PZo0WJG1n2wbWaJAif9lKHOn9QoOR2y60cTaUflm+uZUbbVh1+Uoz
bats+nyDde8uaWJs66SN3Zf3G7RwZcmNVpm2OGnjNA/6jKZaaK3Boq212mhz
TSftwdsWOpxGjdTBJP4A2tCXVEy9Dw6S03xY4IGKc8W/QhuKiUoNPqosKYL8
LWiIsYgUIYLbJXo1Dj/9PSxz1kCIhqQQPZZIJII4XWlOT3oofXFqw1CwjRY9
nGfxKhE2i4FetrM0D7IzQYIBnQlX0BD9j/HYXmQBQ9Yt8hKphdcukQDss5xq
CC7UVE8WurL9nW1jMDCfbIUQROM7I70nih1BbteV1sUIQ9i9CjvPuABixo7G
WoOVKusMA1Oiw4EJO9LG2vP4xPpF+b1clXVbokrmOieGnhm6KPouQ7sEsik2
Wtd0iEIO5A1Rb7q/jMz6DhdPnjseJwfj4I0qhn5AzLt74aEu5zZCvZ5Gxgof
g9ZDXDz5CmyfsdNBk0mRBxlitLmEI3kB9qNzguuCsvhYKoYCkM8IypKDdRke
RtQ/Ol2WYZvmICkOtSvA9jmHI8MRwCWMiw8+dEGXAFF75kxk73VJg6TKgrlA
WFLGExGPUrNqLZ8fL1/kGZA8pjGRx9b36wjOkFYZsnsW0fftDMdPdQCZyMoa
jG13CbF7FdWrKrmzlaAhJ8h7nbGGsgGeEZ2+c9HUq8v0ho/vdcV8AagczSs0
ygRpQZx0BO9Cua6p43HDtW+WR/IMHJJWxHHfkpfICURmu7f9wAHfNJ/ZlJ3h
w7cge9lau/DLeGcV3+IYINzTX0hG0pDasp5QdSXnI3eG/GToypO+hB+6TnJ5
g6a+xK17H20IAL+SmNn3VOcfxPyNvgqtSQZRwh1RaFnSVlCOjss3aKqxoZCi
IHAm8gJZKe80VZ9CNm2ayH4R1oRqU0/Fxey9V1H1yJKFI3mPFCgy/szdqzlN
8AhBPhHOpmpdnHj9SOMSbEDWXblZ5FaZ2UHCVd16LH0j4gG54KwnWWLsmUnU
pt9xVU33tpyOlCZgg4oMcBOEBiFhnJ29n2auwdfCBmPZXLcUt6qICARRke8o
Kh7jn45glJWhxmmkqeyhF1RdDc5mlIU/oiI4JM+RJcc6Z6N5BhOZpq6yLvNk
xB5VdbWGSBemjLGX6laZn4GXNz+jCKqKtBo1KiSmMGlmwC2eFIP5Fdh+LEty
WR7RBZ7kAzB5Rdg5NPU2oyLukiQ1SJNkkIhCV28TUJ0stKoe7Tj0W3WnGIGz
mcKEuDn93KFdcrvQkLsvSyyfb4jqnaXa7t1o8xluuhnrXTYaOLGe2zG+rRcV
36bG1ViDxtMXW6lbHsQ7Iy1LFhrZg0K2X6IPmFynCO6/d+u68Qpe3yVKjOjW
vQ9mDRx3hG0WWskfVtwLJkdXcS6Mu5BUJXEF/URAEWKSGivVBD4UR5c4W9Zs
NUhRxKdoSp7IAJF4pK8pFLCd5awfujaQOaGYxLqD2GVFmCokDGa8YQCLbGkf
x2xQPJdmuWasBXAup04xkqpJgVtFAvRAOTYBiCVqYd2VSMWdhl0jUcAX0nRv
l2G6F5WcmHSXnWQ18XtNDxaYM0Tq4Lmi9IEprVFxoQqRgLEqXzsBaMi4e4W0
KUYVmCXiYRYeriJ+lmXlvEhmMRDDWF8nFjqsScrWWnILW2JjspwKOFAEqIsU
ZVRWcARyrh2FNg96VfcaZaT9SFbwYuRN3kNy71Uyy1d0LRJoC1072FTTKx3H
nyJhQ9TUzHhhgaIOW0DTmPDpnGKCDeqIaElTzGlWgMywvnIpTwemEUFv7jLC
wpoEQ7COOglhOY1+jz+LtY64s2JWLOkHWtVU1NBnKoFTtt4CPpuU1tIZOYek
Bk3rABotm5HXdwj4B6SmS6DpiU0TXNTFzU2EJVSPjX4LuEdTdmgzqdHpbGyf
BLSWU7aJhiRBnjDLEnXNJ44DOpWTL5GESFE5umtOcOxIE43kaeI9S5ZLsF37
1gQ1tBESVihyaYoS3CCkw9AWR2UDNyOE0hXobeBvJLuTsp2hQoeoBqcA7iaC
s7HnkBzLY94Cf9+6Lg0l5IVmaIAb9z4cq8H4cnqCm4wQCqEayCuPHzLas0It
etTrDIWO43tIEmjVMAApMpFFt3uyhmM6DFCuYDn4WJjfBU3deALD4eaDZtyO
49s5vEtb3I7EmNImQDlEogtA6xO8Plhi6HO4+9mwwIBmD5EnCMsQz4N3sQ2g
TcSy98zGwooM2bLKnU4xaM0vJD4cPSC9Urd7HfPohIRVQ9cHqhDQDOfFA6XK
vWVeN1ixB9K8lVjod+C5ZdZNjLXyjTSvWFSsC84KfEfRPBsqMVyUb4sGcQHA
ZtCwLs3WD/ErpZnWQxIC/AdaMOw/LEmlOcvR0VJIXHtTNcBt4JA2PIzwkGeB
AvfNqg4mrwHnYUAQ48lJezhYbPgYYGc6E5Itpj9RhtKGm+w0h47QFyAWxEEb
am7cW8fJSpfdQN5jmcPQwHD3+4THFaLrCc4yZCB9L7BBpfogDbZGxrYh3LVw
1wjU7ywEJyflfLAaAT8hnmzaJSV3sDhUjouneAAj6dopWoBxDFGBCCaDNDEr
lk6RBuKkCq3GeNm2XW282EqmG+GpHOKL+FXNJwsRhFTIatEKdhq8knqybuuE
NR1sP5z27OIhMvg7nLVd3Ljm7bLOHpBOx/0IBp+c+1Eswijht9K5v2GCpz0z
CdirbrBThFSHqmPYx05B4w0/xNgQs/RKQMv8m9Aaaw8Y1jMeAhaTfNosb3n7
Ooh+qLzOKeTtxr2PFq2IJR9aHJYzQGAflIY4A9xuzSoOGrLJ4/ViWnh2sAmW
GWEQW/rBTmEc4oCgGx6PIcFhMfCzTdzABkN7Y2n7RGlnRqmJMLdnNE/ITeCJ
sbC5cbAsxNM3QyB7ik+gY23I3OEdZSxpp/NCWu6M6GNJs6Eb4PkMMcN2zJIE
2KI1XtRLZ2wJaigbC11U090th3Ye6gK0ZDhbAHrB4lAphglE8QzYebxzMtQy
wn9Rvi0airsEljeBhQ2pwlDz2FhWPHiDawdihc/1q0xDIxTUNzC8rHOhZSO0
sdc4GVEwYO/cGrMpYNeJGOmOsSV8d/Jrz30Bv8QJ6wxAiQXw2nCJjO17ZvyK
YTgDeffMeJjx5GucKAEg0PEIwNBC1hMF//akeZNAGEMwIopfMG6UXw2vFDQ7
aGFuJ4hMcetUIGRhPGOwXDbgkG0RgBhWbgHD1oFWpu0cmBscWwQXwU4tRLML
fi/OQry5HYA1maZDpB4GEhzOlueSIuLLQisFGEF8Hd4ZSAUtEoOYI1IJG1az
xksdIARV86TtauPOtq3thRNuNSeDDQBMoZ1soNkuKoQOt639YCsE6LnexuKt
MtILX8EKMZH9aDDW4E0bihYnI1REDkRCCW2wHcQS4C5jZ0Y/3LnORBdm7kfz
tr+N4AyEYHtYagMgcvytWoUAAhowCPc9Ry2QL6RpZGapDYB0TG1MnhwG6et4
5CwyCcK6uVmhZGTQxkTBDkFEIK80HowXGtzCk3aK1p1P2+49afKMkybvctLk
nXeaY0wE3+ZNY9+5jqz7w/c+3HXzKL8aSz8OOd+cuG5D2VZIVkPc39DS4mpB
2g1xCywRogig2YEHSFKGyzO4P5rrAbwrpK0B22WI7kigNethrOoTiALYLki/
Wy0mMrk4KDTvddhlAMWatMGdgnYBusKkctjHFS5PDatSB/Z2Gu9SxRUVWmU+
IgBrui09DuyAgP20zxHLgiaOlg1+wbp3t9zsPNSWznI6wKhwb2ahu71fxKFf
pAJGvqMR8wut0OwZcAFhx1dEn6w8t/I0gOYuVkSPKNbQeoGIELPZ4abJ+pk/
guw9ot5Y51jMZpd6QOyHlcEBA5ah/ZojOFL2PFFTYy+Lll55lB/i1GqrzBHu
YQPbN/FfnpXXUP4LfvHTpTWejHT1XoHtiwDsWJWnVT65MxcLklk9OHFJ8tP4
gO0GGwVBPz2cwDUwycZXhTLx7g5WRkMZo3w81p/rFokNJakRFbKLCoAYUa6y
2lKU2IGZeMwqCQ0NPElmUPXI6hGQJvi9Ms5+SCy8F3idMKGs/sUJeuyQ9sFx
pXvRCn4VPDD4oJri3KlbtLl7270bDek2LmVcoObxLoClH9yARLzPx8rB2Qz1
YCQYcSkfSw77r8jGJPUXcE5XuSooyBnr2rzsqAo18u49HvwMcJeSohoCNYk9
szEMlIoTHtJE6FuUCsGPbs5AvqyaoPpCfwuF6AN7JKSgNwKAScX3w1ch0ugo
tk1DAS9vfLD0IKgJjhy7AEjgEB6AuBFHwr4kxSkQRkFjzmnaVNgMsTp5LS9o
HVC0UgeQC9xUWFbET5YDGt0IumkWMYcR66zmWI/NAQlhMSvTZqiARqcGeeEi
QgK7oy0EEpL2ULat0zskSTCNsOisfgLBd6qtMtHjCH43EUoFykB/oCB7P+Qu
WubOriIsH4QBk3IIYMKhHGKANBXOD0iuVh+jSJqaoSzkPNAcnm9f9aSA10dd
tL4xZNZyYSWs3hu+HhwKZM/s2PYsV6MNrLUziTAUrLPWnkcqIHpQlhsbIpO5
YVp05AVLB0pVeF2TSCkaHcixgrQF4qmIVYs5PnmsEJL0eCYmNh2yWgNxc0hy
Qr54fmaLpxAlDXMG0FRFPAPugKVauwoMOj3wpY8YuiQ7TA0KaPswzrk5GkfA
iVioooDEUGB7E9ekOytdZxZYmTlnJcGpkJV3UaXJE41A30b8IWxm1WUVrwlV
ghTUaq4uALnQzLAdxOaC3xBFdLWq7iLwN7eHHTvK/izAeimV2foPVKRBhTmi
xOdaZ2cIMpD4Kr0Taw0ey0lToY3aFJ8fFRuA8Ac5GL6sJmAT4+kEjimgGd6M
SoPB1SM+SkzbpnCOJBlK+msSvVubN88EhJ0BpdwEF2YPHMDAs0FuRAoM2n5w
UBApJR6/+8lnr8DJWSLhhO9JLf/iZPQVUOSJQE9BKsp9G0ltYc+mE56/FdIL
koaXluxM43MXpxDzlZTXb+1Cd3t9dtKsnFok+/mN5DXhjiITmA/be22ktH4+
8Bhd3zhJw2So4dzKtV5DGaACF3Z4rv7uVZmvyKv0WHt548O1mcTvbJM+CFzN
qYcw9y2zlPwgAT92IUXCGPcl2zZ8khxbCR0La8pSGPH5JW/eWcXiJKq5k7A5
gaQST67bSZGorIOUJFIJUs/HZ+8kXZydpEu4SI/G8EJ3JIkmAUT3QeCcDZoG
2AEx5aFO6DmtuBGc2gQVhVonw3c6Aj+YhldYKT5Tg3iKwkAwIZSwx3PwGw2R
cIh1UfBfkQMZuE/xGxkcwvmCQmGJ7bKjD0wXtEwRW5+4Y9/pOGvTDOQnAqOQ
cyuZXSwiI4pi9bTBimgeQ8shGu4PTrkw9e1N8uy9czIPHCS+arcEGXI98Nn5
qvr2gPsg+LhcbYa8W6XXXxUBGFAIVbkS2YCWqHkqXC8fJqYSqTGsajEIpCMy
GWvf5SUQuvPwItBdQF+ieIK9EMFzxdk+liZBVu2Sgbfu3NrACrdnAWsXhgNn
uxT4/QCHbNFUkBpWQlnuFZgaUAOEEQEJDPQGCBSETbGC9gJ6iLxKwwEE+kMq
YfAo1wEshNAlEqEKBgUQFzGS6KwElREykmZcH1GVmiXlk7VmAIEbsEUcf1JG
RJ8AOMkAJ4lmJmvBlY7FjJ25ZHBqFBAN5x1ZnCEVTd+L9UtYWMcqmGeRZVS1
bgHpJd7Rai3ovEGyUP+h8nfRC7f3jVGdKDdm4wHb8Lj8rsDEBgGSqR7fiPJb
g2J1yRYDalidsVjiSjRzotYSAuCrjJiY68ES9qiFGIHgii0Fx2xWP9ce5zAk
CyBlZVcAAZvso7oTkyeQplORTFJ4tmV22B0KWYiVuJPOd33PCeGteaaD5eSA
unMVoIfMmyqe+eWNjz6tUS6ekiTru1SeYQuD5Iurlr1ifaCy0KQjzCOwY8kA
GLHqvsBa8g0MwF4gUFnDcPaqSltn3AI6z2udF7PzjWiDqPKHUBCU90oys0kc
XDMfzaKFkixIIKErmm5lQJ7pSEFKN7CwZxbBIahTYMJQWQwQaoTYtIcLd9dJ
7CnMguKrjrm3u5kdKlgxpdIQpYAckVsrckFCG0FmBA3SfPvO3HonJI0kx/Ji
hIY1FE30BnynlVIlKAOnEbA/qnYAuWHyFAlGXegkYQCggYpuR5XcmnfT6LVj
DO1+1HZF/DUJySl81Ax7tJRSwz4HSeE6eHDqvwRJ5A9SVnN2stx48qukEtg5
FAEeh+4RYoKyO40AHoIezU4wF2x/lbRsezB1F+hKV5/MI+reSdKjGU4ww6yb
gCCNAr8Y5TYabEA4GQbPTupU2iZszy/l7/b6rBs3kv18nbb9fImN5FhDsS8/
Kmn0qqIGDzstCoqnqncKIDBJzeqMPH4DTL3JMpt4huO3bl2VJawEUvd3bnx4
XJ1t7JB0yFEigwwQkaB8HhQbBESr6pMh5wB0DcmRaCsbvhZStCMYIA4F10AL
8XeQfSXMT5D+g4KOZRHPglriB6PjX8ezJpwbEpUPxFGtfFVowy7bh1ZwIREd
pNkbi1I4gdA9s4VAzgKma1XB40OUERJEVY9iwoH9ScJ5TsNjFyG5t53odCpC
EiRmhiJWHg9QirwPiR2ChCYstklLWLyUpqeQpIluBzVVdFuLO5oRfZJi3sFV
7AfXBb4lkpYlaYVlS5K6hz1HONdcWo3hUdt1rcMjMhYUK6J1NEq2TWNn4UhK
0epCYp5ASAqOMaZCmuR1kqAX/KW0GjP85YITe60xxApHazNN7GR8kg6t2qs5
s4hlx8mh+JQfUWeyHXkZ8vRCxCHJqST14JBKAtqA/Xg17gs/rxSua1bQhCav
sEYtzF5PaB60iQyb6nDTwmyIrQFjkOIEW7AnGBv/FcMAEG5CobXErIThN8m+
CP/NnXsLpZfcsb2oe2my4xPr0Ilu2j8HbUKVvbzG+AHU4LsnKj9+tGPt88aE
iLjnKJxqbSWRvyWsFMB+CcIjUBbiuRmFsCBsWVWQKpOZ9QAdomth6QfkFeWn
PR9IYERXaX5t4FsXiLIDg9V0BQJHRkqfD0bcgMC3rnONFaRQEanevVdl5y8/
R7blKj9CIcwHCLpYCuX+8yEQP/0brDS9hc9/C3H6/CPkyY/tkbZRjs4P5El+
6/MvRSny3//lzWc/+btvn3739fuPX3z88nf/8mefD2n8689/7D3QZjKy+dL4
8fKg9/g39hJPv/7Jtx+fvv3+d+8/Pn3//svfffP1f/79+6ffDtrH97/5/Zdf
f/PV0/t//v79x2++eP4D3xf217DOHvO+Tz//9mdPX/7ui2++ev/rP3v6pDdB
Z+Mhr8OsZyz8Me/x87/79U++/vWffdpSoLsA1E4EbiQ9bOt+Np/+OPARkArj
KIbOrQriRj/9ca2SqJESij7dE1WG9bYNbF2FjEc2DJ6n/sFpnewq6V7P8gYD
YnaWNyAJY6A3tOoZ384jN0wSMke9WiiKBacI4yEzY52noxgGXWAyQkJHqvHz
OBPyJCHvg+TKBKAntqzA+voJCYvMKILWrAkuimZhH+DMM8QkeoMPXQoV5gwl
C0QlDm5MQ0hp0irUsQvMxNtzUZND9TeRqZltLJjCmqhW+QqerwbRQ41PlXfW
6J8USg+zETStmycN3b2I73ZzNRFe7H1BpVlnyau8QUaTHOIEkNdJAhq1y/22
y0i2E2ccJy8g/k8UfJ0ck4axgwz4hOEpXzWzBxf3TdLDwXVo4ATBRIH/sCDI
4EU6UxOrYZBcRH9hdfs0G8ARrTRsU7hoBntAvKfDXsfZYmgkIGVQiINUnW1C
8XKkwgm0TuVFKuKJOemGYRzrP/59MA7wjDjadwZDQ7B6YU4tX9v5OkvDrF0g
gELFVZskZUneAnpgTcMxASBcZLeQ9yH0hvc6tcXtLZRqzNgOQUXt6RDHnWkw
8SCStVq3D/JszbezKfsAtpPBkXrs8RQO1OhREDbBQlTZX9d2vBSqLuB32IfO
PSgTw8TcgcPvVeuHR1qHnYkqEnsukG8o1kLk3zCtxg8+WoMQgYajgEsrao2G
qJu4x37xHKpMUGRlaLyb1wWWpEoxVrp37+NnCniWxCKTDLNQRgo49q8FSLLM
5uGOIC2Uk8e2aFAPqJ2KtvQI/mJJEeA2HVmlZT+wANFEDNFlmMmou54QbWlI
zLLzWXGAdPv4vRAXch1eH5xluNo2CgQNQlBAE9zq2l8lYY5YS5iofMf+xihm
9nPpG2soPQtFbOkrYd2nSskMzoFmKJyrOrq/5ZmNBVnLZucO0jJgccQU63qX
wOs6a8WEJjE00KyvMLO9XBdngV5WIaCBDtal1TrXBXGm6/p1qEbghU1dzHWW
Qm2hFWHTUGcvZ+wRfG9EkxQ8wb2MoXLPu7XPx55D3CJSPH7yBuL64KFaFg3t
BcFrdc4mgPNRJ0++yini2auRmIGmAwOwlfg0/G1KIKIwmbS4sQadX6SMbUgC
UnOIA6HC3OwiZN/L+D1oI+tYb1vEE2FtUed1QxSmyMgYGWTffVzTGQrYdGjQ
Cam27UCvmbq2A2wn/SjdWlKUMqY6q3+J4cM7A01vdXfEwQ52SdG6Sy11kLyV
1r9QG3e2bW0vzI4pql1EAY1RwmIXVAEQZ2trXwXcgnd2s7qgst4PkBabmYN1
oSZG014TS2Ce4Mei6HyqkiT1fjhSJztHguDOdfaM2BNrMcXIsZs09i3ZSQ+k
LHgDWCGzmJGIx7rse466wOHueVYrGL+o2kC1wrROjCdxjr5KHRqTW72RnWEk
fjDDBtEQFQV7FcyrutJ4MF5oqHe60nbRuvNp270nTZ5x0uRdTpq8805zxOqB
VqfGvn0dovg/cu/jq2sTuQ6tdWqyWqjKGhi22zFuVm8KtGCDP5J0/2eH+byM
b0As0Guum5ORCpv3ImM2Z+RAUnAANCkfM0sNnVS9Nig3qxLOCvvjmQYzuwyl
gPZ+gAhBOtBJzQ4eBKWwfEQ42b2NZYbShtPMwc6cEztjb0uPWBKbKMeN1WBY
4CCdjZ9P1r2/5Wrnoee6aUlK3nhnSGJcdiOAEIDOJJPUXDmnh02C7RnowI+I
evWzkoBQBthq6F9pmglBZbBaTbMJNfs04ABlr8o61x5ze7jOcdnqsHGxH96t
vUQFA/spzpFBiTMZsL/ToEkC6mMvxulEdnkXgneXEwnwLWh1c16FJwOrj1+D
7YctEvUzgOy0oXGR7OyW3ROkazRofRateKaHZfyEFQnLcEN+brRwrkAJfJPk
rtASq1JBs9kWzKSGfooMhi9lR9GyZu1sGlaFVmymVZBJgFZsLbTOvDsHS8zQ
siRXDvGNjikR0JJFW6LkO07RD7R7STM7ymIOqjbObbtFm1u53bvT5N+kzYlZ
nmt+sgYO+HKu3/gOulo7WwXBf5xrLwOC2AbT/IdQ2c8E+1bnnkuGh/trYo7+
4+XC4kxoO+ENt2ie77zzkAz8Ia+ZykG/lfEObN1pDjT8hi7iFmZbFi9pAkwj
sfLQwaeM23/CdewJwWKjfO/eh6d5kE6AGCEaX3VGKWsNgtBUI7LdRJRkjSUW
EMxHXT1o3j4N7SC1p8HMXDiZ54l0QzNtBWgGE2rJmpaxDwPa2LMTrbE4+j6A
nXuwdlFSrxYlg1rMFUTuBeyCStQ53kXAf6iXa/Z+cM9gXxJwbrQ2ThzQ8hyk
wkJ0r6Lq13ZkqojtZLyoprtb7mWGKHEosxdFY2HSITIeyadEsYwWTAG6gqok
W68+mR+IPUL1jp0yPrIt0Pm9gbgXrIszFge6pUi+OZgKY5SqStJrjk0sxFMy
XWYqDMnWJtkkZ/EfZGs0D1WtaQDCkcxg5zmwkenUJLTqrJ8Ehndl0rplbSZP
yiSe12D7IjhCdl7PcqLwYMfyoXX4nHCZxTiAi2RFWqVIEG/bcvbBxKG/aTUY
KDTPN01s3d/RIqRa+o/jDz23TbFoLAXNSdg52xweTIdhGjhYg2NtTqy5Yit5
hEtWZYu0vyCbCQPOShG0bjotE7jBxL8Vm2EKWZXuQdGK11B1EaXLkIIIXqiN
O9vGUksX3eW5jQE1Zh9tTSF6WfLi2uuQLUk8s5RDS1vpJiJI7DwUrYchyzRT
E3XQrBUKjM3sZf0mLTF3D9yXswI+9lzwhzrw7E/hKW7JEpMoPkc0Hg2YNWi4
9nedPJyC1dwh+sRVI/XNyFSaPES/Ba3r6+IrupvKk6/E9oxVEmOcTrYH/tFy
rjrIhK3prYp5o5ktTjEq8nsWuFo0v+okp7gt+3en1f33VCy9e0mLNk725VId
tHWv0fZnLFqZU8ykceP5fos2a0BBg8FwfO+ipVgv23uun/gofY7FvH2djBfC
dVbbeePex7OGTDCybfugNGqXYysTI/tXGl2jC40xw2P51pbvNAZULjTRusKm
zzdY9/6SZkKBrzT0oyatX1jyoCVpjHShoRExaLMk19bgoOlaXWhc00V7+LZF
OUsR80Jzww9KA7qeJVvWpyoW9ufc41vo9Oqg1JBNsSWNVVKb6Flgo+KiZAMR
tyrWlwATxKFgt9gTIJYAiEoNldEi6+k5MsVmx2m3P68xLaE1Yv3J/aZgszQy
4tg6K8Bk69PL9ubMsfc8XJ1dN76DbOpm9o0evruy0Mn2d7aN9zJ8fjy3SXif
PRLSfJfi5Z29jd5GKSQiNFuUAN+GanMaE7M/AIpAHdfFzzF9hT3BuX57Wzho
HGaU+lxnVyUglbbRjhlBLxQczTHgjt/EUUKzbV1nO1UU71m/BraowyGIzinm
A2AeVpcYqbdZ41G6vOwxYekg7CZPvgbbozkkPH1kfpq6LSmLF75lHzw71BZe
17ZOithqNiueLCmNeDzh82v5mBAG5rVsbA9ttWUpsHxoe4YshZnEoDlmuiLF
bi4pTOKYZnMeLBWAThTjHM7lY08voxXaCfgNG0NMkQb7IdhnyLtYKMp7mH2p
gzBdN7adcBKityY5V1VyZytJA+yda7uxhrBBWC4jygjgVoENfTi/N0l1m60L
ALpcM2tHF2W0Ga43t2+taZluH2hEsqE9uUtzj4ic2LKMoNFb3/cD74XUBZAb
xs6oR2bW0k+XZ/ILy2385CsEGvcMFmhos7JnKKnq0FZvy355Vm8IT3Y78e5c
h0S+J5zf3bv34aIFmwqHObz2bDZil8wK0Lt2AqDmrQstt3VYUquhPGN2ugkS
190wDxx4Bq+P+F7TnI3DS9hno5nmRF1BZW69m6hmGTqz59ahpSTfHtbQuyxB
QK+oTFm+LvHuLfkKrcsk6JZUZbaoS7LUWt5h6RnQA/CzrJOMHRzRqd/cm4tq
ur/lhYgZ3NtNZJJM/sMzlspp4sowaOTmd0RodoxByOtEwcxpfIfF4zlsD9GO
LbGM0whigXWxoYEcIgfjyofZwoUDE8GSGL8Q1x7x5PFus7v1ZASMe9rOQbEq
bZ365me4uvkZCkR1EvV4Vl5jXsHVddJOnqw28O3xbN+Y5CPcw2lEAPlnSCBL
Lpa3iaIIDtEzrVZllDpFwTzGKhNGQZuHPjx4wnU2MUKoH6cWaKbFKxqxlwst
UhxNLM9luUWbS7Xdu9PsGXW5GfNddlqmRjq3ozCWDto0kDg4TkR6trNBekJ/
L1trHcQ8w0X02QIuXn7v9nV0QVkeUu7d+/D0g5PpVohldE26aRisy4TB5zcS
BcMxhym3liJzUu5KiLjFwCo1Cgs7VktVdMgAAt1CFV0aYwP+bSKPHxligY58
sw9YJ+oLITYzmTGqp7YdnYVQE/JVLG2zqxIBCb3NjNcMtrC3rfU/8WyyCURV
st6xCJUHQaH1trYAw/6AnrJGnVdxurvNzQlGgTMp03wuRkPi94LNsGYPI0Fy
Wf9XvDMhQZzDvQJJKZ/QR6wAiqg28CdiUGhwseHTECqCiQO0u0HKe2BvcwS0
sm2DDCfe11xDmITcr2g5Iqsc+70CooiobVvKfrl4ibhaFgOABkRcpGf2vHMf
Gue8Ulb5hK5KVtmgq4ITfNbr0FWCaEOLu0ep5O59axPXWf6wow1RzwxUX13g
BTTUa+GAFqKZ7NgN1M8YyghZOVyVrKaIyRjYFljbsuVOGhcyWoqKTWPzLlSc
3DTYD5tazyg6yjpsB3ykc4OKjRmnRzlLBmm2LdZUxSH/h5a4vXVvpW4xHBuM
vjWRbz97meIcHkx4fFCig9UlHWcfRI2TZqdyfDa2cuNFZiOwQ3k6bUha5E7F
0SxrDWhXr+d2JCbzEQo2BBASnYIFnhhOWKyuH4jhIBXeJ4zaMRZxQpc9y/DA
Y9HSfpMXI2ving9e3GHUt66TqhHOMUl37/2Uao8qeNHHFwu4X//Zu3fvHo7Y
Z6cfGs+e6o9zizJxHkZ6llLNUgU/Pme0VBkX4KRJ1bN0W0LVG0g2eQVuThOA
us5QgDfEBB42TwdBR5n3BZJOX2C7IR4NEp4gKdB9485pN6MYmeUASb1HThxC
IN3JTG+SsqSyBkmHRdBljXJ6aI9eeIfJC2xX2+zSke7ilRQdLholXEFrxWYc
FcaIYbM2HcYcpekaSFqGSUezyY3adgSvijJJWk0xnW8PcH6d36j2m46/IKyR
25HpKCtJkPuSMtUljIpNrmmNleKrIja5KnqJLAe6IxqJaUgUOmnBMPSwSkPR
TUNO3cl2ZJsjjdyt3KhJoMVMKF7Vul9juUl6ePV0YR8Qej6SraCZAIcQ6NQ+
i3qZIUYxtA5q5rIrdjbMmmFPOG22A4Egbpg3Q+PrVAzPwYqC7deRMhyAhEAY
XB6dn+0dYSM7p+CGlA5+8pH2xM6IgHkjDr1xsC9qOy3WhyPqyiEzqMJHcBnC
FnQrPU28Q0qj8rm3GuGrXri9b8T1tnqIJI4IBDg2TvEy8JYs1ubMLg6t2HjT
F3LbztQ+sxXeLg1wPtWrMDECLt5fVtWLP+Idja597eGV5mw7hJYX+AGFfbKP
Jk4CnwylyVJA6Csemu5kgMY9UBJT1CxXn5wTnPjkVp2PUkNE8kLgbJ57V1W2
QaEzrxX1L298sMy0xukqjE9J5Rba6CGkwClyMnm9i8nNuKVRGFRHgFfWGcaw
xiW13SfsGmhM1EOJAMFqInwXpT9yTRCDnIe9tNtLkkvlmSLN7LL4p6HaIY2x
FoylZZsz32XoNbHlYpehlLQLgj/Z8npWvWIttXsRa6rwRrt2SIJ3RmsLY45T
rdzb0ESvDE8Memg4aZAPknUnQHVWEBS8jpag5xEEBO8lRAw/i5GjYl3Z4Iwx
RiSz9mQRQr4ulGsSYtRsii0mgpOinWAzdgXIy0v2oDB6+GJFt4no7lis2SWs
VgZXEXitut0V1hlH/hmFeOg0FJsIaJdWVcZar6Hvmxy3RUIJ2i0jMlVUiN7S
jYldMidl7TsmC4Jkhx98FJgUSP2JxQILFXFDtOuReKXtQokWjKanp5BlZfsk
4AzkVSTaCKOcWZBmIXtb8zyjewgC4HeyNI/R1QNkjsPKkgodBJKZIDHyIZgI
8qPqSr5sCm8xKMJFwG/uy9y7QvdVKGRmDvszHkALZebYZGEBn0DGDL1TREGi
1wT4lgPKqn471SM6rEmmDZ5GltygJjXgvgXJDOood7rU7VjDxtJ6tm4RPwUO
JFO5wXpgQLYCNzpO05RRh7zvIY8eKPGSrC5+CjjLZaJpf2GtbAPOHs68lU3P
CS+I0jvVyYgm42d9Dy7XSeLBdCHB0T5Ju2zc/qZ140nizx8keYmDJK+6kTqt
PybeTZnevCrE/CM3PrxXVCYulqC2KFNa4ftBUtrMR08PpSFHlM3YbQSLdjt8
oKazF5Cgwrqp8iE/AAVpQxJOEw/EbXmz3DpzCATQlmKWGw8IDvnuh+2Dvtn6
Xj7KxDe0frWpmIExe8K5zBzyzEpxYq5ZW45yiHBuWWuNCCOBK2GxmBN8vPbF
u/Lmvd1VOwrAej0EvcyHZxY9TJsMZiORUyqCqITFetVkEwrxjXQrUW5kv5XY
Xw2RQTPA0NIoC5JOj0qW1Cmoyqx5VKzBGsCq+mn81iZgaK2o4qEM+wTDxV23
rYUZgE1TMwLHK/YPW+vNC3P6EpUTyZ7VMYNCBxpu+X1kudbY6fgVmBrZf/0A
wAvZAK0rtjlPgwOVGEUYMejCJhlDBZJCBDhAkHC1atE7pqC6IN2S9j7CBJci
i6ExVRwiaLizSwMGD8JLZchUfz6wxQZIOpSN5iVlpltPd5Cc4u0U4kD7oqdD
JDkIWm6sQXekMap2yHIVNQNSUd9fnXNVAvsm3SCtfZs37qQqg/tAUt6MTTr+
7DwgLSr39eIUW38wD1LNNZwL7dlenWBddQWZjE8kWRPtFLWioVjFP7aDaI2N
gzGhlStRLJAGUsvtZBNp2U5mUu2RKjubg+TUVEXqM4oYZWvI3SXIwhEAyUhd
KwV++KrSRPdpU4AbNz5aZmphUgqocy9ja6EcK9uRRcPvUzk2aWXU9NUA40H/
VXQ30m8q0uaG/askO0GbIkmLGk0X0z5hOzJn7TiZAA0y4VETzbR9tIGU9TDP
VXpLwBhSDgZWCJYkgLB6zsDUIu43zRbpqKniAMlAvU6SZ5tC8HnTQBuK93mM
dRtkhuVPynV2jF10zJ3dxWAzxEpamU4Nu++fGjEHqXNq3SarsCgSegHGpQou
LGDY2D3QDyOpCLZj/8ZGSC47OllLeZkdwEICa8TtOa2cNQhNtyNKpXMXvAhJ
mbkGbodGQYDORk9eRmODMQC7DaIhke52lbAJxxnq0YOWo1kYQC3pxXLemq8+
unusDh8h5lyaBjItRH3uCGR8FhIcG9YhaRPKwfICJJ+7yxRTS7t+wovDCt9V
aZdxV9gkzftiQRkkQFsybSrMTmfCrlUVG4fr6lRLG2kR2KeNAyd1kxBeSCIz
XkcBQBMG6cvm1VJi769IkXTaCI2FFiKlWgMPo8mxMWKcTf4vSuD2JjGXj1lS
+xM908isY1HJYtmFsIVX66YVdmfEIiV1Q3CieRn6qY022eErSc2M177MwORX
Wa9mJKADpT2X9t6UpUuHeKNHGjvyOYMYMHvIirVGM/fYx3lcYJ3QQ2GTZa5T
kNIqzeKwG5+XSihrbY3gL05cZbnXYGrJybAHkszUmkyNwQChGlOzogiV19ou
eCOpHQxSJxK9WKptJ2mYZ4nRNEF3ydIZuzsp2m+d8nd7fXbSvHGR5s8bqVjb
O5JoxW/vtUiKHeAm5X5+o5Gy9TucW3mul3gEyXou3rxKbGlcpZ0Sb9z4cB4o
MjZaN+mDkDwLXo99a+3FVoobcpBg/x5LtjZ8kpJUIZ0k6k1lxOeXvHlvFZN0
bDhJlXWBg9QuXHeQIsvBDlK2+udUzs/eSLY4B0mWcJIevUlATeIoBlA8EgzA
HsXsIxFne25EgVvbA0EgAZ/GTga6ikTECii5dm1K7ZjZJkKszO7DQKZs4Rp2
nq6CmPZerxJIIbxTbUqKBDVa4NE7FfeR1b5Fisg1Y8BKPrwqmrsUbchfJ/fb
VuqociqjplcFrgpImh9C9p4dHndOOZn69ibhRgaF9yd6CVYDiKWa2SfOT8Sr
Jnv7wmzI5m4Hgv6yFLCIE8UqxCgFE1EXGnWsBITLFCOSsgREgENXVUpAooRv
tLYL2fvE6FC0xBL7jBfp0NCtb7WT98J8C0kHsGc5ji2UCWjfajT1iRIvTK4a
ifm0FQhlOXHJk+VegakRi4fXjFRFpZ9AdEPNezAdV6HZBJOwzc/1gdOEVsjG
dVViqezcPZeMWck4cXgEwYSwR93Zrj8JplkNUxZIMxXTrLyQQ9CRgoRnWbyt
D+NRSYAi+5KlYGODiHSARkxiBZqUJkFvq90LEkvLV0R5ineq5h6xER74PM2m
R1e9cHvfSPLSNiYuHuCGp2YOGUiJ6YZi9c/rGzO7eOpKoAkCnOBoHc69xLZS
NL9qLiECEMaIjp63gL6dbQdz9CvnxaJzrMS29qEJDgHIdWVXjLoAn8diDsbi
iWxuCCdetrJnXUDCvKQtX0Z9xdZFM1vDKara4SjoAXX7KuaNuZTlzo2P9q27
AC8ZA0xqsTlJGqCXpipv1P5G6XzX6jzcqJ8QKVSF6wSTvOXVOWmkCMnmfnhP
1CMDpDoiAb1x2ZQPSFi9KnNBt0Qu9Hnib7Vp0XrpD4/gYbGtlFbVWyqQRfxM
T84kH+BljM6GifDj8rOt1URCcUouTmuIuXgTVx1zb3el2weijlq7w+4CiJWG
iarCe2HoBzKGwfjJcWAXMo0KxuTgcSiUECwCzTnmCBas3GbQ2ZNYiaRqB6HY
JOtlw1qQPE/S/bCFuR0hy9pPo1ePMZyWZrtWydVi03SWnRn26PcfpmeC5njY
bW0xRReLafswm4NPlgv06l+Dqb20W/LeulqDhFJikHyYzhxtMTQf0PhKlxkd
5HOvV0VCBNmhXn1F+HXZ7wICl4+4aJA09tAl5n6QCpnGhO35pfzdXp9140ay
nw9m26+X2EiJHfyP5Y9SYI7JpOqBs+2C7pubK+H0t5pOBES8R5+ossxpRsGf
v3XzKtZKAPuh+JGXN77ClMM2DjX0qJXB2hYyQoBD3wKFCZ4tLYume1ACE4mG
dBqJ1Ym2cOB1zpaOPwV8QR1+GorEwlab6dRYCoL2nBoxQXMe4n0cq2hJkhjI
juRB2yYFS2q1vgR3BaNjORwLVjip7SepSecwdnMQnkTIDjEHZBC1VT9jDY1V
HE2feJGVO7uqg3c5fdHeq0mfONet2bfXIbN8oua8MDqUMMMy81SIW5RyYIcw
4bakAwcIeLivB4AJDSOr4KOCwnZq5ewB9uiNuvTIB6VjoTXAh664aQaLq/TJ
DTbVrTP/vO0hDGjPJqWpzaAjwLsICK3hf+QyhNhfJwl6QhiZBDUII2JKE/vI
lvfwJRX3hoxLENihsxSSIw/vKLTkpY8QguaqHzhSKR6QM5SidmlAq+4cE01J
SNq2AZYlioARkc0rWxDZkbbYbEEvnaOX7GDWT2A/2pyPYDJibLrugFw4ynKz
SLVM/+1Slf+84vO7dB8a4OZu4a5e476jWQahYdc1+4Oxp6kcX5HZfgalBhb3
j6JJOllGv7SWg+fQ9DYIYFrdJCI1gmgAp4cLCsbCifhDyWsVXK6OisAmtZAO
LB9yTb4ccFHUh+Z+Amc7G1odmFVA8QTVqL39F9c1m5dwEzh74yo03pE2uTHc
u3HKyBVW/WMy4jf0tvy3NjKP/E5pteNneTysaKM9bzS62VZ7oPfeom33jlf+
xx8dHgDL0cnECtQEPgZP/u9+8Ytf/8R/avd5VC4TGCbz/+wVsiCC/shX+PUw
9jcw+2N2jUcJZnWh0sMTB2brbaTnRbKu+s/rxhuk7cZP2DCWixfJIaGXyAP3
6//45GkBsLXHsYNOMv1R8yZ+8Xc/sluB197eLcxwIThd1/SD1lYR11ZlHM5Y
37//Yzjh9lewxE16b0ph7Aetl4MQSTe2VarGBpWwrqxW+nLvJ8oqWx8xmBN5
cj5m4f+3T5dUhE4IoK701x72/J3z/ojNR5hy2BTKA7Q2tLl6mf2UHrj1jHVk
idGi+9QHOQDZ+nkpZJZ2aCsMOzkvN65t/yM+GgYpa6ADj2y8BPkrJmcjvR/J
7pn1UDEJYnc8LXMaZESATTzwyphVxGdru4Pznn/d13atXJf+ydZUA828IsMP
7uHynT1jj9FXBsM/aME7EgkRkVkrE0XvjGG8RU4otAL1895PlW900+MgTml6
/hj5+t8/TakrP6GXLFb1Mc/+D9QtTziLn/7Dp8+jCYlYkLdAecRHnXF/2EAc
NLAZ5uE8615hIs4fzqh3amQ9kfFvIzwXb0Wy0st0Ep/fWDNTJdp0LelmqsQ0
24BWNo4jMSQrlS3spz+Izbx6VsaWoX9ILNYPG4U8PQnRmvUxehyCEJ21AUbQ
UV6+mp/AOlqY/iSG2XEUZYANxDJ7NCL02OU3Cxs8GRFNjQYxM+1DIuqUPB+U
6D09a00qunSRmKw/JEcnOBAjS/jsdnSCGcSwOlMigiurhNLvPp8+dLDcnq1F
LjtkNHmQs0LR9UVptkjEtyMcwZefbSxRPpWjEPNs2RuJxSfROhMy+puzLEic
65k5xpnEMmtopfiLxJ4Xsclvwn/0kxnQnIrEORwjSA01ibOdKooxs9fdtPax
ixXr7Oa4Me0k/tEe1j3BAJfzvZFiaXJqSH/qIERvg02ANOOeQbHbFCbIA5cy
xjVzg435C4hAla/+1sgfvY1RDkEhVmJHBhGjLqxbeWHg+m3k2Fx7eiaQ4uQt
OMstXbgQ7nItFyaGwyzSsskAsknBX0QIwNEXEhhl7B+J1kQTKTWUW53yj7SP
SEtf0xOu2ufe7moNdLiIunZCOnkLbaGS8mubY7gq4/QnZ3MQl78IRpJU8ylX
CBqJCG1iCbn1L1Y+kZO4R92+fe5R7LM1KHYTbaa4791kAO/ccDsW1sQS3XOo
JZGGs6r/xTZhNY3m4CGyjZvNd2TYEa4cUre6qncaliQqeO3elY01VHJla3dv
f7gEAriawMRIxThtUFIktTqIfU1lKjIw8m1ESNctIiZ4DOKsreO4icz19QgQ
WUf9xJT0W1hcycQSgyPJWxiQM+ckBWbw3sJec/NBqObkWoRtHA5KmfEgHFw2
PIOz0vFK1KnW97+yNcYgFhpRQiwEPgxiXW3WM+oQiix6MgXJkVH9opKyZ2yc
xDJ566LR7vMBLFAX5OnNTjbgYikDCPrMgQeJo7n58rPXc87sm8zPXO3+K8vU
uCDdmBhRmsL3FKfUVqnUG+vZKNVh4hq2lUcphb08kMxkYvSMsJcv0kd4EMs2
ySxR4Q5iskpPYQaPb0c6Zz4os0yGDLbmYmSiEsmKzpQC2n5SpyjTvsrRVIko
fRvQKMbZHENJvAxissiqjBiD0g0sKFkcA6QYifPsxoyXwN/M62zJhaplEAs7
OB57FlrlEAvbsyZXIpO6JlUgT8pZmdOUQts0cHZgdeFlewKw06Yg0X21ctRm
sSyarC/OgYCA+hxBVggGHYvuONvMiDBTBxEpxDaJqj5mpvelorm3kfuWpzU1
EMxBGXBhzRkq0jOcr1RsOzB2rxV5+dm+pUROyOFn2rxgrBIVedAMp60neqcP
YpzTgDlmz1VZTzdltRFgfK48ShlhV2OPrNkithgdegcRCYGlaIqwzcwBUv65
SiczeKb7SQzmFJiiAS+1qWgm02YbcPV4wWjEA5Gzi43wgQ0Dm9ikxd4GMbQX
RJ6zVyIwxy+IhwTe+8L99pOoDzqJ+konUV9+JxYaISS6aYXeubL09OO3P3wn
EFahjilizMlok6jMUmTmubkXdAE518bm42CgSMdaYLBNXK4A8qMyDXDrlwOn
hGLU5vyQJCYLBK7PQSOFZYkU97gNXoUa4GyqOk1qNQExuGzOzwAOCzYch8tN
IywSbMBRWWsgUWJHM87Zsu6JMAGRbpQhXdtO0KjF1K+aNy4MVKVhjSe4cvYP
8IGalbi9TsMuc7gKx5XlvEzVwgXZgsuBBi4/s6wBDETjgY0I8yxzlVD9rGPb
bI86wcQy320b24rqTxkEN8fUFnYt48rPOY+A7KUqe1Ta2mLUP4jxZpYYWjHI
byY2dRG2qWzZKMww3V9Bh5OYpqMcxcIB0W3OtzJtsJ4SDxcM7RHHj0FNkXTd
K8yFyPliphXOnaJMPI0btPboTojRTjpkI32Sj7G2noA05ViFmG2aHidk6AJ5
YzjgoWK8yJUPvEBOompDNyLraGTmZ1nEnooI8LThgMTyWYjV1hfdOmO+iPow
yLAOcrrNCSeV/U5PTeEby8qEaOaaRVFM0Vw28iZx7u5++05sxFcKsaxXarRG
do5BUxhK4LGehS3BTobzsCBfbEciPofEOsNKwHMn2eI5UJXAFK/7PpuieVOd
mwwAyNX19tYW0VV3ZTB450WIxfQUyuppB8KmmgNsKqtnxaYyj3wwbQ+qT+dQ
NDQtEn36o1cWgi5kYqRFOG7c/mgJZHqNZwvQG97SfYETk4RobRIR1YbPwRFk
MyNXCAEgsWzjRTrPAQKLtxkhzQmxW89GdDahkZAFvSHETMg1zalq/We7hC/E
8LJGtRxXBDZCQeXst+iUjdDc3s5AdHChrcnuHcqvKCWjokHrdDNVAZ+gsVgQ
3XJzJ4CtEKm2gZCAUJhOmYftVaP9AB9kLqMYx5O3EgsWT7lCGQ/cdM43tDaN
aNlI7aPOhn07sNriluh5xZI2+HD7t7NDKY87uKfWOJkjoaKsZ56NLxOPfXpK
E0nBQk8n2zG7csK8Ji9hxKj1YWdBeReis4boqHTmt6OdsTXkh1eWlOisTzAw
cpTq1KePsTFtJ7z/NQQDjaV9F2MG1gIFAwY+zYnq1kQXuJWi9hp7RwsxSMhy
5wNindLl8GU/fvoHmyJnxQ3iA8whbdMOGNjhcOs5KkEKFmUiuPVRxZFCeyBH
qwjlwINKpYup4JY+L1JwI4Merck0Z97o+tqAbk9LrwjRvH4AAjqPEcTaZqPk
wq0SO836018Vzb2N5O2d9tXx9MQAF98zzC7DnqAxUR/zizqNZOHCGOdnFp7A
iNtYR1v2l6mySrPdbEHLSVvPSXQEIWoMYLXJxljLQ30Qqib2lVuNsjkuoskR
GlO77vs6xIgja+nUFOAllCKQwappSQgefxMjVXyfRPGJlWlfRTC8BGVh/iJ6
cBGMTCixCYajNkJH7MnEG3F2U2cXd/3N3m4Qy1z0KZbL+D5ktffwklj239yl
+t6qncSyzSWZxPWgSUzEuhtR/JbjPTdijRuR1sjx7ZOIWvl83fJzPSstB1aa
lh+6MrDQmFdWk8Abtz+cYxBV9dtGflCiaKPL7jLZcSWKu3YhMix6LuXGHIvo
NSR0IYrOViZ+vsXZP7C+6FEQXhJRvSJTpvsLfj2Jud24MlJvgRjDdUE24lq6
k6iLPIkP30hkWfGFCOMlA3KgDR/1GCbHWQP0gCQQQ24rYse+e3zFPlvHvkVR
DjNhCM4FG7aCsioaYWzVYr9ZJIm4B9JQToMCQ4k92XieIK0I6PX7Oa/Gc14i
vf5kA4mi3CVD6K1Ve5SOaoxOzFl9GFUu8YFtyzE8JnqRszqnkER9OjScHZSI
Pbkrb10F495G8nYmEc6nJ0l24D3dHMWEo19fvswv6pIe24MbMm2G3w4Twsa0
oLYtyiqt+SuB5XqynjaQLzr1t1rkLbYdvWqILdorAQEhsbw6M6Bsk1g0/uqt
Iz72ne/JxnX6dIzd4JHao3X5I9ugCz0ZrFQ/iUwJ7+Fw9kstaTHtawjGWIvK
zA3SYwaaRONrQkS2fAybZjJzA7yEtdFHD19G7NEU1vgVKSimneBW17WUknL3
mK61CYYrZ+aGHc9alITfHK2AbJOkBgPLf+f6MruO0IedC0Ha8Q2iWzbcWspm
TTwp1YVJb5QozPcMLLAexLImDaBs+5pumOojwsuZHOOJSxlEz74QRjy0z73d
JdEza4V+1xvHCF4A7QU3YiLKwqXZ9n19O92+PlfJxShfNL1SlOkxq4rea/G6
yEjKTibOLOjjegYbpINqd9/PTC3bd/d63aPKNiDczTzZvUkEGfs+nbDFS3m5
a8hxpngm/MCKAAIeiV5qyebPfKHMTjKmNQPp3pUCoABu2wai3Lj98VZpY+sw
QYPo9HDY3dUrMdsMDM5pK0IMbh2+1IXAJEyVD58m9RN2QniqwA8ap8ybJkat
CtEL/hiU5wXfso8WC8Q5begFzvuS34zLlo9S80cgjcXdgcZl1H9PZbNGXZLJ
K0GNRWeEnmnnOXBLqvqYYZ6eBFqPEzsF2KX5W1eN9gN8EBTSFKTpg52rgoTD
mR/W2SKYOVTlt/VFoQbJmdv4cLZ3p/ICom6fKsYc5JaxZ6FDj7JK05RCMF5w
I2HOcMZ2VPIrX2NtHJKU3KNp+tthC9jJtN2BViIwgcPSzN/yC7Wy3J7Idtnk
kDTnMWVNpDPHYga9MS2Mi9fJPXGKpSxQX0P0GERX4hxVVaQknYLhTBdq11yR
lm3wUyJ+ILllTiDmQKDCLmzoCSIwSbdGnmGapGDoTqKbcC4L9Fyl+t6qbbdf
iPIgGm/18koH0bN0/dweeOtOr8xmyCEwV21361qlZr85Jwxjzmi4agoOKa3X
37xzJR1lEo8Zp+ftD+cYBGWRQIlIfHdVpRbbIzGu2F6ifs2JmlKIhU8n0dn8
KwxYp9pDQGqOMfLsukCis1ALijyJd0MEbQ7UrpzTPoieGTUhSoektwDOZzMr
UerZFG2b5kSpwHp5wdDOodBO0CCAy1m+cAaPAIKb4xYx7plHP3pU2AQuzgdX
vFuz4d0oMfYUDE/crO3uIYE/wAdFICKUwDmnVAYD8jfn9MPSOCpAnm7HSOmK
3EJDybhiZLFc8K5YEMaJdwAwG9l4BRXOUeFVkAxcujnzscrYUy6yTgR4K4PS
02U7LHyLjTMkDAK9gh/KEpU3tgkEae77jhpj2fdgtYlkxUrbEgENMzgX0wqy
8hUE4wWamdnKhWaOVh/KK50YHsl66ehkoiSL7iyFSSutPJ3gUsxNiAoEnzgS
L5HLE0fKoUVFFt0cZSY7mxL7zBdU1rXKohtUyFKtWLVkCT/kIGhWbmLJDiDk
V0QowyXdAGKzcBiqYoMqhWC2OwrqKVc5rTGhlug5dMpV+9zbXSYmOlnz4IPC
ImQSS16DuirNieMzHfeLRJtIKp1Ci6xSsZwu2oRx3zcmZk7HKbuXurLUmeAn
JLkMROC6fuaxcY4NVLnFKa28puLIN1gvAJteMckTcc45Uf3pgsvPbLlwgnV9
ZY8Q8mfa5mYpJwfCbJ5PTt5x+TevbOogEQl8//ZPGcKE8crQ9w8vUHkxhOkx
aoD9gauWGkTtAc8GwW7Rnt9oh2DTxjrhhfVbStNBWtIjWNHUmhj13CtDrFup
fmIkWDZS212mzAZopNmUC2gXp0dDtZr+wgY7sova0BY85vSsUn+YU0gFwO4Z
qX6WIn4B9CVnvrhnMk4tuGh9bh27NvGYK9oTFPax+EXdppcxylrUVkpp3tuo
BePsoMh4aFHbulhn204gjNhZeh27FBe153I7vyN2G6TI7+UexdWRHfUa1AGw
btNcv5DM5rS+11nC8VgX64zLJtoqBNFaIESJ9rJQr0yaN2FpefaFjlJSELi4
yhuJfj/kx5oBOHp5pGl6beO1YLMeN56ctAeffpiVw7ginLciaR/p2U43LVpx
Aa5zTf1O61eCe4si6a0/RVCsZCR2KRutS0UIhs4oLShGNUbOfSMtEjAqXpuf
M5C62NCLhRBjZJXVxmqIpKQLmyJq6cLJ4sDXyWm9xAPuswunaLH7mp7/OpMd
Pm3sF5GOVUUB6kCb7FxVyZ2tlK4K8RRf9DKI+WShmHTt05pDEBVhvLMuR7iZ
U6dsj4BC6KfIYJBYDae4IQLpruucGTznfhT93rUfAuvRfeviBK+xAojVxSp7
rohdDvvJCtgPzZ+8EWZfQxlf1YTXyj4xS0H0c9adk/wrohHNJkLcus7z5JKo
hbYWuHHvo0UL3XsZmQBKxUsBMqOhjKrG2WFZpyAyBGmdytEVyGlI1voiswMI
I4jj5VRzol0btS5sDJshUehYMqiomUeOt8saPqxrbAiyKAwU2mCyYdQkCRrP
ATnoYVWlTMPN9i543KxU0O4ijEg7WdI5Ry1rwBhhWr8NGSunevGSAqcasuEw
V9V0b8vHvVLhCP6y4WOKMwbN6bACr+hUBsTWKLPItecPz3FwrWjBheZKZGKZ
1ltYUyngDNPL9fMUVRhtNoNsrrNArXQ/QteIfY9zvpgGg6eXyZF5NPNg/Ie5
54GWIxBr9gyZscrYdk2TVmg3orW4jnXAlF96c8qTr3GiBHavYlIKB+0H2TZ+
GmjNmntIAybmqfxiDQE6I1ygBy1QllLz4eZhieZ0kh6cEfa5RchmWTN8SMpM
I5rIAPhYNZe1pgmmprUANlvGtgPJSh0gzo47zFXCWdX+aVhSQm269PpXmrNS
j649dCDmxD3AafJrKBkBU33OX3+hNu5s29xe3JvzVBEUBTxDZ7KzmxiRWn0O
M+fYRcnORkscyIDNIkm60ub4PGpiZPNa2+YIBVmXsCbZVCkAKNbinI1GZs5Q
1xm5j6j1O36NDmwE9qFbmJ9qIzbL9Nogwirrcux5YxsA8kZXY9zUBmHgpjaM
J8FDr4IswyOYoAHrok3fBzVyUl+ioK8iy3fSeDBeaYJvOGiHaN35tHXvhcZn
nDTdyoMm77zTogHe15jOO9fF6H/03kcvPZquGFau6iQR9ttSuGizISrqagHu
FWzWimejEYGA5WmKS1I/r+5l7PtLZGQbSnwOsKVdwWI+VbBo5OsVv+2sVZbX
opcSLEoy7TLAxGwgJ0APUUGmNmaW9ZIEiSGHHM0ui6wRqY69fNQuY40iChX8
WnqE3ASsVBb7EdZRpR7s+Qbr3t1ytfNY3hHnQNLcFdEU6rQbE6H6dQ31RDJb
sDGr1SDKPqUioNOa0HURZEypFi/kxFxBYmaCTtX+9V1R5eaPAPWRFNKu8+zY
56YqyDbaXOMqrirAfKGtBmqsfMmrdyA8Np4AubGIRHlI3gUBDnNBC5Nh5Je6
XFrlScS4X+Wg5TQbxSQmbXADMKiUObhp9wDgb6DTbA3yAqeik6bQDyRLolfc
tLXEw08LlnJrpQduT/JpGqTmPEXBCG8N/1BMoLS95V/2Im6tThpTL6CZbYVK
TYKucjEQC8frdHeKL6C3Re912mISkWZqtU30gRaLRlM7yiIRpjbObbtFm1u5
3bvRvCSwSGvzXXzOJ2sg/krR2tcvKrZ+Y6ucmF8+1x6AJKUli8YUYvRJ0z4I
WHtGmgg0tmaGGA1XThbH9lNjY1PdpPWcLzzkJNJEXlOVg/mPAmp3c+wjcmtB
i1KCurlFtICUydi9SCKFT7guclacFONomODGvY8WLYDWyC5JAPEQLVQC074E
TTXiMG0S67vQJkE1GCbdEcaHkWD6ac3rlqdoPQc404ZsxWS19j0tkk9DLVvW
fpfAj1ILoet7nZ1PZdsQ/dLTiIOytGajaa/YoViZUyG8WqMERdpkCpBaO7yW
QjABIdNB7UYUokklgrSq0aXPTgHTWh7rWevTzpPxqprubnliQSLZLxkLwem/
aFNUNEtFCGYDzblQTVRJIrhav9dnBch7mwzlWGB/fC8OSZ5QCkLVNa0sG0M8
XwOONXPuuxTHuNmbNvKkSDIwkjS0fYu6R24OKGIWFXupIELwBnMwoAWNDKEW
XbD2E0LIIXUUVRw3atsvnkx0Vh7P9oz1E46IkgdpFIekgFSUlDwHT8B1E6Mk
GGST1Wx0q9aWs+zNjCZvnR8zp1HumhhpD6kCxAwycSkCW1s72bbalebYsF1K
SXRMAmq5aAggONyVVli9yu3oNtcjSgYJS6/zqGQKU1QRtMbgCHx0EVXzpFmb
r+JrQ7CQuxJxCwQenFsUrKHFrW3DvY6Gz/5cIOz1OoXB4F3EZUwT780BZ02/
Ldpkk0iuk7Japx3aM+c6SAlXnJ38q1XddKN1yQBinZMNKfGcWLirA5ZFZt03
Zz3/kyAUWbmiLfjX/s6TB3yQpLBvij74xXutKtTWvqCJ34LqmhiNpsXLwpOv
wfZNsq2wQ2GfH2xf17gE0HjQYlKLselGU1tcxhdU+b3SX9LiNgtGxG3av4cI
avfdgxbX7x2iemepDtq8d6PNZ2w07edLmhzI2/tttLSekXO+fK/RsC5rco+6
tMf6qY/iOfLm7nWVU9t43Ryv8/LeR7MGwoJu27YPQguUynMre325veIanTTG
DI/l29hg0poGVE6aat1ubuQL1r27pKhleklrXov9o7uw5ElL7Ilx0gq1EMrH
UjnXYKPNtTppsqaL9uhtY9kaixdkqM8HoRHliDhd0skWgMQ0RatrfAs09jVk
XxBdUvQbkHjUUM4604MNxhh7ClbkysYCrO9ZsSf2VKjagUA7n6KtgK9aPtJ0
+hUG53attbJxKegfQJsE1Uo2UCjqO9c5/AHdxKZ02PZirhFrpKHB9PBA5qwq
W2kmDl0CtOPEYqEr29/ZNs6pCu7y3CzhfdA0syezefSdo32Hk8zPFiWQMUha
SeWzDgTKGjNEzZRO00OnM8Yq65p4ggSXaJxGDJauvcsakHL6LkjMs+gfAyr1
XVDbQS0OQJtOj8L+8v1atjJCmnJWwOJ03BmHMWkDIB3Xy54XRfvVaEyYtgj3
ss9BU49m+9gVC4/MT5BRWWgDX/2RfcB1XbIU0QIbXCqnLaGKsiRYV2DfAnDQ
5ZPksF+Do4CR8u3IUtDcIWLHTbgsls8brl5LarmkUj2QzTWiaSOZi2S21Vy+
6GavQXaTSYr9d/Z+VfuHuTVACgWrrNpdYfZNHWC+gTeaBNYwgMBE9aJK7mwl
aQyOYTDBYg1lg2ouI/uZSH8jmWl6fq9jlwpdl9612EHdPjEDs3yvun3bmkbG
wnXtM0Fhbs0OQ1UR8RQry0gPlVm3fT+C4kcw7cPY2WtLR3RT0BlWi18m3j4k
4cU9gwVe89J3bmYoqepSOrJf7J/ilCe1++C96ySpj6FHOtTrxr0PtxG9tMtg
V8ssooXkoeTM1xBUjmDS/Hj387AMWSHqprGR4xYoS1xaMjKpxDx6M02ctaMk
6jJ03BMHLCbBWMzZiZ05vj23zoFrWXPrZk5jFp6A9YvFndnK0p3J18Dihnok
VbHMjE8jWaqePrcja+2AmfEAWxMyjm7N+h1X1XR3y6tCaOBHqMjEovAqGJ9x
ngqV0B1YJ31+hzSwxETFPL83Uw2hoshm5qHnUDoSyziNMAqN62JGDmLRTLgj
UF3n2geyZDhGMwqEC31c9TvsZMS+me0cvCbNWWMTzQijn4E9n35GUaAnNmuN
uAyCsdgmYU6ejDbk59Fsj8GmUetagsCD2OHCKW3OA8ti+4FW+5ykWbNeZ1Pi
kLJmjjtmg7fQgxfozjZLGIpGi2zmSE9nDUYPWjfIUNThdFdRvbNU270HTZ+x
pniud9loTTpI7dsB7zrodUGNK3SFSbaVba6Lr7rlPc4BstKQdRN9Dqitl9+7
fR1dUDZJtTHRL+99dIwUCSTW7bGyVbJuFgeLjJnPOBg7hYDmy5yH1QW9JHkD
0oo0jSGaX+NvHH+lyFmtTERAJVbtcj2nm4cFptUeGDKmm6iuwS4ayu+FyJkD
rdUrkTgCttTYLHqrGOJKs18z8BI5b0mXObBBlZSSlRmMqY7bUa3MUIbqKdvP
QXsX0bq75VECaxStGOy5hRoMNc02LNxLOS6fqycAWkUaKNOyfeiuUy7gSAxl
KgqENIAoJnV4RacZYq1HwydH9rYmzVtD7GSFjRxP39259hbTZDPuNOPnrWpz
8uxm/LxKD/W1v4OHZg1DtDhsl4ZAoGlF5MaTlUb+K7D9Fef64c2Oc23ELTxL
5sd5xaUWGzkVOZmVS181XYDodVBsqQESNXHFpTdYQ64EUh/gQ4zLatqcvdmo
O6dlajAWLVQerPyl2PzJmSlkH3PNYCHkH8opbqhT8VpkE+IZZmdHe80eVgV+
s/W9hvJr4GRVgcjrGlg6Y1cRV1VyZysRjpeyk33Lo3S6IWtoNo0earh8W6dN
ILUxlqaoppqkw7eugdbQLDZFjj5oD2118bCmWTqFJxZK6tqLv7TvUZc2IpHT
p+bosR4Mfa/AT2RUhMUX7pgDybSmdeKxUc6nbbYN0JnDKogL7orHrkSPPh98
uuGxb13n1R9BpaQCB27c+/CBXzC4mFXVkVvWiEK6aijx+SDWuApk5u03iev2
T5r6BYiZdGVyrJT9bzH2C6CJqMjQPM6Z/57nfuncGRm6UKvEHoL4oUZ73mkI
N2k+ZN57i7bu/ZThX6gRlgxqYX+f/xbTv3TM0tuIbk/uv4/xX8hAU/3BitBJ
D9DPUcA7wVC8Dx0QREyQ4toAUvug5aFJ2t4VVsI+azWkNrOtq4Xa9fZPFF3J
wNM39AT//FefAoaUFs9W2APugS/wrxwDBmQHzzudSUWgXFcYQp090B45CQyn
bdbWei2LuYQeaikdepolRdZs2o7Y671r//+Ib6+OSFdpxhCkvisLApmwXuGv
B356k3YhxAL3LNOqx6eFqR/ob0oAjqBkibxcbvvXfXPWgpog/dk/aAsINiql
hk2P/mr2c3D8plDZevCDNo5A29y3QHPPumhgFuEc4x/WhvnF7Z8q9GicSfyB
l9EL/1VHg1m1I0un/KME/gdmgz3q2EbHbjh5QFK7LGB9eCmw9Iz2vNPQEkEs
0XnrDdK68xP2DjgyxEPs7H7Ykf32809Xlvkp3hAg209p712pMdE9DNFcnFna
COGB8gPwPRDtNl4ND0zSK9kvPB7KI6DI/eowdr3xD1AcN79dGhTAkkLLqSjw
UkQ/YV3haNamUI88LJRtJkvxkV7CKWhEYGjJGCUHBUfPW5XS5d5P1BuIY6T1
kY/hvX//6aYC/L7GPBQq+f0D32C3Ff6XN5+9/+Y3333/8f0XH/jPb/9x/KWM
beE/ai+pLHo1+p//+XiXz//ln94//fRvvv3m+/E//v73//g9//fnH3//Hn8Z
tL/74gMu8OOff/nFd+9x5dNP//qbrz5+8X++//jdLz7H9wzaX73/7suPX//T
999+fGrjAb8a5L/+5stvf/P1N189/fTff/3Nz7757msjvPnsL/5ivU+78z7r
Fwf5Z999+X48eKyCG//r51/80795//VXv/v+aTit43/jUvx5CHLE+zx/8dV3
TzHpq/3lX377z0//MDYhIa7s4abjd57+o/5dvvD8pL/9/ovnr7/82TdfPb+H
wsPafP/+w//61Nz58vHGy//yi6+wcL/84iPeKelq/OL9b77+gm9Cj2/819C4
+Af+P17lV++/+/b3H798/53+2C8/fvvl37///ukffvrLv/obe1f92+CgKr+L
l8H//fTn46/jed8NeZ9/sLdMd95yPOqn//br33w33gkf8iu+x8+//T1W+vwF
f+MXfv7FWKRvv+Knjt+yL91vC8dt44t+8/sv3398+snffvPdt0//9otvvvvi
u6eff/39vzz99T//07cfv38aX/r026+fv3//8c/OH/rnj+9/+8Y99Tdu/uep
ZNTIQoLwn+biMEHkL98sWukvaAj2XWmo9Dhp4z9DcE9a7XUo4Re01F/QUPk4
ad9//OLr5/cfdRX+/uv/8n58yE//9pvffvsUlDt+9e23Y83XAn73/Rcfv+dH
N5dSePOnf/rX//PfvPn/AVBLAQITAxQAAAAIAOd1mio3ZtnWi18AAEA7AQAH
AAAAAAAAAAEAAADkgQAAAABsbW0ucGRmUEsFBgAAAAABAAEANQAAALBfAAAA
AA==

--Army_of_Caterpillars_697_000--


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 23:22:33 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA00227
	for ; Thu, 26 Apr 2001 23:22:32 -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 UAA00255;
	Thu, 26 Apr 2001 20:21:47 -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 UAA29859;
	Thu, 26 Apr 2001 20:21: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 f3R3JxIM021822
	for ; Thu, 26 Apr 2001 20:19:59 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3R3Jwpi021821
	for mobile-ip-dist; Thu, 26 Apr 2001 20:19: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 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 f3R3JlIM021814
	for ; Thu, 26 Apr 2001 20:19:49 -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 UAA14434
	for ; Thu, 26 Apr 2001 20:19:46 -0700 (PDT)
From: Basavaraj.Patil@nokia.com
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA25879
	for ; Thu, 26 Apr 2001 20:19:35 -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 f3R3Lnw18989
	for ; Thu, 26 Apr 2001 22:21:59 -0500 (CDT)
Received: from daebh01nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id ;
 Thu, 26 Apr 2001 22:19:24 -0500
Received: by daebh01nok with Internet Mail Service (5.5.2652.78)
	id ; Thu, 26 Apr 2001 22:19:24 -0500
Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B03213902@daeis07nok>
To: mobile-ip@sunroof.eng.sun.com
Cc: James.Kempf@Sun.COM
Subject: RE: [mobile-ip] Protocol Decision Fixed?
Date: Thu, 26 Apr 2001 22:19: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,

>In addition, they seem to be getting support from one WG
>chair and an AD who may have some vested interest in keeping 
>the protocol decision fixed, despite the somewhat dubious technical 
>grounds on which it was selected in the first place. 

I guess the one WG chair you refer to is me.
The comments that I have made w.r.t the HMIPv6 I-D and the LMM
problem is strictly as just any other WG participant. I am not wearing
my "co-chair" hat when I expressed my opinions. So please do not
construe things. 
And your accusation of having a vested interest in promoting this I-D
against another is ridiculous. 

-Basavaraj


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 23:27:02 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA00346
	for ; Thu, 26 Apr 2001 23:27: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 UAA02401;
	Thu, 26 Apr 2001 20:26:35 -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 UAA01741;
	Thu, 26 Apr 2001 20:26: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 f3R3PQIM021845
	for ; Thu, 26 Apr 2001 20:25:27 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3R3PQcq021844
	for mobile-ip-dist; Thu, 26 Apr 2001 20:25: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 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 f3R3PFIM021837
	for ; Thu, 26 Apr 2001 20:25: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 UAA01551
	for ; Thu, 26 Apr 2001 20:25:15 -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 UAA01698
	for ; Thu, 26 Apr 2001 20:25:13 -0700 (PDT)
Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM)
	id AA04280; Thu, 26 Apr 2001 23:25:13 -0400
Date: Thu, 26 Apr 2001 23:25:13 -0400 (EDT)
From: Jim Bound 
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Protocol Decision Fixed?
In-Reply-To: <7B5C0390ACE7D211BC9C0008C7EABA2B03213902@daeis07nok>
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 you always respond as individual.  I will say this publicly if you
like.

/jim

On Thu, 26 Apr 2001 Basavaraj.Patil@nokia.com wrote:

> James,
> 
> >In addition, they seem to be getting support from one WG
> >chair and an AD who may have some vested interest in keeping 
> >the protocol decision fixed, despite the somewhat dubious technical 
> >grounds on which it was selected in the first place. 
> 
> I guess the one WG chair you refer to is me.
> The comments that I have made w.r.t the HMIPv6 I-D and the LMM
> problem is strictly as just any other WG participant. I am not wearing
> my "co-chair" hat when I expressed my opinions. So please do not
> construe things. 
> And your accusation of having a vested interest in promoting this I-D
> against another is ridiculous. 
> 
> -Basavaraj
> 



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 26 23:28:24 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA00412
	for ; Thu, 26 Apr 2001 23:28: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 UAA03101;
	Thu, 26 Apr 2001 20:28:01 -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 UAA01964;
	Thu, 26 Apr 2001 20:27:56 -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 f3R3QjIM021855
	for ; Thu, 26 Apr 2001 20:26:45 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3R3QjY5021854
	for mobile-ip-dist; Thu, 26 Apr 2001 20:26: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 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 f3R3QYIM021847
	for ; Thu, 26 Apr 2001 20:26:35 -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 UAA07343
	for ; Thu, 26 Apr 2001 20:26:33 -0700 (PDT)
Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id VAA25971
	for ; Thu, 26 Apr 2001 21:28:53 -0600 (MDT)
Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM)
	id AA07894; Thu, 26 Apr 2001 23:26:27 -0400
Date: Thu, 26 Apr 2001 23:26:27 -0400 (EDT)
From: Jim Bound 
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Protocol Decision Fixed?
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: 

oh well I already did........but not on purpose....:---)

/jim

On Thu, 26 Apr 2001, Jim Bound wrote:

> I agree you always respond as individual.  I will say this publicly if you
> like.
> 
> /jim
> 
> On Thu, 26 Apr 2001 Basavaraj.Patil@nokia.com wrote:
> 
> > James,
> > 
> > >In addition, they seem to be getting support from one WG
> > >chair and an AD who may have some vested interest in keeping 
> > >the protocol decision fixed, despite the somewhat dubious technical 
> > >grounds on which it was selected in the first place. 
> > 
> > I guess the one WG chair you refer to is me.
> > The comments that I have made w.r.t the HMIPv6 I-D and the LMM
> > problem is strictly as just any other WG participant. I am not wearing
> > my "co-chair" hat when I expressed my opinions. So please do not
> > construe things. 
> > And your accusation of having a vested interest in promoting this I-D
> > against another is ridiculous. 
> > 
> > -Basavaraj
> > 
> 
> 



From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 27 02:55:07 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA17448
	for ; Fri, 27 Apr 2001 02:55:06 -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 XAA18567;
	Thu, 26 Apr 2001 23:54: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 XAA02238;
	Thu, 26 Apr 2001 23:54: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 f3R6rHIM022300
	for ; Thu, 26 Apr 2001 23:53:17 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3R6rGB6022299
	for mobile-ip-dist; Thu, 26 Apr 2001 23:53: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 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 f3R6r5IM022292
	for ; Thu, 26 Apr 2001 23:53:08 -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 XAA19580
	for ; Thu, 26 Apr 2001 23:53:06 -0700 (PDT)
Received: from ns2.iaf.fi (ns2.iaf.fi [195.94.103.2])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA00212
	for ; Fri, 27 Apr 2001 00:55:51 -0600 (MDT)
Received: from proxyfw.netseal.com (gw.netseal.com [195.94.100.110])
	by ns2.iaf.fi (8.11.2/8.11.2) with ESMTP id f3R6orC09635
	for ; Fri, 27 Apr 2001 09:50:53 +0300
Received: from (Undisclosed Firewall protected host)
	by Baudia Firewall with SMTP id IAA30789
	for ; Fri, 27 Apr 2001 08:55:00 +0300]
Message-ID: <006f01c0cee6$dd96a050$3f02a8c0@garibaldi>
From: "Sami Vaarala" 
To: 
References: <200104262301.QAA29425@heliopolis.eng.sun.com>
Subject: Re: [mobile-ip] Some Analysis
Date: Fri, 27 Apr 2001 09:54:12 +0300
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

James,

> > Numbers!!!
>
> After having unjustly flamed Erik this morning and being inspired by
> his challenge, I went through an analysis comparing signalling
> overhead on hierarchical v.s. nonhierarchical designs. The attached
> zipped PDF (sorry for the zip, I couldn't get a unzipped through the list
size
> filter) and text explain.
>
> Note to H&K: Arguments about the analysis are welcome, but please
> don't post "this won't happen in practice" arguments. You may have
> your opinion and I may have mine. The math speaks for itself.

When analysing the non-hierarchical case, you are summing all the
delays to calculate the latency.  Wouldn't the binding updates
(or registration requests) be sent in parallel to both HA, and all
CNs?  Thus the latency would be a maximum of a set of numbers, not
a sum ?

-Sami






From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 27 03:21:13 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA17845
	for ; Fri, 27 Apr 2001 03:21:12 -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 AAA29386;
	Fri, 27 Apr 2001 00:19: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 AAA28764;
	Fri, 27 Apr 2001 00: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 f3R7IZIM022330
	for ; Fri, 27 Apr 2001 00:18:36 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3R7IZ5I022329
	for mobile-ip-dist; Fri, 27 Apr 2001 00:18: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 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 f3R7IOIM022322
	for ; Fri, 27 Apr 2001 00:18:27 -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 AAA22112
	for ; Fri, 27 Apr 2001 00:18:24 -0700 (PDT)
Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA28582
	for ; Fri, 27 Apr 2001 00:18:23 -0700 (PDT)
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 JAA08783;
	Fri, 27 Apr 2001 09:18:16 +0200 (MET DST)
Message-ID: <3AE91D80.745D5873@darmstadt.gmd.de>
Date: Fri, 27 Apr 2001 09:19:28 +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: <200104262301.QAA29425@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

Oh (sigh of relief),
hope that this will make this mailing list discussion
a little bit more fruitful.

No problem with zips, ASCII math formulas etc.
The great thing is that statements are quantifi-ed/-able.

"Thus, the signalling latency in the hierarchical case will always be better."
That's what you can expect from similar questions (effect of divide-and-conquer).
More questions:
How much better is signalling latency?
How is payload affected?
Can the architectural complexities be measured
(which affect program development, maintenance, ...)?
Is there some overall measure which appropriately weights these factors?
And, most importantly, how can answers to these questions convince practicioners?

Wolfgang

James Kempf schrieb:
> 
> (second send, first perhaps filtered due to size...)
> 
> > Numbers!!!
> >
> 
> After having unjustly flamed Erik this morning and being inspired by
> his challenge, I went through an analysis comparing signalling
> overhead on hierarchical v.s. nonhierarchical designs. The attached
> zipped PDF (sorry for the zip, I couldn't get a unzipped through the list size
> filter) and text explain.
> 
> Note to H&K: Arguments about the analysis are welcome, but please
> don't post "this won't happen in practice" arguments. You may have
> your opinion and I may have mine. The math speaks for itself.
> 
>                 jak
> 
>   ----------------------------------------------------------------------------------------------------
>                               Name: lmm-analysis.zip
>                               Type: Zip Compressed Data (application/x-zip-compressed)
>    lmm-analysis.zip       Encoding: BASE64
>                        Description: lmm-analysis.zip
>                    Download-Status: Nicht mit der Nachricht heruntergeladen
> 
>                      Name: lmm.zip
>                      Type: Zip Compressed Data (application/x-zip-compressed)
>    lmm.zip       Encoding: BASE64
>               Description: lmm.zip
>           Download-Status: Nicht mit der Nachricht heruntergeladen

-- 
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  Fri Apr 27 03:58: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 DAA18490
	for ; Fri, 27 Apr 2001 03:58: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 AAA21268;
	Fri, 27 Apr 2001 00:58: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 AAA24070;
	Fri, 27 Apr 2001 00:57: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 f3R7u4IM022385
	for ; Fri, 27 Apr 2001 00:56:05 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3R7u4xD022384
	for mobile-ip-dist; Fri, 27 Apr 2001 00:56: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 f3R7tsIM022377
	for ; Fri, 27 Apr 2001 00:55:55 -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 AAA23926
	for ; Fri, 27 Apr 2001 00:55:55 -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 BAA20899
	for ; Fri, 27 Apr 2001 01:59:00 -0600 (MDT)
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 JAA12536
	for ; Fri, 27 Apr 2001 09:55:09 +0200 (MEST)
Message-ID: <3AE925DA.96EE7405@inrialpes.fr>
Date: Fri, 27 Apr 2001 09:55:06 +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] Some Analysis
References: <200104262301.QAA29425@heliopolis.eng.sun.com> <3AE91D80.745D5873@darmstadt.gmd.de> <3AE9245A.81D150B0@inrialpes.fr>
Content-Type: multipart/alternative;
 boundary="------------433C44766BD70091774C59CB"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

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


oups...
The analysis can actually be found at
http://www.inrialpes.fr/planete/people/ccastel/hmip.ps.gz

sorry about that ...

Claude.


Claude Castelluccia wrote:

> Hello,
>
> Some more analysis can be found in
> http://www.inrialpes.fr/people/ccastel/hmip.ps.gz
>
> This analysis was made 3 years ago when I was working on the design of
> one of the HMIPv6
> ancestor.
>
> Hope this help!
>
> regards,
>
> Claude.
>
> Wolfgang Schoenfeld wrote:
>
>> Oh (sigh of relief),
>> hope that this will make this mailing list discussion
>> a little bit more fruitful.
>>
>> No problem with zips, ASCII math formulas etc.
>> The great thing is that statements are quantifi-ed/-able.
>>
>> "Thus, the signalling latency in the hierarchical case will always
>> be better."
>> That's what you can expect from similar questions (effect of
>> divide-and-conquer).
>> More questions:
>> How much better is signalling latency?
>> How is payload affected?
>> Can the architectural complexities be measured
>> (which affect program development, maintenance, ...)?
>> Is there some overall measure which appropriately weights these
>> factors?
>> And, most importantly, how can answers to these questions convince
>> practicioners?
>>
>> Wolfgang
>>
>> James Kempf schrieb:
>> >
>> > (second send, first perhaps filtered due to size...)
>> >
>> > > Numbers!!!
>> > >
>> >
>> > After having unjustly flamed Erik this morning and being inspired
>> by
>> > his challenge, I went through an analysis comparing signalling
>> > overhead on hierarchical v.s. nonhierarchical designs. The
>> attached
>> > zipped PDF (sorry for the zip, I couldn't get a unzipped through
>> the list size
>> > filter) and text explain.
>> >
>> > Note to H&K: Arguments about the analysis are welcome, but please
>> > don't post "this won't happen in practice" arguments. You may have
>>
>> > your opinion and I may have mine. The math speaks for itself.
>> >
>> >                 jak
>> >
>> >
>> ----------------------------------------------------------------------------------------------------
>>
>> >                               Name: lmm-analysis.zip
>> >                               Type: Zip Compressed Data
>> (application/x-zip-compressed)
>> >    lmm-analysis.zip       Encoding: BASE64
>> >                        Description: lmm-analysis.zip
>> >                    Download-Status: Nicht mit der Nachricht
>> heruntergeladen
>> >
>> >                      Name: lmm.zip
>> >                      Type: Zip Compressed Data
>> (application/x-zip-compressed)
>> >    lmm.zip       Encoding: BASE64
>> >               Description: lmm.zip
>> >           Download-Status: Nicht mit der Nachricht heruntergeladen
>>
>> --
>> Wolfgang Schoenfeld, GMD-IPSI, Dolivostr. 15, D-64293 Darmstadt
>> Office: +49-6151-869-865 FAX: -6847 Mobile: +49-174-7093455
>
> --
>
> ----------------------------------------
> Claude CASTELLUCCIA, INRIA Rhone-Alpes
> ph:  +33 4.76.61.52.15 (fax: 52.52)
> http://www.inrialpes.fr/planete/
>
>

--

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



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



 

oups...

The analysis can actually be found at http://www.inrialpes.fr/planete/people/ccastel/hmip.ps.gz

sorry about that ...

Claude.

 

Claude Castelluccia wrote:

Hello,

Some more analysis can be found in http://www.inrialpes.fr/people/ccastel/hmip.ps.gz

This analysis was made 3 years ago when I was working on the design
of one of the HMIPv6

ancestor.

Hope this help!

regards,

Claude.

Wolfgang Schoenfeld wrote:

Oh (sigh of relief),

hope that this will make this mailing list discussion

a little bit more fruitful.

No problem with zips, ASCII math formulas etc.

The great thing is that statements are quantifi-ed/-able.

"Thus, the signalling latency in the hierarchical case will always be
better."

That's what you can expect from similar questions (effect of divide-and-conquer).

More questions:

How much better is signalling latency?

How is payload affected?

Can the architectural complexities be measured

(which affect program development, maintenance, ...)?

Is there some overall measure which appropriately weights these factors?

And, most importantly, how can answers to these questions convince
practicioners?

Wolfgang

James Kempf schrieb:

>

> (second send, first perhaps filtered due to size...)

>

> > Numbers!!!

> >

>

> After having unjustly flamed Erik this morning and being inspired
by

> his challenge, I went through an analysis comparing signalling

> overhead on hierarchical v.s. nonhierarchical designs. The attached

> zipped PDF (sorry for the zip, I couldn't get a unzipped through
the list size

> filter) and text explain.

>

> Note to H&K: Arguments about the analysis are welcome, but please

> don't post "this won't happen in practice" arguments. You may have

> your opinion and I may have mine. The math speaks for itself.

>

>                
jak

>

>   ----------------------------------------------------------------------------------------------------

>                              
Name: lmm-analysis.zip

>                              
Type: Zip Compressed Data (application/x-zip-compressed)

>    lmm-analysis.zip      
Encoding: BASE64

>                       
Description: lmm-analysis.zip

>                   
Download-Status: Nicht mit der Nachricht heruntergeladen

>

>                     
Name: lmm.zip

>                     
Type: Zip Compressed Data (application/x-zip-compressed)

>    lmm.zip       Encoding:
BASE64

>              
Description: lmm.zip

>           Download-Status:
Nicht mit der Nachricht heruntergeladen

--

Wolfgang Schoenfeld, GMD-IPSI, Dolivostr. 15, D-64293 Darmstadt

Office: +49-6151-869-865 FAX: -6847 Mobile: +49-174-7093455



-- 

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

 



-- 

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

 

--------------433C44766BD70091774C59CB--



From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 27 06:46:51 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA21363
	for ; Fri, 27 Apr 2001 06:46:50 -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 DAA04767;
	Fri, 27 Apr 2001 03:45:58 -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 DAA19204;
	Fri, 27 Apr 2001 03:45: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 f3RAihIM022617
	for ; Fri, 27 Apr 2001 03:44:43 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3RAih01022616
	for mobile-ip-dist; Fri, 27 Apr 2001 03:44:43 -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 f3RAiWIM022609
	for ; Fri, 27 Apr 2001 03:44:32 -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 DAA12838
	for ; Fri, 27 Apr 2001 03:44:32 -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 DAA16283
	for ; Fri, 27 Apr 2001 03:44:31 -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 GAA21030;
	Fri, 27 Apr 2001 06:44:29 -0400 (EDT)
Message-Id: <200104271044.GAA21030@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-fast-mipv6-01.txt
Date: Fri, 27 Apr 2001 06:44:28 -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		: Fast Handovers for Mobile IPv6
	Author(s)	: G. Tsirtsis, A. Yegin, C. Perkins, G. Dommety, 
                          K. Malki, M. Khalil
	Filename	: draft-ietf-mobileip-fast-mipv6-01.txt
	Pages		: 35
	Date		: 26-Apr-01
	
This document specifies protocol enhancements to MIPv6 that enable 
mobile nodes to more quickly become connected at new points of 
attachment to the Internet.  These protocol enhancements are intended 
to minimize the time during which the mobile node is unable to send 
or receive IPv6 packets (i.e., the handover latency).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-fast-mipv6-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-fast-mipv6-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-fast-mipv6-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:	<20010426132359.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mobileip-fast-mipv6-01.txt

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

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

--OtherAccess--

--NextPart--




From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 27 06:54: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 GAA21776
	for ; Fri, 27 Apr 2001 06:54: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 AAA19785;
	Fri, 27 Apr 2001 00:51:59 -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 AAA01058;
	Fri, 27 Apr 2001 00:51:46 -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 f3R7nfIM022362
	for ; Fri, 27 Apr 2001 00:49:41 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3R7nfPg022361
	for mobile-ip-dist; Fri, 27 Apr 2001 00: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 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 f3R7nUIM022354
	for ; Fri, 27 Apr 2001 00:49: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 AAA24246
	for ; Fri, 27 Apr 2001 00:49:30 -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 BAA18816
	for ; Fri, 27 Apr 2001 01:52:23 -0600 (MDT)
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 JAA12327
	for ; Fri, 27 Apr 2001 09:48:45 +0200 (MEST)
Message-ID: <3AE9245A.81D150B0@inrialpes.fr>
Date: Fri, 27 Apr 2001 09:48:42 +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] Some Analysis
References: <200104262301.QAA29425@heliopolis.eng.sun.com> <3AE91D80.745D5873@darmstadt.gmd.de>
Content-Type: multipart/alternative;
 boundary="------------C206A8D2A30DB13778FD9209"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

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

Hello,

Some more analysis can be found in http://www.inrialpes.fr/people/ccastel/hmip.ps.gz

This analysis was made 3 years ago when I was working on the design of one of the HMIPv6
ancestor.

Hope this help!

regards,

Claude.

Wolfgang Schoenfeld wrote:

> Oh (sigh of relief),
> hope that this will make this mailing list discussion
> a little bit more fruitful.
>
> No problem with zips, ASCII math formulas etc.
> The great thing is that statements are quantifi-ed/-able.
>
> "Thus, the signalling latency in the hierarchical case will always be better."
> That's what you can expect from similar questions (effect of divide-and-conquer).
> More questions:
> How much better is signalling latency?
> How is payload affected?
> Can the architectural complexities be measured
> (which affect program development, maintenance, ...)?
> Is there some overall measure which appropriately weights these factors?
> And, most importantly, how can answers to these questions convince practicioners?
>
> Wolfgang
>
> James Kempf schrieb:
> >
> > (second send, first perhaps filtered due to size...)
> >
> > > Numbers!!!
> > >
> >
> > After having unjustly flamed Erik this morning and being inspired by
> > his challenge, I went through an analysis comparing signalling
> > overhead on hierarchical v.s. nonhierarchical designs. The attached
> > zipped PDF (sorry for the zip, I couldn't get a unzipped through the list size
> > filter) and text explain.
> >
> > Note to H&K: Arguments about the analysis are welcome, but please
> > don't post "this won't happen in practice" arguments. You may have
> > your opinion and I may have mine. The math speaks for itself.
> >
> >                 jak
> >
> >   ----------------------------------------------------------------------------------------------------
> >                               Name: lmm-analysis.zip
> >                               Type: Zip Compressed Data (application/x-zip-compressed)
> >    lmm-analysis.zip       Encoding: BASE64
> >                        Description: lmm-analysis.zip
> >                    Download-Status: Nicht mit der Nachricht heruntergeladen
> >
> >                      Name: lmm.zip
> >                      Type: Zip Compressed Data (application/x-zip-compressed)
> >    lmm.zip       Encoding: BASE64
> >               Description: lmm.zip
> >           Download-Status: Nicht mit der Nachricht heruntergeladen
>
> --
> Wolfgang Schoenfeld, GMD-IPSI, Dolivostr. 15, D-64293 Darmstadt
> Office: +49-6151-869-865 FAX: -6847 Mobile: +49-174-7093455

--

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



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



Hello,

Some more analysis can be found in http://www.inrialpes.fr/people/ccastel/hmip.ps.gz

This analysis was made 3 years ago when I was working on the design
of one of the HMIPv6

ancestor.

Hope this help!

regards,

Claude.

Wolfgang Schoenfeld wrote:

Oh (sigh of relief),

hope that this will make this mailing list discussion

a little bit more fruitful.

No problem with zips, ASCII math formulas etc.

The great thing is that statements are quantifi-ed/-able.

"Thus, the signalling latency in the hierarchical case will always be
better."

That's what you can expect from similar questions (effect of divide-and-conquer).

More questions:

How much better is signalling latency?

How is payload affected?

Can the architectural complexities be measured

(which affect program development, maintenance, ...)?

Is there some overall measure which appropriately weights these factors?

And, most importantly, how can answers to these questions convince
practicioners?

Wolfgang

James Kempf schrieb:

>

> (second send, first perhaps filtered due to size...)

>

> > Numbers!!!

> >

>

> After having unjustly flamed Erik this morning and being inspired
by

> his challenge, I went through an analysis comparing signalling

> overhead on hierarchical v.s. nonhierarchical designs. The attached

> zipped PDF (sorry for the zip, I couldn't get a unzipped through
the list size

> filter) and text explain.

>

> Note to H&K: Arguments about the analysis are welcome, but please

> don't post "this won't happen in practice" arguments. You may have

> your opinion and I may have mine. The math speaks for itself.

>

>                
jak

>

>   ----------------------------------------------------------------------------------------------------

>                              
Name: lmm-analysis.zip

>                              
Type: Zip Compressed Data (application/x-zip-compressed)

>    lmm-analysis.zip      
Encoding: BASE64

>                       
Description: lmm-analysis.zip

>                   
Download-Status: Nicht mit der Nachricht heruntergeladen

>

>                     
Name: lmm.zip

>                     
Type: Zip Compressed Data (application/x-zip-compressed)

>    lmm.zip       Encoding:
BASE64

>              
Description: lmm.zip

>           Download-Status:
Nicht mit der Nachricht heruntergeladen

--

Wolfgang Schoenfeld, GMD-IPSI, Dolivostr. 15, D-64293 Darmstadt

Office: +49-6151-869-865 FAX: -6847 Mobile: +49-174-7093455



-- 

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

 

--------------C206A8D2A30DB13778FD9209--



From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 27 07:28:23 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA23441
	for ; Fri, 27 Apr 2001 07:28:23 -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 EAA20784;
	Fri, 27 Apr 2001 04:27:44 -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 EAA08621;
	Fri, 27 Apr 2001 04:27: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 f3RBPaIM022716
	for ; Fri, 27 Apr 2001 04:25:37 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3RBPaGY022715
	for mobile-ip-dist; Fri, 27 Apr 2001 04:25: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 f3RBPKIM022693
	for ; Fri, 27 Apr 2001 04:25:22 -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 EAA16141
	for ; Fri, 27 Apr 2001 04:25:19 -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 FAA01254
	for ; Fri, 27 Apr 2001 05:28:54 -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 f3RBPGN20951
	for ; Fri, 27 Apr 2001 13:25:16 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Apr 27 13:24:54 2001 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Fri, 27 Apr 2001 13:20:13 +0200
Message-ID: 
From: "Karim El-Malki (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Protocol Decision Fixed?
Date: Fri, 27 Apr 2001 13:24:52 +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 Jim

> I don't agree with Karim that one LMM per cloud is all that 
> will ever be
> needed simply because the cloud will be too large in some 
> cases as a metro
> network (e.g. LA, Boston, London, Tokyo, Paris).

My point was the other way round. I don't think that LMM
clouds/domains will be so small so that you continuously have
to change LMMs when you move. I agree that you wouldn't want
to have a LMM cover LA, Boston etc. On the other hand a LMM
could cover LA or a parts of LA, which makes changing the LMM a
rare event. I think it's been said previously that you can design
the network appropriately for this.

> Also think about this.  I leave my office and I am mobile with my PDA
> gambling on the horses and keep doing it in my car.  While 
> heading to the
> bar I hit another access router and then in the bar I hit 
> their wireline
> 10MB xDSL access router and get a cheaper rate and jump off 
> the metro cost
> to the xDSL cheaper cost.  Still gambling in the bar on my 
> PDA.  Then I
> jump into a taxi to get home and hit the metro again.  Then I 
> finally get
> home watching the wagers on the last race in my house and now 
> jump on that
> Access Router at my home xDSL which is the cheapest rate for 
> connectivity
> via my access point in my house.  Win a million dollars and go to bed.
> 
> I would argue the above was all in the same cloud in metro LA and the
> wager access was in the city seciton I work, party, and live 
> in.  Its a
> subset of the cloud.  And there were other subsets in the 
> cloud (the car,
> taxi, bar, home) which are LMMs.  

OK. But such a multi-access ISP (xDSL, wireless) could also achieve this
by having one LMM (or a set of them for reliability and sharing of MN
load) and ARs connected to the different access technologies through
the city (i.e. what you called subsets in the cloud). You could still move,
get the different rates and change technologies, but you wouldn't have
to change LMM. Do you need to have/use a LMM in the bar and at home?

Regards
/Karim


From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 27 07:33:10 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA23628
	for ; Fri, 27 Apr 2001 07:33:09 -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 EAA22778;
	Fri, 27 Apr 2001 04:32: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 EAA16653;
	Fri, 27 Apr 2001 04:32:17 -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 f3RBV8IM022878
	for ; Fri, 27 Apr 2001 04:31:09 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3RBV80h022877
	for mobile-ip-dist; Fri, 27 Apr 2001 04:31: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 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 f3RBUvIM022870
	for ; Fri, 27 Apr 2001 04:30:59 -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 EAA08879
	for ; Fri, 27 Apr 2001 04:30:56 -0700 (PDT)
Received: from c007.snv.cp.net (c007-h000.c007.snv.cp.net [209.228.33.206])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id EAA01444
	for ; Fri, 27 Apr 2001 04:30:56 -0700 (PDT)
Received: (cpmta 11521 invoked from network); 27 Apr 2001 04:30:55 -0700
Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129)
  by smtp.telocity.com (209.228.33.206) with SMTP; 27 Apr 2001 04:30:55 -0700
X-Sent: 27 Apr 2001 11:30:55 GMT
Message-ID: <010901c0cf0d$6a6e1e60$6401a8c0@philneum>
From: "Phil Neumiller" 
To: 
References: 
Subject: Re: [mobile-ip] Protocol Decision Fixed?
Date: Fri, 27 Apr 2001 06:30:02 -0500
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: 

Some comments.
----- Original Message -----
From: "Karim El-Malki (ERA)" 
To: 
Sent: Friday, April 27, 2001 6:24 AM
Subject: RE: [mobile-ip] Protocol Decision Fixed?


> Hello Jim
>
> > I don't agree with Karim that one LMM per cloud is all that
> > will ever be
> > needed simply because the cloud will be too large in some
> > cases as a metro
> > network (e.g. LA, Boston, London, Tokyo, Paris).
>
> My point was the other way round. I don't think that LMM
> clouds/domains will be so small so that you continuously have
> to change LMMs when you move.

Well, you will be changing access routers almost every time
and definitely when you cross AD boundaries right?

-Phil




From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 27 07:58:44 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA24548
	for ; Fri, 27 Apr 2001 07:58: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 EAA03078;
	Fri, 27 Apr 2001 04:58: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 EAA24087;
	Fri, 27 Apr 2001 04:58: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 f3RBv5IM022920
	for ; Fri, 27 Apr 2001 04:57:05 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3RBv5KK022919
	for mobile-ip-dist; Fri, 27 Apr 2001 04:57:05 -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 f3RBurIM022912
	for ; Fri, 27 Apr 2001 04:56:56 -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 EAA23965
	for ; Fri, 27 Apr 2001 04:56:52 -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 GAA12428
	for ; Fri, 27 Apr 2001 06:00:26 -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 f3RBunN17943
	for ; Fri, 27 Apr 2001 13:56:49 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Apr 27 13:56:34 2001 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Fri, 27 Apr 2001 13:56:34 +0200
Message-ID: 
From: "Karim El-Malki (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Protocol Decision Fixed?
Date: Fri, 27 Apr 2001 13:56: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 Phil

> >
> > > I don't agree with Karim that one LMM per cloud is all that
> > > will ever be
> > > needed simply because the cloud will be too large in some
> > > cases as a metro
> > > network (e.g. LA, Boston, London, Tokyo, Paris).
> >
> > My point was the other way round. I don't think that LMM
> > clouds/domains will be so small so that you continuously have
> > to change LMMs when you move.
> 
> Well, you will be changing access routers almost every time
> and definitely when you cross AD boundaries right?

Of course the MN can change ARs and can move between admin domains,
but I don't think there's a one-to-one mapping with the change in
LMM in the comment above. Maybe you want to elaborate more. 

/Karim


From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 27 08:04:59 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA24773
	for ; Fri, 27 Apr 2001 08:04: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 FAA05562;
	Fri, 27 Apr 2001 05:03: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 FAA18092;
	Fri, 27 Apr 2001 05:03: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 f3RC2tIM022945
	for ; Fri, 27 Apr 2001 05:02:55 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3RC2t5w022944
	for mobile-ip-dist; Fri, 27 Apr 2001 05:02:55 -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 f3RC2hIM022934
	for ; Fri, 27 Apr 2001 05:02: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 FAA18926
	for ; Fri, 27 Apr 2001 05:02:42 -0700 (PDT)
Received: from c007.snv.cp.net (c007-h011.c007.snv.cp.net [209.228.33.217])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id FAA04451
	for ; Fri, 27 Apr 2001 05:02:42 -0700 (PDT)
Received: (cpmta 27680 invoked from network); 27 Apr 2001 05:02:42 -0700
Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129)
  by smtp.telocity.com (209.228.33.217) with SMTP; 27 Apr 2001 05:02:42 -0700
X-Sent: 27 Apr 2001 12:02:42 GMT
Message-ID: <011101c0cf11$daf72ec0$6401a8c0@philneum>
From: "Phil Neumiller" 
To: 
References: 
Subject: Re: [mobile-ip] Protocol Decision Fixed?
Date: Fri, 27 Apr 2001 07:01:49 -0500
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: 

Comments below.
----- Original Message -----
From: "Karim El-Malki (ERA)" 
To: 
Sent: Friday, April 27, 2001 6:56 AM
Subject: RE: [mobile-ip] Protocol Decision Fixed?


> Hi Phil
>
> > >
> > > > I don't agree with Karim that one LMM per cloud is all that
> > > > will ever be
> > > > needed simply because the cloud will be too large in some
> > > > cases as a metro
> > > > network (e.g. LA, Boston, London, Tokyo, Paris).
> > >
> > > My point was the other way round. I don't think that LMM
> > > clouds/domains will be so small so that you continuously have
> > > to change LMMs when you move.
> >
> > Well, you will be changing access routers almost every time
> > and definitely when you cross AD boundaries right?
>
> Of course the MN can change ARs and can move between admin domains,
> but I don't think there's a one-to-one mapping with the change in
> LMM in the comment above. Maybe you want to elaborate more.
>
> /Karim
>
I guess I have elaborated in this thread already. I am proposing a third (3rd)
protocol solution where the LMM can be "hosted" in any AR and follows
the MN around by using SeaMoby CT.  What I can't seem to get an
answer on from Phil R. or Raj is whether a draft supporting this 3rd protocol
would be looked at as a candidate for this problem.  I want to create the
draft but I want to make sure that it will at least have a chance against
the other two proposals.

Thanks,

Phil




From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 27 08:29:00 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 IAA26013
	for ; Fri, 27 Apr 2001 08:28: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 FAA28682;
	Fri, 27 Apr 2001 05:28: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 FAA19957;
	Fri, 27 Apr 2001 05:28: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 f3RCR8IM022970
	for ; Fri, 27 Apr 2001 05:27:08 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3RCR7pJ022969
	for mobile-ip-dist; Fri, 27 Apr 2001 05:27: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 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 f3RCQuIM022962
	for ; Fri, 27 Apr 2001 05:26: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 FAA26472
	for ; Fri, 27 Apr 2001 05:26:57 -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 FAA15625
	for ; Fri, 27 Apr 2001 05:26:56 -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 f3RCQtN12342
	for ; Fri, 27 Apr 2001 14:26:55 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Fri Apr 27 14:26:23 2001 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Fri, 27 Apr 2001 14:21:41 +0200
Message-ID: 
From: "Karim El-Malki (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Protocol Decision Fixed?
Date: Fri, 27 Apr 2001 14:26:15 +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 Phil

> > > >
> > > > > I don't agree with Karim that one LMM per cloud is all that
> > > > > will ever be
> > > > > needed simply because the cloud will be too large in some
> > > > > cases as a metro
> > > > > network (e.g. LA, Boston, London, Tokyo, Paris).
> > > >
> > > > My point was the other way round. I don't think that LMM
> > > > clouds/domains will be so small so that you continuously have
> > > > to change LMMs when you move.
> > >
> > > Well, you will be changing access routers almost every time
> > > and definitely when you cross AD boundaries right?
> >
> > Of course the MN can change ARs and can move between admin domains,
> > but I don't think there's a one-to-one mapping with the change in
> > LMM in the comment above. Maybe you want to elaborate more.
> >
> > /Karim
> >
> I guess I have elaborated in this thread already. I am 
> proposing a third (3rd)
> protocol solution where the LMM can be "hosted" in any AR and follows
> the MN around by using SeaMoby CT.  What I can't seem to get an
> answer on from Phil R. or Raj is whether a draft supporting 
> this 3rd protocol
> would be looked at as a candidate for this problem.  I want 
> to create the
> draft but I want to make sure that it will at least have a 
> chance against
> the other two proposals.

I don't think the LMM should be tied to Seamoby CT, and it doesn't
have to be in the AR (although it can be). There is a WG draft as
you know called HMIPv6. The LMM (MAP) can be located anywhere,
even at the AR. Would that not address your problem?
Applying CT would then be independent of whether it is an AR or MAP?
Any comments on the draft are welcome.

Regards
/Karim


From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 27 09:16:00 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27797
	for ; Fri, 27 Apr 2001 09:15: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 GAA10042;
	Fri, 27 Apr 2001 06:11:08 -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 GAA24206;
	Fri, 27 Apr 2001 06:11: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 f3RD9pIM023217
	for ; Fri, 27 Apr 2001 06:09:51 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3RD9pdU023216
	for mobile-ip-dist; Fri, 27 Apr 2001 06:09: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 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 f3RD9fIM023209
	for ; Fri, 27 Apr 2001 06:09:42 -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 GAA24409
	for ; Fri, 27 Apr 2001 06:09:42 -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 GAA07977
	for ; Fri, 27 Apr 2001 06:09:41 -0700 (PDT)
Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 27 Apr 2001 09:03:40 -0400
Message-ID: 
From: Phil Roberts 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Protocol Decision Fixed?
Date: Fri, 27 Apr 2001 09:03: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: 

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.

Phil


> -----Original Message-----
> From: Phil Neumiller [mailto:neumiller@telocity.com]
> Sent: Thursday, April 26, 2001 3:50 PM
> To: mobile-ip@sunroof.eng.sun.com
> Subject: Re: [mobile-ip] Protocol Decision Fixed?
> 
> 
> Phil R.,
> 
> So if I submit a new draft, that competes with the existing 
> two protocol
> proposals will it  be ignored?  If the requirements of the 
> existing proposals
> are suitable then its a horse race right?  What if I have a 
> faster horse?
> 
> Thanks,
> 
> Phil N.
> 
> ----- Original Message -----
> From: "Phil Roberts" 
> To: 
> Sent: Thursday, April 26, 2001 1:28 PM
> Subject: RE: [mobile-ip] Protocol Decision Fixed?
> 
> 
> > Hi,
> >
> >     Is there a question buried in here or are you just 
> venting?  I think the
> > WG is having a fairly productive discussion of requirements 
> right now.  Why
> > don't we finish that before trying to decide whether to 
> revisit the choice
> > of draft to take forward?
> >
> > Phil
> >
> >
> > > -----Original Message-----
> > > From: James Kempf [mailto:James.Kempf@Sun.COM]
> > > Sent: Thursday, April 26, 2001 12:50 PM
> > > To: mobile-ip@sunroof.eng.sun.com
> > > Subject: [mobile-ip] Protocol Decision Fixed?
> > >
> > >
> > > Hi Phil,
> > >
> > >
> > > >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.
> > > >
> > > >
> > >
> > > A requirements phase is usually gone through in order to 
> define what
> > > the protocol needs to accomplish. Doing a requirements analysis
> > > subsequent to selecting a protocol is a bit like putting on your
> > > bathing suit after you've jumped into the water with your cloths
> > > on. :-) The tendency is to "cook" the requirements to satisfy the
> > > already selected protocol. IMHO, we are seeing a bit of that
> > > now, with the authors of the selected protocol arguing strenuously
> > > against including requirements which their protocol currently
> > > can't support. In addition, they seem to be getting support
> > > from one WG
> > > chair and an AD who may have some vested interest in keeping
> > > the protocol decision fixed, despite the somewhat dubious 
> technical
> > > grounds on which it was selected in the first place.
> > > Meanwhile, those other
> > > members of the working group who have spoken up have largely
> > > been arguing in the
> > > opposite direction.
> > >
> > > If the IESG and WG chairs decide they want to keep the protocol
> > > decision fixed, then let's simply drop discussion of requirements
> > > and rubber stamp HMIP. I'm perfectly fine with that. There's
> > > no point in wasting
> > > transcontinental bandwidth on email any further. Clearly,
> > > we're in the
> > > "political" layer of the IP stack here. :-)
> > >
> > > jak
> > >
> >
> 
> 


From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 27 09:24:57 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28131
	for ; Fri, 27 Apr 2001 09:24: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 GAA18115;
	Fri, 27 Apr 2001 06:24: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 GAA18525;
	Fri, 27 Apr 2001 06:24: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 f3RDMHIM023272
	for ; Fri, 27 Apr 2001 06:22:17 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3RDMHl2023271
	for mobile-ip-dist; Fri, 27 Apr 2001 06:22: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 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 f3RDM6IM023264
	for ; Fri, 27 Apr 2001 06:22:08 -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 GAA02806
	for ; Fri, 27 Apr 2001 06:22:07 -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 GAA00257
	for ; Fri, 27 Apr 2001 06:22:06 -0700 (PDT)
Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 27 Apr 2001 09:16:06 -0400
Message-ID: 
From: Phil Roberts 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Protocol Decision Fixed?
Date: Fri, 27 Apr 2001 09:16:06 -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 guess I have elaborated in this thread already. I am 
> proposing a third (3rd)
> protocol solution where the LMM can be "hosted" in any AR and follows
> the MN around by using SeaMoby CT.  What I can't seem to get an
> answer on from Phil R. or Raj is whether a draft supporting 
> this 3rd protocol
> would be looked at as a candidate for this problem.  I want 
> to create the
> draft but I want to make sure that it will at least have a 
> chance against
> the other two proposals.
> 
> Thanks,
> 
> Phil
> 
> 

Hi,

    I posted a response to your earlier question just now.  Hope it helps.
It's not really possible to prejudge whether or not a draft would be
considered.  Like I said in the other post, in the interest of progress it's
good to avoid churn, and proposed some questions that are worth asking. 

Phil


From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 27 09:26:06 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28240
	for ; Fri, 27 Apr 2001 09:26:05 -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 GAA19129;
	Fri, 27 Apr 2001 06:25:36 -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 GAA18732;
	Fri, 27 Apr 2001 06:25: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 f3RDNmIM023299
	for ; Fri, 27 Apr 2001 06:23:48 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3RDNlwB023298
	for mobile-ip-dist; Fri, 27 Apr 2001 06:23: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 f3RDNfIM023284
	for ; Fri, 27 Apr 2001 06:23:41 -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 JAA01101
	for ; Fri, 27 Apr 2001 09:23:41 -0400 (EDT)
Received: (from glass@localhost)
	by onion.east.sun.com (8.9.3+Sun/8.9.3) id JAA25377
	for mobile-ip@sunroof.eng.sun.com; Fri, 27 Apr 2001 09:23:54 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QK8OK9020372
	for ; Thu, 26 Apr 2001 13:08:24 -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 NAA16924
	for ; Thu, 26 Apr 2001 13:08:22 -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 NAA12228
	for ; Thu, 26 Apr 2001 13:08:14 -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 f3QK87N26082
	for ; Thu, 26 Apr 2001 22:08:07 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Apr 26 22:08:07 2001 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Thu, 26 Apr 2001 22:08:06 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBDC5@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: Thu, 26 Apr 2001 22:08:04 +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: 

	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. 


	Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 27 10:16:51 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00724
	for ; Fri, 27 Apr 2001 10:16:50 -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 HAA24194;
	Fri, 27 Apr 2001 07:16:24 -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 HAA01740;
	Fri, 27 Apr 2001 07:15:56 -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 f3REDpIM024060
	for ; Fri, 27 Apr 2001 07:13:52 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3REDpe2024059
	for mobile-ip-dist; Fri, 27 Apr 2001 07:13: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 f3REDXIM024044
	for ; Fri, 27 Apr 2001 07:13:35 -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 HAA13578
	for ; Fri, 27 Apr 2001 07:13:34 -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 HAA07327
	for ; Fri, 27 Apr 2001 07:13:19 -0700 (PDT)
Received: (qmail 10369 invoked by uid 500); 27 Apr 2001 14:03:23 -0000
Date: Fri, 27 Apr 2001 07:03:23 -0700
From: Pat Calhoun 
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Protocol Decision Fixed?
Message-ID: <20010427070323.T2738@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 Fri, Apr 27, 2001 at 09:03:40AM -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, 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


From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 27 11:55: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 LAA06472
	for ; Fri, 27 Apr 2001 11:55: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 IAA19006;
	Fri, 27 Apr 2001 08:53: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 IAA23865;
	Fri, 27 Apr 2001 08:25: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 f3RFNtIM024166
	for ; Fri, 27 Apr 2001 08:23:56 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3RFNt83024165
	for mobile-ip-dist; Fri, 27 Apr 2001 08:23:55 -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 f3RFNjIM024158
	for ; Fri, 27 Apr 2001 08:23: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 IAA04345
	for ; Fri, 27 Apr 2001 08:23:45 -0700 (PDT)
From: Franck.Le@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 JAA15694
	for ; Fri, 27 Apr 2001 09:28:23 -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 f3RFNng22623
	for ; Fri, 27 Apr 2001 10:23:49 -0500 (CDT)
Received: from daebh02nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id  for ;
 Fri, 27 Apr 2001 10:23:43 -0500
Received: by daebh02nok with Internet Mail Service (5.5.2652.78)
	id ; Fri, 27 Apr 2001 10:23:43 -0500
Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B028DC6E3@daeis07nok>
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] I-D ACTION:draft-le-mobileip-dh-00.txt
Date: Fri, 27 Apr 2001 10:23:43 -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: 

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


        Title           : Dynamic Diffie Hellman based Key Distribution for 
                          Mobile IPv6
        Author(s)       : F. Le
        Filename        : draft-le-mobileip-dh-00.txt
        Pages           : 12
        Date            : 25-Apr-01
        
Mobile IP requires several security associations: the Mobile Node
must share a security association with its Home agent and its
Correspondent Nodes to send the binding Update; these messages need
to be authenticated to prevent some kind of denial of service
attacks.  When some Mobile IP extensions such as [HMPIv6] or
[RegRegv6] are deployed, the MN also has to set up a security
association with the Mobility Agents.

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

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

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


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

Send a message to:
        mailserv@ietf.org.
In the body type:
        "FILE /internet-drafts/draft-le-mobileip-dh-00.txt".
        
NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.
                



From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 27 12:07:14 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06955
	for ; Fri, 27 Apr 2001 12:07: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 JAA21071;
	Fri, 27 Apr 2001 09:06: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 IAA08971;
	Fri, 27 Apr 2001 08:10:17 -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 f3RF92IM024129
	for ; Fri, 27 Apr 2001 08:09:02 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3RF92Hj024128
	for mobile-ip-dist; Fri, 27 Apr 2001 08:09: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 f3RF8pIM024121
	for ; Fri, 27 Apr 2001 08:08: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 IAA08806
	for ; Fri, 27 Apr 2001 08:08:52 -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 IAA04562
	for ; Fri, 27 Apr 2001 08:08:47 -0700 (PDT)
Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 27 Apr 2001 11:02:44 -0400
Message-ID: 
From: Phil Roberts 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Protocol Decision Fixed?
Date: Fri, 27 Apr 2001 11:02: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: 

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

I don't think so either.

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

Do you feel that the current requirements gathering is hindered by the fact
that the working group already has a document proposing a solution?  What
other requirements might we see if this weren't the case?

> 
> I think that limiting contributions to existing proposals is the wrong
> approach.
> 
> my 2 cents,

It's worth more than that I'd say.

Phil

> 
> PatC
> 


From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 27 12:07:17 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06966
	for ; Fri, 27 Apr 2001 12:07:16 -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 JAA21480;
	Fri, 27 Apr 2001 09:06:59 -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 JAA12128;
	Fri, 27 Apr 2001 09:06: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 f3RG4TIM024215
	for ; Fri, 27 Apr 2001 09:04:29 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3RG4St4024214
	for mobile-ip-dist; Fri, 27 Apr 2001 09:04: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 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 f3RG4KIM024207
	for ; Fri, 27 Apr 2001 09:04:20 -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 JAA14028
	for ; Fri, 27 Apr 2001 09:04:20 -0700 (PDT)
Message-Id: <200104271604.JAA14028@heliopolis.eng.sun.com>
Date: Fri, 27 Apr 2001 09:04:20 -0700 (PDT)
From: James Kempf 
Subject: RE: [mobile-ip] Protocol Decision Fixed?
To: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 8zxicM3s3jhPnlkv2cam4Q==
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 Phil,

Here's my $0.02.

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

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.

3) There is more awareness in the working group, as with the IETF
at large, in the necessity and value of doing requriements prior to selecting
a protocol. If the process is done in the other direction, there
is a tendency to "cook" the requirements to match the protocol.

>"What requirements have changed since we made the decision?" 

There were no explicitly stated, concensus-defined technical requirements when 
the decision was made. As I understand the history of the decision, it was made 
because two drafts were viewed as being easy to understand, and were combined. A 
question was put to the list about whether the draft should be made a working
group draft, and nobody responded. A third draft was viewed as
too complex because some people had questions on it. While understandability
at first presentation is important for good design, using that as the single 
requirement for a working group draft seems somewhat questionable.

There are some implicit requirements that came out of the RegV4 work
(which was also done without an explicit requirments definition phase).
Most of these seem to be showing up in the requirements that we've
been discussing on the list, but there are others that have come
out of the discussion over the last few weeks.
 
>How to proceed is based on working group consensus.
>

My suggestion is to open up the protocol selection phase, allow PhilN
to submit his draft. There are then two possibilities:

1) Have three people who have not been active participants in the requirements 
dicussion nor are they co-authors on any of the drafts nor do they have any 
vested interest in the decision sit down and match the requirements 
against the protocols. The protocol that best matches the requirements
becomes the working group draft.

2) Form a design team of draft authors, as was done for the low latency
handoff work, to combine the three drafts into one that has working
group concensus and meets the requirements.

The first procedure was successfully followed by the AAA working group,
the second, though somewhat controversial, is being pursued currently
in the MIP working group.

		jak




From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 27 12:13:36 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07279
	for ; Fri, 27 Apr 2001 12:13:35 -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 JAA28696;
	Fri, 27 Apr 2001 09:13:18 -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 JAA20022;
	Fri, 27 Apr 2001 09:13: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 f3RGC2IM024278
	for ; Fri, 27 Apr 2001 09:12:02 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3RGC1wX024277
	for mobile-ip-dist; Fri, 27 Apr 2001 09: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 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 f3RGBoIM024261
	for ; Fri, 27 Apr 2001 09:11:50 -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 JAA13636
	for ; Fri, 27 Apr 2001 09:11:50 -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 JAA27412
	for ; Fri, 27 Apr 2001 09:11:49 -0700 (PDT)
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 f3RGBsg29773
	for ; Fri, 27 Apr 2001 11:11:54 -0500 (CDT)
Received: from daebh01nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id  for ;
 Fri, 27 Apr 2001 11:11:48 -0500
Received: by daebh01nok with Internet Mail Service (5.5.2652.78)
	id ; Fri, 27 Apr 2001 11:11:48 -0500
Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B03213908@daeis07nok>
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] LMM Process thoughts...
Date: Fri, 27 Apr 2001 11:11:46 -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: 

Some background:

0. I am not sure if WG members are aware that the WG went through 
    a consensus call on picking a WG document on hierarchical mobility 
    sometime last year. At the time of the consensus call, there were no 
    responses. It's only after almost a year of this work becoming a WG 
    document that WG members have expressed concerned with the I-D
    and the process. So if you think the work was slipped into the WG 
    under the radar, that's hogwash. I wish people would pay attention to 
    WG last calls and consensus calls on the list and respond to them. 

1. The reason for starting an analysis of the requirements was not to
   ratify the HMIPv6 I-D which was approved as a WG document and to
   tailor the requirements around a proposed solution.
   The renewed interest in local mobility is the reason for doing a
   study of the requirements, and this is not just an exercise for
   academic reasons or to stimulate interest in this work in the
   WG. We obviously want to use these requirements to ensure that any
   solution for LM is something that most people in the WG agree on or
   there is broad consensus.
   
   So what do we do, now that we have defined a set of requirements:
   1. We can re-evaluate the proposed protocols against these
   requirements, although we do not necessarily want to go through a
   protocol beauty contest. 
   2. We can make the necessary changes to HMIPv6 as per the
   requirements and simplify the current proposal/I-D to only address
   these requirements and drop everything else from the I-D
   3. If there are concepts from the other draft (regreg6) that is not
   a WG document that need to be considered, I am sure we can include
   those by extending the current WG doc

2. The IETF is an open forum and people are welcome to send in different
    proposals to the same problem. Ultimately WG consensus will make the
    decision. The only problem is that if we keep on doing this, we will
probably
    never converge on any solution as such and the implications of this are
    no implementations/interworking and adoption by the industry.

-Basavaraj





From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 27 12:42: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 MAA08015
	for ; Fri, 27 Apr 2001 12:42:01 -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 JAA14597;
	Fri, 27 Apr 2001 09:40:50 -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 JAA08882;
	Fri, 27 Apr 2001 09:40: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 f3RGd9IM024325
	for ; Fri, 27 Apr 2001 09:39:09 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3RGd8WE024324
	for mobile-ip-dist; Fri, 27 Apr 2001 09:39: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 f3RGcwIM024317
	for ; Fri, 27 Apr 2001 09:39: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 JAA08493
	for ; Fri, 27 Apr 2001 09:38:59 -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 KAA28140
	for ; Fri, 27 Apr 2001 10:44:27 -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 LAA06819
	for ; Fri, 27 Apr 2001 11:38:56 -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 f3RGctn21033
	for ; Fri, 27 Apr 2001 11:38:55 -0500 (CDT)
Message-ID: <3AE99238.59184CCB@usa.alcatel.com>
Date: Fri, 27 Apr 2001 11:37:29 -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 Process thoughts...
References: <7B5C0390ACE7D211BC9C0008C7EABA2B03213908@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

Hi Raj,
  Thanks for the clarifications. HMIP is there because there is a need for it.
The requirements were drafted not because some people wanted to have yet
another RFC with their name stuck. RFC writing is not the same as conference/
journal paper writing. If IETF can not come up with the needed RFCs, the
industry will eventually end up developing them somehow.
  Having said that however, the problem that gave rise to the recent noise is :

when Phil R. came up with the initial requirements, nobody asked where we are
heading. People jumped on it including the authors of HMIP.
  The lesson is that the rules of the game should be made clear at the outset.
Basavaraj.Patil@nokia.com wrote:


> The only problem is that if we keep on doing this, we will
> probably
>     never converge on any solution as such and the implications of this are
>     no implementations/interworking and adoption by the industry.
>
> -Basavaraj

--
Behcet



From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 27 13:12: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 NAA08834
	for ; Fri, 27 Apr 2001 13:11:58 -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 KAA29249;
	Fri, 27 Apr 2001 10:11: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 KAA15065;
	Fri, 27 Apr 2001 10:10: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 f3RH9fIM024401
	for ; Fri, 27 Apr 2001 10:09:42 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3RH9f6j024400
	for mobile-ip-dist; Fri, 27 Apr 2001 10:09: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 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 f3RH9XIM024393
	for ; Fri, 27 Apr 2001 10:09: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 KAA16098
	for ; Fri, 27 Apr 2001 10:09:33 -0700 (PDT)
Message-Id: <200104271709.KAA16098@heliopolis.eng.sun.com>
Date: Fri, 27 Apr 2001 10:09:33 -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: JR1ChsiKiabFmZ1hhZJEyQ==
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: 

Sami,

>
>When analysing the non-hierarchical case, you are summing all the
>delays to calculate the latency.  Wouldn't the binding updates
>(or registration requests) be sent in parallel to both HA, and all
>CNs?  Thus the latency would be a maximum of a set of numbers, not
>a sum ?
>

You're right, but the same can be said of the hierarchical case.
LMM(i) sends the BU to LMM-T independently of replying to MN,
so MN doesn't necessarily have to wait.

Also, I think MN would at least have to wait for the BU-ack to the HA 
before proceeding with sending the BU to the CN. So these would
be sequential.

In any case, I think this is a worst case analysis, there is potential
for optimization that could probably be developed. I basically
worked it out yesterday afternoon in a half hour, a little more time
with a white board could probably sharpen it up. If there is any
interest in the working group, I'm up for continuing, though I 
don't know how far one could get without having to resort to
simulation.

Thanx for your reply. It's such a relief to be able to do some
technical discussion around this issue.

		jak



From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 27 13:45:09 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 NAA09609
	for ; Fri, 27 Apr 2001 13:45:09 -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 KAA15149;
	Fri, 27 Apr 2001 10:44: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 KAA09540;
	Fri, 27 Apr 2001 10:44: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 f3RHgjIM024476
	for ; Fri, 27 Apr 2001 10:42:45 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3RHgir4024475
	for mobile-ip-dist; Fri, 27 Apr 2001 10:42: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 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 f3RHgdIM024468
	for ; Fri, 27 Apr 2001 10:42:40 -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 NAA18736
	for ; Fri, 27 Apr 2001 13:42:39 -0400 (EDT)
Received: (from glass@localhost)
	by onion.east.sun.com (8.9.3+Sun/8.9.3) id NAA29602
	for mobile-ip@sunroof.eng.sun.com; Fri, 27 Apr 2001 13:42:53 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QMQYK9020918
	for ; Thu, 26 Apr 2001 15:26: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 PAA12275
	for ; Thu, 26 Apr 2001 15:26:31 -0700 (PDT)
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA01159
	for ; Thu, 26 Apr 2001 15:26:30 -0700 (PDT)
Received: (qmail 2406 invoked by uid 500); 26 Apr 2001 22:16:41 -0000
Date: Thu, 26 Apr 2001 15:16:41 -0700
From: Pat Calhoun 
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Protocol Decision Fixed?
Message-ID: <20010426151641.D591@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: 

> I would be more than glad to participate in the editing of such draft.
> 
> Please consider me in if such request is in effect by the WG chair hats...

I am not sure whether the hats themselves have to power needed to cause
such a draft to be created, but at least the people wearing them should
consider this very seriously.

PatC

PS: Note a change in contact info.


From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 27 14:51:52 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11046
	for ; Fri, 27 Apr 2001 14:51:51 -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 LAA04753;
	Fri, 27 Apr 2001 11:51:40 -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 LAA28751;
	Fri, 27 Apr 2001 11:51: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 f3RInuIM024659
	for ; Fri, 27 Apr 2001 11:49:56 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3RInura024658
	for mobile-ip-dist; Fri, 27 Apr 2001 11:49: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 eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241])
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3RInpIM024651
	for ; Fri, 27 Apr 2001 11:49:51 -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 OAA04368
	for ; Fri, 27 Apr 2001 14:49:50 -0400 (EDT)
Received: (from glass@localhost)
	by onion.east.sun.com (8.9.3+Sun/8.9.3) id OAA00851
	for mobile-ip@sunroof.eng.sun.com; Fri, 27 Apr 2001 14:50:03 -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 f3RIifIM024632
	for ; Fri, 27 Apr 2001 11:44:42 -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 LAA26779
	for ; Fri, 27 Apr 2001 11:44:37 -0700 (PDT)
Received: from prue.eim.surrey.ac.uk (prue.eim.surrey.ac.uk [131.227.76.5])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA01695
	for ; Fri, 27 Apr 2001 11:44:35 -0700 (PDT)
Received: from carter-e0.ee.surrey.ac.uk ([131.227.86.16])
	by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1)
	id 14tDEG-0003oX-00
	for mobile-ip@sunroof.eng.sun.com; Fri, 27 Apr 2001 19:44:32 +0100
Date: Fri, 27 Apr 2001 19:44:31 +0100 (BST)
From: Karann Chew 
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: <00c401c0cebe$21907fc0$6401a8c0@philneum>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanner: exiscan *14tDEG-0003oX-00*KacUoD5HwLY* 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: 

Could somebody please give me a pointer to the file/draft which describes
these "L ocalized Mobility Management Requirement s"?

Many thanks.

	Karann

++++++++++++++++++++++++++++++++++++++++++
Karann Chew   
Mobile Communications Research Group
Centre for Communication Systems Research
University of Surrey
Guildford
Surrey GU2 7XH
United Kingdom
Tel: +44 (0) 1483-879488
Fax: +44 (0) 1483-876011
++++++++++++++++++++++++++++++++++++++++++


On Thu, 26 Apr 2001, Phil Neumiller wrote:

> Arthur,
> 
> Please take a look at the OBAST paper at http://federalmobility.com/.  I think this
> will explain how to do this with CDMA macro-diversity selection.  The paper
> describes a way to put macro-diversity into a BTS thus allowing BTSs, SDUs,
> and RNCs to all be co-located at the edge of the network and function peer-to
> peer.  What I have been describing in digestable chunks to the MIP list is
> essentially OBAST.  Others have called it MIPv6, some have called it
> MIPv4 fast handoff, but none of those address the CDMA issues (and therefore
> 3G issues) that you have brought up, except for OBAST.
> 
> Thanks,
> 
> Phil
> 
> ----- Original Message -----
> From: "Arthur Ross" 
> To: 
> 
> 
> > The attachment points may be multiple and simultaneous, with time-varying
> > performance that will exhibit high raw error rates. From a comm-theoretic
> > standpoint, you will almost always do better in bad link conditions if the
> > network can use whatever transceiver resources are available, i.e. listen
> > from multiple transceivers & diversity combine them in the network;
> > transmit from multiple transceivers & diversity combine them in the MN.
> > This is what "soft handoff" in the CDMA air interfaces is all about.
> >
> > This leads to the need to distinguish between the addresses of the access
> > transceivers (which may or may not be one-to-one with access routers), and
> > physical radio comm link addresses (spreading code, or whatever). The
> > physical addresses may be MN-permanent, BTS-permanent, dynamically
> > assigned, or something as yet to be defined. That is a question in itself.
> > >
> 
> 
> 


From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 27 14:59:48 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 OAA11237
	for ; Fri, 27 Apr 2001 14:59: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 LAA23829;
	Fri, 27 Apr 2001 11:59:40 -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 LAA01260;
	Fri, 27 Apr 2001 11:59: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 f3RIw8IM024676
	for ; Fri, 27 Apr 2001 11:58:08 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3RIw8lG024675
	for mobile-ip-dist; Fri, 27 Apr 2001 11:58: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 f3RIvvIM024668
	for ; Fri, 27 Apr 2001 11:57:59 -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 LAA10938
	for ; Fri, 27 Apr 2001 11:57:53 -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 LAA08398
	for ; Fri, 27 Apr 2001 11:57:52 -0700 (PDT)
Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 27 Apr 2001 14:51:51 -0400
Message-ID: 
From: Phil Roberts 
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)
Date: Fri, 27 Apr 2001 14:51:50 -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 collecting them on the mailist list so far.  Here's a copy:

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.)
2. LMM shall be secure from malicious behavior.
3. Connectivity to the mobiles should be minimized (MUST) or eliminated
(strive for this) in the presence of failure of LMM agents.
(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.)
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)
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))
8. LMM shall not require changes to the HA and the CNs.
9. LMM should provide the same level of mobility management support as in
the basic MIPv6 spec.
10. LMM should support autoconfig.

Unless there is some strong objection to these they will be requirements.
We may or may not add one on multiple levels of hierarchy depending on the
other discussion.

Phil

> -----Original Message-----
> From: Karann Chew [mailto:k.chew@eim.surrey.ac.uk]
> Sent: Friday, April 27, 2001 2:45 PM
> 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)
> 
> 
> Could somebody please give me a pointer to the file/draft 
> which describes
> these "L ocalized Mobility Management Requirement s"?
> 
> Many thanks.
> 
> 	Karann
> 
> ++++++++++++++++++++++++++++++++++++++++++
> Karann Chew   
> Mobile Communications Research Group
> Centre for Communication Systems Research
> University of Surrey
> Guildford
> Surrey GU2 7XH
> United Kingdom
> Tel: +44 (0) 1483-879488
> Fax: +44 (0) 1483-876011
> ++++++++++++++++++++++++++++++++++++++++++
> 
> 
> On Thu, 26 Apr 2001, Phil Neumiller wrote:
> 
> > Arthur,
> > 
> > Please take a look at the OBAST paper at 
http://federalmobility.com/.  I think this
> will explain how to do this with CDMA macro-diversity selection.  The
paper
> describes a way to put macro-diversity into a BTS thus allowing BTSs,
SDUs,
> and RNCs to all be co-located at the edge of the network and function
peer-to
> peer.  What I have been describing in digestable chunks to the MIP list is
> essentially OBAST.  Others have called it MIPv6, some have called it
> MIPv4 fast handoff, but none of those address the CDMA issues (and
therefore
> 3G issues) that you have brought up, except for OBAST.
> 
> Thanks,
> 
> Phil
> 
> ----- Original Message -----
> From: "Arthur Ross" 
> To: 
> 
> 
> > The attachment points may be multiple and simultaneous, with
time-varying
> > performance that will exhibit high raw error rates. From a
comm-theoretic
> > standpoint, you will almost always do better in bad link conditions if
the
> > network can use whatever transceiver resources are available, i.e.
listen
> > from multiple transceivers & diversity combine them in the network;
> > transmit from multiple transceivers & diversity combine them in the MN.
> > This is what "soft handoff" in the CDMA air interfaces is all about.
> >
> > This leads to the need to distinguish between the addresses of the
access
> > transceivers (which may or may not be one-to-one with access routers),
and
> > physical radio comm link addresses (spreading code, or whatever). The
> > physical addresses may be MN-permanent, BTS-permanent, dynamically
> > assigned, or something as yet to be defined. That is a question in
itself.
> > >
> 
> 
> 


From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 27 15:41: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 PAA12911
	for ; Fri, 27 Apr 2001 15:41:54 -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 MAA10591;
	Fri, 27 Apr 2001 12:41:40 -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 MAA18096;
	Fri, 27 Apr 2001 12:41: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 f3RJcYIM024715
	for ; Fri, 27 Apr 2001 12:38:34 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3RJcYcf024714
	for mobile-ip-dist; Fri, 27 Apr 2001 12:38:34 -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 f3RJcKIM024707
	for ; Fri, 27 Apr 2001 12:38:21 -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 MAA18614
	for ; Fri, 27 Apr 2001 12:38:19 -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 MAA06939
	for ; Fri, 27 Apr 2001 12:38:18 -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 OAA10611
	for ; Fri, 27 Apr 2001 14:38:42 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Fri, 27 Apr 2001 14:38:16 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Fri, 27 Apr 2001 14:38:01 -0500
Message-ID: <85AA7486A2C1D411BCA20000F8073E4302072931@crchy271.us.nortel.com>
From: "Glenn Morrow" 
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Final(?) Cut on LMM Requirements
Date: Fri, 27 Apr 2001 14:37:50 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0CF51.8BACC470"
Sender: owner-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_01C0CF51.8BACC470
Content-Type: text/plain;
	charset="iso-8859-1"

I'm not sure if fast handoff has delved into all of the requirements from an
inter-system perspective.

-----Original Message-----
From: Phil Roberts [mailto:PRoberts@MEGISTO.com]
Sent: Thursday, April 26, 2001 9:36 AM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: [mobile-ip] Final(?) Cut on LMM Requirements


 


4. LMM shall be compatible with fast handoffs. 
[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?

	- Muhammad Jaseemuddin 
[Phil Roberts] 

	I didn't see any response to your post.  Personally speaking I
really don't want these two proposals coupled in any way.  It makes sense to
make sure they are compatible (you can use them at the same time) but it
does not make sense that they should have dependencies on each other.  It
seems reasonable to me that some networks with fast handover enabled will
see little if any need for LMM support. 


------_=_NextPart_001_01C0CF51.8BACC470
Content-Type: text/html;
	charset="iso-8859-1"




RE: [mobile-ip] Final(?) Cut on LMM Requirements




I'm 
not sure if fast handoff has delved into all of the requirements from an 
inter-system perspective.



  
-----Original Message-----
From: Phil Roberts 
  [mailto:PRoberts@MEGISTO.com]
Sent: Thursday, April 26, 2001 9:36 
  AM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: 
  [mobile-ip] Final(?) Cut on LMM Requirements


  
 

  

    

4. LMM shall be compatible with 
    fast handoffs. 
[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?

    
    
      
    - Muhammad 
      Jaseemuddin 
    [Phil Roberts] 
    
      
    I 
      didn't see any response to your post.  Personally speaking I really 
      don't want these two proposals coupled in any way.  It makes 
      sense to make sure they are compatible (you can use them at the same time) 
      but it does not make sense that they should have dependencies on each 
      other.  It seems reasonable to me that some networks 
      with fast handover enabled will see little if any need for LMM 
      support. 


------_=_NextPart_001_01C0CF51.8BACC470--


From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 27 15:54: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 PAA13818
	for ; Fri, 27 Apr 2001 15:54: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 MAA15463;
	Fri, 27 Apr 2001 12:54: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 MAA03899;
	Fri, 27 Apr 2001 12:53: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 f3RJpIIM024734
	for ; Fri, 27 Apr 2001 12:51:18 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3RJpIFT024733
	for mobile-ip-dist; Fri, 27 Apr 2001 12:51:18 -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 f3RJp8IM024726
	for ; Fri, 27 Apr 2001 12:51:09 -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 MAA19686
	for ; Fri, 27 Apr 2001 12:51: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 NAA05095
	for ; Fri, 27 Apr 2001 13:57:04 -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 OAA13950
	for ; Fri, 27 Apr 2001 14:51:32 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Fri, 27 Apr 2001 14:45:31 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Fri, 27 Apr 2001 14:50:53 -0500
Message-ID: <85AA7486A2C1D411BCA20000F8073E4302072963@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: Fri, 27 Apr 2001 14:50:47 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0CF53.5AB0DF30"
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_01C0CF53.5AB0DF30
Content-Type: text/plain;
	charset="iso-8859-1"

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_01C0CF53.5AB0DF30
Content-Type: text/html;
	charset="iso-8859-1"




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_01C0CF53.5AB0DF30--


From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 27 16:04:24 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14463
	for ; Fri, 27 Apr 2001 16:04:23 -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 NAA25265;
	Fri, 27 Apr 2001 13:04: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 NAA22955;
	Fri, 27 Apr 2001 13:04: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 f3RK2BIM024786
	for ; Fri, 27 Apr 2001 13:02:11 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3RK27Rg024785
	for mobile-ip-dist; Fri, 27 Apr 2001 13:02: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 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 f3RK1uIM024778
	for ; Fri, 27 Apr 2001 13:01:58 -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 NAA14709
	for ; Fri, 27 Apr 2001 13:01:48 -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 NAA23496
	for ; Fri, 27 Apr 2001 13:01:47 -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 PAA16685
	for ; Fri, 27 Apr 2001 15:02:15 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Fri, 27 Apr 2001 14:56:17 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Fri, 27 Apr 2001 15:01:40 -0500
Message-ID: <85AA7486A2C1D411BCA20000F8073E430207298C@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 L 
         ocalized Mobility Management Requirement s)
Date: Fri, 27 Apr 2001 15:01:18 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0CF54.D2D300A0"
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_01C0CF54.D2D300A0
Content-Type: text/plain;
	charset="iso-8859-1"

Theo,

Some excellent insights. Actually with IPv6, people might find that
subnetting site locals would afford a natural method of developing such a
topological routing that could be disjunct from the global subnetting.

-----Original Message-----
From: Theo Pagtzis [mailto:tpagtzis@iprg.nokia.com]
Sent: Thursday, April 26, 2001 10:50 AM
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)


Hi again Erik,


Erik Nordmark wrote:

> Theo,
>
> > I must say that this is far from truth... by the moment you have the
notion
> > of "next possible candates" you have already established a hierarchy
> > structure of "previous -> next"
>
> Now I'm really confused.
> I've been assuming that the hierarchy that we've been discussing is
> common for a number of MNs (perhaps all) in some particular part of
> the network.
>
> But your previous->next relationship is a function of the individual
movement
> patterns of a particular MN thus it might be different for all MNs (at
least
> if you track enough of their history using a chain of prev->next
> relationships).
>
> That sounds like the "update the previous FA" scheme in MIPv4 which
> doesn't look like a (shared) hierarchy at all.
>
>    Erik

Ok,

   the hierarchy implied by the "previous->next" relationship can either be
generic...ie all mobile nodes that are participating in a admin domain ...or
it
can be specific that is per MN by refering specifically to generic
relationship.
It is only the per-MN behaviour that is instantiated on the second.

In your understanding (above) you happen to see the second. The first though
is
ALREADY there.

In the first you refer to a packet that goes from the previous LMM-aware
routing
element to the next..

In the second you refer to a packet for a _particular_ MN that goes for the
last
hop previous LMM-aware routing element to the next..

So you have correctly assumed a common hierarchy for all MNs here..you just
pick
a snapshot for the individual MN...

It is like the analogy...I can see the map of the roads...but at the same
time I
can see my route on that map.


Multicast has said it in a different ..perhaps clearer way...incoming and
outgoing interfaces...but it is the same thing...stil hierarchy..

I only wanted to show that the building blocks for a hierarchy are in
principle
there...it is just a matter of tying them together...in an admin domain

So I am definetely refering to a shared hierarchy...one which an LMM scheme
could instantiate differently than another depending on how it wants to see
it...


Theo


UCL/ Mobile Systems


------_=_NextPart_001_01C0CF54.D2D300A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised =
L  ocalized Mobility Management Requirement s)




Theo,




Some excellent insights. Actually with IPv6, people =
might find that subnetting site locals would afford a natural method of =
developing such a topological routing that could be disjunct from the =
global subnetting.



-----Original Message-----

From: Theo Pagtzis [mailto:tpagtzis@iprg.nokia.com]

Sent: Thursday, April 26, 2001 10:50 AM

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)






Hi again Erik,






Erik Nordmark wrote:




> Theo,

>

> > I must say that this is far from truth... =
by the moment you have the notion

> > of "next possible candates" you =
have already established a hierarchy

> > structure of "previous -> =
next"

>

> Now I'm really confused.

> I've been assuming that the hierarchy that =
we've been discussing is

> common for a number of MNs (perhaps all) in =
some particular part of

> the network.

>

> But your previous->next relationship is a =
function of the individual movement

> patterns of a particular MN thus it might be =
different for all MNs (at least

> if you track enough of their history using a =
chain of prev->next

> relationships).

>

> That sounds like the "update the previous =
FA" scheme in MIPv4 which

> doesn't look like a (shared) hierarchy at =
all.

>

>    Erik




Ok,




   the hierarchy implied by the =
"previous->next" relationship can either be

generic...ie all mobile nodes that are participating =
in a admin domain ...or it

can be specific that is per MN by refering =
specifically to generic relationship.

It is only the per-MN behaviour that is instantiated =
on the second.




In your understanding (above) you happen to see the =
second. The first though is

ALREADY there.




In the first you refer to a packet that goes from the =
previous LMM-aware routing

element to the next..




In the second you refer to a packet for a =
_particular_ MN that goes for the last

hop previous LMM-aware routing element to the =
next..




So you have correctly assumed a common hierarchy for =
all MNs here..you just pick

a snapshot for the individual MN...




It is like the analogy...I can see the map of the =
roads...but at the same time I

can see my route on that map.






Multicast has said it in a different ..perhaps =
clearer way...incoming and

outgoing interfaces...but it is the same =
thing...stil hierarchy..




I only wanted to show that the building blocks for a =
hierarchy are in principle

there...it is just a matter of tying them =
together...in an admin domain




So I am definetely refering to a shared =
hierarchy...one which an LMM scheme

could instantiate differently than another depending =
on how it wants to see

it...






Theo






UCL/ Mobile Systems





------_=_NextPart_001_01C0CF54.D2D300A0--


From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 27 16:06: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 QAA14520
	for ; Fri, 27 Apr 2001 16:06:18 -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 NAA20655;
	Fri, 27 Apr 2001 13:06:13 -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 NAA23778;
	Fri, 27 Apr 2001 13:06: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 f3RK4hIM024812
	for ; Fri, 27 Apr 2001 13:04:43 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3RK4hQK024811
	for mobile-ip-dist; Fri, 27 Apr 2001 13:04:43 -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 f3RK4UIM024804
	for ; Fri, 27 Apr 2001 13:04: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 NAA15208
	for ; Fri, 27 Apr 2001 13:04:30 -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 NAA04870
	for ; Fri, 27 Apr 2001 13:04:29 -0700 (PDT)
Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 27 Apr 2001 15:58:28 -0400
Message-ID: 
From: Phil Roberts 
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: Fri, 27 Apr 2001 15:58:28 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0CF54.6D8926A2"
Sender: owner-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_01C0CF54.6D8926A2
Content-Type: text/plain;
	charset="iso-8859-1"

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_01C0CF54.6D8926A2
Content-Type: text/html;
	charset="iso-8859-1"




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_01C0CF54.6D8926A2--


From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 27 18:59:33 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18677
	for ; Fri, 27 Apr 2001 18:59: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 PAA22701;
	Fri, 27 Apr 2001 15:59: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 PAA16108;
	Fri, 27 Apr 2001 15:58:58 -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 f3RMvEIM024958
	for ; Fri, 27 Apr 2001 15:57:14 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3RMvEIv024957
	for mobile-ip-dist; Fri, 27 Apr 2001 15:57: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 f3RMv3IM024950
	for ; Fri, 27 Apr 2001 15:57:05 -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 PAA29413
	for ; Fri, 27 Apr 2001 15:56:59 -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 PAA17335
	for ; Fri, 27 Apr 2001 15:56:58 -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 f3RMuvO13014
	for ; Sat, 28 Apr 2001 00:56:57 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Sat Apr 28 00:56:56 2001 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Sat, 28 Apr 2001 00:52:14 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBDCD@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Protocol Decision Fixed?
Date: Sat, 28 Apr 2001 00:56:56 +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 Jim
> >
> > > I don't agree with Karim that one LMM per cloud is all that
> > > will ever be
> > > needed simply because the cloud will be too large in some
> > > cases as a metro
> > > network (e.g. LA, Boston, London, Tokyo, Paris).
> >
> > My point was the other way round. I don't think that LMM
> > clouds/domains will be so small so that you continuously have
> > to change LMMs when you move.
> 
> Well, you will be changing access routers almost every time
> and definitely when you cross AD boundaries right?
> 
	=> Changnig ARs does not necessarily mean changing 
	AD (I assume you mean Admin Domains). I'm not 
	sure why you assume this relationship.

	Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 27 19:07: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 TAA18853
	for ; Fri, 27 Apr 2001 19:07: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 QAA27759;
	Fri, 27 Apr 2001 16:07: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 QAA27198;
	Fri, 27 Apr 2001 16:07: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 f3RN5tIM024992
	for ; Fri, 27 Apr 2001 16:05:55 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3RN5tAT024991
	for mobile-ip-dist; Fri, 27 Apr 2001 16:05:55 -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 f3RN5iIM024984
	for ; Fri, 27 Apr 2001 16:05:46 -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 QAA26804
	for ; Fri, 27 Apr 2001 16:05:45 -0700 (PDT)
Received: from c007.snv.cp.net (c007-h013.c007.snv.cp.net [209.228.33.220])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id QAA09896
	for ; Fri, 27 Apr 2001 16:05:44 -0700 (PDT)
Received: (cpmta 12143 invoked from network); 27 Apr 2001 16:05:43 -0700
Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129)
  by smtp.telocity.com (209.228.33.220) with SMTP; 27 Apr 2001 16:05:43 -0700
X-Sent: 27 Apr 2001 23:05:43 GMT
Message-ID: <008f01c0cf6e$6aac41c0$6401a8c0@philneum>
From: "Phil Neumiller" 
To: 
References: <034BEFD03799D411A59F00508BDF7546013DBDCD@esealnt448.al.sw.ericsson.se>
Subject: Re: [mobile-ip] Protocol Decision Fixed?
Date: Fri, 27 Apr 2001 18:04:24 -0500
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: 

English a wonderful "scientific" language.  See new language below.

----- Original Message -----
From: "Hesham Soliman (ERA)" 

I wrote:
> > Well, you will be changing access routers almost every time
> > and definitely when you cross AD boundaries right?
> >
> => Changnig ARs does not necessarily mean changing
> AD (I assume you mean Admin Domains). I'm not
> sure why you assume this relationship.
>
> Hesham
>

Assumptions:
1).  AR changes will be frequent.  In many designs it is desirable to
       make every BTS or AP an AR.
2). When you cross AD boundaries you are "probably" crossing
      AR boundaries too.
3).  Verticle handovers will become much more prevelant thus
       crossing AD boundaries will be much more prevelant, eg.
       Bluetooth to CDMA, etc.





From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 27 19:17:54 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19666
	for ; Fri, 27 Apr 2001 19:17: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 QAA03750;
	Fri, 27 Apr 2001 16:17:37 -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 QAA09960;
	Fri, 27 Apr 2001 16:17: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 f3RNG8IM025032
	for ; Fri, 27 Apr 2001 16:16:08 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3RNG7R7025031
	for mobile-ip-dist; Fri, 27 Apr 2001 16:16: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 f3RNFuIM025024
	for ; Fri, 27 Apr 2001 16:15: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 QAA03464
	for ; Fri, 27 Apr 2001 16:15:42 -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 QAA02388
	for ; Fri, 27 Apr 2001 16:15:40 -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 f3RNFeN27732
	for ; Sat, 28 Apr 2001 01:15:40 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Sat Apr 28 01:15:39 2001 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Sat, 28 Apr 2001 01:10:57 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBDCE@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Protocol Decision Fixed?
Date: Sat, 28 Apr 2001 01:15: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: 

> >"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.
> 
	=> There were FOUR proposals on LMM last summer. I think 
	this constitutes interest. Perhaps you had more urgent 
	work to do back then, but that doesn't mean "people"
	were not interested. They definitely were.

> 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. 
> 
	=> As a co-author of that draft and someone who worked on MIPv6
	for a couple of years I think this statement is incorrect.
	Even the requirement that we're discussing now
	(multi-level hierarchy) is already met by the current proposal
	and can be furher optimised. The point we're
	discussing is "why" ?
	I believe all the other equirements are also already
	met or can be quite easily. Perhaps you could 
	specify which ones aren't and whether you 
	have another proposal that meets those.


> 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.
> 
	=> This is sort of the point of having a WG draft 
	isn't it ? A WG _draft_ is owned by the 
	entie WG and the entire_WG_ can propose 
	changes. Which is unfortunately not what I'm
	seeing here !
	I find it hard to believe that there is a fundamental
	design problem in the current proposal that would 
	stop it from improving. This is due to the 
	fact that the changes from MIPv6 are extremely 
	minor (1 flag).


	Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 27 19:33:54 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 TAA19869
	for ; Fri, 27 Apr 2001 19:33:53 -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 QAA06965;
	Fri, 27 Apr 2001 16:33:39 -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 QAA24435;
	Fri, 27 Apr 2001 16:33: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 f3RNVHIM025101
	for ; Fri, 27 Apr 2001 16:31:17 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3RNVGKA025100
	for mobile-ip-dist; Fri, 27 Apr 2001 16:31: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 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 f3RNV6IM025093
	for ; Fri, 27 Apr 2001 16:31:07 -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 QAA07322
	for ; Fri, 27 Apr 2001 16:31:06 -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 RAA15470
	for ; Fri, 27 Apr 2001 17:37:21 -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 f3RNV3N28591
	for ; Sat, 28 Apr 2001 01:31:03 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Sat Apr 28 01:31:02 2001 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Sat, 28 Apr 2001 01:26:20 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBDD0@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Protocol Decision Fixed?
Date: Sat, 28 Apr 2001 01:31:01 +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 din't see Karim's reply to you earlier 
	which said the same thing, so sorry for 
	repeatin what he'd already said. 

> Assumptions:
> 1).  AR changes will be frequent.  In many designs it is desirable to
>        make every BTS or AP an AR.
> 
	=> That's fine.

> 2). When you cross AD boundaries you are "probably" crossing
>       AR boundaries too.
> 
	=> Yes.

> 3).  Verticle handovers will become much more prevelant thus
>        crossing AD boundaries will be much more prevelant, eg.
>        Bluetooth to CDMA, etc.
> 
	=> No, this is a crossing between two access technologies,
	an AD may contain more than one access technology.
	There is no need to say that one access technology =
	AD. In fact one AR may have more than one access 
	technology attached to it. 

	Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 27 20:06:34 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20339
	for ; Fri, 27 Apr 2001 20:06: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 RAA27854;
	Fri, 27 Apr 2001 17:06: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 RAA13449;
	Fri, 27 Apr 2001 17:06: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 f3S04jIM025201
	for ; Fri, 27 Apr 2001 17:04:45 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3S04jMM025200
	for mobile-ip-dist; Fri, 27 Apr 2001 17:04: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 f3S04YIM025193
	for ; Fri, 27 Apr 2001 17:04: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 RAA00798
	for ; Fri, 27 Apr 2001 17:04:34 -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 RAA12563
	for ; Fri, 27 Apr 2001 17:04:33 -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 f3S04WN00746
	for ; Sat, 28 Apr 2001 02:04:32 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Sat Apr 28 02:04:31 2001 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Sat, 28 Apr 2001 01:59:49 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBDD3@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Some Analysis
Date: Sat, 28 Apr 2001 02:04:30 +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, 

	Please see my comments below.

> > Numbers!!!
> >
> 
> After having unjustly flamed Erik this morning and being inspired by
> his challenge, I went through an analysis comparing signalling
> overhead on hierarchical v.s. nonhierarchical designs. The attached
> zipped PDF (sorry for the zip, I couldn't get a unzipped through the list size 
> filter) and text explain.
> 
	=. No probs. As a side not, I believe Erik said "Numbers". 
	This is a nice detailed analysis, but it's missing "Numbers". 
	I do agree that updating a node 2 hops away is faster
	than updating a node 3 hops away. That's just common
	sense. However, the point is: is there any _significant_
	improvement ? I don't think so.
	Why ? because the numbers for delays over the air interface
	are so much higher than forwarding on the wire, 
	which makes forwarding delays on the wire (within a local 
	domain) insignificant. 

	I hope you can see that I didn't say "it will never happen".
	I said that there is no significant improvement .
	To use Eriks's words from an earlier mail, we need to
	see an order of magntude reduction in delays for any of 
	this to be significant. 

> Note to H&K: Arguments about the analysis are welcome, but please
> don't post "this won't happen in practice" arguments. You may have
> your opinion and I may have mine. The math speaks for itself.
> 
	=> I guess I'm "H", your math is fine, but this academic 
	argument needs to be placed in the right context. 
	I'm sure you're already aware of these delays I'm referring
	to, since you're heavily involved in MWIF. 

	Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 27 20:32:41 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20696
	for ; Fri, 27 Apr 2001 20:32:40 -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 RAA08479;
	Fri, 27 Apr 2001 17:32: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 RAA05324;
	Fri, 27 Apr 2001 17:32:17 -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 f3S0TxIM025235
	for ; Fri, 27 Apr 2001 17:29:59 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3S0Tx0u025234
	for mobile-ip-dist; Fri, 27 Apr 2001 17:29: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 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 f3S0TmIM025227
	for ; Fri, 27 Apr 2001 17:29: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 RAA13141
	for ; Fri, 27 Apr 2001 17:29:48 -0700 (PDT)
Received: from c007.snv.cp.net (c007-h000.c007.snv.cp.net [209.228.33.206])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id SAA07963
	for ; Fri, 27 Apr 2001 18:36:05 -0600 (MDT)
Received: (cpmta 7470 invoked from network); 27 Apr 2001 17:29:46 -0700
Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129)
  by smtp.telocity.com (209.228.33.206) with SMTP; 27 Apr 2001 17:29:46 -0700
X-Sent: 28 Apr 2001 00:29:46 GMT
Message-ID: <00a401c0cf7a$27a41b80$6401a8c0@philneum>
From: "Phil Neumiller" 
To: 
References: <034BEFD03799D411A59F00508BDF7546013DBDD3@esealnt448.al.sw.ericsson.se>
Subject: Re: [mobile-ip] Some Analysis
Date: Fri, 27 Apr 2001 19:28:25 -0500
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: 

Numbers?
----- Original Message -----
From: "Hesham Soliman (ERA)" 
To: 
Sent: Friday, April 27, 2001 7:04 PM
Subject: RE: [mobile-ip] Some Analysis


> James,
>
> Please see my comments below.
>
> > > Numbers!!!
> > >
> >
> > After having unjustly flamed Erik this morning and being inspired by
> > his challenge, I went through an analysis comparing signalling
> > overhead on hierarchical v.s. nonhierarchical designs. The attached
> > zipped PDF (sorry for the zip, I couldn't get a unzipped through the list size
> > filter) and text explain.
> >
> =. No probs. As a side not, I believe Erik said "Numbers".
> This is a nice detailed analysis, but it's missing "Numbers".
> I do agree that updating a node 2 hops away is faster
> than updating a node 3 hops away. That's just common
> sense. However, the point is: is there any _significant_
> improvement ? I don't think so.
> Why ? because the numbers for delays over the air interface
> are so much higher than forwarding on the wire,
> which makes forwarding delays on the wire (within a local
> domain) insignificant.

Please quantify your response.  You are complaining about the lack
of numbers yet provide none.  At least we have a delay model with
what James has provided.

>
> I hope you can see that I didn't say "it will never happen".
> I said that there is no significant improvement .

What is the quantitative or qualitative basis for the significant
improvement you seek?





From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 27 20:41:54 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 UAA20812
	for ; Fri, 27 Apr 2001 20:41:53 -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 RAA21809;
	Fri, 27 Apr 2001 17:41:47 -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 RAA24631;
	Fri, 27 Apr 2001 17:41: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 f3S0eSIM025281
	for ; Fri, 27 Apr 2001 17:40:29 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3S0eSMG025280
	for mobile-ip-dist; Fri, 27 Apr 2001 17:40: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 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 f3S0eHIM025273
	for ; Fri, 27 Apr 2001 17:40:19 -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 RAA14831
	for ; Fri, 27 Apr 2001 17:40:18 -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 RAA16298
	for ; Fri, 27 Apr 2001 17:40:16 -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 f3S0eEO20767
	for ; Sat, 28 Apr 2001 02:40:14 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Sat Apr 28 02:40:13 2001 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Sat, 28 Apr 2001 02:35:31 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBDD5@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Some Analysis
Date: Sat, 28 Apr 2001 02:40:13 +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: 

	Phil N, 

> Please quantify your response.  You are complaining about the lack
> of numbers yet provide none. 
> 
	=> Well maybe there are too many mails to read on 
	this list, but I have already done that. 
	The typical figures that I know of (you can easily 
	check that) for forwarding delays in some 
	major routers are roughly 1-2 ms (I'm being concservative,
	some routers can do much better). 
	Delays over the air in CDMA (eg. WCDMA )
	are 60 - 80 ms (80 being the worste case scenario) 

>  At least we have a delay model with
> what James has provided.
> 
	=> I know, I did also agree with that.

	Hesham



From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 27 20:43: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 UAA20841
	for ; Fri, 27 Apr 2001 20:43:19 -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 RAA22128;
	Fri, 27 Apr 2001 17:43: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 RAA15121;
	Fri, 27 Apr 2001 17:43: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 f3S0g1IM025291
	for ; Fri, 27 Apr 2001 17:42:01 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3S0g0US025290
	for mobile-ip-dist; Fri, 27 Apr 2001 17:42: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 f3S0fiIM025283
	for ; Fri, 27 Apr 2001 17:41:46 -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 RAA14996
	for ; Fri, 27 Apr 2001 17:41:45 -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 RAA11804
	for ; Fri, 27 Apr 2001 17:41:44 -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 RAA00074
	for ; Fri, 27 Apr 2001 17:41:44 -0700 (PDT)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3S0ffq32237
	for ; Fri, 27 Apr 2001 17:41:41 -0700
X-mProtect:  Fri, 27 Apr 2001 17:41:41 -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(WTS.12.69) smtpdgBUvlC; Fri, 27 Apr 2001 17:41:35 PDT
Message-ID: <3AEA11C2.9A45EAF5@iprg.nokia.com>
Date: Fri, 27 Apr 2001 17:41:38 -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] Protocol Decision Fixed?
References: <034BEFD03799D411A59F00508BDF7546013DBDCD@esealnt448.al.sw.ericsson.se> <008f01c0cf6e$6aac41c0$6401a8c0@philneum>
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 Phil,


Phil Neumiller wrote:

> English a wonderful "scientific" language.  See new language below.
>
> ----- Original Message -----
> From: "Hesham Soliman (ERA)" 
>
> I wrote:
> > > Well, you will be changing access routers almost every time
> > > and definitely when you cross AD boundaries right?
> > >
> > => Changnig ARs does not necessarily mean changing
> > AD (I assume you mean Admin Domains). I'm not
> > sure why you assume this relationship.
> >
> > Hesham
> >
>
> Assumptions:
> 1).  AR changes will be frequent.  In many designs it is desirable to
>        make every BTS or AP an AR.

Correct.. we are hoping though that the root (or sole LMM) will not
change that often (hopefully if the LMM-aware overlay has been
positioned carefully by the head)

>
> 2). When you cross AD boundaries you are "probably" crossing
>       AR boundaries too.
>

true

> 3).  Verticle handovers will become much more prevelant thus
>        crossing AD boundaries will be much more prevelant, eg.
>        Bluetooth to CDMA, etc.

sure but vertical overlays cannot assume that are topologicaly
neighbouring so the handoff between their respective LMMs is bound to be
slow as the RTT between overlay LMM, I think, would be relatively long,
ie the edges of the domain need to exist in two
dimensions...horizontally and vertically if the handoff is expected to
be fast....and if that is the case then you have twice as many candidate
places for border routers and LMM agents...let see which one is
best......

Theo

UCL/ Mobile Systems




From owner-mobile-ip@sunroof.eng.sun.com  Sat Apr 28 00:14:45 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA25962
	for ; Sat, 28 Apr 2001 00:14:44 -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 VAA07607;
	Fri, 27 Apr 2001 21:14: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 VAA05209;
	Fri, 27 Apr 2001 21:14: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 f3S4CwIM025646
	for ; Fri, 27 Apr 2001 21:12:58 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3S4CvD4025643
	for mobile-ip-dist; Fri, 27 Apr 2001 21:12: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 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 f3S4CiIM025636
	for ; Fri, 27 Apr 2001 21:12:46 -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 VAA23147
	for ; Fri, 27 Apr 2001 21:12:44 -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 VAA08766
	for ; Fri, 27 Apr 2001 21:12:43 -0700 (PDT)
Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM)
	id AA15339; Sat, 28 Apr 2001 00:12:39 -0400
Date: Sat, 28 Apr 2001 00:12:39 -0400 (EDT)
From: Jim Bound 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Protocol Decision Fixed?
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: 

Hi Karim,

> > I don't agree with Karim that one LMM per cloud is all that 
> > will ever be
> > needed simply because the cloud will be too large in some 
> > cases as a metro
> > network (e.g. LA, Boston, London, Tokyo, Paris).
> 
> My point was the other way round. I don't think that LMM
> clouds/domains will be so small so that you continuously have
> to change LMMs when you move. I agree that you wouldn't want
> to have a LMM cover LA, Boston etc. On the other hand a LMM
> could cover LA or a parts of LA, which makes changing the LMM a
> rare event. I think it's been said previously that you can design
> the network appropriately for this.

How dispersed the LMMs are should be up to the providers and is really a
business decision in the market not a protocol decision.  At least I
believe the protocol or design should not force a specific business
decision.  I believe this can be architected and then engineered to
support multiple models and maintain interoperability.  Which should have
a strong weight as to which protocol is used to support the model we
define from this discussion thread for requirements.

I hate to state such a strong position at this point in the discussion but
when I agreed that the HA should be left untouched I was also saying that
having to send a HA an updated CoA is also not optimal and though
bicasting is used in the celluar world I do not believe it is required or
needed for MIPv6 model, architecture, or engineered solution (all three
are needed and I think we are still discussing the 'model' IMO).  In fact
to jump way down to a detail I believe the LMMs at the lowest level of
hierarchy can use IPv6 site-local addresses for LMM Area communications
and for signaling too.  Only when talking to the CN is a new
LMM-Specific-CoA required.

So taking my example the paging for the PDA in the bar for that LMM can
use site-local addressing with IPv6.  But the TCP/UDP/SCTP packet to enter
my chit to the wager CN would use the LMM global-LMM-CoA.

At this point I will also point to James's LMM Analysis and PDF file he
sent where I can't refute the math and took the time to check it once. So
the idea is that hierarchy will work and is more scalable I believe that
work proves.
 
> > Also think about this.  I leave my office and I am mobile with my PDA
> > gambling on the horses and keep doing it in my car.  While 
> > heading to the
> > bar I hit another access router and then in the bar I hit 
> > their wireline
> > 10MB xDSL access router and get a cheaper rate and jump off 
> > the metro cost
> > to the xDSL cheaper cost.  Still gambling in the bar on my 
> > PDA.  Then I
> > jump into a taxi to get home and hit the metro again.  Then I 
> > finally get
> > home watching the wagers on the last race in my house and now 
> > jump on that
> > Access Router at my home xDSL which is the cheapest rate for 
> > connectivity
> > via my access point in my house.  Win a million dollars and go to bed.
> > 
> > I would argue the above was all in the same cloud in metro LA and the
> > wager access was in the city seciton I work, party, and live 
> > in.  Its a
> > subset of the cloud.  And there were other subsets in the 
> > cloud (the car,
> > taxi, bar, home) which are LMMs.  
> 
> OK. But such a multi-access ISP (xDSL, wireless) could also achieve this
> by having one LMM (or a set of them for reliability and sharing of MN
> load) and ARs connected to the different access technologies through
> the city (i.e. what you called subsets in the cloud). You could still move,
> get the different rates and change technologies, but you wouldn't have
> to change LMM. Do you need to have/use a LMM in the bar and at home?

Of course this is possible and my LMM at the bar/taxi was extrapolation.
But I think the case I am presenting is stating there are multiple LMMs
and they may not always be linear (flat or all a the top) but distributed
as we are discussing, much like a binary tree.

As Butler Lampson often stated a long time ago.  Every problem in computer
science can be solved by another level of indirection.  I have been unable
to see that precept not valid as an architect or engineer writing code.

Why we would not use this principle for MIPv6 is beyond me still.
Maybe my day job has me distracted :-------)

regards,
/jim



From owner-mobile-ip@sunroof.eng.sun.com  Sat Apr 28 00:25:49 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA26381
	for ; Sat, 28 Apr 2001 00:25: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 VAA10310;
	Fri, 27 Apr 2001 21:25:41 -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 VAA01282;
	Fri, 27 Apr 2001 21:25: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 f3S4OCIM025666
	for ; Fri, 27 Apr 2001 21:24:13 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3S4OCHE025665
	for mobile-ip-dist; Fri, 27 Apr 2001 21:24: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 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 f3S4O1IM025658
	for ; Fri, 27 Apr 2001 21:24:03 -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 VAA05884
	for ; Fri, 27 Apr 2001 21:24:01 -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 VAA11014
	for ; Fri, 27 Apr 2001 21:24:00 -0700 (PDT)
Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM)
	id AA04804; Sat, 28 Apr 2001 00:23:59 -0400
Date: Sat, 28 Apr 2001 00:23:59 -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: <85AA7486A2C1D411BCA20000F8073E430207298C@crchy271.us.nortel.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: 

I agree.  It is definitely possible.  By definition all proposals have MTs
with global CoAs for communications out of the site.  So thats one battle
that won't rage.  I am not a fan of anything private but this is actually
a good use of site-local addresses besides RAN communications before IP as
we move to ALMOST-IP (I can't call the 3G logic model currently ALL-IP
anymore as it ain't true:----)).  I do await FULL-IP for 3G's though as
end user who likes to tcpdump all packets to see where they go :---)

/jim

On Fri, 27 Apr 2001, Glenn Morrow wrote:

> Theo,
> 
> Some excellent insights. Actually with IPv6, people might find that
> subnetting site locals would afford a natural method of developing such a
> topological routing that could be disjunct from the global subnetting.
> 
> -----Original Message-----
> From: Theo Pagtzis [mailto:tpagtzis@iprg.nokia.com]
> Sent: Thursday, April 26, 2001 10:50 AM
> 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)
> 
> 
> Hi again Erik,
> 
> 
> Erik Nordmark wrote:
> 
> > Theo,
> >
> > > I must say that this is far from truth... by the moment you have the
> notion
> > > of "next possible candates" you have already established a hierarchy
> > > structure of "previous -> next"
> >
> > Now I'm really confused.
> > I've been assuming that the hierarchy that we've been discussing is
> > common for a number of MNs (perhaps all) in some particular part of
> > the network.
> >
> > But your previous->next relationship is a function of the individual
> movement
> > patterns of a particular MN thus it might be different for all MNs (at
> least
> > if you track enough of their history using a chain of prev->next
> > relationships).
> >
> > That sounds like the "update the previous FA" scheme in MIPv4 which
> > doesn't look like a (shared) hierarchy at all.
> >
> >    Erik
> 
> Ok,
> 
>    the hierarchy implied by the "previous->next" relationship can either be
> generic...ie all mobile nodes that are participating in a admin domain ...or
> it
> can be specific that is per MN by refering specifically to generic
> relationship.
> It is only the per-MN behaviour that is instantiated on the second.
> 
> In your understanding (above) you happen to see the second. The first though
> is
> ALREADY there.
> 
> In the first you refer to a packet that goes from the previous LMM-aware
> routing
> element to the next..
> 
> In the second you refer to a packet for a _particular_ MN that goes for the
> last
> hop previous LMM-aware routing element to the next..
> 
> So you have correctly assumed a common hierarchy for all MNs here..you just
> pick
> a snapshot for the individual MN...
> 
> It is like the analogy...I can see the map of the roads...but at the same
> time I
> can see my route on that map.
> 
> 
> Multicast has said it in a different ..perhaps clearer way...incoming and
> outgoing interfaces...but it is the same thing...stil hierarchy..
> 
> I only wanted to show that the building blocks for a hierarchy are in
> principle
> there...it is just a matter of tying them together...in an admin domain
> 
> So I am definetely refering to a shared hierarchy...one which an LMM scheme
> could instantiate differently than another depending on how it wants to see
> it...
> 
> 
> Theo
> 
> 
> UCL/ Mobile Systems
> 
> 



From owner-mobile-ip@sunroof.eng.sun.com  Sat Apr 28 02:53:53 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA11180
	for ; Sat, 28 Apr 2001 02:53:52 -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 VAA14964;
	Fri, 27 Apr 2001 21:48: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 VAA02466;
	Fri, 27 Apr 2001 21:48: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 f3S4lFIM025697
	for ; Fri, 27 Apr 2001 21:47:15 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3S4lEhr025696
	for mobile-ip-dist; Fri, 27 Apr 2001 21:47: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 f3S4l3IM025689
	for ; Fri, 27 Apr 2001 21:47:06 -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 VAA06958
	for ; Fri, 27 Apr 2001 21:47:03 -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 VAA14699
	for ; Fri, 27 Apr 2001 21:47:02 -0700 (PDT)
Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM)
	id AA20849; Sat, 28 Apr 2001 00:47:02 -0400
Date: Sat, 28 Apr 2001 00:47:02 -0400 (EDT)
From: Jim Bound 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Some Analysis
In-Reply-To: <034BEFD03799D411A59F00508BDF7546013DBDD3@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: 

Hesham,

But your or Erik have not proven there is no significant benefit either.
I feel your response is using a logic model that states one cannot deduce
anything from mathematical properties and James also did the inequalities
too. So I would argue his logic table was duplicate with an addition
discrete logical component.

And as another comment do you know how many I told you so cards I am
holding where Ipv6 made choices to defer a minimum performance gain with
the argument that "no significant gain is made".  A lot.  Know what.  I
built an IPv6 stack.  And we had to make up for all those decisions as
implementors in our production IPv4/v6 stack.

So at this point with your comment I will say now I am digging my heels in
to the chairs and saying arguments of this sort are simply not fair in
this case.  The distribtution of hierarchy in this case will also cause
ease of management at each level and with LDAP, Agentx, or a host of other
user level protocols can be managed quite easily and maintained at the top
of the hiearchy.

Not picking on you or Erik but the argument OK.  I am as sick of this one
as I am of being liberal in what I receive and conservative in what I
send.  It is simply not logical or scientific.

Also I see a mege of RegRe and HMIPv6 with minimum alteration to either.
But give and take would be required.

respectfully to you as author too,

/jim

On Sat, 28 Apr 2001, Hesham Soliman  (ERA) wrote:

> James, 
> 
> 	Please see my comments below.
> 
> > > Numbers!!!
> > >
> > 
> > After having unjustly flamed Erik this morning and being inspired by
> > his challenge, I went through an analysis comparing signalling
> > overhead on hierarchical v.s. nonhierarchical designs. The attached
> > zipped PDF (sorry for the zip, I couldn't get a unzipped through the list size 
> > filter) and text explain.
> > 
> 	=. No probs. As a side not, I believe Erik said "Numbers". 
> 	This is a nice detailed analysis, but it's missing "Numbers". 
> 	I do agree that updating a node 2 hops away is faster
> 	than updating a node 3 hops away. That's just common
> 	sense. However, the point is: is there any _significant_
> 	improvement ? I don't think so.
> 	Why ? because the numbers for delays over the air interface
> 	are so much higher than forwarding on the wire, 
> 	which makes forwarding delays on the wire (within a local 
> 	domain) insignificant. 
> 
> 	I hope you can see that I didn't say "it will never happen".
> 	I said that there is no significant improvement .
> 	To use Eriks's words from an earlier mail, we need to
> 	see an order of magntude reduction in delays for any of 
> 	this to be significant. 
> 
> > Note to H&K: Arguments about the analysis are welcome, but please
> > don't post "this won't happen in practice" arguments. You may have
> > your opinion and I may have mine. The math speaks for itself.
> > 
> 	=> I guess I'm "H", your math is fine, but this academic 
> 	argument needs to be placed in the right context. 
> 	I'm sure you're already aware of these delays I'm referring
> 	to, since you're heavily involved in MWIF. 
> 
> 	Hesham
> 



From owner-mobile-ip@sunroof.eng.sun.com  Sat Apr 28 12:52:13 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15239
	for ; Sat, 28 Apr 2001 12:52: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 JAA10498;
	Sat, 28 Apr 2001 09:51:50 -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 JAA05396;
	Sat, 28 Apr 2001 09:51: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 f3SGoKIM026130
	for ; Sat, 28 Apr 2001 09:50:21 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3SGoK8P026129
	for mobile-ip-dist; Sat, 28 Apr 2001 09:50: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 f3SGo8IM026122
	for ; Sat, 28 Apr 2001 09:50:11 -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 JAA03526
	for ; Sat, 28 Apr 2001 09:50:08 -0700 (PDT)
Received: from smtp-2.hut.fi (smtp-2.hut.fi [130.233.228.92])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09686
	for ; Sat, 28 Apr 2001 09:50:06 -0700 (PDT)
Received: from cc.hut.fi (root@gamma.hut.fi [130.233.224.52])
	by smtp-2.hut.fi (8.9.3/8.9.3) with ESMTP id TAA48918;
	Sat, 28 Apr 2001 19:50:01 +0300 (EEST)
Message-ID: <3AEAE70B.2AA1F23F@cc.hut.fi>
Date: Sat, 28 Apr 2001 18:51:39 +0300
From: Tom =?iso-8859-1?Q?Weckstr=F6m?= 
Organization: HUT/TKK
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20smp i686)
X-Accept-Language: fi,sv,de
MIME-Version: 1.0
To: Erik Nordmark 
CC: 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)
References: 
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 JAA10498
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA15239

Hi Erik.

Here is an example of benefits that I think cannot be achieved with just
two levels in the hierarchy.

Erik Nordmark wrote:
> 
> Tom,
> 
> > As I have experienced the scalability benefit of the LMM, it will allow
> > scalability in the number of MNs moving within the domain through the
> > reduced signaling.
> 
> Do you have example topologies and numbers showing the differences?
> 
>    Erik

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.

Now, what happens, if we put another level of hierarchy underneath each
FA on the second level? Let us put M FAs under each of the N second
level FAs. We now have: 1. Level: 1 FA, 2. Level: N FAs, 3. Level: M
FAs. Now, the second layer takes signaling burden away from the highest
FA. How much the signaling is localized to the second layer, depends on
the mobility scenarios (aka mobility patterns) of the MNs. The more MNs,
the more signaling, the more the 3rd level helps. 

Additionally, if the same distance d between FAs is kept all the way
through the lowest level of the hierarchy (I am not saying this is wise,
just to simplify), then the  two-level hierarchy covers length of d*N of
the highway and the three level hierarchy covers something like d*M*N.
So, the hierarchy also provides scalability in geographical terms.

What this third level did not change is the amount of signaling per
kilometer on the highway, but the area of fast handoffs was enlarged by
M times. The VoIP data is taking more bandwidth than the signaling data,
so the highest FA could perhaps not take the VoIP traffic load generated
by k*M Mobile Nodes and should thus be updated with faster NICs.

Sorry for not providing any real numbers. Those would have been great,
but I think my time is way too limited for doing such research right
now.

Here are some seed parameters for further analysis in case anyone is
interested:
	- Number of MNs:	k
	- Number of FAs:	1,N,N*M
	- Number of levels in the hierarchy:	H
	- Distances between FAs (FA1 and FA2):	d_1,2
	- Amount of "useful" data traffic per MN:	X bps/MN
	- Amount of MIP signaling generated by an MN:	S bps/MN
	- Universal link speed in the infra:		L bps
	- Mobility patterns:	Not defined
	- Universal link speed over the air:	W bps

I know these could be fed into a network simulator for nice testing with
real numbers, but that is could be a subject of an entire research
project...

Comments? C'mon and shoot my ideas down! ;-)

Regards,
	Tom

-- 
        Tom Weckström           Dynamics group
                                Helsinki University of Technology
                                dynamics@cs.hut.fi
                                http://www.cs.hut.fi/Research/Dynamics/


From owner-mobile-ip@sunroof.eng.sun.com  Sat Apr 28 13:04: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 NAA15349
	for ; Sat, 28 Apr 2001 13:04:49 -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 KAA29743;
	Sat, 28 Apr 2001 10:04: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 KAA06149;
	Sat, 28 Apr 2001 10:04: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 f3SH3IIM026152
	for ; Sat, 28 Apr 2001 10:03:18 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3SH3IZ4026151
	for mobile-ip-dist; Sat, 28 Apr 2001 10:03:18 -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 f3SH39IM026144
	for ; Sat, 28 Apr 2001 10:03:09 -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 KAA07449
	for ; Sat, 28 Apr 2001 10:03:08 -0700 (PDT)
Received: from smtp-2.hut.fi (smtp-2.hut.fi [130.233.228.92])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15172
	for ; Sat, 28 Apr 2001 10:03:07 -0700 (PDT)
Received: from cc.hut.fi (root@gamma.hut.fi [130.233.224.52])
	by smtp-2.hut.fi (8.9.3/8.9.3) with ESMTP id UAA49089;
	Sat, 28 Apr 2001 20:02:59 +0300 (EEST)
Message-ID: <3AEAEA1B.939A4220@cc.hut.fi>
Date: Sat, 28 Apr 2001 19:04:43 +0300
From: Tom =?iso-8859-1?Q?Weckstr=F6m?= 
Organization: HUT/TKK
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20smp i686)
X-Accept-Language: fi,sv,de
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised 
 Localized Mobility Management Requirement s)
References: <034BEFD03799D411A59F00508BDF7546013DBDBC@esealnt448.al.sw.ericsson.se>
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 KAA29743
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA15349


Hi Hesham, 

"Hesham Soliman (ERA)" wrote:

> > There is little to argue against this clear benefit.
> > This benefit, in the end, results in *better scalability* as Theo and
> > others have already said.
> >
>         => Scalability of what ? How can you possibly claim that
>         keeping more state in the network scales better ?
>         Please explain this to me.
> 
>         Hesham

Could you elaborate with examples, what increased amount of state
information are you referring to? State information per LMM entity?
State information in the highest LMM agent? Routing state information
(mobility bindings)?

If we keep the number of MNs (k) within the domain as constant as well
as the traffic numbers of useful and signaling data per MN, and only add
LMM agents and levels into the hierarchy, then it seems to me that the
amount of state information in the highest LMM agent is the same with 2
levels than with Q (Q > 2) levels. Of course, the total amount of state
information is higher in the deeper hierarchy, but what does it matter
as long as the information is distributed? In this scenario (k and other
parameters being constants) the benefit of localized signaling in deeper
hierarchies is still achieved compared to 2 level hierarchies.

Where did I go wrong in my deduction?

Regards,
	Tom


-- 
        Tom Weckström           Dynamics group
                                Helsinki University of Technology
                                dynamics@cs.hut.fi
                                http://www.cs.hut.fi/Research/Dynamics/


From owner-mobile-ip@sunroof.eng.sun.com  Sat Apr 28 16:47: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 QAA16915
	for ; Sat, 28 Apr 2001 16:47: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 NAA14381;
	Sat, 28 Apr 2001 13:47: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 NAA18769;
	Sat, 28 Apr 2001 13:47: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 f3SKjqIM026263
	for ; Sat, 28 Apr 2001 13:45:53 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3SKjqAG026262
	for mobile-ip-dist; Sat, 28 Apr 2001 13:45:52 -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 f3SKjeIM026255
	for ; Sat, 28 Apr 2001 13:45:43 -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 NAA16706
	for ; Sat, 28 Apr 2001 13:45: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 OAA18808
	for ; Sat, 28 Apr 2001 14:54:58 -0600 (MDT)
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 f3SKjaO21057
	for ; Sat, 28 Apr 2001 22:45:36 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Sat Apr 28 22:45:35 2001 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Sat, 28 Apr 2001 22:40:52 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBDD6@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 L
	ocalized Mobility Management Requirement s)
Date: Sat, 28 Apr 2001 22:45:35 +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 Tom, 



> > > There is little to argue against this clear benefit.
> > > This benefit, in the end, results in *better scalability* as Theo and
> > > others have already said.
> > >
> >         => Scalability of what ? How can you possibly claim that
> >         keeping more state in the network scales better ?
> >         Please explain this to me.
> > 
> >         Hesham
> 
> Could you elaborate with examples, what increased amount of state
> information are you referring to? State information per LMM entity?
> State information in the highest LMM agent? Routing state information
> (mobility bindings)?
> 
	=> I was referring to the amount of state on each level of the 
	hierarchy. If you have multiple levels agents, each level keeps 
	a certain amount of state (ie. Binding cache entries).
	The top level clearly keeps the most amount. Hence you end 
	up with a tree of agents and a number of single points 
	of failure that is equal to the number of levels in the hierarchy. 

	The lower agents in the hierarchy will clearly keep a subset
	of the entries in the top agent. This is true whether your
	hierarchy is hidden or visible to the MN. Hence, more 
	(unnecessary IMHO) state is kept within the domain
	resulting in more single points of failure. To make these
	agents redundant, the cost would also be N times 
	the cost of keeping one agent redundant. Where N is 
	the number of levels in a hierarchy.

> If we keep the number of MNs (k) within the domain as constant as well
> as the traffic numbers of useful and signaling data per MN, and only add
> LMM agents and levels into the hierarchy, then it seems to me that the
> amount of state information in the highest LMM agent is the same with 2
> levels than with Q (Q > 2) levels. Of course, the total amount of state
> information is higher in the deeper hierarchy, but what does it matter
> as long as the information is distributed? 
> 
	=> Actually the amount is duplicated. The lower agents 
	keep a subset of the amount of state in the top agent.
	It does matter, because you're introducing single points
	of failure. Hence a less robust network.

> In this scenario (k and other
> parameters being constants) the benefit of localized signaling in deeper
> hierarchies is still achieved compared to 2 level hierarchies.
> 
	=> The signalling is always local to a domain. Where
	you place the LMM agent is a matter of network engineering.

	Regards,
	Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Sat Apr 28 17:08:08 2001
Received: from patan.sun.com ([192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17066
	for ; Sat, 28 Apr 2001 17:08:08 -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 OAA10646;
	Sat, 28 Apr 2001 14:08: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 OAA16521;
	Sat, 28 Apr 2001 14:07: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 f3SL6MIM026311
	for ; Sat, 28 Apr 2001 14:06:23 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3SL6M9s026310
	for mobile-ip-dist; Sat, 28 Apr 2001 14:06: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 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 f3SL6AIM026303
	for ; Sat, 28 Apr 2001 14:06: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 OAA17520
	for ; Sat, 28 Apr 2001 14:06:09 -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 PAA26636
	for ; Sat, 28 Apr 2001 15:15:30 -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 f3SL66O22944
	for ; Sat, 28 Apr 2001 23:06:06 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Sat Apr 28 23:06:06 2001 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Sat, 28 Apr 2001 23:01:22 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBDD7@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Some Analysis
Date: Sat, 28 Apr 2001 23:06:05 +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, 

> But your or Erik have not proven there is no significant benefit either.
> I feel your response is using a logic model that states one cannot deduce
> anything from mathematical properties and James also did the inequalities
> too. So I would argue his logic table was duplicate with an addition
> discrete logical component.
> 
	=> Let me just state that the model Jim sent was fine.
	I tried to put it in the right context. Does it really 
	matter if we save 3 or 4 ms if we have a 70 ms delay ?
	Or put differently, is there a siginificant gain is reducing 
	the delay from 76 to 73 ms ? 
	I can't see a significant difference but I might be missing 
	something. 

> And as another comment do you know how many I told you so cards I am
> holding where Ipv6 made choices to defer a minimum performance gain with
> the argument that "no significant gain is made".  A lot.  Know what.  I
> built an IPv6 stack.  And we had to make up for all those decisions as
> implementors in our production IPv4/v6 stack.
> 
> So at this point with your comment I will say now I am digging my heels in
> to the chairs and saying arguments of this sort are simply not fair in
> this case.  The distribtution of hierarchy in this case will also cause
> ease of management at each level and with LDAP, Agentx, or a host of other
> user level protocols can be managed quite easily and maintained at the top
> of the hiearchy.
> 
	=> I can appreciate your logic, but I think that the 
	"no signifigant gain" argument should be backed up
	by propoer reasoning. If not then what you mention
	above may happen. Of course I'm saying this 
	in general without knowing what specific case 
	you're referring to. But in this particular example
	I've attempted to show numbers that some of us 
	(including James I'm sure) are aware of to see 
	whether the gain is significant enough to introduce 
	a clearly less robust and more complex/expensive
	solution.

> Not picking on you or Erik but the argument OK.  
> 
	=> Sure.

> Also I see a mege of RegRe and HMIPv6 with minimum alteration to either.
> But give and take would be required.
> 
	=> As discussed before and suggested by Raj, there is 
	nothing wrong with using ideas from other drafts of course. 
	The point of the exercise is to highlight the requirements.
	When we argee on them we can then see what's missing 
	from the current proposal. If requirement X is not met 
	_and_ the best solution for it is in draft A, then why not. 

	So IMHO saying that a merger is needed is a bit premature, 
	first we should agree (by consensus of course) on the 
	requirements, then see what requirements are not 
	met and finally identify the best way of solving it. 

	As Karim said earlier, multi-level hierarchy is already
	supported in the current proposal (for the MR case). 
	Of course it can be further optimised if that's what 
	the WG wants. But it is very important to make sure
	that whatever functionality we add is actually needed.
	IMO too many options can kill any proposal. 

	Thanks,
	Hesham



From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 30 07:06: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 HAA04681
	for ; Mon, 30 Apr 2001 07:06: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 EAA27012;
	Mon, 30 Apr 2001 04:06: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 EAA04121;
	Mon, 30 Apr 2001 04:06: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 f3UB5FIM027989
	for ; Mon, 30 Apr 2001 04:05:15 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3UB5FgJ027988
	for mobile-ip-dist; Mon, 30 Apr 2001 04:05: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 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 f3UB54IM027981
	for ; Mon, 30 Apr 2001 04:05:04 -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 EAA29537
	for ; Mon, 30 Apr 2001 04:05:03 -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 FAA01824
	for ; Mon, 30 Apr 2001 05:21:58 -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 HAA04346;
	Mon, 30 Apr 2001 07:05:00 -0400 (EDT)
Message-Id: <200104301105.HAA04346@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-hmipv6-03.txt
Date: Mon, 30 Apr 2001 07:05:00 -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		: Hierarchical MIPv6 mobility management
	Author(s)	: H. Soliman, C. Castelluccia, K. Malki, L. Bellier
	Filename	: draft-ietf-mobileip-hmipv6-03.txt
	Pages		: 27
	Date		: 27-Apr-01
	
This draft introduces some extensions for MIPv6 and neighbour
discovery to allow for the introduction of a hierarchical MIPv6
mobility management model. The proposed hierarchical mobility
management for MIPv6 will reduce the amount of signalling to CNs and
the HA and may also improve the performance of MIPv6 in terms of
handoff speed. Moreover, HMIPv6 is well-suited to implement access
control and handoffs between different access technologies.

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

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

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

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

--OtherAccess--

--NextPart--




From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 30 07:57: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 HAA06090
	for ; Mon, 30 Apr 2001 07:57:06 -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 EAA07931;
	Mon, 30 Apr 2001 04:56: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 EAA02119;
	Mon, 30 Apr 2001 04:56:46 -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 f3UBtCIM028072
	for ; Mon, 30 Apr 2001 04:55:12 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3UBtB9S028071
	for mobile-ip-dist; Mon, 30 Apr 2001 04:55:11 -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 f3UBt3IM028064
	for ; Mon, 30 Apr 2001 04:55: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 EAA22171
	for ; Mon, 30 Apr 2001 04:55:02 -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 EAA06371
	for ; Mon, 30 Apr 2001 04:55:01 -0700 (PDT)
Received: from ws34.nomadiclab.com (ws34.nomadiclab.com [195.165.196.34])
	by ws130.nomadiclab.com (Postfix) with ESMTP id 99A4172504
	for ; Mon, 30 Apr 2001 14:54:59 +0300 (EEST)
Received: from nomadiclab.com (localhost [127.0.0.1])
	by ws34.nomadiclab.com (Postfix) with ESMTP id 1A343BA2F
	for ; Mon, 30 Apr 2001 14:54:59 +0300 (EEST)
Message-ID: <3AED5196.4771F69@nomadiclab.com>
Date: Mon, 30 Apr 2001 12:50:46 +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>
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 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 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.  

--Pekka Nikander


From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 30 09:53: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 JAA10458
	for ; Mon, 30 Apr 2001 09:53:16 -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 GAA21136;
	Mon, 30 Apr 2001 06:53: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 GAA20414;
	Mon, 30 Apr 2001 06:52: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 f3UDoaIM028242
	for ; Mon, 30 Apr 2001 06:50:36 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3UDoZpX028241
	for mobile-ip-dist; Mon, 30 Apr 2001 06:50: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 f3UDoRIM028234
	for ; Mon, 30 Apr 2001 06:50: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 GAA12995
	for ; Mon, 30 Apr 2001 06:50:27 -0700 (PDT)
Received: from p-mail2.cnet.fr (p-mail2.rd.francetelecom.fr [193.49.124.32])
	by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id GAA18543
	for ; Mon, 30 Apr 2001 06:50:26 -0700 (PDT)
Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19)
	id ; Mon, 30 Apr 2001 15:50:10 +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 221NBP7K; Mon, 30 Apr 2001 15:50:04 +0200
Message-ID: <3AED6D36.26EEA17B@francetelecom.com>
Date: Mon, 30 Apr 2001 15:48:39 +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>
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 GAA21136
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA10458

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.

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



From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 30 11:31: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 LAA15412
	for ; Mon, 30 Apr 2001 11:31: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 IAA22627;
	Mon, 30 Apr 2001 08:31:01 -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 IAA11859;
	Mon, 30 Apr 2001 08:29: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 f3UFSIIM028738
	for ; Mon, 30 Apr 2001 08:28:18 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3UFSHtE028737
	for mobile-ip-dist; Mon, 30 Apr 2001 08:28: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 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 f3UFSCIM028730
	for ; Mon, 30 Apr 2001 08:28:13 -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 LAA23070
	for ; Mon, 30 Apr 2001 11:28:13 -0400 (EDT)
Received: (from glass@localhost)
	by onion.east.sun.com (8.9.3+Sun/8.9.3) id LAA07908
	for mobile-ip@sunroof.eng.sun.com; Mon, 30 Apr 2001 11:28:26 -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 f3S7iOIM025801
	for ; Sat, 28 Apr 2001 00:44: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 AAA15460
	for ; Sat, 28 Apr 2001 00:44:25 -0700 (PDT)
Received: from mail.edu.cn ([202.202.32.39])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA10687
	for ; Sat, 28 Apr 2001 00:43:43 -0700 (PDT)
Received: from tanghong ([202.202.41.21])
	by mail.edu.cn (8.9.1b+Sun/8.9.1) with SMTP id PAA21953
	for ; Sat, 28 Apr 2001 15:41:59 +0800 (CST)
Message-ID: <007501c0cfb6$7cd4eb20$1529caca@cqupt.edu.cn>
From: "tang" 
To: 
References: <034BEFD03799D411A59F00508BDF7546013DBDA7@esealnt448.al.sw.ericsson.se>
Subject: [mobile-ip] help me,please
Date: Sat, 28 Apr 2001 15:39:30 +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 f3S7iQIM025802
Sender: owner-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

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  Mon Apr 30 12:10: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 MAA17087
	for ; Mon, 30 Apr 2001 12:10:38 -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 JAA29178;
	Mon, 30 Apr 2001 09:10: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 JAA12492;
	Mon, 30 Apr 2001 09:09: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 f3UG7fIM028785
	for ; Mon, 30 Apr 2001 09:07:42 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3UG7fPu028784
	for mobile-ip-dist; Mon, 30 Apr 2001 09:07: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 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 f3UG7WIM028777
	for ; Mon, 30 Apr 2001 09:07:32 -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 JAA19919
	for ; Mon, 30 Apr 2001 09:07:26 -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 KAA17628
	for ; Mon, 30 Apr 2001 10:25:40 -0600 (MDT)
Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id MAA20009; Mon, 30 Apr 2001 12:06:18 -0400
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.nortelnetworks.com; Mon, 30 Apr 2001 12:06:07 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Mon, 30 Apr 2001 12:04:49 -0400
Message-ID: 
From: "Muhammad Jaseemuddin" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Final(?) Cut on LMM Requirements
Date: Mon, 30 Apr 2001 12:04:47 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0D18F.4776A420"
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_01C0D18F.4776A420
Content-Type: text/plain

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_01C0D18F.4776A420
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: [mobile-ip] Final(?) Cut on LMM Requirements




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=20

    

    


            Hesham

    




------_=_NextPart_001_01C0D18F.4776A420--


From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 30 12:22:00 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 MAA17505
	for ; Mon, 30 Apr 2001 12:21: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 JAA20067;
	Mon, 30 Apr 2001 09:21: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 JAA22177;
	Mon, 30 Apr 2001 09:20: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 f3UGIBIM028828
	for ; Mon, 30 Apr 2001 09:18:11 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3UGIBfO028827
	for mobile-ip-dist; Mon, 30 Apr 2001 09:18:11 -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 f3UGI6IM028820
	for ; Mon, 30 Apr 2001 09:18:06 -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 MAA02376
	for ; Mon, 30 Apr 2001 12:18:06 -0400 (EDT)
Received: (from glass@localhost)
	by onion.east.sun.com (8.9.3+Sun/8.9.3) id MAA08794
	for mobile-ip@sunroof.eng.sun.com; Mon, 30 Apr 2001 12:18:19 -0400 (EDT)
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 f3UFvEIM028761
	for ; Mon, 30 Apr 2001 08:57:14 -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 IAA12893
	for ; Mon, 30 Apr 2001 08:57:14 -0700 (PDT)
Received: from c007.snv.cp.net (c007-h000.c007.snv.cp.net [209.228.33.206])
	by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id IAA16859
	for ; Mon, 30 Apr 2001 08:57:13 -0700 (PDT)
Received: (cpmta 19382 invoked from network); 30 Apr 2001 08:57:12 -0700
Received: from unknown (HELO federalmobility.com) (64.193.0.129)
  by smtp.federalmobility.com (209.228.33.206) with SMTP; 30 Apr 2001 08:57:12 -0700
X-Sent: 30 Apr 2001 15:57:12 GMT
Message-ID: <3AED8AEE.4D8780D8@federalmobility.com>
Date: Mon, 30 Apr 2001 10:55:26 -0500
From: Phil Neumiller 
Organization: Federal Mobility
X-Mailer: Mozilla 4.77 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: seamoby@diameter.org, mobile-ip@sunroof.eng.sun.com, cellular@diameter.org
Subject: [mobile-ip] New Wireless Internet IETF List
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

Apologies if you receive multiple copies of this.

Greetings,

A new wireless internet list has been created and can be subscribed to at:

http://internet.motlabs.com/mailman/listinfo/wirelessinternet

The WirelessInternet discussion list is devoted to new ideas and proposals on how future wireless technologies should be supported
by IETF working groups and their specifications.

Topics on this list are open but some of the following seem like appropriate starter discussions:

o Expansion of the global Internet over wireless access devices and wireless routers,
   Internet Over Wireless Expansion (IOWE) pre-BOF?
o Massive deployment of Mobile IP in non-cellular and perhaps non-carrier class networks.
o Pre-BOF discussions for new wireless WGs, i.e. last mile wireless/mobility BOF?
o Commercializing MANETs what is the best way to approach this?
o OpenRAN and possibly re-incarnating parts of Motorola's OBAST archictecture?
o Neo-3G (post-cellular) network architectures.

List moderators are Ron Akers and Phil Neumiller.

Thanks,

Phil Neumiller


From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 30 12:33: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 MAA18032
	for ; Mon, 30 Apr 2001 12:33:09 -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 JAA26251;
	Mon, 30 Apr 2001 09:33: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 JAA03538;
	Mon, 30 Apr 2001 09:32: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 f3UGUcIM028902
	for ; Mon, 30 Apr 2001 09:30:38 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3UGUbvK028901
	for mobile-ip-dist; Mon, 30 Apr 2001 09:30: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 f3UGUSIM028894
	for ; Mon, 30 Apr 2001 09:30:28 -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 JAA02930
	for ; Mon, 30 Apr 2001 09:30:29 -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 JAA27491
	for ; Mon, 30 Apr 2001 09:30:28 -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 JAA20095
	for ; Mon, 30 Apr 2001 09:30:22 -0700 (PDT)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3UGULt06153
	for ; Mon, 30 Apr 2001 09:30:21 -0700
X-mProtect:  Mon, 30 Apr 2001 09:30:21 -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 smtpdO6153g; Mon, 30 Apr 2001 09:30:05 PDT
Message-ID: <3AED930E.E08176B@iprg.nokia.com>
Date: Mon, 30 Apr 2001 09:30:06 -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: 
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 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.

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.

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.

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.

Regards,
Charlie P.


> 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


From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 30 13:27: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 NAA19876
	for ; Mon, 30 Apr 2001 13:27: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 KAA07445;
	Mon, 30 Apr 2001 10:27: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 KAA02863;
	Mon, 30 Apr 2001 10:26: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 f3UHOCIM029103
	for ; Mon, 30 Apr 2001 10:24:13 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3UHOCOQ029102
	for mobile-ip-dist; Mon, 30 Apr 2001 10:24: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 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 f3UHO0IM029085
	for ; Mon, 30 Apr 2001 10:24:00 -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 KAA06466
	for ; Mon, 30 Apr 2001 10:23:59 -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 KAA03927
	for ; Mon, 30 Apr 2001 10:23:58 -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 MAA24244
	for ; Mon, 30 Apr 2001 12:24:23 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Mon, 30 Apr 2001 12:23:57 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Mon, 30 Apr 2001 12:23:37 -0500
Message-ID: 
From: "Haseeb Akhtar" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Cc: "Mohamed Khalil" ,
        "Emad Qaddoura" ,
        "Russ Coffin" 
Subject: [mobile-ip] Updated SAPv2
Date: Mon, 30 Apr 2001 12:23:32 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0D19A.47BA3BD0"
Sender: owner-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_01C0D19A.47BA3BD0
Content-Type: text/plain;
	charset="iso-8859-1"

Hello all,

We have sent an updated version of the SAPv2 (Security Association
establishment Protocol) to the IETF editor. Following is the link for
accessing the document while it shows up in the IETF database. 

The introduction is attached as well.

We would appreciate your feedback.

Regards,

Mohamed Khalil
Haseeb Akhtar
Emad Qaddoura

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

ftp://standards.nortelnetworks.com/mobile-ip/docs/draft-mkhalil-mobileip-ipv
6-sap-02.txt

1.0 Introduction

   This draft outlines a  protocol that allows a dynamic establishment
   of Security Association (SA) between two nodes: the MN and the CN.
   The proposed protocol doesn't depend on its operation on a global or
   centralized PKI (Public Key Infrastructure) or KDC (Key Distribution
   Center). The existing Mobile IPv6 [2] messages are used to piggyback
   the security extensions required to negotiate the SA between the MN
   and the CN. This results in a usage optimization for the RF
   interface.

   The whole idea behind this protocol is to protect the messages
   between the MN and the CN (e.g. Binding Update, Binding
   Acknowledgement etc.). If the attacker resides on the link between
   the MN and the CN, the attacker then has no interest in intercepting
   and/or changing the messages (e.g. Binding Warning, Binding Update
   and Binding Acknowledgement) that are exchanged (since the attacker
   already has access to the traffic). If the attacker is off the link,
   then the attacker is interested in intercepting the messages (e.g.
   Binding Update) in order to direct the CN's traffic to the attacker.
   An assumption is made here that the attacker who is on the link is
   really not applicable to this problem.

   The security features provided by the proposed protocol are discussed
   in details in section 4.0, which include DoS protection, replay
   protection, non-repudiation, and message integrity.

------_=_NextPart_001_01C0D19A.47BA3BD0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






Updated SAPv2




Hello all,




We have sent an updated version of the =
SAPv2 (Security Association establishment Protocol) to the IETF editor. =
Following is the link for accessing the document while it shows up in =
the IETF database. 



The introduction is attached as =
well.




We would appreciate your =
feedback.




Regards,




Mohamed Khalil

Haseeb Akhtar

Emad Qaddoura




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




ftp://standards.nortelnetworks.com/mobile-ip/docs/draf=
t-mkhalil-mobileip-ipv6-sap-02.txt




1.0 Introduction




   This draft outlines =
a  protocol that allows a dynamic establishment

   of Security Association =
(SA) between two nodes: the MN and the CN.

   The proposed protocol =
doesn't depend on its operation on a global or

   centralized PKI (Public =
Key Infrastructure) or KDC (Key Distribution

   Center). The existing =
Mobile IPv6 [2] messages are used to piggyback

   the security extensions =
required to negotiate the SA between the MN

   and the CN. This results =
in a usage optimization for the RF

   interface.




   The whole idea behind =
this protocol is to protect the messages

   between the MN and the =
CN (e.g. Binding Update, Binding

   Acknowledgement etc.). =
If the attacker resides on the link between

   the MN and the CN, the =
attacker then has no interest in intercepting

   and/or changing the =
messages (e.g. Binding Warning, Binding Update

   and Binding =
Acknowledgement) that are exchanged (since the attacker

   already has access to =
the traffic). If the attacker is off the link,

   then the attacker is =
interested in intercepting the messages (e.g.

   Binding Update) in order =
to direct the CN's traffic to the attacker.

   An assumption is made =
here that the attacker who is on the link is

   really not applicable to =
this problem.




   The security features =
provided by the proposed protocol are discussed

   in details in section =
4.0, which include DoS protection, replay

   protection, =
non-repudiation, and message integrity.





------_=_NextPart_001_01C0D19A.47BA3BD0--


From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 30 13:52: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 NAA20558
	for ; Mon, 30 Apr 2001 13:52: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 KAA00783;
	Mon, 30 Apr 2001 10:51: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 KAA08207;
	Mon, 30 Apr 2001 10:50: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 f3UHmMIM029213
	for ; Mon, 30 Apr 2001 10:48:23 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3UHmMJP029212
	for mobile-ip-dist; Mon, 30 Apr 2001 10:48: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 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 f3UHmDIM029205
	for ; Mon, 30 Apr 2001 10:48:13 -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 KAA09527
	for ; Mon, 30 Apr 2001 10:48:12 -0700 (PDT)
Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27984
	for ; Mon, 30 Apr 2001 10:48:09 -0700 (PDT)
Received: from schoenfeld-isdn.darmstadt.gmd.de (schfeld@schoenfeld-isdn [141.12.156.205])
	by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id TAA26384;
	Mon, 30 Apr 2001 19:47:57 +0200 (MET DST)
Message-ID: <3AEDA1A1.2AB3D95C@schoenfeld-isdn.darmstadt.gmd.de>
Date: Mon, 30 Apr 2001 19:32:17 +0200
From: Wolfgang =?iso-8859-1?Q?Sch=F6nfeld?= 
	
Organization: GMD-IPSI
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13 i586)
X-Accept-Language: de, en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Some Analysis
References: <200104271709.KAA16098@heliopolis.eng.sun.com>
Content-Type: multipart/mixed;
 boundary="------------E52753D1FC7E8D24F2C47F87"
Sender: owner-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.
--------------E52753D1FC7E8D24F2C47F87
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Please see attached file...
-- 
Wolfgang Schoenfeld, GMD-IPSI, +49 6151 869 865
--------------E52753D1FC7E8D24F2C47F87
Content-Type: text/plain; charset=us-ascii;
 name="wheel.txt"
Content-Disposition: inline;
 filename="wheel.txt"
Content-Transfer-Encoding: 7bit

Many thanks again to Jak for triggering this discussion!!!
The many replies he received prove high interest.
Let me mention one more, I think, important point.
As Claude has shown in his INRIA report,
the mobile node's mobility has to be taken into account
when talking about performance of (non-)hierarchical mobility support.
Let me try to illustrate this by an example.

Assume you have a network with tree-like topology (like a cellular network)
where mobile nodes attach to the leaves (base stations).
Hierarchical mobility support means that each node is a mobility agent (HA, FA, or MAP).
When a mobile node MN moves from leaf A to leaf B,
exactly the mobility agents on the (unique!) path from A to B
are affected by the move, i.e. have to change the bindings for MN.
Let us call the length of that path the "distance" between A and B
(it is just the distance in the graph-theoretic sense)
and consider it as a measure for binding update performance
(obviously, more parameters come into play, see Jak's e-mail).

In order to arrive at some numbers :-) ,
consider as topology a complete binary tree of height n 
and, for a better understanding of the following,
draw it as a wheel of radius n where
- the root becomes the nave
- the branches become the (branching!) spokes
- the leaves are arranged on the felly
and MN moves on the felly.
(Had to use a German-English dictionary - hope the notions are correct.)
By accident, such a move may be very short
(of distance 2 in case of two base stations served by the same controller)
or very long (of distance 2n if the root/nave is traversed).
In order to have some better average cost analysis,
let us consider complete travels around the wheel,
i.e. permutations of the leaves/felly.

If MN proceeds from each leaf to its neighbour, say clock-wise, around the wheel,
then the average distance is (2^n-1)/(2^(n-2)) which approximates 4 .
(The number 2^n-1 is the sum of all distances since each part of a spoke
is traversed by some binding update excactly twice.
And 2^(n-2) is the number of leaves, i.e. of moves.
That the average length of a binding update is constant
is plausible since the very short distance of 2 happens in 50% of all cases.)
On the other hand, it is easy to imagine travels
where each move has distance 2n because it crosses the nave.
Altogether, binding updates in the hierarchical case 
have to traverse paths of lengths between 4 (constant) and 2n 
(linear in the diameter of the network).

Now let us only sketch non-hierarchical mobility support, i.e. Mobile IP.
Here, you fix a leaf (home agent) on the felly,
and all binding updates have to go to it.
But this means that at least 50% of them have to traverse the root/nave,
i.e. most cases are worst
and binding updates always have costs linear in the network diameter.


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.

Maybe, one should distinguish mobility
by feet, by car/train, and by plane
because they show different travel characteristics in the above model.
But, probably, this question is out of the scope of a theoretical analysis
and has, as Jak suggests, to be attacked by simulation.

--------------E52753D1FC7E8D24F2C47F87--



From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 30 14:10:13 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 OAA21038
	for ; Mon, 30 Apr 2001 14:10:13 -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 LAA16904;
	Mon, 30 Apr 2001 11:09:56 -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 LAA27609;
	Mon, 30 Apr 2001 11:09: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 f3UI8KIM029328
	for ; Mon, 30 Apr 2001 11:08:20 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3UI8JC0029327
	for mobile-ip-dist; Mon, 30 Apr 2001 11:08: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 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 f3UI8BIM029320
	for ; Mon, 30 Apr 2001 11:08:11 -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 f3UI81HD359141
	for ; Mon, 30 Apr 2001 11:08:03 -0700 (PDT)
Message-Id: <200104301808.f3UI81HD359141@jurassic.eng.sun.com>
Date: Mon, 30 Apr 2001 11:08:11 -0700 (PDT)
From: Alper Yegin 
Subject: Re: [mobile-ip] Authenticating BU and PKI
To: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=ISO-8859-1
Content-MD5: cKxmkJFECF3aXk3QfLcwFQ==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc 
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by sunroof.eng.sun.com id f3UI8BIM029321
Sender: owner-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 LAA16904
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA21038

> 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.... But of course if you 
are suggesting that MN should not send BU to CN until MN receives the first 
tunneled packet. (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



From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 30 17:59: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 RAA26818
	for ; Mon, 30 Apr 2001 17:59:21 -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 OAA22951;
	Mon, 30 Apr 2001 14:58: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 OAA11171;
	Mon, 30 Apr 2001 14:58: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 f3ULuZIM029705
	for ; Mon, 30 Apr 2001 14:56:35 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3ULuYhd029704
	for mobile-ip-dist; Mon, 30 Apr 2001 14:56:34 -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 f3ULuOIM029697
	for ; Mon, 30 Apr 2001 14:56:25 -0700 (PDT)
Received: from lillen (gbl-rem-38 [129.157.174.38])
	by bebop.france (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id XAA28829;
	Mon, 30 Apr 2001 23:56:11 +0200 (MET DST)
Date: Mon, 30 Apr 2001 13:58:32 -0700 (PDT)
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: 

> 
> Hi Erik.
> 
> Here is an example of benefits that I think cannot be achieved with just
> two levels in the hierarchy.


Tom,


I've think you've just recreated the computer science argument that the
only good answers are 0, 1, or infinity (and in your case you decided that
infinity was the best one).

I think we need an engineering analysis with some real numbers.
To help point out the need for a quantitaive approach 
I've added some comments below.

> Additionally, if the same distance d between FAs is kept all the way
> through the lowest level of the hierarchy (I am not saying this is wise,
> just to simplify), then the  two-level hierarchy covers length of d*N of
> the highway and the three level hierarchy covers something like d*M*N.
> So, the hierarchy also provides scalability in geographical terms.

Yes, but there is a difference between d = 10 meters and d = 10 light years.
If d is the latter I wouldn't need to worry about more hierarchy would I?

> What this third level did not change is the amount of signaling per
> kilometer on the highway, but the area of fast handoffs was enlarged by
> M times. The VoIP data is taking more bandwidth than the signaling data,
> so the highest FA could perhaps not take the VoIP traffic load generated
> by k*M Mobile Nodes and should thus be updated with faster NICs.

What if the needed bandwith exceeds (say) 100 Tbits/s?
I would be hard to construct such a LMM in the near future.

Thus we do collectively need real numbers somehow.

   Erik



From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 30 19:56:13 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 TAA28609
	for ; Mon, 30 Apr 2001 19:56: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 QAA12631;
	Mon, 30 Apr 2001 16:55: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 QAA21983;
	Mon, 30 Apr 2001 16:55: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 f3UNrlIM029801
	for ; Mon, 30 Apr 2001 16:53:47 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3UNrk2P029800
	for mobile-ip-dist; Mon, 30 Apr 2001 16:53: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 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 f3UNrcIM029793
	for ; Mon, 30 Apr 2001 16:53:38 -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 QAA10783
	for ; Mon, 30 Apr 2001 16:53:38 -0700 (PDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA03627
	for ; Mon, 30 Apr 2001 18:13:27 -0600 (MDT)
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 f3UNrwK08575;
	Mon, 30 Apr 2001 16:53:58 -0700 (PDT)
Received: (msubbara@localhost) by msubbara-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id TAA12248; Mon, 30 Apr 2001 19:53:01 -0400 (EDT)
Date: Mon, 30 Apr 2001 19:53:01 -0400
From: Madhavi Subbarao 
To: mobile-ip@sunroof.eng.sun.com
Cc: Madhavi W Subbarao 
Subject: [mobile-ip] Multiple flows with single NAI
Message-ID: <20010430195301.C12187@cisco.com>
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: 

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  Mon Apr 30 20:20: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 UAA28912
	for ; Mon, 30 Apr 2001 20:20: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 RAA17438;
	Mon, 30 Apr 2001 17:20:01 -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 RAA22141;
	Mon, 30 Apr 2001 17:19: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 f410HgIM029863
	for ; Mon, 30 Apr 2001 17:17:43 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f410Heim029860
	for mobile-ip-dist; Mon, 30 Apr 2001 17:17: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 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 f410HNIM029849
	for ; Mon, 30 Apr 2001 17:17:24 -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 UAA14730
	for ; Mon, 30 Apr 2001 20:17:23 -0400 (EDT)
Received: (from glass@localhost)
	by onion.east.sun.com (8.9.3+Sun/8.9.3) id UAA16693
	for mobile-ip@sunroof.eng.sun.com; Mon, 30 Apr 2001 20:17:36 -0400 (EDT)
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 f3UJUjIM029522
	for ; Mon, 30 Apr 2001 12:30:45 -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 MAA06478
	for ; Mon, 30 Apr 2001 12:30:33 -0700 (PDT)
Received: from goliath.siemens.de ([194.138.37.131])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA26528
	for ; Mon, 30 Apr 2001 12:30:31 -0700 (PDT)
X-Envelope-Sender-Is: wwlu@ieee.org (at relayer goliath.siemens.de)
Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11])
	by goliath.siemens.de (8.11.1/8.11.1) with ESMTP id f3UJUQC12606;
	Mon, 30 Apr 2001 21:30:27 +0200 (MET DST)
Received: from ieee.org ([219.8.75.114])
	by mail2.siemens.de (8.11.0/8.11.0) with ESMTP id f3UJUPK08034;
	Mon, 30 Apr 2001 21:30:25 +0200 (MET DST)
Message-ID: <3AEDBD4F.D47E2DB9@ieee.org>
Date: Mon, 30 Apr 2001 12:30:23 -0700
From: "Office of Willie W. LU" 
Organization: US Office - II of Willie W. Lu
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Phil Neumiller 
CC: seamoby@diameter.org, mobile-ip@sunroof.eng.sun.com, cellular@diameter.org
Subject: [mobile-ip] Re: [cellular] New Wireless Internet IETF List
References: <3AED8AEE.4D8780D8@federalmobility.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

thanks, all.

wmi is also a hot topic in 3Gwireless'2001 at: 3gwireless.com/3gwireless01 - the most authoritative tech event on 3Gwireless and
beyond.

rgds.
-willie


Phil Neumiller wrote:

> Apologies if you receive multiple copies of this.
>
> Greetings,
>
> A new wireless internet list has been created and can be subscribed to at:
>
> http://internet.motlabs.com/mailman/listinfo/wirelessinternet
>
> The WirelessInternet discussion list is devoted to new ideas and proposals on how future wireless technologies should be supported
> by IETF working groups and their specifications.
>
> Topics on this list are open but some of the following seem like appropriate starter discussions:
>
> o Expansion of the global Internet over wireless access devices and wireless routers,
>    Internet Over Wireless Expansion (IOWE) pre-BOF?
> o Massive deployment of Mobile IP in non-cellular and perhaps non-carrier class networks.
> o Pre-BOF discussions for new wireless WGs, i.e. last mile wireless/mobility BOF?
> o Commercializing MANETs what is the best way to approach this?
> o OpenRAN and possibly re-incarnating parts of Motorola's OBAST archictecture?
> o Neo-3G (post-cellular) network architectures.
>
> List moderators are Ron Akers and Phil Neumiller.
>
> Thanks,
>
> Phil Neumiller

--
Office of Willie W. LU
3Gwireless'01, Globecom'01, WCNC'02
e-mail: wwlu@ieee.org



From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 30 22:32: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 WAA02566
	for ; Mon, 30 Apr 2001 22:32:24 -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 TAA04814;
	Mon, 30 Apr 2001 19:32: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 TAA03838;
	Mon, 30 Apr 2001 19:32: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 f412UKIM000140
	for ; Mon, 30 Apr 2001 19:30:20 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f412UJfI000139
	for mobile-ip-dist; Mon, 30 Apr 2001 19:30: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 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 f412UBIM000132
	for ; Mon, 30 Apr 2001 19:30:11 -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 TAA00097
	for ; Mon, 30 Apr 2001 19:30:11 -0700 (PDT)
From: hspark@etri.re.kr
Received: from cms3.etri.re.kr (cms3.etri.re.kr [129.254.16.13])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA04036
	for ; Mon, 30 Apr 2001 19:30:10 -0700 (PDT)
Received: by cms3.etri.re.kr with Internet Mail Service (5.5.2653.19)
	id ; Tue, 1 May 2001 11:29:35 +0900
Message-ID: <766FA1FC5C2AD511B3C800D0B7A8AC4A230D81@cms3.etri.re.kr>
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Questions about Route Optimization in MIPv4
Date: Tue, 1 May 2001 11:29:25 +0900 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0D1E6.8A30A160"
Sender: owner-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_01C0D1E6.8A30A160
Content-Type: text/plain;
	charset="iso-8859-1"

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

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

Thanks in advance....

Regards, 
Hyun Seo

------_=_NextPart_001_01C0D1E6.8A30A160
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






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 ?

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




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




Thanks in advance....




Regards, 

Hyun Seo





------_=_NextPart_001_01C0D1E6.8A30A160--