From owner-seamoby@diameter.org Thu Feb 1 00:24:48 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07001 for ; Thu, 1 Feb 2001 00:24:48 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f114YMJ12488 for seamoby-list; Wed, 31 Jan 2001 20:34:22 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from c007.snv.cp.net (c007-h015.c007.snv.cp.net [209.228.33.222]) by charizard.diameter.org (8.10.0/8.10.0) with SMTP id f114X5o12478 for ; Wed, 31 Jan 2001 20:33:05 -0800 Received: (cpmta 6515 invoked from network); 31 Jan 2001 19:41:04 -0800 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; 31 Jan 2001 19:41:04 -0800 X-Sent: 1 Feb 2001 03:41:04 GMT Message-ID: <003501c08c00$d63a2f80$6501a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Gary Kenward" , "'seamoby'" , , "'seamoby-mm'" References: <13E2EF604DE5D111B2E50000F80824E8057A8BD9@zwdld001.ca.nortel.com> Subject: [seamoby] SPAM Date: Wed, 31 Jan 2001 21:41:17 -0600 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-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit There has not been that much spam, I only recall that one. I say don't fix it if it aint broke .... yet.... If we get bombarded I am all fer it... Danke, -pdn From owner-seamoby@diameter.org Thu Feb 1 00:24:52 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07013 for ; Thu, 1 Feb 2001 00:24:51 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f114VCn12462 for seamoby-list; Wed, 31 Jan 2001 20:31:12 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from c007.snv.cp.net (c007-h008.c007.snv.cp.net [209.228.33.214]) by charizard.diameter.org (8.10.0/8.10.0) with SMTP id f114Tro12453 for ; Wed, 31 Jan 2001 20:29:53 -0800 Received: (cpmta 1432 invoked from network); 31 Jan 2001 19:37:51 -0800 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; 31 Jan 2001 19:37:51 -0800 X-Sent: 1 Feb 2001 03:37:51 GMT Message-ID: <001f01c08c00$63586540$6501a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Gary Kenward" , "James Kempf" Cc: , References: <5.0.0.25.1.20010130123347.00a0e2e0@localhost> Subject: [seamoby] Was *?, Now a consension?? Date: Wed, 31 Jan 2001 21:38:03 -0600 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-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Jeez Loueezz, I think Mark Twain once said, "Always acknowledge a fault frankly. This will throw those in authority off their guard and give you opportunity to commit more." So here goes.... Hello Mr. James Kempf, You make Andrew and I sound like the martyrs of the IETF. I can't speak for him but I am quite flattered that you have chosen to bestow this distinction upon us. Last time I checked I worked for a struggling company that is trying to build REAL products attempting to solve REAL world problems. So if my academic hubris has become overwhelming I am quite happy to hear that I have gone "overboard" and I am quite willing to yield to concensus. My Mama said "I didn't raise no fool". I want to make things better than they are no matter what. YES, some of my ideas are "out there", but then again there is one in every bunch right? -pdn James Kempf of Sun Microsystems wrote: > I think Phil N., Andrew C., and the others that have new ideas in > this area need some space where they can explore exactly > what is the right way to do mobility at the edge and in the > core, without regard to precedent. The IETF is not the > right place for this work, since the intent of IETF standards > is to facilitate interoperability and deployment. The IRTF > is. From owner-seamoby@diameter.org Thu Feb 1 04:30:29 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA22356 for ; Thu, 1 Feb 2001 04:30:29 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f118Yjk12759 for seamoby-list; Thu, 1 Feb 2001 00:34:45 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f118Yho12754; Thu, 1 Feb 2001 00:34:43 -0800 Received: from centralmail1.Central.Sun.COM ([129.147.62.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA20984; Wed, 31 Jan 2001 23:42:43 -0800 (PST) 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 AAA25724; Thu, 1 Feb 2001 00:42:42 -0700 (MST) Received: from sunyata.sun.com by esun1as-mm. (SMI-8.6/SMI-SVR4) id BAA25133; Thu, 1 Feb 2001 01:00:47 -0700 Message-Id: <5.0.0.25.1.20010128233642.00a16150@localhost> X-Sender: kempf@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sun, 28 Jan 2001 23:40:09 -0800 To: "Phil Neumiller" , "Gary Kenward" From: James Kempf Subject: [seamoby] Re: Was *?, Now a consension?? Cc: , In-Reply-To: <001f01c08c00$63586540$6501a8c0@philneum> References: <5.0.0.25.1.20010130123347.00a0e2e0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-seamoby@diameter.org Precedence: bulk Hi Phil, There seems to be some kind of opinion that doing something in IRTF is consigning it to some kind of abstract realm where it will never see the light of day. Quite the contrary. The whole point of doing this work at IRTF is to get it "fully baked" in a place where the full implications of doing it could be followed without having to shoe horn it into existing precident. Does anybody know how IPv6 got done? I think IRTF was essentially morbid during that period, but it has been recently revived. If IRTF isn't the right place to do it, then maybe we need to figure out some other way, but I would rather see the work done in a way where it can be fully thought through than hemming and hawing about how to fit it in under mobile IP. jak At 09:38 PM 1/31/01 -0600, Phil Neumiller wrote: >Jeez Loueezz, > >I think Mark Twain once said, > >"Always acknowledge a fault frankly. This will throw those in authority off >their >guard and give you opportunity to commit more." > >So here goes.... > >Hello Mr. James Kempf, > >You make Andrew and I sound like the martyrs of the IETF. I can't speak >for >him but I am quite flattered that you have chosen to bestow this distinction >upon >us. Last time I checked I worked for a struggling company that is trying to >build >REAL products attempting to solve REAL world problems. So if my academic >hubris has become overwhelming I am quite happy to hear that I have gone >"overboard" and I am quite willing to yield to concensus. My Mama said >"I didn't raise no fool". I want to make things better than they are no >matter what. >YES, some of my ideas are "out there", but then again there is one in every >bunch >right? > >-pdn > >James Kempf of Sun Microsystems wrote: > > I think Phil N., Andrew C., and the others that have new ideas in > > this area need some space where they can explore exactly > > what is the right way to do mobility at the edge and in the > > core, without regard to precedent. The IETF is not the > > right place for this work, since the intent of IETF standards > > is to facilitate interoperability and deployment. The IRTF > > is. From owner-seamoby@diameter.org Thu Feb 1 09:01:03 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27362 for ; Thu, 1 Feb 2001 09:01:03 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f11CqBu13277 for seamoby-list; Thu, 1 Feb 2001 04:52:11 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from porsta.cs.Helsinki.FI (root@porsta.cs.Helsinki.FI [128.214.48.124]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f11Cpeo13272 for ; Thu, 1 Feb 2001 04:51:40 -0800 Received: from melkinpaasi.cs.Helsinki.FI (jmanner@melkinpaasi.cs.Helsinki.FI [128.214.10.13]) by porsta.cs.Helsinki.FI (8.8.8/8.8.8) with ESMTP id NAA14465; Thu, 1 Feb 2001 13:59:37 +0200 Date: Thu, 1 Feb 2001 13:59:33 +0200 (EET) From: Jukka Manner To: Seamoby Context Transfer Design Team cc: Seamoby Working Group Subject: [seamoby] Re: draft-brain-seamoby-terms-00.txt In-Reply-To: <13E2EF604DE5D111B2E50000F80824E8057A8B4E@zwdld001.ca.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk Gary, Here are some (late) answers to your comments. I copy this to the main Cmoby list to raise more discussion on the terminology of the draft. Regards, Jukka On Thu, 18 Jan 2001, Gary Kenward wrote: > Overall, I liked this draft, and the clarity and logic of the definitions. > It goes beyond what we need for the CT problem statement, and so we > must be cautious not to rat-hole on issues such as paging. Hopefully, > appropriate selections will be made in the problem statement draft > that Henrik is leading. The draft was intended for the whole Seamoby WG, so part of it is truly not needed in CT discussions. Hopefully the whole WG will benefit from it. > > Some specific comments/concerns: > > p5: section 2.2.2, Layer 2 handovers are not necessarily intra-technology. I > have > misplaced the announcement, but at least one company is working on dual mode > devices that will switch between Bluetooth and 802.11 without involving the > IP layer. True. Perhaps we should then just change "necessarily" to "typically". > > p5: section 2.2.2, I did not understand the discussion on Horizontal and > Vertical handover, and in particular how these definitions mapped onto the > architecture. I'm probably missing some key IETF nomenclature here, but if you > would help > me out, and explain the relationship between Horizontal and Vertical > handover > and inter- and intra- AR handover. If there is no relationship, then one of > the > definitions would seem to be redundant. > We try to see the handover event from the IP POV. When the interface on the IP layer does not change, we can think that a pure layer 2 handover happened, which remained (partially) unnoticed at the IP layer. This was called horizontal. When the network interface clearly changes at the IP layer, we called this vertical handover. The definitions come from discussions on what to call handovers between different link layers. In future wireless communications, a MH can do handovers from UMTS to GPRS to blue tooth to WLAN to any-network-you-like. Previously those were called vertical and horizontal (change of link layer vs. no change in link layer). We tried to adopt those and look at them from the IP POV. The handover terms defined in 2.2.1 and 2.2.2 are related to the context of discussions. They define somewhat similar handovers, but for clarity and to provide less room for misunderstanding, we have defined that many. In the definition of "Horizontal" we must replace "OAR and NAR" with "AN". > p6: I do not agree that a planned handover is generally a result of backward > handover. The definition of planned handover does not suffer if this > sentence > is removed. Should we say that "planned assumes backward" - would that be enough? I'm not sure whether a NAR can be chosen and be active to initiate the handover. Wouldn't choosing a NAR be part of the handover procedure? > p6: "planned" vs. "unplanned" don't work for me. they have a connotation of > long term, slow. I'm not sure why you chose not to use "proactive" and > "reactive", > and introduced "planned" and "unplanned" - the latter terms don't really add > to the meaning. (one could be trite and say that a "reactive" handover could > be planned). To us this was a matter of taste. In the "literature", they are used synonymously. > p7: I am not comfortable with the definition of Seamless, in that if it is > really simply > the combination of smooth and fast, then it is already being done in MIP. I > see > Seamless as being handover with no (discernable) drop in QoS. This is both > semantically and practically different from smooth+fast. Actually, if we then start using "seamless", we have to specify whether we mean "mobileip-seamless" or "seamoby-seamless" because the term has a "well-known" meaning in mobileip. We would assume that "being done in MIP" means "being tackled in mobileip WG", i.e., refers to the fast handover proposals. (nevertheless, the fact that something is being done in mobileip means extensions to MIP that are not necessarily straightforwardly applicable to seamoby) Would we need another handover type then to include the idea of supporting QoS. So, a "QoS (and/or context) aware" handover? > p.7: You have introduced the concept of "context aware". I don't think we > need yet > another handover type. In my mind, context aware was part of seamless. Now, > given your definition of seamless, yes, there is context that goes beyond > smooth+fast, > and indeed goes beyond sustained QoS. Of course, we can define SeaMoby to be > seamless + context aware, but now we have a 5 types of handover (including > the > non-smooth, non-fast, non-context aware case). Would it not be better to > define > seamless as being context aware? Or, even better, as being context > sustaining? > I can see that we have two types of definitions for seamlessness: "Cmless"=seamless+context+everything or "Cmless"=fast+no-packet-drops Since the MIP people have already a definition for seamless, I don't think we should make a new one, but perhaps define a new type that includes the notion of sustaining the QoS. Would "QoS (aware) handover" be a bad term? > p8: I don't want to open a discussion of paging on this mailing list, so as > a short note > to be taken to the paging mailing list, I don't believe that paging itself > should do all > that you imply. There should be an intermediate stage between a paging > wake-up and > establishment of a SAR. True. But I'm not the right person to comment on that issue. Anyone want to add more insight to this? > > p8:, section 2.5: The distinguishment you make between user and personal > mobility > seems to have more to do with whether push applications are possible. From > the appendices, > I gather that the definition came from the telecom arena, and is biased (or > limited) > accordingly. Also, the essence of this definition seems to be tracking of > the user, which > is outside the scope of SeaMob. Yes, we tried to emphasize that these are defined in order to be able to describe what is not in scope (L2 handover and similar might also be augmented with such remarks). > Regards > Gary > From owner-seamoby@diameter.org Thu Feb 1 09:53:33 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28490 for ; Thu, 1 Feb 2001 09:53:33 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f11Dqkp13356 for seamoby-list; Thu, 1 Feb 2001 05:52:46 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f11Dqio13351; Thu, 1 Feb 2001 05:52:44 -0800 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA05380; Thu, 1 Feb 2001 05:00:45 -0800 (PST) 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 FAA14014; Thu, 1 Feb 2001 05:00:44 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id FAA03265; Thu, 1 Feb 2001 05:00:40 -0800 (PST) Date: Thu, 1 Feb 2001 05:00:39 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: [seamoby] Re: [seamoby-mm] Re: Was *?, Now a consension?? To: James Kempf Cc: Phil Neumiller , Gary Kenward , seamoby-mm@cdma-2000.org, seamoby@cdma-2000.org In-Reply-To: "Your message with ID" <5.0.0.25.1.20010128233642.00a16150@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk All, I've somehow lost the original thread that caused this discussions, but telling people to go play in another sandbox doesn't normally foster good working relationships. I am quite sure that Jim had no ill intentions when he originally sent the e-mail, and perhaps we can let this thread die. As far as where the work belongs, I haven't (yet) seen anything that is so half baked that it belongs in the pressure cooker.... but we will see as our problem statements develop. PatC From owner-seamoby@diameter.org Thu Feb 1 11:30:51 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00668 for ; Thu, 1 Feb 2001 11:30:50 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f11FJO913565 for seamoby-list; Thu, 1 Feb 2001 07:19:24 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from zcars04e (h56s242a129n47.user.nortelnetworks.com [47.129.242.56]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f11FJKo13555 for ; Thu, 1 Feb 2001 07:19:20 -0800 Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Wed, 31 Jan 2001 11:43:39 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id ; Wed, 31 Jan 2001 11:37:57 -0500 Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8BDF@zwdld001.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" Cc: seamoby-mm@cdma-2000.org, "'seamoby@diameter.org'" Subject: RE: [seamoby-mm] RE: [seamoby] problem statement and rechartering (was: Re: The ri ght protocol was RE: [seamoby-mm] ietf-seamoby-mm-pr oblem-00-a1.txt) Date: Wed, 31 Jan 2001 11:37:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08BA4.2345AC80" X-Orig: Sender: owner-seamoby@diameter.org Precedence: bulk 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_01C08BA4.2345AC80 Content-Type: text/plain; charset="ISO-8859-1" Fair assessment James, although I do believe that there is a real emerging market need for an alternative mobility solution. Namely, in support of wireless LANs, CANs, PANs. I do find it curious that you see it as being a research activity. There has been research going on for 20 years on network mobility support, and there is actually more information floating about on alternative solutions then there was for MIP when the IETF created the working group 10 years ago. I'm going to get flamed for saying this, but I sense that out of the ten years of struggling to be deployed, the people working on MIP are paranoid that an alternative solution will take away what momentum it has, similar to what DHCP did for the nomadic application. I always thought the rule was to let the market decide. The reason that this is coming out now, is in response to your statement of losing 10 years of effort. I sincerely hope that this is not a factor in determining the formulation of the micromobility problem statement, or in influencing its focus and forcefulness. 'Nuff said. Gary > -----Original Message----- > From: James Kempf [mailto:james.kempf@sun.com] > Sent: Tuesday, January 30, 2001 3:49 PM > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: seamoby-mm@cdma-2000.org; 'seamoby@diameter.org' > Subject: [seamoby-mm] RE: [seamoby] problem statement and rechartering > (was: Re: The ri ght protocol was RE: [seamoby-mm] ietf-seamoby-mm-pr > oblem-00-a1.txt) > > > At 02:47 PM 1/30/01 -0500, Gary Kenward wrote: > > >I'm with you to this point, James. But, if we were to follow > this logic > >through, we'd still be trying to get ISDN to work, or maybe even, > >*shudder* X.25. I'm willing to bet that the total person years and > >$$$ invested in both of these solutions far outweighs what has been > >expended on MIP. > > > >The telecom industry, and ITU, are known for there inertia. > Are you implying > >that the IETF must avoid developing better solutions simply because > >people spent 10 years on a solution that wasn't needed? > > If I thought that, I wouldn't have recommended micromobility > be taken to > the IRTF. > And if I thought mobile IP wasn't needed, I wouldn't be working > on fast handoff (and care so much that the right solution be adopted). > > Mobile IP has made some straightforward > extrapolations from the wired case, but it is not clear that they > are optimal. The Seamoby micromobilty design team > has decided to restrict discussion of the need for a new micromobility > protocol to intrasubnet mobility. Now, it is not at all clear > that this > is even a problem at L3 given support provided in L2 for mobility > between access points. I don't want to prejudge the outcome of > their process, but I have the impression that this decision was > as much influenced by the fact that mobile IP is the mobility > protocol of choice for the intersubnet case and the people who > have been pushing for doing a new micromobility protocol are > looking for some space where they can do some new work. > I don't think that's the right way to get the best mobility solution. > > I think Phil N., Andrew C., and the others that have new ideas in > this area need some space where they can explore exactly > what is the right way to do mobility at the edge and in the > core, without regard to precedent. The IETF is not the > right place for this work, since the intent of IETF standards > is to facilitate interoperability and deployment. The IRTF > is. > > The fact of the matter is that mobile IP has deployment momentum > even if it isn't the best (in some abstract sense) protocol given > what we know now. It clearly was when it was designed, and > the deployment momentum suggests we finish it and make > it available for the 3G's and others. After all, would the Internet > have ever happened if IPv4 had been abandoned immediately when > Deering and others began to realize the problems it has? > > jak > > ------_=_NextPart_001_01C08BA4.2345AC80 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [seamoby-mm] RE: [seamoby] problem statement and = rechartering (was: Re: The ri ght protocol was RE: [seamoby-mm] = ietf-seamoby-mm-pr oblem-00-a1.txt)

Fair assessment James, although I do believe that = there is a real
emerging market need for an alternative mobility = solution. Namely,
in support of wireless LANs, CANs, PANs.

I do find it curious that you see it as being a = research activity. There
has been research going on for 20 years on network = mobility support,
and there is actually more information floating = about on alternative solutions
then there was for MIP when the IETF created the = working group 10
years ago.

I'm going to get flamed for saying this, but I sense = that out of the ten
years of struggling to be deployed, the people = working on MIP are
paranoid that an alternative solution will take away = what momentum
it has, similar to what DHCP did for the nomadic = application. I always
thought the rule was to let the market = decide.

The reason that this is coming out now, is in = response to your statement
of losing 10 years of effort. I sincerely hope that = this is not a factor
in determining the formulation of the micromobility = problem statement,
or in influencing its focus and forcefulness.

'Nuff said.
Gary

> -----Original Message-----
> From: James Kempf [mailto:james.kempf@sun.com]
> Sent: Tuesday, January 30, 2001 3:49 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby-mm@cdma-2000.org; = 'seamoby@diameter.org'
> Subject: [seamoby-mm] RE: [seamoby] problem = statement and rechartering
> (was: Re: The ri ght protocol was RE: = [seamoby-mm] ietf-seamoby-mm-pr
> oblem-00-a1.txt)
>
>
> At 02:47 PM 1/30/01 -0500, Gary Kenward = wrote:
>
> >I'm with you to this point, James. But, if = we were to follow
> this logic
> >through, we'd still be trying to get ISDN = to work, or maybe even,
> >*shudder* X.25.  I'm willing to bet = that the total person years and
> >$$$ invested in both of these solutions far = outweighs what has been
> >expended on MIP.
> >
> >The telecom industry, and ITU, are  = known for there inertia.
> Are you implying
> >that the IETF must avoid developing better = solutions simply because
> >people spent 10 years on a solution that = wasn't needed?
>
> If I thought that, I wouldn't have recommended = micromobility
> be taken to
> the IRTF.
> And if I thought mobile IP wasn't needed, I = wouldn't be working
> on fast handoff (and care so much that the = right solution be adopted).
>
> Mobile IP has made some straightforward
> extrapolations from the wired case, but it is = not clear that they
> are optimal. The Seamoby micromobilty design = team
> has decided to restrict discussion of the need = for a new micromobility
> protocol to intrasubnet mobility. Now, it is = not at all clear
> that this
> is even a problem at L3 given support provided = in L2 for mobility
> between access points. I don't want to prejudge = the outcome of
> their process, but I have the impression that = this decision was
> as much influenced by the fact that mobile IP = is the mobility
> protocol of choice for the intersubnet case and = the people who
> have been pushing for doing a new micromobility = protocol are
> looking for some space where they can do some = new work.
> I don't think that's the right way to get the = best mobility solution.
>
> I think Phil N., Andrew C., and the others that = have new ideas in
> this area need some space where they can = explore exactly
> what is the right way to do mobility at the = edge and in the
> core, without regard to precedent. The IETF is = not the
> right place for this work, since the intent of = IETF standards
> is to facilitate interoperability and = deployment. The IRTF
> is.
>
> The fact of the matter is that mobile IP has = deployment momentum
> even if it isn't the best (in some abstract = sense) protocol given
> what we know now. It clearly was when it was = designed, and
> the deployment momentum suggests we finish it = and make
> it available for the 3G's and others. After = all, would the Internet
> have ever happened if IPv4 had been = abandoned  immediately when
> Deering and others began to realize the = problems it has?
>
>          = ;        jak
>
>

------_=_NextPart_001_01C08BA4.2345AC80-- From owner-seamoby@diameter.org Thu Feb 1 11:59:17 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03187 for ; Thu, 1 Feb 2001 11:59:17 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f11FJvH13576 for seamoby-list; Thu, 1 Feb 2001 07:19:57 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from c007.snv.cp.net (c007-h012.c007.snv.cp.net [209.228.33.219]) by charizard.diameter.org (8.10.0/8.10.0) with SMTP id f11FJto13571 for ; Thu, 1 Feb 2001 07:19:55 -0800 Received: (cpmta 4061 invoked from network); 1 Feb 2001 06:27:56 -0800 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; 1 Feb 2001 06:27:56 -0800 X-Sent: 1 Feb 2001 14:27:56 GMT Message-ID: <003601c08c5b$34927560$6501a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Jukka Manner" , "Seamoby Context Transfer Design Team" Cc: "Seamoby Working Group" References: Subject: [seamoby] New name -> Seamless to become Hidden Handover?? Date: Thu, 1 Feb 2001 08:28:09 -0600 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-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit How about HIDDEN handover? You are correct. Seamless is already overloaded all over the place. I like HIDDEN handover because it conveys what we are trying to do, i.e. have no user noticeable changes during handovers. The handover is also "hidden" from MIP so it is like a two edged sword. Cool acronym too: HiHo, HiHo... Alternatives could be Invisible Handover ++ Transparent Handover 0 ^ | Isn't English great | V Opaque Handover -- Imperceptible Handover + Concealed Handover +++ Thanks, Phil ----- Original Message ----- From: "Jukka Manner" > I can see that we have two types of definitions for seamlessness: > > "Cmless"=seamless+context+everything > > or > > "Cmless"=fast+no-packet-drops > > Since the MIP people have already a definition for seamless, I don't think we > should make a new one, but perhaps define a new type that includes the notion of > sustaining the QoS. Would "QoS (aware) handover" be a bad term? > From owner-seamoby@diameter.org Thu Feb 1 12:21:18 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03677 for ; Thu, 1 Feb 2001 12:21:18 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f11Fm4S13626 for seamoby-list; Thu, 1 Feb 2001 07:48:04 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from porsta.cs.Helsinki.FI (root@porsta.cs.Helsinki.FI [128.214.48.124]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f11Fm1o13621 for ; Thu, 1 Feb 2001 07:48:01 -0800 Received: from melkinpaasi.cs.Helsinki.FI (jmanner@melkinpaasi.cs.Helsinki.FI [128.214.10.13]) by porsta.cs.Helsinki.FI (8.8.8/8.8.8) with ESMTP id QAA21768; Thu, 1 Feb 2001 16:56:03 +0200 Date: Thu, 1 Feb 2001 16:55:58 +0200 (EET) From: Jukka Manner To: Phil Neumiller cc: Seamoby Context Transfer Design Team , Seamoby Working Group Subject: [seamoby] Re: New name -> Seamless to become Hidden Handover?? In-Reply-To: <003601c08c5b$34927560$6501a8c0@philneum> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk I like your reasoning... HiHo... :) However, even though the "HiHo" sounds cool, "transparent" handover might be more correct, and dull. An additional question rose about to whom is the transparent HO seamless: A HiHo handover deals mainly with QoS, so to an application and its flows a HiHo should not be seen. But if a HiHo is also a Vertical handover and the IP layer's network interface changes, ie. a HO from a 3G network to a WLAN, the HO is noticed, at least the user will see this. So, I guess a HiHo or a transparent HO (THO) is "seamless" from purely a flow's POV. Jukka On Thu, 1 Feb 2001, Phil Neumiller wrote: > How about HIDDEN handover? You are correct. Seamless is already overloaded > all over the place. I like HIDDEN handover because it conveys what we are > trying > to do, i.e. have no user noticeable changes during handovers. The handover > is also > "hidden" from MIP so it is like a two edged sword. Cool acronym too: HiHo, > HiHo... > Alternatives could be > > Invisible Handover ++ > Transparent Handover 0 > ^ > | > Isn't English great > | > V > Opaque Handover -- > Imperceptible Handover + > Concealed Handover +++ > > Thanks, > > Phil > ----- Original Message ----- > From: "Jukka Manner" > > I can see that we have two types of definitions for seamlessness: > > > > "Cmless"=seamless+context+everything > > > > or > > > > "Cmless"=fast+no-packet-drops > > > > Since the MIP people have already a definition for seamless, I don't think > we > > should make a new one, but perhaps define a new type that includes the > notion of > > sustaining the QoS. Would "QoS (aware) handover" be a bad term? > > > From owner-seamoby@diameter.org Thu Feb 1 14:14:19 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08432 for ; Thu, 1 Feb 2001 14:14:18 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f11HpXb13904 for seamoby-list; Thu, 1 Feb 2001 09:51:33 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f11HpVo13899 for ; Thu, 1 Feb 2001 09:51:31 -0800 Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f11GwM107108; Thu, 1 Feb 2001 08:58:22 -0800 (PST) Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104]) by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f11GxVA27900; Thu, 1 Feb 2001 08:59:32 -0800 (PST) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 882569E6.005D77D3 ; Thu, 1 Feb 2001 09:00:55 -0800 X-Lotus-FromDomain: 3COM From: Phil_Neumiller@3Com.com To: Jukka Manner cc: seamoby@diameter.org Message-ID: <882569E6.005D6FB0.00@hqoutbound.ops.3com.com> Date: Thu, 1 Feb 2001 11:06:25 -0600 Subject: [seamoby] Re: New name -> Seamless to become Hidden Handover?? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-seamoby@diameter.org Precedence: bulk Hi Jukka, Please respond to Jukka Manner A HiHo handover deals mainly with QoS, so to an application and its pdn>Wherever did you get this fixation on QoS? IMHO, a HiHo is the epitome pdn>of handovers combining all desirable qualities including QoS. flows a HiHo should not be seen. But if a HiHo is also a Vertical handover and the IP layer's network interface changes, ie. a HO from a 3G network to a WLAN, the HO is noticed, at least the user will see this. pdn>If its a vertical HO, and the COA must change, it is no longer a HiHo or pdn>a concern of SeaMoby MM (however SeaMoby CT is still interested). This is pdn>my understanding of the SeaMoby boundaries, i.e. Micro-mobility is invoked pdn>when COA does not change, and CT controlled by either Macro or Micro mobility pdn>will always be invoked in some manner. Take it easy, pdn From owner-seamoby@diameter.org Thu Feb 1 19:09:41 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15138 for ; Thu, 1 Feb 2001 19:09:40 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f11N6bE14386 for seamoby-list; Thu, 1 Feb 2001 15:06:37 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f11N6Xo14380 for ; Thu, 1 Feb 2001 15:06:33 -0800 Received: from centralmail1.Central.Sun.COM ([129.147.62.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16802; Thu, 1 Feb 2001 14:13:33 -0800 (PST) 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 PAA09460; Thu, 1 Feb 2001 15:13:33 -0700 (MST) Received: from sunyata.sun.com by esun1as-mm. (SMI-8.6/SMI-SVR4) id PAA13834; Thu, 1 Feb 2001 15:31:40 -0700 Message-Id: <5.0.0.25.1.20010129140329.00a2da00@localhost> X-Sender: kempf@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 29 Jan 2001 14:10:54 -0800 To: "Gary Kenward" From: James Kempf Subject: RE: [seamoby-mm] RE: [seamoby] problem statement and rechartering (was: Re: The ri ght protocol was RE: [seamoby-mm] ietf-seamoby-mm-pr oblem-00-a1.txt) Cc: seamoby-mm@cdma-2000.org, "'seamoby@diameter.org'" In-Reply-To: <13E2EF604DE5D111B2E50000F80824E8057A8BDF@zwdld001.ca.norte l.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1690403==_.ALT" Sender: owner-seamoby@diameter.org Precedence: bulk --=====================_1690403==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Gary, At 11:37 AM 1/31/01 -0500, Gary Kenward wrote: >The reason that this is coming out now, is in response to your statement >of losing 10 years of effort. I sincerely hope that this is not a factor >in determining the formulation of the micromobility problem statement, >or in influencing its focus and forcefulness. This is *your * interpretation of my email. It is not what I intended to say. I don't think that there has been 10 years of lost effort. Quite the contrary. I think mobile IP made some straightforward assumptions from the wired case that were fairly accurate at the time. Exactly like IPv4 made the assumption that 32 bits of address space was enough. Let's get on with the job of finishing mobile IP, while opening some space in the context of IRTF to begin exploring alternatives. >'Nuff said. >Gary Yes, exactly. I will now shut up in deference to our working group chair's request for silence on this thread. jak --=====================_1690403==_.ALT Content-Type: text/html; charset="us-ascii" Gary,

At 11:37 AM 1/31/01 -0500, Gary Kenward wrote:

The reason that this is coming out now, is in response to your statement
of losing 10 years of effort. I sincerely hope that this is not a factor
in determining the formulation of the micromobility problem statement,
or in influencing its focus and forcefulness.


This is *your * interpretation of my email. It is not what I intended
to say.

I don't think that there has been 10 years of lost effort. Quite the contrary. I think
mobile IP made some straightforward assumptions from the
wired case that were fairly accurate at the time. Exactly like IPv4 made
the assumption that 32 bits of address space was enough. Let's get on with the
job of finishing mobile IP, while opening some space in the
context of IRTF to begin exploring alternatives.

'Nuff said.
Gary

Yes, exactly. I will now shut up in deference to our working group chair's request
for silence on this thread.

                jak --=====================_1690403==_.ALT-- From owner-seamoby@diameter.org Thu Feb 1 19:48:59 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15635 for ; Thu, 1 Feb 2001 19:48:59 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f11LJ6n14245 for seamoby-list; Thu, 1 Feb 2001 13:19:06 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f11LJ4o14240 for ; Thu, 1 Feb 2001 13:19:04 -0800 Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f11KPu100959 for ; Thu, 1 Feb 2001 12:25:56 -0800 (PST) Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104]) by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f11KR6A04937 for ; Thu, 1 Feb 2001 12:27:06 -0800 (PST) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 882569E6.00707EA0 ; Thu, 1 Feb 2001 12:28:44 -0800 X-Lotus-FromDomain: 3COM From: Phil_Neumiller@3Com.com To: seamoby@diameter.org Message-ID: <882569E6.0070706E.00@hqoutbound.ops.3com.com> Date: Thu, 1 Feb 2001 14:24:25 -0600 Subject: [seamoby] Single sentence problem statements Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-seamoby@diameter.org Precedence: bulk The SeaMoby chartered problems stated in single sentences. Micro-mobility Problem Statement ====================================================================== To avoid extraneous latency and signalling overhead caused by MIP, a light weight micro-mobility protocol running on the edges of the global Internet is required for handovers that do not require an updated MIP COA. Context Transfer Problem Statement ====================================================================== To preserve the MN context during handover, a reliable mechanism to transfer and negotiate MN connection/micro-flow state is required. Paging Problem Statement (1 sentence) ====================================================================== Most of today's wireless systems use link layer methods for paging, however, it is desired to create a layer 3 IP-based method to notify a MN of a network event requiring the MN's attention. The single sentence exercise has a nice Occam's razor effect of simplifying this stuff. Please let me know if these are adequate or what you would change. I would encourage others to try and reduce the problem statements to a single sentence. Maybe then we could build an optimized synthesized single statement problem statement or perhaps a power paragraph? From owner-seamoby@diameter.org Thu Feb 1 19:56:57 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15774 for ; Thu, 1 Feb 2001 19:56:56 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f11NM2t14413 for seamoby-list; Thu, 1 Feb 2001 15:22:02 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f11NLto14408 for ; Thu, 1 Feb 2001 15:21:56 -0800 Received: from centralmail1.Central.Sun.COM ([129.147.62.10]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA06732; Thu, 1 Feb 2001 14:29:50 -0800 (PST) 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 PAA15647; Thu, 1 Feb 2001 15:29:50 -0700 (MST) Received: from sunyata.sun.com by esun1as-mm. (SMI-8.6/SMI-SVR4) id PAA14357; Thu, 1 Feb 2001 15:47:58 -0700 Message-Id: <5.0.0.25.1.20010129142546.00a319f0@localhost> X-Sender: kempf@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 29 Jan 2001 14:27:16 -0800 To: Phil_Neumiller@3Com.com, seamoby@diameter.org From: James Kempf Subject: Re: [seamoby] Single sentence problem statements In-Reply-To: <882569E6.0070706E.00@hqoutbound.ops.3com.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-seamoby@diameter.org Precedence: bulk Phil, The paging group is in the process of finalizing a draft with the paging problem statement. The group has discussed the issues involved in paging in some amount of detail. If you would like to contribute comments on the draft, I can send you a copy. Unfortunately, your statement does not capture the whole picture. Thanx for the suggestion. jak At 02:24 PM 2/1/01 -0600, Phil_Neumiller@3Com.com wrote: >The SeaMoby chartered problems stated in single sentences. > >Micro-mobility Problem Statement >====================================================================== >To avoid extraneous latency and signalling overhead caused by >MIP, a light weight micro-mobility protocol running on the edges >of the global Internet is required for handovers that do not >require an updated MIP COA. > >Context Transfer Problem Statement >====================================================================== >To preserve the MN context during handover, a reliable mechanism to >transfer and negotiate MN connection/micro-flow state is required. > >Paging Problem Statement (1 sentence) >====================================================================== >Most of today's wireless systems use link layer methods for paging, >however, it is desired to create a layer 3 IP-based method to >notify a MN of a network event requiring the MN's attention. > >The single sentence exercise has a nice Occam's razor effect of >simplifying this >stuff. >Please let me know if these are adequate or what you would change. I would >encourage >others to try and reduce the problem statements to a single sentence. Maybe >then we >could build an optimized synthesized single statement problem statement or >perhaps >a power paragraph? From owner-seamoby@diameter.org Thu Feb 1 21:17:24 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17115 for ; Thu, 1 Feb 2001 21:17:24 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f120eLH14572 for seamoby-list; Thu, 1 Feb 2001 16:40:21 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f120eHo14567 for ; Thu, 1 Feb 2001 16:40:18 -0800 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 f11NmLC03956 for ; Fri, 2 Feb 2001 00:48:21 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Feb 02 00:48:21 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id <1CVMW1DS>; Fri, 2 Feb 2001 00:48:21 +0100 Message-ID: <034BEFD03799D411A59F00508BDF75465B6961@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: seamoby@diameter.org Subject: RE: [seamoby] Single sentence problem statements Date: Fri, 2 Feb 2001 00:48:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-seamoby@diameter.org Precedence: bulk I haven't been following every mail in the discussion. I've looked through the achives though, but I apologise if I'm bringing up comments that were already discussed. Having said that here are some questions below. I'd appreciate your answers. > Micro-mobility Problem Statement > ====================================================================== > To avoid extraneous latency and signalling overhead caused by > MIP, > => Signalling latency and overhead have essentially been reduced by HMIPv6 for MIPv6 and regional registrations for MIPv4. This is done by introducing local agents (MAP and GFA) to manage the MN's mobility within the MAP/GFA domain. I would refer to these drafts as part of MIP or extensions to it. Was your intention to separate them from MIP ? or do you not think that they solve this problem ? > a light weight micro-mobility protocol running on the edges > of the global Internet is required for handovers that do not > require an updated MIP COA. > => Ok I'll talk about IPv6 because I just like it more :) If you're changing your L3 attachment point or default router, then you are expected to get a new COA. If you're moving within one subnet, you are obviously keeping your COA. So IP mobility takes place when you change your COA. Is this a proposal for nodes that do change their L3 attachment point but keep a topologically incorrect address ? or is it an attempt to manage mobility within "a" subnet ? I guess my question is: should we consider handovers that do not require a change in COA IP handovers ? Thanks Hesham From owner-seamoby@diameter.org Thu Feb 1 21:50:10 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA18357 for ; Thu, 1 Feb 2001 21:50:08 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f121GKu14614 for seamoby-list; Thu, 1 Feb 2001 17:16:20 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f121GFo14609 for ; Thu, 1 Feb 2001 17:16:16 -0800 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 f120OKd07520 for ; Fri, 2 Feb 2001 01:24:20 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Fri Feb 02 01:24:19 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id <1CVMW1KD>; Fri, 2 Feb 2001 01:24:20 +0100 Message-ID: <034BEFD03799D411A59F00508BDF75465B6963@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'seamoby@cdma-2000.org'" Cc: "Hesham Soliman (ERA)" Subject: FW: [seamoby] Single sentence problem statements Date: Fri, 2 Feb 2001 01:24:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-seamoby@diameter.org Precedence: bulk Sorry if you receive multiple copies, the first mails seems to have disappeared > > I haven't been following every mail in the discussion. I've looked > through the achives though, but I apologise if I'm bringing up comments > that were already discussed. Having said that here are some questions > below. I'd appreciate your answers. > > > Micro-mobility Problem Statement > ====================================================================== > To avoid extraneous latency and signalling overhead caused by > MIP, > > => Signalling latency and overhead have essentially been reduced > by HMIPv6 for MIPv6 and regional registrations for MIPv4. > This is done by introducing local agents (MAP and GFA) to manage > the MN's mobility within the MAP/GFA domain. > I would refer to these drafts as part of MIP or extensions to it. Was your > intention to separate them from MIP ? or do you not think that they > solve this problem ? > > a light weight micro-mobility protocol running on the edges > of the global Internet is required for handovers that do not > require an updated MIP COA. > > => Ok I'll talk about IPv6 because I just like it more :) > If you're changing your L3 attachment point or default > router, then you are expected to get a new COA. If you're > moving within one subnet, you are obviously keeping your > COA. So IP mobility takes place when you change your > COA. > Is this a proposal for nodes that do change their L3 attachment > point but keep a topologically incorrect address ? > or is it an attempt to manage mobility within "a" subnet ? > > I guess my question is: should we consider handovers that > do not require a change in COA IP handovers ? > > > Thanks > Hesham > > From owner-seamoby@diameter.org Fri Feb 2 00:56:06 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA20823 for ; Fri, 2 Feb 2001 00:56:06 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f124mok15040 for seamoby-list; Thu, 1 Feb 2001 20:48:50 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from sirius.ctr.columbia.edu (sirius.ctr.columbia.edu [128.59.64.60]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f124mlo15035 for ; Thu, 1 Feb 2001 20:48:47 -0800 Received: from coltrane (coltrane.ocs.columbia.edu [128.59.240.174]) by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with SMTP id WAA03402; Thu, 1 Feb 2001 22:56:44 -0500 (EST) From: "Andrew T. Campbell" To: , Subject: RE: [seamoby] Single sentence problem statements Date: Thu, 1 Feb 2001 23:07:58 -0500 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: <882569E6.0070706E.00@hqoutbound.ops.3com.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit I like these. Short and to the point. > -----Original Message----- > From: owner-seamoby@diameter.org [mailto:owner-seamoby@diameter.org]On > Behalf Of Phil_Neumiller@3Com.com > Sent: Thursday, February 01, 2001 3:24 PM > To: seamoby@diameter.org > Subject: [seamoby] Single sentence problem statements > > > > > The SeaMoby chartered problems stated in single sentences. > > Micro-mobility Problem Statement > ====================================================================== > To avoid extraneous latency and signalling overhead caused by > MIP, a light weight micro-mobility protocol running on the edges > of the global Internet is required for handovers that do not > require an updated MIP COA. > > Context Transfer Problem Statement > ====================================================================== > To preserve the MN context during handover, a reliable mechanism to > transfer and negotiate MN connection/micro-flow state is required. > > Paging Problem Statement (1 sentence) > ====================================================================== > Most of today's wireless systems use link layer methods for paging, > however, it is desired to create a layer 3 IP-based method to > notify a MN of a network event requiring the MN's attention. > > The single sentence exercise has a nice Occam's razor effect of > simplifying this > stuff. > Please let me know if these are adequate or what you would > change. I would > encourage > others to try and reduce the problem statements to a single > sentence. Maybe > then we > could build an optimized synthesized single statement problem statement or > perhaps > a power paragraph? > > > From owner-seamoby@diameter.org Fri Feb 2 04:20:22 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA05242 for ; Fri, 2 Feb 2001 04:20:21 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f128G4L15282 for seamoby-list; Fri, 2 Feb 2001 00:16:04 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from porsta.cs.Helsinki.FI (root@porsta.cs.Helsinki.FI [128.214.48.124]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f128FCo15277 for ; Fri, 2 Feb 2001 00:15:12 -0800 Received: from melkinpaasi.cs.Helsinki.FI (jmanner@melkinpaasi.cs.Helsinki.FI [128.214.10.13]) by porsta.cs.Helsinki.FI (8.8.8/8.8.8) with ESMTP id JAA07329; Fri, 2 Feb 2001 09:23:06 +0200 Date: Fri, 2 Feb 2001 09:23:04 +0200 (EET) From: Jukka Manner To: cc: Subject: Re: [seamoby] Re: New name -> Seamless to become Hidden Handover?? In-Reply-To: <882569E6.005D6FB0.00@hqoutbound.ops.3com.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk Hi, On Thu, 1 Feb 2001 Phil_Neumiller@3Com.com wrote: > > A HiHo handover deals mainly with QoS, so to an application and its > > pdn>Wherever did you get this fixation on QoS? IMHO, a HiHo is the epitome > pdn>of handovers combining all desirable qualities including QoS. > Notice the word "mainly"... Anyway, if QoS weren't such a big deal, we wouldn't have nearly such a big problem as the CT team is/will be having. > flows a HiHo should not be seen. But if a HiHo is also a Vertical handover and > the IP layer's network interface changes, ie. a HO from a 3G network to a WLAN, > the HO is noticed, at least the user will see this. > > pdn>If its a vertical HO, and the COA must change, it is no longer a HiHo or > pdn>a concern of SeaMoby MM (however SeaMoby CT is still interested). This is > pdn>my understanding of the SeaMoby boundaries, i.e. Micro-mobility is invoked > pdn>when COA does not change, and CT controlled by either Macro or Micro mobility > pdn>will always be invoked in some manner. > True, that Seamoby MM might not be interested, but CT team is definitely interested: Context transfer deals with change of ARs, independent of whether the link layer technology changes or not (or might be part of a CT, but does not limit it). But isn't an inter-technology HO, that still maintains the context of the MH a HiHo? If we do a HO from some 3G tech to WLAN and keep the QoS, wouldn't that still be a HiHo? Or do we need a new term to define that HO: "Context-aware" HO: context+seamless+including inter-tech ? > Take it easy, > > pdn You too, :) Jukka From owner-seamoby@diameter.org Fri Feb 2 07:32:03 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA06505 for ; Fri, 2 Feb 2001 07:31:53 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f12BRq915533 for seamoby-list; Fri, 2 Feb 2001 03:27:52 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from www.amcc.com.cn ([202.102.193.110]) by charizard.diameter.org (8.10.0/8.10.0) with SMTP id f12BQXo15524 for ; Fri, 2 Feb 2001 03:26:33 -0800 Received: (qmail 13699 invoked by uid 101); 1 Feb 2001 01:49:11 -0000 Received: from unknown (HELO aol.com) (unknown) by unknown with SMTP; 1 Feb 2001 01:49:11 -0000 From: Subject: [seamoby] Buying a home? Self employed? Hard to qualify? 1246 Date: Wed, 31 Jan 2001 20:33:56 Message-Id: <626.396320.30609@aol.com> Reply-To: homeloan013101@aol.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-seamoby@diameter.org Precedence: bulk WE SOLVE MORTGAGE PROBLEMS !!! Specializing in loans for exceptional people Self-Employed Borrowers No Income or Asset Verification All Levels of Credit Quality Up to 100% Financing High Debt Ratios Non-Owner Occupied Properties Renovation Plus Purchase and Refinance $UPER $OLUTION$ ......... $UPER RE$ULT$ If you would like additional information please email us at wed1111@excite.com?Subject=MoreInformation Help a family member or a friend with their home loan needs by FORWARDING THIS EMAIL TO THEM! An Equal Housing Opportunity Lender If you wish to be removed from this advertiser's future mailings, please reply with the subject "Remove" and this software will automatically block you from their future mailings. From owner-seamoby@diameter.org Fri Feb 2 12:52:03 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18173 for ; Fri, 2 Feb 2001 12:52:01 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f12GZ2t16148 for seamoby-list; Fri, 2 Feb 2001 08:35:02 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from zcars04e (h56s242a129n47.user.nortelnetworks.com [47.129.242.56]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f12GYxo16143 for ; Fri, 2 Feb 2001 08:34:59 -0800 Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e; Fri, 2 Feb 2001 10:41:13 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id ; Fri, 2 Feb 2001 10:41:13 -0500 Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8BFA@zwdld001.ca.nortel.com> From: "Gary Kenward" To: "'Jukka Manner'" , seamoby_context@standards.nortelnetworks.com Cc: Seamoby Working Group Subject: RE: [seamoby] Re: draft-brain-seamoby-terms-00.txt Date: Fri, 2 Feb 2001 10:41:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08D2E.8CAA31B0" X-Orig: Sender: owner-seamoby@diameter.org Precedence: bulk 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_01C08D2E.8CAA31B0 Content-Type: text/plain; charset="ISO-8859-1" Jukka: Comments inserted.... Gary > -----Original Message----- > From: Jukka Manner [mailto:jmanner@cs.helsinki.fi] > Sent: Thursday, February 01, 2001 7:00 AM > To: seamoby_context@standards.nortelnetworks.com > Cc: Seamoby Working Group > Subject: [seamoby] Re: draft-brain-seamoby-terms-00.txt > > > > Gary, > > Here are some (late) answers to your comments. I copy > this to the main > Cmoby list to raise more discussion on the terminology of the draft. > > Regards, > > Jukka > > On Thu, 18 Jan 2001, Gary Kenward wrote: > > > Overall, I liked this draft, and the clarity and logic of > the definitions. > > It goes beyond what we need for the CT problem statement, and so we > > must be cautious not to rat-hole on issues such as paging. > Hopefully, > > appropriate selections will be made in the problem statement draft > > that Henrik is leading. > > The draft was intended for the whole Seamoby WG, so > part of it is > truly not needed in CT discussions. Hopefully the whole WG > will benefit > from it. > > > > > Some specific comments/concerns: > > > > p5: section 2.2.2, Layer 2 handovers are not necessarily > intra-technology. I > > have > > misplaced the announcement, but at least one company is > working on dual mode > > devices that will switch between Bluetooth and 802.11 > without involving the > > IP layer. > > True. Perhaps we should then just change "necessarily" > to "typically". > > > > > p5: section 2.2.2, I did not understand the discussion on > Horizontal and > > Vertical handover, and in particular how these definitions > mapped onto the > > architecture. I'm probably missing some key IETF > nomenclature here, but if you > > would help > > me out, and explain the relationship between Horizontal and Vertical > > handover > > and inter- and intra- AR handover. If there is no > relationship, then one of > > the > > definitions would seem to be redundant. > > > > We try to see the handover event from the IP POV. When > the interface on > the IP layer does not change, we can think that a pure layer > 2 handover > happened, which remained (partially) unnoticed at the IP > layer. This was called > horizontal. When the network interface clearly changes at the > IP layer, we > called this vertical handover. The definitions come from > discussions on what to > call handovers between different link layers. In future > wireless communications, > a MH can do handovers from UMTS to GPRS to blue tooth to WLAN to > any-network-you-like. Previously those were called vertical > and horizontal > (change of link layer vs. no change in link layer). We tried > to adopt those and > look at them from the IP POV. These are the definitions that I am familiar with. They need to be expanded upon in your document, for clarity. I'm still not sure how this impacts the Seamoby solution, but then, we don't have a solution yet and it is worth capturing. > > The handover terms defined in 2.2.1 and 2.2.2 are > related to the context > of discussions. They define somewhat similar handovers, but > for clarity and to > provide less room for misunderstanding, we have defined that many. > > In the definition of "Horizontal" we must replace "OAR and > NAR" with "AN". > > > > p6: I do not agree that a planned handover is generally a > result of backward > > handover. The definition of planned handover does not suffer if this > > sentence > > is removed. > > Should we say that "planned assumes backward" - would that be > enough? I'm not > sure whether a NAR can be chosen and be active to initiate > the handover. > Wouldn't choosing a NAR be part of the handover procedure? My point was that it is not necessary to tie the two definitions together. Doing so presumes a certain solution set. > > > > p6: "planned" vs. "unplanned" don't work for me. they have > a connotation of > > long term, slow. I'm not sure why you chose not to use > "proactive" and > > "reactive", > > and introduced "planned" and "unplanned" - the latter terms > don't really add > > to the meaning. (one could be trite and say that a > "reactive" handover could > > be planned). > > To us this was a matter of taste. In the "literature", they are used > synonymously. Maybe so, but we should stick to one set of terms, and as an earlier email discussion, the group agreed on the use of proactive and reactive. (at least implicitly). "planned" still sounds like "provisioned" to me, but that's just my connotation. > > > > p7: I am not comfortable with the definition of Seamless, > in that if it is > > really simply > > the combination of smooth and fast, then it is already > being done in MIP. I > > see > > Seamless as being handover with no (discernable) drop in > QoS. This is both > > semantically and practically different from smooth+fast. > > Actually, if we then start using "seamless", we have to > specify whether we > mean "mobileip-seamless" or "seamoby-seamless" because the term has a > "well-known" meaning in mobileip. > > We would assume that "being done in MIP" means "being tackled > in mobileip WG", > i.e., refers to the fast handover proposals. (nevertheless, > the fact that > something is being done in mobileip means extensions to MIP > that are not > necessarily straightforwardly applicable to seamoby) > > Would we need another handover type then to include the idea > of supporting QoS. > So, a "QoS (and/or context) aware" handover? *sigh*. The result of approaching mobility incrementally, from the core to the edge. Do we "really" need 5 types of handover at the IP layer? (in addition to soft, hard, etc., etc. at L2). IMHO: we are the Seamless Mobility working group, and we get to define what we mean by seamless. since our definition is an enhancement to the MIP definition (and actually is a new service, not just fast + smooth), I don't see a problem, as long as we clearly state what seamless means to us. > > > p.7: You have introduced the concept of "context aware". I > don't think we > > need yet > > another handover type. In my mind, context aware was part > of seamless. Now, > > given your definition of seamless, yes, there is context > that goes beyond > > smooth+fast, > > and indeed goes beyond sustained QoS. Of course, we can > define SeaMoby to be > > seamless + context aware, but now we have a 5 types of > handover (including > > the > > non-smooth, non-fast, non-context aware case). Would it not > be better to > > define > > seamless as being context aware? Or, even better, as being context > > sustaining? > > > > I can see that we have two types of definitions for seamlessness: > > "Cmless"=seamless+context+everything > > or > > "Cmless"=fast+no-packet-drops > > Since the MIP people have already a definition for seamless, > I don't think we > should make a new one, but perhaps define a new type that > includes the notion of > sustaining the QoS. Would "QoS (aware) handover" be a bad term? See above.... > > > p8: I don't want to open a discussion of paging on this > mailing list, so as > > a short note > > to be taken to the paging mailing list, I don't believe > that paging itself > > should do all > > that you imply. There should be an intermediate stage > between a paging > > wake-up and > > establishment of a SAR. > > True. But I'm not the right person to comment on that issue. > Anyone want to add > more insight to this? > > > > > p8:, section 2.5: The distinguishment you make between user > and personal > > mobility > > seems to have more to do with whether push applications are > possible. From > > the appendices, > > I gather that the definition came from the telecom arena, > and is biased (or > > limited) > > accordingly. Also, the essence of this definition seems to > be tracking of > > the user, which > > is outside the scope of SeaMob. > > Yes, we tried to emphasize that these are defined in order to > be able to > describe what is not in scope (L2 handover and similar might > also be augmented > with such remarks). > > > Regards > > Gary > > > > ------_=_NextPart_001_01C08D2E.8CAA31B0 Content-Type: text/html; charset="ISO-8859-1" RE: [seamoby] Re: draft-brain-seamoby-terms-00.txt

Jukka:

  Comments inserted....

Gary

> -----Original Message-----
> From: Jukka Manner [mailto:jmanner@cs.helsinki.fi]
> Sent: Thursday, February 01, 2001 7:00 AM
> To: seamoby_context@standards.nortelnetworks.com
> Cc: Seamoby Working Group
> Subject: [seamoby] Re: draft-brain-seamoby-terms-00.txt
>
>
>
>       Gary,
>
>       Here are some (late) answers to your comments. I copy
> this to the main
> Cmoby list to raise more discussion on the terminology of the draft.
>
>       Regards,
>
>       Jukka
>
> On Thu, 18 Jan 2001, Gary Kenward wrote:
>
> > Overall, I liked this draft, and the clarity and logic of
> the definitions.
> > It goes beyond what we need for the CT problem statement, and so we
> > must be cautious not to rat-hole on issues such as paging.
> Hopefully,
> > appropriate selections will be made in the problem statement draft
> > that Henrik is leading.
>
>       The draft was intended for the whole Seamoby WG, so
> part of it is
> truly not needed in CT discussions. Hopefully the whole WG
> will benefit
> from it.
>
> >
> > Some specific comments/concerns:
> >
> > p5: section 2.2.2, Layer 2 handovers are not necessarily
> intra-technology. I
> > have
> > misplaced the announcement, but at least one company is
> working on dual mode
> > devices that will switch between Bluetooth and 802.11
> without involving the
> > IP layer.
>
>       True. Perhaps we should then just change "necessarily"
> to "typically".
>
> >
> > p5: section 2.2.2, I did not understand the discussion on
> Horizontal and
> > Vertical handover, and in particular how these definitions
> mapped onto the
> > architecture. I'm probably missing some key IETF
> nomenclature here, but if you
> > would help
> > me out, and explain the relationship between Horizontal and Vertical
> > handover
> > and inter- and intra- AR handover. If there is no
> relationship, then one of
> > the
> > definitions would seem to be redundant.
> >
>
>       We try to see the handover event from the IP POV. When
> the interface on
> the IP layer does not change, we can think that a pure layer
> 2 handover
> happened, which remained (partially) unnoticed at the IP
> layer. This was called
> horizontal. When the network interface clearly changes at the
> IP layer, we
> called this vertical handover. The definitions come from
> discussions on what to
> call handovers between different link layers. In future
> wireless communications,
> a MH can do handovers from UMTS to GPRS to blue tooth to WLAN to
> any-network-you-like. Previously those were called vertical
> and horizontal
> (change of link layer vs. no change in link layer). We tried
> to adopt those and
> look at them from the IP POV.

These are the definitions that I am familiar with. They need to
be expanded upon in your document, for clarity. I'm still not sure
how this impacts the Seamoby solution, but then, we don't have a solution
yet and it is worth capturing.

>
>       The handover terms defined in 2.2.1 and 2.2.2 are
> related to the context
> of discussions. They define somewhat similar handovers, but
> for clarity and to
> provide less room for misunderstanding, we have defined that many.
>
> In the definition of "Horizontal" we must replace "OAR and
> NAR" with "AN".
>
>
> > p6: I do not agree that a planned handover is generally a
> result of backward
> > handover. The definition of planned handover does not suffer if this
> > sentence
> > is removed.
>
> Should we say that "planned assumes backward" - would that be
> enough? I'm not
> sure whether a NAR can be chosen and be active to initiate
> the handover.
> Wouldn't choosing a NAR be part of the handover procedure?

My point was that it is not necessary to tie the two definitions together.
Doing so presumes a certain solution set.

>
>
> > p6: "planned" vs. "unplanned" don't work for me. they have
> a connotation of
> > long term, slow. I'm not sure why you chose not to use
> "proactive" and
> > "reactive",
> > and introduced "planned" and "unplanned" - the latter terms
> don't really add
> > to the meaning. (one could be trite and say that a
> "reactive" handover could
> > be planned).
>
> To us this was a matter of taste. In the "literature", they are used
> synonymously.

Maybe so, but we should stick to one set of terms, and as an earlier
email discussion, the group agreed on the use of proactive and reactive.
(at least implicitly).

"planned" still sounds like "provisioned" to me, but that's just my
connotation.

>
>
> > p7: I am not comfortable with the definition of Seamless,
> in that if it is
> > really simply
> > the combination of smooth and fast, then it is already
> being done in MIP. I
> > see
> > Seamless as being handover with no (discernable) drop in
> QoS. This is both
> > semantically and practically different from smooth+fast.
>
> Actually, if we then start using "seamless", we have to
> specify whether we
> mean "mobileip-seamless" or "seamoby-seamless" because the term has a
> "well-known" meaning in mobileip.
>
> We would assume that "being done in MIP" means "being tackled
> in mobileip WG",
> i.e., refers to the fast handover proposals. (nevertheless,
> the fact that
> something is being done in mobileip means extensions to MIP
> that are not
> necessarily straightforwardly applicable to seamoby)
>
> Would we need another handover type then to include the idea
> of supporting QoS.
> So, a "QoS (and/or context) aware" handover?

*sigh*. The result of approaching mobility incrementally, from the core
to the edge. Do we "really" need 5 types of handover at the IP layer?
(in addition to soft, hard, etc., etc. at L2).

IMHO: we are the Seamless Mobility working group, and we get to
define what we mean by seamless. since our definition is an enhancement
to the MIP definition (and actually is a new service, not just fast + smooth),
I don't see a problem, as long as we clearly state what seamless means
to us.

>
> > p.7: You have introduced the concept of "context aware". I
> don't think we
> > need yet
> > another handover type. In my mind, context aware was part
> of seamless. Now,
> > given your definition of seamless, yes, there is context
> that goes beyond
> > smooth+fast,
> > and indeed goes beyond sustained QoS. Of course, we can
> define SeaMoby to be
> > seamless + context aware, but now we have a 5 types of
> handover (including
> > the
> > non-smooth, non-fast, non-context aware case). Would it not
> be better to
> > define
> > seamless as being context aware? Or, even better, as being context
> > sustaining?
> >
>
> I can see that we have two types of definitions for seamlessness:
>
> "Cmless"=seamless+context+everything
>
> or
>
> "Cmless"=fast+no-packet-drops
>
> Since the MIP people have already a definition for seamless,
> I don't think we
> should make a new one, but perhaps define a new type that
> includes the notion of
> sustaining the QoS. Would "QoS (aware) handover" be a bad term?

See above....

>
> > p8: I don't want to open a discussion of paging on this
> mailing list, so as
> > a short note
> > to be taken to the paging mailing list, I don't believe
> that paging itself
> > should do all
> > that you imply. There should be an intermediate stage
> between a paging
> > wake-up and
> > establishment of a SAR.
>
> True. But I'm not the right person to comment on that issue.
> Anyone want to add
> more insight to this?
>
> >
> > p8:, section 2.5: The distinguishment you make between user
> and personal
> > mobility
> > seems to have more to do with whether push applications are
> possible. From
> > the appendices,
> > I gather that the definition came from the telecom arena,
> and is biased (or
> > limited)
> > accordingly. Also, the essence of this definition seems to
> be tracking of
> > the user, which
> > is outside the scope of SeaMob.
>
> Yes, we tried to emphasize that these are defined in order to
> be able to
> describe what is not in scope (L2 handover and similar might
> also be augmented
> with such remarks).
>
> > Regards
> > Gary
> >
>
>

------_=_NextPart_001_01C08D2E.8CAA31B0-- From owner-seamoby@diameter.org Fri Feb 2 12:52:06 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18156 for ; Fri, 2 Feb 2001 12:51:53 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f12G9pY16082 for seamoby-list; Fri, 2 Feb 2001 08:09:51 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f12G9mo16077 for ; Fri, 2 Feb 2001 08:09:48 -0800 Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 2 Feb 2001 10:14:05 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id ; Fri, 2 Feb 2001 10:14:05 -0500 Message-ID: From: "Hongyi Li" To: "'Hesham Soliman (ERA)'" , seamoby@diameter.org Subject: RE: [seamoby] Single sentence problem statements Date: Fri, 2 Feb 2001 10:13:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08D2A.C5016640" X-Orig: Sender: owner-seamoby@diameter.org Precedence: bulk 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_01C08D2A.C5016640 Content-Type: text/plain; charset="ISO-8859-1" Hesham, > ====================================================================== > > To avoid extraneous latency and signalling overhead caused by > > MIP, > > > => Signalling latency and overhead have essentially > been reduced > by HMIPv6 for MIPv6 and regional registrations for MIPv4. > This is done by introducing local agents (MAP and GFA) to manage > the MN's mobility within the MAP/GFA domain. > I would refer to these drafts as part of MIP or > extensions to it. Was your > intention to separate them from MIP ? or do you not > think that they > solve this problem ? The issue here is not only "solving the problem" but also "solving it in a right way". -Hongyi ------_=_NextPart_001_01C08D2A.C5016640 Content-Type: text/html; charset="ISO-8859-1" RE: [seamoby] Single sentence problem statements

Hesham,


> ======================================================================
> > To avoid extraneous latency and signalling overhead caused by
> > MIP,
> >
>       => Signalling latency and overhead have essentially
> been reduced
>       by HMIPv6 for MIPv6 and regional registrations for MIPv4.
>       This is done by introducing local agents (MAP and GFA) to manage
>       the MN's mobility within the MAP/GFA domain.
>       I would refer to these drafts as part of MIP or
> extensions to it. Was your
>       intention to separate them from MIP ? or do you not
> think that they
>       solve this problem ?

The issue here is not only "solving the problem" but also
"solving it in a right way".

-Hongyi


------_=_NextPart_001_01C08D2A.C5016640-- From owner-seamoby@diameter.org Fri Feb 2 12:52:10 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18203 for ; Fri, 2 Feb 2001 12:52:09 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f12GFD716109 for seamoby-list; Fri, 2 Feb 2001 08:15:13 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f12GFAo16104 for ; Fri, 2 Feb 2001 08:15:10 -0800 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 f12FNId25017 for ; Fri, 2 Feb 2001 16:23:19 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Fri Feb 02 16:23:52 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id <1CVZMH67>; Fri, 2 Feb 2001 16:19:31 +0100 Message-ID: <034BEFD03799D411A59F00508BDF75465B696C@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Hongyi Li'" , seamoby@diameter.org Subject: RE: [seamoby] Single sentence problem statements Date: Fri, 2 Feb 2001 16:22:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-seamoby@diameter.org Precedence: bulk > > ====================================================================== > > > To avoid extraneous latency and signalling overhead caused by > > > MIP, > > > > > => Signalling latency and overhead have essentially > > been reduced > > by HMIPv6 for MIPv6 and regional registrations for MIPv4. > > This is done by introducing local agents (MAP and GFA) to manage > > the MN's mobility within the MAP/GFA domain. > > I would refer to these drafts as part of MIP or > > extensions to it. Was your > > intention to separate them from MIP ? or do you not > > think that they > > solve this problem ? > > The issue here is not only "solving the problem" but also > "solving it in a right way". > => Agreed. .. fully, but what is wrong about the above ? Shouldn't this be part of the problem statement. Perhaps it was discussed before ? I would appreciate a reference if it was. Hesham From owner-seamoby@diameter.org Fri Feb 2 13:04:39 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19211 for ; Fri, 2 Feb 2001 13:04:38 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f12GAhm16099 for seamoby-list; Fri, 2 Feb 2001 08:10:43 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f12GAfo16094 for ; Fri, 2 Feb 2001 08:10:41 -0800 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 HAA15202; Fri, 2 Feb 2001 07:18:56 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT14895; Fri, 2 Feb 2001 07:18:44 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA00021; Fri, 2 Feb 2001 07:18:44 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14970.53204.422095.499231@thomasm-u1.cisco.com> Date: Fri, 2 Feb 2001 07:18:44 -0800 (PST) To: "Phil Neumiller" Cc: "Jukka Manner" , "Seamoby Context Transfer Design Team" , "Seamoby Working Group" Subject: [seamoby] New name -> Seamless to become Hidden Handover?? In-Reply-To: <003601c08c5b$34927560$6501a8c0@philneum> References: <003601c08c5b$34927560$6501a8c0@philneum> 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-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Phil Neumiller writes: > How about HIDDEN handover? You are correct. Seamless is already overloaded > all over the place. I like HIDDEN handover because it conveys what we are > trying > to do, i.e. have no user noticeable changes during handovers. The handover > is also > "hidden" from MIP so it is like a two edged sword. Cool acronym too: HiHo, > HiHo... Phil, While I might be persuaded that there are reasons for a hidden handover, and whatever else comes of this you may not claim Bashful as your HiHo name, I think that hidden handoff places too much emphasis on transparency. A mobile node may not want to participate in transparent moves, but then again it may very well want to control them or know about them, even if the move only generates localized signaling. As such, I think that HiHo is just a subset of the entire problem. And with this, it's off to work I go. Mike From owner-seamoby@diameter.org Fri Feb 2 13:20:39 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20105 for ; Fri, 2 Feb 2001 13:20:38 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f12Goo416183 for seamoby-list; Fri, 2 Feb 2001 08:50:51 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from zcars04e (h56s242a129n47.user.nortelnetworks.com [47.129.242.56]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f12GnXo16178 for ; Fri, 2 Feb 2001 08:49:33 -0800 Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e; Fri, 2 Feb 2001 10:53:20 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id ; Fri, 2 Feb 2001 10:53:20 -0500 Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8BFB@zwdld001.ca.nortel.com> From: "Gary Kenward" To: "'Jukka Manner'" , Phil_Neumiller Cc: seamoby Subject: RE: [seamoby] Re: New name -> Seamless to become Hidden Handover? ? Date: Fri, 2 Feb 2001 10:53:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08D30.407C79E0" X-Orig: Sender: owner-seamoby@diameter.org Precedence: bulk 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_01C08D30.407C79E0 Content-Type: text/plain; charset="ISO-8859-1" comments inserted.... > -----Original Message----- > From: Jukka Manner [mailto:jmanner@cs.helsinki.fi] > Sent: Friday, February 02, 2001 2:23 AM > To: Phil_Neumiller > Cc: seamoby > Subject: Re: [seamoby] Re: New name -> Seamless to become Hidden > Handover?? > > > > Hi, > > On Thu, 1 Feb 2001 Phil_Neumiller@3Com.com wrote: > > > > A HiHo handover deals mainly with QoS, so to an > application and its > > > > pdn>Wherever did you get this fixation on QoS? IMHO, a > HiHo is the epitome > > pdn>of handovers combining all desirable qualities including QoS. > > I probably should have said "service" or "quality of service", without the capitals. From a users perspective, there is a service (http + IPSec for secure www browsing for example), and there is the quality with which that service is provided. So, in order to end this micro-debate, let's substitute "context" for "QoS", and define (as we have been) context (e.g. QoS, security, etc.). > > Notice the word "mainly"... Anyway, if QoS weren't such > a big deal, we > wouldn't have nearly such a big problem as the CT team > is/will be having. If QoS weren't such a big deal, we would have only BE and any old handover mechanism that took less then 1/2 sec and dropped fewer the 1% of the packets would do.... (these are the rough thresholds where TCP starts to act up) > > > flows a HiHo should not be seen. But if a HiHo is also a > Vertical handover and HiHo, HiHo, it's off to work we go... I feel like I'm in a Disney movie. We don't need a new term. seamless works fine enough. > > the IP layer's network interface changes, i.e.. a HO from a > 3G network to a WLAN, > > the HO is noticed, at least the user will see this. > > > > pdn>If its a vertical HO, and the COA must change, it is no No. As I pointed out to Jukka, a COA will change only if the veridical handoff is inter-network. There are real scenarios where the vertical handoff is intra-network. > longer a HiHo or > > pdn>a concern of SeaMoby MM (however SeaMoby CT is still > interested). This is > > pdn>my understanding of the SeaMoby boundaries, i.e. > Micro-mobility is invoked > > pdn>when COA does not change, and CT controlled by either > Macro or Micro mobility > > pdn>will always be invoked in some manner. > > > > True, that Seamoby MM might not be interested, but CT > team is definitely > interested: Context transfer deals with change of ARs, > independent of whether > the link layer technology changes or not (or might be part of > a CT, but does not > limit it). > > But isn't an inter-technology HO, that still maintains > the context of > the MH a HiHo? If we do a HO from some 3G tech to WLAN and > keep the QoS, > wouldn't that still be a HiHo? Or do we need a new term to > define that HO: > > "Context-aware" HO: context+seamless+including inter-tech ? The purpose of these definitions is to map out the problem space clearly enough for ourselves and the IETF to understand what it is we want to work on. The definitions will never be linear, complete, and closed. And we will be here forever if we attempt to make them so. What we do need to be careful about, is ensuring that the definitions are not redundant, nor contradictory, nor co-dependent. Put another way, we need to describe the complex problem space by identifying and defining a sparse set of independent definitions. Gary > > > Take it easy, > > > > pdn > > > You too, :) > > > Jukka > > ------_=_NextPart_001_01C08D30.407C79E0 Content-Type: text/html; charset="ISO-8859-1" RE: [seamoby] Re: New name -> Seamless to become Hidden Handover??

comments inserted....

> -----Original Message-----
> From: Jukka Manner [mailto:jmanner@cs.helsinki.fi]
> Sent: Friday, February 02, 2001 2:23 AM
> To: Phil_Neumiller
> Cc: seamoby
> Subject: Re: [seamoby] Re: New name -> Seamless to become Hidden
> Handover??
>
>
>
>       Hi,
>
> On Thu, 1 Feb 2001 Phil_Neumiller@3Com.com wrote:
> >
> >         A HiHo handover deals mainly with QoS, so to an
> application and its
> >
> > pdn>Wherever did you get this fixation on QoS?  IMHO, a
> HiHo  is the epitome
> > pdn>of handovers combining all desirable qualities including QoS.
> >

I probably should have said "service" or "quality of service",
without the capitals. From a users perspective, there is a service
(http + IPSec for secure www browsing for example), and there
is the quality with which that service is provided.

So, in order to end this micro-debate, let's substitute "context"
for "QoS", and define (as we have been) context (e.g. QoS, security,
etc.).

>
>       Notice the word "mainly"... Anyway, if QoS weren't such
> a big deal, we
> wouldn't have nearly such a big problem as the CT team
> is/will be having.

If QoS weren't such a big deal, we would have only BE and
any old handover mechanism that took less then 1/2 sec and
dropped fewer the 1% of the packets would do....

(these are the rough thresholds where TCP starts to act up)

>
> > flows a HiHo should not be seen. But if a HiHo is also a
> Vertical handover and

HiHo, HiHo, it's off to work we go...

I feel like I'm in a Disney movie. We don't need a new term.
seamless works fine enough.

> > the IP layer's network interface changes, i.e.. a HO from a
> 3G network to a WLAN,
> > the HO is noticed, at least the user will see this.
> >
> > pdn>If its a vertical HO, and the COA must change, it is no

No. As I pointed out to Jukka, a COA will change only if the
veridical handoff is inter-network. There are real scenarios where
the vertical handoff is intra-network.

> longer a HiHo or
> > pdn>a concern of SeaMoby MM (however SeaMoby CT is still
> interested).  This is
> > pdn>my understanding of the SeaMoby boundaries, i.e.
> Micro-mobility is invoked
> > pdn>when COA does not change, and CT controlled by either
> Macro or Micro mobility
> > pdn>will always be invoked in some manner.
> >
>
>       True, that Seamoby MM might not be interested, but CT
> team is definitely
> interested: Context transfer deals with change of ARs,
> independent of whether
> the link layer technology changes or not (or might be part of
> a CT, but does not
> limit it).
>
>       But isn't an inter-technology HO, that still maintains
> the context of
> the MH a HiHo? If we do a HO from some 3G tech to WLAN and
> keep the QoS,
> wouldn't that still be a HiHo? Or do we need a new term to
> define that HO:
>
> "Context-aware" HO: context+seamless+including inter-tech ?

The purpose of these definitions is to map out the problem space
clearly enough for ourselves and the IETF to understand what it is
we want to work on.

The definitions will never be linear, complete, and closed. And we will
be here forever if we attempt to make them so. What we do need to
be careful about, is ensuring that the definitions are not redundant,
nor contradictory, nor co-dependent.

Put another way, we need to describe the complex problem space by
identifying and defining a sparse set of independent definitions.

Gary

>
> > Take it easy,
> >
> > pdn
>
>
>       You too, :)
>
>
>       Jukka
>
>

------_=_NextPart_001_01C08D30.407C79E0-- From owner-seamoby@diameter.org Fri Feb 2 18:27:15 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04849 for ; Fri, 2 Feb 2001 18:27:12 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f12M00B16665 for seamoby-list; Fri, 2 Feb 2001 14:00:00 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f12Lxwo16655 for ; Fri, 2 Feb 2001 13:59:58 -0800 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA16375; Fri, 2 Feb 2001 13:07:55 -0800 (PST) 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 NAA13330; Fri, 2 Feb 2001 13:07:54 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id NAA05103; Fri, 2 Feb 2001 13:07:42 -0800 (PST) Date: Fri, 2 Feb 2001 13:07:43 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: RE: [seamoby] Single sentence problem statements To: Phil_Neumiller@3Com.com Cc: "Hesham Soliman (ERA)" , seamoby@diameter.org In-Reply-To: "Your message with ID" <882569E7.00719294.00@hqoutbound.ops.3com.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk > > 1). There is a concern that A GFA/FA in every AP may not scale or even > be desirable in extremely inexpensive access point devices. > > 2). There is a concern that putting an FA essentially everywhere would > add a lot of complication to what could be a relatively simple micro- > mobility handover. > > 3). There are some thoughts that micro-mobility could possibly be handled > completely my MNs (as I am sure have been discussed in MIP ad > nauseum in the past. > > Pat ,our chair, has a firm grasp on this issue, since one of his main chores > as a WG chair is to avoid redundancy with other WGs. Correct, and one of the co-authors of the v4 fast handoff work, so I am quite familiar with the ongoing work :) I believe that the MM folks have raised some interesting questions about MIPv6's reliance on IPSec, and the fact that a fast handoff will require an IKE exchange. So, minimizing such exchanges will in fact provide the perceived fast handoff :) Of course, the MM folks could explain what they are doing much better than I could (I am just an observer). PatC From owner-seamoby@diameter.org Fri Feb 2 18:37:12 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05147 for ; Fri, 2 Feb 2001 18:37:10 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f12LWmW16616 for seamoby-list; Fri, 2 Feb 2001 13:32:48 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f12LWko16611 for ; Fri, 2 Feb 2001 13:32:46 -0800 Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f12Kde126721; Fri, 2 Feb 2001 12:39:40 -0800 (PST) Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104]) by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f12KeoA06305; Fri, 2 Feb 2001 12:40:50 -0800 (PST) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 882569E7.0071C023 ; Fri, 2 Feb 2001 12:42:27 -0800 X-Lotus-FromDomain: 3COM From: Phil_Neumiller@3Com.com To: "Hesham Soliman (ERA)" cc: seamoby@diameter.org Message-ID: <882569E7.00719294.00@hqoutbound.ops.3com.com> Date: Fri, 2 Feb 2001 14:46:05 -0600 Subject: RE: [seamoby] Single sentence problem statements Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-seamoby@diameter.org Precedence: bulk > > The issue here is not only "solving the problem" but also > "solving it in a right way". > > => Agreed. .. fully, but what is wrong about the above ? > Shouldn't this be part of the problem statement. Perhaps > it was discussed before ? I would appreciate a reference if it > was. Hello Hesham, I think what you are getting at here is that you think that the SeaMoby MM work is completely redundant with MIP fast handoff work right? You may be absolutely correct in the long wrong. Then again you could also be wrong. Part of the exercise the SeaMoby WG has been given by the IESG is to determine IF a light weight micro-mobility protocol solves problems NOT solved by MIP or perhaps solves problems in a more efficient way than MIP++. I don't think it is safe to assume that all the SeaMoby micro-mobility design team members have done a detailed examination of all the current fast handoff MIP drafts. It is my understanding that many of the people participating on the list have a cursory understanding of the fast handoff drafts (and if they don't, they should get one). Some folks on the list have brought up some problems that the work in progress may have. I will try to recall some of them here. INT Dana, If your reading this thread, it might be nice to add a perceived problems with MIP(+fast handover) section to the problem statement draft. IRET 1). There is a concern that A GFA/FA in every AP may not scale or even be desirable in extremely inexpensive access point devices. 2). There is a concern that putting an FA essentially everywhere would add a lot of complication to what could be a relatively simple micro- mobility handover. 3). There are some thoughts that micro-mobility could possibly be handled completely my MNs (as I am sure have been discussed in MIP ad nauseum in the past. Pat ,our chair, has a firm grasp on this issue, since one of his main chores as a WG chair is to avoid redundancy with other WGs. Perhaps if you examined the MM draft you would see that what is being done in SeaMoby at this time is to articulate problems that MAY require micro-mobility. It is not SeaMoby's current job to to examine existing, proposed, or dreamed up solutions. I am not sure I could ascertain from you statements what it is you wanted added to the SeaMoby micro-mobility problem statement. I have included the brief problem that I believe caught your eye for reference. To avoid extraneous latency and signalling overhead caused by MIP, a light weight micro-mobility protocol running on the edges of the global Internet is required for handovers that do not require an updated MIP COA. From owner-seamoby@diameter.org Fri Feb 2 23:12:56 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA14245 for ; Fri, 2 Feb 2001 23:12:55 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f1332EG17129 for seamoby-list; Fri, 2 Feb 2001 19:02:14 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from c007.snv.cp.net (c007-h008.c007.snv.cp.net [209.228.33.214]) by charizard.diameter.org (8.10.0/8.10.0) with SMTP id f13323o17124 for ; Fri, 2 Feb 2001 19:02:03 -0800 Received: (cpmta 11340 invoked from network); 2 Feb 2001 18:10:08 -0800 Received: from dsl-64-193-0-129.telocity.com (HELO telocity.com) (64.193.0.129) by smtp.telocity.com (209.228.33.214) with SMTP; 2 Feb 2001 18:10:08 -0800 X-Sent: 3 Feb 2001 02:10:08 GMT Message-ID: <3A7B68F0.10F065A0@telocity.com> Date: Fri, 02 Feb 2001 20:12:00 -0600 From: Phil Neumiller Organization: 3Com X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.16 i686) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: "'Jukka Manner'" , Phil_Neumiller , seamoby Subject: Re: [seamoby] Re: New name -> Seamless to become Hidden Handover? ? References: <13E2EF604DE5D111B2E50000F80824E8057A8BFB@zwdld001.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit > Gary Kenward wrote: > > > (these are the rough thresholds where TCP starts to act up) This is interesting Gary. As an aside, what would happen if we tunnelled TCP and UDP over SCTP to avoid these strange things? (I KNOW ITS SOLUTION SPACE!!!!) > > HiHo, HiHo, it's off to work we go... > > I feel like I'm in a Disney movie. We don't need a new term. > seamless works fine enough. Yeah, I guess its time to kill the Disney references (even though I could could have claimed the "Grumpy" dwarf name). Seamless is overloaded, but we might as well build a black hole for it here in SeaMoby. Perhaps we can get the MIP guys to stop using the term sooooo very much??? :-) They seem to use it like a marketing term for their fast handoff work which in the SeaMoby sense is nowhere near Seamless, go figure. > > > > the IP layer's network interface changes, i.e.. a HO from a > > 3G network to a WLAN, > > > the HO is noticed, at least the user will see this. > > > > > > pdn>If its a vertical HO, and the COA must change, it is no > > No. pdn>Yes... I should have not added the comma, I meant vertical + COA change pdn>not vertical => COA change. >As I pointed out to Jukka, a COA will change only if the > veridical handoff is inter-network. pdn>Of course. and there are bound to be lots of both types in the pdn>near future >>>but CT > > team is definitely pdn>Yes I did indicate this. > > > > But isn't an inter-technology HO, that still maintains > > the context of > > the MH a HiHo? pdn>Yeah but HiHo is dead, lets call it CMobyHO or seamoby HO or pdn>something. PLEASE SOMEBODY GIVE US AN ACRONYM for SEAMOBY pdn>MICROMOBILITY HANDOVER. HiHo is too flaky. THO is not PC. pdn>CMobHO? CMbyHo? IDHO (intra-domain handover)??????????? > > If we do a HO from some 3G tech to WLAN and > > keep the QoS, > > wouldn't that still be a HiHo? Or do we need a new term to > > define that HO: > > > > "Context-aware" HO: context+seamless+including inter-tech ? No. Lets just have uno name for the seamoby HO. We let MIP folks do their own thing as far as naming goes when CT is involved. > Put another way, we need to describe the complex problem space by > identifying and defining a sparse set of independent definitions. So, the definitions provide a "basis" for our space. The problem statements our set of theorems. Gary, do you have a mathematics background per chance? Often your verbage strikes me as that of a mathematician.... TNX, -pdn (N9FCW) From owner-seamoby@diameter.org Sat Feb 3 04:24:44 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA27623 for ; Sat, 3 Feb 2001 04:24:44 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f1384cX17587 for seamoby-list; Sat, 3 Feb 2001 00:04:38 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from NEPTUNE.zucotto.com ([216.95.209.154]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f1384ao17582 for ; Sat, 3 Feb 2001 00:04:36 -0800 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21) id ; Sat, 3 Feb 2001 02:12:45 -0500 Message-ID: From: Kulwinder Atwal To: "'Phil Neumiller'" , Gary Kenward Cc: "'Jukka Manner'" , seamoby Subject: RE: [seamoby] Re: New name -> Seamless to become Hidden Handover? ? Date: Sat, 3 Feb 2001 02:12:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk How does Real-Time Mobility sound in place of SeaMoby. Before commenting please read the below abstract written in 1997. It is un-canny how closely this abstract resembles to our current discussions. Real-Time Behaviour in a Heterogeneous Environment? E. Nett German National Research Center for Information Technology (GMD) Because of the availability of cheap network technology and computing power, people and business become increasingly dependent on computing systems. Timeliness and correctness, therefore, become the most urgently requested system properties, often subsumed in the notion of Quality of Service. Real-time computing is becoming an enabling technology for many important applications such as flexible manufacturing, multimedia, robotics and process control. Traditionally, real-time systems have been realized as isolated, embedded systems, dedicated to provide the requested service for single, dedicated applications like automatic brake systems in vehicles or control systems for nuclear plants. Unfortunately, the solutions provided there do no longer suffice for more complex systems as they are encountered in many of the above mentioned applications. Their most distinguishing requirement is the need of the computing system to dynamically adapt to changing conditions. Little work has been done on (operating) system mechanisms and algorithms, flexible enough to cope with the new requirements. Keywords: real-time systems, quality of service, scheduling, responsiveness Proceedings of the 3rd Workshop on Object-Oriented Real-Time Dependable Systems - (WORDS '97) Copyright (c) 1997 Institute of Electrical and Electronics Engineers, Inc. All rights reserved. And Real-Time handover in place of Hidden or Seamless. Real-time system: A system whose operation depends not just on the correctness but also the timeliness of the behaviour. Real-time handover: A handover where the result depends not just on the correctness but also the timeliness of the handover. Real-time mobility: The movement of micro-flows for mobile devices where the movement depends not just on the correctness but also the timeliness of the handover. I have the same reservations regarding "planned", and "unplanned" that others have stated. -Kulwinder. From owner-seamoby@diameter.org Sat Feb 3 17:13:53 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12937 for ; Sat, 3 Feb 2001 17:13:52 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f13L9in18555 for seamoby-list; Sat, 3 Feb 2001 13:09:44 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f13L9go18549 for ; Sat, 3 Feb 2001 13:09:42 -0800 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 MAA29788; Sat, 3 Feb 2001 12:18:03 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT18016; Sat, 3 Feb 2001 12:17:47 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA00462; Sat, 3 Feb 2001 12:17:47 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14972.26474.972825.310927@thomasm-u1.cisco.com> Date: Sat, 3 Feb 2001 12:17:46 -0800 (PST) To: john.loughney@nokia.com Cc: seamoby-mm@cdma-2000.org, seamoby@diameter.org Subject: [seamoby] context transfer/fast MIP conflict (was: [seamoby-mm] FW: I-D ACTION:draft-designteam-fast-mipv6-00.txt) In-Reply-To: <01D91AFB08B6D211BFD00008C7EABAE10680A839@eseis04nok> References: <01D91AFB08B6D211BFD00008C7EABAE10680A839@eseis04nok> 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-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit [why is it that John's always the shot messenger? :)] john.loughney@nokia.com writes: > Hi all, > > This is probably a good thing for all of us to read. I've read through this and I'm struck by the fact that the HI and HACK do not seem to have anything to do with the fast handoff Mobile IP problem at all. As far as I can tell, they are not required since the tunnel is established between ARold and MN. All ARnew is doing forwarding packets toward the subnet that it already knows how to forward to. Before people get up in arms that ARnew might not be willing to forward packets, I'll point out that that is a routing and/or admission control problem and seems squarely in the problem space that the context transfer design team seems to have in its charter. So my question is what justification the MIP design team has for initiating what amounts to the shell of a context transfer when their charter was to figure out a way to provide a way to provide fast mobility during movement? It appears to me that their work minus the HI/HACK does that just fine and that it would be better to keep the agreed upon problem partition intact so that the context transfer design is not needlessly hobbled by the design decisions which did not account for the larger problem. Mike From owner-seamoby@diameter.org Sat Feb 3 20:10:06 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16472 for ; Sat, 3 Feb 2001 20:10:06 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f13NY5W18706 for seamoby-list; Sat, 3 Feb 2001 15:34:05 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f13NXwo18700 for ; Sat, 3 Feb 2001 15:33:58 -0800 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 OAA07197; Sat, 3 Feb 2001 14:42:03 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f13Mg0008993; Sat, 3 Feb 2001 14:42:00 -0800 X-Virus-Scanned: Sat, 3 Feb 2001 14:42:00 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdjV9zJJ; Sat, 03 Feb 2001 14:41:55 PST Message-ID: <3A7C88CD.BA373BC4@iprg.nokia.com> Date: Sat, 03 Feb 2001 14:40:13 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: seamoby-mm@cdma-2000.org, seamoby@diameter.org, George Tsirtsis , "Basavaraj Patil (NTC/Dallas)" , Phil Roberts Subject: [seamoby] Re: context transfer/fast MIP conflict (was: [seamoby-mm] FW: I-D ACTION:draft-designteam-fast-mipv6-00.txt) References: <01D91AFB08B6D211BFD00008C7EABAE10680A839@eseis04nok> <14972.26474.972825.310927@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I reckon I need to supply at least part of this answer. Also, there is a very much improved version of the draft that will be posted on Monday, resulting from our recent two-day design meeting last week. It was a big success. The [mobile-ip] working group design team did this for a lot of logical reasons (note that I do not speak for them, and these comments must be considered my opinions only): - The design does work with care-of addresses. Maybe it also works with other addresses. So much the better! I reckon you do not suggest we should have made needless restrictions - It is a routing protocol. [mobile-ip] is a working group in the Routing Area. - Everyone always knew that fast handovers should work with context transfers. If it is at all reassuring (?) whenever anyone in the design team mentioned context transfers, we were told not to be concerned with that because it was out of scope. Nevertheless, most people on the design team are aware of the general problem surrounding context transfer. - The network-controlled case is explicitly designed to provide information needed for care-of addresses. One of the things about Mobile IPv6 is that it uses natural IPv6 address configuration mechanisms to create care-of addresses. Thus, any protocol whatsoever that we might create for the expedient management of new care-of address assignment, would right away look like an expedient mechanism for managing new IPv6 address assignment. We had to solve the problem. We had a mandate to solve the problem. We went about it the most direct way we could figure out to do. I'm surprised if this makes anyone uncomfortable. On the contrary, I'd expect to a certain degree that other people might be happy we did the appropriate amount of analysis and engineering to come up with a useful solution. On your more specific statements... Michael Thomas wrote: > I've read through this and I'm struck by the fact that > the HI and HACK do not seem to have anything to do with > the fast handoff Mobile IP problem at all. As far as I > can tell, they are not required since the tunnel > is established between ARold and MN. All ARnew is > doing forwarding packets toward the subnet that > it already knows how to forward to. HI provides information that the new AR needs to avoid doing DAD. That's useful. The new AR provides information to the old AR, using HAck, about whether this avoidance is going to work. I'm not sure about what you meant in the last sentence. I also do NOT believe that we make any statement anywhere about a tunnel between the new AR and the mobile node. That's something which would severely limit the applicability of our fast handover protocol. > Before people get up in arms that ARnew might not > be willing to forward packets, I'll point out > that that is a routing and/or admission control > problem and seems squarely in the problem space > that the context transfer design team seems to > have in its charter. Right, if I understand you correctly. However, in many circumstances the admission control policy is trivial. > So my question is what justification the MIP > design team has for initiating what amounts to > the shell of a context transfer when their > charter was to figure out a way to provide a > way to provide fast mobility during movement? I think this amounts to an accusation of something, but I'm not quite sure what. Perhaps you would like to reconsider your demand in light of the foregoing explanations. > It appears to me that their work minus the > HI/HACK does that just fine and that it would > be better to keep the agreed upon problem > partition intact so that the context transfer > design is not needlessly hobbled by the design > decisions which did not account for the larger > problem. Without HI/HAck, there is no fast handover protocol. Maybe I'm not getting the sense of your discussion. No matter, I'll volunteer to try to bridge the gap in as polite a way as possible. Now, where is my cane? Regards, Charlie P. From owner-seamoby@diameter.org Sat Feb 3 21:31:56 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA06892 for ; Sat, 3 Feb 2001 21:31:53 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f140Y4w18781 for seamoby-list; Sat, 3 Feb 2001 16:34:04 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f140Y2o18775 for ; Sat, 3 Feb 2001 16:34:02 -0800 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 PAA14838; Sat, 3 Feb 2001 15:42:12 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT18118; Sat, 3 Feb 2001 15:41:57 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA00468; Sat, 3 Feb 2001 15:41:57 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14972.38725.417965.650464@thomasm-u1.cisco.com> Date: Sat, 3 Feb 2001 15:41:57 -0800 (PST) To: Charlie Perkins Cc: Michael Thomas , seamoby-mm@cdma-2000.org, seamoby@diameter.org, George Tsirtsis , "Basavaraj Patil (NTC/Dallas)" , Phil Roberts Subject: [seamoby] Re: context transfer/fast MIP conflict (was: [seamoby-mm] FW: I-D ACTION:draft-designteam-fast-mipv6-00.txt) In-Reply-To: <3A7C88CD.BA373BC4@iprg.nokia.com> References: <01D91AFB08B6D211BFD00008C7EABAE10680A839@eseis04nok> <14972.26474.972825.310927@thomasm-u1.cisco.com> <3A7C88CD.BA373BC4@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-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Charlie Perkins writes: > I reckon I need to supply at least part of this answer. > Also, there is a very much improved version of the draft > that will be posted on Monday, resulting from our recent > two-day design meeting last week. It was a big success. > > The [mobile-ip] working group design team did this for > a lot of logical reasons (note that I do not speak for them, > and these comments must be considered my opinions > only): The MIP WG seems to be schizophrenic about what it sees as in its charter. When it punted the context transfer problem to SEAMOBY, it should have punted the *entire* problem, not just the parts that it didn't feel like working on. As it stands now, MIP WG has either decided for SEAMOBY what the appropriate transport vessel for context transfer is (a destination option strikes me as a giagantic hack), or define a different protocol which deals with everything but the few bits and dregs that MIP needed to affect "fast" handoff (read: fast in the narrow world view of MIP's charter). > - It is a routing protocol. [mobile-ip] is a working group > in the Routing Area. Yet, you're clearly defining a transport protocol to move CoA's, DAD state, etc. What, exactly, is HI/HACK doing to the _routing_ state of ARnew? > > I've read through this and I'm struck by the fact that > > the HI and HACK do not seem to have anything to do with > > the fast handoff Mobile IP problem at all. As far as I > > can tell, they are not required since the tunnel > > is established between ARold and MN. All ARnew is > > doing forwarding packets toward the subnet that > > it already knows how to forward to. > > HI provides information that the new AR needs > to avoid doing DAD. That's useful. Fine, but why ought that not just be input to the seamoby/context transfer? There are a *lot* of other things than DAD that are required to effect a fast/smooth handoff in reality. Besides, I thought it was MN that did DAD? How can AR know the difference between two different MN's that have the same lower 64 bits? > The new AR provides > information to the old AR, using HAck, about whether this > avoidance is going to work. Again, there's a lot more than DAD which figure into "work" vs. "not work". > I'm not sure about what you > meant in the last sentence. It means exactly what it says: ARnew's job is just to forward packets; it's not like it needs to terminate a tunnel or something. Any state which is a pre-condition to forwarding seems squarely within the problem that seamoby/context transfer is supposed to solve. > I also do NOT believe that we > make any statement anywhere about a tunnel between > the new AR and the mobile node. That's something which > would severely limit the applicability of our fast handover > protocol. I didn't say anything about a tunnel from ARnew to anything. > > Before people get up in arms that ARnew might not > > be willing to forward packets, I'll point out > > that that is a routing and/or admission control > > problem and seems squarely in the problem space > > that the context transfer design team seems to > > have in its charter. > > Right, if I understand you correctly. However, in many > circumstances the admission control policy is trivial. And in many cases it's complex. I don't see this as a reason to gratuitously come up with a protocol to solve that narrow problem. > > It appears to me that their work minus the > > HI/HACK does that just fine and that it would > > be better to keep the agreed upon problem > > partition intact so that the context transfer > > design is not needlessly hobbled by the design > > decisions which did not account for the larger > > problem. > > Without HI/HAck, there is no fast handover protocol. How so? Assuming can MN get the new subnet in a reasonable period of time, it can cons up its address and do parallel DAD as the draft suggests. What, exactly, prevents ARnew forwarding packets to MN? > Maybe I'm not getting the sense of your discussion. > No matter, I'll volunteer to try to bridge the gap in as > polite a way as possible. Now, where is my cane? Without the rest of context transfer, HI/HACK is inadequate in a large enough set of cases that SEAMOBY became a WG to set about finding a generalized mechanism to deal with the rest of those things that are necessary to perform fast/smooth handoffs. Mike From owner-seamoby@diameter.org Sat Feb 3 22:53:57 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA10698 for ; Sat, 3 Feb 2001 22:53:56 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f142X9g18925 for seamoby-list; Sat, 3 Feb 2001 18:33:09 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f142X7o18919 for ; Sat, 3 Feb 2001 18:33:07 -0800 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 RAA08180; Sat, 3 Feb 2001 17:39:32 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT18159; Sat, 3 Feb 2001 17:39:19 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA00473; Sat, 3 Feb 2001 17:39:19 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14972.45766.832605.237746@thomasm-u1.cisco.com> Date: Sat, 3 Feb 2001 17:39:18 -0800 (PST) To: Charlie Perkins Cc: Michael Thomas , seamoby-mm@cdma-2000.org, seamoby@diameter.org, George Tsirtsis , "Basavaraj Patil (NTC/Dallas)" , Phil Roberts Subject: [seamoby] Re: context transfer/fast MIP conflict (was: [seamoby-mm] FW: I-D ACTION:draft-designteam-fast-mipv6-00.txt) In-Reply-To: <3A7CA09C.4CAAE1FE@iprg.nokia.com> References: <01D91AFB08B6D211BFD00008C7EABAE10680A839@eseis04nok> <14972.26474.972825.310927@thomasm-u1.cisco.com> <3A7C88CD.BA373BC4@iprg.nokia.com> <14972.38725.417965.650464@thomasm-u1.cisco.com> <3A7CA09C.4CAAE1FE@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-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Charlie Perkins writes: > > As it stands now, MIP > > WG has either decided for SEAMOBY what the > > appropriate transport vessel for context transfer > > is (a destination option strikes me as a giagantic > > hack), or define a different protocol which deals > > with everything but the few bits and dregs that > > MIP needed to affect "fast" handoff (read: fast in > > the narrow world view of MIP's charter). > > Well, this statement wrong (and perhaps even > offensive) on several counts: > - We only have a draft, not a decision > - We are only a design team, not the working group > - Your (polite) inputs are welcome, and could > change the design Fine. Since (polite) is in the eye of the beholder, I'll just state my objections. Consider this as input that I think that MIP should not be defining a transport protocol between AR's which has nothing to do with routing. > > Yet, you're clearly defining a transport protocol > > to move CoA's, DAD state, etc. What, exactly, is > > HI/HACK doing to the _routing_ state of ARnew? > > This is also wrong. > > We don't move CoAs. > > We don't move DAD state. You're splitting hairs. You're transporting the knowledge of whether DAD would fail on ARnew. You're also transporting Old CoA, New CoA, HomeAddress and L2 address in HI, and new CoA in HACK. I don't see how you can rationalize that Old, HomeAddress and L2 are not state knowledge that ARold possess that ARnew doesn't. > The old AR sets up a route to the new AR by using > HI. The new AR tells the old AR how to determine > some details about its route table entry for the > mobile node by using the HAck. Wait a minute: I thought that the tunnel between ARold and MN was no different than the tunnel between HA and MN. That is, ARnew is no different than any other router that might be in the path between ARold and MN. ARold only needs to consult its existing FIB to determine where to forward the tunneled packets. > > Fine, but why ought that not just be input > > to the seamoby/context transfer? There are a *lot* > > of other things than DAD that are required to > > effect a fast/smooth handoff in reality. > > Please say what they are. AAA state, QoS state, etc, etc. Regardless I think the burden is still on the design team to justify why ARnew needs to be involved in the fast handoff in way that is related to routing. Thus far haven't seen any reason which holds any more weight than the things I just mentioned. > > Besides, I thought it was MN that did DAD? How > > can AR know the difference between two different > > MN's that have the same lower 64 bits? > > Which AR? Two mobile node's cannot have the same > care-of address, nor the same link-local address. > If the new AR finds out that a new mobile node is > trying to use a care-of address that is already spoken > for, then it should return an error in the HAck message. The only way that ARnew can tell that MN is trying to use an already spoken for address is to *transmit*. ARnew cannot know whether a receive only MN (perhaps because it hasn't arrived) is a duplicate. If a MN configures a duplicate address and sends a fast handoff BU to ARold, the only thing that will happen is that ARnew will forward the packets arriving to the wrong MN. C'est la guerre. This is a reasonable thing to counter with some communication between the two AR's, but I don't see it as a reason for MIP to design a handoff transport protocol in addition to whatever SEAMOBY comes up with. > > Again, there's a lot more than DAD which figure > > into "work" vs. "not work". > > If it's for routing, then I hope we didn't miss it. My point, such as it is, is that what you've got in there is *not* routing, per se. It's pre-configuration of ARnew which is, I thought, what SEAMOBY was supposed to deal with. > > > Without HI/HAck, there is no fast handover protocol. > > > > How so? Assuming can MN get the new subnet in a > > reasonable period of time, it can cons up its > > address and do parallel DAD as the draft suggests. > > What, exactly, prevents ARnew forwarding packets > > to MN? > > The point is to do handovers as fast as possible. There are > many scenarios under which signaling between the mobile node > and the new AR is not possible. We reckon that signaling > between the old AR and the new AR is always possible. > In fact, we basically relegate to base Mobile IPv6 all > scenarios under which the first signaling to/from the mobile > node occurs at the new AR. Only when the old AR can > help, can handovers be "faster" than base Mobile IPv6. Even if what you're thinking of is the MAP stuff here, I don't see how that resolves the conflict between SEAMOBY and MIP's charter. In fact, I don't see how ARnew's reachability by MN for signaling changes anything at all in any case. > A mobile node cannot receive packets on the new subnet > at its new care-of address until DAD is done. That could > take a while. Even with short-cuts, we would need a > retransmission algorithm, and we would be introducing > additional traffic between entities at a bad time. Yet, section 5.1 suggests that the MN does DAD in parallel while using the address anyway which seems eminently reasonable to me. > I guess we tend to disagree on this point. In fact, to me > it is clear that context transfer operations are specifically > useful only when the context(s) exist. It is also clear that, > for all values of context that I am aware of, useful systems > can be built that use none of them. All you're really saying is that sometimes less context needs to be transfered than other times. Fine. I don't see that as a reason to I either Shanghai SEAMOBY into using HI/HACK as the transport vessel for context, or end up with yet another protocol mechanism if that is not agreeable. > In other words, > vanilla fast handover is useful, contrary to your assertion. I've never said that. I said it's not adequate for fast handoff in large set of cases. Namely, oh say, where a service provider such as, oh say, a cellular provider, needs AAA to happen first before access is granted on ARnew, etc, etc. > You still didn't say what's wrong with HI/HAck. See above. Mike From owner-seamoby@diameter.org Sat Feb 3 22:56:51 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA10720 for ; Sat, 3 Feb 2001 22:56:50 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f141Js818836 for seamoby-list; Sat, 3 Feb 2001 17:19:54 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f141Jqo18830 for ; Sat, 3 Feb 2001 17:19:52 -0800 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 QAA10475; Sat, 3 Feb 2001 16:27:57 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f140RtP07336; Sat, 3 Feb 2001 16:27:55 -0800 X-Virus-Scanned: Sat, 3 Feb 2001 16:27:55 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpd8Xkpwq; Sat, 03 Feb 2001 16:27:50 PST Message-ID: <3A7CA09C.4CAAE1FE@iprg.nokia.com> Date: Sat, 03 Feb 2001 16:21:48 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: seamoby-mm@cdma-2000.org, seamoby@diameter.org, George Tsirtsis , "Basavaraj Patil (NTC/Dallas)" , Phil Roberts Subject: [seamoby] Re: context transfer/fast MIP conflict (was: [seamoby-mm] FW: I-D ACTION:draft-designteam-fast-mipv6-00.txt) References: <01D91AFB08B6D211BFD00008C7EABAE10680A839@eseis04nok> <14972.26474.972825.310927@thomasm-u1.cisco.com> <3A7C88CD.BA373BC4@iprg.nokia.com> <14972.38725.417965.650464@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello again, > The MIP WG seems to be schizophrenic about what it > sees as in its charter. When it punted the context > transfer problem to SEAMOBY, it should have punted > the *entire* problem, not just the parts that it > didn't feel like working on. You ought to ask the area directors about this. I agree that context transfer is important during fast handovers, and nevertheless I also agree that a division of labor is possible and perhaps even desirable. However, the desirability will depend on the results. > As it stands now, MIP > WG has either decided for SEAMOBY what the > appropriate transport vessel for context transfer > is (a destination option strikes me as a giagantic > hack), or define a different protocol which deals > with everything but the few bits and dregs that > MIP needed to affect "fast" handoff (read: fast in > the narrow world view of MIP's charter). Well, this statement wrong (and perhaps even offensive) on several counts: - We only have a draft, not a decision - We are only a design team, not the working group - Your (polite) inputs are welcome, and could change the design - A (?narrow, ?circumscribed, ?focussed, ?practical) world view does sometimes help to get things done. - There is a hell of a lot of work to do besides just bits and dregs. If you think otherwise, then please produce the "dregs draft" to show how easy it is. > > - It is a routing protocol. [mobile-ip] is a working group > > in the Routing Area. > > Yet, you're clearly defining a transport protocol > to move CoA's, DAD state, etc. What, exactly, is > HI/HACK doing to the _routing_ state of ARnew? This is also wrong. We don't move CoAs. We don't move DAD state. The old AR sets up a route to the new AR by using HI. The new AR tells the old AR how to determine some details about its route table entry for the mobile node by using the HAck. Is there some particular thing that can be explained better so that communication will be possible? > Fine, but why ought that not just be input > to the seamoby/context transfer? There are a *lot* > of other things than DAD that are required to > effect a fast/smooth handoff in reality. Please say what they are. > Besides, I thought it was MN that did DAD? How > can AR know the difference between two different > MN's that have the same lower 64 bits? Which AR? Two mobile node's cannot have the same care-of address, nor the same link-local address. If the new AR finds out that a new mobile node is trying to use a care-of address that is already spoken for, then it should return an error in the HAck message. > > The new AR provides > > information to the old AR, using HAck, about whether this > > avoidance is going to work. > > Again, there's a lot more than DAD which figure > into "work" vs. "not work". If it's for routing, then I hope we didn't miss it. If it's for context, then I hope that [seamboby] won't miss it. Maybe QoS is context, or maybe it's network-layer, but I reckon that there is so far some tacit agreement to treat it as context. If you suggest that additional errors should be defined for the HAck message, I'm sure people will be willing to believe you. I can imagine errors to the effect that admission control has failed, or that resources are unavailable for particular QoS contexts. > > I'm not sure about what you > > meant in the last sentence. > > It means exactly what it says: ARnew's job is just > to forward packets; it's not like it needs to > terminate a tunnel or something. Any state which > is a pre-condition to forwarding seems squarely > within the problem that seamoby/context transfer > is supposed to solve. Then I agree with both of your clarifications, and do not see any contradiction to HI/HAck. > I didn't say anything about a tunnel from ARnew > to anything. You are right. You said something about a tunnel from ARold to the mobile node, and I reached the wrong conclusion. > > Right, if I understand you correctly. However, in many > > circumstances the admission control policy is trivial. > > And in many cases it's complex. I don't see this > as a reason to gratuitously come up with a > protocol to solve that narrow problem. Of course we didn't come up with such a protocol, gratuitous or otherwise. That would be the work of [seamoby-context], presumably. > > Without HI/HAck, there is no fast handover protocol. > > How so? Assuming can MN get the new subnet in a > reasonable period of time, it can cons up its > address and do parallel DAD as the draft suggests. > What, exactly, prevents ARnew forwarding packets > to MN? The point is to do handovers as fast as possible. There are many scenarios under which signaling between the mobile node and the new AR is not possible. We reckon that signaling between the old AR and the new AR is always possible. In fact, we basically relegate to base Mobile IPv6 all scenarios under which the first signaling to/from the mobile node occurs at the new AR. Only when the old AR can help, can handovers be "faster" than base Mobile IPv6. A mobile node cannot receive packets on the new subnet at its new care-of address until DAD is done. That could take a while. Even with short-cuts, we would need a retransmission algorithm, and we would be introducing additional traffic between entities at a bad time. There are a lot of details. > Without the rest of context transfer, HI/HACK is > inadequate in a large enough set of cases that > SEAMOBY became a WG to set about finding a > generalized mechanism to deal with the rest of > those things that are necessary to perform > fast/smooth handoffs. I guess we tend to disagree on this point. In fact, to me it is clear that context transfer operations are specifically useful only when the context(s) exist. It is also clear that, for all values of context that I am aware of, useful systems can be built that use none of them. In other words, vanilla fast handover is useful, contrary to your assertion. You still didn't say what's wrong with HI/HAck. Regards, Charlie P. From owner-seamoby@diameter.org Sat Feb 3 23:36:22 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA11329 for ; Sat, 3 Feb 2001 23:36:21 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f143BHQ18986 for seamoby-list; Sat, 3 Feb 2001 19:11:17 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f143B6o18980 for ; Sat, 3 Feb 2001 19:11:06 -0800 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 SAA13540; Sat, 3 Feb 2001 18:19:11 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f142JAo02240; Sat, 3 Feb 2001 18:19:10 -0800 X-Virus-Scanned: Sat, 3 Feb 2001 18:19:10 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpd4Zy9Te; Sat, 03 Feb 2001 18:19:05 PST Message-ID: <3A7CB8FB.8DFD32C1@iprg.nokia.com> Date: Sat, 03 Feb 2001 18:05:47 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: seamoby-mm@cdma-2000.org, seamoby@diameter.org, George Tsirtsis , "Basavaraj Patil (NTC/Dallas)" , Phil Roberts Subject: Re: [seamoby] Re: context transfer/fast MIP conflict (was: [seamoby-mm] FW: I-D ACTION:draft-designteam-fast-mipv6-00.txt) References: <01D91AFB08B6D211BFD00008C7EABAE10680A839@eseis04nok> <14972.26474.972825.310927@thomasm-u1.cisco.com> <3A7C88CD.BA373BC4@iprg.nokia.com> <14972.38725.417965.650464@thomasm-u1.cisco.com> <3A7CA09C.4CAAE1FE@iprg.nokia.com> <14972.45766.832605.237746@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello again, > Fine. Since (polite) is in the eye of the > beholder, I'll just state my objections. > Consider this as input that I think that > MIP should not be defining a transport protocol > between AR's which has nothing to do with > routing. The matter seems to be that you don't accept our work as a routing protocol, and yet I think it very clearly is. Maybe that's the point worth elaborating, and I'll do so by inserting commentary below. > > We don't move CoAs. > > > > We don't move DAD state. > > You're splitting hairs. You're transporting the knowledge > of whether DAD would fail on ARnew. Only ARnew can determine that, and it matters to ARold because of the need to determine the destination IP address of the outer tunnel. That's routing. That's NOT transporting DAD state. I think this is obvious. > You're also transporting > Old CoA, New CoA, HomeAddress and L2 address in HI, and > new CoA in HACK. I don't see how you can rationalize that > Old, HomeAddress and L2 are not state knowledge that ARold > possess that ARnew doesn't. Well, in my route tables the IP address and the L2 address are the information that is important. Routing is stateful. That's obvious, so calling something "state" does not insert it into the exclusive realm of [seamoby-context]. I could make a better definition of "context" that would distinguish [seamoby-context] from routing, but evidence indicates that my effort would be about as useful to you as a burp in a scuba-diving suit We do not transport HomeAddress, that was fixed. > > The old AR sets up a route to the new AR by using > > HI. The new AR tells the old AR how to determine > > some details about its route table entry for the > > mobile node by using the HAck. > > Wait a minute: I thought that the tunnel between > ARold and MN was no different than the tunnel > between HA and MN. That is, ARnew is no different > than any other router that might be in the > path between ARold and MN. ARold only needs to > consult its existing FIB to determine where to > forward the tunneled packets. We don't define FIB, and we never compared the tunnel between ARold and MN to that between the HA and MN. However, I don't see why you are insisting that they are different. The new draft will be much clearer in this matter. > > > Fine, but why ought that not just be input > > > to the seamoby/context transfer? There are a *lot* > > > of other things than DAD that are required to > > > effect a fast/smooth handoff in reality. > > > > Please say what they are. > > AAA state, QoS state, etc, etc. AAA state and QoS state are required sometimes. I'm still not getting your point, though, unless you are saying that no solution is worth anything unless it solves everything all at once. > Regardless I > think the burden is still on the design team to > justify why ARnew needs to be involved in the > fast handoff in way that is related to routing. > Thus far haven't seen any reason which holds > any more weight than the things I just mentioned. How about if we involve ARnew it makes things faster? That's good enough for me, and it works. > > > Besides, I thought it was MN that did DAD? How > > > can AR know the difference between two different > > > MN's that have the same lower 64 bits? > > > > Which AR? Two mobile node's cannot have the same > > care-of address, nor the same link-local address. > > If the new AR finds out that a new mobile node is > > trying to use a care-of address that is already spoken > > for, then it should return an error in the HAck message. > > The only way that ARnew can tell that MN is trying > to use an already spoken for address is to > *transmit*. This assumption is not universally valid. A router has a neighbor cache. That cache has useful information for the determination we are discussing. > ARnew cannot know whether a receive > only MN (perhaps because it hasn't arrived) is > a duplicate. If a MN configures a duplicate > address and sends a fast handoff BU to ARold, > the only thing that will happen is that ARnew > will forward the packets arriving to the wrong > MN. C'est la guerre. This is not one of the scenarios we consider in the draft. I'm not sure how it is relevant to the current discussion. I could try to make it relevant by imagining further uses for HI/HAck, but that doesn't seem to help advance the discussion. > This is a reasonable thing to counter > with some communication between the two AR's, > but I don't see it as a reason for MIP to > design a handoff transport protocol in addition > to whatever SEAMOBY comes up with. O.K. I'm lost. Regarding your last sentence, I think it's obvious that the two efforts should be coordinated. I think it's also obvious that each bit of context is useful in fewer cases than the overall fast handover will be useful. Thus, waiting for [seamoby] to design particular context transfer mechanisms for particular bits of to context, before doing fast handover, would seem weird to me. Or, what were you proposing? > > > Again, there's a lot more than DAD which figure > > > into "work" vs. "not work". > > > > If it's for routing, then I hope we didn't miss it. > > My point, such as it is, is that what you've > got in there is *not* routing, per se. It's > pre-configuration of ARnew which is, I thought, > what SEAMOBY was supposed to deal with. It's preconfiguration of the _routing tables_ on ARnew. That's not what [seamoby] is supposed to deal with. > > The point is to do handovers as fast as possible. There are > > many scenarios under which signaling between the mobile node > > and the new AR is not possible. We reckon that signaling > > between the old AR and the new AR is always possible. > > In fact, we basically relegate to base Mobile IPv6 all > > scenarios under which the first signaling to/from the mobile > > node occurs at the new AR. Only when the old AR can > > help, can handovers be "faster" than base Mobile IPv6. > > Even if what you're thinking of is the MAP > stuff here, I don't see how that resolves > the conflict between SEAMOBY and MIP's > charter. In fact, I don't see how ARnew's > reachability by MN for signaling changes > anything at all in any case. MAP didn't cross my mind when I wrote the above paragraph. I don't know what to say to make it clearer. I reread the paragraph, and it says exactly that the fast handovers have only been designed for the case where the old AR can help speed the handover. That's what I think we _were_ supposed to do, and (again) I I thought that if the old AR can't help, then Mobile IPv6 was deemed to be sort-of good enough. Modulo context transfer, that is, which is what we were not supposed to be doing. > > I guess we tend to disagree on this point. In fact, to me > > it is clear that context transfer operations are specifically > > useful only when the context(s) exist. It is also clear that, > > for all values of context that I am aware of, useful systems > > can be built that use none of them. > > All you're really saying is that sometimes less > context needs to be transfered than other > times. Fine. I don't see that as a reason to > I either Shanghai SEAMOBY into using HI/HACK > as the transport vessel for context, or end > up with yet another protocol mechanism if > that is not agreeable. Instead of railroading something, why don't you have a discussion about what's needed? You have a tool at your disposal. You can sharpen it, use it as it is, or discard it as unworthy. There's a lot of people around who would like to help. > > In other words, > > vanilla fast handover is useful, contrary to your assertion. > > I've never said that. I said it's not adequate > for fast handoff in large set of cases. Namely, > oh say, where a service provider such as, oh > say, a cellular provider, needs AAA to happen > first before access is granted on ARnew, etc, etc. So we agree that vanilla fast handover is useful. I point out that is what we intended to design. You say it's not good enough for many cases. I hope to eventually see you point out the insufficiencies. > > You still didn't say what's wrong with HI/HAck. > > See above. I sure have been looking hard. Regards, Charlie P. From owner-seamoby@diameter.org Sun Feb 4 14:11:11 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10865 for ; Sun, 4 Feb 2001 14:11:10 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f14I71925443 for seamoby-list; Sun, 4 Feb 2001 10:07:01 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f14I6xo25438 for ; Sun, 4 Feb 2001 10:06:59 -0800 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 f14HFCd02564 for ; Sun, 4 Feb 2001 18:15:13 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Sun Feb 04 18:16:16 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id <1CVZM7N3>; Sun, 4 Feb 2001 18:11:50 +0100 Message-ID: <034BEFD03799D411A59F00508BDF75465B6973@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Phil_Neumiller@3com.com'" Cc: seamoby@diameter.org Subject: RE: [seamoby] Single sentence problem statements Date: Sun, 4 Feb 2001 18:15:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-seamoby@diameter.org Precedence: bulk Hello Phil, Thanks for the detailed explanation. I hope you don't read too much criticism into my questions, I'm genuinely trying to understand the problem. Having said that I have some more comments on your statements below. > I think what you are getting at here is that you think that the SeaMoby MM > work > is > completely redundant with MIP fast handoff work right? > => Not quite :) I'm curious to know what we missed in the fast handoff work and I would gladly support a problem statement that shows fundamental problems in the MIP work that can not be fixed. > You may be absolutely > correct in the long wrong. Then again you could also be wrong. Part of > the > exercise the SeaMoby WG has been given by the IESG is to determine IF a > light weight micro-mobility protocol solves problems NOT solved by MIP or > perhaps solves problems in a more efficient way than MIP++. > => Again I fully support this, but part of your problem statement (signalling delays and number of signals over the air) are solved by MIP++, hence my question. > I don't think it > is safe to assume that all the SeaMoby micro-mobility design team members > have done a detailed examination of all the current fast handoff MIP > drafts. It > is my understanding that many of the people participating on the list have > a > cursory understanding of the fast handoff drafts (and if they don't, they > should > get one). Some folks on the list have brought up some problems that the > work in progress may have. I will try to recall some of them here. > > INT > Dana, > If your reading this thread, it might be nice to add a perceived problems > with > MIP(+fast handover) section to the problem statement draft. > IRET > > 1). There is a concern that A GFA/FA in every AP may not scale or even > be desirable in extremely inexpensive access point devices. > => Sure, but for V6 that would be a very simple and inexpensive router. There are products that support this already in cellular networks. > 2). There is a concern that putting an FA essentially everywhere would > add a lot of complication to what could be a relatively simple > micro- > mobility handover. > => Maybe, but so far this is V4 specific. I'm biased towards V6. > 3). There are some thoughts that micro-mobility could possibly be handled > completely my MNs (as I am sure have been discussed in MIP ad > nauseum in the past. => Ok, worth investigating. > Pat ,our chair, has a firm grasp on this issue, since one of his main > chores as > a WG chair is to avoid redundancy with other WGs. > > Perhaps if you examined the MM draft you would see that what is being done > in SeaMoby at this time is to articulate problems that MAY require > micro-mobility. It is not SeaMoby's current job to to examine existing, > proposed, > or dreamed up solutions. I am not sure I could ascertain from you > statements > what it is you wanted added to the SeaMoby micro-mobility problem > statement. > I have included the brief problem that I believe caught your eye for > reference. > => Ok I'll read the draft. My main concern was that to be able to articulate an accurate problem statement current solutions must be examined carefully and their weaknesses have to be shown. Otherwise you get people like me asking questions. I'm not trying to say the work is not needed, but I really can't understand how the first statement is correct in light of the current MIP++ work. Perhaps you were trying to make it short but it was too short for me to understand. One other concern I have is whether you are considering the impacts of supporting more than on mobility management scheme in the MN ? Perhaps I'll get some answers from the draft. From owner-seamoby@diameter.org Sun Feb 4 14:24:33 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10976 for ; Sun, 4 Feb 2001 14:24:31 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f14ILKG25468 for seamoby-list; Sun, 4 Feb 2001 10:21:20 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f14ILIo25463 for ; Sun, 4 Feb 2001 10:21:18 -0800 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 f14HTXd03569 for ; Sun, 4 Feb 2001 18:29:33 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Sun Feb 04 18:29:33 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id <1CVMXX9P>; Sun, 4 Feb 2001 18:29:33 +0100 Message-ID: <034BEFD03799D411A59F00508BDF75465B6974@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Patrice Calhoun'" Cc: seamoby@diameter.org Subject: RE: [seamoby] Single sentence problem statements Date: Sun, 4 Feb 2001 18:29:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-seamoby@diameter.org Precedence: bulk > > > > Pat ,our chair, has a firm grasp on this issue, since one of his main chores > > as a WG chair is to avoid redundancy with other WGs. > > Correct, and one of the co-authors of the v4 fast handoff work, so I am quite > familiar with the ongoing work :) > > I believe that the MM folks have raised some interesting questions about > MIPv6's reliance on IPSec, and the fact that a fast handoff will require an > IKE exchange. So, minimizing such exchanges will in fact provide the perceived > fast handoff :) Of course, the MM folks could explain what they are doing much > better than I could (I am just an observer). > => We most certainly do not want the handover to require a new IKE exchange and I don't understand how it would. I'm surprised these concerns were raised. The concerns are not valid because MIPv6 mandates that the SA be established based on the Home address. Hence, when moving no new SAs are required to update the HA and CNs. As for updating the previous AR, yes an SA is required but there are two solutions we investigated in MIP to solve this : 1. If you're using a flat mobility management model (no MAP) then we were counting on SEAMOBY to transfer the SA from the old AR to the new one. I think this is a very valid solution. 2. If a MAP exists, the MN establishes an SA only when moving between two MAP domains. Therefore the SA establishment will be very rare, depending on the size of the MAP domain. In other words, depending on how many ARs are advertising a MAP option. As for IKE and whether it's too heavy, spectrum inefficient ..etc please have a look at draft-soliman-mobileip-routeopt--mipv6-00.txt which proposes an alternative. Hesham From owner-seamoby@diameter.org Sun Feb 4 15:00:54 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11157 for ; Sun, 4 Feb 2001 15:00:53 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f14IvoA25511 for seamoby-list; Sun, 4 Feb 2001 10:57:50 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f14Ivjo25500 for ; Sun, 4 Feb 2001 10:57:45 -0800 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 f14I60d06872 for ; Sun, 4 Feb 2001 19:06:00 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Sun Feb 04 19:05:59 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id <1CVZM7XV>; Sun, 4 Feb 2001 19:02:37 +0100 Message-ID: <034BEFD03799D411A59F00508BDF75465B6975@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Charlie Perkins'" , Michael Thomas Cc: seamoby-mm@cdma-2000.org, seamoby@diameter.org, George Tsirtsis , "Basavaraj Patil (NTC/Dallas)" , Phil Roberts Subject: RE: [seamoby] Re: context transfer/fast MIP conflict (was: [seamo by-mm] FW: I-D ACTION:draft-designteam-fast-mipv6-00.txt) Date: Sun, 4 Feb 2001 19:05:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-seamoby@diameter.org Precedence: bulk Hello, First of all I'd like to state that there is a new draft that will appear in a couple of days, this draft is much clearer and hopefully it will explain a bit more what we're trying to achieve. The draft will however still contain the HI/Ack messages hence this email. Now, let me try to explain why these messages exist and see if we can get some feedback. I hope we can keep this discussion constructive. IPv6 allows the MNs to get a new COA when attaching to the new AR, however this requires DAD. DAD can take up to 2 seconds. If you strictly folow RFC 2462, then the MN can not receive or send packets during that period. Not very fast is it ! The draft is based on anticipation, the MN anticipates its new COA and sends BUs based on that anticipated address. So we had to work around RFC 2462: - If the new AR has knowledge of all MNs connected to it, then this knowledge can be used to immediately know whether the MN's address is valid or not. This would require a request-reply message from the old AR to the new one. The option of doing DAD in parallel was there but in view of the new approach (coming out in the new draft) it may not be needed. Now we are solving the routing part of the problem. No new COA means no routing. Obviously CT is still needed for a more complete solution. We had two possible options for sending this request-reply messages. Dest options or ICMP. After a long debate we thought ICMP is more appropriate since it allows for future extensions and MAY also be used by the CT team. Now if that is a bad solution then we can always revert to destination options and leave the door open for highler level protocols for CT. But we need to know why it's bad and why CT will be done differently. So far we haven't heard any reasons because the work of the CT team is not done yet. So nothing is set in stone. As far as I'm aware no one was trying to "take over" the context transfer work. So I don't see any need for being concerned about that. I hope we can cooperate in this area as it is obviously needed by both WGs. Hesham From owner-seamoby@diameter.org Sun Feb 4 19:17:32 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13294 for ; Sun, 4 Feb 2001 19:17:31 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f14MjBv25752 for seamoby-list; Sun, 4 Feb 2001 14:45:11 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f14Mj5o25746 for ; Sun, 4 Feb 2001 14:45:05 -0800 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 NAA19989; Sun, 4 Feb 2001 13:53:27 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT18541; Sun, 4 Feb 2001 13:53:10 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA00757; Sun, 4 Feb 2001 13:53:10 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14973.53062.314908.356967@thomasm-u1.cisco.com> Date: Sun, 4 Feb 2001 13:53:10 -0800 (PST) To: Charlie Perkins Cc: Michael Thomas , seamoby-mm@cdma-2000.org, seamoby@diameter.org, George Tsirtsis , "Basavaraj Patil (NTC/Dallas)" , Phil Roberts Subject: Re: [seamoby] Re: context transfer/fast MIP conflict (was: [seamoby-mm] FW: I-D ACTION:draft-designteam-fast-mipv6-00.txt) In-Reply-To: <3A7CB8FB.8DFD32C1@iprg.nokia.com> References: <01D91AFB08B6D211BFD00008C7EABAE10680A839@eseis04nok> <14972.26474.972825.310927@thomasm-u1.cisco.com> <3A7C88CD.BA373BC4@iprg.nokia.com> <14972.38725.417965.650464@thomasm-u1.cisco.com> <3A7CA09C.4CAAE1FE@iprg.nokia.com> <14972.45766.832605.237746@thomasm-u1.cisco.com> <3A7CB8FB.8DFD32C1@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-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Charlie Perkins writes: > > You're splitting hairs. You're transporting the knowledge > > of whether DAD would fail on ARnew. > > Only ARnew can determine that, and it matters to ARold > because of the need to determine the destination IP address > of the outer tunnel. > > That's routing. That's NOT transporting DAD state. I think > this is obvious. Well, I don't think it's obvious at all. > > You're also transporting > > Old CoA, New CoA, HomeAddress and L2 address in HI, and > > new CoA in HACK. I don't see how you can rationalize that > > Old, HomeAddress and L2 are not state knowledge that ARold > > possess that ARnew doesn't. > > Well, in my route tables the IP address and the L2 address are > the information that is important. Routing is stateful. That's > obvious, > so calling something "state" does not insert it into the exclusive realm > of [seamoby-context]. By this definition, DHCP is a routing problem too. > > Wait a minute: I thought that the tunnel between > > ARold and MN was no different than the tunnel > > between HA and MN. That is, ARnew is no different > > than any other router that might be in the > > path between ARold and MN. ARold only needs to > > consult its existing FIB to determine where to > > forward the tunneled packets. > > We don't define FIB, and we never compared the tunnel > between ARold and MN to that between the HA and MN. > However, I don't see why you are insisting that they are > different. The new draft will be much clearer in this matter. Please read what I actually write. This is the second time that you've misconstrued something that was not mistated. And I still don't understand your previous comment about "old AR sets up a route to the new AR". It is my understanding that the new AR is just a router like any other router in the path between MN and ARold; that there is no reason to change ARold's routing tables at all. Did you misspeak, or is there something that I'm not understanding? > > AAA state, QoS state, etc, etc. > > AAA state and QoS state are required sometimes. > I'm still not getting your point, though, unless you are saying > that no solution is worth anything unless it solves everything > all at once. No, I'm saying that I don't understand what modularity is buying in this particular case, and indeed, it may have significant downside. > > Regardless I > > think the burden is still on the design team to > > justify why ARnew needs to be involved in the > > fast handoff in way that is related to routing. > > Thus far haven't seen any reason which holds > > any more weight than the things I just mentioned. > > How about if we involve ARnew it makes things faster? > That's good enough for me, and it works. Great. If we do context transfer, it will be faster still. Whether we think this was a great split or not, the AD's decided to partition the problem this way. All I'm asking is that we not end up with a bifurcation because MIP WG (or their design team) could rationalize *some* of the needed state transfer within the MIP context. > Regarding your last sentence, I think it's obvious that the > two efforts should be coordinated. I think it's also obvious > that each bit of context is useful in fewer cases than the > overall fast handover will be useful. Thus, waiting for > [seamoby] to design particular context transfer mechanisms > for particular bits of to context, before doing fast handover, > would seem weird to me. Can Destination Options be encrypted using ESP? I was under the impression from the last IETF that the answer was no (which I confess to still not understanding the reason why). If so, by coding MIP's needs as a destination option, you have either forced a new protocol for context transfer to be devised, or made the job doing a context transfer harder by requiring it to needlessly devise an application layer encryption scheme. > Or, what were you proposing? I'm proposing that MIP deliver its requirements to SEAMOBY context transfer and then a suitable protocol can be devised that meets all of the requirements. > > My point, such as it is, is that what you've > > got in there is *not* routing, per se. It's > > pre-configuration of ARnew which is, I thought, > > what SEAMOBY was supposed to deal with. > > It's preconfiguration of the _routing tables_ on ARnew. > That's not what [seamoby] is supposed to deal with. Again, then DHCP is a routing protocol too. It delivers static routes to hosts, and some routers use the MAC/IP data going by to build proxy ARP tables, blah blah blah. You think this is cut and dry. I don't. > Instead of railroading something, why don't you have > a discussion about what's needed? You have a tool > at your disposal. You can sharpen it, use it as it is, > or discard it as unworthy. There's a lot of people > around who would like to help. Um, the same can be said in reverse. Why are you so disagreable to the notion of letting SEAMOBY deal with the MIP context requirements? Why is MIP any different than, say, RSVP, Diffserv, AAA, RAP, IPsec, etc that need to have state and/or coordination with ARnew to achieve fast/smooth handoff? > So we agree that vanilla fast handover is useful. I point out > that is what we intended to design. You say it's not good enough > for many cases. I hope to eventually see you point out the > insufficiencies. Right, but I think you can achieve vanilla fast handoff without needing to create the HI/HACK messages. Since SEAMOBY will be right behind with the CT work which could incorporate the shortcomings of "vanilla" (as if there were, IMO :-), I don't see this as risking an orphaned problem. Mike From owner-seamoby@diameter.org Sun Feb 4 19:28:17 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13345 for ; Sun, 4 Feb 2001 19:28:15 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f14MuXB25781 for seamoby-list; Sun, 4 Feb 2001 14:56:33 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f14MuVo25775 for ; Sun, 4 Feb 2001 14:56:31 -0800 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 OAA22903; Sun, 4 Feb 2001 14:04:52 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT18546; Sun, 4 Feb 2001 14:04:36 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA00760; Sun, 4 Feb 2001 14:04:36 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14973.53748.458540.799829@thomasm-u1.cisco.com> Date: Sun, 4 Feb 2001 14:04:36 -0800 (PST) To: "Hesham Soliman (ERA)" Cc: "'Charlie Perkins'" , Michael Thomas , seamoby-mm@cdma-2000.org, seamoby@diameter.org, George Tsirtsis , "Basavaraj Patil (NTC/Dallas)" , Phil Roberts Subject: RE: [seamoby] Re: context transfer/fast MIP conflict (was: [seamo by-mm] FW: I-D ACTION:draft-designteam-fast-mipv6-00.txt) In-Reply-To: <034BEFD03799D411A59F00508BDF75465B6975@esealnt448.al.sw.ericsson.se> References: <034BEFD03799D411A59F00508BDF75465B6975@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-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hesham Soliman (ERA) writes: > Now we are solving the routing part of the problem. No new > COA means no routing. Obviously CT is still needed for a more > complete solution. > We had two possible options for sending this > request-reply messages. Dest options or ICMP. After a long > debate we thought ICMP is more appropriate since it allows > for future extensions and MAY also be used by the CT team. Well, I'm glad to hear that you ditched the Destination Option, but as far as whether ICMP is the right method, I think it's far to early to guess. A few questions come immediately to mind: 1) Do we need congestion avoidance? 2) Do we need > MAX MTU contexts? 3) What are the security requirements? > Now if that is a bad solution then we can always revert to > destination options and leave the door open for highler level > protocols for CT. Or you could feed the requirements to SEAMOBY and have a single solution. #1 above is almost certainly going to have some AD shaking their head "yes" and I don't see why MIP's can ignore it either. Mike From owner-seamoby@diameter.org Sun Feb 4 19:33:07 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13369 for ; Sun, 4 Feb 2001 19:33:06 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f14NIuu25825 for seamoby-list; Sun, 4 Feb 2001 15:18:56 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f14NIpo25815 for ; Sun, 4 Feb 2001 15:18:51 -0800 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 f14MR7C25741 for ; Sun, 4 Feb 2001 23:27:07 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Sun Feb 04 23:27:06 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id <1CVZM921>; Sun, 4 Feb 2001 23:23:44 +0100 Message-ID: <034BEFD03799D411A59F00508BDF75465B697E@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Michael Thomas'" Cc: seamoby-mm@cdma-2000.org, seamoby@diameter.org, "Basavaraj Patil (NTC/Dallas)" , Phil Roberts Subject: RE: [seamoby] Re: context transfer/fast MIP conflict (was: [seamo by-mm] FW: I-D ACTION:draft-designteam-fast-mipv6-00.txt) Date: Sun, 4 Feb 2001 23:27:05 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-seamoby@diameter.org Precedence: bulk I've removed people from the cc list to avoid receiving duplicates I know the're on the list already. > Hesham Soliman (ERA) writes: > > Now we are solving the routing part of the problem. No new > > COA means no routing. Obviously CT is still needed for a more > > complete solution. > > We had two possible options for sending this > > request-reply messages. Dest options or ICMP. After a long > > debate we thought ICMP is more appropriate since it allows > > for future extensions and MAY also be used by the CT team. > > Well, I'm glad to hear that you ditched the > Destination Option, > => Why ? > but as far as whether ICMP > is the right method, I think it's far to early > to guess. A few questions come immediately to > mind: > > 1) Do we need congestion avoidance? => Could you elaborate a bit on this ? I don't see the additional need here compared to other signalling flows. > 2) Do we need > MAX MTU contexts? > => So far we haven't seen the need. > 3) What are the security requirements? > => The HI/Ack MUST be authenticated. IPsec is used. > > > Now if that is a bad solution then we can always revert to > > destination options and leave the door open for highler level > > protocols for CT. > > Or you could feed the requirements to SEAMOBY > and have a single solution. > => I see. I have to disagree with this. As I said earlier we're trying to solve the problem of routing packets to and from the MN. Forming a new COA in a stateless manner poses a challenge to this routing problem. This is how we chose to solve it. I was also happy with doing DAD in parallel but this seemed to be a good way to do it for routers that can confirm that no duplication will take place. As to whether it should be done in SEAMOBY, well, I believe SEAMOBY is standardising the CT and not every message that is sent between ARs. Especially if the purpose of these messages is to enable the routing of packets. We are not transferring context really (like QoS, SAs ...etc). I think this discussion should be taken on the MIP list since it is a MIP draft. Hesham PS: This list is very slow. It takes me at least half an hour to get my email back ! From owner-seamoby@diameter.org Sun Feb 4 19:54:34 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13427 for ; Sun, 4 Feb 2001 19:54:32 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f14Nfnw25871 for seamoby-list; Sun, 4 Feb 2001 15:41:49 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f14Nfjo25861 for ; Sun, 4 Feb 2001 15:41:46 -0800 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 f14Mo2d02336 for ; Sun, 4 Feb 2001 23:50:02 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Sun Feb 04 23:51:04 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id <1CVZM9MK>; Sun, 4 Feb 2001 23:45:49 +0100 Message-ID: <034BEFD03799D411A59F00508BDF75465B697F@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Michael Thomas'" Cc: seamoby-mm@cdma-2000.org, seamoby@diameter.org, "Basavaraj Patil (NTC/Dallas)" , Phil Roberts Subject: RE: [seamoby] Re: context transfer/fast MIP conflict (was: [seamo by-mm] FW: I-D ACTION:draft-designteam-fast-mipv6-00.txt) Date: Sun, 4 Feb 2001 23:49:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-seamoby@diameter.org Precedence: bulk > Can Destination Options be encrypted using ESP? => There are 2 dest options in the IPv6 header. Dest 1 is processed by intermediate nodes and can not be encrypted. Dest 2 is placed after the IPsec header and is processed by the end node only and can definitely be encrypted. Hesham From owner-seamoby@diameter.org Sun Feb 4 20:58:52 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13884 for ; Sun, 4 Feb 2001 20:58:51 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f1506al25908 for seamoby-list; Sun, 4 Feb 2001 16:06:36 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f1506Yo25902 for ; Sun, 4 Feb 2001 16:06:34 -0800 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 PAA19081; Sun, 4 Feb 2001 15:14:41 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f14NEc127310; Sun, 4 Feb 2001 15:14:38 -0800 X-Virus-Scanned: Sun, 4 Feb 2001 15:14:38 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdvv5fee; Sun, 04 Feb 2001 15:14:30 PST Message-ID: <3A7DE2A0.453F324D@iprg.nokia.com> Date: Sun, 04 Feb 2001 15:15:44 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: seamoby-mm@cdma-2000.org, seamoby@diameter.org, George Tsirtsis , "Basavaraj Patil (NTC/Dallas)" , Phil Roberts Subject: Re: [seamoby] Re: context transfer/fast MIP conflict (was: [seamoby-mm] FW: I-D ACTION:draft-designteam-fast-mipv6-00.txt) References: <01D91AFB08B6D211BFD00008C7EABAE10680A839@eseis04nok> <14972.26474.972825.310927@thomasm-u1.cisco.com> <3A7C88CD.BA373BC4@iprg.nokia.com> <14972.38725.417965.650464@thomasm-u1.cisco.com> <3A7CA09C.4CAAE1FE@iprg.nokia.com> <14972.45766.832605.237746@thomasm-u1.cisco.com> <3A7CB8FB.8DFD32C1@iprg.nokia.com> <14973.53062.314908.356967@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Michael, > > Well, in my route tables the IP address and the L2 address are > > the information that is important. Routing is stateful. That's > > obvious, > > so calling something "state" does not insert it into the exclusive realm > > of [seamoby-context]. > > By this definition, DHCP is a routing problem too. You use DHCP as an example related to determining whether MAC address usage distinguishes routing protocols from other protocols. We perhaps do agree that DHCP is not a routing protocol, and yet DHCP relays use the MAC address for routing purposes. I claim that this example is the exception that proves the rule, because DHCP relays have no other choice in this matter. Things are, of course, a lot better in IPv6 because there are link-local addresses available for use. Mobile IPv4 struggled with this problem, exactly because of the effects of MAC address resolution. While ARP is also not a routing protocol, routing is much more difficult without something like it. Furthermore, ARP and DHCP are not application protocols, and they are not context transfer protocols. Thus, I think that using the example of DHCP detracts from the validity of your argument in a very substantial way. > > > Wait a minute: I thought that the tunnel between > > > ARold and MN was no different than the tunnel > > > between HA and MN. That is, ARnew is no different > > > than any other router that might be in the > > > path between ARold and MN. ARold only needs to > > > consult its existing FIB to determine where to > > > forward the tunneled packets. > > > > We don't define FIB, and we never compared the tunnel > > between ARold and MN to that between the HA and MN. > > However, I don't see why you are insisting that they are > > different. The new draft will be much clearer in this matter. > > Please read what I actually write. This is the > second time that you've misconstrued something > that was not mistated. In order to avoid parsing hairs, I'll let this drop, since I gather you do not disagree with my statements even if they were incorrectly motivated. > And I still don't understand your previous comment > about "old AR sets up a route to the new AR". It > is my understanding that the new AR is just a > router like any other router in the path between > MN and ARold; that there is no reason to change > ARold's routing tables at all. Did you > misspeak, or is there something that I'm not > understanding? Well, I meant exactly that. Routers typically set up routes for particular (hosts-or-prefixes), and in this case the old router sets up a route for (destination == mobile node) that uses (next intermediate point == new access router). That is what I think I said, and I don't know if it was said in a way that was understandable to you. I believed that we were discussing ways to route packets to a mobile node undergoing handover. > > > AAA state, QoS state, etc, etc. > > > > AAA state and QoS state are required sometimes. > > I'm still not getting your point, though, unless you are saying > > that no solution is worth anything unless it solves everything > > all at once. > > No, I'm saying that I don't understand what > modularity is buying in this particular case, > and indeed, it may have significant downside. O.K. I claim that modularity is crucial for the overall design. Perhaps you will eventually come to the same conclusion. So far, in our implementation, there hasn't been any downside except possibly the need for a few more bytes of memory in certain framework data structures. > > > Regardless I > > > think the burden is still on the design team to > > > justify why ARnew needs to be involved in the > > > fast handoff in way that is related to routing. > > > Thus far haven't seen any reason which holds > > > any more weight than the things I just mentioned. > > > > How about if we involve ARnew it makes things faster? > > That's good enough for me, and it works. > > Great. If we do context transfer, it will be > faster still. That's specfically assuming that there is context to transfer, and that the context is in place for the purposes of performance enhancements that are relevant to handovers. > Can Destination Options be encrypted using ESP? > I was under the impression from the last IETF > that the answer was no (which I confess to > still not understanding the reason why). Here, we are entering the realm where few mortals dare to tread. I _think_, speaking as an avowed mortal, that the IESG suggests that "tunnel mode" with ESP is the right way to handle encrypting destination options. In order to get away from that, you have to have a payload in a "higher order protocol". That could be an ICMP payload, I believe, but more typically is a TCP or UDP payload. Please don't shoot me if I am wrong about this. > I'm proposing that MIP deliver its requirements > to SEAMOBY context transfer and then a suitable > protocol can be devised that meets all of the > requirements. This is a very clear statement, and thanks. I reckon that you'll have a hard time convincing the [mobile-ip] working group to delegate that charter item, though. > > It's preconfiguration of the _routing tables_ on ARnew. > > That's not what [seamoby] is supposed to deal with. > > Again, then DHCP is a routing protocol too. It > delivers static routes to hosts, and some > routers use the MAC/IP data going by to build > proxy ARP tables, blah blah blah. That blah blah blah is what routers do, and as I pointed out at the start of this note, it is an unfortunate (and very confrontational) part of DHCP that they had to mess with this. It has had continuing bad effects on other protocols. For instance, it's not perfectly clear how a mobile node should get its home agent to use DHCP for home address allocation, although people have done it in several different ways. > > Instead of railroading something, why don't you have > > a discussion about what's needed? You have a tool > > at your disposal. You can sharpen it, use it as it is, > > or discard it as unworthy. There's a lot of people > > around who would like to help. > > Um, the same can be said in reverse. Why are > you so disagreable to the notion of letting > SEAMOBY deal with the MIP context requirements? Actually, I am quite agreeable to exactly that mode of operation. However, Mobile IP doesn't have very much context requirement, as best I understand it. > Why is MIP any different than, say, RSVP, > Diffserv, AAA, RAP, IPsec, etc that need to > have state and/or coordination with ARnew to > achieve fast/smooth handoff? A good thing would be to identify and coalesce all the common needs. Why don't we make that our roadmap? > Right, but I think you can achieve vanilla > fast handoff without needing to create the > HI/HACK messages. Since SEAMOBY will be right > behind with the CT work which could > incorporate the shortcomings of "vanilla" > (as if there were, IMO :-), I don't see this > as risking an orphaned problem. My experience from the design team effort is that it's easier said than done, but even so I'll be very happy to see what you can come up with. We do not say our approach has no shortcomings. In fact, I could rattle off a few right away, but this is the wrong mailing list for it. I only claim that it is a very good approach that does what it is supposed to do without getting in your way. Regards, Charlie P. From owner-seamoby@diameter.org Sun Feb 4 21:39:43 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA15249 for ; Sun, 4 Feb 2001 21:39:41 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f151LXf26046 for seamoby-list; Sun, 4 Feb 2001 17:21:33 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f151LUo26040 for ; Sun, 4 Feb 2001 17:21:30 -0800 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 QAA05802; Sun, 4 Feb 2001 16:29:52 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT18624; Sun, 4 Feb 2001 16:29:38 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA00768; Sun, 4 Feb 2001 16:29:38 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14973.62450.411228.130495@thomasm-u1.cisco.com> Date: Sun, 4 Feb 2001 16:29:38 -0800 (PST) To: Charlie Perkins Cc: Michael Thomas , seamoby-mm@cdma-2000.org, seamoby@diameter.org, George Tsirtsis , "Basavaraj Patil (NTC/Dallas)" , Phil Roberts Subject: Re: [seamoby] Re: context transfer/fast MIP conflict (was: [seamoby-mm] FW: I-D ACTION:draft-designteam-fast-mipv6-00.txt) In-Reply-To: <3A7DE2A0.453F324D@iprg.nokia.com> References: <01D91AFB08B6D211BFD00008C7EABAE10680A839@eseis04nok> <14972.26474.972825.310927@thomasm-u1.cisco.com> <3A7C88CD.BA373BC4@iprg.nokia.com> <14972.38725.417965.650464@thomasm-u1.cisco.com> <3A7CA09C.4CAAE1FE@iprg.nokia.com> <14972.45766.832605.237746@thomasm-u1.cisco.com> <3A7CB8FB.8DFD32C1@iprg.nokia.com> <14973.53062.314908.356967@thomasm-u1.cisco.com> <3A7DE2A0.453F324D@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-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Charlie Perkins writes: > > And I still don't understand your previous comment > > about "old AR sets up a route to the new AR". It > > is my understanding that the new AR is just a > > router like any other router in the path between > > MN and ARold; that there is no reason to change > > ARold's routing tables at all. Did you > > misspeak, or is there something that I'm not > > understanding? > > Well, I meant exactly that. Routers typically set up routes > for particular (hosts-or-prefixes), and in this case the old router > sets up a route for (destination == mobile node) that uses > (next intermediate point == new access router). That is > what I think I said, and I don't know if it was said in a way > that was understandable to you. I believed that we were > discussing ways to route packets to a mobile node undergoing > handover. I'm still confused, so maybe I should be pedantic to make certain we're communicating here: Suppose that my home address is 11.12.13.14 and my current attachment point is 100.1.1.1, my next attachment point is 100.1.2.1. When I send a BU to the old AR to create a tunnel to my new care of address at 100.1.2.1, the format of the IP packets from the old AR will be: IPHdr: D:100.1.2.1 [D:11.12.13.14 ...] Correct? As such, _ARnew_ doesn't need to do anything extraordinary to route the tunneled packet to MN since from its perspective it's just an ordinary IP datagram that is reachable via whichever interface 100.1.2.0 points to. Correct? Thus, I don't understand what new routing state needs to be set up on ARnew: it's already there. What you seem to be implying above is that the tunnel endpoint is on ARnew instead of MN in which case I could understand why ARnew's routing tables need to be updated, but that's not what you mean is it? > > No, I'm saying that I don't understand what > > modularity is buying in this particular case, > > and indeed, it may have significant downside. > > O.K. I claim that modularity is crucial for the overall design. > Perhaps you will eventually come to the same conclusion. > So far, in our implementation, there hasn't been any > downside except possibly the need for a few more > bytes of memory in certain framework data structures. The downside I see is that if there needs to be two different messages exchanged between the AR's it may be pertinent to the overall latency of the handoff. I'm certainly open to modularity arguments -- I have no love for protocol reinvention -- but in this case, it seems that combining the two needs into one would not raise the modularity spectre. Since you don't seem to disagree with that -- since it was an explicit desire to be able to use HI/HACK for CT if appropriate -- our argument is only in who should choose the appropriate transport vessel for the goodies. I think it would be better to defer that decision and let SEAMOBY decide which is best for both in light of the full set of requirements. > > Can Destination Options be encrypted using ESP? > > I was under the impression from the last IETF > > that the answer was no (which I confess to > > still not understanding the reason why). > > Here, we are entering the realm where few mortals > dare to tread. I _think_, speaking as an avowed mortal, > that the IESG suggests that "tunnel mode" with ESP is > the right way to handle encrypting destination options. Bletch. > In order to get away from that, you have to have a payload > in a "higher order protocol". That could be an ICMP > payload, I believe, but more typically is a TCP or UDP > payload. Please don't shoot me if I am wrong about this. Right. Another reason to use a higher level protocol -- especially here -- is that we avoid playing the Stump Bellovin game :-) > > Why is MIP any different than, say, RSVP, > > Diffserv, AAA, RAP, IPsec, etc that need to > > have state and/or coordination with ARnew to > > achieve fast/smooth handoff? > > A good thing would be to identify and coalesce all the > common needs. Why don't we make that our roadmap? Yes, let's do. Mike From owner-seamoby@diameter.org Sun Feb 4 22:45:43 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA16580 for ; Sun, 4 Feb 2001 22:45:42 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f152dKS26296 for seamoby-list; Sun, 4 Feb 2001 18:39:20 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from m018.com ([210.112.11.138]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f152dAo26283 for ; Sun, 4 Feb 2001 18:39:11 -0800 Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Mon, 5 Feb 2001 10:24:21 +0900 Received: from charizard.diameter.org ([24.20.167.220]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Mon, 5 Feb 2001 09:54:41 +0900 Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f14I71925443 for seamoby-list; Sun, 4 Feb 2001 10:07:01 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f14I6xo25438 for ; Sun, 4 Feb 2001 10:06:59 -0800 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 f14HFCd02564 for ; Sun, 4 Feb 2001 18:15:13 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Sun Feb 04 18:16:16 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id <1CVZM7N3>; Sun, 4 Feb 2001 18:11:50 +0100 Message-ID: <034BEFD03799D411A59F00508BDF75465B6973@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Phil_Neumiller@3com.com'" Cc: seamoby@diameter.org Subject: RE: [seamoby] Single sentence problem statements Date: Sun, 4 Feb 2001 18:15:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-seamoby@diameter.org Precedence: bulk Hello Phil, Thanks for the detailed explanation. I hope you don't read too much criticism into my questions, I'm genuinely trying to understand the problem. Having said that I have some more comments on your statements below. > I think what you are getting at here is that you think that the SeaMoby MM > work > is > completely redundant with MIP fast handoff work right? > => Not quite :) I'm curious to know what we missed in the fast handoff work and I would gladly support a problem statement that shows fundamental problems in the MIP work that can not be fixed. > You may be absolutely > correct in the long wrong. Then again you could also be wrong. Part of > the > exercise the SeaMoby WG has been given by the IESG is to determine IF a > light weight micro-mobility protocol solves problems NOT solved by MIP or > perhaps solves problems in a more efficient way than MIP++. > => Again I fully support this, but part of your problem statement (signalling delays and number of signals over the air) are solved by MIP++, hence my question. > I don't think it > is safe to assume that all the SeaMoby micro-mobility design team members > have done a detailed examination of all the current fast handoff MIP > drafts. It > is my understanding that many of the people participating on the list have > a > cursory understanding of the fast handoff drafts (and if they don't, they > should > get one). Some folks on the list have brought up some problems that the > work in progress may have. I will try to recall some of them here. > > INT > Dana, > If your reading this thread, it might be nice to add a perceived problems > with > MIP(+fast handover) section to the problem statement draft. > IRET > > 1). There is a concern that A GFA/FA in every AP may not scale or even > be desirable in extremely inexpensive access point devices. > => Sure, but for V6 that would be a very simple and inexpensive router. There are products that support this already in cellular networks. > 2). There is a concern that putting an FA essentially everywhere would > add a lot of complication to what could be a relatively simple > micro- > mobility handover. > => Maybe, but so far this is V4 specific. I'm biased towards V6. > 3). There are some thoughts that micro-mobility could possibly be handled > completely my MNs (as I am sure have been discussed in MIP ad > nauseum in the past. => Ok, worth investigating. > Pat ,our chair, has a firm grasp on this issue, since one of his main > chores as > a WG chair is to avoid redundancy with other WGs. > > Perhaps if you examined the MM draft you would see that what is being done > in SeaMoby at this time is to articulate problems that MAY require > micro-mobility. It is not SeaMoby's current job to to examine existing, > proposed, > or dreamed up solutions. I am not sure I could ascertain from you > statements > what it is you wanted added to the SeaMoby micro-mobility problem > statement. > I have included the brief problem that I believe caught your eye for > reference. > => Ok I'll read the draft. My main concern was that to be able to articulate an accurate problem statement current solutions must be examined carefully and their weaknesses have to be shown. Otherwise you get people like me asking questions. I'm not trying to say the work is not needed, but I really can't understand how the first statement is correct in light of the current MIP++ work. Perhaps you were trying to make it short but it was too short for me to understand. One other concern I have is whether you are considering the impacts of supporting more than on mobility management scheme in the MN ? Perhaps I'll get some answers from the draft. From owner-seamoby@diameter.org Sun Feb 4 22:45:44 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA16591 for ; Sun, 4 Feb 2001 22:45:44 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f152d7626270 for seamoby-list; Sun, 4 Feb 2001 18:39:07 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from m018.com ([210.112.11.138]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f152cwo26242 for ; Sun, 4 Feb 2001 18:38:59 -0800 Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Mon, 5 Feb 2001 10:24:14 +0900 Received: from charizard.diameter.org ([24.20.167.220]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Mon, 5 Feb 2001 09:54:38 +0900 Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f14NIuu25825 for seamoby-list; Sun, 4 Feb 2001 15:18:56 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f14NIpo25815 for ; Sun, 4 Feb 2001 15:18:51 -0800 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 f14MR7C25741 for ; Sun, 4 Feb 2001 23:27:07 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Sun Feb 04 23:27:06 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id <1CVZM921>; Sun, 4 Feb 2001 23:23:44 +0100 Message-ID: <034BEFD03799D411A59F00508BDF75465B697E@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Michael Thomas'" Cc: seamoby-mm@cdma-2000.org, seamoby@diameter.org, "Basavaraj Patil (NTC/Dallas)" , Phil Roberts Subject: RE: [seamoby] Re: context transfer/fast MIP conflict (was: [seamo by-mm] FW: I-D ACTION:draft-designteam-fast-mipv6-00.txt) Date: Sun, 4 Feb 2001 23:27:05 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-seamoby@diameter.org Precedence: bulk I've removed people from the cc list to avoid receiving duplicates I know the're on the list already. > Hesham Soliman (ERA) writes: > > Now we are solving the routing part of the problem. No new > > COA means no routing. Obviously CT is still needed for a more > > complete solution. > > We had two possible options for sending this > > request-reply messages. Dest options or ICMP. After a long > > debate we thought ICMP is more appropriate since it allows > > for future extensions and MAY also be used by the CT team. > > Well, I'm glad to hear that you ditched the > Destination Option, > => Why ? > but as far as whether ICMP > is the right method, I think it's far to early > to guess. A few questions come immediately to > mind: > > 1) Do we need congestion avoidance? => Could you elaborate a bit on this ? I don't see the additional need here compared to other signalling flows. > 2) Do we need > MAX MTU contexts? > => So far we haven't seen the need. > 3) What are the security requirements? > => The HI/Ack MUST be authenticated. IPsec is used. > > > Now if that is a bad solution then we can always revert to > > destination options and leave the door open for highler level > > protocols for CT. > > Or you could feed the requirements to SEAMOBY > and have a single solution. > => I see. I have to disagree with this. As I said earlier we're trying to solve the problem of routing packets to and from the MN. Forming a new COA in a stateless manner poses a challenge to this routing problem. This is how we chose to solve it. I was also happy with doing DAD in parallel but this seemed to be a good way to do it for routers that can confirm that no duplication will take place. As to whether it should be done in SEAMOBY, well, I believe SEAMOBY is standardising the CT and not every message that is sent between ARs. Especially if the purpose of these messages is to enable the routing of packets. We are not transferring context really (like QoS, SAs ...etc). I think this discussion should be taken on the MIP list since it is a MIP draft. Hesham PS: This list is very slow. It takes me at least half an hour to get my email back ! From owner-seamoby@diameter.org Sun Feb 4 22:48:43 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA16602 for ; Sun, 4 Feb 2001 22:48:39 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f152dM326299 for seamoby-list; Sun, 4 Feb 2001 18:39:22 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from m018.com ([210.112.11.138]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f152dFo26290 for ; Sun, 4 Feb 2001 18:39:16 -0800 Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Mon, 5 Feb 2001 10:24:27 +0900 Received: from charizard.diameter.org ([24.20.167.220]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Mon, 5 Feb 2001 09:54:49 +0900 Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f143BHQ18986 for seamoby-list; Sat, 3 Feb 2001 19:11:17 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f143B6o18980 for ; Sat, 3 Feb 2001 19:11:06 -0800 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 SAA13540; Sat, 3 Feb 2001 18:19:11 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f142JAo02240; Sat, 3 Feb 2001 18:19:10 -0800 X-Virus-Scanned: Sat, 3 Feb 2001 18:19:10 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpd4Zy9Te; Sat, 03 Feb 2001 18:19:05 PST Message-ID: <3A7CB8FB.8DFD32C1@iprg.nokia.com> Date: Sat, 03 Feb 2001 18:05:47 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: seamoby-mm@cdma-2000.org, seamoby@diameter.org, George Tsirtsis , "Basavaraj Patil (NTC/Dallas)" , Phil Roberts Subject: Re: [seamoby] Re: context transfer/fast MIP conflict (was: [seamoby-mm] FW: I-D ACTION:draft-designteam-fast-mipv6-00.txt) References: <01D91AFB08B6D211BFD00008C7EABAE10680A839@eseis04nok> <14972.26474.972825.310927@thomasm-u1.cisco.com> <3A7C88CD.BA373BC4@iprg.nokia.com> <14972.38725.417965.650464@thomasm-u1.cisco.com> <3A7CA09C.4CAAE1FE@iprg.nokia.com> <14972.45766.832605.237746@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello again, > Fine. Since (polite) is in the eye of the > beholder, I'll just state my objections. > Consider this as input that I think that > MIP should not be defining a transport protocol > between AR's which has nothing to do with > routing. The matter seems to be that you don't accept our work as a routing protocol, and yet I think it very clearly is. Maybe that's the point worth elaborating, and I'll do so by inserting commentary below. > > We don't move CoAs. > > > > We don't move DAD state. > > You're splitting hairs. You're transporting the knowledge > of whether DAD would fail on ARnew. Only ARnew can determine that, and it matters to ARold because of the need to determine the destination IP address of the outer tunnel. That's routing. That's NOT transporting DAD state. I think this is obvious. > You're also transporting > Old CoA, New CoA, HomeAddress and L2 address in HI, and > new CoA in HACK. I don't see how you can rationalize that > Old, HomeAddress and L2 are not state knowledge that ARold > possess that ARnew doesn't. Well, in my route tables the IP address and the L2 address are the information that is important. Routing is stateful. That's obvious, so calling something "state" does not insert it into the exclusive realm of [seamoby-context]. I could make a better definition of "context" that would distinguish [seamoby-context] from routing, but evidence indicates that my effort would be about as useful to you as a burp in a scuba-diving suit We do not transport HomeAddress, that was fixed. > > The old AR sets up a route to the new AR by using > > HI. The new AR tells the old AR how to determine > > some details about its route table entry for the > > mobile node by using the HAck. > > Wait a minute: I thought that the tunnel between > ARold and MN was no different than the tunnel > between HA and MN. That is, ARnew is no different > than any other router that might be in the > path between ARold and MN. ARold only needs to > consult its existing FIB to determine where to > forward the tunneled packets. We don't define FIB, and we never compared the tunnel between ARold and MN to that between the HA and MN. However, I don't see why you are insisting that they are different. The new draft will be much clearer in this matter. > > > Fine, but why ought that not just be input > > > to the seamoby/context transfer? There are a *lot* > > > of other things than DAD that are required to > > > effect a fast/smooth handoff in reality. > > > > Please say what they are. > > AAA state, QoS state, etc, etc. AAA state and QoS state are required sometimes. I'm still not getting your point, though, unless you are saying that no solution is worth anything unless it solves everything all at once. > Regardless I > think the burden is still on the design team to > justify why ARnew needs to be involved in the > fast handoff in way that is related to routing. > Thus far haven't seen any reason which holds > any more weight than the things I just mentioned. How about if we involve ARnew it makes things faster? That's good enough for me, and it works. > > > Besides, I thought it was MN that did DAD? How > > > can AR know the difference between two different > > > MN's that have the same lower 64 bits? > > > > Which AR? Two mobile node's cannot have the same > > care-of address, nor the same link-local address. > > If the new AR finds out that a new mobile node is > > trying to use a care-of address that is already spoken > > for, then it should return an error in the HAck message. > > The only way that ARnew can tell that MN is trying > to use an already spoken for address is to > *transmit*. This assumption is not universally valid. A router has a neighbor cache. That cache has useful information for the determination we are discussing. > ARnew cannot know whether a receive > only MN (perhaps because it hasn't arrived) is > a duplicate. If a MN configures a duplicate > address and sends a fast handoff BU to ARold, > the only thing that will happen is that ARnew > will forward the packets arriving to the wrong > MN. C'est la guerre. This is not one of the scenarios we consider in the draft. I'm not sure how it is relevant to the current discussion. I could try to make it relevant by imagining further uses for HI/HAck, but that doesn't seem to help advance the discussion. > This is a reasonable thing to counter > with some communication between the two AR's, > but I don't see it as a reason for MIP to > design a handoff transport protocol in addition > to whatever SEAMOBY comes up with. O.K. I'm lost. Regarding your last sentence, I think it's obvious that the two efforts should be coordinated. I think it's also obvious that each bit of context is useful in fewer cases than the overall fast handover will be useful. Thus, waiting for [seamoby] to design particular context transfer mechanisms for particular bits of to context, before doing fast handover, would seem weird to me. Or, what were you proposing? > > > Again, there's a lot more than DAD which figure > > > into "work" vs. "not work". > > > > If it's for routing, then I hope we didn't miss it. > > My point, such as it is, is that what you've > got in there is *not* routing, per se. It's > pre-configuration of ARnew which is, I thought, > what SEAMOBY was supposed to deal with. It's preconfiguration of the _routing tables_ on ARnew. That's not what [seamoby] is supposed to deal with. > > The point is to do handovers as fast as possible. There are > > many scenarios under which signaling between the mobile node > > and the new AR is not possible. We reckon that signaling > > between the old AR and the new AR is always possible. > > In fact, we basically relegate to base Mobile IPv6 all > > scenarios under which the first signaling to/from the mobile > > node occurs at the new AR. Only when the old AR can > > help, can handovers be "faster" than base Mobile IPv6. > > Even if what you're thinking of is the MAP > stuff here, I don't see how that resolves > the conflict between SEAMOBY and MIP's > charter. In fact, I don't see how ARnew's > reachability by MN for signaling changes > anything at all in any case. MAP didn't cross my mind when I wrote the above paragraph. I don't know what to say to make it clearer. I reread the paragraph, and it says exactly that the fast handovers have only been designed for the case where the old AR can help speed the handover. That's what I think we _were_ supposed to do, and (again) I I thought that if the old AR can't help, then Mobile IPv6 was deemed to be sort-of good enough. Modulo context transfer, that is, which is what we were not supposed to be doing. > > I guess we tend to disagree on this point. In fact, to me > > it is clear that context transfer operations are specifically > > useful only when the context(s) exist. It is also clear that, > > for all values of context that I am aware of, useful systems > > can be built that use none of them. > > All you're really saying is that sometimes less > context needs to be transfered than other > times. Fine. I don't see that as a reason to > I either Shanghai SEAMOBY into using HI/HACK > as the transport vessel for context, or end > up with yet another protocol mechanism if > that is not agreeable. Instead of railroading something, why don't you have a discussion about what's needed? You have a tool at your disposal. You can sharpen it, use it as it is, or discard it as unworthy. There's a lot of people around who would like to help. > > In other words, > > vanilla fast handover is useful, contrary to your assertion. > > I've never said that. I said it's not adequate > for fast handoff in large set of cases. Namely, > oh say, where a service provider such as, oh > say, a cellular provider, needs AAA to happen > first before access is granted on ARnew, etc, etc. So we agree that vanilla fast handover is useful. I point out that is what we intended to design. You say it's not good enough for many cases. I hope to eventually see you point out the insufficiencies. > > You still didn't say what's wrong with HI/HAck. > > See above. I sure have been looking hard. Regards, Charlie P. From owner-seamoby@diameter.org Sun Feb 4 22:54:21 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA16632 for ; Sun, 4 Feb 2001 22:54:20 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f152dAu26278 for seamoby-list; Sun, 4 Feb 2001 18:39:10 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from m018.com ([210.112.11.138]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f152d2o26255 for ; Sun, 4 Feb 2001 18:39:03 -0800 Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Mon, 5 Feb 2001 10:24:15 +0900 Received: from charizard.diameter.org ([24.20.167.220]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Mon, 5 Feb 2001 09:54:51 +0900 Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f140Y4w18781 for seamoby-list; Sat, 3 Feb 2001 16:34:04 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f140Y2o18775 for ; Sat, 3 Feb 2001 16:34:02 -0800 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 PAA14838; Sat, 3 Feb 2001 15:42:12 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT18118; Sat, 3 Feb 2001 15:41:57 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA00468; Sat, 3 Feb 2001 15:41:57 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14972.38725.417965.650464@thomasm-u1.cisco.com> Date: Sat, 3 Feb 2001 15:41:57 -0800 (PST) To: Charlie Perkins Cc: Michael Thomas , seamoby-mm@cdma-2000.org, seamoby@diameter.org, George Tsirtsis , "Basavaraj Patil (NTC/Dallas)" , Phil Roberts Subject: [seamoby] Re: context transfer/fast MIP conflict (was: [seamoby-mm] FW: I-D ACTION:draft-designteam-fast-mipv6-00.txt) In-Reply-To: <3A7C88CD.BA373BC4@iprg.nokia.com> References: <01D91AFB08B6D211BFD00008C7EABAE10680A839@eseis04nok> <14972.26474.972825.310927@thomasm-u1.cisco.com> <3A7C88CD.BA373BC4@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-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Charlie Perkins writes: > I reckon I need to supply at least part of this answer. > Also, there is a very much improved version of the draft > that will be posted on Monday, resulting from our recent > two-day design meeting last week. It was a big success. > > The [mobile-ip] working group design team did this for > a lot of logical reasons (note that I do not speak for them, > and these comments must be considered my opinions > only): The MIP WG seems to be schizophrenic about what it sees as in its charter. When it punted the context transfer problem to SEAMOBY, it should have punted the *entire* problem, not just the parts that it didn't feel like working on. As it stands now, MIP WG has either decided for SEAMOBY what the appropriate transport vessel for context transfer is (a destination option strikes me as a giagantic hack), or define a different protocol which deals with everything but the few bits and dregs that MIP needed to affect "fast" handoff (read: fast in the narrow world view of MIP's charter). > - It is a routing protocol. [mobile-ip] is a working group > in the Routing Area. Yet, you're clearly defining a transport protocol to move CoA's, DAD state, etc. What, exactly, is HI/HACK doing to the _routing_ state of ARnew? > > I've read through this and I'm struck by the fact that > > the HI and HACK do not seem to have anything to do with > > the fast handoff Mobile IP problem at all. As far as I > > can tell, they are not required since the tunnel > > is established between ARold and MN. All ARnew is > > doing forwarding packets toward the subnet that > > it already knows how to forward to. > > HI provides information that the new AR needs > to avoid doing DAD. That's useful. Fine, but why ought that not just be input to the seamoby/context transfer? There are a *lot* of other things than DAD that are required to effect a fast/smooth handoff in reality. Besides, I thought it was MN that did DAD? How can AR know the difference between two different MN's that have the same lower 64 bits? > The new AR provides > information to the old AR, using HAck, about whether this > avoidance is going to work. Again, there's a lot more than DAD which figure into "work" vs. "not work". > I'm not sure about what you > meant in the last sentence. It means exactly what it says: ARnew's job is just to forward packets; it's not like it needs to terminate a tunnel or something. Any state which is a pre-condition to forwarding seems squarely within the problem that seamoby/context transfer is supposed to solve. > I also do NOT believe that we > make any statement anywhere about a tunnel between > the new AR and the mobile node. That's something which > would severely limit the applicability of our fast handover > protocol. I didn't say anything about a tunnel from ARnew to anything. > > Before people get up in arms that ARnew might not > > be willing to forward packets, I'll point out > > that that is a routing and/or admission control > > problem and seems squarely in the problem space > > that the context transfer design team seems to > > have in its charter. > > Right, if I understand you correctly. However, in many > circumstances the admission control policy is trivial. And in many cases it's complex. I don't see this as a reason to gratuitously come up with a protocol to solve that narrow problem. > > It appears to me that their work minus the > > HI/HACK does that just fine and that it would > > be better to keep the agreed upon problem > > partition intact so that the context transfer > > design is not needlessly hobbled by the design > > decisions which did not account for the larger > > problem. > > Without HI/HAck, there is no fast handover protocol. How so? Assuming can MN get the new subnet in a reasonable period of time, it can cons up its address and do parallel DAD as the draft suggests. What, exactly, prevents ARnew forwarding packets to MN? > Maybe I'm not getting the sense of your discussion. > No matter, I'll volunteer to try to bridge the gap in as > polite a way as possible. Now, where is my cane? Without the rest of context transfer, HI/HACK is inadequate in a large enough set of cases that SEAMOBY became a WG to set about finding a generalized mechanism to deal with the rest of those things that are necessary to perform fast/smooth handoffs. Mike From owner-seamoby@diameter.org Sun Feb 4 22:54:23 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA16643 for ; Sun, 4 Feb 2001 22:54:21 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f152cBK26176 for seamoby-list; Sun, 4 Feb 2001 18:38:11 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from m018.com ([210.112.11.138]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f152c7o26167 for ; Sun, 4 Feb 2001 18:38:07 -0800 Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Mon, 5 Feb 2001 10:23:47 +0900 Received: from charizard.diameter.org ([24.20.167.220]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Mon, 5 Feb 2001 09:54:53 +0900 Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f13NY5W18706 for seamoby-list; Sat, 3 Feb 2001 15:34:05 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f13NXwo18700 for ; Sat, 3 Feb 2001 15:33:58 -0800 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 OAA07197; Sat, 3 Feb 2001 14:42:03 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f13Mg0008993; Sat, 3 Feb 2001 14:42:00 -0800 X-Virus-Scanned: Sat, 3 Feb 2001 14:42:00 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdjV9zJJ; Sat, 03 Feb 2001 14:41:55 PST Message-ID: <3A7C88CD.BA373BC4@iprg.nokia.com> Date: Sat, 03 Feb 2001 14:40:13 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: seamoby-mm@cdma-2000.org, seamoby@diameter.org, George Tsirtsis , "Basavaraj Patil (NTC/Dallas)" , Phil Roberts Subject: [seamoby] Re: context transfer/fast MIP conflict (was: [seamoby-mm] FW: I-D ACTION:draft-designteam-fast-mipv6-00.txt) References: <01D91AFB08B6D211BFD00008C7EABAE10680A839@eseis04nok> <14972.26474.972825.310927@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I reckon I need to supply at least part of this answer. Also, there is a very much improved version of the draft that will be posted on Monday, resulting from our recent two-day design meeting last week. It was a big success. The [mobile-ip] working group design team did this for a lot of logical reasons (note that I do not speak for them, and these comments must be considered my opinions only): - The design does work with care-of addresses. Maybe it also works with other addresses. So much the better! I reckon you do not suggest we should have made needless restrictions - It is a routing protocol. [mobile-ip] is a working group in the Routing Area. - Everyone always knew that fast handovers should work with context transfers. If it is at all reassuring (?) whenever anyone in the design team mentioned context transfers, we were told not to be concerned with that because it was out of scope. Nevertheless, most people on the design team are aware of the general problem surrounding context transfer. - The network-controlled case is explicitly designed to provide information needed for care-of addresses. One of the things about Mobile IPv6 is that it uses natural IPv6 address configuration mechanisms to create care-of addresses. Thus, any protocol whatsoever that we might create for the expedient management of new care-of address assignment, would right away look like an expedient mechanism for managing new IPv6 address assignment. We had to solve the problem. We had a mandate to solve the problem. We went about it the most direct way we could figure out to do. I'm surprised if this makes anyone uncomfortable. On the contrary, I'd expect to a certain degree that other people might be happy we did the appropriate amount of analysis and engineering to come up with a useful solution. On your more specific statements... Michael Thomas wrote: > I've read through this and I'm struck by the fact that > the HI and HACK do not seem to have anything to do with > the fast handoff Mobile IP problem at all. As far as I > can tell, they are not required since the tunnel > is established between ARold and MN. All ARnew is > doing forwarding packets toward the subnet that > it already knows how to forward to. HI provides information that the new AR needs to avoid doing DAD. That's useful. The new AR provides information to the old AR, using HAck, about whether this avoidance is going to work. I'm not sure about what you meant in the last sentence. I also do NOT believe that we make any statement anywhere about a tunnel between the new AR and the mobile node. That's something which would severely limit the applicability of our fast handover protocol. > Before people get up in arms that ARnew might not > be willing to forward packets, I'll point out > that that is a routing and/or admission control > problem and seems squarely in the problem space > that the context transfer design team seems to > have in its charter. Right, if I understand you correctly. However, in many circumstances the admission control policy is trivial. > So my question is what justification the MIP > design team has for initiating what amounts to > the shell of a context transfer when their > charter was to figure out a way to provide a > way to provide fast mobility during movement? I think this amounts to an accusation of something, but I'm not quite sure what. Perhaps you would like to reconsider your demand in light of the foregoing explanations. > It appears to me that their work minus the > HI/HACK does that just fine and that it would > be better to keep the agreed upon problem > partition intact so that the context transfer > design is not needlessly hobbled by the design > decisions which did not account for the larger > problem. Without HI/HAck, there is no fast handover protocol. Maybe I'm not getting the sense of your discussion. No matter, I'll volunteer to try to bridge the gap in as polite a way as possible. Now, where is my cane? Regards, Charlie P. From owner-seamoby@diameter.org Sun Feb 4 22:55:19 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA16654 for ; Sun, 4 Feb 2001 22:55:16 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f152cM026189 for seamoby-list; Sun, 4 Feb 2001 18:38:22 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from m018.com ([210.112.11.138]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f152cJo26184 for ; Sun, 4 Feb 2001 18:38:19 -0800 Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Mon, 5 Feb 2001 10:23:52 +0900 Received: from charizard.diameter.org ([24.20.167.220]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Mon, 5 Feb 2001 09:54:56 +0900 Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f1384cX17587 for seamoby-list; Sat, 3 Feb 2001 00:04:38 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from NEPTUNE.zucotto.com ([216.95.209.154]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f1384ao17582 for ; Sat, 3 Feb 2001 00:04:36 -0800 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21) id ; Sat, 3 Feb 2001 02:12:45 -0500 Message-ID: From: Kulwinder Atwal To: "'Phil Neumiller'" , Gary Kenward Cc: "'Jukka Manner'" , seamoby Subject: RE: [seamoby] Re: New name -> Seamless to become Hidden Handover? ? Date: Sat, 3 Feb 2001 02:12:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk How does Real-Time Mobility sound in place of SeaMoby. Before commenting please read the below abstract written in 1997. It is un-canny how closely this abstract resembles to our current discussions. Real-Time Behaviour in a Heterogeneous Environment? E. Nett German National Research Center for Information Technology (GMD) Because of the availability of cheap network technology and computing power, people and business become increasingly dependent on computing systems. Timeliness and correctness, therefore, become the most urgently requested system properties, often subsumed in the notion of Quality of Service. Real-time computing is becoming an enabling technology for many important applications such as flexible manufacturing, multimedia, robotics and process control. Traditionally, real-time systems have been realized as isolated, embedded systems, dedicated to provide the requested service for single, dedicated applications like automatic brake systems in vehicles or control systems for nuclear plants. Unfortunately, the solutions provided there do no longer suffice for more complex systems as they are encountered in many of the above mentioned applications. Their most distinguishing requirement is the need of the computing system to dynamically adapt to changing conditions. Little work has been done on (operating) system mechanisms and algorithms, flexible enough to cope with the new requirements. Keywords: real-time systems, quality of service, scheduling, responsiveness Proceedings of the 3rd Workshop on Object-Oriented Real-Time Dependable Systems - (WORDS '97) Copyright (c) 1997 Institute of Electrical and Electronics Engineers, Inc. All rights reserved. And Real-Time handover in place of Hidden or Seamless. Real-time system: A system whose operation depends not just on the correctness but also the timeliness of the behaviour. Real-time handover: A handover where the result depends not just on the correctness but also the timeliness of the handover. Real-time mobility: The movement of micro-flows for mobile devices where the movement depends not just on the correctness but also the timeliness of the handover. I have the same reservations regarding "planned", and "unplanned" that others have stated. -Kulwinder. From owner-seamoby@diameter.org Sun Feb 4 22:55:30 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA16665 for ; Sun, 4 Feb 2001 22:55:29 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f152csH26223 for seamoby-list; Sun, 4 Feb 2001 18:38:54 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from m018.com ([210.112.11.138]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f152coo26216 for ; Sun, 4 Feb 2001 18:38:51 -0800 Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Mon, 5 Feb 2001 10:24:06 +0900 Received: from charizard.diameter.org ([24.20.167.220]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Mon, 5 Feb 2001 09:54:46 +0900 Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f142X9g18925 for seamoby-list; Sat, 3 Feb 2001 18:33:09 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f142X7o18919 for ; Sat, 3 Feb 2001 18:33:07 -0800 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 RAA08180; Sat, 3 Feb 2001 17:39:32 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT18159; Sat, 3 Feb 2001 17:39:19 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA00473; Sat, 3 Feb 2001 17:39:19 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14972.45766.832605.237746@thomasm-u1.cisco.com> Date: Sat, 3 Feb 2001 17:39:18 -0800 (PST) To: Charlie Perkins Cc: Michael Thomas , seamoby-mm@cdma-2000.org, seamoby@diameter.org, George Tsirtsis , "Basavaraj Patil (NTC/Dallas)" , Phil Roberts Subject: [seamoby] Re: context transfer/fast MIP conflict (was: [seamoby-mm] FW: I-D ACTION:draft-designteam-fast-mipv6-00.txt) In-Reply-To: <3A7CA09C.4CAAE1FE@iprg.nokia.com> References: <01D91AFB08B6D211BFD00008C7EABAE10680A839@eseis04nok> <14972.26474.972825.310927@thomasm-u1.cisco.com> <3A7C88CD.BA373BC4@iprg.nokia.com> <14972.38725.417965.650464@thomasm-u1.cisco.com> <3A7CA09C.4CAAE1FE@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-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Charlie Perkins writes: > > As it stands now, MIP > > WG has either decided for SEAMOBY what the > > appropriate transport vessel for context transfer > > is (a destination option strikes me as a giagantic > > hack), or define a different protocol which deals > > with everything but the few bits and dregs that > > MIP needed to affect "fast" handoff (read: fast in > > the narrow world view of MIP's charter). > > Well, this statement wrong (and perhaps even > offensive) on several counts: > - We only have a draft, not a decision > - We are only a design team, not the working group > - Your (polite) inputs are welcome, and could > change the design Fine. Since (polite) is in the eye of the beholder, I'll just state my objections. Consider this as input that I think that MIP should not be defining a transport protocol between AR's which has nothing to do with routing. > > Yet, you're clearly defining a transport protocol > > to move CoA's, DAD state, etc. What, exactly, is > > HI/HACK doing to the _routing_ state of ARnew? > > This is also wrong. > > We don't move CoAs. > > We don't move DAD state. You're splitting hairs. You're transporting the knowledge of whether DAD would fail on ARnew. You're also transporting Old CoA, New CoA, HomeAddress and L2 address in HI, and new CoA in HACK. I don't see how you can rationalize that Old, HomeAddress and L2 are not state knowledge that ARold possess that ARnew doesn't. > The old AR sets up a route to the new AR by using > HI. The new AR tells the old AR how to determine > some details about its route table entry for the > mobile node by using the HAck. Wait a minute: I thought that the tunnel between ARold and MN was no different than the tunnel between HA and MN. That is, ARnew is no different than any other router that might be in the path between ARold and MN. ARold only needs to consult its existing FIB to determine where to forward the tunneled packets. > > Fine, but why ought that not just be input > > to the seamoby/context transfer? There are a *lot* > > of other things than DAD that are required to > > effect a fast/smooth handoff in reality. > > Please say what they are. AAA state, QoS state, etc, etc. Regardless I think the burden is still on the design team to justify why ARnew needs to be involved in the fast handoff in way that is related to routing. Thus far haven't seen any reason which holds any more weight than the things I just mentioned. > > Besides, I thought it was MN that did DAD? How > > can AR know the difference between two different > > MN's that have the same lower 64 bits? > > Which AR? Two mobile node's cannot have the same > care-of address, nor the same link-local address. > If the new AR finds out that a new mobile node is > trying to use a care-of address that is already spoken > for, then it should return an error in the HAck message. The only way that ARnew can tell that MN is trying to use an already spoken for address is to *transmit*. ARnew cannot know whether a receive only MN (perhaps because it hasn't arrived) is a duplicate. If a MN configures a duplicate address and sends a fast handoff BU to ARold, the only thing that will happen is that ARnew will forward the packets arriving to the wrong MN. C'est la guerre. This is a reasonable thing to counter with some communication between the two AR's, but I don't see it as a reason for MIP to design a handoff transport protocol in addition to whatever SEAMOBY comes up with. > > Again, there's a lot more than DAD which figure > > into "work" vs. "not work". > > If it's for routing, then I hope we didn't miss it. My point, such as it is, is that what you've got in there is *not* routing, per se. It's pre-configuration of ARnew which is, I thought, what SEAMOBY was supposed to deal with. > > > Without HI/HAck, there is no fast handover protocol. > > > > How so? Assuming can MN get the new subnet in a > > reasonable period of time, it can cons up its > > address and do parallel DAD as the draft suggests. > > What, exactly, prevents ARnew forwarding packets > > to MN? > > The point is to do handovers as fast as possible. There are > many scenarios under which signaling between the mobile node > and the new AR is not possible. We reckon that signaling > between the old AR and the new AR is always possible. > In fact, we basically relegate to base Mobile IPv6 all > scenarios under which the first signaling to/from the mobile > node occurs at the new AR. Only when the old AR can > help, can handovers be "faster" than base Mobile IPv6. Even if what you're thinking of is the MAP stuff here, I don't see how that resolves the conflict between SEAMOBY and MIP's charter. In fact, I don't see how ARnew's reachability by MN for signaling changes anything at all in any case. > A mobile node cannot receive packets on the new subnet > at its new care-of address until DAD is done. That could > take a while. Even with short-cuts, we would need a > retransmission algorithm, and we would be introducing > additional traffic between entities at a bad time. Yet, section 5.1 suggests that the MN does DAD in parallel while using the address anyway which seems eminently reasonable to me. > I guess we tend to disagree on this point. In fact, to me > it is clear that context transfer operations are specifically > useful only when the context(s) exist. It is also clear that, > for all values of context that I am aware of, useful systems > can be built that use none of them. All you're really saying is that sometimes less context needs to be transfered than other times. Fine. I don't see that as a reason to I either Shanghai SEAMOBY into using HI/HACK as the transport vessel for context, or end up with yet another protocol mechanism if that is not agreeable. > In other words, > vanilla fast handover is useful, contrary to your assertion. I've never said that. I said it's not adequate for fast handoff in large set of cases. Namely, oh say, where a service provider such as, oh say, a cellular provider, needs AAA to happen first before access is granted on ARnew, etc, etc. > You still didn't say what's wrong with HI/HAck. See above. Mike From owner-seamoby@diameter.org Sun Feb 4 22:57:25 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA16687 for ; Sun, 4 Feb 2001 22:57:19 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f152d9O26272 for seamoby-list; Sun, 4 Feb 2001 18:39:09 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from m018.com ([210.112.11.138]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f152d0o26247 for ; Sun, 4 Feb 2001 18:39:00 -0800 Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Mon, 5 Feb 2001 10:24:18 +0900 Received: from charizard.diameter.org ([24.20.167.220]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Mon, 5 Feb 2001 09:54:54 +0900 Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f13L9in18555 for seamoby-list; Sat, 3 Feb 2001 13:09:44 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f13L9go18549 for ; Sat, 3 Feb 2001 13:09:42 -0800 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 MAA29788; Sat, 3 Feb 2001 12:18:03 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT18016; Sat, 3 Feb 2001 12:17:47 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA00462; Sat, 3 Feb 2001 12:17:47 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14972.26474.972825.310927@thomasm-u1.cisco.com> Date: Sat, 3 Feb 2001 12:17:46 -0800 (PST) To: john.loughney@nokia.com Cc: seamoby-mm@cdma-2000.org, seamoby@diameter.org Subject: [seamoby] context transfer/fast MIP conflict (was: [seamoby-mm] FW: I-D ACTION:draft-designteam-fast-mipv6-00.txt) In-Reply-To: <01D91AFB08B6D211BFD00008C7EABAE10680A839@eseis04nok> References: <01D91AFB08B6D211BFD00008C7EABAE10680A839@eseis04nok> 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-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit [why is it that John's always the shot messenger? :)] john.loughney@nokia.com writes: > Hi all, > > This is probably a good thing for all of us to read. I've read through this and I'm struck by the fact that the HI and HACK do not seem to have anything to do with the fast handoff Mobile IP problem at all. As far as I can tell, they are not required since the tunnel is established between ARold and MN. All ARnew is doing forwarding packets toward the subnet that it already knows how to forward to. Before people get up in arms that ARnew might not be willing to forward packets, I'll point out that that is a routing and/or admission control problem and seems squarely in the problem space that the context transfer design team seems to have in its charter. So my question is what justification the MIP design team has for initiating what amounts to the shell of a context transfer when their charter was to figure out a way to provide a way to provide fast mobility during movement? It appears to me that their work minus the HI/HACK does that just fine and that it would be better to keep the agreed upon problem partition intact so that the context transfer design is not needlessly hobbled by the design decisions which did not account for the larger problem. Mike From owner-seamoby@diameter.org Sun Feb 4 23:08:16 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA16732 for ; Sun, 4 Feb 2001 23:08:14 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f152c6A26148 for seamoby-list; Sun, 4 Feb 2001 18:38:06 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from m018.com ([210.112.11.138]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f152bwo26143 for ; Sun, 4 Feb 2001 18:37:58 -0800 Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Mon, 5 Feb 2001 10:23:41 +0900 Received: from charizard.diameter.org ([24.20.167.220]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Mon, 5 Feb 2001 09:54:40 +0900 Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f14MjBv25752 for seamoby-list; Sun, 4 Feb 2001 14:45:11 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f14Mj5o25746 for ; Sun, 4 Feb 2001 14:45:05 -0800 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 NAA19989; Sun, 4 Feb 2001 13:53:27 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT18541; Sun, 4 Feb 2001 13:53:10 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA00757; Sun, 4 Feb 2001 13:53:10 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14973.53062.314908.356967@thomasm-u1.cisco.com> Date: Sun, 4 Feb 2001 13:53:10 -0800 (PST) To: Charlie Perkins Cc: Michael Thomas , seamoby-mm@cdma-2000.org, seamoby@diameter.org, George Tsirtsis , "Basavaraj Patil (NTC/Dallas)" , Phil Roberts Subject: Re: [seamoby] Re: context transfer/fast MIP conflict (was: [seamoby-mm] FW: I-D ACTION:draft-designteam-fast-mipv6-00.txt) In-Reply-To: <3A7CB8FB.8DFD32C1@iprg.nokia.com> References: <01D91AFB08B6D211BFD00008C7EABAE10680A839@eseis04nok> <14972.26474.972825.310927@thomasm-u1.cisco.com> <3A7C88CD.BA373BC4@iprg.nokia.com> <14972.38725.417965.650464@thomasm-u1.cisco.com> <3A7CA09C.4CAAE1FE@iprg.nokia.com> <14972.45766.832605.237746@thomasm-u1.cisco.com> <3A7CB8FB.8DFD32C1@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-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Charlie Perkins writes: > > You're splitting hairs. You're transporting the knowledge > > of whether DAD would fail on ARnew. > > Only ARnew can determine that, and it matters to ARold > because of the need to determine the destination IP address > of the outer tunnel. > > That's routing. That's NOT transporting DAD state. I think > this is obvious. Well, I don't think it's obvious at all. > > You're also transporting > > Old CoA, New CoA, HomeAddress and L2 address in HI, and > > new CoA in HACK. I don't see how you can rationalize that > > Old, HomeAddress and L2 are not state knowledge that ARold > > possess that ARnew doesn't. > > Well, in my route tables the IP address and the L2 address are > the information that is important. Routing is stateful. That's > obvious, > so calling something "state" does not insert it into the exclusive realm > of [seamoby-context]. By this definition, DHCP is a routing problem too. > > Wait a minute: I thought that the tunnel between > > ARold and MN was no different than the tunnel > > between HA and MN. That is, ARnew is no different > > than any other router that might be in the > > path between ARold and MN. ARold only needs to > > consult its existing FIB to determine where to > > forward the tunneled packets. > > We don't define FIB, and we never compared the tunnel > between ARold and MN to that between the HA and MN. > However, I don't see why you are insisting that they are > different. The new draft will be much clearer in this matter. Please read what I actually write. This is the second time that you've misconstrued something that was not mistated. And I still don't understand your previous comment about "old AR sets up a route to the new AR". It is my understanding that the new AR is just a router like any other router in the path between MN and ARold; that there is no reason to change ARold's routing tables at all. Did you misspeak, or is there something that I'm not understanding? > > AAA state, QoS state, etc, etc. > > AAA state and QoS state are required sometimes. > I'm still not getting your point, though, unless you are saying > that no solution is worth anything unless it solves everything > all at once. No, I'm saying that I don't understand what modularity is buying in this particular case, and indeed, it may have significant downside. > > Regardless I > > think the burden is still on the design team to > > justify why ARnew needs to be involved in the > > fast handoff in way that is related to routing. > > Thus far haven't seen any reason which holds > > any more weight than the things I just mentioned. > > How about if we involve ARnew it makes things faster? > That's good enough for me, and it works. Great. If we do context transfer, it will be faster still. Whether we think this was a great split or not, the AD's decided to partition the problem this way. All I'm asking is that we not end up with a bifurcation because MIP WG (or their design team) could rationalize *some* of the needed state transfer within the MIP context. > Regarding your last sentence, I think it's obvious that the > two efforts should be coordinated. I think it's also obvious > that each bit of context is useful in fewer cases than the > overall fast handover will be useful. Thus, waiting for > [seamoby] to design particular context transfer mechanisms > for particular bits of to context, before doing fast handover, > would seem weird to me. Can Destination Options be encrypted using ESP? I was under the impression from the last IETF that the answer was no (which I confess to still not understanding the reason why). If so, by coding MIP's needs as a destination option, you have either forced a new protocol for context transfer to be devised, or made the job doing a context transfer harder by requiring it to needlessly devise an application layer encryption scheme. > Or, what were you proposing? I'm proposing that MIP deliver its requirements to SEAMOBY context transfer and then a suitable protocol can be devised that meets all of the requirements. > > My point, such as it is, is that what you've > > got in there is *not* routing, per se. It's > > pre-configuration of ARnew which is, I thought, > > what SEAMOBY was supposed to deal with. > > It's preconfiguration of the _routing tables_ on ARnew. > That's not what [seamoby] is supposed to deal with. Again, then DHCP is a routing protocol too. It delivers static routes to hosts, and some routers use the MAC/IP data going by to build proxy ARP tables, blah blah blah. You think this is cut and dry. I don't. > Instead of railroading something, why don't you have > a discussion about what's needed? You have a tool > at your disposal. You can sharpen it, use it as it is, > or discard it as unworthy. There's a lot of people > around who would like to help. Um, the same can be said in reverse. Why are you so disagreable to the notion of letting SEAMOBY deal with the MIP context requirements? Why is MIP any different than, say, RSVP, Diffserv, AAA, RAP, IPsec, etc that need to have state and/or coordination with ARnew to achieve fast/smooth handoff? > So we agree that vanilla fast handover is useful. I point out > that is what we intended to design. You say it's not good enough > for many cases. I hope to eventually see you point out the > insufficiencies. Right, but I think you can achieve vanilla fast handoff without needing to create the HI/HACK messages. Since SEAMOBY will be right behind with the CT work which could incorporate the shortcomings of "vanilla" (as if there were, IMO :-), I don't see this as risking an orphaned problem. Mike From owner-seamoby@diameter.org Sun Feb 4 23:08:21 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA16747 for ; Sun, 4 Feb 2001 23:08:20 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f152cDk26182 for seamoby-list; Sun, 4 Feb 2001 18:38:13 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from m018.com ([210.112.11.138]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f152cBo26177 for ; Sun, 4 Feb 2001 18:38:11 -0800 Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Mon, 5 Feb 2001 10:23:49 +0900 Received: from charizard.diameter.org ([24.20.167.220]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Mon, 5 Feb 2001 09:54:48 +0900 Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f141Js818836 for seamoby-list; Sat, 3 Feb 2001 17:19:54 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f141Jqo18830 for ; Sat, 3 Feb 2001 17:19:52 -0800 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 QAA10475; Sat, 3 Feb 2001 16:27:57 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f140RtP07336; Sat, 3 Feb 2001 16:27:55 -0800 X-Virus-Scanned: Sat, 3 Feb 2001 16:27:55 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpd8Xkpwq; Sat, 03 Feb 2001 16:27:50 PST Message-ID: <3A7CA09C.4CAAE1FE@iprg.nokia.com> Date: Sat, 03 Feb 2001 16:21:48 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: seamoby-mm@cdma-2000.org, seamoby@diameter.org, George Tsirtsis , "Basavaraj Patil (NTC/Dallas)" , Phil Roberts Subject: [seamoby] Re: context transfer/fast MIP conflict (was: [seamoby-mm] FW: I-D ACTION:draft-designteam-fast-mipv6-00.txt) References: <01D91AFB08B6D211BFD00008C7EABAE10680A839@eseis04nok> <14972.26474.972825.310927@thomasm-u1.cisco.com> <3A7C88CD.BA373BC4@iprg.nokia.com> <14972.38725.417965.650464@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello again, > The MIP WG seems to be schizophrenic about what it > sees as in its charter. When it punted the context > transfer problem to SEAMOBY, it should have punted > the *entire* problem, not just the parts that it > didn't feel like working on. You ought to ask the area directors about this. I agree that context transfer is important during fast handovers, and nevertheless I also agree that a division of labor is possible and perhaps even desirable. However, the desirability will depend on the results. > As it stands now, MIP > WG has either decided for SEAMOBY what the > appropriate transport vessel for context transfer > is (a destination option strikes me as a giagantic > hack), or define a different protocol which deals > with everything but the few bits and dregs that > MIP needed to affect "fast" handoff (read: fast in > the narrow world view of MIP's charter). Well, this statement wrong (and perhaps even offensive) on several counts: - We only have a draft, not a decision - We are only a design team, not the working group - Your (polite) inputs are welcome, and could change the design - A (?narrow, ?circumscribed, ?focussed, ?practical) world view does sometimes help to get things done. - There is a hell of a lot of work to do besides just bits and dregs. If you think otherwise, then please produce the "dregs draft" to show how easy it is. > > - It is a routing protocol. [mobile-ip] is a working group > > in the Routing Area. > > Yet, you're clearly defining a transport protocol > to move CoA's, DAD state, etc. What, exactly, is > HI/HACK doing to the _routing_ state of ARnew? This is also wrong. We don't move CoAs. We don't move DAD state. The old AR sets up a route to the new AR by using HI. The new AR tells the old AR how to determine some details about its route table entry for the mobile node by using the HAck. Is there some particular thing that can be explained better so that communication will be possible? > Fine, but why ought that not just be input > to the seamoby/context transfer? There are a *lot* > of other things than DAD that are required to > effect a fast/smooth handoff in reality. Please say what they are. > Besides, I thought it was MN that did DAD? How > can AR know the difference between two different > MN's that have the same lower 64 bits? Which AR? Two mobile node's cannot have the same care-of address, nor the same link-local address. If the new AR finds out that a new mobile node is trying to use a care-of address that is already spoken for, then it should return an error in the HAck message. > > The new AR provides > > information to the old AR, using HAck, about whether this > > avoidance is going to work. > > Again, there's a lot more than DAD which figure > into "work" vs. "not work". If it's for routing, then I hope we didn't miss it. If it's for context, then I hope that [seamboby] won't miss it. Maybe QoS is context, or maybe it's network-layer, but I reckon that there is so far some tacit agreement to treat it as context. If you suggest that additional errors should be defined for the HAck message, I'm sure people will be willing to believe you. I can imagine errors to the effect that admission control has failed, or that resources are unavailable for particular QoS contexts. > > I'm not sure about what you > > meant in the last sentence. > > It means exactly what it says: ARnew's job is just > to forward packets; it's not like it needs to > terminate a tunnel or something. Any state which > is a pre-condition to forwarding seems squarely > within the problem that seamoby/context transfer > is supposed to solve. Then I agree with both of your clarifications, and do not see any contradiction to HI/HAck. > I didn't say anything about a tunnel from ARnew > to anything. You are right. You said something about a tunnel from ARold to the mobile node, and I reached the wrong conclusion. > > Right, if I understand you correctly. However, in many > > circumstances the admission control policy is trivial. > > And in many cases it's complex. I don't see this > as a reason to gratuitously come up with a > protocol to solve that narrow problem. Of course we didn't come up with such a protocol, gratuitous or otherwise. That would be the work of [seamoby-context], presumably. > > Without HI/HAck, there is no fast handover protocol. > > How so? Assuming can MN get the new subnet in a > reasonable period of time, it can cons up its > address and do parallel DAD as the draft suggests. > What, exactly, prevents ARnew forwarding packets > to MN? The point is to do handovers as fast as possible. There are many scenarios under which signaling between the mobile node and the new AR is not possible. We reckon that signaling between the old AR and the new AR is always possible. In fact, we basically relegate to base Mobile IPv6 all scenarios under which the first signaling to/from the mobile node occurs at the new AR. Only when the old AR can help, can handovers be "faster" than base Mobile IPv6. A mobile node cannot receive packets on the new subnet at its new care-of address until DAD is done. That could take a while. Even with short-cuts, we would need a retransmission algorithm, and we would be introducing additional traffic between entities at a bad time. There are a lot of details. > Without the rest of context transfer, HI/HACK is > inadequate in a large enough set of cases that > SEAMOBY became a WG to set about finding a > generalized mechanism to deal with the rest of > those things that are necessary to perform > fast/smooth handoffs. I guess we tend to disagree on this point. In fact, to me it is clear that context transfer operations are specifically useful only when the context(s) exist. It is also clear that, for all values of context that I am aware of, useful systems can be built that use none of them. In other words, vanilla fast handover is useful, contrary to your assertion. You still didn't say what's wrong with HI/HAck. Regards, Charlie P. From owner-seamoby@diameter.org Sun Feb 4 23:08:24 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA16750 for ; Sun, 4 Feb 2001 23:08:21 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f152dGi26289 for seamoby-list; Sun, 4 Feb 2001 18:39:16 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from m018.com ([210.112.11.138]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f152d8o26271 for ; Sun, 4 Feb 2001 18:39:08 -0800 Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Mon, 5 Feb 2001 10:24:27 +0900 Received: from charizard.diameter.org ([24.20.167.220]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Mon, 5 Feb 2001 09:54:44 +0900 Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f14ILKG25468 for seamoby-list; Sun, 4 Feb 2001 10:21:20 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f14ILIo25463 for ; Sun, 4 Feb 2001 10:21:18 -0800 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 f14HTXd03569 for ; Sun, 4 Feb 2001 18:29:33 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Sun Feb 04 18:29:33 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id <1CVMXX9P>; Sun, 4 Feb 2001 18:29:33 +0100 Message-ID: <034BEFD03799D411A59F00508BDF75465B6974@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Patrice Calhoun'" Cc: seamoby@diameter.org Subject: RE: [seamoby] Single sentence problem statements Date: Sun, 4 Feb 2001 18:29:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-seamoby@diameter.org Precedence: bulk > > > > Pat ,our chair, has a firm grasp on this issue, since one of his main chores > > as a WG chair is to avoid redundancy with other WGs. > > Correct, and one of the co-authors of the v4 fast handoff work, so I am quite > familiar with the ongoing work :) > > I believe that the MM folks have raised some interesting questions about > MIPv6's reliance on IPSec, and the fact that a fast handoff will require an > IKE exchange. So, minimizing such exchanges will in fact provide the perceived > fast handoff :) Of course, the MM folks could explain what they are doing much > better than I could (I am just an observer). > => We most certainly do not want the handover to require a new IKE exchange and I don't understand how it would. I'm surprised these concerns were raised. The concerns are not valid because MIPv6 mandates that the SA be established based on the Home address. Hence, when moving no new SAs are required to update the HA and CNs. As for updating the previous AR, yes an SA is required but there are two solutions we investigated in MIP to solve this : 1. If you're using a flat mobility management model (no MAP) then we were counting on SEAMOBY to transfer the SA from the old AR to the new one. I think this is a very valid solution. 2. If a MAP exists, the MN establishes an SA only when moving between two MAP domains. Therefore the SA establishment will be very rare, depending on the size of the MAP domain. In other words, depending on how many ARs are advertising a MAP option. As for IKE and whether it's too heavy, spectrum inefficient ..etc please have a look at draft-soliman-mobileip-routeopt--mipv6-00.txt which proposes an alternative. Hesham From owner-seamoby@diameter.org Sun Feb 4 23:08:44 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA16781 for ; Sun, 4 Feb 2001 23:08:43 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f152clZ26211 for seamoby-list; Sun, 4 Feb 2001 18:38:47 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from m018.com ([210.112.11.138]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f152cho26201 for ; Sun, 4 Feb 2001 18:38:43 -0800 Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Mon, 5 Feb 2001 10:24:01 +0900 Received: from charizard.diameter.org ([24.20.167.220]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Mon, 5 Feb 2001 09:54:43 +0900 Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f14IvoA25511 for seamoby-list; Sun, 4 Feb 2001 10:57:50 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f14Ivjo25500 for ; Sun, 4 Feb 2001 10:57:45 -0800 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 f14I60d06872 for ; Sun, 4 Feb 2001 19:06:00 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Sun Feb 04 19:05:59 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id <1CVZM7XV>; Sun, 4 Feb 2001 19:02:37 +0100 Message-ID: <034BEFD03799D411A59F00508BDF75465B6975@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Charlie Perkins'" , Michael Thomas Cc: seamoby-mm@cdma-2000.org, seamoby@diameter.org, George Tsirtsis , "Basavaraj Patil (NTC/Dallas)" , Phil Roberts Subject: RE: [seamoby] Re: context transfer/fast MIP conflict (was: [seamo by-mm] FW: I-D ACTION:draft-designteam-fast-mipv6-00.txt) Date: Sun, 4 Feb 2001 19:05:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-seamoby@diameter.org Precedence: bulk Hello, First of all I'd like to state that there is a new draft that will appear in a couple of days, this draft is much clearer and hopefully it will explain a bit more what we're trying to achieve. The draft will however still contain the HI/Ack messages hence this email. Now, let me try to explain why these messages exist and see if we can get some feedback. I hope we can keep this discussion constructive. IPv6 allows the MNs to get a new COA when attaching to the new AR, however this requires DAD. DAD can take up to 2 seconds. If you strictly folow RFC 2462, then the MN can not receive or send packets during that period. Not very fast is it ! The draft is based on anticipation, the MN anticipates its new COA and sends BUs based on that anticipated address. So we had to work around RFC 2462: - If the new AR has knowledge of all MNs connected to it, then this knowledge can be used to immediately know whether the MN's address is valid or not. This would require a request-reply message from the old AR to the new one. The option of doing DAD in parallel was there but in view of the new approach (coming out in the new draft) it may not be needed. Now we are solving the routing part of the problem. No new COA means no routing. Obviously CT is still needed for a more complete solution. We had two possible options for sending this request-reply messages. Dest options or ICMP. After a long debate we thought ICMP is more appropriate since it allows for future extensions and MAY also be used by the CT team. Now if that is a bad solution then we can always revert to destination options and leave the door open for highler level protocols for CT. But we need to know why it's bad and why CT will be done differently. So far we haven't heard any reasons because the work of the CT team is not done yet. So nothing is set in stone. As far as I'm aware no one was trying to "take over" the context transfer work. So I don't see any need for being concerned about that. I hope we can cooperate in this area as it is obviously needed by both WGs. Hesham From owner-seamoby@diameter.org Mon Feb 5 00:46:32 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA17834 for ; Mon, 5 Feb 2001 00:46:31 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f154Jco26479 for seamoby-list; Sun, 4 Feb 2001 20:19:38 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from zcars04e (h56s242a129n47.user.nortelnetworks.com [47.129.242.56]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f154Jao26474 for ; Sun, 4 Feb 2001 20:19:36 -0800 Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e; Sun, 4 Feb 2001 13:58:46 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id ; Sun, 4 Feb 2001 13:58:46 -0500 Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8C0D@zwdld001.ca.nortel.com> From: "Gary Kenward" To: "'Phil Neumiller'" Cc: "'Jukka Manner'" , Phil_Neumiller , seamoby Subject: RE: [seamoby] Re: New name -> Seamless to become Hidden Handover? ? Date: Sun, 4 Feb 2001 13:58:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08EDC.7F2BCC60" X-Orig: Sender: owner-seamoby@diameter.org Precedence: bulk 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_01C08EDC.7F2BCC60 Content-Type: text/plain; charset="ISO-8859-1" > -----Original Message----- > From: Phil Neumiller [mailto:neumiller@telocity.com] > Sent: Friday, February 02, 2001 9:12 PM > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: 'Jukka Manner'; Phil_Neumiller; seamoby > Subject: Re: [seamoby] Re: New name -> Seamless to become Hidden > Handover? ? > > > > Gary Kenward wrote: > > > > > (these are the rough thresholds where TCP starts to act up) > > This is interesting Gary. As an aside, what would happen if > we tunnelled TCP and UDP over SCTP to avoid these strange > things? (I KNOW ITS SOLUTION SPACE!!!!) And don't forget MPLS...RTP=>UDP=>SCTP=>IP=>MPLS=>? And people complain about the cell tax...;^} > > > > > HiHo, HiHo, it's off to work we go... > > > > I feel like I'm in a Disney movie. We don't need a new term. > > seamless works fine enough. > > > Yeah, I guess its time to kill the Disney references (even though > I could could have claimed the "Grumpy" dwarf name). Seamless > is overloaded, but we might as well build a black hole for it > here in SeaMoby. Perhaps we can get the MIP guys to stop using > the term sooooo very much??? :-) They seem to use it like a > marketing term for their fast handoff work which in the SeaMoby > sense is nowhere near Seamless, go figure. > Ok, how about Proactive Handoff? > > > > > > > the IP layer's network interface changes, i.e.. a HO from a > > > 3G network to a WLAN, > > > > the HO is noticed, at least the user will see this. > > > > > > > > pdn>If its a vertical HO, and the COA must change, it is no > > > > No. > pdn>Yes... I should have not added the comma, I meant > vertical + COA change > pdn>not vertical => COA change. > > >As I pointed out to Jukka, a COA will change only if the > > veridical handoff is inter-network. > pdn>Of course. and there are bound to be lots of both types in the > pdn>near future > > >>>but CT > > > team is definitely > > pdn>Yes I did indicate this. > > > > > > > But isn't an inter-technology HO, that still maintains > > > the context of > > > the MH a HiHo? > pdn>Yeah but HiHo is dead, lets call it CMobyHO or seamoby HO or > pdn>something. PLEASE SOMEBODY GIVE US AN ACRONYM for SEAMOBY > pdn>MICROMOBILITY HANDOVER. HiHo is too flaky. THO is not PC. > pdn>CMobHO? CMbyHo? IDHO (intra-domain handover)??????????? ProHo? > > > > If we do a HO from some 3G tech to WLAN and > > > keep the QoS, > > > wouldn't that still be a HiHo? Or do we need a new term to > > > define that HO: > > > > > > "Context-aware" HO: context+seamless+including inter-tech ? > > No. Lets just have uno name for the seamoby HO. We let MIP > folks do their own thing as far as naming goes when CT is involved. > > > Put another way, we need to describe the complex problem space by > > identifying and defining a sparse set of independent definitions. > > So, the definitions provide a "basis" for our space. The problem > statements our set of theorems. Gary, do you have a mathematics > background per chance? Often your verbage strikes me as that of > a mathematician.... Hmmm. Thanks for the complement... > > TNX, > > -pdn (N9FCW) Gary > ------_=_NextPart_001_01C08EDC.7F2BCC60 Content-Type: text/html; charset="ISO-8859-1" RE: [seamoby] Re: New name -> Seamless to become Hidden Handover? ?

> -----Original Message-----
> From: Phil Neumiller [mailto:neumiller@telocity.com]
> Sent: Friday, February 02, 2001 9:12 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'Jukka Manner'; Phil_Neumiller; seamoby
> Subject: Re: [seamoby] Re: New name -> Seamless to become Hidden
> Handover? ?
>
>
> > Gary Kenward wrote:
> > >
> > (these are the rough thresholds where TCP starts to act up)
>
> This is interesting Gary.  As an aside, what would happen if
> we tunnelled TCP and UDP over SCTP to avoid these strange
> things?  (I KNOW ITS SOLUTION SPACE!!!!)

And don't forget MPLS...RTP=>UDP=>SCTP=>IP=>MPLS=>?
And people complain about the cell tax...;^}

>
> >
> > HiHo, HiHo, it's off to work we go...
> >
> > I feel like I'm in a Disney movie. We don't need a new term.
> > seamless works fine enough.
>
> <pdn>
> Yeah, I guess its time to kill the Disney references (even though
> I could could have claimed the "Grumpy" dwarf name).  Seamless
> is overloaded, but we might as well build a black hole for it
> here in SeaMoby.  Perhaps we can get the MIP guys to stop using
> the term sooooo very much??? :-)  They seem to use it like a
> marketing term for their fast handoff work which in the SeaMoby
> sense is nowhere near Seamless, go figure.
> </pdn>

Ok, how about Proactive Handoff?

>
> >
> > > > the IP layer's network interface changes, i.e.. a HO from a
> > > 3G network to a WLAN,
> > > > the HO is noticed, at least the user will see this.
> > > >
> > > > pdn>If its a vertical HO, and the COA must change, it is no
> >
> > No.
> pdn>Yes... I should have not added the comma, I meant
> vertical + COA change
> pdn>not vertical => COA change.
>
> >As I pointed out to Jukka, a COA will change only if the
> > veridical handoff is inter-network.
> pdn>Of course.  and there are bound to be lots of both types in the
> pdn>near future
>
> >>>but CT
> > > team is definitely
>
> pdn>Yes I did indicate this.
>
> > >
> > >       But isn't an inter-technology HO, that still maintains
> > > the context of
> > > the MH a HiHo?
> pdn>Yeah but HiHo is dead, lets call it CMobyHO or seamoby HO or
> pdn>something.  PLEASE SOMEBODY GIVE US AN ACRONYM for SEAMOBY
> pdn>MICROMOBILITY HANDOVER.  HiHo is too flaky.  THO is not PC.
> pdn>CMobHO?  CMbyHo?  IDHO (intra-domain handover)???????????

ProHo?

>
> > > If we do a HO from some 3G tech to WLAN and
> > > keep the QoS,
> > > wouldn't that still be a HiHo? Or do we need a new term to
> > > define that HO:
> > >
> > > "Context-aware" HO: context+seamless+including inter-tech ?
>
> No.  Lets just have uno name for the seamoby HO.  We let MIP
> folks do their own thing as far as naming goes when CT is involved.
> 
> > Put another way, we need to describe the complex problem space by
> > identifying and defining a sparse set of independent definitions.
>
> So, the definitions provide a "basis" for our space.  The problem
> statements our set of theorems.  Gary, do you have a mathematics
> background per chance?  Often your verbage strikes me as that of
> a mathematician....

Hmmm. Thanks for the complement...

>
> TNX,
>
> -pdn (N9FCW)

Gary

>

------_=_NextPart_001_01C08EDC.7F2BCC60-- From owner-seamoby@diameter.org Mon Feb 5 01:14:36 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA19160 for ; Mon, 5 Feb 2001 01:14:36 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f154jtH26524 for seamoby-list; Sun, 4 Feb 2001 20:45:55 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f154jro26518 for ; Sun, 4 Feb 2001 20:45:53 -0800 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 TAA28354; Sun, 4 Feb 2001 19:54:00 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f153rvk31465; Sun, 4 Feb 2001 19:53:57 -0800 X-Virus-Scanned: Sun, 4 Feb 2001 19:53:57 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdJPxy6G; Sun, 04 Feb 2001 19:53:49 PST Message-ID: <3A7E241B.A5AF6100@iprg.nokia.com> Date: Sun, 04 Feb 2001 19:55:07 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: seamoby-mm@cdma-2000.org, seamoby@diameter.org, George Tsirtsis , "Basavaraj Patil (NTC/Dallas)" , Phil Roberts Subject: Re: [seamoby] Re: context transfer/fast MIP conflict (was: [seamoby-mm] FW: I-D ACTION:draft-designteam-fast-mipv6-00.txt) References: <01D91AFB08B6D211BFD00008C7EABAE10680A839@eseis04nok> <14972.26474.972825.310927@thomasm-u1.cisco.com> <3A7C88CD.BA373BC4@iprg.nokia.com> <14972.38725.417965.650464@thomasm-u1.cisco.com> <3A7CA09C.4CAAE1FE@iprg.nokia.com> <14972.45766.832605.237746@thomasm-u1.cisco.com> <3A7CB8FB.8DFD32C1@iprg.nokia.com> <14973.53062.314908.356967@thomasm-u1.cisco.com> <3A7DE2A0.453F324D@iprg.nokia.com> <14973.62450.411228.130495@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello again, > Suppose that my home address is 11.12.13.14 and > my current attachment point is 100.1.1.1, my > next attachment point is 100.1.2.1. When I send > a BU to the old AR to create a tunnel to my > new care of address at 100.1.2.1, the format > of the IP packets from the old AR will be: > > IPHdr: D:100.1.2.1 [D:11.12.13.14 ...] Check. > Correct? As such, _ARnew_ doesn't need to do anything > extraordinary to route the tunneled packet to MN > since from its perspective it's just an ordinary > IP datagram that is reachable via whichever interface > 100.1.2.0 points to. Correct? Check. > Thus, I don't understand what new routing state > needs to be set up on ARnew: it's already there. No, what needs to be set up is that ARnew needs to know the MAC address for the mobile node, and ARnew needs to confirm that 100.1.2.0 is not already in use by some other mobile node. > What you seem to be implying above is that the tunnel > endpoint is on ARnew instead of MN in which case > I could understand why ARnew's routing tables > need to be updated, but that's not what you > mean is it? No, the tunnel endpoint is MN as you originally thought. However, in order for MN to actually use its new care-of address without suffering the rigors of DAD and ND, special arrangements have to be made at ARnew, and the logical seat of authority for those arrangements is ARold. > ... our argument is only in > who should choose the appropriate transport > vessel for the goodies. I think it would be > better to defer that decision and let SEAMOBY > decide which is best for both in light of the > full set of requirements. On the other hand, other people do not feel this way. Nothing has been set into stone, although I think that the design team has a good design. If after due consideration it turns out to be incompatible with whatever [seamoby-context] decides has to be done simultaneously with HI/HAck, then why don't we fix the problem then instead of going into paralysis mode now? Regards, Charlie P. From owner-seamoby@diameter.org Mon Feb 5 09:32:34 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06788 for ; Mon, 5 Feb 2001 09:32:33 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f15DF8f27597 for seamoby-list; Mon, 5 Feb 2001 05:15:08 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f15DF4o27586 for ; Mon, 5 Feb 2001 05:15:04 -0800 Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Feb 2001 07:23:12 -0500 Message-ID: From: George Tsirtsis To: seamoby-mm@cdma-2000.org, seamoby@diameter.org Subject: RE: [seamoby] Re: context transfer/fast MIP conflict (was: [seamo by-mm] FW: I-D ACTION:draft-designteam-fast-mipv6-00.txt) Date: Mon, 5 Feb 2001 07:23:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi all, I think we should all relax and take a deep breath... The new draft of the design team will by out on Tuesday or Wednesday (the latest) this week. As Charlie and Hesham have indicated it is going to be significantly different from v00. I think we should all wait for this draft so we can have a reasonable discussion on something specific rather than some of you trying to guess what we have done and the design team trying to explain mechanisms over e-mail instead of pointing to a draft. George -----Original Message----- From: Charlie Perkins [mailto:charliep@iprg.nokia.com] Sent: Monday, February 05, 2001 3:55 AM To: Michael Thomas Cc: seamoby-mm@cdma-2000.org; seamoby@diameter.org; George Tsirtsis; Basavaraj Patil (NTC/Dallas); Phil Roberts Subject: Re: [seamoby] Re: context transfer/fast MIP conflict (was: [seamoby-mm] FW: I-D ACTION:draft-designteam-fast-mipv6-00.txt) Hello again, > Suppose that my home address is 11.12.13.14 and > my current attachment point is 100.1.1.1, my > next attachment point is 100.1.2.1. When I send > a BU to the old AR to create a tunnel to my > new care of address at 100.1.2.1, the format > of the IP packets from the old AR will be: > > IPHdr: D:100.1.2.1 [D:11.12.13.14 ...] Check. > Correct? As such, _ARnew_ doesn't need to do anything > extraordinary to route the tunneled packet to MN > since from its perspective it's just an ordinary > IP datagram that is reachable via whichever interface > 100.1.2.0 points to. Correct? Check. > Thus, I don't understand what new routing state > needs to be set up on ARnew: it's already there. No, what needs to be set up is that ARnew needs to know the MAC address for the mobile node, and ARnew needs to confirm that 100.1.2.0 is not already in use by some other mobile node. > What you seem to be implying above is that the tunnel > endpoint is on ARnew instead of MN in which case > I could understand why ARnew's routing tables > need to be updated, but that's not what you > mean is it? No, the tunnel endpoint is MN as you originally thought. However, in order for MN to actually use its new care-of address without suffering the rigors of DAD and ND, special arrangements have to be made at ARnew, and the logical seat of authority for those arrangements is ARold. > ... our argument is only in > who should choose the appropriate transport > vessel for the goodies. I think it would be > better to defer that decision and let SEAMOBY > decide which is best for both in light of the > full set of requirements. On the other hand, other people do not feel this way. Nothing has been set into stone, although I think that the design team has a good design. If after due consideration it turns out to be incompatible with whatever [seamoby-context] decides has to be done simultaneously with HI/HAck, then why don't we fix the problem then instead of going into paralysis mode now? Regards, Charlie P. From owner-seamoby@diameter.org Mon Feb 5 10:29:23 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09072 for ; Mon, 5 Feb 2001 10:29:23 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f15EOSP27882 for seamoby-list; Mon, 5 Feb 2001 06:24:28 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f15EOPo27877 for ; Mon, 5 Feb 2001 06:24:25 -0800 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA20982; Mon, 5 Feb 2001 05:31:33 -0800 (PST) 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 FAA17835; Mon, 5 Feb 2001 05:31:33 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id FAA23270; Mon, 5 Feb 2001 05:31:31 -0800 (PST) Date: Mon, 5 Feb 2001 05:31:31 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [seamoby] Re: New name -> Seamless to become Hidden Handover? ? To: Phil Neumiller Cc: Gary Kenward , "'Jukka Manner'" , Phil_Neumiller , seamoby In-Reply-To: "Your message with ID" <3A7B68F0.10F065A0@telocity.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk > This is interesting Gary. As an aside, what would happen if > we tunnelled TCP and UDP over SCTP to avoid these strange > things? (I KNOW ITS SOLUTION SPACE!!!!) Tunneling a reliable transport over a reliable transport is evil. Let's not go there... > Yeah, I guess its time to kill the Disney references (even though > I could could have claimed the "Grumpy" dwarf name). Seamless > is overloaded, but we might as well build a black hole for it > here in SeaMoby. Perhaps we can get the MIP guys to stop using > the term sooooo very much??? :-) They seem to use it like a > marketing term for their fast handoff work which in the SeaMoby > sense is nowhere near Seamless, go figure. Having participated heavily in the MIP work, I have *never* heard anyone use the term seamless. The only term that I know of that was used is fast. PatC From owner-seamoby@diameter.org Mon Feb 5 12:30:40 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12490 for ; Mon, 5 Feb 2001 12:30:39 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f15GGKT28120 for seamoby-list; Mon, 5 Feb 2001 08:16:20 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f15GF3o28115 for ; Mon, 5 Feb 2001 08:15:03 -0800 Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f15FM5106907; Mon, 5 Feb 2001 07:22:05 -0800 (PST) Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104]) by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f15FNHA02011; Mon, 5 Feb 2001 07:23:17 -0800 (PST) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 882569EA.0054A99B ; Mon, 5 Feb 2001 07:24:44 -0800 X-Lotus-FromDomain: 3COM From: Phil_Neumiller@3Com.com To: Patrice Calhoun cc: seamoby@diameter.org Message-ID: <882569EA.0054A7B8.00@hqoutbound.ops.3com.com> Date: Mon, 5 Feb 2001 09:30:48 -0600 Subject: Re: [seamoby] Re: New name -> Seamless to become Hidden Handover? ? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-seamoby@diameter.org Precedence: bulk Comments below. Please respond to Patrice Calhoun > This is interesting Gary. As an aside, what would happen if > we tunnelled TCP and UDP over SCTP to avoid these strange > things? (I KNOW ITS SOLUTION SPACE!!!!) Tunneling a reliable transport over a reliable transport is evil. Let's not go there... pdn>Hmm. Last time I checked there was nothing reliable about pdn>a tunnel composed of datagrams between two ARs (which might pdn>in fact be mobile). Also, reliable is an end-to-end concept pdn>and does not mean squat to the path of potentially mobile pdn>routers between the end points. So tell me more about pdn>this great evil Pat so I can be sure to avoid it. :-) > They seem to use it like a > marketing term Having participated heavily in the MIP work, I have *never* heard anyone use the term seamless. The only term that I know of that was used is fast. pdn>Huh? Look again. Do you want me to dig up the references? pdn>(Maybe its more prevalent in the v6 and HMIP than v4). From owner-seamoby@diameter.org Mon Feb 5 12:55:48 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12995 for ; Mon, 5 Feb 2001 12:55:47 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f15GeJ328186 for seamoby-list; Mon, 5 Feb 2001 08:40:19 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f15GeHo28181 for ; Mon, 5 Feb 2001 08:40:17 -0800 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA18409; Mon, 5 Feb 2001 07:48:29 -0800 (PST) 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 HAA04734; Mon, 5 Feb 2001 07:48:29 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA24187; Mon, 5 Feb 2001 07:48:25 -0800 (PST) Date: Mon, 5 Feb 2001 07:48:25 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [seamoby] Re: New name -> Seamless to become Hidden Handover? ? To: Phil_Neumiller@3Com.com Cc: Patrice Calhoun , seamoby@diameter.org In-Reply-To: "Your message with ID" <882569EA.0054A7B8.00@hqoutbound.ops.3com.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk > > > Comments below. > > > > Please respond to Patrice Calhoun > > > > > This is interesting Gary. As an aside, what would happen if > > we tunnelled TCP and UDP over SCTP to avoid these strange > > things? (I KNOW ITS SOLUTION SPACE!!!!) > > Tunneling a reliable transport over a reliable transport is evil. Let's not > go there... > > pdn>Hmm. Last time I checked there was nothing reliable about > pdn>a tunnel composed of datagrams between two ARs (which might > pdn>in fact be mobile). Also, reliable is an end-to-end concept > pdn>and does not mean squat to the path of potentially mobile > pdn>routers between the end points. So tell me more about > pdn>this great evil Pat so I can be sure to avoid it. :-) Let me try again. SCTP Retransmitting a TCP transmission doesn't sound like a great idea to me. This comment was a result of your TCP over SCTP proposal above. > > > They seem to use it like a > > marketing term > > Having participated heavily in the MIP work, I have *never* heard anyone use > the term seamless. The only term that I know of that was used is fast. > > pdn>Huh? Look again. Do you want me to dig up the references? > pdn>(Maybe its more prevalent in the v6 and HMIP than v4). ok, I'll look deeper into the v6 stuff, but I haven't seen any on the list. PatC From owner-seamoby@diameter.org Mon Feb 5 13:22:46 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13501 for ; Mon, 5 Feb 2001 13:22:45 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f15GRhE28152 for seamoby-list; Mon, 5 Feb 2001 08:27:43 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from cisco.com (flipper.cisco.com [171.69.25.141]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f15GRao28147 for ; Mon, 5 Feb 2001 08:27:36 -0800 Received: from dblair-pc (ssh-sj1.cisco.com [171.68.225.134]) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with SMTP id HAA06383; Mon, 5 Feb 2001 07:35:38 -0800 (PST) Message-Id: <4.1.20010205093844.00a10e50@flipper.cisco.com> X-Sender: dblair@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 05 Feb 2001 09:40:25 -0500 To: George Tsirtsis , seamoby-mm@cdma-2000.org, seamoby@diameter.org From: Dana Blair Subject: Re: [seamoby-mm] RE: [seamoby] Re: context transfer/fast MIP conflict (was: [seamoby-mm] FW: I-D ACTION:draft-designteam-fast-mipv6-00.txt) In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-seamoby@diameter.org Precedence: bulk At 07:23 AM 2/5/01 -0500, George Tsirtsis wrote: >Hi all, > >I think we should all relax and take a deep breath... >The new draft of the design team will by out on Tuesday or Wednesday (the >latest) this week. As Charlie and Hesham have indicated it is going to be >significantly different from v00. I think we should all wait for this draft >so we can have a reasonable discussion on something specific rather than >some of you trying to guess what we have done and the design team trying to >explain mechanisms over e-mail instead of pointing to a draft. > >George I concur with George's statement. While discussion of solutions is desireable and we all would like to jump to that point, we really need to focus on defining problem statement and other sections of the draft and get the IESG endorsement to continue. thanks, Dana > > > > > >-----Original Message----- >From: Charlie Perkins [mailto:charliep@iprg.nokia.com] >Sent: Monday, February 05, 2001 3:55 AM >To: Michael Thomas >Cc: seamoby-mm@cdma-2000.org; seamoby@diameter.org; George Tsirtsis; >Basavaraj Patil (NTC/Dallas); Phil Roberts >Subject: Re: [seamoby] Re: context transfer/fast MIP conflict (was: >[seamoby-mm] FW: I-D ACTION:draft-designteam-fast-mipv6-00.txt) > > >Hello again, > >> Suppose that my home address is 11.12.13.14 and >> my current attachment point is 100.1.1.1, my >> next attachment point is 100.1.2.1. When I send >> a BU to the old AR to create a tunnel to my >> new care of address at 100.1.2.1, the format >> of the IP packets from the old AR will be: >> >> IPHdr: D:100.1.2.1 [D:11.12.13.14 ...] > >Check. > >> Correct? As such, _ARnew_ doesn't need to do anything >> extraordinary to route the tunneled packet to MN >> since from its perspective it's just an ordinary >> IP datagram that is reachable via whichever interface >> 100.1.2.0 points to. Correct? > >Check. > >> Thus, I don't understand what new routing state >> needs to be set up on ARnew: it's already there. > >No, what needs to be set up is that ARnew needs >to know the MAC address for the mobile node, and >ARnew needs to confirm that 100.1.2.0 is not already >in use by some other mobile node. > >> What you seem to be implying above is that the tunnel >> endpoint is on ARnew instead of MN in which case >> I could understand why ARnew's routing tables >> need to be updated, but that's not what you >> mean is it? > >No, the tunnel endpoint is MN as you originally thought. >However, in order for MN to actually use its new care-of >address without suffering the rigors of DAD and ND, >special arrangements have to be made at ARnew, and >the logical seat of authority for those arrangements is >ARold. > >> ... our argument is only in >> who should choose the appropriate transport >> vessel for the goodies. I think it would be >> better to defer that decision and let SEAMOBY >> decide which is best for both in light of the >> full set of requirements. > >On the other hand, other people do not feel this way. >Nothing has been set into stone, although I think that >the design team has a good design. If after due >consideration it turns out to be incompatible with >whatever [seamoby-context] decides has to be done >simultaneously with HI/HAck, then why don't we fix >the problem then instead of going into paralysis mode >now? > >Regards, >Charlie P. > From owner-seamoby@diameter.org Mon Feb 5 13:39:58 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13984 for ; Mon, 5 Feb 2001 13:39:58 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f15HTaU28330 for seamoby-list; Mon, 5 Feb 2001 09:29:36 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f15HTYo28325 for ; Mon, 5 Feb 2001 09:29:34 -0800 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA29211; Mon, 5 Feb 2001 08:37:46 -0800 (PST) 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 IAA13237; Mon, 5 Feb 2001 08:37:41 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id IAA24846; Mon, 5 Feb 2001 08:37:39 -0800 (PST) Date: Mon, 5 Feb 2001 08:37:39 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [seamoby] Re: New name -> Seamless to become Hidden Handover? ? To: Phil_Neumiller@3Com.com Cc: Patrice Calhoun , seamoby@diameter.org In-Reply-To: "Your message with ID" <882569EA.005AE579.00@hqoutbound.ops.3com.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk > SCTP Retransmitting a TCP transmission doesn't sound like a great idea to me. > This comment was a result of your TCP over SCTP proposal above. > > pdn>Yes this sounds like a really bad idea on the surface. It seems to > violate the > pdn>end-to-end principle, etc. It really has nothing to do with end-to-end (or anymore than existing tunneling mechanisms). > However, if we are assuming edge devices that > pdn>have really lousy connections that come and go (like wireless for > instance) pdn>this starts to make more sense. If we assume routers you are > right on! Let me put it this way. If congestion is occuring, why do you want to further congest the network by retransmitting TCP retransmissions??? Here is an example (Rn is the retransmission number): TCP:R0(Packet)------> SCTP:R0(TCP:R0(Packet))------> SCTP:R1(TCP:R0(Packet))------> TCP:R1(Packet)------> SCTP:R0(TCP:R1(Packet))------> SCTP:R2(TCP:R0(Packet))------> SCTP:R1(TCP:R1(Packet))------> Ad Nauseum See what I mean, now? PatC From owner-seamoby@diameter.org Mon Feb 5 13:43:19 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14074 for ; Mon, 5 Feb 2001 13:43:19 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f15HUfv28348 for seamoby-list; Mon, 5 Feb 2001 09:30:41 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f15HUdo28343 for ; Mon, 5 Feb 2001 09:30:39 -0800 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 IAA01059; Mon, 5 Feb 2001 08:38:53 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f15Gcp602851; Mon, 5 Feb 2001 08:38:51 -0800 X-Virus-Scanned: Mon, 5 Feb 2001 08:38:51 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdeMPoWa; Mon, 05 Feb 2001 08:38:46 PST Message-ID: <3A7ED717.F0F2D5A2@iprg.nokia.com> Date: Mon, 05 Feb 2001 08:38:47 -0800 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: seamoby@diameter.org Subject: Re: [seamoby] Upcoming REAL IP for Bluetooth BOF References: <3A723A69.7BA73F9D@telocity.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Phil, ..... > 1). REAL SIMPLE ad hoc networking capabilities, i.e. limited it to a few > hops so you don't have to worry about the scalability of flooding > algorithms, etc. The MANET group has been focused on esoteric > routing algorithm optimization and is in gridlock. We need simple > IP based ad hoc networking. This is an area that Bluetooth can > take a leadership role for future local wireless technologies. .... other points deleted .... It's fine if Bluetooth can take a leadership role, but it's not fine to maintain that [manet] is in gridlock. Indeed, there has been concrete progress reported at every IETF. As an engineer involved with one of the protocols (AODV), and with my own certainty that it is applicable to Bluetooth, I need to at least point out that your opinion, Phil, is not universally shared. I don't remember any message from you on the [manet] mailing list to suggest improvements, either, so slurs on other mailing lists seem at least inappropriate. Furthermore, regarding "esoteric"... Scalability is good. You are right that limiting networks to a few hops makes life simpler in the short run, but then you have the problem that sooner rather than later your whole technology will run out of steam. Then you have the field upgrade problem sooner rather than later. This is all a matter of economics, of course. But the cost for scalability is very much worthwhile if little or no additional complication is involved. I wish you would be more specific about what you think is wrong, at least with AODV. What is needed more than anything now is some new ideas about application interfaces in an ad-hoc network. Now that we have routing protocols, how do we fix the largely broken client-server paradigm which doesn't hold up so well in the ad-hoc world? Even DNS is hard (actually, it's especially hard). I believe that [zeroconf] has some applicable idea on this. There should be more cross-pollination between [manet] and [zeroconf]. It will happen a lot sooner with people who are willing to make the effort to harmonize instead of issuing blanket condemnations. Regards, Charlie P. From owner-seamoby@diameter.org Mon Feb 5 13:43:47 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14093 for ; Mon, 5 Feb 2001 13:43:45 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f15Gsjb28235 for seamoby-list; Mon, 5 Feb 2001 08:54:45 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from zcars04e (h56s242a129n47.user.nortelnetworks.com [47.129.242.56]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f15Gsho28230 for ; Mon, 5 Feb 2001 08:54:43 -0800 Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e; Mon, 5 Feb 2001 11:02:45 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 5 Feb 2001 11:02:45 -0500 Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8C12@zwdld001.ca.nortel.com> From: "Gary Kenward" To: "'seamoby'" , seamoby_context@standards.nortelnetworks.com, "'seamoby-mm'" Subject: [seamoby] spam Date: Mon, 5 Feb 2001 11:02:16 -0500 Sensitivity: Company-Confidential MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain; charset="ISO-8859-1" X-Orig: Sender: owner-seamoby@diameter.org Precedence: bulk I have to note, through a perverse love of irony, that while single spam message generated great consternation on these mail lists, the fact that there are often up to 6 copies of every posting seems of no great concern. Maybe everyone is just happy receiving at least one copy? Gary From owner-seamoby@diameter.org Mon Feb 5 13:54:21 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14368 for ; Mon, 5 Feb 2001 13:54:20 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f15HfHc28375 for seamoby-list; Mon, 5 Feb 2001 09:41:17 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from zcars04e (h56s242a129n47.user.nortelnetworks.com [47.129.242.56]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f15HfEo28370 for ; Mon, 5 Feb 2001 09:41:14 -0800 Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e; Mon, 5 Feb 2001 11:49:11 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 5 Feb 2001 11:49:11 -0500 Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8C13@zwdld001.ca.nortel.com> From: "Gary Kenward" To: seamoby Subject: RE: [seamoby] Re: New name -> Seamless to become Hidden Handover? ? Date: Mon, 5 Feb 2001 11:49:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08F93.8F0C0CF0" X-Orig: Sender: owner-seamoby@diameter.org Precedence: bulk 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_01C08F93.8F0C0CF0 Content-Type: text/plain; charset="ISO-8859-1" > -----Original Message----- > From: Patrice Calhoun [mailto:pcalhoun@nasnfs.eng.sun.com] > Sent: Monday, February 05, 2001 8:32 AM > To: Phil Neumiller > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; 'Jukka Manner'; Phil_Neumiller; > seamoby > Subject: Re: [seamoby] Re: New name -> Seamless to become Hidden > Handover? ? > > > > > This is interesting Gary. As an aside, what would happen if > > we tunnelled TCP and UDP over SCTP to avoid these strange > > things? (I KNOW ITS SOLUTION SPACE!!!!) > > Tunneling a reliable transport over a reliable transport is > evil. Let's not go > there... > > > Yeah, I guess its time to kill the Disney references (even though > > I could could have claimed the "Grumpy" dwarf name). Seamless > > is overloaded, but we might as well build a black hole for it > > here in SeaMoby. Perhaps we can get the MIP guys to stop using > > the term sooooo very much??? :-) They seem to use it like a > > marketing term for their fast handoff work which in the SeaMoby > > sense is nowhere near Seamless, go figure. > > Having participated heavily in the MIP work, I have *never* > heard anyone use > the term seamless. The only term that I know of that was used is fast. Interesting, Pat. If I recall correctly, seamless is mentioned in Charlie Perkin's fast handoff draft, as being fast + smooth. This is where the debate started, I believe, as I claim that seamless is more then smooth. I also don't believe that the fast handoff draft intended to provide a normative reference; I would suspect that the definitions were intended as a *starting point* for solving real problems (something we in Seamoby should consider carefully). One can simply look at what has happened with FH in MIP, and see that the original definition is of secondary importance to finding a working solution. So, seamless it is. Gary > > PatC > > ------_=_NextPart_001_01C08F93.8F0C0CF0 Content-Type: text/html; charset="ISO-8859-1" RE: [seamoby] Re: New name -> Seamless to become Hidden Handover? ?

> -----Original Message-----
> From: Patrice Calhoun [mailto:pcalhoun@nasnfs.eng.sun.com]
> Sent: Monday, February 05, 2001 8:32 AM
> To: Phil Neumiller
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; 'Jukka Manner'; Phil_Neumiller;
> seamoby
> Subject: Re: [seamoby] Re: New name -> Seamless to become Hidden
> Handover? ?
>
>
>
> > This is interesting Gary.  As an aside, what would happen if
> > we tunnelled TCP and UDP over SCTP to avoid these strange
> > things?  (I KNOW ITS SOLUTION SPACE!!!!)
>
> Tunneling a reliable transport over a reliable transport is
> evil. Let's not go
> there...
>
> > Yeah, I guess its time to kill the Disney references (even though
> > I could could have claimed the "Grumpy" dwarf name).  Seamless
> > is overloaded, but we might as well build a black hole for it
> > here in SeaMoby.  Perhaps we can get the MIP guys to stop using
> > the term sooooo very much??? :-)  They seem to use it like a
> > marketing term for their fast handoff work which in the SeaMoby
> > sense is nowhere near Seamless, go figure.
>
> Having participated heavily in the MIP work, I have *never*
> heard anyone use
> the term seamless. The only term that I know of that was used is fast.

Interesting, Pat. If I recall correctly, seamless is mentioned in Charlie
Perkin's fast handoff draft, as being fast + smooth. This is where
the debate started, I believe, as I claim that seamless is more then
smooth. I also don't believe that the fast handoff draft intended to
provide a normative reference; I would suspect that the definitions
were intended as a *starting point* for solving real problems (something
we in Seamoby should consider carefully). One can simply look at what
has happened with FH in MIP, and see that the original definition is
of secondary importance to finding a working solution.

So, seamless it is.

Gary
>
> PatC
>
>

------_=_NextPart_001_01C08F93.8F0C0CF0-- From owner-seamoby@diameter.org Mon Feb 5 14:47:03 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15898 for ; Mon, 5 Feb 2001 14:47:02 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f15GhOY28197 for seamoby-list; Mon, 5 Feb 2001 08:43:24 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from bwa-pts.PTS.BWAUTO.CO.KR (pts.bwauto.co.kr.81.126.210.in-addr.arpa [210.126.81.2] (may be forged)) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f15GhMo28192 for ; Mon, 5 Feb 2001 08:43:22 -0800 Received: from max1-41.losangeles.corecomm.net by bwa-pts.PTS.BWAUTO.CO.KR with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id 1C50VTZN; Mon, 5 Feb 2001 09:26:22 +0900 DATE: 04 Feb 01 4:28:00 PM FROM: hk67hk89@yahoo.com Message-ID: Subject: [seamoby] Work in your underwear! Stay at home and make big money! Sender: owner-seamoby@diameter.org Precedence: bulk Researched, Legitimate... Work-At-Home Jobs and Opportunities!! ***HOME WORKERS NEEDED*** Never before have so many businesses aggressively sought home workers! You can chose from hundreds of EASY JOBS and other opportunities! Over 150 legitimate companies are NOW HIRING!! Make excellent pay! Yes!!... You can increase your income by performing assembly or clerical work in your home! Introducing the ... Work-At-Home Directory [The Most Complete Home Employment Source Book] ORDER NOW!!! and get your free bonus -- The Business Opportunity Guide The Work-At-Home Directory offers the best home employment opportunities in the USA with some in Canada. The Directory includes the names and addresses of each company with a full description of the assembly or clerical work offered. In most cases no special training, skills or equipment is required. Instructions are easy to follow [these companies WANT you to do this work] and can be mastered immediately. Many of these opportunities are businesses you can start from your own home with very little investment, on a part or full time basis, if you’re sincere in starting your own business. **************************************************** TAKE IMMEDIATE ADVANTAGE OF THESE UNIQUE OPPORTUNITIES!!! The Work-At-Home Directory is just $19.95 [shipping and handling included]. We accept checks, money orders, even cash. Print the following form and mail it to: Watkins Associates WAH Directory 3104 E. Camelback Road, #754 Phoenix, AZ 85016 Ship to: _________________________________________________________ Shipping Address: _________________________________________________ City: ___________________________________________________________ State: ___________________________________________________________ Zip Code: ________________________________________________________ Your email: _______________________________________________________ Make your check payable to: Watkins Associates All orders ship within 24 hours. ** REMOVE ** REMOVE ** REMOVE ** REMOVE ** REMOVE ** To be removed from our mailing list, please email hk67hk89@yahoo.com All REMOVE requests AUTOMATICALLY honored upon receipt. PLEASE understand that any effort to disrupt, close or block this REMOVE account can only result in difficulties for others wanting to be removed from our mailing list as it will be impossible to take anyone off the list if the remove instruction can not be received. From owner-seamoby@diameter.org Mon Feb 5 15:04:24 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16241 for ; Mon, 5 Feb 2001 15:04:24 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f15HRXZ28319 for seamoby-list; Mon, 5 Feb 2001 09:27:33 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from newman.frascone.com (god@www.frascone.com [216.62.83.25]) by charizard.diameter.org (8.10.0/8.10.0) with SMTP id f15HRVo28314 for ; Mon, 5 Feb 2001 09:27:31 -0800 Received: (qmail 10981 invoked by uid 500); 5 Feb 2001 17:11:46 -0000 Date: Mon, 5 Feb 2001 11:11:46 -0600 From: David Frascone To: Phil_Neumiller@3Com.com Cc: Patrice Calhoun , seamoby@diameter.org Subject: Re: [seamoby] Re: New name -> Seamless to become Hidden Handover? ? Message-ID: <20010205111146.V6651@newman.frascone.com> Mail-Followup-To: Phil_Neumiller@3Com.com, Patrice Calhoun , seamoby@diameter.org References: <882569EA.005AE579.00@hqoutbound.ops.3com.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <882569EA.005AE579.00@hqoutbound.ops.3com.com>; from Phil_Neumiller@3Com.com on Mon, Feb 05, 2001 at 10:38:03AM -0600 X-encrypt-payload: no Sender: owner-seamoby@diameter.org Precedence: bulk On Mon, Feb 05, 2001 at 10:38:03AM -0600, Phil_Neumiller@3Com.com wrote: > > Please respond to Patrice Calhoun > > Let me try again. > > SCTP Retransmitting a TCP transmission doesn't sound like a great idea to me. > This comment was a result of your TCP over SCTP proposal above. > > pdn>Yes this sounds like a really bad idea on the surface. It seems to violate > the > pdn>end-to-end principle, etc. However, if we are assuming edge devices that > pdn>have really lousy connections that come and go (like wireless for instance) > pdn>this starts to make more sense. If we assume routers you are right on! > I get dizzy thinking of SCTP retransmitting TCP retransmissions. Say that ten times fast :) -Dave From owner-seamoby@diameter.org Mon Feb 5 15:04:28 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16252 for ; Mon, 5 Feb 2001 15:04:27 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f15IPAU28553 for seamoby-list; Mon, 5 Feb 2001 10:25:10 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f15IP1o28548 for ; Mon, 5 Feb 2001 10:25:01 -0800 Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f15HW3101766; Mon, 5 Feb 2001 09:32:03 -0800 (PST) Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104]) by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f15HXEA19073; Mon, 5 Feb 2001 09:33:14 -0800 (PST) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 882569EA.00609381 ; Mon, 5 Feb 2001 09:34:52 -0800 X-Lotus-FromDomain: 3COM From: Phil_Neumiller@3Com.com To: Patrice Calhoun cc: seamoby@diameter.org Message-ID: <882569EA.0060909E.00@hqoutbound.ops.3com.com> Date: Mon, 5 Feb 2001 11:41:01 -0600 Subject: Re: [seamoby] Re: New name -> Seamless to become Hidden Handover? ? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-seamoby@diameter.org Precedence: bulk Please respond to Patrice Calhoun See what I mean, now? pdn>You almost have the right end-to-end argument and I do pdn>understand that it makes complete sense when talking about pdn>routers. So... pdn> pdn>YES. However, most radio links already do retransmits for pdn>end-to-end reliable protocols take RLP in cdma2000 or RLC pdn>in UMTS your favorite 3G standards I believe. Neither of pdn>these can provide multi-homing like SCTP. Suppose that pdn>you have a bunch of bumble bees hovering around the hive pdn>and each of them is a router. pdn>Do you see what I mean now??? Phil From owner-seamoby@diameter.org Mon Feb 5 15:06:08 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16322 for ; Mon, 5 Feb 2001 15:06:07 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f15HNJ028308 for seamoby-list; Mon, 5 Feb 2001 09:23:19 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f15HNHo28303 for ; Mon, 5 Feb 2001 09:23:17 -0800 Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f15GUE118454; Mon, 5 Feb 2001 08:30:14 -0800 (PST) Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104]) by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f15GVQA09502; Mon, 5 Feb 2001 08:31:26 -0800 (PST) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 882569EA.005AEB60 ; Mon, 5 Feb 2001 08:33:04 -0800 X-Lotus-FromDomain: 3COM From: Phil_Neumiller@3Com.com To: Patrice Calhoun cc: seamoby@diameter.org Message-ID: <882569EA.005AE579.00@hqoutbound.ops.3com.com> Date: Mon, 5 Feb 2001 10:38:03 -0600 Subject: Re: [seamoby] Re: New name -> Seamless to become Hidden Handover? ? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-seamoby@diameter.org Precedence: bulk Please respond to Patrice Calhoun Let me try again. SCTP Retransmitting a TCP transmission doesn't sound like a great idea to me. This comment was a result of your TCP over SCTP proposal above. pdn>Yes this sounds like a really bad idea on the surface. It seems to violate the pdn>end-to-end principle, etc. However, if we are assuming edge devices that pdn>have really lousy connections that come and go (like wireless for instance) pdn>this starts to make more sense. If we assume routers you are right on! -Phil From owner-seamoby@diameter.org Mon Feb 5 15:06:47 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16338 for ; Mon, 5 Feb 2001 15:06:47 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f15IQNv28562 for seamoby-list; Mon, 5 Feb 2001 10:26:23 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f15IQJo28557 for ; Mon, 5 Feb 2001 10:26:20 -0800 Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f15HXM101979 for ; Mon, 5 Feb 2001 09:33:22 -0800 (PST) Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104]) by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f15HYXA19159 for ; Mon, 5 Feb 2001 09:34:33 -0800 (PST) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 882569EA.0060B295 ; Mon, 5 Feb 2001 09:36:11 -0800 X-Lotus-FromDomain: 3COM From: Phil_Neumiller@3Com.com To: seamoby@diameter.org Message-ID: <882569EA.0060AE04.00@hqoutbound.ops.3com.com> Date: Mon, 5 Feb 2001 11:41:35 -0600 Subject: Re: [seamoby] Re: New name -> Seamless to become Hidden Handover? ? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-seamoby@diameter.org Precedence: bulk ---------------------- Forwarded by Phil Neumiller/MW/US/3Com on 02/05/2001 11:34 AM --------------------------- Phil Neumiller/MW/US/3Com 02/05/2001 11:41 AM Sent by: Phil Neumiller - Network Systems Architect, RCG To: Patrice Calhoun cc: seamoby@diameter.org Subject: Re: [seamoby] Re: New name -> Seamless to become Hidden Handover? ? (Document link: Database 'Phil Neumiller', View '($Sent)') Please respond to Patrice Calhoun See what I mean, now? pdn>You almost have the right end-to-end argument and I do pdn>understand that it makes complete sense when talking about pdn>routers. So... pdn> pdn>YES. However, most radio links already do retransmits for pdn>end-to-end reliable protocols take RLP in cdma2000 or RLC pdn>in UMTS your favorite 3G standards I believe. Neither of pdn>these can provide multi-homing like SCTP. Suppose that pdn>you have a bunch of bumble bees hovering around the hive pdn>and each of them is a router. pdn>Do you see what I mean now??? Phil From owner-seamoby@diameter.org Mon Feb 5 15:52:34 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17281 for ; Mon, 5 Feb 2001 15:52:34 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f15ITuu28572 for seamoby-list; Mon, 5 Feb 2001 10:29:56 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f15ITqo28567 for ; Mon, 5 Feb 2001 10:29:52 -0800 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA20947; Mon, 5 Feb 2001 09:38:04 -0800 (PST) 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 JAA26675; Mon, 5 Feb 2001 09:38:04 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id JAA26122; Mon, 5 Feb 2001 09:38:02 -0800 (PST) Date: Mon, 5 Feb 2001 09:38:02 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [seamoby] Re: New name -> Seamless to become Hidden Handover? ? To: Phil_Neumiller@3Com.com Cc: Patrice Calhoun , seamoby@diameter.org In-Reply-To: "Your message with ID" <882569EA.0060909E.00@hqoutbound.ops.3com.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk > pdn>You almost have the right end-to-end argument and I do > pdn>understand that it makes complete sense when talking about > pdn>routers. So... ok.... > pdn> > pdn>YES. However, most radio links already do retransmits for > pdn>end-to-end reliable protocols take RLP in cdma2000 or RLC > pdn>in UMTS your favorite 3G standards I believe. Neither of > pdn>these can provide multi-homing like SCTP. Suppose that > pdn>you have a bunch of bumble bees hovering around the hive > pdn>and each of them is a router. Actually, to be fair, the radio guys provide *two* different type of service over the air (each in separate channels). Real-Time traffic is sent through one type of channel, which does NOT provide retransmission at the link layer, and normal traffic uses a channel that does provide retransmission. > pdn>Do you see what I mean now??? Not within the context of the IETF I don't. As you see above, even the radio guys know that *some* traffic shouldn't be retransmitted. I would hate to have to impose such intelligence in routers as well. PatC From owner-seamoby@diameter.org Mon Feb 5 16:27:54 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18043 for ; Mon, 5 Feb 2001 16:27:54 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f15JsAn28942 for seamoby-list; Mon, 5 Feb 2001 11:54:10 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f15Js7o28937 for ; Mon, 5 Feb 2001 11:54:07 -0800 Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f15J19122003; Mon, 5 Feb 2001 11:01:09 -0800 (PST) Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104]) by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f15J2KA03730; Mon, 5 Feb 2001 11:02:21 -0800 (PST) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 882569EA.0068BA68 ; Mon, 5 Feb 2001 11:03:54 -0800 X-Lotus-FromDomain: 3COM From: Phil_Neumiller@3Com.com To: Patrice Calhoun cc: Seamoby@diameter.org Message-ID: <882569EA.00689D55.00@hqoutbound.ops.3com.com> Date: Mon, 5 Feb 2001 13:05:00 -0600 Subject: [seamoby] Was honeycomb hideout, now SCTP with mobile routers Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-seamoby@diameter.org Precedence: bulk In many cases bearer channels can be and AREretransmitted as well with a reliable link ARQ since the re-transmission occurs on a time scale that is orders of magnitude smaller than the latency induced by the network end-to-end. However, this is not my main, point. My point is that a couple hops between MNs in some scatter net MAY very well have a negligable round trip latency when compared to the larger scope of end-to-end delay caused by TCP across the global Interenet to the CN. Lets take a few nodes M1, M2, M3, and a gateway G for example. Suppose they have an un-reliable transport directly between them as follows. |--------------Reliable SCTP---------------| M1 <- un-reliable -> M2 <- un-reliable -> G \ <- un-reliable -> M3 <- un-reliable --/ Suppose further that M2 and M3 can both serve as routers for M1 to the gateway node G. If I tunnel over M2 and M3 to G with SCTP, either link can fail and my TCP payload goes through un-hindered and guess what! I get less overall network congestion. This type of link hop RF loss will be quite common in the busy bee scatternets that will become prevelant. There is some trade off in the number of hops where this is possible and efficient as opposed to where it would break down. I don't think it would work well with MANET-like algorithms. Thanks, Ph -Phil Please respond to Patrice Calhoun Not within the context of the IETF I don't. As you see above, even the radio guys know that *some* traffic shouldn't be retransmitted. I would hate to have to impose such intelligence in routers as well. PatC From owner-seamoby@diameter.org Mon Feb 5 16:40:44 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18314 for ; Mon, 5 Feb 2001 16:40:43 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f15KSUC29027 for seamoby-list; Mon, 5 Feb 2001 12:28:30 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f15KSRo29022 for ; Mon, 5 Feb 2001 12:28:27 -0800 Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f15JZT101995; Mon, 5 Feb 2001 11:35:29 -0800 (PST) Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104]) by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f15JafA11001; Mon, 5 Feb 2001 11:36:41 -0800 (PST) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 882569EA.006BE0A3 ; Mon, 5 Feb 2001 11:38:18 -0800 X-Lotus-FromDomain: 3COM From: Phil_Neumiller@3Com.com To: "Charles E. Perkins" cc: seamoby@diameter.org Message-ID: <882569EA.006BD099.00@hqoutbound.ops.3com.com> Date: Mon, 5 Feb 2001 13:43:23 -0600 Subject: Re: [seamoby] Upcoming REAL IP for Bluetooth BOF Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-seamoby@diameter.org Precedence: bulk Hi Charlie, I do need to take a Dale Carnegie course pretty soon! I apologize for the language used in that mail. However, unfortunately, my sentiment was accurately stated. I have talked to MANY other folks about this and they too seem to concur. I guess I was dumb enough to state this in a public forum. The MANET community should know that many pragmatists in the (lets get this thing running yesterday) mobillity community feel there has been a bit too much focus on "esoteric" routing protocols in the MANET WG. Many I have talked to, stated that they would prefer a simple IP based discovery and few hop routing protocol to be availabel from the IETF. This may not be possible, but IMHO it is possible (I know put up or shut up, write a draft, etc). This should be a far less challenging problem than say getting the AODV work optimized. When I suggested this to the MANET community I did not seem to get much interest raised about a year ago hence I did not write a draft. Regarding posts to the MANET group. I believe if you dig deep into the archives you will see that I did indeed post several times to the group about Bluetooth and its method for ad hoc networking. See the following archive pointers where you and I discussed this very issue. http://www.cs.hut.fi/~mart/mail/manet/2000/0196.html http://www.cs.hut.fi/~mart/mail/manet/2000/0194.html The quote that I posted to MANET in January of 2000 over a year ago states: "It seems to me that what we want to do is have manet-like capabilities specified at the IP layer so that we can change out radios as needed. With this in mind, can somebody write a draft that puts these really basic Bluetooth capabilities like cable replacement, ad hoc networking, over manet so that we eventually have an RFC standard for the really basic stuff?" Sent by: "Charles E. Perkins" Charles E. Perkins writes: I don't remember any message from you on the [manet] mailing list to suggest improvements, either Furthermore, regarding "esoteric"... Scalability is good. You are right that limiting networks to a few hops makes life simpler in the short run, but then you have the problem that sooner rather than later your whole technology will run out of steam. Then you have the field upgrade problem sooner rather than later. This is all a matter of economics, of course. But the cost for scalability is very much worthwhile if little or no additional complication is involved. I wish you would be more specific about what you think is wrong, at least with AODV. pdn>I don't think there is anything wrong with it. It may simply pdn>be overkill for today's consumer. I am looking at building pdn>wireless consumer products in the $15 to $65 price range and pdn>believe me every bit of RAM costs. What is needed more than anything now is some new ideas about application interfaces in an ad-hoc network. Now that we have routing protocols, how do we fix the largely broken client-server paradigm which doesn't hold up so well in the ad-hoc world? pdn>Peer-to-peer is the answer (I happen to be a BIG advocate of pdn>contract nets). :-) will happen a lot sooner with people who are willing to make the effort to harmonize instead of issuing blanket condemnations. pdn>The condemnation is not on the work but the priority inversion of simple pdn>solutions versus analysis paralysis. Sorry for any broken feathers, thanks, Phil From owner-seamoby@diameter.org Mon Feb 5 17:03:54 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18728 for ; Mon, 5 Feb 2001 17:03:53 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f15JWoN28788 for seamoby-list; Mon, 5 Feb 2001 11:32:50 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from zcars04e (h56s242a129n47.user.nortelnetworks.com [47.129.242.56]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f15JWko28783 for ; Mon, 5 Feb 2001 11:32:46 -0800 Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e; Mon, 5 Feb 2001 13:40:54 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 5 Feb 2001 13:40:54 -0500 Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8C16@zwdld001.ca.nortel.com> From: "Gary Kenward" To: seamoby@diameter.org Subject: RE: [seamoby] Re: New name -> Seamless to become Hidden Handover? ? Date: Mon, 5 Feb 2001 13:40:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08FA3.2887BF00" X-Orig: Sender: owner-seamoby@diameter.org Precedence: bulk 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_01C08FA3.2887BF00 Content-Type: text/plain; charset="ISO-8859-1" Phil: RLP retransmitting over a link is not the same as SCTP retransmitting end to end. The whole argument for link layer transmissions is based upon taking advantage of knowledge of the link layer behaviour and minimizing latency (there's a PILC draft on this topic, somewhere). Gary > -----Original Message----- > From: Phil_Neumiller@3Com.com [mailto:Phil_Neumiller@3Com.com] > Sent: Monday, February 05, 2001 12:41 PM > To: Patrice Calhoun > Cc: seamoby@diameter.org > Subject: Re: [seamoby] Re: New name -> Seamless to become Hidden > Handover? ? > > > > > > > > > Please respond to Patrice Calhoun > See what I mean, now? > > pdn>You almost have the right end-to-end argument and I do > pdn>understand that it makes complete sense when talking about > pdn>routers. So... > pdn> > pdn>YES. However, most radio links already do retransmits for > pdn>end-to-end reliable protocols take RLP in cdma2000 or RLC > pdn>in UMTS your favourite 3G standards I believe. Neither of > pdn>these can provide multi-homing like SCTP. Suppose that > pdn>you have a bunch of bumble bees hovering around the hive > pdn>and each of them is a router. > > pdn>Do you see what I mean now??? > > Phil > > > > > > ------_=_NextPart_001_01C08FA3.2887BF00 Content-Type: text/html; charset="ISO-8859-1" RE: [seamoby] Re: New name -> Seamless to become Hidden Handover? ?

Phil:

  RLP retransmitting over a link is not the same as SCTP retransmitting
end to end. The whole argument for link layer transmissions is based
upon taking advantage of knowledge of the link layer behaviour and minimizing
latency (there's a PILC draft on this topic, somewhere).

Gary

> -----Original Message-----
> From: Phil_Neumiller@3Com.com [mailto:Phil_Neumiller@3Com.com]
> Sent: Monday, February 05, 2001 12:41 PM
> To: Patrice Calhoun
> Cc: seamoby@diameter.org
> Subject: Re: [seamoby] Re: New name -> Seamless to become Hidden
> Handover? ?
>
>
>
>
>
>
>
>
> Please respond to Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
> See what I mean, now?
>
> pdn>You almost have the right end-to-end argument and I do
> pdn>understand that it makes complete sense when talking about
> pdn>routers.  So...
> pdn>
> pdn>YES.  However, most radio links already do retransmits for
> pdn>end-to-end reliable protocols take RLP in cdma2000 or RLC
> pdn>in UMTS your favourite 3G standards I believe.  Neither of
> pdn>these can provide multi-homing like SCTP.  Suppose that
> pdn>you have a bunch of bumble bees hovering around the hive
> pdn>and each of them is a router.
>
> pdn>Do you see what I mean now???
>
> Phil
>
>
>
>
>
>

------_=_NextPart_001_01C08FA3.2887BF00-- From owner-seamoby@diameter.org Mon Feb 5 17:46:49 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19764 for ; Mon, 5 Feb 2001 17:46:48 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f15Knbe29130 for seamoby-list; Mon, 5 Feb 2001 12:49:37 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from cisco.com (flipper.cisco.com [171.69.25.141]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f15KnUo29125 for ; Mon, 5 Feb 2001 12:49:31 -0800 Received: from dblair-pc (dhcp-atlanta-220-34.cisco.com [161.44.220.34]) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with SMTP id LAA13046; Mon, 5 Feb 2001 11:37:24 -0800 (PST) Message-Id: <4.1.20010205143352.00b51ed0@flipper.cisco.com> X-Sender: dblair@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 05 Feb 2001 14:36:16 -0500 To: "Gary Kenward" , seamoby@diameter.org From: "Dana L. Blair" Subject: RE: [seamoby] Re: New name -> Seamless to become Hidden Handover? ? In-Reply-To: <13E2EF604DE5D111B2E50000F80824E8057A8C16@zwdld001.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-seamoby@diameter.org Precedence: bulk At 01:40 PM 2/5/01 -0500, Gary Kenward wrote: > > Phil: > > RLP retransmitting over a link is not the same as SCTP retransmitting > end to end. The whole argument for link layer transmissions is based > upon taking advantage of knowledge of the link layer behaviour and minimizing > latency (there's a PILC draft on this topic, somewhere). Folks involved in integrating cellular access links ( or any access links) with IP should really take a look at the drafts at the Performance Implications of Link Characteristicss (pilc) IETF Working Group web page. These drafts have been very educational for me. Scroll down to the internet drafts section of the following URL: http://www.ietf.org/html.charters/pilc-charter.html thanks, Dana > > Gary > > > -----Original Message----- > > From: Phil_Neumiller@3Com.com > [mailto:Phil_Neumiller@3Com.com] > > Sent: Monday, February 05, 2001 12:41 PM > > To: Patrice Calhoun > > Cc: seamoby@diameter.org > > Subject: Re: [seamoby] Re: New name -> Seamless to become Hidden > > Handover? ? > > > > > > > > > > > > > > > > > > Please respond to Patrice Calhoun > > See what I mean, now? > > > > pdn>You almost have the right end-to-end argument and I do > > pdn>understand that it makes complete sense when talking about > > pdn>routers. So... > > pdn> > > pdn>YES. However, most radio links already do retransmits for > > pdn>end-to-end reliable protocols take RLP in cdma2000 or RLC > > pdn>in UMTS your favourite 3G standards I believe. Neither of > > pdn>these can provide multi-homing like SCTP. Suppose that > > pdn>you have a bunch of bumble bees hovering around the hive > > pdn>and each of them is a router. > > > > pdn>Do you see what I mean now??? > > > > Phil > > > > > > > > > > > > From owner-seamoby@diameter.org Mon Feb 5 18:47:02 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20661 for ; Mon, 5 Feb 2001 18:46:59 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f15LjCo29243 for seamoby-list; Mon, 5 Feb 2001 13:45:12 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f15Lj9o29238 for ; Mon, 5 Feb 2001 13:45:09 -0800 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 MAA28081; Mon, 5 Feb 2001 12:53:20 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f15KrJM23759; Mon, 5 Feb 2001 12:53:19 -0800 X-Virus-Scanned: Mon, 5 Feb 2001 12:53:19 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpda64fXX; Mon, 05 Feb 2001 12:53:14 PST Message-ID: <3A7F130B.2B966D2D@iprg.nokia.com> Date: Mon, 05 Feb 2001 12:54:35 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Phil_Neumiller@3Com.com CC: seamoby@diameter.org Subject: Re: [seamoby] Upcoming REAL IP for Bluetooth BOF References: <882569EA.006BD099.00@hqoutbound.ops.3com.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Phil, Let me try again to address your actual concern. I'm not too concerned about the language you used to express it, although it does matter to a certain extent. > I do need to take a Dale Carnegie course pretty soon! I apologize for > the language used in that mail. However, unfortunately, my sentiment > was accurately stated. I have talked to MANY other folks about this > and they too seem to concur. I guess I was dumb enough to state this in > a public forum. Stating exactly that is not dumb, and such things should be stated in public more often so that things can be resolved. > The MANET community should know that many > pragmatists in the (lets get this thing running yesterday) mobillity > community feel there has been a bit too much focus on "esoteric" routing > protocols in the MANET WG. Many I have talked to, stated that they > would prefer a simple IP based discovery and few hop routing protocol > to be availabel from the IETF. Well, it is. Any [manet] protocol can do a few hops. Just pick one. Of course I'd prefer that you pick AODV, but performance over a small neighborhood won't differ enough to argue about. Regarding Service Discovery, it's simple enough using various methods. I'd suggest SLP, but then again you may think I am biased. > This may not be possible, but IMHO it > is possible (I know put up or shut up, write a draft, etc). This should be a > far less challenging problem than say getting the AODV work optimized. > When I suggested this to the MANET community I did not seem to get > much interest raised about a year ago hence I did not write a draft. I think a lot of people in [manet] would say there's not much left to do. Part of the problem (I'm guessing) is that the IETF doesn't build systems. If no protocol development is needed, then IETF doesn't do all that much for you. Perhaps the scenario you want already has enough protocol available for the job. If not, from what you said I reckon we could do the rest on the back of an envelope. If you want to do this, let's sit down in Minneapolis and draft something for consideration. > Regarding posts to the MANET group. I believe if you dig deep into > the archives you will see that I did indeed post several times to the group > about Bluetooth and its method for ad hoc networking. See the > following archive pointers where you and I discussed this very issue. > > http://www.cs.hut.fi/~mart/mail/manet/2000/0196.html > http://www.cs.hut.fi/~mart/mail/manet/2000/0194.html O.K. I just didn't remember, but thanks. > pdn>I don't think there is anything wrong with it. It may simply > pdn>be overkill for today's consumer. I am looking at building > pdn>wireless consumer products in the $15 to $65 price range and > pdn>believe me every bit of RAM costs. I'm having a hard time believing that AODV vs. anything else would be the cost determinant. I know that RAM counts, but so does reliability etc. > What is needed more than anything now is some new ideas about > application interfaces in an ad-hoc network. Now that we have > routing protocols, how do we fix the largely broken client-server > paradigm which doesn't hold up so well in the ad-hoc world? > > pdn>Peer-to-peer is the answer (I happen to be a BIG advocate of > pdn>contract nets). :-) Peer-to-peer is the answer as long as the endpoints can identify and communicate with each other. Sometimes servers are useful, too. > will happen a lot sooner with people who are willing to make > the effort to harmonize instead of issuing blanket condemnations. > > pdn>The condemnation is not on the work but the priority inversion of simple > pdn>solutions versus analysis paralysis. > > Sorry for any broken feathers, thanks, Well, the point is to get past unneeded biases to see what there is and what needs to be done. Regards, Charlie P. From owner-seamoby@diameter.org Mon Feb 5 18:49:58 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20713 for ; Mon, 5 Feb 2001 18:49:58 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f15MJjJ29306 for seamoby-list; Mon, 5 Feb 2001 14:19:45 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f15MJgo29301 for ; Mon, 5 Feb 2001 14:19:43 -0800 Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f15LQc127034; Mon, 5 Feb 2001 13:26:38 -0800 (PST) Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104]) by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f15LRoA27509; Mon, 5 Feb 2001 13:27:50 -0800 (PST) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 882569EA.00760E10 ; Mon, 5 Feb 2001 13:29:28 -0800 X-Lotus-FromDomain: 3COM From: Phil_Neumiller@3Com.com To: Charlie Perkins cc: seamoby@diameter.org, manet@itd.nrl.navy.mil Message-ID: <882569EA.00760153.00@hqoutbound.ops.3com.com> Date: Mon, 5 Feb 2001 15:23:59 -0600 Subject: Re: [seamoby] Upcoming REAL IP for Bluetooth BOF Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-seamoby@diameter.org Precedence: bulk Hi Charlie, I cross-posted this to MANET, please forgive multiple copies. BTW, Thanks for the AODV recommendation... As a casual observer of MANET activity I look at the work and I see no RFC for basic ad hoc networking. Case closed. I do see the following work in progress (which as been in progress for some time): o (AODV) Routing o Temporally-Ordered Routing Algorithm (TORA) o The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks o Optimized Link State Routing Protocol o Differential Destination Multicast (DDM) Specification o Multicast Ad hoc On-Demand Distance Vector (MAODV) o Topology Broadcast based on Reverse-Path Forwarding (TBRPF) o Landmark Routing Protocol (LANMAR) for Large Scale Ad Hoc Networks o A Simple Protocol for Multicast and Broadcast in Mobile Ad Hoc Networks o Fisheye State Routing Protocol (FSR) for Ad Hoc Networks While I am quite convinced that ALL this work is valuable and useful it does not solve my basic problems (at least not in a standard way). WHAT IS THE IETF's consensus and current recommendation for basic ad hoc networking??? Would this work not prove to be better served in the IRTF? It seems the MANET WG should be working more towards a consensus and a standard RFC protocol for ad hoc networking right? If I am out of order here please explain. Thanks, -Phil From owner-seamoby@diameter.org Mon Feb 5 19:19:28 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21129 for ; Mon, 5 Feb 2001 19:19:27 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f15Mm7C29408 for seamoby-list; Mon, 5 Feb 2001 14:48:07 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f15Mkko29403 for ; Mon, 5 Feb 2001 14:46:46 -0800 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 NAA18791; Mon, 5 Feb 2001 13:54:39 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT21384; Mon, 5 Feb 2001 13:54:24 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA01081; Mon, 5 Feb 2001 13:54:24 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14975.8464.593497.888118@thomasm-u1.cisco.com> Date: Mon, 5 Feb 2001 13:54:24 -0800 (PST) To: vincent magret Cc: seamoby Subject: [seamoby] Re: [seamoby-mm] Host route vs. tunneling In-Reply-To: <3A7F1C75.D430D8BE@ind.alcatel.com> References: <3A7F1C75.D430D8BE@ind.alcatel.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-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit vincent magret writes: > I see a difference, it all depends how many nodes you have between the > access router of the wireless domain and the mobile node itself. It is > also a question of salability. If your network intends to support > 100.000 visiting subscribers, that starts making huge routing table. Host routing scales exactly as far as you want it to scale. If you don't want 100k host routes, summarize the routes faster at the expense of somewhat slower handoffs/more signaling. > Host router add a strong requirement on the router in the wireless > domain (i.e. they all need to talk host routing update protocol) as > opposed to regular router. It's not clear that there is any new protocol to be invented here. IS-IS, I think, deals with this already. Mike From owner-seamoby@diameter.org Mon Feb 5 20:38:36 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21804 for ; Mon, 5 Feb 2001 20:38:33 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f15Mbvb29378 for seamoby-list; Mon, 5 Feb 2001 14:37:57 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from ind.alcatel.com (postal.xylan.com [208.8.0.248]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f15Maeo29373 for ; Mon, 5 Feb 2001 14:36:40 -0800 Received: from mailhub.ind.alcatel.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with ESMTP id NAA20415 for ; Mon, 5 Feb 2001 13:44:55 -0800 (PST) X-Origination-Site: Received: from omni.ind.alcatel.com (localhost [127.0.0.1]) by mailhub.ind.alcatel.com (8.9.3+Sun/8.9.3/(mailhub 3.2.4 [HUB])) with ESMTP id NAA14398 for ; Mon, 5 Feb 2001 13:44:39 -0800 (PST) X-InterScan: Passed Received: from ind.alcatel.com (eph128251021241.dhcp.ind.alcatel.com [128.251.21.241]) by omni.ind.alcatel.com (8.9.3+Sun/8.9.1 (omni 3.0 [engr-SPOOL])) with ESMTP id NAA02367 for ; Mon, 5 Feb 2001 13:44:39 -0800 (PST) Message-ID: <3A7F1C75.D430D8BE@ind.alcatel.com> Date: Mon, 05 Feb 2001 13:34:46 -0800 From: vincent magret X-Mailer: Mozilla 4.72 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: seamoby Subject: [seamoby] Re: [seamoby-mm] Host route vs. tunneling References: Content-Type: multipart/alternative; boundary="------------4DFEBA6D326018E135C04729" Sender: owner-seamoby@diameter.org Precedence: bulk --------------4DFEBA6D326018E135C04729 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I see a difference, it all depends how many nodes you have between the access router of the wireless domain and the mobile node itself. It is also a question of salability. If your network intends to support 100.000 visiting subscribers, that starts making huge routing table. Host router add a strong requirement on the router in the wireless domain (i.e. they all need to talk host routing update protocol) as opposed to regular router. Vincent. Hongyi Li wrote: > > > Hi, > I don't see much difference between the host routing and tunneling > approaches in supporting micro/local/edge mobility. In the tunneling > approach, an agent (e.g., FA, MA) typically de-tunnels an incoming > packet, > looks at the destination address of the packet, and forwards the > packet to the next tunnel (i.e., to another agent or the mobile). Each > agent > makes next-hop forwarding decision (i.e., next tunnel) based on the > mobile's current location which is updated as the mobile moves. These > agents actually use host routing instead of prefix based routing. > > If we can agree that the agents use host routing too, then the only > difference > between routing and tunneling approaches is the deployment options. > Therefore, > to support mobility, we need only a host routing protocol + host route > update > protocol (named as mobile routing protocol) and give services > providers the > options for deployment (i.e., in routers, or agents in overlay > network). If a service > provider operates a network where the main concern is route efficiency > instead > of amount of state information, it can deploy the mobile routing > protocol in every > routers in its network; Otherwise, the service provider can deploy the > routing > protocol over selected nodes (e.g.,agents) that connected by tunnels. > > A good example that highlights this deployment problem is the > multicast routing > protocols (e.g., DVMRP, MOSPF). The multicast routing protocols were > designed for > routers. As people realized that it is hard to have all the routers to > support > multicast, they deploy the multicast routing protocols over the > multicast > enabled nodes and use tunnels to connect those nodes. This doesn't > prevent > a service provider to deploy the same multicast routing protocol in > all the > routers if he wants to. To design the micro-mobility solution, I > believe > we should follow a similar way. We don't design a protocol for the > nodes > in overlay network and another protocol for routers because they > actually > do the same thing. > > Tunneling is a transport technique used to transport packets from > point A to point B in a network. I believe that the tunneling work > (e.g., > reverse tunnel, hierarchical tunnels, ...) belongs to transport area. > The > only routing part for supporting mobility is host routing. > > -Hongyi --------------4DFEBA6D326018E135C04729 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I see a difference, it all depends how many nodes you have between the access router of the wireless domain and the mobile node itself. It is also a question of salability. If your network intends to support 100.000 visiting subscribers, that starts making huge routing table.

Host router add a strong requirement on the router in the wireless domain (i.e. they all need to talk host routing update protocol) as opposed to regular router.

Vincent.

Hongyi Li wrote:

 

Hi,
  I don't see much difference between the host routing and tunneling
approaches in supporting micro/local/edge mobility. In the tunneling
approach, an agent (e.g., FA, MA) typically de-tunnels an incoming packet,
looks at the destination address of the packet, and forwards the
packet to the next tunnel (i.e., to another agent or the mobile). Each agent
makes next-hop forwarding decision (i.e., next tunnel) based on the
mobile's current location which is updated as the mobile moves. These
agents actually use host routing instead of prefix based routing.

  If we can agree that the agents use host routing too, then the only difference
between routing and tunneling approaches is the deployment options. Therefore,
to support mobility, we need only a host routing protocol + host route update
protocol (named as mobile routing protocol) and give services providers the
options for deployment (i.e., in routers, or agents in overlay network). If a service
provider operates a network where the main concern is route efficiency instead
of amount of state information, it can deploy the mobile routing protocol in every
routers in its network; Otherwise, the service provider can deploy the routing
protocol over selected nodes (e.g.,agents) that connected by tunnels.

  A good example that highlights this deployment problem is the multicast routing
protocols (e.g., DVMRP, MOSPF). The multicast routing protocols were designed for
routers. As people realized that it is hard to have all the routers to support
multicast, they deploy the multicast routing protocols over the multicast
enabled nodes and use tunnels to connect those nodes. This doesn't prevent
a service provider to deploy the same multicast routing protocol in all the
routers if he wants to. To design the micro-mobility solution, I believe
we should follow a similar way. We don't design a protocol for the nodes
in overlay network and another protocol for routers because they actually
do the same thing.

  Tunneling is a transport technique used to transport packets from
point A to point B in a network. I believe that the tunneling work (e.g.,
reverse tunnel, hierarchical tunnels, ...) belongs to transport area. The
only routing part for supporting mobility is host routing.

-Hongyi

--------------4DFEBA6D326018E135C04729-- From owner-seamoby@diameter.org Mon Feb 5 21:10:24 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA22167 for ; Mon, 5 Feb 2001 21:10:23 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f161K6w29825 for seamoby-list; Mon, 5 Feb 2001 17:20:06 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f161K4o29820 for ; Mon, 5 Feb 2001 17:20:04 -0800 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 QAA10171; Mon, 5 Feb 2001 16:28:32 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT22210; Mon, 5 Feb 2001 16:28:15 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA01123; Mon, 5 Feb 2001 16:28:15 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14975.17695.721644.157298@thomasm-u1.cisco.com> Date: Mon, 5 Feb 2001 16:28:15 -0800 (PST) To: "Hesham Soliman (ERA)" Cc: "'Patrice Calhoun'" , seamoby@diameter.org Subject: RE: [seamoby] Single sentence problem statements In-Reply-To: <034BEFD03799D411A59F00508BDF75465B6974@esealnt448.al.sw.ericsson.se> References: <034BEFD03799D411A59F00508BDF75465B6974@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-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hesham Soliman (ERA) writes: > => We most certainly do not want the handover to require a new IKE > exchange and I don't understand how it would. I'm surprised these > concerns were raised. The concerns are not valid because MIPv6 > mandates that the SA be established based on the Home address. > Hence, when moving no new SAs are required to update the HA and > CNs. As for updating the previous AR, yes an SA is required but there > are two solutions we investigated in MIP to solve this : > > 1. If you're using a flat mobility management model (no MAP) > then we were counting on SEAMOBY to transfer the SA > from the old AR to the new one. I think this is a very valid > solution. I believe that *any* discussion of the ability to transfer security context needs to be placed under a giant microscope and evaluated with a jaundiced eye. Transfering secret keys and security context is not something that should be taken lightly. I'm particularly vexed by the notion of transfering IPsec SA's: it strikes me as a highly dubious thing to do. This is one area that I'd far prefer that if there is a way to get this all to work in the usual way (read: just recreating the SA), it should be considered. > As for IKE and whether it's too heavy, spectrum inefficient ..etc > please have a look at draft-soliman-mobileip-routeopt--mipv6-00.txt > which proposes an alternative. This is _simpler_ than IKE? Yikes. Also: it looks like you've managed to recreate the cross realm Kerberos wheel with about 15 years less deployment experience. Mike From owner-seamoby@diameter.org Mon Feb 5 21:10:24 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA22168 for ; Mon, 5 Feb 2001 21:10:24 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f160muf29642 for seamoby-list; Mon, 5 Feb 2001 16:48:56 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f160mqo29636 for ; Mon, 5 Feb 2001 16:48:52 -0800 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 PAA28111; Mon, 5 Feb 2001 15:57:14 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT22033; Mon, 5 Feb 2001 15:57:01 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA01114; Mon, 5 Feb 2001 15:57:01 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14975.15821.457300.727601@thomasm-u1.cisco.com> Date: Mon, 5 Feb 2001 15:57:01 -0800 (PST) To: Charlie Perkins Cc: Michael Thomas , seamoby-mm@cdma-2000.org, seamoby@diameter.org, George Tsirtsis , "Basavaraj Patil (NTC/Dallas)" , Phil Roberts Subject: Re: [seamoby] Re: context transfer/fast MIP conflict (was: [seamoby-mm] FW: I-D ACTION:draft-designteam-fast-mipv6-00.txt) In-Reply-To: <3A7E241B.A5AF6100@iprg.nokia.com> References: <01D91AFB08B6D211BFD00008C7EABAE10680A839@eseis04nok> <14972.26474.972825.310927@thomasm-u1.cisco.com> <3A7C88CD.BA373BC4@iprg.nokia.com> <14972.38725.417965.650464@thomasm-u1.cisco.com> <3A7CA09C.4CAAE1FE@iprg.nokia.com> <14972.45766.832605.237746@thomasm-u1.cisco.com> <3A7CB8FB.8DFD32C1@iprg.nokia.com> <14973.53062.314908.356967@thomasm-u1.cisco.com> <3A7DE2A0.453F324D@iprg.nokia.com> <14973.62450.411228.130495@thomasm-u1.cisco.com> <3A7E241B.A5AF6100@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-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Charlie Perkins writes: > > Thus, I don't understand what new routing state > > needs to be set up on ARnew: it's already there. > > No, what needs to be set up is that ARnew needs > to know the MAC address for the mobile node, and > ARnew needs to confirm that 100.1.2.0 is not already > in use by some other mobile node. Why can't ARnew get the MAC address in the usual way? Ie, through ARP or ND? This only looks like an optimization of one round trip on the local media which is certainly not on the same order latency as what fast handoff is trying to counter. As for DAD, I sort of like the optimistic do-dad-in-parallel optimistic approach. Since we could easily put that in the SEAMOBY CT protocol, we could have it both ways eventually. Honestly, I really like the idea of keeping fast handoffs localized just within MN and ARold. Involving ARnew adds more complexity to that which is otherwise a fairly clean mechanism. Context transfer -- as a router router mechanism -- explicitly says that you're willing to deal with all of the added complexity of moving stuff around (besides routes). It would be nice to have a mechanism which doesn't require that heft too. Fast handoff without HI/HACK fits that middle ground, IMO. > > ... our argument is only in > > who should choose the appropriate transport > > vessel for the goodies. I think it would be > > better to defer that decision and let SEAMOBY > > decide which is best for both in light of the > > full set of requirements. > > On the other hand, other people do not feel this way. > Nothing has been set into stone, although I think that > the design team has a good design. If after due > consideration it turns out to be incompatible with > whatever [seamoby-context] decides has to be done > simultaneously with HI/HAck, then why don't we fix > the problem then instead of going into paralysis mode > now? The problem is that it's impossible to tell you whether your transport vessel is a good one at this point. I was fairly certain that a destination option wasn't the right answer, but can't tell you whether ICMP is adequate and won't be able to tell you until the requirements are nailed down. Assuming you go forward with HI/HACK and they don't fit the requirements, you'll be somewhere around last call and we'll have a conflict if we want to combine the two (as I think they should be). And hence this entire thread. Mike From owner-seamoby@diameter.org Tue Feb 6 01:38:35 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA00459 for ; Tue, 6 Feb 2001 01:38:35 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f165UpQ30376 for seamoby-list; Mon, 5 Feb 2001 21:30:51 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from NEPTUNE.zucotto.com ([216.95.209.154]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f165Uno30371 for ; Mon, 5 Feb 2001 21:30:49 -0800 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Feb 2001 23:39:08 -0500 Message-ID: From: Kulwinder Atwal To: "'Patrice Calhoun'" , Phil_Neumiller@3Com.com Cc: seamoby@diameter.org Subject: RE: [seamoby] Re: New name -> Seamless to become Hidden Handover? ? Date: Mon, 5 Feb 2001 23:39:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk The problem I have with using SCTP to carry TCP is the Round-Trip-Time. Using TCP/SCTP does not reduce the RTT in face of a de-graded physical radio link. The physical delay (RTT) due to a poor radio link will exist with TCP and TCP/SCTP. TCP uses RTT to ramp down the bytes per second. A longer RTT causes TCP to re-transmit, and causes TCP to cut the rate to half until sufficient ACKs are recieved from the reciever. SCTP does not improve TCP's RTT problem, therefore the same problem will exist. SCTP must be used end-to-end, otherwise it is overhead. I suppose one could provide an API on either end that converts TCP packets to SCTP before transmission, but there is no gauranttee the other side will do the same. If one is going to do this, one may ask why not just put the effort into moving to SCTP instead? It may be time to take the plunge and move to SCTP/IPv6. - Kulwinder. > -----Original Message----- > From: Patrice Calhoun [mailto:pcalhoun@nasnfs.eng.sun.com] > Sent: Monday, February 05, 2001 12:38 PM > To: Phil_Neumiller@3com.com > Cc: Patrice Calhoun; seamoby@diameter.org > Subject: Re: [seamoby] Re: New name -> Seamless to become Hidden > Handover? ? > > > > pdn>You almost have the right end-to-end argument and I do > > pdn>understand that it makes complete sense when talking about > > pdn>routers. So... > > ok.... > > > pdn> > > pdn>YES. However, most radio links already do retransmits for > > pdn>end-to-end reliable protocols take RLP in cdma2000 or RLC > > pdn>in UMTS your favorite 3G standards I believe. Neither of > > pdn>these can provide multi-homing like SCTP. Suppose that > > pdn>you have a bunch of bumble bees hovering around the hive > > pdn>and each of them is a router. > > Actually, to be fair, the radio guys provide *two* different > type of service > over the air (each in separate channels). Real-Time traffic > is sent through > one type of channel, which does NOT provide retransmission at > the link layer, > and normal traffic uses a channel that does provide retransmission. > > > pdn>Do you see what I mean now??? > > Not within the context of the IETF I don't. As you see above, > even the radio > guys know that *some* traffic shouldn't be retransmitted. I > would hate to have > to impose such intelligence in routers as well. > > PatC > From owner-seamoby@diameter.org Tue Feb 6 03:57:54 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA10256 for ; Tue, 6 Feb 2001 03:57:53 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f167xHx30604 for seamoby-list; Mon, 5 Feb 2001 23:59:17 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f167xFo30599 for ; Mon, 5 Feb 2001 23:59:15 -0800 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f1677BS01447 for ; Tue, 6 Feb 2001 09:07:11 +0200 (EET) Received: from esebh03nok.ntc.nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 6 Feb 2001 09:07:29 +0200 Received: by esebh03nok with Internet Mail Service (5.5.2652.78) id <1LYM0S58>; Tue, 6 Feb 2001 09:07:29 +0200 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680A8BE@eseis04nok> From: john.loughney@nokia.com To: Hesham.Soliman@era.ericsson.se, Phil_Neumiller@3Com.com Cc: seamoby@diameter.org Subject: RE: [seamoby] Single sentence problem statements Date: Tue, 6 Feb 2001 09:07:28 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi Hesham & Phil, > => Again I fully support this, but part of your problem > statement (signalling delays and number of signals over the air) > are solved by MIP++, hence my question. I'm a little lost. What is MIP++ (is it something to be determined)? As I understand it (please correct me if I am wrong), MIP is attempting to create a general mobility solution. There are some enhancements, such as Hierarchical Mobile IP, Fast Handovers, etc. that are part of the working group. I am sure that a large portion of the WG would like that seamlessness was addressed in some fashion - but I don't think it is part of the charter. Anyhow, what I am getting at is that I believe a valuable problem for us (SeaMoby & MIP) would be a solution for seamless handovers. It could be very well that this solution involves H-MIP + handovers + context transfers - or it could be another solution (remember, we are still just trying to capture the problem at this momement). Anyhow, I'd like to have in a single document (with relevant references, of course) a document which 'solves' this problem and brings together the elements needed. I'd hope we could analyze the existing solutions, determine if they are sufficient and bring together the right elements to provide a solution. So, IMO, it is a worthwhile exercise to put together problem statement(s) outlining what we think is the problem. Afterwards, we can apply the solutions to the problem and see where we are at. In keeping with this, perhaps it isn't useful to say 'protocol x with y & z solutions solves your problem, so lets not talk about it anymore'. I'd really like to see some statements about what folks want from a handover. My very highlevel statement would be: Mobility is and will be an increasingly useful aspect of the Internet. Applications running on nodes which are mobile should not suffer adversely due to movement. Packets should not be dropped (more than normal) or delayed dueto handoffs; nor should signaling induced by the handoffs adversely affect both the network and the users. Comments? John From owner-seamoby@diameter.org Tue Feb 6 07:06:56 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11229 for ; Tue, 6 Feb 2001 07:06:56 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f16BJbp30930 for seamoby-list; Tue, 6 Feb 2001 03:19:37 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f16BJZo30925 for ; Tue, 6 Feb 2001 03:19:35 -0800 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 f16ARtC22060 for ; Tue, 6 Feb 2001 11:27:55 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Feb 06 11:29:00 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id <1CVMZTYV>; Tue, 6 Feb 2001 11:27:54 +0100 Message-ID: <034BEFD03799D411A59F00508BDF75465B698D@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'john.loughney@nokia.com'" Cc: seamoby@diameter.org Subject: RE: [seamoby] Single sentence problem statements Date: Tue, 6 Feb 2001 11:27:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-seamoby@diameter.org Precedence: bulk > Hi Hesham & Phil, > > > => Again I fully support this, but part of your problem > > statement (signalling delays and number of signals over the air) > > are solved by MIP++, hence my question. > > I'm a little lost. What is MIP++ (is it something to > be determined)? > => I was referring to MIP extensions like Regional for MIPv4 and HMIPv6 for MIPv6. > As I understand it (please correct me if I am wrong), MIP is > attempting to create a general mobility solution. There are > some enhancements, such as Hierarchical Mobile IP, Fast > Handovers, etc. that are part of the working group. I am > sure that a large portion of the WG would like that seamlessness > was addressed in some fashion - but I don't think it is part > of the charter. > > Anyhow, what I am getting at is that I believe a valuable > problem for us (SeaMoby & MIP) would be a solution for > seamless handovers. It could be very well that this > solution involves H-MIP + handovers + context transfers - > or it could be another solution (remember, we are still > just trying to capture the problem at this momement). > => I'm not trying to discuss solutions or push any ideas on the group. I was simply questioning the problem statement that Phil sent. Especially the first sentence which I believe is an inaccurate statement about MIP. So I hope this doesn't get misinterpreted as a push for HMIPv6 or other solutions. > Anyhow, I'd like to have in a single document (with relevant > references, of course) a document which 'solves' this problem > and brings together the elements needed. I'd hope we could > analyze the existing solutions, determine if they are sufficient > and bring together the right elements to provide a solution. > => Sure. All I want to emphasise is that to come up with a problem statement, you MUST say what is wrong with the existing solutions. Otherwise it is not clear what the problem is. > I'd really like to see some statements about what folks want > from a handover. My very highlevel statement would be: > > Mobility is and will be an increasingly useful aspect of the > Internet. Applications running on nodes which are mobile should > not suffer adversely due to movement. Packets should not be dropped > (more than normal) or delayed dueto handoffs; nor should signaling > induced by the handoffs adversely affect both the network and the > users. > => Ok, but what is "normal" ? In the fast handoffs work we were aiming to come close to zero loss due to L3 handoff. How close ? well that's what the investigation should say. Of course losses due to L2 handoff were out of scope. Hesham From owner-seamoby@diameter.org Tue Feb 6 07:21:37 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11337 for ; Tue, 6 Feb 2001 07:21:36 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f16BAYW30917 for seamoby-list; Tue, 6 Feb 2001 03:10:34 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f16BAWo30912 for ; Tue, 6 Feb 2001 03:10:32 -0800 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 f16AIpC14083 for ; Tue, 6 Feb 2001 11:18:52 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Feb 06 11:19:56 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id <1CVZ3Y4R>; Tue, 6 Feb 2001 11:15:27 +0100 Message-ID: <034BEFD03799D411A59F00508BDF75465B698C@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Michael Thomas'" Cc: seamoby@diameter.org Subject: RE: [seamoby] Single sentence problem statements Date: Tue, 6 Feb 2001 11:15:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-seamoby@diameter.org Precedence: bulk > > => We most certainly do not want the handover to require a new IKE > > exchange and I don't understand how it would. I'm surprised these > > concerns were raised. The concerns are not valid because MIPv6 > > mandates that the SA be established based on the Home address. > > Hence, when moving no new SAs are required to update the HA and > > CNs. As for updating the previous AR, yes an SA is required but > there > > are two solutions we investigated in MIP to solve this : > > > > 1. If you're using a flat mobility management model (no MAP) > > then we were counting on SEAMOBY to transfer the SA > > from the old AR to the new one. I think this is a very valid > > solution. > > I believe that *any* discussion of the ability to > transfer security context needs to be placed under > a giant microscope and evaluated with a jaundiced > eye. Transfering secret keys and security context > is not something that should be taken lightly. > I'm particularly vexed by the notion of > transfering IPsec SA's: it strikes me as a highly > dubious thing to do. > => I'm sure tha the CT team will have access to the necessary microscopes. So let's not predict what the outcome will be. > This is one area that I'd far prefer that if there > is a way to get this all to work in the usual way > (read: just recreating the SA), it should be > considered. > => Not if you're moving fast within small subnets and trying to save spectrum ! You ignored point #2 because you agree with it ? > > As for IKE and whether it's too heavy, spectrum inefficient ..etc > > please have a look at draft-soliman-mobileip-routeopt--mipv6-00.txt > > which proposes an alternative. > > This is _simpler_ than IKE? Yikes. Also: it looks > like you've managed to recreate the cross realm > Kerberos wheel with about 15 years less deployment > experience. > => So Sending one message from the MN to establish an SA is more complex than doing an IKE exchange in your opinion ? Apart from suffering the "Yikes", is there a technical argument against the draft ? Really, we'd like to get some technical feedback. Hesham From owner-seamoby@diameter.org Tue Feb 6 11:08:15 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19871 for ; Tue, 6 Feb 2001 11:08:15 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f16EdLW31486 for seamoby-list; Tue, 6 Feb 2001 06:39:21 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f16EdIo31480 for ; Tue, 6 Feb 2001 06:39:18 -0800 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA00852; Tue, 6 Feb 2001 05:47:32 -0800 (PST) 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 FAA12405; Tue, 6 Feb 2001 05:47:32 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id FAA09992; Tue, 6 Feb 2001 05:47:29 -0800 (PST) Date: Tue, 6 Feb 2001 05:47:30 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: RE: [seamoby] Re: New name -> Seamless to become Hidden Handover? ? To: Kulwinder Atwal Cc: "'Patrice Calhoun'" , Phil_Neumiller@3Com.com, seamoby@diameter.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk > I suppose one could provide an API on either end that converts TCP packets > to SCTP > before transmission, but there is no gauranttee the other side will do the > same. > If one is going to do this, one may ask why not just put the effort into > moving to > SCTP instead? No gateways please. Breaking the end-to-end model is not on our charter. I really do not understand how this thread has anything to do with seamby, btw. PatC From owner-seamoby@diameter.org Tue Feb 6 12:44:44 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24742 for ; Tue, 6 Feb 2001 12:44:43 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f16GQS231657 for seamoby-list; Tue, 6 Feb 2001 08:26:28 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f16GQQo31652 for ; Tue, 6 Feb 2001 08:26:26 -0800 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 HAA07337; Tue, 6 Feb 2001 07:34:43 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f16FYfT15699; Tue, 6 Feb 2001 07:34:41 -0800 X-Virus-Scanned: Tue, 6 Feb 2001 07:34:41 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdT9NTjm; Tue, 06 Feb 2001 07:34:37 PST Message-ID: <3A80198E.B0D0388C@iprg.nokia.com> Date: Tue, 06 Feb 2001 07:34:38 -0800 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: seamoby@diameter.org Subject: Re: [seamoby] Re: context transfer/fast MIP conflict (was: [seamoby-mm] FW: I-D ACTION:draft-designteam-fast-mipv6-00.txt) References: <01D91AFB08B6D211BFD00008C7EABAE10680A839@eseis04nok> <14972.26474.972825.310927@thomasm-u1.cisco.com> <3A7C88CD.BA373BC4@iprg.nokia.com> <14972.38725.417965.650464@thomasm-u1.cisco.com> <3A7CA09C.4CAAE1FE@iprg.nokia.com> <14972.45766.832605.237746@thomasm-u1.cisco.com> <3A7CB8FB.8DFD32C1@iprg.nokia.com> <14973.53062.314908.356967@thomasm-u1.cisco.com> <3A7DE2A0.453F324D@iprg.nokia.com> <14973.62450.411228.130495@thomasm-u1.cisco.com> <3A7E241B.A5AF6100@iprg.nokia.com> <14975.15821.457300.727601@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Mike, > Why can't ARnew get the MAC address in the > usual way? Ie, through ARP or ND? This only looks > like an optimization of one round trip on the > local media which is certainly not on the same > order latency as what fast handoff is trying > to counter. Any such round trip comes equipped with retransmission timers and failure conditions. So, even if I agreed with your premise (which I do not) I would still believe it is highly advantageous to eliminate control messages over the air. Furthermore, we have to design a protocol that allows access routers to work better even if they have hundreds of thousands of attached mobile nodes. I claim that eliminating this round trip that you mention is more than worth the effort. And I do not see any downside. > As for DAD, I sort of like the optimistic > do-dad-in-parallel optimistic approach. Since > we could easily put that in the SEAMOBY CT > protocol, we could have it both ways > eventually. One problem that has to be considered (according to strict IPv6 design guidelines) is what to do if two mobile nodes end up trying to use the same link-local address. DAD prevents that. Any strategy deviating from DAD has to also prevent that. I believe that the design team has achieved that goal, but the cost is some signaling between access routers. I'm not sure what you mean about having it both ways. > Honestly, I really like the idea of keeping > fast handoffs localized just within MN and > ARold. Involving ARnew adds more complexity > to that which is otherwise a fairly clean > mechanism. Context transfer -- as a router > router mechanism -- explicitly says that you're > willing to deal with all of the added > complexity of moving stuff around (besides > routes). It would be nice to have a mechanism > which doesn't require that heft too. Fast > handoff without HI/HACK fits that middle > ground, IMO. You have made your opinion very clear! There is a tradeoff between signaling between routers and speed of handovers. I think it is clear that we can get significantly faster and less error-prone handovers by specifying a bit of signaling between routers. You are trying to convince people otherwise. Maybe it's time to get a little field experience and compare notes. > The problem is that it's impossible to tell you > whether your transport vessel is a good one at > this point. This is in the eye of the beholder. I'm 95% sure that it's a good one, and a number of highly qualified people have been staring at it for months. The design team didn't get to this point accidentally after a wild night of bar-hopping. There has been a great deal of serious design and engineering consideration going into it. That may not help you decide, but at least you ought to recognize the effort and the possibility for good. > I was fairly certain that a > destination option wasn't the right answer, but > can't tell you whether ICMP is adequate and > won't be able to tell you until the > requirements are nailed down. Assuming you go > forward with HI/HACK and they don't fit the > requirements, you'll be somewhere around last > call and we'll have a conflict if we want to > combine the two (as I think they should be). > > And hence this entire thread. Unfortunately, your statement is tautologically true, and hence somewhat unpersuasive. One can _always_ take the viewpoint that some "other way" is better, until the specification for that other way is able to be inspected, constructed, and tested. We've put out something that can be inspected. You do not find it compelling, but as best I can tell mainly because you view it as a design constraint on your own underspecified problem space. I'm not trying to put words in your mouth, though, so if I have the wrong picture please set me straight. And, in the meantime, perhaps we can make further engineering observations about how best to proceed. Regards, Charlie P. PS. I cut down the number of respondents. I reckon if they care, by now they know where to find us. From owner-seamoby@diameter.org Tue Feb 6 13:56:12 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27937 for ; Tue, 6 Feb 2001 13:56:11 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f16HZAa31762 for seamoby-list; Tue, 6 Feb 2001 09:35:10 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from NEPTUNE.zucotto.com ([216.95.209.154]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f16HXqo31757 for ; Tue, 6 Feb 2001 09:33:52 -0800 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21) id ; Tue, 6 Feb 2001 11:42:13 -0500 Message-ID: From: Kulwinder Atwal To: "'Patrice Calhoun'" , Kulwinder Atwal Cc: Phil_Neumiller@3Com.com, seamoby@diameter.org Subject: RE: [seamoby] Re: New name -> Seamless to become Hidden Handover? ? Date: Tue, 6 Feb 2001 11:42:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk It was a general statement. In no way am I suggested it. My point is move to SCTP/IP. TCP/SCTP will not work. - Kulwinder. > -----Original Message----- > From: Patrice Calhoun [mailto:pcalhoun@nasnfs.eng.sun.com] > Sent: Tuesday, February 06, 2001 8:48 AM > To: Kulwinder Atwal > Cc: 'Patrice Calhoun'; Phil_Neumiller@3com.com; seamoby@diameter.org > Subject: RE: [seamoby] Re: New name -> Seamless to become Hidden > Handover? ? > > > > I suppose one could provide an API on either end that > converts TCP packets > > to SCTP > > before transmission, but there is no gauranttee the other > side will do the > > same. > > If one is going to do this, one may ask why not just put > the effort into > > moving to > > SCTP instead? > > No gateways please. Breaking the end-to-end model is not on > our charter. > > I really do not understand how this thread has anything to do > with seamby, btw. > PatC > From owner-seamoby@diameter.org Tue Feb 6 15:15:17 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00523 for ; Tue, 6 Feb 2001 15:15:16 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f16JMWY32092 for seamoby-list; Tue, 6 Feb 2001 11:22:32 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f16JMTo32087 for ; Tue, 6 Feb 2001 11:22:29 -0800 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 KAA00288; Tue, 6 Feb 2001 10:30:49 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT26046; Tue, 6 Feb 2001 10:30:46 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA01453; Tue, 6 Feb 2001 10:30:45 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14976.17107.345347.784263@thomasm-u1.cisco.com> Date: Tue, 6 Feb 2001 10:30:43 -0800 (PST) To: "Charles E. Perkins" Cc: Michael Thomas , seamoby@diameter.org Subject: Re: [seamoby] Re: context transfer/fast MIP conflict (was: [seamoby-mm] FW: I-D ACTION:draft-designteam-fast-mipv6-00.txt) In-Reply-To: <3A80198E.B0D0388C@iprg.nokia.com> References: <01D91AFB08B6D211BFD00008C7EABAE10680A839@eseis04nok> <14972.26474.972825.310927@thomasm-u1.cisco.com> <3A7C88CD.BA373BC4@iprg.nokia.com> <14972.38725.417965.650464@thomasm-u1.cisco.com> <3A7CA09C.4CAAE1FE@iprg.nokia.com> <14972.45766.832605.237746@thomasm-u1.cisco.com> <3A7CB8FB.8DFD32C1@iprg.nokia.com> <14973.53062.314908.356967@thomasm-u1.cisco.com> <3A7DE2A0.453F324D@iprg.nokia.com> <14973.62450.411228.130495@thomasm-u1.cisco.com> <3A7E241B.A5AF6100@iprg.nokia.com> <14975.15821.457300.727601@thomasm-u1.cisco.com> <3A80198E.B0D0388C@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-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Charles E. Perkins writes: > > Why can't ARnew get the MAC address in the > > usual way? Ie, through ARP or ND? This only looks > > like an optimization of one round trip on the > > local media which is certainly not on the same > > order latency as what fast handoff is trying > > to counter. > > Any such round trip comes equipped with retransmission > timers and failure conditions. So, even if I agreed > with your premise (which I do not) I would still believe > it is highly advantageous to eliminate control messages > over the air. > > Furthermore, we have to design a protocol that allows > access routers to work better even if they have > hundreds of thousands of attached mobile nodes. It would be even more advantagous for the router to do some mind reading. I'm sorry, but this is completely unpersuasive. Fast handoff's job is to come up with a way that deals with in-flight data for the potentially long round trips to HA's and CN's. It wasn't to explore every possible optimization for the least common denominator. I, for one, think it is a lousy idea for an 802.11 network which has ample bandwidth and doesn't want to deal with the administrative nonsense of having to get adjacent routers to know and trust one another. Yet the last draft I saw makes HI/HACK MUST requirements. Bletch. > Furthermore, we have to design a protocol that allows > access routers to work better even if they have > hundreds of thousands of attached mobile nodes. Please explain the scaling issue here. If a router melts down because of a single round trip to do ARP/ND per node, it's got way bigger problems than the MIP WG can help with. > I claim that eliminating this round trip that you > mention is more than worth the effort. And I do not > see any downside. Sure there's downside: you're *requiring* network administrators to set up the provisioning and security between AR's. That is *hardly* inconsequential. > You have made your opinion very clear! There is a > tradeoff between signaling between routers and speed > of handovers. I think it is clear that we can get > significantly faster and less error-prone handovers > by specifying a bit of signaling between routers. _Significantly_? It sure looks like it's down several orders of magnitude to me. Like one round trip on the local interface vs. round trips across the world. > > The problem is that it's impossible to tell you > > whether your transport vessel is a good one at > > this point. > > This is in the eye of the beholder. I'm 95% sure that > it's a good one, and a number of highly qualified people > have been staring at it for months. How can you say that when your design team just decided to switch to ICMP? How can you know that CT's requirements won't require a reliable datastream using, say, SCTP because context doesn't fit within an MTU and we need congestion avoidence? I think it's entirely premature to be spouting 95% confidence levels. > The design team > didn't get to this point accidentally after a wild > night of bar-hopping. Yes, but does it pass the Turing Test? Mike From owner-seamoby@diameter.org Tue Feb 6 15:49:48 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01536 for ; Tue, 6 Feb 2001 15:49:48 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f16JwHI32171 for seamoby-list; Tue, 6 Feb 2001 11:58:17 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f16JwFo32166 for ; Tue, 6 Feb 2001 11:58:15 -0800 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 LAA28924; Tue, 6 Feb 2001 11:06:33 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f16J6UC04195; Tue, 6 Feb 2001 11:06:30 -0800 X-Virus-Scanned: Tue, 6 Feb 2001 11:06:30 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from dhcp-3-111.iprg.nokia.com (205.226.3.111, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdL6TxYt; Tue, 06 Feb 2001 11:05:35 PST Message-ID: <3A804928.AB6F8A30@iprg.nokia.com> Date: Tue, 06 Feb 2001 10:57:44 -0800 From: "Charles E. Perkins" Organization: Nokia X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: seamoby@diameter.org Subject: Re: [seamoby] Re: context transfer/fast MIP conflict (was: [seamoby-mm] FW: I-D ACTION:draft-designteam-fast-mipv6-00.txt) References: <01D91AFB08B6D211BFD00008C7EABAE10680A839@eseis04nok> <14972.26474.972825.310927@thomasm-u1.cisco.com> <3A7C88CD.BA373BC4@iprg.nokia.com> <14972.38725.417965.650464@thomasm-u1.cisco.com> <3A7CA09C.4CAAE1FE@iprg.nokia.com> <14972.45766.832605.237746@thomasm-u1.cisco.com> <3A7CB8FB.8DFD32C1@iprg.nokia.com> <14973.53062.314908.356967@thomasm-u1.cisco.com> <3A7DE2A0.453F324D@iprg.nokia.com> <14973.62450.411228.130495@thomasm-u1.cisco.com> <3A7E241B.A5AF6100@iprg.nokia.com> <14975.15821.457300.727601@thomasm-u1.cisco.com> <3A80198E.B0D0388C@iprg.nokia.com> <14976.17107.345347.784263@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, > > Any such round trip comes equipped with retransmission > > timers and failure conditions. So, even if I agreed > > with your premise (which I do not) I would still believe > > it is highly advantageous to eliminate control messages > > over the air. > > > > Furthermore, we have to design a protocol that allows > > access routers to work better even if they have > > hundreds of thousands of attached mobile nodes. > > It would be even more advantagous for the router > to do some mind reading. I'm sorry, but this is > completely unpersuasive. I didn't think I said anything so horrid as to evoke mockery. > Fast handoff's job is > to come up with a way that deals with in-flight > data for the potentially long round trips to HA's > and CN's. It wasn't to explore every possible optimization > for the least common denominator. In the first place, Mobile IPv6 already offers a way for a mobile node to connect the dots between its previous and new access routers. In the second place, it doesn't have to be limited to "in-flight" data. You don't have any need nor grounds to make the accusation implicit in that second sentence. > I, for one, think > it is a lousy idea for an 802.11 network which > has ample bandwidth and doesn't want to deal > with the administrative nonsense of having to > get adjacent routers to know and trust one > another. Yet the last draft I saw makes HI/HACK > MUST requirements. Bletch. They are requirements for routers that implement the protocol. They are not requirements for routers that do not implement the protocol. I guess that we're doomed to be receptacles for Thomas-Bletch for the foreseeable future. I, for one, think it's a lousy idea to carry on an argument when I'm doomed to be Bletched-on, but I'll do it anyway for a short while longer. > > Furthermore, we have to design a protocol that allows > > access routers to work better even if they have > > hundreds of thousands of attached mobile nodes. > > Please explain the scaling issue here. If a > router melts down because of a single round trip to > do ARP/ND per node, it's got way bigger problems than > the MIP WG can help with. A problem here, a problem there, and sooner or later you really have a problem. > > I claim that eliminating this round trip that you > > mention is more than worth the effort. And I do not > > see any downside. > > Sure there's downside: you're *requiring* network > administrators to set up the provisioning and > security between AR's. That is *hardly* > inconsequential. We decided not to design the inter-router discovery protocol, since the fast handover part could be done separately and more quickly. > > You have made your opinion very clear! There is a > > tradeoff between signaling between routers and speed > > of handovers. I think it is clear that we can get > > significantly faster and less error-prone handovers > > by specifying a bit of signaling between routers. > > _Significantly_? It sure looks like it's down > several orders of magnitude to me. Like one > round trip on the local interface vs. round > trips across the world. Compared to what? The mobile node, using our protocol, should be able to get on the air immediately upon connecting to a new access router. We avoid DAD and ND, under typical circumstances. Avoiding the routing trip across the world is already available using Mobile IPv6, given appropriate security. > > This is in the eye of the beholder. I'm 95% sure that > > it's a good one, and a number of highly qualified people > > have been staring at it for months. > > How can you say that when your design team just > decided to switch to ICMP? How can you know > that CT's requirements won't require a reliable > datastream using, say, SCTP because context > doesn't fit within an MTU and we need > congestion avoidence? Switching to ICMP didn't alter the basic control flow. We could still switch back if need be. We could still switch to UDP if need be. Nobody claimed infallibility, nor intransigence, as you seem to imply. And, I stand by my statement. > I think it's entirely premature to be spouting > 95% confidence levels. O.K., a clarification: I am 100% confident that the design is not finished. I am 95% confident that the design is good. Well, maybe 92%. I lost my black and white crayons. > > The design team > > didn't get to this point accidentally after a wild > > night of bar-hopping. > > Yes, but does it pass the Turing Test? Please explain to me how that is going to move us towards any beneficial resolution to the questions you have raised. Charlie P. From owner-seamoby@diameter.org Tue Feb 6 19:24:46 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05086 for ; Tue, 6 Feb 2001 19:24:46 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f16NROh32648 for seamoby-list; Tue, 6 Feb 2001 15:27:24 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f16NRLo32643 for ; Tue, 6 Feb 2001 15:27:21 -0800 Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2650.21) id <1M1X1TXZ>; Tue, 6 Feb 2001 17:35:30 -0500 Message-ID: From: George Tsirtsis To: "'Michael Thomas'" , "Charles E. Perkins" Cc: seamoby@diameter.org Subject: RE: [seamoby] Re: context transfer/fast MIP conflict (was: [seamo by-mm] FW: I-D ACTION:draft-designteam-fast-mipv6-00.txt) Date: Tue, 6 Feb 2001 17:35:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi Michael, I apologize in advance for only having glanced at this discussion but I am trying to understand what is really bothering you. From what I can say you do not like the idea that we use HI/HACK messages between old and newARs...and the reason is that you want to define those after you consider context transfer in seamoby? Moreover you also seam to think that the newAR should be not be involved at all with the fast handoff, is this true? If yes, could you please let us know how this can be done? I would be very interested in such scheme. Are the above your main objections? If not, please do correct me... George -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Tuesday, February 06, 2001 6:31 PM To: Charles E. Perkins Cc: Michael Thomas; seamoby@diameter.org Subject: Re: [seamoby] Re: context transfer/fast MIP conflict (was: [seamoby-mm] FW: I-D ACTION:draft-designteam-fast-mipv6-00.txt) Charles E. Perkins writes: > > Why can't ARnew get the MAC address in the > > usual way? Ie, through ARP or ND? This only looks > > like an optimization of one round trip on the > > local media which is certainly not on the same > > order latency as what fast handoff is trying > > to counter. > > Any such round trip comes equipped with retransmission > timers and failure conditions. So, even if I agreed > with your premise (which I do not) I would still believe > it is highly advantageous to eliminate control messages > over the air. > > Furthermore, we have to design a protocol that allows > access routers to work better even if they have > hundreds of thousands of attached mobile nodes. It would be even more advantagous for the router to do some mind reading. I'm sorry, but this is completely unpersuasive. Fast handoff's job is to come up with a way that deals with in-flight data for the potentially long round trips to HA's and CN's. It wasn't to explore every possible optimization for the least common denominator. I, for one, think it is a lousy idea for an 802.11 network which has ample bandwidth and doesn't want to deal with the administrative nonsense of having to get adjacent routers to know and trust one another. Yet the last draft I saw makes HI/HACK MUST requirements. Bletch. > Furthermore, we have to design a protocol that allows > access routers to work better even if they have > hundreds of thousands of attached mobile nodes. Please explain the scaling issue here. If a router melts down because of a single round trip to do ARP/ND per node, it's got way bigger problems than the MIP WG can help with. > I claim that eliminating this round trip that you > mention is more than worth the effort. And I do not > see any downside. Sure there's downside: you're *requiring* network administrators to set up the provisioning and security between AR's. That is *hardly* inconsequential. > You have made your opinion very clear! There is a > tradeoff between signaling between routers and speed > of handovers. I think it is clear that we can get > significantly faster and less error-prone handovers > by specifying a bit of signaling between routers. _Significantly_? It sure looks like it's down several orders of magnitude to me. Like one round trip on the local interface vs. round trips across the world. > > The problem is that it's impossible to tell you > > whether your transport vessel is a good one at > > this point. > > This is in the eye of the beholder. I'm 95% sure that > it's a good one, and a number of highly qualified people > have been staring at it for months. How can you say that when your design team just decided to switch to ICMP? How can you know that CT's requirements won't require a reliable datastream using, say, SCTP because context doesn't fit within an MTU and we need congestion avoidence? I think it's entirely premature to be spouting 95% confidence levels. > The design team > didn't get to this point accidentally after a wild > night of bar-hopping. Yes, but does it pass the Turing Test? Mike From owner-seamoby@diameter.org Wed Feb 7 22:10:23 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA15673 for ; Wed, 7 Feb 2001 22:10:23 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f181b0u03143 for seamoby-list; Wed, 7 Feb 2001 17:37:00 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f181Zho03138 for ; Wed, 7 Feb 2001 17:35:43 -0800 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 QAA12894; Wed, 7 Feb 2001 16:44:18 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAV10286; Wed, 7 Feb 2001 16:44:02 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA01862; Wed, 7 Feb 2001 16:44:02 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14977.60369.946233.757353@thomasm-u1.cisco.com> Date: Wed, 7 Feb 2001 16:44:01 -0800 (PST) To: "Hesham Soliman (ERA)" Cc: "'Michael Thomas'" , seamoby@diameter.org Subject: RE: [seamoby] Single sentence problem statements In-Reply-To: <034BEFD03799D411A59F00508BDF75465B698C@esealnt448.al.sw.ericsson.se> References: <034BEFD03799D411A59F00508BDF75465B698C@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-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hesham Soliman (ERA) writes: > > This is one area that I'd far prefer that if there > > is a way to get this all to work in the usual way > > (read: just recreating the SA), it should be > > considered. > > > => Not if you're moving fast within small subnets and > trying to save spectrum ! Hopefully it doesn't come down to this kind of tradeoff. > You ignored point #2 because you agree with it ? No, it's because I generally ignore all of this krufty back to back tunnel stuff since it's just PSTN access tandems in IP clothes. > > > As for IKE and whether it's too heavy, spectrum inefficient ..etc > > > please have a look at draft-soliman-mobileip-routeopt--mipv6-00.txt > > > which proposes an alternative. > > > > This is _simpler_ than IKE? Yikes. Also: it looks > > like you've managed to recreate the cross realm > > Kerberos wheel with about 15 years less deployment > > experience. > > > => So Sending one message from the MN to establish an > SA is more complex than doing an IKE exchange in your opinion ? > Apart from suffering the "Yikes", is there a technical argument > against the draft ? > Really, we'd like to get some technical feedback. Well, first of all the notion that CN has any relationship with a AAA of any sort is highly suspect, IMO. Whose AAA is my apache web server supposed to be contacting? Second, if you want centralized key distribution in the manner you are describing, Kerberos is a far better fit and has been around forever. Kerberos in general has a lot of very appealing properties for fast mobility and scaling. Mike From owner-seamoby@diameter.org Wed Feb 7 22:12:39 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA15691 for ; Wed, 7 Feb 2001 22:12:39 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f181tHu03170 for seamoby-list; Wed, 7 Feb 2001 17:55:17 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f181rwo03165 for ; Wed, 7 Feb 2001 17:53:58 -0800 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 f1812NC22212 for ; Thu, 8 Feb 2001 02:02:23 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Thu Feb 08 02:03:30 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id <1CVM7ACS>; Thu, 8 Feb 2001 02:03:30 +0100 Message-ID: <034BEFD03799D411A59F00508BDF75465B69BB@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: seamoby@diameter.org Subject: RE: [seamoby] Single sentence problem statements Date: Thu, 8 Feb 2001 01:58:03 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-seamoby@diameter.org Precedence: bulk > > > This is one area that I'd far prefer that if there > > > is a way to get this all to work in the usual way > > > (read: just recreating the SA), it should be > > > considered. > > > > > => Not if you're moving fast within small subnets and > > trying to save spectrum ! > > Hopefully it doesn't come down to this kind of > tradeoff. > => Which tradeoff, the fast mobility part or the small coverage areas or saving spectrum. I don't want to be the one delivering news to wireless operators that they will be wasting some of their billions of dollars on licences because of a problem that can be avoided. > > > You ignored point #2 because you agree with it ? > > No, it's because I generally ignore all of this krufty > back to back tunnel stuff since it's just PSTN access > tandems in IP clothes. > => Hmmm ... PSTN huh. I guess I'll ignore that. Not worth pursuing really. Either you don't know what PSTN is or you're talking about a different solution from the one I mentioned. > > > > As for IKE and whether it's too heavy, spectrum inefficient ..etc > > > > please have a look at draft-soliman-mobileip-routeopt--mipv6-00.txt > > > > which proposes an alternative. > > > > > > This is _simpler_ than IKE? Yikes. Also: it looks > > > like you've managed to recreate the cross realm > > > Kerberos wheel with about 15 years less deployment > > > experience. > > > > > => So Sending one message from the MN to establish an > > SA is more complex than doing an IKE exchange in your opinion ? > > Apart from suffering the "Yikes", is there a technical argument > > against the draft ? > > Really, we'd like to get some technical feedback. > > Well, first of all the notion that CN has any > relationship with a AAA of any sort is highly > suspect, IMO. Whose AAA is my apache web > server supposed to be contacting? > => When people are trying to get customers to pay for their services on the Internet I guess they'll see the need for AAA. Even if they're offering services for free, they still need to keep the "trouble makers" away from their networks. AAA can do that. > Second, if you want centralized key distribution in > the manner you are describing, Kerberos is a far > better fit and has been around forever. Kerberos in > general has a lot of very appealing properties for > fast mobility and scaling. > => I'm not trying to replace Kerberos or IKE for that matter and never claimed this method is better than either one. The idea was that since AAA will be widely deployed (at least in mobile networks) it can be taken advantage of in this manner. Hesham From owner-seamoby@diameter.org Wed Feb 7 23:33:46 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA17722 for ; Wed, 7 Feb 2001 23:33:45 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f1831JD03293 for seamoby-list; Wed, 7 Feb 2001 19:01:19 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from ee.cornell.edu (anise.ee.cornell.edu [128.84.239.14]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f18300o03286 for ; Wed, 7 Feb 2001 19:00:00 -0800 Received: from verdi.ee.cornell.edu (verdi.ee.cornell.edu [128.84.240.71]) by ee.cornell.edu (8.9.3/8.9.1) with ESMTP id VAA10885; Wed, 7 Feb 2001 21:08:19 -0500 (EST) Date: Wed, 7 Feb 2001 21:07:46 -0500 (EST) From: Zygmunt Haas To: Phil_Neumiller@3Com.com cc: Charlie Perkins , seamoby@diameter.org, manet@itd.nrl.navy.mil Subject: Re: [seamoby] Upcoming REAL IP for Bluetooth BOF In-Reply-To: <882569EA.00760153.00@hqoutbound.ops.3com.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk Hi Phil, As a side note, you forgot the issue of hybrid protocols; i.e., the tradeoff between proactive and reactive routing, as to achieve adaptivity in the operation/configuration of an ad hoc network. Yes, the Zone Routing Protocol (ZRP) is an example of a framework that supports such a tradeoff. Yes, it has been worked on and some preliminary results presented in the IETF meetings. Zygmunt. ===--==== ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- Prof. Zygmunt J. Haas tel: +1-607-255-3454 Wireless Networks Laboratory School of Electrical Engineering fax: +1-607-255-9072 Cornell University 323 Frank Rhodes Hall e-mail: haas@ece.cornell.edu Ithaca, NY 14853 U.S.A http://www.ee.cornell.edu/~haas/wnl.html ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- -------------------------------------------------------------------------- Words of Wisdom: "Turns out that not where, but who you are with that really matters." David Matthews -------------------------------------------------------------------------- On Mon, 5 Feb 2001 Phil_Neumiller@3com.com wrote: > > > > Hi Charlie, > > I cross-posted this to MANET, please forgive multiple copies. > > BTW, Thanks for the AODV recommendation... > > As a casual observer of MANET activity I look at the work and I see no RFC > for basic ad hoc networking. Case closed. I do see the following work in > progress (which as been in progress for some time): > > o (AODV) Routing > o Temporally-Ordered Routing Algorithm (TORA) > o The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks > o Optimized Link State Routing Protocol > o Differential Destination Multicast (DDM) Specification > o Multicast Ad hoc On-Demand Distance Vector (MAODV) > o Topology Broadcast based on Reverse-Path Forwarding (TBRPF) > o Landmark Routing Protocol (LANMAR) for Large Scale Ad Hoc Networks > o A Simple Protocol for Multicast and Broadcast in Mobile Ad Hoc Networks > o Fisheye State Routing Protocol (FSR) for Ad Hoc Networks > > While I am quite convinced that ALL this work is valuable and useful it > does not solve my basic problems (at least not in a standard way). > WHAT IS THE IETF's consensus and current recommendation for basic > ad hoc networking??? Would this work not prove to be better served > in the IRTF? It seems the MANET WG should be working more towards > a consensus and a standard RFC protocol for ad hoc networking right? > If I am out of order here please explain. > > Thanks, > > -Phil > > > From owner-seamoby@diameter.org Thu Feb 8 06:58:47 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04467 for ; Thu, 8 Feb 2001 06:58:47 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f18AO9204068 for seamoby-list; Thu, 8 Feb 2001 02:24:09 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f18AO4o04063 for ; Thu, 8 Feb 2001 02:24:05 -0800 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 f189WVf07129 for ; Thu, 8 Feb 2001 11:32:31 +0200 (EET) Received: from esebh11nok.ntc.nokia.com (unverified) by esvir06nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 8 Feb 2001 11:32:31 +0200 Received: by esebh11nok with Internet Mail Service (5.5.2652.78) id <1LYPTG64>; Thu, 8 Feb 2001 11:32:31 +0200 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680A902@eseis04nok> From: john.loughney@nokia.com To: Hesham.Soliman@era.ericsson.se Cc: seamoby@diameter.org Subject: RE: [seamoby] Single sentence problem statements Date: Thu, 8 Feb 2001 11:32:28 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi Hesham, > => I was referring to MIP extensions like Regional for MIPv4 > and HMIPv6 for MIPv6. I kind of guessed, but just wanted to make sure :) > => I'm not trying to discuss solutions or push any ideas > on the group. I was simply questioning the problem > statement that Phil sent. Especially the first sentence > which I believe is an inaccurate statement about > MIP. > So I hope this doesn't get misinterpreted as a push for > HMIPv6 or other solutions. Not a problem, if & when it is time to discuss solutions, I'd hope you'd state the case for HMIPv6. Also, MIP is somewhat of an amorphous beast - depending upon what extensions you support, etc. I think that people's results will vary greatly, depending upon what extensions are used, etc. > => Sure. All I want to emphasise is that to come up > with a problem statement, you MUST say what is wrong > with the existing solutions. Otherwise it is not clear what > the problem is. Except it is hard to hit a moving target. I think that the first draft should attempt to be a more generic problem statement, meaning what it is we want to solve. The problem would be something that isn't being mass deployed at the moment. Again, if the problem is solved with HMIPv6 + context transfer (for example), then documenting this is useful. If another solution is needed, then we still need a paper trail, IMO. > => Ok, but what is "normal" ? > In the fast handoffs work we were aiming to come close to > zero loss due to L3 handoff. How close ? well that's what the > investigation should say. > Of course losses due to L2 handoff were out of scope. I'd say that we are talking about the same target. Though, I have a question - I thought that goal of the fast handover was 'fastness' i.e. - accomplish the handover with minimal delay, therefor reduce any latentcy due to the handover process. Is seamlessness a goal as well? thanks, John From owner-seamoby@diameter.org Thu Feb 8 07:09:40 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04466 for ; Thu, 8 Feb 2001 06:58:47 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f18AZxe04097 for seamoby-list; Thu, 8 Feb 2001 02:35:59 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f18AZto04092 for ; Thu, 8 Feb 2001 02:35:56 -0800 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 f189iMC03050 for ; Thu, 8 Feb 2001 10:44:22 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Feb 08 10:44:29 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id <1CVZRS9P>; Thu, 8 Feb 2001 10:39:56 +0100 Message-ID: <034BEFD03799D411A59F00508BDF75465B69C1@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: seamoby@diameter.org Subject: RE: [seamoby] Single sentence problem statements Date: Thu, 8 Feb 2001 10:40:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-seamoby@diameter.org Precedence: bulk Hi John, > > => I'm not trying to discuss solutions or push any ideas > > on the group. I was simply questioning the problem > > statement that Phil sent. Especially the first sentence > > which I believe is an inaccurate statement about > > MIP. > > So I hope this doesn't get misinterpreted as a push for > > HMIPv6 or other solutions. > > Not a problem, if & when it is time to discuss solutions, > I'd hope you'd state the case for HMIPv6. > > Also, MIP is somewhat of an amorphous beast - depending upon > what extensions you support, etc. I think that people's > results will vary greatly, depending upon what extensions > are used, etc. > => Well, I'm only referring to one draft for V4 and one for V6. > > > => Sure. All I want to emphasise is that to come up > > with a problem statement, you MUST say what is wrong > > with the existing solutions. Otherwise it is not clear what > > the problem is. > > Except it is hard to hit a moving target. I think that the first > draft should attempt to be a more generic problem statement, > meaning what it is we want to solve. The problem would be something > that isn't being mass deployed at the moment. Again, if > the problem is solved with HMIPv6 + context transfer (for example), > then documenting this is useful. If another solution is needed, > then we still need a paper trail, IMO. > => Ok. > > => Ok, but what is "normal" ? > > In the fast handoffs work we were aiming to come close to > > zero loss due to L3 handoff. How close ? well that's what the > > investigation should say. > > Of course losses due to L2 handoff were out of scope. > > I'd say that we are talking about the same target. Though, I have > a question - I thought that goal of the fast handover was 'fastness' > i.e. - accomplish the handover with minimal delay, therefor reduce > any latentcy due to the handover process. Is seamlessness a goal > as well? > => Well, if seamless means no packet loss and transfer of all the relevant states (QoS, AAA....etc) then I'd say we didn't aim for that. We aimed for minimising losses due to L3 handover. There is nothing we can do in IETF about L2 handover IMO. So we can't guarantee zero packet loss in the intra-access technology case. At least this is my understanding. Hesham From owner-seamoby@diameter.org Thu Feb 8 10:01:51 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09206 for ; Thu, 8 Feb 2001 10:01:51 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f18CoIe04475 for seamoby-list; Thu, 8 Feb 2001 04:50:18 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f18CoEo04470 for ; Thu, 8 Feb 2001 04:50:14 -0800 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 f18Bwfd24222 for ; Thu, 8 Feb 2001 12:58:42 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Feb 08 12:58:41 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id <1CVM74CJ>; Thu, 8 Feb 2001 12:58:44 +0100 Message-ID: <5F05C89FB2F8D211B6430008C7919127074603F3@esealnt190> From: "Karim El-Malki (ERA)" To: "'Michael Thomas'" Cc: seamoby@diameter.org Subject: RE: [seamoby] Single sentence problem statements Date: Thu, 8 Feb 2001 12:58:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hello Mike > > > > As for IKE and whether it's too heavy, spectrum > inefficient ..etc > > > > please have a look at > draft-soliman-mobileip-routeopt--mipv6-00.txt > > > > which proposes an alternative. > > > > > > This is _simpler_ than IKE? Yikes. Also: it looks > > > like you've managed to recreate the cross realm > > > Kerberos wheel with about 15 years less deployment > > > experience. > > > > > => So Sending one message from the MN to establish an > > SA is more complex than doing an IKE exchange in your opinion ? > > Apart from suffering the "Yikes", is there a technical argument > > against the draft ? > > Really, we'd like to get some technical feedback. > > Well, first of all the notion that CN has any > relationship with a AAA of any sort is highly > suspect, IMO. Whose AAA is my apache web > server supposed to be contacting? Clearly it doesn't apply to all cases and this was not the purpose of the draft. On the other hand I expect the AAA infrastructure to be widespread, it already includes some KDC functionality and therefore looks pretty good for the purpose of things like SA establishment for Mobile IP route opt. between mobile devices. My thinking is that Route opt will be most useful for real-time applications between mobiles so your apache web server example was not the aim. > > Second, if you want centralized key distribution in > the manner you are describing, Kerberos is a far > better fit and has been around forever. Kerberos in > general has a lot of very appealing properties for > fast mobility and scaling. > The mechanism in the draft is different from Kerberos. We try to eliminate the direct communication between nodes and only go through the AAA infrastructure. Also, you seem to be assuming that Kerberos KDCs will be available everywhere while AAA won't be? Rgds /Karim From owner-seamoby@diameter.org Thu Feb 8 14:23:50 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17469 for ; Thu, 8 Feb 2001 14:23:47 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f18HuSR05179 for seamoby-list; Thu, 8 Feb 2001 09:56:28 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from homerun.comdev.cc (adsl-63-194-99-36.dsl.snlo01.pacbell.net [63.194.99.36]) by charizard.diameter.org (8.10.0/8.10.0) with SMTP id f18HuPo05174 for ; Thu, 8 Feb 2001 09:56:25 -0800 Received: (qmail 3888 invoked from network); 8 Feb 2001 17:04:53 -0000 Received: from soldout.comdev.cc (HELO soldout) (192.168.67.89) by homerun.comdev.cc with SMTP; 8 Feb 2001 17:04:53 -0000 From: "Mat Horan" To: Subject: [seamoby] FW: Mobile Host -> Mobile Terminal name change proposal Date: Thu, 8 Feb 2001 09:06:42 -0800 Message-ID: <00a801c091f1$82b9e2a0$5943a8c0@soldout> 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit As long as we're considering definition name changes I'd like to propose changing the term Mobile Host to Mobile Terminal. The functionality of this device remains the same as does the name and functionality of the Mobile Node. The reason for this is that many implementations may use a device other than a "PC" to connect to an Access Point or Mobile Node. This device may connect to a "PC" or may be embedded. Regards, Mat Mat Horan COM DEV Wireless Group 805.544.1089 x2244 (v), 805.544.2055 (f) http://www.comdev.cc -----Original Message----- From: Seamless Mobility Working Group [mailto:SEAMOBY_CONTEXT@STANDARDS.NORTELNETWORKS.COM] On Behalf Of Nakhjiri Madjid-MNAKHJI1 Sent: Wednesday, February 07, 2001 9:12 AM To: SEAMOBY_CONTEXT@STANDARDS.NORTELNETWORKS.COM Henrik, others Based on my email exchange with Rajeev, I like to suggest the following changes. Also, please let me know what you think about the name changes (at the very end of this email), I feel this is something that needs to be addressed and decided at the conference call. Regards, Madjid 3.1.4- I suggest that we add the following to the end of the definition of context 3.1.4 "It should be noted that, not context, but subcontext is the smallest unit of information storage and transfer, in other word, storage and transfer of information for one single microflow at a time (instead of all microflows for the mobile at once) should be allowed." 3.1.2 - I like to add a sentence to the second paragraph of section 3.1.2 as follows Eventual protocol state modifications, needed for proper operation or maximizing utility of the protocol at the new network, are outside the scope of the context definition. The same applies to cases where the protocols at original network are not supported at the new network; matching equivalent protocols at different sides of a seam is outside the scope. [New: However, for cases where the functionality each protocol can be provided based on several mechnisms (example: MPLS and diffserv for QoS, or RTP/UDP/IP and TCP/IP for header compression), states for all supported mechanisms needs to be stored and transfered]. The network element, which stores the state for each protocol will not be determined here (left to protocol/ system implementers). However, the issue of buffering the state during (or until after) the handover might be addressed here. ------------------------------------- Rajeev suggest using the word feature instead of protocol, what do people think? I agree. He is also suggesting to change the name subcontext to context, to make context the smallest unit of transfer, instead of subcontext, do I understand this correctly? If yes, I do not agree. what do people think? From owner-seamoby@diameter.org Thu Feb 8 16:41:34 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20340 for ; Thu, 8 Feb 2001 16:41:34 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f18KHsX05528 for seamoby-list; Thu, 8 Feb 2001 12:17:54 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from NEPTUNE.zucotto.com ([216.95.209.154]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f18KHqo05523 for ; Thu, 8 Feb 2001 12:17:52 -0800 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21) id ; Thu, 8 Feb 2001 14:26:19 -0500 Message-ID: From: Kulwinder Atwal To: "'Mat Horan'" , seamoby@diameter.org Subject: RE: [seamoby] FW: Mobile Host -> Mobile Terminal name change prop osal Date: Thu, 8 Feb 2001 14:26:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk > -----Original Message----- > From: Mat Horan [mailto:Mat.Horan@comdev.cc] > Sent: Thursday, February 08, 2001 12:07 PM > To: seamoby@diameter.org > Subject: [seamoby] FW: Mobile Host -> Mobile Terminal name change > proposal > > > > > As long as we're considering definition name changes I'd like > to propose > changing the term Mobile Host to Mobile Terminal. The > functionality of this > device remains the same as does the name and functionality of > the Mobile > Node. > The reason for this is that many implementations may use a > device other than > a "PC" to connect to an Access Point or Mobile Node. This device may > connect to a "PC" or may be embedded. Could a Mobile Terminal not be a mobile node, or mobile host? Just becuase it is embedded does not reduce its functionality. Please clarify. - Kulwinder. > Regards, > Mat > Mat Horan > COM DEV Wireless Group > 805.544.1089 x2244 (v), 805.544.2055 (f) > http://www.comdev.cc > > > -----Original Message----- > From: Seamless Mobility Working Group > [mailto:SEAMOBY_CONTEXT@STANDARDS.NORTELNETWORKS.COM] On > Behalf Of Nakhjiri > Madjid-MNAKHJI1 > Sent: Wednesday, February 07, 2001 9:12 AM > To: SEAMOBY_CONTEXT@STANDARDS.NORTELNETWORKS.COM > > > Henrik, others > Based on my email exchange with Rajeev, I like to suggest the > following > changes. > Also, please let me know what you think about the name > changes (at the very > end of this email), I feel this is something that needs to be > addressed and > decided at the conference call. > Regards, > Madjid > > > 3.1.4- I suggest that we add the following to the end of the > definition of > context 3.1.4 > "It should be noted that, not context, but subcontext is the > smallest unit > of information storage and transfer, in other word, storage > and transfer of > information for one single microflow at a time (instead of > all microflows > for the mobile at once) should be allowed." > 3.1.2 - I like to add a sentence to the second paragraph of > section 3.1.2 > as follows > Eventual protocol state modifications, needed for proper operation > or maximizing utility of the protocol at the new network, are > outside the scope of the context definition. The same applies to > cases where the protocols at original network are not supported at > the new network; matching equivalent protocols at different sides of > a seam is outside the scope. [New: However, for cases where the > functionality each protocol can be provided based on several mechnisms > (example: MPLS and diffserv for QoS, or RTP/UDP/IP and TCP/IP > for header > compression), states for all supported mechanisms needs to be > stored and > transfered]. The network element, which stores the > state for each protocol will not be determined here (left to > protocol/ system implementers). However, the issue of buffering the > state during (or until after) the handover might be addressed here. > > ------------------------------------- > Rajeev suggest using the word feature instead of protocol, > what do people > think? I agree. > He is also suggesting to change the name subcontext to > context, to make > context the smallest unit of transfer, instead of subcontext, do I > understand this correctly? If yes, I do not agree. what do > people think? > > From owner-seamoby@diameter.org Thu Feb 8 17:55:04 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21191 for ; Thu, 8 Feb 2001 17:55:04 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f18LjZP05708 for seamoby-list; Thu, 8 Feb 2001 13:45:35 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f18LjXo05703 for ; Thu, 8 Feb 2001 13:45:33 -0800 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 MAA01843; Thu, 8 Feb 2001 12:54:08 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAV15865; Thu, 8 Feb 2001 12:53:52 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA02154; Thu, 8 Feb 2001 12:53:52 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14979.1887.967385.641325@thomasm-u1.cisco.com> Date: Thu, 8 Feb 2001 12:53:51 -0800 (PST) To: "Karim El-Malki (ERA)" Cc: "'Michael Thomas'" , seamoby@diameter.org Subject: RE: [seamoby] Single sentence problem statements In-Reply-To: <5F05C89FB2F8D211B6430008C7919127074603F3@esealnt190> References: <5F05C89FB2F8D211B6430008C7919127074603F3@esealnt190> 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-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit First, let me apologize since this is pretty off-topic -- I wanted to take this to mobile-ip, but Nortel's listserv seems to have completely melted down. Karim El-Malki (ERA) writes: > > Well, first of all the notion that CN has any > > relationship with a AAA of any sort is highly > > suspect, IMO. Whose AAA is my apache web > > server supposed to be contacting? > > Clearly it doesn't apply to all cases and this was not the purpose of > the draft. On the other hand I expect the AAA infrastructure to be > widespread, it already includes some KDC functionality and therefore ^ | tenuous to put it in the most charitable terms > looks pretty good for the purpose of things like SA establishment > for Mobile IP route opt. between mobile devices. My thinking is that > Route opt will be most useful for real-time applications between mobiles > so your apache web server example was not the aim. I don't see why there's any advantage if it means that you have to have a completely different mechanism to deal with servers and interrealm. The moblie node is then stuck with yet another way to key SA's. The entire scheme strikes me as a gigantic hack and yet another misuse of AAA which seems to be giant accretion disk of bad ideas. > > Second, if you want centralized key distribution in > > the manner you are describing, Kerberos is a far > > better fit and has been around forever. Kerberos in > > general has a lot of very appealing properties for > > fast mobility and scaling. > > > > The mechanism in the draft is different from Kerberos. We try > to eliminate the direct communication between nodes That sounds like a bug not a feature to me. How, for example, do you plan to allow each host to contribute to the keying material entropy? Cipher suite negotiation? Cross realm keying and policy? Oh, and best of all how does MN/CN trust the AAA? Current AAA assumes unidirectional (client->AAA) trust. > and only go > through the AAA infrastructure. Also, you seem to be assuming that > Kerberos KDCs will be available everywhere while AAA won't be? AAA certainly will not be used where access control is not needed. Kerberos and distributed PKI's at least have the advantage that they address security problems common across narrow slices of the problem space. Mike From owner-seamoby@diameter.org Thu Feb 8 18:30:31 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21514 for ; Thu, 8 Feb 2001 18:30:30 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f18LtJ105728 for seamoby-list; Thu, 8 Feb 2001 13:55:19 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f18LtHo05723 for ; Thu, 8 Feb 2001 13:55:17 -0800 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA04231; Thu, 8 Feb 2001 13:03:41 -0800 (PST) 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 NAA12112; Thu, 8 Feb 2001 13:03:39 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id NAA28766; Thu, 8 Feb 2001 13:03:37 -0800 (PST) Date: Thu, 8 Feb 2001 13:03:38 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: RE: [seamoby] Single sentence problem statements To: Michael Thomas Cc: "Karim El-Malki (ERA)" , seamoby@diameter.org In-Reply-To: "Your message with ID" <14979.1887.967385.641325@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk > Oh, and best of all > how does MN/CN trust the AAA? Current AAA > assumes unidirectional (client->AAA) trust. Correction. RADIUS has a unidirectional trust relationship. Diameter does not, and it's bi-directional relationship is a MUST for Mobile IP. PatC From owner-seamoby@diameter.org Thu Feb 8 18:33:09 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21548 for ; Thu, 8 Feb 2001 18:33:09 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f18MAXP05763 for seamoby-list; Thu, 8 Feb 2001 14:10:33 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f18MAUo05758 for ; Thu, 8 Feb 2001 14:10:30 -0800 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 NAA14941; Thu, 8 Feb 2001 13:18:57 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAV16116; Thu, 8 Feb 2001 13:18:52 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA02157; Thu, 8 Feb 2001 13:18:52 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14979.3388.444091.4700@thomasm-u1.cisco.com> Date: Thu, 8 Feb 2001 13:18:52 -0800 (PST) To: Patrice Calhoun Cc: Michael Thomas , "Karim El-Malki (ERA)" , seamoby@diameter.org Subject: RE: [seamoby] Single sentence problem statements In-Reply-To: References: <14979.1887.967385.641325@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-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Patrice Calhoun writes: > > Oh, and best of all > > how does MN/CN trust the AAA? Current AAA > > assumes unidirectional (client->AAA) trust. > Correction. RADIUS has a unidirectional trust relationship. Diameter does not, > and it's bi-directional relationship is a MUST for Mobile IP. Well, I did say current. The last I heard in the AAA WG, MN and AAA don't directly communicate. How does MN verify the identity of the AAA cryptographically? Is it done case by case? At least Kerberos has IAKERB which gives a standard way to deal with relay-like functionality with mutual authentication. Mike From owner-seamoby@diameter.org Thu Feb 8 20:10:37 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA22513 for ; Thu, 8 Feb 2001 20:10:36 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f18NHWR05869 for seamoby-list; Thu, 8 Feb 2001 15:17:32 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f18NGio05864 for ; Thu, 8 Feb 2001 15:16:44 -0800 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 OAA09059; Thu, 8 Feb 2001 14:25:10 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAV16891; Thu, 8 Feb 2001 14:25:06 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA02178; Thu, 8 Feb 2001 14:25:06 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14979.7361.978311.386618@thomasm-u1.cisco.com> Date: Thu, 8 Feb 2001 14:25:05 -0800 (PST) To: "Hesham Soliman (ERA)" Cc: seamoby@diameter.org Subject: RE: [seamoby] Single sentence problem statements In-Reply-To: <034BEFD03799D411A59F00508BDF75465B69C1@esealnt448.al.sw.ericsson.se> References: <034BEFD03799D411A59F00508BDF75465B69C1@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-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hesham Soliman (ERA) writes: > There is nothing we can do in IETF about L2 handover IMO. > So we can't guarantee zero packet loss in the intra-access > technology case. I don't think that the last sentence follows from the first. Fast handoff seems pretty applicable to both intra and inter access technology. It may just be redundant and possibly less efficient than an intra-L2 solution. Mike From owner-seamoby@diameter.org Fri Feb 9 07:10:26 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA13753 for ; Fri, 9 Feb 2001 07:10:25 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f19Ad3210716 for seamoby-list; Fri, 9 Feb 2001 02:39:03 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from mailhub1.shef.ac.uk (mailhub1.shef.ac.uk [143.167.1.9]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f19Acvo10711 for ; Fri, 9 Feb 2001 02:39:01 -0800 Received: from ridingwood.shef.ac.uk ([143.167.59.249]) by mailhub1.shef.ac.uk with esmtp (Exim 3.16 #1) id 14RA9B-0006Qv-00; Fri, 09 Feb 2001 09:47:21 +0000 Received: from RIDINGWOOD/SpoolDir by ridingwood.shef.ac.uk (Mercury 1.48); 9 Feb 01 09:47:22 +0000 Received: from SpoolDir by RIDINGWOOD (Mercury 1.48); 9 Feb 01 09:47:08 +0000 Received: from Mobile1 (143.167.251.4) by ridingwood.shef.ac.uk (Mercury 1.48); 9 Feb 01 09:47:00 +0000 Message-ID: <005b01c0927c$c4939460$04fba78f@Mobile1> Reply-To: "cnyap" From: "cnyap" To: "Mat Horan" , References: <00a801c091f1$82b9e2a0$5943a8c0@soldout> Subject: Re: [seamoby] FW: Mobile Host -> Mobile Terminal name change proposal Date: Fri, 9 Feb 2001 09:43:33 -0000 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-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi ----- Original Message ----- From: "Mat Horan" To: Sent: Thursday, February 08, 2001 5:06 PM Subject: [seamoby] FW: Mobile Host -> Mobile Terminal name change proposal > > > As long as we're considering definition name changes I'd like to propose > changing the term Mobile Host to Mobile Terminal. The functionality of this > device remains the same as does the name and functionality of the Mobile > Node. > The reason for this is that many implementations may use a device other than > a "PC" to connect to an Access Point or Mobile Node. This device may > connect to a "PC" or may be embedded. > Regards, > Mat > Mat Horan > COM DEV Wireless Group > 805.544.1089 x2244 (v), 805.544.2055 (f) > http://www.comdev.cc > I think there are some differences between Mobile Terminal and Mobile Host. In many case, Mobile Terminal = Physical System. Anything lower than IP Mobile Node/Host = Logical System. Anything runs on IP or higher than IP. Cheers Chern Nam Yap MIEEE, MSc(Res), BSc(Hons) Research Associate Center for Mobile Communication Research Department of Electronic and Electrical Engineering University of Sheffield F132 Mappin Building Mappin Street Sheffield S1 3JD United Kingdom Tel:+44 (0) 114-222-5182 Mobile:+ 44(0) 7712804892 Web: www.mobile1.net E-mail: cny@ieee.org From owner-seamoby@diameter.org Fri Feb 9 08:25:53 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA15887 for ; Fri, 9 Feb 2001 08:25:52 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f19BNdg10859 for seamoby-list; Fri, 9 Feb 2001 03:23:39 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f19BNZo10854 for ; Fri, 9 Feb 2001 03:23:36 -0800 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 f19AW0C23431 for ; Fri, 9 Feb 2001 11:32:00 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Feb 09 11:32:00 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id <1CVZTA1V>; Fri, 9 Feb 2001 11:28:33 +0100 Message-ID: <034BEFD03799D411A59F00508BDF75465B69C8@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Michael Thomas'" Cc: seamoby@diameter.org Subject: RE: [seamoby] Single sentence problem statements Date: Fri, 9 Feb 2001 11:31:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-seamoby@diameter.org Precedence: bulk > > There is nothing we can do in IETF about L2 handover IMO. > > So we can't guarantee zero packet loss in the intra-access > > technology case. > > I don't think that the last sentence follows from the first. > Fast handoff seems pretty applicable to both intra and inter > access technology. It may just be redundant and possibly > less efficient than an intra-L2 solution. > => Sorry, I should have clarified this a bit more. The Fast Handoff mechanism we have today is designed to allow the MN to anticipate its movement by getting the information about its "new" subnet from the current AR. the underlying assuption here is that the MN is not simultaneously data-connected to both ARs. That is why I see it as beneficial for intr-access technology case. I believe MIPv6 can handle the inter-access case (where the MN has 2 interfaces and can receive data on both). So while the design is not restricting it to intra-access (and it shouldn't) I see the intra-access case as the main beneficiary. Hesham From owner-seamoby@diameter.org Fri Feb 9 13:00:29 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26701 for ; Fri, 9 Feb 2001 13:00:29 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f19G8kZ11597 for seamoby-list; Fri, 9 Feb 2001 08:08:46 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f19G8io11592 for ; Fri, 9 Feb 2001 08:08:44 -0800 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA00932 for ; Fri, 9 Feb 2001 07:17:15 -0800 (PST) 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 HAA24497 for ; Fri, 9 Feb 2001 07:17:15 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA03542 for ; Fri, 9 Feb 2001 07:17:13 -0800 (PST) Date: Fri, 9 Feb 2001 07:17:14 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: [seamoby] To the design teams... To: seamoby@cdma-2000.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk Just a reminder that you have exactly two weeks left before the I-D cutoff, which is 2/23 at 5PM EST. PatC From owner-seamoby@diameter.org Fri Feb 9 13:14:46 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27159 for ; Fri, 9 Feb 2001 13:14:46 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f19GEUP11643 for seamoby-list; Fri, 9 Feb 2001 08:14:30 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f19GESo11638 for ; Fri, 9 Feb 2001 08:14:28 -0800 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA05523 for ; Fri, 9 Feb 2001 07:22:59 -0800 (PST) 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 HAA25384 for ; Fri, 9 Feb 2001 07:22:59 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA03602 for ; Fri, 9 Feb 2001 07:22:58 -0800 (PST) Date: Fri, 9 Feb 2001 07:22:58 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: [seamoby] Minneapolis meeting To: seamoby@cdma-2000.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk The deadline for draft submission prior to the Minneapolis meeting is 23 February at 5pm EST. Please note, however, that the IETF does the bulk of its work via email discussions. Note, as well, that the meetings are not for technology presentations but rather for face time to resolve outstanding issues. What should be inferred from this is that the meeting deadlines should probably not be regarded as having some necessary relationship to progression of the deliverables. For those who have material that they feel needs attention in Minneapolis, it would be useful to get your drafts in early enough for us to be able to get a handle on what the outstanding issues are in advance of the meeting. The current agenda is: - Paging Design Team update - Micro-Mobility Design Team update - Context Transfer Design Team update (the above should include a short update, with a discussion on any unresolved issues) PatC From owner-seamoby@diameter.org Fri Feb 9 13:55:47 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28561 for ; Fri, 9 Feb 2001 13:55:46 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f19HJlg11825 for seamoby-list; Fri, 9 Feb 2001 09:19:47 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f19HJjo11820 for ; Fri, 9 Feb 2001 09:19:45 -0800 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA02110 for ; Fri, 9 Feb 2001 08:28:15 -0800 (PST) From: kempf@heliopolis.Eng.Sun.COM Received: from heliopolis.Eng.Sun.COM (heliopolis.Eng.Sun.COM [152.70.1.39]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA10716 for ; Fri, 9 Feb 2001 08:28:11 -0800 (PST) Received: from vayne (muc-isdn-9.Germany.Sun.COM [129.157.164.109]) by heliopolis.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id IAA14830 for ; Fri, 9 Feb 2001 08:28:08 -0800 (PST) Date: Fri, 9 Feb 2001 17:38:44 +0100 (MET) Reply-To: Subject: [seamoby] Paging Problem Statement To: seamoby@diameter.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk All, The IETF draft announcement has me listed as "author". In fact my role was editor (by default: nobody else volunteered when I asked). This is the role listed on the draft. I am open to ways of including full attribution of the design teams help. Can we make the author be "design team"? I would rather not have a list of 20 authors, however. jak From owner-seamoby@diameter.org Fri Feb 9 14:02:05 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28798 for ; Fri, 9 Feb 2001 14:02:02 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f19HP1l11844 for seamoby-list; Fri, 9 Feb 2001 09:25:01 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f19HOxo11839 for ; Fri, 9 Feb 2001 09:24:59 -0800 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 IAA14146; Fri, 9 Feb 2001 08:33:28 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAV21594; Fri, 9 Feb 2001 08:33:24 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA02458; Fri, 9 Feb 2001 08:33:24 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14980.7124.212776.357302@thomasm-u1.cisco.com> Date: Fri, 9 Feb 2001 08:33:24 -0800 (PST) To: Cc: seamoby@diameter.org Subject: [seamoby] Paging Problem Statement 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-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Does it actually matter? The problem statements aren't going to go informational are they? I expect that they'll eventually be transmogrified into requirements and/or frameworks informational RFC's, in which case it's probably more important to get a list of who's to blame :-) Mike kempf@heliopolis.Eng.Sun.COM writes: > All, > > The IETF draft announcement has me listed as "author". In fact my > role was editor (by default: nobody else volunteered when I asked). > This is the role listed on the draft. I am open to ways of including > full attribution of the design teams help. Can we make the > author be "design team"? I would rather not have a list of 20 > authors, however. > > jak > From owner-seamoby@diameter.org Fri Feb 9 14:32:09 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29665 for ; Fri, 9 Feb 2001 14:32:07 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f19HFQ011816 for seamoby-list; Fri, 9 Feb 2001 09:15:26 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f19HFKo11811 for ; Fri, 9 Feb 2001 09:15:24 -0800 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA29939 for ; Fri, 9 Feb 2001 08:23:52 -0800 (PST) From: kempf@heliopolis.Eng.Sun.COM Received: from heliopolis.Eng.Sun.COM (heliopolis.Eng.Sun.COM [152.70.1.39]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA10181 for ; Fri, 9 Feb 2001 08:23:52 -0800 (PST) Received: from vayne (muc-isdn-9.Germany.Sun.COM [129.157.164.109]) by heliopolis.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id IAA14768 for ; Fri, 9 Feb 2001 08:23:47 -0800 (PST) Date: Fri, 9 Feb 2001 17:34:23 +0100 (MET) Reply-To: Subject: [seamoby] Paging Problem Statement To: seamoby@diameter.org Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-LA_F2155733230R-1A-981736465=:411NCE.IlHAFeR" Sender: owner-seamoby@diameter.org Precedence: bulk ---LA_F2155733230R-1A-981736465=:411NCE.IlHAFeR Content-Type: TEXT/PLAIN; CHARSET=US-ASCII All, The draft editor has been slow to post this, so I thought I would include it. This is the problem statement that the paging design team came up with. There will probably be an updated draft with a few minor editorial changes next week, but I thought we could get discussion going now even though Pat can't officially make last call until it is posted. jak ---LA_F2155733230R-1A-981736465=:411NCE.IlHAFeR Content-Type: TEXT/plain; name="draft-ietf-seamoby-paging-problem-statement.txt"; charset=us-ascii Content-Description: default INTERNET DRAFT James Kempf, Editor Category: Informational Sun Microsystems Title: draft-ietf-seamoby-paging-problem-statement-00.txt Date: Feburary 2001 Paging Problem Statement Status of this Memo This document is a working group contribution for the Seamoby Working Group. Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Copyright (C) The Internet Society 2000. All Rights Reserved. Abstract The IESG has requested that the Seamoby Working Group develop a problem statement about the need for additional protocol work to support paging for seamless IP mobility. This draft describes paging, assesses the need for paging at L3, and presents a list of recommendations for Seamoby charter items regarding work on paging. 1.0 Introduction Many existing radio link protocols and mobile systems support James Kempf, Editor expires August 2001 [Page 1] INTERNET DRAFT Feburary 2001 location of and radio link establishment with mobile nodes that are not actively listening for delivery of IP packets. This functionality allows mobile nodes to reduce power consumption and decreases signalling load on the network for tracking mobiles that are not actively participating in IP packet generation or reception. When a mobile is in low power consumption mode, special steps need to be taken to locate the mobile. These steps differ depending on the radio link, but the generic name for this process is paging. In this document, after some initial definitions and material related to more clearly explaining what paging is, we assess the need for paging in existing IP mobility protocols (namely Mobile IP [1] [2]) and briefly discuss the potential need for paging in a future micromobility protocol. We then develop a list of work items for the Seamoby working group related to this need. 2.0 Definitions The following definitions are relevent with respect to clarifying the paging functionality: Dormant Mode - A state in which a mobile can not receive IP packets, but may still be able to receive L2 signalling related to tracking the mobile's location. A mobile may transition out of dormant mode due to a lower layer interface message (possibly triggered by receipt of an IP packet) or a timer expiration. A dormant terminal may signal to the network when it changes paging area, but may delay the signal until the next time it wakes up (if, for example, the mobile is using a time-slotted dormant mode algorithm). Note that a terminal which is continuously listening to L2 for receipt of L3 packets is not in dormant mode. Paging - As a consequence of a mobile-bound packet destined for a mobile currently in dormant mode, messaging by the L2 access point directed to locating the mobile and establishing a last hop connection. This messaging is in addition to simply delivering the packet to the mobile, i.e. last hop routing of packets is NOT considered to be paging. Paging Area - Collection of last hop routers and/or L2 access points that are searched to locate a dormant mode node. A paging area does not necessarily correspond to an IP subnet. 3.0 Discussion of Paging Dormant mode is advantageous to a mobile node for the following James Kempf, Editor expires August 2001 [Page 2] INTERNET DRAFT Feburary 2001 reasons: - Power savings. By reducing the amount of time the mobile is required to listen to L2, the drain on the mobile node's battery is reduced. - Reduced signalling for location tracking. By requiring the mobile to only signal when it crosses a paging area boundary rather than when it switches between L2 access points, the amount of signalling for tracking the mobile is reduced. Most existing radio L2 protocols provide support for dormant mode. Some such protocols also support paging, while others do not. The important distinction is whether the radio L2 protocol supports periodic signalling between the mobile and the network on a reduced basis, for example only when the mobile crosses a paging area boundary, for the purpose of giving the network a rough idea of the mobile's location. Some deployments of paging reduce signalling even further by using heuristics to determine where the mobile is located, in which case, no signalling is required while the mobile is in dormant mode. An incoming packet or, for voice-based systems, voice call is directed to the paging area where the mobile last reported. The network performs an L2 page by sending out a signal on a special radio channel that awakens the mobile. The signal may be repeated until the mobile answers or a timeout occurs. In the former case, the packet is delivered or the call connected, in the latter, the mobile is assumed to be unreachable. An L3 paging protocol is sensible only if L2 supports paging. In the absence of L2 paging, L3 paging achieves no reduction in power drain because the mobile is forced to monitor L2 for L3 paging messages. Having the mobile constantly listen to L2 for L3 packets is NOT considered to be adequate L2 support, because it does not achieve enough power savings to be meaningful. Some reduction in signalling load might be achieved, however, since the mobile would only need to update its location with the network when it moves from one paging area to another. 4.0 Is L3 Paging Necessary? In this section, we consider whether L3 paging support is necessary. As discussed above, L2 support for paging is assumed. There are two cases to consider: paging for networks consisting of a homogeneous radio L2 technology and networks in which handoffs are occuring between heterogeneous radio L2 technologies. We first consider the two cases given the existing IETF mobility protocol, namely Mobile IP. We also briefly consider the relationship between paging and a potential future micromobility protocol. James Kempf, Editor expires August 2001 [Page 3] INTERNET DRAFT Feburary 2001 4.1 Homogeneous Technology Networks Subnets constitute the unit of signalling for presence at L3. When a mobile node moves from one subnet to another, Mobile IP signalling is required to change the mobile's care-of address. This signalling establishes the mobile's presence in the new subnet. Paging areas constitute the unit of signalling for presence at L2. There are many ways to configure how paging areas are utilized to obtain a rough idea of where the mobile is. One way is to use regional registrations. When the mobile moves from one paging area to another, it signals the network indicating that it has arrived in the new paging area. This signalling establishes the mobile presence in the paging area. Alternate possibilities are for the network to page in the home area, then the area of last origination, then in the area of last power-on registration, etc. In this case, the network is not tracking the mobile, so the L2 paging system has only a very rough idea of where the mobile is located. The exact algorithm depends on how a particular operator configures their network, as well as the available support at L2. Given these two units of presence at L2 and L3, the most important point with regard to whether or not paging is needed in homogeneous networks is how subnets are mapped into paging areas. To determine whether additional L3 paging protocol work is required, we first need to determine whether we can support location of and link establishment with a mobile in dormant mode given some mapping between subnets and paging areas using Mobile IP. Standard Mobile IP requires the mobile node to actively listen for or solicit foreign agent or router advertisements and participate in registering, so it is of little use if the mobile is in dormant mode. However, network assisted handoff techniques used for fast handoff [3] [4] allow the network to track the mobile without requiring any signalling from the mobile. The L2 signalling that occurs when a dormant mobile crosses paging area boundaries (provided the operator has configured L2 regional registrations) can be used as the "L2 trigger" for network assisted handoff techniques to allow the network to track the mobile in dormant mode, with perhaps some enhancements to optimize the ability of the network to update the home agent and/or any hierarchical agents about the mobile's location. We need to examine paging area to subnet mappings in order to determine when we can utilize the L2 paging area update trigger to trigger network assisted handoff in dormant mode. In general, the mapping between paging areas and subnets can be arbitrary, but we consider here a smooth subset relationship, in which paging areas are subsets of subnets or vice versa. Network topologies in which one James Kempf, Editor expires August 2001 [Page 4] INTERNET DRAFT Feburary 2001 subnet is split between two or more paging areas are therefore eliminated. The restriction is arbitrary, but by starting here, we can discover whether additional work is needed. If it turns out that work is needed, then more complex topologies can be investigated in the course of actually doing the work. There are three cases: 1) The topological boundaries of the paging area and subnet are identical. 2) Multiple paging areas are part of the same subnet. 3) Multiple subnets are part of the same paging area. In the case where L2 paging areas map one to one onto IP subnets (and hence Mobile IPv4 Foreign Agents or IPv6 Access Routers), it is possible to use L2 paging together with Mobile IP network assisted handoff techniques for the network to track the mobile's location. Enhancements to network-assisted handoff techniques can allow the network to track the mobile as it moves from paging area (== subnet) to paging area. New Mobile IP signalling for the mobile node to inform the network when it is going into dormant mode could possibly optimize this. With network tracking, if a packet for the dormant mobile comes in, it is routed by the Regional Attendant, Regional Foreign Agent, Mobile Access Point, or Home Agent to the last hop Foreign Agent or Access Router at the mobile's last known position, where the L2 page is performed. Once the L2/L3 address mapping is known, the packet is delivered. The case where multiple L2 paging areas map to a single IP subnet is the same as above, with the exception that the last hop Mobile IPv4 Foreign Agent or IPv6 Access Router for the subnet performs paging in multiple paging areas to locate the mobile. In the case where a single L2 paging area maps onto multiple IP subnets, it is not possible to directly use enhanced network assisted handoff techniques between last hop Access Routers or Foreign Agents to track the mobile's location as it moves, because the mobile does not signal its location when it changes subnets. Within the set of subnets that span the paging area, the mobile's movement is invisible to the L2 paging system, so a packet delivered to the mobile's last known location may result in a page that is answered in a different subnet. In this case, some support is required at L3 for locating a dormant mode mobile that has moved into a different subnet. James Kempf, Editor expires August 2001 [Page 5] INTERNET DRAFT Feburary 2001 4.2 Heterogeneous Technology Networks In a network composed of links with multiple technologies, there may be commonalities in the corresponding L2 paging protocols that would allow a mapping to be established between the L2 protocols and an abstract L3 protocol. For example, assume we have a common paging area identifier defined at L3 that is mapped to each L2 paging protocol by the access points. An L3 paging message containing the identifier is sent to multiple access points, where the appropriate L2 paging message is sent based on the particular technology implemented by the access points. The results are then returned by the L2 paging responses, mapped back into L3 by the access points, and delivered back to the origin of the page. Note, however, that the same analysis as applied to homogeneous networks regarding the mapping between paging areas and subnets applies here as well. For example, if there is a one-to-one mapping between L2 paging areas and subnets, then there can be only a single technology per subnet, and movement across paging area boundries by a dual technology moble in dormant mode on both interfaces can be tracked through mobile IP network assisted handoff. Similarly, if more than one paging area exists per subnet, even if the areas are from multiple technologies, the Foreign Agent or Access Router can page in the multiple areas at L2 and a dual mode mobile can be tracked as it crosses paging area boundaries. But if multiple subnets are contained within a paging area or for more complex topologies, the lack of clear identification between subnet boundaries at L3 and paging area boundaries at L2 requires some means of locating the mobile at L3. An additional case to consider is when a subnet consists of multiple access tchnologies. A wireless access point usually provides L2 bridge behavior to the wired link with which it is connected. If two access point with incompatible technologies and non-overlapping cells are connected to the same subnet, a mobile node with interfaces to both technologies would need paging from both technologies. If reachability can be established simply by ARP or neighbor discovery, no L3 paging is needed. However, note that ARP or neighbor discovery requires that a functional L2 link be available to the mobile, since these techniques reach all the way to the mobile and assume a functional L2. If the mobile is currently in the sleep phase of a time-slotted dormant mode, it will fail to respond to these requests. In this case, some means of triggering an L2 page from L3 is necessary to find the mobile. 4.3 Paging and Micromobility If the Seamoby Working Group decides that an L3 micromobility James Kempf, Editor expires August 2001 [Page 6] INTERNET DRAFT Feburary 2001 protocol is necessary for intra-subnet mobility, then the above analysis is no longer complete. A micromobility protocol may require some type of paging support. The design team does not want to include any further discussion of paging and micromobility at this point, because it is not clear whether micromobility will be pursued by Seamoby and hence such discussion would be premature. 5.0 What Exactly is the Problem? While the above analysis has identified situations in which location of a mobile in dormant mode may require some action at L3, it is important not to misinterpret this finding as an endorsement for a complex L3 paging algorithm. The problem to be solved is the location of the mobile because it has moved while in dormant mode. L3 paging is just one solution to the problem, there are alternatives. For example, paging involves action by the network at the time a packet or, in voice systems, the call comes in. An alternative solution would be for the network to distribute information about a dormant mode mobile when it goes dormant. In the case of multiple subnets per paging area, the Foreign Agent or Access Router in the subnet where the mobile goes dormant could distribute the mobile's L2 address and IP address, and the last known Foreign Agent or Access Router address to other Foreign Agents or Access Routers in the paging area. When a packet comes in, the subnet where the mobile was last registered does the page, but the mobile answers in a different subnet. The Foreign Agent or Access Router has the IP address, contacts the previous Foreign Agent or Access Router, and negotiates a handoff and assignment of an new CoA for the mobile. This solution leverages off of the existing Mobile IP infrastructure considerably more than would a paging algorithm designed to be orthogonal to Mobile IP. If further study determines that, in fact, an L3 paging algorithm is the right solution to the problem, then the algorithm for doing L3 paging cannot involve any sort of L3 signalling to the mobile, because the mobile is, by definition, probably not listening to L2 for L3 traffic. It may be listening periodically, if the L2 dormant mode technology involves time slotting, but most of the time it will not be. So an L3 page could only extend as far as the L2 access points, at which point it would have to be translated into L2 paging. As a consequence, L2 technologies that do not support paging would still derive no benefit from the L3 paging algorithm. 6.0 Recommendations The design group recommends the following charter items for Seamboy: James Kempf, Editor expires August 2001 [Page 7] INTERNET DRAFT Feburary 2001 1) Since the design group has identified at least one network deployment scenerio where existing Mobile IP technology cannot find a mobile in dormant mode, protocol work is necessary to define a way for the network to find a mobile that is currently in dormant mode. 2) The work defined above should be pursued in a way that is maximally consistent with Mobile IP and other existing IETF protocols. In particular, it is expected, based on the analysis undertaken by the design team, that network assisted handoff can be heavily leveraged in any new protocol work. 3) If it is determined that extensions to existing protocols are completely inadequate to solve location of a dormant mode mobile, or if the Seamoby working group decides to pursue a micromobility protocol that requires paging, the Seamoby group should undertake the design of a new paging protocol. 4) There is some evidence that cellular operators' deployments of paging are highly variable, and may, in fact, be suboptimal in many cases with respect to supporting IP. The Seamoby working group should write a BCP which explains how to perform IP subnet to paging area mapping and which techniques to use when, so network designers in wireless networks have a guide when they are setting up their networks. 7.0 References [1] C. Perkins, editor. "IP Mobility Support", RFC 2002, October, 1966. [2] Johnson, D., and C. Perkins, "Mobility Support in IPv6", draft- ietf-mobileip-ipv6-13.txt, a work in progress. [3] Calhoun, P., et. al., "Foreign Agent Assisted Hand-off", draft- calhoun-mobileip-proactive-fa-03.txt, a work in progress. [4] Perkins, C., Editor, "Fast Handovers for Mobile IPv6", draft- perkins-mobileip-handover-00.txt, a work in progress. 8.0 Editor's Address Questions about this memo can be directed to: James Kempf James Kempf, Editor expires August 2001 [Page 8] INTERNET DRAFT Feburary 2001 Sun Labs California Sun Microsystems, Inc. 901 San Antonio Rd., UMPK15-214 Palo Alto, CA, 94303 USA Phone: +1 650 786 5890 Fax: +1 650 786 6445 E-Mail: james.kempf@sun.com 9.0 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this docu- ment itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Inter- net organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permis- sions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WAR- RANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." James Kempf, Editor expires August 2001 [Page 9] ---LA_F2155733230R-1A-981736465=:411NCE.IlHAFeR-- From owner-seamoby@diameter.org Fri Feb 9 15:15:00 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00739 for ; Fri, 9 Feb 2001 15:14:59 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f19HDOT11806 for seamoby-list; Fri, 9 Feb 2001 09:13:24 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f19HDMo11801 for ; Fri, 9 Feb 2001 09:13:23 -0800 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA29040 for ; Fri, 9 Feb 2001 08:21:54 -0800 (PST) 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 IAA03134 for ; Fri, 9 Feb 2001 08:21:54 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id IAA04106 for ; Fri, 9 Feb 2001 08:21:52 -0800 (PST) Date: Fri, 9 Feb 2001 08:21:52 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: [seamoby] WG Last Call: I-D ACTION:draft-seamoby-paging-problem-statement-00.txt (Fwd) To: seamoby@cdma-2000.org In-Reply-To: "Your message with ID" <200102091225.HAA14050@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk This is the 2 week last call for the paging problem draft, which is the output of the paging design team. If no comments are received by 2/23, the I-D will be sent to the IESG. Thanks, PatC >----------------Begin Forwarded Message----------------< Date: Fri, 09 Feb 2001 07:25:21 -0500 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-seamoby-paging-problem-statement-00.txt To: IETF-Announce@, @ A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Paging Problem Statement Author(s) : J. Kempf Filename : draft-seamoby-paging-problem-statement-00.txt Pages : 9 Date : 08-Feb-01 The IESG has requested that the Seamoby Working Group develop a problem statement about the need for additional protocol work to support paging for seamless IP mobility. This draft describes paging, assesses the need for paging at L3, and presents a list of recommendations for Seamoby charter items regarding work on paging. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-seamoby-paging-problem-statement-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-seamoby-paging-problem-statement-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-seamoby-paging-problem-statement-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. >----------------End Forwarded Message----------------< From owner-seamoby@diameter.org Fri Feb 9 18:22:05 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04476 for ; Fri, 9 Feb 2001 18:22:05 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f19LAZb12270 for seamoby-list; Fri, 9 Feb 2001 13:10:35 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from NEPTUNE.zucotto.com ([216.95.209.154]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f19LAXo12265 for ; Fri, 9 Feb 2001 13:10:33 -0800 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21) id ; Fri, 9 Feb 2001 15:19:04 -0500 Message-ID: From: Kulwinder Atwal To: "'Michael Thomas'" , kempf@heliopolis.Eng.Sun.COM Cc: seamoby@diameter.org Subject: RE: [seamoby] Paging Problem Statement Date: Fri, 9 Feb 2001 15:19:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk I have noticed that Charlie Perkins IP Mobility Support draft RFC:2002 where he talks about mobile routers has him listed as the Editor and no other credits. -kulwinder. > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Friday, February 09, 2001 11:33 AM > To: kempf@heliopolis.Eng.Sun.COM > Cc: seamoby@diameter.org > Subject: [seamoby] Paging Problem Statement > > > > Does it actually matter? The problem statements > aren't going to go informational are they? I > expect that they'll eventually be transmogrified > into requirements and/or frameworks informational > RFC's, in which case it's probably more important > to get a list of who's to blame :-) > > Mike > > kempf@heliopolis.Eng.Sun.COM writes: > > All, > > > > The IETF draft announcement has me listed as "author". In fact my > > role was editor (by default: nobody else volunteered when I asked). > > This is the role listed on the draft. I am open to ways of > including > > full attribution of the design teams help. Can we make the > > author be "design team"? I would rather not have a list of 20 > > authors, however. > > > > jak > > > From owner-seamoby@diameter.org Fri Feb 9 18:38:46 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04624 for ; Fri, 9 Feb 2001 18:38:45 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f19Lfw812323 for seamoby-list; Fri, 9 Feb 2001 13:41:58 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f19Lfso12318 for ; Fri, 9 Feb 2001 13:41:55 -0800 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 f19KoQC04795 for ; Fri, 9 Feb 2001 21:50:26 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Feb 09 21:50:26 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id <1CVZTVTC>; Fri, 9 Feb 2001 21:46:59 +0100 Message-ID: <034BEFD03799D411A59F00508BDF75465B69D8@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: seamoby@cdma-2000.org Subject: RE: [seamoby] WG Last Call: I-D ACTION:draft-seamoby-paging-probl em-statement-00.txt (Fwd) Date: Fri, 9 Feb 2001 21:50:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-seamoby@diameter.org Precedence: bulk Hello, I have some initial comments on the draft and will follow that later with some more detailed ones. So here they are: General comment: The assumption that L3 packets can only be sent on certain channels is not correct. The whole draft seems to be based on that assumption. I disagree with that unless one of the team members can explain it better to me. I'm sure this would have been discussed in detail. "Dormant Mode - A state in which a mobile can not receive IP packets, but may still be able to receive L2 signalling related to tracking the mobile's location. A mobile may transition out of dormant mode due to a lower layer interface message (possibly triggered by receipt of an IP packet) or a timer expiration. A dormant terminal may signal to the network when it changes paging area, but may delay the signal until the next time it wakes up (if, for example, the mobile is using a time-slotted dormant mode algorithm). Note that a terminal which is continuously listening to L2 for receipt of L3 packets is not in dormant mode. " => This definition of dormant mode is not correct. A dormant mobile is a mobile that can only receive information on certain channels and not others. This has absolutely nothing to do with the nature of this information or which layer it is adressing (L2 or L3). For example in the cellular networks I'm half familiar with, a dormant mobile can receive/send signalling messages on common channels. A dormant mobile is a mobile that does not have a traffic channel setup. Therfore saying that it can not receive L3 packets is not true. Maybe in today's cellular networks the system designers chose to send L3 signalling on traffic channels. But of course that should NOT imply that this is the definition of dormancy. After all there is no L3 paging in today's cellular networks. In chapter 3: "An L3 paging protocol is sensible only if L2 supports paging. In the absence of L2 paging, L3 paging achieves no reduction in power drain because the mobile is forced to monitor L2 for L3 paging messages." => I dont see how this can be right ? This is a statement that simply removes the need of L3 paging altogether. If you need L2 paging then what's L3 paging needed for ?? "Having the mobile constantly listen to L2 for L3 packets is NOT considered to be adequate L2 support, because it does not achieve enough power savings to be meaningful. " => The mobile has to listen to L2 all the time. Again there is an underlying assumption here that L3 packets are only sent on certain bearers. That's a bad assuption IMO. If someone disagrees with that then please explain why this is the case. I don't think that sending L3 packets on other channels breaks any laws of physics. Or maybe I missed something ? The references to both V4 and V6 drafts are incorrect. There is a new V6 draft that is completely different and is now the WG draft in the MIP WG. We've been discussing it for a while now on this list so please refer to it. Also there is a new V4 draft that will also be the WG draft. I guess I shouldn't need to remind the editor ;) Regards, Hesham From owner-seamoby@diameter.org Fri Feb 9 21:05:56 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA06183 for ; Fri, 9 Feb 2001 21:05:55 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f1A0sfO12677 for seamoby-list; Fri, 9 Feb 2001 16:54:41 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from NEPTUNE.zucotto.com ([216.95.209.154]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f1A0s1o12672 for ; Fri, 9 Feb 2001 16:54:02 -0800 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21) id ; Fri, 9 Feb 2001 19:02:32 -0500 Message-ID: From: Kulwinder Atwal To: "'zeroconf@merit.edu'" , seamoby@cdma-2000.org, MOBILE-IP@STANDARDS.NORTELNETWORKS.COM, "'srvloc@srvloc.org'" , "'aaa-wg@merit.edu'" , "'manet@itd.nrl.navy.mil'" , "'ipsec@lists.tislabs.com'" , "'ipsec-policy@vpnc.org'" , "'ietf-ipsra@vpnc.org'" , "'ietf-sacred@imc.org'" , "'enum@ietf.org'" , "'sigtran@standards.nortelnetworks.com'" , "'ietf@ietf.org'" , "'IETF-Announce@ietf.org'" , "'BLUETOOTH-BOF@mailbag.cps.intel.com'" Cc: "'Thomas Narten'" , Akers Ron-WRA001 Subject: [seamoby] BOF: IP over Bluetooth for 50th Meeting of IETF. Date: Fri, 9 Feb 2001 19:02:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Myself and Ron Akers have requested an IP over Bluetooth BOF for the 50th Meeting of the IETF in Minneapolis. The BOF will discuss the creation of a IETF Working Group to investigate the most open and efficient way to place IP over the Bluetooth Host Controller. Current work in this area within the Bluetooth SIG concentrates on defining IP over a set of other lower-layer stacks. Currently there are two options defined by the Bluetoth SIG: Option 1: IP/PPP/RFCOM/L2CAP/Host Controller Option 2: IP/PAN Profile/L2CAP/Host Controller (where the PAN Profile is a Bluetooth SIG work in progress) We are proposing that the IETF form a WG to define a more efficient way of running IP over Bluetooth. In particular, IP would run over an IETF protocol over the Host Controller without L2CAP. This option may be adopted by the Bluetooth SIG at a later date as a Profile. Since all Bluetooth SIG Profiles are optional, a customer may choose any combination of Profiles in a final product. Further, since Bluetooth Working Groups have it in their mandate to adopt protocols from other standards making bodies such as the IETF, there exists a clear path for IETF work to be adopted by the Bluetooth SIG. Whereas the last BOF was informational only and organized by the Bluetooth SIG itself, the objective of this BOF will be to foster innovation, and speed progress by placing IP related protocol development wihin the IETF and Bluetooth-specific protocol development within the Bluetooth SIG, by developing an IP over Bluetooth IETF Working Group. This effort will define its own way of running IP over Bluetooth, by carefully selecting a set of Bluetooth protocols (freely available from published specifications at http://www.bluetooth.com/developer/specification/specification.asp) on which to build IP. Please join myself, Kulwinder Atwal, and Ron Akers on the pre-BOF mailing list: This site runs version 2.0.1 of the "Mailman" list manager. The following describes commands you can send to get information about, and control your subscription to the lists at this site. Note that much of the following can also be accomplished via the World Wide Web, at: http://internet.motlabs.com/mailman/listinfo/bluetooth In particular, you can use the Web site to have your password sent to your delivery address. Email commands can be in the subject line or in the body of the message. The commands should be set to the following address: About the descriptions - words in "<>"s signify REQUIRED items and words in "[]" denote OPTIONAL items. Do not include the "<>"s or "[]"s when you use the commands. The following commands are valid: subscribe [password] [digest-option] [address=
] Subscribe to the mailing list. Your password must be given to unsubscribe or change your options. When you subscribe to the list, you'll be reminded of your password periodically. 'digest-option' may be either: 'nodigest' or 'digest' (no quotes!) If you wish to subscribe an address other than the address you send this request from, you may specify "address=" (no brackets around the email address, no quotes!) unsubscribe [address] Unsubscribe from the mailing list. Your password must match the one you gave when you subscribed. If you are trying to unsubscribe from a different address than the one you subscribed from, you may specify it in the 'address' field. who See everyone who is on this mailing list. info View the introductory information for this list. lists See what mailing lists are run by this Mailman server. help This message. set