From owner-seamoby@diameter.org Tue May 1 08:05:20 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 IAA23997 for ; Tue, 1 May 2001 08:05:18 -0400 (EDT) Received: (qmail 16310 invoked by alias); 1 May 2001 11:35:12 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 16304 invoked by uid 200); 1 May 2001 11:35:11 -0000 Received: (qmail 16299 invoked from network); 1 May 2001 11:35:09 -0000 Received: from c007-h008.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.214) by c900656-a.plstn1.sfba.home.com with SMTP; 1 May 2001 11:35:09 -0000 Received: (cpmta 17064 invoked from network); 1 May 2001 04:45:08 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.214) with SMTP; 1 May 2001 04:45:08 -0700 X-Sent: 1 May 2001 11:45:08 GMT Message-ID: <000b01c0d233$028c7b60$6401a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Phil Roberts" , References: Subject: Re: [seamoby] Comments on IRTF mm problem statement Date: Tue, 1 May 2001 06:36:43 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk Phil R. You have listed many references at the end of the draft, yet we interpret those references in completely different ways. I look forward to some of the authors of those drafts to chime in. You seem to reduce the world to router failures. That is not what micromobility is about. That may be one aspect but that is NOT the main gist. Thanks, Phil ----- Original Message ----- From: "Phil Roberts" To: "'Phil Neumiller'" ; Sent: Monday, April 30, 2001 4:23 PM Subject: RE: [seamoby] Comments on IRTF mm problem statement > > > Hi Phil R, > > Hi, > > I haven't answered each point by point, but I hope what I've said covers > most of the questions you included. > > > >There are a couple of seemingly unrelated problems that > > > have lead investigators to converge on the desirability of new > > >routing protocols to implement host routes within a constrained area. > > > > The wording of the above sentence could be confusing for MIP/SeaMoby > > "outsiders". I suggest SOMETHINK LIKE : > > > > ...routing protocols that allow for a mobile host to > > implement a limited > > host routing table to other mobile hosts in the same > > constrained routing > > area. > > But I don't think this is what we're interested in. The work certainly > applies to completely fixed networks (for network recovery of failed routers > and links) and the problem of scaling is in the routers. > > > >The problem is to investigate the limits and issues with using (a) > > >new protocol(s) to implement host routes to facilitate better mobile > > >hosts and network recovery in the presence of failed links or > > >routers. > > > > To be fair, you MUST add that there are perceived deficiencies > > in using MIP all the time. These must be quantified and qualified > > by the IRTF. Specifically, how fast is a fast handoff, and WHEN > > IS USING HOST ROUTES EVEN DESIRABLE? > > I'm not opposed to putting in something about the limitations of MIP, but > I'm not sure measuring MIP performance is what we want the IRTF to do. > Seems like one could get some MIP implementors to measure its performance. > What do others think? > > > > > >The document is a brief statement of the problem to be > > >investigated with lots of references to other work that has been done > > >already by many others in the area. > > > > I would reword "with lots of references .. " with "and the references > > to lots of prior work in this area have been included in this draft." > > Good. > > > > > > Many investigators in this area have converged on > > > solutions that propose the use of host routing to support mobility > > > within a limited domain, effectively exposing the mobility of end > > > systems to the routing protocols. > > > > Yes, an MANET has been working on this for years. I don't think > > that's what we want to say here Phil. What we need to do is talk > > about is localized host routing and WHAT it means to be local, > > i.e. how many hops, what kind of hops, how is MIP involved and > > how does it inter-work. > > OK. Doesn't the following take what you're concerned about into account? > "Specifically how many nodes could be supported across what kind of network > breadth and depth at what cost of complexity in the routers around the edge > of such a network?" > > I hadn't perceived that what we wanted the IRTF to do was come up with an > interworking strategy between MIP and some to-be-defined protocol. Again, > other feedback? > > > If fast recovery is important, MANET has the fastest non-looping and > > looping (Distance vector and link state routing) algorithms > > and protocols > > around. Fast recovery of what Phil? The link? The MN to AR path? > > The MN to MN path that bypasses MIP??? > > What *I* have in mind is a completely fixed network with router and link > failures where losing the traffic for many seconds results in a much longer > service disruption. I'm not sure these specifics need to be specified in > the problem statement, but am open to suggestions from others. One of the > references describes this. > > > > A). "due mobility" -> "due to mobility" > Got it. > > > A). Why OSPF? > > B). Why not BGP? > It's a particular problem of link or router failure in a local fixed domain. > Hence OSPF. I guess I'm not willing to ask about scaling host routes across > domains where BGP operates just yet. > > > > C). The primary issue needed is to expose the limitations of MIP and > > harden what we know about MIP quantitatively so ANY holes can > > be filled with local mobility management protocols. I can > > not emphasize > > this enough. THIS IS THE primary REASON. The secondary REASON > > is to investigate if host routes deployed in a limited scoped > > way (where the > > limitations are set by what MIP can't do) is reasonable. > > Also, carefull > > analysis of where the MANET boundary is also required. > > I guess our perceptions of what the ADs requested are reversed. Perhaps we > can get some clarification. > > Phil > > > > > > > Thanks, > > > > Phil Neumiller > > > > > From owner-seamoby@diameter.org Tue May 1 09:27: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 JAA26289 for ; Tue, 1 May 2001 09:27:48 -0400 (EDT) Received: (qmail 17749 invoked by alias); 1 May 2001 13:15:41 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 17743 invoked by uid 200); 1 May 2001 13:15:41 -0000 Received: (qmail 17738 invoked from network); 1 May 2001 13:15:39 -0000 Received: from unknown (HELO megisto-sql1.megisto.com) (63.113.114.132) by c900656-a.plstn1.sfba.home.com with SMTP; 1 May 2001 13:15:39 -0000 Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Tue, 1 May 2001 09:19:00 -0400 Message-ID: From: Phil Roberts To: "'Phil Neumiller'" , Phil Roberts , seamoby@cdma-2000.org Subject: RE: [seamoby] Comments on IRTF mm problem statement Date: Tue, 1 May 2001 09:19:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk > -----Original Message----- > From: Phil Neumiller [mailto:neumiller@telocity.com] > Sent: Tuesday, May 01, 2001 7:37 AM > To: Phil Roberts; seamoby@cdma-2000.org > Subject: Re: [seamoby] Comments on IRTF mm problem statement > > > Phil R. > > You have listed many references at the end of the draft, yet > we interpret > those references in completely different ways. I look > forward to some of > the authors of those drafts to chime in. Well, a few of them already reviewed this. But yes, more comment would be welcome. > > You seem to reduce the world to router failures. Hardly. > That is not > what micromobility > is about. That may be one aspect but that is NOT the main gist. > > Thanks, > > Phil > ----- Original Message ----- > From: "Phil Roberts" > To: "'Phil Neumiller'" ; > > Sent: Monday, April 30, 2001 4:23 PM > Subject: RE: [seamoby] Comments on IRTF mm problem statement > > > > > > > Hi Phil R, > > > > Hi, > > > > I haven't answered each point by point, but I hope what > I've said covers > > most of the questions you included. > > > > > >There are a couple of seemingly unrelated problems that > > > > have lead investigators to converge on the desirability of new > > > >routing protocols to implement host routes within a > constrained area. > > > > > > The wording of the above sentence could be confusing for > MIP/SeaMoby > > > "outsiders". I suggest SOMETHINK LIKE : > > > > > > ...routing protocols that allow for a mobile host to > > > implement a limited > > > host routing table to other mobile hosts in the same > > > constrained routing > > > area. > > > > But I don't think this is what we're interested in. The > work certainly > > applies to completely fixed networks (for network recovery > of failed routers > > and links) and the problem of scaling is in the routers. > > > > > >The problem is to investigate the limits and issues with > using (a) > > > >new protocol(s) to implement host routes to facilitate > better mobile > > > >hosts and network recovery in the presence of failed links or > > > >routers. > > > > > > To be fair, you MUST add that there are perceived deficiencies > > > in using MIP all the time. These must be quantified and qualified > > > by the IRTF. Specifically, how fast is a fast handoff, and WHEN > > > IS USING HOST ROUTES EVEN DESIRABLE? > > > > I'm not opposed to putting in something about the > limitations of MIP, but > > I'm not sure measuring MIP performance is what we want the > IRTF to do. > > Seems like one could get some MIP implementors to measure > its performance. > > What do others think? > > > > > > > > >The document is a brief statement of the problem to be > > > >investigated with lots of references to other work that > has been done > > > >already by many others in the area. > > > > > > I would reword "with lots of references .. " with "and > the references > > > to lots of prior work in this area have been included in > this draft." > > > > Good. > > > > > > > > > Many investigators in this area have converged on > > > > solutions that propose the use of host routing to > support mobility > > > > within a limited domain, effectively exposing the > mobility of end > > > > systems to the routing protocols. > > > > > > Yes, an MANET has been working on this for years. I don't think > > > that's what we want to say here Phil. What we need to do is talk > > > about is localized host routing and WHAT it means to be local, > > > i.e. how many hops, what kind of hops, how is MIP involved and > > > how does it inter-work. > > > > OK. Doesn't the following take what you're concerned about > into account? > > "Specifically how many nodes could be supported across what > kind of network > > breadth and depth at what cost of complexity in the routers > around the edge > > of such a network?" > > > > I hadn't perceived that what we wanted the IRTF to do was > come up with an > > interworking strategy between MIP and some to-be-defined > protocol. Again, > > other feedback? > > > > > If fast recovery is important, MANET has the fastest > non-looping and > > > looping (Distance vector and link state routing) algorithms > > > and protocols > > > around. Fast recovery of what Phil? The link? The MN > to AR path? > > > The MN to MN path that bypasses MIP??? > > > > What *I* have in mind is a completely fixed network with > router and link > > failures where losing the traffic for many seconds results > in a much longer > > service disruption. I'm not sure these specifics need to > be specified in > > the problem statement, but am open to suggestions from > others. One of the > > references describes this. > > > > > > > A). "due mobility" -> "due to mobility" > > Got it. > > > > > A). Why OSPF? > > > B). Why not BGP? > > It's a particular problem of link or router failure in a > local fixed domain. > > Hence OSPF. I guess I'm not willing to ask about scaling > host routes across > > domains where BGP operates just yet. > > > > > > > C). The primary issue needed is to expose the limitations > of MIP and > > > harden what we know about MIP quantitatively so ANY holes can > > > be filled with local mobility management protocols. I can > > > not emphasize > > > this enough. THIS IS THE primary REASON. The secondary REASON > > > is to investigate if host routes deployed in a limited scoped > > > way (where the > > > limitations are set by what MIP can't do) is reasonable. > > > Also, carefull > > > analysis of where the MANET boundary is also required. > > > > I guess our perceptions of what the ADs requested are > reversed. Perhaps we > > can get some clarification. > > > > Phil > > > > > > > > > > > Thanks, > > > > > > Phil Neumiller > > > > > > > > > > From owner-seamoby@diameter.org Tue May 1 09:30: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 JAA26387 for ; Tue, 1 May 2001 09:30:56 -0400 (EDT) Received: (qmail 18010 invoked by alias); 1 May 2001 13:17:43 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 18004 invoked by uid 200); 1 May 2001 13:17:43 -0000 Received: (qmail 17995 invoked from network); 1 May 2001 13:17:41 -0000 Received: from c007-h013.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.220) by c900656-a.plstn1.sfba.home.com with SMTP; 1 May 2001 13:17:41 -0000 Received: (cpmta 3161 invoked from network); 1 May 2001 06:27:42 -0700 Received: from unknown (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.220) with SMTP; 1 May 2001 06:27:42 -0700 X-Sent: 1 May 2001 13:27:42 GMT Message-ID: <009101c0d241$3964fa00$6401a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Phil Roberts" , References: Subject: Re: [seamoby] Comments on IRTF mm problem statement Date: Tue, 1 May 2001 08:18:27 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk > > > > You seem to reduce the world to router failures. > Hardly. That is the only motivation that calls for a need of micromobility in this draft isn't it? What other problem is solved besides this as described in the draft? -pdn From owner-seamoby@diameter.org Tue May 1 09:33: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 JAA26451 for ; Tue, 1 May 2001 09:33:22 -0400 (EDT) Received: (qmail 18145 invoked by alias); 1 May 2001 13:18:50 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 18139 invoked by uid 200); 1 May 2001 13:18:49 -0000 Received: (qmail 18132 invoked from network); 1 May 2001 13:18:48 -0000 Received: from unknown (HELO megisto-sql1.megisto.com) (63.113.114.132) by c900656-a.plstn1.sfba.home.com with SMTP; 1 May 2001 13:18:48 -0000 Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Tue, 1 May 2001 09:22:12 -0400 Message-ID: From: Phil Roberts To: "'Michael Thomas'" Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] Comments on IRTF mm problem statement Date: Tue, 1 May 2001 09:22:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Agreed. Sounds definitely worth including. Care to suggest some wording changes? > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Monday, April 30, 2001 7:14 PM > To: Phil Roberts > Cc: 'Michael Thomas'; 'Phil Neumiller'; seamoby@cdma-2000.org > Subject: RE: [seamoby] Comments on IRTF mm problem statement > > > Phil Roberts writes: > > > > Hi Mike, > > > > Perhaps, but I thought investigation using host routes and > routing protocols > > to support those was the point of this exercise? What > would you suggest as > > an alternative? Do you just want to make sure mobile > subnets are evaluated? > > Yes; "host routes" are just a degenerate form > of a subnet prefix, after all. IMO, the point > of the protocol is to allow subnets to move > around within a contained area (ie, still leads > to globally aggregated prefixes), that makes > them look for all intents and purposes as > stationary hosts (except in routers of the > contained area). Though host routes for mobile > nodes are likely to be the most common, I think > it would be a mistake to not consider any old > prefix up front so that we can address any > hidden problems with the protocol (if any). > > Mike > From owner-seamoby@diameter.org Tue May 1 10:43: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 KAA29108 for ; Tue, 1 May 2001 10:43:06 -0400 (EDT) Received: (qmail 20139 invoked by alias); 1 May 2001 14:30:23 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 20133 invoked by uid 200); 1 May 2001 14:30:23 -0000 Received: (qmail 20128 invoked from network); 1 May 2001 14:30:21 -0000 Received: from unknown (HELO zrc2s03g.us.nortel.com) (47.103.122.66) by c900656-a.plstn1.sfba.home.com with SMTP; 1 May 2001 14:30:21 -0000 Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id JAA20033 for ; Tue, 1 May 2001 09:40:20 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Tue, 1 May 2001 09:34:00 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 May 2001 09:39:23 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E43020D5DB0@crchy271.us.nortel.com> From: "Glenn Morrow" To: Phil Roberts Cc: "'seamoby@diameter.org'" Subject: RE: [seamoby] IRTF mm problem statement Date: Tue, 1 May 2001 09:39:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D24C.82E495E0" 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_01C0D24C.82E495E0 Content-Type: text/plain; charset="iso-8859-1" Phil, I'm sorry about not getting comments to you sooner. One point I believe people have misunderstood about using the other routing protocols such as OSPF and BGP is as follows: I do not believe that people ever conceived that these protocols should be used to distribute per-node routes. I do believe that some WG either in the IRTF or IETF should explore how these protocols can be used to set up and identify heirarchical adjancencies from a geographical point of view. I.e. set up the fact that this subnet is next to another subnet even though they are not in the same aggregate or administrative domain. I do agree that the stimulus for the installation and maintenance of the per-host routes within a local context MUST come from an MM protocol and it should be fast. These existing routing protocols should be enhanced to allow tiers of routers to identify the capabilities and route relationships of hierarchy, adjacency to add a new dimension "mobile routing distance" to the routers' routing/policy tables. This new information could be utilized by MM protocol daemons to do their fast thing. I also believe that this information, in conjunction with per-host routes distributed via the MM protocol to the piers of a specific tier of aggregation, would also get rid of the single point of failure problem associated with explicit anchoring. If the routers know the piers of the tier and the geographical adjacency vectors, then the MM protocol knows where to get directed to install the redundant - yet finite and scalable - per node routes - no single point of failure. I believe OSPF and BGP would be fine candidates for this type of optional routing extension. This particular signaling doesn't need to be fast. The MM signaling does, though. I agree with that. This would be extra work but you may wish to explore this concept as well. I don't think anyone ever wanted to use these protocols for per-node routes and turn them into MANET; however, by adding the vectors for these new mobile dimensions to these existing routing protocols, it would certainly facilitate and enhance an MM solution. You can also utilize the installed base of solutions to handle any intra/inter-system security and routing policy. It is a win- win situation. I do believe there is a market for an IP-based inter-system fast micromobility. Re-use of the existing protocols where you can will help in deployment and acceptance IMHO. Thanks, Glenn -----Original Message----- From: Phil Roberts [mailto:PRoberts@MEGISTO.com] Sent: Monday, April 30, 2001 1:56 PM To: 'seamoby@diameter.org' Subject: [seamoby] IRTF mm problem statement Hi folks, a draft of an IRTF problem statement for host routing is now available at: http://www.diameter.org/draft-proberts-hostrouting-problem-00.txt. I'd like to run it by the working group before submitting it as an I-D. All comments and suggestions are welcome. It would probably help if it had a set of proposed deliverables. Phil ------_=_NextPart_001_01C0D24C.82E495E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [seamoby] IRTF mm problem statement

Phil,

I'm sorry about not getting comments to you sooner. = One point I believe people have misunderstood about using the other = routing protocols such as OSPF and BGP is as follows:

I do not believe that people ever conceived that = these protocols should be used to distribute per-node routes. I do = believe that some WG either in the IRTF or IETF should explore how = these protocols can be used to set up and identify heirarchical = adjancencies from a geographical point of view. I.e. set up the fact = that this subnet is next to another subnet even though they are not in = the same aggregate or administrative domain.

I do agree that the stimulus for the installation and = maintenance of the per-host routes within a local context MUST come = from an MM protocol and it should be fast.

These existing routing protocols should be enhanced = to allow tiers of routers to identify the capabilities and route = relationships of hierarchy, adjacency to add a new dimension =

"mobile routing distance" to the routers' = routing/policy tables.

This new information could be utilized by MM protocol = daemons to do their fast thing. I also believe that this information, = in conjunction with per-host routes distributed via the MM protocol to = the  piers of a specific tier of aggregation, would also get rid = of the single point of failure problem associated with explicit = anchoring.

If the routers know the piers of the tier and the = geographical adjacency vectors, then the MM protocol knows where to get = directed to install the redundant - yet finite and scalable - per node = routes - no single point of failure.

I believe OSPF and BGP would be fine candidates for = this type of optional routing extension. This particular signaling = doesn't need to be fast. The MM signaling does, though. I agree with = that.

This would be extra work but you may wish to explore = this concept as well. I don't think anyone ever wanted to use these = protocols for per-node routes and turn them into MANET; however, by = adding the vectors for these new mobile dimensions to these existing = routing protocols, it would certainly facilitate and enhance an MM = solution. You can also utilize the installed base of solutions to = handle any intra/inter-system security and routing policy. It is a win- = win situation.

I do believe there is a market for an IP-based = inter-system fast micromobility. Re-use of the existing protocols where = you can will help in deployment and acceptance IMHO.

Thanks,

Glenn

-----Original Message-----
From: Phil Roberts [mailto:PRoberts@MEGISTO.com]
Sent: Monday, April 30, 2001 1:56 PM
To: 'seamoby@diameter.org'
Subject: [seamoby] IRTF mm problem statement



Hi folks,

   a draft of an IRTF problem statement for = host routing is now available
at:
http://www.diameter.org/draft-proberts-hostrouting-pro= blem-00.txt.  I'd like
to run it by the working group before submitting it = as an I-D.  All comments
and suggestions are welcome.  It would probably = help if it had a set of
proposed deliverables.

Phil

------_=_NextPart_001_01C0D24C.82E495E0-- From owner-seamoby@diameter.org Tue May 1 10:48: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 KAA29373 for ; Tue, 1 May 2001 10:48:43 -0400 (EDT) Received: (qmail 20631 invoked by alias); 1 May 2001 14:36:50 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 20625 invoked by uid 200); 1 May 2001 14:36:49 -0000 Received: (qmail 20612 invoked by uid 500); 1 May 2001 14:36:48 -0000 Date: Tue, 1 May 2001 07:36:48 -0700 From: Pat Calhoun To: Glenn Morrow Cc: Phil Roberts , "'seamoby@diameter.org'" Subject: Re: [seamoby] IRTF mm problem statement Message-ID: <20010501073647.F19382@charizard.diameter.org> Mail-Followup-To: Glenn Morrow , Phil Roberts , "'seamoby@diameter.org'" References: <85AA7486A2C1D411BCA20000F8073E43020D5DB0@crchy271.us.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <85AA7486A2C1D411BCA20000F8073E43020D5DB0@crchy271.us.nortel.com>; from gmorrow@nortelnetworks.com on Tue, May 01, 2001 at 09:39:22AM -0500 Sender: owner-seamoby@diameter.org Precedence: bulk On Tue, May 01, 2001 at 09:39:22AM -0500, Glenn Morrow wrote: > Phil, > > I'm sorry about not getting comments to you sooner. One point I believe > people have misunderstood about using the other routing protocols such as > OSPF and BGP is as follows: > It seems like more of the comments that I have seen so far have been very solutions based. Given that this draft is a problem statement to the IRTF, which will result in a research project, should we really be getting into protocol details? At this point we need to kick off the research activities, and try to stay away from how the problem can be solved. So, let me ask the following question. Could the interested parties provide comments on how the draft could express the problem better, as opposed to how a particular protocol could, or couldn't, solve the problem. Thanks, PatC From owner-seamoby@diameter.org Tue May 1 11:18: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 LAA00861 for ; Tue, 1 May 2001 11:18:47 -0400 (EDT) Received: (qmail 22145 invoked by alias); 1 May 2001 15:06:39 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 22139 invoked by uid 200); 1 May 2001 15:06:38 -0000 Received: (qmail 22131 invoked from network); 1 May 2001 15:06:37 -0000 Received: from unknown (HELO zrc2s03g.us.nortel.com) (47.103.122.66) by c900656-a.plstn1.sfba.home.com with SMTP; 1 May 2001 15:06:37 -0000 Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id KAA04263; Tue, 1 May 2001 10:16:41 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Tue, 1 May 2001 10:10:31 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 May 2001 10:15:54 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E43020D5E78@crchy271.us.nortel.com> From: "Glenn Morrow" To: Pat Calhoun Cc: "'seamoby@diameter.org'" Subject: RE: [seamoby] IRTF mm problem statement Date: Tue, 1 May 2001 10:15:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D251.9B7872C0" 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_01C0D251.9B7872C0 Content-Type: text/plain; charset="iso-8859-1" Pat, I was responding to the explicit verbage in the document about NOT exploring the use of BGP and OSPF. I was simply trying to indicate that perhaps the group should not limit itself in this manner. I felt that in order to do get the point across, I had to give at least a rough example of how you might be able to use these protocols to help solve part of the problem and how an MM protocol can work with these protocols in a synergistic manner. It seemed to me that the verbage in the document about these protocols was perhaps making an assumption it shouldn't have. i.e. that BGP and OSPF would have to be used to install per-node routes and that the scaling problems of MANET would be inherent. That was the only point I was trying to make but you are right it was delving into a possible solution space. Thanks for checking me on that. Glenn -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: Tuesday, May 01, 2001 9:37 AM To: Morrow, Glenn [RICH2:C330:EXCH] Cc: Phil Roberts; 'seamoby@diameter.org' Subject: Re: [seamoby] IRTF mm problem statement On Tue, May 01, 2001 at 09:39:22AM -0500, Glenn Morrow wrote: > Phil, > > I'm sorry about not getting comments to you sooner. One point I believe > people have misunderstood about using the other routing protocols such as > OSPF and BGP is as follows: > It seems like more of the comments that I have seen so far have been very solutions based. Given that this draft is a problem statement to the IRTF, which will result in a research project, should we really be getting into protocol details? At this point we need to kick off the research activities, and try to stay away from how the problem can be solved. So, let me ask the following question. Could the interested parties provide comments on how the draft could express the problem better, as opposed to how a particular protocol could, or couldn't, solve the problem. Thanks, PatC ------_=_NextPart_001_01C0D251.9B7872C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [seamoby] IRTF mm problem statement

Pat,

I was responding to the explicit verbage in the = document about NOT exploring the use of BGP and OSPF. I was simply = trying to indicate that perhaps the group should not limit itself in = this manner. I felt that in order to do get the point across, I had to = give at least a rough example of how you might be able to use these = protocols to help solve part of the problem and how an MM protocol can = work with these protocols in a synergistic manner.

It seemed to me that the verbage in the document = about these protocols was perhaps making an assumption it shouldn't = have. i.e. that BGP and OSPF would have to be used to install per-node = routes and that the scaling problems of MANET would be = inherent.

That was the only point I was trying to make but you = are right it was delving into a possible solution space.

Thanks for checking me on that.

Glenn



-----Original Message-----
From: Pat Calhoun [mailto:pcalhoun@diameter.org]<= /FONT>
Sent: Tuesday, May 01, 2001 9:37 AM
To: Morrow, Glenn [RICH2:C330:EXCH]
Cc: Phil Roberts; 'seamoby@diameter.org'
Subject: Re: [seamoby] IRTF mm problem = statement


On Tue, May 01, 2001 at 09:39:22AM -0500, Glenn = Morrow wrote:
> Phil,
>
> I'm sorry about not getting comments to you = sooner. One point I believe
> people have misunderstood about using the other = routing protocols such as
> OSPF and BGP is as follows:
>

It seems like more of the comments that I have seen = so far have been very
solutions based. Given that this draft is a problem = statement to the IRTF,
which will result in a research project, should we = really be getting into
protocol details? At this point we need to kick off = the research activities,
and try to stay away from how the problem can be = solved.

So, let me ask the following question. Could the = interested parties
provide comments on how the draft could express the = problem better, as
opposed to how a particular protocol could, or = couldn't, solve the
problem.

Thanks,

PatC

------_=_NextPart_001_01C0D251.9B7872C0-- From owner-seamoby@diameter.org Tue May 1 11:30:38 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 LAA01270 for ; Tue, 1 May 2001 11:30:35 -0400 (EDT) Received: (qmail 22709 invoked by alias); 1 May 2001 15:17:35 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 22703 invoked by uid 200); 1 May 2001 15:17:35 -0000 Received: (qmail 22698 invoked from network); 1 May 2001 15:17:34 -0000 Received: from c007-h015.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.222) by c900656-a.plstn1.sfba.home.com with SMTP; 1 May 2001 15:17:34 -0000 Received: (cpmta 7678 invoked from network); 1 May 2001 08:27:28 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.222) with SMTP; 1 May 2001 08:27:28 -0700 X-Sent: 1 May 2001 15:27:28 GMT Message-ID: <005001c0d251$dd369660$6401a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Glenn Morrow" , "Pat Calhoun" Cc: References: <85AA7486A2C1D411BCA20000F8073E43020D5E78@crchy271.us.nortel.com> Subject: Re: [seamoby] IRTF mm problem statement Date: Tue, 1 May 2001 10:17:34 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004C_01C0D227.F049CDA0" 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 This is a multi-part message in MIME format. ------=_NextPart_000_004C_01C0D227.F049CDA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: [seamoby] IRTF mm problem statementPat, In some senses, I agree in others I disagree. The micro-mobility solution, if it is to exist will have to be sandwiched between Mobile IP and MANET. I would like very much for the IRTF to explore what those lines in the sand are. Yes, the nature of these types of discussion WILL BE solution oriented because we have tons of solutions DONE in MIP and MANET. It makes a whole heck of a lot of sense to me, to look at the solutions we have, namely MIP and MANET and finds the deficiencies, inadequacies, and boundaries. This is of paramount importance to the micro-mobility problem statement. Thanks, Phil ----- Original Message ----- From: Glenn Morrow To: Pat Calhoun Cc: 'seamoby@diameter.org' Sent: Tuesday, May 01, 2001 10:15 AM Subject: RE: [seamoby] IRTF mm problem statement Pat, I was responding to the explicit verbage in the document about NOT exploring the use of BGP and OSPF. I was simply trying to indicate that perhaps the group should not limit itself in this manner. I felt that in order to do get the point across, I had to give at least a rough example of how you might be able to use these protocols to help solve part of the problem and how an MM protocol can work with these protocols in a synergistic manner. It seemed to me that the verbage in the document about these protocols was perhaps making an assumption it shouldn't have. i.e. that BGP and OSPF would have to be used to install per-node routes and that the scaling problems of MANET would be inherent. That was the only point I was trying to make but you are right it was delving into a possible solution space. Thanks for checking me on that. Glenn -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: Tuesday, May 01, 2001 9:37 AM To: Morrow, Glenn [RICH2:C330:EXCH] Cc: Phil Roberts; 'seamoby@diameter.org' Subject: Re: [seamoby] IRTF mm problem statement On Tue, May 01, 2001 at 09:39:22AM -0500, Glenn Morrow wrote: > Phil, > > I'm sorry about not getting comments to you sooner. One point I believe > people have misunderstood about using the other routing protocols such as > OSPF and BGP is as follows: > It seems like more of the comments that I have seen so far have been very solutions based. Given that this draft is a problem statement to the IRTF, which will result in a research project, should we really be getting into protocol details? At this point we need to kick off the research activities, and try to stay away from how the problem can be solved. So, let me ask the following question. Could the interested parties provide comments on how the draft could express the problem better, as opposed to how a particular protocol could, or couldn't, solve the problem. Thanks, PatC ------=_NextPart_000_004C_01C0D227.F049CDA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [seamoby] IRTF mm problem statement
Pat,
 
In some senses, I agree in others I = disagree.=20
 
The micro-mobility solution, if it is = to exist=20 will have
to be sandwiched between Mobile IP = and=20 MANET.  I would like
very much for the IRTF to explore = what those=20 lines in the
sand are.  Yes, the nature of = these types of=20 discussion WILL
BE solution oriented because we have = tons of=20 solutions DONE
in MIP and MANET.  It makes a = whole heck of=20 a lot of sense
to me, to look at the solutions we = have, namely=20 MIP and
MANET and finds the deficiencies, = inadequacies,=20 and boundaries.
This is of paramount importance to = the=20 micro-mobility
problem statement.
 
Thanks,
 
Phil
 
----- Original Message -----=20
From: Glenn=20 Morrow
Sent: Tuesday, May 01, 2001 10:15 AM
Subject: RE: [seamoby] IRTF mm problem statement

Pat,

I was responding to the explicit verbage in the = document about=20 NOT exploring the use of BGP and OSPF. I was simply trying to indicate = that=20 perhaps the group should not limit itself in this manner. I felt that in = order=20 to do get the point across, I had to give at least a rough example of = how you=20 might be able to use these protocols to help solve part of the problem = and how=20 an MM protocol can work with these protocols in a synergistic manner.=20

It seemed to me that the verbage in the document about = these=20 protocols was perhaps making an assumption it shouldn't have. i.e. that = BGP and=20 OSPF would have to be used to install per-node routes and that the = scaling=20 problems of MANET would be inherent.

That was the only point I was trying to make but you = are right=20 it was delving into a possible solution space.

Thanks for checking me on that.

Glenn



-----Original Message-----
From: Pat=20 Calhoun [mailto:pcalhoun@diameter.org]=20
Sent: Tuesday, May 01, 2001 9:37 AM
To:=20 Morrow, Glenn [RICH2:C330:EXCH]
Cc: Phil = Roberts;=20 'seamoby@diameter.org'
Subject: Re: [seamoby] = IRTF mm=20 problem statement


On Tue, May 01, 2001 at 09:39:22AM -0500, Glenn Morrow = wrote:
> Phil,
>=20
> I'm sorry about not getting comments to = you sooner.=20 One point I believe
> people have = misunderstood about=20 using the other routing protocols such as
> = OSPF and=20 BGP is as follows:
>

It seems like more of the comments that I have seen so = far have=20 been very
solutions based. Given that this = draft is a=20 problem statement to the IRTF,
which will = result in a=20 research project, should we really be getting into
protocol details? At this point we need to kick off the = research=20 activities,
and try to stay away from how the = problem=20 can be solved.

So, let me ask the following question. Could the = interested=20 parties
provide comments on how the draft = could express=20 the problem better, as
opposed to how a = particular=20 protocol could, or couldn't, solve the
problem.=20

Thanks,

PatC

------=_NextPart_000_004C_01C0D227.F049CDA0-- From owner-seamoby@diameter.org Tue May 1 11:33: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 LAA01394 for ; Tue, 1 May 2001 11:33:58 -0400 (EDT) Received: (qmail 23203 invoked by alias); 1 May 2001 15:23:04 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 23197 invoked by uid 200); 1 May 2001 15:23:04 -0000 Received: (qmail 23188 invoked by uid 500); 1 May 2001 15:23:02 -0000 Date: Tue, 1 May 2001 08:23:02 -0700 From: Pat Calhoun To: Glenn Morrow Cc: Pat Calhoun , "'seamoby@diameter.org'" Subject: Re: [seamoby] IRTF mm problem statement Message-ID: <20010501082302.I19382@charizard.diameter.org> Mail-Followup-To: Glenn Morrow , Pat Calhoun , "'seamoby@diameter.org'" References: <85AA7486A2C1D411BCA20000F8073E43020D5E78@crchy271.us.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <85AA7486A2C1D411BCA20000F8073E43020D5E78@crchy271.us.nortel.com>; from gmorrow@nortelnetworks.com on Tue, May 01, 2001 at 10:15:50AM -0500 Sender: owner-seamoby@diameter.org Precedence: bulk On Tue, May 01, 2001 at 10:15:50AM -0500, Glenn Morrow wrote: > Pat, > > I was responding to the explicit verbage in the document about NOT exploring > the use of BGP and OSPF. I was simply trying to indicate that perhaps the > group should not limit itself in this manner. I felt that in order to do get > the point across, I had to give at least a rough example of how you might be > able to use these protocols to help solve part of the problem and how an MM > protocol can work with these protocols in a synergistic manner. > > It seemed to me that the verbage in the document about these protocols was > perhaps making an assumption it shouldn't have. i.e. that BGP and OSPF would > have to be used to install per-node routes and that the scaling problems of > MANET would be inherent. Given that this draft is still on my to-do list, I should have read it prior to sending my e-mail :( If what you say is true, I agree that perhaps ruling out specific routing protocols MAY be a tad premature. Phil, what are the reasoning? Thanks, PatC From owner-seamoby@diameter.org Tue May 1 11:58: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 LAA01998 for ; Tue, 1 May 2001 11:58:34 -0400 (EDT) Received: (qmail 23896 invoked by alias); 1 May 2001 15:46:53 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 23890 invoked by uid 200); 1 May 2001 15:46:53 -0000 Received: (qmail 23882 invoked from network); 1 May 2001 15:46:51 -0000 Received: from patan.sun.com (192.18.98.43) by c900656-a.plstn1.sfba.home.com with SMTP; 1 May 2001 15:46:51 -0000 Received: from heliopolis.eng.sun.com ([152.70.1.39]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA09787; Tue, 1 May 2001 08:56:53 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id IAA29136; Tue, 1 May 2001 08:56:52 -0700 (PDT) Message-Id: <200105011556.IAA29136@heliopolis.eng.sun.com> Date: Tue, 1 May 2001 08:56:53 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: Re: [seamoby] IRTF mm problem statement To: gmorrow@nortelnetworks.com, pcalhoun@diameter.org Cc: PRoberts@MEGISTO.com, seamoby@diameter.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: wGIk7u8ArxFtpL2ZEnKOYA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-seamoby@diameter.org Precedence: bulk Hi Pat, I agree with PhilN that there is too much emphasis on router failure. I'd like to see some discussion about targeted update. Current router protocols indiscriminately flood updates. I think it may be necessary for MM routing to look at targeting updates just to those routers that need it. This technology could have broader applicability in BGP routing as well. jak >Delivered-To: seamoby-list@charizard.diameter.org >Date: Tue, 1 May 2001 07:36:48 -0700 >From: Pat Calhoun >To: Glenn Morrow >Cc: Phil Roberts , "'seamoby@diameter.org'" >Subject: Re: [seamoby] IRTF mm problem statement >Mail-Followup-To: Glenn Morrow , Phil Roberts , "'seamoby@diameter.org'" >Content-Disposition: inline >User-Agent: Mutt/1.2.5i > >On Tue, May 01, 2001 at 09:39:22AM -0500, Glenn Morrow wrote: >> Phil, >> >> I'm sorry about not getting comments to you sooner. One point I believe >> people have misunderstood about using the other routing protocols such as >> OSPF and BGP is as follows: >> > >It seems like more of the comments that I have seen so far have been very >solutions based. Given that this draft is a problem statement to the IRTF, >which will result in a research project, should we really be getting into >protocol details? At this point we need to kick off the research activities, >and try to stay away from how the problem can be solved. > >So, let me ask the following question. Could the interested parties >provide comments on how the draft could express the problem better, as >opposed to how a particular protocol could, or couldn't, solve the >problem. > >Thanks, > >PatC From owner-seamoby@diameter.org Tue May 1 12:06: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 MAA02293 for ; Tue, 1 May 2001 12:06:50 -0400 (EDT) Received: (qmail 24503 invoked by alias); 1 May 2001 15:55:02 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 24497 invoked by uid 200); 1 May 2001 15:55:02 -0000 Received: (qmail 24485 invoked from network); 1 May 2001 15:54:59 -0000 Received: from unknown (HELO megisto-sql1.megisto.com) (63.113.114.132) by c900656-a.plstn1.sfba.home.com with SMTP; 1 May 2001 15:54:59 -0000 Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Tue, 1 May 2001 11:58:15 -0400 Message-ID: From: Phil Roberts To: "'Pat Calhoun'" Cc: "'seamoby@diameter.org'" Subject: RE: [seamoby] IRTF mm problem statement Date: Tue, 1 May 2001 11:58:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Tuesday, May 01, 2001 11:23 AM > To: Glenn Morrow > Cc: Pat Calhoun; 'seamoby@diameter.org' > Subject: Re: [seamoby] IRTF mm problem statement > > > On Tue, May 01, 2001 at 10:15:50AM -0500, Glenn Morrow wrote: > > Pat, > > > > I was responding to the explicit verbage in the document > about NOT exploring > > the use of BGP and OSPF. I was simply trying to indicate > that perhaps the > > group should not limit itself in this manner. I felt that > in order to do get > > the point across, I had to give at least a rough example of > how you might be > > able to use these protocols to help solve part of the > problem and how an MM > > protocol can work with these protocols in a synergistic manner. > > > > It seemed to me that the verbage in the document about > these protocols was > > perhaps making an assumption it shouldn't have. i.e. that > BGP and OSPF would > > have to be used to install per-node routes and that the > scaling problems of > > MANET would be inherent. > > Given that this draft is still on my to-do list, I should > have read it prior to > sending my e-mail :( If what you say is true, I agree that > perhaps ruling out > specific routing protocols MAY be a tad premature. > > Phil, what are the reasoning? > > Thanks, > > PatC > Hi, here are the two sentences that mention OSPF - Could such mobility requirements and fast restoration requirements be met in a way that is more efficient and simpler than approaches based on Mobile IP and OSPF by using a routing protocol that implements host routes within a limited scope within the network? - A comparison with OSPF and Mobile IP are involved in making such an assessment both in terms of relative scalability, performance, and complexity. I don't think mentioning them in this way does anything other than state the problem or suggests that an alternative must be used. But it would be fairly easy to modify it to suggest enhancements to OSPF as an alternate, sounds a little too solution oriented. What if in the first I said, "using a *new or enhanced existing* routing protocol ...?" And I could just delete the last sentence. I do agree that limiting choices and suggesting solutions are not appropriate in this doc. Phil From owner-seamoby@diameter.org Tue May 1 12:17: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 MAA02646 for ; Tue, 1 May 2001 12:17:14 -0400 (EDT) Received: (qmail 25091 invoked by alias); 1 May 2001 16:05:47 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 25085 invoked by uid 200); 1 May 2001 16:05:47 -0000 Received: (qmail 25077 invoked from network); 1 May 2001 16:05:45 -0000 Received: from sj-msg-core-4.cisco.com (171.71.163.10) by c900656-a.plstn1.sfba.home.com with SMTP; 1 May 2001 16:05:45 -0000 Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f41GFNd10377; Tue, 1 May 2001 09:15:23 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AEW27598; Tue, 1 May 2001 09:15:17 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA13580; Tue, 1 May 2001 09:15:13 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15086.57617.175533.388740@thomasm-u1.cisco.com> Date: Tue, 1 May 2001 09:15:13 -0700 (PDT) To: Phil Roberts Cc: "'Pat Calhoun'" , "'seamoby@diameter.org'" Subject: RE: [seamoby] IRTF mm 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 Phil, Perhaps it would be better to state it in terms of intradomain routing protocols instead of naming OSPF specifically. Then the MANET folks, as well as other IGP's won't feel like they're being ruled out. In fact, I think that wide-net comparison is an important part of the work. Mike Phil Roberts writes: > > > > -----Original Message----- > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > Sent: Tuesday, May 01, 2001 11:23 AM > > To: Glenn Morrow > > Cc: Pat Calhoun; 'seamoby@diameter.org' > > Subject: Re: [seamoby] IRTF mm problem statement > > > > > > On Tue, May 01, 2001 at 10:15:50AM -0500, Glenn Morrow wrote: > > > Pat, > > > > > > I was responding to the explicit verbage in the document > > about NOT exploring > > > the use of BGP and OSPF. I was simply trying to indicate > > that perhaps the > > > group should not limit itself in this manner. I felt that > > in order to do get > > > the point across, I had to give at least a rough example of > > how you might be > > > able to use these protocols to help solve part of the > > problem and how an MM > > > protocol can work with these protocols in a synergistic manner. > > > > > > It seemed to me that the verbage in the document about > > these protocols was > > > perhaps making an assumption it shouldn't have. i.e. that > > BGP and OSPF would > > > have to be used to install per-node routes and that the > > scaling problems of > > > MANET would be inherent. > > > > Given that this draft is still on my to-do list, I should > > have read it prior to > > sending my e-mail :( If what you say is true, I agree that > > perhaps ruling out > > specific routing protocols MAY be a tad premature. > > > > Phil, what are the reasoning? > > > > Thanks, > > > > PatC > > > > Hi, > > here are the two sentences that mention OSPF > > - Could such mobility requirements and fast restoration requirements be met > in a way that is more efficient and simpler than approaches based on Mobile > IP and OSPF by using a routing protocol that implements host routes within a > limited scope within the network? > > - A comparison with OSPF and Mobile IP are involved in making such an > assessment both in terms of relative scalability, performance, and > complexity. > > > I don't think mentioning them in this way does anything other than state > the problem or suggests that an alternative must be used. But it would be > fairly easy to modify it to suggest enhancements to OSPF as an alternate, > sounds a little too solution oriented. What if in the first I said, "using > a *new or enhanced existing* routing protocol ...?" And I could just delete > the last sentence. I do agree that limiting choices and suggesting > solutions are not appropriate in this doc. > > Phil From owner-seamoby@diameter.org Tue May 1 12:20: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 MAA02812 for ; Tue, 1 May 2001 12:20:47 -0400 (EDT) Received: (qmail 25481 invoked by alias); 1 May 2001 16:07:43 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 25475 invoked by uid 200); 1 May 2001 16:07:43 -0000 Received: (qmail 25461 invoked by uid 500); 1 May 2001 16:07:41 -0000 Date: Tue, 1 May 2001 09:07:41 -0700 From: Pat Calhoun To: Phil Roberts Cc: "'Pat Calhoun'" , "'seamoby@diameter.org'" Subject: Re: [seamoby] IRTF mm problem statement Message-ID: <20010501090741.C23735@charizard.diameter.org> Mail-Followup-To: Phil Roberts , 'Pat Calhoun' , "'seamoby@diameter.org'" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from PRoberts@MEGISTO.com on Tue, May 01, 2001 at 11:58:14AM -0400 Sender: owner-seamoby@diameter.org Precedence: bulk On Tue, May 01, 2001 at 11:58:14AM -0400, Phil Roberts wrote: > here are the two sentences that mention OSPF > > - Could such mobility requirements and fast restoration requirements be met > in a way that is more efficient and simpler than approaches based on Mobile > IP and OSPF by using a routing protocol that implements host routes within a > limited scope within the network? > > - A comparison with OSPF and Mobile IP are involved in making such an > assessment both in terms of relative scalability, performance, and > complexity. > > > I don't think mentioning them in this way does anything other than state > the problem or suggests that an alternative must be used. But it would be > fairly easy to modify it to suggest enhancements to OSPF as an alternate, > sounds a little too solution oriented. I agree. > What if in the first I said, "using > a *new or enhanced existing* routing protocol ...?" And I could just delete > the last sentence. I do agree that limiting choices and suggesting > solutions are not appropriate in this doc. I think this would be less controversial, and more appropriate to this type of document. Thanks, PatC > > Phil From owner-seamoby@diameter.org Tue May 1 12:28: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 MAA03035 for ; Tue, 1 May 2001 12:28:05 -0400 (EDT) Received: (qmail 26289 invoked by alias); 1 May 2001 16:15:26 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 26283 invoked by uid 200); 1 May 2001 16:15:26 -0000 Received: (qmail 26275 invoked from network); 1 May 2001 16:15:20 -0000 Received: from patan.sun.com (192.18.98.43) by c900656-a.plstn1.sfba.home.com with SMTP; 1 May 2001 16:15:20 -0000 Received: from heliopolis.eng.sun.com ([152.70.1.39]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02168 for ; Tue, 1 May 2001 09:25:09 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id JAA00045 for ; Tue, 1 May 2001 09:25:04 -0700 (PDT) Message-Id: <200105011625.JAA00045@heliopolis.eng.sun.com> Date: Tue, 1 May 2001 09:25:05 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: [seamoby] test To: seamoby@diameter.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 1B2M2Y8AsgTpgAmY7PhCfg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-seamoby@diameter.org Precedence: bulk From owner-seamoby@diameter.org Tue May 1 13:43: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 NAA05369 for ; Tue, 1 May 2001 13:43:48 -0400 (EDT) Received: (qmail 29427 invoked by alias); 1 May 2001 17:32:09 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 29421 invoked by uid 200); 1 May 2001 17:32:09 -0000 Received: (qmail 29416 invoked from network); 1 May 2001 17:32:07 -0000 Received: from out1.prserv.net (HELO prserv.net) (32.97.166.31) by c900656-a.plstn1.sfba.home.com with SMTP; 1 May 2001 17:32:07 -0000 Received: from [32.101.185.28] (slip-32-101-185-28.ca.us.prserv.net[32.101.185.28]) by prserv.net (out1) with ESMTP id <2001050117415820104vrqqte>; Tue, 1 May 2001 17:41:58 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Sender: ahmrphd@pop3.attglobal.net Message-Id: In-Reply-To: Date: Tue, 1 May 2001 10:42:26 -0700 To: Phil Roberts , "'seamoby@diameter.org'" From: Arthur Ross Subject: Re: [seamoby] IRTF mm problem statement Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA05369 Phil: A very important aspect of MM is missing from this statement: the need for MM to aware of, in some sense, the radio nature of the connections. While I believe that the solution(s) should be RTT-agnostic (RTT = radio transmission technology), it should not be radio-physics-ignorant. I don't believe for a microsecond that the micromobility problem can be addressed, or even has much meaning, in the absence of radio physics awareness. Radio propagation in the ground clutter is unavoidably ugly. Connections are "soft." They are error-prone and highly variable in their properties (read: they fade, in several senses). There are well-known communication-theoretic ways of coping with these problems, but, alas, they cannot be conveniently isolated to each access point; the best mitigation techniques will involve interaction among the access points. Several things come to mind: selection of the best access point(s) (a.k.a. "mobile assisted handoff" in the cellular/PCS world); power control; transmission rate, others, diversity transmission/combining. QoS, in particular, is intimately intertwined with the physics. Clearly, what I am trying to do here is suggest that this new MM protocol subsume some (most?) of the RAN functionality that has previously been ignored in the IP world. I find it very strange that the fast handoff discussion seems to have assumed that the nature of the physical layer can be packaged and idealized away in some nice, neat way. Sorry, not so. The physics is at the heart of the problem, damnit! Clearly, of course, this is a sort of electro-political hand grenade on the dinner table, but it needs to be confronted. I'm not trying to sully the intellectual purity of IP. Rather, I'm trying to raise awareness of the need for MM to address the low-level behavior of the radio environment in order that realistic IP-based mobility solutions can be found. There are both architectural and protocol implications of radio-aware IP. Primarily, there will need to be some network functionality that serves as the diversity combiner/packet distributor. A combo FA-Combiner/Distributor gizmo comes to mind. Something must be assumed about this architecture to make progress, IMHO. And there are two major categories of protocol: those between the RAN and the MNs, and the interactions among the access points/access routers/mobile routers. CNP comes to mind in regard to the latter. The whole thing is a real design challenge, if one agrees that the connectivity, even of the nominally fixed parts of the network isn't really fixed, but will be dynamic - devices come & go, change their connectivity, etc. This, I suppose, is the domain of MANET, with which I am not familiar. Seems to me that the conceptual interface between MM and the specific RTTs would be a kind of OOP-like "wrapper" that encapsulates the RTT details, leaving visible only those aspects that are needed for MM. To make this proposal concrete, I suggest that §2.2 be augmented as follows: "2.2 Problem Two" "One of the primary principles of the Internet has been end-to-end communication. Most (if not all) of the protocols running over IP have been designed with end-to-end signaling in mind. Currently, changes due mobility induce unwanted end-to-end signaling. This may cause applications running over IP to fail due to delay and latency induced by unwanted signaling. Security, QoS and AAA signaling all suffer due to this." "Moreover, in a wireless-connected mobile host environment, routing and QoS are intimately related to the radio nature of the connection. Effective management of communication performance involves cooperation and exchange of information among radio access points. Host-based routing will be more useful if it supports such communication-engineering aspects of wireless mobile IP services. [CNP] may be of use in this interaction." And add the following to the references: [CNP] P. Neumiller, "Applying Contract Net Protocol to Mobile Handover State Transfer, Draft-neumiller-seamoby-cnpmobility-00, November 17, 2000. Sorry to be the skunk at the garden party ... -- Regards, -- Arthur From owner-seamoby@diameter.org Tue May 1 13:55: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 NAA05949 for ; Tue, 1 May 2001 13:55:06 -0400 (EDT) Received: (qmail 30722 invoked by alias); 1 May 2001 17:43:36 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 30716 invoked by uid 200); 1 May 2001 17:43:36 -0000 Received: (qmail 30708 invoked from network); 1 May 2001 17:43:34 -0000 Received: from dsl081-031-075.sea1.dsl.speakeasy.net (HELO exc01.cerulic.com) (64.81.31.75) by c900656-a.plstn1.sfba.home.com with SMTP; 1 May 2001 17:43:34 -0000 Received: by EXC01 with Internet Mail Service (5.5.2653.19) id <2FY40RXS>; Tue, 1 May 2001 11:00:33 -0700 Message-ID: From: "Rosso, Jean-Michel" To: James Kempf , gmorrow@nortelnetworks.com, pcalhoun@diameter.org Cc: PRoberts@MEGISTO.com, seamoby@diameter.org Subject: RE: [seamoby] IRTF mm problem statement Date: Tue, 1 May 2001 11:00:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0D268.9B15E8F0" 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_000_01C0D268.9B15E8F0 Content-Type: text/plain; charset="iso-8859-1" > I'd like to see some discussion about targeted update.Current router > protocols indiscriminately flood updates. I think it may be necessary > for MM routing to look at targeting updates just to those routers > that need it. I would second that. In the context of public access (data) networks there is a business trend that seems to emerge, which will allow for "peering agreements". The business assumption, here, is that no single entity will own all networks ... fair! and that business arrangements will be made to rapidly increase wireless coverage. "Peering agreements" will enable roaming in the short term but will also enable MM across domains in the future. In other words, targeted updates will provide an efficient mean to deliver network updates to one's peers (on adjacent networks). -jmr -----Original Message----- From: James Kempf [mailto:James.Kempf@Sun.COM] Sent: Tuesday, May 01, 2001 8:57 AM To: gmorrow@nortelnetworks.com; pcalhoun@diameter.org Cc: PRoberts@MEGISTO.com; seamoby@diameter.org Subject: Re: [seamoby] IRTF mm problem statement Hi Pat, I agree with PhilN that there is too much emphasis on router failure. I'd like to see some discussion about targeted update. Current router protocols indiscriminately flood updates. I think it may be necessary for MM routing to look at targeting updates just to those routers that need it. This technology could have broader applicability in BGP routing as well. jak >Delivered-To: seamoby-list@charizard.diameter.org >Date: Tue, 1 May 2001 07:36:48 -0700 >From: Pat Calhoun >To: Glenn Morrow >Cc: Phil Roberts , "'seamoby@diameter.org'" >Subject: Re: [seamoby] IRTF mm problem statement >Mail-Followup-To: Glenn Morrow , Phil Roberts , "'seamoby@diameter.org'" >Content-Disposition: inline >User-Agent: Mutt/1.2.5i > >On Tue, May 01, 2001 at 09:39:22AM -0500, Glenn Morrow wrote: >> Phil, >> >> I'm sorry about not getting comments to you sooner. One point I believe >> people have misunderstood about using the other routing protocols such as >> OSPF and BGP is as follows: >> > >It seems like more of the comments that I have seen so far have been very >solutions based. Given that this draft is a problem statement to the IRTF, >which will result in a research project, should we really be getting into >protocol details? At this point we need to kick off the research activities, >and try to stay away from how the problem can be solved. > >So, let me ask the following question. Could the interested parties >provide comments on how the draft could express the problem better, as >opposed to how a particular protocol could, or couldn't, solve the >problem. > >Thanks, > >PatC ------_=_NextPart_000_01C0D268.9B15E8F0 Content-Type: application/octet-stream; name="Jean-Michel Rosso (Business Fax).vcf" Content-Disposition: attachment; filename="Jean-Michel Rosso (Business Fax).vcf" ------_=_NextPart_000_01C0D268.9B15E8F0-- From owner-seamoby@diameter.org Tue May 1 15:54: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 PAA08906 for ; Tue, 1 May 2001 15:53:54 -0400 (EDT) Received: (qmail 2687 invoked by alias); 1 May 2001 19:41:40 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2681 invoked by uid 200); 1 May 2001 19:41:39 -0000 Received: (qmail 2676 invoked from network); 1 May 2001 19:41:38 -0000 Received: from unknown (HELO megisto-sql1.megisto.com) (63.113.114.132) by c900656-a.plstn1.sfba.home.com with SMTP; 1 May 2001 19:41:38 -0000 Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Tue, 1 May 2001 15:45:04 -0400 Message-ID: From: Phil Roberts To: "'Arthur Ross'" , "'seamoby@diameter.org'" Subject: RE: [seamoby] IRTF mm problem statement Date: Tue, 1 May 2001 15:45:03 -0400 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, Well, what to say about this. One might think that a good chunk of this problem can be abstracted without any awareness of radio link characteristics. The point of this particular piece of research has to do with updating reachability awareness and forwarding tables within the routers the mobile attaches to rather than how to figure out which points the mobiles can reach and how well they can reach it. It would be hard also to make too many assumptions about what that radio system could be. You include that the architecture should have a provision for a diversity combiner but surely there are networks over which something like this would run on which there is no diversity combiner? I wasn't privy to all the discussions in the fast handover design teams in MIP but there was at least some effort put in to thinking about what happens when this is running over a fairly lossy medium. Whether or not a ping-pong effect should be handled in these protocols was also discussed and highly controversial. Both of those can be characteristics of wireless systems with multiple access points, and both may be quite independent of whether it is a TDMA or CDMA or whatever system running at 800MHz, 1800MHz, or whatever. There has been reluctance so far to design within the IETF a radio technology specific subsystem. I personally am not willing to push for that. Perhaps you can get a discussion going on in the new wireless interest list Phil N set up to organize an effort to promote such. It seems that productive work along the path already specified in the document can go on and the possibilities for exploring ratholes by adding in radio technology specific issues might be plentiful. Phil > -----Original Message----- > From: Arthur Ross [mailto:a.ross@ieee.org] > Sent: Tuesday, May 01, 2001 1:42 PM > To: Phil Roberts; 'seamoby@diameter.org' > Subject: Re: [seamoby] IRTF mm problem statement > > > Phil: > > A very important aspect of MM is missing from this statement: > the need for > MM to aware of, in some sense, the radio nature of the connections. > > While I believe that the solution(s) should be RTT-agnostic > (RTT = radio > transmission technology), it should not be > radio-physics-ignorant. I don't > believe for a microsecond that the micromobility problem can > be addressed, > or even has much meaning, in the absence of radio physics awareness. > > Radio propagation in the ground clutter is unavoidably ugly. > Connections > are "soft." They are error-prone and highly variable in their > properties > (read: they fade, in several senses). There are well-known > communication-theoretic ways of coping with these problems, > but, alas, they > cannot be conveniently isolated to each access point; the > best mitigation > techniques will involve interaction among the access points. > Several things > come to mind: selection of the best access point(s) (a.k.a. "mobile > assisted handoff" in the cellular/PCS world); power control; > transmission > rate, others, diversity transmission/combining. QoS, in particular, is > intimately intertwined with the physics. > > Clearly, what I am trying to do here is suggest that this new > MM protocol > subsume some (most?) of the RAN functionality that has previously been > ignored in the IP world. I find it very strange that the fast handoff > discussion seems to have assumed that the nature of the > physical layer can > be packaged and idealized away in some nice, neat way. Sorry, > not so. The > physics is at the heart of the problem, damnit! > > Clearly, of course, this is a sort of electro-political hand > grenade on the > dinner table, but it needs to be confronted. > > I'm not trying to sully the intellectual purity of IP. > Rather, I'm trying > to raise awareness of the need for MM to address the > low-level behavior of > the radio environment in order that realistic IP-based > mobility solutions > can be found. > > There are both architectural and protocol implications of > radio-aware IP. > Primarily, there will need to be some network functionality > that serves as > the diversity combiner/packet distributor. A combo > FA-Combiner/Distributor > gizmo comes to mind. Something must be assumed about this > architecture to > make progress, IMHO. > > And there are two major categories of protocol: those between > the RAN and > the MNs, and the interactions among the access points/access > routers/mobile > routers. CNP comes to mind in regard to the latter. The whole > thing is a > real design challenge, if one agrees that the connectivity, > even of the > nominally fixed parts of the network isn't really fixed, but will be > dynamic - devices come & go, change their connectivity, etc. This, I > suppose, is the domain of MANET, with which I am not familiar. > > Seems to me that the conceptual interface between MM and the > specific RTTs > would be a kind of OOP-like "wrapper" that encapsulates the > RTT details, > leaving visible only those aspects that are needed for MM. > > To make this proposal concrete, I suggest that §2.2 be > augmented as follows: > > "2.2 Problem Two" > > "One of the primary principles of the Internet has been end-to-end > communication. Most (if not all) of the protocols running over IP > have been designed with end-to-end signaling in mind. Currently, > changes due mobility induce unwanted end-to-end signaling. This may > cause applications running over IP to fail due to delay and latency > induced by unwanted signaling. Security, QoS and AAA signaling all > suffer due to this." > > "Moreover, in a wireless-connected mobile host > environment, routing and QoS > are intimately related to the radio nature of the > connection. Effective > management of communication performance involves > cooperation and exchange > of information among radio access points. Host-based > routing will be more > useful if it supports such communication-engineering aspects of > wireless mobile IP services. [CNP] may be of use in this > interaction." > > And add the following to the references: > > [CNP] P. Neumiller, "Applying Contract Net Protocol to > Mobile Handover > State Transfer, Draft-neumiller-seamoby-cnpmobility-00, > November 17, 2000. > > Sorry to be the skunk at the garden party ... > > -- Regards, > -- Arthur > From owner-seamoby@diameter.org Tue May 1 16:19: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 QAA09428 for ; Tue, 1 May 2001 16:19:21 -0400 (EDT) Received: (qmail 3409 invoked by alias); 1 May 2001 20:07:38 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 3403 invoked by uid 200); 1 May 2001 20:07:38 -0000 Received: (qmail 3398 invoked from network); 1 May 2001 20:07:36 -0000 Received: from c007-h000.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.206) by c900656-a.plstn1.sfba.home.com with SMTP; 1 May 2001 20:07:36 -0000 Received: (cpmta 13287 invoked from network); 1 May 2001 13:17:04 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.206) with SMTP; 1 May 2001 13:17:04 -0700 X-Sent: 1 May 2001 20:17:04 GMT Message-ID: <000d01c0d27a$0740bc60$6401a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Phil Roberts" , "'Arthur Ross'" , References: Subject: Re: [seamoby] IRTF mm problem statement Date: Tue, 1 May 2001 15:05:03 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk Hi Phil R./Arthur, > One might think that a good chunk of this problem can be abstracted without > any awareness of radio link characteristics. The point of this particular > piece of research has to do with updating reachability awareness and > forwarding tables within the routers the mobile attaches to rather than how > to figure out which points the mobiles can reach and how well they can reach > it. I see this is where the disconnect is Phil R. We HAD gone much further in SeaMoby of our discussions of micro-mobility than your current list of drafts. We entertained issues related to the mobile and its view of the network. Also, most people were familiar with the OBAST paper which describes a method for macro/micro/local mobility where the air interfaces properties of CDMA are socketed as Arthur has described (mainly because I recited enough times on the list) [even in the CRAPS BOF I had to make this argument]{See thwap thread a while back on SeaMoby list}. > > It would be hard also to make too many assumptions about what that radio > system could be. You include that the architecture should have a provision > for a diversity combiner but surely there are networks over which something > like this would run on which there is no diversity combiner? Also, Phil R., I had discussed many times on the SeaMoby list that diversity combining is not just for CDMA. When done over IP, other radios, even TDMA radios can take advantage of it in the outer-loop sense. I have several patents pending on how to do this with TDMA, and frequency hop radios, not just DSSS. Of course those are Motorola's and don't do us much good here in the IETF unless some other folks can come up with some stuff independently. :-) > I wasn't privy > to all the discussions in the fast handover design teams in MIP but there > was at least some effort put in to thinking about what happens when this is > running over a fairly lossy medium. Whether or not a ping-pong effect > should be handled in these protocols was also discussed and highly > controversial. Again we discussed this in the SeaMoby list and CRAPS list and OBAST list numerous times. The TADD/TDROP timers as used in CDMA can work for any RF interface to reduce ping-pong if done in a borrowed and abstract way over IP. > Both of those can be characteristics of wireless systems > with multiple access points, and both may be quite independent of whether it > is a TDMA or CDMA or whatever system running at 800MHz, 1800MHz, or > whatever. In this sense I agree with you, but only so far as it can be done in a common way. Macro-diversity selection can be done with almost any radio type, and OBAST it is an option. OBAST allows optionalk make-before-break with any radio type. OBAST allows simultaneous and different link layers to be active if they want to use it. > > There has been reluctance so far to design within the IETF a radio > technology specific subsystem. I personally am not willing to push for > that. Perhaps you can get a discussion going on in the new wireless > interest list Phil N set up to organize an effort to promote such. It seems > that productive work along the path already specified in the document can go > on and the possibilities for exploring ratholes by adding in radio > technology specific issues might be plentiful. We don't need to explore a rathole here. What we need to do is ask ourselves what things can be made common for all RF L2s and be put over IP? This is the IMPORTANT question to ask yourself. Really! Of course I sound like a broken record, but I think (I hope, Pat and James and Gary and many others) are starting to think about this and understand it. Perhaps not in the same with the same zeal that I express. :-) I am pretty confident that Arthur is on the right track. His arguments about radio physics can be hidden with an OO like abstraction of putting macro-diversity over IP. That is the big first step to consider. I will show deference to the draft author and chair. If you want this conversation moved over to the new list that is fine I will try and summarize it and move it over. Thanks, Phil N. From owner-seamoby@diameter.org Tue May 1 16:31: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 QAA09642 for ; Tue, 1 May 2001 16:31:40 -0400 (EDT) Received: (qmail 4070 invoked by alias); 1 May 2001 20:19:50 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 4064 invoked by uid 200); 1 May 2001 20:19:49 -0000 Received: (qmail 4059 invoked from network); 1 May 2001 20:19:48 -0000 Received: from unknown (HELO megisto-sql1.megisto.com) (63.113.114.132) by c900656-a.plstn1.sfba.home.com with SMTP; 1 May 2001 20:19:48 -0000 Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Tue, 1 May 2001 16:23:13 -0400 Message-ID: From: Phil Roberts To: "'Phil Neumiller'" , seamoby@diameter.org Subject: RE: [seamoby] IRTF mm problem statement Date: Tue, 1 May 2001 16:23:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi, I didn't see any of this in the resultant mm problem statement and it didn't come out in the discussions in Minneapolis. Did it not get any consensus in the seamoby design teams? I would like to stay focused in this request for the IRTF. But it sounds like there is a possibility for more work of a different sort. Don't know where it should be discussed. Phil > -----Original Message----- > From: Phil Neumiller [mailto:neumiller@telocity.com] > Sent: Tuesday, May 01, 2001 4:05 PM > To: Phil Roberts; 'Arthur Ross'; seamoby@diameter.org > Subject: Re: [seamoby] IRTF mm problem statement > > > Hi Phil R./Arthur, > > > One might think that a good chunk of this problem can be > abstracted without > > any awareness of radio link characteristics. The point of > this particular > > piece of research has to do with updating reachability awareness and > > forwarding tables within the routers the mobile attaches to > rather than how > > to figure out which points the mobiles can reach and how > well they can reach > > it. > > I see this is where the disconnect is Phil R. We HAD gone > much further in > SeaMoby of our discussions of micro-mobility than your > current list of drafts. > We entertained issues related to the mobile and its view of > the network. > Also, most people were familiar with the OBAST paper which describes > a method for macro/micro/local mobility where the air > interfaces properties > of CDMA are socketed as Arthur has described (mainly because I recited > enough times on the list) [even in the CRAPS BOF I had to make this > argument]{See thwap thread a while back on SeaMoby list}. > > > > > It would be hard also to make too many assumptions about > what that radio > > system could be. You include that the architecture should > have a provision > > for a diversity combiner but surely there are networks over > which something > > like this would run on which there is no diversity combiner? > > Also, Phil R., I had discussed many times on the SeaMoby list > that diversity > combining is not just for CDMA. When done over IP, other radios, even > TDMA radios can take advantage of it in the outer-loop sense. > I have several > patents pending on how to do this with TDMA, and frequency hop radios, > not just DSSS. Of course those are Motorola's and don't do > us much good > here in the IETF unless some other folks can come up with some stuff > independently. :-) > > > I wasn't privy > > to all the discussions in the fast handover design teams in > MIP but there > > was at least some effort put in to thinking about what > happens when this is > > running over a fairly lossy medium. Whether or not a > ping-pong effect > > should be handled in these protocols was also discussed and highly > > controversial. > > Again we discussed this in the SeaMoby list and CRAPS list and OBAST > list numerous times. The TADD/TDROP timers as used in CDMA can > work for any RF interface to reduce ping-pong if done in a > borrowed and > abstract way over IP. > > > Both of those can be characteristics of wireless systems > > with multiple access points, and both may be quite > independent of whether it > > is a TDMA or CDMA or whatever system running at 800MHz, 1800MHz, or > > whatever. > > In this sense I agree with you, but only so far as it can be > done in a common way. > Macro-diversity selection can be done with almost any radio > type, and OBAST > it is an option. OBAST allows optionalk make-before-break > with any radio type. > OBAST allows simultaneous and different link layers to be > active if they want to > use it. > > > > There has been reluctance so far to design within the IETF a radio > > technology specific subsystem. I personally am not willing > to push for > > that. Perhaps you can get a discussion going on in the new wireless > > interest list Phil N set up to organize an effort to > promote such. It seems > > that productive work along the path already specified in > the document can go > > on and the possibilities for exploring ratholes by adding in radio > > technology specific issues might be plentiful. > > We don't need to explore a rathole here. What we need to do > is ask ourselves > what things can be made common for all RF L2s and be put over IP? This > is the IMPORTANT question to ask yourself. Really! Of > course I sound like > a broken record, but I think (I hope, Pat and James and Gary > and many others) are > starting to think about this and understand it. Perhaps not > in the same with > the same zeal that I express. :-) I am pretty confident that > Arthur is on the > right track. His arguments about radio physics can be hidden > with an OO > like abstraction of putting macro-diversity over IP. That is > the big first step > to consider. > > I will show deference to the draft author and chair. If you > want this conversation > moved over to the new list that is fine I will try and > summarize it and move > it over. > > Thanks, > > Phil N. > > From owner-seamoby@diameter.org Tue May 1 16:55: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 QAA10016 for ; Tue, 1 May 2001 16:55:24 -0400 (EDT) Received: (qmail 4893 invoked by alias); 1 May 2001 20:43:11 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 4886 invoked by uid 200); 1 May 2001 20:43:11 -0000 Received: (qmail 4881 invoked from network); 1 May 2001 20:43:08 -0000 Received: from unknown (HELO RRMAIL01.RADIOROUTER?NT) (63.103.94.23) by c900656-a.plstn1.sfba.home.com with SMTP; 1 May 2001 20:43:08 -0000 Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2650.21) id <2MX5GAD7>; Tue, 1 May 2001 16:52:31 -0400 Message-ID: From: Vincent Park To: "'Phil Neumiller'" , Phil Roberts , "'Arthur Ross'" , seamoby@diameter.org Subject: RE: [seamoby] IRTF mm problem statement Date: Tue, 1 May 2001 16:52:23 -0400 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 think I agree with Phil R. There is a lot going on the wireless space and any attempt to custom build IP protocols for wireless sounds to me like the wrong path to take... The idea here is to abstract a specific (hard) problem for the routing experts in the IETF (host routing or fast subnet routing or whatever you want to call it) and let the IRTF folks scratch their heads for a while....If anything, Seamoby, has been very useful in allowing people to explore the mobility space in general, realize the enormity of the task/issues/interactions etc and hopefully identify *core* pieces of technology that are missing.... I hope that the new IRTF group is going to be about **one of these core missing pieces** i.e.: host routing. At this state wirless links maybe need to be abstracted in the way wired-line links are (Up, Down, Relative merit). Later on, when we have a better understand how things might work we may consider exposing more of the characteristics of the "wireless world" to the routing protocol....but lets first walk before we fly... -Vince Vincent D. Park Flarion Technologies, Inc. Bedminster One 135 Route 202/206 South Bedminster, NJ 07921 -----Original Message----- From: Phil Neumiller [mailto:neumiller@telocity.com] Sent: Tuesday, May 01, 2001 4:05 PM To: Phil Roberts; 'Arthur Ross'; seamoby@diameter.org Subject: Re: [seamoby] IRTF mm problem statement Hi Phil R./Arthur, > One might think that a good chunk of this problem can be abstracted without > any awareness of radio link characteristics. The point of this particular > piece of research has to do with updating reachability awareness and > forwarding tables within the routers the mobile attaches to rather than how > to figure out which points the mobiles can reach and how well they can reach > it. I see this is where the disconnect is Phil R. We HAD gone much further in SeaMoby of our discussions of micro-mobility than your current list of drafts. We entertained issues related to the mobile and its view of the network. Also, most people were familiar with the OBAST paper which describes a method for macro/micro/local mobility where the air interfaces properties of CDMA are socketed as Arthur has described (mainly because I recited enough times on the list) [even in the CRAPS BOF I had to make this argument]{See thwap thread a while back on SeaMoby list}. > > It would be hard also to make too many assumptions about what that radio > system could be. You include that the architecture should have a provision > for a diversity combiner but surely there are networks over which something > like this would run on which there is no diversity combiner? Also, Phil R., I had discussed many times on the SeaMoby list that diversity combining is not just for CDMA. When done over IP, other radios, even TDMA radios can take advantage of it in the outer-loop sense. I have several patents pending on how to do this with TDMA, and frequency hop radios, not just DSSS. Of course those are Motorola's and don't do us much good here in the IETF unless some other folks can come up with some stuff independently. :-) > I wasn't privy > to all the discussions in the fast handover design teams in MIP but there > was at least some effort put in to thinking about what happens when this is > running over a fairly lossy medium. Whether or not a ping-pong effect > should be handled in these protocols was also discussed and highly > controversial. Again we discussed this in the SeaMoby list and CRAPS list and OBAST list numerous times. The TADD/TDROP timers as used in CDMA can work for any RF interface to reduce ping-pong if done in a borrowed and abstract way over IP. > Both of those can be characteristics of wireless systems > with multiple access points, and both may be quite independent of whether it > is a TDMA or CDMA or whatever system running at 800MHz, 1800MHz, or > whatever. In this sense I agree with you, but only so far as it can be done in a common way. Macro-diversity selection can be done with almost any radio type, and OBAST it is an option. OBAST allows optionalk make-before-break with any radio type. OBAST allows simultaneous and different link layers to be active if they want to use it. > > There has been reluctance so far to design within the IETF a radio > technology specific subsystem. I personally am not willing to push for > that. Perhaps you can get a discussion going on in the new wireless > interest list Phil N set up to organize an effort to promote such. It seems > that productive work along the path already specified in the document can go > on and the possibilities for exploring ratholes by adding in radio > technology specific issues might be plentiful. We don't need to explore a rathole here. What we need to do is ask ourselves what things can be made common for all RF L2s and be put over IP? This is the IMPORTANT question to ask yourself. Really! Of course I sound like a broken record, but I think (I hope, Pat and James and Gary and many others) are starting to think about this and understand it. Perhaps not in the same with the same zeal that I express. :-) I am pretty confident that Arthur is on the right track. His arguments about radio physics can be hidden with an OO like abstraction of putting macro-diversity over IP. That is the big first step to consider. I will show deference to the draft author and chair. If you want this conversation moved over to the new list that is fine I will try and summarize it and move it over. Thanks, Phil N. From owner-seamoby@diameter.org Tue May 1 17:18: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 RAA10470 for ; Tue, 1 May 2001 17:18:31 -0400 (EDT) Received: (qmail 5812 invoked by alias); 1 May 2001 21:07:26 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 5806 invoked by uid 200); 1 May 2001 21:07:26 -0000 Received: (qmail 5801 invoked from network); 1 May 2001 21:07:24 -0000 Received: from c007-h011.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.217) by c900656-a.plstn1.sfba.home.com with SMTP; 1 May 2001 21:07:24 -0000 Received: (cpmta 7552 invoked from network); 1 May 2001 14:16:49 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.217) with SMTP; 1 May 2001 14:16:49 -0700 X-Sent: 1 May 2001 21:16:49 GMT Message-ID: <001f01c0d282$48985c60$6401a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Vincent Park" , References: Subject: Re: [seamoby] IRTF mm problem statement Date: Tue, 1 May 2001 16:04:10 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk Hello Vincent, ----- Original Message ----- From: "Vincent Park" To: "'Phil Neumiller'" ; "Phil Roberts" ; "'Arthur Ross'" ; Sent: Tuesday, May 01, 2001 3:52 PM Subject: RE: [seamoby] IRTF mm problem statement > I think I agree with Phil R. There is a lot going on the wireless space and > any attempt to custom build IP protocols for wireless sounds to me like the > wrong path to take... Hmm. I (and Arthur) AM (is)/WAS/were suggesting abstraction not custom protocols. So I don't understand your statment at all. > > The idea here is to abstract a specific (hard) problem for the routing > experts in the IETF (host routing or fast subnet routing or whatever you > want to call it) and let the IRTF folks scratch their heads for a > while....If anything, Seamoby, has been very useful in allowing people to > explore the mobility space in general, realize the enormity of the > task/issues/interactions etc and hopefully identify *core* pieces of > technology that are missing.... There are some other real hard problems too. Mobile nodes move and the physics of this is will be completely ignored if we just focus on host routing. May as well NOT call it micro-mobility then. I can't see how this can be called micro-mobility at all in fact. Can somebody please explain this to me? I feel like I just fell off a turnip truck or something??? Thanks, Phil From owner-seamoby@diameter.org Tue May 1 17:49: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 RAA11028 for ; Tue, 1 May 2001 17:49:03 -0400 (EDT) Received: (qmail 7363 invoked by alias); 1 May 2001 21:37:51 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 7357 invoked by uid 200); 1 May 2001 21:37:51 -0000 Received: (qmail 7352 invoked from network); 1 May 2001 21:37:49 -0000 Received: from c007-h000.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.206) by c900656-a.plstn1.sfba.home.com with SMTP; 1 May 2001 21:37:49 -0000 Received: (cpmta 15143 invoked from network); 1 May 2001 14:47:32 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.206) with SMTP; 1 May 2001 14:47:32 -0700 X-Sent: 1 May 2001 21:47:32 GMT Message-ID: <004901c0d286$8a38c200$6401a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "James Kempf" , , , References: <200105012131.OAA10129@heliopolis.eng.sun.com> Subject: Re: Radio Access Network Protocols (was: Re: [seamoby] IRTF mm problem statement) Date: Tue, 1 May 2001 16:34:38 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk Perhaps this should be moved to the new list. I will let Pat decide. I have some more comments below: ----- Original Message ----- From: "James Kempf" To: ; ; ; Sent: Tuesday, May 01, 2001 4:31 PM Subject: Radio Access Network Protocols (was: Re: [seamoby] IRTF mm problem statement) > IETF has resisted doing wireless specific protocols in the past. The > CRAPS BOF explicitly rejected doing that kind of work, though perhaps This seeams rather oxymoronic, since COMMON is the first word in CRAPS. Common implied abstraction in my mind, but I guess this sense was lost by others. > there has been a change of heart. I expect, however, that there > will be the same kind of resistance in the future. I am not sure there was resistance James. What I found was just lots of confusion. The terminology barrier is huge. We don't have a constituency in the IETF that knows enough about a large number of RF protocols to even formulate an abstraction I am afraid. Somebody said the IEEE may be a better choice. The problem I have with MWIF is that (last time I checked) its sole purpose in life is/was to influence 3GPP2 and 3GPP, two cellular standards. What we had hoped for in CRAPS is what Ron Akers (Bluetooth BOF co-chair) called the "uber-alles" [forgot umlaut] RF protocol [he was not fond of the idea of a one size fits all either]. But I DONT want one size fits all. I wanted to specify the requirements for essentially a base class (in OO terms), from which individual implementors or RF protocols can inherit most of the important mechanisms and use the protocol equivalent of virtual functions for their radio specifics [which by no means have to be standardized in the IETF]. The protocol could provide a "framework" if you will for doing RF in the IETF. I suggested a similar approach to Scott Bradner for the sub-IP area. I am not sure if he has considered it yet. The best would be perhaps to focus by starting on the handover abstract trigger [as being discussed in the CT DT] and work to tie the know between the sub-IP area and whatever micro-mobility is/was can be. Thanks, Phil From owner-seamoby@diameter.org Tue May 1 17:53: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 RAA11106 for ; Tue, 1 May 2001 17:53:48 -0400 (EDT) Received: (qmail 6537 invoked by alias); 1 May 2001 21:21:25 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 6531 invoked by uid 200); 1 May 2001 21:21:24 -0000 Received: (qmail 6526 invoked from network); 1 May 2001 21:21:23 -0000 Received: from patan.sun.com (192.18.98.43) by c900656-a.plstn1.sfba.home.com with SMTP; 1 May 2001 21:21:23 -0000 Received: from heliopolis.eng.sun.com ([152.70.1.39]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05017; Tue, 1 May 2001 14:31:19 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id OAA10129; Tue, 1 May 2001 14:31:18 -0700 (PDT) Message-Id: <200105012131.OAA10129@heliopolis.eng.sun.com> Date: Tue, 1 May 2001 14:31:18 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: Radio Access Network Protocols (was: Re: [seamoby] IRTF mm problem statement) To: PRoberts@MEGISTO.com, a.ross@ieee.org, seamoby@diameter.org, neumiller@telocity.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 2NBzjr63MJ/w7YwWL9mJQQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-seamoby@diameter.org Precedence: bulk IETF has resisted doing wireless specific protocols in the past. The CRAPS BOF explicitly rejected doing that kind of work, though perhaps there has been a change of heart. I expect, however, that there will be the same kind of resistance in the future. There has been some ongoing work in MWIF (Mobile Wireless Internet Forum, http://www.mwif.org) on a radio access network architecture, called OpenRAN, that is independent of radio link protocol, along the lines suggested by Arthur and PhilN. The architecture is complete, we are about to release the report, and we are planning some conference presentations and journal articles to familiarize the wireless community with the architecture in the near future. We have already taken this work to the 3Gs, there is some interest in 3GPP2 though also a certain amount of resistence, but 3GPP has essentially rejected it as too experimental. The next step for the OpenRAN architecture is to do some protocol development work, and MWIF is currently debating whether to do this or not. If it does, you can be sure the OBAST work will be important input. The objective of the protocol development work would be to develop a RAN protocol independent of radio link protocol and have vendors implement prototypes for interoperability testing (the other aspect of this is interoperable radio network management, which turns out to be the single largest barrier to open systems in UTRAN, and it is also being investigated by MWIF). Once the protocol is complete, it would be taken to IETF and the 3Gs for consideration. By virtue of it being radio link independent, one could view it as not L2 specific, though it is wireless specific, so perhaps IETF would be more interested in it. If MWIF declines to continue working on the protocol, some mild interest has been expressed by a few vendors to continue working on it in another forum. Most of the people involved in the OpenRAN effort believe that MWIF is the right place to do the technical work for now (similar to how the Multivendor Switching Forum developed their protocol first, before bringing it to IETF), then bringing it to IETF later, if appropriate. So if any radio knowledgable types are interested, I'd encourage you to become involved. jak >Delivered-To: seamoby-list@charizard.diameter.org >X-Sent: 1 May 2001 20:17:04 GMT >From: "Phil Neumiller" >To: "Phil Roberts" , "'Arthur Ross'" , >Subject: Re: [seamoby] IRTF mm problem statement >Date: Tue, 1 May 2001 15:05:03 -0500 >X-Priority: 3 >X-MSMail-Priority: Normal >X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 > >Hi Phil R./Arthur, > >> One might think that a good chunk of this problem can be abstracted without >> any awareness of radio link characteristics. The point of this particular >> piece of research has to do with updating reachability awareness and >> forwarding tables within the routers the mobile attaches to rather than how >> to figure out which points the mobiles can reach and how well they can reach >> it. > >I see this is where the disconnect is Phil R. We HAD gone much further in >SeaMoby of our discussions of micro-mobility than your current list of drafts. >We entertained issues related to the mobile and its view of the network. >Also, most people were familiar with the OBAST paper which describes >a method for macro/micro/local mobility where the air interfaces properties >of CDMA are socketed as Arthur has described (mainly because I recited >enough times on the list) [even in the CRAPS BOF I had to make this >argument]{See thwap thread a while back on SeaMoby list}. > >> >> It would be hard also to make too many assumptions about what that radio >> system could be. You include that the architecture should have a provision >> for a diversity combiner but surely there are networks over which something >> like this would run on which there is no diversity combiner? > >Also, Phil R., I had discussed many times on the SeaMoby list that diversity >combining is not just for CDMA. When done over IP, other radios, even >TDMA radios can take advantage of it in the outer-loop sense. I have several >patents pending on how to do this with TDMA, and frequency hop radios, >not just DSSS. Of course those are Motorola's and don't do us much good >here in the IETF unless some other folks can come up with some stuff >independently. :-) > >> I wasn't privy >> to all the discussions in the fast handover design teams in MIP but there >> was at least some effort put in to thinking about what happens when this is >> running over a fairly lossy medium. Whether or not a ping-pong effect >> should be handled in these protocols was also discussed and highly >> controversial. > >Again we discussed this in the SeaMoby list and CRAPS list and OBAST >list numerous times. The TADD/TDROP timers as used in CDMA can >work for any RF interface to reduce ping-pong if done in a borrowed and >abstract way over IP. > >> Both of those can be characteristics of wireless systems >> with multiple access points, and both may be quite independent of whether it >> is a TDMA or CDMA or whatever system running at 800MHz, 1800MHz, or >> whatever. > >In this sense I agree with you, but only so far as it can be done in a common way. >Macro-diversity selection can be done with almost any radio type, and OBAST >it is an option. OBAST allows optionalk make-before-break with any radio type. >OBAST allows simultaneous and different link layers to be active if they want to >use it. >> >> There has been reluctance so far to design within the IETF a radio >> technology specific subsystem. I personally am not willing to push for >> that. Perhaps you can get a discussion going on in the new wireless >> interest list Phil N set up to organize an effort to promote such. It seems >> that productive work along the path already specified in the document can go >> on and the possibilities for exploring ratholes by adding in radio >> technology specific issues might be plentiful. > >We don't need to explore a rathole here. What we need to do is ask ourselves >what things can be made common for all RF L2s and be put over IP? This >is the IMPORTANT question to ask yourself. Really! Of course I sound like >a broken record, but I think (I hope, Pat and James and Gary and many others) are >starting to think about this and understand it. Perhaps not in the same with >the same zeal that I express. :-) I am pretty confident that Arthur is on the >right track. His arguments about radio physics can be hidden with an OO >like abstraction of putting macro-diversity over IP. That is the big first step >to consider. > >I will show deference to the draft author and chair. If you want this conversation >moved over to the new list that is fine I will try and summarize it and move >it over. > >Thanks, > >Phil N. > > From owner-seamoby@diameter.org Tue May 1 18:03: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 SAA11220 for ; Tue, 1 May 2001 18:03:02 -0400 (EDT) Received: (qmail 7991 invoked by alias); 1 May 2001 21:51:55 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 7985 invoked by uid 200); 1 May 2001 21:51:55 -0000 Received: (qmail 7976 invoked from network); 1 May 2001 21:51:53 -0000 Received: from mercury.sun.com (192.9.25.1) by c900656-a.plstn1.sfba.home.com with SMTP; 1 May 2001 21:51:53 -0000 Received: from heliopolis.eng.sun.com ([152.70.1.39]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA20366; Tue, 1 May 2001 15:01:50 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id PAA11319; Tue, 1 May 2001 15:01:47 -0700 (PDT) Message-Id: <200105012201.PAA11319@heliopolis.eng.sun.com> Date: Tue, 1 May 2001 15:01:47 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: Re: Radio Access Network Protocols (was: Re: [seamoby] IRTF mm problem statement) To: James.Kempf@sun.com, PRoberts@MEGISTO.com, a.ross@ieee.org, seamoby@diameter.org, neumiller@telocity.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: mlgYQ73LrT2ySZDVwcqb0A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-seamoby@diameter.org Precedence: bulk Hi PhilN, > The problem I have with MWIF is that (last time I checked) >its sole purpose in life is/was to influence 3GPP2 and 3GPP, two cellular >standards. What we had hoped for in CRAPS is what Ron Akers (Bluetooth >BOF co-chair) called the "uber-alles" [forgot umlaut] RF protocol [he was >not fond of the idea of a one size fits all either]. > There are some of us who don't like this restriction in MWIF's mission and we are trying to change it. If we are not successful, you are likely to see a significant decrease in technical participation in MWIF. If we are, then there will be radio access network protocol development done there. MWIF has gone about as far as it can go in influencing the 3Gs. >But I DONT want one size fits all. I wanted to specify the requirements for >essentially a base class (in OO terms), from which individual implementors >or RF protocols can inherit most of the important mechanisms and use the >protocol equivalent of virtual functions for their radio specifics [which by >no means have to be standardized in the IETF]. The protocol could provide >a "framework" if you will for doing RF in the IETF. Well, the OpenRAN architecure attempts to define that kind of framework. The intent of doing the protocol development is to come up with a common protocol that would allow customization for different radio link layers. So the common protocol would handle stuff like power control, channel allocation, congestion resolution, etc., which would then be customized to particular radio links by configuration. And if a particular radio link protocol didn't need a particular function, it could be dropped. I'm tempted to say macrodiversity resolution for TDMA fits in this class, but, as you've pointed out, it might be possible to do macrodiversity resolution with an IP layer protocol. jak From owner-seamoby@diameter.org Tue May 1 18:10: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 SAA11339 for ; Tue, 1 May 2001 18:10:58 -0400 (EDT) Received: (qmail 8555 invoked by alias); 1 May 2001 21:59:56 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8549 invoked by uid 200); 1 May 2001 21:59:56 -0000 Received: (qmail 8544 invoked from network); 1 May 2001 21:59:54 -0000 Received: from c007-h008.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.214) by c900656-a.plstn1.sfba.home.com with SMTP; 1 May 2001 21:59:54 -0000 Received: (cpmta 6145 invoked from network); 1 May 2001 14:51:46 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.214) with SMTP; 1 May 2001 14:51:46 -0700 X-Sent: 1 May 2001 21:51:46 GMT Message-ID: <005501c0d287$208cf320$6401a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Phil Roberts" , References: Subject: Re: [seamoby] IRTF mm problem statement Date: Tue, 1 May 2001 16:38:56 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk Hi Phil, I have some more comments. ----- Original Message ----- From: "Phil Roberts" To: "'Phil Neumiller'" ; Sent: Tuesday, May 01, 2001 3:23 PM Subject: RE: [seamoby] IRTF mm problem statement > > Hi, > > I didn't see any of this in the resultant mm problem statement and it > didn't come out in the discussions in Minneapolis. Did it not get any > consensus in the seamoby design teams? I would like to stay focused in this > request for the IRTF. But it sounds like there is a possibility for more > work of a different sort. Don't know where it should be discussed. > > Phil > Ok here is a quote directly from the SeaMoby MM problem statement. * Mobility maintaining the same routable IP address of a mobile node or mobile network. * Handover between heterogeneous networks. For example, 802.11, Bluetooth and 3G cellular. * How to discover a new Access Link and the Access Router serving the new Access Link. * How to discover the bandwidth, cost, error rate (and other properties) of candidate Access Links. * Involving QoS characteristics as part of the handover process. * Optimize the path for mobile-to-mobile communications. * Enable plug and play capabilities for Mobile Devices, Access Routers/Access Links. * Support for mobility of mobile hosts and mobile networks I don't see the words "host routing" in there anywhere. I do see lots of physical issues related specifically to radio links. What am I missing in your comment? This was the consensus??? Best regards, Phil From owner-seamoby@diameter.org Tue May 1 19:05: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 TAA12079 for ; Tue, 1 May 2001 19:05:55 -0400 (EDT) Received: (qmail 10118 invoked by alias); 1 May 2001 22:54:46 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 10112 invoked by uid 200); 1 May 2001 22:54:45 -0000 Received: (qmail 10107 invoked from network); 1 May 2001 22:54:44 -0000 Received: from unknown (HELO megisto-sql1.megisto.com) (63.113.114.132) by c900656-a.plstn1.sfba.home.com with SMTP; 1 May 2001 22:54:44 -0000 Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Tue, 1 May 2001 18:58:10 -0400 Message-ID: From: Phil Roberts To: "'Phil Neumiller'" , seamoby@diameter.org Subject: RE: [seamoby] IRTF mm problem statement Date: Tue, 1 May 2001 18:58:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk > > Hi, > > > > I didn't see any of this in the resultant mm problem > statement and it > > didn't come out in the discussions in Minneapolis. Did it > not get any > > consensus in the seamoby design teams? I would like to > stay focused in this > > request for the IRTF. But it sounds like there is a > possibility for more > > work of a different sort. Don't know where it should be discussed. > > > > Phil > > > > Ok here is a quote directly from the SeaMoby MM problem statement. > > > * Mobility maintaining the same routable IP address of a mobile > node or mobile network. > * Handover between heterogeneous networks. For example, 802.11, > Bluetooth and 3G cellular. > * How to discover a new Access Link and the Access Router serving > the new Access Link. > * How to discover the bandwidth, cost, error rate (and other > properties) of candidate Access Links. > * Involving QoS characteristics as part of the handover process. > * Optimize the path for mobile-to-mobile communications. > * Enable plug and play capabilities for Mobile Devices, Access > Routers/Access Links. > * Support for mobility of mobile hosts and mobile networks > > I don't see the words "host routing" in there anywhere. I do > see lots of > physical issues related specifically to radio links. What am > I missing in > your comment? This was the consensus??? > > Best regards, > > Phil > > > Hi Phil, I see that in the list from the mm problem statement there is something about discovery of network/link/access point characteristics, but nothing like what you were talking about in the email I responded to. Re: host routing. The first item does seem to describe host routing, doesn't it? > Mobility maintaining the same routable IP address of a mobile > node or mobile network. Isn't that exactly what you end up with? An entry in the forwarding table of the current router and the previous router for that mobile's specific address which did not change, and a mechanism for propagating that info? I don't get the impression we're converging on anything or considering anything new here. If I'm correct, do you mind if I stop responding to these? Phil From owner-seamoby@diameter.org Tue May 1 19:12: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 TAA12177 for ; Tue, 1 May 2001 19:12:31 -0400 (EDT) Received: (qmail 10686 invoked by alias); 1 May 2001 23:01:36 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 10680 invoked by uid 200); 1 May 2001 23:01:35 -0000 Received: (qmail 10675 invoked from network); 1 May 2001 23:01:33 -0000 Received: from sj-msg-core-2.cisco.com (171.69.43.88) by c900656-a.plstn1.sfba.home.com with SMTP; 1 May 2001 23:01:33 -0000 Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f41NBYK18969; Tue, 1 May 2001 16:11:34 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AEW39444; Tue, 1 May 2001 16:11:06 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA13638; Tue, 1 May 2001 16:11:06 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15087.17034.320408.531147@thomasm-u1.cisco.com> Date: Tue, 1 May 2001 16:11:06 -0700 (PDT) To: Phil Roberts Cc: "'Phil Neumiller'" , seamoby@diameter.org Subject: RE: [seamoby] IRTF mm 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 Phil Roberts writes: > I see that in the list from the mm problem statement there is something > about discovery of network/link/access point characteristics, but nothing > like what you were talking about in the email I responded to. > > Re: host routing. The first item does seem to describe host routing, > doesn't it? > > Mobility maintaining the same routable IP address of a mobile > > node or mobile network. No, because it says mobile network as well. That implies the ability to push subnets around, not just host routes. Mike From owner-seamoby@diameter.org Tue May 1 19:15: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 TAA12191 for ; Tue, 1 May 2001 19:15:56 -0400 (EDT) Received: (qmail 11167 invoked by alias); 1 May 2001 23:05:09 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 11161 invoked by uid 200); 1 May 2001 23:05:09 -0000 Received: (qmail 11156 invoked from network); 1 May 2001 23:05:08 -0000 Received: from unknown (HELO megisto-sql1.megisto.com) (63.113.114.132) by c900656-a.plstn1.sfba.home.com with SMTP; 1 May 2001 23:05:08 -0000 Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Tue, 1 May 2001 19:08:34 -0400 Message-ID: From: Phil Roberts To: "'Michael Thomas'" Cc: seamoby@diameter.org Subject: RE: [seamoby] IRTF mm problem statement Date: Tue, 1 May 2001 19:08:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk > > Re: host routing. The first item does seem to describe > host routing, > > doesn't it? > > > Mobility maintaining the same routable IP address > of a mobile > > > node or mobile network. > > No, because it says mobile network as well. That > implies the ability to push subnets around, not > just host routes. > > Mike > True enough. BTW, have you come up with any suggested language changes to include this in the draft? Phil From owner-seamoby@diameter.org Tue May 1 19:58: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 TAA12648 for ; Tue, 1 May 2001 19:58:23 -0400 (EDT) Received: (qmail 12148 invoked by alias); 1 May 2001 23:47:30 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 12142 invoked by uid 200); 1 May 2001 23:47:30 -0000 Received: (qmail 12137 invoked from network); 1 May 2001 23:47:27 -0000 Received: from penguin-ext.wise.edt.ericsson.se (194.237.142.110) by c900656-a.plstn1.sfba.home.com with SMTP; 1 May 2001 23:47:27 -0000 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 f41NvUO11286 for ; Wed, 2 May 2001 01:57:30 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Wed May 02 01:57:30 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 2 May 2001 01:52:43 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBDE2@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman \(ERA\)" To: "'Vincent Park'" , "'Phil Neumiller'" , Phil Roberts , "'Arthur Ross'" , seamoby@diameter.org Subject: RE: [seamoby] IRTF mm problem statement Date: Wed, 2 May 2001 01:57:27 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-seamoby@diameter.org Precedence: bulk > I think I agree with Phil R. There is a lot going on the wireless space and > any attempt to custom build IP protocols for wireless sounds to me like the > wrong path to take... > => I think Phil N point was that you do not need to custom build protocols for specific L2's. Instead abstracting the common features of these L2s and considering that in the MM design. Makes sense to me. What's wrong with that ? Hesham From owner-seamoby@diameter.org Tue May 1 19:59: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 TAA12660 for ; Tue, 1 May 2001 19:59:58 -0400 (EDT) Received: (qmail 12320 invoked by alias); 1 May 2001 23:47:57 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 12313 invoked by uid 200); 1 May 2001 23:47:57 -0000 Received: (qmail 12303 invoked from network); 1 May 2001 23:47:54 -0000 Received: from unknown (HELO RRMAIL01.RADIOROUTER?NT) (63.103.94.23) by c900656-a.plstn1.sfba.home.com with SMTP; 1 May 2001 23:47:54 -0000 Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2650.21) id <2MX5GAJ5>; Tue, 1 May 2001 19:57:27 -0400 Message-ID: <41331FBC6C32D411A93D00B0D04C95532C7623@rrmail01.lab.flarion.com> From: "Alan O'Neill" To: "'Michael Thomas'" , Phil Roberts Cc: seamoby@diameter.org Subject: RE: [seamoby] IRTF mm problem statement Date: Tue, 1 May 2001 19:57:19 -0400 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 Phil, Its a nick pit but we do need to cover the mobile network equally well in the draft. We are overly dependent on the host routing term (with all its baggage) so maybe mobile enhanced routing would be better ? Michael, If Phil makes this clear, then I think we can all agree that we are talking about a very different problem than is presently solved in the Internet, that of support for rapidly changing prefixes (at mobility rates) where the prefixes include a large proportion of hosts, and mobile entities are not renumbered on movement. Its not the whole problem, just a reasonable slice that if solved brings community benefits. Alan. -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: 02 May 2001 00:11 To: Phil Roberts Cc: 'Phil Neumiller'; seamoby@diameter.org Subject: RE: [seamoby] IRTF mm problem statement Phil Roberts writes: > I see that in the list from the mm problem statement there is something > about discovery of network/link/access point characteristics, but nothing > like what you were talking about in the email I responded to. > > Re: host routing. The first item does seem to describe host routing, > doesn't it? > > Mobility maintaining the same routable IP address of a mobile > > node or mobile network. No, because it says mobile network as well. That implies the ability to push subnets around, not just host routes. Mike From owner-seamoby@diameter.org Tue May 1 20:01: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 UAA12690 for ; Tue, 1 May 2001 20:01:31 -0400 (EDT) Received: (qmail 12764 invoked by alias); 1 May 2001 23:49:28 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 12755 invoked by uid 200); 1 May 2001 23:49:27 -0000 Received: (qmail 12736 invoked from network); 1 May 2001 23:49:24 -0000 Received: from unknown (HELO RRMAIL01.RADIOROUTER?NT) (63.103.94.23) by c900656-a.plstn1.sfba.home.com with SMTP; 1 May 2001 23:49:24 -0000 Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2650.21) id <2MX5GAKA>; Tue, 1 May 2001 19:58:57 -0400 Message-ID: <41331FBC6C32D411A93D00B0D04C95532C7624@rrmail01.lab.flarion.com> From: "Alan O'Neill" To: "'seamoby@diameter.org'" Subject: RE: [seamoby] IRTF mm problem statement Date: Tue, 1 May 2001 19:58:49 -0400 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 Nick pit ? Nit pit ? Nit Pick ? Wow - am I dislexik ? :-) -----Original Message----- From: Alan O'Neill Sent: 02 May 2001 00:57 To: 'Michael Thomas'; Phil Roberts Cc: seamoby@diameter.org Subject: RE: [seamoby] IRTF mm problem statement Phil, Its a nick pit but we do need to cover the mobile network equally well in the draft. We are overly dependent on the host routing term (with all its baggage) so maybe mobile enhanced routing would be better ? From owner-seamoby@diameter.org Tue May 1 20:05: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 UAA12724 for ; Tue, 1 May 2001 20:05:50 -0400 (EDT) Received: (qmail 13615 invoked by alias); 1 May 2001 23:54:47 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 13609 invoked by uid 200); 1 May 2001 23:54:47 -0000 Received: (qmail 13604 invoked from network); 1 May 2001 23:54:45 -0000 Received: from c007-h011.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.217) by c900656-a.plstn1.sfba.home.com with SMTP; 1 May 2001 23:54:45 -0000 Received: (cpmta 24937 invoked from network); 1 May 2001 17:04:19 -0700 Received: from unknown (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.217) with SMTP; 1 May 2001 17:04:19 -0700 X-Sent: 2 May 2001 00:04:19 GMT Message-ID: <002001c0d299$89ff19c0$6401a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Phil Roberts" , References: Subject: Re: [seamoby] IRTF mm problem statement Date: Tue, 1 May 2001 18:50:38 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk Hello PhilR, > Hi Phil, > > I see that in the list from the mm problem statement there is something > about discovery of network/link/access point characteristics, but nothing > like what you were talking about in the email I responded to. Can you point out what this is. I can't tell from your response what you are talking about specifically. > > Re: host routing. The first item does seem to describe host routing, > doesn't it? > > Mobility maintaining the same routable IP address of a mobile > > node or mobile network. No, not to me, at least not from the explanations I have read. > Isn't that exactly what you end up with? An entry in the forwarding table > of the current router and the previous router for that mobile's specific > address which did not change, and a mechanism for propagating that info? > > I don't get the impression we're converging on anything or considering > anything new here. If I'm correct, do you mind if I stop responding to > these? Yes I do mind. Just think of me as a child or something and please break this down into words I can understand. I need extra explaining or something on this because I don't get it. It is your draft and your words and this problem is very important to me, and I really want to understand why its host routes out of the box. A). Why do you conclude that there is a route propogation solution needed already? B). There are other possible solutions right? C). The mobile may very well need to communicate with the newAR long before a route can be "propogated". D). Why aren't tunnels discussed as an option? E). What if that new router is also a mobile node? Best regards, Phil From owner-seamoby@diameter.org Tue May 1 20:10:01 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 UAA12749 for ; Tue, 1 May 2001 20:10:00 -0400 (EDT) Received: (qmail 14134 invoked by alias); 1 May 2001 23:59:10 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 14128 invoked by uid 200); 1 May 2001 23:59:10 -0000 Received: (qmail 14123 invoked from network); 1 May 2001 23:59:08 -0000 Received: from out2.prserv.net (HELO prserv.net) (32.97.166.32) by c900656-a.plstn1.sfba.home.com with SMTP; 1 May 2001 23:59:08 -0000 Received: from [129.37.43.143] (slip-129-37-42-173.ca.us.prserv.net[129.37.42.173]) by prserv.net (out2) with ESMTP id <2001050200091020205188s7e>; Wed, 2 May 2001 00:09:11 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: ahmrphd@pop3.attglobal.net Message-Id: In-Reply-To: <034BEFD03799D411A59F00508BDF7546013DBDE2@esealnt448.al.sw.ericsson.se> Date: Tue, 1 May 2001 17:08:33 -0700 To: "Hesham Soliman" , "'Vincent Park'" , "'Phil Neumiller'" , Phil Roberts , seamoby@diameter.org From: Arthur Ross Subject: RE: [seamoby] IRTF mm problem statement Sender: owner-seamoby@diameter.org Precedence: bulk At 16:57 -0700 05/01/2001, Hesham Soliman wrote: >> > => I think Phil N point was that you do not need to custom > build protocols for specific L2's. Instead abstracting the > common features of these L2s and considering that in the > MM design. Makes sense to me. > What's wrong with that ? > This was exactly my original intent ... guess I didn't express it as well as I could have. -- ahmr From owner-seamoby@diameter.org Tue May 1 20:13: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 UAA12806 for ; Tue, 1 May 2001 20:13:10 -0400 (EDT) Received: (qmail 14660 invoked by alias); 2 May 2001 00:02:20 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 14654 invoked by uid 200); 2 May 2001 00:02:20 -0000 Received: (qmail 14647 invoked by uid 500); 2 May 2001 00:02:17 -0000 Date: Tue, 1 May 2001 17:02:17 -0700 From: Pat Calhoun To: Phil Neumiller Cc: Phil Roberts , seamoby@diameter.org Subject: Re: [seamoby] IRTF mm problem statement Message-ID: <20010501170217.G4672@charizard.diameter.org> Mail-Followup-To: Phil Neumiller , Phil Roberts , seamoby@diameter.org References: <002001c0d299$89ff19c0$6401a8c0@philneum> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <002001c0d299$89ff19c0$6401a8c0@philneum>; from neumiller@telocity.com on Tue, May 01, 2001 at 06:50:38PM -0500 Sender: owner-seamoby@diameter.org Precedence: bulk On Tue, May 01, 2001 at 06:50:38PM -0500, Phil Neumiller wrote: > A). Why do you conclude that there is a route propogation solution needed > already? > B). There are other possible solutions right? > C). The mobile may very well need to communicate with the newAR long > before a route can be "propogated". > D). Why aren't tunnels discussed as an option? > E). What if that new router is also a mobile node? Phil, While I do agree that it would be nice to have some clearer protocol design details, it begs the question whether this level of detail is required in a document that is intended to kick start a research activity. Should the IRTF WG responsible for this work not be the one that would specify these details? Is it required in this spec? Seems like we are moving into the solution space :( PatC From owner-seamoby@diameter.org Tue May 1 20:16:42 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 UAA12818 for ; Tue, 1 May 2001 20:16:42 -0400 (EDT) Received: (qmail 15126 invoked by alias); 2 May 2001 00:05:38 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 15120 invoked by uid 200); 2 May 2001 00:05:38 -0000 Received: (qmail 15112 invoked from network); 2 May 2001 00:05:36 -0000 Received: from c007-h013.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.220) by c900656-a.plstn1.sfba.home.com with SMTP; 2 May 2001 00:05:36 -0000 Received: (cpmta 12490 invoked from network); 1 May 2001 17:15:10 -0700 Received: from unknown (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.220) with SMTP; 1 May 2001 17:15:10 -0700 X-Sent: 2 May 2001 00:15:10 GMT Message-ID: <004801c0d29b$0b296540$6401a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Pat Calhoun" Cc: "Phil Roberts" , References: <002001c0d299$89ff19c0$6401a8c0@philneum> <20010501170217.G4672@charizard.diameter.org> Subject: Re: [seamoby] IRTF mm problem statement Date: Tue, 1 May 2001 19:01:30 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk Pat, Why propose a solution (host routes) to a research activity then? I would think we would talk more about problems with EXISTING micro-mobility and macro-mobility solutions so the appropriate architecture and fit and analysis can be peformed. I don't get it. Please explain. Thanks, Phil Now I am really confused. ----- Original Message ----- From: "Pat Calhoun" To: "Phil Neumiller" Cc: "Phil Roberts" ; Sent: Tuesday, May 01, 2001 7:02 PM Subject: Re: [seamoby] IRTF mm problem statement > On Tue, May 01, 2001 at 06:50:38PM -0500, Phil Neumiller wrote: > > A). Why do you conclude that there is a route propogation solution needed > > already? > > B). There are other possible solutions right? > > C). The mobile may very well need to communicate with the newAR long > > before a route can be "propogated". > > D). Why aren't tunnels discussed as an option? > > E). What if that new router is also a mobile node? > > Phil, > > While I do agree that it would be nice to have some clearer protocol > design details, it begs the question whether this level of detail is > required in a document that is intended to kick start a research > activity. Should the IRTF WG responsible for this work not be the one > that would specify these details? Is it required in this spec? > > Seems like we are moving into the solution space :( > > PatC > From owner-seamoby@diameter.org Tue May 1 20:24: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 UAA12879 for ; Tue, 1 May 2001 20:24:16 -0400 (EDT) Received: (qmail 15726 invoked by alias); 2 May 2001 00:13:16 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 15720 invoked by uid 200); 2 May 2001 00:13:15 -0000 Received: (qmail 15715 invoked from network); 2 May 2001 00:13:13 -0000 Received: from sj-msg-core-4.cisco.com (171.71.163.10) by c900656-a.plstn1.sfba.home.com with SMTP; 2 May 2001 00:13:13 -0000 Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f420Mnd09258; Tue, 1 May 2001 17:22:49 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AEW41320; Tue, 1 May 2001 17:22:42 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA13676; Tue, 1 May 2001 17:22:42 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15087.21330.537590.346501@thomasm-u1.cisco.com> Date: Tue, 1 May 2001 17:22:42 -0700 (PDT) To: "Hesham Soliman \(ERA\)" Cc: "'Vincent Park'" , "'Phil Neumiller'" , Phil Roberts , "'Arthur Ross'" , seamoby@diameter.org Subject: RE: [seamoby] IRTF mm problem statement In-Reply-To: <034BEFD03799D411A59F00508BDF7546013DBDE2@esealnt448.al.sw.ericsson.se> References: <034BEFD03799D411A59F00508BDF7546013DBDE2@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: > > > I think I agree with Phil R. There is a lot going on the wireless space and > > any attempt to custom build IP protocols for wireless sounds to me like the > > wrong path to take... > > > => I think Phil N point was that you do not need to custom > build protocols for specific L2's. Instead abstracting the > common features of these L2s and considering that in the > MM design. Makes sense to me. > What's wrong with that ? The QoS folks have much the same problem and the result was the ISSLL working group. Whether that's appropriate here, I don't know but getting a base level abstraction followed by working on the L2-L3 glue may be a sensible problem partition. Mike From owner-seamoby@diameter.org Tue May 1 20:57:38 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 UAA13330 for ; Tue, 1 May 2001 20:57:36 -0400 (EDT) Received: (qmail 16740 invoked by alias); 2 May 2001 00:46:05 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 16734 invoked by uid 200); 2 May 2001 00:46:05 -0000 Received: (qmail 16729 invoked from network); 2 May 2001 00:46:03 -0000 Received: from unknown (HELO NEPTUNE.zucotto.com) (216.95.209.154) by c900656-a.plstn1.sfba.home.com with SMTP; 2 May 2001 00:46:03 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 May 2001 20:56:04 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B90D2BA6@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Alan O'Neill'" , "'Michael Thomas'" , Phil Roberts Cc: seamoby@diameter.org Subject: RE: [seamoby] IRTF mm problem statement Date: Tue, 1 May 2001 20:56:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk > -----Original Message----- > From: Alan O'Neill [mailto:A.ONeill@flarion.com] > Sent: Tuesday, May 01, 2001 7:57 PM > To: 'Michael Thomas'; Phil Roberts > Cc: seamoby@diameter.org > Subject: RE: [seamoby] IRTF mm problem statement > > > Phil, > > Its a nick pit but we do need to cover the mobile network > equally well in > the draft. We are overly dependent on the host routing term > (with all its > baggage) so maybe mobile enhanced routing would be better ? > > Michael, > > If Phil makes this clear, then I think we can all agree that > we are talking > about a very different problem than is presently solved in > the Internet, > that of support for rapidly changing prefixes (at mobility > rates) where the > prefixes include a large proportion of hosts, and mobile > entities are not > renumbered on movement. > > Its not the whole problem, just a reasonable slice that if > solved brings > community benefits. I agree. Changing prefixes, instead of individual routes needs to be apart of the problem statement. But, also a way for the sender (or sender's AR) to learn the new attachment point of the mobile. Some current solutions assume that mobility is a problem on the mobile side. These solutions see mobility as a problem for the mobile, or ARs near the mobile to solve. Rather mobility should be consider a normal state of the entire network. The both sides of the communication should be able to adjust to the mobility of the other, by changing where packets are sent. There is of course signalling delay involved, but this would get rid of a need for every mobile device to have a 'home' address (ie. Home Agent type entity). And the packet re-direction (wasted bandwidth) involved with having a 'home' entity. A single point of failure (COA) is not needed, if the new route update is propagated up the network to where the new route to the remote device, converges with the old route (most cases). Followed by a removal of the old route by the AR at the convergence point. This can be any number of hops. For where the routes do not converge until they reach the remote device/remote AR, it is the remote device's/remote AR's responsibility to send a route removal message along the old route. Because, this is where the route convergence point is located. With multiple packet flows there will be multiple convergence points. I would call it a Relative Mobility Protocol, because the routes are moved relative to the mobility of the source and destination entities (Mobile Node,Mobile Router,Mobile Network) involved in the communication. With Relative Mobility the each packet takes the least amount of hops physically possible to reach its intended destination. - Kulwinder. > > Alan. > > > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: 02 May 2001 00:11 > To: Phil Roberts > Cc: 'Phil Neumiller'; seamoby@diameter.org > Subject: RE: [seamoby] IRTF mm problem statement > > > Phil Roberts writes: > > I see that in the list from the mm problem statement there > is something > > about discovery of network/link/access point > characteristics, but nothing > > like what you were talking about in the email I responded to. > > > > Re: host routing. The first item does seem to describe > host routing, > > doesn't it? > > > Mobility maintaining the same routable IP address > of a mobile > > > node or mobile network. > > No, because it says mobile network as well. That > implies the ability to push subnets around, not > just host routes. > > Mike > From owner-seamoby@diameter.org Tue May 1 22:10: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 WAA15038 for ; Tue, 1 May 2001 22:10:09 -0400 (EDT) Received: (qmail 18177 invoked by alias); 2 May 2001 01:58:52 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 18171 invoked by uid 200); 2 May 2001 01:58:51 -0000 Received: (qmail 18166 invoked from network); 2 May 2001 01:58:50 -0000 Received: from unknown (HELO megisto-sql1.megisto.com) (63.113.114.132) by c900656-a.plstn1.sfba.home.com with SMTP; 2 May 2001 01:58:50 -0000 Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Tue, 1 May 2001 22:02:17 -0400 Message-ID: From: Phil Roberts To: "'Phil Neumiller'" , seamoby@diameter.org Subject: RE: [seamoby] IRTF mm problem statement Date: Tue, 1 May 2001 22:02:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk OK. I'll keep answering then. You don't seem childish or dense, I just didn't think the thread was going anywhere and have other deliverables elsewhere. > -----Original Message----- > From: Phil Neumiller [mailto:neumiller@telocity.com] > Sent: Tuesday, May 01, 2001 7:51 PM > To: Phil Roberts; seamoby@diameter.org > Subject: Re: [seamoby] IRTF mm problem statement > > > Hello PhilR, > > > Hi Phil, > > > > I see that in the list from the mm problem statement there > is something > > about discovery of network/link/access point > characteristics, but nothing > > like what you were talking about in the email I responded to. > > Can you point out what this is. I can't tell from your > response what you > are talking about specifically. This is the one I had in mind: * How to discover the bandwidth, cost, error rate (and other properties) of candidate Access Links. > > > > > Re: host routing. The first item does seem to describe > host routing, > > doesn't it? > > > Mobility maintaining the same routable IP address > of a mobile > > > node or mobile network. > > No, not to me, at least not from the explanations I have read. When this was discussed with the ADs, this was the item that was converged on as a nonstarter, because of issues of scalability in terms of forwarding table size and propagation of routing updates as in the following two questions from one of the posts in the thread. Hence the idea of sending this to the IRTF for evaluation. > > > Isn't that exactly what you end up with? An entry in the > forwarding table > > of the current router and the previous router for that > mobile's specific > > address which did not change, and a mechanism for > propagating that info? > A). Why do you conclude that there is a route propogation > solution needed > already? > B). There are other possible solutions right? > C). The mobile may very well need to communicate with the newAR long > before a route can be "propogated". > D). Why aren't tunnels discussed as an option? > E). What if that new router is also a mobile node? Hard to comment on all of these. If the criteria is that the mobile keeps the same address as it moves through the network as in this from the original mm problem statement: "Mobility maintaining the same routable IP address of a mobile node or mobile network" then it seems like evaluating the scaling of forwarding table entries and propagation of routing table is at least part of what needs to be investigated. There's certainly more to enabling mobility than this particular problem, but the scope of the work for the IRTF is this I believe. Phil > > Best regards, > > Phil > > > > From owner-seamoby@diameter.org Tue May 1 22:45: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 WAA16421 for ; Tue, 1 May 2001 22:45:04 -0400 (EDT) Received: (qmail 19059 invoked by alias); 2 May 2001 02:33:34 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 19053 invoked by uid 200); 2 May 2001 02:33:34 -0000 Received: (qmail 19048 invoked from network); 2 May 2001 02:33:32 -0000 Received: from c007-h000.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.206) by c900656-a.plstn1.sfba.home.com with SMTP; 2 May 2001 02:33:32 -0000 Received: (cpmta 8420 invoked from network); 1 May 2001 19:43:07 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.206) with SMTP; 1 May 2001 19:43:07 -0700 X-Sent: 2 May 2001 02:43:07 GMT Message-ID: <000701c0d2af$7f4c7200$6401a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Phil Roberts" , References: Subject: Re: [seamoby] IRTF mm problem statement Date: Tue, 1 May 2001 21:27:49 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk Hi Phil, OK I see. I have several comments on this below. ----- Original Message ----- From: "Phil Roberts" To: "'Phil Neumiller'" ; Sent: Tuesday, May 01, 2001 9:02 PM Subject: RE: [seamoby] IRTF mm problem statement > > > > -----Original Message----- > > From: Phil Neumiller [mailto:neumiller@telocity.com] > > Sent: Tuesday, May 01, 2001 7:51 PM > > To: Phil Roberts; seamoby@diameter.org > > Subject: Re: [seamoby] IRTF mm problem statement > > > Re: host routing. The first item does seem to describe > > host routing, > > > doesn't it? > > > > Mobility maintaining the same routable IP address > > of a mobile > > > > node or mobile network. > > > > No, not to me, at least not from the explanations I have read. > > When this was discussed with the ADs, this was the item that was converged > on as a nonstarter, because of issues of scalability in terms of forwarding > table size and propagation of routing updates as in the following two > questions from one of the posts in the thread. Hence the idea of sending > this to the IRTF for evaluation. 1). How can ADs come to convergence withouth WG consensus? 2). I thought the work group convergence and consensus is what matters? 3). All the drafts I have read on this subject do NOT make the "source routing" solution a big point in their drafts? 4). How come the ADs get to decide how to write this problem statement for the IRTF on micro-mobility and not the MIP and SeaMoby WGs???? > > > Isn't that exactly what you end up with? An entry in the > > forwarding table > > > of the current router and the previous router for that > > mobile's specific > > > address which did not change, and a mechanism for > > propagating that info? > > > > A). Why do you conclude that there is a route propogation > > solution needed > > already? > > B). There are other possible solutions right? > > C). The mobile may very well need to communicate with the newAR long > > before a route can be "propogated". > > D). Why aren't tunnels discussed as an option? > > E). What if that new router is also a mobile node? > > Hard to comment on all of these. If the criteria is that the mobile keeps > the same address as it moves through the network as in this from the > original mm problem statement: "Mobility maintaining the same routable IP > address of a mobile node or mobile network" then it seems like evaluating > the scaling of forwarding table entries and propagation of routing table is > at least part of what needs to be investigated. > > There's certainly more to enabling mobility than this particular problem, > but the scope of the work for the IRTF is this I believe. > There certainly is. There is tons of stuff in the drafts that you have referenced and stuff you have not, i.e. list traffic. It seems you are just reacting to AD desires and not WG consensus - and I realize since you are a chair that it is difficult for you to comment on this. For this reason I think chairs should not write drafts and in particular I think you should recuse yourself from this particular draft. I would much prefer a work group created draft to be given to the IRTF. Please thank the ADs for their input Phil. Thanks, Phil Neumiller From owner-seamoby@diameter.org Tue May 1 23:30: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 XAA16838 for ; Tue, 1 May 2001 23:30:22 -0400 (EDT) Received: (qmail 20012 invoked by alias); 2 May 2001 03:19:13 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 20006 invoked by uid 200); 2 May 2001 03:19:13 -0000 Received: (qmail 20001 invoked from network); 2 May 2001 03:19:11 -0000 Received: from unknown (HELO NEPTUNE.zucotto.com) (216.95.209.154) by c900656-a.plstn1.sfba.home.com with SMTP; 2 May 2001 03:19:11 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 May 2001 23:29:15 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B90D2BA9@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Phil Roberts'" , "'Phil Neumiller'" , seamoby@diameter.org Subject: RE: [seamoby] IRTF mm problem statement Date: Tue, 1 May 2001 23:29:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk > -----Original Message----- > From: Phil Roberts [mailto:PRoberts@MEGISTO.com] > Sent: Tuesday, May 01, 2001 10:02 PM > To: 'Phil Neumiller'; seamoby@diameter.org > Subject: RE: [seamoby] IRTF mm problem statement > > > > > > > > > Re: host routing. The first item does seem to describe > > host routing, > > > doesn't it? > > > > Mobility maintaining the same routable IP address > > of a mobile > > > > node or mobile network. > > > > No, not to me, at least not from the explanations I have read. > > When this was discussed with the ADs, this was the item that > was converged > on as a nonstarter, because of issues > of scalability in terms of forwarding table size Forwarding table size is really not that large. 1. Consider that most people travel from home to work on a continous incremental path. (no tele-portation). It becomes a problem localized to approximately a city. Consider that New York City has about 14 million people. A very rough calculation on the upper bound: 14 Megs * 16 bytes (IPv6) = 224 MBytes. We are not talking about moving the entire planet instaneously. > and propagation of routing updates Most routing updates will be from newAR to the oldAR. How long it takes for a highly divergent new route change to propagate up the network is not as important, as long as it is transaction-based at each hop. Routing updates are done today. The trade-off is more memory is used for tables, but bandwidth and computational power is saved that would have been spent on mis-directed packets. I did discuss moving subnets with some of the ADs for Bluetooth. It was Allison Mankin who suggested using IPv6 and subnet prefixes. I didn't hear any ADs object to the idea. You were present if I remember correctly in Minniapolis. - Kulwinder. > as in the following two > questions from one of the posts in the thread. Hence the > idea of sending > this to the IRTF for evaluation. > > > > > Best regards, > > > > Phil > > > > > > > > > From owner-seamoby@diameter.org Wed May 2 02:30: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 CAA02425 for ; Wed, 2 May 2001 02:30:35 -0400 (EDT) Received: (qmail 22706 invoked by alias); 2 May 2001 06:19:36 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 22700 invoked by uid 200); 2 May 2001 06:19:35 -0000 Received: (qmail 22695 invoked from network); 2 May 2001 06:19:33 -0000 Received: from mgw-x2.nokia.com (131.228.20.22) by c900656-a.plstn1.sfba.home.com with SMTP; 2 May 2001 06:19:33 -0000 Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f426TiS09450 for ; Wed, 2 May 2001 09:29:45 +0300 (EET DST) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 2 May 2001 09:29:29 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Wed, 2 May 2001 09:29:29 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680AE26@eseis04nok> From: john.loughney@nokia.com To: neumiller@telocity.com, seamoby@diameter.org Subject: RE: [seamoby] IRTF mm problem statement Date: Wed, 2 May 2001 09:29:26 +0300 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 Phil N., > His arguments about radio physics can be hidden with an OO > like abstraction of putting macro-diversity over IP. That is > the big first step to consider. Do you see this as part of a routing solution, or something handled above IP? This is an important distinction. You have been discussing this since Spring 2000, but if this is something that the IETF should persue, let's get down to it. I think that we need to break the problem in to bite sized chunks or we will go nowhere. IMO, that has been the biggest problem in much of what you have been agitating for. The solution lies below IP, on IP, between IP and above IP. There is no way that we can just solve all of this with one draft, one protocol, one whatever. I do think that this IRTF routing work is an important piece of the puzzel, but I think we should focus on the ROUTING part of the puzzel in this draft. br, John From owner-seamoby@diameter.org Wed May 2 02:33: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 CAA02453 for ; Wed, 2 May 2001 02:33:58 -0400 (EDT) Received: (qmail 23220 invoked by alias); 2 May 2001 06:22:59 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 23214 invoked by uid 200); 2 May 2001 06:22:58 -0000 Received: (qmail 23209 invoked from network); 2 May 2001 06:22:57 -0000 Received: from mgw-x1.nokia.com (131.228.20.21) by c900656-a.plstn1.sfba.home.com with SMTP; 2 May 2001 06:22:57 -0000 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 f426WV208581 for ; Wed, 2 May 2001 09:32:31 +0300 (EET DST) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 2 May 2001 09:32:58 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Wed, 2 May 2001 09:32:58 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680AE27@eseis04nok> From: john.loughney@nokia.com To: PRoberts@MEGISTO.com, seamoby@diameter.org Subject: RE: [seamoby] IRTF mm problem statement Date: Wed, 2 May 2001 09:32:56 +0300 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 Phil R, > I didn't see any of this in the resultant mm problem > statement and it didn't come out in the discussions in Minneapolis. > Did it not get any consensus in the seamoby design teams? As the editor of the draft, I will mention that some of what Phil N. mentioned was discussed, but not in the broad expanse that Phil N. presented it in the previous mail. If there are some concepts in the MM Problem Statement draft that should be highlighted in this problem statement, please show it. Also, this brings up another point. The current SeaMoby MM Problem statement will probably not be re-issued as NOONE seems to care ... best regards, John From owner-seamoby@diameter.org Wed May 2 02:38: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 CAA02470 for ; Wed, 2 May 2001 02:38:57 -0400 (EDT) Received: (qmail 23688 invoked by alias); 2 May 2001 06:27:56 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 23682 invoked by uid 200); 2 May 2001 06:27:56 -0000 Received: (qmail 23677 invoked from network); 2 May 2001 06:27:54 -0000 Received: from mgw-x3.nokia.com (131.228.20.26) by c900656-a.plstn1.sfba.home.com with SMTP; 2 May 2001 06:27:54 -0000 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f426cWH22408 for ; Wed, 2 May 2001 09:38:32 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 2 May 2001 09:37:58 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Wed, 2 May 2001 09:37:58 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680AE28@eseis04nok> From: john.loughney@nokia.com To: A.ONeill@flarion.com Cc: seamoby@diameter.org Subject: RE: [seamoby] IRTF mm problem statement Date: Wed, 2 May 2001 09:37:56 +0300 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 Alan, > Its a nick pit but we do need to cover the mobile network > equally well in the draft. We are overly dependent on the > host routing term (with all its baggage) so maybe mobile > enhanced routing would be better ? Oh no! Let's not get down a 'name that protocol' rathole just yet! (just kidding - but it might be useful to focus on defining the problem than naming it!!!) > If Phil makes this clear, then I think we can all agree that > we are talking about a very different problem than is presently > solved in the Internet, that of support for rapidly changing > prefixes (at mobility rates) where the prefixes include a large > proportion of hosts, and mobile entities are not renumbered on > movement. > > Its not the whole problem, just a reasonable slice that if > solved brings community benefits. Agreed. I'm getting more than a little tired of the 'let's through all of our gripes and see what sticks ...' approach. I think we really need to focus on what is appropriate and where it is appropriate for. Unless someone can suggest improvements to the text, I'd suggest that Phil R. submit the draft. br, John From owner-seamoby@diameter.org Wed May 2 03:01: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 DAA02734 for ; Wed, 2 May 2001 03:01:28 -0400 (EDT) Received: (qmail 24496 invoked by alias); 2 May 2001 06:50:23 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 24490 invoked by uid 200); 2 May 2001 06:50:22 -0000 Received: (qmail 24483 invoked from network); 2 May 2001 06:50:20 -0000 Received: from mgw-x4.nokia.com (131.228.20.27) by c900656-a.plstn1.sfba.home.com with SMTP; 2 May 2001 06:50:20 -0000 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f4271d816456 for ; Wed, 2 May 2001 10:01:39 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 2 May 2001 10:00:23 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Wed, 2 May 2001 10:00:23 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680AE29@eseis04nok> From: john.loughney@nokia.com To: a.ross@ieee.org, seamoby@diameter.org Subject: RE: [seamoby] IRTF mm problem statement Date: Wed, 2 May 2001 10:00:22 +0300 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 Arthur, I'm deleting much text, to get to the point ... > "2.2 Problem Two" > [original text clipped] > "Moreover, in a wireless-connected mobile host environment, routing and > QoS are intimately related to the radio nature of the connection. Effective > management of communication performance involves cooperation and exchange > of information among radio access points. Host-based routing will be more > useful if it supports such communication-engineering aspects of > wireless mobile IP services. [CNP] may be of use in this interaction." Is what you are saying something along these lines: "Devices (mobile/stationary & wireless/wired) may have multiple points of connection to the Internet. These connections may not be static and may change over time. Further more, these connections may suffer from reliability problems. Therefore, any solution should be tolerant to these conditions." Am I getting your gist? > And add the following to the references: > > [CNP] P. Neumiller, "Applying Contract Net Protocol to > Mobile Handover State Transfer, Draft-neumiller-seamoby-cnpmobility-00, > November 17, 2000. I've asked Phil N. several times if this is something he is intending to persue ... I have yet to receive an answer. Perhaps it wouldn't be good to cite it, as Internet Drafts should only be considered 'Works in Progress' and will expire. br, John From owner-seamoby@diameter.org Wed May 2 03:04: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 DAA02747 for ; Wed, 2 May 2001 03:04:50 -0400 (EDT) Received: (qmail 24977 invoked by alias); 2 May 2001 06:53:52 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 24971 invoked by uid 200); 2 May 2001 06:53:52 -0000 Received: (qmail 24966 invoked from network); 2 May 2001 06:53:50 -0000 Received: from mgw-x2.nokia.com (131.228.20.22) by c900656-a.plstn1.sfba.home.com with SMTP; 2 May 2001 06:53:50 -0000 Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f42743S25565 for ; Wed, 2 May 2001 10:04:03 +0300 (EET DST) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 2 May 2001 10:03:52 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Wed, 2 May 2001 10:03:52 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680AE2A@eseis04nok> From: john.loughney@nokia.com To: Hesham.Soliman@era.ericsson.se, seamoby@diameter.org Subject: RE: [seamoby] IRTF mm problem statement Date: Wed, 2 May 2001 10:03:46 +0300 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 think Phil N point was that you do not need to custom > build protocols for specific L2's. Instead abstracting the > common features of these L2s and considering that in the > MM design. Makes sense to me. What's wrong with that ? It makes sense to me, but where are we going to do this? Is this part of an API, routing protocol or signaling protocol. I think the burden of proof is upon those who wish to have it. br, John From owner-seamoby@diameter.org Wed May 2 07:01: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 HAA05389 for ; Wed, 2 May 2001 07:01:47 -0400 (EDT) Received: (qmail 29607 invoked by alias); 2 May 2001 10:50:20 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 29601 invoked by uid 200); 2 May 2001 10:50:20 -0000 Received: (qmail 29596 invoked from network); 2 May 2001 10:50:18 -0000 Received: from c007-h014.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.221) by c900656-a.plstn1.sfba.home.com with SMTP; 2 May 2001 10:50:18 -0000 Received: (cpmta 3578 invoked from network); 2 May 2001 04:00:14 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.221) with SMTP; 2 May 2001 04:00:14 -0700 X-Sent: 2 May 2001 11:00:14 GMT Message-ID: <00a001c0d2f4$129b6180$6401a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: , , References: <01D91AFB08B6D211BFD00008C7EABAE10680AE2A@eseis04nok> Subject: Re: [seamoby] IRTF mm problem statement Date: Wed, 2 May 2001 05:38:48 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk Hi John, I am going to respond to your messages in reverse order. ----- Original Message ----- From: To: ; Sent: Wednesday, May 02, 2001 2:03 AM Subject: RE: [seamoby] IRTF mm problem statement > Hi Hesham, > > > => I think Phil N point was that you do not need to custom > > build protocols for specific L2's. Instead abstracting the > > common features of these L2s and considering that in the > > MM design. Makes sense to me. What's wrong with that ? > > It makes sense to me, but where are we going to do this? Is > this part of an API, routing protocol or signaling protocol. > I think the burden of proof is upon those who wish to have it. There is a new sub-IP work area that has been created in the IETF. This is an area where some of the work can be done. I believe that specifically, sub-IP issues that relate to RF are numerous, and in many cases COMMON to most RF L2s. I believe Kulwinder (Bluetooth BOF co-chair) has come to the conclusion that an abstract triggering mechanism for handoff is desirable. This would be one very good place to start. The IRTF is going to look at micro-mobility, but so far just one "solution" has been proposed to study by the IESG. I think we can write drafts for other unknown issues with respect to mobility and give them to the IRTF. I have stated countless time with absolutely no rebuttal that mobile IP itself is not well understood in the scaling (how local is local mobility), performance (how fast is fast), and interaction with ANY proposed micro-mobility protocol. To me this seems like an important area for the IRTF investigate. Furthermore, whatever micro-mobility will become, it will need to cooperate with both MIP and MANET routing algorithms. It seems of paramount importance to me to understand what this interaction is. If I could draw a Venn diagram in ASCII I would show three areas, MIP, micro-mobility-solution-X, MANET, each with some overlap. What is the overlap? When is using one solution more desirable than another? How does one SWITCH from using one to the using the other? Since, Phil R's appears to be reciting the IESG party line, I think it would behoove the SeaMoby WG to construct a few IRTF recommendation drafts of its own. I am making these arguments to give the SeaMoby workgroup a voice in this process. I think I agree with you John, no-one does SEEM interested? I don't understand why. This is a crucial piece of the WHOLE IP seamless mobility puzzle. Thanks and best regards, Phil Neumiller From owner-seamoby@diameter.org Wed May 2 07:04: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 HAA05410 for ; Wed, 2 May 2001 07:04:17 -0400 (EDT) Received: (qmail 30104 invoked by alias); 2 May 2001 10:53:07 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 30099 invoked by uid 200); 2 May 2001 10:53:06 -0000 Received: (qmail 30094 invoked from network); 2 May 2001 10:53:05 -0000 Received: from c007-h011.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.217) by c900656-a.plstn1.sfba.home.com with SMTP; 2 May 2001 10:53:05 -0000 Received: (cpmta 16306 invoked from network); 2 May 2001 04:02:40 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.217) with SMTP; 2 May 2001 04:02:40 -0700 X-Sent: 2 May 2001 11:02:40 GMT Message-ID: <00ae01c0d2f4$695c8c60$6401a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: , Cc: References: <01D91AFB08B6D211BFD00008C7EABAE10680AE28@eseis04nok> Subject: Re: [seamoby] IRTF mm problem statement Date: Wed, 2 May 2001 05:41:14 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk Hi John, > > Agreed. I'm getting more than a little tired of the 'let's > through all of our gripes and see what sticks ...' > approach. I think we really need to focus on what is appropriate > and where it is appropriate for. Maybe some of the stuff that has stuck already, i.e. stuff that is supported in the draft you edited, could be further refined into additional IRTF recommendation drafts. I could not agree MORE with focusing on what is appropriate and where. I think we are on the same page there. Thanks, Phil From owner-seamoby@diameter.org Wed May 2 09:22:13 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 JAA09745 for ; Wed, 2 May 2001 09:22:12 -0400 (EDT) Received: (qmail 423 invoked by alias); 2 May 2001 13:10:22 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 417 invoked by uid 200); 2 May 2001 13:10:22 -0000 Received: (qmail 410 invoked from network); 2 May 2001 13:10:20 -0000 Received: from unknown (HELO megisto-sql1.megisto.com) (63.113.114.132) by c900656-a.plstn1.sfba.home.com with SMTP; 2 May 2001 13:10:20 -0000 Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Wed, 2 May 2001 09:13:47 -0400 Message-ID: From: Phil Roberts To: seamoby@diameter.org Subject: [seamoby] work that "needs" to get done and where Date: Wed, 2 May 2001 09:13:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk > The IRTF is going to look at micro-mobility, but so far just one > "solution" has been proposed to study by the IESG. I think > we can write drafts for other unknown issues with respect to > mobility and give them to the IRTF. I have stated countless time > with absolutely no rebuttal that mobile IP itself is not well > understood > in the scaling (how local is local mobility), performance > (how fast is fast), > and interaction with ANY proposed micro-mobility protocol. To > me this seems like an important area for the IRTF investigate. > > Furthermore, whatever micro-mobility will become, it will need to > cooperate with both MIP and MANET routing algorithms. It > seems of paramount importance to me to understand what this > interaction is. If I could draw a Venn diagram in ASCII I would > show three areas, MIP, micro-mobility-solution-X, MANET, > each with some overlap. What is the overlap? When is using > one solution more desirable than another? How does one SWITCH > from using one to the using the other? > > Since, Phil R's appears to be reciting the IESG party line, I think it > would behoove the SeaMoby WG to construct a few IRTF recommendation > drafts of its own. I am making these arguments to give the SeaMoby > workgroup a voice in this process. > > I think I agree with you John, no-one does SEEM interested? I don't > understand why. This is a crucial piece of the WHOLE IP seamless > mobility puzzle. > > Thanks and best regards, > > Phil Neumiller At the seamoby meeting in Minneapolis I thought it was pretty clearly explained that there were two activities that needed to be done as a follow-on to the seamoby mm design team. One was to investigate the art formerly known as host routing (mobile hosts and networks not changing their IP address or subnet prefix) and the other a list of requirements for the MIP working group to compare the protocol sets there against. The first was suggested as an IRTF work item because at least in part the routing ADs are concerned about the scalability of such an approach. I took the token to produce a problem statement for that for the IRTF to look into. The second was for the seamoby mm design team to come up with a set of things which they believe an mm protocol MUST do and throw it over to MIP to see whether the set of protocols in MIP can do those things. I haven't seen much activity on this. John sent out an email asking for volunteers recently I believe - don't know whether he got any response. So it seems some useful work could be done on that. I don't recall anyone suggesting that all micromobility work go to the IRTF. That's not to prevent anyone from sending a few work items to someone over there. Phil From owner-seamoby@diameter.org Wed May 2 09:34: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 JAA10223 for ; Wed, 2 May 2001 09:34:36 -0400 (EDT) Received: (qmail 1038 invoked by alias); 2 May 2001 13:22:36 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 1032 invoked by uid 200); 2 May 2001 13:22:35 -0000 Received: (qmail 1026 invoked from network); 2 May 2001 13:22:34 -0000 Received: from unknown (HELO RRMAIL01.RADIOROUTER?NT) (63.103.94.23) by c900656-a.plstn1.sfba.home.com with SMTP; 2 May 2001 13:22:34 -0000 Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2650.21) id <2MX5GA4A>; Wed, 2 May 2001 09:32:06 -0400 Message-ID: From: Vincent Park To: "'Phil Neumiller'" , seamoby@diameter.org Subject: RE: [seamoby] IRTF mm problem statement Date: Wed, 2 May 2001 09:31:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi Phil, Some comments below. > -----Original Message----- > From: Phil Neumiller [mailto:neumiller@telocity.com] > Sent: Wednesday, May 02, 2001 6:39 AM > To: john.loughney@nokia.com; Hesham.Soliman@era.ericsson.se; > seamoby@diameter.org > Subject: Re: [seamoby] IRTF mm problem statement > > > Hi John, > > I am going to respond to your messages in reverse order. > > ----- Original Message ----- > From: > To: ; > Sent: Wednesday, May 02, 2001 2:03 AM > Subject: RE: [seamoby] IRTF mm problem statement > > > > Hi Hesham, > > > > > => I think Phil N point was that you do not need to custom > > > build protocols for specific L2's. Instead abstracting the > > > common features of these L2s and considering that in the > > > MM design. Makes sense to me. What's wrong with that ? > > > > It makes sense to me, but where are we going to do this? Is > > this part of an API, routing protocol or signaling protocol. > > I think the burden of proof is upon those who wish to have it. > > There is a new sub-IP work area that has been created in the IETF. > This is an area where some of the work can be done. I believe that > specifically, sub-IP issues that relate to RF are numerous, and in > many cases COMMON to most RF L2s. I believe Kulwinder > (Bluetooth BOF co-chair) has come to the conclusion that an abstract > triggering mechanism for handoff is desirable. This would be one > very good place to start. I don't disagree with the importance of this work. Potential standardization of a radio API has been discussed repeatedly within the manet WG. Several years back a presention of the radio API developed under the DARPA GloMo project was even presented at one of the WG meeting. However, I think that most the worker bees in manet we should work on the routing protocols first and then worry about possibly enhancing them with link layer metrics. So in short I don't think that the IRTF routing research group should take on this work now. Addressing it in another group (as you suggest above) seems reasonable. > > The IRTF is going to look at micro-mobility, but so far just one > "solution" has been proposed to study by the IESG. I think > we can write drafts for other unknown issues with respect to > mobility and give them to the IRTF. I have stated countless time > with absolutely no rebuttal that mobile IP itself is not well > understood > in the scaling (how local is local mobility), performance > (how fast is fast), > and interaction with ANY proposed micro-mobility protocol. To > me this seems like an important area for the IRTF investigate. > I think that you are being a little overly critical here. I think that the problem statement that PhilR put out does not try to limit the scope of possible solutions. It does point out the common tread of host specific routes that exists in many of the proposed solutions. Additionaly, I think that it fairly suggest comparison with MIP and other existing protocols is needed. Quote from the draft: "A comparison with OSPF and Mobile IP are involved in making such an assessment both in terms of relative scalability, performance, and complexity." > Furthermore, whatever micro-mobility will become, it will need to > cooperate with both MIP and MANET routing algorithms. It > seems of paramount importance to me to understand what this > interaction is. If I could draw a Venn diagram in ASCII I would > show three areas, MIP, micro-mobility-solution-X, MANET, > each with some overlap. What is the overlap? When is using > one solution more desirable than another? How does one SWITCH > from using one to the using the other? Here I basically agree with you again, but I don't know if it is necessary to put these things in the draft. If you think so, I would suggest that you offer some text to PhilR. My belief is that the draft should be breif, and is simply intended to broadly outline the problem and provide some motivation. I would hope that once the group starts working on the problem it will adapt as necessary to come to a good solution. Maybe I have too much faith in people's ability to come to a good solution regardless of their starting point. > Since, Phil R's appears to be reciting the IESG party line, I think it > would behoove the SeaMoby WG to construct a few IRTF recommendation > drafts of its own. I am making these arguments to give the SeaMoby > workgroup a voice in this process. I think that PhilR sent this to the seamoby list to get input from the group. :) Thanks, Vince Park > > I think I agree with you John, no-one does SEEM interested? I don't > understand why. This is a crucial piece of the WHOLE IP seamless > mobility puzzle. > > Thanks and best regards, > > Phil Neumiller > > > > > From owner-seamoby@diameter.org Wed May 2 10:10: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 KAA11929 for ; Wed, 2 May 2001 10:10:14 -0400 (EDT) Received: (qmail 2178 invoked by alias); 2 May 2001 13:58:40 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2172 invoked by uid 200); 2 May 2001 13:58:39 -0000 Received: (qmail 2165 invoked by uid 500); 2 May 2001 13:58:38 -0000 Date: Wed, 2 May 2001 06:58:38 -0700 From: Pat Calhoun To: Phil Neumiller Cc: Phil Roberts , seamoby@diameter.org Subject: Re: [seamoby] IRTF mm problem statement Message-ID: <20010502065837.L4672@charizard.diameter.org> Mail-Followup-To: Phil Neumiller , Phil Roberts , seamoby@diameter.org References: <000701c0d2af$7f4c7200$6401a8c0@philneum> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000701c0d2af$7f4c7200$6401a8c0@philneum>; from neumiller@telocity.com on Tue, May 01, 2001 at 09:27:49PM -0500 Sender: owner-seamoby@diameter.org Precedence: bulk Well, here we go again.... :( On Tue, May 01, 2001 at 09:27:49PM -0500, Phil Neumiller wrote: > 1). How can ADs come to convergence withouth WG consensus? Well, the draft put together by Phil was the output of the MM work. I participated in some of the conference calls, and host based routing protocols was mentioned on many occasions. Now, some of you seem to want to discuss other methods, and that's fine, but the result of the MM work was in fact a host-based approach. Dana, the MM DT lead, participated in the Minn meeting (as did Phil R and the MIP WG co-chair), and Dana discussed the various ideas in the MM space, all of which are in the problem statement. The biggest one of concern to the IESG was a new protocol based on host routes, because of its possible scaling problems. So the IRTF chair stated that they would be interested in looking at *this* problem space. If the problem space has changed since the ID was put out, then take it to the IRTF. We are done here. So, let's be a little easier on PhilR here, please. He is ONLY communicating what the rest of you spoke about during the various conference calls, and agreed to have in the problem statement. I realize that the problem statement also includes other problem areas, and I believe that we are handling each one of the them, but in a different way. > 2). I thought the work group convergence and consensus is what matters? The DT agreed on the MM problem statement. > 3). All the drafts I have read on this subject do NOT make the "source routing" > solution a big point in their drafts? what "drafts"? The only one that really matters here PhilN is the MM problem statement. > 4). How come the ADs get to decide how to write this problem statement for > the IRTF on micro-mobility and not the MIP and SeaMoby WGs???? Not the ADs, the DT did. > > > > There's certainly more to enabling mobility than this particular problem, > > but the scope of the work for the IRTF is this I believe. > > > > There certainly is. There is tons of stuff in the drafts that you have referenced > and stuff you have not, i.e. list traffic. Here you are correct. Lots of stuff have happened in the list since the draft was sent out. And I believe that the place where this will be discussed is in the IRTF. However, I am not sure that it would be correct for PhilR to interpret mailing list threads, and assume that there is concensus. So, what he has done is taken data from the MM problem statement, and assume that people will contribute to the IRTF process, and provide their input. Again, if you have specific text to change/add/delete, then propose it. But if it is to propose an approach, let's have those discussions in the IRTF. > It seems you are just reacting to > AD desires and not WG consensus - and I realize since you are a chair that > it is difficult for you to comment on this. For this reason I think chairs should > not write drafts and in particular I think you should recuse yourself from this > particular draft. I would much prefer a work group created draft to be given > to the IRTF. Please thank the ADs for their input Phil. sigh. [ignoring the unsolicited accusations] Again, please see above. PhilR simply took stuff from the MM problem statement. The draft he has put together includes what was discussed in Minn. between the chairs, ADs, IRTF and MM DT team lead. PatC From owner-seamoby@diameter.org Wed May 2 10:17: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 KAA12282 for ; Wed, 2 May 2001 10:17:23 -0400 (EDT) Received: (qmail 2874 invoked by alias); 2 May 2001 14:06:16 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2868 invoked by uid 200); 2 May 2001 14:06:16 -0000 Received: (qmail 2862 invoked by uid 500); 2 May 2001 14:06:14 -0000 Date: Wed, 2 May 2001 07:06:14 -0700 From: Pat Calhoun To: Phil Roberts Cc: seamoby@diameter.org Subject: Re: [seamoby] work that "needs" to get done and where Message-ID: <20010502070614.M4672@charizard.diameter.org> Mail-Followup-To: Phil Roberts , seamoby@diameter.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from PRoberts@MEGISTO.com on Wed, May 02, 2001 at 09:13:46AM -0400 Sender: owner-seamoby@diameter.org Precedence: bulk On Wed, May 02, 2001 at 09:13:46AM -0400, Phil Roberts wrote: > At the seamoby meeting in Minneapolis I thought it was pretty clearly > explained that there were two activities that needed to be done as a > follow-on to the seamoby mm design team. One was to investigate the art > formerly known as host routing (mobile hosts and networks not changing their > IP address or subnet prefix) and the other a list of requirements for the > MIP working group to compare the protocol sets there against. The first was > suggested as an IRTF work item because at least in part the routing ADs are > concerned about the scalability of such an approach. I took the token to > produce a problem statement for that for the IRTF to look into. This is correct. > I don't recall anyone suggesting that all micromobility work go to the IRTF. > That's not to prevent anyone from sending a few work items to someone over > there. Correct. If people want to do this, then they are free to contact the IRTF routing chair to start this activity. However, as Phil mentions, the proposal from seamoby was constrained to the discussions in the MM conference calls, and portions of the resulting MM problem statement. PatC From owner-seamoby@diameter.org Wed May 2 10: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 KAA12377 for ; Wed, 2 May 2001 10:21:17 -0400 (EDT) Received: (qmail 3458 invoked by alias); 2 May 2001 14:10:09 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 3452 invoked by uid 200); 2 May 2001 14:10:08 -0000 Received: (qmail 3444 invoked from network); 2 May 2001 14:10:07 -0000 Received: from c007-h011.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.217) by c900656-a.plstn1.sfba.home.com with SMTP; 2 May 2001 14:10:07 -0000 Received: (cpmta 2572 invoked from network); 2 May 2001 07:19:42 -0700 Received: from unknown (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.217) with SMTP; 2 May 2001 07:19:42 -0700 X-Sent: 2 May 2001 14:19:42 GMT Message-ID: <009e01c0d30f$c7da0c20$6401a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Pat Calhoun" Cc: "Phil Roberts" , References: <000701c0d2af$7f4c7200$6401a8c0@philneum> <20010502065837.L4672@charizard.diameter.org> Subject: Re: [seamoby] IRTF mm problem statement Date: Wed, 2 May 2001 08:57:02 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk Hello Pat, I did work hard in this space since it is of extreme interest to me. Please take another look at SeaMoby MM problem statement. Host routes are not mentioned in ANY spot as a recommended solution. I see this as an IESG/AD interpretation or reading between the lines. As for the other drafts I mentioned they are all listed in Phil Rs draft. ----- Original Message ----- From: "Pat Calhoun" > On Tue, May 01, 2001 at 09:27:49PM -0500, Phil Neumiller wrote: > > 1). How can ADs come to convergence withouth WG consensus? > > Well, the draft put together by Phil was the output of the MM work. I > participated in some of the conference calls, and host based routing > protocols was mentioned on many occasions. Yes, I participated in them too. Host based routing is not mentioned in the draft!!! > Dana, the MM DT lead, participated in the Minn meeting (as did Phil R and > the MIP WG co-chair), and Dana discussed the various ideas in the MM > space, all of which are in the problem statement. The biggest one of > concern to the IESG was a new protocol based on host routes, because of > its possible scaling problems. So the IRTF chair stated that they would > be interested in looking at *this* problem space. If the problem space > has changed since the ID was put out, then take it to the IRTF. We are > done here. OK so the TRUTH of the matter is that the IRTF decided apriori that they were interested in a host based routes solution. I can live with that. I just like honesty in advertising, that's all. Thanks, Phil From owner-seamoby@diameter.org Wed May 2 10:27: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 KAA12548 for ; Wed, 2 May 2001 10:27:04 -0400 (EDT) Received: (qmail 4101 invoked by alias); 2 May 2001 14:15:59 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 4095 invoked by uid 200); 2 May 2001 14:15:59 -0000 Received: (qmail 4085 invoked by uid 500); 2 May 2001 14:15:57 -0000 Date: Wed, 2 May 2001 07:15:57 -0700 From: Pat Calhoun To: Phil Neumiller Cc: Pat Calhoun , Phil Roberts , seamoby@diameter.org Subject: Re: [seamoby] IRTF mm problem statement Message-ID: <20010502071557.Q4672@charizard.diameter.org> Mail-Followup-To: Phil Neumiller , Pat Calhoun , Phil Roberts , seamoby@diameter.org References: <000701c0d2af$7f4c7200$6401a8c0@philneum> <20010502065837.L4672@charizard.diameter.org> <009e01c0d30f$c7da0c20$6401a8c0@philneum> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <009e01c0d30f$c7da0c20$6401a8c0@philneum>; from neumiller@telocity.com on Wed, May 02, 2001 at 08:57:02AM -0500 Sender: owner-seamoby@diameter.org Precedence: bulk On Wed, May 02, 2001 at 08:57:02AM -0500, Phil Neumiller wrote: > Hello Pat, > > I did work hard in this space since it is of extreme interest to me. that I do know, and thank you for it. > Please take another look at SeaMoby MM problem statement. perhaps I should... it's been a while :) > Host routes are not mentioned in ANY spot as a recommended > solution. I see this as an IESG/AD interpretation or reading > between the lines. As for the other drafts I mentioned they are > all listed in Phil Rs draft. ok, perhaps, and also mis-interpreted by Dana and Phil R :( Host based routes was in fact what was communicated by Dana to the IRTF chair. > OK so the TRUTH of the matter is that the IRTF decided apriori that they > were interested in a host based routes solution. No, that's what they were told. PatC From owner-seamoby@diameter.org Wed May 2 10:34: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 KAA12803 for ; Wed, 2 May 2001 10:34:17 -0400 (EDT) Received: (qmail 4980 invoked by alias); 2 May 2001 14:23:00 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 4974 invoked by uid 200); 2 May 2001 14:23:00 -0000 Received: (qmail 4963 invoked from network); 2 May 2001 14:22:58 -0000 Received: from c007-h015.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.222) by c900656-a.plstn1.sfba.home.com with SMTP; 2 May 2001 14:22:58 -0000 Received: (cpmta 16347 invoked from network); 2 May 2001 07:32:32 -0700 Received: from unknown (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.222) with SMTP; 2 May 2001 07:32:32 -0700 X-Sent: 2 May 2001 14:32:32 GMT Message-ID: <00b701c0d311$8ca67d80$6401a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Pat Calhoun" Cc: "Pat Calhoun" , "Phil Roberts" , References: <000701c0d2af$7f4c7200$6401a8c0@philneum> <20010502065837.L4672@charizard.diameter.org> <009e01c0d30f$c7da0c20$6401a8c0@philneum> <20010502071557.Q4672@charizard.diameter.org> Subject: Re: [seamoby] IRTF mm problem statement Date: Wed, 2 May 2001 09:09:42 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk I want to apologize to PhilR for being a pain, I didn't mean to shoot the messenger. I THOUGHT this was an attempt to go around the WG by the IESG or the IRTF. As it turns out it was Dana's Phil R's interpretation of the draft (s) as explained to the IRTF. I can live with this, I am glad that the truth of the matter is out. For the record, I do believe OTHER "solutions" were discussed AND I believe there are OTHER issues that warrant investigation as I have tried to explain in the VERY long (too long) of a thread. I am dormant on this now, and appreciate you explaining this Pat. I welcome other SeaMoby WG members to comment. I will not complain about this any more. Thanks, Phil ----- Original Message ----- From: "Pat Calhoun" To: "Phil Neumiller" Cc: "Pat Calhoun" ; "Phil Roberts" ; Sent: Wednesday, May 02, 2001 9:15 AM Subject: Re: [seamoby] IRTF mm problem statement > On Wed, May 02, 2001 at 08:57:02AM -0500, Phil Neumiller wrote: > > Hello Pat, > > > > I did work hard in this space since it is of extreme interest to me. > > that I do know, and thank you for it. > > > Please take another look at SeaMoby MM problem statement. > > perhaps I should... it's been a while :) > > > Host routes are not mentioned in ANY spot as a recommended > > solution. I see this as an IESG/AD interpretation or reading > > between the lines. As for the other drafts I mentioned they are > > all listed in Phil Rs draft. > > ok, perhaps, and also mis-interpreted by Dana and Phil R :( Host > based routes was in fact what was communicated by Dana to the IRTF > chair. > > > OK so the TRUTH of the matter is that the IRTF decided apriori that they > > were interested in a host based routes solution. > > No, that's what they were told. > > PatC > From owner-seamoby@diameter.org Wed May 2 10:36: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 KAA12871 for ; Wed, 2 May 2001 10:36:16 -0400 (EDT) Received: (qmail 5357 invoked by alias); 2 May 2001 14:24:42 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 5349 invoked by uid 200); 2 May 2001 14:24:41 -0000 Received: (qmail 5331 invoked by uid 500); 2 May 2001 14:24:38 -0000 Date: Wed, 2 May 2001 07:24:38 -0700 From: Pat Calhoun To: Phil Neumiller Cc: Pat Calhoun , Phil Roberts , seamoby@diameter.org Subject: Re: [seamoby] IRTF mm problem statement Message-ID: <20010502072438.S4672@charizard.diameter.org> Mail-Followup-To: Phil Neumiller , Pat Calhoun , Phil Roberts , seamoby@diameter.org References: <000701c0d2af$7f4c7200$6401a8c0@philneum> <20010502065837.L4672@charizard.diameter.org> <009e01c0d30f$c7da0c20$6401a8c0@philneum> <20010502071557.Q4672@charizard.diameter.org> <00b701c0d311$8ca67d80$6401a8c0@philneum> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <00b701c0d311$8ca67d80$6401a8c0@philneum>; from neumiller@telocity.com on Wed, May 02, 2001 at 09:09:42AM -0500 Sender: owner-seamoby@diameter.org Precedence: bulk On Wed, May 02, 2001 at 09:09:42AM -0500, Phil Neumiller wrote: > For the record, I do believe OTHER "solutions" were discussed AND > I believe there are OTHER issues that warrant investigation as I have > tried to explain in the VERY long (too long) of a thread. and these other solutions can, and should, be discussed in the IRTF, once the research activity has begun. Thanks, PatC From owner-seamoby@diameter.org Wed May 2 12:13: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 MAA16000 for ; Wed, 2 May 2001 12:13:48 -0400 (EDT) Received: (qmail 9006 invoked by alias); 2 May 2001 16:02:40 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 9000 invoked by uid 200); 2 May 2001 16:02:39 -0000 Received: (qmail 8995 invoked from network); 2 May 2001 16:02:38 -0000 Received: from unknown (HELO megisto-sql1.megisto.com) (63.113.114.132) by c900656-a.plstn1.sfba.home.com with SMTP; 2 May 2001 16:02:38 -0000 Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Wed, 2 May 2001 12:06:04 -0400 Message-ID: From: Phil Roberts To: "'Michael Thomas'" Cc: seamoby@diameter.org Subject: RE: [seamoby] IRTF mm problem statement Date: Wed, 2 May 2001 12:06:02 -0400 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 > > OK so the TRUTH of the matter is that the IRTF decided > apriori that they > > were interested in a host based routes solution. I can > live with that. I just > > like honesty in advertising, that's all. > > Huh? Now I'm really confused. The problem isn't > host routes, per se -- they're just the pathological > case. The scaling problem is when you try to propogate > those small prefixes outside of some contained area, > usually an AS. My take on the MM stuff is that > the interesting part of this is allowing mobile > hosts and mobile routers to treat their > mobility like normal routing topology changes > within an AS. > > I sure hope that what Pat said is not true > because focusing *only* on host routes fundamentally > misses the point, and certainly wasn't the > sentiment of the MM problem statement. You've got a real opportunity to make sure a mistake isn't made right now. Have you got any suggested wording updates in the draft to be sent to the IRTF? Phil > > Mike > From owner-seamoby@diameter.org Wed May 2 12:16:01 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 MAA16046 for ; Wed, 2 May 2001 12:16:00 -0400 (EDT) Received: (qmail 9227 invoked by alias); 2 May 2001 16:03:32 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 9219 invoked by uid 200); 2 May 2001 16:03:31 -0000 Received: (qmail 9204 invoked from network); 2 May 2001 16:03:28 -0000 Received: from out4.prserv.net (HELO prserv.net) (32.97.166.34) by c900656-a.plstn1.sfba.home.com with SMTP; 2 May 2001 16:03:28 -0000 Received: from [32.101.227.100] (slip-32-101-227-100.ca.us.prserv.net[32.101.227.100]) by prserv.net (out4) with ESMTP id <2001050216133320405basn1e>; Wed, 2 May 2001 16:13:33 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: ahmrphd@pop3.attglobal.net (Unverified) Message-Id: In-Reply-To: <01D91AFB08B6D211BFD00008C7EABAE10680AE29@eseis04nok> Date: Wed, 2 May 2001 09:13:15 -0700 To: john.loughney@nokia.com, seamoby@diameter.org From: Arthur Ross Subject: RE: [seamoby] IRTF mm problem statement Sender: owner-seamoby@diameter.org Precedence: bulk At 0:00 -0700 05/02/2001, john.loughney@nokia.com wrote: >Hi Arthur, > [snip] > >Is what you are saying something along these lines: > >"Devices (mobile/stationary & wireless/wired) may have multiple points of >connection to the Internet. These connections may not be static and may >change over time. Further more, these connections may suffer from >reliability problems. Therefore, any solution should be tolerant to >these conditions." > >Am I getting your gist? > Close. Although my intent was to suggest not only that the protocol should be TOLERANT of not-wholely reliablble links, but that there may be mechanisms, perhaps not addressed in this particular IRTF project, that may proactively MANAGE and ENHANCE link performance through, e.g., macro-diversity, or even micro-diversity, among other things. The solution should be cognizant of those potential mechanisms, and supportive of them where necessary. For example, if indeed it evolves that there is a network entity that serves that combiner-distributor function, then that device might be the endpoint (CoA), as seen by the routing protocols, with some other mechanism for connection to the actual radio transceiver(s). Or maybe both sides are part of it. There is a question of the network architecture abstractions here too. ... putting on the ol' ahmr English teacher wannabe hat ... and noting the spec-ese language nuance of the difference between "may" in the sense of "it is permissible to ..." versus "it may transpire in the future that ..." or "it is physically possible that ..." .... how about something like: "Devices (mobile/stationary & wireless/wired) can have multiple points of connection to the Internet. Those connections in general will not be static and will change over time. Furthermore, network-supported mechanisms for communication link performance managment and enhancement may become available in the future. The solution should support that multiple connectivity and those mechanisms, if and when they become available." >> And add the following to the references: >> >> [CNP] P. Neumiller, "Applying Contract Net Protocol to >> Mobile Handover State Transfer, Draft-neumiller-seamoby-cnpmobility-00, >> November 17, 2000. > >I've asked Phil N. several times if this is something he is >intending to persue ... I have yet to receive an answer. Perhaps >it wouldn't be good to cite it, as Internet Drafts should only >be considered 'Works in Progress' and will expire. > Indeed, take it up with Phil. I have no problem one way or the other. While I still think it's a good concept, it is not essential to the central issue. -- ahmr From owner-seamoby@diameter.org Wed May 2 12:30: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 MAA16440 for ; Wed, 2 May 2001 12:30:35 -0400 (EDT) Received: (qmail 8465 invoked by alias); 2 May 2001 15:58:31 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8459 invoked by uid 200); 2 May 2001 15:58:31 -0000 Received: (qmail 8451 invoked from network); 2 May 2001 15:58:28 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by c900656-a.plstn1.sfba.home.com with SMTP; 2 May 2001 15:58:28 -0000 Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f42G84j01650; Wed, 2 May 2001 09:08:04 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AFA08663; Wed, 2 May 2001 09:08:03 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA13917; Wed, 2 May 2001 09:08:03 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15088.12515.182606.333322@thomasm-u1.cisco.com> Date: Wed, 2 May 2001 09:08:03 -0700 (PDT) To: "Phil Neumiller" Cc: "Pat Calhoun" , "Phil Roberts" , Subject: Re: [seamoby] IRTF mm problem statement In-Reply-To: <009e01c0d30f$c7da0c20$6401a8c0@philneum> References: <000701c0d2af$7f4c7200$6401a8c0@philneum> <20010502065837.L4672@charizard.diameter.org> <009e01c0d30f$c7da0c20$6401a8c0@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: > Hello Pat, > > I did work hard in this space since it is of extreme interest to me. > Please take another look at SeaMoby MM problem statement. > Host routes are not mentioned in ANY spot as a recommended > solution. I see this as an IESG/AD interpretation or reading > between the lines. As for the other drafts I mentioned they are > all listed in Phil Rs draft. > > ----- Original Message ----- > From: "Pat Calhoun" > > On Tue, May 01, 2001 at 09:27:49PM -0500, Phil Neumiller wrote: > > > 1). How can ADs come to convergence withouth WG consensus? > > > > Well, the draft put together by Phil was the output of the MM work. I > > participated in some of the conference calls, and host based routing > > protocols was mentioned on many occasions. > > Yes, I participated in them too. Host based routing is not mentioned in > the draft!!! Correct. The use of "host routes" was an unfortunate short hand for "small subnets that we knew wouldn't scale across AS's, but that's OK because MIP will take care of that level of mobility." > > Dana, the MM DT lead, participated in the Minn meeting (as did Phil R and > > the MIP WG co-chair), and Dana discussed the various ideas in the MM > > space, all of which are in the problem statement. The biggest one of > > concern to the IESG was a new protocol based on host routes, because of > > its possible scaling problems. So the IRTF chair stated that they would > > be interested in looking at *this* problem space. If the problem space > > has changed since the ID was put out, then take it to the IRTF. We are > > done here. > > OK so the TRUTH of the matter is that the IRTF decided apriori that they > were interested in a host based routes solution. I can live with that. I just > like honesty in advertising, that's all. Huh? Now I'm really confused. The problem isn't host routes, per se -- they're just the pathological case. The scaling problem is when you try to propogate those small prefixes outside of some contained area, usually an AS. My take on the MM stuff is that the interesting part of this is allowing mobile hosts and mobile routers to treat their mobility like normal routing topology changes within an AS. I sure hope that what Pat said is not true because focusing *only* on host routes fundamentally misses the point, and certainly wasn't the sentiment of the MM problem statement. Mike From owner-seamoby@diameter.org Wed May 2 16:36: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 QAA22721 for ; Wed, 2 May 2001 16:36:10 -0400 (EDT) Received: (qmail 15425 invoked by alias); 2 May 2001 20:23:44 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 15418 invoked by uid 200); 2 May 2001 20:23:43 -0000 Received: (qmail 15404 invoked from network); 2 May 2001 20:23:40 -0000 Received: from sj-msg-core-4.cisco.com (171.71.163.10) by c900656-a.plstn1.sfba.home.com with SMTP; 2 May 2001 20:23:40 -0000 Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f42KXMd28815 for ; Wed, 2 May 2001 13:33:22 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AFB05448; Wed, 2 May 2001 13:33:16 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA13951; Wed, 2 May 2001 13:33:16 -0700 (PDT) Date: Wed, 2 May 2001 13:33:16 -0700 (PDT) Message-Id: <200105022033.NAA13951@thomasm-u1.cisco.com> From: Michael Thomas To: seamoby@diameter.org Subject: [seamoby] suggestions for MM IRTF statement 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 PhilR, As promised, here are my suggestions. Abstract: o replace "new routing protocol" with "a routing protocol" which leaves the door open to tweaks on old or in development protocols o replace mobile host with mobile node so as to encompass hosts and routers. o we need to emphasize that the property that we keep the same routable address within a limited scope. How about: "...to implement a routing protocol whose purpose is to allow a mobile node to retain connectivity via its current IP subnet while it moves within the scope of the micro mobility domain. In general this domain is expected to be contained within an autonomous system so that global aggregation of subnets is still preserved. An additional benefit of the protocols is that mobile nodes may more quickly react to failed links..." Introduction: o use "stationary" instead of "static" o replace "host routing" with "a protocol which allows the mobile node to keep its current IP subnet when it attaches to a new access router." o I'd say it's not the routing protocols, but the routers in the last sentence of paragraph 1. o p2: I'd replace "the use of host routing ..." with: "how a local subnet mobility routing protocol can be employed to enable mobility and fast network recovery." Problem Statement: o Replace first sentence with "Why is there a perceived need for a non-tunnel based routing based solution for mobility?" o I might start this with "The current Internet has a high expectation that nodes are stationary. While Mobile IP goes to some length to hide the mobility from the end system communicating to the mobile network, it uses tunnels which are not necessarily transparent to routers in the tunnel path. This in turn causes services which are provided by those routers, such as quality of service guarantees, to be impacted by the mobility. However, mobility in many respects can be viewed as just a change in topology for the impacted subnets -- a property with which routers are well acquainted. Thus, it would be desirable to have a means of providing mobility which leveraged routers inherent ability to deal with topology changes, even if they do not scale to a global scope as mobile IP does. Another other property we would like to take as fully advantage of as possible is local convergence. That is, if changes can be isolated within a small region -- namely close to the mobile node's points of attachment, we can avoid potentially costly signaling of all of the elements currently sharing state with the host or hosts on the mobile network." -- last part probably needs to be combined better with what you have on the signaling overhead o I'd replace OSPF with intradomain routing protocols. May want to mention MANET in there too. o Replace "implements host routes" with "local subnet mobility routing protocol..." 2.2: o Replace last sentence: "Could a local subnet mobility routing protocol aid in this respect?" 2.3: o Replace "scale of host routing..." with "scale of local subnet mobility routing" o Qualify need, as in "the potential need" o Replace "OSPF" with "intradomain routing protocols, MANET protocols, as well as Mobile IP" Mike From owner-seamoby@diameter.org Wed May 2 17:51: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 RAA24523 for ; Wed, 2 May 2001 17:51:02 -0400 (EDT) Received: (qmail 18023 invoked by alias); 2 May 2001 21:39:31 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 18017 invoked by uid 200); 2 May 2001 21:39:31 -0000 Received: (qmail 18012 invoked from network); 2 May 2001 21:39:29 -0000 Received: from unknown (HELO megisto-sql1.megisto.com) (63.113.114.132) by c900656-a.plstn1.sfba.home.com with SMTP; 2 May 2001 21:39:29 -0000 Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Wed, 2 May 2001 17:42:57 -0400 Message-ID: From: Phil Roberts To: seamoby@diameter.org Subject: RE: [seamoby] suggestions for MM IRTF statement Date: Wed, 2 May 2001 17:42:55 -0400 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 Mike, thanks for your comments. They are all good and I've incorporated almost all of them in the doc with a little wordsmithing in places to make it flow well. I have questions about this one: > o I might start this with "The current Internet > has a high expectation that nodes are > stationary. While Mobile IP goes to some > length to hide the mobility from the end > system communicating to the mobile network, > it uses tunnels which are not necessarily > transparent to routers in the tunnel path. > This in turn causes services which are > provided by those routers, such as quality > of service guarantees, to be impacted by > the mobility. Up to this point I have the following question. You say which *are not* necessarily transparent to routers. Do you mean to say that *are* necessarily transparent to routers? Presumably if there are foreign agents involved or mobile aware access routers for v6 they can and will handle QoS characteristics for themselves and between themselves and the mobile, but the next router or two up the chain doesn't see the mobility and can't really deal with the fact that the flow has moved. Just trying to understand what you're after here. > However, mobility in many > respects can be viewed as just a change in topology for the > impacted subnets -- a property with which routers > are well acquainted. Thus, it would be > desirable to have a means of providing > mobility which leveraged routers inherent > ability to deal with topology changes, even > if they do not scale to a global scope as > mobile IP does. Another other property we would > like to take as fully advantage of as possible > is local convergence. That is, if changes can > be isolated within a small region -- namely > close to the mobile node's points of > attachment, we can avoid potentially costly > signaling of all of the elements currently > sharing state with the host or hosts on the > mobile network." > > Phil From owner-seamoby@diameter.org Wed May 2 17:57: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 RAA24804 for ; Wed, 2 May 2001 17:57:19 -0400 (EDT) Received: (qmail 18631 invoked by alias); 2 May 2001 21:44:35 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 18625 invoked by uid 200); 2 May 2001 21:44:35 -0000 Received: (qmail 18616 invoked from network); 2 May 2001 21:44:33 -0000 Received: from c007-h000.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.206) by c900656-a.plstn1.sfba.home.com with SMTP; 2 May 2001 21:44:33 -0000 Received: (cpmta 24684 invoked from network); 2 May 2001 14:54:31 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.206) with SMTP; 2 May 2001 14:54:31 -0700 X-Sent: 2 May 2001 21:54:31 GMT Message-ID: <03ef01c0d34e$b021f860$6401a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Michael Thomas" , References: <200105022033.NAA13951@thomasm-u1.cisco.com> Subject: Re: [seamoby] suggestions for MM IRTF statement Date: Wed, 2 May 2001 16:27:21 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk I really like Mike's changes (for my two cents worth)! From owner-seamoby@diameter.org Wed May 2 18: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 SAA25036 for ; Wed, 2 May 2001 18:08:15 -0400 (EDT) Received: (qmail 19441 invoked by alias); 2 May 2001 21:57:08 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 19434 invoked by uid 200); 2 May 2001 21:57:07 -0000 Received: (qmail 19427 invoked by uid 500); 2 May 2001 21:57:06 -0000 Date: Wed, 2 May 2001 14:57:06 -0700 From: Pat Calhoun To: Phil Neumiller Cc: Michael Thomas , seamoby@diameter.org Subject: Re: [seamoby] suggestions for MM IRTF statement Message-ID: <20010502145705.K4672@charizard.diameter.org> Mail-Followup-To: Phil Neumiller , Michael Thomas , seamoby@diameter.org References: <200105022033.NAA13951@thomasm-u1.cisco.com> <03ef01c0d34e$b021f860$6401a8c0@philneum> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <03ef01c0d34e$b021f860$6401a8c0@philneum>; from neumiller@telocity.com on Wed, May 02, 2001 at 04:27:21PM -0500 Sender: owner-seamoby@diameter.org Precedence: bulk On Wed, May 02, 2001 at 04:27:21PM -0500, Phil Neumiller wrote: > I really like Mike's changes (for my two cents worth)! I admit that it was very nice to have a list of concrete changes to make to the I-D. This way, you don't have to interpret meanings. Thanks Mike! PatC From owner-seamoby@diameter.org Wed May 2 19:00: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 TAA25833 for ; Wed, 2 May 2001 19:00:19 -0400 (EDT) Received: (qmail 21588 invoked by alias); 2 May 2001 22:48:51 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 21582 invoked by uid 200); 2 May 2001 22:48:51 -0000 Received: (qmail 21577 invoked from network); 2 May 2001 22:48:49 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by c900656-a.plstn1.sfba.home.com with SMTP; 2 May 2001 22:48:49 -0000 Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f42MwQj29101; Wed, 2 May 2001 15:58:26 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AFB09774; Wed, 2 May 2001 15:58:25 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA13983; Wed, 2 May 2001 15:58:25 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15088.37137.309478.49019@thomasm-u1.cisco.com> Date: Wed, 2 May 2001 15:58:25 -0700 (PDT) To: Phil Roberts Cc: seamoby@diameter.org Subject: RE: [seamoby] suggestions for MM IRTF 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 Phil Roberts writes: > > Mike, > > thanks for your comments. They are all good and I've incorporated > almost all of them in the doc with a little wordsmithing in places to make > it flow well. I have questions about this one: > > o I might start this with "The current Internet > > has a high expectation that nodes are > > stationary. While Mobile IP goes to some > > length to hide the mobility from the end > > system communicating to the mobile network, > > it uses tunnels which are not necessarily > > transparent to routers in the tunnel path. > > This in turn causes services which are > > provided by those routers, such as quality > > of service guarantees, to be impacted by > > the mobility. > > Up to this point I have the following question. You say which *are not* > necessarily transparent to routers. Do you mean to say that *are* > necessarily transparent to routers? You're right, that's pretty awful; a maze of double negatives, all alike. How about: While Mobile IP provides transparency of the mobility to correspondent nodes communicating with hosts on the mobile network, Mobile IP does not provide transparency for any state contained within routers along the paths from correspondent nodes and the mobile node's home agent. That is, state in routers which is dependent on the stability of the source or destination address in the IP header will be negatively impacted by Mobile IP's need to change care of addresses. For example, when a mobile node changes its care of addresss, the mobile node's current reservation would require that the filter specs be updated with the new care of address. By instead treating the mobility as a topology change within the local area, these unpleasant second order effects can be avoided. > Presumably if there are foreign agents involved or mobile aware access > routers for v6 they can and will handle QoS characteristics for themselves > and between themselves and the mobile, but the next router or two up the > chain doesn't see the mobility and can't really deal with the fact that the > flow has moved. Just trying to understand what you're after here. Basically, the problem is that filterspec might need to change since the CoA is what you'd naively put in the filterspec (it's what's in the IP header, after all), which pretty much pooches your handover unless we do something about it with NSIS. A MM based solution neatly skates past that little road block which is pretty nice. Mike From owner-seamoby@diameter.org Wed May 2 19:35: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 TAA26358 for ; Wed, 2 May 2001 19:34:56 -0400 (EDT) Received: (qmail 22760 invoked by alias); 2 May 2001 23:19:11 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 22753 invoked by uid 200); 2 May 2001 23:19:10 -0000 Received: (qmail 22747 invoked from network); 2 May 2001 23:19:08 -0000 Received: from unknown (HELO megisto-sql1.megisto.com) (63.113.114.132) by c900656-a.plstn1.sfba.home.com with SMTP; 2 May 2001 23:19:08 -0000 Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Wed, 2 May 2001 19:22:36 -0400 Message-ID: From: Phil Roberts To: "'seamoby@diameter.org'" Subject: [seamoby] updated problem statement Date: Wed, 2 May 2001 19:22:34 -0400 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 just submitted this to internet drafts. Text included below. Incorporated changes from several people including most of michael's comment. Personal P. Roberts Compiler Internet Draft Title: draft-proberts-localsubnetmobility- problem-00.txt Category: Informational May 2001 Expires : November 2001 Local Subnet Mobility Problem Statement Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Abstract This document specifies a problem statement for investigation within the IRTF. There are a couple of seemingly unrelated problems that have led investigators to converge on the desirability of implementing a routing protocol whose purpose is to allow a mobile node to retain connectivity via its current IP subnet while it moves within the scope of the micro mobility domain. In general this domain is expected to be contained within an autonomous system so that global aggregation of subnets is still preserved. An additional benefit of the protocols is that mobile nodes may more quickly react to failed links. The problem is to investigate the limits and issues with using (a) new protocol(s) to implement per node routes to facilitate better the movement of nodes and recovery of the network in the presence of failed links or routers. The document is a brief statement of the problem to be investigated with references to lots of other work that has been done already by many others in the area. 1 Internet Draft Local Subnet Mobility Problem Statement May 2001 1. Introduction The design of Internet routing has evolved largely based on the assumption that most end systems are stationary. As the idea of mobile devices came along, Mobile IP provided an easy migration path for supporting end system mobility without significant change or impact to the Internet infrastructure. This was achieved primarily by placing the support for routing to mobile devices on the end systems and at a limited number of centralized points within the infrastructure, effectively "hiding" the end system mobility from the infrastructure routing protocols. However, as we anticipate the desire to support real-time traffic flows to mobile devices and the possibility that mobile devices may become a significant portion of all Internet end nodes, investigation of alternative designs merit consideration. Many investigators in this area have converged on solutions that propose the use of local subnet mobility routing to support mobility within a limited domain, effectively exposing the mobility of end systems to the routers. This draft represents a problem statement to enable investigation of how a local subnet mobility routing protocol can be employed to enable mobility and fast network recovery. It is a problem statement based on a lot of work done in attempting to provide low latency handover in mobile networks and fast recovery in networks with fast recovery requirements. Please see the reference list for a large set of work that has been done in the past along these lines. A good summary of the problem as it pertains to network recovery is [MC]. The micromobility design team of the seamoby working group produced a problem statement also [SMM]. See the reference list for lots of previous work that has been done especially in the area of mobility with alternate proposals from Mobile IP. 2. Problem Statement This section proposes questions that have led to a perceived need for investigation of node routing within the IRTF. Why is there a perceived need for a non-tunnel-based routing solution for mobility? While Mobile IP provides transparency of the mobility to correspondent nodes communicating with hosts on the mobile network, Mobile IP does not provide transparency for any state contained within routers along the paths from correspondent nodes and the mobile node's home agent. That is, state in routers which is dependent on the stability of the source or destination address in the IP header will be negatively impacted by the mobile node's change of care of addresses. For example, when a mobile node changes its care of address, the mobile node's current reservation would require that the filter specs be updated with the new care of address. By instead treating the mobility as a topology change within the local area, these unpleasant second order effects can be avoided. Design Team 2 Internet Draft Local Subnet Mobility Problem Statement May 2001 2.1 Problem One There are applications that involve supporting real-time traffic flows to end devices that are mobile. These applications require that there be minimal (ideally no) interruption to the packet flows and that these flows need to preserve the existing QoS and security characteristics as the end station moves. In addition the movement of the end devices should not cause excessive signaling in the network as the devices move. Such applications often also run on networks in which link failures or router failures can cause a significant service disruption. Is it possible to use a similar protocol to allow for faster restoration of service during link failures. Could such mobility requirements and fast restoration requirements be met in a way that is more efficient and simpler than approaches based on Mobile IP and current intradomain routing protocols by using a routing protocol that implements local subnet mobility within a limited scope within the network? What would the limits of such a solution be in terms of scaling? Specifically how many nodes could be supported across what kind of network breadth and depth at what cost of complexity in the routers around the edge of such a network? Is it possible to meet traffic engineering requirements using such a protocol? Could it simplify management of QoS in the part of the network where mobility is most readily felt? 2.2 Problem Two One of the primary principles of the Internet has been end-to-end communication. Most (if not all) of the protocols running over IP have been designed with end-to-end signaling in mind. Currently, changes due to mobility induce unwanted end-to-end signaling. This may cause applications running over IP to fail due to delay and latency induced by unwanted signaling. Security, QoS and AAA signaling all suffer due to this. Could a local subnet mobility protocol aid in this respect? 2.3 Problem Three Why is there a need for an investigation of it in the IRTF rather than a direct move to work on a standard within a working group of the IETF? The area directors overseeing the activities of the seamoby working group and the mobile-ip working group have raised questions about the scale of local subnet mobility routing and the potential need to introduce both another routing protocol and another mobility protocol. A comparison with existing mobility management and routing protocols are involved in making such an assessment both in terms of relative scalability, performance, and complexity. 3. Acknowledgements The compiler would like to acknowledge all the contributors who have produced work relating to host routing for the various problems. Design Team 3 Internet Draft Local Subnet Mobility Problem Statement May 2001 References [MC] M. Scott Corson, A. O'Neill, G. Tsirtsis. IP Fast Restoration. Work in Progress. Draft-corson-fastrestore-00.txt, November 2000. [SMM] J. Loughney, et. al. "SeaMoby Micromobility Problem Statement." Work in Progress. Draft-ietf-seamoby-mm-problem-01.txt, February 2001. [FHO] G. Tsirtsis, et. al. "Fast Handovers for Mobile Ipv6." Work in Progress. Draft-ietf-mobileip-fast-mipv6-00.txt, February 2001. [MT] M. Thomas. "Analysis of Mobile IP and RSVP Interactions." Work in Progress. Draft-thomas-seamoby-rsvp-analysis-00.txt, February 2001. [CI] Z. Shelby, et. al. "Cellular IP v6." Work in Progress. Draft-shelby-seamoby-cellularipv6-00.txt, November 2000. [HSR] A. O'Neill. "Host Specific Routing." Work in Progress. Draft-oneill-li-hst-00.txt, November 2000. [IMMP] A. Campbell and J. Gomez. "IP Micro-mobility Protocols." ACM SIGMOBILE Mobile Computer and Communications Review (MC2R), 2001, available at http://www.comet.columbia.edu/micromobility. [CIP] Campbell, et. al. "Cellular IP." Work in Progress. Draft expired, but available at http://www.comet.columbia.edu/micromobility. [HAW] Ramjee, et. al. "Hawaii." Work in Progress. Draft expired, but available at http://www.comet.columbia.edu/micromobility. [EMA] M. Scott Corson, and Alan O'Neill. An Approach to Fixed/Mobile Converged Routing. University of Maryland, Institute for Systems Research, Technical Report, TR 2000-5. 2000. available at http://www.isr.umd.edu/TechReports/ISR/2000/TR_2000-5/TR_2000-5.phtml Addresses The compiler of this document is: Phil Roberts, Megisto Systems, Inc., proberts@megisto.com Design Team 4 From owner-seamoby@diameter.org Wed May 2 19:58: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 TAA26695 for ; Wed, 2 May 2001 19:58:23 -0400 (EDT) Received: (qmail 23958 invoked by alias); 2 May 2001 23:47:14 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 23952 invoked by uid 200); 2 May 2001 23:47:14 -0000 Received: (qmail 23947 invoked from network); 2 May 2001 23:47:12 -0000 Received: from out2.prserv.net (HELO prserv.net) (32.97.166.32) by c900656-a.plstn1.sfba.home.com with SMTP; 2 May 2001 23:47:12 -0000 Received: from [32.101.227.108] (slip-32-101-227-9.ca.us.prserv.net[32.101.227.9]) by prserv.net (out2) with ESMTP id <20010502235712202042gsrje>; Wed, 2 May 2001 23:57:13 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: ahmrphd@pop3.attglobal.net Message-Id: In-Reply-To: Date: Wed, 2 May 2001 16:56:38 -0700 To: Phil Roberts , "'seamoby@diameter.org'" From: Arthur Ross Subject: Re: [seamoby] updated problem statement Sender: owner-seamoby@diameter.org Precedence: bulk At 16:22 -0700 05/02/2001, Phil Roberts wrote: >I just submitted this to internet drafts. Text included below. >Incorporated changes from several people including most of michael's >comment. > Phil - I think this has converged on a very good, clear summary of the issues. While I would like some more explicit mention of support for radio-ish issues, the statements about QoS can be interpreted broadly to include those sorts of things, without attempting to pre-bias the solution. Again, good job by all. -- ahmr From owner-seamoby@diameter.org Wed May 2 20:40:27 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 UAA27363 for ; Wed, 2 May 2001 20:40:22 -0400 (EDT) Received: (qmail 24955 invoked by alias); 3 May 2001 00:26:44 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 24949 invoked by uid 200); 3 May 2001 00:26:43 -0000 Received: (qmail 24944 invoked from network); 3 May 2001 00:26:42 -0000 Received: from unknown (HELO NEPTUNE.zucotto.com) (216.95.209.154) by c900656-a.plstn1.sfba.home.com with SMTP; 3 May 2001 00:26:42 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 May 2001 20:36:49 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B90D2BB9@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Phil Roberts'" , "'seamoby@diameter.org'" Subject: RE: [seamoby] updated problem statement Date: Wed, 2 May 2001 20:36:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Very well written. I just read it for the first time. Good job! - Cheers, Kulwinder. > -----Original Message----- > From: Phil Roberts [mailto:PRoberts@MEGISTO.com] > Sent: Wednesday, May 02, 2001 7:23 PM > To: 'seamoby@diameter.org' > Subject: [seamoby] updated problem statement > > > > I just submitted this to internet drafts. Text included below. > Incorporated changes from several people including most of michael's > comment. > > > > > Personal P. Roberts > Compiler > Internet Draft > Title: draft-proberts-localsubnetmobility- > problem-00.txt > Category: Informational May 2001 > Expires : November 2001 > > > > Local Subnet Mobility Problem Statement > > > > > Status of This Memo > > > This document is an Internet-Draft and is in full conformance with > all provisions of Section 10 of RFC2026. Internet-Drafts > are working > documents of the Internet Engineering Task Force (IETF), > its areas, > and its working groups. Note that other groups may also > distribute > working documents as Internet-Drafts. > > Internet-Drafts are draft documents valid for a maximum of > six months > and may be updated, replaced, or obsoleted by other documents at > any time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at: > http://www.ietf.org/ietf/1id-abstracts.txt > The list of Internet-Draft Shadow Directories can be accessed at: > http://www.ietf.org/shadow.html. > > > Abstract > > This document specifies a problem statement for > investigation within > the IRTF. There are a couple of seemingly unrelated problems that > have led investigators to converge on the desirability of > implementing a routing protocol whose purpose is to allow a mobile > node to retain connectivity via its current IP subnet > while it moves > within the scope of the micro mobility domain. In general > this domain > is expected to be contained within an autonomous system so that > global aggregation of subnets is still preserved. An additional > benefit of the protocols is that mobile nodes may more > quickly react > to failed links. The problem is to investigate the limits > and issues > with using (a) new protocol(s) to implement per node routes to > facilitate better the movement of nodes and recovery of > the network > in the presence of failed links or routers. The document > is a brief > statement of the problem to be investigated with > references to lots > of other work that has been done already by many others in > the area. > > > > > 1 > > Internet Draft Local Subnet Mobility Problem Statement May 2001 > > > > > 1. Introduction > > The design of Internet routing has evolved largely based on the > assumption that most end systems are stationary. As the idea of > mobile devices came along, Mobile IP provided an easy > migration path > for supporting end system mobility without significant change or > impact to the Internet infrastructure. This was achieved > primarily by > placing the support for routing to mobile devices on the > end systems > and at a limited number of centralized points within the > infrastructure, effectively "hiding" the end system > mobility from the > infrastructure routing protocols. However, as we anticipate the > desire to support real-time traffic flows to mobile > devices and the > possibility that mobile devices may become a significant > portion of > all Internet end nodes, investigation of alternative designs merit > consideration. Many investigators in this area have converged on > solutions that propose the use of local subnet mobility routing to > support mobility within a limited domain, effectively exposing the > mobility of end systems to the routers. > > This draft represents a problem statement to enable > investigation of > how a local subnet mobility routing protocol can be employed to > enable mobility and fast network recovery. It is a > problem statement > based on a lot of work done in attempting to provide low latency > handover in mobile networks and fast recovery in networks > with fast > recovery requirements. Please see the reference list for > a large set > of work that has been done in the past along these lines. > > A good summary of the problem as it pertains to network > recovery is > [MC]. The micromobility design team of the seamoby working group > produced a problem statement also [SMM]. See the > reference list for > lots of previous work that has been done especially in the area of > mobility with alternate proposals from Mobile IP. > > 2. Problem Statement > > This section proposes questions that have led to a > perceived need for > investigation of node routing within the IRTF. Why is there a > perceived need for a non-tunnel-based routing solution for > mobility? > While Mobile IP provides transparency of the mobility to > correspondent nodes communicating with hosts on the mobile > network, > Mobile IP does not provide transparency for any state contained > within routers along the paths from correspondent nodes and the > mobile node's home agent. That is, state in routers which is > dependent on the stability of the source or destination address in > the IP header will be negatively impacted by the mobile > node's change > of care of addresses. For example, when a mobile node changes its > care of address, the mobile node's current reservation > would require > that the filter specs be updated with the new care of address. By > instead treating the mobility as a topology change within > the local > area, these unpleasant second order effects can be avoided. > > > Design Team > 2 > > Internet Draft Local Subnet Mobility Problem Statement May 2001 > > > 2.1 Problem One > > There are applications that involve supporting real-time traffic > flows to end devices that are mobile. These applications require > that there be minimal (ideally no) interruption to the > packet flows > and that these flows need to preserve the existing QoS and > security > characteristics as the end station moves. In addition the > movement > of the end devices should not cause excessive signaling in the > network as the devices move. Such applications often also run on > networks in which link failures or router failures can cause a > significant service disruption. Is it possible to use a similar > protocol to allow for faster restoration of service during link > failures. Could such mobility requirements and fast restoration > requirements be met in a way that is more efficient and > simpler than > approaches based on Mobile IP and current intradomain routing > protocols by using a routing protocol that implements local subnet > mobility within a limited scope within the network? What > would the > limits of such a solution be in terms of scaling? > Specifically how > many nodes could be supported across what kind of network > breadth and > depth at what cost of complexity in the routers around the edge of > such a network? Is it possible to meet traffic engineering > requirements using such a protocol? Could it simplify > management of > QoS in the part of the network where mobility is most > readily felt? > > 2.2 Problem Two > > One of the primary principles of the Internet has been end-to-end > communication. Most (if not all) of the protocols running over IP > have been designed with end-to-end signaling in mind. Currently, > changes due to mobility induce unwanted end-to-end signaling. This > may cause applications running over IP to fail due to delay and > latency induced by unwanted signaling. Security, QoS and AAA > signaling all suffer due to this. Could a local subnet mobility > protocol aid in this respect? > > 2.3 Problem Three > > Why is there a need for an investigation of it in the IRTF rather > than a direct move to work on a standard within a working group of > the IETF? The area directors overseeing the activities of the > seamoby working group and the mobile-ip working group have raised > questions about the scale of local subnet mobility routing and the > potential need to introduce both another routing protocol > and another > mobility protocol. A comparison with existing mobility > management and > routing protocols are involved in making such an > assessment both in > terms of relative scalability, performance, and complexity. > > > 3. Acknowledgements > > The compiler would like to acknowledge all the > contributors who have > produced work relating to host routing for the various problems. > > > Design Team > 3 > > Internet Draft Local Subnet Mobility Problem Statement May 2001 > > > > References > > [MC] M. Scott Corson, A. O'Neill, G. Tsirtsis. IP Fast > Restoration. > Work in Progress. Draft-corson-fastrestore-00.txt, November 2000. > [SMM] J. Loughney, et. al. "SeaMoby Micromobility Problem > Statement." Work in Progress. Draft-ietf-seamoby-mm-problem-01.txt, > February 2001. > [FHO] G. Tsirtsis, et. al. "Fast Handovers for Mobile > Ipv6." Work > in Progress. Draft-ietf-mobileip-fast-mipv6-00.txt, February 2001. > [MT] M. Thomas. "Analysis of Mobile IP and RSVP Interactions." > Work in Progress. Draft-thomas-seamoby-rsvp-analysis-00.txt, > February > 2001. > [CI] Z. Shelby, et. al. "Cellular IP v6." Work in Progress. > Draft-shelby-seamoby-cellularipv6-00.txt, November 2000. > [HSR] A. O'Neill. "Host Specific Routing." Work in Progress. > Draft-oneill-li-hst-00.txt, November 2000. > [IMMP] A. Campbell and J. Gomez. "IP Micro-mobility Protocols." > ACM SIGMOBILE Mobile Computer and Communications Review (MC2R), 2001, > available at http://www.comet.columbia.edu/micromobility. > [CIP] Campbell, et. al. "Cellular IP." Work in Progress. Draft > expired, but available at http://www.comet.columbia.edu/micromobility. [HAW] Ramjee, et. al. "Hawaii." Work in Progress. Draft expired, but available at http://www.comet.columbia.edu/micromobility. [EMA] M. Scott Corson, and Alan O'Neill. An Approach to Fixed/Mobile Converged Routing. University of Maryland, Institute for Systems Research, Technical Report, TR 2000-5. 2000. available at http://www.isr.umd.edu/TechReports/ISR/2000/TR_2000-5/TR_2000-5.phtml Addresses The compiler of this document is: Phil Roberts, Megisto Systems, Inc., proberts@megisto.com Design Team 4 From owner-seamoby@diameter.org Thu May 3 06:16: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 GAA18081 for ; Thu, 3 May 2001 06:16:15 -0400 (EDT) Received: (qmail 31212 invoked by alias); 3 May 2001 10:04:50 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 31206 invoked by uid 200); 3 May 2001 10:04:49 -0000 Received: (qmail 31201 invoked from network); 3 May 2001 10:04:47 -0000 Received: from mgw-x1.nokia.com (131.228.20.21) by c900656-a.plstn1.sfba.home.com with SMTP; 3 May 2001 10:04:47 -0000 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 f43AEO211590 for ; Thu, 3 May 2001 13:14:24 +0300 (EET DST) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 3 May 2001 13:14:48 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Thu, 3 May 2001 13:14:48 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680AE4F@eseis04nok> From: john.loughney@nokia.com To: PRoberts@MEGISTO.com, seamoby@diameter.org Subject: RE: [seamoby] work that "needs" to get done and where Date: Thu, 3 May 2001 13:14:46 +0300 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 all, > The second was for the seamoby mm design team to come up with a set of > things which they believe an mm protocol MUST do and throw it > over to MIP to see whether the set of protocols in MIP can do those > things. I haven't seen much activity on this. John sent out an email > asking for volunteers recently I believe - don't know whether he got any > response. I've had one person respond "maybe, if it is about something that I want to do ..." and one person who has said that they are considering writing an individual submission. So, can I ask again? Who is interested in this work? If this is something of interest, let's crank up the MM Design Team. I might even be able to host some conference calls. If this work is not of interest, let's drop it. John From owner-seamoby@diameter.org Thu May 3 09:16: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 JAA22212 for ; Thu, 3 May 2001 09:16:07 -0400 (EDT) Received: (qmail 566 invoked by alias); 3 May 2001 13:04:45 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 560 invoked by uid 200); 3 May 2001 13:04:45 -0000 Received: (qmail 555 invoked from network); 3 May 2001 13:04:43 -0000 Received: from c007-h011.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.217) by c900656-a.plstn1.sfba.home.com with SMTP; 3 May 2001 13:04:43 -0000 Received: (cpmta 21666 invoked from network); 3 May 2001 06:14:22 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.217) with SMTP; 3 May 2001 06:14:22 -0700 X-Sent: 3 May 2001 13:14:22 GMT Message-ID: <004001c0d3ce$303b72e0$6401a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: , , References: <01D91AFB08B6D211BFD00008C7EABAE10680AE4F@eseis04nok> Subject: Re: [seamoby] work that "needs" to get done and where Date: Thu, 3 May 2001 07:40:07 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk John, Please count me in. I would like to contribute to this draft. I can also work out the CNP stuff (if the WG feels like that is useful). I have had a difficult time determining if there is interest in CNP in the WG as well. If you want to look at what my next draft WAS going to be you can download the MS Word paper from www.federalmobility.com/cnpoiplatest.doc. Peter Lei (Cisco) and I were waiting to hear whether this paper was accepted by the Mobicom 2001 conference before releasing any details to the list, but the May 1st acceptance date has come and gone and I have heard nothing (probably not a good sign :-)). Eitherway, this is a technology we can take a look at for putting some more brains into the handoff decision and it meshes quite nicely with context transfer. Would you like to use this paper as a first item of discussion activity for the MM design team? Thanks, Phil ----- Original Message ----- From: To: ; Sent: Thursday, May 03, 2001 5:14 AM Subject: RE: [seamoby] work that "needs" to get done and where > Hi all, > > > The second was for the seamoby mm design team to come up with a set of > > things which they believe an mm protocol MUST do and throw it > > over to MIP to see whether the set of protocols in MIP can do those > > things. I haven't seen much activity on this. John sent out an email > > asking for volunteers recently I believe - don't know whether he got any > > response. > > I've had one person respond "maybe, if it is about something that I want > to do ..." and one person who has said that they are considering writing > an individual submission. > > So, can I ask again? Who is interested in this work? If this is something > of interest, let's crank up the MM Design Team. I might even be able to > host some conference calls. > > If this work is not of interest, let's drop it. > > John > From owner-seamoby@diameter.org Thu May 3 09:40: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 JAA23176 for ; Thu, 3 May 2001 09:40:19 -0400 (EDT) Received: (qmail 1232 invoked by alias); 3 May 2001 13:28:59 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 1225 invoked by uid 200); 3 May 2001 13:28:59 -0000 Received: (qmail 1220 invoked from network); 3 May 2001 13:28:57 -0000 Received: from out1.prserv.net (HELO prserv.net) (32.97.166.31) by c900656-a.plstn1.sfba.home.com with SMTP; 3 May 2001 13:28:57 -0000 Received: from [129.37.43.120] (slip-129-37-43-120.ca.us.prserv.net[129.37.43.120]) by prserv.net (out1) with ESMTP id <2001050313390420103d3opfe>; Thu, 3 May 2001 13:39:05 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: ahmrphd@pop3.attglobal.net Message-Id: In-Reply-To: <01D91AFB08B6D211BFD00008C7EABAE10680AE4F@eseis04nok> Date: Thu, 3 May 2001 06:38:43 -0700 To: john.loughney@nokia.com, PRoberts@MEGISTO.com, seamoby@diameter.org From: Arthur Ross Subject: RE: [seamoby] work that "needs" to get done and where Sender: owner-seamoby@diameter.org Precedence: bulk At 3:14 -0700 05/03/2001, john.loughney@nokia.com wrote: > >So, can I ask again? Who is interested in this work? If this is something >of interest, let's crank up the MM Design Team. I might even be able to >host some conference calls. > John - As you no doubt gathered, I am intensely interested in this. I'm not sure that this is exactly the right roadmap for getting to where I would like to see "mobile IP" in the most generic sense wind up, but I certainly would like to participate if it happens. ... and I've actually embarked on a self-education campaign re routing & all, so next time I shoot my yap off there may be something other than just the radio comm perspective behind it ;-). To elaborate just a tad - I am thinking in terms of a grand design for MM that operates on a philosophy of distributed control, using peer-to-peer coordination, perhaps involving something like Phil's CNP. As this will be a major change in the way the world of wireless works, it has high potential for both fractiousness AND fun! Please count me in. -- Best -- ahmr PS: I don't seem to have received your original mail on this thread, or if I did it was mislaid somehow. From owner-seamoby@diameter.org Thu May 3 09:42:45 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 JAA23298 for ; Thu, 3 May 2001 09:42:44 -0400 (EDT) Received: (qmail 1288 invoked by alias); 3 May 2001 13:29:05 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 1275 invoked by uid 200); 3 May 2001 13:29:03 -0000 Received: (qmail 1244 invoked from network); 3 May 2001 13:29:00 -0000 Received: from www.bit-net.com (HELO mail.users.bit-net.com) (208.146.132.4) by c900656-a.plstn1.sfba.home.com with SMTP; 3 May 2001 13:29:00 -0000 Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA24492; Thu, 3 May 2001 09:37:46 -0400 Date: Thu, 3 May 2001 09:37:46 -0400 (EDT) From: Jim Bound To: john.loughney@nokia.com Cc: PRoberts@MEGISTO.com, seamoby@diameter.org Subject: RE: [seamoby] work that "needs" to get done and where In-Reply-To: <01D91AFB08B6D211BFD00008C7EABAE10680AE4F@eseis04nok> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk does this inclue an IP RAN gateway for mm? in your mind john? thanks /jim On Thu, 3 May 2001 john.loughney@nokia.com wrote: > Hi all, > > > The second was for the seamoby mm design team to come up with a set of > > things which they believe an mm protocol MUST do and throw it > > over to MIP to see whether the set of protocols in MIP can do those > > things. I haven't seen much activity on this. John sent out an email > > asking for volunteers recently I believe - don't know whether he got any > > response. > > I've had one person respond "maybe, if it is about something that I want > to do ..." and one person who has said that they are considering writing > an individual submission. > > So, can I ask again? Who is interested in this work? If this is something > of interest, let's crank up the MM Design Team. I might even be able to > host some conference calls. > > If this work is not of interest, let's drop it. > > John > From owner-seamoby@diameter.org Thu May 3 10:15: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 KAA25028 for ; Thu, 3 May 2001 10:15:14 -0400 (EDT) Received: (qmail 2722 invoked by alias); 3 May 2001 14:04:02 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2716 invoked by uid 200); 3 May 2001 14:04:01 -0000 Received: (qmail 2709 invoked by uid 500); 3 May 2001 14:03:59 -0000 Date: Thu, 3 May 2001 07:03:59 -0700 From: Pat Calhoun To: john.loughney@nokia.com Cc: PRoberts@MEGISTO.com, seamoby@diameter.org Subject: Re: [seamoby] work that "needs" to get done and where Message-ID: <20010503070359.D26582@charizard.diameter.org> Mail-Followup-To: john.loughney@nokia.com, PRoberts@MEGISTO.com, seamoby@diameter.org References: <01D91AFB08B6D211BFD00008C7EABAE10680AE4F@eseis04nok> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01D91AFB08B6D211BFD00008C7EABAE10680AE4F@eseis04nok>; from john.loughney@nokia.com on Thu, May 03, 2001 at 01:14:46PM +0300 Sender: owner-seamoby@diameter.org Precedence: bulk On Thu, May 03, 2001 at 01:14:46PM +0300, john.loughney@nokia.com wrote: > Hi all, > > > The second was for the seamoby mm design team to come up with a set of > > things which they believe an mm protocol MUST do and throw it > > over to MIP to see whether the set of protocols in MIP can do those > > things. I haven't seen much activity on this. John sent out an email > > asking for volunteers recently I believe - don't know whether he got any > > response. > > I've had one person respond "maybe, if it is about something that I want > to do ..." and one person who has said that they are considering writing > an individual submission. > > So, can I ask again? Who is interested in this work? If this is something > of interest, let's crank up the MM Design Team. I might even be able to > host some conference calls. > > If this work is not of interest, let's drop it. FWIW, I am waiting for the new charter to be approved, which would include this very work item. So, since it isn't in the charter, perhaps people are reluctant to work on it. However, if people still aren't that interested once the new charter is available, then I will be confused. I do recall people complaining a whole lot about MIP on the list, and no one is willing to work on fixing it.... PatC From owner-seamoby@diameter.org Thu May 3 12:16: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 MAA28850 for ; Thu, 3 May 2001 12:16:36 -0400 (EDT) Received: (qmail 6039 invoked by alias); 3 May 2001 16:05:19 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 6032 invoked by uid 200); 3 May 2001 16:05:18 -0000 Received: (qmail 6027 invoked from network); 3 May 2001 16:05:16 -0000 Received: from mercury.sun.com (192.9.25.1) by c900656-a.plstn1.sfba.home.com with SMTP; 3 May 2001 16:05:16 -0000 Received: from heliopolis.eng.sun.com ([152.70.1.39]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA07451; Thu, 3 May 2001 09:15:19 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id JAA27029; Thu, 3 May 2001 09:13:30 -0700 (PDT) Message-Id: <200105031613.JAA27029@heliopolis.eng.sun.com> Date: Thu, 3 May 2001 09:13:31 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: Re: [seamoby] updated problem statement To: seamoby@diameter.org, PRoberts@MEGISTO.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: d3mnZR13txZQQtr8kIRIJQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-seamoby@diameter.org Precedence: bulk Hi Phil, The problem statement looks good, I've got just one comment. There seems to be an implicit assumption in the statement that the routing protocol which IRTF will come up with will be based on a standard wired subnet routing model. I think this assumption is somewhat limiting. Remember, we are talking about research. The model might end up being something between the completely ad hoc MANET model and the standard subnet model. So, I'd suggest changing "subnet" to "network" or some other neutral term. jak From owner-seamoby@diameter.org Thu May 3 12: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 MAA29162 for ; Thu, 3 May 2001 12:24:52 -0400 (EDT) Received: (qmail 6742 invoked by alias); 3 May 2001 16:13:25 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 6736 invoked by uid 200); 3 May 2001 16:13:24 -0000 Received: (qmail 6731 invoked from network); 3 May 2001 16:13:21 -0000 Received: from sj-msg-core-2.cisco.com (171.69.43.88) by c900656-a.plstn1.sfba.home.com with SMTP; 3 May 2001 16:13:21 -0000 Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f43GNRK05761; Thu, 3 May 2001 09:23:27 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AFC02348; Thu, 3 May 2001 09:22:57 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA14266; Thu, 3 May 2001 09:22:57 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15089.34273.83795.56756@thomasm-u1.cisco.com> Date: Thu, 3 May 2001 09:22:57 -0700 (PDT) To: James Kempf Cc: seamoby@diameter.org, PRoberts@MEGISTO.com Subject: Re: [seamoby] updated problem statement In-Reply-To: <200105031613.JAA27029@heliopolis.eng.sun.com> References: <200105031613.JAA27029@heliopolis.eng.sun.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit So I'm sort of ignorant of MANET protocols, but subnets are just ways of moving the reachability of aggregates of connectivity around. From my skim of TORA, it didn't look like it was doing anything mysterious on that from; it was mainly working on the way the change was propogated from what I could tell (link reversal). Mike James Kempf writes: > Hi Phil, > > The problem statement looks good, I've got just one comment. There > seems to be an implicit assumption in the statement that the routing > protocol which IRTF will come up with will be based on a standard > wired subnet routing model. I think this assumption is somewhat limiting. > Remember, we are talking about research. The model might end up > being something between the completely ad hoc MANET model and > the standard subnet model. > > So, I'd suggest changing "subnet" to "network" or some other neutral > term. > > jak > From owner-seamoby@diameter.org Thu May 3 12:29: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 MAA29289 for ; Thu, 3 May 2001 12:29:44 -0400 (EDT) Received: (qmail 7245 invoked by alias); 3 May 2001 16:16:40 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 7239 invoked by uid 200); 3 May 2001 16:16:40 -0000 Received: (qmail 7234 invoked from network); 3 May 2001 16:16:37 -0000 Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.nortelnetworks.com) (47.129.242.157) by c900656-a.plstn1.sfba.home.com with SMTP; 3 May 2001 16:16:37 -0000 Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id MAA20203; Thu, 3 May 2001 12:26:09 -0400 Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Thu, 3 May 2001 12:26:02 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 May 2001 12:26:06 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C12589E@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'seamoby'" Subject: RE: Radio Access Network Protocols (was: Re: [seamoby] IRTF mm pr oblem statement) Date: Thu, 3 May 2001 12:26:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Orig: Sender: owner-seamoby@diameter.org Precedence: bulk > -----Original Message----- > From: James Kempf [mailto:James.Kempf@Sun.COM] > Sent: Tuesday, May 01, 2001 5:31 PM > To: PRoberts@MEGISTO.com; a.ross@ieee.org; seamoby@diameter.org; > neumiller@telocity.com > Subject: Radio Access Network Protocols (was: Re: [seamoby] IRTF mm > problem statement) > > > IETF has resisted doing wireless specific protocols in the past. The > CRAPS BOF explicitly rejected doing that kind of work, though perhaps > there has been a change of heart. I expect, however, that there > will be the same kind of resistance in the future. James: I don't know how you can say the BOF accepted or rejected anything. They never were allowed to hold a vote!. > > There has been some ongoing work in MWIF (Mobile Wireless Internet > Forum, http://www.mwif.org) on a radio access network > architecture, called > OpenRAN, that is independent of radio link protocol, along the lines > suggested by Arthur and PhilN. The architecture is > complete, we are about to release the report, and we are planning > some conference presentations and journal articles to familiarize > the wireless community with the architecture in the near future. > We have already taken this work to the 3Gs, there is some interest > in 3GPP2 though also a certain amount of resistence, but 3GPP has > essentially rejected it as too experimental. > > The next step for the OpenRAN architecture is to do some protocol > development work, and MWIF is currently debating whether to do > this or not. If it does, you can be sure the OBAST work will be > important input. The objective of the protocol development work > would be to develop a RAN protocol independent of radio link protocol > and have vendors implement prototypes for interoperability testing > (the other aspect of this is interoperable radio network management, > which turns out to be the single largest barrier to open systems > in UTRAN, and it is also being investigated by MWIF). Once > the protocol > is complete, it would be taken to IETF and the 3Gs for consideration. Sounds like an IRTF activity to me. Gary > By virtue of it being radio link independent, one could view it > as not L2 specific, though it is wireless specific, so perhaps > IETF would be more interested in it. If MWIF declines to continue > working on the protocol, some mild interest has been expressed by > a few vendors to continue working on it in another forum. > > Most of the people involved in the OpenRAN effort believe that > MWIF is the right place to do the technical work for now (similar > to how the Multivendor Switching Forum developed their protocol > first, before bringing it to IETF), then bringing it to IETF > later, if appropriate. So if any radio knowledgable types are > interested, I'd > encourage you to become involved. > > jak > > > > > >Delivered-To: seamoby-list@charizard.diameter.org > >X-Sent: 1 May 2001 20:17:04 GMT > >From: "Phil Neumiller" > >To: "Phil Roberts" , "'Arthur Ross'" > , > > >Subject: Re: [seamoby] IRTF mm problem statement > >Date: Tue, 1 May 2001 15:05:03 -0500 > >X-Priority: 3 > >X-MSMail-Priority: Normal > >X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 > > > >Hi Phil R./Arthur, > > > >> One might think that a good chunk of this problem can be > abstracted without > >> any awareness of radio link characteristics. The point of > this particular > >> piece of research has to do with updating reachability > awareness and > >> forwarding tables within the routers the mobile attaches > to rather than how > >> to figure out which points the mobiles can reach and how > well they can reach > >> it. > > > >I see this is where the disconnect is Phil R. We HAD gone > much further in > >SeaMoby of our discussions of micro-mobility than your > current list of drafts. > >We entertained issues related to the mobile and its view of > the network. > >Also, most people were familiar with the OBAST paper which describes > >a method for macro/micro/local mobility where the air > interfaces properties > >of CDMA are socketed as Arthur has described (mainly because > I recited > >enough times on the list) [even in the CRAPS BOF I had to make this > >argument]{See thwap thread a while back on SeaMoby list}. > > > >> > >> It would be hard also to make too many assumptions about > what that radio > >> system could be. You include that the architecture should > have a provision > >> for a diversity combiner but surely there are networks > over which something > >> like this would run on which there is no diversity combiner? > > > >Also, Phil R., I had discussed many times on the SeaMoby > list that diversity > >combining is not just for CDMA. When done over IP, other > radios, even > >TDMA radios can take advantage of it in the outer-loop > sense. I have several > >patents pending on how to do this with TDMA, and frequency > hop radios, > >not just DSSS. Of course those are Motorola's and don't do > us much good > >here in the IETF unless some other folks can come up with some stuff > >independently. :-) > > > >> I wasn't privy > >> to all the discussions in the fast handover design teams > in MIP but there > >> was at least some effort put in to thinking about what > happens when this is > >> running over a fairly lossy medium. Whether or not a > ping-pong effect > >> should be handled in these protocols was also discussed and highly > >> controversial. > > > >Again we discussed this in the SeaMoby list and CRAPS list and OBAST > >list numerous times. The TADD/TDROP timers as used in CDMA can > >work for any RF interface to reduce ping-pong if done in a > borrowed and > >abstract way over IP. > > > >> Both of those can be characteristics of wireless systems > >> with multiple access points, and both may be quite > independent of whether it > >> is a TDMA or CDMA or whatever system running at 800MHz, 1800MHz, or > >> whatever. > > > >In this sense I agree with you, but only so far as it can be > done in a common > way. > >Macro-diversity selection can be done with almost any radio > type, and OBAST > >it is an option. OBAST allows optionalk make-before-break > with any radio type. > >OBAST allows simultaneous and different link layers to be > active if they want > to > >use it. > >> > >> There has been reluctance so far to design within the IETF a radio > >> technology specific subsystem. I personally am not > willing to push for > >> that. Perhaps you can get a discussion going on in the > new wireless > >> interest list Phil N set up to organize an effort to > promote such. It seems > >> that productive work along the path already specified in > the document can go > >> on and the possibilities for exploring ratholes by adding in radio > >> technology specific issues might be plentiful. > > > >We don't need to explore a rathole here. What we need to do > is ask ourselves > >what things can be made common for all RF L2s and be put > over IP? This > >is the IMPORTANT question to ask yourself. Really! Of > course I sound like > >a broken record, but I think (I hope, Pat and James and Gary > and many others) > are > >starting to think about this and understand it. Perhaps not > in the same with > >the same zeal that I express. :-) I am pretty confident > that Arthur is on the > >right track. His arguments about radio physics can be > hidden with an OO > >like abstraction of putting macro-diversity over IP. That > is the big first > step > >to consider. > > > >I will show deference to the draft author and chair. If you > want this > conversation > >moved over to the new list that is fine I will try and > summarize it and move > >it over. > > > >Thanks, > > > >Phil N. > > > > > > From owner-seamoby@diameter.org Thu May 3 12:41: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 MAA29662 for ; Thu, 3 May 2001 12:41:16 -0400 (EDT) Received: (qmail 8146 invoked by alias); 3 May 2001 16:29:42 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8140 invoked by uid 200); 3 May 2001 16:29:42 -0000 Received: (qmail 8135 invoked from network); 3 May 2001 16:29:40 -0000 Received: from patan.sun.com (192.18.98.43) by c900656-a.plstn1.sfba.home.com with SMTP; 3 May 2001 16:29:40 -0000 Received: from heliopolis.eng.sun.com ([152.70.1.39]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17395; Thu, 3 May 2001 09:39:09 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id JAA27801; Thu, 3 May 2001 09:39:08 -0700 (PDT) Message-Id: <200105031639.JAA27801@heliopolis.eng.sun.com> Date: Thu, 3 May 2001 09:39:08 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: RE: Radio Access Network Protocols (was: Re: [seamoby] IRTF mm pr oblem statement) To: seamoby@diameter.org, gkenward@nortelnetworks.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: WD7YXESMcj9hyfEsHh7ADA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-seamoby@diameter.org Precedence: bulk Hi Gary, >> IETF has resisted doing wireless specific protocols in the past. The >> CRAPS BOF explicitly rejected doing that kind of work, though perhaps >> there has been a change of heart. I expect, however, that there >> will be the same kind of resistance in the future. > > I don't know how you can say the BOF accepted or rejected anything. They >never were allowed to hold a vote!. > Sure, but there was no charter approved, most of the speakers were opposed to the work. There was no concensus. >> >> There has been some ongoing work in MWIF (Mobile Wireless Internet >> Forum, http://www.mwif.org) on a radio access network >> architecture, called >> OpenRAN, that is independent of radio link protocol, along the lines >> suggested by Arthur and PhilN. The architecture is >> complete, we are about to release the report, and we are planning >> some conference presentations and journal articles to familiarize >> the wireless community with the architecture in the near future. >> We have already taken this work to the 3Gs, there is some interest >> in 3GPP2 though also a certain amount of resistence, but 3GPP has >> essentially rejected it as too experimental. >> >> The next step for the OpenRAN architecture is to do some protocol >> development work, and MWIF is currently debating whether to do >> this or not. If it does, you can be sure the OBAST work will be >> important input. The objective of the protocol development work >> would be to develop a RAN protocol independent of radio link protocol >> and have vendors implement prototypes for interoperability testing >> (the other aspect of this is interoperable radio network management, >> which turns out to be the single largest barrier to open systems >> in UTRAN, and it is also being investigated by MWIF). Once >> the protocol >> is complete, it would be taken to IETF and the 3Gs for consideration. > >Sounds like an IRTF activity to me. It turns out that the MWIF Board has approved work on an OpenRAN protocol, so the work will go forward in MWIF, *provided* we can get support from radio vendors. Times are hard, so I don't know how forthcoming it will be, but we need radio vendors support to make this happen. If we are lucky and get support, I think many of the good, creative ideas (and hopefully none of the bad ones :-) on OBAST, CRAPS, and others that are wireless specific will get incorporated into the MWIF protocol. I hope to see this develop somewhat like the work done by the Multivendor Switching Forum, in which they developed a protocol and did interoperability testing, then brought it to the IETF and now there is a working group at IETF standardizing with their protocol as a base. jak From owner-seamoby@diameter.org Thu May 3 13:10: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 NAA00500 for ; Thu, 3 May 2001 13:10:21 -0400 (EDT) Received: (qmail 9510 invoked by alias); 3 May 2001 16:58:51 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 9504 invoked by uid 200); 3 May 2001 16:58:49 -0000 Received: (qmail 9499 invoked from network); 3 May 2001 16:58:46 -0000 Received: from c007-h015.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.222) by c900656-a.plstn1.sfba.home.com with SMTP; 3 May 2001 16:58:46 -0000 Received: (cpmta 2842 invoked from network); 3 May 2001 10:08:52 -0700 Received: from unknown (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.222) with SMTP; 3 May 2001 10:08:52 -0700 X-Sent: 3 May 2001 17:08:52 GMT Message-ID: <00e801c0d3ee$684fa0a0$6401a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Michael Thomas" , "James Kempf" Cc: , References: <200105031613.JAA27029@heliopolis.eng.sun.com> <15089.34273.83795.56756@thomasm-u1.cisco.com> Subject: Re: [seamoby] updated problem statement Date: Thu, 3 May 2001 11:30:39 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk Mike, Route aggragation is a "REAL PROBLEM" for MANETs. Most of the algorithms full in one of two camps, either Link state routing (LSR) [more-OSPF like] or distance vector (DV) more BGP or RIP like. The algorithms for MANET are in general a distributed version of the Dykstra shortest path first (SPF) algorithm or the Bellman Ford algorithm. [I just finished Charlie's book!]. In the case of what Dana has suggested to the IRTF a "route propogation" solution was suggested namely source routes. You would expect a recommendation like this from a router company!!! :-) :-) NO FLAMES please. The point of my argument was that the MN's themselves may be participating in the creation of temporary tunnel and some may the first hop ARs AND that a route propogation algorithm may NOT be able to keep up with this. Thanks, Phil Neumiller ----- Original Message ----- From: "Michael Thomas" To: "James Kempf" Cc: ; Sent: Thursday, May 03, 2001 11:22 AM Subject: Re: [seamoby] updated problem statement > > So I'm sort of ignorant of MANET protocols, but > subnets are just ways of moving the reachability > of aggregates of connectivity around. From my skim > of TORA, it didn't look like it was doing anything > mysterious on that from; it was mainly working on > the way the change was propogated from what I > could tell (link reversal). > > Mike > > James Kempf writes: > > Hi Phil, > > > > The problem statement looks good, I've got just one comment. There > > seems to be an implicit assumption in the statement that the routing > > protocol which IRTF will come up with will be based on a standard > > wired subnet routing model. I think this assumption is somewhat limiting. > > Remember, we are talking about research. The model might end up > > being something between the completely ad hoc MANET model and > > the standard subnet model. > > > > So, I'd suggest changing "subnet" to "network" or some other neutral > > term. > > > > jak > > > From owner-seamoby@diameter.org Fri May 4 04:59: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 EAA07156 for ; Fri, 4 May 2001 04:59:24 -0400 (EDT) Received: (qmail 24383 invoked by alias); 4 May 2001 08:47:41 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 24377 invoked by uid 200); 4 May 2001 08:47:41 -0000 Received: (qmail 24372 invoked from network); 4 May 2001 08:47:39 -0000 Received: from unknown (HELO NEPTUNE.zucotto.com) (216.95.209.154) by c900656-a.plstn1.sfba.home.com with SMTP; 4 May 2001 08:47:39 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 May 2001 04:57:51 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B90D2BCA@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'James Kempf'" , seamoby@diameter.org, PRoberts@megisto.com Subject: RE: [seamoby] updated problem statement Date: Fri, 4 May 2001 04:57:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk > -----Original Message----- > From: James Kempf [mailto:James.Kempf@sun.com] > Sent: Thursday, May 03, 2001 12:14 PM > To: seamoby@diameter.org; PRoberts@megisto.com > Subject: Re: [seamoby] updated problem statement > > > Hi Phil, > > The problem statement looks good, I've got just one comment. There > seems to be an implicit assumption in the statement that the routing > protocol which IRTF will come up with will be based on a standard > wired subnet routing model. I think this assumption is > somewhat limiting. It is not limiting. It is quite the opposite. Subnets allow route aggregation, and thus scalability. > Remember, we are talking about research. The model might end up > being something between the completely ad hoc MANET model and > the standard subnet model. MANET approaches do not seem too focused on scalability. > > So, I'd suggest changing "subnet" to "network" or some other neutral > term. Subnet is an useful term. It allows devices that move together to be grouped into a mobile subnet. Take for example a collection of devices installed into a vehicle. Rather than doing handoff for each device in a vechicle, the vechicle can be treated as a mobile subnet. The entire subnet can be handed off with just one subnet prefix. It has the added advantage that the subnetted devices do not have to be "mobile aware". A collection of PCs and other devices mounted in a train would never have to know that they were mobile. The idea of a subnet maps very well with the idea of a "Reference Frame" for a 'body in motion' in Physics. A mobile subnet extends the Physics idea of Relative Motion to IP. - Kulwinder. > > jak > From owner-seamoby@diameter.org Fri May 4 08:02: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 IAA09916 for ; Fri, 4 May 2001 08:02:23 -0400 (EDT) Received: (qmail 26401 invoked by alias); 4 May 2001 11:50:30 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 26395 invoked by uid 200); 4 May 2001 11:50:30 -0000 Received: (qmail 26390 invoked from network); 4 May 2001 11:50:27 -0000 Received: from mgw-x1.nokia.com (131.228.20.21) by c900656-a.plstn1.sfba.home.com with SMTP; 4 May 2001 11:50:27 -0000 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 f44C07218978 for ; Fri, 4 May 2001 15:00:07 +0300 (EET DST) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 4 May 2001 15:00:02 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Fri, 4 May 2001 15:00:02 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE1077D1A17@eseis04nok> From: john.loughney@nokia.com To: seamus@bit-net.com Cc: PRoberts@MEGISTO.com, seamoby@diameter.org Subject: RE: [seamoby] work that "needs" to get done and where Date: Fri, 4 May 2001 15:00:00 +0300 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 Jim, > does this inclue an IP RAN gateway for mm? in your mind john? While I might know what you are asking, can you expand on it? What would the gateway do? Thanks, John From owner-seamoby@diameter.org Fri May 4 10:24: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 KAA13152 for ; Fri, 4 May 2001 10:24:56 -0400 (EDT) Received: (qmail 30884 invoked by alias); 4 May 2001 14:10:50 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 30878 invoked by uid 200); 4 May 2001 14:10:50 -0000 Received: (qmail 30873 invoked from network); 4 May 2001 14:10:48 -0000 Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.nortelnetworks.com) (47.129.242.157) by c900656-a.plstn1.sfba.home.com with SMTP; 4 May 2001 14:10:48 -0000 Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id KAA24562; Fri, 4 May 2001 10:20:27 -0400 Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Fri, 4 May 2001 10:20:19 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 May 2001 10:20:23 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C1258A6@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , seamoby@diameter.org Subject: RE: Radio Access Network Protocols (was: Re: [seamoby] IRTF mm pr oblem statement) Date: Fri, 4 May 2001 10:20:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D4A5.5CA9AD10" 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_01C0D4A5.5CA9AD10 Content-Type: text/plain; charset="iso-8859-1" Well James, we have different perceptions of what happened. I heard many people who were opposed to work being done in areas that were not even part of the proposed charter. My perception is that a number of people took the opportunity to pontificate on favourite issues, and ignored what the organizers were trying to accomplish. In psychological terms, it's called "already listening" - some people had their minds made up about what it was all about before the meeting happened and didn't bother hearing what was being discussed. Some might call it knee jerking. A cacophony from the audience does not constitute a consensus, particularly when there was so much obvious misunderstanding. Enough on the past. I think the fact that many of the wireless issues discussed in that BOF have not gone away, and indeed some of them have turned into MIP work items, new working groups, possibly even a new work area, is a good indication that CRAPS BOF was headed into the right direction. Anyone, it's history. Bottom line: there was no vote, and no consensus was reached. Gary > -----Original Message----- > From: James Kempf [mailto:James.Kempf@Sun.COM] > Sent: Thursday, May 03, 2001 12:39 PM > To: seamoby@diameter.org; Kenward, Gary [WDLN2:AN10:EXCH] > Subject: RE: Radio Access Network Protocols (was: Re: > [seamoby] IRTF mm > pr oblem statement) > > > Hi Gary, > > >> IETF has resisted doing wireless specific protocols in the > past. The > >> CRAPS BOF explicitly rejected doing that kind of work, > though perhaps > >> there has been a change of heart. I expect, however, that there > >> will be the same kind of resistance in the future. > > > > I don't know how you can say the BOF accepted or rejected > anything. They > >never were allowed to hold a vote!. > > > > Sure, but there was no charter approved, most of the speakers were > opposed to the work. There was no concensus. > > >> > >> There has been some ongoing work in MWIF (Mobile Wireless Internet > >> Forum, http://www.mwif.org) on a radio access network > >> architecture, called > >> OpenRAN, that is independent of radio link protocol, along > the lines > >> suggested by Arthur and PhilN. The architecture is > >> complete, we are about to release the report, and we are planning > >> some conference presentations and journal articles to familiarize > >> the wireless community with the architecture in the near future. > >> We have already taken this work to the 3Gs, there is some interest > >> in 3GPP2 though also a certain amount of resistence, but 3GPP has > >> essentially rejected it as too experimental. > >> > >> The next step for the OpenRAN architecture is to do some protocol > >> development work, and MWIF is currently debating whether to do > >> this or not. If it does, you can be sure the OBAST work will be > >> important input. The objective of the protocol development work > >> would be to develop a RAN protocol independent of radio > link protocol > >> and have vendors implement prototypes for interoperability testing > >> (the other aspect of this is interoperable radio network > management, > >> which turns out to be the single largest barrier to open systems > >> in UTRAN, and it is also being investigated by MWIF). Once > >> the protocol > >> is complete, it would be taken to IETF and the 3Gs for > consideration. > > > >Sounds like an IRTF activity to me. > > It turns out that the MWIF Board has approved work on an OpenRAN > protocol, so the work will go forward in MWIF, *provided* we can > get support from radio vendors. Times are hard, so I don't know > how forthcoming it will be, but we need radio vendors support > to make this happen. If we are lucky and get support, I think many > of the good, creative ideas (and hopefully none of the bad ones :-) > on OBAST, CRAPS, and others that are wireless specific will > get incorporated > into the MWIF protocol. > > > I hope to see this develop somewhat like the work done by the > Multivendor Switching Forum, in which they developed a protocol > and did interoperability testing, then brought it to the IETF > and now there is a working group at IETF standardizing with > their protocol as a base. > > > jak > > ------_=_NextPart_001_01C0D4A5.5CA9AD10 Content-Type: text/html; charset="iso-8859-1" RE: Radio Access Network Protocols (was: Re: [seamoby] IRTF mm pr oblem statement)

Well James, we have different perceptions of what happened.
I heard many people who were opposed to work being done in
areas that were not even part of the proposed charter.

My perception is that a number of people took the opportunity to
pontificate on favourite issues, and ignored what the organizers
were trying to accomplish. In psychological terms, it's called "already
listening" - some people had their minds made up about what it was
all about before the meeting happened and didn't bother hearing
what was being discussed. Some might call it knee jerking.

A cacophony from the audience does not constitute a consensus, particularly
when there was so much obvious misunderstanding.

Enough on the past. I think the fact that many of the wireless issues
discussed in that BOF have not gone away, and indeed some of them
have turned into MIP work items, new working groups, possibly even
a new work area, is a good indication that CRAPS BOF was headed
into the right direction.

Anyone, it's history. Bottom line: there was no vote, and no consensus
was reached.
Gary

> -----Original Message-----
> From: James Kempf [mailto:James.Kempf@Sun.COM]
> Sent: Thursday, May 03, 2001 12:39 PM
> To: seamoby@diameter.org; Kenward, Gary [WDLN2:AN10:EXCH]
> Subject: RE: Radio Access Network Protocols (was: Re:
> [seamoby] IRTF mm
> pr oblem statement)
>
>
> Hi Gary,
>
> >> IETF has resisted doing wireless specific protocols in the
> past. The
> >> CRAPS BOF explicitly rejected doing that kind of work,
> though perhaps
> >> there has been a change of heart. I expect, however, that there
> >> will be the same kind of resistance in the future.
> >
> >  I don't know how you can say the BOF accepted or rejected
> anything. They
> >never were allowed to hold a vote!.
> >
>
> Sure, but there was no charter approved, most of the speakers were
> opposed to the work. There was no concensus.
>
> >>
> >> There has been some ongoing work in MWIF (Mobile Wireless Internet
> >> Forum, http://www.mwif.org) on a radio access network
> >> architecture, called
> >> OpenRAN, that is independent of radio link protocol, along
> the lines
> >> suggested by Arthur and PhilN. The architecture is
> >> complete, we are about to release the report, and we are planning
> >> some conference presentations and journal articles to familiarize
> >> the wireless community with the architecture in the near future.
> >> We have already taken this work to the 3Gs, there is some interest
> >> in 3GPP2 though also a certain amount of resistence, but 3GPP has
> >> essentially rejected it as too experimental.
> >>
> >> The next step for the OpenRAN architecture is to do some protocol
> >> development work, and MWIF is currently debating whether to do
> >> this or not. If it does, you can be sure the OBAST work will be
> >> important input. The objective of the protocol development work
> >> would be to develop a RAN protocol independent of radio
> link protocol
> >> and have vendors implement prototypes for interoperability testing
> >> (the other aspect of this is interoperable radio network
> management,
> >> which turns out to be the single largest barrier to open systems
> >> in UTRAN, and it is also being investigated by MWIF). Once
> >> the protocol
> >> is complete, it would be taken to IETF and the 3Gs for
> consideration.
> >
> >Sounds like an IRTF activity to me.
>
> It turns out that the MWIF Board has approved work on an OpenRAN
> protocol, so the work will go forward in MWIF, *provided* we can
> get support from radio vendors. Times are hard, so I don't know
> how forthcoming it will be, but we need radio vendors support
> to make this happen. If we are lucky and get support, I think many
> of the good, creative ideas (and hopefully none of the bad ones :-)
> on OBAST, CRAPS, and others that are wireless specific will
> get incorporated
> into the MWIF protocol.
>
>
> I hope to see this develop somewhat like the work done by the
> Multivendor Switching Forum, in which they developed a protocol
> and did interoperability testing, then brought it to the IETF
> and now there is a working group at IETF standardizing with
> their protocol as a base.
>
>
>               jak
>
>

------_=_NextPart_001_01C0D4A5.5CA9AD10-- From owner-seamoby@diameter.org Fri May 4 10:44: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 KAA13576 for ; Fri, 4 May 2001 10:44:44 -0400 (EDT) Received: (qmail 31535 invoked by alias); 4 May 2001 14:33:05 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 31528 invoked by uid 200); 4 May 2001 14:33:03 -0000 Received: (qmail 31523 invoked from network); 4 May 2001 14:33:02 -0000 Received: from mercury.sun.com (192.9.25.1) by c900656-a.plstn1.sfba.home.com with SMTP; 4 May 2001 14:33:02 -0000 Received: from heliopolis.eng.sun.com ([152.70.1.39]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA27014; Fri, 4 May 2001 07:43:08 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id HAA24772; Fri, 4 May 2001 07:43:07 -0700 (PDT) Message-Id: <200105041443.HAA24772@heliopolis.eng.sun.com> Date: Fri, 4 May 2001 07:43:07 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: RE: [seamoby] updated problem statement To: James.Kempf@Sun.COM, seamoby@diameter.org, PRoberts@megisto.com, kulwinder.atwal@zucotto.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 5KCIwIwTkEOkG1qLLjCxvA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-seamoby@diameter.org Precedence: bulk Hi Kulwinder, While I appreciate the points you make, the point I was trying to make was that this is supposed to be a problem statement about a research activity. In research, it is best to let such questions open to encourage out of the box thinking. I'm sure you and I can exchange email back and forth on the list examining cases and discussing this and that, but I would rather see Abha and her team get a clear, unconstrained statement of the problem and let them go at it. jak >From: Kulwinder Atwal >To: "'James Kempf'" , seamoby@diameter.org, PRoberts@megisto.com >Subject: RE: [seamoby] updated problem statement >Date: Fri, 4 May 2001 04:57:50 -0400 > > > >> -----Original Message----- >> From: James Kempf [mailto:James.Kempf@sun.com] >> Sent: Thursday, May 03, 2001 12:14 PM >> To: seamoby@diameter.org; PRoberts@megisto.com >> Subject: Re: [seamoby] updated problem statement >> >> >> Hi Phil, >> >> The problem statement looks good, I've got just one comment. There >> seems to be an implicit assumption in the statement that the routing >> protocol which IRTF will come up with will be based on a standard >> wired subnet routing model. I think this assumption is >> somewhat limiting. > >It is not limiting. It is quite the opposite. Subnets allow route >aggregation, and thus scalability. > > >> Remember, we are talking about research. The model might end up >> being something between the completely ad hoc MANET model and >> the standard subnet model. > >MANET approaches do not seem too focused on scalability. > >> >> So, I'd suggest changing "subnet" to "network" or some other neutral >> term. > >Subnet is an useful term. It allows devices that move together to be >grouped into a mobile subnet. > >Take for example a collection of devices installed into a vehicle. Rather >than doing handoff for each device in a vechicle, the vechicle can be >treated as a mobile subnet. > >The entire subnet can be handed off with just one subnet prefix. >It has the added advantage that the subnetted devices do not have to be >"mobile aware". > >A collection of PCs and other devices mounted in a train would never have to >know that they were mobile. > >The idea of a subnet maps very well with the idea of a "Reference Frame" for >a 'body in motion' in Physics. >A mobile subnet extends the Physics idea of Relative Motion to IP. > > >- Kulwinder. > >> >> jak >> From owner-seamoby@diameter.org Fri May 4 22:57: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 WAA25954 for ; Fri, 4 May 2001 22:57:28 -0400 (EDT) Received: (qmail 8634 invoked by alias); 5 May 2001 02:45:35 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8628 invoked by uid 200); 5 May 2001 02:45:34 -0000 Received: (qmail 8623 invoked from network); 5 May 2001 02:45:32 -0000 Received: from www.bit-net.com (HELO mail.users.bit-net.com) (208.146.132.4) by c900656-a.plstn1.sfba.home.com with SMTP; 5 May 2001 02:45:32 -0000 Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA27826; Fri, 4 May 2001 22:55:39 -0400 Date: Fri, 4 May 2001 22:55:38 -0400 (EDT) From: Jim Bound To: john.loughney@nokia.com Cc: PRoberts@MEGISTO.com, seamoby@diameter.org Subject: RE: [seamoby] work that "needs" to get done and where In-Reply-To: <01D91AFB08B6D211BFD00008C7EABAE1077D1A17@eseis04nok> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk Hi John, > > does this inclue an IP RAN gateway for mm? in your mind john? > > While I might know what you are asking, can you expand on it? > What would the gateway do? If we moved to FULL IP. Then there will be a transition period. Part of that will be to take the bearer handoff services from that implementation to Mobile IP. During the transition there could be use for Gateways between the bearer and IP. Just thinking MM will be most complex and to perform at this point. The Mobile Terminals and infrasture will not change all at once. A RAN gateway may assist the deployment of MM. thanks /jim From owner-seamoby@diameter.org Mon May 7 15:27:14 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 PAA19867 for ; Mon, 7 May 2001 15:23:44 -0400 (EDT) Received: (qmail 10693 invoked by alias); 7 May 2001 19:02:56 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 10686 invoked by uid 200); 7 May 2001 19:02:56 -0000 Received: (qmail 10681 invoked from network); 7 May 2001 19:02:53 -0000 Received: from unknown (HELO zrc2s03g.us.nortel.com) (47.103.122.66) by c900656-a.plstn1.sfba.home.com with SMTP; 7 May 2001 19:02:53 -0000 Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id OAA23054 for ; Mon, 7 May 2001 14:13:21 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Mon, 7 May 2001 14:07:07 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 7 May 2001 14:12:32 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E43021EEF49@crchy271.us.nortel.com> From: "Glenn Morrow" To: Phil Roberts , "'seamoby@diameter.org'" Subject: RE: [seamoby] updated problem statement Date: Mon, 7 May 2001 14:12:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D729.A3BC46F0" 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_01C0D729.A3BC46F0 Content-Type: text/plain; charset="iso-8859-1" I likes it. -----Original Message----- From: Phil Roberts [mailto:PRoberts@MEGISTO.com] Sent: Wednesday, May 02, 2001 6:23 PM To: 'seamoby@diameter.org' Subject: [seamoby] updated problem statement I just submitted this to internet drafts. Text included below. Incorporated changes from several people including most of michael's comment. Personal P. Roberts Compiler Internet Draft Title: draft-proberts-localsubnetmobility- problem-00.txt Category: Informational May 2001 Expires : November 2001 Local Subnet Mobility Problem Statement Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Abstract This document specifies a problem statement for investigation within the IRTF. There are a couple of seemingly unrelated problems that have led investigators to converge on the desirability of implementing a routing protocol whose purpose is to allow a mobile node to retain connectivity via its current IP subnet while it moves within the scope of the micro mobility domain. In general this domain is expected to be contained within an autonomous system so that global aggregation of subnets is still preserved. An additional benefit of the protocols is that mobile nodes may more quickly react to failed links. The problem is to investigate the limits and issues with using (a) new protocol(s) to implement per node routes to facilitate better the movement of nodes and recovery of the network in the presence of failed links or routers. The document is a brief statement of the problem to be investigated with references to lots of other work that has been done already by many others in the area. 1 Internet Draft Local Subnet Mobility Problem Statement May 2001 1. Introduction The design of Internet routing has evolved largely based on the assumption that most end systems are stationary. As the idea of mobile devices came along, Mobile IP provided an easy migration path for supporting end system mobility without significant change or impact to the Internet infrastructure. This was achieved primarily by placing the support for routing to mobile devices on the end systems and at a limited number of centralized points within the infrastructure, effectively "hiding" the end system mobility from the infrastructure routing protocols. However, as we anticipate the desire to support real-time traffic flows to mobile devices and the possibility that mobile devices may become a significant portion of all Internet end nodes, investigation of alternative designs merit consideration. Many investigators in this area have converged on solutions that propose the use of local subnet mobility routing to support mobility within a limited domain, effectively exposing the mobility of end systems to the routers. This draft represents a problem statement to enable investigation of how a local subnet mobility routing protocol can be employed to enable mobility and fast network recovery. It is a problem statement based on a lot of work done in attempting to provide low latency handover in mobile networks and fast recovery in networks with fast recovery requirements. Please see the reference list for a large set of work that has been done in the past along these lines. A good summary of the problem as it pertains to network recovery is [MC]. The micromobility design team of the seamoby working group produced a problem statement also [SMM]. See the reference list for lots of previous work that has been done especially in the area of mobility with alternate proposals from Mobile IP. 2. Problem Statement This section proposes questions that have led to a perceived need for investigation of node routing within the IRTF. Why is there a perceived need for a non-tunnel-based routing solution for mobility? While Mobile IP provides transparency of the mobility to correspondent nodes communicating with hosts on the mobile network, Mobile IP does not provide transparency for any state contained within routers along the paths from correspondent nodes and the mobile node's home agent. That is, state in routers which is dependent on the stability of the source or destination address in the IP header will be negatively impacted by the mobile node's change of care of addresses. For example, when a mobile node changes its care of address, the mobile node's current reservation would require that the filter specs be updated with the new care of address. By instead treating the mobility as a topology change within the local area, these unpleasant second order effects can be avoided. Design Team 2 Internet Draft Local Subnet Mobility Problem Statement May 2001 2.1 Problem One There are applications that involve supporting real-time traffic flows to end devices that are mobile. These applications require that there be minimal (ideally no) interruption to the packet flows and that these flows need to preserve the existing QoS and security characteristics as the end station moves. In addition the movement of the end devices should not cause excessive signaling in the network as the devices move. Such applications often also run on networks in which link failures or router failures can cause a significant service disruption. Is it possible to use a similar protocol to allow for faster restoration of service during link failures. Could such mobility requirements and fast restoration requirements be met in a way that is more efficient and simpler than approaches based on Mobile IP and current intradomain routing protocols by using a routing protocol that implements local subnet mobility within a limited scope within the network? What would the limits of such a solution be in terms of scaling? Specifically how many nodes could be supported across what kind of network breadth and depth at what cost of complexity in the routers around the edge of such a network? Is it possible to meet traffic engineering requirements using such a protocol? Could it simplify management of QoS in the part of the network where mobility is most readily felt? 2.2 Problem Two One of the primary principles of the Internet has been end-to-end communication. Most (if not all) of the protocols running over IP have been designed with end-to-end signaling in mind. Currently, changes due to mobility induce unwanted end-to-end signaling. This may cause applications running over IP to fail due to delay and latency induced by unwanted signaling. Security, QoS and AAA signaling all suffer due to this. Could a local subnet mobility protocol aid in this respect? 2.3 Problem Three Why is there a need for an investigation of it in the IRTF rather than a direct move to work on a standard within a working group of the IETF? The area directors overseeing the activities of the seamoby working group and the mobile-ip working group have raised questions about the scale of local subnet mobility routing and the potential need to introduce both another routing protocol and another mobility protocol. A comparison with existing mobility management and routing protocols are involved in making such an assessment both in terms of relative scalability, performance, and complexity. 3. Acknowledgements The compiler would like to acknowledge all the contributors who have produced work relating to host routing for the various problems. Design Team 3 Internet Draft Local Subnet Mobility Problem Statement May 2001 References [MC] M. Scott Corson, A. O'Neill, G. Tsirtsis. IP Fast Restoration. Work in Progress. Draft-corson-fastrestore-00.txt, November 2000. [SMM] J. Loughney, et. al. "SeaMoby Micromobility Problem Statement." Work in Progress. Draft-ietf-seamoby-mm-problem-01.txt, February 2001. [FHO] G. Tsirtsis, et. al. "Fast Handovers for Mobile Ipv6." Work in Progress. Draft-ietf-mobileip-fast-mipv6-00.txt, February 2001. [MT] M. Thomas. "Analysis of Mobile IP and RSVP Interactions." Work in Progress. Draft-thomas-seamoby-rsvp-analysis-00.txt, February 2001. [CI] Z. Shelby, et. al. "Cellular IP v6." Work in Progress. Draft-shelby-seamoby-cellularipv6-00.txt, November 2000. [HSR] A. O'Neill. "Host Specific Routing." Work in Progress. Draft-oneill-li-hst-00.txt, November 2000. [IMMP] A. Campbell and J. Gomez. "IP Micro-mobility Protocols." ACM SIGMOBILE Mobile Computer and Communications Review (MC2R), 2001, available at http://www.comet.columbia.edu/micromobility. [CIP] Campbell, et. al. "Cellular IP." Work in Progress. Draft expired, but available at http://www.comet.columbia.edu/micromobility. [HAW] Ramjee, et. al. "Hawaii." Work in Progress. Draft expired, but available at http://www.comet.columbia.edu/micromobility. [EMA] M. Scott Corson, and Alan O'Neill. An Approach to Fixed/Mobile Converged Routing. University of Maryland, Institute for Systems Research, Technical Report, TR 2000-5. 2000. available at http://www.isr.umd.edu/TechReports/ISR/2000/TR_2000-5/TR_2000-5.phtml Addresses The compiler of this document is: Phil Roberts, Megisto Systems, Inc., proberts@megisto.com Design Team 4 ------_=_NextPart_001_01C0D729.A3BC46F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [seamoby] updated problem statement

I likes it.

-----Original Message-----
From: Phil Roberts [mailto:PRoberts@MEGISTO.com]
Sent: Wednesday, May 02, 2001 6:23 PM
To: 'seamoby@diameter.org'
Subject: [seamoby] updated problem statement



I just submitted this to internet drafts.  Text = included below.
Incorporated changes from several people including = most of michael's
comment. 


 

   = Personal          &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p; P. Roberts
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;            = Compiler
   Internet = Draft           &= nbsp;           &= nbsp;           &= nbsp;
   Title: = draft-proberts-localsubnetmobility-      &= nbsp; 
problem-00.txt
   Category: = Informational          = ;            = ;            May = 2001
   Expires : November = 2001           &n= bsp;           &n= bsp;   
   
   
   
          &nb= sp;           &nb= sp; Local Subnet Mobility Problem Statement
          &nb= sp;         = <draft-proberts-localsubnetmobility-problem-00.txt>
   
   
   Status of This Memo
   
   
   This document is an Internet-Draft and = is in full conformance with
   all provisions of Section 10 of = RFC2026.  Internet-Drafts are working
   documents of the Internet Engineering = Task Force (IETF), its areas,
   and its working groups.  Note that = other groups may also distribute
   working documents as Internet-Drafts. =
   
   Internet-Drafts are draft documents = valid for a maximum of six months
   and may be updated, replaced, or = obsoleted by other documents at
   any time.  It is inappropriate to = use Internet-Drafts as reference
   material or to cite them other than as = "work in progress."
   
   The list of current Internet-Drafts can = be accessed at:
        http://www.ietf.org/ietf/1id-abstracts.txt =
   The list of Internet-Draft Shadow = Directories can be accessed at:
        http://www.ietf.org/shadow.html.
   
   
          &nb= sp;           &nb= sp;          Abstract =
   
   This document specifies a problem = statement for investigation within
   the IRTF.  There are a couple of = seemingly unrelated problems that
   have led investigators to converge on = the desirability of
   implementing a routing protocol whose = purpose is to allow a mobile
   node to retain connectivity via its = current IP subnet while it moves
   within the scope of the micro mobility = domain. In general this domain
   is expected to be contained within an = autonomous system so that
   global aggregation of subnets is still = preserved. An additional
   benefit of the protocols is that mobile = nodes may more quickly react
   to failed links.  The problem is = to investigate the limits and issues
   with using (a) new protocol(s) to = implement per node routes to
   facilitate better the movement of nodes = and recovery of the network
   in the presence of failed links or = routers.  The document is a brief
   statement of the problem to be = investigated with references to lots
   of other work that has been done = already by many others in the area.  
    
   
 
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;          1 =0C
Internet Draft Local Subnet Mobility Problem = Statement       May 2001
 
 
   
   
1. Introduction
   
   The design of Internet routing has = evolved largely based on the
   assumption that most end systems are = stationary. As the idea of
   mobile devices came along, Mobile IP = provided an easy migration path
   for supporting end system mobility = without significant change or
   impact to the Internet infrastructure. = This was achieved primarily by
   placing the support for routing to = mobile devices on the end systems
   and at a limited number of centralized = points within the
   infrastructure, effectively = "hiding" the end system mobility from the
   infrastructure routing protocols. = However, as we anticipate the
   desire to support real-time traffic = flows to mobile devices and the
   possibility that mobile devices may = become a significant portion of
   all Internet end nodes, investigation = of alternative designs merit
   consideration. Many investigators in = this area have converged on
   solutions that propose the use of local = subnet mobility routing to
   support mobility within a limited = domain, effectively exposing the
   mobility of end systems to the routers. =
   
   This draft represents a problem = statement to enable investigation of
   how a local subnet mobility routing = protocol can be employed to
   enable mobility and fast network = recovery.  It is a problem statement
   based on a lot of work done in = attempting to provide low latency
   handover in mobile networks and fast = recovery in networks with fast
   recovery requirements.  Please see = the reference list for a large set
   of work that has been done in the past = along these lines.
   
   A good summary of the problem as it = pertains to network recovery is
   [MC].  The micromobility design = team of the seamoby working group
   produced a problem statement also = [SMM].  See the reference list for
   lots of previous work that has been = done especially in the area of
   mobility with alternate proposals from = Mobile IP.
   
2. Problem Statement
   
   This section proposes questions that = have led to a perceived need for
   investigation of node routing within = the IRTF.  Why is there a
   perceived need for a non-tunnel-based = routing solution for mobility? 
   While Mobile IP provides transparency = of the mobility to
   correspondent nodes communicating with = hosts on the mobile network,
   Mobile IP does not provide transparency = for any state contained
   within routers along the paths from = correspondent nodes and the
   mobile node's home agent. That is, = state in routers which is
   dependent on the stability of the = source or destination address in
   the IP header will be negatively = impacted by the mobile node's change
   of care of addresses. For example, when = a mobile node changes its
   care of address, the mobile node's = current reservation would require
   that the filter specs be updated with = the new care of address. By
   instead treating the mobility as a = topology change within the local
   area, these unpleasant second order = effects can be avoided. 
   
 
Design = Team           &n= bsp;           &n= bsp;           &n= bsp;           &n= bsp;          2 =0C
Internet Draft Local Subnet Mobility Problem = Statement       May 2001
 
 
2.1 Problem One 
   
   There are applications that involve = supporting real-time traffic
   flows to end devices that are = mobile.  These applications require
   that there be minimal (ideally no) = interruption to the packet flows
   and that these flows need to preserve = the existing QoS and security
   characteristics as the end station = moves.  In addition the movement
   of the end devices should not cause = excessive signaling in the
   network as the devices move.  Such = applications often also run on
   networks in which link failures or = router failures can cause a
   significant service disruption.  = Is it possible to use a similar
   protocol to allow for faster = restoration of service during link
   failures.  Could such mobility = requirements and fast restoration
   requirements be met in a way that is = more efficient and simpler than
   approaches based on Mobile IP and = current intradomain routing
   protocols by using a routing protocol = that implements local subnet
   mobility within a limited scope within = the network?  What would the
   limits of such a solution be in terms = of scaling?  Specifically how
   many nodes could be supported across = what kind of network breadth and
   depth at what cost of complexity in the = routers around the edge of
   such a network?  Is it possible to = meet traffic engineering
   requirements using such a = protocol?  Could it simplify management of
   QoS in the part of the network where = mobility is most readily felt?
   
2.2 Problem Two
   
   One of the primary principles of the = Internet has been end-to-end 
   communication. Most (if not all) of the = protocols running over IP
   have been designed with end-to-end = signaling in mind.  Currently,
   changes due to mobility induce unwanted = end-to-end signaling. This
   may cause applications running over IP = to fail due to delay and
   latency induced by unwanted = signaling.  Security, QoS and AAA
   signaling all suffer due to this.  = Could a local subnet mobility
   protocol aid in this respect?
   
2.3 Problem Three
   
   Why is there a need for an = investigation of it in the IRTF rather
   than a direct move to work on a = standard within a working group of
   the IETF?  The area directors = overseeing the activities of the
   seamoby working group and the mobile-ip = working group have raised
   questions about the scale of local = subnet mobility routing and the
   potential need to introduce both = another routing protocol and another
   mobility protocol. A comparison with = existing mobility management and
   routing protocols are involved in = making such an assessment both in
   terms of relative scalability, = performance, and complexity.
   
   
3. Acknowledgements
   
   The compiler would like to acknowledge = all the contributors who have
   produced work relating to host routing = for the various problems.  
   
 
Design = Team           &n= bsp;           &n= bsp;           &n= bsp;           &n= bsp;          3 =0C
Internet Draft Local Subnet Mobility Problem = Statement       May 2001
 
 
   
References
   
    [MC] M. Scott Corson, A. O'Neill, = G. Tsirtsis.  IP Fast Restoration. 
Work in Progress.  = Draft-corson-fastrestore-00.txt, November 2000.
    [SMM] J. Loughney, et. al.  = "SeaMoby Micromobility Problem
Statement."  Work in Progress.  = Draft-ietf-seamoby-mm-problem-01.txt,
February 2001.
    [FHO] G. Tsirtsis, et. al.  = "Fast Handovers for Mobile Ipv6."  Work
in Progress.  = Draft-ietf-mobileip-fast-mipv6-00.txt, February 2001.
    [MT] M. Thomas.  = "Analysis of Mobile IP and RSVP Interactions." 
Work in Progress.  = Draft-thomas-seamoby-rsvp-analysis-00.txt, February
2001.
    [CI] Z. Shelby, et. al.  = "Cellular IP v6."  Work in Progress. 
Draft-shelby-seamoby-cellularipv6-00.txt, November = 2000.
    [HSR] A. O'Neill.  = "Host Specific Routing."  Work in Progress.  =
Draft-oneill-li-hst-00.txt, November 2000.
    [IMMP] A. Campbell and J. = Gomez.  "IP Micro-mobility Protocols." 
ACM SIGMOBILE Mobile Computer and Communications = Review (MC2R), 2001,
available at http://www.comet.columbia.edu/micromobility. =
    [CIP] Campbell, et. al.  = "Cellular IP."  Work in Progress.  Draft
expired, but available at http://www.comet.columbia.edu/micromobility. =
    [HAW] Ramjee, et. al.  = "Hawaii."  Work in Progress.  Draft expired, =
but available at http://www.comet.columbia.edu/micromobility. =
    [EMA] M. Scott Corson, and Alan = O'Neill. An Approach to Fixed/Mobile
   Converged Routing. University of = Maryland, Institute for Systems
Research,
   Technical Report, TR 2000-5. 2000. = available at
   http://www.isr.umd.edu/TechReports/ISR/2000/TR_2000-5/= TR_2000-5.phtml
   
   
   
Addresses
   
   The compiler of this document is: =
   
   Phil Roberts, Megisto Systems, Inc., = proberts@megisto.com
   
   














 
Design = Team           &n= bsp;           &n= bsp;           &n= bsp;           &n= bsp;          4

------_=_NextPart_001_01C0D729.A3BC46F0-- From owner-seamoby@diameter.org Tue May 8 03:50: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 DAA16975 for ; Tue, 8 May 2001 03:50:19 -0400 (EDT) Received: (qmail 16239 invoked by alias); 8 May 2001 07:38:46 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 16233 invoked by uid 200); 8 May 2001 07:38:46 -0000 Received: (qmail 16228 invoked from network); 8 May 2001 07:38:44 -0000 Received: from mgw-x2.nokia.com (131.228.20.22) by c900656-a.plstn1.sfba.home.com with SMTP; 8 May 2001 07:38:44 -0000 Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f487nIS24370 for ; Tue, 8 May 2001 10:49:18 +0300 (EET DST) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 8 May 2001 10:49:02 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Tue, 8 May 2001 10:49:01 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680AE87@eseis04nok> From: john.loughney@nokia.com To: seamus@bit-net.com Cc: seamoby@diameter.org Subject: RE: [seamoby] work that "needs" to get done and where Date: Tue, 8 May 2001 10:49:00 +0300 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 Jim, > If we moved to FULL IP. Then there will be a transition > period. Part of that will be to take the bearer handoff services > from that implementation to Mobile IP. During the transition there > could be use for Gateways between the bearer and IP. Just thinking > MM will be most complex and to perform at this point. The Mobile > Terminals and infrasture will not change all at once. A RAN gateway > may assist the deployment of MM. I concur, in a general sense. However, I lack sufficient processing capabilities to concieve of transition issues for a yet undone MM protocol. Hopefully, by handling MM in the IRTF, this work can be done and not hinder the current deployment of MIP. When this MM work is done, then we consider how it can be transitioned to. John From owner-seamoby@diameter.org Tue May 8 09:20: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 JAA21184 for ; Tue, 8 May 2001 09:20:46 -0400 (EDT) Received: (qmail 18412 invoked by alias); 8 May 2001 13:08:41 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 18406 invoked by uid 200); 8 May 2001 13:08:41 -0000 Received: (qmail 18401 invoked from network); 8 May 2001 13:08:39 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by c900656-a.plstn1.sfba.home.com with SMTP; 8 May 2001 13:08:39 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20877; Tue, 8 May 2001 09:18:57 -0400 (EDT) Message-Id: <200105081318.JAA20877@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: seamoby@cdma-2000.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [seamoby] I-D ACTION:draft-ietf-seamoby-paging-problem-statement-03.txt Date: Tue, 08 May 2001 09:18:56 -0400 Sender: owner-seamoby@diameter.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Context and Micro-mobility Routing Working Group of the IETF. Title : Dormant Mode Host Alerting ('IP Paging') Problem Statement Author(s) : J. Kempf Filename : draft-ietf-seamoby-paging-problem-statement-03.txt Pages : 14 Date : 07-May-01 The IESG has requested that the Seamoby Working Group develop a problem statement about the need for additional protocol work to support alerting of dormant mode mobile hosts, commonly known as IP paging, for seamless IP mobility. The paging design team interpreted this as direction to examine whether location of a mobile node in power saving mode can be supported by the existing Mobile IPv4 and Mobile IPv6 protocols given existing radio link protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-seamoby-paging-problem-statement-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-seamoby-paging-problem-statement-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-seamoby-paging-problem-statement-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010507125217.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-seamoby-paging-problem-statement-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-seamoby-paging-problem-statement-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010507125217.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-seamoby@diameter.org Tue May 8 09:23: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 JAA21298 for ; Tue, 8 May 2001 09:23:31 -0400 (EDT) Received: (qmail 18914 invoked by alias); 8 May 2001 13:11:35 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 18908 invoked by uid 200); 8 May 2001 13:11:35 -0000 Received: (qmail 18903 invoked from network); 8 May 2001 13:11:33 -0000 Received: from www.bit-net.com (HELO mail.users.bit-net.com) (208.146.132.4) by c900656-a.plstn1.sfba.home.com with SMTP; 8 May 2001 13:11:33 -0000 Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA25086; Tue, 8 May 2001 09:21:55 -0400 Date: Tue, 8 May 2001 09:21:55 -0400 (EDT) From: Jim Bound To: john.loughney@nokia.com Cc: seamoby@diameter.org Subject: RE: [seamoby] work that "needs" to get done and where In-Reply-To: <01D91AFB08B6D211BFD00008C7EABAE10680AE87@eseis04nok> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk Hi John, Agreed. thanks /jim On Tue, 8 May 2001 john.loughney@nokia.com wrote: > Hi Jim, > > > If we moved to FULL IP. Then there will be a transition > > period. Part of that will be to take the bearer handoff services > > from that implementation to Mobile IP. During the transition there > > could be use for Gateways between the bearer and IP. Just thinking > > MM will be most complex and to perform at this point. The Mobile > > Terminals and infrasture will not change all at once. A RAN gateway > > may assist the deployment of MM. > > I concur, in a general sense. However, I lack sufficient processing > capabilities to concieve of transition issues for a yet undone > MM protocol. Hopefully, by handling MM in the IRTF, this work can > be done and not hinder the current deployment of MIP. When this > MM work is done, then we consider how it can be transitioned to. > > John > From owner-seamoby@diameter.org Wed May 9 09:36:14 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06389 for ; Wed, 9 May 2001 09:36:13 -0400 (EDT) Received: (qmail 25113 invoked by alias); 9 May 2001 13:24:33 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 25106 invoked by uid 200); 9 May 2001 13:24:32 -0000 Received: (qmail 25098 invoked from network); 9 May 2001 13:24:30 -0000 Received: from mgw-x3.nokia.com (131.228.20.26) by c900656-a.plstn1.sfba.home.com with SMTP; 9 May 2001 13:24:30 -0000 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f49DZWv22673; Wed, 9 May 2001 16:35:32 +0300 (EET DST) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 9 May 2001 16:34:53 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Wed, 9 May 2001 16:34:53 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680AEA6@eseis04nok> From: john.loughney@nokia.com To: pcalhoun@diameter.org Cc: seamoby@diameter.org Subject: RE: [seamoby] work that "needs" to get done and where Date: Wed, 9 May 2001 16:34:45 +0300 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 Pat, > FWIW, I am waiting for the new charter to be approved, which > would include this very work item. So, since it isn't in the > charter, perhaps people are reluctant to work on it. However, > if people still aren't that interested once the new charter > is available, then I will be confused. I do recall > people complaining a whole lot about MIP on the list, and no one is > willing to work on fixing it.... Does this mean that we should wait until the charter is updated before doing anything on a DT basis? I have a large handful of people who have said they could do something. John From owner-seamoby@diameter.org Wed May 9 10:04:38 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07256 for ; Wed, 9 May 2001 10:04:37 -0400 (EDT) Received: (qmail 26018 invoked by alias); 9 May 2001 13:53:26 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 26012 invoked by uid 200); 9 May 2001 13:53:25 -0000 Received: (qmail 26003 invoked by uid 500); 9 May 2001 13:53:24 -0000 Date: Wed, 9 May 2001 06:53:24 -0700 From: Pat Calhoun To: john.loughney@nokia.com Cc: pcalhoun@diameter.org, seamoby@diameter.org Subject: Re: [seamoby] work that "needs" to get done and where Message-ID: <20010509065324.D12425@charizard.diameter.org> Mail-Followup-To: john.loughney@nokia.com, pcalhoun@diameter.org, seamoby@diameter.org References: <01D91AFB08B6D211BFD00008C7EABAE10680AEA6@eseis04nok> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01D91AFB08B6D211BFD00008C7EABAE10680AEA6@eseis04nok>; from john.loughney@nokia.com on Wed, May 09, 2001 at 04:34:45PM +0300 Sender: owner-seamoby@diameter.org Precedence: bulk On Wed, May 09, 2001 at 04:34:45PM +0300, john.loughney@nokia.com wrote: > Hi Pat, > > > FWIW, I am waiting for the new charter to be approved, which > > would include this very work item. So, since it isn't in the > > charter, perhaps people are reluctant to work on it. However, > > if people still aren't that interested once the new charter > > is available, then I will be confused. I do recall > > people complaining a whole lot about MIP on the list, and no one is > > willing to work on fixing it.... > > Does this mean that we should wait until the charter is updated > before doing anything on a DT basis? I have a large handful of > people who have said they could do something. No need to wait, I was just making a statement on the charter. PatC From owner-seamoby@diameter.org Wed May 9 18:22:56 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27431 for ; Wed, 9 May 2001 18:22:47 -0400 (EDT) Received: (qmail 30230 invoked by alias); 9 May 2001 22:07:10 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 30224 invoked by uid 200); 9 May 2001 22:07:09 -0000 Received: (qmail 30214 invoked from network); 9 May 2001 22:07:06 -0000 Received: from a24b31n80client230.hawaii.rr.com (HELO pavilion) (24.31.80.230) by c900656-a.plstn1.sfba.home.com with SMTP; 9 May 2001 22:07:06 -0000 Message-ID: <1897320015392292920@pavilion> X-EM-Version: 5, 0, 0, 19 X-EM-Registration: #01B0530810E603002D00 X-Priority: 3 X-MSMail-Priority: Normal From: "Mitchell" To: seamoby@cdma-2000.org Subject: [seamoby] Business/Employment Opportunity Date: Wed, 9 May 2001 12:09:29 -1000 MIME-Version: 1.0 Content-type: text/plain; charset="US-ASCII" Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA27431 Dear Friend: "Making over half million dollars every 4 to 5 months from your home for an investment of only $25 U.S. Dollars expense one time" THANKS TO THE COMPUTER AGE AND THE INTERNET! =============================================== BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR !! Before you say "Bull" , please read the following. This is the letter you have been hearing about on the news lately. Due to the popularity of this letter on the internet, a national weekly news program recently devoted an entire show to the investigation of this program described below , to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are "absolutely no laws prohibiting the participation in the program and if people can follow the simple instructions, they are bound to make some mega bucks with only $25 out of pocket cost". DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING BETTER THAN EVER. This is what one had to say: "Thanks to this profitable opportunity. I was approached many times before but each time I passed on it. I am so glad I finally joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received total $ 610,470.00 in 21 weeks, with money still coming in". Pam Hedland, Fort Lee, New Jersey. ------------------------------------------------------------------------- Here is another testimonial: "This program has been around for a long time but I never believed in it. But one day when I received this again in the mail I decided to gamble my $25 on it. I followed thesimple instructions and walaa ..... 3 weeks later the money started to come in. First month I only made $240.00 but the next 2 months after that I made a total of $290,000.00. So far, in the past 8 months by re-entering the program,I have made over $710,000.00 and I am playing it again. The key to success in this program is to follow the simple steps and NOT change anything ." More testimonials later but first, ****** PRINT THIS NOW FOR YOUR FUTURE REFERENCE ******* $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make at least $500,000 every 4 to 5 months easily and comfortably, please read the following...THEN READ IT AGAIN and AGAIN !!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL DREAMS WILL COME TRUE, GUARANTEED! INSTRUCTIONS: **** Order all 5 reports shown on the list below. **** For each report, send $5 CASH, THE NAME & NUMBER OF THE REPORT YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the person whose name appears ON THAT LIST next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mail problems. **** When you place your order, make sure you order each of the 5 reports. You will need all 5 reports so that you can save them on your computer and resell them. YOUR TOTAL COST $5 X 5 = $25.00. **** Within a few days you will receive, via e-mail, each of the 5 reports from these 5 different individuals. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. Also make a floppy of these reports and keep it on your desk in case something happen to your computer. ****.IMPORTANT - DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than what is instructed below in steps 1 through6 or you will loose out on majority of your profits. Once you understand the way this works, you will also see how it does not work if you change it. Remember, this method has been tested, and if you alter, it will NOT work!!! People have tried to put their friends/relatives names on all five thinking they could get all the money. But it does not work this way. Believe us, we all have tried to be greedy and then nothing happened. So Do Not try to change anything other than what is instructed. Because if you do, it will not work for you. Remember, honesty reaps the reward!!! 1.. After you have ordered all 5 reports, take this advertisement and REMOVE the name & address of the person in REPORT # 5. This person has made it through the cycle and is no doubt counting their fortune. 2.... Move the name & address in REPORT # 4 down TO REPORT # 5. 3.... Move the name & address in REPORT # 3 down TO REPORT # 4. 4.... Move the name & address in REPORT # 2 down TO REPORT # 3. 5.... Move the name & address in REPORT # 1 down TO REPORT # 2 6.... Insert YOUR name & address in the REPORT # 1 Position. PLEASE MAKE SURE you copy every name & address ACCURATELY ! ========================================================= Take this entire letter, with the modified list of names, and save it on your computer. DO NOT MAKE ANY OTHER CHANGES. Save this on a disk as well just in case if you loose any data. To assist you with marketing your business on the internet, the 5 reports you purchase will provide you with invaluable marketing information which includes how to send bulk e-mails legally, where to find thousands of free classified ads and much more. There are 2 Primary methods to get this venture going: METHOD # 1 : BY SENDING BULK E-MAIL LEGALLY ============================================ let's say that you decide to start small, just to see how it goes, and we will assume You and those involved send out only 5,000 e-mails each. Let's also assume that the mailing receive only a0.2% response (the response could be much better but lets just say it is only 0.2% . Also many people will send out hundreds of thousands e-mails instead of only 5,000 each). Continuing with this example, you send out only 5,000 e-mails. With a 0.2% response, that is only 10 orders for report # 1. Those 10 people responded by sending out 5,000 e-mail each for a total of 50,000. Out of those 50,000 e-mails only 0.2% responded with orders. That's = 100 people responded and ordered Report # 2. Those 100 people mail out 5,000 e-mails each for a total of 500,000 e-mails. The 0.2% response to that is 1000 orders for Report # 3. Those 1000 people send out 5,000 e-mails each for a total of 5 million e-mails sent out. The 0.2% response to that is 10,000 orders for Report # 4. Those 10,000 people send out 5,000 e-mails each for a total of 50,000,000 (50 million) e-mails. The 0.2% response to that is 100,000 orders for Report # 5. THAT'S 100,000 ORDERS TIMES $5 EACH = $500,000.00 (half million). Your total income in this example is: 1..... $50 + 2..... $500 + 3..... $5,000 + 4..... $50,000 + 5..... $500,000 ......... Grand Total = $555,550.00 NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE OUT THE WORST POSSIBLE RESPONSES AND NO MATTER HOW YOU CALCULATE IT, YOU WILL STILL MAKE A LOT OF MONEY ! ------------------------------------------------------------------------------ REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE ORDERING OUT OF 5,000 YOU MAILED TO. Dare to think for a moment what would happen if everyone, or half or even one 4th of those people mailed 100,000 e-mails each or more? There are over 250 million people on the internet worldwide and counting. Believe me, many people will do just that, and more! METHOD # 2 : BY PLACING FREE ADS ON THE INTERNET =================================================== Advertising on the net is very very inexpensive and there are hundreds of FREE places to advertise. Placing a lot of free adson the internet will easily get a larger response. We strongly suggest you start with Method # 1 and add METHOD # 2 as you go along. For every $5 you receive, all you must do is e-mail them the Report they ordered. That's it . Always provide same day service on all orders. This will guarantee that the e-mail they send out, with your name and address on it, will be prompt because they can not advertise until they receive the report. _____________________ AVAILABLE REPORTS_____________________ ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes: Always send $5 cash (U.S. CURRENCY) for each Report. Checks NOT accepted. Make sure the cash is concealed by wrapping it in at least 2 sheets of paper. On one of those sheets of paper, Write the NUMBER & the NAME of the Report you are ordering, YOUR E-MAIL ADDRESS and your name and postal address. PLACE YOUR ORDER FOR THESE REPORTS NOW : ============================================== REPORT #1, "The Insider's Guide to Sending Bulk E-mail on the Internet" ORDER REPORT #1 FROM: G. Donaldson P.O. Box 25884 Honolulu, Hawaii 96825-0884 don't forget to provide a permanent e-mail address in clear writing (better typed) to receive the reports. We had problems in delivery e-mails before!!! ============================================== REPORT #2 "The Insider's Guide to Advertising for Free on the Internet" ORDER REPORT #2 FROM: Vijay Paul C-291, Second Floor Defence Colony New Delhi - 110024 INDIA ============================================== REPORT #3 "The Secrets to Multilevel Marketing on the Internet" ORDER REPORT #3 FROM: JD P.O.Box 1114 Des Plaines, IL 60017 USA ============================================== REPORT #4 "How to become a Millionaire utilizing the Power of Multilevel Marketing and the Internet" ORDER REPORT #4 FROM: J Santi 833 Walter Ave Des Plaines, IL 60016 USA ============================================== REPORT #5 "How to SEND 1,000,000 e-mails for FREE" ORDER REPORT #5 FROM: Elaine Rix 138 Dundas Street, West, #243 Toronto, Ontario Canada M5G 1C3 ============================================== There are currently more than 250,000,000 people online worldwide! $$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$ Follow these guidelines to guarantee your success: If you do not receive at least 10 orders for Report #1 within 2 weeks, continue sending e-mails until you do. After you have received 10 orders, 2 to 3 weeks after that you should receive 100 orders or more for REPORT # 2. If you did not, continue advertising or sending e-mails until you do. Once you have received 100 or more orders for Report # 2, YOU CAN RELAX, because the system is already working for you , and the cash will continue to roll in ! THIS IS IMPORTANT TO REMEMBER : Every time your name is moved down on the list, you are placed in front of a different report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. IF YOU WANT TO GENERATE MORE INCOME SEND ANOTHER BATCH OF E-MAILS AND START THE WHOLE PROCESS AGAIN. There is NO LIMIT to the income you can generate from this business !!! ____________________________________________________ FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS PROGRAM: You have just received information that can give you financial freedom for the rest of your life, with NO RISK and JUST A LITTLE BIT OF EFFORT. You can make more money in the next few weeks and months than you have ever imagined. Follow the program EXACTLY AS INSTRUCTED. Do Not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report after you have put your name and address in Report #1 and moved others to #2...........# 5 as instructed above. One of the people you send this to may send out 100,000 or more e-mails and your name will be on everyone of them. Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU NOW ! ************** MORE TESTIMONIALS **************** "My name is Mitchell. My wife , Jody and I live in Chicago. I am an accountant with a major U.S. Corporation and I make pretty good money. When I received this program I grumbled to Jody about receiving ''junk mail''. I made fun of the whole thing, spouting my knowledge of the population and percentages involved. I ''knew'' it wouldn't work. Jody totally ignored my supposed intelligence and few days later she jumped in with both feet. I made merciless fun of her, and was ready to lay the old ''I told you so'' on her when the thing didn'twork. Well, the laugh was on me! Within 3 weeks she had received 50 responses. Within the next 45 days she had received a total of $ 147,200.00 all cash! I was shocked. I have joined Jody in her ''hobby''." Mitchell Wolf, Chicago, Illinois ------------------------------------------------------------ "Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back. I was surprised when I found my medium size post office box crammed with orders. I made $319,210.00 in the first 12 weeks. The nice thing about this deal is that it does not matter where people live. There simply isn't a better investment with a faster return and so big." Dan Sondstrom, Alberta, Canada ----------------------------------------------------------- "I had received this program before. I deleted it, but later I wondered if I should have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed again by someone else.........11 months passed then it luckily came again...... I did not delete this one! I made more than $490,000 on my first try and all the money came within 22 weeks". Susan De Suza, New York, N.Y. ---------------------------------------------------- "It really is a great opportunity to make relatively easy money with little cost to you. I followed the simple instructions carefully and within 10 days the money started to come in. My first month I made $ 20,560.00 and by the end of third month my total cash count was $ 362,840.00. Life is beautiful, Thanx to internet". Fred Dellaca, Westport, New Zealand ------------------------------------------------------------ ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO FINANCIAL FREEDOM ! ======================================================= If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection, Washington, D.C. Under Bill s.1618 TITLE III passed by the 105th US Congress this letter cannot be considered spam as long as the sender includes contact information and a method of removal. This is one time e-mail transmission. No request for removal is necessary. ------------------------------------------------------------ This message is sent in compliance of the new email Bill HR 1910. Under Bill HR 1910 passed by the 106th US Congress on May 24, 1999, this message cannot be considered Spam as long as we include the way to be removed. Per Section HR 1910, Please type "REMOVE" in the subject line and reply to this email. All removal requests are handled personally an immediately once received. From owner-seamoby@diameter.org Thu May 10 17:17:22 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA08495 for ; Thu, 10 May 2001 17:17:21 -0400 (EDT) Received: (qmail 5926 invoked by alias); 10 May 2001 21:04:10 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 5920 invoked by uid 200); 10 May 2001 21:04:10 -0000 Received: (qmail 5915 invoked from network); 10 May 2001 21:04:08 -0000 Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.nortelnetworks.com) (47.129.242.157) by c900656-a.plstn1.sfba.home.com with SMTP; 10 May 2001 21:04:08 -0000 Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id RAA24802; Thu, 10 May 2001 17:14:01 -0400 Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Thu, 10 May 2001 17:13:54 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 May 2001 17:13:55 -0400 Message-ID: From: "Muhammad Jaseemuddin" To: seamoby@cdma-2000.org Subject: [seamoby] CFP: SPECIAL SESSION ON RESOURCE MANAGEMENT FOR WIRELESS MULTIMED IA Date: Thu, 10 May 2001 17:13:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D996.1F5415E0" 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_01C0D996.1F5415E0 Content-Type: text/plain SPECIAL SESSION ON RESOURCE MANAGEMENT FOR WIRELESS MULTIMEDIA IFIP/IEEE International Conference on Management of Multimedia Networks and Services (IFIP/IEEE MMNS2001) October 29- November 1, 2001, Chicago, Illinois, USA http://www.mnlab.cs.depaul.edu/mmns2001 Broadband wireless multimedia services are becoming very popular. This special session will focus on architectures and techniques for supporting QoS in future wireless multimedia networks. The session is looking for original contributions in this demanding area that address issues related to both networking and wireless systems. This includes integration of personal wireless multimedia into the Internet, efficient resource management techniques in wireless access netowrks that consider internet QoS models, the limited resources in wireless systems, such as spectrum resource and transmitter power, mobility management, bandwidth allocation, location and handoff procedures, channel access and assignment, call admission control, and end-to-end adaptive control for wireless multimedia. You can submit papers on-line using the keyword SPECIAL SESSION ON RESOURCE MANAGEMENT FOR WIRELESS MULTIMEDIA either to the conference website or to jaseem@nortelnetworks.com. The deadline for paper submission for this special session is May 31, 2001. For questions about this special session, contact: Muhammad Jaseemuddin Nortel Networks P.O. Box 3511 Station C Ottawa, ON K1Y 4H7 Canada Tel: +1 613 765-7520 Email: jaseem@nortelnetworks.com ------_=_NextPart_001_01C0D996.1F5415E0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable CFP: SPECIAL SESSION ON RESOURCE MANAGEMENT FOR WIRELESS = MULTIMEDIA

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

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

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

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




------_=_NextPart_001_01C0D996.1F5415E0-- From owner-seamoby@diameter.org Fri May 11 16:24:41 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19942 for ; Fri, 11 May 2001 16:24:38 -0400 (EDT) Received: (qmail 11999 invoked by alias); 11 May 2001 20:04:15 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 11993 invoked by uid 200); 11 May 2001 20:04:14 -0000 Received: (qmail 11988 invoked from network); 11 May 2001 20:04:12 -0000 Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.nortelnetworks.com) (47.129.242.157) by c900656-a.plstn1.sfba.home.com with SMTP; 11 May 2001 20:04:12 -0000 Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id QAA14031; Fri, 11 May 2001 16:14:09 -0400 Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Fri, 11 May 2001 16:14:02 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 May 2001 16:14:04 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C1258F5@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'seamoby'" Cc: "'Allison Mankin'" , "'Pat Calhoun'" Subject: [seamoby] version 01 of the Context Transfer Problem Statement Date: Fri, 11 May 2001 16:14:01 -0400 Importance: high X-Priority: 1 Sensitivity: Company-Confidential MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0DA56.EAF596E0" 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_000_01C0DA56.EAF596E0 Content-Type: text/plain; charset="ISO-8859-1" Here is the revised Seamoby Context Transfer Problem statement. It has been modified in response to feedback received from the area directors. Gary Kenward ------_=_NextPart_000_01C0DA56.EAF596E0 Content-Type: text/plain; name="draft-ietf-seamoby-context-transfer-problem-stat-01.txt" Content-Disposition: attachment; filename="draft-ietf-seamoby-context-transfer-problem-stat-01.txt" Content-Transfer-Encoding: quoted-printable =20 Context and Micro-mobility Routing Working Group O. H. = Levkowetz Internet Draft = ABNW draft-ietf-seamoby-context-transfer-problem- P. R. = Calhoun 01.doc Sun = MicroSystems, Inc Expires: November 2001 G. = Kenward H. M. = Syed Nortel = Networks J. = Manner University of = Helsinki M. = Nakhjiri = Motorola G. = Krishnamurthi R. = Koodli = Nokia K. S. = Atwal Zucotto = Wireless M. = Thomas = Cisco M. = Horan = COM DEV P. = Neumiller = 3Com May = 2001 =20 =20 Problem Description: Reasons For Performing Context Transfers = Between Nodes in an IP Access Network=20 =20 Status of This Memo=20 =20 This document is an Internet-Draft and is in full conformance = with=20 all provisions of Section 10 of RFC2026.=20 =20 Internet-Drafts are working documents of the Internet = Engineering=20 Task Force (IETF), its areas, and its working groups. Note that = other groups may also distribute working documents as Internet- Drafts.=20 =20 Internet-Drafts are draft documents valid for a maximum of six=20 months and may be updated, replaced, or obsoleted by other = documents=20 at any time. It is inappropriate to use Internet-Drafts as = reference=20 material or to cite them other than as "work in progress."=20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt.=20 =20 The list of Internet-Draft Shadow Directories can be accessed = at=20 http://www.ietf.org/shadow.html.=20 =20 Copyright Notice=20 =20 Copyright (C) The Internet Society (2001). All Rights Reserved. = =20 Levkowetz et al. = [Page 1] =0D=0C =0D Internet Draft May = 2001=20 draft-ietf-seamoby-context-transfer-problem-01.txt=20 =20 Abstract=20 =20 There are a large number of IP access networks that support = mobility=20 of hosts. For example, wireless Personal Area Networks (PANs),=20 wireless LANs, satellite WANs and cellular WANs. The nature of = this=20 mobility is such that the communication path to the host = changes=20 frequently and rapidly. =20 =20 This Internet-Draft describes the problem encountered during=20 mobility that requires the exchange of IP context between = different=20 forwarding nodes in an access network.=20 =20 Table of Contents=20 =20 1 = Introduction...................................................2=20 2 Reference Definitions.........................................= .3=20 3 The Need for Context = Transfer..................................4=20 3.1 Scope of the Context Transfer Solution = .....................5=20 3.2 Reference Architectures = ....................................6=20 4 A Description of = Context.......................................6=20 4.1 Feature = ....................................................6=20 4.2 Feature Context = ............................................7=20 4.3 Microflow Context = ..........................................7=20 4.4 Common Context = .............................................7=20 4.5 Examples of Feature Context = ................................7=20 5 Context Transfer and = Mobility..................................8=20 6 Forwarding Node = Capabilities...................................8=20 7 Inter-technology Context = Transfers.............................8=20 8 Performance = Considerations.....................................8=20 9 Security = Considerations........................................9=20 10 = Recommendations...............................................9=20 =20 =20 1 Introduction=20 =20 There are a large number of IP access networks that support = hosts=20 that are mobile. For example, wireless Personal Area Networks=20 (PANs), wireless LANs, satellite WANs and cellular WANs. The = nature=20 of this mobility is such that the communication path to a host = may=20 change frequently and rapidly. =20 =20 In networks where the hosts are mobile, the forwarding path = through=20 the access network must often be redirected in order to deliver = the=20 host's IP traffic to the new point of access. The success of a = time=20 sensitive service such as VoIP telephony, video, etc., in a = mobile=20 environment depends heavily upon the minimization of the impact = of=20 this traffic redirection. In the process of establishing the = new=20 forwarding path, the nodes along the new path must be prepared = to=20 provide similar forwarding treatment to the IP packets. =20 =20 =20 Levkowetz et al. = [Page 2] =0D=0C =0D Internet Draft May = 2001=20 draft-ietf-seamoby-context-transfer-problem-01.txt=20 =20 The information required in support of a specific forwarding=20 treatment provided to IP traffic is part of the context for = that=20 traffic. This context is comprised of configuration and state=20 information. To minimize the impact of a path change on an IP = flow,=20 the context used at the forwarding nodes along the original = path,=20 must be replicated at the forwarding nodes along the new path.=20 =20 The transfer of context information may be advantageous in=20 minimizing the impact of host mobility on, for example, AAA, = header=20 compression, QoS, Policy, and possibly sub-IP protocols and = services=20 such as PPP. Context transfer at a minimum will be used to = replicate=20 the configuration information needed to establish the = respective=20 protocols and services. In addition, it may also provide the=20 capability to replicate state information, allowing stateful=20 protocols and services at the new node to be activated along = the new=20 path with less delay and less signalling overhead.=20 =20 2 Reference Definitions=20 =20 Mobile Node=20 =20 An IP node capable of changing its point of attachment to the=20 network. The mobile node is usually an end user host, but may = be a=20 forwarding node for a network that is itself mobile. =20 =20 Forwarding Node=20 =20 A node that supports IP forwarding within the access network. = This=20 includes all routers, gateways, servers and other nodes within = the=20 network that have IP protocol stacks and forward IP traffic to = and=20 from a mobile node.=20 =20 A forwarding node will be connected to one or more other = forwarding=20 nodes. Some forwarding nodes will be connected to zero or more=20 mobile nodes. The forwarding nodes that connect to mobile nodes = will=20 do so through a layer two entity that supports wireless=20 communications. =20 =20 Microflow=20 =20 One useful definition for the fundamental unit of IP service is = the=20 microflow. RFC 2475 [1] defines a microflow as:=20 =20 A single instance of an application-to application flow of = packets=20 destined to or originated from a mobile device (MN or MH), = which is=20 identified by source address, source port, destination address, = destination port and protocol id.=20 =20 =20 Levkowetz et al. = [Page 3] =0D=0C =0D Internet Draft May = 2001=20 draft-ietf-seamoby-context-transfer-problem-01.txt=20 =20 RFC 2207 [2] provides a definition of a microflow that applies = to=20 IPSec packets. It is based on the IPSec SPI found in the AH or = ESP=20 headers. Other methods for identifying for IP microflows may be = defined in the future, e.g. the Ipv6 flow label.=20 =20 3 The Need for Context Transfer=20 =20 In networks where the hosts are mobile, the forwarding path = through=20 the access network must often be redirected in order to deliver = the=20 host's IP traffic to the new point of access. The success of a = time=20 sensitive service such as VoIP telephony, video, etc., in a = mobile=20 environment depends heavily upon the minimization of the impact = of=20 this traffic redirection. In the process of establishing the = new=20 forwarding path, the nodes along the new path must be prepared = to=20 provide similar forwarding treatment to the IP packets. =20 =20 Figure 1 and 2 below illustrate an example of a handover = scenario. A=20 mobile node, MN7, is shown attached to the Internet via an = access=20 network. The forwarding nodes, FN1 through to FN7 comprise a = portion=20 of this access network. FN1 and FN7 are the last forwarding = nodes=20 before the untethered link to MN7. This last link allows the = nodes=20 to move while maintaining connectivity to the edge of the = access=20 network - e.g. the last link is wireless. For simplicity, many=20 details of a real access network topology have been left out of = the=20 diagrams.=20 =20 Prior to handoff, the path for MN7's traffic traverses FN1 and = FN2.=20 It is presumable that FN1 and FN2 have been configured to = provide=20 specific forwarding services for MN7's traffic, and that some = of=20 these services may require state information to be maintained.=20 =20 = =20 MN7's traffic = =20 <------------------> = =20 ------- ------- = =20 [ MN7 ]<=3D =3D =3D =3D>| FN1 = |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| FN2 = |=3D=3D=3D=3D=3D=3D=3D=3D =20 ------- /------- = =20 / = =20 -------/ = =20 | FN4 | = =20 /-------\ = =20 / \ = =20 / \ = =20 -------/ \------- = =20 - - -| FN7 | | FN6 |---- = =20 ------- ------- = =20 = =20 Figure 1: Path Prior to Handover = =20 = =20 =20 =20 Levkowetz et al. = [Page 4] =0D=0C =0D Internet Draft May = 2001=20 draft-ietf-seamoby-context-transfer-problem-01.txt=20 =20 When MN7's movement results in the link to FN1 to be replaced = by a=20 link to FN7, MN7's traffic must be re-directed along a new=20 forwarding path, illustrated in Figure 2 as the path through = FN7,=20 FN4 and FN2. In many mobile networks, this handover can occur=20 frequently, and sometimes with little or no warning.=20 ------- ------- = =20 - - -| FN1 |----------------| FN2 = |=3D=3D=3D=3D=3D=3D=3D=3D =20 ------- //------- = =20 // MN7's traffic = =20 -------/ <-----------> = =20 | FN4 | = =20 //------\ = =20 MN7's traffic // \ = =20 <-----------> // \ = =20 -------/ \------- = =20 [ MN7 ]<=3D =3D =3D =3D>| FN7 | | FN6 = |---- =20 ------- ------- = =20 = =20 Figure 2: Path Re-Directed After Handover = =20 = =20 =20 If the forwarding treatment provided to MN7's traffic is to be=20 sustained, the support conditions at FN1 and FN2 must be = reproduced=20 at FN7 and FN4. At the very least, this requires that FN7 and = FN4 be=20 configured to provide the appropriate support to the traffic = flow.=20 However, establishing forwarding support along the new path = through=20 the use of IP signalling protocols would be relatively time=20 consuming. In addition, given that some forwarding services may = maintain state information, simply configuring FN7 and FN4 = would not=20 circumvent disruption of the services.=20 =20 Given that FN7 and FN4 support the same functionality as FN1, = it=20 should be possible to reproduce the needed support along the = new=20 forwarding path by capturing the salient information at FN1 as = it=20 exists just prior to the handover, and then use that = information to=20 replicate the state of FN1 at FN7 and FN4.=20 =20 3.1 Scope of the Context Transfer Solution=20 =20 The information required to produce the necessary forwarding=20 treatments at a node is referred to as the support "context". = In=20 order to replicate the context of one forwarding node at = another=20 forwarding node, an open, standard solution for context = transfer=20 must be developed. =20 =20 In addition, for a forwarding node to be able to interpret the=20 transferred context, both the syntax and the semantics of the=20 context information must be defined. Definition of the actual=20 context information will be specific to the support feature = being=20 replicated, however, a generic container format of the payload = of=20 context transfer messages is required for inter-operability.=20 =20 Levkowetz et al. = [Page 5] =0D=0C =0D Internet Draft May = 2001=20 draft-ietf-seamoby-context-transfer-problem-01.txt=20 =20 =20 3.2 Reference Architectures=20 =20 The concept of the "forwarding node" is used here to describe = the=20 general context transfer problem. In different networks, the = actual=20 context transfer may take place between different entities = within=20 the network. In some cases the preferred context transfer peers = might be the routers at the edge of the access network. In = other=20 situations, it may be more appropriate to transfer context = between=20 wireless access points that also support forwarding of IP = packets.=20 =20 The context transfer solution will be applicable to any nodes = that=20 support forwarding of a mobile nodes IP traffic.=20 =20 4 A Description of Context=20 =20 The term _context_ pertains to all information required by a=20 forwarding node specific to supporting the IP traffic for a=20 particular mobile node. =20 =20 The context for a mobile node can be partitioned into three=20 categories:=20 =20 - information required to provide generaly support to = the =20 mobile node;=20 =20 - information required to provide common support to the = mobile node's traffic;=20 =20 - information required to support specific features of = the=20 forwarding treatment for an IP microflow.=20 =20 4.1 Feature=20 =20 A feature is an aspect of the IP forwarding treatment that is=20 instantiated for each mobile node, and which may support one or = more=20 of the mobile nodes microflows. A feature must include = associated=20 configuration information: at the very least, some = identification=20 information for the mobile node, such as the mobile node's IP=20 address. A feature may have associated state information.=20 =20 In other words, for the purpose of supporting mobility the = features=20 of interest all have context pertinent to the forwarding of a=20 specific mobile nodes IP packets. Examples of features include: = header compression, security, subscriber policy, and quality of = service.=20 =20 =20 Levkowetz et al. = [Page 6] =0D=0C =0D Internet Draft May = 2001=20 draft-ietf-seamoby-context-transfer-problem-01.txt=20 =20 Each feature is, in general, supported by an amalgamation of = one or=20 more protocols and associated local support mechanisms. As an=20 example, header compression is a feature that consists of = various=20 "mechanisms" such as IP/TCP header compression and IPv6/UDP/RTP = header compression, operating according to well-defined = "protocols".=20 Thus, an instance of a feature reflects the state associated = with=20 protocols and the corresponding mechanisms.=20 =20 4.2 Feature Context=20 =20 Feature context is the condition or state of an instance of a=20 particular feature. It represents the current evolution of the=20 behaviour of that feature instance. At a given instant in time, = feature context is represented by the values of the associated = data=20 elements.=20 =20 Some of the data elements associated with a feature are time=20 invariant and, thus, represent the configuration of the feature = instance. Other data elements, which are often referred to as = the=20 "state variables" for the feature instance, change value over = time=20 as a consequence of the various operations performed in support = of=20 the feature instance.=20 =20 A feature context is believed to be the smallest indivisible = unit of=20 context that can be transferred between forwarding nodes.=20 =20 4.3 Microflow Context=20 =20 A microflow context is the collection of the various feature=20 contexts associated with a single IP microflow. It is the = smallest=20 unit of context that must be transferred in order to = re-establish=20 support for the microflow at a forwarding node.=20 =20 4.4 Common Context=20 =20 Some of the associated feature contexts may be applicable to = more=20 then one of the IP microflows comprising the mobile node's = traffic.=20 An example of this might be the authentication state for the = mobile.=20 This type of feature context is also required to support each=20 microflow, but because of the multiplicity of the relationship = to=20 the mobile node's microflows, it would seem prudent to transfer = one=20 instance of the context, independent of the microflow context.=20 =20 4.5 Examples of Feature Context=20 =20 Some examples of feature contexts that are candidates for = context=20 transfer are given below. This list is provided solely to = illustrate=20 the nature of the context transfer problem domain.=20 =20 - encryption context;=20 - authentication context;=20 =20 Levkowetz et al. = [Page 7] =0D=0C =0D Internet Draft May = 2001=20 draft-ietf-seamoby-context-transfer-problem-01.txt=20 =20 - authorization context;=20 - accounting context;=20 - header compression context;=20 - quality of service context;=20 - policy enforcement context;=20 - multicast group membership;=20 - buffer state;=20 - sub-network layer context (e.g. PPP context).=20 =20 5 Context Transfer and Mobility=20 =20 Context transfer is an enhancement to a mobility solution that = is=20 clearly most effective when used on a local scale between = forwarding=20 nodes within a subnetwork. However, with due consideration to = the=20 nature of the context and the requirements for transfer of that = context, context transfer should be applicable between any two=20 similar forwarding nodes.=20 =20 6 Forwarding Node Capabilities=20 =20 Context transfer between two forwarding nodes is worthwhile = only if=20 the receiving node's capabilities are similar enough to those = of the=20 sending node that the received context can be utilized. This = does=20 not mean that the two nodes are identical in their = implementation,=20 nor does it even imply that they must have identical = capabilities.=20 =20 A forwarding node that cannot make use of received context = could,=20 and should, refuse the transfer. This would result in a = situation no=20 different then mobile handover without context transfer.=20 =20 7 Inter-technology Context Transfers=20 =20 The context transfer described here operates at the IP layer, = and=20 should be applicable to situations where the forwarding nodes = are=20 supporting different wireless link technologies. =20 =20 An exception to this would be where sub-IP layer context is an=20 intrinsic part of the forwarding treatment. In this situation, = an=20 interworking solution must be developed for sub-IP context = transfer=20 between the two technologies. This issue is outside the scope = of the=20 Seamoby working group.=20 =20 8 Performance Considerations=20 =20 The purpose of context transfer is to sustain the services being= =20 provided to a mobile node's traffic during handover. It is=20 essentially an enhancement to a mobility solution that = ultimately=20 must result in an improvement in handover performance. The = various=20 aspects of performance must be a prime consideration in the=20 development of the context transfer solution.=20 =20 =20 Levkowetz et al. = [Page 8] =0D=0C =0D Internet Draft May = 2001=20 draft-ietf-seamoby-context-transfer-problem-01.txt=20 =20 9 Security Considerations=20 =20 Context transfer does not introduce any new types of threats to = the=20 security of an IP network. The context itself may contain = sensitive=20 information; in which case security measures applied to its = transfer=20 should be the same as those measures applied to the transport = of=20 information between peers in an IP network.=20 =20 10 Recommendations=20 =20 The Seamoby context transfer design team recommends the = following:=20 =20 - investigation into candidates for context transfer - = in=20 particular, feature context transfer, and an analysis = of the transfer requirements for each candidate; =20 =20 - the development of a framework and protocol(s) that = will=20 support the transfer of configuration and state = context=20 between the forwarding nodes of an IP network.=20 =20 The context transfer solution must interwork with existing and=20 emerging IP protocols, in particular, those protocols = supporting=20 mobility in an IP network.=20 =20 References=20 =20 [1] Blake, et al., "An Architecture for Differentiated = Services",=20 RFC 2475, December 1998.=20 =20 [2] Berger & O'Malley, "RSVP Extensions for IPSEC Data Flows",=20 RFC 2207, September 1997.=20 =20 Authors' Addresses=20 O. Henrik Levkowetz=20 A Brand New World=20 Osterogatan 1=20 S-164 28 Kista =20 SWEDEN=20 =20 Phone: +46 8 477 9942=20 EMail: henrik@levkowetz.com=20 =20 =20 Pat R. Calhoun=20 Network and Security Research Center, Sun Labs=20 15 Network Circle=20 Menlo Park CA 94025=20 USA=20 =20 Phone: +1 650-786-7733=20 EMail: pcalhoun@eng.sun.com=20 =20 Levkowetz et al. = [Page 9] =0D=0C =0D Internet Draft May = 2001=20 draft-ietf-seamoby-context-transfer-problem-01.txt=20 =20 =20 =20 Gary Kenward=20 Nortel Networks=20 3500 Carling Avenue=20 Nepean, Ontario K2G 6J8=20 CANADA=20 =20 Phone: +1 613-765-1437=20 EMail: gkenward@nortelnetworks.com=20 =20 =20 Hamid Syed=20 Nortel Networks=20 100 Constellation Crescent=20 Nepean Ontario K2G 6J8=20 CANADA=20 =20 Phone: +1 613 763-6553=20 EMail: hmsyed@nortelnetworks.com=20 =20 Jukka Manner=20 Department of Computer Science, University of Helsinki=20 P.O. Box 26 (Teollisuuskatu 23)=20 FIN-00014 Helsinki=20 FINLAND=20 =20 Phone: +358-9-191-44210=20 EMail: jmanner@cs.helsinki.fi=20 =20 =20 Madjid Nakhjiri=20 Motorola=20 1501 West Shure Drive=20 Arlington Heights IL 60004=20 USA=20 =20 Phone: +1 847-632-5030=20 EMail: madjid.nakhjiri@motorola.com=20 =20 =20 Govind Krishnamurthi=20 Communications Systems Laboratory, Nokia Research Center=20 5 Wayside Road=20 Burlington MA 01803=20 USA=20 =20 Phone: +1 781 993 3627=20 EMail: govind.krishnamurthi@nokia.com=20 =20 =20 =20 Levkowetz et al. = [Page 10] =0D=0C =0D Internet Draft May = 2001=20 draft-ietf-seamoby-context-transfer-problem-01.txt=20 =20 Rajeev Koodli=20 Communications Systems Lab, Nokia Research Center=20 313 Fairchild Drive=20 Mountain View CA 94043=20 USA=20 =20 Phone: +1 650 625 2359=20 EMail: rajeev.koodli@nokia.com=20 =20 =20 Kulwinder S. Atwal=20 Zucotto Wireless Inc.=20 Ottawa Ontario K1P 6E2=20 CANADA=20 =20 Phone: +1 613 789 0090=20 EMail: kulwinder.atwal@zucotto.com=20 =20 =20 Michael Thomas=20 Cisco Systems=20 375 E Tasman Rd=20 San Jose CA 95134=20 USA=20 =20 Phone: +1 408 525 5386=20 EMail: mat@cisco.com=20 =20 =20 Mat Horan=20 COM DEV Wireless Group=20 San Luis Obispo CA 93401=20 USA=20 =20 Phone: +1 805 544 1089=20 EMail: mat.horan@comdev.cc=20 =20 =20 Phillip Neumiller=20 3Com Corporation=20 1800 W. Central Road=20 Mount Prospect IL 60056=20 USA=20 =20 EMail: phil_neumiller@3com.com=20 =20 =20 Full Copyright Statement=20 =20 Copyright (C) The Internet Society (2001). All Rights Reserved. = =20 =20 Levkowetz et al. = [Page 11] =0D=0C =0D Internet Draft May = 2001=20 draft-ietf-seamoby-context-transfer-problem-01.txt=20 =20 This document and translations of it may be copied and = furnished to=20 others, and derivative works that comment on or otherwise = explain it=20 or assist in its implementation may be prepared, copied, = published=20 and distributed, in whole or in part, without restriction of = any=20 kind, provided that the above copyright notice and this = paragraph=20 are included on all such copies and derivative works. However, = this=20 document itself may not be modified in any way, such as by = removing=20 the copyright notice or references to the Internet Society or = other=20 Internet organizations, except as needed for the purpose of=20 developing Internet standards in which case the procedures for=20 copyrights defined in the Internet Standards process must be=20 followed, or as required to translate it into languages other = than=20 English.=20 =20 The limited permissions granted above are perpetual and will = not be=20 revoked by the Internet Society or its successors or assigns.=20 =20 This document and the information contained herein is provided = on an=20 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET = ENGINEERING=20 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, = INCLUDING=20 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION = HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES = OF=20 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=20 =20 Acknowledgement=20 =20 Funding for the RFC editor function is currently provided by = the=20 Internet Society.=20 =20 Levkowetz et al. = [Page 12] =0D=0C ------_=_NextPart_000_01C0DA56.EAF596E0-- From owner-seamoby@diameter.org Fri May 11 17:05:39 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20554 for ; Fri, 11 May 2001 17:05:36 -0400 (EDT) Received: (qmail 12570 invoked by alias); 11 May 2001 20:39:51 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 12564 invoked by uid 200); 11 May 2001 20:39:51 -0000 Received: (qmail 12559 invoked from network); 11 May 2001 20:39:48 -0000 Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.nortelnetworks.com) (47.129.242.157) by c900656-a.plstn1.sfba.home.com with SMTP; 11 May 2001 20:39:48 -0000 Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id QAA16387; Fri, 11 May 2001 16:49:49 -0400 Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Fri, 11 May 2001 16:49:48 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 May 2001 16:49:49 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C1258F8@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'seamoby'" Subject: [seamoby] FW: Again: version 01 of the Context Transfer Problem Statement ( plain text) Date: Fri, 11 May 2001 16:49:42 -0400 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="utf-7" X-Orig: Sender: owner-seamoby@diameter.org Precedence: bulk +AD4-Here is the plain text version of the draft: +AD4- +AD4- +AD4- Context and Micro-mobility Routing Working Group O. H. +AD4-Levkowetz +AD4- Internet Draft +AD4-ABNW +AD4- draft-ietf-seamoby-context-transfer-problem- P. R. +AD4-Calhoun +AD4- 01.doc Sun MicroSystems, +AD4-Inc +AD4- Expires: November 2001 G. +AD4-Kenward +AD4- H. M. +AD4-Syed +AD4- Nortel +AD4-Networks +AD4- J. +AD4-Manner +AD4- University of +AD4-Helsinki +AD4- M. +AD4-Nakhjiri +AD4- +AD4-Motorola +AD4- G. +AD4-Krishnamurthi +AD4- R. +AD4-Koodli +AD4- +AD4-Nokia +AD4- K. S. +AD4-Atwal +AD4- Zucotto +AD4-Wireless +AD4- M. +AD4-Thomas +AD4- +AD4-Cisco +AD4- M. +AD4-Horan +AD4- COM +AD4-DEV +AD4- P. +AD4-Neumiller +AD4- +AD4-3Com +AD4- May +AD4-2001 +AD4- +AD4- +AD4- Problem Description: Reasons For Performing Context Transfers +AD4- Between Nodes in an IP Access Network +AD4- +AD4- Status of This Memo +AD4- +AD4- This document is an Internet-Draft and is in full conformance with +AD4- all provisions of Section 10 of RFC2026. +AD4- +AD4- Internet-Drafts are working documents of the Internet Engineering +AD4- Task Force (IETF), its areas, and its working groups. Note that +AD4- other groups may also distribute working documents as Internet- +AD4- Drafts. +AD4- +AD4- Internet-Drafts are draft documents valid for a maximum of six +AD4- months and may be updated, replaced, or obsoleted by other +AD4-documents +AD4- at any time. It is inappropriate to use Internet-Drafts as +AD4-reference +AD4- material or to cite them other than as +ACI-work in progress.+ACI- +AD4- +AD4- The list of current Internet-Drafts can be accessed at +AD4- http://www.ietf.org/ietf/1id-abstracts.txt. +AD4- +AD4- The list of Internet-Draft Shadow Directories can be accessed at +AD4- http://www.ietf.org/shadow.html. +AD4- +AD4- Copyright Notice +AD4- +AD4- Copyright (C) The Internet Society (2001). All Rights Reserved. +AD4- +AD4- Levkowetz et al. +AFs-Page +AD4-1+AF0- +AD4- +AD4- Internet Draft +AD4-May 2001 +AD4- draft-ietf-seamoby-context-transfer-problem-01.txt +AD4- +AD4- Abstract +AD4- +AD4- There are a large number of IP access networks that support +AD4-mobility +AD4- of hosts. For example, wireless Personal Area Networks (PANs), +AD4- wireless LANs, satellite WANs and cellular WANs. The nature of this +AD4- +AD4- mobility is such that the communication path to the host changes +AD4- frequently and rapidly. +AD4- +AD4- This Internet-Draft describes the problem encountered during +AD4- mobility that requires the exchange of IP context between different +AD4- +AD4- forwarding nodes in an access network. +AD4- +AD4- Table of Contents +AD4- +AD4- 1 Introduction...................................................2 +AD4- 2 Reference Definitions..........................................3 +AD4- 3 The Need for Context Transfer..................................4 +AD4- 3.1 Scope of the Context Transfer Solution .....................5 +AD4- 3.2 Reference Architectures ....................................6 +AD4- 4 A Description of Context.......................................6 +AD4- 4.1 Feature ....................................................6 +AD4- 4.2 Feature Context ............................................7 +AD4- 4.3 Microflow Context ..........................................7 +AD4- 4.4 Common Context .............................................7 +AD4- 4.5 Examples of Feature Context ................................7 +AD4- 5 Context Transfer and Mobility..................................8 +AD4- 6 Forwarding Node Capabilities...................................8 +AD4- 7 Inter-technology Context Transfers.............................8 +AD4- 8 Performance Considerations.....................................8 +AD4- 9 Security Considerations........................................9 +AD4- 10 Recommendations...............................................9 +AD4- +AD4- +AD4- 1 Introduction +AD4- +AD4- There are a large number of IP access networks that support hosts +AD4- that are mobile. For example, wireless Personal Area Networks +AD4- (PANs), wireless LANs, satellite WANs and cellular WANs. The nature +AD4- +AD4- of this mobility is such that the communication path to a host may +AD4- change frequently and rapidly. +AD4- +AD4- In networks where the hosts are mobile, the forwarding path through +AD4- +AD4- the access network must often be redirected in order to deliver the +AD4- +AD4- host's IP traffic to the new point of access. The success of a time +AD4- +AD4- sensitive service such as VoIP telephony, video, etc., in a mobile +AD4- environment depends heavily upon the minimization of the impact of +AD4- this traffic redirection. In the process of establishing the new +AD4- forwarding path, the nodes along the new path must be prepared to +AD4- provide similar forwarding treatment to the IP packets. +AD4- +AD4- +AD4- Levkowetz et al. +AFs-Page +AD4-2+AF0- +AD4- +AD4- Internet Draft +AD4-May 2001 +AD4- draft-ietf-seamoby-context-transfer-problem-01.txt +AD4- +AD4- The information required in support of a specific forwarding +AD4- treatment provided to IP traffic is part of the context for that +AD4- traffic. This context is comprised of configuration and state +AD4- information. To minimize the impact of a path change on an IP flow, +AD4- +AD4- the context used at the forwarding nodes along the original path, +AD4- must be replicated at the forwarding nodes along the new path. +AD4- +AD4- The transfer of context information may be advantageous in +AD4- minimizing the impact of host mobility on, for example, AAA, header +AD4- +AD4- compression, QoS, Policy, and possibly sub-IP protocols and +AD4-services +AD4- such as PPP. Context transfer at a minimum will be used to +AD4-replicate +AD4- the configuration information needed to establish the respective +AD4- protocols and services. In addition, it may also provide the +AD4- capability to replicate state information, allowing stateful +AD4- protocols and services at the new node to be activated along the +AD4-new +AD4- path with less delay and less signalling overhead. +AD4- +AD4- 2 Reference Definitions +AD4- +AD4- Mobile Node +AD4- +AD4- An IP node capable of changing its point of attachment to the +AD4- network. The mobile node is usually an end user host, but may be a +AD4- forwarding node for a network that is itself mobile. +AD4- +AD4- Forwarding Node +AD4- +AD4- A node that supports IP forwarding within the access network. This +AD4- includes all routers, gateways, servers and other nodes within the +AD4- network that have IP protocol stacks and forward IP traffic to and +AD4- from a mobile node. +AD4- +AD4- A forwarding node will be connected to one or more other forwarding +AD4- +AD4- nodes. Some forwarding nodes will be connected to zero or more +AD4- mobile nodes. The forwarding nodes that connect to mobile nodes +AD4-will +AD4- do so through a layer two entity that supports wireless +AD4- communications. +AD4- +AD4- Microflow +AD4- +AD4- One useful definition for the fundamental unit of IP service is the +AD4- +AD4- microflow. RFC 2475 +AFs-1+AF0- defines a microflow as: +AD4- +AD4- A single instance of an application-to application flow of packets +AD4- destined to or originated from a mobile device (MN or MH), which is +AD4- +AD4- identified by source address, source port, destination address, +AD4- destination port and protocol id. +AD4- +AD4- +AD4- Levkowetz et al. +AFs-Page +AD4-3+AF0- +AD4- +AD4- Internet Draft +AD4-May 2001 +AD4- draft-ietf-seamoby-context-transfer-problem-01.txt +AD4- +AD4- RFC 2207 +AFs-2+AF0- provides a definition of a microflow that applies to +AD4- IPSec packets. It is based on the IPSec SPI found in the AH or ESP +AD4- headers. Other methods for identifying for IP microflows may be +AD4- defined in the future, e.g. the Ipv6 flow label. +AD4- +AD4- 3 The Need for Context Transfer +AD4- +AD4- In networks where the hosts are mobile, the forwarding path through +AD4- +AD4- the access network must often be redirected in order to deliver the +AD4- +AD4- host's IP traffic to the new point of access. The success of a time +AD4- +AD4- sensitive service such as VoIP telephony, video, etc., in a mobile +AD4- environment depends heavily upon the minimization of the impact of +AD4- this traffic redirection. In the process of establishing the new +AD4- forwarding path, the nodes along the new path must be prepared to +AD4- provide similar forwarding treatment to the IP packets. +AD4- +AD4- Figure 1 and 2 below illustrate an example of a handover scenario. +AD4-A +AD4- mobile node, MN7, is shown attached to the Internet via an access +AD4- network. The forwarding nodes, FN1 through to FN7 comprise a +AD4-portion +AD4- of this access network. FN1 and FN7 are the last forwarding nodes +AD4- before the untethered link to MN7. This last link allows the nodes +AD4- to move while maintaining connectivity to the edge of the access +AD4- network - e.g. the last link is wireless. For simplicity, many +AD4- details of a real access network topology have been left out of the +AD4- +AD4- diagrams. +AD4- +AD4- Prior to handoff, the path for MN7's traffic traverses FN1 and FN2. +AD4- +AD4- It is presumable that FN1 and FN2 have been configured to provide +AD4- specific forwarding services for MN7's traffic, and that some of +AD4- these services may require state information to be maintained. +AD4- +AD4- +AD4- MN7's traffic +AD4- +ADw-------------------+AD4- +AD4- ------- ------- +AD4- +AFs- MN7 +AF0APAA9- +AD0- +AD0- +AD0APgB8- FN1 +AHwAPQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AHw- FN2 +AHwAPQA9AD0APQA9AD0APQA9- +AD4- ------- /------- +AD4- / +AD4- -------/ +AD4- +AHw- FN4 +AHw- +AD4- /-------+AFw- +AD4- / +AFw- +AD4- / +AFw- +AD4- -------/ +AFw-------- +AD4- - - -+AHw- FN7 +AHw- +AHw- FN6 +AHw----- +AD4- ------- ------- +AD4- +AD4- Figure 1: Path Prior to Handover +AD4- +AD4- +AD4- +AD4- Levkowetz et al. +AFs-Page +AD4-4+AF0- +AD4- +AD4- Internet Draft +AD4-May 2001 +AD4- draft-ietf-seamoby-context-transfer-problem-01.txt +AD4- +AD4- When MN7's movement results in the link to FN1 to be replaced by a +AD4- link to FN7, MN7's traffic must be re-directed along a new +AD4- forwarding path, illustrated in Figure 2 as the path through FN7, +AD4- FN4 and FN2. In many mobile networks, this handover can occur +AD4- frequently, and sometimes with little or no warning. +AD4- ------- ------- +AD4- - - -+AHw- FN1 +AHw-----------------+AHw- FN2 +AHwAPQA9AD0APQA9AD0APQA9- +AD4- ------- //------- +AD4- // MN7's traffic +AD4- -------/ +ADw------------+AD4- +AD4- +AHw- FN4 +AHw- +AD4- //------+AFw- +AD4- MN7's traffic // +AFw- +AD4- +ADw------------+AD4- // +AFw- +AD4- -------/ +AFw-------- +AD4- +AFs- MN7 +AF0APAA9- +AD0- +AD0- +AD0APgB8- FN7 +AHw- +AHw- FN6 +AHw----- +AD4- ------- ------- +AD4- +AD4- Figure 2: Path Re-Directed After Handover +AD4- +AD4- +AD4- If the forwarding treatment provided to MN7's traffic is to be +AD4- sustained, the support conditions at FN1 and FN2 must be reproduced +AD4- +AD4- at FN7 and FN4. At the very least, this requires that FN7 and FN4 +AD4-be +AD4- configured to provide the appropriate support to the traffic flow. +AD4- However, establishing forwarding support along the new path through +AD4- +AD4- the use of IP signalling protocols would be relatively time +AD4- consuming. In addition, given that some forwarding services may +AD4- maintain state information, simply configuring FN7 and FN4 would +AD4-not +AD4- circumvent disruption of the services. +AD4- +AD4- Given that FN7 and FN4 support the same functionality as FN1, it +AD4- should be possible to reproduce the needed support along the new +AD4- forwarding path by capturing the salient information at FN1 as it +AD4- exists just prior to the handover, and then use that information to +AD4- +AD4- replicate the state of FN1 at FN7 and FN4. +AD4- +AD4- 3.1 Scope of the Context Transfer Solution +AD4- +AD4- The information required to produce the necessary forwarding +AD4- treatments at a node is referred to as the support +ACI-context+ACI-. In +AD4- order to replicate the context of one forwarding node at another +AD4- forwarding node, an open, standard solution for context transfer +AD4- must be developed. +AD4- +AD4- In addition, for a forwarding node to be able to interpret the +AD4- transferred context, both the syntax and the semantics of the +AD4- context information must be defined. Definition of the actual +AD4- context information will be specific to the support feature being +AD4- replicated, however, a generic container format of the payload of +AD4- context transfer messages is required for inter-operability. +AD4- +AD4- Levkowetz et al. +AFs-Page +AD4-5+AF0- +AD4- +AD4- Internet Draft +AD4-May 2001 +AD4- draft-ietf-seamoby-context-transfer-problem-01.txt +AD4- +AD4- +AD4- 3.2 Reference Architectures +AD4- +AD4- The concept of the +ACI-forwarding node+ACI- is used here to describe the +AD4- general context transfer problem. In different networks, the actual +AD4- +AD4- context transfer may take place between different entities within +AD4- the network. In some cases the preferred context transfer peers +AD4- might be the routers at the edge of the access network. In other +AD4- situations, it may be more appropriate to transfer context between +AD4- wireless access points that also support forwarding of IP packets. +AD4- +AD4- The context transfer solution will be applicable to any nodes that +AD4- support forwarding of a mobile nodes IP traffic. +AD4- +AD4- 4 A Description of Context +AD4- +AD4- The term +AF8-context+AF8- pertains to all information required by a +AD4- forwarding node specific to supporting the IP traffic for a +AD4- particular mobile node. +AD4- +AD4- The context for a mobile node can be partitioned into three +AD4- categories: +AD4- +AD4- - information required to provide generaly support to the +AD4- mobile node+ADs- +AD4- +AD4- - information required to provide common support to the +AD4- mobile node's traffic+ADs- +AD4- +AD4- - information required to support specific features of the +AD4- forwarding treatment for an IP microflow. +AD4- +AD4- 4.1 Feature +AD4- +AD4- A feature is an aspect of the IP forwarding treatment that is +AD4- instantiated for each mobile node, and which may support one or +AD4-more +AD4- of the mobile nodes microflows. A feature must include associated +AD4- configuration information: at the very least, some identification +AD4- information for the mobile node, such as the mobile node's IP +AD4- address. A feature may have associated state information. +AD4- +AD4- In other words, for the purpose of supporting mobility the features +AD4- +AD4- of interest all have context pertinent to the forwarding of a +AD4- specific mobile nodes IP packets. Examples of features include: +AD4- header compression, security, subscriber policy, and quality of +AD4- service. +AD4- +AD4- +AD4- Levkowetz et al. +AFs-Page +AD4-6+AF0- +AD4- +AD4- Internet Draft +AD4-May 2001 +AD4- draft-ietf-seamoby-context-transfer-problem-01.txt +AD4- +AD4- Each feature is, in general, supported by an amalgamation of one or +AD4- +AD4- more protocols and associated local support mechanisms. As an +AD4- example, header compression is a feature that consists of various +AD4- +ACI-mechanisms+ACI- such as IP/TCP header compression and IPv6/UDP/RTP +AD4- header compression, operating according to well-defined +AD4-+ACI-protocols+ACI-. +AD4- Thus, an instance of a feature reflects the state associated with +AD4- protocols and the corresponding mechanisms. +AD4- +AD4- 4.2 Feature Context +AD4- +AD4- Feature context is the condition or state of an instance of a +AD4- particular feature. It represents the current evolution of the +AD4- behaviour of that feature instance. At a given instant in time, +AD4- feature context is represented by the values of the associated data +AD4- +AD4- elements. +AD4- +AD4- Some of the data elements associated with a feature are time +AD4- invariant and, thus, represent the configuration of the feature +AD4- instance. Other data elements, which are often referred to as the +AD4- +ACI-state variables+ACI- for the feature instance, change value over time +AD4- as a consequence of the various operations performed in support of +AD4- the feature instance. +AD4- +AD4- A feature context is believed to be the smallest indivisible unit +AD4-of +AD4- context that can be transferred between forwarding nodes. +AD4- +AD4- 4.3 Microflow Context +AD4- +AD4- A microflow context is the collection of the various feature +AD4- contexts associated with a single IP microflow. It is the smallest +AD4- unit of context that must be transferred in order to re-establish +AD4- support for the microflow at a forwarding node. +AD4- +AD4- 4.4 Common Context +AD4- +AD4- Some of the associated feature contexts may be applicable to more +AD4- then one of the IP microflows comprising the mobile node's traffic. +AD4- +AD4- An example of this might be the authentication state for the +AD4-mobile. +AD4- This type of feature context is also required to support each +AD4- microflow, but because of the multiplicity of the relationship to +AD4- the mobile node's microflows, it would seem prudent to transfer one +AD4- +AD4- instance of the context, independent of the microflow context. +AD4- +AD4- 4.5 Examples of Feature Context +AD4- +AD4- Some examples of feature contexts that are candidates for context +AD4- transfer are given below. This list is provided solely to +AD4-illustrate +AD4- the nature of the context transfer problem domain. +AD4- +AD4- - encryption context+ADs- +AD4- - authentication context+ADs- +AD4- +AD4- Levkowetz et al. +AFs-Page +AD4-7+AF0- +AD4- +AD4- Internet Draft +AD4-May 2001 +AD4- draft-ietf-seamoby-context-transfer-problem-01.txt +AD4- +AD4- - authorization context+ADs- +AD4- - accounting context+ADs- +AD4- - header compression context+ADs- +AD4- - quality of service context+ADs- +AD4- - policy enforcement context+ADs- +AD4- - multicast group membership+ADs- +AD4- - buffer state+ADs- +AD4- - sub-network layer context (e.g. PPP context). +AD4- +AD4- 5 Context Transfer and Mobility +AD4- +AD4- Context transfer is an enhancement to a mobility solution that is +AD4- clearly most effective when used on a local scale between +AD4-forwarding +AD4- nodes within a subnetwork. However, with due consideration to the +AD4- nature of the context and the requirements for transfer of that +AD4- context, context transfer should be applicable between any two +AD4- similar forwarding nodes. +AD4- +AD4- 6 Forwarding Node Capabilities +AD4- +AD4- Context transfer between two forwarding nodes is worthwhile only if +AD4- +AD4- the receiving node's capabilities are similar enough to those of +AD4-the +AD4- sending node that the received context can be utilized. This does +AD4- not mean that the two nodes are identical in their implementation, +AD4- nor does it even imply that they must have identical capabilities. +AD4- +AD4- A forwarding node that cannot make use of received context could, +AD4- and should, refuse the transfer. This would result in a situation +AD4-no +AD4- different then mobile handover without context transfer. +AD4- +AD4- 7 Inter-technology Context Transfers +AD4- +AD4- The context transfer described here operates at the IP layer, and +AD4- should be applicable to situations where the forwarding nodes are +AD4- supporting different wireless link technologies. +AD4- +AD4- An exception to this would be where sub-IP layer context is an +AD4- intrinsic part of the forwarding treatment. In this situation, an +AD4- interworking solution must be developed for sub-IP context transfer +AD4- +AD4- between the two technologies. This issue is outside the scope of +AD4-the +AD4- Seamoby working group. +AD4- +AD4- 8 Performance Considerations +AD4- +AD4- The purpose of context transfer is to sustain the services being +AD4- provided to a mobile node's traffic during handover. It is +AD4- essentially an enhancement to a mobility solution that ultimately +AD4- must result in an improvement in handover performance. The various +AD4- aspects of performance must be a prime consideration in the +AD4- development of the context transfer solution. +AD4- +AD4- +AD4- Levkowetz et al. +AFs-Page +AD4-8+AF0- +AD4- +AD4- Internet Draft +AD4-May 2001 +AD4- draft-ietf-seamoby-context-transfer-problem-01.txt +AD4- +AD4- 9 Security Considerations +AD4- +AD4- Context transfer does not introduce any new types of threats to the +AD4- +AD4- security of an IP network. The context itself may contain sensitive +AD4- +AD4- information+ADs- in which case security measures applied to its +AD4-transfer +AD4- should be the same as those measures applied to the transport of +AD4- information between peers in an IP network. +AD4- +AD4- 10 Recommendations +AD4- +AD4- The Seamoby context transfer design team recommends the following: +AD4- +AD4- - investigation into candidates for context transfer - in +AD4- particular, feature context transfer, and an analysis +AD4- of the transfer requirements for each candidate+ADs- +AD4- +AD4- - the development of a framework and protocol(s) that will +AD4- support the transfer of configuration and state context +AD4- between the forwarding nodes of an IP network. +AD4- +AD4- The context transfer solution must interwork with existing and +AD4- emerging IP protocols, in particular, those protocols supporting +AD4- mobility in an IP network. +AD4- +AD4- References +AD4- +AD4- +AFs-1+AF0- Blake, et al., +ACI-An Architecture for Differentiated Services+ACI-, +AD4- RFC 2475, December 1998. +AD4- +AD4- +AFs-2+AF0- Berger +ACY- O'Malley, +ACI-RSVP Extensions for IPSEC Data Flows+ACI-, +AD4- RFC 2207, September 1997. +AD4- +AD4- Authors' Addresses +AD4- O. Henrik Levkowetz +AD4- A Brand New World +AD4- Osterogatan 1 +AD4- S-164 28 Kista +AD4- SWEDEN +AD4- +AD4- Phone: 8 477 9942 +AD4- EMail: henrik+AEA-levkowetz.com +AD4- +AD4- +AD4- Pat R. Calhoun +AD4- Network and Security Research Center, Sun Labs +AD4- 15 Network Circle +AD4- Menlo Park CA 94025 +AD4- USA +AD4- +AD4- Phone: 650-786-7733 +AD4- EMail: pcalhoun+AEA-eng.sun.com +AD4- +AD4- Levkowetz et al. +AFs-Page +AD4-9+AF0- +AD4- +AD4- Internet Draft +AD4-May 2001 +AD4- draft-ietf-seamoby-context-transfer-problem-01.txt +AD4- +AD4- +AD4- +AD4- Gary Kenward +AD4- Nortel Networks +AD4- 3500 Carling Avenue +AD4- Nepean, Ontario K2G 6J8 +AD4- CANADA +AD4- +AD4- Phone: 613-765-1437 +AD4- EMail: gkenward+AEA-nortelnetworks.com +AD4- +AD4- +AD4- Hamid Syed +AD4- Nortel Networks +AD4- 100 Constellation Crescent +AD4- Nepean Ontario K2G 6J8 +AD4- CANADA +AD4- +AD4- Phone: 613 763-6553 +AD4- EMail: hmsyed+AEA-nortelnetworks.com +AD4- +AD4- Jukka Manner +AD4- Department of Computer Science, University of Helsinki +AD4- P.O. Box 26 (Teollisuuskatu 23) +AD4- FIN-00014 Helsinki +AD4- FINLAND +AD4- +AD4- Phone: +358-9-191-44210 +AD4- EMail: jmanner+AEA-cs.helsinki.fi +AD4- +AD4- +AD4- Madjid Nakhjiri +AD4- Motorola +AD4- 1501 West Shure Drive +AD4- Arlington Heights IL 60004 +AD4- USA +AD4- +AD4- Phone: 847-632-5030 +AD4- EMail: madjid.nakhjiri+AEA-motorola.com +AD4- +AD4- +AD4- Govind Krishnamurthi +AD4- Communications Systems Laboratory, Nokia Research Center +AD4- 5 Wayside Road +AD4- Burlington MA 01803 +AD4- USA +AD4- +AD4- Phone: 781 993 3627 +AD4- EMail: govind.krishnamurthi+AEA-nokia.com +AD4- +AD4- +AD4- +AD4- Levkowetz et al. +AFs-Page +AD4-10+AF0- +AD4- +AD4- Internet Draft +AD4-May 2001 +AD4- draft-ietf-seamoby-context-transfer-problem-01.txt +AD4- +AD4- Rajeev Koodli +AD4- Communications Systems Lab, Nokia Research Center +AD4- 313 Fairchild Drive +AD4- Mountain View CA 94043 +AD4- USA +AD4- +AD4- Phone: 650 625 2359 +AD4- EMail: rajeev.koodli+AEA-nokia.com +AD4- +AD4- +AD4- Kulwinder S. Atwal +AD4- Zucotto Wireless Inc. +AD4- Ottawa Ontario K1P 6E2 +AD4- CANADA +AD4- +AD4- Phone: 613 789 0090 +AD4- EMail: kulwinder.atwal+AEA-zucotto.com +AD4- +AD4- +AD4- Michael Thomas +AD4- Cisco Systems +AD4- 375 E Tasman Rd +AD4- San Jose CA 95134 +AD4- USA +AD4- +AD4- Phone: 408 525 5386 +AD4- EMail: mat+AEA-cisco.com +AD4- +AD4- +AD4- Mat Horan +AD4- COM DEV Wireless Group +AD4- San Luis Obispo CA 93401 +AD4- USA +AD4- +AD4- Phone: 805 544 1089 +AD4- EMail: mat.horan+AEA-comdev.cc +AD4- +AD4- +AD4- Phillip Neumiller +AD4- 3Com Corporation +AD4- 1800 W. Central Road +AD4- Mount Prospect IL 60056 +AD4- USA +AD4- +AD4- EMail: phil+AF8-neumiller+AEA-3com.com +AD4- +AD4- +AD4- Full Copyright Statement +AD4- +AD4- Copyright (C) The Internet Society (2001). All Rights Reserved. +AD4- +AD4- +AD4- Levkowetz et al. +AFs-Page +AD4-11+AF0- +AD4- +AD4- Internet Draft +AD4-May 2001 +AD4- draft-ietf-seamoby-context-transfer-problem-01.txt +AD4- +AD4- This document and translations of it may be copied and furnished to +AD4- +AD4- others, and derivative works that comment on or otherwise explain +AD4-it +AD4- or assist in its implementation may be prepared, copied, published +AD4- and distributed, in whole or in part, without restriction of any +AD4- kind, provided that the above copyright notice and this paragraph +AD4- are included on all such copies and derivative works. However, this +AD4- +AD4- document itself may not be modified in any way, such as by removing +AD4- +AD4- the copyright notice or references to the Internet Society or other +AD4- +AD4- Internet organizations, except as needed for the purpose of +AD4- developing Internet standards in which case the procedures for +AD4- copyrights defined in the Internet Standards process must be +AD4- followed, or as required to translate it into languages other than +AD4- English. +AD4- +AD4- The limited permissions granted above are perpetual and will not be +AD4- +AD4- revoked by the Internet Society or its successors or assigns. +AD4- +AD4- This document and the information contained herein is provided on +AD4-an +AD4- +ACI-AS IS+ACI- basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING +AD4- +AD4- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING +AD4- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION +AD4- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF +AD4- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. +AD4- +AD4- Acknowledgement +AD4- +AD4- Funding for the RFC editor function is currently provided by the +AD4- Internet Society. +AD4- +AD4- Levkowetz et al. +AFs-Page +AD4-12+AF0- +AD4- +AD4- +AD4- +AD4-+AD4- -----Original Message----- +AD4-+AD4- From: Kenward, Gary +AFs-WDLN2:AN10:EXCH+AF0- +AD4-+AD4- Sent: Friday, May 11, 2001 4:14 PM +AD4-+AD4- To: 'seamoby' +AD4-+AD4- Cc: 'Allison Mankin'+ADs- 'Pat Calhoun' +AD4-+AD4- Subject: +AFs-seamoby+AF0- version 01 of the Context Transfer Problem +AD4-+AD4- Statement +AD4-+AD4- Importance: High +AD4-+AD4- Sensitivity: Confidential +AD4-+AD4- +AD4-+AD4- +AD4-+AD4- Here is the revised Seamoby Context Transfer Problem statement. +AD4-+AD4- It has been modified in response to feedback received from the area +AD4-+AD4- directors. +AD4-+AD4- +AD4-+AD4- Gary Kenward +AD4-+AD4- +AD4-+AD4- +AD4-+AD4- From owner-seamoby@diameter.org Fri May 11 18:23:16 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22014 for ; Fri, 11 May 2001 18:23:15 -0400 (EDT) Received: (qmail 14015 invoked by alias); 11 May 2001 21:53:20 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 14009 invoked by uid 200); 11 May 2001 21:53:20 -0000 Received: (qmail 14004 invoked from network); 11 May 2001 21:53:18 -0000 Received: from tce-e-7-182-12.bta.net.cn (HELO china.com) (202.106.182.12) by c900656-a.plstn1.sfba.home.com with SMTP; 11 May 2001 21:53:18 -0000 Received: from china.com([10.1.7.101]) by china.com(AIMC 2.9.5.1) with SMTP id jm43afc7517; Sat, 12 May 2001 06:03:59 +0800 Received: from loki.ietf.org([132.151.1.177]) by china.com(AIMC 2.9.5.1) with SMTP id jmf63afbdafd; Fri, 11 May 2001 15:02:47 +0800 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA09897 for ietf-123-outbound.02@ietf.org; Tue, 8 May 2001 09:55:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id JAA09597 for ; Tue, 8 May 2001 09:19:03 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20877; Tue, 8 May 2001 09:18:57 -0400 (EDT) Message-Id: <200105081318.JAA20877@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: seamoby@cdma-2000.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [seamoby] I-D ACTION:draft-ietf-seamoby-paging-problem-statement-03.txt Date: Tue, 08 May 2001 09:18:56 -0400 Sender: owner-seamoby@diameter.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Context and Micro-mobility Routing Working Group of the IETF. Title : Dormant Mode Host Alerting ('IP Paging') Problem Statement Author(s) : J. Kempf Filename : draft-ietf-seamoby-paging-problem-statement-03.txt Pages : 14 Date : 07-May-01 The IESG has requested that the Seamoby Working Group develop a problem statement about the need for additional protocol work to support alerting of dormant mode mobile hosts, commonly known as IP paging, for seamless IP mobility. The paging design team interpreted this as direction to examine whether location of a mobile node in power saving mode can be supported by the existing Mobile IPv4 and Mobile IPv6 protocols given existing radio link protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-seamoby-paging-problem-statement-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-seamoby-paging-problem-statement-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-seamoby-paging-problem-statement-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010507125217.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-seamoby-paging-problem-statement-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-seamoby-paging-problem-statement-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010507125217.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-seamoby@diameter.org Sat May 12 15:35:25 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19406 for ; Sat, 12 May 2001 15:35:19 -0400 (EDT) Received: (qmail 16112 invoked by alias); 12 May 2001 19:23:00 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 16106 invoked by uid 200); 12 May 2001 19:23:00 -0000 Received: (qmail 16101 invoked by uid 500); 12 May 2001 19:22:58 -0000 Date: Sat, 12 May 2001 12:22:58 -0700 From: Pat Calhoun To: seamoby@cdma-2000.org Subject: [seamoby] Seamoby Charter Last Call Message-ID: <20010512122258.Y10188@charizard.diameter.org> Mail-Followup-To: seamoby@cdma-2000.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-seamoby@diameter.org Precedence: bulk All, Below is the proposed Seamoby Charter. The WG last call will be completed on May 29th (given the long weekend in the US). We had proposed to write up a set of issues that we had found with the Mobile IP protocol, but our AD stated that this work really needs to occur in the MIP WG. So I would ask that all interested parties take up that activity on the MIP mailing list. Please send any comments to the list. Thanks, PatC ---- Context Transfer, Handoff Candidate Discovery and Dormant Mode Host Alerting (seamoby) Chair(s): Pat Calhoun Transport Area Director(s): Scott Bradner Allison Mankin Transport Area Advisor: Allison Mankin Mailing Lists: General Discussion:seamoby@cdma-2000.org To Subscribe: majordomo@cdma-2000.org In Body: (un)subscribe seamoby your_e-mail_address Archive: http://www.diameter.org/cgi-bin/lwgate/seamoby/ History During the fast handoff discussions within the Mobile IP WG, a need for a new protocol was identified that would allow state information to be transferred between edge devices (e.g. Foreign Agents). Examples of state information that could need to be transferred is AAA information, security context, QOS properties assigned to the user, Robust Header Compression information, etc. SDOs that work on wireless, such as 3GPP, 3GPP2, IEEE and others, are hoping that the IETF will be able to provide a set of protocols that will enable them to provide real-time services over an IP infrastructure, and, along with Mobile IP, SeaMoby is expected to provide such protocols. Furthermore, the protocols developed by the Seamoby Working Group must allow for real-time services to work with minimal disruption across heterogeneous wireless, and wired, technologies. It is expected that SDOs working on wireless technologies will provide their input into the WG during the requirements gathering and protocol design phase. Description There are a large number of IP access networks that support mobility of hosts. For example, wireless Personal Area Networks (PANs) and LANs, satellite and cellular WANs. The nature of this roaming is such that the communication path to the host changes frequently, and rapidly. In many situations, the change of communications path includes a change in communications media between the host and access networking, including changes from a wireless to a wired connection and changes between wireless technologies even under common administration. Although the protocol used to actively re-direct the IP packet flows during a change in a mobile's point of attachment is handled by other Working Groups, there is a need for preserving the context of its active IP flows. The IP flow context includes, but is not limited to security context, policy, QOS, congestion indication/management, header compression and accounting. The SeaMoby Working group will analyze the requirements and tradeoffs for the goal of transferring context information from a mobile's old access to the new access point (versus accessing needed context over a distance). Depending on the results of the requirements analysis, the SeaMoby Working Group will develop a protocol (or start from an existing protocol such as Contract Net Protocol (CNP) or the IEEE's 802.11f) to transfer the context information for a session. The context information to be transferred includes QOS, header compression state, policy, security context, congestion management state, AAA information, etc. Transferring context state is expected to provide a more robust handoff to the user, and applications. Quality of service (QOS) state may include both diffserv and intserv information, as needed. While other IETF Working Groups are developing protocols to provide "fast handoff" solutions, the mechanisms currently under development are designed to hand off a mobile to the first available handoff candidate. The Seamoby Working Group has documented that "seamless" handoffs can be achieved by ensuring that a handoff occurs to a candidate that can best support a given mobile, and this work in not within the scope of the "fast handoff" protocols being developed. Seamoby will define the work in a problem statement, and if needed, will define the requirements and the protocol for a handoff candidate discovery protocol, which could be used with any mobility management protocol. Lastly, the Working Group will define the requirements for Dormant Mode Host Alerting (DMHA) at the IP layer (also known as IP Paging) in networks, and a protocol will be developed to tackle this problem. DMHA is typically used in networks that support mobile devices that periodically enter dormant mode to reduce power consumption. DMHA enable network devices to track a mobile that has moved from its last point of attachment, while in dormant mode, allowing the mobile's packets to be delivered. All work produced by the Working Group will support both IPv4 and IPv6, will follow the congestion control principles in RFC2914 (BCP41), and will undergo a security review prior to WG last call. The Working Group will coordinate closely with the aaa, cnrp, impp, mobileip, pilc, and rohc working groups. Goals and Milestones: Jun 01 Submit I-D on Dormant Mode Host Alerting Requirements Jul 01 Submit Handoff Candidate Discovery Problem Statement Sep 01 Interim Meeting to review Inter Access Point Context Transfer and Handoff Candidate Discovery Requirements Oct 01 Dormant Mode Host Alerting Protocol to IESG for consideration as a Proposed Standard Oct 01 Submit requirements analysis for Inter Access Point Context Transfer Protocol to IESG for consideration as Informational Oct 01 Submit Handoff Discovery Requirements I-D to IESG for consideration as Informational Nov 01 Candidate Inter Access Point Context Transfer Protocols are submitted, with accompanying comparison against requirements Nov 01 Candidate Handoff Discovery Protocols are submitted, with accompanying comparison against requirements Dec 01 Dormant Mode Host Alerting Protocol MIB to IESG for consideration as a Proposed Standard Feb 02 Inter Access Point Context Transfer Protocol to IESG for consideration as a Proposed Standard Feb 02 Handoff Discovery Protocol to IESG for consideration as a Proposed Standard Jun 02 Submit Inter Access Point Context Transfer Protocol MIB to IESG for consideration as a Proposed Standard Jun 02 Submit Handoff Discovery Protocol MIB to IESG for consideration as a Proposed Standard From owner-seamoby@diameter.org Mon May 14 08:29:22 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08501 for ; Mon, 14 May 2001 08:29:21 -0400 (EDT) Received: (qmail 25699 invoked by alias); 14 May 2001 12:17:18 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 25692 invoked by uid 200); 14 May 2001 12:17:17 -0000 Received: (qmail 25687 invoked from network); 14 May 2001 12:17:16 -0000 Received: from mgw-x1.nokia.com (131.228.20.21) by c900656-a.plstn1.sfba.home.com with SMTP; 14 May 2001 12:17:16 -0000 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 f4ECRNe16640 for ; Mon, 14 May 2001 15:27:23 +0300 (EET DST) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 14 May 2001 15:27:56 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Mon, 14 May 2001 15:27:56 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680AF2A@eseis04nok> From: john.loughney@nokia.com To: pcalhoun@diameter.org, seamoby@cdma-2000.org Subject: RE: [seamoby] Seamoby Charter Last Call Date: Mon, 14 May 2001 15:27:52 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi Pat, Some comments: > During the fast handoff discussions within the Mobile IP WG, a need for a new > protocol was identified that would allow state information to be transferred > between edge devices (e.g. Foreign Agents). The above statement is too IPv4 centric. There has been some work about context transfer on going for MIPv6 for over a year, so I suggest we remove the 'foreign agents' text. > Examples of state information that could need to be transferred ... The above sentence is rather awkward, how about: 'Examples of state information that could be transferred ...' - or - 'Examples of state information that could be useful to transfer ...' One small nit: > The Working Group will coordinate closely with the aaa, cnrp, > impp, mobileip, pilc, and rohc working groups. We discussed long ago how CNRP fits into SeaMoby, and I think we agreed it did not, so let's drop it from the charter. Otherwise, a fine job, John From owner-seamoby@diameter.org Mon May 14 09:43:07 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11252 for ; Mon, 14 May 2001 09:43:07 -0400 (EDT) Received: (qmail 26253 invoked by alias); 14 May 2001 13:31:34 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 26247 invoked by uid 200); 14 May 2001 13:31:33 -0000 Received: (qmail 26238 invoked by uid 500); 14 May 2001 13:31:31 -0000 Date: Mon, 14 May 2001 06:31:31 -0700 From: Pat Calhoun To: john.loughney@nokia.com Cc: pcalhoun@diameter.org, seamoby@cdma-2000.org Subject: Re: [seamoby] Seamoby Charter Last Call Message-ID: <20010514063130.C10188@charizard.diameter.org> Mail-Followup-To: john.loughney@nokia.com, pcalhoun@diameter.org, seamoby@cdma-2000.org References: <01D91AFB08B6D211BFD00008C7EABAE10680AF2A@eseis04nok> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01D91AFB08B6D211BFD00008C7EABAE10680AF2A@eseis04nok>; from john.loughney@nokia.com on Mon, May 14, 2001 at 03:27:52PM +0300 Sender: owner-seamoby@diameter.org Precedence: bulk On Mon, May 14, 2001 at 03:27:52PM +0300, john.loughney@nokia.com wrote: > > During the fast handoff discussions within the Mobile IP WG, a need for a > new > > protocol was identified that would allow state information to be > transferred > > between edge devices (e.g. Foreign Agents). > > The above statement is too IPv4 centric. There has been some work > about context transfer on going for MIPv6 for over a year, so I > suggest we remove the 'foreign agents' text. I agree. > > > Examples of state information that could need to be transferred ... > > The above sentence is rather awkward, how about: > > 'Examples of state information that could be transferred ...' > > - or - > > 'Examples of state information that could be useful to transfer ...' ok, I will fix that sentence up. > > One small nit: > > > The Working Group will coordinate closely with the aaa, cnrp, > > impp, mobileip, pilc, and rohc working groups. > > We discussed long ago how CNRP fits into SeaMoby, and I think > we agreed it did not, so let's drop it from the charter. you are right, and I missed that one. PatC From owner-seamoby@diameter.org Mon May 14 10:17:02 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12776 for ; Mon, 14 May 2001 10:16:55 -0400 (EDT) Received: (qmail 27378 invoked by alias); 14 May 2001 13:59:37 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 27372 invoked by uid 200); 14 May 2001 13:59:37 -0000 Received: (qmail 27363 invoked from network); 14 May 2001 13:59:34 -0000 Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.nortelnetworks.com) (47.129.242.157) by c900656-a.plstn1.sfba.home.com with SMTP; 14 May 2001 13:59:34 -0000 Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id KAA24840; Mon, 14 May 2001 10:09:41 -0400 Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Mon, 14 May 2001 10:09:19 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 May 2001 10:09:15 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C1258FE@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Pat Calhoun'" , seamoby@cdma-2000.org Subject: RE: [seamoby] Seamoby Charter Last Call Date: Mon, 14 May 2001 10:09:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DC7F.747AB510" 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_01C0DC7F.747AB510 Content-Type: text/plain; charset="ISO-8859-1" Looks fine. Comments included below. Gary > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Saturday, May 12, 2001 3:23 PM > To: seamoby@cdma-2000.org > Subject: [seamoby] Seamoby Charter Last Call > > > All, > > Below is the proposed Seamoby Charter. The WG last call will > be completed > on May 29th (given the long weekend in the US). > > We had proposed to write up a set of issues that we had found with the > Mobile IP protocol, but our AD stated that this work really > needs to occur > in the MIP WG. So I would ask that all interested parties take up that > activity on the MIP mailing list. > > Please send any comments to the list. > > Thanks, > > PatC > ---- > Context Transfer, Handoff Candidate Discovery and Dormant Mode Host > Alerting (seamoby) > > > > Chair(s): > > Pat Calhoun > > Transport Area Director(s): > > Scott Bradner > Allison Mankin > > Transport Area Advisor: > > Allison Mankin > > Mailing Lists: > > General Discussion:seamoby@cdma-2000.org > To Subscribe: majordomo@cdma-2000.org > In Body: (un)subscribe seamoby your_e-mail_address > Archive: http://www.diameter.org/cgi-bin/lwgate/seamoby/ > > > History > > During the fast handoff discussions within the Mobile IP WG, > a need for a new > protocol was identified that would allow state information to > be transferred > between edge devices (e.g. Foreign Agents). Examples of state > information that > could need to be transferred is AAA information, security context, QOS > properties assigned to the user, Robust Header Compression > information, etc. > > SDOs that work on wireless, such as 3GPP, 3GPP2, IEEE and > others, are hoping > that the IETF will be able to provide a set of protocols that > will enable > them to provide real-time services over an IP infrastructure, > and, along > with Mobile IP, SeaMoby is expected to provide such > protocols. Furthermore, > the protocols developed by the Seamoby Working Group must allow for > real-time services to work with minimal disruption across > heterogeneous > wireless, and wired, technologies. > > It is expected that SDOs working on wireless technologies > will provide their > input into the WG during the requirements gathering and > protocol design > phase. > > Description > > There are a large number of IP access networks that support > mobility of hosts. > For example, wireless Personal Area Networks (PANs) and LANs, > satellite and > cellular WANs. The nature of this roaming is such that the > communication path > to the host changes frequently, and rapidly. In many > situations, the change of > communications path includes a change in communications media > between the host > and access networking, including changes from a wireless to a wired > connection and changes between wireless technologies even under common > administration. > > Although the protocol used to actively re-direct the IP > packet flows during a > change in a mobile's point of attachment is handled by other > Working Groups, > there is a need for preserving the context of its active IP > flows. The IP flow > context includes, but is not limited to security context, policy, QOS, > congestion indication/management, header compression and accounting. > > The SeaMoby Working group will analyze the requirements and > tradeoffs for the > goal of transferring context information from a mobile's old > access to the new > access point (versus accessing needed context over a distance). I understand what was intended here, but the role of the "access point" has been a topic of great debate. To some, an "access point" is a box in a specific network soltuion. There is no simple alternative (that I have been able to come up with), but in the requirements documents we have used "point of access" instead of "access point". > > Depending on the results of the requirements analysis, the > SeaMoby Working > Group will develop a protocol (or start from an existing > protocol such as > Contract Net Protocol (CNP) or the IEEE's 802.11f) to > transfer the context > information for a session. The context information to be > transferred includes > QOS, header compression state, policy, security context, > congestion management > state, AAA information, etc. Transferring context state is > expected to > provide a more robust handoff to the user, and applications. > Quality of > service (QOS) state may include both diffserv and intserv > information, as > needed. > > While other IETF Working Groups are developing protocols to > provide "fast > handoff" solutions, the mechanisms currently under > development are designed > to hand off a mobile to the first available handoff > candidate. The Seamoby > Working Group has documented that "seamless" handoffs can be > achieved by > ensuring that a handoff occurs to a candidate that can best > support a given > mobile, and this work in not within the scope of the "fast > handoff" protocols > being developed. Seamoby will define the work in a problem > statement, and > if needed, will define the requirements and the protocol for > a handoff > candidate discovery protocol, which could be used with any mobility > management protocol. > > Lastly, the Working Group will define the requirements for > Dormant Mode Host > Alerting (DMHA) at the IP layer (also known as IP Paging) in > networks, and a > protocol will be developed to tackle this problem. DMHA is > typically used in > networks that support mobile devices that periodically enter > dormant mode to > reduce power consumption. DMHA enable network devices to > track a mobile that > has moved from its last point of attachment, while in dormant > mode, allowing > the mobile's packets to be delivered. > > All work produced by the Working Group will support both IPv4 > and IPv6, will > follow the congestion control principles in RFC2914 (BCP41), > and will undergo > a security review prior to WG last call. > > The Working Group will coordinate closely with the aaa, cnrp, > impp, mobileip, > pilc, and rohc working groups. > > > Goals and Milestones: > > Jun 01 Submit I-D on Dormant Mode Host Alerting Requirements > Jul 01 Submit Handoff Candidate Discovery Problem Statement > Sep 01 Interim Meeting to review Inter Access Point Context > Transfer and > Handoff Candidate Discovery Requirements Why so late? > Oct 01 Dormant Mode Host Alerting Protocol to IESG for > consideration as a > Proposed Standard > Oct 01 Submit requirements analysis for Inter Access Point > Context Transfer > Protocol to IESG for consideration as Informational > Oct 01 Submit Handoff Discovery Requirements I-D to IESG for > consideration > as Informational > Nov 01 Candidate Inter Access Point Context Transfer Protocols > are submitted, with accompanying comparison against requirements > Nov 01 Candidate Handoff Discovery Protocols are submitted, with > accompanying comparison against requirements > Dec 01 Dormant Mode Host Alerting Protocol MIB to IESG for > consideration as a > Proposed Standard > Feb 02 Inter Access Point Context Transfer Protocol to IESG > for consideration > as a Proposed Standard > Feb 02 Handoff Discovery Protocol to IESG for consideration > as a Proposed > Standard > Jun 02 Submit Inter Access Point Context Transfer Protocol > MIB to IESG for > consideration as a Proposed Standard > Jun 02 Submit Handoff Discovery Protocol MIB to IESG for > consideration as a > Proposed Standard > ------_=_NextPart_001_01C0DC7F.747AB510 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [seamoby] Seamoby Charter Last Call

Looks fine. Comments included below.

Gary

> -----Original Message-----
> From: Pat Calhoun [mailto:pcalhoun@diameter.org]<= /FONT>
> Sent: Saturday, May 12, 2001 3:23 PM
> To: seamoby@cdma-2000.org
> Subject: [seamoby] Seamoby Charter Last = Call
>
>
> All,
>
> Below is the proposed Seamoby Charter. The WG = last call will
> be completed
> on May 29th (given the long weekend in the = US).
>
> We had proposed to write up a set of issues = that we had found with the
> Mobile IP protocol, but our AD stated that this = work really
> needs to occur
> in the MIP WG. So I would ask that all = interested parties take up that
> activity on the MIP mailing list.
>
> Please send any comments to the list.
>
> Thanks,
>
> PatC
> ----
> Context Transfer, Handoff Candidate Discovery = and Dormant Mode Host
> Alerting (seamoby)
>
>
>
> Chair(s):
>
> Pat Calhoun = <pcalhoun@diameter.org>
>
> Transport Area Director(s):
>
> Scott Bradner <sob@harvard.edu>
> Allison Mankin <mankin@isi.edu>
>
> Transport Area Advisor:
>
> Allison Mankin <mankin@isi.edu>
>
> Mailing Lists:
>
> General Discussion:seamoby@cdma-2000.org =
> To Subscribe: majordomo@cdma-2000.org
> In Body: (un)subscribe seamoby = your_e-mail_address
> Archive: http://www.diameter.org/cgi-bin/lwgate/seamoby/ =
>
>
> History
>
> During the fast handoff discussions within the = Mobile IP WG,
> a need for a new
> protocol was identified that would allow state = information to
> be transferred
> between edge devices (e.g. Foreign Agents). = Examples of state
> information that
> could need to be transferred is AAA = information, security context, QOS
> properties assigned to the user, Robust Header = Compression
> information, etc.
>
> SDOs that work on wireless, such as 3GPP, = 3GPP2, IEEE and
> others, are hoping
> that the IETF will be able to provide a set of = protocols that
> will enable
> them to provide real-time services over an IP = infrastructure,
> and, along
> with Mobile IP, SeaMoby is expected to provide = such
> protocols. Furthermore,
> the protocols developed by the Seamoby Working = Group must allow for
> real-time services to work with minimal = disruption across
> heterogeneous
> wireless, and wired, technologies.
>
> It is expected that SDOs working on wireless = technologies
> will provide their
> input into the WG during the requirements = gathering and
> protocol design
> phase.
>
> Description
>
> There are a large number of IP access networks = that support
> mobility of hosts.
> For example, wireless Personal Area Networks = (PANs) and LANs,
> satellite and
> cellular WANs. The nature of this roaming is = such that the
> communication path
> to the host changes frequently, and rapidly. In = many
> situations, the change of
> communications path includes a change in = communications media
> between the host
> and access networking, including changes from a = wireless to a wired
> connection and changes between wireless = technologies even under common
> administration.
>
> Although the protocol used to actively = re-direct the IP
> packet flows during a
> change in a mobile's point of attachment is = handled by other
> Working Groups,
> there is a need for preserving the context of = its active IP
> flows. The IP flow
> context includes, but is not limited to = security context, policy, QOS,
> congestion indication/management, header = compression and accounting.
>
> The SeaMoby Working group will analyze the = requirements and
> tradeoffs for the
> goal of transferring context information from a = mobile's old
> access to the new
> access point (versus accessing needed context = over a distance).

I understand what was intended here, but the role of = the "access
point" has been a topic of great debate. To = some, an "access point"
is a box in a specific network soltuion. There is no = simple alternative
(that I have been able to come up with), but in the = requirements documents
we have used "point of access" instead of = "access point".

>
> Depending on the results of the requirements = analysis, the
> SeaMoby Working
> Group will develop a protocol (or start from an = existing
> protocol such as
> Contract Net Protocol (CNP) or the IEEE's = 802.11f) to
> transfer the context
> information for a session. The context = information to be
> transferred includes
> QOS, header compression state, policy, security = context,
> congestion management
> state, AAA information, etc. Transferring = context state is
> expected to
> provide a more robust handoff to the user, and = applications.
> Quality of
> service (QOS) state may include both diffserv = and intserv
> information, as
> needed.
>
> While other IETF Working Groups are developing = protocols to
> provide "fast
> handoff" solutions, the mechanisms = currently under
> development are designed
> to hand off a mobile to the first available = handoff
> candidate. The Seamoby
> Working Group has documented that = "seamless" handoffs can be
> achieved by
> ensuring that a handoff occurs to a candidate = that can best
> support a given
> mobile, and this work in not within the scope = of the "fast
> handoff" protocols
> being developed. Seamoby will define the work = in a problem
> statement, and
> if needed, will define the requirements and the = protocol for
> a handoff
> candidate discovery protocol, which could be = used with any mobility
> management protocol.
>
> Lastly, the Working Group will define the = requirements for
> Dormant Mode Host
> Alerting (DMHA) at the IP layer (also known as = IP Paging) in
> networks, and a
> protocol will be developed to tackle this = problem. DMHA is
> typically used in
> networks that support mobile devices that = periodically enter
> dormant mode to
> reduce power consumption. DMHA enable network = devices to
> track a mobile that
> has moved from its last point of attachment, = while in dormant
> mode, allowing
> the mobile's packets to be delivered.
>
> All work produced by the Working Group will = support both IPv4
> and IPv6, will
> follow the congestion control principles in = RFC2914 (BCP41),
> and will undergo
> a security review prior to WG last call. =
>
> The Working Group will coordinate closely with = the aaa, cnrp,
> impp, mobileip,
> pilc, and rohc working groups.
>
>
> Goals and Milestones:
>
> Jun 01  Submit I-D on Dormant Mode Host = Alerting Requirements
> Jul 01  Submit Handoff Candidate Discovery = Problem Statement
> Sep 01  Interim Meeting to review Inter = Access Point Context
> Transfer and
>       Handoff = Candidate Discovery Requirements

Why so late?

> Oct 01  Dormant Mode Host Alerting Protocol = to IESG for
> consideration as a
>       Proposed = Standard
> Oct 01  Submit requirements analysis for = Inter Access Point
> Context Transfer
>       Protocol to IESG = for consideration as Informational
> Oct 01  Submit Handoff Discovery = Requirements I-D to IESG for
> consideration
>       as = Informational
> Nov 01  Candidate Inter Access Point = Context Transfer Protocols
>       are submitted, = with accompanying comparison against requirements
> Nov 01  Candidate Handoff Discovery = Protocols are submitted, with 
>       accompanying = comparison against requirements
> Dec 01  Dormant Mode Host Alerting = Protocol MIB to IESG for
> consideration as a
>       Proposed = Standard
> Feb 02  Inter Access Point Context = Transfer Protocol to IESG
> for consideration
>       as a Proposed = Standard
> Feb 02  Handoff Discovery Protocol to IESG = for consideration
> as a Proposed
>       Standard
> Jun 02  Submit Inter Access Point Context = Transfer Protocol
> MIB to IESG for
>       consideration as = a Proposed Standard
> Jun 02  Submit Handoff Discovery Protocol = MIB to IESG for
> consideration as a
>       Proposed = Standard
>

------_=_NextPart_001_01C0DC7F.747AB510-- From owner-seamoby@diameter.org Mon May 14 10:24:02 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13188 for ; Mon, 14 May 2001 10:24:00 -0400 (EDT) Received: (qmail 27581 invoked by alias); 14 May 2001 14:03:35 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 27575 invoked by uid 200); 14 May 2001 14:03:34 -0000 Received: (qmail 27566 invoked by uid 500); 14 May 2001 14:03:31 -0000 Date: Mon, 14 May 2001 07:03:31 -0700 From: Pat Calhoun To: Gary Kenward Cc: "'Pat Calhoun'" , seamoby@cdma-2000.org Subject: Re: [seamoby] Seamoby Charter Last Call Message-ID: <20010514070331.N10188@charizard.diameter.org> Mail-Followup-To: Gary Kenward , 'Pat Calhoun' , seamoby@cdma-2000.org References: <9FBD322B7824D511B36900508BF93C9C1258FE@zcard031.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <9FBD322B7824D511B36900508BF93C9C1258FE@zcard031.ca.nortel.com>; from gkenward@nortelnetworks.com on Mon, May 14, 2001 at 10:09:13AM -0400 Sender: owner-seamoby@diameter.org Precedence: bulk On Mon, May 14, 2001 at 10:09:13AM -0400, Gary Kenward wrote: > > The SeaMoby Working group will analyze the requirements and > > tradeoffs for the > > goal of transferring context information from a mobile's old > > access to the new > > access point (versus accessing needed context over a distance). > > I understand what was intended here, but the role of the "access > point" has been a topic of great debate. To some, an "access point" > is a box in a specific network soltuion. There is no simple alternative > (that I have been able to come up with), but in the requirements documents > we have used "point of access" instead of "access point". To me, point of access doesn't necessarily imply an actual device, but more of a connection point (e.g. ethernet port). Would access device work better? It is commonly used in many other WGs. > > Sep 01 Interim Meeting to review Inter Access Point Context > > Transfer and > > Handoff Candidate Discovery Requirements > > Why so late? There is no penalty for being early. PatC From owner-seamoby@diameter.org Mon May 14 12:02:58 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16192 for ; Mon, 14 May 2001 12:02:54 -0400 (EDT) Received: (qmail 29152 invoked by alias); 14 May 2001 15:21:30 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 29146 invoked by uid 200); 14 May 2001 15:21:30 -0000 Received: (qmail 29141 invoked from network); 14 May 2001 15:21:28 -0000 Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.nortelnetworks.com) (47.129.242.157) by c900656-a.plstn1.sfba.home.com with SMTP; 14 May 2001 15:21:28 -0000 Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id LAA03701; Mon, 14 May 2001 11:31:38 -0400 Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Mon, 14 May 2001 11:31:05 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 May 2001 11:05:03 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C1CD076@zcard031.ca.nortel.com> From: "Hamid Syed" To: "'Pat Calhoun'" Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] Seamoby Charter Last Call Date: Mon, 14 May 2001 11:05:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DC87.40146CF0" 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_01C0DC87.40146CF0 Content-Type: text/plain; charset="ISO-8859-1" Pat, few comments on WG milestones.. -Hamid > -----Original Message----- > From: Pat Calhoun [SMTP:pcalhoun@diameter.org] > Sent: Saturday, May 12, 2001 3:23 PM > To: seamoby@cdma-2000.org > Subject: [seamoby] Seamoby Charter Last Call > > All, > > Below is the proposed Seamoby Charter. The WG last call will be completed > on May 29th (given the long weekend in the US). > > We had proposed to write up a set of issues that we had found with the > Mobile IP protocol, but our AD stated that this work really needs to occur > in the MIP WG. So I would ask that all interested parties take up that > activity on the MIP mailing list. > > Please send any comments to the list. > > Thanks, > > PatC > ---- > Context Transfer, Handoff Candidate Discovery and Dormant Mode Host > Alerting (seamoby) > > > > Chair(s): > > Pat Calhoun > > Transport Area Director(s): > > Scott Bradner > Allison Mankin > > Transport Area Advisor: > > Allison Mankin > > Mailing Lists: > > General Discussion:seamoby@cdma-2000.org > To Subscribe: majordomo@cdma-2000.org > In Body: (un)subscribe seamoby your_e-mail_address > Archive: http://www.diameter.org/cgi-bin/lwgate/seamoby/ > > > History > > During the fast handoff discussions within the Mobile IP WG, a need for a > new > protocol was identified that would allow state information to be > transferred > between edge devices (e.g. Foreign Agents). Examples of state information > that > could need to be transferred is AAA information, security context, QOS > properties assigned to the user, Robust Header Compression information, > etc. > > SDOs that work on wireless, such as 3GPP, 3GPP2, IEEE and others, are > hoping > that the IETF will be able to provide a set of protocols that will enable > them to provide real-time services over an IP infrastructure, and, along > with Mobile IP, SeaMoby is expected to provide such protocols. > Furthermore, > the protocols developed by the Seamoby Working Group must allow for > real-time services to work with minimal disruption across heterogeneous > wireless, and wired, technologies. > > It is expected that SDOs working on wireless technologies will provide > their > input into the WG during the requirements gathering and protocol design > phase. > > Description > > There are a large number of IP access networks that support mobility of > hosts. > For example, wireless Personal Area Networks (PANs) and LANs, satellite > and > cellular WANs. The nature of this roaming is such that the communication > path > to the host changes frequently, and rapidly. In many situations, the > change of > communications path includes a change in communications media between the > host > and access networking, including changes from a wireless to a wired > connection and changes between wireless technologies even under common > administration. > > Although the protocol used to actively re-direct the IP packet flows > during a > change in a mobile's point of attachment is handled by other Working > Groups, > there is a need for preserving the context of its active IP flows. The IP > flow > context includes, but is not limited to security context, policy, QOS, > congestion indication/management, header compression and accounting. > > The SeaMoby Working group will analyze the requirements and tradeoffs for > the > goal of transferring context information from a mobile's old access to the > new > access point (versus accessing needed context over a distance). > > Depending on the results of the requirements analysis, the SeaMoby Working > Group will develop a protocol (or start from an existing protocol such as > Contract Net Protocol (CNP) or the IEEE's 802.11f) to transfer the context > information for a session. The context information to be transferred > includes > QOS, header compression state, policy, security context, congestion > management > state, AAA information, etc. Transferring context state is expected to > provide a more robust handoff to the user, and applications. Quality of > service (QOS) state may include both diffserv and intserv information, as > needed. > > While other IETF Working Groups are developing protocols to provide "fast > handoff" solutions, the mechanisms currently under development are > designed > to hand off a mobile to the first available handoff candidate. The Seamoby > > Working Group has documented that "seamless" handoffs can be achieved by > ensuring that a handoff occurs to a candidate that can best support a > given > mobile, and this work in not within the scope of the "fast handoff" > protocols > being developed. Seamoby will define the work in a problem statement, and > if needed, will define the requirements and the protocol for a handoff > candidate discovery protocol, which could be used with any mobility > management protocol. > > Lastly, the Working Group will define the requirements for Dormant Mode > Host > Alerting (DMHA) at the IP layer (also known as IP Paging) in networks, and > a > protocol will be developed to tackle this problem. DMHA is typically used > in > networks that support mobile devices that periodically enter dormant mode > to > reduce power consumption. DMHA enable network devices to track a mobile > that > has moved from its last point of attachment, while in dormant mode, > allowing > the mobile's packets to be delivered. > > All work produced by the Working Group will support both IPv4 and IPv6, > will > follow the congestion control principles in RFC2914 (BCP41), and will > undergo > a security review prior to WG last call. > > The Working Group will coordinate closely with the aaa, cnrp, impp, > mobileip, > pilc, and rohc working groups. > > > Goals and Milestones: > > Jun 01 Submit I-D on Dormant Mode Host Alerting Requirements [Syed, Hamid [WDLN2:AN22:EXCH]] I am assuming that the inter acces point requirement I-D would be submitted in the same time frame. Probably, a milestone here should reflect it. > Jul 01 Submit Handoff Candidate Discovery Problem Statement > Sep 01 Interim Meeting to review Inter Access Point Context Transfer and > Handoff Candidate Discovery Requirements [Syed, Hamid [WDLN2:AN22:EXCH]] This is kind of late for inter access point ct. are we going to discuss the requirements for the next few months?? > Oct 01 Dormant Mode Host Alerting Protocol to IESG for consideration as a > Proposed Standard > Oct 01 Submit requirements analysis for Inter Access Point Context > Transfer > Protocol to IESG for consideration as Informational > Oct 01 Submit Handoff Discovery Requirements I-D to IESG for > consideration > as Informational > Nov 01 Candidate Inter Access Point Context Transfer Protocols > are submitted, with accompanying comparison against requirements > Nov 01 Candidate Handoff Discovery Protocols are submitted, with > accompanying comparison against requirements > Dec 01 Dormant Mode Host Alerting Protocol MIB to IESG for consideration > as a > Proposed Standard > Feb 02 Inter Access Point Context Transfer Protocol to IESG for > consideration > as a Proposed Standard > Feb 02 Handoff Discovery Protocol to IESG for consideration as a Proposed > > Standard > Jun 02 Submit Inter Access Point Context Transfer Protocol MIB to IESG > for > consideration as a Proposed Standard > Jun 02 Submit Handoff Discovery Protocol MIB to IESG for consideration as > a > Proposed Standard ------_=_NextPart_001_01C0DC87.40146CF0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [seamoby] Seamoby Charter Last Call

Pat,

few comments on WG = milestones..

-Hamid

    -----Original Message-----
    From:   Pat Calhoun [SMTP:pcalhoun@diameter.org]
    Sent:   Saturday, May 12, 2001 3:23 PM
    To:     seamoby@cdma-2000.org
    Subject:       = [seamoby] Seamoby Charter Last = Call

    All,

    Below is the proposed Seamoby Charter. = The WG last call will be completed
    on May 29th (given the long weekend = in the US).

    We had proposed to write up a set of = issues that we had found with the
    Mobile IP protocol, but our AD stated = that this work really needs to occur
    in the MIP WG. So I would ask that = all interested parties take up that
    activity on the MIP mailing = list.

    Please send any comments to the = list.

    Thanks,

    PatC
    ----
    Context Transfer, Handoff Candidate = Discovery and Dormant Mode Host
    Alerting (seamoby)



    Chair(s):

    Pat Calhoun = <pcalhoun@diameter.org>

    Transport Area Director(s):

    Scott Bradner = <sob@harvard.edu>
    Allison Mankin = <mankin@isi.edu>

    Transport Area Advisor:

    Allison Mankin = <mankin@isi.edu>

    Mailing Lists:

    General = Discussion:seamoby@cdma-2000.org
    To Subscribe: majordomo@cdma-2000.org =
    In Body: (un)subscribe seamoby = your_e-mail_address
    Archive: http://www.diameter.org/cgi-bin/lwgate/seamoby/


    History

    During the fast handoff discussions = within the Mobile IP WG, a need for a new
    protocol was identified that would = allow state information to be transferred
    between edge devices (e.g. Foreign = Agents). Examples of state information that
    could need to be transferred is AAA = information, security context, QOS
    properties assigned to the user, = Robust Header Compression information, etc.

    SDOs that work on wireless, such as = 3GPP, 3GPP2, IEEE and others, are hoping
    that the IETF will be able to provide = a set of protocols that will enable
    them to provide real-time services = over an IP infrastructure, and, along
    with Mobile IP, SeaMoby is expected = to provide such protocols. Furthermore,
    the protocols developed by the = Seamoby Working Group must allow for
    real-time services to work with = minimal disruption across heterogeneous
    wireless, and wired, = technologies.

    It is expected that SDOs working on = wireless technologies will provide their
    input into the WG during the = requirements gathering and protocol design
    phase.

    Description

    There are a large number of IP access = networks that support mobility of hosts.
    For example, wireless Personal Area = Networks (PANs) and LANs, satellite and
    cellular WANs. The nature of this = roaming is such that the communication path
    to the host changes frequently, and = rapidly. In many situations, the change of
    communications path includes a change = in communications media between the host
    and access networking, including = changes from a wireless to a wired
    connection and changes between = wireless technologies even under common
    administration.

    Although the protocol used to actively = re-direct the IP packet flows during a
    change in a mobile's point of = attachment is handled by other Working Groups,
    there is a need for preserving the = context of its active IP flows. The IP flow
    context includes, but is not limited = to security context, policy, QOS,
    congestion indication/management, = header compression and accounting.

    The SeaMoby Working group will analyze = the requirements and tradeoffs for the
    goal of transferring context = information from a mobile's old access to the new
    access point (versus accessing needed = context over a distance).

    Depending on the results of the = requirements analysis, the SeaMoby Working
    Group will develop a protocol (or = start from an existing protocol such as
    Contract Net Protocol (CNP) or the = IEEE's 802.11f) to transfer the context
    information for a session. The = context information to be transferred includes
    QOS, header compression state, = policy, security context, congestion management
    state, AAA information, etc. = Transferring context state is expected to
    provide a more robust handoff to the = user, and applications. Quality of
    service (QOS) state may include both = diffserv and intserv information, as
    needed.

    While other IETF Working Groups are = developing protocols to provide "fast
    handoff" solutions, the = mechanisms currently under development are designed
    to hand off a mobile to the first = available handoff candidate. The Seamoby
    Working Group has documented that = "seamless" handoffs can be achieved by
    ensuring that a handoff occurs to a = candidate that can best support a given
    mobile, and this work in not within = the scope of the "fast handoff" protocols
    being developed. Seamoby will define = the work in a problem statement, and
    if needed, will define the = requirements and the protocol for a handoff
    candidate discovery protocol, which = could be used with any mobility
    management protocol.

    Lastly, the Working Group will define = the requirements for Dormant Mode Host
    Alerting (DMHA) at the IP layer (also = known as IP Paging) in networks, and a
    protocol will be developed to tackle = this problem. DMHA is typically used in
    networks that support mobile devices = that periodically enter dormant mode to
    reduce power consumption. DMHA enable = network devices to track a mobile that
    has moved from its last point of = attachment, while in dormant mode, allowing
    the mobile's packets to be = delivered.

    All work produced by the Working Group = will support both IPv4 and IPv6, will
    follow the congestion control = principles in RFC2914 (BCP41), and will undergo
    a security review prior to WG last = call.

    The Working Group will coordinate = closely with the aaa, cnrp, impp, mobileip,
    pilc, and rohc working groups. =


    Goals and Milestones:

    Jun 01  Submit I-D on Dormant = Mode Host Alerting Requirements
    [Syed, Hamid = [WDLN2:AN22:EXCH]]  I am assuming that the inter acces point = requirement I-D would be submitted in the same time frame. Probably, a = milestone here should reflect it.

    Jul 01  Submit Handoff Candidate = Discovery Problem Statement
    Sep 01  Interim Meeting to = review Inter Access Point Context Transfer and
            Handoff Candidate Discovery Requirements
    [Syed, Hamid = [WDLN2:AN22:EXCH]]  This is kind of late for inter access point = ct. are we going to discuss the requirements for the next few = months??

    Oct 01  Dormant Mode Host = Alerting Protocol to IESG for consideration as a
            Proposed Standard
    Oct 01  Submit requirements = analysis for Inter Access Point Context Transfer
            Protocol to IESG for consideration as = Informational
    Oct 01  Submit Handoff Discovery = Requirements I-D to IESG for consideration
            as Informational
    Nov 01  Candidate Inter Access = Point Context Transfer Protocols
            are submitted, with accompanying comparison against = requirements
    Nov 01  Candidate Handoff = Discovery Protocols are submitted, with 
            accompanying comparison against requirements
    Dec 01  Dormant Mode Host = Alerting Protocol MIB to IESG for consideration as a
            Proposed Standard
    Feb 02  Inter Access Point = Context Transfer Protocol to IESG for consideration
            as a Proposed Standard
    Feb 02  Handoff Discovery = Protocol to IESG for consideration as a Proposed
            Standard
    Jun 02  Submit Inter Access = Point Context Transfer Protocol MIB to IESG for
            consideration as a Proposed Standard
    Jun 02  Submit Handoff Discovery = Protocol MIB to IESG for consideration as a
            Proposed Standard

------_=_NextPart_001_01C0DC87.40146CF0-- From owner-seamoby@diameter.org Mon May 14 12:09:00 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16415 for ; Mon, 14 May 2001 12:08:57 -0400 (EDT) Received: (qmail 29827 invoked by alias); 14 May 2001 15:55:52 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 29821 invoked by uid 200); 14 May 2001 15:55:52 -0000 Received: (qmail 29813 invoked from network); 14 May 2001 15:55:49 -0000 Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.nortelnetworks.com) (47.129.242.157) by c900656-a.plstn1.sfba.home.com with SMTP; 14 May 2001 15:55:49 -0000 Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id MAA09427; Mon, 14 May 2001 12:06:00 -0400 Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Mon, 14 May 2001 12:05:56 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 May 2001 12:03:10 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C125904@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Pat Calhoun'" Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] Seamoby Charter Last Call Date: Mon, 14 May 2001 12:03:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DC8F.5CBE3FE0" 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_01C0DC8F.5CBE3FE0 Content-Type: text/plain; charset="ISO-8859-1" > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Monday, May 14, 2001 10:04 AM > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: 'Pat Calhoun'; seamoby@cdma-2000.org > Subject: Re: [seamoby] Seamoby Charter Last Call > > > On Mon, May 14, 2001 at 10:09:13AM -0400, Gary Kenward wrote: > > > The SeaMoby Working group will analyze the requirements and > > > tradeoffs for the > > > goal of transferring context information from a mobile's old > > > access to the new > > > access point (versus accessing needed context over a distance). > > > > I understand what was intended here, but the role of the "access > > point" has been a topic of great debate. To some, an "access point" > > is a box in a specific network soltuion. There is no simple > alternative > > (that I have been able to come up with), but in the > requirements documents > > we have used "point of access" instead of "access point". > > To me, point of access doesn't necessarily imply an actual device, but > more of a connection point (e.g. ethernet port). Would access device > work better? It is commonly used in many other WGs. As I tried to point out, you could call it "fred" as far as I am concerned, but the term does matter to some people. > > > > Sep 01 Interim Meeting to review Inter Access Point Context > > > Transfer and > > > Handoff Candidate Discovery Requirements > > > > Why so late? > > There is no penalty for being early. Please excuse me, but it was a serious question. You have clearly identified aggressive milestones for the paging and other work. Why do you believe the context transfer requirements will take until September, and then require an "interim meeting". Particularly, when the later implies travel and thus $$$. As far as I know, no one in the design team was consulted concerning these dates, and your answer implies that you are not open to input from us. If the dt is irrelevant to the wg progress, then please tell us so that we can move on to other pursuits. Gary > > PatC > ------_=_NextPart_001_01C0DC8F.5CBE3FE0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [seamoby] Seamoby Charter Last Call

> -----Original Message-----
> From: Pat Calhoun [mailto:pcalhoun@diameter.org]<= /FONT>
> Sent: Monday, May 14, 2001 10:04 AM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'Pat Calhoun'; seamoby@cdma-2000.org
> Subject: Re: [seamoby] Seamoby Charter Last = Call
>
>
> On Mon, May 14, 2001 at 10:09:13AM -0400, Gary = Kenward wrote:
> > > The SeaMoby Working group will = analyze the requirements and
> > > tradeoffs for the
> > > goal of transferring context = information from a mobile's old
> > > access to the new
> > > access point (versus accessing needed = context over a distance).
> >
> > I understand what was intended here, but = the role of the "access
> > point" has been a topic of great = debate. To some, an "access point"
> > is a box in a specific network soltuion. = There is no simple
> alternative
> > (that I have been able to come up with), = but in the
> requirements documents
> > we have used "point of access" = instead of "access point".
>
> To me, point of access doesn't necessarily = imply an actual device, but
> more of a connection point (e.g. ethernet = port). Would access device
> work better? It is commonly used in many other = WGs.

As I tried to point out, you could call it = "fred" as far as I am concerned,
but the term does matter to some people.

>
> > > Sep 01  Interim Meeting to = review Inter Access Point Context
> > > Transfer and
> > >   Handoff Candidate Discovery = Requirements
> >
> > Why so late?
>
> There is no penalty for being early.

Please excuse me, but it was a serious question. You = have clearly identified
aggressive milestones for the paging and other work. = Why do you believe the context transfer requirements will take until = September, and then require an "interim meeting".

Particularly, when the later implies travel and thus = $$$.

As far as I know, no one in the design team was = consulted concerning these dates, and your answer implies that you are = not open to input from us. If the dt is irrelevant to the wg progress, = then please tell us so that we can move on to other pursuits. =

Gary
>
> PatC
>

------_=_NextPart_001_01C0DC8F.5CBE3FE0-- From owner-seamoby@diameter.org Mon May 14 12:19:57 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16722 for ; Mon, 14 May 2001 12:19:55 -0400 (EDT) Received: (qmail 30385 invoked by alias); 14 May 2001 16:08:12 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 30379 invoked by uid 200); 14 May 2001 16:08:12 -0000 Received: (qmail 30369 invoked by uid 500); 14 May 2001 16:08:09 -0000 Date: Mon, 14 May 2001 09:08:09 -0700 From: Pat Calhoun To: Gary Kenward Cc: "'Pat Calhoun'" , seamoby@cdma-2000.org Subject: Re: [seamoby] Seamoby Charter Last Call Message-ID: <20010514090809.X10188@charizard.diameter.org> Mail-Followup-To: Gary Kenward , 'Pat Calhoun' , seamoby@cdma-2000.org References: <9FBD322B7824D511B36900508BF93C9C125904@zcard031.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <9FBD322B7824D511B36900508BF93C9C125904@zcard031.ca.nortel.com>; from gkenward@nortelnetworks.com on Mon, May 14, 2001 at 12:03:06PM -0400 Sender: owner-seamoby@diameter.org Precedence: bulk On Mon, May 14, 2001 at 12:03:06PM -0400, Gary Kenward wrote: > > > > To me, point of access doesn't necessarily imply an actual device, but > > more of a connection point (e.g. ethernet port). Would access device > > work better? It is commonly used in many other WGs. > > As I tried to point out, you could call it "fred" as far as I am concerned, > but the term does matter to some people. but using fred would require that people read drafts to recognize "fred". Please keep in mind that people that do not follow our working group, let alone read the specs, will read the charter. These people have to know what's we are up to. So my use of the word "access point" was intended to make the charter understandable to such people. Keep in mind that the words used in the charter do not necessarily reflect what other words the group has decided is more appropriate in the specs. In any case, in the interest of moving along, does the WG (and ADs) care if we use "point of access"? > > > > > > > Sep 01 Interim Meeting to review Inter Access Point Context > > > > Transfer and > > > > Handoff Candidate Discovery Requirements > > > > > > Why so late? > > > > There is no penalty for being early. > > Please excuse me, but it was a serious question. as was my response. > You have clearly identified > aggressive milestones for the paging and other work. Why do you believe the > context transfer requirements will take until September, and then require an > "interim meeting". > Particularly, when the later implies travel and thus $$$. > > As far as I know, no one in the design team was consulted concerning these > dates, and your answer implies that you are not open to input from us. If > the dt is irrelevant to the wg progress, then please tell us so that we can > move on to other pursuits. This e-mail is to *request* input from the WG. This is a last call, and requires WG approval. You requested why the dates were so late, and I felt that it was better to be early than late. My response to your question was honest, and to the point. Nothing was intentionally implied. If people have comments on the dates, then by all means, propose changes. PatC From owner-seamoby@diameter.org Mon May 14 12:31:58 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17173 for ; Mon, 14 May 2001 12:31:47 -0400 (EDT) Received: (qmail 30889 invoked by alias); 14 May 2001 16:17:30 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 30883 invoked by uid 200); 14 May 2001 16:17:30 -0000 Received: (qmail 30878 invoked from network); 14 May 2001 16:17:28 -0000 Received: from out1.prserv.net (HELO prserv.net) (32.97.166.31) by c900656-a.plstn1.sfba.home.com with SMTP; 14 May 2001 16:17:28 -0000 Received: from [32.101.185.157] (slip-32-101-185-157.ca.us.prserv.net[32.101.185.157]) by prserv.net (out1) with ESMTP id <2001051416280620102sbg7ae>; Mon, 14 May 2001 16:28:07 +0000 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="============_-1222264784==_ma============" X-Sender: ahmrphd@pop3.attglobal.net Message-Id: In-Reply-To: <9FBD322B7824D511B36900508BF93C9C1258FE@zcard031.ca.nortel.com> Date: Mon, 14 May 2001 09:27:28 -0700 To: "Gary Kenward" , "'Pat Calhoun'" , seamoby@cdma-2000.org From: Arthur Ross Subject: RE: [seamoby] Seamoby Charter Last Call Cc: wirelessinternet@internet.motlabs.com Sender: owner-seamoby@diameter.org Precedence: bulk --============_-1222264784==_ma============ Content-Type: text/plain; charset="us-ascii" At 7:09 -0700 05/14/2001, Gary Kenward wrote: >> The SeaMoby Working group will analyze the requirements and >> tradeoffs for the >> goal of transferring context information from a mobile's old >> access to the new >> access point (versus accessing needed context over a distance). > >I understand what was intended here, but the role of the "access >point" has been a topic of great debate. To some, an "access point" >is a box in a specific network solution. There is no simple alternative >(that I have been able to come up with), but in the requirements documents >we have used "point of access" instead of "access point". Indeed - While I don't think that the SeaMoby charter is the right place to raise it, this seems to me to be a microcosm of a MAJOR ISSUE confronting the world if IP - one that should be addressed at the highest level, namely: the UNDERLYING ARCHITECTURAL ABSTRACTIONS. We talk at great length about hosts, mobile nodes, etc., but the notion of "host" or "node" is getting fuzzy. Originally [ARPANET] "hosts" were big computers that filled rooms, had squads of people caring for & feeding them, and the protocols were designed with that implicit mindset. But nowadays, when the embodiments of the "hosts" may cost just pennies, may be flyspeck-sized, and may be found in all sorts of non-traditional, often low-tech kinds of places/things, the concepts need revision. My strong feeling is that the questions to be addressed should be things like: * What are the entities that are the endpoints of the communication? When the address space is large enough [IPv6] to give every cell of every human being and every grain of sand on earth its own IP address, perhaps the model and uses of it need to be re-thought. * What is MEANT by "mobility"? Or alternatively what is it that is moving? I can envision many possible answers/opinions. * How are those endpoints identified for various purposes? A major example: paging - IP address, as in MIP, is [perhaps] meaningful for routing purposes, but meaningless in the application context. One could envision a concept whereby there are various "views" of the endpoint space applicable for different sorts of applications (e.g. routing, logical, name-based, geographic, organizational hierarchy, demographic group, etc.). In this light, paging/addressing might be viewed/implemented as a kind of distributed database query. * What is the nature of the "identity" associated with, say, individual humans, that provides the basis/data for authentication? I'm thinking of something like a great-grandson of the SIM card concept, for example [... or maybe you will begin every session with a request to "spit in the little spitoon" on your laptop for the DNA analysis that authenticates the session. ;-) ]. * Is a broader concept of the "addressable individual" needed? [I have in mind functional pseudo-persons, associated with business & organization roles, databases of various kinds, etc.] * Is a "discovery" functionality needed? I.e. a generic method for exposing the internal structure of subnets and/or databases? I.e. a way of creating the local streetmap of an unfamiliar neighborhood? This might be especially important if the "mobile" entities have internal, time-varying structure [think, for a simple example, of folks in vehicles on the highway, each potentially with his PDA, phone, medical monitoring device, plus the "smart car" itself, etc., all of which are communicating through a wireless gateway of some kind; just such things are currently under development]. * What are the business and regulatory models? Giant electro-political hot potato, but very important, IMHO. The regulatory folks need to clean up their act if the mythical "wireless Internet" is to be anything other than hype and snake oil. I have in mind here a complete re-think of the spectrum license auction notion. I personally believe that auctioning the ether was, and still is, a bad idea, not in the long term public interest. The pro-auction argument is that real estate-like ownership is a prerequisite if investors are going to pony up the huge capital expenditures needed to build the "next generation" networks. The fallacy here, IMHO, is the PSTN-centric mindset. If what you are talking about is universal, readily-available wirless IP service, starting from a telephone network is very obviously a bad way of doing it. IMHO wireless IP access should be viewed, for regulatory purposes, as more like a public utility than the proverbial "walled garden" for which the owner charges at the tollbooth. You could make a lot of money by letting someone charge for the air we breathe too, but in neither case is it good public policy. There are many aspects to this, and many ways of pulling it off, as I have tried to convince the FCC for some time now. * What replaces the "walled garden" wireless air interfaces? Good question. I have some opinions as to what it MIGHT be, but other opinions may [read: "undoubtedly will"] differ. This will be, I hope, the subject of this new "wireless internet" discussion group. Just one crazy old fart's opinion ... [My apologies if you get this more than once due to list redundancies.] -- Best regards, -- ahmr --============_-1222264784==_ma============ Content-Type: text/enriched; charset="us-ascii" At 7:09 -0700 05/14/2001, Gary Kenward wrote: > The SeaMoby Working group will analyze the requirements and > tradeoffs for the > goal of transferring context information from a mobile's old > access to the new > access point (versus accessing needed context over a distance). I understand what was intended here, but the role of the "access point" has been a topic of great debate. To some, an "access point" is a box in a specific network solution. There is no simple alternative (that I have been able to come up with), but in the requirements documents we have used "point of access" instead of "access point". Indeed - While I don't think that the SeaMoby charter is the right place to raise it, this seems to me to be a microcosm of a MAJOR ISSUE confronting the world if IP - one that should be addressed at the highest level, namely: the UNDERLYING ARCHITECTURAL ABSTRACTIONS. < We talk at great length about hosts, mobile nodes, etc., but the notion of "host" or "node" is getting fuzzy. Originally [ARPANET] "hosts" were big computers that filled rooms, had squads of people caring for & feeding them, and the protocols were designed with that implicit mindset. But nowadays, when the embodiments of the "hosts" may cost just pennies, may be flyspeck-sized, and may be found in all sorts of non-traditional, often low-tech kinds of places/things, the concepts need revision. My strong feeling is that the questions to be addressed should be things like: * What are the entities that are the endpoints of the communication? When the address space is large enough [IPv6] to give every cell of every human being and every grain of sand on earth its own IP address, perhaps the model and uses of it need to be re-thought. * What is MEANT by "mobility"? Or alternatively what is it that is moving? I can envision many possible answers/opinions. * How are those endpoints identified for various purposes? A major example: paging - IP address, as in MIP, is [perhaps] meaningful for routing purposes, but meaningless in the application context. One could envision a concept whereby there are various "views" of the endpoint space applicable for different sorts of applications (e.g. routing, logical, name-based, geographic, organizational hierarchy, demographic group, etc.). In this light, paging/addressing might be viewed/implemented as a kind of distributed database query. * What is the nature of the "identity" associated with, say, individual humans, that provides the basis/data for authentication? I'm thinking of something like a great-grandson of the SIM card concept, for example [... or maybe you will begin every session with a request to "spit in the little spitoon" on your laptop for the DNA analysis that authenticates the session. ;-) ]. * Is a broader concept of the "addressable individual" needed? [I have in mind functional pseudo-persons, associated with business & organization roles, databases of various kinds, etc.] * Is a "discovery" functionality needed? I.e. a generic method for exposing the internal structure of subnets and/or databases? I.e. a way of creating the local streetmap of an unfamiliar neighborhood? This might be especially important if the "mobile" entities have internal, time-varying structure [think, for a simple example, of folks in vehicles on the highway, each potentially with his PDA, phone, medical monitoring device, plus the "smart car" itself, etc., all of which are communicating through a wireless gateway of some kind; just such things are currently under development]. * What are the business and regulatory models? Giant electro-political hot potato, but very important, IMHO. The regulatory folks need to clean up their act if the mythical "wireless Internet" is to be anything other than hype and snake oil. I have in mind here a complete re-think of the spectrum license auction notion. I personally believe that auctioning the ether was, and still is, a bad idea, not in the long term public interest. The pro-auction argument is that real estate-like ownership is a prerequisite if investors are going to pony up the huge capital expenditures needed to build the "next generation" networks. The fallacy here, IMHO, is the PSTN-centric mindset. If what you are talking about is universal, readily-available wirless IP service, starting from a telephone network is very obviously a bad way of doing it. IMHO wireless IP access should be viewed, for regulatory purposes, as more like a public utility than the proverbial "walled garden" for which the owner charges at the tollbooth. You could make a lot of money by letting someone charge for the air we breathe too, but in neither case is it good public policy. There are many aspects to this, and many ways of pulling it off, as I have tried to convince the FCC for some time now. * What replaces the "walled garden" wireless air interfaces? Good question. I have some opinions as to what it MIGHT be, but other opinions may [read: "undoubtedly will"] differ. This will be, I hope, the subject of this new "wireless internet" discussion group. Just one crazy old fart's opinion ... < [My apologies if you get this more than once due to list redundancies.] -- Best regards, -- ahmr --============_-1222264784==_ma============-- From owner-seamoby@diameter.org Mon May 14 12:43:39 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17564 for ; Mon, 14 May 2001 12:43:38 -0400 (EDT) Received: (qmail 31922 invoked by alias); 14 May 2001 16:31:03 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 31916 invoked by uid 200); 14 May 2001 16:31:02 -0000 Received: (qmail 31905 invoked by uid 500); 14 May 2001 16:31:00 -0000 Date: Mon, 14 May 2001 09:31:00 -0700 From: Pat Calhoun To: Hamid Syed Cc: "'Pat Calhoun'" , seamoby@cdma-2000.org Subject: Re: [seamoby] Seamoby Charter Last Call Message-ID: <20010514093100.Y10188@charizard.diameter.org> Mail-Followup-To: Hamid Syed , 'Pat Calhoun' , seamoby@cdma-2000.org References: <9FBD322B7824D511B36900508BF93C9C1CD076@zcard031.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <9FBD322B7824D511B36900508BF93C9C1CD076@zcard031.ca.nortel.com>; from hmsyed@nortelnetworks.com on Mon, May 14, 2001 at 11:05:02AM -0400 Sender: owner-seamoby@diameter.org Precedence: bulk On Mon, May 14, 2001 at 11:05:02AM -0400, Hamid Syed wrote: > > Jun 01 Submit I-D on Dormant Mode Host Alerting Requirements > [Syed, Hamid [WDLN2:AN22:EXCH]] I am assuming that the inter acces > point requirement I-D would be submitted in the same time frame. Probably, a > milestone here should reflect it. What is the inter access point requirement I-D? > > Sep 01 Interim Meeting to review Inter Access Point Context Transfer and > > Handoff Candidate Discovery Requirements > [Syed, Hamid [WDLN2:AN22:EXCH]] This is kind of late for inter > access point ct. are we going to discuss the requirements for the next few > months?? If you believe that the charter needs to be revised, now is the time. I felt more comfortable having dates where we would end up early as opposed to late. PatC From owner-seamoby@diameter.org Mon May 14 12:46:39 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17723 for ; Mon, 14 May 2001 12:46:38 -0400 (EDT) Received: (qmail 32471 invoked by alias); 14 May 2001 16:34:50 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 32465 invoked by uid 200); 14 May 2001 16:34:49 -0000 Received: (qmail 32460 invoked from network); 14 May 2001 16:34:48 -0000 Received: from patan.sun.com (192.18.98.43) by c900656-a.plstn1.sfba.home.com with SMTP; 14 May 2001 16:34:48 -0000 Received: from heliopolis.eng.sun.com ([152.70.1.39]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06786; Mon, 14 May 2001 09:45:32 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id JAA04455; Mon, 14 May 2001 09:45:32 -0700 (PDT) Message-Id: <200105141645.JAA04455@heliopolis.eng.sun.com> Date: Mon, 14 May 2001 09:45:32 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: RE: [seamoby] Seamoby Charter Last Call To: pcalhoun@diameter.org, gkenward@nortelnetworks.com Cc: seamoby@cdma-2000.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: wQcAB2sjC7I9tN11THVbcQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-seamoby@diameter.org Precedence: bulk Gary/Pat, >> > > >> > > To me, point of access doesn't necessarily imply an >> actual device, but >> > > more of a connection point (e.g. ethernet port). Would >> access device >> > > work better? It is commonly used in many other WGs. >> > >> > As I tried to point out, you could call it "fred" as far as >> I am concerned, >> > but the term does matter to some people. >> >> but using fred would require that people read drafts to >> recognize "fred". >> Please keep in mind that people that do not follow our >> working group, let >> alone read the specs, will read the charter. These people have to know >> what's we are up to. So my use of the word "access point" was >> intended to >> make the charter understandable to such people. >> >> Keep in mind that the words used in the charter do not >> necessarily reflect >> what other words the group has decided is more appropriate in >> the specs. > >No, but it would be nice if the words in the charter reflected the >consensus of the wg. And "access point" has been a contentious >term (BUT NOT for me). If it's contentious within the group, >it will be contentious outside the group? > Maybe we need a terminology draft, or at least, define this term somewhere so that it can be referred to. I'm suprised nobody has done a generalized terminology draft for wireless terms before in the MIP group. jak From owner-seamoby@diameter.org Mon May 14 12:52:11 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17839 for ; Mon, 14 May 2001 12:52:11 -0400 (EDT) Received: (qmail 534 invoked by alias); 14 May 2001 16:40:30 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 528 invoked by uid 200); 14 May 2001 16:40:30 -0000 Received: (qmail 519 invoked by uid 500); 14 May 2001 16:40:28 -0000 Date: Mon, 14 May 2001 09:40:28 -0700 From: Pat Calhoun To: Gary Kenward Cc: "'Pat Calhoun'" , seamoby@cdma-2000.org Subject: Re: [seamoby] Seamoby Charter Last Call Message-ID: <20010514094028.Z10188@charizard.diameter.org> Mail-Followup-To: Gary Kenward , 'Pat Calhoun' , seamoby@cdma-2000.org References: <9FBD322B7824D511B36900508BF93C9C125907@zcard031.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <9FBD322B7824D511B36900508BF93C9C125907@zcard031.ca.nortel.com>; from gkenward@nortelnetworks.com on Mon, May 14, 2001 at 12:34:30PM -0400 Sender: owner-seamoby@diameter.org Precedence: bulk On Mon, May 14, 2001 at 12:34:30PM -0400, Gary Kenward wrote: > > It did not come across as serious, but, to be frank, rather > flippant. well, that was not the intended message I was targetting. It was to the point (in my mind). In any case... > Perhaps you might ask when the requirements draft > will be completed, and what people believe are good dates for > the follow on work. Right, well my proposed charter was exactly that. I would have sent multiple e-mails to everyone, but it seemed more logical for me to write the charter, propose it, and then have the group discuss it. > > As far as I can tell, the design team is near to completion > on the requirements draft. It is my intention to have a "last > call" in the dt this week. I have reason to believe that we > will achieve reasonable consensus. Of course, there is always > a possibility this won't happen), however, it does seem reasonable > that we do not need 4 more months and an interim meeting to complete > the draft. ok, but *do* keep in mind that the document has to go through WG review once it is done within the DT. Then the document has to go through IETF and IESG review. Perhaps these will not necessary raise points that would need to be discussed within an interim meeting, but we (myself and the ADs) felt that scheduling an Interim meeting in the milestones could prepare people for possible travel. If there is no reason to meet, then the meeting would be cancelled. > I think we need milestones that represent the work that has been > done, and the progress that can be made. Yes, but given history, I prefer to have dates that include a little cushion, and the other folks interested in our work (e.g. SDOs) can schedule their work based on our dates. If we are done early, then they are happy. If we are late, then it throws off their schedules. PatC From owner-seamoby@diameter.org Mon May 14 12:55:49 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17940 for ; Mon, 14 May 2001 12:55:48 -0400 (EDT) Received: (qmail 933 invoked by alias); 14 May 2001 16:41:57 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 927 invoked by uid 200); 14 May 2001 16:41:57 -0000 Received: (qmail 915 invoked by uid 500); 14 May 2001 16:41:55 -0000 Date: Mon, 14 May 2001 09:41:55 -0700 From: Pat Calhoun To: James Kempf Cc: pcalhoun@diameter.org, gkenward@nortelnetworks.com, seamoby@cdma-2000.org Subject: Re: [seamoby] Seamoby Charter Last Call Message-ID: <20010514094155.A10188@charizard.diameter.org> Mail-Followup-To: James Kempf , pcalhoun@diameter.org, gkenward@nortelnetworks.com, seamoby@cdma-2000.org References: <200105141645.JAA04455@heliopolis.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200105141645.JAA04455@heliopolis.eng.sun.com>; from James.Kempf@Sun.COM on Mon, May 14, 2001 at 09:45:32AM -0700 Sender: owner-seamoby@diameter.org Precedence: bulk On Mon, May 14, 2001 at 09:45:32AM -0700, James Kempf wrote: > Maybe we need a terminology draft, or at least, define this term > somewhere so that it can be referred to. I'm suprised nobody > has done a generalized terminology draft for wireless terms before in the MIP > group. I agree, but I wouldn't want people to have to read such a draft just to understand our charter. PatC From owner-seamoby@diameter.org Mon May 14 13:03:01 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18181 for ; Mon, 14 May 2001 13:02:58 -0400 (EDT) Received: (qmail 31473 invoked by alias); 14 May 2001 16:25:01 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 31467 invoked by uid 200); 14 May 2001 16:25:01 -0000 Received: (qmail 31442 invoked from network); 14 May 2001 16:24:51 -0000 Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.nortelnetworks.com) (47.129.242.157) by c900656-a.plstn1.sfba.home.com with SMTP; 14 May 2001 16:24:51 -0000 Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id MAA12299; Mon, 14 May 2001 12:34:58 -0400 Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Mon, 14 May 2001 12:34:41 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 May 2001 12:34:38 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C125907@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Pat Calhoun'" Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] Seamoby Charter Last Call Date: Mon, 14 May 2001 12:34:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DC93.BFC732A0" 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_01C0DC93.BFC732A0 Content-Type: text/plain; charset="ISO-8859-1" > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Monday, May 14, 2001 12:08 PM > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: 'Pat Calhoun'; seamoby@cdma-2000.org > Subject: Re: [seamoby] Seamoby Charter Last Call > > > On Mon, May 14, 2001 at 12:03:06PM -0400, Gary Kenward wrote: > > > > > > To me, point of access doesn't necessarily imply an > actual device, but > > > more of a connection point (e.g. ethernet port). Would > access device > > > work better? It is commonly used in many other WGs. > > > > As I tried to point out, you could call it "fred" as far as > I am concerned, > > but the term does matter to some people. > > but using fred would require that people read drafts to > recognize "fred". > Please keep in mind that people that do not follow our > working group, let > alone read the specs, will read the charter. These people have to know > what's we are up to. So my use of the word "access point" was > intended to > make the charter understandable to such people. > > Keep in mind that the words used in the charter do not > necessarily reflect > what other words the group has decided is more appropriate in > the specs. No, but it would be nice if the words in the charter reflected the consensus of the wg. And "access point" has been a contentious term (BUT NOT for me). If it's contentious within the group, it will be contentious outside the group? > > In any case, in the interest of moving along, does the WG > (and ADs) care > if we use "point of access"? Which was exactly my point in the first place. > > > > > > > > > > > Sep 01 Interim Meeting to review Inter Access Point Context > > > > > Transfer and > > > > > Handoff Candidate Discovery Requirements > > > > > > > > Why so late? > > > > > > There is no penalty for being early. > > > > Please excuse me, but it was a serious question. > > as was my response. It did not come across as serious, but, to be frank, rather flippant. Perhaps you might ask when the requirements draft will be completed, and what people believe are good dates for the follow on work. As far as I can tell, the design team is near to completion on the requirements draft. It is my intention to have a "last call" in the dt this week. I have reason to believe that we will achieve reasonable consensus. Of course, there is always a possibility this won't happen), however, it does seem reasonable that we do not need 4 more months and an interim meeting to complete the draft. I think we need milestones that represent the work that has been done, and the progress that can be made. Gary > > > You have clearly identified > > aggressive milestones for the paging and other work. Why do > you believe the > > context transfer requirements will take until September, > and then require an > > "interim meeting". > > Particularly, when the later implies travel and thus $$$. > > > > As far as I know, no one in the design team was consulted > concerning these > > dates, and your answer implies that you are not open to > input from us. If > > the dt is irrelevant to the wg progress, then please tell > us so that we can > > move on to other pursuits. > > This e-mail is to *request* input from the WG. This is a last > call, and > requires WG approval. You requested why the dates were so late, and > I felt that it was better to be early than late. My response to your > question was honest, and to the point. Nothing was > intentionally implied. > > If people have comments on the dates, then by all means, > propose changes. > > PatC > ------_=_NextPart_001_01C0DC93.BFC732A0 Content-Type: text/html; charset="ISO-8859-1" RE: [seamoby] Seamoby Charter Last Call

> -----Original Message-----
> From: Pat Calhoun [mailto:pcalhoun@diameter.org]
> Sent: Monday, May 14, 2001 12:08 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'Pat Calhoun'; seamoby@cdma-2000.org
> Subject: Re: [seamoby] Seamoby Charter Last Call
>
>
> On Mon, May 14, 2001 at 12:03:06PM -0400, Gary Kenward wrote:
> > >
> > > To me, point of access doesn't necessarily imply an
> actual device, but
> > > more of a connection point (e.g. ethernet port). Would
> access device
> > > work better? It is commonly used in many other WGs.
> >
> > As I tried to point out, you could call it "fred" as far as
> I am concerned,
> > but the term does matter to some people.
>
> but using fred would require that people read drafts to
> recognize "fred".
> Please keep in mind that people that do not follow our
> working group, let
> alone read the specs, will read the charter. These people have to know
> what's we are up to. So my use of the word "access point" was
> intended to
> make the charter understandable to such people.
>
> Keep in mind that the words used in the charter do not
> necessarily reflect
> what other words the group has decided is more appropriate in
> the specs.

No, but it would be nice if the words in the charter reflected the
consensus of the wg. And "access point" has been a contentious
term (BUT NOT for me). If it's contentious within the group,
it will be contentious outside the group?

>
> In any case, in the interest of moving along, does the WG
> (and ADs) care
> if we use "point of access"?

Which was exactly my point in the first place.

>
> >
> > >
> > > > > Sep 01  Interim Meeting to review Inter Access Point Context
> > > > > Transfer and
> > > > >       Handoff Candidate Discovery Requirements
> > > >
> > > > Why so late?
> > >
> > > There is no penalty for being early.
> >
> > Please excuse me, but it was a serious question.
>
> as was my response.

It did not come across as serious, but, to be frank, rather
flippant. Perhaps you might ask when the requirements draft
will be completed, and what people believe are good dates for
the follow on work.

As far as I can tell, the design team is near to completion
on the requirements draft. It is my intention to have a "last
call" in the dt this week. I have reason to believe that we
will achieve reasonable consensus. Of course, there is always
a possibility this won't happen), however, it does seem reasonable
that we do not need 4 more months and an interim meeting to complete
the draft.

I think we need milestones that represent the work that has been
done, and the progress that can be made.

Gary
>
> > You have clearly identified
> > aggressive milestones for the paging and other work. Why do
> you believe the
> > context transfer requirements will take until September,
> and then require an
> > "interim meeting".
> > Particularly, when the later implies travel and thus $$$.
> >
> > As far as I know, no one in the design team was consulted
> concerning these
> > dates, and your answer implies that you are not open to
> input from us. If
> > the dt is irrelevant to the wg progress, then please tell
> us so that we can
> > move on to other pursuits.
>
> This e-mail is to *request* input from the WG. This is a last
> call, and
> requires WG approval. You requested why the dates were so late, and
> I felt that it was better to be early than late. My response to your
> question was honest, and to the point. Nothing was
> intentionally implied.
>
> If people have comments on the dates, then by all means,
> propose changes.
>
> PatC
>

------_=_NextPart_001_01C0DC93.BFC732A0-- From owner-seamoby@diameter.org Mon May 14 13:12:38 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18424 for ; Mon, 14 May 2001 13:12:34 -0400 (EDT) Received: (qmail 2244 invoked by alias); 14 May 2001 16:58:48 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2238 invoked by uid 200); 14 May 2001 16:58:48 -0000 Received: (qmail 2230 invoked from network); 14 May 2001 16:58:45 -0000 Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.nortelnetworks.com) (47.129.242.157) by c900656-a.plstn1.sfba.home.com with SMTP; 14 May 2001 16:58:45 -0000 Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id NAA15901; Mon, 14 May 2001 13:08:56 -0400 Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Mon, 14 May 2001 13:08:54 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 May 2001 13:08:56 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C12590C@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Pat Calhoun'" Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] Seamoby Charter Last Call Date: Mon, 14 May 2001 13:08:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DC98.89556A70" 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_01C0DC98.89556A70 Content-Type: text/plain; charset="ISO-8859-1" Ok. So, in the interest of moving on, I propose that we set June 8 as the deadline for the working group requirements draft. That allows 4 weeks for the ct team to finish the draft and the wg to review. As I indicated, the dt should be ready to release the reqs draft this week. The problem statement has been release. Given the lack of discussion on the email list, it would seem to me plausible to set a near term wg release date. I suggest May 25. This is all going to slow. I think many people are losing interest because they want to work on solutions and the "fuzzy front end" of problem statements and requirements is taking too long. Yes, I know these documents are important, but I also know that we can spend until September 2010 analyzing requirements, and still not get it right. Only by working on the solutions will we uncover the really unexpected "gotchas". As for "lining up with the SDOs"? When did this become a schedule driving priority? I think liasing with SDOs is important, but I don't see the need to link up the efforts explicitly. More importantly, I don't see how it can be done. You might link up with one SDO, but there are at least four that I can think of that are of equal importance, and we cannot favour any one over the others. Gary > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Monday, May 14, 2001 12:40 PM > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: 'Pat Calhoun'; seamoby@cdma-2000.org > Subject: Re: [seamoby] Seamoby Charter Last Call > > > On Mon, May 14, 2001 at 12:34:30PM -0400, Gary Kenward wrote: > > > > > It did not come across as serious, but, to be frank, rather > > flippant. > well, that was not the intended message I was targetting. It was > to the point (in my mind). In any case... > > > Perhaps you might ask when the requirements draft > > will be completed, and what people believe are good dates for > > the follow on work. > > Right, well my proposed charter was exactly that. > > I would have sent multiple e-mails to everyone, but it seemed > more logical > for me to write the charter, propose it, and then have the > group discuss > it. > > > > > As far as I can tell, the design team is near to completion > > on the requirements draft. It is my intention to have a "last > > call" in the dt this week. I have reason to believe that we > > will achieve reasonable consensus. Of course, there is always > > a possibility this won't happen), however, it does seem reasonable > > that we do not need 4 more months and an interim meeting to complete > > the draft. > > ok, but *do* keep in mind that the document has to go through > WG review > once it is done within the DT. Then the document has to go through > IETF and IESG review. Perhaps these will not necessary raise points > that would need to be discussed within an interim meeting, but we > (myself and the ADs) felt that scheduling an Interim meeting in the > milestones could prepare people for possible travel. If there is no > reason to meet, then the meeting would be cancelled. > > > I think we need milestones that represent the work that has been > > done, and the progress that can be made. > > Yes, but given history, I prefer to have dates that include a little > cushion, and the other folks interested in our work (e.g. SDOs) can > schedule their work based on our dates. If we are done early, then > they are happy. If we are late, then it throws off their schedules. > > PatC > ------_=_NextPart_001_01C0DC98.89556A70 Content-Type: text/html; charset="ISO-8859-1" RE: [seamoby] Seamoby Charter Last Call

Ok. So, in the interest of moving on, I propose that
we set June 8 as the deadline for the working group
requirements draft. That allows 4 weeks for the ct
team to finish the draft and the wg to review. As I
indicated, the dt should be ready to release the reqs
draft this week.

The problem statement has been release. Given the lack
of discussion on the email list, it would seem to me
plausible to set a near term wg release date. I suggest
May 25.

This is all going to slow. I think many people are losing
interest because they want to work on solutions and the
"fuzzy front end" of problem statements and requirements
is taking too long.  Yes, I know these documents are important,
but I also know that we can spend until September 2010 analyzing
requirements, and still not get it right. Only by working on
the solutions will we uncover the really unexpected "gotchas".

As for "lining up with the SDOs"? When did this become a schedule
driving priority? I think liasing with SDOs is important, but
I don't see the need to link up the efforts explicitly. More importantly,
I don't see how it can be done. You might link up with one SDO, but
there are at least four that I can think of that are of equal importance,
and we cannot favour any one over the others.

Gary

> -----Original Message-----
> From: Pat Calhoun [mailto:pcalhoun@diameter.org]
> Sent: Monday, May 14, 2001 12:40 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'Pat Calhoun'; seamoby@cdma-2000.org
> Subject: Re: [seamoby] Seamoby Charter Last Call
>
>
> On Mon, May 14, 2001 at 12:34:30PM -0400, Gary Kenward wrote:
>
> >
> > It did not come across as serious, but, to be frank, rather
> > flippant.
> well, that was not the intended message I was targetting. It was
> to the point (in my mind). In any case...
>
> > Perhaps you might ask when the requirements draft
> > will be completed, and what people believe are good dates for
> > the follow on work.
>
> Right, well my proposed charter was exactly that.
>
> I would have sent multiple e-mails to everyone, but it seemed
> more logical
> for me to write the charter, propose it, and then have the
> group discuss
> it.
>
> >
> > As far as I can tell, the design team is near to completion
> > on the requirements draft. It is my intention to have a "last
> > call" in the dt this week. I have reason to believe that we
> > will achieve reasonable consensus. Of course, there is always
> > a possibility this won't happen), however, it does seem reasonable
> > that we do not need 4 more months and an interim meeting to complete
> > the draft.
>
> ok, but *do* keep in mind that the document has to go through
> WG review
> once it is done within the DT. Then the document has to go through
> IETF and IESG review. Perhaps these will not necessary raise points
> that would need to be discussed within an interim meeting, but we
> (myself and the ADs) felt that scheduling an Interim meeting in the
> milestones could prepare people for possible travel. If there is no
> reason to meet, then the meeting would be cancelled.
>
> > I think we need milestones that represent the work that has been
> > done, and the progress that can be made.
>
> Yes, but given history, I prefer to have dates that include a little
> cushion, and the other folks interested in our work (e.g. SDOs) can
> schedule their work based on our dates. If we are done early, then
> they are happy. If we are late, then it throws off their schedules.
>
> PatC
>

------_=_NextPart_001_01C0DC98.89556A70-- From owner-seamoby@diameter.org Mon May 14 13:20:46 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18688 for ; Mon, 14 May 2001 13:20:46 -0400 (EDT) Received: (qmail 1665 invoked by alias); 14 May 2001 16:47:34 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 1659 invoked by uid 200); 14 May 2001 16:47:34 -0000 Received: (qmail 1651 invoked from network); 14 May 2001 16:47:31 -0000 Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.nortelnetworks.com) (47.129.242.157) by c900656-a.plstn1.sfba.home.com with SMTP; 14 May 2001 16:47:31 -0000 Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id MAA14610; Mon, 14 May 2001 12:57:42 -0400 Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Mon, 14 May 2001 12:57:30 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 May 2001 12:57:34 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C12590A@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , pcalhoun@diameter.org Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] Seamoby Charter Last Call Date: Mon, 14 May 2001 12:57:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DC96.F3F74E90" 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_01C0DC96.F3F74E90 Content-Type: text/plain; charset="ISO-8859-1" James: A good suggestion. The original ct problem statement had a reference architecture and terminology definitions. They were removed for two reasons: there was too much detail in the problem statement, and there was still much contention over the term "access point", even though it was clearly defined. The latter is the important issue here. I like the term "access point", and if the wg wants to give it a specific meaning, great. Thanks, Gary > -----Original Message----- > From: James Kempf [mailto:James.Kempf@Sun.COM] > Sent: Monday, May 14, 2001 12:46 PM > To: pcalhoun@diameter.org; Kenward, Gary [WDLN2:AN10:EXCH] > Cc: seamoby@cdma-2000.org > Subject: RE: [seamoby] Seamoby Charter Last Call > > > Gary/Pat, > > > >> > > > >> > > To me, point of access doesn't necessarily imply an > >> actual device, but > >> > > more of a connection point (e.g. ethernet port). Would > >> access device > >> > > work better? It is commonly used in many other WGs. > >> > > >> > As I tried to point out, you could call it "fred" as far as > >> I am concerned, > >> > but the term does matter to some people. > >> > >> but using fred would require that people read drafts to > >> recognize "fred". > >> Please keep in mind that people that do not follow our > >> working group, let > >> alone read the specs, will read the charter. These people > have to know > >> what's we are up to. So my use of the word "access point" was > >> intended to > >> make the charter understandable to such people. > >> > >> Keep in mind that the words used in the charter do not > >> necessarily reflect > >> what other words the group has decided is more appropriate in > >> the specs. > > > >No, but it would be nice if the words in the charter reflected the > >consensus of the wg. And "access point" has been a contentious > >term (BUT NOT for me). If it's contentious within the group, > >it will be contentious outside the group? > > > > > Maybe we need a terminology draft, or at least, define this term > somewhere so that it can be referred to. I'm suprised nobody > has done a generalized terminology draft for wireless terms > before in the MIP > group. > > jak > > ------_=_NextPart_001_01C0DC96.F3F74E90 Content-Type: text/html; charset="ISO-8859-1" RE: [seamoby] Seamoby Charter Last Call

James:

  A good suggestion. The original ct problem statement had
a reference architecture and terminology definitions. They
were removed for two reasons: there was too much detail in
the problem statement, and there was still much contention
over the term "access point", even though it was clearly
defined. The latter is the important issue here.

  I like the term "access point", and if the wg wants to give
it a specific meaning, great.

Thanks,
Gary

> -----Original Message-----
> From: James Kempf [mailto:James.Kempf@Sun.COM]
> Sent: Monday, May 14, 2001 12:46 PM
> To: pcalhoun@diameter.org; Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby@cdma-2000.org
> Subject: RE: [seamoby] Seamoby Charter Last Call
>
>
> Gary/Pat,
>
>
> >> > >
> >> > > To me, point of access doesn't necessarily imply an
> >> actual device, but
> >> > > more of a connection point (e.g. ethernet port). Would
> >> access device
> >> > > work better? It is commonly used in many other WGs.
> >> >
> >> > As I tried to point out, you could call it "fred" as far as
> >> I am concerned,
> >> > but the term does matter to some people.
> >>
> >> but using fred would require that people read drafts to
> >> recognize "fred".
> >> Please keep in mind that people that do not follow our
> >> working group, let
> >> alone read the specs, will read the charter. These people
> have to know
> >> what's we are up to. So my use of the word "access point" was
> >> intended to
> >> make the charter understandable to such people.
> >>
> >> Keep in mind that the words used in the charter do not
> >> necessarily reflect
> >> what other words the group has decided is more appropriate in
> >> the specs.
> >
> >No, but it would be nice if the words in the charter reflected the
> >consensus of the wg. And "access point" has been a contentious
> >term (BUT NOT for me). If it's contentious within the group,
> >it will be contentious outside the group?
> >
>
>
> Maybe we need a terminology draft, or at least, define this term
> somewhere so that it can be referred to. I'm suprised nobody
> has done a generalized terminology draft for wireless terms
> before in the MIP
> group.
>
>               jak
>
>

------_=_NextPart_001_01C0DC96.F3F74E90-- From owner-seamoby@diameter.org Mon May 14 13:25:06 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18905 for ; Mon, 14 May 2001 13:25:04 -0400 (EDT) Received: (qmail 2885 invoked by alias); 14 May 2001 17:12:18 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2879 invoked by uid 200); 14 May 2001 17:12:17 -0000 Received: (qmail 2871 invoked from network); 14 May 2001 17:12:15 -0000 Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.nortelnetworks.com) (47.129.242.157) by c900656-a.plstn1.sfba.home.com with SMTP; 14 May 2001 17:12:15 -0000 Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id NAA17445; Mon, 14 May 2001 13:22:26 -0400 Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Mon, 14 May 2001 13:22:07 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 May 2001 13:22:11 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C1CD078@zcard031.ca.nortel.com> From: "Hamid Syed" To: "'Pat Calhoun'" Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] Seamoby Charter Last Call Date: Mon, 14 May 2001 13:22:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DC9A.66F3EC70" 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_01C0DC9A.66F3EC70 Content-Type: text/plain > -----Original Message----- > From: Pat Calhoun [SMTP:pcalhoun@diameter.org] > Sent: Monday, May 14, 2001 12:31 PM > To: Syed, Hamid [WDLN2:AN22:EXCH] > Cc: 'Pat Calhoun'; seamoby@cdma-2000.org > Subject: Re: [seamoby] Seamoby Charter Last Call > > On Mon, May 14, 2001 at 11:05:02AM -0400, Hamid Syed wrote: > > > Jun 01 Submit I-D on Dormant Mode Host Alerting Requirements > > [Syed, Hamid [WDLN2:AN22:EXCH]] I am assuming that the inter acces > > point requirement I-D would be submitted in the same time frame. > Probably, a > > milestone here should reflect it. > > What is the inter access point requirement I-D? [Syed, Hamid [WDLN2:AN22:EXCH]] requirements I-D for context transfer. Sorry, I tried to use the term "inter access point"as it is used in the charter. > > > Sep 01 Interim Meeting to review Inter Access Point Context Transfer > and > > > Handoff Candidate Discovery Requirements > > [Syed, Hamid [WDLN2:AN22:EXCH]] This is kind of late for inter > > access point ct. are we going to discuss the requirements for the next > few > > months?? > > If you believe that the charter needs to be revised, now is the time. I > felt > more comfortable having dates where we would end up early as opposed to > late. [Syed, Hamid [WDLN2:AN22:EXCH]] I agree...I was just trying to understand if there is any oustanding issue for the ct requirements I-D that can keep us busy in the same document for next 4 months. If not, then why not go for something in next couple of months as the WG milestone. We can then move forward towards solutions. -Hamid > PatC ------_=_NextPart_001_01C0DC9A.66F3EC70 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [seamoby] Seamoby Charter Last Call

    -----Original Message-----
    From:   Pat Calhoun [SMTP:pcalhoun@diameter.org]
    Sent:   Monday, May 14, 2001 12:31 PM
    To:     Syed, Hamid [WDLN2:AN22:EXCH]
    Cc:     'Pat Calhoun'; seamoby@cdma-2000.org
    Subject:       = Re: [seamoby] Seamoby Charter Last = Call

    On Mon, May 14, 2001 at 11:05:02AM = -0400, Hamid Syed wrote:
    > > Jun 01  Submit I-D on = Dormant Mode Host Alerting Requirements
    >       = [Syed, Hamid [WDLN2:AN22:EXCH]]  I am assuming that the inter = acces
    > point requirement I-D would be = submitted in the same time frame. Probably, a
    > milestone here should reflect = it.

    What is the inter access point = requirement I-D?
    [Syed, Hamid = [WDLN2:AN22:EXCH]]  requirements I-D for context transfer. Sorry, = I tried to use the term "inter access point"as it is used in = the charter.

    > > Sep 01  Interim Meeting = to review Inter Access Point Context Transfer and
    > >     Handoff = Candidate Discovery Requirements
    >       = [Syed, Hamid [WDLN2:AN22:EXCH]]  This is kind of late for = inter
    > access point ct. are we going to = discuss the requirements for the next few
    > months??

    If you believe that the charter needs = to be revised, now is the time. I felt
    more comfortable having dates where = we would end up early as opposed to late.
    [Syed, Hamid = [WDLN2:AN22:EXCH]]  I agree...I was just trying to understand if = there is any oustanding issue for the ct requirements I-D that can keep = us busy in the same document for next 4 months. If not, then why not go = for something in next couple of months as the WG milestone. We can then = move forward towards solutions.

    -Hamid
    PatC

------_=_NextPart_001_01C0DC9A.66F3EC70-- From owner-seamoby@diameter.org Mon May 14 13:28:40 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19053 for ; Mon, 14 May 2001 13:28:39 -0400 (EDT) Received: (qmail 3131 invoked by alias); 14 May 2001 17:14:10 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 3123 invoked by uid 200); 14 May 2001 17:14:10 -0000 Received: (qmail 3114 invoked by uid 500); 14 May 2001 17:14:08 -0000 Date: Mon, 14 May 2001 10:14:08 -0700 From: Pat Calhoun To: Gary Kenward Cc: "'Pat Calhoun'" , seamoby@cdma-2000.org Subject: Re: [seamoby] Seamoby Charter Last Call Message-ID: <20010514101407.E10188@charizard.diameter.org> Mail-Followup-To: Gary Kenward , 'Pat Calhoun' , seamoby@cdma-2000.org References: <9FBD322B7824D511B36900508BF93C9C12590C@zcard031.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <9FBD322B7824D511B36900508BF93C9C12590C@zcard031.ca.nortel.com>; from gkenward@nortelnetworks.com on Mon, May 14, 2001 at 01:08:46PM -0400 Sender: owner-seamoby@diameter.org Precedence: bulk On Mon, May 14, 2001 at 01:08:46PM -0400, Gary Kenward wrote: > Ok. So, in the interest of moving on, I propose that > we set June 8 as the deadline for the working group > requirements draft. That allows 4 weeks for the ct > team to finish the draft and the wg to review. As I > indicated, the dt should be ready to release the reqs > draft this week. ok, but let me turn this around. Let's assume that someone in the Working Group needs changes, and getting the spec off to the IESG takes an additional month (a week to discuss, a week to update specs and post, and another 2 week last call), then we end up being late again. What, exactly, is the problem with adding a cushion to the milestones that will allow us the time to work on the spec, if we need it. Even if the milestones states that the spec isn't to be ready by November, and it is ready next month, then we are early, scratch off the item from the list, and move on. Can we, somehow, negotiate a date somewhere between your (much too agressive) June 8th, and my (perhaps too far out to accomodate a possible interim meeting) date? How about July? Again, if we are done early, we just look better. > > The problem statement has been release. Given the lack > of discussion on the email list, it would seem to me > plausible to set a near term wg release date. I suggest > May 25. good. so I will do a WG last call on the spec, and if we receive no comments in during that last call (or no comments that would require another last call), we can simply move the spec ahead. I will make the date Jun, to add necessary padding. > > This is all going to slow. I think many people are losing > interest because they want to work on solutions and the > "fuzzy front end" of problem statements and requirements > is taking too long. Yes, I know these documents are important, > but I also know that we can spend until September 2010 analyzing > requirements, and still not get it right. Only by working on > the solutions will we uncover the really unexpected "gotchas". Well, it sounds like we are almost done with requirements, and ready to move on. btw, designing a protocol when you have a concrete set of requirements is MUCH faster than without. So the time savings can in many cases be justified. Further, if someone accuses creeping featurism, you can point to a requirements I-D that went through last call. > As for "lining up with the SDOs"? When did this become a schedule > driving priority? I think liasing with SDOs is important, but > I don't see the need to link up the efforts explicitly. More importantly, > I don't see how it can be done. You might link up with one SDO, but > there are at least four that I can think of that are of equal importance, > and we cannot favour any one over the others. ok, perhaps the wording needs to be changed, but the ADs liked it. We aren't expecting to send liasons, as you know the IETF doesn't do that. This paragraph is an invitation to other SDOs (which, btw, are made aware of our new charters), to send people to work with us, if they are interested. I, personally, don't see the harm in asking for people to participate in our work. Is there another way to put it that you would feel more comfortable with? PatC From owner-seamoby@diameter.org Mon May 14 13:46:16 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19612 for ; Mon, 14 May 2001 13:46:16 -0400 (EDT) Received: (qmail 7328 invoked by alias); 14 May 2001 17:34:40 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 7322 invoked by uid 200); 14 May 2001 17:34:40 -0000 Received: (qmail 7276 invoked from network); 14 May 2001 17:34:37 -0000 Received: from mercury.sun.com (192.9.25.1) by c900656-a.plstn1.sfba.home.com with SMTP; 14 May 2001 17:34:37 -0000 Received: from heliopolis.eng.sun.com ([152.70.1.39]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA17319 for ; Mon, 14 May 2001 10:45:10 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id KAA06666 for ; Mon, 14 May 2001 10:45:09 -0700 (PDT) Message-Id: <200105141745.KAA06666@heliopolis.eng.sun.com> Date: Mon, 14 May 2001 10:45:09 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: Wireless Terminology Draft (was: Re: [seamoby] Seamoby Charter Last Call) To: seamoby@diameter.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Lbpg7hqRAxqhzaq+GbScPQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-seamoby@diameter.org Precedence: bulk ------------- Begin Forwarded Message ------------- X-Delivered-For: X-mProtect: Mon, 14 May 2001 10:33:07 -0700 Nokia Silicon Valley Messaging Protection Date: Mon, 14 May 2001 10:32:43 -0700 From: "Charles E. Perkins" To: James Kempf Subject: Re: [seamoby] Seamoby Charter Last Call Hello Jim, > Maybe we need a terminology draft, or at least, define this term > somewhere so that it can be referred to. I'm suprised nobody > has done a generalized terminology draft for wireless terms before in the MIP > group. RFC 2002 does start off with a long list of terminology. It is questionable whether any specific wireless terms are needed for a protocol running over IP. What is needed is a list of useful terms. For instance, one might care about error rate or bandwidth even if the medium were not wireless. I don't think that chip rate, for instance, should be part of the [seamoby] terminology list. Do you think that there are terms which SHOULD have been defined for RFC 2002? If so, now would be a good time to mention them before RFC 2002bis goes to the RFC editor's desk. Regards, Charlie P. ------------- End Forwarded Message ------------- From owner-seamoby@diameter.org Mon May 14 13:48:23 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19678 for ; Mon, 14 May 2001 13:48:21 -0400 (EDT) Received: (qmail 8136 invoked by alias); 14 May 2001 17:36:14 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8129 invoked by uid 200); 14 May 2001 17:36:14 -0000 Received: (qmail 8088 invoked from network); 14 May 2001 17:36:08 -0000 Received: from mercury.sun.com (192.9.25.1) by c900656-a.plstn1.sfba.home.com with SMTP; 14 May 2001 17:36:08 -0000 Received: from heliopolis.eng.sun.com ([152.70.1.39]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA18324 for ; Mon, 14 May 2001 10:46:53 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id KAA06722 for ; Mon, 14 May 2001 10:46:38 -0700 (PDT) Message-Id: <200105141746.KAA06722@heliopolis.eng.sun.com> Date: Mon, 14 May 2001 10:46:38 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: Wireless Terminology Draft( was: Re: [seamoby] Seamoby Charter Last Call) To: seamoby@diameter.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 03VI8C+eds8PDoRseUcslA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-seamoby@diameter.org Precedence: bulk ------------- Begin Forwarded Message ------------- Date: Mon, 14 May 2001 10:43:47 -0700 (PDT) From: James Kempf Subject: Re: [seamoby] Seamoby Charter Last Call To: James.Kempf@sun.com, charliep@iprg.nokia.com Content-MD5: 6F7Vl9kYVVbqr66TeEQyRw== Hi Charlie, >> Maybe we need a terminology draft, or at least, define this term >> somewhere so that it can be referred to. I'm suprised nobody >> has done a generalized terminology draft for wireless terms before in the MIP >> group. > >RFC 2002 does start off with a long list of terminology. > >It is questionable whether any specific wireless terms are >needed for a protocol running over IP. What is needed is >a list of useful terms. For instance, one might care about >error rate or bandwidth even if the medium were not wireless. >I don't think that chip rate, for instance, should be part >of the [seamoby] terminology list. > Actually, there are plenty of wireless terms that need definition. Access point, handoff (or handover IETF should select which one it wants to use), context transfer, paging, etc. etc. >Do you think that there are terms which SHOULD have been defined >for RFC 2002? If so, now would be a good time to mention them >before RFC 2002bis goes to the RFC editor's desk. > No, I think they have wider applicability. More and more wireless stuff is going on. There are now two working groups associated with wireless, and others that have a big wireless component. I think having a terminology draft that collects all terminology that could be referred to by drafts would be a benefit. jak ------------- End Forwarded Message ------------- From owner-seamoby@diameter.org Mon May 14 13:52:09 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19747 for ; Mon, 14 May 2001 13:52:08 -0400 (EDT) Received: (qmail 9444 invoked by alias); 14 May 2001 17:40:39 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 9438 invoked by uid 200); 14 May 2001 17:40:39 -0000 Received: (qmail 9429 invoked from network); 14 May 2001 17:40:34 -0000 Received: from wall.comdev.cc (HELO cleanup.comdev.cc) (63.150.62.162) by c900656-a.plstn1.sfba.home.com with SMTP; 14 May 2001 17:40:34 -0000 Received: (qmail 2210 invoked from network); 14 May 2001 17:51:13 -0000 Received: from jersey.comdev.cc (HELO comdev.cc) (192.168.67.202) by cleanup.comdev.cc with SMTP; 14 May 2001 17:51:13 -0000 Message-ID: <3B001B0F.8090503@comdev.cc> Date: Mon, 14 May 2001 10:51:11 -0700 From: Mark Smith Organization: COM DEV Wireless User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.19 i686; en-US; 0.8.1) Gecko/20010326 X-Accept-Language: en MIME-Version: 1.0 To: seamoby@cdma-2000.org Subject: Re: [seamoby] Seamoby Charter Last Call References: <9FBD322B7824D511B36900508BF93C9C12590C@zcard031.ca.nortel.com> <20010514101407.E10188@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Pat Calhoun wrote: > Can we, somehow, negotiate a date somewhere between your (much too agressive) > June 8th, and my (perhaps too far out to accomodate a possible interim > meeting) date? How about July? > > Again, if we are done early, we just look better. Having spent a year as a Sales Engineer, I'm a firm believer in "Under promis, over deliver." However, having no experience in the whole process involved here, I have no (informed) opinion on what a reasonable time would be. > Well, it sounds like we are almost done with requirements, and ready > to move on. btw, designing a protocol when you have a concrete set of > requirements is MUCH faster than without. So the time savings can in many > cases be justified. Further, if someone accuses creeping featurism, you > can point to a requirements I-D that went through last call. My wife, a professional software developer, has a saying that I think applies here: "Write software to spec is a lot like walking on water.. It's much easier when frozen.." -Mark From owner-seamoby@diameter.org Mon May 14 13:58:22 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19959 for ; Mon, 14 May 2001 13:58:12 -0400 (EDT) Received: (qmail 9543 invoked by alias); 14 May 2001 17:40:55 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 9534 invoked by uid 200); 14 May 2001 17:40:54 -0000 Received: (qmail 9498 invoked from network); 14 May 2001 17:40:48 -0000 Received: from unknown (HELO zrc2s03g.us.nortel.com) (47.103.122.66) by c900656-a.plstn1.sfba.home.com with SMTP; 14 May 2001 17:40:48 -0000 Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id MAA24192 for ; Mon, 14 May 2001 12:51:46 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Mon, 14 May 2001 12:45:12 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 May 2001 12:50:41 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E430230855E@crchy271.us.nortel.com> From: "Glenn Morrow" To: Arthur Ross , "Gary Kenward" , "'Pat Calhoun'" , seamoby@cdma-2000.org Cc: wirelessinternet@internet.motlabs.com Subject: RE: [seamoby] Seamoby Charter Last Call Date: Mon, 14 May 2001 12:50:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DC9E.5F4B5590" 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_01C0DC9E.5F4B5590 Content-Type: text/plain; charset="iso-8859-1" Arthur, You aren't crazy at all. A paper title'd "Just what the _ _ _ _ is this mobility thing" would be an excellent IETF informational draft. The exploration of the topics you mention below would be excellent content. Such a paper would likely be a good crash course for some of the other folks who haven't been exposed to the topics and why things should be defined as such. Judging from the points you bring up, you do seem to have a PHD grasp on the topic and it sounds to me like you should follow through and do it. You can sign me up for reviewing it and providing even pre-draft feedback. My first feedback is that as you go through each peice of functionality, it would be good to identify the particular layer that you feel each function is appropriate for i.e. "who or what is moving" and the ramifications in terms of functionality with the layers for each proposed solution at each layer. You might even break the mold and discuss the ramifications in terms of business as well. Don't forget QoS interactions and your earlier "layer 1,2 - get physical" points. I think your paper would be an excellent WG input for NSIS too. The biggest problem I see is that the layer 5'ers want to do node mobilty and the layer 3'ers want to do user mobility and the layer 1,2'ers - well - no comment other than "vertical psychosis has been the norm for years in some of the traditional SDOs". Thanks - this was quite a refreshing old fart. Glenn -----Original Message----- From: Arthur Ross [mailto:a.ross@ieee.org] Sent: Monday, May 14, 2001 11:27 AM To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Pat Calhoun'; seamoby@cdma-2000.org Cc: wirelessinternet@internet.motlabs.com Subject: RE: [seamoby] Seamoby Charter Last Call At 7:09 -0700 05/14/2001, Gary Kenward wrote: > The SeaMoby Working group will analyze the requirements and > tradeoffs for the > goal of transferring context information from a mobile's old > access to the new > access point (versus accessing needed context over a distance). I understand what was intended here, but the role of the "access point" has been a topic of great debate. To some, an "access point" is a box in a specific network solution. There is no simple alternative (that I have been able to come up with), but in the requirements documents we have used "point of access" instead of "access point". Indeed - While I don't think that the SeaMoby charter is the right place to raise it, this seems to me to be a microcosm of a MAJOR ISSUE confronting the world if IP - one that should be addressed at the highest level, namely: the UNDERLYING ARCHITECTURAL ABSTRACTIONS. We talk at great length about hosts, mobile nodes, etc., but the notion of "host" or "node" is getting fuzzy. Originally [ARPANET] "hosts" were big computers that filled rooms, had squads of people caring for & feeding them, and the protocols were designed with that implicit mindset. But nowadays, when the embodiments of the "hosts" may cost just pennies, may be flyspeck-sized, and may be found in all sorts of non-traditional, often low-tech kinds of places/things, the concepts need revision. My strong feeling is that the questions to be addressed should be things like: * What are the entities that are the endpoints of the communication? When the address space is large enough [IPv6] to give every cell of every human being and every grain of sand on earth its own IP address, perhaps the model and uses of it need to be re-thought. * What is MEANT by "mobility"? Or alternatively what is it that is moving? I can envision many possible answers/opinions. * How are those endpoints identified for various purposes? A major example: paging - IP address, as in MIP, is [perhaps] meaningful for routing purposes, but meaningless in the application context. One could envision a concept whereby there are various "views" of the endpoint space applicable for different sorts of applications (e.g. routing, logical, name-based, geographic, organizational hierarchy, demographic group, etc.). In this light, paging/addressing might be viewed/implemented as a kind of distributed database query. * What is the nature of the "identity" associated with, say, individual humans, that provides the basis/data for authentication? I'm thinking of something like a great-grandson of the SIM card concept, for example [... or maybe you will begin every session with a request to "spit in the little spitoon" on your laptop for the DNA analysis that authenticates the session. ;-) ]. * Is a broader concept of the "addressable individual" needed? [I have in mind functional pseudo-persons, associated with business & organization roles, databases of various kinds, etc.] * Is a "discovery" functionality needed? I.e. a generic method for exposing the internal structure of subnets and/or databases? I.e. a way of creating the local streetmap of an unfamiliar neighborhood? This might be especially important if the "mobile" entities have internal, time-varying structure [think, for a simple example, of folks in vehicles on the highway, each potentially with his PDA, phone, medical monitoring device, plus the "smart car" itself, etc., all of which are communicating through a wireless gateway of some kind; just such things are currently under development]. * What are the business and regulatory models? Giant electro-political hot potato, but very important, IMHO. The regulatory folks need to clean up their act if the mythical "wireless Internet" is to be anything other than hype and snake oil. I have in mind here a complete re-think of the spectrum license auction notion. I personally believe that auctioning the ether was, and still is, a bad idea, not in the long term public interest. The pro-auction argument is that real estate-like ownership is a prerequisite if investors are going to pony up the huge capital expenditures needed to build the "next generation" networks. The fallacy here, IMHO, is the PSTN-centric mindset. If what you are talking about is universal, readily-available wirless IP service, starting from a telephone network is very obviously a bad way of doing it. IMHO wireless IP access should be viewed, for regulatory purposes, as more like a public utility than the proverbial "walled garden" for which the owner charges at the tollbooth. You could make a lot of money by letting someone charge for the air we breathe too, but in neither case is it good public policy. There are many aspects to this, and many ways of pulling it off, as I have tried to convince the FCC for some time now. * What replaces the "walled garden" wireless air interfaces? Good question. I have some opinions as to what it MIGHT be, but other opinions may [read: "undoubtedly will"] differ. This will be, I hope, the subject of this new "wireless internet" discussion group. Just one crazy old fart's opinion ... [My apologies if you get this more than once due to list redundancies.] -- Best regards, -- ahmr ------_=_NextPart_001_01C0DC9E.5F4B5590 Content-Type: text/html; charset="iso-8859-1"
Arthur,
 
You aren't crazy at all. A paper title'd "Just what the _ _ _ _  is this mobility thing" would be an excellent IETF informational draft. The exploration of the topics you mention below would be excellent content. Such a paper would likely be a good crash course for some of the other folks who haven't been exposed to the topics and why things should be defined as such.
 
Judging from the points you bring up, you do seem to have a PHD grasp on the topic and it sounds to me like you should follow through and do it. You can sign me up for reviewing it and providing even pre-draft feedback.
 
My first feedback is that as you go through each peice of functionality, it would be good to identify the particular layer that you feel each function is appropriate for i.e. "who or what is moving" and the ramifications in terms of functionality with the layers for each proposed solution at each layer. You might even break the mold and discuss the ramifications in terms of business as well.
 
Don't forget QoS interactions and your earlier "layer 1,2 - get physical" points. I think your paper would be an excellent WG input for NSIS too.
 
The biggest problem I see is that the layer 5'ers want to do node mobilty and the layer 3'ers want to do user mobility and the layer 1,2'ers - well - no comment other than "vertical psychosis has been the norm for years in some of the traditional SDOs".
 
Thanks - this was quite a refreshing old fart.
 
Glenn
-----Original Message-----
From: Arthur Ross [mailto:a.ross@ieee.org]
Sent: Monday, May 14, 2001 11:27 AM
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Pat Calhoun'; seamoby@cdma-2000.org
Cc: wirelessinternet@internet.motlabs.com
Subject: RE: [seamoby] Seamoby Charter Last Call

At 7:09 -0700 05/14/2001, Gary Kenward wrote:

> The SeaMoby Working group will analyze the requirements and

> tradeoffs for the

> goal of transferring context information from a mobile's old

> access to the new

> access point (versus accessing needed context over a distance).


I understand what was intended here, but the role of the "access

point" has been a topic of great debate. To some, an "access point"

is a box in a specific network solution. There is no simple alternative

(that I have been able to come up with), but in the requirements documents

we have used "point of access" instead of "access point".


Indeed - While I don't think that the SeaMoby charter is the right place to

raise it, this seems to me to be a microcosm of a MAJOR ISSUE confronting

the world if IP - one that should be addressed at the highest level, namely:

the UNDERLYING ARCHITECTURAL ABSTRACTIONS.


<RANT>


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

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

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

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

the concepts need revision.


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


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

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

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

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


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

I can envision many possible answers/opinions.


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

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

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

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

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

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

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

as a kind of distributed database query.


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

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

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

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

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

the session. ;-) ].


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

mind functional pseudo-persons, associated with business & organization

roles, databases of various kinds, etc.]


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

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

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

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

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

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

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

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

development].


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

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

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

than hype and snake oil.


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

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

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

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

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

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

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

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

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

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

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

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

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


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

have tried to convince the FCC for some time now.


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

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

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

this new "wireless internet" discussion group.


Just one crazy old fart's opinion ...


</RANT>


[My apologies if you get this more than once due to list redundancies.]


-- Best regards,

-- ahmr

------_=_NextPart_001_01C0DC9E.5F4B5590-- From owner-seamoby@diameter.org Mon May 14 14:26:14 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20667 for ; Mon, 14 May 2001 14:26:13 -0400 (EDT) Received: (qmail 10198 invoked by alias); 14 May 2001 17:45:35 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 10192 invoked by uid 200); 14 May 2001 17:45:34 -0000 Received: (qmail 10180 invoked from network); 14 May 2001 17:45:29 -0000 Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.nortelnetworks.com) (47.129.242.157) by c900656-a.plstn1.sfba.home.com with SMTP; 14 May 2001 17:45:29 -0000 Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id NAA20930; Mon, 14 May 2001 13:54:31 -0400 Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Mon, 14 May 2001 13:54:30 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 May 2001 13:54:32 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C1CD079@zcard031.ca.nortel.com> From: "Hamid Syed" To: "'James Kempf'" , seamoby@diameter.org Subject: RE: Wireless Terminology Draft( was: Re: [seamoby] Seamoby Charte r Last Call) Date: Mon, 14 May 2001 13:54:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DC9E.E85964D0" 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_01C0DC9E.E85964D0 Content-Type: text/plain Hello james, A draft was submitted to seamoby early this year that attempted to capture the wireless terminology. her eis the link: http://search.ietf.org/internet-drafts/draft-manner-seamoby-terms-01.txt br -Hamid > -----Original Message----- > From: James Kempf [SMTP:James.Kempf@Sun.COM] > Sent: Monday, May 14, 2001 1:47 PM > To: seamoby@diameter.org > Subject: Wireless Terminology Draft( was: Re: [seamoby] Seamoby > Charter Last Call) > > > ------------- Begin Forwarded Message ------------- > > Date: Mon, 14 May 2001 10:43:47 -0700 (PDT) > From: James Kempf > Subject: Re: [seamoby] Seamoby Charter Last Call > To: James.Kempf@sun.com, charliep@iprg.nokia.com > Content-MD5: 6F7Vl9kYVVbqr66TeEQyRw== > > Hi Charlie, > > > >> Maybe we need a terminology draft, or at least, define this term > >> somewhere so that it can be referred to. I'm suprised nobody > >> has done a generalized terminology draft for wireless terms before in > the MIP > >> group. > > > >RFC 2002 does start off with a long list of terminology. > > > >It is questionable whether any specific wireless terms are > >needed for a protocol running over IP. What is needed is > >a list of useful terms. For instance, one might care about > >error rate or bandwidth even if the medium were not wireless. > >I don't think that chip rate, for instance, should be part > >of the [seamoby] terminology list. > > > > Actually, there are plenty of wireless terms that need definition. > Access point, handoff (or handover IETF should select which one > it wants to use), context transfer, paging, etc. etc. > > >Do you think that there are terms which SHOULD have been defined > >for RFC 2002? If so, now would be a good time to mention them > >before RFC 2002bis goes to the RFC editor's desk. > > > > No, I think they have wider applicability. More and more wireless > stuff is going on. There are now two working groups associated > with wireless, and others that have a big wireless component. I think > having a > terminology draft that collects all terminology that could be referred to > by > drafts would be a benefit. > > jak > > > > ------------- End Forwarded Message ------------- > > ------_=_NextPart_001_01C0DC9E.E85964D0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Wireless Terminology Draft( was: Re: [seamoby] Seamoby = Charter Last Call)

Hello james,

A draft was = submitted to seamoby early this year that attempted to capture the = wireless terminology. her eis the link:
http://search.ietf.org/internet-drafts/draft-manner-se= amoby-terms-01.txt

br

-Hamid

    -----Original Message-----
    From:   James Kempf [SMTP:James.Kempf@Sun.COM]
    Sent:   Monday, May 14, 2001 1:47 PM
    To:     seamoby@diameter.org
    Subject:       = Wireless Terminology Draft( was: Re: = [seamoby] Seamoby Charter Last  Call)


    ------------- Begin Forwarded Message = -------------

    Date: Mon, 14 May 2001 10:43:47 -0700 = (PDT)
    From: James Kempf = <James.Kempf@sun.com>
    Subject: Re: [seamoby] Seamoby = Charter Last Call
    To: James.Kempf@sun.com, = charliep@iprg.nokia.com
    Content-MD5: = 6F7Vl9kYVVbqr66TeEQyRw=3D=3D

    Hi Charlie,


    >> Maybe we need a terminology = draft, or at least, define this term
    >> somewhere so that it can be = referred to. I'm suprised nobody
    >> has done a generalized = terminology draft for wireless terms before in the MIP
    >> group.
    >
    >RFC 2002 does start off with a = long list of terminology.
    >
    >It is questionable whether any = specific wireless terms are
    >needed for a protocol running = over IP.  What is needed is
    >a list of useful terms.  For = instance, one might care about
    >error rate or bandwidth even if = the medium were not wireless.
    >I don't think that chip rate, for = instance, should be part
    >of the [seamoby] terminology = list.
    >

    Actually, there are plenty of wireless = terms that need definition.
    Access point, handoff (or handover = IETF should select which one
    it wants to use), context transfer, = paging, etc. etc.

    >Do you think that there are terms = which SHOULD have been defined
    >for RFC 2002?  If so, now = would be a good time to mention them
    >before RFC 2002bis goes to the = RFC editor's desk.
    >

    No, I think they have wider = applicability. More and more wireless
    stuff is going on. There are now two = working groups associated
    with wireless, and others that have a = big wireless component. I think having a
    terminology draft that collects all = terminology that could be referred to by
    drafts would be a benefit.

            =         jak



    ------------- End Forwarded Message = -------------


------_=_NextPart_001_01C0DC9E.E85964D0-- From owner-seamoby@diameter.org Mon May 14 15:38:03 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22620 for ; Mon, 14 May 2001 15:37:59 -0400 (EDT) Received: (qmail 13240 invoked by alias); 14 May 2001 19:23:11 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 13234 invoked by uid 200); 14 May 2001 19:23:11 -0000 Received: (qmail 13229 invoked from network); 14 May 2001 19:23:09 -0000 Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.nortelnetworks.com) (47.129.242.157) by c900656-a.plstn1.sfba.home.com with SMTP; 14 May 2001 19:23:09 -0000 Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id OAA25414; Mon, 14 May 2001 14:35:23 -0400 Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Mon, 14 May 2001 14:35:09 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 May 2001 14:35:11 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C12590E@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Pat Calhoun'" Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] Seamoby Charter Last Call Date: Mon, 14 May 2001 14:35:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DCA4.95A8D170" 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_01C0DCA4.95A8D170 Content-Type: text/plain; charset="ISO-8859-1" > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Monday, May 14, 2001 1:14 PM > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: 'Pat Calhoun'; seamoby@cdma-2000.org > Subject: Re: [seamoby] Seamoby Charter Last Call > > > On Mon, May 14, 2001 at 01:08:46PM -0400, Gary Kenward wrote: > > Ok. So, in the interest of moving on, I propose that > > we set June 8 as the deadline for the working group > > requirements draft. That allows 4 weeks for the ct > > team to finish the draft and the wg to review. As I > > indicated, the dt should be ready to release the reqs > > draft this week. > > ok, but let me turn this around. Let's assume that someone in > the Working > Group needs changes, and getting the spec off to the IESG > takes an additional > month (a week to discuss, a week to update specs and post, > and another 2 week > last call), then we end up being late again. > > What, exactly, is the problem with adding a cushion to the > milestones that > will allow us the time to work on the spec, if we need it. The problem was the size of the cushion. I clearly mis-understood the purpose of the milestones, which is to identify the point at which the drafts are approved by the IESG? (I don't know how or why one would want to predict such an event ;^}, but so be it). As long as we can proceed with the solutions work before the end of May. I think everything that needs to be said about requirements has been voiced one way or the other. Yes, there is probably more requirements to come out later on, but it's not worth waiting for that possibility to happen. > > Even if the milestones states that the spec isn't to be ready > by November, > and it is ready next month, then we are early, scratch off > the item from > the list, and move on. > > Can we, somehow, negotiate a date somewhere between your > (much too agressive) > June 8th, and my (perhaps too far out to accomodate a possible interim > meeting) date? How about July? > > Again, if we are done early, we just look better. Having had many project roles, I realize the value of setting milestones that you can meet. In my experience, if you pad the schedule enough, people lose faith and the work goes elsewhere. 'nuff said. > > > > > The problem statement has been release. Given the lack > > of discussion on the email list, it would seem to me > > plausible to set a near term wg release date. I suggest > > May 25. > > good. so I will do a WG last call on the spec, and if we receive > no comments in during that last call (or no comments that > would require > another last call), we can simply move the spec ahead. > > I will make the date Jun, to add necessary padding. > > > > > This is all going to slow. I think many people are losing > > interest because they want to work on solutions and the > > "fuzzy front end" of problem statements and requirements > > is taking too long. Yes, I know these documents are important, > > but I also know that we can spend until September 2010 analyzing > > requirements, and still not get it right. Only by working on > > the solutions will we uncover the really unexpected "gotchas". > > Well, it sounds like we are almost done with requirements, and ready > to move on. btw, designing a protocol when you have a concrete set of > requirements is MUCH faster than without. So the time savings > can in many > cases be justified. Further, if someone accuses creeping > featurism, you > can point to a requirements I-D that went through last call. Yes, yes, yes. But as someone instructed me early on in his career: analysis can lead to paralysis. As long as everyone is happy with the idea that we are working on ct solutions without achieving IESG approval on the problem statement, never mind the requirements, then I am happy. > > > As for "lining up with the SDOs"? When did this become a schedule > > driving priority? I think liasing with SDOs is important, but > > I don't see the need to link up the efforts explicitly. > More importantly, > > I don't see how it can be done. You might link up with one SDO, but > > there are at least four that I can think of that are of > equal importance, > > and we cannot favour any one over the others. > > ok, perhaps the wording needs to be changed, but the ADs liked it. We > aren't expecting to send liasons, as you know the IETF > doesn't do that. > This paragraph is an invitation to other SDOs (which, btw, > are made aware > of our new charters), to send people to work with us, if they > are interested. > > I, personally, don't see the harm in asking for people to participate > in our work. > > Is there another way to put it that you would feel more > comfortable with? I really don't want to get into wordsmithing the charter. I like the original one just fine ;^}. My only concern was that the involvement of the SDOs was driving the schedule. > > PatC > GWK ------_=_NextPart_001_01C0DCA4.95A8D170 Content-Type: text/html; charset="ISO-8859-1" RE: [seamoby] Seamoby Charter Last Call

> -----Original Message-----
> From: Pat Calhoun [mailto:pcalhoun@diameter.org]
> Sent: Monday, May 14, 2001 1:14 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'Pat Calhoun'; seamoby@cdma-2000.org
> Subject: Re: [seamoby] Seamoby Charter Last Call
>
>
> On Mon, May 14, 2001 at 01:08:46PM -0400, Gary Kenward wrote:
> > Ok. So, in the interest of moving on, I propose that
> > we set June 8 as the deadline for the working group
> > requirements draft. That allows 4 weeks for the ct
> > team to finish the draft and the wg to review. As I
> > indicated, the dt should be ready to release the reqs
> > draft this week.
>
> ok, but let me turn this around. Let's assume that someone in
> the Working
> Group needs changes, and getting the spec off to the IESG
> takes an additional
> month (a week to discuss, a week to update specs and post,
> and another 2 week
> last call), then we end up being late again.
>
> What, exactly, is the problem with adding a cushion to the
> milestones that
> will allow us the time to work on the spec, if we need it.

The problem was the size of the cushion. I clearly mis-understood
the purpose of the milestones, which is to identify the point
at which the drafts are approved by the IESG? (I don't know how or
why one would want to predict such an event ;^}, but so be it).

As long as we can proceed with the solutions work before the end
of May. I think everything that needs to be said about requirements
has been voiced one way or the other. Yes, there is probably more
requirements to come out later on, but it's not worth waiting for
that possibility to happen.

>
> Even if the milestones states that the spec isn't to be ready
> by November,
> and it is ready next month, then we are early, scratch off
> the item from
> the list, and move on.
>
> Can we, somehow, negotiate a date somewhere between your
> (much too agressive)
> June 8th, and my (perhaps too far out to accomodate a possible interim
> meeting) date? How about July?
>
> Again, if we are done early, we just look better.

Having had many project roles, I realize the value of setting milestones
that you can meet. In my experience, if you pad the schedule enough,
people lose faith and the work goes elsewhere.

'nuff said.

>
> >
> > The problem statement has been release. Given the lack
> > of discussion on the email list, it would seem to me
> > plausible to set a near term wg release date. I suggest
> > May 25.
>
> good. so I will do a WG last call on the spec, and if we receive
> no comments in during that last call (or no comments that
> would require
> another last call), we can simply move the spec ahead.
>
> I will make the date Jun, to add necessary padding.
>
> >
> > This is all going to slow. I think many people are losing
> > interest because they want to work on solutions and the
> > "fuzzy front end" of problem statements and requirements
> > is taking too long.  Yes, I know these documents are important,
> > but I also know that we can spend until September 2010 analyzing
> > requirements, and still not get it right. Only by working on
> > the solutions will we uncover the really unexpected "gotchas".
>
> Well, it sounds like we are almost done with requirements, and ready
> to move on. btw, designing a protocol when you have a concrete set of
> requirements is MUCH faster than without. So the time savings
> can in many
> cases be justified. Further, if someone accuses creeping
> featurism, you
> can point to a requirements I-D that went through last call.

Yes, yes, yes. But as someone instructed me early on in his career:
analysis can lead to paralysis.

As long as everyone is happy with the idea that we are working on ct
solutions without achieving IESG approval on the problem statement,
never mind the requirements, then I am happy.

>
> > As for "lining up with the SDOs"? When did this become a schedule
> > driving priority? I think liasing with SDOs is important, but
> > I don't see the need to link up the efforts explicitly.
> More importantly,
> > I don't see how it can be done. You might link up with one SDO, but
> > there are at least four that I can think of that are of
> equal importance,
> > and we cannot favour any one over the others.
>
> ok, perhaps the wording needs to be changed, but the ADs liked it. We
> aren't expecting to send liasons, as you know the IETF
> doesn't do that.
> This paragraph is an invitation to other SDOs (which, btw,
> are made aware
> of our new charters), to send people to work with us, if they
> are interested.
>
> I, personally, don't see the harm in asking for people to participate
> in our work.
>
> Is there another way to put it that you would feel more
> comfortable with?

I really don't want to get into wordsmithing the charter. I like the original
one just fine ;^}. My only concern was that the involvement of the SDOs was
driving the schedule.

>
> PatC
>

GWK

------_=_NextPart_001_01C0DCA4.95A8D170-- From owner-seamoby@diameter.org Mon May 14 15:43:42 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22714 for ; Mon, 14 May 2001 15:43:41 -0400 (EDT) Received: (qmail 13427 invoked by alias); 14 May 2001 19:25:51 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 13421 invoked by uid 200); 14 May 2001 19:25:50 -0000 Received: (qmail 13412 invoked by uid 500); 14 May 2001 19:25:49 -0000 Date: Mon, 14 May 2001 12:25:49 -0700 From: Pat Calhoun To: Gary Kenward Cc: "'Pat Calhoun'" , seamoby@cdma-2000.org Subject: Re: [seamoby] Seamoby Charter Last Call Message-ID: <20010514122549.L10188@charizard.diameter.org> Mail-Followup-To: Gary Kenward , 'Pat Calhoun' , seamoby@cdma-2000.org References: <9FBD322B7824D511B36900508BF93C9C12590E@zcard031.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <9FBD322B7824D511B36900508BF93C9C12590E@zcard031.ca.nortel.com>; from gkenward@nortelnetworks.com on Mon, May 14, 2001 at 02:35:00PM -0400 Sender: owner-seamoby@diameter.org Precedence: bulk On Mon, May 14, 2001 at 02:35:00PM -0400, Gary Kenward wrote: > The problem was the size of the cushion. I clearly mis-understood > the purpose of the milestones, which is to identify the point > at which the drafts are approved by the IESG? (I don't know how or > why one would want to predict such an event ;^}, but so be it). right :) However, the IETF does try to stay on schedule, when possible, but as you know, outside forces (or in most cases inside forces) delay documents. This is a heads up for people interested in the work, to give them sort of an idea as to when the work could be completed. I will make some slight wording changes to the charter vis-a-vis the interim meeting. It can be used for the next stage of work if we are done with requirements. > > As long as we can proceed with the solutions work before the end > of May. I think everything that needs to be said about requirements > has been voiced one way or the other. Yes, there is probably more > requirements to come out later on, but it's not worth waiting for > that possibility to happen. Right. If the DT and WG can agree on the requirements, then we can move on. As you state, new requirements MAY come in later on, but it should be more difficult for someone to introduce new requirements later on, as opposed to now. Of course, if we (the WG) clearly forgot something, and it obviously will be of limited use, then we can discuss it on the list. However, we need a clear set to begin with, and I think you guys have done a great job. > > Yes, yes, yes. But as someone instructed me early on in his career: > analysis can lead to paralysis. right, and as you agree, requirements gathering phase shouldn't take *that* long, and as I understand it, you're nearly done. PatC From owner-seamoby@diameter.org Tue May 15 02:27:39 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA17899 for ; Tue, 15 May 2001 02:27:39 -0400 (EDT) Received: (qmail 16940 invoked by alias); 15 May 2001 06:15:35 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 16934 invoked by uid 200); 15 May 2001 06:15:35 -0000 Received: (qmail 16929 invoked from network); 15 May 2001 06:15:33 -0000 Received: from porsta.cs.helsinki.fi (root@128.214.48.124) by c900656-a.plstn1.sfba.home.com with SMTP; 15 May 2001 06:15:33 -0000 Received: from melkinpaasi.cs.Helsinki.FI (IDENT:jmanner@melkinpaasi.cs.Helsinki.FI [128.214.10.13]) by porsta.cs.Helsinki.FI (8.11.3/8.11.3) with ESMTP id f4F6Ofm27542; Tue, 15 May 2001 09:24:41 +0300 Date: Tue, 15 May 2001 09:24:40 +0300 (EEST) From: Jukka Manner To: Hamid Syed cc: "'James Kempf'" , Subject: RE: Wireless Terminology Draft( was: Re: [seamoby] Seamoby Charte r Last Call) In-Reply-To: <9FBD322B7824D511B36900508BF93C9C1CD079@zcard031.ca.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk Hamid, Thank you for suggesting it. The draft was originally meant to support the work in Seamoby, but it would be an even better idea to make it a more thorough document for use in more or less all work relating to mobile and wireless environments, including Seamoby, Mobile-IP, and possibly MANET. I would be happy to continue the work on the terminology taking as basis the mentioned draft. BR, Jukka On Mon, 14 May 2001, Hamid Syed wrote: > Hello james, > > A draft was submitted to seamoby early this year that attempted to capture > the wireless terminology. her eis the link: > http://search.ietf.org/internet-drafts/draft-manner-seamoby-terms-01.txt > > br > > -Hamid > > > -----Original Message----- > > From: James Kempf [SMTP:James.Kempf@Sun.COM] > > Sent: Monday, May 14, 2001 1:47 PM > > To: seamoby@diameter.org > > Subject: Wireless Terminology Draft( was: Re: [seamoby] Seamoby > > Charter Last Call) > > > > > > ------------- Begin Forwarded Message ------------- > > > > Date: Mon, 14 May 2001 10:43:47 -0700 (PDT) > > From: James Kempf > > Subject: Re: [seamoby] Seamoby Charter Last Call > > To: James.Kempf@sun.com, charliep@iprg.nokia.com > > Content-MD5: 6F7Vl9kYVVbqr66TeEQyRw== > > > > Hi Charlie, > > > > > > >> Maybe we need a terminology draft, or at least, define this term > > >> somewhere so that it can be referred to. I'm suprised nobody > > >> has done a generalized terminology draft for wireless terms before in > > the MIP > > >> group. > > > > > >RFC 2002 does start off with a long list of terminology. > > > > > >It is questionable whether any specific wireless terms are > > >needed for a protocol running over IP. What is needed is > > >a list of useful terms. For instance, one might care about > > >error rate or bandwidth even if the medium were not wireless. > > >I don't think that chip rate, for instance, should be part > > >of the [seamoby] terminology list. > > > > > > > Actually, there are plenty of wireless terms that need definition. > > Access point, handoff (or handover IETF should select which one > > it wants to use), context transfer, paging, etc. etc. > > > > >Do you think that there are terms which SHOULD have been defined > > >for RFC 2002? If so, now would be a good time to mention them > > >before RFC 2002bis goes to the RFC editor's desk. > > > > > > > No, I think they have wider applicability. More and more wireless > > stuff is going on. There are now two working groups associated > > with wireless, and others that have a big wireless component. I think > > having a > > terminology draft that collects all terminology that could be referred to > > by > > drafts would be a benefit. > > > > jak > > > > > > > > ------------- End Forwarded Message ------------- > > > > > From owner-seamoby@diameter.org Wed May 16 07:03: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 HAA02718 for ; Wed, 16 May 2001 07:03:11 -0400 (EDT) Received: (qmail 31087 invoked by alias); 16 May 2001 10:51:07 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 31081 invoked by uid 200); 16 May 2001 10:51:07 -0000 Received: (qmail 31076 invoked from network); 16 May 2001 10:51:04 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by c900656-a.plstn1.sfba.home.com with SMTP; 16 May 2001 10:51:04 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02554; Wed, 16 May 2001 07:01:47 -0400 (EDT) Message-Id: <200105161101.HAA02554@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: seamoby@cdma-2000.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [seamoby] I-D ACTION:draft-ietf-seamoby-context-transfer-problem-stat-01.txt Date: Wed, 16 May 2001 07:01:46 -0400 Sender: owner-seamoby@diameter.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Context and Micro-mobility Routing Working Group of the IETF. Title : Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network Author(s) : O. Levkowetz, P. Calhoun Filename : draft-ietf-seamoby-context- transfer-problem-stat-01.txt Pages : 12 Date : 15-May-01 There are a large number of IP access networks that support mobility of hosts. For example, wireless Personal Area Networks (PANs), wireless LANs, satellite WANs and cellular WANs. The nature of this mobility is such that the communication path to the host changes frequently and rapidly. This Internet-Draft describes the problem encountered during mobility that requires the exchange of IP context between different forwarding nodes in an access network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-seamoby-context-transfer-problem-stat-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-seamoby-context-transfer-problem-stat-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-seamoby-context-transfer-problem-stat-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010515105445.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-seamoby-context-transfer-problem-stat-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-seamoby-context-transfer-problem-stat-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010515105445.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-seamoby@diameter.org Wed May 16 08:46:42 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 IAA06252 for ; Wed, 16 May 2001 08:46:37 -0400 (EDT) Received: (qmail 31932 invoked by alias); 16 May 2001 12:30:49 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 31925 invoked by uid 200); 16 May 2001 12:30:48 -0000 Cc: recipient list not shown: ; Received: (qmail 31920 invoked from network); 16 May 2001 12:30:40 -0000 Received: from md2.md.chula.ac.th (161.200.96.2) by c900656-a.plstn1.sfba.home.com with SMTP; 16 May 2001 12:30:40 -0000 Received: from slip129-37-237-10.il.us.prserv.net by md2.md.chula.ac.th (5.4R3.10/200.2.1.5) id AA00490; Wed, 16 May 2001 19:44:51 +0700 Date: 16 May 01 7:47:15 AM From: 03uPPAKxa@188.net Message-Id: <3c2Axt8MoFI9845> Subject: [seamoby] New Millennia Currency is "Special Info" Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Sender: owner-seamoby@diameter.org Precedence: bulk Dear Friend: AS SEEN ON NATIONAL TV : ''Making over half million dollars every 4 to 5 months from your home for an investment of only $25 U.S. Dollars expense one time'' THANKS TO THE COMPUTER AGE AND THE INTERNET! ================================================= BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR!!! Before you say ''Bull'', please read the following. This is the letter you have been hearing about on the news lately. Due to the popularity of this letter on the internet, a national weekly news program recently devoted an entire show to the investigation of this program described below, to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are ''absolutely NO laws prohibiting the participation in the program and if people can follow the simple instructions, they are bound to make some mega bucks with only $25 out of pocket cost''. DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING BETTER THAN EVER. This is what one had to say: ''Thanks to this profitable opportunity. I was approached many times before but each time I passed on it. I am so glad I finally joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received total $ 610,470.00 in 21 weeks, with money still coming in''. Pam Hedland, Fort Lee, New Jersey. ------------------------------------------------------------------------- Here is another testimonial: ''This program has been around for a long time but I never believed in it. But one day when I received this again in the mail I decided to gamble my $25 on it. I followed the simple instructions and voila' - 3 weeks later the money started to come in. First month I only made $240.00 but the next 2 months after that I made a total of $290,000.00. So far, in the past 8 months by re-entering the program, I have made over $710,000.00 and I am playing it again.The key to success in this program is to follow the simple steps and NOT change anything'' More testimonials later but first, ****PRINT THIS NOW FOR YOUR FUTURE REFERENCE**** $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make at least $500,000 every 4 to 5 months easily and comfortably, please read the following...THEN READ IT AGAIN and AGAIN!!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL DREAMS WILL COME TRUE, GUARANTEED! INSTRUCTIONS: ****Order all 5 reports shown on the list below. ****For each report, send $5 CASH, THE NAME & NUMBER OF THE REPORT YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the person whose name appears ON THAT LIST next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mail problems. ****When you place your order, make sure you order each of the 5 reports.You will need all 5 reports so that you can save them on your computer and resell them. YOUR TOTAL COST $5 X 5 = $25.00. ****Within a few days you will receive, vie e-mail, each of the 5 reports from these 5 different individuals. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. Also make a floppy of these reports and keep it on your desk in case something happen to your computer. ****IMPORTANT __ DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than what is instructed below in step '' 1 through 6 '' or you will loose out on majority of your profits. Once you understand the way this works, you will also see how it does not work if you change it. Remember, this method has been tested, and if you alter, it will NOT work!!! People have tried to put their friends/relatives names on all five thinking they could get all the money. But it does not work this way. Believe us, we all have tried to be greedy and then nothing happened. So Do Not try to change anything other than what is instructed. Because if you do, it will not work for you.Remember, honesty reaps the reward!!! 1....After you have ordered all 5 reports, take this advertisement and REMOVE the name & address of the person in REPORT #5. This person has made it through the cycle and is no doubt counting their fortune. 2....Move the name & address in REPORT #4 down TO REPORT # 5. 3....Move the name & address in REPORT #3 down TO REPORT # 4. 4....Move the name & address in REPORT #2 down TO REPORT # 3. 5....Move the name & address in REPORT #1 down TO REPORT #2 6....Insert YOUR name & address in the REPORT #1 Position. PLEASE MAKE SURE you copy every name & address ACCURATELY! ================================================= ****Take this entire letter, with the modified list of names, and save it on your computer. DO NOT MAKE ANY OTHER CHANGES. Save this on a disk as well just in case if you loose any data. ****To assist you with marketing your business on the internet, the 5 reports you purchase will provide you with invaluable marketing information which includes how to send bulk e-mails legally, where to find thousands of free classified ads and much more. There are 2 Primary methods to get this venture going: METHOD #1 : BY SENDING BULK E-MAIL LEGALLY ================================================= Let's say that you decide to start small, just to see how it goes, and we will assume You and those involved send out only 5,000 e-mails each. Let's also assume that the mailing receive only a 0.2% response (the response could be much better but lets just say it is only 0.2% . Also many people will send out hundreds of thousands e-mails instead of only 5,000 each). Continuing with this example, you send out only 5,000 e-mails.With a 0.2% response, that is only 10 orders for report # 1.Those 10 people responded by sending out 5,000 e-mail each for a total of 50,000. Out of those 50,000 e-mails only 0.2% responded with orders. That's = 100 people responded and ordered Report # 2. Those 100 people mail out 5,000 e-mails each for a total of 500,000 e-mails. The 0.2% response to that is 1000 orders for Report # 3. Those 1000 people send out 5,000 e-mails each for a total of 5 million e-mails sent out. The 0.2% response to that is 10,000 orders for Report # 4. Those 10,000 people send out 5,000 e-mails each for a total of 50,000,000 (50 million) e-mails. The 0.2% response to that is 100,000 orders for Report # 5 THAT'S 100,000 ORDERS TIMES $5 EACH = $500,000.00 (half million). Your total income in this example is: 1..... $50 + 2..... $500 + 3..... $5,000 + 4..... $50,000 + 5..... $500,000 ......... Grand Total = $555,550.00 NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE OUT THE WORST POSSIBLE RESPONSES AND NO MATTER HOW YOU CALCULATE IT, YOU WILL STILL MAKE A LOT OF MONEY! -------------------------------------------------------------------------- REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE ORDERING OUT OF 5,000 YOU MAILED TO. Dare to think for a moment what would happen if everyone, or half or even one 4th of those people mailed 100,000 e-mails each or more? There are over 150 million people on the internet worldwide and counting. Believe me, any people will do just that, and more! METHOD #2 : BY PLACING FREE ADS ON THE INTERNET ================================================= Advertising on the net is very very inexpensive and there are hundreds of FREE places to advertise. Placing a lot of free ads on the internet will easily get a larger response. We strongly suggest you start with method #1 and add METHOD #2 as you go along. For every $5 you receive, all you must do is e-mail them the Report they ordered. That's it . Always provide same day service on all orders. This will guarantee that the e-mail they send out, with your name and address on it, will be prompt because they can not advertise until they receive the report. _________________AVAILABLE REPORTS__________________ ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes: Always send $5 cash (U.S. CURRENCY) for each Report. Checks NOT accepted. Make sure the cash is concealed by wrapping it in at least 2 sheets of paper. _________________________________________________________ *PLEASE USE THIS REPORT ORDER FORM FOR EACH REPORT* ------- Copy & Paste this form to your word processor 5 times, then fill out & send for each report---------------- Ordering Report Name & Number : My E-mail Address : My Name & Mailing Address : REMEMBER WITHOUT AN E-MAIL ADDRESS THE ORDERS CAN NOT BE PROCESSED!! ****************************************************** PLACE YOUR ORDER FOR THESE REPORTS NOW : ============================================== REPORT #1 ""The Insider's Guide to Sending Bulk E-mail on the Net" ORDER REPORT #1 FROM: Steve Strickland PO Box 56 Rossford, Ohio 43460 USA ---------------------------------------------------------------------- REPORT #2 ”The Insider's Guide to Advertising for Free on the Net ORDER REPORT #2 FROM: Wade Horne Horne Consulting PO Box 745 Shallotte, NC 28459 --------------------------------------------------------------------- REPORT #3 "The Secrets to Multilevel Marketing on the Internet" ORDER REPORT #3 FROM: Michael Green PO Box 326 Union Lake, MI 48387 USA --------------------------------------------------------------------- REPORT #4 "How to become a Millionaire utilizing the Power of Multilevel Marketing and the Internet" ORDER REPORT #4 FROM: Trumpeter Productions 4105 Tujunga Ave #6 Studio City, CA 91604 USA ------------------------------------------------------------------- REPORT #5 "How to SEND 1,000,000 e-mails for FREE" ORDER REPORT #5 FROM: Mark Priebe 2482 Harness Dr. West Bloomfield, MI 48324 USA ****************************************************** $$$$$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$$$$ Follow these guidelines to guarantee your success: ***If you do not receive at least 10 orders for Report #1 within 2 weeks, continue sending e-mails until you do. ***After you have received 10 orders, 2 to 3 weeks after that you should receive 100 orders or more for REPORT #2. If you did not, continue advertising or sending e-mails until you do. ***Once you have received 100 or more orders for Report #2, YOU CAN RELAX, because the system is already working for you , and the cash will continue to roll in! THIS IS IMPORTANT TO REMEMBER : Every time your name is moved down on the list, you are placed in front of a Different report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. IF YOU WANT TO GENERATE MORE INCOME SEND ANOTHER BATCH OF E-MAILS AND START THE WHOLE PROCESS AGAIN. There is NO LIMIT to the income you can generate from this business!!! ______________________________________________________ FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS PROGRAM: "You have just received information that can give you financial freedom for the rest of your life, with NO RISK and JUST A LITTLE BIT OF EFFORT. You can make more money in the next few weeks and months than you have ever imagined. Follow the program EXACTLY AS INSTRUCTED. Do Not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report after you have put your name and address in Report #1 and moved others to #2 ...........#5 as instructed above. One of the people you send this to may send out 100,000 or more e-mails and your name will be on everyone of them. Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU NOW! ****************MORE TESTIMONIALS***************** 'My name is Mitchell. My wife, Jody and I live in Chicago. I am an accountant with a major U.S. Corporation and I make pretty good money. When I received this program I grumbled to Jody about receiving ''junk mail''. I made fun of the whole thing, spouting my knowledge of the population and percentages involved. I ''knew'' it wouldn't work. Jody totally ignored my supposed intelligence and few days later she jumped in with both feet. I made merciless fun of her, and was ready to lay the old ''I told you so'' on her when the thing didn't work. Well, the laugh was on me! Within 3 weeks she had received 50 responses. Within the next 45 days she had received total $ 147,200.00 ......... all cash! I was shocked. I have joined Jody in her ''hobby''. Mitchell Wolf, M.D. , Chicago, Illinois -------------------------------------------------------------------------- ''Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back''. ''I was surprised when I found my medium size post office box crammed with orders. I made $319,210.00 in the first 12 weeks. The nice thing about this deal is that it does not matter where people live. There simply isn't a better investment with a faster return and so big''. Dan Sondstrom, Alberta, Canada -------------------------------------------------------------------------- ''I had received this program before. I deleted it, but later I wondered if I should have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed again by someone else.........11 months passed then it luckily came again...... I did not delete this one! I made more than $490,000 on my first try and all the money came within 22 weeks''. Susan De Suza, New York, N.Y. -------------------------------------------------------------------------- ''It really is a great opportunity to make relatively easy money with little cost to you. I followed the simple instructions carefully and within 10 days the money started to come in. My first month I made $ 20, 560.00 and by the end of third month my total cash count was $ 362,840.00. Life is beautiful, Thanx to internet''. Fred Dellaca, Westport, New Zealand -------------------------------------------------------------------------- ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO FINANCIAL FREEDOM! ================================================== If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection, Washington, D.C. /////////////////////////////////////////////////////////////////////////////// ONE TIME MAILING, NO NEED TO REMOVE /////////////////////////////////////////////////////////////////////////////// This message is sent in compliance of the proposed bill SECTION 301. per Section 301, Paragraph (a)(2)(C) of S. 1618. Further transmission to you by the sender of this e-mail may be stopped at no cost to you by sending a reply to :Sophie530@email.com with the word Remove in the subject line. This message is not intended for residents in the State of Washington, screening of addresses has been done to the best of our technical ability. ******************************************************* THIS LETTER CONSTITUTES NO GUARANTEES STATED NOR IMPLIED. IN THE EVENT THAT IT IS DETERMINED THAT THIS LETTER CONSTITUTES A GUARANTEE OF ANY KIND, THAT GUARANTEE IS NOW VOID. ANY TESTIMONIALS OR AMOUNTS OF EARNINGS LISTED IN THIS LETTER MAY BE FACTUAL OR FICTITIOUS. ******************************************************** From owner-seamoby@diameter.org Wed May 16 09:45: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 JAA08908 for ; Wed, 16 May 2001 09:45:57 -0400 (EDT) Received: (qmail 32706 invoked by alias); 16 May 2001 13:34:31 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 32700 invoked by uid 200); 16 May 2001 13:34:31 -0000 Received: (qmail 32695 invoked by uid 500); 16 May 2001 13:34:29 -0000 Date: Wed, 16 May 2001 06:34:29 -0700 From: Pat Calhoun To: seamoby@cdma-2000.org Subject: [seamoby] WG Last Call: draft-ietf-seamoby-context-transfer-problem-stat-01.txt Message-ID: <20010516063429.D32602@charizard.diameter.org> Mail-Followup-To: seamoby@cdma-2000.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-seamoby@diameter.org Precedence: bulk All, The Context Transfer problem statement is in WG Last Call. Please submit any comments to the list by May 30th, after which the document will be sent to the IESG. Thanks, PatC From owner-seamoby@diameter.org Wed May 16 15:23: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 PAA17583 for ; Wed, 16 May 2001 15:23:11 -0400 (EDT) Received: (qmail 8337 invoked by alias); 16 May 2001 19:10:13 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8331 invoked by uid 200); 16 May 2001 19:10:12 -0000 Received: (qmail 8326 invoked from network); 16 May 2001 19:10:08 -0000 Received: from user196.64.37.247.dsli.com (HELO stewart.chicago.il.us) (root@64.37.247.196) by c900656-a.plstn1.sfba.home.com with SMTP; 16 May 2001 19:10:08 -0000 Received: from stewart.chicago.il.us (IDENT:randall@stewartlin [10.1.1.1]) by stewart.chicago.il.us (8.11.0/8.11.0) with ESMTP id f4GJMPh05769 for ; Wed, 16 May 2001 14:22:25 -0500 Message-ID: <3B02D370.9FFDC96F@stewart.chicago.il.us> Date: Wed, 16 May 2001 14:22:24 -0500 From: "Randall R. Stewart" X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.17-14 i686) X-Accept-Language: en MIME-Version: 1.0 To: seamoby@diameter.org Subject: [seamoby] An API issue Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear All: I have a problem and was wondering if anyone else has encountered this... This may be the wrong place to take this issue Pat, if it is, please redirect me.. Here is the jest of the problem. I have a wireless card driver (it can be any type you can imagine.. GSM, 802.11 even blue-tooth...). It gets a signal that an event has transpired i.e. Association fell apart or came up, i.e. I can now reach a AR or I can no longer reach an AR or maybe some other trigger type event of interest. This is the ole Layer-2 trigger that everyone talks about.... Now HOW do I get it up to layer 3? This seems like a real naive question I know... but when you start digging in to at least most unixy stacks, you have a layer 2 driver servicing the card (or is it layer 1:>), its interfaces to upper layers are: A) ioctl... user requests/response model B) packet arrival -> submit to ether_input() C) packet sending -> output routine is called. Now I can use A if you want to have the interested upper layer poll every N interval and ask... hey what is your current status? But this means that N becomes the granularity of when you might want to handoff/do something. This could be a real problem for real time services... I can't use C.. after all this is output.. And B seems pointless as well.. there is NO packet defined or protocol defined I can launch up to the layer above that will resolve to the listner. Ideally it would be nice to send a "Layer 2" Trigger message in (B). One could even envision an "ether protocol id" that directs the above layer to send it down a particular Layer 3 path where a reader would get it... I have thought about doing this using FreeBSD's routing sockets and allowing it to get this type of input event... but its not standard... It would be nice to have some sort of standard way to signal upwards these Layer-2 triggers (if available). Has anyone thought of this? I would be willing to write a draft on this if folks thought it was a good idea... but it really has no wire side protocol basis... of course neither does a lot of the sockets mapping api's either :/ I would appreciate either re-direction or comments from you all who may have thought of this.. Thanks R -- Randall R. Stewart randall@stewart.chicago.il.us or rrs@cisco.com 815-342-5222 (cell) 815-477-2127 (work) From owner-seamoby@diameter.org Wed May 16 16:48: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 QAA18893 for ; Wed, 16 May 2001 16:48:20 -0400 (EDT) Received: (qmail 9337 invoked by alias); 16 May 2001 20:36:42 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 9331 invoked by uid 200); 16 May 2001 20:36:41 -0000 Received: (qmail 9326 invoked from network); 16 May 2001 20:36:37 -0000 Received: from unknown (HELO cobweb.example.org) (64.103.37.2) by c900656-a.plstn1.sfba.home.com with SMTP; 16 May 2001 20:36:37 -0000 Received: (qmail 1262 invoked by uid 1000); 16 May 2001 20:41:47 -0000 Date: Wed, 16 May 2001 22:41:47 +0200 From: Marco Molteni To: seamoby@diameter.org Cc: "Randall R. Stewart" Subject: Re: [seamoby] An API issue Message-ID: <20010516224147.A635@cobweb.example.org> References: <3B02D370.9FFDC96F@stewart.chicago.il.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B02D370.9FFDC96F@stewart.chicago.il.us>; from randall@stewart.chicago.il.us on Wed, May 16, 2001 at 02:22:24PM -0500 Sender: owner-seamoby@diameter.org Precedence: bulk On 2001-05-16, Randall R. Stewart wrote: Hi Randall, [..] > Here is the jest of the problem. I have a wireless card driver (it > can be any type you can imagine.. GSM, 802.11 even blue-tooth...). > > It gets a signal that an event has transpired i.e. Association fell > apart or came up, i.e. I can now reach a AR or I can no longer reach > an AR or maybe some other trigger type event of interest. This is > the ole Layer-2 trigger that everyone talks about.... > > Now HOW do I get it up to layer 3? > > This seems like a real naive question I know... but when you start > digging in to at least most unixy stacks, you have a layer 2 driver > servicing the card (or is it layer 1:>), its interfaces to upper > layers are: > > A) ioctl... user requests/response model > B) packet arrival -> submit to ether_input() > C) packet sending -> output routine is called. [..] I have a suggestion for the kernel -> userland case: write a pseudo device driver. Usage scenarios: 1. synchronous, but not polling: you can select(2) or poll(2) a descriptor bound to the device, and have the device make the descriptor ready for reading when an event occurs. 2. asynchronous: have the pseudo device send a signal to the process who opened it when an event occurs. in both scenarios then you can either read from it or issue an ioctl to have further informations on the event. Marco From owner-seamoby@diameter.org Wed May 16 17:07: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 RAA19258 for ; Wed, 16 May 2001 17:07:40 -0400 (EDT) Received: (qmail 9870 invoked by alias); 16 May 2001 20:56:02 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 9864 invoked by uid 200); 16 May 2001 20:56:01 -0000 Received: (qmail 9859 invoked from network); 16 May 2001 20:56:00 -0000 Received: from unknown (HELO NEPTUNE.zucotto.com) (216.95.209.154) by c900656-a.plstn1.sfba.home.com with SMTP; 16 May 2001 20:56:00 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Wed, 16 May 2001 17:06:52 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F7F62@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Randall R. Stewart'" , seamoby@diameter.org Subject: RE: [seamoby] An API issue Date: Wed, 16 May 2001 17:06:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk > -----Original Message----- > From: Randall R. Stewart [mailto:randall@stewart.chicago.il.us] > Sent: Wednesday, May 16, 2001 3:22 PM > To: seamoby@diameter.org > Subject: [seamoby] An API issue > > > Dear All: > > I have a problem and was wondering if anyone else > has encountered this... > > This may be the wrong place to take this issue Pat, if it > is, please redirect me.. > > Here is the jest of the problem. I have a wireless card > driver (it can be any type you can imagine.. GSM, 802.11 > even blue-tooth...). > > It gets a signal that an event has transpired > i.e. Association fell apart or came up, i.e. I can now reach > a AR or I can no longer reach an AR or maybe some other trigger > type event of interest. This is the ole Layer-2 > trigger that everyone talks about.... > > Now HOW do I get it up to layer 3? > > This seems like a real naive question I know... but when you > start digging in to at least most unixy stacks, you have > a layer 2 driver servicing the card (or is it layer 1:>), > its interfaces to upper layers are: > > A) ioctl... user requests/response model > B) packet arrival -> submit to ether_input() > C) packet sending -> output routine is called. > D) Interrupts (linux disable_irq/enable_irq) Hardware Interrupt -> Interrupt Handler -> Interrupt Service Routine -> Proxy -> Thread - Kulwinder. From owner-seamoby@diameter.org Wed May 16 18:17: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 SAA20129 for ; Wed, 16 May 2001 18:17:36 -0400 (EDT) Received: (qmail 12224 invoked by alias); 16 May 2001 22:05:52 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 12218 invoked by uid 200); 16 May 2001 22:05:52 -0000 Received: (qmail 12212 invoked by uid 500); 16 May 2001 22:05:48 -0000 Date: Wed, 16 May 2001 15:05:47 -0700 From: Pat Calhoun To: seamoby@cdma-2000.org Subject: [seamoby] [owner-seamoby-context@diameter.org: BOUNCE seamoby-context@diameter.org: Message too long (>100000 chars)] Message-ID: <20010516150547.O1870@charizard.diameter.org> Mail-Followup-To: seamoby@cdma-2000.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-seamoby@diameter.org Precedence: bulk ----- Forwarded message from owner-seamoby-context@diameter.org ----- Guys, you'll have to trim your messages a little. Over 100K seems pretty long for a single sentence response. I am forwarding this from Madjid, since it bounced. PatC ---- I forgot, I do like adding the capability of doing partial CT. Madjid From owner-seamoby@diameter.org Wed May 16 21:02: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 VAA22142 for ; Wed, 16 May 2001 21:02:47 -0400 (EDT) Received: (qmail 14511 invoked by alias); 17 May 2001 00:50:55 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 14505 invoked by uid 200); 17 May 2001 00:50:54 -0000 Received: (qmail 14500 invoked from network); 17 May 2001 00:50:53 -0000 Received: from mercury.sun.com (192.9.25.1) by c900656-a.plstn1.sfba.home.com with SMTP; 17 May 2001 00:50:53 -0000 Received: from heliopolis.eng.sun.com ([152.70.1.39]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA22286; Wed, 16 May 2001 18:01:38 -0700 (PDT) Received: from awe171-106 (awe195-120.AWE.Sun.COM [192.29.195.120]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id SAA24292; Wed, 16 May 2001 18:01:37 -0700 (PDT) Message-Id: <200105170101.SAA24292@heliopolis.eng.sun.com> Date: Wed, 16 May 2001 16:53:46 -0700 (PDT) From: kempf Reply-To: kempf Subject: Re: [seamoby] An API issue To: seamoby@diameter.org, randall@stewart.chicago.il.us MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: s5eo2xjYqjzRhmC2J8vNTA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 i86pc i386 Sender: owner-seamoby@diameter.org Precedence: bulk Randy, >This seems like a real naive question I know... but when you >start digging in to at least most unixy stacks, you have >a layer 2 driver servicing the card (or is it layer 1:>), >its interfaces to upper layers are: > >A) ioctl... user requests/response model >B) packet arrival -> submit to ether_input() >C) packet sending -> output routine is called. > > >Now I can use A if you want to have the interested upper >layer poll every N interval and ask... hey what is your >current status? But this means that N becomes the granularity >of when you might want to handoff/do something. This could >be a real problem for real time services... > How about a thread that blocks on the ioctl() and returns when the Layer 2 event occurs? After all, this is 2001 and while we may not have cities on the moon and spaceships to Juipiter, most operating systems now support multithreading at the user level. jak From owner-seamoby@diameter.org Wed May 16 22:15: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 WAA23579 for ; Wed, 16 May 2001 22:15:28 -0400 (EDT) Received: (qmail 15112 invoked by alias); 17 May 2001 02:03:44 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 15106 invoked by uid 200); 17 May 2001 02:03:44 -0000 Received: (qmail 15100 invoked from network); 17 May 2001 02:03:42 -0000 Received: from user196.64.37.247.dsli.com (HELO stewart.chicago.il.us) (root@64.37.247.196) by c900656-a.plstn1.sfba.home.com with SMTP; 17 May 2001 02:03:42 -0000 Received: from stewart.chicago.il.us (IDENT:randall@stewartlin [10.1.1.1]) by stewart.chicago.il.us (8.11.0/8.11.0) with ESMTP id f4H2DYh07205; Wed, 16 May 2001 21:13:34 -0500 Message-ID: <3B0333CE.2ECFCEB5@stewart.chicago.il.us> Date: Wed, 16 May 2001 21:13:34 -0500 From: "Randall R. Stewart" X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.17-14 i686) X-Accept-Language: en MIME-Version: 1.0 To: kempf CC: seamoby@diameter.org Subject: Re: [seamoby] An API issue References: <200105170101.SAA24292@heliopolis.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit kempf wrote: > > Randy, > > >This seems like a real naive question I know... but when you > >start digging in to at least most unixy stacks, you have > >a layer 2 driver servicing the card (or is it layer 1:>), > >its interfaces to upper layers are: > > > >A) ioctl... user requests/response model > >B) packet arrival -> submit to ether_input() > >C) packet sending -> output routine is called. > > > > > >Now I can use A if you want to have the interested upper > >layer poll every N interval and ask... hey what is your > >current status? But this means that N becomes the granularity > >of when you might want to handoff/do something. This could > >be a real problem for real time services... > > > > How about a thread that blocks on the ioctl() and returns when > the Layer 2 event occurs? After all, this is 2001 and while > we may not have cities on the moon and spaceships to Juipiter, > most operating systems now support multithreading at the > user level. > Hmm.. I suppose a blocking ioctl could be done... something like ioctl(TELL_ME_WHEN_I_LOSE_THE_AR); That blocks... but my question is far deeper than such a naive ioctl()... I think there may be more things I want to know besides I can see an AR and I can't see an AR... maybe I am just attempting to make this too complicated... but a blocking ioctl() crossed my mind but I dismissed it... Of course another reason may also be that I dis-like threads :) R -- Randall R. Stewart randall@stewart.chicago.il.us or rrs@cisco.com 815-342-5222 (cell) 815-477-2127 (work) From owner-seamoby@diameter.org Thu May 17 07:24: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 HAA13719 for ; Thu, 17 May 2001 07:24:28 -0400 (EDT) Received: (qmail 17257 invoked by alias); 17 May 2001 11:11:21 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 17251 invoked by uid 200); 17 May 2001 11:11:20 -0000 Received: (qmail 17246 invoked from network); 17 May 2001 11:11:19 -0000 Received: from user196.64.37.247.dsli.com (HELO stewart.chicago.il.us) (root@64.37.247.196) by c900656-a.plstn1.sfba.home.com with SMTP; 17 May 2001 11:11:19 -0000 Received: from stewart.chicago.il.us (IDENT:randall@stewartlin [10.1.1.1]) by stewart.chicago.il.us (8.11.0/8.11.0) with ESMTP id f4HBNnh08939; Thu, 17 May 2001 06:23:49 -0500 Message-ID: <3B03B4C5.123ED6BE@stewart.chicago.il.us> Date: Thu, 17 May 2001 06:23:49 -0500 From: "Randall R. Stewart" X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.17-14 i686) X-Accept-Language: en MIME-Version: 1.0 To: Marco Molteni CC: seamoby@diameter.org Subject: Re: [seamoby] An API issue References: <3B02D370.9FFDC96F@stewart.chicago.il.us> <20010516224147.A635@cobweb.example.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Marco: It is not that I could not hack something together there are several possiblities. And I don't think I would approach it from the aspect of a pseudo driver since I already have a driver. With most e-net type drivers you don't read directly from... this could be added... but I was just hoping (in vain I see from most of the email) that we might all have a standard way to approach the problem so in the end everyone's card(s) would work and play nice together... R Marco Molteni wrote: > > On 2001-05-16, Randall R. Stewart wrote: > > Hi Randall, > > [..] > > > Here is the jest of the problem. I have a wireless card driver (it > > can be any type you can imagine.. GSM, 802.11 even blue-tooth...). > > > > It gets a signal that an event has transpired i.e. Association fell > > apart or came up, i.e. I can now reach a AR or I can no longer reach > > an AR or maybe some other trigger type event of interest. This is > > the ole Layer-2 trigger that everyone talks about.... > > > > Now HOW do I get it up to layer 3? > > > > This seems like a real naive question I know... but when you start > > digging in to at least most unixy stacks, you have a layer 2 driver > > servicing the card (or is it layer 1:>), its interfaces to upper > > layers are: > > > > A) ioctl... user requests/response model > > B) packet arrival -> submit to ether_input() > > C) packet sending -> output routine is called. > > [..] > > I have a suggestion for the kernel -> userland case: write a pseudo > device driver. > > Usage scenarios: > > 1. synchronous, but not polling: > you can select(2) or poll(2) a descriptor bound to the device, and have > the device make the descriptor ready for reading when an event occurs. > > 2. asynchronous: > have the pseudo device send a signal to the process who opened it when > an event occurs. > > in both scenarios then you can either read from it or issue an ioctl to > have further informations on the event. > > Marco -- Randall R. Stewart randall@stewart.chicago.il.us or rrs@cisco.com 815-342-5222 (cell) 815-477-2127 (work) From owner-seamoby@diameter.org Thu May 17 07:29: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 HAA13819 for ; Thu, 17 May 2001 07:29:35 -0400 (EDT) Received: (qmail 17732 invoked by alias); 17 May 2001 11:16:12 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 17726 invoked by uid 200); 17 May 2001 11:16:12 -0000 Received: (qmail 17721 invoked from network); 17 May 2001 11:16:10 -0000 Received: from user196.64.37.247.dsli.com (HELO stewart.chicago.il.us) (root@64.37.247.196) by c900656-a.plstn1.sfba.home.com with SMTP; 17 May 2001 11:16:10 -0000 Received: from stewart.chicago.il.us (IDENT:randall@stewartlin [10.1.1.1]) by stewart.chicago.il.us (8.11.0/8.11.0) with ESMTP id f4HBQ0h08952; Thu, 17 May 2001 06:26:01 -0500 Message-ID: <3B03B548.4E2BB0A8@stewart.chicago.il.us> Date: Thu, 17 May 2001 06:26:00 -0500 From: "Randall R. Stewart" X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.17-14 i686) X-Accept-Language: en MIME-Version: 1.0 To: Kulwinder Atwal CC: seamoby@diameter.org Subject: Re: [seamoby] An API issue References: <6833D86F1B05CA4FBAB3C73DD98BD8B95F7F62@NEPTUNE.zucotto.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Kulwinder Atwal wrote: > > > -----Original Message----- > > From: Randall R. Stewart [mailto:randall@stewart.chicago.il.us] > > Sent: Wednesday, May 16, 2001 3:22 PM > > To: seamoby@diameter.org > > Subject: [seamoby] An API issue > > > > > > Dear All: > > > > I have a problem and was wondering if anyone else > > has encountered this... > > > > This may be the wrong place to take this issue Pat, if it > > is, please redirect me.. > > > > Here is the jest of the problem. I have a wireless card > > driver (it can be any type you can imagine.. GSM, 802.11 > > even blue-tooth...). > > > > It gets a signal that an event has transpired > > i.e. Association fell apart or came up, i.e. I can now reach > > a AR or I can no longer reach an AR or maybe some other trigger > > type event of interest. This is the ole Layer-2 > > trigger that everyone talks about.... > > > > Now HOW do I get it up to layer 3? > > > > This seems like a real naive question I know... but when you > > start digging in to at least most unixy stacks, you have > > a layer 2 driver servicing the card (or is it layer 1:>), > > its interfaces to upper layers are: > > > > A) ioctl... user requests/response model > > B) packet arrival -> submit to ether_input() > > C) packet sending -> output routine is called. > > > > D) Interrupts (linux disable_irq/enable_irq) > > Hardware Interrupt -> Interrupt Handler -> Interrupt Service Routine -> > Proxy -> Thread > Huh? This is not the question... I already have the interupt that tells me an event happened on the card. My question is directed at how we transfer it in a standard way to an event/layer-2 trigger. That way all cards could play nice and present a standard layer-2 trigger mechanism... R -- Randall R. Stewart randall@stewart.chicago.il.us or rrs@cisco.com 815-342-5222 (cell) 815-477-2127 (work) From owner-seamoby@diameter.org Thu May 17 11:03: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 LAA19324 for ; Thu, 17 May 2001 11:03:38 -0400 (EDT) Received: (qmail 19729 invoked by alias); 17 May 2001 14:51:24 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 19723 invoked by uid 200); 17 May 2001 14:51:23 -0000 Received: (qmail 19718 invoked from network); 17 May 2001 14:51:21 -0000 Received: from user196.64.37.247.dsli.com (HELO stewart.chicago.il.us) (root@64.37.247.196) by c900656-a.plstn1.sfba.home.com with SMTP; 17 May 2001 14:51:21 -0000 Received: from stewart.chicago.il.us (IDENT:randall@stewartlin [10.1.1.1]) by stewart.chicago.il.us (8.11.0/8.11.0) with ESMTP id f4HF17h09627; Thu, 17 May 2001 10:01:10 -0500 Message-ID: <3B03E7B2.5430990C@stewart.chicago.il.us> Date: Thu, 17 May 2001 10:01:06 -0500 From: "Randall R. Stewart" X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.17-14 i686) X-Accept-Language: en MIME-Version: 1.0 To: kempf CC: seamoby@diameter.org Subject: Re: [seamoby] An API issue References: <200105170101.SAA24292@heliopolis.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit kempf wrote: > > Randy, > > >This seems like a real naive question I know... but when you > >start digging in to at least most unixy stacks, you have > >a layer 2 driver servicing the card (or is it layer 1:>), > >its interfaces to upper layers are: > > > >A) ioctl... user requests/response model > >B) packet arrival -> submit to ether_input() > >C) packet sending -> output routine is called. > > > > > >Now I can use A if you want to have the interested upper > >layer poll every N interval and ask... hey what is your > >current status? But this means that N becomes the granularity > >of when you might want to handoff/do something. This could > >be a real problem for real time services... > > > > How about a thread that blocks on the ioctl() and returns when > the Layer 2 event occurs? After all, this is 2001 and while > we may not have cities on the moon and spaceships to Juipiter, > most operating systems now support multithreading at the > user level. > > jak Jim: I have did a bit more digging and your naive approach sounds good at first glance... until you start to dig in to the stacks.. at least a BSD stack. I would imagine that the sun streams based drivers are pretty much the same.. ioctl()'s (which become a put down on to the stream if I remember sunism's/att's stream code) call down the stack with a data pointer attached. When directed down to the driver level, the driver not being aware of sockets, just copies back to the user space pointer. For a streams like thing I would imagine the driver gets (in the end) a message asking for something with a reply address/stream. It then replies to that stream. If one wants to block for the ioctl case it is pretty hard since there is a fundamental seperation of the blocking type things i.e. a socket and the driver level. Sure I can hack up this level.. but that is very in-elegant. I bet if you dig into the sun code you will find similar traits.. The drivers live at a boundary below the blocking/non-blocking wakeup level.. It is well suited for two types of things: 1) Passing messages in/out to the wire 2) Answering requests (i.e. ioctl's) right away. which is what a network driver needs to do in general. By changing this layering you get all sorts of fun.. So far if I am going to hack this in it is probably better to take Marco's suggestion and add a pseudo device... reason being is that most net drivers don't have a appearance in the /dev directory or any place to open them up :< A pseudo device could solve this... but it is still not the general purpose solution I would like to see.. I think a more elegant and general approach would be to design an new socket type. Add a new ether type and design general purpose data structures that could be passed up from the driver(s). Then you would end with a very generic solution that can be blocked/selected for read blocking or whatever... Mores to the point you would have a standard data interface for Layer-2 triggers... R -- Randall R. Stewart randall@stewart.chicago.il.us or rrs@cisco.com 815-342-5222 (cell) 815-477-2127 (work) From owner-seamoby@diameter.org Thu May 17 15:22: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 PAA25277 for ; Thu, 17 May 2001 15:22:41 -0400 (EDT) Received: (qmail 22434 invoked by alias); 17 May 2001 19:10:40 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 22428 invoked by uid 200); 17 May 2001 19:10:39 -0000 Received: (qmail 22423 invoked from network); 17 May 2001 19:10:37 -0000 Received: from unknown (HELO NEPTUNE.zucotto.com) (216.95.209.154) by c900656-a.plstn1.sfba.home.com with SMTP; 17 May 2001 19:10:37 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Thu, 17 May 2001 15:21:30 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F7F68@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Randall R. Stewart'" , kempf Cc: seamoby@diameter.org Subject: RE: [seamoby] An API issue Date: Thu, 17 May 2001 15:21:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk > -----Original Message----- > From: Randall R. Stewart [mailto:randall@stewart.chicago.il.us] > Sent: Thursday, May 17, 2001 11:01 AM > To: kempf > Cc: seamoby@diameter.org > Subject: Re: [seamoby] An API issue > > > kempf wrote: > > > > Randy, > > > I think a more elegant and general approach would be to > design an new socket type. Add a new ether type and > design general purpose data structures that could > be passed up from the driver(s). Then you would > end with a very generic solution that can be blocked/selected > for read blocking or whatever... > > Mores to the point you would have a standard data > interface for Layer-2 triggers... I not sure what you were asking. I agree, a API for layer-2 Triggers is definitely something that needs to be worked on. - Kulwinder. > > R > > > -- > Randall R. Stewart > randall@stewart.chicago.il.us or rrs@cisco.com > 815-342-5222 (cell) 815-477-2127 (work) > From owner-seamoby@diameter.org Thu May 17 16:32: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 QAA26492 for ; Thu, 17 May 2001 16:32:15 -0400 (EDT) Received: (qmail 23495 invoked by alias); 17 May 2001 20:20:16 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 23489 invoked by uid 200); 17 May 2001 20:20:15 -0000 Received: (qmail 23484 invoked from network); 17 May 2001 20:20:12 -0000 Received: from ftpbox.mot.com (129.188.136.101) by c900656-a.plstn1.sfba.home.com with SMTP; 17 May 2001 20:20:12 -0000 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id NAA27377 for ; Thu, 17 May 2001 13:31:08 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id NAA14242 for ; Thu, 17 May 2001 13:31:07 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Thu, 17 May 2001 15:31:07 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B1B7BD0@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'john.loughney@nokia.com'" , seamoby@diameter.org Subject: [seamoby] MM requirements (was: IRTF mm problem statement) Date: Thu, 17 May 2001 15:30:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Also, this brings up another point. The current SeaMoby MM Problem statement will probably not be re-issued as NOONE seems to care ... MN>> Sorry for the late reply, I was on vacation :) Well, what is the status?? until a few days ago, it was not clear whether is on the charter or not, I am interested in the requirement phase, as I said earlier, and I am sure many others are, but that does not mean I have to drop everything and respond on every rant that goes on here. It would be nice to start from a technical text (no offense to you and my appologies for my ignorance) rather than from rants. Let us know what the status is? Is problem statement done? the last thing I heard about the requirement was whether it is called CNP or not? do we want to start from CNP? regards, Madjid From owner-seamoby@diameter.org Thu May 17 16:34: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 QAA26517 for ; Thu, 17 May 2001 16:34:40 -0400 (EDT) Received: (qmail 23957 invoked by alias); 17 May 2001 20:22:48 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 23949 invoked by uid 200); 17 May 2001 20:22:48 -0000 Received: (qmail 23933 invoked from network); 17 May 2001 20:22:44 -0000 Received: from ftpbox.mot.com (129.188.136.101) by c900656-a.plstn1.sfba.home.com with SMTP; 17 May 2001 20:22:44 -0000 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id NAA00176 for ; Thu, 17 May 2001 13:33:40 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id NAA16878 for ; Thu, 17 May 2001 13:33:39 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19) id ; Thu, 17 May 2001 15:33:38 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B1B7BD3@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'john.loughney@nokia.com'" , PRoberts@MEGISTO.com, seamoby@diameter.org Subject: RE: [seamoby] work that "needs" to get done and where Date: Thu, 17 May 2001 15:33:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk I am interested. Madjid -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Thursday, May 03, 2001 5:15 AM To: PRoberts@MEGISTO.com; seamoby@diameter.org Subject: RE: [seamoby] work that "needs" to get done and where Hi all, > The second was for the seamoby mm design team to come up with a set of > things which they believe an mm protocol MUST do and throw it > over to MIP to see whether the set of protocols in MIP can do those > things. I haven't seen much activity on this. John sent out an email > asking for volunteers recently I believe - don't know whether he got any > response. I've had one person respond "maybe, if it is about something that I want to do ..." and one person who has said that they are considering writing an individual submission. So, can I ask again? Who is interested in this work? If this is something of interest, let's crank up the MM Design Team. I might even be able to host some conference calls. If this work is not of interest, let's drop it. John From owner-seamoby@diameter.org Thu May 17 16:41: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 QAA26700 for ; Thu, 17 May 2001 16:41:30 -0400 (EDT) Received: (qmail 24532 invoked by alias); 17 May 2001 20:29:33 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 24526 invoked by uid 200); 17 May 2001 20:29:32 -0000 Received: (qmail 24519 invoked by uid 500); 17 May 2001 20:29:29 -0000 Date: Thu, 17 May 2001 13:29:29 -0700 From: Pat Calhoun To: Nakhjiri Madjid-MNAKHJI1 Cc: "'john.loughney@nokia.com'" , seamoby@diameter.org Subject: Re: [seamoby] MM requirements (was: IRTF mm problem statement) Message-ID: <20010517132929.I1870@charizard.diameter.org> Mail-Followup-To: Nakhjiri Madjid-MNAKHJI1 , "'john.loughney@nokia.com'" , seamoby@diameter.org References: <35DBB8B7AC89D4118E98009027B1009B1B7BD0@IL27EXM10.cig.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <35DBB8B7AC89D4118E98009027B1009B1B7BD0@IL27EXM10.cig.mot.com>; from Madjid.Nakhjiri@motorola.com on Thu, May 17, 2001 at 03:30:55PM -0500 Sender: owner-seamoby@diameter.org Precedence: bulk On Thu, May 17, 2001 at 03:30:55PM -0500, Nakhjiri Madjid-MNAKHJI1 wrote: > > Also, this brings up another point. The current SeaMoby MM Problem > statement will probably not be re-issued as NOONE seems to care ... > > MN>> Sorry for the late reply, I was on vacation :) > Well, what is the status?? until a few days ago, it was not > clear whether is on the charter or not, I am interested in the > requirement phase, as I said earlier, and I am sure many others are, > but that does not mean I have to drop everything and respond on every > rant that goes on here. It would be nice to start from a technical text > (no offense to you and my appologies for my ignorance) rather than from > rants. > Let us know what the status is? Is problem statement done? > the last thing I heard about the requirement was whether it is > called CNP or not? do we want to start from CNP? The MM work was split into three items. Please see the minutes from the Minn meeting for more detaiil (really don't want to re-hash it all over again). As far as the micro-mobility work is concerned, an internet-draft was put together by Phil Roberts (see seamoby archives for info), and this has been passed onto the IRTF routing chair. Now, the other item you seem to be refering to, which is what I call Handoff Candidate Discovery (for lack of better terms) is in the new proposed charter (please see the proposed charter I sent last week). So the work will occur, but I am waiting for IESG OK. Thanks, PatC From owner-seamoby@diameter.org Thu May 17 21:49: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 VAA01127 for ; Thu, 17 May 2001 21:49:00 -0400 (EDT) Received: (qmail 26266 invoked by alias); 18 May 2001 01:36:48 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 26260 invoked by uid 200); 18 May 2001 01:36:48 -0000 Received: (qmail 26255 invoked from network); 18 May 2001 01:36:46 -0000 Received: from www.bit-net.com (HELO mail.users.bit-net.com) (208.146.132.4) by c900656-a.plstn1.sfba.home.com with SMTP; 18 May 2001 01:36:46 -0000 Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA14200; Thu, 17 May 2001 21:47:35 -0400 Date: Thu, 17 May 2001 21:47:35 -0400 (EDT) From: Jim Bound To: "Randall R. Stewart" Cc: Marco Molteni , seamoby@diameter.org Subject: Re: [seamoby] An API issue In-Reply-To: <3B03B4C5.123ED6BE@stewart.chicago.il.us> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk Randy, This is out of scope for the IETF. you and I both know a real OS kernel programmer will use the inherent features available to them on their OS net subsystem stack implementation so they get the best peformance relative to their stacks main business. For me for real paying customers and in a real product I would send it from the driver to my Teclo/Wireless proprietary input queues that would heed that packet prior to ipintrq from enet et al. I would do that by providing the L2 context its own thread (not same as ipintrq) and make sure I could run it on at least 8 processors using the memory sharing capabilities via SMP on my companys machines. The last thing we need for seamoby type operations is a PF_ROUTE socket or user space IOCTL listening to a device driver. With everything else we have to fix we learn from pilc wg we should not add yet more pain to low bandwidth / high latency connections. Someone should just do it in freebsd or netbsd and see what happens. But yet another API from the IETF...not a good idea IMO. /jim On Thu, 17 May 2001, Randall R. Stewart wrote: > Marco: > > It is not that I could not hack something together there > are several possiblities. And I don't think I would > approach it from the aspect of a pseudo driver since > I already have a driver. With most e-net type drivers you don't > read directly from... this could be added... but I was > just hoping (in vain I see from most of the email) that > we might all have a standard way to approach the > problem so in the end everyone's card(s) would work and > play nice together... > > R > Marco Molteni wrote: > > > > On 2001-05-16, Randall R. Stewart wrote: > > > > Hi Randall, > > > > [..] > > > > > Here is the jest of the problem. I have a wireless card driver (it > > > can be any type you can imagine.. GSM, 802.11 even blue-tooth...). > > > > > > It gets a signal that an event has transpired i.e. Association fell > > > apart or came up, i.e. I can now reach a AR or I can no longer reach > > > an AR or maybe some other trigger type event of interest. This is > > > the ole Layer-2 trigger that everyone talks about.... > > > > > > Now HOW do I get it up to layer 3? > > > > > > This seems like a real naive question I know... but when you start > > > digging in to at least most unixy stacks, you have a layer 2 driver > > > servicing the card (or is it layer 1:>), its interfaces to upper > > > layers are: > > > > > > A) ioctl... user requests/response model > > > B) packet arrival -> submit to ether_input() > > > C) packet sending -> output routine is called. > > > > [..] > > > > I have a suggestion for the kernel -> userland case: write a pseudo > > device driver. > > > > Usage scenarios: > > > > 1. synchronous, but not polling: > > you can select(2) or poll(2) a descriptor bound to the device, and have > > the device make the descriptor ready for reading when an event occurs. > > > > 2. asynchronous: > > have the pseudo device send a signal to the process who opened it when > > an event occurs. > > > > in both scenarios then you can either read from it or issue an ioctl to > > have further informations on the event. > > > > Marco > > -- > Randall R. Stewart > randall@stewart.chicago.il.us or rrs@cisco.com > 815-342-5222 (cell) 815-477-2127 (work) > From owner-seamoby@diameter.org Thu May 17 22:56: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 WAA03748 for ; Thu, 17 May 2001 22:56:06 -0400 (EDT) Received: (qmail 26851 invoked by alias); 18 May 2001 02:43:58 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 26845 invoked by uid 200); 18 May 2001 02:43:58 -0000 Received: (qmail 26840 invoked from network); 18 May 2001 02:43:57 -0000 Received: from mercury.sun.com (192.9.25.1) by c900656-a.plstn1.sfba.home.com with SMTP; 18 May 2001 02:43:57 -0000 Received: from heliopolis.eng.sun.com ([152.70.1.39]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA24476; Thu, 17 May 2001 19:54:54 -0700 (PDT) Received: from awe171-106 (awe195-62.AWE.Sun.COM [192.29.195.62]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id TAA26510; Thu, 17 May 2001 19:54:52 -0700 (PDT) Message-Id: <200105180254.TAA26510@heliopolis.eng.sun.com> Date: Thu, 17 May 2001 18:46:59 -0700 (PDT) From: kempf Reply-To: kempf Subject: Re: [seamoby] An API issue To: James.Kempf@Sun.COM, randall@stewart.chicago.il.us Cc: seamoby@diameter.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: RCvG5GLzty0tPH+rv3dxAw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 i86pc i386 Sender: owner-seamoby@diameter.org Precedence: bulk >Jim: > >I have did a bit more digging and your naive approach sounds >good at first glance... until you start to dig in to the stacks.. >at least a BSD stack. I would imagine that the sun streams based >drivers are pretty much the same.. > >ioctl()'s (which become a put down on to the stream if I >remember sunism's/att's stream code) call down >the stack with a data pointer attached. When directed >down to the driver level, the driver not being aware of >sockets, just copies back to the user space pointer. For >a streams like thing I would imagine the driver gets (in >the end) a message asking for something with a reply >address/stream. It then replies to that stream. If one >wants to block for the ioctl case it is pretty hard since >there is a fundamental seperation of the blocking type >things i.e. a socket and the driver level. Sure I can >hack up this level.. but that is very in-elegant. I bet >if you dig into the sun code you will find similar traits.. > >The drivers live at a boundary below the blocking/non-blocking >wakeup level.. It is well suited for two types of things: > >1) Passing messages in/out to the wire >2) Answering requests (i.e. ioctl's) right away. > >which is what a network driver needs to do in general. > >By changing this layering you get all sorts of fun.. > Why do you have to do the ioctl on the socket? It you are looking for an L2 trigger, you should be getting it directly from the driver, so the ioctl should be done on a file descriptor opened directly on the device. Or am I missing something? Of course, if you don't like threads in the first place, there's no point in doing it. I happen to like threads, so that's probably how I would do it. >So far if I am going to hack this in it is probably better >to take Marco's suggestion and add a pseudo device... reason >being is that most net drivers don't have a appearance in >the /dev directory or any place to open them up :< > >A pseudo device could solve this... but it is still not >the general purpose solution I would like to see.. > That would work. It's putting in a new device to handle the ioctl, instead of directly using the interface. May have some implementation advantages. >I think a more elegant and general approach would be to >design an new socket type. Add a new ether type and >design general purpose data structures that could >be passed up from the driver(s). Then you would >end with a very generic solution that can be blocked/selected >for read blocking or whatever... > >Mores to the point you would have a standard data >interface for Layer-2 triggers... > Hmm, good point. There's currently no way to do out of band signalling on SOCK_DGRAM or SOCK_STREAM sockets. Maybe you've come up with something for SOCK_SCTP? jak From owner-seamoby@diameter.org Fri May 18 02:34: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 CAA17886 for ; Fri, 18 May 2001 02:34:10 -0400 (EDT) Received: (qmail 28302 invoked by alias); 18 May 2001 06:22:30 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 28296 invoked by uid 200); 18 May 2001 06:22:29 -0000 Received: (qmail 28291 invoked from network); 18 May 2001 06:22:27 -0000 Received: from mgw-x2.nokia.com (131.228.20.22) by c900656-a.plstn1.sfba.home.com with SMTP; 18 May 2001 06:22:27 -0000 Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f4I6XZm14409 for ; Fri, 18 May 2001 09:33:35 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 18 May 2001 09:33:20 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Fri, 18 May 2001 09:33:20 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680AF95@eseis04nok> From: john.loughney@nokia.com To: Madjid.Nakhjiri@motorola.com, seamoby@diameter.org Subject: [seamoby] RE: MM requirements (was: IRTF mm problem statement) Date: Fri, 18 May 2001 09:33:18 +0300 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 Madjid, > Well, what is the status?? until a few days ago, it was not > clear whether is on the charter or not. The current problem statement: http://www.ietf.org/internet-drafts/draft-ietf-seamoby-mm-problem-01.txt Has recieved no comments on it since before the 50th IETF meeting. Should we go to last call, or should we let it die? I have asked this several times, and noone has given me an answer. The proposed SeaMoby Charter has this item in it: Jul 01 Submit Handoff Candidate Discovery Problem Statement This topic is seperate from the above problem statement. Now, does anyone have any preferences on how to procede? John From owner-seamoby@diameter.org Fri May 18 08:47: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 IAA25118 for ; Fri, 18 May 2001 08:47:28 -0400 (EDT) Received: (qmail 29651 invoked by alias); 18 May 2001 12:35:03 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 29644 invoked by uid 200); 18 May 2001 12:35:03 -0000 Received: (qmail 29625 invoked from network); 18 May 2001 12:34:58 -0000 Received: from user196.64.37.247.dsli.com (HELO stewart.chicago.il.us) (root@64.37.247.196) by c900656-a.plstn1.sfba.home.com with SMTP; 18 May 2001 12:34:58 -0000 Received: from stewart.chicago.il.us (IDENT:randall@stewartlin [10.1.1.1]) by stewart.chicago.il.us (8.11.0/8.11.0) with ESMTP id f4IC4Yh12842; Fri, 18 May 2001 07:04:35 -0500 Message-ID: <3B050FD2.D09495D7@stewart.chicago.il.us> Date: Fri, 18 May 2001 07:04:34 -0500 From: "Randall R. Stewart" X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.17-14 i686) X-Accept-Language: en MIME-Version: 1.0 To: kempf CC: seamoby@diameter.org Subject: Re: [seamoby] An API issue References: <200105180254.TAA26510@heliopolis.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Answer below... kempf wrote: > > >Jim: > > > >I have did a bit more digging and your naive approach sounds > >good at first glance... until you start to dig in to the stacks.. > >at least a BSD stack. I would imagine that the sun streams based > >drivers are pretty much the same.. > > > >ioctl()'s (which become a put down on to the stream if I > >remember sunism's/att's stream code) call down > >the stack with a data pointer attached. When directed > >down to the driver level, the driver not being aware of > >sockets, just copies back to the user space pointer. For > >a streams like thing I would imagine the driver gets (in > >the end) a message asking for something with a reply > >address/stream. It then replies to that stream. If one > >wants to block for the ioctl case it is pretty hard since > >there is a fundamental seperation of the blocking type > >things i.e. a socket and the driver level. Sure I can > >hack up this level.. but that is very in-elegant. I bet > >if you dig into the sun code you will find similar traits.. > > > >The drivers live at a boundary below the blocking/non-blocking > >wakeup level.. It is well suited for two types of things: > > > >1) Passing messages in/out to the wire > >2) Answering requests (i.e. ioctl's) right away. > > > >which is what a network driver needs to do in general. > > > >By changing this layering you get all sorts of fun.. > > > > Why do you have to do the ioctl on the socket? It you are looking for > an L2 trigger, you should be getting it directly from the driver, so > the ioctl should be done on a file descriptor opened directly on > the device. Or am I missing something? > Well, network devices often times do NOT have an appearance that you can open... i.e. there is no /dev/ep0 or /dev/dc0 or /dev/sis0 in any of my bsd machines.. You can find them with ioctl's and such and some other calls.. but they have no read/write service routine... > Of course, if you don't like threads in the first place, there's > no point in doing it. I happen to like threads, so that's probably > how I would do it. > > >So far if I am going to hack this in it is probably better > >to take Marco's suggestion and add a pseudo device... reason > >being is that most net drivers don't have a appearance in > >the /dev directory or any place to open them up :< > > > >A pseudo device could solve this... but it is still not > >the general purpose solution I would like to see.. > > > > That would work. It's putting in a new device to handle the ioctl, > instead of directly using the interface. May have some implementation > advantages. > Doing Marco's suggestion does give you the read/write hooks... > >I think a more elegant and general approach would be to > >design an new socket type. Add a new ether type and > >design general purpose data structures that could > >be passed up from the driver(s). Then you would > >end with a very generic solution that can be blocked/selected > >for read blocking or whatever... > > > >Mores to the point you would have a standard data > >interface for Layer-2 triggers... > > > > Hmm, good point. There's currently no way to do out of band > signalling on SOCK_DGRAM or SOCK_STREAM sockets. Maybe you've come > up with something for SOCK_SCTP? > No, SCTP has nothing to do with this... this is more in-line with AF_ROUTE socket... after all its a routing event that is transpiring.. sort-of :/ R -- Randall R. Stewart randall@stewart.chicago.il.us or rrs@cisco.com 815-342-5222 (cell) 815-477-2127 (work) From owner-seamoby@diameter.org Fri May 18 09:41: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 JAA26790 for ; Fri, 18 May 2001 09:41:27 -0400 (EDT) Received: (qmail 30348 invoked by alias); 18 May 2001 13:29:21 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 30342 invoked by uid 200); 18 May 2001 13:29:20 -0000 Received: (qmail 30335 invoked by uid 500); 18 May 2001 13:29:17 -0000 Date: Fri, 18 May 2001 06:29:17 -0700 From: Pat Calhoun To: john.loughney@nokia.com Cc: Madjid.Nakhjiri@motorola.com, seamoby@diameter.org Subject: Re: [seamoby] RE: MM requirements (was: IRTF mm problem statement) Message-ID: <20010518062917.N1870@charizard.diameter.org> Mail-Followup-To: john.loughney@nokia.com, Madjid.Nakhjiri@motorola.com, seamoby@diameter.org References: <01D91AFB08B6D211BFD00008C7EABAE10680AF95@eseis04nok> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01D91AFB08B6D211BFD00008C7EABAE10680AF95@eseis04nok>; from john.loughney@nokia.com on Fri, May 18, 2001 at 09:33:18AM +0300 Sender: owner-seamoby@diameter.org Precedence: bulk On Fri, May 18, 2001 at 09:33:18AM +0300, john.loughney@nokia.com wrote: > The current problem statement: > > http://www.ietf.org/internet-drafts/draft-ietf-seamoby-mm-problem-01.txt > > Has recieved no comments on it since before the 50th IETF meeting. > Should we go to last call, or should we let it die? I have > asked this several times, and noone has given me an answer. My appologies. The document was very useful in the creation of the new charter, and the work that moved to the IRTF, however it cannot move forward as it is. > The proposed SeaMoby Charter has this item in it: > > Jul 01 Submit Handoff Candidate Discovery Problem Statement > > This topic is seperate from the above problem statement. > > Now, does anyone have any preferences on how to procede? I would like for the work to begin, but was waiting for IESG approval. I have heard that there are really good chances that the charter will be approved, so we could probably start working on this work item. Perhaps one way to start is to extract from the MM problem statement all of the text that has to do with the above, and create a new problem statement. Would you be wiling to start the effort given that you already have the nroff source of the MM problem statement? Thanks, PatC From owner-seamoby@diameter.org Fri May 18 12:33:01 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 MAA00551 for ; Fri, 18 May 2001 12:33:00 -0400 (EDT) Received: (qmail 31400 invoked by alias); 18 May 2001 16:20:34 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 31394 invoked by uid 200); 18 May 2001 16:20:34 -0000 Received: (qmail 31389 invoked from network); 18 May 2001 16:20:30 -0000 Received: from motgate2.mot.com (136.182.1.10) by c900656-a.plstn1.sfba.home.com with SMTP; 18 May 2001 16:20:30 -0000 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id JAA05420 for ; Fri, 18 May 2001 09:31:29 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id JAA00950 for ; Fri, 18 May 2001 09:31:28 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Fri, 18 May 2001 11:31:29 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B1B7BD7@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Jukka Manner'" , Hamid Syed Cc: "'James Kempf'" , seamoby@diameter.org Subject: RE: Wireless Terminology Draft( was: Re: [seamoby] Seamoby Charte r Last Call) Date: Fri, 18 May 2001 11:30:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-seamoby@diameter.org Precedence: bulk Jukka, Thanks for taking charge on this. Did you do a diff on your definitions and CT problem statement draft? Since you were intimately involved with CT PS draft, I assume you did that. I think we did a good job of defining CT related terminology, but I don't know how it differred from MM or Paging terminology, it would be nice to do a diff with those as well to have a WG wide common terminology draft. Thanks again, Madjid -----Original Message----- From: Jukka Manner [mailto:jmanner@cs.Helsinki.FI] Sent: Tuesday, May 15, 2001 1:25 AM To: Hamid Syed Cc: 'James Kempf'; seamoby@diameter.org Subject: RE: Wireless Terminology Draft( was: Re: [seamoby] Seamoby Charter Last Call) Hamid, Thank you for suggesting it. The draft was originally meant to support the work in Seamoby, but it would be an even better idea to make it a more thorough document for use in more or less all work relating to mobile and wireless environments, including Seamoby, Mobile-IP, and possibly MANET. I would be happy to continue the work on the terminology taking as basis the mentioned draft. BR, Jukka On Mon, 14 May 2001, Hamid Syed wrote: > Hello james, > > A draft was submitted to seamoby early this year that attempted to capture > the wireless terminology. her eis the link: > http://search.ietf.org/internet-drafts/draft-manner-seamoby-terms-01.txt > > br > > -Hamid > > > -----Original Message----- > > From: James Kempf [SMTP:James.Kempf@Sun.COM] > > Sent: Monday, May 14, 2001 1:47 PM > > To: seamoby@diameter.org > > Subject: Wireless Terminology Draft( was: Re: [seamoby] Seamoby > > Charter Last Call) > > > > > > ------------- Begin Forwarded Message ------------- > > > > Date: Mon, 14 May 2001 10:43:47 -0700 (PDT) > > From: James Kempf > > Subject: Re: [seamoby] Seamoby Charter Last Call > > To: James.Kempf@sun.com, charliep@iprg.nokia.com > > Content-MD5: 6F7Vl9kYVVbqr66TeEQyRw== > > > > Hi Charlie, > > > > > > >> Maybe we need a terminology draft, or at least, define this term > > >> somewhere so that it can be referred to. I'm suprised nobody > > >> has done a generalized terminology draft for wireless terms before in > > the MIP > > >> group. > > > > > >RFC 2002 does start off with a long list of terminology. > > > > > >It is questionable whether any specific wireless terms are > > >needed for a protocol running over IP. What is needed is > > >a list of useful terms. For instance, one might care about > > >error rate or bandwidth even if the medium were not wireless. > > >I don't think that chip rate, for instance, should be part > > >of the [seamoby] terminology list. > > > > > > > Actually, there are plenty of wireless terms that need definition. > > Access point, handoff (or handover IETF should select which one > > it wants to use), context transfer, paging, etc. etc. > > > > >Do you think that there are terms which SHOULD have been defined > > >for RFC 2002? If so, now would be a good time to mention them > > >before RFC 2002bis goes to the RFC editor's desk. > > > > > > > No, I think they have wider applicability. More and more wireless > > stuff is going on. There are now two working groups associated > > with wireless, and others that have a big wireless component. I think > > having a > > terminology draft that collects all terminology that could be referred to > > by > > drafts would be a benefit. > > > > jak > > > > > > > > ------------- End Forwarded Message ------------- > > > > > From owner-seamoby@diameter.org Fri May 18 12:47: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 MAA01033 for ; Fri, 18 May 2001 12:47:57 -0400 (EDT) Received: (qmail 31878 invoked by alias); 18 May 2001 16:35:24 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 31872 invoked by uid 200); 18 May 2001 16:35:24 -0000 Received: (qmail 31867 invoked from network); 18 May 2001 16:35:20 -0000 Received: from porsta.cs.helsinki.fi (root@128.214.48.124) by c900656-a.plstn1.sfba.home.com with SMTP; 18 May 2001 16:35:20 -0000 Received: from melkinpaasi.cs.Helsinki.FI (IDENT:jmanner@melkinpaasi.cs.Helsinki.FI [128.214.10.13]) by porsta.cs.Helsinki.FI (8.11.3/8.11.3) with ESMTP id f4IGjwm17249; Fri, 18 May 2001 19:45:59 +0300 Date: Fri, 18 May 2001 19:45:54 +0300 (EEST) From: Jukka Manner To: Nakhjiri Madjid-MNAKHJI1 cc: Hamid Syed , "'James Kempf'" , Subject: RE: Wireless Terminology Draft( was: Re: [seamoby] Seamoby Charte r Last Call) In-Reply-To: <35DBB8B7AC89D4118E98009027B1009B1B7BD7@IL27EXM10.cig.mot.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk Hi, quick answers inline (I'm off to have a weekend break for once...:) Have a nice weekend all of you, Jukka On Fri, 18 May 2001, Nakhjiri Madjid-MNAKHJI1 wrote: > Jukka, > > Thanks for taking charge on this. Did you do a diff on your > definitions and CT problem statement draft? Since you were > intimately involved with CT PS draft, I assume you did that. Actually, the terminology in the CT draft was taken from the terminology draft. Some wording was changed, if I remember correctly, in the CT draft, but the basic definitions were the same. > I think we did a good job of defining CT related terminology, > but I don't know how it differred from MM or Paging terminology, > it would be nice to do a diff with those as well to have a WG > wide common terminology draft. The MM team used "our" CT terms and added some new ones; those could be added to a new terminology draft. The Paging team had only a few terms of "their" own, but those could be added as well. > > Thanks again, > Madjid > > -----Original Message----- > From: Jukka Manner [mailto:jmanner@cs.Helsinki.FI] > Sent: Tuesday, May 15, 2001 1:25 AM > To: Hamid Syed > Cc: 'James Kempf'; seamoby@diameter.org > Subject: RE: Wireless Terminology Draft( was: Re: [seamoby] Seamoby > Charter Last Call) > > > > Hamid, > > Thank you for suggesting it. The draft was originally meant to > support the work in Seamoby, but it would be an even better idea to make it > a more thorough document for use in more or less all work relating to mobile > and > wireless environments, including Seamoby, Mobile-IP, and possibly MANET. > > I would be happy to continue the work on the terminology taking as > basis > the mentioned draft. > > BR, > > Jukka > > On Mon, 14 May 2001, Hamid Syed wrote: > > > Hello james, > > > > A draft was submitted to seamoby early this year that attempted to capture > > the wireless terminology. her eis the link: > > http://search.ietf.org/internet-drafts/draft-manner-seamoby-terms-01.txt > > > > br > > > > -Hamid > > > > > -----Original Message----- > > > From: James Kempf [SMTP:James.Kempf@Sun.COM] > > > Sent: Monday, May 14, 2001 1:47 PM > > > To: seamoby@diameter.org > > > Subject: Wireless Terminology Draft( was: Re: [seamoby] Seamoby > > > Charter Last Call) > > > > > > > > > ------------- Begin Forwarded Message ------------- > > > > > > Date: Mon, 14 May 2001 10:43:47 -0700 (PDT) > > > From: James Kempf > > > Subject: Re: [seamoby] Seamoby Charter Last Call > > > To: James.Kempf@sun.com, charliep@iprg.nokia.com > > > Content-MD5: 6F7Vl9kYVVbqr66TeEQyRw== > > > > > > Hi Charlie, > > > > > > > > > >> Maybe we need a terminology draft, or at least, define this term > > > >> somewhere so that it can be referred to. I'm suprised nobody > > > >> has done a generalized terminology draft for wireless terms before in > > > the MIP > > > >> group. > > > > > > > >RFC 2002 does start off with a long list of terminology. > > > > > > > >It is questionable whether any specific wireless terms are > > > >needed for a protocol running over IP. What is needed is > > > >a list of useful terms. For instance, one might care about > > > >error rate or bandwidth even if the medium were not wireless. > > > >I don't think that chip rate, for instance, should be part > > > >of the [seamoby] terminology list. > > > > > > > > > > Actually, there are plenty of wireless terms that need definition. > > > Access point, handoff (or handover IETF should select which one > > > it wants to use), context transfer, paging, etc. etc. > > > > > > >Do you think that there are terms which SHOULD have been defined > > > >for RFC 2002? If so, now would be a good time to mention them > > > >before RFC 2002bis goes to the RFC editor's desk. > > > > > > > > > > No, I think they have wider applicability. More and more wireless > > > stuff is going on. There are now two working groups associated > > > with wireless, and others that have a big wireless component. I think > > > having a > > > terminology draft that collects all terminology that could be referred > to > > > by > > > drafts would be a benefit. > > > > > > jak > > > > > > > > > > > > ------------- End Forwarded Message ------------- > > > > > > > > > From owner-seamoby@diameter.org Fri May 18 13:48:38 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 NAA05614 for ; Fri, 18 May 2001 13:48:26 -0400 (EDT) Received: (qmail 32451 invoked by alias); 18 May 2001 17:32:30 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 32445 invoked by uid 200); 18 May 2001 17:32:29 -0000 Received: (qmail 32440 invoked from network); 18 May 2001 17:32:26 -0000 Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.nortelnetworks.com) (47.129.242.157) by c900656-a.plstn1.sfba.home.com with SMTP; 18 May 2001 17:32:26 -0000 Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id NAA21667; Fri, 18 May 2001 13:42:50 -0400 Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 18 May 2001 13:42:37 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 18 May 2001 13:42:40 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C12595A@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Jukka Manner'" , Nakhjiri Madjid-MNAKHJI1 , "Hamid Syed" , "'James Kempf'" Cc: seamoby Subject: RE: Wireless Terminology Draft( was: Re: [seamoby] Seamoby Charte r Last Call) Date: Fri, 18 May 2001 13:42:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DFC1.EF037FC0" 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_01C0DFC1.EF037FC0 Content-Type: text/plain; charset="ISO-8859-1" So that it is clear, the new version of the ct problem statement does not use the reference architecture of the original draft. The only terms that may seem familiar are mobile node, and access network. This was done to simplify the problem statement, and avoid some of the persistent controversy, not because there was anything wrong with the original reference architecture or nomenclature (probably yet another argument in favour of producing a nomenclature reference draft). Gary > -----Original Message----- > From: Jukka Manner [mailto:jmanner@cs.Helsinki.FI] > Sent: Friday, May 18, 2001 12:46 PM > To: Nakhjiri Madjid-MNAKHJI1 > Cc: Syed, Hamid [WDLN2:AN22:EXCH]; 'James Kempf'; seamoby > Subject: RE: Wireless Terminology Draft( was: Re: [seamoby] Seamoby > Charte r Last Call) > > > > > Hi, quick answers inline (I'm off to have a weekend > break for once...:) > > Have a nice weekend all of you, > > Jukka > > On Fri, 18 May 2001, Nakhjiri Madjid-MNAKHJI1 wrote: > > > Jukka, > > > > Thanks for taking charge on this. Did you do a diff on your > > definitions and CT problem statement draft? Since you were > > intimately involved with CT PS draft, I assume you did that. > > Actually, the terminology in the CT draft was taken > from the terminology > draft. Some wording was changed, if I remember correctly, in > the CT draft, but > the basic definitions were the same. > > > I think we did a good job of defining CT related terminology, > > but I don't know how it differred from MM or Paging terminology, > > it would be nice to do a diff with those as well to have a WG > > wide common terminology draft. > > The MM team used "our" CT terms and added some new > ones; those could be > added to a new terminology draft. The Paging team had only a > few terms of > "their" own, but those could be added as well. > > > > > Thanks again, > > Madjid > > > > -----Original Message----- > > From: Jukka Manner [mailto:jmanner@cs.Helsinki.FI] > > Sent: Tuesday, May 15, 2001 1:25 AM > > To: Hamid Syed > > Cc: 'James Kempf'; seamoby@diameter.org > > Subject: RE: Wireless Terminology Draft( was: Re: [seamoby] Seamoby > > Charter Last Call) > > > > > > > > Hamid, > > > > Thank you for suggesting it. The draft was originally meant to > > support the work in Seamoby, but it would be an even better > idea to make it > > a more thorough document for use in more or less all work > relating to mobile > > and > > wireless environments, including Seamoby, Mobile-IP, and > possibly MANET. > > > > I would be happy to continue the work on the > terminology taking as > > basis > > the mentioned draft. > > > > BR, > > > > Jukka > > > > On Mon, 14 May 2001, Hamid Syed wrote: > > > > > Hello james, > > > > > > A draft was submitted to seamoby early this year that > attempted to capture > > > the wireless terminology. her eis the link: > > > > http://search.ietf.org/internet-drafts/draft-manner-seamoby-te > rms-01.txt > > > > > > br > > > > > > -Hamid > > > > > > > -----Original Message----- > > > > From: James Kempf [SMTP:James.Kempf@Sun.COM] > > > > Sent: Monday, May 14, 2001 1:47 PM > > > > To: seamoby@diameter.org > > > > Subject: Wireless Terminology Draft( was: Re: > [seamoby] Seamoby > > > > Charter Last Call) > > > > > > > > > > > > ------------- Begin Forwarded Message ------------- > > > > > > > > Date: Mon, 14 May 2001 10:43:47 -0700 (PDT) > > > > From: James Kempf > > > > Subject: Re: [seamoby] Seamoby Charter Last Call > > > > To: James.Kempf@sun.com, charliep@iprg.nokia.com > > > > Content-MD5: 6F7Vl9kYVVbqr66TeEQyRw== > > > > > > > > Hi Charlie, > > > > > > > > > > > > >> Maybe we need a terminology draft, or at least, > define this term > > > > >> somewhere so that it can be referred to. I'm suprised nobody > > > > >> has done a generalized terminology draft for > wireless terms before in > > > > the MIP > > > > >> group. > > > > > > > > > >RFC 2002 does start off with a long list of terminology. > > > > > > > > > >It is questionable whether any specific wireless terms are > > > > >needed for a protocol running over IP. What is needed is > > > > >a list of useful terms. For instance, one might care about > > > > >error rate or bandwidth even if the medium were not wireless. > > > > >I don't think that chip rate, for instance, should be part > > > > >of the [seamoby] terminology list. > > > > > > > > > > > > > Actually, there are plenty of wireless terms that need > definition. > > > > Access point, handoff (or handover IETF should select which one > > > > it wants to use), context transfer, paging, etc. etc. > > > > > > > > >Do you think that there are terms which SHOULD have > been defined > > > > >for RFC 2002? If so, now would be a good time to mention them > > > > >before RFC 2002bis goes to the RFC editor's desk. > > > > > > > > > > > > > No, I think they have wider applicability. More and > more wireless > > > > stuff is going on. There are now two working groups associated > > > > with wireless, and others that have a big wireless > component. I think > > > > having a > > > > terminology draft that collects all terminology that > could be referred > > to > > > > by > > > > drafts would be a benefit. > > > > > > > > jak > > > > > > > > > > > > > > > > ------------- End Forwarded Message ------------- > > > > > > > > > > > > > > > ------_=_NextPart_001_01C0DFC1.EF037FC0 Content-Type: text/html; charset="ISO-8859-1" RE: Wireless Terminology Draft( was: Re: [seamoby] Seamoby Charte r Last Call)

So that it is clear, the new version of the ct problem statement
does not use the reference architecture of the original draft. The
only terms that may seem familiar are mobile node, and access network.
This was done to simplify the problem statement, and avoid some of the
persistent controversy, not because there was anything wrong with the
original reference architecture or nomenclature (probably yet another
argument in favour of producing a nomenclature reference draft).

Gary

> -----Original Message-----
> From: Jukka Manner [mailto:jmanner@cs.Helsinki.FI]
> Sent: Friday, May 18, 2001 12:46 PM
> To: Nakhjiri Madjid-MNAKHJI1
> Cc: Syed, Hamid [WDLN2:AN22:EXCH]; 'James Kempf'; seamoby
> Subject: RE: Wireless Terminology Draft( was: Re: [seamoby] Seamoby
> Charte r Last Call)
>
>
>
>
>       Hi, quick answers inline (I'm off to have a weekend
> break for once...:)
>
>       Have a nice weekend all of you,
>
>       Jukka
>
> On Fri, 18 May 2001, Nakhjiri Madjid-MNAKHJI1 wrote:
>
> > Jukka,
> >
> > Thanks for taking charge on this. Did you do a diff on your
> > definitions and CT problem statement draft? Since you were
> > intimately involved with CT PS draft, I assume you did that.
>
>       Actually, the terminology in the CT draft was taken
> from the terminology
> draft. Some wording was changed, if I remember correctly, in
> the CT draft, but
> the basic definitions were the same.
>
> > I think we did a good job of defining CT related terminology,
> > but I don't know how it differred from MM or Paging terminology,
> > it would be nice to do a diff with those as well to have a WG
> > wide common terminology draft.
>
>       The MM team used "our" CT terms and added some new
> ones; those could be
> added to a new terminology draft. The Paging team had only a
> few terms of
> "their" own, but those could be added as well.
>
> >
> > Thanks again,
> > Madjid
> >
> > -----Original Message-----
> > From: Jukka Manner [mailto:jmanner@cs.Helsinki.FI]
> > Sent: Tuesday, May 15, 2001 1:25 AM
> > To: Hamid Syed
> > Cc: 'James Kempf'; seamoby@diameter.org
> > Subject: RE: Wireless Terminology Draft( was: Re: [seamoby] Seamoby
> > Charter Last Call)
> >
> >
> >
> >     Hamid,
> >
> >     Thank you for suggesting it. The draft was originally meant to
> > support the work in Seamoby, but it would be an even better
> idea to make it
> > a more thorough document for use in more or less all work
> relating to mobile
> > and
> > wireless environments, including Seamoby, Mobile-IP, and
> possibly MANET.
> >
> >     I would be happy to continue the work on the
> terminology taking as
> > basis
> > the mentioned draft.
> >
> >     BR,
> >
> >     Jukka
> >
> > On Mon, 14 May 2001, Hamid Syed wrote:
> >
> > > Hello james,
> > >
> > > A draft was submitted to seamoby early this year that
> attempted to capture
> > > the wireless terminology. her eis the link:
> > >
> http://search.ietf.org/internet-drafts/draft-manner-seamoby-te
> rms-01.txt
> > >
> > > br
> > >
> > > -Hamid
> > >
> > > > -----Original Message-----
> > > > From:   James Kempf [SMTP:James.Kempf@Sun.COM]
> > > > Sent:   Monday, May 14, 2001 1:47 PM
> > > > To:     seamoby@diameter.org
> > > > Subject:        Wireless Terminology Draft( was: Re:
> [seamoby] Seamoby
> > > > Charter Last  Call)
> > > >
> > > >
> > > > ------------- Begin Forwarded Message -------------
> > > >
> > > > Date: Mon, 14 May 2001 10:43:47 -0700 (PDT)
> > > > From: James Kempf <James.Kempf@sun.com>
> > > > Subject: Re: [seamoby] Seamoby Charter Last Call
> > > > To: James.Kempf@sun.com, charliep@iprg.nokia.com
> > > > Content-MD5: 6F7Vl9kYVVbqr66TeEQyRw==
> > > >
> > > > Hi Charlie,
> > > >
> > > >
> > > > >> Maybe we need a terminology draft, or at least,
> define this term
> > > > >> somewhere so that it can be referred to. I'm suprised nobody
> > > > >> has done a generalized terminology draft for
> wireless terms before in
> > > > the MIP
> > > > >> group.
> > > > >
> > > > >RFC 2002 does start off with a long list of terminology.
> > > > >
> > > > >It is questionable whether any specific wireless terms are
> > > > >needed for a protocol running over IP.  What is needed is
> > > > >a list of useful terms.  For instance, one might care about
> > > > >error rate or bandwidth even if the medium were not wireless.
> > > > >I don't think that chip rate, for instance, should be part
> > > > >of the [seamoby] terminology list.
> > > > >
> > > >
> > > > Actually, there are plenty of wireless terms that need
> definition.
> > > > Access point, handoff (or handover IETF should select which one
> > > > it wants to use), context transfer, paging, etc. etc.
> > > >
> > > > >Do you think that there are terms which SHOULD have
> been defined
> > > > >for RFC 2002?  If so, now would be a good time to mention them
> > > > >before RFC 2002bis goes to the RFC editor's desk.
> > > > >
> > > >
> > > > No, I think they have wider applicability. More and
> more wireless
> > > > stuff is going on. There are now two working groups associated
> > > > with wireless, and others that have a big wireless
> component. I think
> > > > having a
> > > > terminology draft that collects all terminology that
> could be referred
> > to
> > > > by
> > > > drafts would be a benefit.
> > > >
> > > >                 jak
> > > >
> > > >
> > > >
> > > > ------------- End Forwarded Message -------------
> > > >
> > > >
> > >
> >
>
>

------_=_NextPart_001_01C0DFC1.EF037FC0-- From owner-seamoby@diameter.org Fri May 18 13:55: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 NAA07663 for ; Fri, 18 May 2001 13:55:32 -0400 (EDT) Received: (qmail 363 invoked by alias); 18 May 2001 17:40:03 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 357 invoked by uid 200); 18 May 2001 17:40:02 -0000 Received: (qmail 340 invoked from network); 18 May 2001 17:39:54 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 18 May 2001 17:39:54 -0000 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 KAA23365; Fri, 18 May 2001 10:50:13 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f4IHo8u17753; Fri, 18 May 2001 10:50:08 -0700 X-mProtect: Fri, 18 May 2001 10:50:08 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdKaVMk6; Fri, 18 May 2001 10:50:06 PDT Message-ID: <3B0560D0.3B0DDC40@iprg.nokia.com> Date: Fri, 18 May 2001 10:50:08 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Nakhjiri Madjid-MNAKHJI1 CC: "'Jukka Manner'" , Hamid Syed , "'James Kempf'" , seamoby@diameter.org, Mobile Ad Hoc IETF working group Subject: Re: Wireless Terminology Draft( was: Re: [seamoby] Seamoby Charter Last Call) References: <35DBB8B7AC89D4118E98009027B1009B1B7BD7@IL27EXM10.cig.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello folks, I made an attempt a few years ago to develop such a terminology draft, within the context of the [manet] working group. Here is a URL for the draft if you are interested: http://people.nokia.net/~charliep/txt/manet/term.txt If you would like to use some of the definitions in that draft, and/or if you are looking for help in creating the new draft, I'd be happy to work on it. The draft was rejected within the [manet] working group for a reason that I thought was very curious. Essentially, the objection was made that every working group Internet Draft should contain its own terminology definitions, and that no common terminology draft was desirable. I disagreed with that reason then, and I still disagree with it, but I haven't felt a very strong need to take up the matter within the [manet] group since I didn't need yet another battle on my hands. I do think it would be a good idea to keep the terminology draft separated out from a more wide-ranging wireless issues draft, such as has generated a lot of recent interest on this mailing list. Regards, Charlie P. PS. to [manet] working group readers: I'd be happy to reintroduce the old draft, or a revision of it, for reconsideration. Nakhjiri Madjid-MNAKHJI1 wrote: > > Jukka, > > Thanks for taking charge on this. Did you do a diff on your > definitions and CT problem statement draft? Since you were > intimately involved with CT PS draft, I assume you did that. > I think we did a good job of defining CT related terminology, > but I don't know how it differred from MM or Paging terminology, > it would be nice to do a diff with those as well to have a WG > wide common terminology draft. > > Thanks again, > Madjid > > -----Original Message----- > From: Jukka Manner [mailto:jmanner@cs.Helsinki.FI] > Sent: Tuesday, May 15, 2001 1:25 AM > To: Hamid Syed > Cc: 'James Kempf'; seamoby@diameter.org > Subject: RE: Wireless Terminology Draft( was: Re: [seamoby] Seamoby > Charter Last Call) > > Hamid, > > Thank you for suggesting it. The draft was originally meant to > support the work in Seamoby, but it would be an even better idea to make it > a more thorough document for use in more or less all work relating to mobile > and > wireless environments, including Seamoby, Mobile-IP, and possibly MANET. > > I would be happy to continue the work on the terminology taking as > basis > the mentioned draft. > > BR, > > Jukka > > On Mon, 14 May 2001, Hamid Syed wrote: > > > Hello james, > > > > A draft was submitted to seamoby early this year that attempted to capture > > the wireless terminology. her eis the link: > > http://search.ietf.org/internet-drafts/draft-manner-seamoby-terms-01.txt > > > > br > > > > -Hamid > > > > > -----Original Message----- > > > From: James Kempf [SMTP:James.Kempf@Sun.COM] > > > Sent: Monday, May 14, 2001 1:47 PM > > > To: seamoby@diameter.org > > > Subject: Wireless Terminology Draft( was: Re: [seamoby] Seamoby > > > Charter Last Call) > > > > > > > > > ------------- Begin Forwarded Message ------------- > > > > > > Date: Mon, 14 May 2001 10:43:47 -0700 (PDT) > > > From: James Kempf > > > Subject: Re: [seamoby] Seamoby Charter Last Call > > > To: James.Kempf@sun.com, charliep@iprg.nokia.com > > > Content-MD5: 6F7Vl9kYVVbqr66TeEQyRw== > > > > > > Hi Charlie, > > > > > > > > > >> Maybe we need a terminology draft, or at least, define this term > > > >> somewhere so that it can be referred to. I'm suprised nobody > > > >> has done a generalized terminology draft for wireless terms before in > > > the MIP > > > >> group. > > > > > > > >RFC 2002 does start off with a long list of terminology. > > > > > > > >It is questionable whether any specific wireless terms are > > > >needed for a protocol running over IP. What is needed is > > > >a list of useful terms. For instance, one might care about > > > >error rate or bandwidth even if the medium were not wireless. > > > >I don't think that chip rate, for instance, should be part > > > >of the [seamoby] terminology list. > > > > > > > > > > Actually, there are plenty of wireless terms that need definition. > > > Access point, handoff (or handover IETF should select which one > > > it wants to use), context transfer, paging, etc. etc. > > > > > > >Do you think that there are terms which SHOULD have been defined > > > >for RFC 2002? If so, now would be a good time to mention them > > > >before RFC 2002bis goes to the RFC editor's desk. > > > > > > > > > > No, I think they have wider applicability. More and more wireless > > > stuff is going on. There are now two working groups associated > > > with wireless, and others that have a big wireless component. I think > > > having a > > > terminology draft that collects all terminology that could be referred > to > > > by > > > drafts would be a benefit. > > > > > > jak > > > > > > > > > > > > ------------- End Forwarded Message ------------- > > > > > > > > From owner-seamoby@diameter.org Fri May 18 15:16: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 PAA12671 for ; Fri, 18 May 2001 15:16:04 -0400 (EDT) Received: (qmail 1885 invoked by alias); 18 May 2001 19:03:46 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 1879 invoked by uid 200); 18 May 2001 19:03:45 -0000 Received: (qmail 1874 invoked from network); 18 May 2001 19:03:42 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by c900656-a.plstn1.sfba.home.com with SMTP; 18 May 2001 19:03:42 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12585; Fri, 18 May 2001 15:14:25 -0400 (EDT) Message-Id: <200105181914.PAA12585@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: seamoby@cdma-2000.org From: The IESG Subject: [seamoby] Document Action: Dormant Mode Host Alerting ('IP Paging') Problem Statement to Informational Date: Fri, 18 May 2001 15:14:25 -0400 Sender: owner-seamoby@diameter.org Precedence: bulk The IESG has approved the Internet-Draft 'Dormant Mode Host Alerting ('IP Paging') Problem Statement' as an Informational RFC. This document is the product of the Context and Micro-mobility Routing Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. From owner-seamoby@diameter.org Fri May 18 17:44:38 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 RAA17007 for ; Fri, 18 May 2001 17:44:37 -0400 (EDT) Received: (qmail 2693 invoked by alias); 18 May 2001 21:30:54 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2687 invoked by uid 200); 18 May 2001 21:30:54 -0000 Received: (qmail 2682 invoked from network); 18 May 2001 21:30:51 -0000 Received: from motgate.mot.com (129.188.136.100) by c900656-a.plstn1.sfba.home.com with SMTP; 18 May 2001 21:30:51 -0000 Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id OAA26987 for ; Fri, 18 May 2001 14:41:50 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id OAA28159 for ; Fri, 18 May 2001 14:41:50 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Fri, 18 May 2001 16:41:50 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B1B7BDA@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Jukka Manner'" , Nakhjiri Madjid-MNAKHJI1 Cc: Hamid Syed , "'James Kempf'" , seamoby@diameter.org Subject: RE: Wireless Terminology Draft( was: Re: [seamoby] Seamoby Charte r Last Call) Date: Fri, 18 May 2001 16:40:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-seamoby@diameter.org Precedence: bulk -----Original Message----- From: Jukka Manner [mailto:jmanner@cs.Helsinki.FI] Sent: Friday, May 18, 2001 11:46 AM To: Nakhjiri Madjid-MNAKHJI1 Cc: Hamid Syed; 'James Kempf'; seamoby@diameter.org Subject: RE: Wireless Terminology Draft( was: Re: [seamoby] Seamoby Charter Last Call) Hi, quick answers inline (I'm off to have a weekend break for once...:) Have a nice weekend all of you, Jukka On Fri, 18 May 2001, Nakhjiri Madjid-MNAKHJI1 wrote: > Jukka, > > Thanks for taking charge on this. Did you do a diff on your > definitions and CT problem statement draft? Since you were > intimately involved with CT PS draft, I assume you did that. Actually, the terminology in the CT draft was taken from the terminology draft. Some wording was changed, if I remember correctly, in the CT draft, but the basic definitions were the same. MN>> Yes some wordings were changed, but didn't mean to take credit away from you. Sorry :) > I think we did a good job of defining CT related terminology, > but I don't know how it differred from MM or Paging terminology, > it would be nice to do a diff with those as well to have a WG > wide common terminology draft. The MM team used "our" CT terms and added some new ones; those could be added to a new terminology draft. The Paging team had only a few terms of "their" own, but those could be added as well. MN>> Ok, it would be nice to have a common terminology draft (info RFC?) for the WG that all the design teams can share, IMO. Thanks again, Madjid > > -----Original Message----- > From: Jukka Manner [mailto:jmanner@cs.Helsinki.FI] > Sent: Tuesday, May 15, 2001 1:25 AM > To: Hamid Syed > Cc: 'James Kempf'; seamoby@diameter.org > Subject: RE: Wireless Terminology Draft( was: Re: [seamoby] Seamoby > Charter Last Call) > > > > Hamid, > > Thank you for suggesting it. The draft was originally meant to > support the work in Seamoby, but it would be an even better idea to make it > a more thorough document for use in more or less all work relating to mobile > and > wireless environments, including Seamoby, Mobile-IP, and possibly MANET. > > I would be happy to continue the work on the terminology taking as > basis > the mentioned draft. > > BR, > > Jukka > > On Mon, 14 May 2001, Hamid Syed wrote: > > > Hello james, > > > > A draft was submitted to seamoby early this year that attempted to capture > > the wireless terminology. her eis the link: > > http://search.ietf.org/internet-drafts/draft-manner-seamoby-terms-01.txt > > > > br > > > > -Hamid > > > > > -----Original Message----- > > > From: James Kempf [SMTP:James.Kempf@Sun.COM] > > > Sent: Monday, May 14, 2001 1:47 PM > > > To: seamoby@diameter.org > > > Subject: Wireless Terminology Draft( was: Re: [seamoby] Seamoby > > > Charter Last Call) > > > > > > > > > ------------- Begin Forwarded Message ------------- > > > > > > Date: Mon, 14 May 2001 10:43:47 -0700 (PDT) > > > From: James Kempf > > > Subject: Re: [seamoby] Seamoby Charter Last Call > > > To: James.Kempf@sun.com, charliep@iprg.nokia.com > > > Content-MD5: 6F7Vl9kYVVbqr66TeEQyRw== > > > > > > Hi Charlie, > > > > > > > > > >> Maybe we need a terminology draft, or at least, define this term > > > >> somewhere so that it can be referred to. I'm suprised nobody > > > >> has done a generalized terminology draft for wireless terms before in > > > the MIP > > > >> group. > > > > > > > >RFC 2002 does start off with a long list of terminology. > > > > > > > >It is questionable whether any specific wireless terms are > > > >needed for a protocol running over IP. What is needed is > > > >a list of useful terms. For instance, one might care about > > > >error rate or bandwidth even if the medium were not wireless. > > > >I don't think that chip rate, for instance, should be part > > > >of the [seamoby] terminology list. > > > > > > > > > > Actually, there are plenty of wireless terms that need definition. > > > Access point, handoff (or handover IETF should select which one > > > it wants to use), context transfer, paging, etc. etc. > > > > > > >Do you think that there are terms which SHOULD have been defined > > > >for RFC 2002? If so, now would be a good time to mention them > > > >before RFC 2002bis goes to the RFC editor's desk. > > > > > > > > > > No, I think they have wider applicability. More and more wireless > > > stuff is going on. There are now two working groups associated > > > with wireless, and others that have a big wireless component. I think > > > having a > > > terminology draft that collects all terminology that could be referred > to > > > by > > > drafts would be a benefit. > > > > > > jak > > > > > > > > > > > > ------------- End Forwarded Message ------------- > > > > > > > > > From owner-seamoby@diameter.org Fri May 18 17:57: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 RAA17268 for ; Fri, 18 May 2001 17:57:40 -0400 (EDT) Received: (qmail 2859 invoked by alias); 18 May 2001 21:32:40 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2854 invoked by uid 200); 18 May 2001 21:32:40 -0000 Received: (qmail 2849 invoked from network); 18 May 2001 21:32:38 -0000 Received: from motgate.mot.com (129.188.136.100) by c900656-a.plstn1.sfba.home.com with SMTP; 18 May 2001 21:32:38 -0000 Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id OAA27845 for ; Fri, 18 May 2001 14:43:38 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id OAA28766 for ; Fri, 18 May 2001 14:43:37 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Fri, 18 May 2001 16:43:37 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B1B7BDB@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Charles E. Perkins'" , Nakhjiri Madjid-MNAKHJI1 Cc: "'Jukka Manner'" , Hamid Syed , "'James Kempf'" , seamoby@diameter.org, Mobile Ad Hoc IETF working group Subject: RE: Wireless Terminology Draft( was: Re: [seamoby] Seamoby Charte r Last Call) Date: Fri, 18 May 2001 16:43:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-seamoby@diameter.org Precedence: bulk -----Original Message----- From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com] Sent: Friday, May 18, 2001 12:50 PM To: Nakhjiri Madjid-MNAKHJI1 Cc: 'Jukka Manner'; Hamid Syed; 'James Kempf'; seamoby@diameter.org; Mobile Ad Hoc IETF working group Subject: Re: Wireless Terminology Draft( was: Re: [seamoby] Seamoby Charter Last Call) Hello folks, I made an attempt a few years ago to develop such a terminology draft, within the context of the [manet] working group. Here is a URL for the draft if you are interested: http://people.nokia.net/~charliep/txt/manet/term.txt If you would like to use some of the definitions in that draft, and/or if you are looking for help in creating the new draft, I'd be happy to work on it. The draft was rejected within the [manet] working group for a reason that I thought was very curious. Essentially, the objection was made that every working group Internet Draft should contain its own terminology definitions, and that no common terminology draft was desirable. MN>> Interesting. I find this peculiar, since the problem statement was criticized for being too long and elaborate. If every draft contains its own terminology, then you got 2-3 extra overhead pages right there. What is wrong to have one reference within the group? Regards, Madjid I disagreed with that reason then, and I still disagree with it, but I haven't felt a very strong need to take up the matter within the [manet] group since I didn't need yet another battle on my hands. I do think it would be a good idea to keep the terminology draft separated out from a more wide-ranging wireless issues draft, such as has generated a lot of recent interest on this mailing list. Regards, Charlie P. PS. to [manet] working group readers: I'd be happy to reintroduce the old draft, or a revision of it, for reconsideration. Nakhjiri Madjid-MNAKHJI1 wrote: > > Jukka, > > Thanks for taking charge on this. Did you do a diff on your > definitions and CT problem statement draft? Since you were > intimately involved with CT PS draft, I assume you did that. > I think we did a good job of defining CT related terminology, > but I don't know how it differred from MM or Paging terminology, > it would be nice to do a diff with those as well to have a WG > wide common terminology draft. > > Thanks again, > Madjid > > -----Original Message----- > From: Jukka Manner [mailto:jmanner@cs.Helsinki.FI] > Sent: Tuesday, May 15, 2001 1:25 AM > To: Hamid Syed > Cc: 'James Kempf'; seamoby@diameter.org > Subject: RE: Wireless Terminology Draft( was: Re: [seamoby] Seamoby > Charter Last Call) > > Hamid, > > Thank you for suggesting it. The draft was originally meant to > support the work in Seamoby, but it would be an even better idea to make it > a more thorough document for use in more or less all work relating to mobile > and > wireless environments, including Seamoby, Mobile-IP, and possibly MANET. > > I would be happy to continue the work on the terminology taking as > basis > the mentioned draft. > > BR, > > Jukka > > On Mon, 14 May 2001, Hamid Syed wrote: > > > Hello james, > > > > A draft was submitted to seamoby early this year that attempted to capture > > the wireless terminology. her eis the link: > > http://search.ietf.org/internet-drafts/draft-manner-seamoby-terms-01.txt > > > > br > > > > -Hamid > > > > > -----Original Message----- > > > From: James Kempf [SMTP:James.Kempf@Sun.COM] > > > Sent: Monday, May 14, 2001 1:47 PM > > > To: seamoby@diameter.org > > > Subject: Wireless Terminology Draft( was: Re: [seamoby] Seamoby > > > Charter Last Call) > > > > > > > > > ------------- Begin Forwarded Message ------------- > > > > > > Date: Mon, 14 May 2001 10:43:47 -0700 (PDT) > > > From: James Kempf > > > Subject: Re: [seamoby] Seamoby Charter Last Call > > > To: James.Kempf@sun.com, charliep@iprg.nokia.com > > > Content-MD5: 6F7Vl9kYVVbqr66TeEQyRw== > > > > > > Hi Charlie, > > > > > > > > > >> Maybe we need a terminology draft, or at least, define this term > > > >> somewhere so that it can be referred to. I'm suprised nobody > > > >> has done a generalized terminology draft for wireless terms before in > > > the MIP > > > >> group. > > > > > > > >RFC 2002 does start off with a long list of terminology. > > > > > > > >It is questionable whether any specific wireless terms are > > > >needed for a protocol running over IP. What is needed is > > > >a list of useful terms. For instance, one might care about > > > >error rate or bandwidth even if the medium were not wireless. > > > >I don't think that chip rate, for instance, should be part > > > >of the [seamoby] terminology list. > > > > > > > > > > Actually, there are plenty of wireless terms that need definition. > > > Access point, handoff (or handover IETF should select which one > > > it wants to use), context transfer, paging, etc. etc. > > > > > > >Do you think that there are terms which SHOULD have been defined > > > >for RFC 2002? If so, now would be a good time to mention them > > > >before RFC 2002bis goes to the RFC editor's desk. > > > > > > > > > > No, I think they have wider applicability. More and more wireless > > > stuff is going on. There are now two working groups associated > > > with wireless, and others that have a big wireless component. I think > > > having a > > > terminology draft that collects all terminology that could be referred > to > > > by > > > drafts would be a benefit. > > > > > > jak > > > > > > > > > > > > ------------- End Forwarded Message ------------- > > > > > > > > From owner-seamoby@diameter.org Fri May 18 18:03: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 SAA17372 for ; Fri, 18 May 2001 18:03:40 -0400 (EDT) Received: (qmail 3150 invoked by alias); 18 May 2001 21:36:46 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 3144 invoked by uid 200); 18 May 2001 21:36:45 -0000 Received: (qmail 3139 invoked from network); 18 May 2001 21:36:44 -0000 Received: from ftpbox.mot.com (129.188.136.101) by c900656-a.plstn1.sfba.home.com with SMTP; 18 May 2001 21:36:44 -0000 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id OAA18310 for ; Fri, 18 May 2001 14:47:28 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id OAA24468 for ; Fri, 18 May 2001 14:47:28 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19) id ; Fri, 18 May 2001 16:47:27 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B1B7BDC@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Gary Kenward'" , "'Jukka Manner'" , Nakhjiri Madjid-MNAKHJI1 , Hamid Syed , "'James Kempf'" Cc: seamoby Subject: RE: Wireless Terminology Draft( was: Re: [seamoby] Seamoby Charte r Last Call) Date: Fri, 18 May 2001 16:47:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Gary, I thought we were only talking about the terminology section, not the reference architecture, but anyways! I am not objecting to this, however, this is ok, as long as we don't loose track of all terminology work (if it does not go into any document whatsoever!) and find find a home for all terminology and reference architecture text that people worked on. Regards, Madjid -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Friday, May 18, 2001 12:43 PM To: 'Jukka Manner'; Nakhjiri Madjid-MNAKHJI1; Hamid Syed; 'James Kempf' Cc: seamoby Subject: RE: Wireless Terminology Draft( was: Re: [seamoby] Seamoby Charte r Last Call) So that it is clear, the new version of the ct problem statement does not use the reference architecture of the original draft. The only terms that may seem familiar are mobile node, and access network. This was done to simplify the problem statement, and avoid some of the persistent controversy, not because there was anything wrong with the original reference architecture or nomenclature (probably yet another argument in favour of producing a nomenclature reference draft). Gary > -----Original Message----- > From: Jukka Manner [mailto:jmanner@cs.Helsinki.FI] > Sent: Friday, May 18, 2001 12:46 PM > To: Nakhjiri Madjid-MNAKHJI1 > Cc: Syed, Hamid [WDLN2:AN22:EXCH]; 'James Kempf'; seamoby > Subject: RE: Wireless Terminology Draft( was: Re: [seamoby] Seamoby > Charte r Last Call) > > > > > Hi, quick answers inline (I'm off to have a weekend > break for once...:) > > Have a nice weekend all of you, > > Jukka > > On Fri, 18 May 2001, Nakhjiri Madjid-MNAKHJI1 wrote: > > > Jukka, > > > > Thanks for taking charge on this. Did you do a diff on your > > definitions and CT problem statement draft? Since you were > > intimately involved with CT PS draft, I assume you did that. > > Actually, the terminology in the CT draft was taken > from the terminology > draft. Some wording was changed, if I remember correctly, in > the CT draft, but > the basic definitions were the same. > > > I think we did a good job of defining CT related terminology, > > but I don't know how it differred from MM or Paging terminology, > > it would be nice to do a diff with those as well to have a WG > > wide common terminology draft. > > The MM team used "our" CT terms and added some new > ones; those could be > added to a new terminology draft. The Paging team had only a > few terms of > "their" own, but those could be added as well. > > > > > Thanks again, > > Madjid > > > > -----Original Message----- > > From: Jukka Manner [mailto:jmanner@cs.Helsinki.FI] > > Sent: Tuesday, May 15, 2001 1:25 AM > > To: Hamid Syed > > Cc: 'James Kempf'; seamoby@diameter.org > > Subject: RE: Wireless Terminology Draft( was: Re: [seamoby] Seamoby > > Charter Last Call) > > > > > > > > Hamid, > > > > Thank you for suggesting it. The draft was originally meant to > > support the work in Seamoby, but it would be an even better > idea to make it > > a more thorough document for use in more or less all work > relating to mobile > > and > > wireless environments, including Seamoby, Mobile-IP, and > possibly MANET. > > > > I would be happy to continue the work on the > terminology taking as > > basis > > the mentioned draft. > > > > BR, > > > > Jukka > > > > On Mon, 14 May 2001, Hamid Syed wrote: > > > > > Hello james, > > > > > > A draft was submitted to seamoby early this year that > attempted to capture > > > the wireless terminology. her eis the link: > > > > http://search.ietf.org/internet-drafts/draft-manner-seamoby-te > rms-01.txt > > > > > > br > > > > > > -Hamid > > > > > > > -----Original Message----- > > > > From: James Kempf [SMTP:James.Kempf@Sun.COM] > > > > Sent: Monday, May 14, 2001 1:47 PM > > > > To: seamoby@diameter.org > > > > Subject: Wireless Terminology Draft( was: Re: > [seamoby] Seamoby > > > > Charter Last Call) > > > > > > > > > > > > ------------- Begin Forwarded Message ------------- > > > > > > > > Date: Mon, 14 May 2001 10:43:47 -0700 (PDT) > > > > From: James Kempf > > > > Subject: Re: [seamoby] Seamoby Charter Last Call > > > > To: James.Kempf@sun.com, charliep@iprg.nokia.com > > > > Content-MD5: 6F7Vl9kYVVbqr66TeEQyRw== > > > > > > > > Hi Charlie, > > > > > > > > > > > > >> Maybe we need a terminology draft, or at least, > define this term > > > > >> somewhere so that it can be referred to. I'm suprised nobody > > > > >> has done a generalized terminology draft for > wireless terms before in > > > > the MIP > > > > >> group. > > > > > > > > > >RFC 2002 does start off with a long list of terminology. > > > > > > > > > >It is questionable whether any specific wireless terms are > > > > >needed for a protocol running over IP. What is needed is > > > > >a list of useful terms. For instance, one might care about > > > > >error rate or bandwidth even if the medium were not wireless. > > > > >I don't think that chip rate, for instance, should be part > > > > >of the [seamoby] terminology list. > > > > > > > > > > > > > Actually, there are plenty of wireless terms that need > definition. > > > > Access point, handoff (or handover IETF should select which one > > > > it wants to use), context transfer, paging, etc. etc. > > > > > > > > >Do you think that there are terms which SHOULD have > been defined > > > > >for RFC 2002? If so, now would be a good time to mention them > > > > >before RFC 2002bis goes to the RFC editor's desk. > > > > > > > > > > > > > No, I think they have wider applicability. More and > more wireless > > > > stuff is going on. There are now two working groups associated > > > > with wireless, and others that have a big wireless > component. I think > > > > having a > > > > terminology draft that collects all terminology that > could be referred > > to > > > > by > > > > drafts would be a benefit. > > > > > > > > jak > > > > > > > > > > > > > > > > ------------- End Forwarded Message ------------- > > > > > > > > > > > > > > > From owner-seamoby@diameter.org Fri May 18 18:08: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 SAA17451 for ; Fri, 18 May 2001 18:08:27 -0400 (EDT) Received: (qmail 3277 invoked by alias); 18 May 2001 21:41:07 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 3271 invoked by uid 200); 18 May 2001 21:41:07 -0000 Received: (qmail 3266 invoked from network); 18 May 2001 21:41:05 -0000 Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.nortelnetworks.com) (47.129.242.157) by c900656-a.plstn1.sfba.home.com with SMTP; 18 May 2001 21:41:05 -0000 Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id RAA10893; Fri, 18 May 2001 17:51:29 -0400 Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 18 May 2001 17:51:31 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 18 May 2001 17:51:35 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C12595D@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Nakhjiri Madjid-MNAKHJI1'" Cc: "'seamoby'" Subject: RE: Wireless Terminology Draft( was: Re: [seamoby] Seamoby Charte r Last Call) Date: Fri, 18 May 2001 17:51:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" X-Orig: Sender: owner-seamoby@diameter.org Precedence: bulk In my experience, terminology cannot be defined unless you can relate the entities being described, hence, you do need to start discussing the reference architecture at some level. E.g. the terminology in the problem statement was all derived from the reference architecture. I agree, it's worth retaining. How or where is a tougher question. Gary > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Friday, May 18, 2001 5:47 PM > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Jukka Manner'; Nakhjiri > Madjid-MNAKHJI1; Syed, Hamid [WDLN2:AN22:EXCH]; 'James Kempf' > Cc: seamoby > Subject: RE: Wireless Terminology Draft( was: Re: [seamoby] Seamoby > Charte r Last Call) > > > Gary, > > I thought we were only talking about the terminology section, not the > reference architecture, but anyways! > I am not objecting to this, however, this is ok, as long as > we don't loose > track of all > terminology work (if it does not go into any document > whatsoever!) and find > find a home for all terminology and reference architecture > text that people > worked on. > > Regards, > Madjid > > -----Original Message----- > From: Gary Kenward [mailto:gkenward@nortelnetworks.com] > Sent: Friday, May 18, 2001 12:43 PM > To: 'Jukka Manner'; Nakhjiri Madjid-MNAKHJI1; Hamid Syed; > 'James Kempf' > Cc: seamoby > Subject: RE: Wireless Terminology Draft( was: Re: [seamoby] > Seamoby Charte r > Last Call) > > > So that it is clear, the new version of the ct problem statement > does not use the reference architecture of the original draft. The > only terms that may seem familiar are mobile node, and access > network. > This was done to simplify the problem statement, and avoid > some of the > persistent controversy, not because there was anything wrong with the > original reference architecture or nomenclature (probably yet another > argument in favour of producing a nomenclature reference draft). > Gary > > -----Original Message----- > > From: Jukka Manner [mailto:jmanner@cs.Helsinki.FI] > > Sent: Friday, May 18, 2001 12:46 PM > > To: Nakhjiri Madjid-MNAKHJI1 > > Cc: Syed, Hamid [WDLN2:AN22:EXCH]; 'James Kempf'; seamoby > > Subject: RE: Wireless Terminology Draft( was: Re: [seamoby] Seamoby > > Charte r Last Call) > > > > > > > > > > Hi, quick answers inline (I'm off to have a weekend > > break for once...:) > > > > Have a nice weekend all of you, > > > > Jukka > > > > On Fri, 18 May 2001, Nakhjiri Madjid-MNAKHJI1 wrote: > > > > > Jukka, > > > > > > Thanks for taking charge on this. Did you do a diff on your > > > definitions and CT problem statement draft? Since you were > > > intimately involved with CT PS draft, I assume you did that. > > > > Actually, the terminology in the CT draft was taken > > from the terminology > > draft. Some wording was changed, if I remember correctly, in > > the CT draft, but > > the basic definitions were the same. > > > > > I think we did a good job of defining CT related terminology, > > > but I don't know how it differred from MM or Paging terminology, > > > it would be nice to do a diff with those as well to have a WG > > > wide common terminology draft. > > > > The MM team used "our" CT terms and added some new > > ones; those could be > > added to a new terminology draft. The Paging team had only a > > few terms of > > "their" own, but those could be added as well. > > > > > > > > Thanks again, > > > Madjid > > > > > > -----Original Message----- > > > From: Jukka Manner [mailto:jmanner@cs.Helsinki.FI] > > > Sent: Tuesday, May 15, 2001 1:25 AM > > > To: Hamid Syed > > > Cc: 'James Kempf'; seamoby@diameter.org > > > Subject: RE: Wireless Terminology Draft( was: Re: > [seamoby] Seamoby > > > Charter Last Call) > > > > > > > > > > > > Hamid, > > > > > > Thank you for suggesting it. The draft was originally > meant to > > > support the work in Seamoby, but it would be an even better > > idea to make it > > > a more thorough document for use in more or less all work > > relating to mobile > > > and > > > wireless environments, including Seamoby, Mobile-IP, and > > possibly MANET. > > > > > > I would be happy to continue the work on the > > terminology taking as > > > basis > > > the mentioned draft. > > > > > > BR, > > > > > > Jukka > > > > > > On Mon, 14 May 2001, Hamid Syed wrote: > > > > > > > Hello james, > > > > > > > > A draft was submitted to seamoby early this year that > > attempted to capture > > > > the wireless terminology. her eis the link: > > > > > > http://search.ietf.org/internet-drafts/draft-manner-seamoby-te > > rms-01.txt > > > > > > > > br > > > > > > > > -Hamid > > > > > > > > > -----Original Message----- > > > > > From: James Kempf [SMTP:James.Kempf@Sun.COM] > > > > > Sent: Monday, May 14, 2001 1:47 PM > > > > > To: seamoby@diameter.org > > > > > Subject: Wireless Terminology Draft( was: Re: > > [seamoby] Seamoby > > > > > Charter Last Call) > > > > > > > > > > > > > > > ------------- Begin Forwarded Message ------------- > > > > > > > > > > Date: Mon, 14 May 2001 10:43:47 -0700 (PDT) > > > > > From: James Kempf > > > > > Subject: Re: [seamoby] Seamoby Charter Last Call > > > > > To: James.Kempf@sun.com, charliep@iprg.nokia.com > > > > > Content-MD5: 6F7Vl9kYVVbqr66TeEQyRw== > > > > > > > > > > Hi Charlie, > > > > > > > > > > > > > > > >> Maybe we need a terminology draft, or at least, > > define this term > > > > > >> somewhere so that it can be referred to. I'm > suprised nobody > > > > > >> has done a generalized terminology draft for > > wireless terms before in > > > > > the MIP > > > > > >> group. > > > > > > > > > > > >RFC 2002 does start off with a long list of terminology. > > > > > > > > > > > >It is questionable whether any specific wireless terms are > > > > > >needed for a protocol running over IP. What is needed is > > > > > >a list of useful terms. For instance, one might care about > > > > > >error rate or bandwidth even if the medium were not > wireless. > > > > > >I don't think that chip rate, for instance, should be part > > > > > >of the [seamoby] terminology list. > > > > > > > > > > > > > > > > Actually, there are plenty of wireless terms that need > > definition. > > > > > Access point, handoff (or handover IETF should select > which one > > > > > it wants to use), context transfer, paging, etc. etc. > > > > > > > > > > >Do you think that there are terms which SHOULD have > > been defined > > > > > >for RFC 2002? If so, now would be a good time to > mention them > > > > > >before RFC 2002bis goes to the RFC editor's desk. > > > > > > > > > > > > > > > > No, I think they have wider applicability. More and > > more wireless > > > > > stuff is going on. There are now two working groups > associated > > > > > with wireless, and others that have a big wireless > > component. I think > > > > > having a > > > > > terminology draft that collects all terminology that > > could be referred > > > to > > > > > by > > > > > drafts would be a benefit. > > > > > > > > > > jak > > > > > > > > > > > > > > > > > > > > ------------- End Forwarded Message ------------- > > > > > > > > > > > > > > > > > > > > > > From owner-seamoby@diameter.org Fri May 18 18:12: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 SAA17546 for ; Fri, 18 May 2001 18:12:28 -0400 (EDT) Received: (qmail 4324 invoked by alias); 18 May 2001 21:56:57 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 4316 invoked by uid 200); 18 May 2001 21:56:57 -0000 Received: (qmail 4306 invoked from network); 18 May 2001 21:56:53 -0000 Received: from motgate.mot.com (129.188.136.100) by c900656-a.plstn1.sfba.home.com with SMTP; 18 May 2001 21:56:53 -0000 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id PAA11781 for ; Fri, 18 May 2001 15:07:51 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id PAA00095 for ; Fri, 18 May 2001 15:07:50 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Fri, 18 May 2001 17:07:51 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B1B7BDD@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'john.loughney@nokia.com'" , Nakhjiri Madjid-MNAKHJI1 , seamoby@diameter.org Subject: [seamoby] RE: MM requirements (was: IRTF mm problem statement) Date: Fri, 18 May 2001 17:07:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk John, MM design team folks, I don't know what John means by "should we let it die" Anyway, I read the draft long time ago, but I need to read it again, so If I ask dumb or unfair questions, let me know. Either way, I am planning to read it again! just a few comments, for Friday afternoon (or Saturday morning your time :) ), I hope this is not a repeat, or not fuel for a lot of flames! and it is not meant to be criticism. Regards, Madjid "In this draft, the term 'local mobility' is used in place of micromobility." Why? and why do we call the draft Micromobility then! I guess later on, I have answered the first "why" but I am not sure. "While studying solutions for seamless handovers, the SEAMOBY Working Group should include the following considerations:" Is this still true, or might want take the SEAMOBY WG out of it? " * Mobility maintaining the same routable IP address of a mobile node or mobile network." OK, This one sounds like MM to me, but " * Handover between heterogeneous networks. For example, 802.11, Bluetooth and 3G cellular." This one is a bit not clear. I want to read handover between L2s of these networks (or APs as we defined them earlier). If it would be ARs, then isn't handled by MIP then? in anycase it wouldn't be called micromobility, would it, just wondering? (maybe local mobility is the better term after all :) ) Generally one problem that I have with the draft is that whether it is AP or AR, is not alway clear. " * How to discover a new Access Link and the Access Router serving the new Access Link." so you also mean discover a new AP? " * How to discover the bandwidth, cost, error rate (and other properties) of candidate Access Links. * Involving QoS characteristics as part of the handover process." These two sound like the stuff in CNP, do we want to start from there? " * Optimize the path for mobile-to-mobile communications. * Enable plug and play capabilities for Mobile Devices, Access Routers/Access Links." the text that is provided for this (in 4.3.3) talks about capability discovery of neighboring APs. Is that the same as plug and play capability, you say? * Support for mobility of mobile hosts and mobile networks -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Friday, May 18, 2001 1:33 AM To: Madjid.Nakhjiri; seamoby@diameter.org Subject: RE: MM requirements (was: IRTF mm problem statement) Hi Madjid, > Well, what is the status?? until a few days ago, it was not > clear whether is on the charter or not. The current problem statement: http://www.ietf.org/internet-drafts/draft-ietf-seamoby-mm-problem-01.txt Has recieved no comments on it since before the 50th IETF meeting. Should we go to last call, or should we let it die? I have asked this several times, and noone has given me an answer. The proposed SeaMoby Charter has this item in it: Jul 01 Submit Handoff Candidate Discovery Problem Statement This topic is seperate from the above problem statement. Now, does anyone have any preferences on how to procede? John From owner-seamoby@diameter.org Fri May 18 18:14: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 SAA17590 for ; Fri, 18 May 2001 18:14:43 -0400 (EDT) Received: (qmail 4756 invoked by alias); 18 May 2001 22:00:40 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 4750 invoked by uid 200); 18 May 2001 22:00:40 -0000 Received: (qmail 4736 invoked from network); 18 May 2001 22:00:37 -0000 Received: from motgate2.mot.com (136.182.1.10) by c900656-a.plstn1.sfba.home.com with SMTP; 18 May 2001 22:00:37 -0000 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id PAA17897 for ; Fri, 18 May 2001 15:11:33 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id PAA09507 for ; Fri, 18 May 2001 15:11:33 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19) id ; Fri, 18 May 2001 17:11:32 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B1B7BDE@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Gary Kenward'" , Nakhjiri Madjid-MNAKHJI1 Cc: "'seamoby'" Subject: RE: Wireless Terminology Draft( was: Re: [seamoby] Seamoby Charte r Last Call) Date: Fri, 18 May 2001 17:11:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Friday, May 18, 2001 4:52 PM To: 'Nakhjiri Madjid-MNAKHJI1' Cc: 'seamoby' Subject: RE: Wireless Terminology Draft( was: Re: [seamoby] Seamoby Charte r Last Call) In my experience, terminology cannot be defined unless you can relate the entities being described, hence, you do need to start discussing the reference architecture at some level. E.g. the terminology in the problem statement was all derived from the reference architecture. MN>> fair enough I agree, it's worth retaining. How or where is a tougher question. Gary MN>> How about a separate WG draft that all teams and the rest of WG can use? Seems like, Jukka has already got most of it in place and people are willing to chip in. Regards, Madjid From owner-seamoby@diameter.org Fri May 18 19:20: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 TAA19007 for ; Fri, 18 May 2001 19:20:48 -0400 (EDT) Received: (qmail 5737 invoked by alias); 18 May 2001 23:08:37 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 5731 invoked by uid 200); 18 May 2001 23:08:37 -0000 Received: (qmail 5726 invoked from network); 18 May 2001 23:08:35 -0000 Received: from penguin-ext.wise.edt.ericsson.se (194.237.142.110) by c900656-a.plstn1.sfba.home.com with SMTP; 18 May 2001 23:08:35 -0000 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 f4INJXO10746 for ; Sat, 19 May 2001 01:19:33 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Sat May 19 01:19:33 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Sat, 19 May 2001 01:19:33 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBE6B@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman \(ERA\)" To: "'Randall R. Stewart'" , seamoby@diameter.org Subject: RE: [seamoby] An API issue Date: Sat, 19 May 2001 01:19:32 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-seamoby@diameter.org Precedence: bulk Hello Randall, I (and a couple of my colleagues) have encountered exactly this problem and analysis. I fully agree with your conclusions. We sort of came to the same conclusion. This seems relevant to the AP discovery work being done here. Hesham > -----Original Message----- > From: Randall R. Stewart [SMTP:randall@stewart.chicago.il.us] > Sent: Thursday, 17 May 2001 5:22 > To: seamoby@diameter.org > Subject: [seamoby] An API issue > > Dear All: > > I have a problem and was wondering if anyone else > has encountered this... > > This may be the wrong place to take this issue Pat, if it > is, please redirect me.. > > Here is the jest of the problem. I have a wireless card > driver (it can be any type you can imagine.. GSM, 802.11 > even blue-tooth...). > > It gets a signal that an event has transpired > i.e. Association fell apart or came up, i.e. I can now reach > a AR or I can no longer reach an AR or maybe some other trigger > type event of interest. This is the ole Layer-2 > trigger that everyone talks about.... > > Now HOW do I get it up to layer 3? > > This seems like a real naive question I know... but when you > start digging in to at least most unixy stacks, you have > a layer 2 driver servicing the card (or is it layer 1:>), > its interfaces to upper layers are: > > A) ioctl... user requests/response model > B) packet arrival -> submit to ether_input() > C) packet sending -> output routine is called. > > > Now I can use A if you want to have the interested upper > layer poll every N interval and ask... hey what is your > current status? But this means that N becomes the granularity > of when you might want to handoff/do something. This could > be a real problem for real time services... > > I can't use C.. after all this is output.. > > And B seems pointless as well.. there is NO packet defined > or protocol defined I can launch up to the layer above that > will resolve to the listner. > > Ideally it would be nice to send a "Layer 2" Trigger message > in (B). One could even envision an "ether protocol id" that directs > the above layer to send it down a particular Layer 3 path where > a reader would get it... I have thought about doing this using > FreeBSD's routing sockets and allowing it to get this type > of input event... but its not standard... > > It would be nice to have some sort of standard way to signal > upwards these Layer-2 triggers (if available). Has anyone > thought of this? I would be willing to write a draft on this > if folks thought it was a good idea... but it really has no > wire side protocol basis... of course neither does a lot of > the sockets mapping api's either :/ > > I would appreciate either re-direction or comments from you all > who may have thought of this.. > > Thanks > > R > > > -- > Randall R. Stewart > randall@stewart.chicago.il.us or rrs@cisco.com > 815-342-5222 (cell) 815-477-2127 (work) From owner-seamoby@diameter.org Fri May 18 21:36: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 VAA22121 for ; Fri, 18 May 2001 21:36:35 -0400 (EDT) Received: (qmail 6581 invoked by alias); 19 May 2001 01:23:31 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 6575 invoked by uid 200); 19 May 2001 01:23:31 -0000 Received: (qmail 6570 invoked from network); 19 May 2001 01:23:28 -0000 Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.nortelnetworks.com) (47.129.242.157) by c900656-a.plstn1.sfba.home.com with SMTP; 19 May 2001 01:23:28 -0000 Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id VAA14446; Fri, 18 May 2001 21:33:49 -0400 Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 18 May 2001 21:33:52 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 18 May 2001 21:33:55 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C12595E@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Nakhjiri Madjid-MNAKHJI1'" Cc: "'seamoby'" Subject: RE: Wireless Terminology Draft( was: Re: [seamoby] Seamoby Charte r Last Call) Date: Fri, 18 May 2001 21:33:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0E003.C49BEA50" 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_01C0E003.C49BEA50 Content-Type: text/plain; charset="ISO-8859-1" I'm all for it. But I think the idea should be run by the ADs first, just to be sure that the effort has some chance of making it to an rfc (probably informational). Gary > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Friday, May 18, 2001 6:12 PM > To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1 > Cc: 'seamoby' > Subject: RE: Wireless Terminology Draft( was: Re: [seamoby] Seamoby > Charte r Last Call) > > > > -----Original Message----- > From: Gary Kenward [mailto:gkenward@nortelnetworks.com] > Sent: Friday, May 18, 2001 4:52 PM > To: 'Nakhjiri Madjid-MNAKHJI1' > Cc: 'seamoby' > Subject: RE: Wireless Terminology Draft( was: Re: [seamoby] > Seamoby Charte r > Last Call) > > > In my experience, terminology cannot be defined unless you > can relate the entities being described, hence, you do need > to start discussing the reference architecture at some level. > E.g. the terminology in the problem statement was all derived > from the reference architecture. > > MN>> fair enough > > I agree, it's worth retaining. How or where is a tougher question. > Gary > > MN>> How about a separate WG draft that all teams and the rest of > WG can use? Seems like, Jukka has already got most of it in place > and people are willing to chip in. > > Regards, > Madjid > ------_=_NextPart_001_01C0E003.C49BEA50 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: Wireless Terminology Draft( was: Re: [seamoby] Seamoby = Charte r Last Call)

I'm all for it. But I think the idea should be run by = the ADs first,
just to be sure that the effort has some chance of = making it to an
rfc (probably informational).

Gary

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@moto= rola.com]
> Sent: Friday, May 18, 2001 6:12 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri = Madjid-MNAKHJI1
> Cc: 'seamoby'
> Subject: RE: Wireless Terminology Draft( was: = Re: [seamoby] Seamoby
> Charte r Last Call)
>
>
>
> -----Original Message-----
> From: Gary Kenward [mailto:gkenward@nortelnetwor= ks.com]
> Sent: Friday, May 18, 2001 4:52 PM
> To: 'Nakhjiri Madjid-MNAKHJI1'
> Cc: 'seamoby'
> Subject: RE: Wireless Terminology Draft( was: = Re: [seamoby]
> Seamoby Charte r
> Last Call)
>
>
> In my experience, terminology cannot be defined = unless you
> can relate the entities being described, hence, = you do need
> to start discussing the reference architecture = at some level.
> E.g. the terminology in the problem statement = was all derived
> from the reference architecture.
>
> MN>> fair enough
>
> I agree, it's worth retaining. How or where is = a tougher question.
> Gary
>
> MN>> How about a separate WG draft that = all teams and the rest of
> WG can use? Seems like, Jukka has already got = most of it in place
> and people are willing to chip in.
>
> Regards,
> Madjid
>

------_=_NextPart_001_01C0E003.C49BEA50-- From owner-seamoby@diameter.org Mon May 21 03:02: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 DAA02668 for ; Mon, 21 May 2001 03:02:18 -0400 (EDT) Received: (qmail 16068 invoked by alias); 21 May 2001 06:49:40 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 16061 invoked by uid 200); 21 May 2001 06:49:39 -0000 Received: (qmail 16053 invoked from network); 21 May 2001 06:49:37 -0000 Received: from mgw-x3.nokia.com (131.228.20.26) by c900656-a.plstn1.sfba.home.com with SMTP; 21 May 2001 06:49:37 -0000 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f4L71Kv25621; Mon, 21 May 2001 10:01:20 +0300 (EET DST) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 21 May 2001 10:00:30 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Mon, 21 May 2001 10:00:30 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680AFB3@eseis04nok> From: john.loughney@nokia.com To: pcalhoun@diameter.org, Madjid.Nakhjiri@motorola.com Cc: seamoby@diameter.org Subject: RE: [seamoby] MM requirements (was: IRTF mm problem statement) Date: Mon, 21 May 2001 10:00:29 +0300 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 Pat, > The MM work was split into three items. Please see the > minutes from the Minn meeting for more detaiil (really > don't want to re-hash it all over again). > > As far as the micro-mobility work is concerned, an internet-draft was > put together by Phil Roberts (see seamoby archives for info), and this > has been passed onto the IRTF routing chair. One comment, Phil's draft references the existing MM Problem Statement. Does this cause any problems, after the MM Problem Statement Draft expires? br, John From owner-seamoby@diameter.org Mon May 21 03:06: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 DAA02937 for ; Mon, 21 May 2001 03:06:34 -0400 (EDT) Received: (qmail 16537 invoked by alias); 21 May 2001 06:54:17 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 16530 invoked by uid 200); 21 May 2001 06:54:17 -0000 Received: (qmail 16525 invoked from network); 21 May 2001 06:54:15 -0000 Received: from mgw-x3.nokia.com (131.228.20.26) by c900656-a.plstn1.sfba.home.com with SMTP; 21 May 2001 06:54:15 -0000 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f4L767v28749 for ; Mon, 21 May 2001 10:06:07 +0300 (EET DST) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 21 May 2001 10:05:20 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Mon, 21 May 2001 10:05:20 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680AFB4@eseis04nok> From: john.loughney@nokia.com To: Madjid.Nakhjiri@motorola.com, seamoby@diameter.org Subject: [seamoby] RE: MM requirements (was: IRTF mm problem statement) Date: Mon, 21 May 2001 10:05:17 +0300 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 Madjid, > I don't know what John means by "should we let it die" The current problem statement is used in 2 Internet Drafts as a refence. When I asked "should we let it die" - I really meant should we let the draft expire. > Anyway, I read the draft long time ago, but I need to read it again, > so If I ask dumb or unfair questions, let me know. Either way, > I am planning to read it again! > "In this draft, the term 'local mobility' is used in place of > micromobility." > > Why? and why do we call the draft Micromobility then! > I guess later on, I have answered the first "why" but I am not sure. MM was used as it was called that in the charter. However, after countless discussions, it was felt that MM had too much baggage, and the DT thought Local Mobility was more fitting term. > "While studying solutions for seamless handovers, the SEAMOBY Working > Group should include the following considerations:" > > Is this still true, or might want take the SEAMOBY WG out of it? Maybe Pat can comment on this. > " * Handover between heterogeneous networks. For example, 802.11, > Bluetooth and 3G cellular." > > This one is a bit not clear. I want to read handover between L2s of > these networks (or APs as we defined them earlier). If it would be > ARs, then isn't handled by MIP then? in anycase it wouldn't be called > micromobility, would it, just wondering? (maybe local mobility is > the better term after all :) ) > Generally one problem that I have with the draft is that whether it is > AP or AR, is not alway clear. That I can try to clean up. > " * How to discover a new Access Link and the Access > Router serving the new Access Link." > > so you also mean discover a new AP? Yes. > " * How to discover the bandwidth, cost, error rate (and other > properties) of candidate Access Links. > * Involving QoS characteristics as part of the handover process." > > These two sound like the stuff in CNP, do we want to start from there? I think CNP is an example of what we want to do, but let's not take it as a given. > * Enable plug and play capabilities for Mobile Devices, Access > Routers/Access Links." > > the text that is provided for this (in 4.3.3) talks about capability > discovery of neighboring APs. Is that the same as plug and play > capability, you say? Yes. John From owner-seamoby@diameter.org Mon May 21 03:11: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 DAA03044 for ; Mon, 21 May 2001 03:11:17 -0400 (EDT) Received: (qmail 17030 invoked by alias); 21 May 2001 06:58:53 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 17021 invoked by uid 200); 21 May 2001 06:58:52 -0000 Received: (qmail 17005 invoked from network); 21 May 2001 06:58:50 -0000 Received: from mgw-x2.nokia.com (131.228.20.22) by c900656-a.plstn1.sfba.home.com with SMTP; 21 May 2001 06:58:50 -0000 Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f4L7A8m18474; Mon, 21 May 2001 10:10:08 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 21 May 2001 10:09:55 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Mon, 21 May 2001 10:09:42 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680AFB5@eseis04nok> From: john.loughney@nokia.com To: pcalhoun@diameter.org Cc: Madjid.Nakhjiri@motorola.com, seamoby@diameter.org Subject: RE: [seamoby] RE: MM requirements (was: IRTF mm problem statement ) Date: Mon, 21 May 2001 10:09:39 +0300 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 Pat, > My appologies. The document was very useful in the creation of the > new charter, and the work that moved to the IRTF, however it cannot > move forward as it is. I understand. Quick question, Phil R.'s problem statement on Subnet Mobility references the current MM Problem statement. Either we could keep some of the existing problem in the MM Problem statement and mention the work will be done by the IRTF, or Phil can remove the reference from Phil R.'s draft. > I would like for the work to begin, but was waiting for IESG > approval. I have heard that there are really good chances that > the charter will be approved, so we could probably start working > on this work item. > > Perhaps one way to start is to extract from the MM problem statement > all of the text that has to do with the above, and create a new > problem statement. > > Would you be wiling to start the effort given that you already have > the nroff source of the MM problem statement? Sure, that would be fine. John From owner-seamoby@diameter.org Mon May 21 09:09: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 JAA08660 for ; Mon, 21 May 2001 09:09:15 -0400 (EDT) Received: (qmail 18181 invoked by alias); 21 May 2001 12:57:30 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 18175 invoked by uid 200); 21 May 2001 12:57:29 -0000 Received: (qmail 18165 invoked by uid 500); 21 May 2001 12:57:28 -0000 Date: Mon, 21 May 2001 05:57:28 -0700 From: Pat Calhoun To: john.loughney@nokia.com Cc: pcalhoun@diameter.org, Madjid.Nakhjiri@motorola.com, seamoby@diameter.org Subject: Re: [seamoby] MM requirements (was: IRTF mm problem statement) Message-ID: <20010521055727.B18132@charizard.diameter.org> Mail-Followup-To: john.loughney@nokia.com, pcalhoun@diameter.org, Madjid.Nakhjiri@motorola.com, seamoby@diameter.org References: <01D91AFB08B6D211BFD00008C7EABAE10680AFB3@eseis04nok> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01D91AFB08B6D211BFD00008C7EABAE10680AFB3@eseis04nok>; from john.loughney@nokia.com on Mon, May 21, 2001 at 10:00:29AM +0300 Sender: owner-seamoby@diameter.org Precedence: bulk On Mon, May 21, 2001 at 10:00:29AM +0300, john.loughney@nokia.com wrote: > Hi Pat, > > > The MM work was split into three items. Please see the > > minutes from the Minn meeting for more detaiil (really > > don't want to re-hash it all over again). > > > > As far as the micro-mobility work is concerned, an internet-draft was > > put together by Phil Roberts (see seamoby archives for info), and this > > has been passed onto the IRTF routing chair. > > One comment, Phil's draft references the existing MM Problem > Statement. Does this cause any problems, after the MM Problem > Statement Draft expires? If it is a normative reference, then yes. Otherwise I need to check. PatC From owner-seamoby@diameter.org Mon May 21 09:13: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 JAA08821 for ; Mon, 21 May 2001 09:13:39 -0400 (EDT) Received: (qmail 18672 invoked by alias); 21 May 2001 13:01:57 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 18666 invoked by uid 200); 21 May 2001 13:01:56 -0000 Received: (qmail 18656 invoked by uid 500); 21 May 2001 13:01:55 -0000 Date: Mon, 21 May 2001 06:01:55 -0700 From: Pat Calhoun To: john.loughney@nokia.com Cc: pcalhoun@diameter.org, Madjid.Nakhjiri@motorola.com, seamoby@diameter.org Subject: Re: [seamoby] RE: MM requirements (was: IRTF mm problem statement ) Message-ID: <20010521060155.C18132@charizard.diameter.org> Mail-Followup-To: john.loughney@nokia.com, pcalhoun@diameter.org, Madjid.Nakhjiri@motorola.com, seamoby@diameter.org References: <01D91AFB08B6D211BFD00008C7EABAE10680AFB5@eseis04nok> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01D91AFB08B6D211BFD00008C7EABAE10680AFB5@eseis04nok>; from john.loughney@nokia.com on Mon, May 21, 2001 at 10:09:39AM +0300 Sender: owner-seamoby@diameter.org Precedence: bulk On Mon, May 21, 2001 at 10:09:39AM +0300, john.loughney@nokia.com wrote: > I understand. Quick question, Phil R.'s problem statement on > Subnet Mobility references the current MM Problem statement. That's fine, but if he plans to publish it as an RFC, this may become a problem. > Either we could keep some of the existing problem in the > MM Problem statement and mention the work will be done by the > IRTF, or Phil can remove the reference from Phil R.'s > draft. I would remove the reference since the IESG has stated that the document cannot move along as-is. In any case, I see little use trying to polish this document, when it would be more worth our while to start the AP discovery document. > > Would you be wiling to start the effort given that you already have > > the nroff source of the MM problem statement? > > Sure, that would be fine. > Great. Looking forward to it. PatC From owner-seamoby@diameter.org Tue May 22 07:04:14 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 HAA13042 for ; Tue, 22 May 2001 07:04:13 -0400 (EDT) Received: (qmail 23628 invoked by alias); 22 May 2001 10:52:02 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 23622 invoked by uid 200); 22 May 2001 10:52:02 -0000 Received: (qmail 23617 invoked from network); 22 May 2001 10:52:00 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by c900656-a.plstn1.sfba.home.com with SMTP; 22 May 2001 10:52:00 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12774; Tue, 22 May 2001 07:02:47 -0400 (EDT) Message-Id: <200105221102.HAA12774@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: seamoby@cdma-2000.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [seamoby] I-D ACTION:draft-ietf-seamoby-paging-requirements-01.txt Date: Tue, 22 May 2001 07:02:47 -0400 Sender: owner-seamoby@diameter.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Context and Micro-mobility Routing Working Group of the IETF. Title : Requirements for an IP Mobile Node Alerting Protocol Author(s) : J. Kempf et al. Filename : draft-ietf-seamoby-paging-requirements-01.txt Pages : Date : 21-May-01 This document develops an architecture and a set of requirements needed to support alerting of hosts that are in dormant mode. The architecture and requirements are designed to guide development of an IP protocol for alerting dormant IP mobile hosts, commonly called paging. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-seamoby-paging-requirements-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-seamoby-paging-requirements-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-seamoby-paging-requirements-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010521131059.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-seamoby-paging-requirements-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-seamoby-paging-requirements-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010521131059.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-seamoby@diameter.org Tue May 22 09:49: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 JAA18188 for ; Tue, 22 May 2001 09:49:26 -0400 (EDT) Received: (qmail 24740 invoked by alias); 22 May 2001 13:37:00 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 24733 invoked by uid 200); 22 May 2001 13:37:00 -0000 Received: (qmail 24728 invoked from network); 22 May 2001 13:36:58 -0000 Received: from drama.navipath.com (root@216.67.14.8) by c900656-a.plstn1.sfba.home.com with SMTP; 22 May 2001 13:36:58 -0000 Received: (from root@localhost) by drama.navipath.com with id f4MDlLe31254; Tue, 22 May 2001 09:47:21 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA19837 for ietf-123-outbound.04@ietf.org; Tue, 22 May 2001 07:35:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA19527 for ; Tue, 22 May 2001 07:02:59 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12774; Tue, 22 May 2001 07:02:47 -0400 (EDT) Message-Id: <200105221102.HAA12774@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: seamoby@cdma-2000.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [seamoby] I-D ACTION:draft-ietf-seamoby-paging-requirements-01.txt Date: Tue, 22 May 2001 07:02:47 -0400 Sender: owner-seamoby@diameter.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Context and Micro-mobility Routing Working Group of the IETF. Title : Requirements for an IP Mobile Node Alerting Protocol Author(s) : J. Kempf et al. Filename : draft-ietf-seamoby-paging-requirements-01.txt Pages : Date : 21-May-01 This document develops an architecture and a set of requirements needed to support alerting of hosts that are in dormant mode. The architecture and requirements are designed to guide development of an IP protocol for alerting dormant IP mobile hosts, commonly called paging. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-seamoby-paging-requirements-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-seamoby-paging-requirements-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-seamoby-paging-requirements-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010521131059.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-seamoby-paging-requirements-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-seamoby-paging-requirements-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010521131059.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-seamoby@diameter.org Wed May 23 03:07: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 DAA28220 for ; Wed, 23 May 2001 03:07:49 -0400 (EDT) Received: (qmail 5526 invoked by alias); 23 May 2001 06:55:41 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 5520 invoked by uid 200); 23 May 2001 06:55:41 -0000 Received: (qmail 5515 invoked from network); 23 May 2001 06:55:39 -0000 Received: from unknown (HELO nortel-lab.tsinghua.edu.cn) (202.205.15.187) by c900656-a.plstn1.sfba.home.com with SMTP; 23 May 2001 06:55:39 -0000 Received: from oldcat ([202.205.15.182]) by nortel-lab.tsinghua.edu.cn (8.9.2/8.9.2) with SMTP id PAA04392 for ; Wed, 23 May 2001 15:06:41 +0900 (CDT) Message-ID: <001701c0e357$659c0ec0$b60fcdca@oldcat> From: "Hewu Li" To: Subject: [seamoby] majordomo@cdma-2000.org Date: Wed, 23 May 2001 15:10:06 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01C0E39A.7369B4B0" 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 This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C0E39A.7369B4B0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 c3Vic2NyaWJlIHNlYW1vYnkgeW91cl9lLW1haWxfYWRkcmVzcyANCg0K ------=_NextPart_000_0014_01C0E39A.7369B4B0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4zMTAzLjEwMDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5zdWJzY3JpYmUgc2VhbW9i eSB5b3VyX2UtbWFpbF9hZGRyZXNzIA0KPEJSPjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0014_01C0E39A.7369B4B0-- From owner-seamoby@diameter.org Wed May 23 09:40: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 JAA04866 for ; Wed, 23 May 2001 09:40:24 -0400 (EDT) Received: (qmail 8286 invoked by alias); 23 May 2001 13:28:07 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8280 invoked by uid 200); 23 May 2001 13:28:07 -0000 Received: (qmail 8275 invoked by uid 500); 23 May 2001 13:28:05 -0000 Date: Wed, 23 May 2001 06:28:05 -0700 From: Pat Calhoun To: seamoby@cdma-2000.org Subject: [seamoby] WG Last Call: draft-ietf-seamoby-paging-requirements-01.txt Message-ID: <20010523062805.F5124@charizard.diameter.org> Mail-Followup-To: seamoby@cdma-2000.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-seamoby@diameter.org Precedence: bulk This is the Working Group last call on the above Internet-Draft. If you have any comments, please send them to the list (or to the author if you prefer anonymity) by June 6th. PatC From owner-seamoby@diameter.org Wed May 23 13:30: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 NAA10512 for ; Wed, 23 May 2001 13:30:34 -0400 (EDT) Received: (qmail 12114 invoked by alias); 23 May 2001 17:18:04 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 12108 invoked by uid 200); 23 May 2001 17:18:04 -0000 Received: (qmail 12103 invoked from network); 23 May 2001 17:18:02 -0000 Received: from motgate3.mot.com (144.189.100.103) by c900656-a.plstn1.sfba.home.com with SMTP; 23 May 2001 17:18:02 -0000 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (motgate3 2.1) with ESMTP id KAA26452 for ; Wed, 23 May 2001 10:22:58 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id KAA02647 for ; Wed, 23 May 2001 10:29:13 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Wed, 23 May 2001 12:29:13 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B1B7BF9@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'john.loughney@nokia.com'" , Nakhjiri Madjid-MNAKHJI1 , seamoby@diameter.org Subject: [seamoby] RE: MM requirements (was: IRTF mm problem statement) Date: Wed, 23 May 2001 12:29:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk John, My replies below. -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Monday, May 21, 2001 2:05 AM To: Madjid.Nakhjiri; seamoby@diameter.org Subject: RE: MM requirements (was: IRTF mm problem statement) The current problem statement is used in 2 Internet Drafts as a refence. When I asked "should we let it die" - I really meant should we let the draft expire. MN>> So there would be no problem statement for MM, straight to requirements? MM was used as it was called that in the charter. However, after countless discussions, it was felt that MM had too much baggage, and the DT thought Local Mobility was more fitting term. MN>> I would make more sense to change the name to local mobility then, if you are keeping the scope the same, doesn't it? > " * How to discover the bandwidth, cost, error rate (and other > properties) of candidate Access Links. > * Involving QoS characteristics as part of the handover process." > > These two sound like the stuff in CNP, do we want to start from there? I think CNP is an example of what we want to do, but let's not take it as a given. MN>> sure, it is not a given, but a good place to start the technical discussion. > * Enable plug and play capabilities for Mobile Devices, Access > Routers/Access Links." > > the text that is provided for this (in 4.3.3) talks about capability > discovery of neighboring APs. Is that the same as plug and play > capability, you say? Yes. MN>> I don't quite see plug and play capability to be the same as capability discovery. From the MN's point of view, plug and play would include, capability discovery AND service/ policy negotiation, handover, maybe context transfer as well. Don't you think? Regards, Madjid From owner-seamoby@diameter.org Wed May 23 18:05: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 SAA16338 for ; Wed, 23 May 2001 18:05:46 -0400 (EDT) Received: (qmail 19134 invoked by alias); 23 May 2001 21:53:22 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 19127 invoked by uid 200); 23 May 2001 21:53:21 -0000 Received: (qmail 19122 invoked from network); 23 May 2001 21:53:18 -0000 Received: from softdnserror (HELO meshpdc.meshnetworks.com) (205.245.27.196) by c900656-a.plstn1.sfba.home.com with SMTP; 23 May 2001 21:53:18 -0000 Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2650.21) id ; Wed, 23 May 2001 18:04:21 -0400 Message-ID: <0DF9FBC42474A24CA50F7A27FB08E048445487@meshpdc.meshnetworks.com> From: Phillip Neumiller To: "'Nakhjiri Madjid-MNAKHJI1'" , "'john.loughney@nokia.com'" , seamoby@diameter.org Subject: RE: [seamoby] RE: MM requirements (was: IRTF mm problem statement ) Date: Wed, 23 May 2001 18:04:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk I believe CNP can be useful Madjid. However, nobody seems to be getting excited about it except us. Perhaps we should just go ahead and update the draft together and add others if they become interested. Its is definitely part of the SeaMoby charter. Why don't you take a pass at the draft Madjid (you can add anything you want from my rejected Mobicom paper :-)). Then paste the draft to the list to see if we can get any interest. Peter may be interested but he's been pretty busy. Thanks, -Phil -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] Sent: Wednesday, May 23, 2001 1:29 PM To: 'john.loughney@nokia.com'; Nakhjiri Madjid-MNAKHJI1; seamoby@diameter.org Subject: [seamoby] RE: MM requirements (was: IRTF mm problem statement) John, My replies below. -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Monday, May 21, 2001 2:05 AM To: Madjid.Nakhjiri; seamoby@diameter.org Subject: RE: MM requirements (was: IRTF mm problem statement) The current problem statement is used in 2 Internet Drafts as a refence. When I asked "should we let it die" - I really meant should we let the draft expire. MN>> So there would be no problem statement for MM, straight to requirements? MM was used as it was called that in the charter. However, after countless discussions, it was felt that MM had too much baggage, and the DT thought Local Mobility was more fitting term. MN>> I would make more sense to change the name to local mobility then, if you are keeping the scope the same, doesn't it? > " * How to discover the bandwidth, cost, error rate (and other > properties) of candidate Access Links. > * Involving QoS characteristics as part of the handover process." > > These two sound like the stuff in CNP, do we want to start from there? I think CNP is an example of what we want to do, but let's not take it as a given. MN>> sure, it is not a given, but a good place to start the technical discussion. > * Enable plug and play capabilities for Mobile Devices, Access > Routers/Access Links." > > the text that is provided for this (in 4.3.3) talks about capability > discovery of neighboring APs. Is that the same as plug and play > capability, you say? Yes. MN>> I don't quite see plug and play capability to be the same as capability discovery. From the MN's point of view, plug and play would include, capability discovery AND service/ policy negotiation, handover, maybe context transfer as well. Don't you think? Regards, Madjid From owner-seamoby@diameter.org Thu May 24 03:14:14 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 DAA08994 for ; Thu, 24 May 2001 03:14:13 -0400 (EDT) Received: (qmail 22731 invoked by alias); 24 May 2001 07:01:45 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 22725 invoked by uid 200); 24 May 2001 07:01:45 -0000 Received: (qmail 22720 invoked from network); 24 May 2001 07:01:42 -0000 Received: from mgw-x2.nokia.com (131.228.20.22) by c900656-a.plstn1.sfba.home.com with SMTP; 24 May 2001 07:01:42 -0000 Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f4O7D7m05331 for ; Thu, 24 May 2001 10:13:07 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 24 May 2001 10:12:50 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Thu, 24 May 2001 10:12:50 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680B006@eseis04nok> From: john.loughney@nokia.com To: Madjid.Nakhjiri@motorola.com, seamoby@diameter.org Subject: [seamoby] RE: MM requirements (was: IRTF mm problem statement) Date: Thu, 24 May 2001 10:12:48 +0300 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 Madjid, > MN>> So there would be no problem statement for MM, straight to > requirements? Nope, we will reuse some material from the existing draft and write a new problem statement. From the proposed charter: Jul 01 Submit Handoff Candidate Discovery Problem Statement This covers CNP; capability discovery and plug 'n play, in my mind. I will try to get started on this next week. I want to just work with the existing material from the MM design team before getting loads of comments. > MN>> I don't quite see plug and play capability to be the > same as capability discovery. From the MN's point of view, > plug and play would include, capability discovery > AND service/ policy negotiation, handover, maybe context > transfer as well. Don't you think? I think all will be involved, in some respects. This is all stuff we talked about in the MM design team, that is why my intention is to pull something together & then let people comment. John From owner-seamoby@diameter.org Thu May 24 07:27: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 HAA10909 for ; Thu, 24 May 2001 07:27:34 -0400 (EDT) Received: (qmail 23714 invoked by alias); 24 May 2001 11:12:26 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 23708 invoked by uid 200); 24 May 2001 11:12:26 -0000 Received: (qmail 23703 invoked from network); 24 May 2001 11:12:23 -0000 Received: from softdnserror (HELO meshpdc.meshnetworks.com) (205.245.27.196) by c900656-a.plstn1.sfba.home.com with SMTP; 24 May 2001 11:12:23 -0000 Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2650.21) id ; Thu, 24 May 2001 07:23:20 -0400 Message-ID: <0DF9FBC42474A24CA50F7A27FB08E048445488@meshpdc.meshnetworks.com> From: Phillip Neumiller To: "'Gary Kenward'" , "'seamoby@diameter.org'" Subject: RE: [seamoby] RE: MM requirements (was: IRTF mm problem statement ) Date: Thu, 24 May 2001 07:23:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0E443.EEA1C5D8" 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_01C0E443.EEA1C5D8 Content-Type: text/plain; charset="iso-8859-1" Well, I don't see any harm in you Nortel guys proposing your ideas. Since Madjid does not seem interested and Peter is too busy, I guess I will hold off for now. I am not interested on expounding on the problem statement for MM at this time. I am VERY interested in tight coupling of CT with seamless handovers and doing a more "enlightened" handover. These items are relatively new charter items and deserve a draft independent of CT protocol requirements. CNP will not dictate protocol requirements since it is more of a way to use CTP IMO. Thanks, Phil -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Wednesday, May 23, 2001 6:13 PM To: 'Phillip Neumiller' Subject: RE: [seamoby] RE: MM requirements (was: IRTF mm problem statement ) Phil: FYI: we (Hamid and I) believe that we have a ct solution that does not require CNP. We're just waiting for the appropriate moment for us to submit our drafts. Gary > -----Original Message----- > From: Phillip Neumiller [ mailto:PNeumiller@MeshNetworks.com ] > Sent: Wednesday, May 23, 2001 6:04 PM > To: 'Nakhjiri Madjid-MNAKHJI1'; 'john.loughney@nokia.com'; > seamoby@diameter.org > Subject: RE: [seamoby] RE: MM requirements (was: IRTF mm problem > statement ) > > > I believe CNP can be useful Madjid. However, nobody seems to be > getting excited about it except us. Perhaps we should just > go ahead and > update the draft together and add others if they become interested. > Its is definitely part of the SeaMoby charter. Why don't you take > a pass at the draft Madjid (you can add anything you want from my > rejected Mobicom paper :-)). Then paste the draft to the list to > see if we can get any interest. Peter may be interested but he's > been pretty busy. > > Thanks, > > -Phil > > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [ mailto:Madjid.Nakhjiri@motorola.com ] > Sent: Wednesday, May 23, 2001 1:29 PM > To: 'john.loughney@nokia.com'; Nakhjiri Madjid-MNAKHJI1; > seamoby@diameter.org > Subject: [seamoby] RE: MM requirements (was: IRTF mm problem > statement) > > > John, > > My replies below. > > -----Original Message----- > From: john.loughney@nokia.com [ mailto:john.loughney@nokia.com ] > Sent: Monday, May 21, 2001 2:05 AM > To: Madjid.Nakhjiri; seamoby@diameter.org > Subject: RE: MM requirements (was: IRTF mm problem statement) > > The current problem statement is used in 2 Internet Drafts > as a refence. When I asked "should we let it die" - I really > meant should we let the draft expire. > > MN>> So there would be no problem statement for MM, straight to > requirements? > > MM was used as it was called that in the charter. However, after > countless discussions, it was felt that MM had too much baggage, > and the DT thought Local Mobility was more fitting term. > > MN>> I would make more sense to change the name to local > mobility then, > if you are keeping the scope the same, doesn't it? > > > " * How to discover the bandwidth, cost, error rate (and other > > properties) of candidate Access Links. > > * Involving QoS characteristics as part of the > handover process." > > > > These two sound like the stuff in CNP, do we want to start > from there? > > I think CNP is an example of what we want to do, but let's > not take it as a given. > > MN>> sure, it is not a given, but a good place to start the technical > discussion. > > > * Enable plug and play capabilities for Mobile Devices, Access > > Routers/Access Links." > > > > the text that is provided for this (in 4.3.3) talks about capability > > discovery of neighboring APs. Is that the same as plug and play > > capability, you say? > > Yes. > > MN>> I don't quite see plug and play capability to be the > same as capability > discovery. > From the MN's point of view, plug and play would include, capability > discovery > AND service/ policy negotiation, handover, maybe context > transfer as well. > Don't you think? > > Regards, > Madjid > ------_=_NextPart_001_01C0E443.EEA1C5D8 Content-Type: text/html; charset="iso-8859-1" RE: [seamoby] RE: MM requirements (was: IRTF mm problem statement )
Well,
 
I don't see any harm in you Nortel guys proposing your ideas.  Since Madjid does not
seem interested and Peter is too busy, I guess I will hold off for now.  I am not interested
on expounding on the problem statement for MM at this time.  I am VERY interested
in tight coupling of CT with seamless handovers and doing a more "enlightened" handover.
These items are relatively new charter items and deserve a draft independent of CT
protocol requirements.  CNP will not dictate protocol requirements since it is more of a
way to use CTP IMO.
 
Thanks,
 
Phil
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Wednesday, May 23, 2001 6:13 PM
To: 'Phillip Neumiller'
Subject: RE: [seamoby] RE: MM requirements (was: IRTF mm problem statement )

Phil:

  FYI: we (Hamid and I) believe that we have a ct solution that
does not require CNP. We're just waiting for the appropriate moment
for us to submit our drafts.

Gary

> -----Original Message-----
> From: Phillip Neumiller [mailto:PNeumiller@MeshNetworks.com]
> Sent: Wednesday, May 23, 2001 6:04 PM
> To: 'Nakhjiri Madjid-MNAKHJI1'; 'john.loughney@nokia.com';
> seamoby@diameter.org
> Subject: RE: [seamoby] RE: MM requirements (was: IRTF mm problem
> statement )
>
>
> I believe CNP can be useful Madjid.  However, nobody seems to be
> getting excited about it except us.  Perhaps we should just
> go ahead and
> update the draft together and add others if they become interested.
> Its is definitely part of the SeaMoby charter.  Why don't you take
> a pass at the draft Madjid (you can add anything you want from my
> rejected Mobicom paper :-)).  Then paste the draft to the list to
> see if we can get any interest.  Peter may be interested but he's
> been pretty busy.
>
> Thanks,
>
> -Phil
>
> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
> Sent: Wednesday, May 23, 2001 1:29 PM
> To: 'john.loughney@nokia.com'; Nakhjiri Madjid-MNAKHJI1;
> seamoby@diameter.org
> Subject: [seamoby] RE: MM requirements (was: IRTF mm problem
> statement)
>
>
> John,
>
> My replies below.
>
> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: Monday, May 21, 2001 2:05 AM
> To: Madjid.Nakhjiri; seamoby@diameter.org
> Subject: RE: MM requirements (was: IRTF mm problem statement)
>
> The current problem statement is used in 2 Internet Drafts
> as a refence.  When I asked "should we let it die" - I really
> meant should we let the draft expire.
>
> MN>> So there would be no problem statement for MM, straight to
> requirements?
>
> MM was used as it was called that in the charter.  However, after
> countless discussions, it was felt that MM had too much baggage,
> and the DT thought Local Mobility was more fitting term.
>
> MN>> I would make more sense to change the name to local
> mobility then,
> if you are keeping the scope the same, doesn't it?
> 
> > "    *  How to discover the bandwidth, cost, error rate (and other
> >        properties) of candidate Access Links.
> >     *  Involving QoS characteristics as part of the
> handover process."
> >
> > These two sound like the stuff in CNP, do we want to start
> from there?
>
> I think CNP is an example of what we want to do, but let's
> not take it as a given.
>
> MN>> sure, it is not a given, but a good place to start the technical
> discussion.
>
> >     *  Enable plug and play capabilities for Mobile Devices, Access
> >        Routers/Access Links."
> >
> > the text that is provided for this (in 4.3.3) talks about capability
> > discovery of neighboring APs. Is that the same as plug and play
> > capability, you say?
>
> Yes.
>
> MN>> I don't quite see plug and play capability to be the
> same as capability
> discovery.
> From the MN's point of view, plug and play would include, capability
> discovery
> AND service/ policy negotiation, handover, maybe context
> transfer as well.
> Don't you think?
>
> Regards,
> Madjid
>

------_=_NextPart_001_01C0E443.EEA1C5D8-- From owner-seamoby@diameter.org Fri May 25 06:14: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 GAA14225 for ; Fri, 25 May 2001 06:14:32 -0400 (EDT) Received: (qmail 9660 invoked by alias); 25 May 2001 10:02:21 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 9654 invoked by uid 200); 25 May 2001 10:02:21 -0000 Received: (qmail 9649 invoked from network); 25 May 2001 10:02:19 -0000 Received: from mx0.gmx.net (213.165.64.100) by c900656-a.plstn1.sfba.home.com with SMTP; 25 May 2001 10:02:19 -0000 Received: (qmail 16450 invoked by alias); 25 May 2001 10:13:38 -0000 Delivered-To: GMX delivery to claudia%carmendorn@gmx.de Received: (qmail 16441 invoked by uid 0); 25 May 2001 10:13:38 -0000 Date: Fri, 25 May 2001 12:13:38 +0200 (MEST) From: Carmen Dornbach MIME-Version: 1.0 X-Priority: 3 (Normal) X-Authenticated-Sender: #0010896236@gmx.net X-Authenticated-IP: [195.93.64.171] Message-ID: <29063.990785618@www31.gmx.net> X-Mailer: WWW-Mail 1.5 (Global Message Exchange) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit To: claudia%CarmenDorn@gmx.de Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 8bit Hallo, wir sind 9 heiße und hemmungslose Girls, nämlich Babette, Moni, Carola, Angelique, Michelle, Jessica, Melissa, Iris und Sandra, die ein geiles tabuloses Telefonat, oder bei gefallen einen heißen Seitensprung suchen. Ganz wie Du willst :o) Erreichen kannst Du uns direkt unter Telefonnummer: 019085/4794* Am Telefon können wir uns gleich ein Date ausmachen. Oder hast Du etwa keine Lust auf einen wilden One Night Stand ? Wir schon :o) ... also beeil Dich .... fg Wenn Du uns vorher sehen möchtest, dann schau einfach mal auf unserer Homepage vorbei ... dort erfährst Du einiges mehr über uns ... www.datingfon.de Unsere intimsten Geheimnisse verraten wir Dir natürlich nur direkt ... wir können sie Dir ja am Telefon ins Ohr flüstern ... Also alles ist möglich weil wir auf alles Lust haben und noch so vieles ausprobieren wollen .... hoffentlich mit Dir. ... 019085/4794* Lass uns nicht so lange warten .... Bussi bis gleich Deine süssen Girls (* E.p. DM 3,63/min.) -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net -- U2 Konzertreisen inkl. VIP-Package Hier Eventreisen zur U2-Tour bei Getgo.de online buchen! http://www.getgo.de/cgi-bin/TDoc.dll?doc=reisen/rei_kon_sta&affiliate=GMX From owner-seamoby@diameter.org Fri May 25 12:35:42 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 MAA20881 for ; Fri, 25 May 2001 12:35:41 -0400 (EDT) Received: (qmail 14008 invoked by alias); 25 May 2001 16:23:50 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 14002 invoked by uid 200); 25 May 2001 16:23:50 -0000 Received: (qmail 13997 invoked from network); 25 May 2001 16:23:48 -0000 Received: from patan.sun.com (192.18.98.43) by c900656-a.plstn1.sfba.home.com with SMTP; 25 May 2001 16:23:48 -0000 Received: from heliopolis.eng.sun.com ([152.70.1.39]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27055 for ; Fri, 25 May 2001 10:35:09 -0600 (MDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id JAA27403 for ; Fri, 25 May 2001 09:35:09 -0700 (PDT) Message-Id: <200105251635.JAA27403@heliopolis.eng.sun.com> Date: Fri, 25 May 2001 09:35:09 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: [seamoby] Next Steps in Paging? To: seamoby@diameter.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: YVUb5JrtpLlFCADUephFCA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-seamoby@diameter.org Precedence: bulk Pat, Now that the requirements are done what should be the next steps for paging? I realize that the requirements still need to complete WG last call and IESG last call, but we still have 2 months until London and it seems like we could press forward in some fashion. Any suggestions? jak From owner-seamoby@diameter.org Fri May 25 12:41: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 MAA21025 for ; Fri, 25 May 2001 12:41:30 -0400 (EDT) Received: (qmail 14513 invoked by alias); 25 May 2001 16:29:39 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 14507 invoked by uid 200); 25 May 2001 16:29:39 -0000 Received: (qmail 14501 invoked by uid 500); 25 May 2001 16:29:37 -0000 Date: Fri, 25 May 2001 09:29:37 -0700 From: Pat Calhoun To: James Kempf Cc: seamoby@diameter.org Subject: Re: [seamoby] Next Steps in Paging? Message-ID: <20010525092937.W30735@charizard.diameter.org> Mail-Followup-To: James Kempf , seamoby@diameter.org References: <200105251635.JAA27403@heliopolis.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200105251635.JAA27403@heliopolis.eng.sun.com>; from James.Kempf@Sun.COM on Fri, May 25, 2001 at 09:35:09AM -0700 Sender: owner-seamoby@diameter.org Precedence: bulk On Fri, May 25, 2001 at 09:35:09AM -0700, James Kempf wrote: > Now that the requirements are done what should be the next steps for > paging? I realize that the requirements still need to complete WG > last call and IESG last call, but we still have 2 months until London > and it seems like we could press forward in some fashion. Any suggestions? Although premature, it would be interesting to know if anyone is planning on submitting a protocol to be evaluated against the requirements. Of course, since the requirements haven't been through a complete last call, and IESG review, it is premature, but it would at least provide us with an idea of how to proceed. PatC From owner-seamoby@diameter.org Fri May 25 13:15: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 NAA21705 for ; Fri, 25 May 2001 13:15:50 -0400 (EDT) Received: (qmail 15121 invoked by alias); 25 May 2001 17:00:19 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 15115 invoked by uid 200); 25 May 2001 17:00:19 -0000 Received: (qmail 15110 invoked from network); 25 May 2001 17:00:17 -0000 Received: from unknown (HELO zrc2s03g.nortelnetworks.com) (47.103.122.66) by c900656-a.plstn1.sfba.home.com with SMTP; 25 May 2001 17:00:17 -0000 Received: from zcars04e.nortelnetworks.com (zcars04e.ca.nortel.com [47.129.242.56]) by zrc2s03g.nortelnetworks.com (8.9.3+Sun/8.9.1) with ESMTP id MAA16849 for ; Fri, 25 May 2001 12:12:10 -0500 (CDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Fri, 25 May 2001 13:10:46 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 25 May 2001 13:10:44 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5BD5@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Phillip Neumiller'" , "'seamoby@diameter.org'" Subject: RE: [seamoby] RE: MM requirements (was: IRTF mm problem statement ) Date: Fri, 25 May 2001 13:10:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0E53D.A1556D70" 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_01C0E53D.A1556D70 Content-Type: text/plain; charset="ISO-8859-1" Of course there's no harm in our ideas. There's no harm in being able to assess different approaches either. Gary -----Original Message----- From: Phillip Neumiller [mailto:PNeumiller@MeshNetworks.com] Sent: Thursday, May 24, 2001 7:23 AM To: Kenward, Gary [WDLN2:AN10:EXCH]; 'seamoby@diameter.org' Subject: RE: [seamoby] RE: MM requirements (was: IRTF mm problem statement ) Well, I don't see any harm in you Nortel guys proposing your ideas. Since Madjid does not seem interested and Peter is too busy, I guess I will hold off for now. I am not interested on expounding on the problem statement for MM at this time. I am VERY interested in tight coupling of CT with seamless handovers and doing a more "enlightened" handover. These items are relatively new charter items and deserve a draft independent of CT protocol requirements. CNP will not dictate protocol requirements since it is more of a way to use CTP IMO. Thanks, Phil -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Wednesday, May 23, 2001 6:13 PM To: 'Phillip Neumiller' Subject: RE: [seamoby] RE: MM requirements (was: IRTF mm problem statement ) Phil: FYI: we (Hamid and I) believe that we have a ct solution that does not require CNP. We're just waiting for the appropriate moment for us to submit our drafts. Gary > -----Original Message----- > From: Phillip Neumiller [ mailto:PNeumiller@MeshNetworks.com ] > Sent: Wednesday, May 23, 2001 6:04 PM > To: 'Nakhjiri Madjid-MNAKHJI1'; 'john.loughney@nokia.com'; > seamoby@diameter.org > Subject: RE: [seamoby] RE: MM requirements (was: IRTF mm problem > statement ) > > > I believe CNP can be useful Madjid. However, nobody seems to be > getting excited about it except us. Perhaps we should just > go ahead and > update the draft together and add others if they become interested. > Its is definitely part of the SeaMoby charter. Why don't you take > a pass at the draft Madjid (you can add anything you want from my > rejected Mobicom paper :-)). Then paste the draft to the list to > see if we can get any interest. Peter may be interested but he's > been pretty busy. > > Thanks, > > -Phil > > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [ mailto:Madjid.Nakhjiri@motorola.com ] > Sent: Wednesday, May 23, 2001 1:29 PM > To: 'john.loughney@nokia.com'; Nakhjiri Madjid-MNAKHJI1; > seamoby@diameter.org > Subject: [seamoby] RE: MM requirements (was: IRTF mm problem > statement) > > > John, > > My replies below. > > -----Original Message----- > From: john.loughney@nokia.com [ mailto:john.loughney@nokia.com ] > Sent: Monday, May 21, 2001 2:05 AM > To: Madjid.Nakhjiri; seamoby@diameter.org > Subject: RE: MM requirements (was: IRTF mm problem statement) > > The current problem statement is used in 2 Internet Drafts > as a refence. When I asked "should we let it die" - I really > meant should we let the draft expire. > > MN>> So there would be no problem statement for MM, straight to > requirements? > > MM was used as it was called that in the charter. However, after > countless discussions, it was felt that MM had too much baggage, > and the DT thought Local Mobility was more fitting term. > > MN>> I would make more sense to change the name to local > mobility then, > if you are keeping the scope the same, doesn't it? > > > " * How to discover the bandwidth, cost, error rate (and other > > properties) of candidate Access Links. > > * Involving QoS characteristics as part of the > handover process." > > > > These two sound like the stuff in CNP, do we want to start > from there? > > I think CNP is an example of what we want to do, but let's > not take it as a given. > > MN>> sure, it is not a given, but a good place to start the technical > discussion. > > > * Enable plug and play capabilities for Mobile Devices, Access > > Routers/Access Links." > > > > the text that is provided for this (in 4.3.3) talks about capability > > discovery of neighboring APs. Is that the same as plug and play > > capability, you say? > > Yes. > > MN>> I don't quite see plug and play capability to be the > same as capability > discovery. > From the MN's point of view, plug and play would include, capability > discovery > AND service/ policy negotiation, handover, maybe context > transfer as well. > Don't you think? > > Regards, > Madjid > ------_=_NextPart_001_01C0E53D.A1556D70 Content-Type: text/html; charset="ISO-8859-1" RE: [seamoby] RE: MM requirements (was: IRTF mm problem statement )
Of course there's no harm in our ideas.
 
There's no harm in being able to assess different approaches either.
 
Gary
-----Original Message-----
From: Phillip Neumiller [mailto:PNeumiller@MeshNetworks.com]
Sent: Thursday, May 24, 2001 7:23 AM
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'seamoby@diameter.org'
Subject: RE: [seamoby] RE: MM requirements (was: IRTF mm problem statement )

Well,
 
I don't see any harm in you Nortel guys proposing your ideas.  Since Madjid does not
seem interested and Peter is too busy, I guess I will hold off for now.  I am not interested
on expounding on the problem statement for MM at this time.  I am VERY interested
in tight coupling of CT with seamless handovers and doing a more "enlightened" handover.
These items are relatively new charter items and deserve a draft independent of CT
protocol requirements.  CNP will not dictate protocol requirements since it is more of a
way to use CTP IMO.
 
Thanks,
 
Phil
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Wednesday, May 23, 2001 6:13 PM
To: 'Phillip Neumiller'
Subject: RE: [seamoby] RE: MM requirements (was: IRTF mm problem statement )

Phil:

  FYI: we (Hamid and I) believe that we have a ct solution that
does not require CNP. We're just waiting for the appropriate moment
for us to submit our drafts.

Gary

> -----Original Message-----
> From: Phillip Neumiller [mailto:PNeumiller@MeshNetworks.com]
> Sent: Wednesday, May 23, 2001 6:04 PM
> To: 'Nakhjiri Madjid-MNAKHJI1'; 'john.loughney@nokia.com';
> seamoby@diameter.org
> Subject: RE: [seamoby] RE: MM requirements (was: IRTF mm problem
> statement )
>
>
> I believe CNP can be useful Madjid.  However, nobody seems to be
> getting excited about it except us.  Perhaps we should just
> go ahead and
> update the draft together and add others if they become interested.
> Its is definitely part of the SeaMoby charter.  Why don't you take
> a pass at the draft Madjid (you can add anything you want from my
> rejected Mobicom paper :-)).  Then paste the draft to the list to
> see if we can get any interest.  Peter may be interested but he's
> been pretty busy.
>
> Thanks,
>
> -Phil
>
> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
> Sent: Wednesday, May 23, 2001 1:29 PM
> To: 'john.loughney@nokia.com'; Nakhjiri Madjid-MNAKHJI1;
> seamoby@diameter.org
> Subject: [seamoby] RE: MM requirements (was: IRTF mm problem
> statement)
>
>
> John,
>
> My replies below.
>
> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: Monday, May 21, 2001 2:05 AM
> To: Madjid.Nakhjiri; seamoby@diameter.org
> Subject: RE: MM requirements (was: IRTF mm problem statement)
>
> The current problem statement is used in 2 Internet Drafts
> as a refence.  When I asked "should we let it die" - I really
> meant should we let the draft expire.
>
> MN>> So there would be no problem statement for MM, straight to
> requirements?
>
> MM was used as it was called that in the charter.  However, after
> countless discussions, it was felt that MM had too much baggage,
> and the DT thought Local Mobility was more fitting term.
>
> MN>> I would make more sense to change the name to local
> mobility then,
> if you are keeping the scope the same, doesn't it?
> 
> > "    *  How to discover the bandwidth, cost, error rate (and other
> >        properties) of candidate Access Links.
> >     *  Involving QoS characteristics as part of the
> handover process."
> >
> > These two sound like the stuff in CNP, do we want to start
> from there?
>
> I think CNP is an example of what we want to do, but let's
> not take it as a given.
>
> MN>> sure, it is not a given, but a good place to start the technical
> discussion.
>
> >     *  Enable plug and play capabilities for Mobile Devices, Access
> >        Routers/Access Links."
> >
> > the text that is provided for this (in 4.3.3) talks about capability
> > discovery of neighboring APs. Is that the same as plug and play
> > capability, you say?
>
> Yes.
>
> MN>> I don't quite see plug and play capability to be the
> same as capability
> discovery.
> From the MN's point of view, plug and play would include, capability
> discovery
> AND service/ policy negotiation, handover, maybe context
> transfer as well.
> Don't you think?
>
> Regards,
> Madjid
>

------_=_NextPart_001_01C0E53D.A1556D70-- From owner-seamoby@diameter.org Fri May 25 17:42: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 RAA25668 for ; Fri, 25 May 2001 17:42:32 -0400 (EDT) Received: (qmail 17175 invoked by alias); 25 May 2001 21:29:55 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 17169 invoked by uid 200); 25 May 2001 21:29:55 -0000 Received: (qmail 17164 invoked from network); 25 May 2001 21:29:53 -0000 Received: from ftpbox.mot.com (129.188.136.101) by c900656-a.plstn1.sfba.home.com with SMTP; 25 May 2001 21:29:53 -0000 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id OAA26809 for ; Fri, 25 May 2001 14:41:16 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id OAA12581 for ; Fri, 25 May 2001 14:41:16 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19) id ; Fri, 25 May 2001 16:41:15 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B1B7C10@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Phillip Neumiller'" , "'john.loughney@nokia.com'" , seamoby@diameter.org Subject: RE: [seamoby] RE: MM requirements (was: IRTF mm problem statement ) Date: Fri, 25 May 2001 16:41:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Thanks for the Mobicom paper, I did not find CNP draft version 1. I only found version 0. Could you send that to me too. Regards, Madjid -----Original Message----- From: Phillip Neumiller [mailto:PNeumiller@MeshNetworks.com] Sent: Wednesday, May 23, 2001 5:04 PM To: Nakhjiri Madjid-MNAKHJI1; 'john.loughney@nokia.com'; seamoby@diameter.org Subject: RE: [seamoby] RE: MM requirements (was: IRTF mm problem statement) I believe CNP can be useful Madjid. However, nobody seems to be getting excited about it except us. Perhaps we should just go ahead and update the draft together and add others if they become interested. Its is definitely part of the SeaMoby charter. Why don't you take a pass at the draft Madjid (you can add anything you want from my rejected Mobicom paper :-)). Then paste the draft to the list to see if we can get any interest. Peter may be interested but he's been pretty busy. Thanks, -Phil -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] Sent: Wednesday, May 23, 2001 1:29 PM To: 'john.loughney@nokia.com'; Nakhjiri Madjid-MNAKHJI1; seamoby@diameter.org Subject: [seamoby] RE: MM requirements (was: IRTF mm problem statement) John, My replies below. -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Monday, May 21, 2001 2:05 AM To: Madjid.Nakhjiri; seamoby@diameter.org Subject: RE: MM requirements (was: IRTF mm problem statement) The current problem statement is used in 2 Internet Drafts as a refence. When I asked "should we let it die" - I really meant should we let the draft expire. MN>> So there would be no problem statement for MM, straight to requirements? MM was used as it was called that in the charter. However, after countless discussions, it was felt that MM had too much baggage, and the DT thought Local Mobility was more fitting term. MN>> I would make more sense to change the name to local mobility then, if you are keeping the scope the same, doesn't it? > " * How to discover the bandwidth, cost, error rate (and other > properties) of candidate Access Links. > * Involving QoS characteristics as part of the handover process." > > These two sound like the stuff in CNP, do we want to start from there? I think CNP is an example of what we want to do, but let's not take it as a given. MN>> sure, it is not a given, but a good place to start the technical discussion. > * Enable plug and play capabilities for Mobile Devices, Access > Routers/Access Links." > > the text that is provided for this (in 4.3.3) talks about capability > discovery of neighboring APs. Is that the same as plug and play > capability, you say? Yes. MN>> I don't quite see plug and play capability to be the same as capability discovery. From the MN's point of view, plug and play would include, capability discovery AND service/ policy negotiation, handover, maybe context transfer as well. Don't you think? Regards, Madjid From owner-seamoby@diameter.org Tue May 29 04:43:05 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA27454 for ; Tue, 29 May 2001 04:43:03 -0400 (EDT) Received: (qmail 12242 invoked by alias); 29 May 2001 08:30:21 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 12235 invoked by uid 200); 29 May 2001 08:30:20 -0000 Received: (qmail 12230 invoked from network); 29 May 2001 08:30:18 -0000 Received: from unknown (HELO queen.es.sigma.se) (195.163.68.46) by c900656-a.plstn1.sfba.home.com with SMTP; 29 May 2001 08:30:18 -0000 Received: by queen.es.sigma.se with Internet Mail Service (5.5.2650.21) id ; Tue, 29 May 2001 10:41:57 +0200 Message-ID: <960FCE94AC10D1119EFF00A02416D7EA02156691@queen.es.sigma.se> From: Jonas Norberg Subject: [seamoby] Sigma and Bluetooth @ Your Service Date: Tue, 29 May 2001 10:41:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0E81B.37EBC020" 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_000_01C0E81B.37EBC020 Content-Type: text/plain; charset="iso-8859-1" Dear Sir/Madam, As you may know Sigma is a high-profile developer of Bluetooth technology with a lot of experience in the filed. One of the areas that we have a particular knowledge in is Bluetooth headset, phones and accessories to this. (http://www.sigma.se/english/operations/lasmer/Cases.asp?Cid=25) We also have some "building" blocks that we can use in some products for our customers that would save a lot of time in software development in a Bluetooth project. For instance our own Bluetooth Protocol Stack that has already been used in some products. Sigma is a design-house in Europe with main-office in Sweden. We're around 3300 engineers. The branches we often work in is the automotive, tele/data industry as well as in the medical technology field. A short list of some of Sigma's reference projects within the Bluetooth area: * A headset for communication against either a cellular phone or another headset. Within the project we designed a complete qualified Bluetooth stack including the headset profile and all necessary hard ware. * Design-concept for automotive wireless hands-free. * R&D of a product that can be used as a information zone using Bluetooth. Sigma had a big project group involved in the product that allows the user to get up-to-date information into the mobile when entering shops. * Design of Bluetooth low-level protocol analyzer. * Design of gateway CAN-Bluetooth. * Distributor of Bluetooth development tools and training seminars (www.comtec.sigma.se) This was just a short presentation of us and I do believe that we can help you in any kind of project, not only with wireless issues. Maybe you or someone at your company are interested in the Bluetooth field and maybe even in a co-operation with Sigma, as we are one of the leading consultancy firms in Bluetooth technology and embedded systems solutions. Why not send me an e-mail or call me if you have any questions what Sigma is doing or what we can do. If you are going to the Bluetooth Congress next week in Monte Carlo I would gladly have a chat with you or someone from your company. I'm going to be in booth D6, the Sigma booth. Best regards Jonas Norberg Business Developer Bluetooth Solutions Sigma Exallon Systems AB +46 40 665 92 52 (Direct) http://www.es.sigma.se http://www.sigma.se <> ------_=_NextPart_000_01C0E81B.37EBC020 Content-Type: application/octet-stream; name="Jonas Norberg (E-mail).vcf" Content-Disposition: attachment; filename="Jonas Norberg (E-mail).vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Norberg;Jonas FN:Jonas Norberg (E-mail) ORG:Sigma Exallon Systems AB;Embedded Systems TITLE:Business Developer Bluetooth TEL;WORK;VOICE:+46 (40) 665 92 52 TEL;CELL;VOICE:+46 (703) 79 10 37 TEL;WORK;FAX:+46 (40) 665 92 52 ADR;WORK:;;Dockplatsen 1;Malm=F6;;211 19;Sweden LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Dockplatsen 1=3D0D=3D0AMalm=3DF6 = 211 19=3D0D=3D0ASweden EMAIL;PREF;INTERNET:jonas.norberg@es.sigma.se REV:20010507T143146Z END:VCARD ------_=_NextPart_000_01C0E81B.37EBC020-- From owner-seamoby@diameter.org Tue May 29 13:54:08 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07949 for ; Tue, 29 May 2001 13:53:56 -0400 (EDT) Received: (qmail 19500 invoked by alias); 29 May 2001 17:36:08 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 19494 invoked by uid 200); 29 May 2001 17:36:07 -0000 Received: (qmail 19487 invoked from network); 29 May 2001 17:36:03 -0000 Received: from cpimssmtpu08.email.msn.com (207.46.181.83) by c900656-a.plstn1.sfba.home.com with SMTP; 29 May 2001 17:36:03 -0000 Received: from 6egud ([63.30.138.13]) by cpimssmtpu08.email.msn.com with Microsoft SMTPSVC(5.0.2195.3225); Tue, 29 May 2001 10:43:48 -0700 Message-ID: <010701c0e866$a318e5c0$9e0bfea9@6egud> From: "MC Didone" To: Subject: [seamoby] IP Security System Architect Opportunity Date: Tue, 29 May 2001 13:39:23 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C6_01C0E844.C58016A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-OriginalArrivalTime: 29 May 2001 17:43:49.0224 (UTC) FILETIME=[EAEF6680:01C0E866] Sender: owner-seamoby@diameter.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00C6_01C0E844.C58016A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello,=20 I am with ARC Inc. an Executive Search and Recruiting organization. We = have a very specific opportunity with a Mobile Wireless Internet = Technology Company. We are looking for very specific, highly technical, = qualified candidates for this great opportunity. In doing research on = the Internet, I came across the IETF's IPsec thread.=20 Since your background, experience and interests are most likely in IP = Security, I thought you might be interested in or know of a colleague or = working professional that might be interested in our opportunity. =20 We are seeking an IP Security System Architect. We are looking for = candidates who can design the security at the chip level. As I mentioned, our client is a venture stage Mobile Wireless Internet = Technology Company. They are developing a next generation wireless = communication system. It is a data-centric wireless communication = system that provides multimedia services (voice, data, video, and = location) to mobile personal Internet devices. They achieve this = through the use of an advanced, patented IP-based peer-to-peer ad hoc = networking and a high performance wireless modems.=20 The successful candidate would be able to fulfill the following position = requirements: IP Security System Architect=20 Looking for a bright and enthusiastic individual to provide the security = system design and to oversee the development of that design for a = wireless IP network designed to support mobile subscribers. Specific Responsibilities a.. Develop the network security requirements for a wireless IP based = designed product to serve mobile voice, data, and video subscribers.=20 b.. Provide the network security design for this wireless IP based = network, providing an embedded solution that encompasses the = subscriber's transceiver device, wireless routers, intelligent access = points, and standard infrastructure elements.=20 c.. Architect a solution based on the use of industry standards and = commercially available products.=20 d.. Work with selected vendors to ensure timely delivery and = compliance to specifications.=20 e.. Lead the implementation of the selected security solution.=20 f.. Write, publish and present technical white papers on security.=20 g.. Articulate a vision of security for the near- and long-terms.=20 Minimum Qualifications=20 a.. MSEE/BSEE/CS with a minimum of 10 years of network security design = experience.=20 b.. Advanced degree preferred.=20 Specific Network Security Experience=20 =20 =B7 Experience providing the embedded network security design = for a telecommunications network and/or an Internet based network.=20 =B7 Experience with embedded network security system designs = that provide the following: authentication, access control, data = integrity, confidentiality, and intrusion detection and analysis.=20 =B7 Experience providing embedded network security design in a = wireless communications system.=20 =B7 Highly familiar with secure operating systems, asymmetric = and symmetric key cryptographic approaches, certificate management = systems, key management systems, authentication token exchange = protocols, the vulnerabilities of VPN products, and bandwidth = optimization approaches for deployment of security solutions in a = wireless environment.=20 The successful candidate will possess strong interpersonal and = negotiation skills and will fit in well as a team player in a close = knit, fast moving multidisciplinary environment. This individual will = have good command of oral and written presentation skills, and will be = flexible, independent and able to work and communicate effectively at = all levels, and with a variety of organizations and vendors.=20 I was wondering if you would be interested in hearing about this = exciting career opportunity or if you know anyone that might be = interested in our opportunity. =20 Anyone interested in pursuing this opportunity should email me a full = resume with contact information as soon as possible and / or call me at = their earliest convenience. I can be reached toll-free at 877-331-3715. = =20 Thank you for taking the time to read this email and forward my contact = information to any interested parties. =20 Regards, MC Didone Executive Recruiter ARC Incorporated 877-331-3715 mcdidone@hotmail.com =20 ------=_NextPart_000_00C6_01C0E844.C58016A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello, 

I am=20 with ARC Inc. an Executive Search and Recruiting organization.  We = have a=20 very specific opportunity with a Mobile Wireless Internet Technology=20 Company.  We are looking for very specific, highly technical, = qualified=20 candidates for this great opportunity.  In doing research on the = Internet,=20 I came across the IETF's IPsec thread.=20

Since=20 your background, experience and interests are most likely in IP = Security, I=20 thought you might be interested in or know of a colleague or working=20 professional that might be interested in our opportunity. =20

We=20 are seeking an IP Security System Architect.  We are looking = for=20 candidates who can design the security at the chip level.

As I=20 mentioned, our client is a venture stage Mobile Wireless Internet = Technology=20 Company.  They are = developing a next=20 generation wireless communication system. =20 It is a data-centric wireless communication system that provides=20 multimedia services (voice, data, video, and location) to mobile = personal=20 Internet devices.  They = achieve this=20 through the use of an advanced, patented IP-based peer-to-peer ad hoc = networking=20 and a high performance wireless modems. 

The=20 successful candidate would be able to fulfill the following position=20 requirements:

IP=20 Security System Architect 

Looking=20 for a bright and enthusiastic individual to provide the security system = design=20 and to oversee the development of that design for a wireless IP network = designed=20 to support mobile subscribers.

Specific=20 Responsibilities

  • Develop=20 the network security requirements for a wireless IP based designed = product to=20 serve mobile voice, data, and video subscribers.
  • Provide the network = security=20 design for this wireless IP based network, providing an embedded = solution that=20 encompasses the subscriber’s transceiver device, wireless = routers, intelligent=20 access points, and standard infrastructure elements. =
  • Architect=20 a solution based on the use of industry standards and commercially = available=20 products.=20
  • Work=20 with selected vendors to ensure timely delivery and compliance to=20 specifications.=20
  • Lead the implementation = of the=20 selected security solution.
  • Write, publish and = present=20 technical white papers on security.
  • Articulate=20 a vision of security for the near- and long-terms. =

Minimum=20 Qualifications

  • MSEE/BSEE/CS=20 with a minimum of 10 years of network security design = experience.
  • Advanced=20 degree preferred.=20

Specific=20 Network Security Experience=20

 =20

=B7        =20 Experience=20 providing the embedded network security design for a telecommunications = network=20 and/or an Internet based network.

=B7        =20 Experience=20 with embedded network security system designs that provide the = following:  authentication, access = control, data=20 integrity, confidentiality, and intrusion detection and analysis. =

=B7        =20 Experience = providing=20 embedded network security design in a wireless communications=20 system.=20

=B7        =20 Highly=20 familiar with secure operating systems, asymmetric and symmetric key=20 cryptographic approaches, certificate management systems, key management = systems, authentication token exchange protocols, the vulnerabilities of = VPN=20 products, and bandwidth optimization approaches for deployment of = security=20 solutions in a wireless environment.

The=20 successful candidate will possess strong interpersonal and negotiation = skills=20 and will fit in well as a team player in a close knit, fast moving=20 multidisciplinary environment. This individual will have good command of = oral=20 and written presentation skills, and will be flexible, independent and = able to=20 work and communicate effectively at all levels, and with a variety of=20 organizations and vendors. 

I was=20 wondering if you would be interested in hearing about this exciting = career=20 opportunity or if you know anyone that might be interested in our=20 opportunity.    =20

Anyone=20 interested in pursuing this opportunity should email me a full resume = with=20 contact information as soon as possible and / or call me at their = earliest=20 convenience.  I can be = reached=20 toll-free at 877-331-3715. =20

Thank=20 you for taking the time to read this email and forward my contact = information to=20 any interested parties.  

Regards,

MC=20 Didone

Executive=20 Recruiter

ARC=20 Incorporated

877-331-3715

mcdidone@hotmail.com

 

------=_NextPart_000_00C6_01C0E844.C58016A0-- From owner-seamoby@diameter.org Thu May 31 14:56:01 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06162 for ; Thu, 31 May 2001 14:55:56 -0400 (EDT) Received: (qmail 15434 invoked by alias); 31 May 2001 18:42:03 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 15427 invoked by uid 200); 31 May 2001 18:42:02 -0000 Received: (qmail 15422 invoked from network); 31 May 2001 18:42:00 -0000 Received: from 205-158-62-43.outblaze.com (HELO spf11.us4.outblaze.com) (205.158.62.43) by c900656-a.plstn1.sfba.home.com with SMTP; 31 May 2001 18:42:00 -0000 Received: from mta1-3.us4.outblaze.com (205-158-62-44.outblaze.com [205.158.62.44] (may be forged)) by spf11.us4.outblaze.com (8.11.0/8.11.0) with SMTP id f4VIrBf07578 for ; Thu, 31 May 2001 18:53:12 GMT Received: (qmail 8215 invoked by uid 0); 31 May 2001 18:45:05 -0000 MBOX-Line: From owner-manet@itd.nrl.navy.mil Sat May 19 18:05:29 2001 Received: (qmail 24579 invoked from network); 18 May 2001 22:01:42 -0000 Received: from unknown (HELO spf1.us4.outblaze.com) (205.158.62.23) by 205-158-62-44.outblaze.com with SMTP; 18 May 2001 22:01:42 -0000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by spf1.us4.outblaze.com (8.11.0/8.11.0) with ESMTP id f4IM1Wp19930 for ; Fri, 18 May 2001 22:01:32 GMT Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id NAA02487 for manet-outgoing; Fri, 18 May 2001 13:50:23 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id NAA02482 for ; Fri, 18 May 2001 13:50:15 -0400 (EDT) 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 KAA23365; Fri, 18 May 2001 10:50:13 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f4IHo8u17753; Fri, 18 May 2001 10:50:08 -0700 X-mProtect: Fri, 18 May 2001 10:50:08 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdKaVMk6; Fri, 18 May 2001 10:50:06 PDT Message-ID: <3B0560D0.3B0DDC40@iprg.nokia.com> Date: Fri, 18 May 2001 10:50:08 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Nakhjiri Madjid-MNAKHJI1 CC: "'Jukka Manner'" , Hamid Syed , "'James Kempf'" , seamoby@diameter.org, Mobile Ad Hoc IETF working group Subject: Re: Wireless Terminology Draft( was: Re: [seamoby] Seamoby Charter Last Call) References: <35DBB8B7AC89D4118E98009027B1009B1B7BD7@IL27EXM10.cig.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello folks, I made an attempt a few years ago to develop such a terminology draft, within the context of the [manet] working group. Here is a URL for the draft if you are interested: http://people.nokia.net/~charliep/txt/manet/term.txt If you would like to use some of the definitions in that draft, and/or if you are looking for help in creating the new draft, I'd be happy to work on it. The draft was rejected within the [manet] working group for a reason that I thought was very curious. Essentially, the objection was made that every working group Internet Draft should contain its own terminology definitions, and that no common terminology draft was desirable. I disagreed with that reason then, and I still disagree with it, but I haven't felt a very strong need to take up the matter within the [manet] group since I didn't need yet another battle on my hands. I do think it would be a good idea to keep the terminology draft separated out from a more wide-ranging wireless issues draft, such as has generated a lot of recent interest on this mailing list. Regards, Charlie P. PS. to [manet] working group readers: I'd be happy to reintroduce the old draft, or a revision of it, for reconsideration. Nakhjiri Madjid-MNAKHJI1 wrote: > > Jukka, > > Thanks for taking charge on this. Did you do a diff on your > definitions and CT problem statement draft? Since you were > intimately involved with CT PS draft, I assume you did that. > I think we did a good job of defining CT related terminology, > but I don't know how it differred from MM or Paging terminology, > it would be nice to do a diff with those as well to have a WG > wide common terminology draft. > > Thanks again, > Madjid > > -----Original Message----- > From: Jukka Manner [mailto:jmanner@cs.Helsinki.FI] > Sent: Tuesday, May 15, 2001 1:25 AM > To: Hamid Syed > Cc: 'James Kempf'; seamoby@diameter.org > Subject: RE: Wireless Terminology Draft( was: Re: [seamoby] Seamoby > Charter Last Call) > > Hamid, > > Thank you for suggesting it. The draft was originally meant to > support the work in Seamoby, but it would be an even better idea to make it > a more thorough document for use in more or less all work relating to mobile > and > wireless environments, including Seamoby, Mobile-IP, and possibly MANET. > > I would be happy to continue the work on the terminology taking as > basis > the mentioned draft. > > BR, > > Jukka > > On Mon, 14 May 2001, Hamid Syed wrote: > > > Hello james, > > > > A draft was submitted to seamoby early this year that attempted to capture > > the wireless terminology. her eis the link: > > http://search.ietf.org/internet-drafts/draft-manner-seamoby-terms-01.txt > > > > br > > > > -Hamid > > > > > -----Original Message----- > > > From: James Kempf [SMTP:James.Kempf@Sun.COM] > > > Sent: Monday, May 14, 2001 1:47 PM > > > To: seamoby@diameter.org > > > Subject: Wireless Terminology Draft( was: Re: [seamoby] Seamoby > > > Charter Last Call) > > > > > > > > > ------------- Begin Forwarded Message ------------- > > > > > > Date: Mon, 14 May 2001 10:43:47 -0700 (PDT) > > > From: James Kempf > > > Subject: Re: [seamoby] Seamoby Charter Last Call > > > To: James.Kempf@sun.com, charliep@iprg.nokia.com > > > Content-MD5: 6F7Vl9kYVVbqr66TeEQyRw== > > > > > > Hi Charlie, > > > > > > > > > >> Maybe we need a terminology draft, or at least, define this term > > > >> somewhere so that it can be referred to. I'm suprised nobody > > > >> has done a generalized terminology draft for wireless terms before in > > > the MIP > > > >> group. > > > > > > > >RFC 2002 does start off with a long list of terminology. > > > > > > > >It is questionable whether any specific wireless terms are > > > >needed for a protocol running over IP. What is needed is > > > >a list of useful terms. For instance, one might care about > > > >error rate or bandwidth even if the medium were not wireless. > > > >I don't think that chip rate, for instance, should be part > > > >of the [seamoby] terminology list. > > > > > > > > > > Actually, there are plenty of wireless terms that need definition. > > > Access point, handoff (or handover IETF should select which one > > > it wants to use), context transfer, paging, etc. etc. > > > > > > >Do you think that there are terms which SHOULD have been defined > > > >for RFC 2002? If so, now would be a good time to mention them > > > >before RFC 2002bis goes to the RFC editor's desk. > > > > > > > > > > No, I think they have wider applicability. More and more wireless > > > stuff is going on. There are now two working groups associated > > > with wireless, and others that have a big wireless component. I think > > > having a > > > terminology draft that collects all terminology that could be referred > to > > > by > > > drafts would be a benefit. > > > > > > jak > > > > > > > > > > > > ------------- End Forwarded Message ------------- > > > > > > > > From owner-seamoby@diameter.org Thu May 31 16:45:09 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07844 for ; Thu, 31 May 2001 16:45:05 -0400 (EDT) Received: (qmail 2333 invoked by alias); 31 May 2001 20:32:51 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2327 invoked by uid 200); 31 May 2001 20:32:50 -0000 Received: (qmail 2322 invoked from network); 31 May 2001 20:32:48 -0000 Received: from mercury.sun.com (192.9.25.1) by c900656-a.plstn1.sfba.home.com with SMTP; 31 May 2001 20:32:48 -0000 Received: from heliopolis.eng.sun.com ([152.70.1.39]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA07733; Thu, 31 May 2001 13:42:39 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id NAA01314; Thu, 31 May 2001 13:41:59 -0700 (PDT) Message-Id: <200105312041.NAA01314@heliopolis.eng.sun.com> Date: Thu, 31 May 2001 13:42:00 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: [seamoby] Re: Wireless Terminology Draft To: Madjid.Nakhjiri@motorola.com, charliep@iprg.nokia.com Cc: jmanner@cs.helsinki.fi, hmsyed@nortelnetworks.com, James.Kempf@Sun.COM, seamoby@diameter.org, manet@itd.nrl.navy.mil MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: M1NbEXEz4PsHujlpPsGBHg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-seamoby@diameter.org Precedence: bulk Charlie, I think this is an excellent idea. IETF needs to get a common set of terminology for wireless. Leaving it up to the individual working groups means that someone from a different working group must translate terminology from one to another. Imagine the chaos if half the IETF RFCs referred to routers as routers and the other half as something else. This may actually be an IAB kind of item, perhaps we could get their sponsorship. It seems like the kind of thing they would do. In any event, I will take a look at your draft and submit comments. Thanks for taking the initative on this. jak >MBOX-Line: From owner-manet@itd.nrl.navy.mil Sat May 19 18:05:29 2001 >X-mProtect: Fri, 18 May 2001 10:50:08 -0700 Nokia Silicon Valley Messaging Protection >Date: Fri, 18 May 2001 10:50:08 -0700 >From: "Charles E. Perkins" >To: Nakhjiri Madjid-MNAKHJI1 >CC: "'Jukka Manner'" , Hamid Syed , "'James Kempf'" , seamoby@diameter.org, Mobile Ad Hoc IETF working group >Subject: Re: Wireless Terminology Draft( was: Re: [seamoby] Seamoby Charter Last Call) > > >Hello folks, > >I made an attempt a few years ago to develop such a terminology >draft, within the context of the [manet] working group. Here >is a URL for the draft if you are interested: > http://people.nokia.net/~charliep/txt/manet/term.txt > >If you would like to use some of the definitions in that draft, >and/or if you are looking for help in creating the new draft, >I'd be happy to work on it. > >The draft was rejected within the [manet] working group for >a reason that I thought was very curious. Essentially, the >objection was made that every working group Internet Draft should >contain its own terminology definitions, and that no common >terminology draft was desirable. I disagreed with that reason >then, and I still disagree with it, but I haven't felt a very >strong need to take up the matter within the [manet] group >since I didn't need yet another battle on my hands. > >I do think it would be a good idea to keep the terminology >draft separated out from a more wide-ranging wireless issues >draft, such as has generated a lot of recent interest on this >mailing list. > >Regards, >Charlie P. > >PS. to [manet] working group readers: I'd be happy to reintroduce > the old draft, or a revision of it, for reconsideration. > > > > >Nakhjiri Madjid-MNAKHJI1 wrote: >> >> Jukka, >> >> Thanks for taking charge on this. Did you do a diff on your >> definitions and CT problem statement draft? Since you were >> intimately involved with CT PS draft, I assume you did that. >> I think we did a good job of defining CT related terminology, >> but I don't know how it differred from MM or Paging terminology, >> it would be nice to do a diff with those as well to have a WG >> wide common terminology draft. >> >> Thanks again, >> Madjid >> >> -----Original Message----- >> From: Jukka Manner [mailto:jmanner@cs.Helsinki.FI] >> Sent: Tuesday, May 15, 2001 1:25 AM >> To: Hamid Syed >> Cc: 'James Kempf'; seamoby@diameter.org >> Subject: RE: Wireless Terminology Draft( was: Re: [seamoby] Seamoby >> Charter Last Call) >> >> Hamid, >> >> Thank you for suggesting it. The draft was originally meant to >> support the work in Seamoby, but it would be an even better idea to make it >> a more thorough document for use in more or less all work relating to mobile >> and >> wireless environments, including Seamoby, Mobile-IP, and possibly MANET. >> >> I would be happy to continue the work on the terminology taking as >> basis >> the mentioned draft. >> >> BR, >> >> Jukka >> >> On Mon, 14 May 2001, Hamid Syed wrote: >> >> > Hello james, >> > >> > A draft was submitted to seamoby early this year that attempted to capture >> > the wireless terminology. her eis the link: >> > http://search.ietf.org/internet-drafts/draft-manner-seamoby-terms-01.txt >> > >> > br >> > >> > -Hamid >> > >> > > -----Original Message----- >> > > From: James Kempf [SMTP:James.Kempf@Sun.COM] >> > > Sent: Monday, May 14, 2001 1:47 PM >> > > To: seamoby@diameter.org >> > > Subject: Wireless Terminology Draft( was: Re: [seamoby] Seamoby >> > > Charter Last Call) >> > > >> > > >> > > ------------- Begin Forwarded Message ------------- >> > > >> > > Date: Mon, 14 May 2001 10:43:47 -0700 (PDT) >> > > From: James Kempf >> > > Subject: Re: [seamoby] Seamoby Charter Last Call >> > > To: James.Kempf@sun.com, charliep@iprg.nokia.com >> > > Content-MD5: 6F7Vl9kYVVbqr66TeEQyRw== >> > > >> > > Hi Charlie, >> > > >> > > >> > > >> Maybe we need a terminology draft, or at least, define this term >> > > >> somewhere so that it can be referred to. I'm suprised nobody >> > > >> has done a generalized terminology draft for wireless terms before in >> > > the MIP >> > > >> group. >> > > > >> > > >RFC 2002 does start off with a long list of terminology. >> > > > >> > > >It is questionable whether any specific wireless terms are >> > > >needed for a protocol running over IP. What is needed is >> > > >a list of useful terms. For instance, one might care about >> > > >error rate or bandwidth even if the medium were not wireless. >> > > >I don't think that chip rate, for instance, should be part >> > > >of the [seamoby] terminology list. >> > > > >> > > >> > > Actually, there are plenty of wireless terms that need definition. >> > > Access point, handoff (or handover IETF should select which one >> > > it wants to use), context transfer, paging, etc. etc. >> > > >> > > >Do you think that there are terms which SHOULD have been defined >> > > >for RFC 2002? If so, now would be a good time to mention them >> > > >before RFC 2002bis goes to the RFC editor's desk. >> > > > >> > > >> > > No, I think they have wider applicability. More and more wireless >> > > stuff is going on. There are now two working groups associated >> > > with wireless, and others that have a big wireless component. I think >> > > having a >> > > terminology draft that collects all terminology that could be referred >> to >> > > by >> > > drafts would be a benefit. >> > > >> > > jak >> > > >> > > >> > > >> > > ------------- End Forwarded Message ------------- >> > > >> > > >> > > From owner-seamoby@diameter.org Thu May 31 17:50:48 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA08755 for ; Thu, 31 May 2001 17:50:48 -0400 (EDT) Received: (qmail 5623 invoked by alias); 31 May 2001 21:22:42 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 5617 invoked by uid 200); 31 May 2001 21:22:42 -0000 Received: (qmail 5603 invoked from network); 31 May 2001 21:22:36 -0000 Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157) by c900656-a.plstn1.sfba.home.com with SMTP; 31 May 2001 21:22:36 -0000 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f4VLW7E17651 for ; Thu, 31 May 2001 17:32:07 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 31 May 2001 17:31:35 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 May 2001 17:31:40 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5C5D@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'seamoby'" Cc: "'Pat Calhoun'" Subject: [seamoby] ct problem statement Date: Thu, 31 May 2001 17:31:41 -0400 Sensitivity: Company-Confidential MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" X-Orig: Sender: owner-seamoby@diameter.org Precedence: bulk Pat: I'm afraid to ask, but I must. What's up with the ct problem statement? Gary From owner-seamoby@diameter.org Thu May 31 18:11:07 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA09176 for ; Thu, 31 May 2001 18:11:07 -0400 (EDT) Received: (qmail 7089 invoked by alias); 31 May 2001 22:00:43 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 7083 invoked by uid 200); 31 May 2001 22:00:42 -0000 Received: (qmail 7076 invoked by uid 500); 31 May 2001 22:00:41 -0000 Date: Thu, 31 May 2001 15:00:40 -0700 From: Pat Calhoun To: Gary Kenward Cc: "'seamoby'" , "'Pat Calhoun'" Subject: Re: [seamoby] ct problem statement Message-ID: <20010531150040.C1078@charizard.diameter.org> Mail-Followup-To: Gary Kenward , 'seamoby' , 'Pat Calhoun' References: <9FBD322B7824D511B36900508BF93C9C9F5C5D@zcard031.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <9FBD322B7824D511B36900508BF93C9C9F5C5D@zcard031.ca.nortel.com>; from gkenward@nortelnetworks.com on Thu, May 31, 2001 at 05:31:41PM -0400 Sender: owner-seamoby@diameter.org Precedence: bulk On Thu, May 31, 2001 at 05:31:41PM -0400, Gary Kenward wrote: > Pat: > > I'm afraid to ask, but I must. What's up with the ct problem statement? > Let me check with our ADs. PatC From owner-seamoby@diameter.org Thu May 31 21:22:30 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA11231 for ; Thu, 31 May 2001 21:22:29 -0400 (EDT) Received: (qmail 9453 invoked by alias); 1 Jun 2001 01:11:44 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 9447 invoked by uid 200); 1 Jun 2001 01:11:44 -0000 Received: (qmail 9442 invoked from network); 1 Jun 2001 01:11:42 -0000 Received: from f242.law9.hotmail.com (HELO hotmail.com) (64.4.9.242) by c900656-a.plstn1.sfba.home.com with SMTP; 1 Jun 2001 01:11:42 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 31 May 2001 18:21:25 -0700 Received: from 129.107.62.3 by lw9fd.law9.hotmail.msn.com with HTTP; Fri, 01 Jun 2001 01:21:24 GMT X-Originating-IP: [129.107.62.3] Reply-To: hardikatuta@yahoo.com From: "Hardik Gandhi" To: seamoby@diameter.org Subject: [seamoby] how to sign up Date: Fri, 01 Jun 2001 06:51:24 +0530 Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 01 Jun 2001 01:21:25.0079 (UTC) FILETIME=[2CB9E670:01C0EA39] Sender: owner-seamoby@diameter.org Precedence: bulk
hi friends,
   i am a graduate student of university of texas arlington and i am interested in seamoby how can i sign up for ietf and see all the discussion regarding this . can you help me out
thanks
hardik

Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.